...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. Nothing came easily to me. Every feature felt like an uphill battle. I can't even count how many hours I spent digging through Stack Overflow. And then there was the stress of PR reviews, where I sometimes got absolutely roasted in the comments (rightfully so!) š
Eventually, things started getting better and better. Shipping features took me less time, and there were fewer comments on my pull requests. Over time, I started handling more complex things, including architecture. I could choose the right solution, explain why a particular tool or design pattern made sense, and defend my decisions.
And I loved being good at coding.Ā Domain knowledge or architectural concerns? Those were somewhere in the background.
Then Coding Stopped Being the Hard Part
The longer I worked as a developer, the more complicated the problems became, and the less they had to do with coding itself.
I stopped getting excited about every new framework feature. In fact, whenever I heard about another "revolutionary" solution, my first thought became something along the lines of:Ā "Yet another state management solution..."Ā (I'll probably write a whole article about that someday.)
Eventually, I ended up where every tech lead eventually ends up: spending most of my time thinking things through, sitting in calls, and getting people to agree on things, while handing coding tasks to juniors and mids.Ā Much to their delight, actually, because they're happy to get a chance to learn something new.
Fortunately, I still code quite a lot, but these days it's usually the more horizontal stuff or the technically difficult features.
And that's exactly the point in my career when the AI revolution arrived.
And I Welcomed AI With Open Arms
I was genuinely happy about it!Ā I'm not crying over the fact that I no longer have to handcraft every precious little piece of artisanal code myself.Ā I didn't particularly want to anyway.
@nazar-boyko recently asked in his article, "Has AI Made You A Lazier Developer? Be Honest."Ā I answered honestly: no. Quite the opposite.Ā AI has made me less lazy.Ā I do more because I don't have to spend as much time on the most boring part: writing redundant code.
And in my opinion, AI is already better at shipping code than most software developers.
There is actual research behind this, some of which I've linked at the bottom of this article, so you can check that I'm not just making things up. šĀ The research shows that AI can dramatically accelerate coding and that frontier AI agents can already complete some coding tasks that would take humans days or even weeks.
And we often see this in our own work.Ā AI doesn't get tired. It doesn't get stressed. It doesn't get distracted. It doesn't have a "bad day."Ā (Okay, sometimes I swear it does )
Not All Developers Are Equally Good at Coding
And let's face another uncomfortable truth: there are better and worse developers.
I know that's not particularly pleasant to say, but it's simply true.Ā Some people are better at cooking. Some are better at singing. Some are exceptional at coding.Ā And some are... a little less exceptional.
Sometimes I get the impression that here on DEV, we treat programmers as some kind of meritocratic class of geniuses. As if every developer, by definition, possesses an extraordinary set of irreplaceable skills.Ā But everyone who has spent enough time in this industry knows that's simply not true.
And AI might actually level the playing field here.Ā A developer who isn't an exceptional coder but is responsible, understands the product really well, makes good decisions, and knows what needs to be built can now go incredibly far.
But There's One Tiny Little Detail
There's just one small, tiny detail.Ā Something we intuitively understand, and something the research I've linked below also hints at:Ā The further the job moves away from simply generating code, the less spectacular the machine's advantage over humans becomes.
In an older study, experienced developers actually worked SLOWER when using AI.
More recent results suggest that newer AI tools probably do speed them up, but the effect is nowhere near as straightforward or spectacular as the raw coding benchmarks might make you think.
In general, the more the work depends on experience, judgment, coordination, and higher-level decisions, the less useful "how fast can this thing generate code?" becomes as a measure of productivity.
And I know exactly why.
Five Minutes of Coding. Four Days of Engineering.
Recently, I had to introduce a change to an application that would probably take a coding agent ā even a not particularly brilliant one ā about five minutes to implement.
So what was the problem?Ā Discussing WHAT that change should actually look like, coordinating it with all the teams involved, and agreeing on the final solution with the client took FOUR DAYS.Ā During those four days, the decisions changed several times.
And let me add something important here: having a developer in those meetings, and preferably an experienced one, was absolutely necessary.
The implementation took five minutes.Ā Figuring out what should be implemented took four days.Ā And that is exactly the difference between coding and software engineering.
Coding Is Becoming Cheaper. Engineering Isn't.
See what I'm getting at?Ā AI is taking repetitive, derivative work off our shoulders.Ā It does that work faster than we do. Often better than we do. It doesn't get tired while doing it, and it doesn't get stressed.
And because of that, the skills the market needs from developers are shifting.Ā If all you can do is code, and an agent can now do that faster and better, you might soon have a problem on the job market.
But if you feel like an agent can do the work you used to give to your junior developers, while you still have to guide it by the hand when it comes to details, architecture, trade-offs, and all the weird little realities of an actual production system,Ā you're in a very different position.
Mine, for example, generated a dropdown today that was permanently open and literally couldn't be collapsed. š¤£
If you understand the bigger picture, know how to make technical decisions, understand the product, and aren't afraid of innovation, your job is probably safe.
At least for now. š
So yes, AI getting better at coding doesn't make software engineers less valuable. It makes coding itself less valuable as a software engineering skill.
BTW if you liked this post, you can also follow me on LinkedIn.
Further Reading & Research
METR https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
METR https://metr.org/blog/2026-02-24-uplift-update/
METR https://metr.org/blog/2026-04-10-mirrorcode-preliminary-results/
Top comments (191)
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. š
Iām only replying now because I actually had to think about this one. But yes, I think your argument makes a lot of sense.
In a way, weāve already seen something similar happen with websites and really small applications. There was a time when you would hire a software company to build something relatively simple. Then we got templates, CMSs, no-code/low-code tools, SaaS products, and so many ready-made components that the nature of that work completely changed.
It didnāt mean companies suddenly stopped needing websites or internal tools. They just stopped needing an entire traditional software team for many of them. Instead, one person who understands the problem and can work end-to-end can sometimes deliver the whole thing. So yes, I can absolutely imagine AI pushing much more software development in that direction.
BUT! š Thereās another thing I keep thinking about.
When I look at whatās happening in agentic development right now, I sometimes wonder whether good old-fashioned software engineering has simply moved there, at least temporarily.
Weāre suddenly dealing with nondeterministic systems and trying to figure out, almost from scratch, how to make them reliable, observable and safe. How do you evaluate an agent? How much autonomy do you give it? How do you deal with unpredictable tool calls? How do you design guardrails and permissions? How do you recover when it does something you didnāt anticipate? How do you build a system around something whose output you cannot fully predict?
That feels very much like engineering to me. š
And then, of course, someone still has to train and optimize the models, build the infrastructure, work close to the hardware, optimize inference, etc. Interestingly, AI can sometimes help much less at the very edge of these areas simply because there isnāt enough existing code, documentation, or training data for it to reproduce established solutions.
So perhaps there are two things happening at once: a huge amount of āordinaryā software development is being absorbed into broader end-to-end roles, while the frontier keeps creating new engineering problems that require highly specialized engineers.
Maybe software engineering isnāt disappearing at all. Maybe the boundary of what we consider āreal engineeringā is just moving again. š
What do you think?
Yes ā and I think this is where I actually agree with you quite strongly. š
What you describe around agents is absolutely engineering. Making delegated processes reliable, observable and safe is a real engineering problem.
Iām just not entirely convinced by the ānondeterministic systemsā part. š
Weāve actually been dealing with systems that make context-dependent decisions from imperfect information for quite a while. Minolta was already using fuzzy logic in the Dynax 7xi back in 1991, for things like autofocus and exposure. That was quite a revolution at the time.
The camera didnāt need deterministic certainty about the scene. It combined several imperfect signals and used them to make a decision that was good enough for the overwhelming majority of situations.
And I think that distinction matters.
The goal of a reliable AI system doesnāt necessarily have to be making the AI itself deterministic or āalways rightā. The goal is to make the process around it reliable.
The AI can propose something, make a decision, call a tool or generate an implementation. Then deterministic parts of the system can check the result against strict rules, invariants, permissions, expected states, tests, schemas, and so on.
If the result doesnāt satisfy those constraints, we reject it, retry, fall back, or involve a human.
So Iād put it roughly like this:
The AI doesnāt have to be reliable by itself. The system in which we allow it to operate has to be reliable.
And that actually brings us back to the arbitration idea.
The interesting engineering question becomes: where do we allow probabilistic decisions, where do we impose deterministic constraints, and where do we require human validation?
An agent can be extraordinarily good at finding a solution without being trustworthy enough to execute that solution unchecked.
Which also makes your last point even more interesting. Maybe the new engineering frontier isnāt really āengineering nondeterministic systemsā, but engineering reliable systems around components whose outputs we cannot fully predict.
And once we get good at doing that, I suspect AI will start helping us engineer those systems too. š
So yes: absolutely engineering.
Iām just not sure the frontier stays there for very long. š
Thank you so much for this comment, Pascal! There are actually a lot of nuances here, and this is going to be genuinely useful for the talk Iām giving on Thursday. š
Iām talking about WebMCP, which, as we know, is still very early. And because Iām always terrified that conference Wi-Fi will fail exactly when I start the demo š, I built a Chrome extension that can use not only cloud Gemini, but also local models as alternative providers.
And playing with that made your distinction very tangible to me. Itās not necessarily that the whole system suddenly becomes nondeterministic. Itās that we introduce a component whose output is probabilistic, and then we have to engineer the system around that fact.
You can see it immediately when switching models. The local models can behave completely differently from Gemini Flash for exactly the same task. One model might decide to call one tool, while Gemini decides to call four. And once you add consequential actions into the equation, this becomes much more than an interesting implementation detail. š
So yes, I completely agree with you that the application around the model can still be deterministic. In fact, thatās exactly the engineering problem: deciding what the model is allowed to decide, what we validate deterministically, when we reject or retry, and when a human needs to approve an action.
Where Iām perhaps slightly more optimistic is how long this particular frontier will stay interesting. š I think weāll be engineering systems like this for a while yet. Iām not saying 50 yearsā¦ but could you please give us at least 10 before AI takes this one too? š
What do you think?
Your Gemini vs local models example actually makes me wonder about something. š
The fact that different models can choose completely different tool calls for exactly the same task isnāt necessarily a problem. If they take different paths but reliably reach the same expected result, then from the applicationās point of view, who cares?
But that āreliablyā is doing a lot of work here. š
Because if the model is given predefined criteria and the result is supposed to follow those criteria, Iām not sure we should let the model make the final decision at all.
Take a simple example: āFind me a product under ā¬100, available for delivery before Friday.ā
The AI can be useful for understanding the userās request, translating it into structured criteria, and deciding which tools are needed to retrieve the relevant information.
But once we have the data, checking:
price < ā¬100 AND delivery_date <= Friday
isnāt really an AI task anymore. Itās a rule.
And that distinction becomes important when you switch models.
If Gemini calls four tools and a local model calls one, but both produce the same valid result, fine. Different strategies, same outcome.
But if you give them the same criteria and the same underlying data, and one model selects A while another selects B ā or even the same model makes different choices from one run to another ā then you have a very different problem.
Especially if selecting A or B triggers a consequential action.
At that point, I start wondering whether weāre introducing probabilistic decision-making where deterministic decision-making would actually be more appropriate.
And thatās where Iām still somewhat skeptical about WebMCP, to be honest. š
I can absolutely see the value of giving an AI access to application capabilities. Iām just less convinced that giving the model more freedom to decide how to use those capabilities is automatically better.
Sometimes I think the architecture should be much closer to:
AI interprets the intent ā deterministic code applies the rules ā AI can explain or communicate the result.
Rather than:
AI interprets ā AI reasons ā AI decides ā AI acts.
The first model still gives us plenty of room for AI. It just doesnāt ask the AI to make decisions that can be expressed more reliably as explicit rules.
And this is perhaps another part of the arbitration problem weāve been circling around.
We keep asking:
āShould the human or the AI do this?ā
But there is a third answer that I think we sometimes forget:
āNeither. This should just be deterministic software.ā š
Thatās actually what I find most interesting in your WebMCP example. The challenge isnāt only deciding how much autonomy to give an AI. Itās deciding which decisions deserve autonomy in the first place.
And that may be an even more important architectural skill in an AI-heavy world: knowing when to use intelligence, when to use rules, and when to keep the human in the loop.
So yes, Iām still giving you your ten years. š
But I reserve the right to spend those ten years arguing about which parts of the system should actually contain AI in the first place. š
Hahaha Pascal, I think Iāll have to come back to this one after the weekend. š You keep leaving me comments that require me to actually sit down, think properly, and write a decent answer. š
At this point, Iām starting to suspect the discussion under the article might be better than the article itself. š
Hahaha, Iāll take that as a compliment. š
But no, I donāt think the discussion is better than the article. The comments enrich the article without replacing it. Theyāre where we can take an idea, push it a bit further, challenge it, and sometimes discover something neither of us had quite formulated yet.
And without the article, there wouldnāt be a discussion in the first place. š
So Iād say the article starts the conversation, and the comments let it grow.
Which is probably what a good DEV article is supposed to do. š
And donāt worry, Iāll let you enjoy your weekend before giving you something else to argue about. š
What a long and interesting conversation!
Iike it's even more valuable than the actual article itself lol, learnt so much from it
@pascal_cescato_692b7a8a20 okay, I finally had time to read this properly! š
I think there are two aspects Iād point out here.
First, most of our web applications are deterministic by nature ā and thatās exactly what we expect from them. We click a button, submit a form, apply a filter, and expect a predictable result.
In its simplest form, WebMCP doesnāt necessarily have to change that. It can just make interacting with those deterministic capabilities easier.
For example, imagine you want to submit a complicated support ticket. Today, we can already complain to an AI about something and ask it to turn our rant into a polite email āso we donāt offend the client.ā š With WebMCP, the same AI could potentially translate that into a properly filled support form instead. Then we review it and decide whether to submit it.
And here, as always with generative AI, a lot depends on the model and the prompt. The results will vary. Sometimes it will be brilliant, and sometimes youāll look at it and think: āI could have done this faster and better myself.ā š
So generative AI will remain generative AI. The underlying application can still be perfectly deterministic while AI is simply another interface for interacting with it.
At least until somebody opens the gate a little too wide and gives the AI far more capabilities and autonomy than it should have ā which, of course, someone absolutely will. š
So Iām pretty sure pentesters will have plenty of work to do. š
Yes! Now I think weāre getting very close to the same picture. š
Your support-ticket example is actually where I find WebMCP much more convincing.
If the application already knows how to create a support ticket, then the AI can simply become a much more natural interface to that deterministic capability:
human intent ā AI translates it ā deterministic application ā human reviews ā action
That makes a lot of sense to me.
The important distinction, I think, is between using AI to navigate a deterministic system and using AI to replace the deterministic logic of that system.
In the first case, Iām quite happy with the variability. If Gemini and a local model structure my angry rant slightly differently but both produce a correct ticket that I can review, no big deal. š
In the second case, though, I start getting nervous. If the model is deciding whether a refund should be issued, which account should be modified, or whether some business rule applies, then Iād much rather have deterministic code make that decision ā with the AI helping before or after it.
And that probably brings us back to the same arbitration problem again. š
The interesting question isnāt only āhow much autonomy do we give the AI?ā
Itās also:
āWhich parts of the system should never have been delegated to the AI in the first place?ā
And yes, I have absolutely no doubt that someone will open that gate far too wide. š
Which is probably why the pentesters are going to have a very entertaining decade. š
I think youāve captured the key design boundary really well. š
For me, the most interesting future pattern is not āAI replaces the application logic,ā but āAI becomes an intelligent orchestration layer around reliable systems.ā
The application should still own:
The AI should help with:
A good architecture is probably:
User ā AI reasoning layer ā deterministic APIs/services ā validation layer ā human or automated approval ā execution
The AI becomes powerful because it can interact with many systems, but the systems should still maintain control boundaries.
I also think the biggest security challenge will not only be model accuracy. It will be permission design.
For example:
āCreate a support ticketā is low risk.
āApprove a $50,000 refundā is a completely different category.
The question becomes:
What capabilities can the AI call?
Under what conditions?
With what level of autonomy?
And how do we audit every decision?
Thatās where I think AI security, evaluation, and agent observability will become extremely important.
And yes, I agree pentesters are going to have a very interesting decade. š Prompt injection, tool abuse, data leakage, and excessive agent permissions are going to become major attack surfaces.
I think weāre very much on the same page. š
Iād only add one small distinction: even the āAI orchestration layerā doesnāt necessarily need to be AI.
Sometimes the orchestration can be deterministic too, with the AI simply translating human intent into a structured request that the application can then process according to its own rules.
And I think thereās one layer missing from the diagram:
Who decides that this is what we should be doing in the first place?
Thatās the part I keep coming back to. š
The AI can understand the request, find information, suggest actions, orchestrate tools, and even prepare everything for approval. The application can enforce the rules and permissions. A human can approve consequential actions.
But none of those layers necessarily answers:
Why are we doing this? Is it actually worth doing? Is this the right priority?
Thatās where I think the human role becomes particularly interesting ā not because AI canāt reason about those questions, but because someone still has to define the objective, the constraints and ultimately take responsibility for choosing it.
And I completely agree about permissions. The difference between ācreate a support ticketā and āapprove a $50,000 refundā is exactly why Iām increasingly thinking about AI less as an autonomous actor and more as a component whose capabilities have to be deliberately bounded by the architecture around it.
Which brings us right back to the question that started this whole rabbit hole:
For this particular task, in this particular context, who ā or what ā should actually be allowed to do it? š
And yes, Iām still betting on a very busy decade for pentesters. š
Exactly. I think the key shift is moving from āwhat can AI do?ā to āwhat should AI be allowed to do?ā
AI can accelerate understanding and execution, but humans still need to define the goal, constraints, and responsibility.
The best systems will probably be the ones where AI is powerful but intentionally bounded. That balance between capability and control will define the next generation of AI engineering. š
Exactly.
And I think there may even be one question above that:
What is actually worth doing in the first place?
AI can help us understand, suggest, orchestrate and execute. Deterministic systems can enforce rules and constraints. Humans can approve important actions.
But someone still has to decide the objective, the priorities, and whether solving this particular problem is worth the effort at all.
So perhaps the progression becomes:
What can AI do?
ā What should AI be allowed to do?
ā What is worth doing, and who should do it?
Thatās probably where architecture, engineering, governance and human judgment all meet.
Absolutely. I think that is the layer where engineering meets product thinking and responsibility.
The biggest risk with AI is not that it cannot solve problems it is that we become very efficient at solving the wrong problems.
The future skill is not only building smarter systems, but asking better questions:
Why are we building this?
Who benefits?
What constraints matter?
What should remain human-driven?
AI can amplify decisions, but humans still need to define the direction.
Exactly. š
And I think thatās probably the part of this whole discussion I care about most.
Weāre getting extremely good at making things possible. AI is going to make that even cheaper and faster.
Which makes the question āshould we do it?ā increasingly more important than ācan we do it?ā
Otherwise, weāll just become incredibly efficient at producing things nobody actually needed. š
And I think thatās a pretty good place to leave this rabbit hole before we accidentally turn the comment section into another article. š
Exactly. š I think thatās the key shift from engineering capability to engineering judgment.
AI will continue lowering the barrier to building things, but the hardest part will remain identifying the right problems and creating meaningful solutions.
The best engineers wonāt just ask, āCan we build this?ā Theyāll also ask:
āWho does this help?ā
āWhy does it matter?ā
āWhat is the simplest responsible way to solve it?ā
Being able to build is powerful, but knowing what is worth building is where real impact comes from.
Great discussion definitely a rabbit hole worth exploring. š
The AI wrote the code in 5 minutes.
Then I spent 4 days explaining to it why we absolutely cannot put the database in production.
Software engineering: 10% coding, 90% preventing the coding from becoming a crime scene.
Hahaha, this is beautiful. š Iāve definitely had a few moments where, if I had just blindly shipped what AI generated, Iām pretty sure I would have ended up in prison. š
āPreventing the coding from becoming a crime sceneā might actually be the most accurate definition of software engineering Iāve seen lately. š
I am beginning to notice this a lot about AI generated code, it's one reason I have decided that there were certain things you don't just give AI, just do it yourself
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.
I really like this approach. It feels very mature, especially the rule: āIf I couldn't maintain it without the tool, it isn't finished.ā
But listening to people in the industry, Iām afraid your prediction might be exactly where weāre heading: companies becoming increasingly dependent on AI and engineers gradually losing track of what the systems they maintain actually do.
And thatās still the better scenario when experienced engineers are involved and can recognize when something is going wrong. Iāve already heard stories about applications that became almost unusable just seven months after being built because stakeholders insisted on shipping them quickly with AI. š
So yes, weāll see. Iām very curious what all of this looks like in a few years. Interesting times ahead. š
Thanks, glad that rule landed š Honestly it's the only one I trust myself to actually follow. š
Legacy code used to take years to reach the point where nobody wants to touch it. If that's down to months now, then we didn't just speed up the building, we sped up the rotting at the same rate. And considering that at work, any AI request I make (even something as simple as changing a button's color) immediately clogs up 80% of a 1-million-item context due to all sorts of features like RAG and rules, I think things are going to get interesting soon š
And you're right that the experienced engineer case is the good one. What makes it hard to catch is that these projects usually work at first. Nothing looks wrong on day one, so there's no warning until someone needs to change something and finds out that nobody can.
Interesting times indeed. I'd settle for being wrong about the pricing part. š
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.
I think we all slowly have to get used to dropping the term "software" from "developer", "engineering", "architecture", or whatever, and replace it with "system". Software is simply a tool we use to materialize the systems we specify, and it will soon be the exclusive domain of machines.
Humans will be responsible for and in control of intent. This requires a different mindset and skill set than most of us have acquired over the years in the software industry.
Honestly, it felt good to be on top of the world while software was eating it, but all good things must come to an end. Now the revolution devours its children.
Time to adapt and climb up the abstraction ladder.
I really like this shift from āsoftwareā to āsystemā. It actually captures the direction weāre moving in surprisingly well: climbing higher up the abstraction ladder and focusing more on intent, constraints, architecture, and outcomes rather than the implementation itself.
And yes, I also think it was pretty nice being a software developer while software developers were ruling the world. š But I suspect that era was slowly coming to an end even without AI. The market was gradually maturing and becoming more saturated anyway. AI is just accelerating the transition dramatically.
But wellā¦ whatever we managed to earn while the good times lasted is ours to keep. š¤£ Time to adapt and climb that abstraction ladder!
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.
ššš
Hahaha, oh yes, there absolutely were. š
Thank you so much, Sylwia, šfor this meaningful article! Your effort in simplifying such complex and important topics is truly appreciated. You perfectly captured the real difference between "coding" and "software engineering" with the "5 minutes vs. 4 days" example. Wishing you more success and creativity. Keep up the wonderful work! šš§š»š
Aww, thank you so much! š Iām really glad you enjoyed it and that the ā5 minutes vs. 4 daysā example resonated with you. Thank you for such a lovely comment! š
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. š
Some comments may only be visible to logged-in visitors. Sign in to view all comments.