2025 was a turning point for many developers in their relationship with AI, with the emergence of agents — and that's probably what we'll remember most.

Of course, we've been talking about AI to the point of exhaustion for 4 years now. I've done a few posts and videos on the subject, but the evolution between early 2025 and early 2026 is now striking.

With this evolution comes a major question: what's the impact on our profession? How do we reinvent it?

Let me offer a press review to explore this question.

The Age of Agents?

In this article, Simon Willison, co-creator of Django and Lanyrd, highlights the major shift of 2025: the year of agents.

With the arrival of flows in Windsurf in late 2024 and Claude Code in February 2025, everything changed. For many of us, we went from simple copy-paste between the web browser and our IDE to complete delegation of code production.

2025 was also:

• The popularization of the term "vibe coding," which continues to divide between misunderstanding and contempt
• The normalization of $200/month subscriptions
• Conversational image generation models like Nano Banana (previously, you didn't iterate — you had to find the right prompt on the first try)
• The beginning of local code models, which I really hope to see develop further

Go read Simon's article — it's much more comprehensive. But the key takeaway is that with these agents, the very nature of our profession has changed, and it's probably not going to stop anytime soon.

A Profession in Transformation

For those — and there are many — who continue not to use AI, or who only use basic autocomplete in their IDE, the wake-up call may be brutal. The profession is undergoing radical change.

I'd recommend reading this article on the topic: "The Inevitable Evolution of the Developer Role" by Smaine Milianni 🇫🇷

Smaine emphasizes the evolution of the role:

$ echo

>

• from execution to direction
• from local optimizations to system-level thinking
• from writing instructions to defining intent

And of course it's uncomfortable, because it seemingly diminishes the prestige traditionally associated with writing code.

$ echo

>

When an LLM can generate boilerplate, implement well-scoped features, refactor safely, review code tirelessly… Then the act of typing code stops being the core differentiator, and that's uncomfortable for many of us.

I say "seemingly," because while the job is changing, expertise and experience remain important differentiators. In the current workflow, I'm still the one giving directives, correcting the architecture, defining the requirements, the problems to solve, and the expected behaviors.

But as yoandev points out 🇫🇷 (translated from French):

$ echo

>

AI demands even greater architectural rigor. Why? Because AI is an amplifier. It magnifies what already exists. If I give it a spaghetti codebase, it will produce more spaghetti, faster. If I give it a clean architecture with clear responsibilities, it becomes a frighteningly efficient surgical assistant. The principle is simple: Garbage In, Garbage Out.

Now, we need to understand that these new practices only emerged in 2025 — the term "vibe coding" itself appeared in a tweet in February! So today, one of the key questions is: "how are we going to industrialize these new practices and make them more compatible with reliable software production?"

The Time for Industrialization

To simplify, my job is now to design and then write what I want to see appear in my application. It's a job of writing, then verification. I need to check that the architecture is correct, that security and performance have been considered, that the model is coherent.

An advanced feature takes me between 2 and 6 hours depending on complexity and my available credits (no, I don't pay $200/month). Some features would have taken me 1 to 2 weeks of work before.

For Chris Loy, software is becoming a commodity:

$ echo

>

Traditionally, software has been expensive to produce, with expense driven largely by the labour costs of a highly skilled and specialised workforce. This workforce has also constituted a bottleneck for the possible scale of production, making software a valuable commodity to produce effectively. Industrialisation of production, in any field, seeks to address both of these limitations at once, by using automation of processes to reduce the reliance on human labour, both lowering costs and also allowing greater scale and elasticity of production. Such changes relegate the human role to oversight, quality control, and optimisation of the industrial process.

But we're only at the beginning, and many are wondering how to make what's produced by code assistants more reliable, which involves:

• Optimizing the number of tokens needed to reduce costs
• Making the documentary sources used by AI more reliable
• Ensuring overall coherence through the use of guidelines
• Guaranteeing conformity between implementation and spec

In short: industrializing.

A few approaches have already emerged, such as:

• BMAD, which offers a complete set of conversational agents to simulate a full team.
• SpecKit, similar in spirit but much simpler.

Having tried both, I didn't find what I was looking for. Sure, BMAD lets you simulate a complete team. But it reminded me of the pitfalls of large corporations. I quadrupled my design time, blew through my credit quota, and the produced specification was far too verbose and complex. I felt like I was doing SAFe with myself. And that's not an experience I'd recommend...

SpecKit is much simpler, but still too verbose for my taste. For a simple feature, it created half a dozen files — PRDs, functional specs, technical specs, etc. That's probably what you want in a large industrial group. It's unsuitable in just about every other context. Too much documentation kills documentation.

It would be a shame to reinvent a profession only to immediately recreate robotized bullshit jobs...

Now, since we're talking about transformation, is this the end of developers or a renewal?

End or Renewal?

This question has come up so many times over the years that it's become a caricature. Until now, the conclusion has always been the same: no.

Because we've had the famous rebound effect — by simplifying usage, we've had more demand for developers.

I tend to moderate this conclusion, which has become too automatic today, and I'm afraid we're settling into a sort of Pavlovian reflex. Yes, the answer has systematically been no, but I invite you to reflect on this article that reminds us of the parallel between developers and weavers of 1811 during the famous Luddite revolt 🇫🇷 (translated from French):

$ echo

>

Here's what we often forget: during the first industrial revolution in England, real wages stagnated for 40 years while productivity exploded. Forty years. Two generations of workers saw their standard of living decline while factory owners got richer.

Yes, there can be a rebound effect, but it can take a long time and not necessarily benefit everyone:

$ echo

>

The World Economic Forum notes that every industrial revolution has created more jobs than it has destroyed. **But **(and this is a big but) the people who lose their jobs aren't necessarily the ones who find new ones.

$ echo

>

Historical research shows that during the second industrial revolution, young workers adapted by switching careers to growing sectors. Older workers, on the other hand, were stuck in devalued jobs or shifted to unskilled positions.

What's certain is that there now seems to be an inevitability to these changes, as Salvatore Sanfilippo, the creator of Redis, reminds us:

$ echo

>

But, in general, it is now clear that for most projects, writing the code yourself is no longer sensible, if not to have fun. (...) you can't control it by refusing what is happening right now. Skipping AI is not going to help you or your career.

Even for Linus Torvalds, the question is no longer up for debate:

$ echo

>

Is this much better than I could do by hand? Sure is.

We find the same observation from Jaana Dogan (Principal Engineer at Google):

$ echo

>

I'm not joking and this isn't funny. We have been trying to build distributed agent orchestrators at Google since last year. There are various options, not everyone is aligned, etc. I gave Claude Code a description of the problem, it generated what we built last year in an hour.

You can find this quote in a Pragmatic Engineer article on the same topic: When AI writes almost all code, what happens to software engineering?.

I could also quote Quentin Adam (CEO of Clever Cloud) 🇫🇷:

$ echo

>

As developers, we should be careful not to turn healthy skepticism into outright rejection of innovation. History shows that many of the biggest leaps in our field came from tools or ideas that were initially dismissed as "dangerous", "lazy", or "not real engineering".

To end on a more optimistic note, I loved this article by Mattias Geniar: Web development is fun again:

$ echo

>

There's mental space for creativity in building software again.

I relate quite a lot to this article. Building an application is hard, but I love building products. Now, I can go much further, and faster. I can focus on what really matters instead of redoing the same boilerplate over and over for 20 years. For me, it's an accelerator, and it completely changes the way I create software. I spend more time thinking, designing, considering the problems to solve — and less time struggling with implementation details. I produce better software, and yes, it's fun.

What Now?

It's hard to say what 2026 will bring when you see how fast everything accelerated in 2025 — especially since we can't really ignore what's happening in the real world and the potential impacts it could have on us. It seems unlikely that we'll voluntarily go back on AI usage, but external events could disrupt things in Europe — for example, if the US cut off our access to certain services, or used them for large-scale industrial espionage.

So perhaps this will be the year of optimization research — making it easier, cheaper, and less energy-intensive to run these agents on local machines. It may also be the year of industrializing LLM usage in companies, but with a clear separation between AI-native companies and the rest. I'll write a more detailed article on this specific topic in the future.

In any case, stay tuned. The profession is changing — fast.