The first implementation slice gave me the number I did not want. The documented estimate was 66 hours. After implementation, design review, hidden data work, framework setup, security hardening, infrastructure, and remediation were counted, the same slice modelled closer to 226 hours of traditional effort.

The original planning method was good at extracting user-facing feature work from the material I had: screens, entities, routes, permissions, forms, states, and acceptance criteria. It estimated the feature layer, which is much better than starting with a blank backlog or a vague list of "admin area" tasks. But a feature spec is not a delivery spec.

The Earlier Estimate Had A Boundary

The previous scoping work came from a practical question: can a two-hour client call be turned into a structured delivery model? It could. The call became a transcript, the transcript became requirement areas, the screens became field lists, and the feature groups became a plan with rough hour estimates. It gave me a map of the visible system quickly enough that I could start reasoning about a six-month project instead of staring at a wall of unknowns.

The boundary was too narrow: the estimate captured the feature as it appeared from the outside, what a user would see, edit, navigate, save, approve, search, or publish. It did not force enough questions about the work needed to make that feature real inside a live system.

AI can accelerate the work that is already named. It can generate entities, controllers, migrations, forms, tests, commands, fixtures, and review fixes much faster than I can type them by hand. What it does not do automatically is notice every category of work I failed to name.

If the plan says "build the content editor", the agent will help build the content editor. If the plan forgets that old content has to be imported, cleaned, mapped, rolled back, seeded into review environments, and secured against the new permission model, the agent may still do a lot of work. It just will not be working from a complete delivery model.

The Miss Split Into Three Buckets

The final number split into three useful buckets. The original documented scope was 66 hours. That was the visible feature work: data model, migrations, edit screens, list views, routes, permissions, publishing states, tests, and the first version of the interaction model.

Unexpected additions after review added roughly 75 hours. Some of this was normal design reality. Once the client could see the work, choices that had sounded fine in the abstract became easier to judge. Some of it was also a planning miss that can be improved next time: design review happened too late, so a navigation-pattern change, additional curation screens, and more specific search behaviour entered the slice after the scope had already been treated as stable. Some pieces were later deferred or split out, but they had still entered the slice as real scope pressure.

The hidden delivery requirements added roughly 85 hours. This is the bucket that matters most to me, because it was predictable in hindsight.

It included import work. Existing data was not going to walk into the new system by itself. A manual import would have been unreliable, slow, and impossible to repeat safely. The real requirement was an idempotent import path with legacy identifiers, insert/update/delete behaviour, verification, cleanup rules, rollback, and enough logging to trust the result.

It included framework and toolchain work. The feature was not being built in isolation. It needed asset handling, editor integration, sortable interfaces, timezone decisions, inheritance mapping, pagination, search behaviour, and the small framework-specific decisions that only become visible when a screen stops being a mock-up and becomes code. Luckily this is mostly a once-per-project cost, with smaller refinements later.

It included security work. The visible requirement might say "one editor role", but the implementation had to answer sharper questions: who can create, edit, delete, reorder, publish, submit AJAX changes, or access soft-deleted records? Which fields need sanitising? Which junction IDs need validating against the database instead of trusting the request?

It included infrastructure work. Review needed an environment. That environment needed seed data, secrets alignment, deploy scripts, dump and restore scripts, and enough visible state that I could tell whether a branch was showing current work or stale data.

It also included review remediation: inspecting boundaries, duplicated logic, missing validation, unsafe assumptions, and places where the implementation followed the prompt too literally.

"Just Add Contingency" Is Too Blunt

The lazy answer is to add a contingency percentage. That would hide the lesson. If a 66-hour slice becomes 226 hours, adding 20% or 30% to the next estimate does not tell me much. It might make the spreadsheet look more mature, but it does not improve the planning method. The important question is not "how large should the padding be?" The important question is "which categories were absent from the plan?"

For this slice, the absent categories were specific enough to become reusable:

  • If a slice touches legacy data, ask for import work explicitly.
  • If it introduces or stretches a framework pattern, ask for toolchain and integration work explicitly.
  • If it writes business data, ask for security hardening explicitly.
  • If someone has to review the branch, ask for review infrastructure explicitly.
  • If AI agents are generating implementation, ask for review remediation explicitly.

The Multiplier Does Not Apply Evenly

This also changes the six-month question. A six-month project gives me roughly 1,000 hands-on hours. The tempting mistake is to multiply all of those hours by the strongest number from previous AI-assisted work and call that the project capacity.

That is not how the work behaves. Some work is highly compressible. Conventional CRUD, migrations, forms, tests, repositories, fixtures, and repetitive framework code can move very quickly when the patterns are clear.

Some work compresses less. Legacy import rules, security decisions, data cleanup, environment behaviour, and review remediation require judgement. AI still helps, but the limiting factor is not typing speed.

Some work is not implementation at all. It is waiting for feedback, interpreting a design reaction, checking whether a client can live with a workflow, deciding whether to defer something, or rebuilding a slice boundary after new information appears.

The Method Has To Change

This is where the planning method has to account for the delivery layer. The early checklist asked good feature questions: what is the UI, what are the entities, what routes exist, what security rules apply, and what does done mean?

The next version needs a delivery layer underneath those questions:

  • What data has to move from the old system?
  • What import path makes that movement repeatable?
  • What framework conventions or toolchain pieces does this slice depend on?
  • What security checks exist beyond the visible role label?
  • What review environment does this slice need?
  • What seed data must exist before review is meaningful?
  • What remediation time should be expected after AI-generated implementation?

I do not need the first estimate to be final. I need it to be structured enough that implementation can show me exactly which categories were missing, so the next slice is planned with those categories already on the page.