I wrote recently about how I use AI every day to build and ship. That post was from the trenches — the working loop, the guardrails. This one is the thing I keep turning over as someone who leads engineers, not just writes code: when the typing gets cheap, where does the value go?
Because that's what actually happened. For most of my career, a large part of what we paid engineers for was the act of producing code — translating an idea into working syntax, line by line. AI has made that part nearly free. Not perfect, not thoughtless, but cheap. So the honest question isn't "will AI replace engineers" — it's "the value that used to sit in typing, where did it move?"
It didn't disappear. It moved up the stack, to the things that were always the real job.
The work that got more valuable, not less
Strip away the typing and look at what's left. It turns out to be everything that actually decides whether software is any good:
- Framing the problem. AI will confidently build whatever you ask. If you can't say precisely what "done" and "wrong" look like, it fills the gap with something plausible and subtly off. Knowing what to build — and what not to — is worth more when building is cheap, not less.
- Architecture and the expensive decisions. The choices that are painful to unwind later — data models, boundaries, what to couple and what to keep apart. AI hands you a reasonable-looking answer that quietly boxes you in three months out. That call is still yours.
- Smelling the bug before it happens. The instinct that says "this will break under load" or "this edge case will bite" — that's pattern-matching earned over years. You can't prompt your way to it.
- Holding the bar in review. When code is cheap to generate, the scarce, valuable act is deciding what's actually good enough to keep. Review stops being a formality and becomes the main event.
- Deciding what's worth doing at all. Taste. Priorities. The judgment to kill an idea, or to not build the thing everyone's excited about.
None of that got automated. All of it got more leveraged, because now one person with good judgment can direct a lot more output.
The uncomfortable corollary
If the value moved to judgment, then the people who were paid mostly to type are the ones exposed — and the people who were really paid to think are fine, maybe better than fine.
That's uncomfortable, especially for engineers early in their careers who are still building the judgment. But it's not new. The job was never really "produce code." It was "solve the problem correctly, and be the one accountable when it's wrong." AI just made that obvious by taking the typing off the table. The syntax was always the least interesting part; we just spent a lot of hours on it.
What it changes about how I lead
Let me make this concrete, because most of it I've learned the hard way.
A change once landed in one of my reviews that was simply too good. Too polished; an unfamiliar pattern; a quality of code that — and I knew this person, I knew what he could and couldn't do — was too good to be true coming from him. Knowing your people well enough to feel that gap is its own kind of judgment, and it's exactly the kind that just got more valuable. I pushed on it in the review. He held for a moment, and then it came out: ChatGPT.
Here's the part it's easy to get wrong. Using AI wasn't the problem — I'd have been glad if he had. The problem was that he'd handed me work he couldn't explain, couldn't defend, and couldn't have written himself, and passed it off as his own. It never went to production; he reworked it to our platform's guidelines, into something similar that he could actually stand behind. And it turned out to be a symptom, not a one-off — of a piece with a gap I'd been watching for a while. He stayed on a bit longer, went onto a plan, and just before we'd have had to make the call, he resigned and left.
I don't tell that as a gotcha. I tell it because it's the cleanest example I have of where the value moved. His typing was free; everyone's is now. What he didn't have was the part that's become the whole job — the judgment to know whether what the machine handed him was right, and the ownership to put his name on it. Review is where that shows up, which is why it stopped being a formality on my teams the day the typing got cheap.
And notice what I actually couldn't tolerate: it was never the tool. It was the not owning it — not saying so, holding out until we pressed, then trying to quietly slip the whole thing. That's the opposite of how I run a team. We're an open lot, by design; we'd far rather own a mistake out loud than hide a polished one. That's the real reason review matters more now, not less — it's where ownership either shows up, or it doesn't.
So, concretely, a few things changed:
I hire for judgment and taste, not typing speed. Raw ability to churn out code was never the constraint I optimised for, and now it matters even less. I want people who ask the sharp question, who can smell a bad abstraction, who hold a high bar without being told to.
Review is now the bottleneck — so budget for it. And done right, that's a superpower, not a tax. We needed SSO built into the platform — a month of work, comfortably. With AI we had it working in about a week. Then we did the part that matters: reviewed it properly — architecture, design, the code itself, QA, even UAT — before it went anywhere near production. The AI bought us three weeks; the review is what let us trust those three weeks. Produce in a week, but be sure before you ship. A team that speeds up the producing without funding the being-sure hasn't gotten faster — it's just built a bigger pile of code nobody has actually vouched for.
I teach judgment, not syntax. Mentoring used to be a lot of "here's the idiomatic way to write this." Increasingly it's "here's how to tell whether what the machine gave you is right — and here's why this architecture will hurt later." The senior engineer's job is shifting from writing the hard parts to knowing which parts are hard.
Never ship what you can't explain. My one non-negotiable — and that whole story in a single line. If someone can't defend a change in review, it doesn't matter that it was cheap to produce. Cheap and unexplained is a loan against a future 2am debugging session, at interest.
The trap: mistaking output for progress
The seductive failure mode is confusing volume with value. AI makes it trivial to generate mountains of plausible code, plausible docs, plausible plans. It feels like progress. Often it's just more surface area to be wrong across.
I've paid for that surface area myself. A set of our services were AI-assisted — one serialized data into a store, the others read it back out and deserialized it. Each service passed its own tests; each review looked clean. But two of them quietly disagreed on how the data was deserialized, and the mismatch only surfaced once they were talking to each other for real. We spent the better part of two days debugging every service in the chain before we found it — because the bug wasn't in any one service, it was in the seam between them, exactly the kind of thing that slips past when each piece looks plausible on its own. We'd missed it in review. More code, generated faster, means more seams — and more places for a subtle disagreement to hide. Volume was never the same as correctness; it's just cheaper to fake now.
The teams that win with this won't be the ones that produce the most. They'll be the ones that keep their judgment fast enough to match how quickly the tools now produce. The bottleneck moved from making to being sure — and pretending otherwise is how you end up shipping fast and breaking quietly.
What it means for your career
If you take one thing from this: become the person who decides what's right, not the one who types fastest. Build the judgment. Learn the foundations properly, not just the tools — because the tools change every six months and the judgment compounds for decades. Get reps at framing problems, at reviewing hard, at owning the "is this actually correct" question.
The engineers I'd bet on aren't worried about AI writing their code. They were never really paid to write code — they were paid to think, and to be right. That premium just went up.
The honest close
None of this is doom, and none of it is hype. And I get it wrong too — that's the honest part, and the same bar I hold anyone on my team to: own it, out loud. I once trusted an AI-assisted change that ran perfectly in dev and then simply refused to work in production; I ended up walking it line by line until I found the exact place it broke. AI made me faster on a good day and gave me more rope to hang myself with on a careless one.
It hasn't made engineering easier; it's made the thinking the whole job, and cleared away the busywork that used to hide it. The tool got sharper. So the person holding it has to be sharper too. That's the deal — and honestly, it's a better one. The boring part got cheap, and the part that was always the actual work got more valuable. I'll take that trade.