On this page:
TL;DR: AI codegen does the typing. Knowing what to aim at, and whether we got there, was always the actual skill. It was never about the coding.
ZX81 + QY10 I grew up in a strange, lucky window. The home computer revolution and the synthesizer revolution were happening at the same time, and for the first time kids my age could afford both: a computer of their own, and a keyboard of their own. Either would have been a generation-defining toy on its own.
I didn't pick. My computer was a Sinclair ZX81, built around a Z80, with 1k of RAM and a membrane keyboard that fought you for every keystroke. My synth was a Yamaha QY10, a palm-sized hardware sequencer with just enough buttons to be a complete instrument. I'd already had the odd go on my brother's computer, and I'd started learning piano, so neither was entirely foreign. But both were mine, both were new, and I embraced them with equal devotion.
When I learned to program, programming was a craft. You went to the library and took out a book on the instruction set. You bought magazines with programs printed in them and typed them in line by line, hoping the computer wouldn't crash before you'd saved to tape. The code was the whole thing: finding the right combination of instructions to make the machine do what you wanted.
I don't think I'd heard the phrase "automated testing" until I'd been programming for ten years. Pair programming and code review were completely unheard of. The job was the code. You sat alone with the machine, made an assumption, wrote it down, measured what came out, and adjusted. Assumption, hypothesis, measurement, adjustment. A tight, often unforgiving loop, repeated until the thing worked, or until you were so tired of rebooting after a crash that you called it a night. There was nothing else to it, because nothing else had been invented yet.
Speeding Up Creation Every creative act starts the same way, with an idea. Then we make something, hold it up against what we had in mind, adjust, and try again. Sometimes the idea shifts as we go. Sometimes the original idea turns out to have flaws we couldn't see from the outside, and we never quite get there.
The QY10 broke that loop for me in the best way. Pretty quickly I realized I could ask it to play things I hadn't learned to play yet. I could write music that I, personally, could never perform. My creation loop went from "have an idea, learn to play it, record it" to "have an idea, get the sequencer to play it, record it." The bottleneck moved off my hands and onto the idea itself.
AI Coding Something very similar has happened in software development. We no longer have to type all the code we want to write. We can get AI to write it for us.
When I first saw AI codegen, my first thoughts weren't positive. I felt slightly threatened. I also told myself the output would always be awful code I could never trust, which was a tidy way of not engaging with the threat in the first place.
I have to admit I'd thought the same thing about compilers. I started in BASIC, wanted things to go faster, and wrote assembly. Then I started debugging programs that other people had compiled, and what I saw horrified me. The generated assembly was wasteful, inefficient, sometimes downright stupid compared to what I'd write by hand. How could I ever use a compiler if that was the kind of code it produced?
Of course, I was missing the point. I was optimizing for one thing, which wasn't always the most important thing to optimize for. Iteration speed and the ability to read and debug what I'd written six months later mattered more, by miles.
And the world kept moving. Hand-rolled assembly made sense on a ZX81 with 1k of RAM and a handful of cycles to play with. Once computers had thousands of times more of both, the gap between compiler output and hand-written assembly mattered less and less.
[Steering The Arrow](#steering-the-arrow)
If the aim is creating things rather than performing them, AI codegen is exactly the kind of accelerator the sequencer was for me. The bottleneck moves off the keyboard and onto the idea, and the interesting part of the work (having something to say, sketching it fast, listening for whether it works) gets faster.
Think of software development, or any creative endeavor, as hitting a moving target with an arrow. Before AI, you had to do three things at once: propel the arrow, keep your eye on the target as it moves, and steer your aim toward it. AI codegen takes propulsion off your hands. What's left is the part that was always the actual skill: the aiming.
Two things follow. Because AI is doing the propelling, we hit targets faster. And because we can put our full attention on steering, we're more likely to hit the bullseye when we get there.
And we still pick the targets. When code is cheap, there is a strong pull to build everything that could be built. Aim at one target and you might hit the bullseye. Aim at a hundred and you will be lucky to hit the board. Resisting that pull (choosing which target is worth aiming at) matters more when shooting is cheap, not less.
Aiming as the targets slide past
How We're Using AI Codegen You might have heard we're rewriting CRIU (the Linux checkpoint/restore tool) to serve our own needs, in the language of our choice, using AI. If you haven't, the previous post covers the why.
There's a popular fantasy floating around about how this kind of work goes. You give the AI a vague target, walk away, come back, and find the arrow in the bullseye.
That can work, if the target is large. "Create me a website for my company with a contact form" often does give a good first result: many different kinds of website would satisfy the user.
But we're working on low-level code, picking up customer workloads, moving them, and restoring them. If we get something wrong, it doesn't just make a page look a bit jarring; it means the workload crashes.
Even with the most painstakingly detailed spec, you don't hit a small target on the first shot. Assumptions shift. Sometimes the target moves once you've started hitting near it and realized you wanted something slightly different. Creative endeavor is a loop. AI doesn't change that. And if the loop stays, we still need to measure how near we got to the target, and course-correct on the next pass.
The Ceremony Was The Work I first ran into these ideas in the early 2000s, at a bigco that was pushing them hard. I resisted all three. They sounded like ceremony designed to keep me away from the actual work, which was writing code. The dev loop I described earlier (assumption, hypothesis, measure, adjust) had been just fine without any of this, thanks. I wasn't alone. Plenty of us pushed back, and over the years the noise around them softened.
Look at what I'm doing today.
I'm pair programming with Claude, in a tight back-and-forth loop. I'm reviewing code constantly (Claude makes mistakes!), and most of my time goes to reading and judging the output. And before we touch the implementation, Claude and I usually build the tests together first: the acceptance criteria, written down in code. That's how we know when we've hit a bullseye and not just something that looks like one from a distance.
These practices were built for exactly this situation. They came out of a generation of trying to reduce bugs, catch mistakes early, and prove that what we built matched what we set out to build. That work felt like overhead when one person sat alone with the machine, holding the whole thing in their head. With AI doing the typing, it isn't overhead anymore. AI is fast, confident, and sometimes wrong. Catching that is the work.
Every practice I dismissed in 2003 turns out to be the nuts and bolts of how I get any real work done today.
The Sequencer Question To a musician, the advent of mechanical music and sequencers must have been perplexing. Why learn to play the piano anymore, if a machine can play it better than I can? Programmers facing AI codegen for the first time could be forgiven for thinking the same thing. When the thing you got good at suddenly stops being scarce, the natural first reaction is to assume you're out of a job.
Once I had the QY10 I had far more fun telling the sequencer which notes to play (I told it to play a lot of notes in quick succession), than I would have had trying to learn to play it on a piano myself.
And once I gave compilers a chance, I had far more fun telling them what I wanted in a higher-level language than I would have had writing all that assembly out myself, and I got far more done that way too.
Same with AI Codegen. I'm having much more fun telling AI what to aim at next, than I would have writing it all out myself, and I'm able to iterate much faster. That's where the real skill is: everything that isn't writing the code.
AI can have the typing. The aiming is mine.