我如何透過少寫程式碼，成為更好的開發者

The best thing I shipped last year was a diff that deleted more than it added.

I don't mean that as a humble-brag about clean code. I mean it literally changed how I think about my own job. For about a decade I had one quiet, unexamined definition of getting better as a developer: produce more. More features, more commits, more lines that worked, more of the thing on the screen at the end of the day. I never said it out loud because it never needed saying — it was just the water I swam in. More output was more skill. Everyone I respected produced a lot, so I tried to produce a lot.

Then the machine showed up and let me produce more than I ever had in my life. And the most "productive" quarter I'd had in years is the one that nearly cost us a paying customer. That's the story. It's the reason I now think the thing that made me better wasn't learning to write more — it was learning to write less.

The decade where "more" was just true

I want to be fair to the old me, because he wasn't stupid. For most of the history of this job, producing the code genuinely was the hard part. It was slow. It was bottlenecked on you — your fingers, your working memory, your ability to hold the whole shape in your head while you typed it out. If you shipped a lot of good code, that meant something real: you had the skill, you understood the system, you could do the work nobody else could do as fast.

So "more output = better developer" wasn't a mistake. It was a decent proxy, honest enough to build a career on. The volume was expensive to produce, so the volume was evidence. Nobody could fake a mountain of working code; producing it was the skill, bundled all together. I measured myself by the mountain because, back then, the mountain and the skill were the same thing.

That's the assumption I never noticed I was making. And it's the exact assumption that stopped being true.

Then production got cheap, and I didn't update

Here's what nobody warns you about when the machine gets good: at first it feels like you leveled up.

Code got cheap for me almost overnight. Not free, not always correct — but cheap. A competent first draft of a well-scoped change went from a day of typing to a few minutes of generating and shaping. My throughput went vertical. More commits, bigger diffs, features landing faster than I'd ever landed them. By my own decade-old scorecard — produce more — I was having the best year of my career.

And for a while that felt like getting better. It took me an embarrassingly long time to notice I hadn't gotten better at anything. I'd just gotten faster at the part that stopped being hard. The mountain was still growing, but the mountain had stopped being evidence of anything, because now anyone with the machine could make a mountain. I was pouring more effort into the one input that had just become abundant, and feeling great about it, because my scorecard only knew how to count that input.

The scar: the most productive code I wrote all year

Let me make it concrete, because this is the moment the whole thing turned over for me.

I shipped a write path that acknowledged a request before it had actually persisted the row. The code was clean. Idiomatic, typed, tested, reviewed, green. It was productive code — it moved fast, it closed the ticket, it made my output numbers look great that sprint. By every measure I'd used to rate myself for ten years, it was good work.

Then one ordinary day a retry hit at exactly the wrong moment. The "got it" went out, the save never landed, and a paying customer got locked out of their own account with nothing in the logs to say they'd ever been there. Ack before persist. I can still feel the phone call.

Here's the part that rearranged my head. That bug didn't get in despite me being productive. It got in because of it. The speed that my scorecard was rewarding is the exact thing that carried a confident, clean, plausible, catastrophic diff straight past me. I wasn't going slow enough to ask the one question that mattered — what does this do if it retries? — because asking it produces nothing, and I was optimizing for producing.

The cure, when we finally found it, was two lines reordered. Negative code. The most valuable change I made that entire quarter subtracted from the total. And there was no row on my mental scorecard where that went.

What I was actually getting paid for, and never measured

Once I saw it, I couldn't unsee it. When code was the bottleneck, judgment came bundled into writing it — you couldn't produce the thing without making a thousand small decisions along the way, so you never had to think of judgment as a separate skill. It rode along for free inside the typing.

The machine ripped them apart. Now I can have all the output I want without exercising any judgment over it at all. Which means judgment is suddenly standing on its own, for the first time, as the thing that's actually scarce. Not "can I produce the code" — the machine does that. It's "can I tell which of these confident, clean, plausible diffs is quietly wrong before it reaches a customer at 2am."

And the scarcest, lowest-status form of that is the one I'd spent a decade not counting: the "no." The deleted function. The feature I talk the team out of. The one-sentence question on a pull request that stops a bad night before it happens. None of it produces anything. All of it prevents. And prevention was invisible to every instrument — including the one in my own head — that I'd ever used to decide whether I was any good.

What "writing less code" actually looks like

So "I got better by writing less" isn't a Zen koan. It's a set of concrete habits I didn't have before and do now:

• I delete before I add. The first question on most changes now is "can this be less code," not "what do I add." A smaller surface is fewer places for the machine's confident, wrong guess to hide. The diff that removes a special case is worth more to me than the one that adds a feature, and it used to be the reverse.
• I treat the question as the deliverable. "What happens on the retry? what if this is empty? what if two of these race?" produces zero lines and is the highest-leverage thing I do all week. I stopped waiting to have an answer before I counted the asking as work.
• I review the machine instead of racing it. The machine's job is to produce the mountain; my job is the one thing it structurally cannot do — distrust its own output. Every green, confident diff gets read like it's trying to lie to me, because the ack-before-persist one did.
• I stopped reading a small diff as a small contribution. Some weeks the most valuable thing I do is the three lines I stopped from shipping. My old scorecard would've logged that week as coasting. I go looking for those on purpose now.

To be clear — this is not "shipping is for juniors"

I want to be careful, because the lazy version of this is "real developers don't write code, they think deep thoughts," and that's garbage.

Shipping matters. I ship all day. The machine writes most of my code now and I would never go back — the typing was never the hard part, and a developer who produces nothing isn't a wise skeptic, he's just slow. Output is table stakes. You still have to deliver the thing.

The claim is narrower, and I think it's hard to argue with once you've lived it: output stopped being the scarce thing, so it stopped being the thing that makes you better at this job. When production was the hard part, getting faster at production was getting better. Now production is the cheap part, and getting better means getting good at the judgment the machine hands back to you un-exercised. I didn't stop shipping. I stopped mistaking the thing the machine now does for the thing I'm actually here to do.

Why this is the exact reason I build the way I do

One level up, it's the same lesson, and it's why I build an agent platform the way I do.

The whole industry right now wants to cheer for the thing that produces — look how much it ships, look how clean, look how fast. But an agent that generates is just doing the skill that stopped being scarce, at a scale no human can match, and then — worse — it signs off on its own work in the same confident voice whether the diff is a masterpiece or the ack-before-persist bug all over again. It's the productive version of me from last year with the volume turned up to infinity: endless throughput, zero "no."

So I never let the thing that writes the code be the thing that blesses it. There's an author that produces the diff — cheap, fast, endless, the abundant thing. There's a separate skeptic whose entire job is to try to break that diff rather than admire it — the "no" given its own seat, so it doesn't depend on one tired human remembering to ask the retry question at the end of a long day. And there's a human on the merge button who owns the call and sees the blast radius neither agent can. Author, skeptic, human. The author has infinite throughput and I measure it by almost nothing. The skeptic has zero throughput and it's the whole point. That's the shape of xenition, and it's just the thing my own scar taught me, built into software: the moment production got cheap, the thing worth paying for stopped being production.

I spent a decade getting better by adding. I got good the year I started subtracting — and the machine, by making the adding free, is the thing that finally showed me the difference.