Will AI replace developers? Wrong question.

Before asking what AI is going to replace, we need to know what there is to replace. Let’s forget dictionary definitions and look at what a developer receives in the morning and delivers in the evening. Or three sprints later.

Who? A translator of intentions

In practice, a developer takes an intention as input, often a fuzzy one, and turns it into something that works. The intention arrives as a requirements document, a user story, a mockup, a bug ticket, or a sentence dropped by the coffee machine: “It would be nice if the customer could…”.

If we had to write it the way a developer would, it would look something like this:

function developer(spec, context, coffee) {
  const need        = understand(spec, context); // the real one, not just the written one
  const answers     = ask(need);                 // product, design, client, security…
  const plan        = design(need, answers);
  const deliverable = build(plan);               // ← the “code” part
  verify(deliverable);                           // tests, review, acceptance
  return ship(deliverable); // web app, mobile app, API, docs, architecture, demo, prototype
}
// Simplified signature. The real one takes 47 optional parameters,
// including `deadline`, which is never optional.

Notice that build() is only one line out of six. We’ll come back to that. Here’s the same idea, seen from a little higher up:

Two things to take away from this diagram. First, the inputs are almost always incomplete. A complete, consistent and stable requirements document is a mythical creature, somewhere between the unicorn and up-to-date documentation. A good part of the job is filling in the gaps, and above all spotting the ones nobody has noticed.

Second, the outputs aren’t just code. An architecture diagram, a demo for the sales team, a prototype thrown away after two weeks, a documentation page that will save the support team ten questions: all of that is the developer’s work too.

How? A loop, tools, profiles

The method boils down to a six-step loop that repeats at every scale: for a one-hour ticket as much as for a product that takes a year. Agile methods (Scrum, Kanban) simply organized it into short cycles.

The toolbox

To keep this loop turning, a developer juggles a dozen families of tools. Code is only part of it.

Three profiles, three daily lives

“Developer” is a catch-all word. Behind it are jobs with very different tools and deliverables. Three examples out of dozens:

Three jobs, three toolboxes, and yet the same loop. None of the three works alone, which brings us to the third question.

With whom? At the center of a network

The cliché of the developer alone in the dark dies hard. In a company, they sit at a crossroads instead: every team around them sends them something and expects something back.

Add all of that up (the understanding, the loop, the tools, the people) and you get a picture quite different from that of the “coder”. I tried to sum it up in a single map.

Keep this map in mind: it will be our compass. Because the real question isn’t “can AI code?” (it can, better and better), but “what happens when the purple slice becomes almost free?”. And the profession has asked itself that question before. Several times.

Don’t worry, this isn’t a lecture on the history of computing. Just five snapshots taken at moments of rupture, to see what changed in a developer’s daily life, and what didn’t move an inch.

For each era, I suggest reading the change the way a developer reads a code change: as a diff. In green what comes in, in red what goes out.

+ punch cards, assembly, FORTRAN, COBOL
+ “programmer” becomes a profession in its own right
- programming by rewiring the machine

+ C, C++, graphical interfaces, databases
+ software becomes a mass-market product
- one computer for the whole company

+ HTML, CSS, JavaScript, PHP, Java
+ open source, agile methods, online updates
- the box, the CD-ROM, the yearly release

+ Swift, Kotlin, React, Docker, Kubernetes
+ app stores, cloud, CI/CD, continuous delivery
- installing and maintaining your own servers

+ ???
- ???
  // diff still being computed, see part 3

The same script, four times

Put end to end, these five snapshots tell the same story in four acts. It has played out in every era, with a different cast.

From a few thousand programmers in the 1950s, we have gone to several tens of millions of developers worldwide. Each era removed a layer of tedious work (the cables, managing memory by hand, setting up servers) and each time, demand more than absorbed the gain.

And above all, one thing never changed.

You’ll have recognized the green part of our map from part 1. The successive eras transformed the “producing” slice; they never touched the “understanding, talking, deciding” slice.

In this part, I check my opinions at the door. We look at what happened, what can be measured, what people are saying, and the questions nobody has settled yet. My opinion will wait for part 4, the way a good deployment waits for the tests to pass.

What changed in three years

ChatGPT came out on 30 November 2022. Less than three years later, AI assistants had become a standard developer tool, just like the code editor or Git. Here is what the most solid public figures I know of say.

The last two figures contradict each other, and that in itself is information. AI seems to shine on new, well-bounded tasks, and to struggle more with old, sprawling codebases full of unwritten rules. In other words, where most developers work. Google’s 2024 DORA report, which tracks the performance of software teams, also observed a slight drop in delivery stability associated with AI adoption.

The landscape: six levels of autonomy

There are hundreds of AI tools for developers, and the list changes every month. Rather than a catalog, I suggest classifying them the way we classify cars, from cruise control to self-driving: according to who is holding the wheel.

In 2023, most developers lived between L1 and L2. In 2026, levels L3 and L4 have become common in teams, and L5 has opened up app building to people who have never written a line of code. These last two levels each have their own buzzword.

Vibe coding and agents: what’s genuinely new

In February 2025, Andrej Karpathy, co-founder of OpenAI and former head of AI at Tesla, described a new way of programming that he called vibe coding: you describe what you want, accept what the AI produces without really reading the code, and paste the error messages back to it until it works. He himself presented it as suited to throwaway weekend projects. The term went around the world, to the point of being named Collins Dictionary’s word of the year for 2025.

The other novelty makes less noise but goes further: agents. An assistant answers a question. An agent is given a goal and works in a loop until it reaches it.

In practice, a developer using agents ends up supervising a small team of interns who are very fast, very well read, tireless, and perfectly capable of doing something stupid with remarkable confidence. In July 2025, an agent on the Replit platform deleted a user’s production database during a code freeze, despite explicit instructions. The story went viral, and Replit’s founder publicly apologized.

Vibe coding, assisted development, agents: the three terms are often used as synonyms. They aren’t.

All these novelties lead back to the question everyone is asking, and which I promised to tackle without bias.

Is AI replacing developers?

Rather than answering it (patience, part 4), here is the state of the debate, sorted into three columns: what we hear, what we observe, and what we still don’t know.

The questions nobody has settled yet

Beyond “replacement”, the arrival of AI opens up issues that neither companies, nor lawyers, nor schools have finished dealing with. Here are eight.

First, I wrote down my convictions as they came to me, in no particular order. Then I put them through code review, with the same standards as for code going to production: is it true? Will it still hold in five years? Some pass, others get rewritten, and the review added a few of its own.

- The developer’s job has always withstood technological revolutions.
- It has always adapted, so AI will be no exception.
+ The job never withstood anything: it mutated. Some roles did disappear.
+ The past makes adaptation likely, not automatic. I bet it will happen,
+ for reasons that still hold today.

- Vibe coding is a fad that will shrink and give birth
- to AI-assisted coding.
+ The word “vibe coding” will go out of fashion. The practice itself will split
+ into two uses, both legitimate.

  The promises of agents that build mobile apps on their own and publish them
  to the stores don’t tell the whole story.
- They won’t replace mobile developers.
+ They will replace a good share of an app’s starter code.
+ Not responsibility for its life cycle.

What the review added

Rereading it all, I felt four ideas were missing. They weren’t in my original notes, but they follow from everything above.

Back to the map

Putting all of this together, here is how I see a developer’s typical week evolving. It’s a personal projection, not a numerical prediction.

Code doesn’t disappear; it changes hands. The time freed up shifts upstream (understanding, specifying) and downstream (reviewing, verifying). In other words, towards the part of the job that didn’t budge in any of the four previous revolutions.

What I take from it, depending on where you sit

Your turn

I don’t have all the answers, and I’m wary of those who do. Here are the questions I’m still asking myself. I’d love to read your answers.