...but let me say this right away: coding was never the most valuable part of software engineering.
I remember when I was a junior software dev. N...
For further actions, you may consider blocking this person and/or reporting abuse
I really loved your article. Then again, that’s a bit of a constant with your posts. 😄
Honestly, I think you’re right. AI is already better at coding than many developers, and that inevitably changes the value of the developer’s role.
I also agree with your idea that this pushes developers toward architecture, context, judgment, trade-offs and responsibility.
But, knowing me, you probably won’t be surprised that I think there’s another step hiding behind that one. 😉
The same AI that can accelerate coding can also accelerate debugging, analysis, architecture, testing, documentation, research… potentially every stage of the process.
And I insist on the “can”, because AI isn’t automatically more efficient.
Yesterday, I had a perfectly trivial error: an application told me that the MySQL credentials were wrong. I opened the project, found the relevant file, changed the credentials, restarted the application, and… done.
An AI could probably have given me fifteen possible explanations, asking me to check
.env, permissions, networking, Docker, MySQL configuration, and so on. It might eventually have found the right answer. Or it might simply have turned a 30-second fix into a 10-minute investigation.That’s why I increasingly see AI less as a replacement for a developer and more as another member of the team: potentially brilliant at some tasks, mediocre at others, extremely fast in some contexts and surprisingly inefficient in others.
And just like any other member of a team, it needs human governance.
The human is not only the person who reviews what the AI produces. The human is still the one who decides what needs to be done in the first place.
And that isn’t theoretical anymore. Mozilla is already using AI to analyze and harden Firefox, with AI-assisted work uncovering issues that humans might not have found on their own. That is exactly the kind of task where AI can genuinely be better than developers.
But even then, there is still a question of arbitration.
For this particular task, in this particular context, who should do it: the human, the AI, or both?
A model can be extraordinarily good at auditing Firefox without ever deciding that auditing Firefox is what we should be doing today rather than fixing something else, building a new feature, or doing nothing at all.
Someone still has to define the objective, the context, the constraints and the priorities — and ultimately take responsibility for that decision.
And that’s perhaps where I see the next shift differently.
I don’t think the destination is simply “developers become architects”. Architecture itself can benefit from AI, just like coding, debugging, analysis and almost every other part of the process.
We could continue producing very good software without AI. We’ve been doing it for decades.
AI without humans, however, still has a rather fundamental problem: deciding what is worth doing.
So yes, I completely agree with your starting point: the value is moving away from simply being able to code and toward broader engineering skills.
I just think the next step may be beyond software architecture itself: designing and governing systems in which humans and AI each contribute where they are actually good at contributing.
And if AI really can be better than developers at some tasks, that doesn’t make the human role less important. It makes the arbitration of who should do what even more important.
Excellent article, seriously. As usual, you gave me something to argue with. 😄
Thank you so much, Pascal! And I can’t even disagree with you, because I think you’re absolutely right. 😄
Even architecture is largely based on known patterns. Sure, AI is still hit-or-miss with some of it today, but there’s absolutely no reason to assume it has said its last word here.
And I completely understand your credentials example. 😂 Some time ago I wanted to make a tiny CSS fix and, out of pure laziness, prompted an agent to do it. It immediately started searching through the entire application and burning some ridiculous number of tokens. At some point I just stopped it because I realized I could make the change myself in five minutes. I’m still not sure the agent would have finished by then. 😂
And actually, this is increasingly how I experience my own work: talk to this person, decide that thing, understand the context, figure out what should happen, decide what to delegate to AI and what is easier to just do myself. So I really like your idea of arbitration between humans and AI.
The other interesting question is what this does to the job market. If we soon need far fewer people who are primarily “code craftsmen”, while at the same time the market has become saturated with developers over the last few years, software development might simply become a much more ordinary profession.
I don’t know what it looks like in France, but in Poland being a software developer has been an exceptionally good career for quite a while: high salaries, lots of opportunities, very strong demand. I suspect that might normalize. It won’t disappear, of course. It may simply become a job like many other good professional jobs, rather than this unusually privileged position it has occupied for the last decade or so.
And here I have to disagree with you a little. 😁
I’m not sure software development will simply become a more ordinary profession. I think the profession itself may eventually be absorbed into a broader mission and, in its current form, partially disappear.
There are already a lot of developers whose main added value is essentially: “I know how to turn a specification into code.” That is a real skill, but it is precisely the part AI is making increasingly cheap.
I suspect those people will have to move toward reviewing, refining and improving AI-generated implementations: making the code tighter, more efficient, more robust, less generic, better adapted to the actual system. AI can produce a perfectly valid implementation; someone still needs to look at it and say, “Yes, it works, but this is not how we should implement it here.”
And for juniors, I think the disruption could be even more significant.
Historically, we had a sort of progression:
junior → small tasks → bug fixes → understanding the system → senior.
If AI takes over many of those small tasks, there may simply be far fewer entry-level positions where people can acquire that experience on the job.
That means the ability to understand the whole system — not just how to write code, but what should be built, why, and how the pieces fit together — may increasingly become a prerequisite for entering the market rather than something you develop after several years in it.
And this is why I’m not convinced that “developers become architects” is the final destination either.
Architecture can benefit from AI too. So can analysis, debugging, testing, design, documentation… pretty much every layer.
What may disappear is not necessarily the developer, but the idea that “software development” is a sufficiently complete job in itself.
And there’s another side of this that I find particularly interesting.
There is a huge market that doesn’t necessarily appear in the traditional software-development job market at all: companies with a real business problem worth €50k, €80k or €100k to solve, but which have no reason to hire an ESN, build a five-person development team, and run a two-year project.
They need someone who can understand the business problem, model the processes and data, design the architecture, choose what should be built, decide what should be delegated to AI, integrate the pieces, validate the result, and take responsibility for the whole thing.
If AI dramatically reduces the cost of implementation, I don’t think that market disappears.
I think it potentially gets much bigger.
So perhaps the real transition isn’t:
developer → architect
but:
software development → a capability embedded inside a much broader technical mission.
And honestly, that’s the part of this whole transformation I find most exciting.
Because then the question isn’t really whether software developers will become “ordinary”.
It’s whether we will still call them software developers at all. 😄
And yes, I realise I’m once again making your perfectly reasonable article considerably more complicated than you intended. 😂
Loved reading your post, as always...
We all knew the day would come when AI surpasses humans in coding, even though most of us denied it 😅. But again, coding was such a part before where it was kind of reserved, but after AI, it's become accessible to everyone now, and that's good and bad both ig.
But recently, there are just too many vibe-coded apps. The problem with these is not that they are built using AI, but that people can now build and ship something without really understanding what they're building. And honestly, most of these apps probably don't need to exist in the first place 😭.
AI has made coding accessible, but knowing what to build, why to build it, and how to build it properly is still something else entirely.
Oh yes, but I think that’s a whole different problem! 😂 People got so excited about what AI suddenly made possible that many thought: “Great, now I can build an app in a weekend and FINALLY become a millionaire!” Well… somehow I’m still not seeing all those new millionaires. 😄
And the flood of vibe-coded apps is definitely real. The ability to build something was never the same as having a good reason to build it, and now that the barrier to implementation is so much lower, we’re seeing that distinction very clearly.
Funny enough, I recently saw an actual job posting that was basically looking for someone to clean up vibe-coded applications. 😂 Maybe “vibe-code cleanup engineer” is the real profession of the future. 😄
Agreed Even i was offered to clean up vibe coded mess
Once upon the time I was love programming. Now I know that I can build almost anything with artificial intelligence, just in a different way than before, so I prefer to invest energy in areas far from programming, I even pause my hobby programming and instead throw myself into manual renovation work, where AI can provide maximum advice, for example, it can tell me how much a platonic brick weighs. In a significant part of my corporate work, I do the kind of engineering work that you also mentioned, mainly harmonizing information between teams that go beyond individual code bases. So only a part of the teams working on our programs belong to us, but several external companies also join the operation of the program, so the individual steps of the development consist of a complex network of programs that are also poorly documented and not visible from the code base.
Exactly. This is pretty much what working in software looks like now. And I think that’s the difficult part for some people: coding wasn’t just their main skill, it was also the part of the job they genuinely enjoyed and even found relaxing. Recently, I was reading a discussion in a group for women in tech, and several developers were saying how frustrated they are because they used to spend their days coding, while now it’s mostly coding agents, MCP, and supervising AI. And in between they scroll Facebook and wait for the next round of layoffs. 😅
Unfortunately, that’s simply how the world is changing. If you make beautiful dresses by hand, you can still argue that mass-produced ones from factories are worse quality and that craftsmanship has value. With code, I suspect almost nobody will care who or what wrote it as long as it works well. So renovation sounds like a very good hobby for 2026. 😄
The thing is that most software was never that sophisticated or complex to build. And that was even before AI. A dashboard was never hard to build, centering a button or multiple UI elements, is not a rocket science. Building some CRUD API is trivial. The difficult part is to scale these in XMillion users, have a nice UX that your customers not struggle, have nice and engaging content.
But most of those things weren’t necessarily what the average developer would do in their day-to-day work. They were usually responsibilities that fell more to senior or staff engineers, while the rest of us did a lot of the implementation and, yes, the typing.
The value of becoming more senior was that, with enough repetition, you started seeing patterns. You learned to recognize trade-offs, understand when to say no, and explain your reasoning to people who might not have tech background.
And now I’m not entirely sure what “engineering” is supposed to mean anymore, even though I have a computer engineering degree. Is it to say yes or no? Is it to explore and plan features? Explain the trade offs? Is it to scale systems? Or just code review changes, which is without a doubt the most boring part of the job? If we don't code how we do any of the above? If AI takes over more and more of the implementation, what exactly are we expecting engineers to become? Middle managers to a non sentient chatbox?
Yes, this is such a great comment! And I was aware of this problem while writing the article, but I deliberately didn’t go there because I felt it would dilute the main point. And, well… I genuinely don’t know the answer. 😄 This is probably a topic for three more articles on its own.
Of course, nobody is stopping anyone from learning by coding without AI. And I absolutely believe that it will make you a better developer. But then there’s another uncomfortable question: how many of those “better developers” will we actually need?
If anything, the current situation seems to favor senior engineers even more than before. And I can already see mid-level developers struggling with this transition and getting frustrated, because their role can increasingly feel like being a supervisor for AI: give it a task, wait, review what it produced, correct it, repeat. Let’s be honest, that’s not necessarily the most exciting job in the world. 😅
So I’m definitely not going to pretend I know how this ends. I don’t. And I think this question might actually be even more interesting than whether AI is already better at coding.
Yeah, i feel the same. Is even relevant to be a better developer? But if you are not a better developer how you even become a senior one? 😅
Seniors engineers seem to be favored because let's say "they already paid their dues" in learning/coding/engineering. In most companies, seniors/staff didnt even code before AI. They were the thought leaders, shaping the features and the direction. The most pressure with AI is happening to juniors and medior developers, which transform to chatbox babysitters.
Thank you for nice article! 😸
Lately, coding itself has started to move away from my hands, and I spend much more time discussing system design, architecture, and technical decisions.
But it has also made me wonder:
If the design is solid enough, maybe much of the implementation was always just translating those decisions into code.
Actually, this new way of working fits me surprisingly well. I can turn ideas into working software much faster now, and I’m really enjoying that.
I completely agree.
At least for now. 😹
Exactly! 😄 I think the longer you work in software, the more naturally you end up spending time on architecture, system design, trade-offs, and technical decisions anyway. So for many experienced developers, this shift might actually feel quite natural.
And yes… “at least for now” is definitely the important part. 😹 Let’s just hope we can keep adapting fast enough to make it all the way to retirement. 😂
I agree. Coding has been solved, but don’t listen to all the doomer talk on leaving coding. Coding has been solved (I.e the act of converting English to code (tbf, it’s was already on its way to being solved before LLMs)) but software engineering is far from solved. There is objectively more software in the world than “crud in front of db” apps. As long as there is a need for more complex software. Software engineering hasn’t been solved, it’s just more efficient.
Exactly, Daniel! And now that I’m getting more into agent architecture, I can see there’s still soooo much to figure out. 😄 Sure, the code will get written. But someone still has to figure out WHAT should be written, how all the pieces should work together, and how to design the whole thing without causing an absolute disaster. 😂
That’s a very different skill from turning requirements into code, and arguably a much more interesting one.
That’s not a very different skill - It's called as Software Engineering 😀 That's exactly why great engineers are highly paid to do the Systems Design, Build the right architecture and solve the business problems
That really depends! 😀 I agree that this is what software engineering is supposed to be. But I think there was also a huge group of developers whose professional identity was built mostly around coding itself: writing code, shipping features, solving implementation problems. Architecture, system design, or the broader business context simply wasn’t what interested them most. And I think those are the people who feel this shift the most now.
Disaster 🤣. So true but before now there's been disastrous coders.
🏃🏃🏃
The “five minutes of coding, four days of engineering” example captures the shift really well. As implementation gets cheaper, context, decision history and trade-offs become the real bottleneck. AI can generate the solution quickly; knowing which solution to generate is still the hard part.
Exactly! The job is simply changing. The “easy” part is getting automated, while all the messy context, decisions, trade-offs, and figuring out what actually needs to be built are becoming more important than ever.
Exactly. And I think that makes context and decision-making increasingly valuable—not because coding disappears, but because the cost of getting the wrong thing built keeps falling.
"Five minutes of code, four days of engineering" 😅 painfully accurate. AI writes my Lambda function in seconds, it just won't tell me which IAM permissions I'll regret giving it at 2am. Turns out judgment doesn't ship with autocomplete.
Hahaha, exactly! 😂 I’ve been spending a lot of time with WebMCP recently because I have a talk about it coming up soon, and it’s exactly the same story. Generating the code takes seconds. But then you realize that if you don’t want to accidentally create an absolute security disaster, THAT is the moment when you actually have to start thinking. 😄
HaHa, WebMCP sounds like it has the same trap dressed up in a new acronym 😅 Feels like every new AI-coding tool needs a companion talk titled "Congrats, now go audit what it just gave you access to." Would watch that talk.
This reminds me of the performance load tests I ran at my previous company. Honestly, writing the test scripts was the easiest part of the whole thing 😂. The real headache was coordinating with colleagues across different departments.
I had to align four groups: operations, developers, QA and SRE. First, operations needed to provide real production traffic data and performance targets for the campaign. Then I discussed with developers whether the existing architecture could support the load. Next, I worked with SREs to verify if our staging environment mirrored production, and decide where we should run the test.🤣
Only after locking in all those details would I write the test scripts. When the test kicked off, we all monitored the run together. I would never try to carry out a full load test alone, haha.
Hahaha, exactly! 😂 That’s pretty much what the job actually looks like. And then, after all that coordination, decision-making, and figuring things out, you finally get to write the code. Which, depending on the person, is either the most annoying part or the most relaxing part of the whole process. 😄
Exactly! For me, writing test scripts is the relaxing part. After days of aligning requirements and coordinating teams, coding feels like a quiet reward🤣
One thing I think is easy to overlook here is that AI coding ability and AI coding efficiency aren't always the same thing. A model can produce technically correct code faster than a developer, but still take longer overall if it over-analyzes a simple problem or introduces unnecessary complexity. The real productivity gain seems to come from knowing when to give the agent autonomy and when the fastest path is simply to make the decision yourself and move on.
Yes! And actually, some of the research I mentioned in the article showed exactly that pattern: the less complex the task, the better AI performed. As task complexity increased, the results got progressively worse. So in a way, the data confirms something we already intuitively feel when working with these tools. 😄
This is a really interesting perspective. I think the biggest shift AI is bringing to software development is not simply replacing developers, but changing what makes a developer valuable. Writing code is becoming faster and easier, but understanding the problem, making the right decisions, designing systems, and knowing what should be built are still deeply human skills.
Exactly! And I think this is what the job will look like for at least some time. The value is shifting from producing code to understanding what should be built, why, and how all the pieces should fit together. Where it goes from there… we’ll see. 😄
Coding is a what we use to arrive to a goal. But the engineering decisions, tradeoffs, fixes, and overall architecture is still the hardest part of any codebase.
I agree, AI do make code generation faster and even better than some software engineers. But not all generated code hits the final mark. As you said, it takes minutes to generate but days to finalize. I also like that you pointed out that having an experienced developer is a must even with AI.
But then again, it all boils down to discipline (which is true even before AI). Disciplined actions produce great engineers while non-disciplined actions produce what you call the "little less exceptional" in the field.
And if both try and use AI to multiply productivity, the gap becomes way more obvious.
That’s also very true, thank you for this comment! I think discipline is incredibly important here, perhaps even more important than it was before AI.
Generated code can look perfectly clean and convincing at first glance, and that’s exactly what makes it dangerous. If we stop questioning it, testing it, and actually understanding what it does just because it “looks right”, we have a perfect recipe for disaster. 😅
And I agree that AI can amplify the difference between engineers as much as it amplifies productivity.
...but let me say this right away: coding was never the most valuable part of software engineering.
This line really hits the nail on the head.
Exactly! And I think that’s the realization we have to face now. Coding was the most visible part of the job, and for many of us the most enjoyable one, but it was never necessarily the most valuable part.
Thanks for the mention, Sylwia. 😇
I completely agree with all of this and I’d add one thing from my own experience.
When I already know how to solve something, writing the code can take anywhere from a few minutes to a couple of hours. And if a bug shows up later, I usually have a pretty good idea where to start looking.
With AI, the workflow feels different. I still need to read what it generated, fix the parts it got wrong, test everything a few times, and then check whether it quietly broke something somewhere else in the project. That last part is something we rarely include when we talk about how much time AI saves.
Project size makes a huge difference too! On a small project, or an open source project, AI can find a solution very quickly. And even if it changes the design a little along the way, it usually isn’t a big problem. On a large production codebase, it’s a completely different story. There, I find AI most useful for analysis and even that isn’t always correct. A fairly normal task can suddenly consume far more tokens than you expected.
You also end up writing a surprising amount of instructions just to keep it focused: stay within the scope, don’t add functionality nobody asked for, don’t refactor unrelated code, don’t touch files that have nothing to do with the task ect.
And I’m sure this will improve. Analysis will get faster, generation will get better, and models will become more capable. But at the same time, context keeps getting bigger, even for relatively small tasks. Bigger context means more compute, and I’d expect cost to remain part of the conversation too. And that’s really what I meant with the question about laziness. I’m less worried about being lazy and more worried about becoming dependent.
@ale3oula ’s point about having code that works but nobody really understands is the part that stayed with me! Imagine a company building up years of AI-generated code like that and then one day the AI isn’t available exactly when something critical breaks.
So the rule I try to keep is simple. 🙂 If I couldn't maintain it without the tool, it isn't finished. That doesn't mean using AI less, it just means not owing it anything.
The most useful consequence is that senior engineering judgment becomes visible sooner. A model can produce a plausible implementation, but it cannot own the trade-off unless the team has made the constraints, failure modes, and acceptance evidence explicit. That makes architecture and review more valuable, not less.
.
"At least for now. 😅"
Truth.
Hi