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.

Build fast without undermining human judgment.

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 result is something I want. An agent can implement, investigate, run checks, review code, challenge my decisions, and prepare evidence. I still own the product intent, tradeoffs, and acceptance.

Passing tests, a clean security scan, an approval status, or a convincing generated review does not tell me whether I understand the change or think it is the right product decision. A CSV export can pass every check and still be wrong for the workflow if it exports the current page when the user needs every matching result. That choice needs human agreement, even if the ticket never spelled it out.

I need to understand why the change exists, how its behavior works, what it interacts with, what must remain true, and its important failure cases. That is enough understanding to own the affected behavior and assess the evidence. It does not require every teammate to memorize the entire codebase.

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.

What I want the interview to uncover

My /grill-me base asks one question at a time, recommends an answer from the available context, and explains what that answer changes. It investigates what it can before asking me. I want it to resolve the decisions that matter, then stop. Four directions help:

• What would make this the wrong solution even if it met the literal acceptance criteria and passed every automated check?
• What must I be able to explain about this change before considering it complete?
• What plausible incorrect implementation could still pass these checks?
• What decision or constraint must the next engineer understand without reconstructing this entire chat?

These are directions for the conversation, not four questions to repeat on every ticket. An engineer with the context can supply both product and technical judgment. Bring in a product partner or client when their input is needed. Solo use is enough.

For a bug fix, a test that stays green while the behavior is broken gives me little reason to accept the fix. I want verification that can expose the defect, such as reproducing it and showing the regression test fail before the fix. Implementation and tests can share the same mistaken assumption. The evidence helps me judge correctness; it does not decide whether I want the feature.

Record the accepted scope and material tradeoffs in the ticket or existing documentation. Extra features and changed behavior need human agreement. Preserve important contracts and the reasoning behind verification where the next engineer can find them. The amount of explanation should fit the change.

Why I start with three

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.”

Kevin O'Leary describes a focus rule he says he learned from Steve Jobs: choose three important things to get done that day and do those first. In his Build or Break interview, he talks about protecting those priorities from everything competing for his attention.

That resonates with Kasperowski's account and my own experience. Agents can work on more things than I can responsibly understand and judge. I still have to choose where my attention goes.

My extension is to start with three substantial ticket contexts receiving an engineer's attention each day, including work that continues tomorrow. We can raise or lower that default during refinement based on the person and the work.

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. Count ticket contexts, not PRs, meetings, or review activities. Several small PRs may deliver one coherent ticket; their count tells me little about whether the engineer understands the combined outcome.

One to three substantive contexts feels consistent with my own experience. Three is my starting default, not a scientific limit or a performance quota.

Size an outcome as Day or Week

I still want meaningful tickets. First establish how the team works. A specialist team might use related frontend and backend tickets; a full-stack team might own the feature in one ticket. Each ticket gets one responsible role and a clear outcome someone can 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. 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.
• An engineer using the default of three contexts per day has 15 planned item-days in a five-day working 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.

With that default, adding the Day items to five times the Week items and dividing by 15 gives the model's initial demand in engineer-weeks. Different people can have different integer capacities. An AI engineer might carry two contexts per day, while a data engineer carries one. That changes the arithmetic, but neither count promises that many daily completions. I still need to place the actual work on a calendar.

The calendar still has to work. A dependency can force two items to run in sequence. People join later, roll off earlier, take vacations, and have different working days. I want names when we know them and role-based placeholders when we do not. Each person belongs to one role in the plan, so we do not count the same person twice. 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 skill

Attention-First Engineering is available in my public GitHub repository, with installation instructions for Codex and Claude Code. Both plugins use the same skill: my /grill-me interview base plus the human-judgment and Attention-First planning rules. It runs inside the assistant you already use, and you can start with a sentence.

The repository contains the canonical skill, worked examples, and evaluation scenarios. The scenarios include an unresolved product decision hidden behind passing checks, a green test that misses broken behavior, and a coherent ticket delivered through several PRs. I am not claiming those scenarios have been run against a live model.

I have also incorporated the approach behind HumanLayer's show-me: use a small diagram or table when it helps us understand the decision. Interview questions stay in the conversation.

The final output can be a standalone HTML planning view with a dated timeline, backlog, and ticket details. Change a target from six weeks to four, adjust staffing by role, and inspect where dependencies still set the finish. It supports individual capacity, working calendars, joining and roll-off dates, time off, CSV export, and saving the selected scenario as HTML. Product, design, and QA are optional parts of the team; they do not automatically receive tickets or count as engineering capacity.

The calculations are a planning aid. Adding people does not automatically shorten an individual ticket, and changing someone's working pattern can invalidate the estimate. The staffing suggestion is a bounded heuristic, not proof of the smallest team or a delivery guarantee. The initial hidden-capacity treatment for routine bugs remains a separate planning assumption.

The plugin follows the Codex skill documentation and Claude Code skill documentation.

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?