4 Aug 2026 · by Rehan Azaz

AI writes the code now. That was never the hard part.

OpinionAICareers

A wireframe neural-network sculpture suspended above a metal base on a dark grid

A year ago, a new client would ask whether I could build the thing. This year, more of them show up with a version already built — a model wrote it in an afternoon — and the ask is different: make it not fall over.

That shift is the whole story of how this job is changing, and most of the takes on it are either too worried or not worried enough.

The part that genuinely got cheap

I am not nostalgic about boilerplate. Scaffolding a service, wiring up a CRUD API, turning a schema into types, writing the first eighty percent of a test suite, one-off migration scripts, the glue between two libraries that almost fit — all of that is faster now, sometimes by a lot. Work that used to take a day takes an hour, and the hour is mostly review.

If your value was turning a clear spec into correct syntax quickly, that value went down. It is worth being honest about that instead of pretending otherwise.

It is also worth being honest about how shaky the "faster" claim is once you measure it instead of feeling it. METR's 2025 randomized study had experienced open-source developers complete real tasks on their own repositories with and without AI tools, and found they were roughly 19% slower with AI — while estimating afterward that they'd been 20% faster. That gap between felt speed and measured speed is the whole argument for judgment over vibes, applied to the tools themselves. (METR later flagged that specific finding as likely outdated as developer workflows adapted — which is exactly the kind of self-correction worth trusting over either the original headline or the hype that replaced it.)

The part that didn't move

Deciding what to build. Knowing which of three reasonable designs survives contact with real traffic. Understanding how a payment provider behaves when the same request arrives twice because a phone dropped signal at the wrong moment. Spotting the outbound call with no timeout before it takes the whole service down at 3 a.m. Knowing which database migration can be rolled back and which one you only get to run once.

None of that got cheaper, because none of it was ever about producing code. It is about judgment, and judgment comes from having shipped things and watched them break.

What clients actually pay for now

Not typing speed. They pay for the person who reads the generated code and points at the line that will double-charge a customer under bad connectivity. The review, the "let's not do it that way", the unglamorous insistence on handling the failure case. A model will confidently hand you something that works in the demo and has a race condition in the resolver. Someone still has to catch that, and be accountable for it once real money moves through it.

That accountability is the product. It always was. The code was just the medium.

The uncomfortable bit

The way most of us built that judgment was by writing a great deal of straightforward code, shipping it, and being on call when it misbehaved. That bottom rung — learn by doing the simple stuff at volume — is exactly the work that is now automated, which makes the ladder harder to climb.

The answer is not to pretend the tools do not exist. It is to build judgment on purpose: read other people's incident write-ups, review a model's output as closely as you would a stranger's pull request, and own something in production early, even something small. The skill was never "write code". It was "be responsible for what the code does in the world", and that is still the job.

Where I have landed

I use these tools every day. They have made me faster at the things I was already good at and no better at the things that were always hard. The work that is left is the work that was always the point — and I think that is a better job than the one it replaced, not a worse one.

FAQ

Does AI actually make developers faster?

It depends heavily on the task and how you measure it. METR's 2025 study found experienced developers were measurably slower with AI tools on their own real repositories despite feeling faster — a gap between perception and reality that's worth checking against your own logs rather than assuming either the hype or the backlash is right for your situation.

Will AI replace software engineers?

It's replacing a category of work — boilerplate, scaffolding, first-draft code — much faster than it's replacing the judgment about what to build, what will break, and who's accountable when it does. That judgment is what the job increasingly is.

What skills should junior developers focus on now?

Reading code critically, not just writing it: review AI output the way you'd review a stranger's pull request, read production incident write-ups to build intuition for failure modes, and own something live early, even something small. The old path to judgment — writing huge amounts of simple code and watching it break — is exactly the work that's now automated, so it has to be built on purpose.

How do I review AI-generated code effectively?

Assume it's confidently wrong somewhere specific rather than generally unreliable. Check concurrency and retry assumptions, error handling on the unhappy path, and anything touching money or user data — the categories of bug a model tends to produce clean-looking code for anyway. See a real one of these that made it to production.

Is AI-generated code less reliable in production?

Not inherently — but it's confidently wrong in the same shapes a junior engineer under deadline pressure is: plausible on the happy path, thin on retries, timeouts, and edge cases. Treat it with the same review rigor you'd apply to any code you didn't personally reason through line by line.

What is "vibe coding" and why is it risky?

Shipping AI-generated code on the strength of it working in a quick manual test, without review or an understanding of why it works. It's risky for the same reason untested code has always been risky — the failure just shows up later, in production, instead of in review.

How do I build engineering judgment if AI writes most of the code?

Deliberately, since it no longer happens as a side effect of typing a lot of code. Read other engineers' incident postmortems, review AI output as rigorously as a colleague's pull request, and take ownership of something in production — even something small — early and often.