The Code Is No Longer the Scarce Part

AI can generate an implementation and may even propose the strategy. The better its answers become, the more we need engineers who can recognise what belongs in the system, detect what is wrong and remain accountable for what happens next.

One application rebuild has now supplied me with three articles, which is the sort of productivity gain executives understand. The first was about management spans. The second was about delivery units. This third is about what the engineer contributed while AI helped produce much of the implementation.

The answer is not mainly code. It is the chain of ideas holding the work together. The engineer devised an architecture that adapts to its environment, separated failure domains, defined invariants shared across several systems, replaced timing guesses with explicit contracts and discarded designs that evidence disproved.

That is the distinction. Plausible implementation can now be generated in extraordinary volume. Coherent, trustworthy change remains scarce.

Current frontier models can feel close to magic, and so did their predecessors. Give an agent the objective, repository, documentation, tools, test environments, a knowledge graph and every context-engineering technique we currently know. It can explain the system, propose designs and implement them. It cannot reliably identify the hidden contradiction that matters, build a coherent architecture around it and revise that architecture as months of runtime evidence expose its faults.

Novel here does not mean unprecedented in computer science. It means discovering which arrangement works within the constraints of an existing system. A model can propose unfamiliar arrangements. It cannot reliably judge which fit the system, which belong together or which evidence should overturn the design.

The software industry is arguing about the wrong thing. We ask whether AI can write code as though code were the whole contribution and the engineer merely the person previously required to type it. If models produce more of the implementation, we assume engineering expertise must become less valuable.

The opposite may be happening. AI did not replace expertise. It gave expertise a larger surface area.

There Is No Incantation for Expertise

A fair amount of prompt engineering consists of telling the machine what you want with sufficient clarity, an activity formerly known as writing a decent specification. Clear instructions, relevant context, examples, constraints and acceptance criteria improve the result. Building retrieval systems, toolchains and evaluations around a model can involve serious engineering. Choosing the right context may itself require deep knowledge of the system. None of this supplies judgement the operator does not possess.

Fluency is not expertise. My ten-year-old has an excellent command of English, studies Latin and earns high marks for grammar. She can express herself to a model perfectly well. She cannot use one to reason seriously about a distributed system, much less produce a world-class implementation. She lacks neither vocabulary nor intelligence. She lacks the mental model of distributed systems needed to test the machine's answers.

The same is true of adults. A beautifully written prompt can ask a model to design an architecture. It cannot tell its author whether the architecture makes sense. No incantation involving "act as a distinguished engineer" supplies the experience required to recognise that the first plausible answer is wrong.

Sean Goedecke recently argued that LLMs reward expertise. His example is the mathematician Terence Tao using ChatGPT to reason about a difficult problem. Tao's prompts are short. What distinguishes his use of the model is knowing which part of an answer matters, when the proposed route is needlessly complicated and which alternative might unlock it.

An expert can say, "That looks wrong," before being able to prove why. They can ask whether the system already contains a simpler mechanism, recognise that a proposed abstraction fights the architecture or notice that a locally elegant answer creates trouble three layers away.

A novice and an expert may use the same model, but they will not extract the same value from it. The model may make both more capable, but it gives the expert a longer lever. Someone with a good theory of the system can reject plausible nonsense and direct several strands of implementation towards one coherent design. Someone without that theory can generate incoherence just as quickly.

Control the Ideas, but Do Not Pretend the Code Has Vanished

Where, then, should that expertise be applied? Salvatore Sanfilippo, the creator of Redis, goes further. In Control the ideas, not the code, he argues that line-by-line inspection becomes a poor use of expert attention when models can generate thousands of lines a day. The engineer should control the design, tests and governing model of the software rather than treat source code as its principal intellectual output.

He is right about the direction and too absolute about the destination.

Code remains the thing the machine executes. Tests sample behaviour; they do not prove every property that matters. Generated implementations can encode subtle security failures, mishandle concurrency or satisfy the test suite while violating an assumption nobody wrote down. In systems handling money, identity or regulated decisions, refusing to inspect consequential code would be a failure of accountability.

But reading every generated line with equal attention will not scale either. Expert attention must move towards architecture, invariants, interfaces, failure modes, evidence and the code paths and interactions where danger lives.

The question changes from "Did a human type this?" to "Does a human understand and own the ideas this software expresses?"

That is a harder standard.

Documentation Becomes Part of the Control System

That understanding must exist somewhere beyond the engineer's head. Software documentation often describes a system after the consequential decisions have been made, which is why so much of it resembles an archaeological note left by somebody who arrived after the civilisation disappeared.

AI makes a first draft cheap, but cheap documentation is not necessarily useful. The valuable document records the engineer's model: the invariant that must hold, the evidence that changed a decision, the alternative that failed, the trade-off accepted and the condition under which the design should be removed.

In the work I have watched, the records form part of the control system. They state invariants that code and tests enforce, record evidence that corrected the architecture and define rollout tripwires before production supplies a reason to wish somebody had.

These records make the engineer's ideas available to other humans and give future models better context. They are valuable only while somebody owns them, tests their claims against the implementation and corrects them when reality changes.

That creates a useful discipline. If nobody can state the architecture, invariants and accepted risks clearly, perhaps nobody controls the ideas after all.

Expertise Includes Changing Your Mind

The record of the work also contains reversals. Assumptions about runtime behaviour were checked against source and real environments, then corrected. Designs were discarded when they behaved incorrectly, consumed too many resources or obscured ownership. Some apparently clever mechanisms were deleted once a simpler rule became visible.

Organisations often confuse seniority with having the answer in the first meeting. That rewards confidence and makes correction look like weakness. Real engineering judgement is often the ability to construct a test that could prove your preferred idea wrong, notice when it has done so and change direction without preserving the old mistake for reasons of status.

AI reduces the cost of exploring alternatives. It can construct competing implementations, attack an assumption and help trace a failure while the context is fresh. Engineers should become more willing to be wrong briefly and quicker to correct themselves.

What Senior Engineers Produce

Lines of code were always a poor measure of engineering contribution. They become absurd when one engineer can direct a model to produce thousands and another can remove them by finding the idea that makes them unnecessary.

A senior engineer increasingly produces:

• a model that explains the system's important behaviour;
• invariants and boundaries that keep implementations coherent;
• tests and observations that can disprove the design;
• records that preserve the reasons behind important decisions;
• simplicity recovered from generated complexity.

Code remains evidence of the work. It is no longer a reliable measure of its value.

This should change how we recognise technical leadership. The engineer exercising the most valuable judgement may not write the most code, review the most pull requests or dominate architecture meetings. They may define the rule that prevents fifty future decisions, write the test that kills an attractive mistake or explain the system well enough that ten other engineers can change it safely.

None of that requires reports.

Scope Should Follow Judgement

If judgement is the scarce input, giving every meaningful outcome to the most senior engineer would be an efficient way to consume the future. A junior engineer can still be a unit of delivery. They should carry a smaller, more reversible outcome, with closer review and more opportunities to pair and observe. As judgement grows, so can the breadth and consequence of the work.

New engineers still need to build things, debug failures, predict behaviour and discover where their mental model differs from reality. Watching a model solve the problem can create recognition without understanding.

The organisation must protect that learning. If every important outcome goes to the person who can finish it fastest, this quarter's throughput will consume next decade's expertise. The objective is not to preserve typing as a rite of passage. It is to develop judgement through progressively larger work.

Reward Judgement as Leadership

This account of expertise supplies the mechanism beneath both earlier arguments. An expert engineer can now exercise judgement across work once divided among several people: their understanding supplies coherence while AI accelerates implementation across the system. Principals can challenge decisions across many outcomes without implementing each one. Managers can support more engineers when visible work, shared standards and greater individual reach allow ordinary technical decisions to proceed without being routed through the line manager.

Greater leverage widens the organisation only when the engineer leaves behind a model others can inspect, challenge and use. Otherwise AI has not removed a dependency. It has made one expert a faster and more dangerous one.

A model given enough context can also propose a plausible product or technology strategy. Better models can make bad judgement harder to detect because they argue the case more convincingly. In a large regulated company, an expert must still test the assumptions against regulation, capital, customers, operational risk and reputation, then answer for the decision.

Accountability returns to the implementation. Often the person with the clearest theory should implement it; sometimes their role requires others to carry much of the work. Seniority changes how work is divided, not who must answer for the evidence, implementation risks and production consequences. Architecture does not become sound because its author is senior. If it ignores users, contradicts operational evidence or collapses under qualified review, it is simply bad architecture.

Current models can multiply implementation. The engineer must still decide what a complicated existing system should become and recognise when evidence invalidates the design. AI does not diminish that judgement. It gives it more territory.