Why Learn to Code When Agents Write It?

At a recent conference, I sat on a panel about agentic engineering. Someone in the audience asked the hardest question of the day: how does a non-technical founder get past throwaway, vibe-coded prototypes to a real MVP, one that's actually engineered with agents?

My answer was three words: "Learn to code."

It came across as flippant. It wasn't meant to be, and the question deserved far more than three words. This is the longer answer.

Two kinds of coding

There are two kinds of coding, and we keep mistaking one for the other.

The first is coding to produce code. You need a thing to exist, so you write the code that makes it exist. That was never the point. Code was never the unit of value. And agents now do much of this kind of coding, faster than any of us.

The second is coding as a practice. You write code to learn, the way a musician plays scales or a pilot flies by hand. The output barely matters. What matters is what the doing does to you.

We already know this about other work. Documenting is important, even though most documents are rarely read again. Dwight Eisenhower put the same thing about planning best: "Plans are worthless, but planning is everything." The plan may be thrown out on day one. The planning is what made you understand the problem well enough to adapt when it was.

The document, the plan and the code are all artifacts. The act of making them is what makes you internalize the thing you were trying to do. Code is a little different from the others: it ships, so it has value of its own. But the durable value of coding was never only the code. It was what you took away from the act: the wisdom, the pattern recognition, the hard lessons that stay with you long after the code is rewritten.

When I said "learn to code," I meant the second kind.

Pilots still fly by hand

In the late 1990s, an American Airlines captain named Warren Vanderburgh gave a now-famous training talk to his pilots called "Children of the Magenta." The magenta line is the course the autopilot follows on the cockpit display. His worry was that pilots had become so used to following it that they were losing the skill, and the judgment, to fly without it, at exactly the moment they needed it most.

Autopilot didn't make pilots unnecessary. It made the pilot's judgment matter more, because the pilot is the one who decides when to take the controls back. Airlines still have their pilots hand-fly, not to get the plane to Denver, but to stay pilots.

Agents are our autopilot. They'll fly the magenta line beautifully. Someone still has to know when the line is wrong.

Hard limits, soft limits

When I was at Boeing, we had deep discussions about how Boeing and Airbus approached fly-by-wire.

Airbus built hard limits. Its flight computers treat the pilot's input as a request, and they will not let the airplane leave its flight envelope, no matter how hard the pilot pulls. Boeing built soft limits. The system pushes back, warns and makes it harder, but if the pilot insists, the pilot wins. In Boeing's view, the pilot is the final authority.

Both are sound on paper. Hard limits protect against the mistake a tired or startled human makes. Soft limits protect against the case the designers never imagined, where the person at the controls understands the situation better than the system does.

Neither side has a spotless record. In 1988, at an air show in Habsheim, France, an Air France crew flew a brand-new Airbus A320 low and slow over the runway in front of a crowd, and into the trees beyond it. Three passengers died. The captain argued the airplane wouldn't give him the climb he asked for. Investigators concluded the crew had flown too low and too slow. People still argue about it.

And Boeing's own hardest lesson came from the opposite direction. On the 737 MAX, a system called MCAS repeatedly pushed the nose down on bad sensor data while the pilots fought it. Two airplanes were lost, and 346 people died. That was automation overruling the humans at the controls, at the company that had always said the pilot gets the last word.

In software engineering, we talk a lot about keeping a human in the loop. With AI, we talk about it a lot more, and for good reason. Without sound judgment and wisdom at the controls, no amount of systems engineering, now or in the foreseeable future, can replace what our wetware evolved to do: novel, ad hoc problem solving, measured in milliseconds.

But a human in the loop is only worth the judgment they bring to it. That's the point of the practice.

What the practice teaches

I've written about procedural knowledge, the kind you only get by doing, in Wisdom Can Be Learned, Not Taught. Coding by hand is one of the fastest ways to start earning it. Here's some of what it teaches that no summary can:

• How systems actually behave. State, data, time and failure stop being words and become things you have tripped over. You learn that two users clicking at once is a different problem from one user clicking twice.
• Where the live wires are. You learn which mistakes are 12 volts and which are 200, because you got zapped by a few of each.
• A language. You learn the words for what can go wrong, which means you can finally ask about it. You can't ask an agent about a race condition if you've never heard of one.
• A nose. After enough hours, some code just smells wrong before you can say why. That smell is judgment, starting to form.

None of that comes from reading the code an agent wrote. It comes from writing some yourself, getting it wrong, and finding out why.

One word, a whole city

That third one, the language, matters more with agents than it ever did with people.

Like us, agents learned from the software world's documents and code. When you use a word that's well cemented in the industry, a word like "race condition," "idempotent" or "eventual consistency," you land somewhere very specific inside the model. That one word drops you into a metropolis, filled to bursting with solid ideas, and the ideas that follow from them.

Try to describe the same idea in a paragraph of your own words, and you'll be lucky to reach the suburbs, let alone the city limits. You might not even land in the right state, or the right country.

The same vocabulary works with people. It lets you talk to other professionals, who can cut a conversation short and get straight to the problem and the possible solutions. Used wisely, an agent can do the same. Learning to code is how you learn those words, and what they really mean.

Doing less, thinking more

Here is the catch. When you work with agents, you do less. The agent writes the code, so the act that used to teach you is happening somewhere else. So how do you stay engaged? How do you keep learning when you're no longer the one doing?

You think on purpose, at three moments: before the agent starts, while it works, and after it's done.

Before the agent starts

Think ahead. Start with what you're actually trying to achieve, because that's the actual problem. The five whys from Lean are a great tool here: ask why, then ask why of that answer, until you reach the real need under the request.

Then start with the customer, the person using what you build. What are they trying to achieve? Can they do it at all? And if they can, is it easy, one click, or do they need a user's manual and an agent to walk them through a 12-step dance? In other words, is it usable?

How would you know you succeeded in delivering value to them? Remember that in software, you know what your users do, not why they do it. If they clicked that button, did they mean to? Or was it poorly labeled, or in the wrong place? The craft of product engineering is broad enough to spend a lifetime learning its nuances.

Only then ask what failure would look like, and where the one-way doors are: the choices that are hard to undo once made, like a data model, a public API or a security boundary. Decide those yourself, or at least decide them knowingly, before an agent decides them for you.

While it works

Think alongside it. Read what it's doing as it does it. Ask why it chose this approach over another. Stop it when it wanders.

After it's done

Think after it. Read the code. Break it. Ask what it didn't consider.

And at every moment, think around the corners, into the negative space. Agents are very good at what you asked for and very bad at what you didn't. The unhappy paths, the second running instance, the retry, the abuse case, the change you'll need to make next year: that's the negative space, and agents don't go there unless someone sends them.

Say what you need, not how to build it

There is one more trap, and it catches experienced people too. An agent is built to meet everything you ask, to the letter, not just the spirit of the ask. If you over-specify how to build something, it will build exactly that, even when your "how" was a poor fit for the problem. It's a kind of over-fitting: the agent fits your words instead of your need.

So separate the two. Be precise about the functional requirements: what it must do, for whom, and under which constraints. Be deliberately loose about the technical implementation, unless the implementation is itself a one-way door you've already thought through. Then judge what comes back against the need, not against your words.

Knowing which is which, what to pin down and what to leave open, is judgment. It's exactly what the practice of coding teaches.

You can't direct what you can't interrogate

This is the real answer to the question about prototypes and MVPs.

A vibe-coded prototype is the agent's answer to "can we?" An engineered MVP is a long series of answers to "should we?": which database, which IDs, what happens on retry, who can see what, what breaks first at a thousand users. The agent will answer all of those questions too, quietly and confidently, whether or not anyone asked. I wrote about how that goes wrong in You Can't Direct What You Can't Interrogate.

The founder's job isn't to write the MVP. It's to ask those questions, and to know a good answer from a confident one. Coding as a practice is how you learn to do that.

A path for non-technical founders

You don't need to become a software engineer. You need enough of the practice to direct agents instead of hoping. Here's where I'd start:

1. Build one small thing by hand, end to end. A tiny app with a real database, deployed somewhere real. Use an agent as a tutor, not a ghostwriter: ask it to explain, then type it yourself.
2. Break it on purpose. Two browsers at once. Turn the database off. Send the same request twice. Watch what happens, and ask why.
3. Read what your agent writes, and ask "why?" about every choice. Why this ID? Why this table? What happens if this fails? If the answer doesn't make sense, that's the lesson.
4. Find a seasoned engineer, an hour a week. Show them what you built and what broke. This is the apprenticeship the industry used to give everyone for free.
5. Learn the vocabulary of the unhappy path. The questions in You Can't Direct What You Can't Interrogate are a good map.

Your first step this week: build the smallest thing you can think of, by hand, that stores something and shows it back. Then break it.

The answer I should have given

So here is the answer I should have given on that panel.

Learn to code. Not to write your product. Your agents will write most of it. Learn to code because the practice teaches you how systems think, and gives you the language to ask the questions that turn a prototype into a product. Code was never the point. But coding is still the way in.