Will AI Replace Software Engineers? No, Unless You Only Write Code

Nov 13, 2026

Jono Bacon

Reading Time: 12 min

The question hanging over software right now is a slightly haunted one: will AI replace software engineers? I’ve watched an absurd number of waves of “this new thing is going to kill all the coders” across thirty-odd years in and around software, including a chunk of developer relations at GitHub and years at Canonical managing the Ubuntu community.At Stateshift, we’ve worked with more than 240 developer-focused companies, and we watch how their teams are adopting AI up close. My answer hasn’t changed, and it’s the one to hold onto if you’re trying to work out whether to panic.

Short answer: will AI replace software engineers?

No, AI is not going to replace software engineers. But it is absolutely going to replace developers who think their entire job is writing code. The gap between those two sentences is going to decide a lot of careers by 2027 and across the five years after it.

The developers who thrive through 2027 are the ones who treat AI as a power tool for the boring half of the job and double down on the parts machines are still laughably bad at: architecture, judgment, security trade-offs, and wrangling actual humans toward a shippable outcome.

The question people are actually asking

The “AI replace developers” debate has become its own little cottage industry. Hot takes on LinkedIn, doomer threads on X, breathless newsletters predicting that by Tuesday your job will be done by a chatbot wearing a tiny hat. Underneath the noise, the question people are really asking is simpler and more personal: am I still going to have a career in five years?

Fair question. A straight answer beats another round of “it’s complicated, hire me as a consultant to find out.”

Every generation gets its own “apocalypse”

We’ve done this before, repeatedly, and the doom parties never seem to remember the last one.

Spreadsheets took out the soul-grinding part of accounting, the human being with a pencil adding up columns of numbers until their eyes bled. The accountants who only did that had a rough decade. The ones who understood the business, who could look a founder in the eye and say “your unit economics don’t work, and here’s why,” became more valuable. A 2026 SSRN paper by Eldar Maksymov at Arizona State argues the spreadsheet sorted accounting, erasing roughly a third of the clerical tier while the judgment-heavy work kept going.

will AI replace software engineers

Then came Zapier, IFTTT, the whole no-code wave, and Gartner predicting that by 2024 low-code would account for more than 65% of application development. The hot takes translated that into software engineering getting its own funeral notice. The casualty was duct-taping two APIs together at three in the morning because the sales team needed a report by breakfast. Everything else carried on.

Coders anxious about Zapier and no-code tools, the earlier version of will AI replace software engineers?

AI is this generation’s version. It’s coming for the repetitive, translation-y part of the job, the bit where you are a very expensive human taking a spec somebody else wrote and converting it into code that somebody else will then review. If that is the sum total of your working day, things are about to get awkward.

What developers actually do all day

The “AI will replace developers” crowd has this completely upside down. In their heads, a developer puts fingers on a keyboard, code comes out, and somebody ships it.

Writing code is the visible piece of what good developers do, sure, the one we put in movies, where someone furrows their brow at a green terminal and saves the world. It’s also the smallest part of the real job.

A real week looks like:

  • Arguing with a product manager about whether a feature can realistically ship in three months, then arguing again about what “ship” even means.
  • Designing a system that won’t collapse the first time real traffic shows up.
  • Sitting with security to balance shipping something customers want against gifting the keys to the kingdom to anyone with a laptop.
  • Turning a vague executive ambition (“we should do something with AI”) into something that exists in production and doesn’t embarrass everyone involved.

The judgment is the job. The code is what it leaves behind.

Yes, AI will keep getting better at architecture, security, and scaling too, and I won’t pretend otherwise. But I predict a human in the loop stays essential for a long time to come, because someone has to decide what gets built, own the trade-offs, and answer for the result when it breaks. AI can propose an architecture. It can’t be accountable for one. Your value as a hireable human is enormously greater if you refuse to constrain yourself to being a keyboard with legs.

Code is the guitar, not the whole band

The easiest way I know to explain AI’s role in a developer’s job is to think about a band.

Code is the guitar, the showy part everybody notices. The job has always been the guitarist, the bassist, the drummer, the sound engineer, and about half the time the one sorting out the van because the drummer got lost again. Then AI turns up, picks up the guitar, and shreds faster and cheaper than any of you, for anyone with a credit card and a browser.

will AI replace software engineers
Our founder, Jono Bacon, drumming in a hot dog costume with the Ubuntu band. AI works the same in a team: it’s one player in a bigger band.

If your entire identity is “I play the guitar,” you are in a bit of trouble. If your identity is “I make the band work,” AI hands you a free world-class session player who never complains about per diems. That’s a ridiculous gift.

Who’s getting hit hardest right now?

Some people are feeling this very hard right now, and waving it away would be insulting.

The developer who finished a bootcamp last year, whose entire marketable skill is turning a Jira ticket into a pull request, has a harder road than someone who graduated five years ago and had time to pick up architecture, system design, and the political dark arts of working with humans.

But the people I’d worry about most are not necessarily the newcomers. They’re the developers who spend their days announcing that AI is a fad, a stochastic parrot with a subscription fee, and who have never once sat down with it for an afternoon. They’ve decided that learning it is somebody else’s problem, ideally somebody younger, and preferably somebody who’ll stop talking about it.Meanwhile the newcomer who picks the tools up can climb toward architecture and judgment faster than anyone could a few years ago. The developer who digs in and refuses to learn isn’t taking a principled stand. They’re handing their chair to whoever will.

I won’t tell the newcomers it’s all fine and they should learn to meditate. There is a flip side, and it’s bigger than the scary side.

How AI moves developers up into architecture and judgment

The exact tool you’ve been told to be frightened of is your ticket to the other side of this. The doomers will never say so out loud, because it ruins the content.

AI helps you learn the parts of the job you’ve been quietly dodging, and it lets you prototype in an afternoon an entire system that would have taken you a month a couple of years ago. Whether you like it or not, it pushes you toward architecture, judgment, and taste, the stuff that makes you the engineer people actually want in the room when the big decisions get made.

It takes courage and time, and it’ll feel ridiculous for the first few weeks, in the same way learning to code felt ridiculous when you stared at a blank editor and wondered what on earth a semicolon had ever done to deserve this much attention. The discomfort is the price, and it’s a bargain for what’s on the other side.

Developers who embrace this get what I think will be one of the most creatively alive decades of their careers. You can now build, with a laptop and a monthly subscription, what used to need a team of ten. You move up into the work that shapes what gets built in the first place, which is about to become the most valuable thing you can do.

Meanwhile, back at the bar, there’s the crowd who’ve decided the correct response is to stand with their arms folded going “I write code, that’s my job, AI is garbage, I’m technically and ethically opposed to the whole thing.” You can hold that view. The code will keep shipping without you, and your opinion will get a sympathetic nod and absolutely no job offers.

How Stateshift runs AI and humans side by side

Stateshift is the go-to-market consultancy we run for technical products, and every day we work with AI and humans side by side.

We use AI for tracking how brands show up in AI search (with Peec and similar tools), and we run a stack of our own specialized agents that help us manage content and business work. Here’s the bit the hype skips: human judgment is still the most critical part of our business, and no amount of tooling changes that.

Someone has to look at what the AI produced and decide whether it’s true, whether it’s useful, and whether it’s safe to put in front of a client. Let AI output ship without that call and you get something confidently, fluently wrong, delivered with total swagger and zero evidence. When that lands in front of a client, nobody gets to blame the robot.

We land on the same split, over and over:

  • AI handles the repetitive analytical lift.
  • Humans own the calls with external consequences. The ones where being wrong actually costs something.

It’s the only sensible way to run it. AI is brilliant at the guitar and still terrible at being in the band.

That same split is the one I’d apply to a software engineer’s week. Let the machine draft, scaffold, and translate, and keep the architecture, the trade-offs, and the human conversations for yourself.

How should developers start working with AI this week?

Nobody is coming to protect you, and nobody enjoys hearing it. A conference talk won’t do it, and the AI certainly won’t. If your head is in the sand, you need to pull it out and start learning.

I’d start this week rather than next year, and the short version looks like this:

  1. Pick the tools up and pay for the good ones. Yes, actually pay. The free tier won’t expose you to everything you need to fully understand and explore what the frontier looks like.
  2. Build something small and stupid. A script, a prototype, a side project you’d never have shipped otherwise. Find out where the tools are brilliant and where they fall apart.
  3. Be upfront about what you don’t know. Use the tools enough to learn exactly where they get it wrong. That gap is where your judgment earns its keep.
  4. Then climb. Move into the work that challenges and excites you: architecture, product, security, and the messy human stuff.

I might be wrong about parts of this. If you’re a developer who thinks I’m being naive, or a founder who’s watched this play out differently inside your own team, tell me. Arguing about it in good faith, with the tools in our hands, is how any of us figure this out.

AI has the guitar covered. Go and pick up the rest of the instruments.

Common Questions On The Future Of AI And Software Engineers

Will AI replace software engineers?

No. AI will replace developers who think their whole job is writing code. Most of software engineering is judgment: architecture, security trade-offs, and getting people to agree on what ships. At Stateshift, we’ve seen that the teams using AI well let it speed up the coding, and humans still make the calls.

Which developers are most at risk from AI?

Two groups. Newer developers whose main skill is turning a Jira ticket into a pull request have the hardest road, because that’s the work AI does best. The bigger risk is experienced developers who refuse to try the tools at all. A newcomer who learns AI can move toward architecture faster than ever. The developer who digs in and won’t learn is handing their chair to whoever will.

What should developers focus on as AI writes more code?

The parts machines are still bad at: system architecture, security trade-offs, product judgment, and steering a group of humans toward something shippable. AI can propose an architecture, but it can’t be accountable for one. Someone has to decide what gets built and answer for it when it breaks, and that person stays valuable.

How should developers start using AI?

Start this week. Pay for the good tools, because the free tiers don’t show you what the best models can do. Build something small and a little stupid, like a script or a side project, and notice where the tools are brilliant and where they fall apart. That gap is where your judgment earns its keep, and it’s how you move into higher-value work.

How should teams split work between AI and humans?

Give AI the repetitive analytical work, and keep humans on any decision where being wrong costs something. That’s how we run Stateshift. AI tools and our own agents help with content, business work, and tracking how brands show up in AI search. A person checks every output for accuracy and safety before it reaches a client. Engineering teams can split work the same way: AI drafts, scaffolds and translates, and engineers own the architecture, the trade-offs and the conversations.

Written by:
Jono Bacon

Jono is the Founder and CEO of Stateshift. He has 27+ years of experience building user and developer engagement across 250+ companies. He is also the author of 'People Powered' by HarperCollins.

Get the SHIFTsignal

SHIFTsignal is not a boring newsletter filled with links…
…it is a FREE weekly dose of high quality insights, techniques, and recommendations for building your movement sent directly to your inbox.