Productivity Numbers Come From Greenfield, Our Work Does Not
A customer showed us a study reporting a large productivity gain and asked why our estimate did not reflect it. The study measured people writing new code with no existing constraints, and our work is the opposite of that in every respect that matters.
The Question and Why It Is Fair
The customer was not being difficult. Published figures for AI-assisted development are large and consistent enough to be worth asking about, and a supplier whose estimate ignores them owes an explanation rather than a shrug.
Our explanation is that almost all of those figures come from writing new code. New code has no existing conventions to respect, no downstream systems depending on its current behaviour, and no fifteen-year-old assumptions encoded in a module nobody has opened since 2014.
What Brownfield Actually Costs
Sharma published work in late 2025 arguing that brownfield engineering is a distinct category rather than greenfield with obstacles, and proposing a framework for where assistance actually helps in existing systems.
The distinction is the useful part. In an existing system, most of the work is establishing what is true before anything can be written: which behaviour is intentional, who depends on it, what breaks if it changes. Assistance helps with a slice of that and not the largest slice.
Where It Genuinely Helps
Reading. An assistant that answers what calls this function and where is this configuration value used replaces a slow search with a fast one, and on a large unfamiliar codebase that is a real saving that we have measured at roughly a third of orientation time.
Writing tests for existing behaviour is the second. Characterisation tests are mechanical, tedious and exactly the work people postpone, and an assistant that drafts them from observed inputs and outputs turns a week into two days.
| Task | Effect of assistance |
|---|---|
| Writing new code with no constraints | Large gain. Not our work |
| Understanding existing code | Real gain, about a third of orientation |
| Drafting characterisation tests | Large gain. Mechanical work |
| Deciding what may change | None. This is the bottleneck |
Where It Does Not Help At All
The decision about what is allowed to change. That is a conversation with the people who own the downstream systems, and it moves at the speed of their availability and their willingness to accept risk.
On our last three brownfield projects, that conversation was between forty and sixty percent of elapsed time. No amount of faster code production compresses it, and a plan that assumes otherwise produces a team waiting with completed work for a decision nobody has made.
The Number We Quote
Between fifteen and twenty-five percent on total elapsed project time, against the fifty and more that some published figures suggest. We say where it comes from: the reading and testing phases compress substantially, the decision phases do not, and the ratio between them decides the total.
Customers respond well to the decomposition. What they object to is a number without a structure, because they have usually been given one before and watched it not materialise.
The Trap in Measuring It
Lines of code and pull request counts both rise, which makes it easy to report a gain that has not occurred. On one project our throughput measured by merged changes rose by a third while the delivery date did not move, because the extra changes were in areas nobody was waiting for.
We now measure elapsed time to a delivered capability, which is a worse metric in every respect except that it is the one the customer is paying for. It is noisy, it is slow to collect, and it does not flatter anyone.
What This Means for Scoping
Front-load the decisions. On the projects that went well, the first two weeks were spent getting the downstream owners into a room and writing down what may change, before anyone wrote code that might not be allowed to ship.
That is an unglamorous recommendation and it is the single strongest predictor we have of whether a brownfield project finishes near its estimate. The assistant makes the building faster; the permission is what makes the building possible.
What We Do Not Claim
We do not claim published greenfield figures are wrong. They measure what they measure, the methodology is often sound, and for a team starting a new service they are probably the right expectation to set.
We also do not claim our fifteen to twenty-five percent is precise. It comes from a handful of projects with different shapes, it has a wide spread, and we quote it as a range with its reasoning rather than as a figure anyone should plan a budget around to the percent.