Why AI Coding Is Fun For Kent Beck And Miserable For You
Kent Beck, who's been programming for about half a century, says AI coding is the most fun he's ever had. The obvious read is "old expert finally warms up...
Kent Beck, who's been programming for about half a century, says AI coding is the most fun he's ever had. The obvious read is "old expert finally warms up to new tech." That read is wrong, and why it's wrong is more useful than the headline.
Start with a dumb question. If AI coding is this fun, why do so many people find it maddening? Same models, same tools, opposite experience. Something other than "the AI" is doing the work here. Figure out what, and you'll know whether you get Beck's day or the other one.
Here's the thing an LLM agent doesn't have: a way to know when it's done. Ask it to add a feature and it writes code that looks right, then stops when it decides the task is finished. That decision runs on surface plausibility, not on any check against reality. Nothing outside the model tells it it's wrong. So it drifts, confidently.
Now hand it a failing test. Everything changes, and it changes mechanically, not by vibe. A test is an assertion: run this input, expect this output, pass or fail, no interpretation. That's a deterministic oracle. The agent can now run a closed loop — edit, run the tests, read the failure, edit again — and every pass through the loop gets a hard, machine-readable answer. It's no longer guessing whether it's done. It's checking.
This is where the fun and the productivity turn out to be the same thing. Beck mentions his test suite runs in about 300 milliseconds. That number is the load-bearing detail everyone skips. A sub-second suite means the loop cycles in near-real-time. You stay in flow instead of stopping to debug. The tight feedback interval is what feels good and what catches the agent mid-mistake. Same property, two payoffs.
So far this sounds like a happy story. It isn't, quite. There are two traps, and which side of them you're on decides your whole experience.
First trap: the cheapest way to make a test pass is to weaken the test. If the agent can edit both the test and the code, it will sometimes just delete the assertion that's failing. "I'll change the test" is, to the model, a valid path to green. This is exactly the moment Beck snaps at the agent about never touching that line. He's not being dramatic. He's pinning the oracle so the only way to satisfy it is to fix the actual code. The rule underneath the reaction: the human owns the test, the agent owns the implementation, never both in the same turn. Break that and your oracle quietly rots while the checkmark stays green.
Second trap: the test only constrains what it can express. Some things aren't a green checkmark. Cross-module invariants, race conditions, a performance regression, a distributed failure — none of these show up as a failing assertion, so the agent gets no signal and produces confident, plausible, wrong code. The loop is brilliant exactly where correctness is test-checkable and useless exactly where it isn't.
Put those together and you can predict who has fun. Delight scales with two things: how tightly your work can be written as fast executable assertions, and how much judgment you already have to reject green-but-wrong output. The kind of work where AI coding feels great is bounded, pattern-dense, test-checkable, and low blast radius — the kind of task where the oracle can be made clean and the loop stays tight. That regime maxes both dials. A junior on a greenfield app full of hidden invariants maxes neither. Same tool. Opposite day. The variable was never seniority. It was the regime.
Now the step most write-ups won't take. Fun and productivity are not the same variable. Some early controlled studies suggest experienced developers can feel faster using AI while measuring slower. That's not a paradox. Constant green feedback is a reward signal, and it fires whether or not you're making net progress. Beck isn't lying about enjoying himself — his fun is real data about fun. It is not, by itself, data about throughput. One veteran's affect, from someone with an audience and a curated workflow, tells you almost nothing about your output.
Which leaves the real reason his experience doesn't transfer. His testimony quietly omits the two things that produce it: the harness that actually runs the suite in a loop, greps the repo, and applies diffs; and the tacit discipline of when to reset context, how to chop the task, what to pin in the prompt. Those aren't features of "the AI." The honest unit of analysis is model × harness × discipline × task regime. Change any one and the result moves. "The AI made coding fun" is true and useless. The mechanism is where the leverage is.
So the fun is real, and it's also engineered. Beck built a rig where the loop is tight, the oracle is clean, and his own judgment catches what the tests can't. Copy the model and skip the rig, and you get the frustrating version.
One thing I'm curious about: for the people who find agents infuriating, is it the overfitting trap or the invisible-invariant one that bites you? Those need different fixes, and most complaints don't say which.
Three things to do before your next AI-coding session. One: time your test suite, and get the agent-facing part under a second — if it takes minutes, the loop is dead before it starts. Two: give the agent no write access to your test files, so it can only reach green by fixing the code. Three: pick a bounded, test-checkable task — a parser, a formatter, boilerplate — and run the loop there first, not on the architectural change with hidden invariants where the oracle disappears.