The Code Is Solved. Now What?

The code is solved.

Almost. Not quite. What has been solved is one very specific part of the job, the part that used to eat whole afternoons, and what is left is the part nobody ever had to train.

For years, my job was this loop: write code, compile, run, it does not work, read the error, change one line, start again. A one-line error could take an entire afternoon. It did not matter how well I had thought the design through: if it would not start, there was nothing. There were days when I got nothing done, and the maddening part was never the error. It was the loop.

Now the code, simply, works. Not always and not for everything, but enough that the loop has stopped being my job. And that has moved the exercise: executing well used to come first; today, knowing what to create. Same profession, different muscle, and I have spent months trying to work out which one gets trained and how.

What was behind the loop

Whenever I tell this, I get the same question: how do you know it is fine if you have not read it? Fair question. For my whole career the answer was that one: I read it. But looking at it closely, the job was never understanding the code. It was being able to grab it. When something broke, I could read it and repair it before anyone noticed. That is a control surface1, and it explains why accepting a change I did not write is hard: it is not that I do not understand it, it is that there is nothing to grab.

The uncomfortable detail is that I did not fully understand the code I did write either. Nobody in my generation knew which bytecode their Python ended up running. Or which plan the database planner would pick. We shipped anyway, because the illusion worked as long as the layer underneath was stable, and not because it was true1.

So what has moved is not my understanding. It is the surface. Today I write the script that measures, and what I review is the script.

And it is not just my impression

I went and looked at the numbers, just in case.

In March, a16z’s consumer ranking dropped one number that surprises nobody any more and one sentence that does: ChatGPT at 900 million weekly users, and a list that has stopped separating AI products from products with AI inside2. The previous edition of the same report already talked about the builder era3.

Microsoft went further: they opened their engineering blog by saying the traditional software development lifecycle is broken. Manual review collapses under a volume of requests nobody designed it for, the focus has moved from shipping code to orchestrating systems, and when building is cheap the scarce resource is the judgement to decide what is worth building4.

The numbers finished convincing me. Code gets written 30-40% faster, and if the rest of the cycle stays manual, team productivity rises by less than 10%: the bottleneck does not disappear, it moves5. An analysis of more than ten thousand developers found 98% more merged changes and 91% more time spent reviewing them6. Writing is fast. The slow part is having something to check it with.

Since then I have changed things, in the part that matters now: deciding.

I write the specification first, and not for paperwork. It works as a contract: the primary artefact stops being working software and becomes that specification7. The convincing part was the one measuring the other side. The less clear it is, the more the agent fills in on its own, and there is a threshold, around 70%, separating the safe zone from the invention zone7. Ambiguity ends up getting filled in, and it is our fault, in a way.

I stopped accepting “done, it works”. Now I ask for the pack: which files changed, in which environment, which tests ran, which gaps are still open6. And I stopped reading the whole diff to check whether something works.

The signature stays mine. Agents synthesise and verify, but the authority to merge and deploy is not delegated: somebody takes responsibility after verification7. Picking a tool is the least of it.

The other side

Here my own opening becomes uncomfortable, because the loop that drove me mad was, for a lot of people, the craft.

Clive Thompson interviewed more than seventy developers for the New York Times Magazine, and the summary he gets out of it is a gradient: many write far less code; some, none at all8. At a two-person startup AI writes one hundred per cent of the lines and they say they move twenty times faster than two years ago8.

The sentence that stopped me is Pia Torain’s: after four months of writing hundreds of instructions a day, she started to feel she was losing her ability to code. She did not drop the tool. She imposed a discipline: read the whole architecture of the program before accepting anything. If you do not use it, you lose it8.

I notice it in something very concrete: I am learning Rust. If I let the agent write what I want to learn, in a year I will not be able to write it. And what gets lost is not syntax, it is the judgement to look at an output and say “that is not good, do it again”8. The loop I was happy to lose is exactly where that judgement is manufactured, and it is the part of my opening I have not resolved.

And there is the account that lands close: in the most AI-exposed occupations, employment for those aged 22 to 25 has fallen 16% relative9. The door is not closing on those of us already inside. It stops opening for those who were coming.

On the productivity figure almost nobody quotes the whole thing, so here it is: in 2025, a METR randomised trial measured that sixteen experienced developers took 19% longer with AI, when they believed they were going much faster10. In 2026 the follow-up flipped the sign, with 18% and 4% faster and with intervals that close on neither10. We do not know how big it is, and that is exactly my trap: the code working does not tell me whether I am learning anything.

It is not all lament either. Most of the people he interviewed were delighted not to write by hand, and Kent Beck said the models had given him back the desire to program8. Both things are true, and both fit in the same paragraph.

The gym

If the exercise used to be executing well and is now knowing what to create, the question I ask myself is no longer whether AI writes good code. It is what I do with the capacity it frees. And here I stop improvising, because for weeks I have been writing something down in the gym that somebody put into words two days ago: every set. Weight, reps, how many I had left in the tank. It is not a love of numbers. If I do not measure, I do not know whether I am progressing, and progress is the only indicator I have that I am doing the right thing. With code I had stopped measuring for months.

The argument I had not managed to build myself is Eero Alvar’s, in an eight-minute video. When a machine removes the necessity of a capability, that capability becomes a choice, and once it is voluntary it can be optimised. The Industrial Revolution took physical work out of daily life: the body stopped being necessary to survive and the modern gym appeared, a place to voluntarily impose a load that was no longer imposed on you. Building muscle became the point, training became science, and the pattern repeated in hand-to-hand fighting (martial arts), in covering distances (athletics) and in writing by hand (calligraphy)11.

The closed case is chess: when engines surpassed humans at calculation, players did not disappear, the engines became their training equipment, and the human level went up. And the detail that made me finish this text is the bench press: Bronze Age lifters had flat chests because the machine had not been invented11. It was not a lack of effort. It was a lack of equipment.

There are two things I do not intend to delegate: the three-in-the-morning loop (system down, hypothesis, test, next hypothesis, which is the real craft and is not learned by reading1) and the release signature, which is where responsibility carries my name7. And there is one I delegate happily: everything I do not want to learn.

The gym is not a metaphor to close a text with. It is what I have been doing for years, and it is the only part of the picture that does not depend on a prediction: loading on purpose what nobody forces on me anymore. How long the cycle will take to settle, which layer of work goes next, whether the productivity numbers will end up proving somebody right: that can be measured, or it can be left alone. Knowing what to create cannot.

References

◂ back to blog