Status Droid how long software work actually takes

Greenfield Versus Mature Code

Two developers describe their experience with the same assistant and disagree completely. One says it transformed their work. The other says it slows them down and produces things they have to unpick.

Both are usually telling the truth. They are working in different kinds of codebase, and the difference is large enough to reverse the sign of the effect. For teams translating this assistant-related trade-off into day-to-day controls, employee PC activity tracking provides a practical reference.

Why greenfield behaves well

There are no conventions to violate, because there are none yet. Whatever the model produces establishes the pattern rather than contradicting one.

Nothing depends on it. Wrong is cheap. You find out immediately and change it, and nobody else has built on top.

No implicit standards. No coverage expectation, no documentation policy, no architectural decision made three years ago whose reasons are undocumented.

Verification is proportional to a small surface. The whole thing fits in your head. Anthropic publishes research on model behavior, reliability, and agentic systems See Anthropic Research.

So generation converts almost fully into progress, and the experience of a very large speedup is accurate. It is the cheap-to-verify hump of the distribution, and prototypes sit at the extreme end of it.

Why mature repositories behave badly

Every advantage above, inverted.

Conventions exist and are mostly unwritten. How errors are handled, where validation lives, which of three similar abstractions is the current one. The model infers from ecosystem norms and produces code that is correct in general and wrong here.

Things depend on it. A change that works locally can break something two modules away, and finding that out is the expensive part.

Standards are implicit and enforced. Coverage thresholds, formatting, documentation, review expectations. METR's participants were working in repositories averaging around a million lines with high implicit quality bars, which the authors specifically identify as a setting where AI capabilities are comparatively lower.

The surface is large. Verification means reasoning about a system you cannot hold entirely in mind.

This is the setting where METR measured a 19% slowdown — later revised toward a speedup in a follow-up the authors themselves describe as weak evidence, but with the mechanism unchallenged. The number moved; the explanation did not.

Where the crossover happens

Not a bright line, and there are recognisable markers. A project stops behaving like greenfield when:

Someone else is depending on the code. Another team, a customer, an integration. Consequences become external.

There are conventions you would defend. The moment "we do it this way here" is a real sentence, a model that does not know that will produce friction.

The tests exist and matter. Which is good, and it means changes now have to satisfy something.

Nobody holds the whole system in their head. Usually earlier than people think. Around the point where the codebase outgrows one person's working memory, verification cost steps up sharply.

Most projects cross in the first few months, well before anyone would call them legacy. The productivity you had in week two is not the productivity you will have in month six, and estimating month six on week two's experience is a common and expensive mistake.

What to change as you cross

Write the conventions down. Not for the model specifically — but a file describing how errors are handled, where things live, and what the preferred patterns are, is now directly useful because you can give it to the assistant along with the task. This is the cheapest single intervention available and almost nobody does it.

Shrink the changes. Review cost grows faster than linearly, and it grows fastest in complex systems.

Move the assistant toward the verification side. Explaining existing code, finding unhandled cases, reviewing your implementation — uses that help where generation does not.

Re-estimate the ratios. Your production-to-verification split from the prototype phase is now wrong in a predictable direction. Widen the verification half.

The practical warning for studios

The dangerous pattern is quoting a build from prototype experience.

The prototype went beautifully — generation-heavy, no consequences, everything fast. The production version is the same features in a system with real users, real data and real standards, and it is a different bucket entirely.

A prototype is not a small version of the product. It is a different kind of work, and the ratio between them changed when generation got cheap. If you are pricing from prototype velocity, you are pricing the wrong hump.

The short version