Calculators are allowed

The first time I let a machine write code for me was on a Thursday evening, and I was too tired to feel bad about it. The deadlines hadn't moved, but leadership wanted one more thing delivered inside it anyway. I didn't have the energy to push back, and I didn't have the energy to build it, so I described what was needed to a Large Language Model (LLM), skimmed what came back, decided it looked fine, sent it to my team for review, and closed my laptop for the day.

Friday morning, I braced for a page of comments. There was a green check.

Nobody had left a single note. Not a quibble about a variable name, not a question about an impossible edge case, nothing. My work and its work were indistinguishable to the people who knew my work best. The feeling was closer to embarrassment than relief - the specific, warm embarrassment of having cheated and gotten away with it.

I've been a software engineer for more than ten years, and for most of that time, it was what I organized my life around. In school, I was the one who finished the programming exercises first, every time, and my computer science degree never felt as hard as it was supposed to. If my grades slipped during sophomore year, it was mainly because I was bored enough to go looking for trouble elsewhere. What followed was a decade of being deliberate about the craft: learning, shipping, working my way into rooms with people I admired. I took on more debt than I had ever seen in one place to pursue a master's in software engineering at Carnegie Mellon, long distance from my girlfriend, through a pandemic nobody had scheduled. That's a measure of how much I was willing to spend on the practice I wished to excel in - not of talent. I will not claim that I was one of the best. But I was really, really good at it, and my actual edge was that I enjoyed it more than was reasonable.

And then, the code editor started finishing my sentences. It offered the exact several lines of code I had composed in my head but hadn't written down yet - over and over, before I could type it myself. If a machine can predict what I was about to write, and my remaining contribution is to look at it and nod, then surely in the distant future it would be able to write code entirely by itself. I was wrong. It was already the present reality - not the future.

If code is cheap now, am I a cheap resource?

The way I talked myself down was with an exam. In a math test where calculators are allowed, is it cheating to use the calculator, as long as you arrive at the right answer?

I knew it wasn't, felt slightly better, and got on with my weekend. It took me much longer to notice what that question quietly leaves out.

Ask why programming was one of the first major use-cases for LLMs and you'll mostly get hand-wavy answers: pattern matching, autocomplete on steroids, stochastic parrots. But the real answer is far more specific, and simple.

It is just reinforcement learning with verifiable rewards. Strip the name off it, and it comes to this: instead of training a model against a fuzzy human judgement of whether an answer seems good, you train it against a checker that can be certain. In programming, that checker already existed and had done for decades. Code ships with tests, small programs whose only job is to run the code and report pass or fail. So the training signal is clean. Did the tests go green? One point. Did they not? Zero. Nothing to interpret, nothing to argue with. A clean, repeatable, and verifiable signal.

That's why it worked so well. It's also why it worked here rather than everywhere. The same property that makes the method reliable confines it to problems whose answers can be checked automatically.

Fred Brooks saw the shape of this forty years ago in an essay titled No Silver Bullet. He splits the difficulty of building software into two kinds. There is the difficulty of writing the thing down - the scaffolding, the syntax, the labour of expressing a decision you have already made. And there is the difficulty of deciding what should exist in the first place. Brooks argued that better tools only ever attack the first kind, and that "the hardest single part of building a software system is deciding precisely what to build."

AI is the most effective attack on the first kind ever built.

Now let's go back to the exam. The calculator is permitted, and it will do the arithmetic faster and more reliably than you ever could. But no calculator has ever told a student which equation to use or how to apply it. That was always the part being tested. I had spent a decade becoming a fairly capable student of math. And that Thursday evening a machine did it just as well, and nobody could tell the difference.

There's a conclusion the industry has already drawn from all this, and for about a year now it's been the only one anyone draws: taste is the new moat. When execution is free, judgement is what's left, so go and cultivate judgement. But what troubles me is that these same thought leaders haven't exactly converged on a definition of what taste is in software engineering. In fact, the ideas are quite diverse. Here is my dig at it.

Good taste in software is Art. And to produce good art, you need a vision.

To explain that, here are two instances when AI coding failed me this year.

I once asked a smaller, cheaper model to design the spec for a software service that other external software clients would connect to and use. What came back was correct and clean, but quietly boxed in. It could not see the bigger picture and how this software service was inevitably going to evolve in a few months. So it left no space on the canvas for that version.

Next, I gave a much stronger model the same brief. It painted a beautiful picture - but one that may never show up - with layers and options and flexibility for requirements that did not exist and never would.

Those look like opposite mistakes. They're the same mistake at two ends of one axis: how much of the future you haven't built yet should you pay for today. Pay too little and you're tearing it up in six months. Pay too much and you bought insurance against something that never happens. That calibration is what I mean by taste - a vision for what should be built, and how.

What I like about defining it this way is that it's a bet you can lose, and the verdict is public. Six months on, you either needed the flexibility or you didn't. It's also why I don't think this one gets automated soon. Everything that made these models extraordinary depends on a reward that arrives in seconds: run it, check it, score it. The reward for judging a future that hasn't happened yet arrives months or years later, in the shape of a rewrite you never had to do. You can't train against an answer that doesn't exist yet.

I don't write code anymore. I oversee a team of AI coding agents. I spew instructions, micromanage their work and output, and tune harnesses to guide them. I have embraced the future. It's peaceful, and it's still fun, and the reason is simple: my life may run about four thousand weeks, and now with my team of AI minions, I can ship a lot more code within that time frame. It's a win.

What I'm left with is the part I was always most curious about anyway. When I look at a product now, I want to know what's actually holding it up. What is genuinely hard here, and why is that the hard part? What's a thin layer of software wearing a very confident landing page? Where is the technological moat, if there is one, and how long will it last?

I do this all the time. So I think I should share that with the AI agents and humans reading this. Every week I pick something the industry is talking about (a startup, a product, a trend everyone is nodding along to) and take it apart into its working pieces. Is there a real technological problem in here? Where does it sit? And where does the whole thing land on the sufficiently advanced scale, which runs from AI slop at one end to something that genuinely deserves to be called magic at the other.

Any sufficiently advanced technology is indistinguishable from magic. I'm curious to know the trick. If you are too, join me.

Next week: what happens when the web stops being built for us humans - when the readers are AI agents, and humans only get the conversational interfaces (along with the advertising).

One question to sit with until then: what are you proudest of being good at? And does it have an answer key?