We are still measuring engineers by the part that got automated.

There is a sentence that engineers with twenty years of experience now say quietly, as if confessing to something: I do not really write code any more.

It is usually said with a small apology attached. It should not be. The interesting thing about that sentence is not what it says about the person saying it. It is what it says about the instruments we use to decide whether that person is any good.

The scoreboard got thrown out, and almost nobody noticed

For roughly a decade, the industry graded delivery on four numbers and sorted teams into low, medium, high and elite. Those tiers were quoted in board decks by people who had never read the underlying report, which is usually the sign that a measurement has become genuinely load bearing.

In 2025 DORA abandoned them. The tiers are gone, replaced by seven team archetypes described across eight measures: throughput, stability, team performance, product performance, individual effectiveness, time spent on valuable work, friction, and burnout. The archetypes have names rather than ranks, of the kind you cannot put on a slide and pretend is a score.

Reasonable people can argue that this is harder to apply than four numbers and a ladder. It is. But the reason for the change is the part worth sitting with: half of those eight measures are not about output at all. Friction, burnout, time spent on valuable work and individual effectiveness are measures of whether an organisation is wasting the judgement it employs.

That is a very specific admission. It says the old instrument measured the volume of work and lost interest in whether the work was the right work, and that this distinction stopped being affordable.

What the numbers say, and why they are uncomfortable

The 2025 data explains the urgency. Around 90% of respondents reported using AI in their job, with a median of roughly two hours a day, up from 75% the previous year. Comparing individuals with otherwise identical traits and environments, higher AI adoption correlates with higher individual effectiveness, higher throughput, higher organisational performance, and better reported code and product quality.

And with higher software delivery instability.

Read that pairing slowly, because the shape of it is the argument. AI moved almost every metric in the right direction except the one that tells you whether the system stays up. The measures that improved are the ones that count production. The measure that got worse is the one that counts consequences.

If your view of an engineer is built from the first five rows, the last two years look like a triumph. If it is built from the last row, they look like a warning. Both readings come from the same dataset, which is exactly why the scoreboard had to change.

This has happened before, and we already know how it ends

Twenty years ago, a good systems administrator was someone who could configure a server well. The skill was real and it was scarce, and it was measured by throughput of a sort: how many machines, how quickly, how few mistakes.

Then configuration management arrived, and then infrastructure as code. An engineer stopped typing the configuration and started describing the desired state. Nobody today thinks an engineer who uses Terraform is less capable than one who configures machines by hand. The opposite: we consider hand configuration a liability, because it cannot be reviewed, reproduced or rolled back.

The work did not disappear. It moved up a level. What used to be an act of production became an act of specification, and the difficulty relocated from executing correctly to deciding correctly, because a mistake in a module now propagates to four hundred machines instead of one.

We never called that a decline. We called it maturity, and we raised the salaries accordingly.

The same ladder, in three rungs:

Application software is now climbing the same rungs, and it is being described in the language of loss by the people going through it. Notice which rung the automation took each time. It took the leftmost one, and it left the rightmost one exactly where it was.

What actually moved up a level

It is worth being precise about which part of the job changed, because the answer is smaller than the hype and larger than the sceptics allow.

What became cheap is the transcription. Turning a decision you have already made into syntax a machine will accept. That was always the least interesting part, and it consumed a large share of the day.

What did not become cheap is everything upstream of the first line: whether this should be a service or a function, what the failure mode is when the third party is down, which of these two data models will be painful in eighteen months, whether this integration creates a dependency the business cannot exit. We wrote about the code quality side of this in AI solved syntax, it did not solve judgement. This is the organisational version of the same boundary.

An agent can already write the code, generate the tests, open the pull request and update the documentation. Those are production tasks and they are being automated in that order. What no agent currently does is tell you that the thing it just built beautifully should not exist.

The right column is not a list of things models will never do. It is a list of things that require knowing the organisation, its history, its contracts and its appetite for risk. Those are not model capabilities. They are context that mostly is not written down anywhere, which is why the people who hold it became more valuable, not less.

The decisions that have no autocomplete

In practice, the decisions that determine whether a system survives are made before anything is typed, and there are fewer of them than people assume. In a normal project we count perhaps a dozen that matter.

• Where the boundary between two systems falls, because that boundary becomes a contract and contracts are expensive to move.
• What happens when a dependency is unavailable, which is a business decision disguised as a technical one.
• Which data is the system of record, because everything downstream inherits that choice.
• What the system is allowed to do without a human, which is now a live question rather than a theoretical one.
• What you are deliberately not building, which is the decision least often written down and most often regretted.

Each of those is a sentence long and none of them can be delegated to something that has not read the last four years of decisions in your organisation. Get them right and mediocre code survives. Get them wrong and excellent code, generated at speed, arrives faster at a place you did not want to be.

A recent example, and deliberately an unglamorous one. A team needed a document approval step. The obvious implementation was a workflow in the platform where the documents already lived, and an assistant will produce that in an afternoon, correctly. The question nobody asked first was whether approval was a document property or a business fact. It was a business fact: the same approval needed to be visible to a system that would never have access to the document library. The afternoon of correct code would have been thrown away within the year, and the cost would not have been the afternoon. It would have been the six months during which two systems disagreed about what had been approved.

That decision took twenty minutes and no code. It is also the entire reason the project did not have to be redone, and it would not appear in any measurement of that engineer's output for that week.

The sentence is not a confession

So when an experienced engineer says they do not write much code any more, the honest reading is usually the opposite of the apologetic one.

It is the same sentence a systems administrator would have said in 2012 about configuring servers by hand, and nobody now hears that as a decline. It means the person has moved from producing artefacts to deciding what the artefacts should be, which is the direction every engineering discipline has moved in as its tooling matured. Structural engineers stopped drawing every line by hand. It did not make them draughtsmen with fewer skills.

The risk in the sentence is different, and worth naming. An engineer who stops writing code entirely eventually stops being able to evaluate the code they are approving, and judgement without contact with the material becomes opinion. The people doing this well are not writing nothing. They are writing less, on purpose, and reading a great deal more.

What to measure instead

If throughput improved while stability got worse, then throughput has stopped working as a proxy for value, and continuing to reward it is not neutral. It actively selects for the behaviour that produced the instability.

The measures worth arguing about are the ones that survive the automation of production:

Every row on the right is harder to collect than the row on its left, and that is not an accident. The things that predict whether a system survives have always been more expensive to measure than the things that predict how busy everyone looked. Automation of the production step removed the last excuse for using the cheap ones.

The part that ages well

The tooling will keep moving. The model in production today will be replaced twice before this is old, and the agent that opens pull requests this year will do something more ambitious next year.

What will not move is the location of the difficulty. It has migrated up the abstraction ladder in every engineering discipline that has ever been automated, and it has never migrated back. Each time, the same three things happened: the production step got cheaper, the cost of a bad decision got larger because it propagated further, and the profession spent a few uncomfortable years measuring the wrong thing before the instruments caught up.

We are in the uncomfortable years. DORA changed its instrument in 2025; most organisations have not changed theirs.

The value of an engineer was never really the typing. It was only ever measurable that way, which is a different claim, and one that has now expired.