Soumitra SahaMay 22, 2026

Will AI Replace Software Developers? What Developers Should Actually Prepare For

I look at what the research says about AI and developer productivity, where certain roles are genuinely at risk, and what is actually worth preparing for.

The question I keep hearing from both developers and non-developers is some version of: “Will AI replace programmers?” I’ve started to think the question is backward — not because the answer is obvious, but because it sets up a binary that misses what’s actually happening.

The real question isn’t whether AI can do what developers do. It’s whether the things developers currently spend most of their time on are the things that actually make them valuable. Those two questions have very different answers.

I’m going to walk through the data honestly, look at what AI can and can’t do well right now, and share what I think the practical preparation looks like — not the abstract “learn soft skills” advice, but something more concrete.

What the data actually shows

The Goldman Sachs research team analysed over 900 occupations in 2023 and concluded that roughly two-thirds of U.S. occupations are exposed to some degree of automation by AI. They estimated that a quarter to half the workload in those exposed roles could be replaced — and put the total exposure at the equivalent of 300 million full-time jobs globally.

That’s a large number, and it shouldn’t be dismissed.

But the same report adds something that doesn’t get quoted as often: “most jobs and industries are only partially exposed to automation and are thus more likely to be complemented rather than substituted by AI.” The researchers also cite economist David Autor’s finding that 60% of today’s workers are employed in occupations that didn’t exist in 1940 — and that more than 85% of employment growth over the last 80 years is explained by technology-driven creation of entirely new positions.

The pattern here isn’t unprecedented. New automation displaces certain task bundles. New tools create demand for people who can use them, shape them, and design what they connect to.

For developers, the more useful data point is what actually happens when you put AI coding tools in front of working engineers. In a 2022 experiment with 95 professional developers, those using an AI coding assistant completed the same task 55% faster on average — 1 hour 11 minutes versus 2 hours 41 minutes, a result that was statistically significant (P=0.0017). A separate survey of more than 2,000 developers found that 87% reported the tool helped them preserve mental energy on repetitive tasks, and 60–75% felt more fulfilled in their work.

Those numbers represent a real shift in how software gets written. Ignoring them would be a mistake.

What AI is genuinely good at right now

Based on both the research and using these tools day to day, there’s a fairly clear picture of where AI coding assistance actually earns its keep.

Boilerplate and pattern repetition. If you’ve written a REST endpoint before, you know roughly what the next one looks like. An AI tool can produce that structure faster than you can type it. The speed gain is real, and it removes the low-grade cognitive friction of transcribing what you already know.

Established solutions to well-understood problems. “Write a function to debounce input events” or “generate a migration to add a foreign key” — tasks with known shapes and a clear right answer. The tool has seen thousands of examples and can reproduce the pattern quickly.

Context-switching across syntax. When you spend most of your time in TypeScript and need to write a short shell script or a SQL query, the cognitive cost of switching context is higher than the actual difficulty. AI assistants reduce that cost.

Drafting tests for existing code. Given a function with clear inputs and outputs, generating a set of unit test cases is mostly mechanical. That’s exactly the kind of task where AI does well.

These are real productivity gains. For a developer working on greenfield code with well-defined requirements, they add up quickly. The 55% speed improvement in the controlled study happened on exactly this kind of task.

Where AI keeps hitting a ceiling

Here’s the part the productivity numbers don’t capture.

The controlled experiment measured how fast developers completed a specific, well-scoped task — writing an HTTP server in JavaScript. The task had defined requirements, a known shape, and a test suite to score it. That’s not the hard part of software development.

The hard part is usually deciding what to build and how it should connect to everything else. An AI tool doesn’t know that the system you’re building needs to handle 50,000 concurrent users. It doesn’t know that the database schema you inherited has three tables that are supposed to mean the same thing but don’t. It doesn’t know that the “simple feature request” from the product team would require a rewrite of the authentication flow to do correctly.

Architecture is upstream of code. The decisions about what components exist, how they communicate, what the failure modes are, and where the boundaries live aren’t in the code — they’re before the code. I’ve written about this in my system design fundamentals post, and the honest summary is that these decisions require understanding the constraints of a specific situation. AI tools don’t have that context unless you give it to them — and knowing what context to give, and whether the output respects that context, is itself the skill.

Debugging messy production problems requires judgment. When a service starts throwing errors in production at 3am, the tool that helps you most isn’t one that can write code quickly — it’s your ability to read signals, form hypotheses, and narrow the problem space efficiently. The AI can generate plausible explanations for a stack trace, but it doesn’t know which of the twelve plausible explanations is actually true in your system. I covered this in more depth in how to debug production performance problems.

Accountability doesn’t compress. Someone has to own the decision. When a security vulnerability ships, or a data migration corrupts records, or a payment system double-charges customers, the question “why did this happen and how do we prevent it” needs a human who understood the tradeoffs at the time they were made. That’s not a soft-skills observation — it’s a structural feature of how organisations work.

Which roles carry the most real risk

Not all developer roles have the same exposure, and being honest about this is more useful than a blanket reassurance.

Role profile	Risk level	Why
Pure execution — code from detailed spec, no design input	High	This is the task profile AI tools do best
Manual QA — running scripted tests by hand	High	Easily automated even without LLMs
Boilerplate-heavy work with no system ownership	Moderate-high	Speed advantage narrows the economics
Full-stack generalist with production ownership	Moderate	AI helps with output speed; judgment still required
Systems architect or technical lead	Lower	Upstream decisions; context and accountability matter
Developer embedded in a complex domain (healthcare, finance, infra)	Lower	Domain knowledge isn’t in the training data

The pattern is consistent with what Goldman Sachs found more broadly: exposure correlates with task repetitiveness and how well-defined the inputs and outputs are. The roles most at risk are the ones where the value is primarily in execution speed on known problem shapes.

One thing I want to say clearly: “lower risk” doesn’t mean “safe if you stop paying attention.” The baseline expectation for what a developer can produce is going up. A role that’s currently protected by complexity will stay protected only if the person in it is actually adding the judgment and context that makes it complex.

What to actually prepare for

If I were starting out now, or rethinking how I invest my development time, here’s where I’d focus:

Understand systems, not just code. The closer you are to the architecture layer — understanding how data flows, where bottlenecks form, how to design for failure — the harder you are to replace with a tool that generates code. The code is downstream of the architecture. I wrote about the lessons I’ve picked up from full-stack work that got me thinking this way.

Own the type system. This sounds narrow, but it isn’t. A developer who deeply understands TypeScript’s type system can specify the shape of a problem clearly enough that AI-generated code fits correctly. A developer who can’t often finds that AI output introduces subtle errors that take longer to fix than the code took to write.

Get comfortable debugging unfamiliar codebases. This is the skill that separates people who are productive in any environment from people who are only productive in their own. AI tools help you produce code faster; they don’t substitute for knowing how to read code you didn’t write and don’t fully understand yet.

Build genuine depth in one domain. A financial developer who understands how settlement works, a healthcare developer who understands HL7, an infra engineer who understands networking — this kind of domain fluency is slow to acquire and hard to compress. The AI can write the code; the domain expert knows whether the code is actually correct.

Practice explaining tradeoffs. The ability to say “we could do X, but the cost is Y, and given our constraints Z makes more sense” is not something AI tools do for you. It requires a position, and a position requires judgment about the specific situation.

The framing error worth correcting

The developers I think are most at risk aren’t the ones AI will replace. They’re the ones who will be expected to do more — design better systems, own harder problems, produce more output — while getting paid the same or less, because the tooling raised the baseline and they didn’t raise their own bar alongside it.

The question worth asking isn’t “will AI take my job?” It’s “am I investing my time in the parts of this work that tools can’t do?” Those are different questions, and the second one has an answer you can act on.

An abstract geometric composition showing two distinct node clusters connected by a central axis — representing the relationship between human judgment and AI computation in software development. — The connection between human judgment and AI computation — two different things working together, not one replacing the other.