๐Ÿ‘ฉโ€๐Ÿ’ปThe dev is dead, long live the dev! ๐Ÿง‘โ€๐Ÿ’ป

๐Ÿ‘ฉโ€๐Ÿ’ปThe dev is dead, long live the dev! ๐Ÿง‘โ€๐Ÿ’ป

2026, Aug 01    

๐Ÿ‡ซ๐Ÿ‡ท Vous trouverez la version franรงaise de cet article ici ๐Ÿ‡ซ๐Ÿ‡ท.

๐Ÿค” Yet another article predicting the end of the dev job?

Is this the umpteenth article where the author gazes into their crystal ball and predicts that the dev job is over and that you'd better start thinking about doing something else ๐Ÿค”?
No, well, not quite ๐Ÿ˜Š.
Almost a year ago, I tried to put words on my relationship between generative AI and the (my) dev job in this article. Let me once again take a look at the impacts of AI on our job. Of course, this is only my own view and I don't claim to hold the truth nor to have a better crystal ball than anyone else ๐Ÿ˜….

โœŠ All resistance is futileโ€ฆ really?

I'm afraid that, as I write these lines, wanting to fight the rise of generative AI in the development world is complicated. Not that it's no longer possible to write code without AI. No, that, just like since the very beginning of our job, and despite all the changes, coding the old-fashioned way has always been and will always be possible. When I say old-fashioned, I mean a more or less advanced editor and manually producing your code in a digital way (aka with your fingers ๐Ÿ˜‚).

The fight I'm talking about is the one on the job market or inside the company.

Today, looking for a developer job and not wanting to do AI, or not mentioning that you know how to use AI-based code generators, is a stance that seems to be a deal breaker. I'm not saying it's good or bad, just that you have to adapt. Just like 30 years ago when we had to adapt to the emergence of the Web, or 20 years ago with the smartphone. The people who stayed on the minitel didn't necessarily survive in the development world.

It's the same inside the company: nothing forces you to use AI (at least if it does, ask yourself some questions) but in the end the context does force you to (more or less strongly). The train (and not just SAFe) is on its way, and the frenzy of wanting to ship more and more features to production, as fast as possible, doesn't always leave you a choice ๐Ÿฅบ.

The massive investment made by our companies means expectations are enormous: in our leaders' imagination we've gone from a x10 dev to a x100 one ๐Ÿคช. We're seeing new roles or jobs emerge, such as Product Engineers or developer PMs / POs.

So yes, fighting this trend isn't impossible, but it's risky for our careers.

So, are we resigned, do we have no choice left ๐Ÿฅบ?

It's not so much a matter of choice as of evolution. Let me go back to the cabinetmaker comparison I used in my previous article. Were cabinetmakers forced to move to tooling and to automating their craft?

Yes and no.

Yes for those who wanted to make a living out of it, to make sure the end-of-month bills got paid ๐Ÿงพ. That took nothing away from their love of the craft, it was just done differently.

No for those who kept doing it as a hobby, by hand, or who simply chose to stay in that niche to turn it into a quality and expertise selling point. Risky, but it works in some cases.

So my opinion, compared to my previous article, hasn't changed that much. Rather than fighting, I'd rather talk about adaptation, change and evolution.

โœจ At the expense of passion and creativity?

That was the big question, and my point of view has evolved somewhat, but not that much. We're changing era: we were in the era where many people chose this job out of passion, out of desire, and less out of necessity or opportunity.

AI isn't going to change that perspective, in my opinion: those who are passionate will remain passionate and will come to this job for everything it brings ๐Ÿคฉ. On the other hand, yes, new profiles are going to show up, people who see code as a tool and not as an end in itself. Is that bad? I don't think so. Those two visions just need to coexist, without either side trying to convince the other that their vision is the best one. They may even be complementary if they're used well.

In many cases AI has allowed people, until then limited by their knowledge, to create (or rather generate ๐Ÿ˜Š) an application. Is it bad to have done it without being an expert in development ๐Ÿค”? No, I don't think so, what matters is what you do with it. And in that respect, whether it was created by a dev or by AI makes no difference.

Is it bad to use a 3D printer to create an object when you don't master how to manufacture the parts and assemble them? I don't think we asked ourselves the question in those terms for 3D printing, for example.

โœ… So what about quality? Is it the big loser?

That's certainly the argument you hear the most: AI generates applications of mediocre quality ๐Ÿ—‘๏ธ. But before knowing whether an application is of good or bad quality, you have to define what you mean by a quality application. For a very long time, we defined an application as being of good quality because it was well written, had tests, was easily maintainable, scalable, ... ๐Ÿ“‹

Building a quality application, at least with those criteria, has never guaranteed that it would be perceived as such by its users. A well-written but badly designed application will be perceived as poor quality. And the opposite can be true: a badly written but well thought-out application for its users will be perceived as high quality by them.

As we can see, quality is subjective. Sure, if the application is well built, it will be easier to evolve, to deployโ€ฆ โœจ,

But when you buy a piece of furniture, do you want it to have been designed and built with all the best practices and hand-made tools by expert cabinetmakers, or simply that it meets your needs and lasts over time? You don't take the furniture apart to see how it was built and validate that everything was respected before buying it; as a general rule you rely on how it looks and on using it.

Applications generated with AI (in whole or in part) can very well have the same definition of quality: that the people using them have the best possible experience. How it was built isn't their concern.

So yes, we hear a lot of things about maintenance, bug fixing, securityโ€ฆ, and it's true. But in the end bad applications won't be used and good ones will, whether they were generated with AI or not.

Fanny Klauk talks about it very well in her talk Dev et Ops des clients comme les autres. Whether it's for an internal or an external application, making sure the application meets what users expect is the first and essential building block to build customer loyalty. I'll let you go watch the replay, through the prism of this article (which isn't Fanny's original one), but I think almost all the notions she covers on the tooling and applications side apply here.

So no, quality won't be the big loser. It will certainly be different from what we knew and were used to doing. But was 100% code coverage really a sign of an application's quality?

Isn't it time to include user perception in how we assess quality?

๐Ÿ› ๏ธ What if it were just the automation of our job?

One of the big mistakes, I think, in how generative AI is perceived in software creation is not seeing it as a tool like the other tools in our design chain. An overpowered tool, sure, but a tool ๐Ÿ—๏ธ.

Maybe one day there will be no need for any human to create software from A to Z, but for now that's not the case โœ‹. We have plenty of examples in industry of jobs where automation hugely transformed the way things are done. Some jobs saw a more than major decrease in workforce, others transformed... some disappeared ๐Ÿ˜ข.

So yes, for once, we find ourselves facing what we've been doing for so many years: automating tasks through machines to replace / improve repetitive and sometimes tedious human actions. Doesn't that remind you of something ๐Ÿคจ?

And like every job that transforms, that goes through automation, it's scary and the transition phase is more or less brutal for the people already in place. I love developing, so I consider myself lucky to have known the period when you had to develop everything yourself (maybe some of my generation don't share that view, by the way). But for the generations to come, it will seem incongruous to learn that there was a time when you had to spend that much time and have that much knowledge to generate a simple web application handling user data ๐Ÿ˜‰.

As I was just saying, it's the switch from one mode to the other that's going to create friction with people like me who will have a hard time moving on. Certainly like every job that went through heavy automation. They didn't disappear, they just evolved, they transformed ๐Ÿฃ. And so did the people: a farmer in 2026 doesn't have at all the same profile as a farmer in 1906. And yet we still call them a farmer ๐Ÿšœ.

That's what's likely to happen to the dev job: we'll still call it a dev, but it won't quite be the same job anymore.

๐Ÿ‘ฉโ€๐Ÿซ And what about our new graduates?

That's another big question in our job. What's going to become of new graduates, they can't find work anymore ๐ŸŽ“. Here again, for me, it's mainly a transition phase: those who started their studies before AI arrived are the ones who will certainly suffer the most ๐Ÿ˜“. It's once more a matter of timing, and on the scale of society it will remain a tiny number of people, even if in the moment it's distressing for those seeing the field they chose transform. The main novelty is that with AI it transforms very (too) fast to sometimes have the time to adapt.

Once AI is fully tamed in the dev job, curricula will evolve, and so will what we expect from a dev. We'll keep learning how all of this works, just like we did at school learning to manipulate logic gates with transistors and current while in companies we were using IDEs and high-level languages like Java โ˜•๏ธ.

Our young people will be adapted to this new way of doing things, it just won't be the same job as what we (and they) are asked to do today.

I'm neither a fortune teller nor a recruitment expert ๐Ÿ”ฎ, but I have the feeling that the real change will be that the development field may no longer be that lucrative, job-guaranteeing field. The development part may only be one subject among many, so you know what happens when you use tools like AI, and no longer a job in its own right. And maybe too, some schools specialized in lucrative career changes (lucrative for whom?) will see their eldorado gradually disappear ๐Ÿ’ธ.

So I can understand that our new graduates are frightened by the change AI brings ๐Ÿค—. In the end, we're living through the same thing, us, the old devs.

But just like for us, the change won't happen without bumps, but once it's done it will be a new way of approaching those studies and that future job.

โ˜ ๏ธ So the dev isn't dead after all?

Yes and no. You may have understood it with this article: I don't claim to hold the truth ๐Ÿ”ฎ. No more than I'm trying to reassure myself or to convince anyone with my own ideas. I'm just trying to share a reflection and maybe reassure you (a little), as I try myself to make sense of these changes ๐Ÿ”€. AI is here and fighting against it seems a risky bet, just like letting yourself be overwhelmed and no longer controlling anything.

You have to accept living with it as a dev, accept doing your job differently, even if it calls into question many habits when you've been doing this job for a long time. Keeping the possibility, for the most nostalgic, of doing it like in the good old days, maybe more as a hobby ๐Ÿ–๏ธ. Or creating a niche market, as there are in many fields, by highlighting the handmade and expertise side (is that viable in our field?).

The expertise will maybe be somewhere else, maybe on architecture choices, deployment or anything else in a software's value chain. And even then, we realize that more and more of our tasks upstream and downstream of software design can be, or are about to be, covered by AI.

Quite simply accepting, without resignation but with clear-sightedness, that the development world as we knew it is disappearing in favor of a new world where development still has its place, but in a different way.

If you made it this far, thanks for reading! If you spot any typos, feel free to open an issue or PR ๐Ÿ˜Š.