The productivity numbers being reported for AI-assisted engineering are real, and they measure the wrong thing.
They measure how quickly code gets written. That was rarely what limited a competent engineering organisation. What limited it was deciding what to build, agreeing how it should fit together, and being confident that what shipped was correct.
None of those got cheaper. One of them got considerably harder.
The bottleneck moved
Every engineering organisation has a constraint. For most of the last two decades it sat in production: the sheer labour of turning an agreed design into working software.
That constraint has genuinely loosened. Work that took a week takes a day, and a small team can now build what recently required a department.
When you relieve a constraint, you do not become uniformly faster. You discover the next constraint, and it is usually one you were not managing because it never had to bear any weight.
For most organisations, the next constraint is review, and the one behind it is architecture.
What got cheaper, and what did not
Producing a plausible implementation of a well-specified thing is now cheap. So is the surrounding work that used to consume afternoons: tests, documentation, migrations, the third variation of a form.
Deciding what should exist did not get cheaper. Nor did working out how a change interacts with the four systems it touches, or carrying the consequences when it is wrong at two in the morning.
There is an asymmetry here worth naming plainly. The cost of producing a change has fallen dramatically. The cost of understanding a change has barely moved, because it is bounded by human attention rather than by typing.
An organisation that increases production without increasing its capacity to understand what it produces has not become more productive. It has become more leveraged, in both directions.
Three ways the debt accumulates faster
Volume outruns review. Review capacity is roughly fixed. When the amount of code arriving at it multiplies, the honest responses are to review less carefully or to queue. Most teams do the first without deciding to. Approval rates stay high, review depth quietly falls, and the defects that get through are the subtle ones that careful reading would have caught.
Wrong code looks right. This is the genuinely new hazard. Code produced with AI assistance is idiomatic, well-structured and confident. Its mistakes are not the ragged mistakes of a tired engineer, which reviewers are trained to spot. They are clean, plausible and wrong in ways that require actually thinking about the problem to see. The usual review heuristics, which lean heavily on how code looks, are much less reliable than they were.
Ownership thins out. Someone who wrote a subsystem by hand carries a model of it for years. Someone who generated, reviewed and merged it carries much less. The code is fine. The understanding around it is thinner, and understanding is what you need in an incident. Repeat this across a codebase and you get a system nobody holds a complete picture of, which is the definition of a system that is expensive to change.
None of this is an argument against using AI in engineering. It is an argument that the practices around it have to change at the same time, and in most organisations they have not.
What actually holds
The countermeasures are unglamorous and mostly predate all of this.
Architecture that constrains. Clear boundaries, explicit interfaces and a small number of ways to do common things. Strong architecture has always reduced the cost of review, because a reviewer only has to reason about one component rather than the whole system. That property is worth far more now than it was three years ago.
Standards a machine can check. Anything that can be enforced automatically should be, because it removes it from human review and leaves attention for the things only a person can assess. This is the highest-return investment most teams are not making.
Evaluation that tests behaviour, not shape. Tests that assert what the system should do, including under failure and ambiguity, rather than mirroring how it currently works. Generated code passes shape-shaped tests easily. Behaviour is harder to fake.
Review that protects depth. Fewer, deeper reviews on the changes that matter, and mechanical review for the ones that do not. Treating every change as equally deserving of attention guarantees the important ones get too little.
Named ownership. Somebody senior owns each part of the system, and owning it means understanding it well enough to be woken up about it. This is now a deliberate act rather than a natural consequence of having written the thing.
Speed you cannot trust is borrowed
There is a version of this argument that matters most at the very start of a venture, where the temptation to defer all of it is strongest.
A product that ships quickly but cannot be trusted is not moving fast. It is borrowing time from the future, and the loan is called in at the worst possible moments: investor diligence, an enterprise customer's security review, a regulator's questions, the first serious incident, or simply success.
The answer is not enterprise process in a week-old company. It is enough technical hygiene for the venture to survive its own success: architecture decided before major build work, security treated as a launch gate, no secrets in code, tests and continuous integration from the start, monitoring live before launch, and AI-generated code reviewed as seriously as anything a person wrote.
None of that slows a team down. It is what lets a team keep moving fast once the stakes rise.
The measurement trap
The last risk is what gets reported upwards.
Output metrics are easy to gather and they all look excellent right now. Changes merged, features shipped, lines produced. A board hearing those numbers will reasonably conclude that engineering has become dramatically more effective.
The metrics that would tell you whether that is true are slower and less flattering: change failure rate, time to restore, the proportion of work that is rework, how long a new engineer takes to become productive, and whether the cost of the next significant change is going up or down.
If production has doubled while change failure rate has crept up and rework has grown, the organisation is not faster. It is accumulating debt more efficiently, and it will find out in about eighteen months.
Speed and craftsmanship were never opposed. The challenge has always been applying the right level of each at the right stage. What has changed is that the price of getting that balance wrong now arrives much sooner, because everything upstream of the mistake happens faster too.
This is one of the places where the technology leadership role is genuinely being rewritten. When execution becomes cheap, judgment becomes the scarce input, and the organisation has to be redesigned around that rather than around throughput.