Kent Beck Recalibrated

A shelf of books that taught me the craft. Their author, recalibrating in public. Ninety per cent of his skills worth nothing. The ten per cent worth a thousand times more. Not vibe coding, and not surrender. The most energised man in software.

There is a shelf in my study I have carried through five companies. Extreme Programming Explained. Test-Driven Development by Example. Implementation Patterns. I read them as a younger engineer the way some people read scripture, and I have quoted Kent Beck to more teams than I can count. This series opens with him, because the discipline most of us were raised on was, in one way or another, his. So I want to tell you what happened when the man who wrote those books changed his mind.

In April 2023, shortly after using a coding model in earnest for the first time, Beck wrote a single line that I have not been able to stop thinking about since. “The value of 90% of my skills just dropped to $0. The leverage for the remaining 10% went up 1000x. I need to recalibrate.”

Sit with who is saying that. Not a sceptic capitulating, not a manager who never shipped, not an influencer chasing a wave. The person with possibly the strongest claim of anyone alive to defend hand-written, well-crafted code looked at what the machine could do and concluded, in public, that most of what he knew had just been repriced to nothing. The honesty of it is the part I admire. He did not reach for a reason it would not affect him. He recalibrated.

The ten per cent

The first question is obvious. If ninety per cent went to zero, what is the ten per cent that went up?

Beck has been precise about this. Speaking to Gergely Orosz on the Pragmatic Engineer podcast in 2025, he named it directly: “having a vision, being able to set milestones towards that vision, keeping track of a design to control the levels of complexity as you go forward, those are hugely leveraged skills now.” And he named the thing that fell away with equal precision, contrasting those skills with “knowing where to put the ampersands and the stars and the brackets in Rust.”

That is the whole repricing in two phrases. The syntax, the local knowledge, the muscle memory of a particular language, the part of the job you spent years getting fluent in, that is the ninety per cent. The vision, the design, the judgement about complexity, the knowing-what-to-build, that is the ten. The machine took the typing and handed back the thinking, and the thinking turned out to be worth far more.

Not vibe coding

It would be easy to file this under the thing everyone now worries about. The careless prompting, the accept-and-ship, the codebase nobody understands. It would be easy and it would be wrong, and Beck has gone out of his way to say so.

He draws a hard line between two ways of working, and he coined a term to hold the better one. The careless mode is vibe coding, a phrase he credits to Andrej Karpathy. Beck’s definition is exact: “In vibe coding you don’t care about the code, just the behaviour of the system. If there’s an error, you feed it back into the genie in hopes of a good enough fix.” Against that he sets what he calls augmented coding: “In augmented coding you care about the code, its complexity, the tests, and their coverage. The value system in augmented coding is similar to hand coding, tidy code that works. It’s just that I don’t type much of that code.”

Tidy code that works. It’s just that I don’t type much of that code.

He did not stop caring about good code. He stopped typing it. The value system survived the transition completely intact; what changed was whose fingers were on the keyboard.

The genie is his word for the agent, and he is clear-eyed about its limits. It will, he says, go past your stated requirements to build what you would have asked for had you thought to ask. It will also, in his phrase, lack taste, and it will cheerfully let complexity pile up because it assumes its planet-sized brain can cope with any amount. So he does not hand it the wheel. He describes the relationship as more like influence than control, a bowling ball rolling downhill that he nudges with a hockey stick, and he keeps hard guardrails the agent is forbidden to move. His instruction to it about failing tests is one I have now repeated to my own team: we do not comment out tests, and never ask permission to. Test-driven development, the discipline he gave the industry a quarter of a century ago, he now describes as a kind of superpower when working with agents, precisely because the agents introduce regressions and the tests are what catch them.

None of this is a man letting go of his standards. It is a man carrying them across to a new instrument.

The most energised man in software

Beck is not mourning. By his own account he has been coding for fifty-two years, and over the last decade had grown tired of it, tired of learning yet another framework, yet another language. The agents have re-energised him. He writes about the specific pleasure of it with an almost boyish directness: the joy of pattern-matching, the small thrill when he adds to his invariant tester, a clutch of tests goes red, and the genie works them back to green. It feels great, he says, and you believe him. He describes augmented coding as never having to say no to an idea, because the cost of trying one has collapsed to almost nothing.

Think about what that means. The person best placed in the entire industry to write the elegy for hand-crafted code, the one who would have every right to grieve, is instead the most excited person in the room. He is not telling us the craft is over. He is telling us he is having more fun than he has had in years.

That is the fact I cannot get around, and it is why I wanted to give this its own chapter at the close of Part One. Every nervous developer I meet is braced for a verdict from on high that the work they love is finished. The verdict came, from the highest authority there is, and it was the opposite of the one they feared.

And Kent Beck is not a lone eccentric. The same turn is happening among people who have little reason to agree with one another. Martin Fowler, who taught a generation of us how to refactor, now expects these models to change software development “to a similar degree as the change from assembler to the first high-level programming languages”, and says plainly that the prospect “rather excites me”. David Heinemeier Hansson, who built Ruby on Rails and spent much of last year loudly sceptical of letting AI near his code, came round entirely, and called the current agents “the most exciting thing we’ve made computers do since we connected them to the internet back in the ’90s”. When the careful architect and the celebrated contrarian arrive at the same place as the man who wrote the book on the craft, you are no longer looking at one person’s change of heart. You are looking at the profession changing its mind.

Which leaves the harder question, the one that ends the first half of this book. If Kent Beck, of all people, put down the chisel and picked this up with both hands, then what actually became of the thing we loved? Did the craft die, or did it simply move?

That is the next chapter.

Barrie