Software Developers Will Never Die

Rumors of my death are greatly exaggerated.

Software, 2026

More and more companies are replacing developers with AI, and consider that software can be built in autonomy by agents, with minimal human intervention. I feel concerned, because my job is to program websites and software. It’s also my passion, and my expertise. So what is the future of programming in the era of agentic programming?

Existing Software Is Free

The story begins with a hack day: one day of pure innovation to explore new uncharted territories, try new tools and invent new products, that everyone at Marmelab does twice a month.

Cindy wanted to get a better understanding of the best practices for rebuilding existing software with AI. She chose a piece of software that we know very well: our CRM. It’s called Atomic CRM, and we’ve built it from scratch, to better match our needs and learn advanced usage of modern web libraries through practice.

Anyway, Cindy decided to use Atomic CRM as a blueprint to rebuild a CRM from the ground up, but with a different technology. She didn’t write code. Instead, she instructed a coding agent (GitHub Copilot with Claude Sonnet) to start a new project, read the original source, and recreate it using Angular (a popular web framework).

In about 8 hours, the agent rebuilt roughly 80% of the original software, with the same UI. The app is functional, and it stores data in a database. There are some bugs (for instance, it’s not possible to create a deal), some missing features (like the ability to merge two contacts), and some minor UI differences (often for the worse) but overall it does the job.

Original	AI-generated version

What about the generated Angular code? The coding agent did a decent job (see for yourself). The code is clear and follows good practices, although I would have done it differently, reusing more existing libraries (coding agents tend to reinvent the wheel) and breaking the code into smaller, more focused pieces. In other terms, I wouldn’t put this CRM in production yet, but I would after a few days of review.

What this means is that reproducing existing software has become basically free. You still need a subscription to a coding agent, and a few hours of work, but it’s orders of magnitude less than what it took us to build the software in the first place (several months by a team of 2 senior developers). You can try yourself: Atomic CRM is Open-Source, so you can clone it, and ask your favorite agent to rebuild it in your favorite language.

In the age of AI, redeveloping a software is just like copying a file. The cost is so low that you don’t even think about it. Wait, are you still paying an exorbitant Salesforce subscription?

Software Engineers Are Still Necessary

We already use AI to rebuild existing apps (either vibe-coded apps or legacy customer apps), but it’s usually a longer process. We first need to gather existing documentation and design screenshots, use an agent to extract feature descriptions from the existing code, review them, generate automated tests, review those too, make sure they pass, and finally instruct the agent to build the app feature by feature.

We also review the code they produce and realign the agent when it’s not respecting the guidelines. That’s a variant of Spec-Driven Development, and it works fine for rewrites. If we don’t do that, the agent produces garbage.

However, with Atomic CRM, there was no product backlog, no screenshots, no documentation — the only specification was the existing codebase. Yet the agent succeeded, and in record time.

The difference, I believe, is that most of the product design and software engineering was already done. When we initially built Atomic CRM, we made a lot of important decisions: what problems to address, what solutions to use, what user experience to offer, how to structure the data based on the business logic, how to organize the communication between the different parts of the system.

All these decisions required discussions with the users and stakeholders, technical expertise, lots of iterations, and the ability to learn from our mistakes.

The agent, on the other side, didn’t have a lot of thinking to do. The data structure was already written. The UI of each screen was determined. The code is organized in a way (shout out to Shadcn Admin Kit) that makes the business logic very apparent. The source code is concise, expressive, and easy to grasp.

In other terms, writing the code was the easiest part, as all the analysis was already done and the decisions were already made.

So if software is losing value, you still need a software engineer sometimes (either during the initial development, or during the rewrite).

Agents Aren’t That Good At Software Engineering

Wait, the logic is backwards. In Cindy’s test, the agent succeeded because it didn’t require software engineering skills. But that doesn’t mean agents aren’t good software engineers, does it?

Well, they are not good software engineers (yet). Let me tell you about another experiment we did that proves it.

In my company, every new recruit follows a 5-week training program during which they have to build a new application from scratch (and without AI). This means we must write a new list of features every time we hire a new developer. For our next recruit, Benoit decided to use AI to generate the first draft of this feature list for a bug tracker.

Pretty soon, the AI (Gemini) gave us a list of features allowing customers to open tickets and agents to reply to those tickets. But the result wasn’t very convincing. The features described a basic interface for creating, reading, updating, and deleting records — not very different from the bug trackers created 20 years ago.

So we iterated on the specification but this still felt off, and quite far from a real-life product. When compared with existing software, this bug tracker seemed bland, not really polished, not really fit to real life usage.

So we took another approach. We opened Lovable, and started building a new bug tracker from scratch. We could test our ideas fast, so we realized that some of them were not that good, and that we missed some important features.

We iterated a lot to get to the final result, but it only took us a couple hours. We even had the time to address small but important features, like navigating from ticket to ticket, fine-grained access control, and the like. The resulting prototype was quite different from the picture drawn by the initial AI-generated feature list, and honestly a lot better.

The value of this process is judgment. You always have to make some decisions without all the necessary information to make the best decision for sure. In this case you have to judge and rely on your limited knowledge, your experience and your intuition to find a good outcome.

This is not something machines can do, or at least this is not something our society accepts to delegate to machines. Machines can fly planes, yet every plane has a human pilot. Judgment is absolutely necessary in software engineering, because we don’t have all the information, and we produce software for humans.

Eventually, I asked an agent to generate a specification based on our Lovable prototype, and we used this specification for the new recruit’s training instead of the initial AI-generated draft.

The learning is that not anyone can build software from first principles, just considering the problem and the solution space. And so product design and test will always require a human in the loop.

Code Is Cheap, Trust Is Not

But even if artificial intelligence was good enough to do all the software engineering, this would not be the end of software.

It’s not because we can rewrite all the software we pay for that we will. Otherwise, we’d have to support way more code than we actually need.

We don’t buy software because we can’t build it. We buy software because it’s not our core asset, and we want to delegate the task of building it to a company for which it is the core asset. And it’s not just building: operating the production servers, deploying updates, monitoring security, fixing bugs, having people on call, complying with legal obligations, all this takes time. Running a software isn’t much cheaper with AI. In the build vs buy decision, the cost of building your own software is often dwarfed by the cost of owning it. That’s the core of the SaaS business.

Software editors are mostly trust intermediaries. You trust them with a (usually non-strategic) part of your business to focus on what really is strategic.

The fact that you can copy (or create) software for free isn’t news either. Open-source has been around for a very long time, and it hasn’t killed software developers or editors. On the contrary, the open-source ecosystem has empowered many developers and gave birth to a gazillion of software.

My company, Marmelab, is a good example. We publish a lot of the code we produce as open-source (totaling 80,000 stars on GitHub). Yet the company is profitable. We’re even getting additional revenue from our open-source assets (via react-admin Enterprise Edition).

What customers pay for is the domain expertise, the adaptability, the commitment to provide a reliable service. Code has very little part in that. I don’t use Postmark because it is hard to send an email. I use it because they handle everything around sending emails — deliverability, security, spam filtering, legal compliance, and more.

Specification Is The New Code

So if software engineering is about judgment and trust, but AI agents can write most of the code, what does that mean for the future of our craft?

We can take advantage of AI agents to reinvent software engineering to make it more effective, but without inverting the responsibilities: the human stays in charge, and has the responsibility of the result. Let me give you an illustration.

When the customer has a problem, don’t imagine the solution in text, in a user story or a specification. Instead, go directly to your coding agent. Prompt the problem and the ideas you have for a solution. Don’t spend too much time refining the implementation plan, because it will be wrong. Instead, go straight to implementation so that you have a working solution five minutes later. Then test it, iterate, and rebuild it enough times to be sure that you’ve solved the problem.

Then, look at the code. There will be problems that you will want to solve by hand. Don’t do it. Instead, instruct the agent to change its own instructions to avoid this kind of problem in the future.

Next, ask the agent to write a precise specification for the solution that you built. The specification should be complete and enough to rebuild the exact same solution that you found.

Now comes the time for your tests. Erase all the code that you’ve done, except the specification and the agent instructions. Then ask an agent to rebuild the functionality. The result should be pretty much the same as what you originally built. That means the value has been captured (not in code, but in the specs and instructions). Any agent will be able to rebuild it the same way in the future.

Now you’ve solved the problem.

Because code and frameworks come and go, because technology invents new, more efficient ways to implement a given specification, we will always need to rewrite our applications with better technology. But for that, we need to capture the specification.

I think that developers should see the specification as the ultimate goal of their craft. The code, which used to be this ultimate goal, is only a transitional artifact of their understanding of the problem and their design of the solution.

You could say that it’s already what software engineers have been doing for the past 30 years: writing code that translates a solution into something reproducible. No text can capture the precision of well-crafted code, so the specification may not be enough to get something perfect. But coding agents are getting smart enough to fill in the gaps and guess the implementation details.

Conclusion

Because trust and judgment are human-specific, software will never die.

A little voice in me whispers that I’m so desperate to stay relevant that I’m overjoyed by this idea. But even in a world with superhuman AI, we will always look for responsible individuals to imagine solutions, confront them with reality, and run them with confidence.

So here’s my suggestion: next time you start a project, don’t start with a specification. Start with a prototype, iterate until it feels right, and only then capture the spec. Let the code be disposable. Let the judgment be yours.