Proximity is calibration

There is a story running through delivery organisations at the moment, and it is being told slightly wrong.

The story is that senior people are going back to hands-on work. Executives are prototyping again. Directors are in the code. Chief executives are turning up to engineering reviews with something they built themselves at the weekend. The framing is almost always appetite: they missed building, AI let them build again, and the itch is finally being scratched.

That framing is comfortable, widely repeated, and wrong in a way that matters.

Nothing changed about the appetite

Senior technical people have always missed building. Ask anyone who moved from writing systems to running the people who write systems and you get some version of the same answer. The pull never went anywhere.

What changed is not desire. It is permission.

A few years ago, a senior person still in the code was a problem to be managed. It read as a failure to delegate, poor prioritisation, someone who had not yet made the transition. There was a whole genre of coaching about it.

Today the same behaviour reads as founder mode. It signals technical credibility rather than the absence of managerial discipline. Same person, same habit, opposite interpretation.

So the interesting question is not why senior people want to be close to the work. They always did. The question is what happens to an organisation when almost nobody is.

Everyone moved up a layer, and nobody decided to

Something happened to the division of labour in software delivery over the last eighteen months, and it happened without a decision being taken anywhere.

AI now writes a substantial share of production code. Sonar’s 2026 survey of more than 1,100 developers puts it at 42% of committed code, with respondents expecting 65% by 2027. Sonar sells code review and verification tooling, and the survey concludes that you need code review and verification tooling, so treat the figure as directional rather than settled. The direction is not seriously disputed.

What follows from that volume is a quiet reshuffle of who does what.

The engineer who used to write the change now reviews a generated one. The lead who used to review the change now reviews the review. The manager who used to review the review now approves a summary. The director who used to approve the summary now reads a dashboard.

Each of those moves is defensible in isolation. Every one of them looks like sensible delegation, and taken singly every one of them is.

Stack four of them and you have built something else. The distance between every approval and the artefact it approves has grown by one layer, everywhere, at the same time.

If no one decided to move each approval further from the work, then no one assessed what the added distance costs. The change arrived as a series of local efficiencies, and local efficiencies do not get risk assessed. They get celebrated in a retrospective and absorbed into the baseline.

Verification is not review

The claim this argument rests on is about cognition rather than organisational design.

DORA states it directly in its March 2026 analysis: verification is a fundamentally different cognitive task than creation.

That sentence deserves more attention than it has had.

When you write something, understanding arrives with the act of writing. You cannot produce the thing without holding a model of it in your head. The comprehension is not an extra step. It is a by-product of the work, and it is free.

When you inherit something, no comprehension arrives with it. You have to construct it deliberately, from the outside, against the clock, for a change you did not choose and would not have made the same way. Werner Vogels calls the resulting cost verification debt, which is a good name for a real thing.

That asymmetry has always existed. Reviewing another person’s code was always harder than writing your own. What changed is the volume and the provenance, and an engineer quoted in DORA’s study put the consequence better than any analyst has:

Reviewing another’s code is so much harder than writing it. AI tools are increasing the rate at which people can churn out code that needs to be reviewed.

Read that as an accounting statement rather than a complaint.

The gain accrues to the author. The cost lands on the reviewer. That is a transfer, not a saving, and it is invisible in every metric that counts throughput. Your delivery numbers improve while the constraint quietly tightens.

Sonar’s data points the same way from a different angle. 38% of developers say reviewing AI-generated code takes more effort than reviewing a human colleague’s work. And while 96% report not fully trusting AI output to be functionally correct, only 48% always check it before committing.

Hold those last two numbers next to each other. Almost everybody doubts the output. Fewer than half always verify it. That gap is not carelessness. It is what happens when the rate of production outruns the capacity to check, and something has to give.

What proximity was quietly producing

Here is the part the flattening conversation misses entirely.

Proximity to the work was never only about producing work. It was also the mechanism by which people became able to judge work.

You saw enough changes up close to develop a sense of what good looked like. You watched enough things fail to recognise the shape of a failure before it fully arrived. You built, over years, an intuition that is hard to articulate and obvious when it is missing.

Nobody designed that. No budget line carried it. No competency framework listed it. It was a by-product of being near the artefact, and because it was free, nobody counted it as a cost when they took it away.

Remove the proximity and the by-product goes with it.

DORA names a version of this as the expertise paradox: AI lets an engineer work productively in domains where they lack the context to judge correctness. One participant described the result as the blind leading the blind. The report goes further, finding that these usage patterns deliver breakthrough productivity while simultaneously blocking skill development, limiting the hands-on problem solving that apprenticeship depends on.

Now scale that upward through an organisation.

If the engineer cannot fully judge the AI output, and the lead cannot fully judge the engineer’s review, and the manager cannot fully judge the lead’s summary, then you hold a chain of approvals in which no single link is independently calibrated.

Every signature in that chain is real. Every one was given in good faith by a competent person doing their job properly. The aggregate assurance is still theatre, and an audit will find nothing wrong with it, because the thing that is missing was never written down as a requirement in the first place.

That is the distinction worth carrying. What most organisations measure is that the review happened, the approver was named, the gate was passed, the policy exists and is current, and throughput rose. What actually governs is whether the reviewer could have caught it, whether the approver had seen comparable work recently, whether the gate has ever refused anything, whether the policy changed a decision this quarter, and whether anybody left can still say the summary is wrong.

The first list is documentation. The second is governance. Most organisations can produce the first on demand and have never once been asked for the second.

Concede the argument about individual contributors, then look at what it skips

There is a related argument doing the rounds that the individual contributor role is finished. The version that got most attention came from Philip Su, who spent time at Microsoft, Meta and OpenAI, writing in early 2026: AI writes the code, the engineer sets priorities, resolves conflicts, gives feedback and reviews output, and those were all manager tasks, so the engineer has become a manager.

I think that is broadly right, and I would concede all of it. The work really has moved from producing to directing.

What the argument skips is what managing people was doing other than coordinating.

It was where judgement got formed. You reviewed enough work to know what good looked like. You sat close enough to the output to sense when something was off before you could say why. That calibration was a by-product of proximity, and because nobody had to design it, nobody noticed it was load-bearing.

If everyone becomes a director of machines, and the machines produce faster than anyone can absorb, the organisation ends up with a great deal of direction and a steadily shrinking pool of people who can evaluate.

That holds until something is wrong in a way the summary does not show.

The bench thins in two directions

There is a second-order effect worth naming, and it arrives long after the quarter in which the decision is made.

Organisations are flattening. Korn Ferry’s 2025 workforce survey, reported in Forbes, has at least 41% of employees saying their organisation had cut management layers, with 43% saying leaders are not aligned and 37% saying the absence of managers has left them feeling directionless. Those figures are quoted second hand and worth tracing before anyone builds a business case on them, but the direction matches what most people are seeing.

The argument that follows is analytical rather than empirical, and it is the most underrated point in the whole debate: an organisation eliminating middle managers in 2026 is dismantling the apparatus that produces its senior leaders in 2029.

Put that next to the calibration problem and you get something worse than either alone.

The middle layer is where judgement was formed. It is also the layer being removed. And the mechanism that used to form judgement in the layer below it, which was doing the work closely enough to learn from it, is the mechanism AI has replaced.

So the bench thins from both ends at once. Fewer people are being trained to judge, and the structure that used to promote the ones who could has been flattened.

None of this shows up as an incident. It shows up in about three years as an inexplicable difficulty hiring people who can hold a system in their head.

The regulator has already said this, in better language than the industry has

The most precise statement of this problem I have read this year came from a compliance practitioner rather than an engineer, and it fits in a single line.

An organisational chart is not an oversight control.

That comes from an assessor writing for the IAPP in May 2026, describing deployer readiness work across around a dozen organisations. The pattern was consistent: asked to evidence human oversight, teams point at a reporting line and assume that settles it.

Article 26(2) of the EU AI Act requires deployers of high-risk AI systems to assign human oversight to natural persons who have the necessary competence, training and authority, as well as the necessary support.

Competence is the word carrying the weight, and it is doing something specific. The Act does not ask who is nominally accountable. It asks whether the named person was in a position to intervene. The evidence that satisfies it, as that assessor lays out, is the named reviewer, the decision authority, the intervention trigger, the escalation route, and the record of what happened when the system behaved abnormally.

That is the same argument this piece has been making, arrived at independently, from the opposite direction, in statutory language.

A note on timing, because a good deal of commentary written earlier this year is now stale. The AI Act became applicable on 2 August 2026 and the Commission began enforcement the same day. The AI Omnibus entered into force on 27 July 2026, moving the high-risk obligations for Annex III systems to 2 December 2027 and for systems embedded into products to 2 August 2028.

What moved is when enforcement starts. Article 26 itself is unchanged.

Anchor to the obligation rather than the deadline. The obligation is that oversight must be real, and sixteen extra months does not turn a reporting line into a control.

The proximity test

Five questions. Answerable this week, without instrumentation, tooling or a maturity assessment. They are diagnostic rather than scored, and the answers tend to be uncomfortable in a useful way.

1. When did you last read an artefact rather than a report about one? Not a dashboard and not a summary. The actual change, specification or decision record. If the honest answer is measured in months, your sense of what good looks like is historical, and it is ageing faster than it used to.

2. Could your named approver have caught it? Take one recent approval on something that mattered. Ask what the approver would have had to see in order to catch a serious defect, and whether they saw it. This is the Article 26 question in operational clothing, and it is the one most organisations cannot answer.

3. What happens to a review that finds nothing? If a thorough review and a cursory one leave identical traces in your evidence, then what you are recording is that reviews occurred. You are not recording that they bit. Those are different claims, and only one of them is a control.

4. Where does the verification cost appear in your plan? If throughput rose and no line absorbed the added review load, the cost did not disappear. It was absorbed silently by whoever reviews, which is usually your most experienced people, which is usually the constraint you were trying to relieve.

5. Who is being trained to judge? If AI now does the work that used to build judgement, name the mechanism that replaces it. If you cannot name one, you do not have a tooling problem. You have a bench problem arriving in about three years, and the people who would have filled it are being hired away from it now.

None of these require you to be hands on in the way an engineer is hands on. They require you to be close enough to the artefact that your judgement about it is current.

The objection I find hardest

A piece that only argues one side is an advert, so here is the strongest case against my own position.

Being hands on at a senior level has a real failure mode. You become the bottleneck on the interesting problems. You take the work that would have grown the people below you, which is precisely the harm I have just spent two thousand words worrying about. And you can describe that as calibration for years without anyone challenging you, because the story is flattering and the alternative is admitting you would rather be building.

Staying close to stay calibrated, and staying close because it is more enjoyable than the management work, feel identical from the inside. I have not found a clean test for the difference. The only honest one I have is directional: are you taking work off your team, or sitting alongside it?

The second objection is empirical, and it applies to the trend rather than the mechanism.

The flattening story is thinner than the coverage suggests. Glassdoor’s data has younger workers reaching management on schedule despite all the unbossing rhetoric, and moving into management still paid better than staying put. Stated preference is not behaviour, and a fair amount of what is being reported as a workforce shift is a mood.

I have written this about a mechanism rather than a trend, because the mechanism is better evidenced and will outlast whatever the mood does next.

What this is actually asking of you

None of this is an argument for senior people to write production code. It is an argument that the distance between an approval and the thing being approved is now a governance variable, and that almost nobody is managing it deliberately.

There is a version of the next few years in which organisations become flatter, faster and more productive, and quietly lose the ability to tell whether any of it is correct.

The signatures will all be in place. The controls will all be documented. Every audit will pass. Somewhere in the middle of it, the last person who could have said the summary was wrong will have moved up a layer, and there will be no incident, no alert and no finding to mark the moment it happened.

Your approval is worth the distance between you and the thing you approved.

How far are you, right now, from the last thing you approved?

Sources, and how to weigh them

• DORA (Google Cloud), Balancing AI tensions, 10 March 2026. The main evidential spine here. Qualitative, drawn from 1,110 open-ended responses at a single company, and five months old at the time of writing. Google Cloud runs DORA, though the findings run against that interest, which strengthens rather than weakens them.
• Sonar, 2026 State of Code Developer Survey, 8 January 2026. Vendor-run. Sonar sells verification tooling and the report concludes you need verification tooling. Directional only.
• IAPP, EU AI Act deployer evidence gaps, 8 May 2026. Practitioner analysis across around a dozen readiness assessments. Written before the Omnibus timeline change; the obligations it describes are unaffected by it.
• European Commission, AI Act regulatory framework, updated 3 August 2026. Used for every date claim above, in preference to secondary commentary.
• Business Insider on Philip Su, 19 February 2026. One practitioner essay reported as news. An argument, not evidence, and treated as such.
• Forbes reporting Korn Ferry Workforce 2025. Contributor piece with figures quoted second hand. Worth tracing to the original before reuse.

Jason Cruz Falzon is the creator of the Cognitive Delivery Framework and the Cognitive Delivery Index. Written in a personal capacity. No client or engagement material appears anywhere in this piece. Correspondence to jason@cognitivedelivery.co.uk