How should we estimate work when agents write the code?

I still need to give someone an estimate

How many engineers do we need? Is the team we have enough? Should we hire? How long will this scope take?

Those questions still need answers when agents write most of the code. They are practical questions I need to help clients answer. I am less sure that the estimation tools I used before are giving me useful answers now.

At Umbrage, we worked backward from the desired end state. We broke it into features and estimatable tickets, used Fibonacci planning poker, and worked out staffing and duration. That worked reasonably well.

Now planning poker, hour estimates, and T-shirt sizes feel less useful to me. I can guide an agent through an implementation quickly. Understanding what it built, deciding whether it is good, and checking it properly still take something out of me.

I am calling my current proposal Attention-First Engineering. I almost called it mental capacity planning. It is an attempt to estimate around the human attention the work needs. I have not validated it as a forecasting method, and I want to hear how other teams are approaching this.

Human taste and judgment are the constraint I care about

I can have several agents working at once. That does not mean I can understand an unlimited number of unrelated changes. After too many things, my brain is fried.

I need to understand the problem, question the approach, read the code, and make sure the output is not slop. An agent finishing its task is only part of that work.

This is why I do not believe in dark software factories as the model for my team and the clients I advise. I believe we need human taste and judgment, including engineers who understand the code they are responsible for.

There is a serious opposing approach. In StrongDM's software factory description, Justin McCarthy describes agents building from specifications and scenarios without human code writing or review. They use external scenarios and digital twins of dependent services for validation. Removing human code review does not remove human specification or evaluation design. My disagreement is with removing that code understanding from the engineer's job in the work I am planning.

HumanLayer's workflow puts human collaboration and reviewable design artifacts early in the process. Its emphasis on engineers continuing to think and make architectural decisions resonates with me. That supports the judgment part of this proposal. It does not establish a capacity number.

Where three came from

Richard Kasperowski's “I Gave Six AI Agents a Scrum Board (And Measured What Happened)” gave me a useful starting point.

He describes acting as Product Owner and CTO while six coding agents work in three pairs. In his account, answering their questions constrained the team to three completed backlog items per day: coded, reviewed, tested, and ready for his push decision. He writes, “I'm the constraint, not them.”

That is his practitioner experience. He is describing completed items passing through one human PO. My extension is to plan at most three substantial items receiving an engineer's attention in a day, including work that continues tomorrow.

That distinction matters. A Week item can occupy one slot all week. Finishing an item at lunchtime still means it used a context that day. Starting more agent processes does not create more human capacity.

One to three substantive contexts feels consistent with my own experience. Three is my starting planning ceiling, not a scientific limit or a performance quota. Kasperowski's experience did not validate this extension or the staffing arithmetic below.

Size an outcome as Day or Week

I still want meaningful tickets. Start with an outcome someone can independently verify, such as being able to download filtered search results as a CSV. Include the implementation and verification needed to make that outcome real.

Then use two sizes:

• Day: A coherent outcome that can reach engineering completion within a normal working day.
• Week: A coherent outcome that can reach engineering completion within a normal working week.

Engineering completion includes understanding the work, guiding agents, reading and refining the code, developer testing, human review, and merge. QA acceptance and release may happen separately. A Day estimate does not promise that a client will accept or receive the feature that day.

These are elapsed completion windows with shared attention. They do not mean eight or forty hours of undivided human effort. Size the item alongside the other work the engineer is expected to carry. Three items that each need nearly all of someone's attention do not become feasible because they fit in three boxes.

Try Day first, then Week. If the work is larger than Week, split it into meaningful outcomes. Creating separate tickets for every file or administrative step would defeat the purpose. If an unknown prevents a sensible estimate, leave it visible and resolve it before assigning a size.

Turn that into an initial forecast

I want to calculate a starting forecast directly from those sizes. I do not want an empirical pilot to be a prerequisite for putting an initial team and duration proposal together.

For a simple five-day week, my untested starting assumption is:

• One Day item consumes one planned item-day.
• One Week item consumes five planned item-days, occupying one slot on each active day.
• A fully allocated engineer proficient with agentic coding has three slots per day, or 15 planned item-days per week.

That arithmetic allows up to 15 Day items, three concurrent Week items, or a mixture. Here is one illustrative mix for one engineer:

Planned work	Use of the five-day week
One Week item	One slot each day: 5 item-days
Two different Day items each day	Two slots each day: 10 item-days
Total	One Week item and ten Day items: 15 item-days

This is what the model assumes, not an observed productivity result. The mixed plan only works if those outcomes are sized to finish under that combined workload and their dependencies allow the schedule.

For an initial forecast, add the Day items to five times the Week items. Dividing by 15 gives the model's demand in fully allocated engineer-weeks. I can use that to compare candidate team sizes and durations, then place the actual work on a calendar.

The calendar still has to work. A dependency can force two items to run in sequence. Part-time availability changes capacity. The team needs the right skills and roles. Human review consumes someone's attention too. Adding engineers does not automatically fix a shared architecture decision or a reviewer who is already full.

We have moved our internal team from sprints to Kanban, and we discuss which features to tackle next month. This is the kind of planning conversation I want the model to help with: what can we reasonably take on, and who needs to be involved?

What about bugs and interruptions?

For a routine small bug, my first step is usually to ask an agent to fix it and write a regression or unit test. I think of those small, readily resolved bugs as hidden capacity outside the initial planned-scope estimate.

I am not adding a default numerical reserve for unknown bug demand to the initial team-size or project-duration calculation. That is a deliberate choice in this proposal. It leaves the forecast exposed to interruptions; the correctness check and my attention are not free.

When the agent cannot readily resolve a bug and it needs substantial engineering attention, it becomes a Day or Week item. It displaces planned work or moves the date. Calling it hidden capacity cannot make that work disappear.

If that happens often enough to make the initial forecasts consistently wrong, I need to revise the model. I would also revisit it if engineers cannot sustain the proposed mix while understanding and reviewing the results.

Try the starter skills

I have packaged my current approach for Codex and Claude Code. These are essentially my grill-me interview base plus the Attention-First planning rules: clarify the outcome, resolve decisions, shape meaningful tickets, size Day or Week, and check the three-context ceiling with the engineer.

For a project-local setup, extract the appropriate ZIP while preserving its folder contents:

• Codex: Place the attention-first folder under .agents/skills/, giving you .agents/skills/attention-first/SKILL.md.
• Claude Code: Place the attention-first-engineering folder under .claude/skills/, giving you .claude/skills/attention-first-engineering/SKILL.md.

Those paths follow the Codex skill documentation and Claude Code skill documentation. Ask the agent to use the skill to refine a feature or backlog with you.

These are prompt skills, not a measured capacity engine. The initial arithmetic and bug treatment above are further clarifications; the packages do not automate those calculations. They include evaluation scenarios, but I am not claiming those scenarios have been run.

I want to use this to make an estimate I can explain, then compare it with what actually happens. How are you estimating work with agentic coding? What are you counting, and where does your team's attention run out?