Code Is Cheap. Show Me the Explain.

Fourteen years of writing software, and the most valuable thing I do today is not writing software.

I started my career dragging PHP files into FileZilla and calling it a deploy. Then CI/CD arrived and the deploy became a pipeline. Then the infrastructure itself became code. Today I watch a system plan its own work, write it, test it, review it and ship it — with me mostly reading and deciding.

Some days that makes me nostalgic. Most days it just makes the job clearer.

AI isn't coming. It's here, it gets meaningfully better every few months, and it is not going to politely stop at the edge of our profession. So the interesting question was never "will it replace us?" It's the one nobody wants to sit with:

What's left that's actually ours?

The Torvalds flip

Linus Torvalds — creator of Linux, and probably the most consequential engineer of the modern era — gave us a line that shaped a whole generation:

"Talk is cheap. Show me the code."

It was the perfect antidote to its moment. An era of endless design documents, architecture astronauts and committees that could describe a system for six months without producing one. Code was the expensive, honest thing. Talk was free.

That economy has inverted. So I'd offer the 2026 edition:

"Code is cheap. Show me the explain."

Producing code is now the cheap part. What's expensive is deciding what to build, choosing the shape it should take, understanding what that shape will cost you in eighteen months — and being able to defend all of it when someone asks.

I'm not saying craft stopped mattering. I'm saying the scarce resource moved. And most of us are still optimizing for the abundant one.

The interview that gave it away

We interview a lot of engineers. A while ago one of them solved the exercise cleanly — working code, reasonable structure, done well before the time was up.

Then I asked why. Why that database. Why that pattern. What breaks first when traffic goes up 10x.

Silence. Not the nervous kind — the kind where the question simply has no landing surface. The code was real. The reasoning behind it had never existed.

That wasn't one candidate. That was the pattern. And it's the whole problem in miniature: we've gotten very good at producing artifacts, and much worse at producing the thinking that should precede them.

Foundations beat frameworks

Every time I've taught a bootcamp, or mentored a teammate or an intern, this is the one principle I push hardest.

New frameworks appear every month. AI has made it worse, not better — every week there's a new shiny term to feel behind on. "Harness engineering." "Human in the loop." "Agentic engineering," the current favorite of recruiters who couldn't define it under oath. So we run down a road with no end, learning the new thing just long enough to abandon it for the next new thing that promises to be better.

Doing this doesn't make you a better engineer. It arguably makes you a worse one, because you end up master of nothing.

The foundations, meanwhile, barely move. The primitives of almost every programming language are the same. Relational databases are the same (apples to apples — I'm not comparing Postgres to Redis). Every REST framework implements the same handful of ideas. Syntax changes; behavior doesn't. And if you understand the behavior, you stop fighting syntax — you just look it up, because you already know what you're looking for.

Here's the part that matters now: you cannot choose between things you have never compared. Cache or database. Event-driven or request-response. Monolith or services. Every one of those is a comparison, and comparison requires vocabulary you can only get from the foundations.

This was always true. AI just removed the last place to hide.

One tool is not a toolbox

There's a failure mode almost as old as the field itself. In the Fortran era, serious people argued it wasn't a real language — it was for lazy programmers, and real engineers used something harder. In the early 2010s it was Java: if you wanted to do serious work, that's what you used. Call it the fanboy effect.

The purism mostly died. The behavior didn't — it just changed shape. Now most engineers reach for the same tool for every problem they meet: the same language, the same database, the same pattern, the same architecture.

You need ACID transactions — you use Postgres. You need document storage — you use Postgres. You need a cache — Postgres. You need a message queue…

You see where this goes.

And to be fair: sometimes that is the right answer. "Just use Postgres" is a legitimate position, and operational simplicity is a real, underrated trade-off. But there's an enormous difference between choosing one tool because you weighed the alternatives, and choosing it because it's the only one you know.

The first is engineering. The second is a habit wearing engineering's clothes.

Each problem is different, so the solutions should differ too. The failure isn't loyalty to a tool — it's not knowing what the options are, and not having the criteria to pick between them.

From coders to thinkers

Which brings us to what the role is actually becoming.

Engineers don't spend hours writing a module anymore. AI does it in minutes, and it does it well. What AI still can't do is decide how a complete solution should fit the thing your company actually needs — the constraints nobody wrote down, the migration you can't afford this quarter, the team that has to maintain this at 3 a.m.

AI will happily write you an impressive RFC with an outstanding solution. That's not the same as the right solution for your context. And trusting it blindly is how you end up with software that reads beautifully and doesn't scale.

So the role moves toward architecture. AI takes the heavy lifting; we take the judgment.

That's the theory. Let me show you the proof.

The part where I stop theorizing

Six months ago we took on an intern. Call this the smallest possible experiment: one person, no curriculum, and a question — can we grow what we can't hire?

Manu walked in expecting a Go bootcamp. Deep language concepts, FizzBuzz, a few toy web services, a syllabus to grind through. That is not remotely what happened. We handed him problems instead — real ones — and then, when he'd solved them, we studied the new problems his solutions had created. He wasn't there to learn Go. He was there to learn the problems we face every day.

He also arrived not trusting AI at all. At university he'd thrown his Operating Systems homework at ChatGPT and gotten back wrong APIs, wrong libraries, code that didn't compile. What he says about the change is the most important sentence in this article:

"Yes, the AI got better. But so did I. Understanding the problem is what let me drive it toward better implementations."

Not "AI made me faster." Understanding the problem is what made the AI useful.

What came out of it was real. A CLI that flags known vulnerabilities and deprecated dependencies — which promptly found things we had to go fix. The same code challenges we use in technical interviews, passed. Nearly all of that work lived in system design; implementation was execution, and execution was AI's job.

He's clear-eyed about the trade, too. AI gave him speed — scaffolding, syntax, the keyboard work. It could not give him judgment: why this pattern, why this trade-off, why now. Design was hard. Code review was harder, and took him longer than he expected — because reading code critically is a different skill from writing it, and it's the one that's suddenly load-bearing.

His line on it:

"AI implements. But when the bugs come, Claude doesn't take the blame — I do."

Six months ago he was thinking about FizzBuzz. Now he is on a production incidents on a Saturday morning, shipping a real fix to a system thousands of people depend on.

That's the distance. And notice what closed it: not a framework, not a course, not the model version. Foundations, real problems, and someone accountable for the result.

What I'd actually change on Monday

• Hire and mentor for explanation, not output. Stop scoring the working solution and start asking why it was chosen. Make "I don't know — here's how I'd find out" a passing answer. It usually is one.
• Teach problems, not syllabi. Nobody has ever become a good engineer by completing a curriculum. Hand people something real that matters, then debrief what their fix broke.
• Treat code review as the new craft. Writing is no longer the bottleneck; reading is. Reviewing AI output well is the highest-leverage skill on most teams right now, and almost nobody is training for it deliberately.
• Own the output. You merged it, you own it. There is no version of this where the model is on call.

The ladder got steeper

Here's what I think actually happened: AI absorbed the lower rungs of the engineering ladder. The tasks we used to hand juniors — the CRUD, the boilerplate, the glue — are gone as a training ground.

The ladder didn't disappear. It just got steeper. The first rung sits about where the third used to be, and that is genuinely harder for anyone starting out today.

Which is exactly why the answer isn't "juniors are finished." It's that we have to bring them in differently: through problems instead of tutorials, through judgment instead of syntax, through owning something real instead of practicing on something fake. Manu is not exceptional because he learned Go quickly. He's the proof that the steeper ladder is climbable if you stop teaching the rungs that AI already ate.

Fourteen years in, the most valuable thing I do isn't writing software. It's knowing which software is worth writing, and being able to say why out loud.

AI shouldn't be used to stop thinking. It should be used to think better.