For 15-minute non-fiction book summaries of best-selling books, check out sumizeit.com

TL;DR

AI hasn't replaced software engineers — it has changed the job description out from under them. The work is shifting from writing code to directing, correcting, and judging the code that machines produce, and the people most at risk aren't the ones who can't code but the ones who refuse to adapt. AI makes weak engineers ship faster mistakes and makes strong engineers extraordinarily productive, which is quietly resetting hiring math across the industry. The durable skill is no longer typing syntax; it's having the judgment to know when the machine is wrong.

A performance review that should worry everyone

A friend of mine — one of the sharpest engineers I know — recently got a disappointing performance review. I assumed the usual: a missed deadline, a buggy release, a project that slipped. The feedback was none of that.

"They told me the bar is higher now," she said. "I'm not using AI enough. Other engineers are shipping ten times the code I am."

Sit with that for a second. The criticism wasn't that her work was bad. It was that she wasn't leveraging the machine hard enough. In a single review cycle, the definition of a productive engineer had been rewritten, and she'd been measured against a standard that didn't exist a year ago.

At another company a friend works at, AI now generates roughly 95% of the code that ships. Ninety-five percent. The humans haven't disappeared — they've changed roles. They've become something closer to editors, conductors, and quality inspectors than authors. And when a project runs slow, the first question in the standup isn't "what's blocking you?" It's "are you using AI? Why is this taking so long?"

That question — half-encouragement, half-accusation — is the sound of an industry resetting its expectations in real time.

The job changed; the title didn't

For decades, "software engineer" meant, at its core, a person who translates intent into code. You understood a problem, designed a solution, and typed it out in a language a computer could run. The typing was never the whole job, but it was the visible, billable, measurable part of it.

That part is now substantially automated. Modern coding assistants can scaffold an entire feature, write tests, generate boilerplate, and refactor messy functions in seconds. The bottleneck has moved. It's no longer "how fast can you write correct code?" but "how well can you specify what you want, evaluate what you get, and catch what's wrong?"

This is a subtle but enormous shift. The engineer's value used to live mostly in their hands — in fluency with syntax, APIs, and patterns. Now it lives mostly in their head — in their taste, their architectural judgment, their ability to smell a bad abstraction before it metastasizes through a codebase. The title stayed the same. The job underneath it quietly became a different job.

And here's the uncomfortable part: not everyone who was good at the old job will be good at the new one. Being a fast, accurate typist of code is no longer a moat. Being the person who knows which code should exist at all is the new moat — and that's a rarer skill that AI, for now, can't fully replicate.

AI doesn't make bad engineers good — it makes them dangerous

There's a seductive myth floating around that AI democratizes engineering — that anyone can now build software because the machine handles the hard parts. The reality on the ground is more complicated, and a lot more dangerous.

AI makes mistakes. Constantly. It hallucinates functions that don't exist, misuses libraries, introduces subtle security holes, and writes code that runs perfectly until the one edge case that takes down production. The difference between a good engineer and a weak one using the same tool is not the speed of output — it's the ability to detect when the output is garbage.

A strong engineer reads the generated code with a skeptical eye. They notice the off-by-one error, the unhandled null, the database query that will choke at scale. A weak engineer sees code that compiles, assumes the smart machine knew what it was doing, and ships it. The tool amplifies whatever judgment the human brings to it. Give it to someone with good judgment and you get a force multiplier. Give it to someone without and you get plausible-looking mistakes at ten times the speed.

This is why the "anyone can code now" framing is misleading. AI lowers the barrier to producing code, but it raises the premium on understanding code. The gap between looking competent and being competent has never been wider, and it tends to stay hidden until something breaks.

You don't prompt once — you negotiate

Anyone who has actually used these tools for serious work knows that "AI writes the code" is a fantasy of people who've never tried it on a real codebase. What actually happens is a negotiation.

You ask for something. You get a first draft that's 70% right. Then the real work begins. "No, refactor this — it's not readable." "A human has to maintain this, so simplify it." "That's the wrong pattern; use dependency injection here." "You introduced a race condition — fix it." Turn after turn, you steer the machine toward something you'd actually be willing to put your name on.

Sometimes the output is technically correct but reads like it was written for another machine, not a person. It works, but no human could maintain it six months from now. So you keep going, pushing for clarity, for naming that makes sense, for structure a teammate could follow. The skill isn't getting code out of the model. It's getting good code out of the model — and knowing the difference.

This is a genuinely new craft. It rewards people who can articulate precise requirements, who can hold a system's architecture in their head while evaluating a fragment of it, and who have the patience to iterate rather than accept the first answer. It's less like typing and more like managing a brilliant, fast, slightly unreliable junior engineer who never gets tired and never learns from yesterday's correction.

The brutal new math of hiring

All of this rolls up into a calculation that executives are now making in spreadsheets across the industry, and it's stark in its simplicity: why hire ten programmers when five — armed with AI — can ship the same output?

That's the logic behind a wave of layoffs that companies are sometimes candid about and sometimes not. When each engineer's effective output multiplies, the headcount required to hit the same roadmap shrinks. The work doesn't vanish; the number of people needed to do it does. And in a market where capital is expensive and investors reward efficiency, that math is irresistible.

It's worth being clear-eyed about who this hits. The narrative that "AI is taking jobs" is too simple. AI isn't walking into offices and firing anyone. What it's doing is changing the ratio of output to headcount, and leaving leadership to decide what to do with the surplus. Some companies reinvest it — same headcount, more ambition, more products. Many don't. They bank the savings.

The engineers most exposed are not necessarily the worst ones. They're the ones whose entire value proposition was the part that got automated, and who haven't yet rebuilt their value around the part that didn't. Tenure doesn't protect you. Pedigree doesn't protect you. Adaptation does.

How to keep your seat — and your sanity

If the job is changing, the obvious move is to change with it. The single most important career decision a technologist can make right now is to get genuinely fluent with AI tools — not dabbling, not occasional use, but deep, daily, expert-level command. Being antiquated is the surest way to find yourself on the wrong side of that hiring spreadsheet.

But there's a nuance worth holding onto, because the pressure can curdle into something unhealthy. The goal isn't to write ten times more code; it's to deliver ten times more value, which is not the same thing. Volume of code has always been a terrible metric — more code usually means more bugs, more maintenance, more surface area for failure. An industry that rewards engineers for sheer output is optimizing for the wrong number, and some of the "10X" pressure is just a bad metric dressed up as a high standard.

The engineers who will thrive are the ones who pair AI fluency with the things AI still can't do well: system design, debugging gnarly production incidents, understanding what users actually need, making judgment calls under ambiguity, and taking responsibility for outcomes rather than just output. Lean into the parts of the job that require a human who understands the whole picture. Use the machine for the parts that don't.

And it's worth naming the human cost honestly. Being told your best work isn't enough because you didn't use a tool aggressively enough is demoralizing, and the pace of change is exhausting in a way that's easy to dismiss. Adapting is necessary, but it shouldn't mean burning yourself out chasing a productivity number that was arbitrary to begin with. The healthiest stance is to learn the tools fast, deliver real value with them, and refuse to confuse activity with worth.

The optimistic case nobody mentions in the layoff headlines

It would be easy to read all of this as pure doom, but that misses half the picture. Every previous wave of automation in software — compilers, high-level languages, open-source libraries, cloud infrastructure — was supposed to reduce the need for engineers. Each time, the opposite happened. Abstracting away the tedious parts didn't shrink the field; it expanded what was buildable, which created demand for more software, not less.

There's a real chance AI follows the same arc. When building a feature costs a fraction of what it used to, the calculus around which projects are worth attempting changes completely. Ideas that were never economical — niche internal tools, one-off automations, software for tiny markets — suddenly pencil out. A solo founder can now ship what used to require a small team. A small team can attempt what used to require a department. If that demand materializes, the surplus productivity gets reinvested into ambition rather than banked as layoffs.

I've watched this play out in my own work. Tools I would never have built because the engineering cost was prohibitive now take an afternoon. The constraint shifted from "can we build it?" to "should we, and is the idea any good?" That's a more interesting question to be limited by, and it puts the premium back on creativity, product sense, and knowing what's worth making — all deeply human skills. The engineers who frame AI as leverage rather than replacement tend to find their reach expanding, not contracting.

The honest answer is that both stories are true at once. Some jobs are being eliminated by the new math, and some new ambitions are being unlocked by the same tools. Which force dominates probably depends less on the technology than on whether leaders choose to harvest the savings or invest them.

The ground is still moving

The disruption in software is not a finished event; it's an ongoing realignment, and nobody — not the executives writing the spreadsheets, not the engineers being measured against them — fully knows where it lands. What's clear is that the nature of the work has changed. The job is no longer "write code." It's "command the tools that write the code, and have the judgment to know when they're wrong."

That's not a smaller job. In some ways it's a harder, more senior one, demanding more taste and more responsibility per person. The engineers who internalize that — who treat AI as an instrument to be mastered rather than a threat to be ignored or a crutch to be leaned on — are the ones who'll still be standing when the dust settles. The rest of us are all, in our own industries, watching the same story start to unfold.

For 15-minute non-fiction book summaries of best-selling books, check out sumizeit.com