...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
Displaying a subset of the total comments. Please sign in to view all comments on this post.
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?
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. 😂
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.
I don't know maybe it became the hardest part now?
It's funny because I've always been telling people that domain knowledge is super important; that being able to piece things together correctly rather than just being a code monkey is what makes you truly valuable as a programmer, and now AI is showing the whole world exactly that.
That being said though, I can't personally confirm that AI is generally "good" at coding. It has its moments, and it certainly benefits from pretty much having any and all language and library features memorized, but just as often as it knows the exact way to correctly do something within seconds, it writes extremely clumsy garbage.
On its own, AI still kind of sucks at writing code; it's really only good as a tool for an experienced human programmer to fill those knowledge gaps of not always knowing the exact library-function or pattern or algorithm to tackle a specific micro-problem.
I assume this is part of why my experience with AI differs a bit: I've always been very aggressive about abstracting away repetitive tasks; if I found myself writing a lot of boilerplate, I just took that as a hint to build some kind of micro-framework around it.
So the type of code AI is "good" at is just not something I particularly care about anyway, and the abstractions around it are usually something AI still struggles with, because that leads back into the big picture questions: designing a good API that is both expressive and flexible enough.
Aaaw, no free platforms? 🤭
Exactly! And actually, pretty much everything you describe here is consistent with both my point in the article and the research I referenced.
I’ve always been that kind of developer too: looking at the bigger picture, keeping track of what’s happening around the code, connecting things, asking questions, making sure the pieces actually fit together. And I don’t even consider myself some extraordinary coding genius. 😄 I have solid senior-level coding skills, sure, but I would never say that my ability to write exceptionally clever code is what makes me good at my job.
For some people this distinction may seem completely obvious. But I also think there was a large group of developers who considered coding itself to be their special skill, almost their craft and professional identity. There were entire blogs, books and communities built around becoming a better and better coder. So I think this shift can feel very different depending on what part of the job you valued most in the first place.
And hahaha, you absolutely got me with the “no free platforms?” I STILL don’t even have a proper personal website or portfolio, and I regularly feel guilty about it. 😂 Somehow it just never happens. I already write a lot, build things, speak, and generally have too many things going on, so there’s always something more interesting or more urgent than adding yet another communication channel to maintain.
Maybe the new year will finally be the year of the personal website. 😂
I'm kind of half in that group myself; it's just that "Programmer" (as in hobby) and "Programmer" (as in job) are different things to me. My job as a programmer isn't writing clever code or even having domain knowledge; It's making sure stuff happens in the digital domain so the company can be productive, that's it.
What I do in my free time is a different question, but that's also unaffected by AI. Could AI fix a problem in my blog's SSG faster than I could do it by hand? Sure, but I didn't write it by hand because I wanted to be effective, and AI existing doesn't ruin my gun any more than widely used SSGs did before.
Basically: I enjoy coding the same way that I enjoy cooking. And with that attitude, AI can't harm my ego nor take my joy. Even if my job became entirely obsolete, that's an income problem, not a programming problem.
There is more into this topic. AI is now arguably "better" coder than many devs, yes. But it is like spitting out the code all around. Eagerly, but blindly. Without proper supervising, all you'll eventually end up with is mess.
I am "Team AI", but I am seriously worried about this. I am getting awesome results in short-circuit "prompt - result - human review" loops over codebases I am familiar with and with scoped focused tasks ("there is that bug, find the cause and fix it"). It is getting worse with vague broad prompts on poorly dokumented older projects (but still mine). And using it on projects I DON'T know? Where I should relly on its judgement? Erm...
Maybe loosing the grip of the code itself is not essentially bad thing. Afterall, it is like moving from dev to managerial and then having to believe that your team will put it together without you doing all the work. And on the brightside - agents understand and follow instructions notably better than average humans.
But still...the doubts 😬
Exactly! And even some of the research I linked in the article showed the same pattern: the more complex the task became, the worse the agent performed. So what you’re describing matches the data surprisingly well. 😄
And I really like your comparison to managing a team, although there’s one funny difference. With a human team, after a while you know your people. You know who is great at what, who you can give a task to and basically forget about it, and who needs much more guidance and review.
With AI… good luck. 😂 The same agent can do something absolutely brilliant one moment and then confidently produce complete nonsense on the next task. 😅
This has always been a manager's perspective. However, that opinion isn't always true. Sometimes, coding is the most valuable / expensive part of software engineering.
Take one of previous Cloudflare outages, for example. A single
unwrap()in production caused the entire service to crash. This is a good example of what can happen when there is an overreliance on AI tools and developers blindly accept their output without fully understanding or reviewing the code.Another example is my previous work finding vulnerabilities in open-source frameworks such as Dioxus. If the developers had written the code themselves, or, more importantly, fully understood what they were implementing, they might have caught these issues before they made it into the framework.
There are many other cases where deep coding knowledge and hands-on implementation are critical. In some situations, coding is the most important part.
I know, we should adapt AI or left behind. But overreliance is an overkill.
Same. I remember the good ol' days of building React apps and participating in hackathons. It was such a good time.
Have fun 👋🏻!
I’m not entirely convinced by this argument, although I definitely agree with part of it. 😄 Overreliance on AI without understanding or reviewing the output is absolutely dangerous. A pentester friend of mine keeps telling me that she has never had such an easy job as she does in the age of AI-generated code. 😂
But there’s another side to this: not every developer was an exceptional coder before AI either.
If someone blindly accepts a dangerous
unwrap()generated by AI, can we really assume that the same person would have written perfectly safe code without AI? Maybe. But they might just as easily have copied a questionable solution from Stack Overflow, misunderstood some documentation, or simply written the bug themselves.Developers have been shipping security vulnerabilities, production outages, terrible abstractions, and completely broken code for decades. 😂 AI can absolutely accelerate that problem, especially when people use it beyond their own level of understanding, but I’m not sure we can conclude that manually written code would necessarily have prevented it.
So I completely agree with “don’t rely on AI to write code you don’t understand.” I’m just less convinced by “if developers had written it themselves, they would have caught the problem.” Sometimes they would. Sometimes they would have created exactly the same problem, just more slowly. 😄
But in our case, basic error handling should be pretty intuitive for an average / experienced developer; It's really not that difficult. Maybe Cloudflare decided to just use AI instead of hiring an experienced Rust developer.
Absolutely, developers have been shipping bad code forever. My point is that AI doesn't remove the need for experienced developers, it makes proper review even more important. If you're going to use AI to generate / review code, at least have someone who understands the code well enough to read and review it before shipping. Otherwise, you're just accelerating the process of shipping bugs.
Till next time 👋!
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.
I think it mostly comes down to the degree of autonomy and the depth of the work. As an example, Dwarf Fortress. AI today is incapable of adding even a single feature to it. There are codebases so intertwined (for better or worse), that a LLM just cant possibly have the context to make a good edit. That's kinda why with Dwarven Stronghold, I had to completely rework how to even approach the problem, just so I can understand it, let alone a LLM. But that's not necessarily a bad thing... Sure, it cant maintain DF, but it can rebuild it better... Sometimes, I sit back and just look at what AI comes up with and genuinely, it's the definition of KISS (keep it simple stupid), it does complex things, by compounding a bunch of simple things. That's good! It's what we're all told to do to make maintainable codebases and it genuinely makes it easier to understand! Often overlooked, those annoying in-line comments that bloat a file, genuinely explain it in 3 months when you have to go back to review it...
The only time a developer can genuinely claim 'AI makes me slower', is if they're sitting all day to write 10 lines of code. When less is more, AI fails... For now... Every other case, AI beats us all.
I’m actually not so sure about the “AI could rebuild the whole system from scratch, but better” part. 😄
For that to work, we would need an almost perfect specification of the existing system, including all the weird edge cases, business rules, exceptions, and behaviors accumulated over the years. And how often do we actually have that? 😂
Otherwise, AI might absolutely be capable of building the replacement, but we could still spend a year or two rebuilding it only to discover that the new system has dozens of subtle problems nobody anticipated. And then everyone keeps using the ugly old system because, well… it works.
There’s a reason we still have critical systems running on COBOL decades later. Rewriting the code is only one part of the problem. Reproducing decades of implicit knowledge and behavior is something else entirely.
So yes, maybe AI could technically rebuild it. But once again, the human turns out to be the weakest link because nobody wrote the damn documentation. 😂
True, but DF was never perfect, it always had bugs. The difference is the velocity of patching. AI tends to do thorough logging and error handling, so with a canary service to inform the AI when a client hits a bug, it can get the details it needs to patch it faster. It'd still need a bit of time, but it definitely wont take 20 years?
Good perspective. I would put it other way. Taking outcome as the focus, AI provides better coding than most of the developers from quality and speed perspective.
I have recently migrated an application - first Java 1.8 spring boot 1.5 to Spring Boot 3.x keeping the front-end as is, then took the Angular 7 front-end migrated to Angular 21, both without writing code myself. I had to feed with good insight of functionality, keep an eye on details where required, at times, asking to revert the changes. I ask AI to make notes daily on migration covered and once, even asked to write lessons learnt as it took multiple iterations to complete a task. While doing angular migration, once I had to point to legacy code by pointing it to look at a particular line, while agent was arguing that legacy screenshot may from a stale code and the not the reference given.
The outcome is amazingly great, I had put the legacy and new UI side-by-side in staging server, I had to put a header saying it is "new ui", to that extent, I could match the migration. Being a coder for 35 years, I find this AI era is a fentastic time. People, Developers ( Engineers!) can build much more than what they could do otherwise. Overall my experience is - AI Agents are great assistants for experienced developers, it is a guide - to be cautious - for new developers.
This is great, and it matches exactly how I see it! For experienced developers, AI can easily be a 10x multiplier precisely because they already know how to work. They know what outcome they want, what to check, when the agent is going in the wrong direction, and when to simply tell it to revert and try again.
With juniors, I think it’s much trickier. They don’t have that judgment yet, so they can easily get lost following the agent. And there’s another problem: if the agent keeps generating the implementation for them, they may not learn nearly as much from doing the work themselves. Which brings us back to the question of where our future seniors will come from. 😅
And I definitely know the pain of those migrations. 😂 What I don’t understand is why every ancient Angular application somehow ALWAYS needs to be migrated from Angular 7. Was that some kind of golden version that everyone collectively decided to stay on forever? 😂
Two questions - two cents from my side.
First one - where do we get seniors in future - this is a serios concern going to be for sometime. In all parts of the world - there are methods to learn langagues, Databases, Operating systems, but there are no methodical approach to learn application design and development. All great product companies have processes in place that would put sufficient checks and tests - it is more like a operationalized system that manages changes, bug-fixes etc. But the complexity comes in custom applications whether enterprise grade or small business - it needs a person's with functional knowledge, and good insight to existing codebase. We used to say - you work in support role for 2 years, you would know most of the application. But now with AI assisted support - the developer knwoledge would remain same after 2 years as well. Typically 80-20 rule applies, only 20% of the team would be interested to learn, pickup larger perspective from day-to-day work.
Coming to second point why there are older angular applications - the same reasons - there are thousands of custom applications - with minimum support persons around - be it Anuglar 7, even Angular js, Java 1.8 based spring boot, or many PHP applications. In many cases, team or team leaders brand them as legacy - suggest the standard strategy- saying rewrite. Usually not everyone can go through existing codebase easily. With AI around, hopefully there is more courage to migrate legacy applications, enable business with more efficient applications.
Is AI (in general) better than most employable developers? NO
Is Fable better than most employable developers? NO
Is Fable better than most unemployable developers? YES.
🥰
Hahaha, fair enough! 😂 The real problem starts when Fable’s successor arrives and suddenly we’re ALL in the “unemployable developers” category. 😂
No.
Even if a future model becomes better than all human developers combined, we’ll have to put regulations in place to ensure capable humans are taking important decisions, and to ensure economy doesn’t collapse.
If AI replaces everybody then AI replaces nobody, because nobody can afford AI at that point.
Also, you simply can’t solve the actual energy requirement to replace most humans with AI within our life time. There’s a physical barrier that even ASI can’t cross.
So, we’ll be alright 🥰
Hahaha, I think we’ve somehow moved from “is AI better at coding?” to “how do we prevent the post-AGI economy from collapsing?” 😂 But I like your optimism. Let’s hope you’re right and we’ll all be alright. 🥰
We should treat AI just like any other tool.
We should treat it like it is now, NOT what AI CEOs promise it'll become next year.
Will you buy and drive a car now which mostly does well, but crashes once a day, if I promise it'll become the best car ever in a few years? You won't. So why would you treat AI any differently?
Fabel is the best model so far in most things, but it still cannot do even 10% of what I can do, by itself or in the hand of a non-developer. In the hand of a good developer, in some cases it can 10x the productivity. Which means it's not better than anyone - it's just a catalyst.
If you know chemistry, you'll recognize that a catalyst is never better than the reagents. No matter how good a catalyst is, you'll always need the reagents for a chemical reaction to happen. Hence, a catalyst is just a catalyst, it's never better than any reagent.
On a different note, will Fabel X.X become better than the best developers all by itself? Perhaps it will, perhaps it'll not! But even if an AI company succeeds in developing such a future model, I strongly believe we'll do just fine.
Here's a simple reason why: dev.to/fm/youll-not-be-replaced-by...
🥰
In general I agree with your article, or to be more specific, there's nothing in your article I disagree with. The thing that I feel like your article kinda glosses over is how someone becomes good at being a Software Engineer.
You point out a few things that are true:
But there's a problem in this flow, and it's right between 1 and 2. In order to become a good problem solver, you first had to solve the small problems, the problems that the code really is the solution. Becoming a great Software Developer requires you to conquer the Coder step.
The biggest problem I have with the way AI is changing software engineering is, so many companies now have no need to hire any Junior Developers, and this is the danger. The Junior Developers out there never get the chance to go through steps 1 and 2. First of all, they have a hard time getting a job at all because everyone wants lots of experience. Second of all, if they DO get the job, they are expected to jump straight to step 4, they're expected to already be good at what senior developers and tech leads are, because they aren't coding.
Then what happens 10 years from now, when the Senior Developers and Tech Leads start retiring and there isn't a new generation of Senior Developers and Tech Leads rising up to take their place.
Hey Nick, thank you for this comment! This is actually one of the things I keep wondering about too, and honestly, I don’t know what the answer is. 😄
I completely agree that a huge part of the judgment I have today came from years of actually writing code. You don’t magically wake up one day with senior-level judgment.
On the other hand, nobody is stopping people at the beginning of their careers from learning fundamentals and building things without AI, or at least without coding agents doing the implementation for them. Whether people will actually choose to do that when they can generate a working solution in seconds is another question. 😅
And realistically, we’re not going to stop technological progress just to preserve the traditional junior-to-senior career path. The industry will have to adapt somehow.
My suspicion is that “software developer” simply might not remain such a huge and popular profession.
But the question you raise about where the next generation of seniors and tech leads will come from is very real. I genuinely don’t know yet. And I think we’ll be discussing this one a lot over the next few years.
This lines up with something I've noticed too: the actual hard part was never typing the code, it was the judgment underneath it. Knowing what to build, catching the thing that looks fine but isn't, deciding what's actually worth fixing before shipping.
AI compressing the coding part doesn't remove that layer, it just makes it more visible how much of the real work was always there. "Five Minutes of Coding. Four Days of Engineering" is exactly right.
Exactly! But there were also plenty of developers who considered coding itself to be their main skill, and sometimes even the core of their professional identity. And I think those are the people who may struggle the most with this transition. If the part you considered your biggest advantage suddenly becomes cheap and incredibly fast to automate, you have to find a new way to create value. 😅
Agreed!!
I think the most interesting part of this isn't actually whether AI is better at coding than most developers.
It's what happens when AI starts getting better at the things we currently consider "engineering" too.
Today we say: coding can be delegated, but humans still need to handle architecture, debugging, trade-offs, and judgment.
But if agents keep improving, they'll increasingly participate in those activities as well. So the important question becomes less:
"Can AI do this task?"
and more:
"Who decides that this is the right task, under which constraints, with which authority, and how do we verify the result?"
Your "five minutes of coding, four days of engineering" example captures this really well. The difficult part wasn't producing the code. It was establishing the context, constraints, stakeholders, trade-offs, and intended outcome before anyone should write the code.
That's also why I'm interested in the infrastructure layer around coding agents.
I don't think the long-term answer is simply "developers become architects." Architecture itself can increasingly be assisted by AI.
The harder problem is governing the transition from:
intent → decision → authorization → execution → verification → evidence
An agent can be extremely good at implementing a decision and still be wrong about whether it was authorized to make that decision in the first place.
And I think that's where the next generation of AI engineering systems gets interesting: not replacing human judgment, but making the boundaries around human and machine judgment explicit, enforceable, and auditable.
AI making coding cheaper is probably inevitable.
Making engineering decisions trustworthy is the much harder problem.
Yes, I fully agree with this! @pascal_cescato_692b7a8a20 actually raised a very similar point somewhere else in this discussion.
Perhaps we’re simply moving from being software engineers to being system engineers, thinking less about the code itself and much more about intent, constraints, permissions, decisions, verification, and how all these pieces interact.
And honestly, that’s a pretty significant mindset shift. It’s not just “developers using AI to write code faster.” It changes what we consider engineering in the first place.
This is a very interesting take. 👏
I strongly agree with the distinction between coding and engineering.
AI can generate a working implementation in minutes, but production engineering is rarely just about “can we write this code?” It’s about choosing the right problem, understanding the context, evaluating trade-offs, handling edge cases, validating the result, and taking responsibility when things go wrong.
I think the next-generation developer won’t necessarily be the person who writes the most code.
It will be the person who knows:
→ What should be built
→ What should NOT be built
→ What to delegate to AI
→ What must remain deterministic
→ How to verify AI-generated work
→ When human judgment is required
In other words, AI makes coding cheaper, but good engineering judgment becomes more valuable. 🚀
The interesting question is no longer “Will AI replace developers?”
It’s “Which parts of software engineering should humans, AI, or deterministic systems own?” 🤔
Exactly! And I suspect that boundary will keep shifting over the next few years. 😄 Things we consider firmly “human judgment” today may gradually become safe to delegate to AI, while humans move further up the abstraction ladder.
So perhaps the most interesting part will be watching where that line moves, and how quickly.
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. 😄
First of all, they are chat bots mimicing language models, so dont assume they are AI! there is no such a thing according to Alan Turing's definition in "AI and Expert Systems" by Russel-Norvig. Then use LLMs if you are senior as a personal assisstant or team mate, not as a crutch filling speciality gap, also LLMs will will make a junior developer to a jack of all trades, but master of none! and will make your project a primary target for offensive security experts, and if you lack core fundamentals
That’s very true. 😄 If someone already knows what they’re doing, AI can make them dramatically more effective. But if someone lacks the fundamentals and can’t properly evaluate what AI produces, it might not help them at all, and in some cases it can actually make things worse.
And I definitely agree about security. 😂 A friend of mine is a pentester, and she says she has never had such an easy life as she does in the age of AI-generated code. Apparently, we’re generating vulnerabilities at unprecedented speed too. 😂
I agree 100%! Vibecoding makes it possible to separate processes and execute them several times faster than humans could. It’s also worth adding that AI isn't fussy—it will keep working no matter what.
Hahaha, that’s true! 😂 AI won’t complain that the task is boring, refuse to touch some ancient legacy code, or ask why it always gets the worst tickets. 😄
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. 😄
The five minutes of coding versus four days of engineering is the key distinction here. Generating implementation is getting cheaper. Deciding what belongs in the system, resolving trade-offs, and verifying that the result fits the real product are still the harder parts.
Exactly! And honestly, this was already true long before AI. 😄 The implementation was always only one part of the job. Understanding what should be built, making the right trade-offs, and making sure it actually solves the real problem were always the harder parts.
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.
Exactly! The only question is: where are we going to get the next generation of senior engineers from if AI takes over more and more of the work through which people used to gain that judgment and experience? 😅
Unless, of course, the plan is simply to never let the current seniors retire. 😂
Interesting perspective. AI’s progress in coding is definitely impressive, especially when it comes to generating boilerplate code, debugging, and speeding up repetitive development tasks.
But I think the bigger shift is not simply about AI replacing developers. It is about changing what makes a great developer valuable: understanding problems deeply, making the right architectural decisions, and knowing how to use AI effectively as a collaborator.
The future of software development will likely belong to those who can combine human creativity, critical thinking, and AI capabilities together. Great discussion on how quickly this space is evolving.
Exactly! And I’m really curious where all of this eventually takes us, and where the boundary will be. 😄 How much of software development will we ultimately delegate to AI, and which parts will remain fundamentally human? I don’t think anyone really knows yet, and that’s what makes this whole transition so fascinating.
This holds even harder in security honestly. AI will write you an exploit or a scanner script fast, that part's cheap now. But knowing what's actually worth testing, reading a system for where it really breaks, deciding if a finding matters or if it's noise, that's the four days part and AI can't hand it to you. Same split you're describing, the code got cheap and the judgment didn't.
The dropdown that couldn't collapse got me though. Mine hands me confident broken code all the time and it looks competent right up until you actually check it. You still have to be the one who knows what right looks like.
Hahaha, exactly! 😂 Security is a perfect example of this.
And yes, the second part is painfully familiar too. AI will confidently fix the thing you asked it to fix, break something completely different in the process, and then proudly announce that the task has been completed successfully. 😂
That’s why knowing what “right” actually looks like is becoming such an important part of the job.
Great perspective. AI may be better at generating code, but understanding the problem, making architectural decisions, and communicating with stakeholders still require real engineering judgment. The example of five minutes of coding versus four days of decision-making explains this perfectly.
At codecan.net, we also see how AI can accelerate development, but the quality of the final product still depends on the developer’s ability to guide, review, and understand the bigger picture.
Exactly! 😄 A good developer can become even better and dramatically more productive with AI. But if the developer lacks the judgment and understanding needed to guide and review what AI produces… well, AI might just help them create bad software much faster. 😂
One part I think is easy to underestimate is that engineering judgment isn't only about choosing the right implementation, it’s also about defining the boundaries the implementation has to respect. AI becomes much more useful when the problem is framed with clear constraints, acceptance criteria, and system context before asking it to generate anything. That changes the developer’s role from simply reviewing generated code to shaping the problem space the AI is allowed to explore. The interesting shift may therefore be less about “AI writes the code” and more about who defines what a successful solution is allowed to look like.
Exactly! I think this is where the shift is happening. And the larger and more complex the task becomes, the more important those boundaries are. You can give AI much more autonomy, but only if you’re increasingly precise about the space in which that autonomy is allowed to operate. 😄
Agree 💯. One of my relative used to work in tech and always used to tell me that coding is not the hardest part, but problem solving, approaching the problem, implementing the solution along with keeping the tandum with your co-workers(including one's senior and junior) are few of the most imp skillsets, and that was 2-3 years before AI became mainstream. At that point, I dismissed his opinion, but now I realised whatever he told was actually true.
Exactly! I was aware of this long before AI became mainstream too. 😄 Sometimes I even used to feel a little guilty that my career was going so well when I never considered myself some kind of coding genius. 😂
But over time I realized how much value comes from everything around the code: understanding the problem, connecting the dots, communicating with people, taking ownership, making decisions, and knowing when something doesn’t make sense.
And now AI is making the importance of those skills even more obvious.
AI is definately very good at coding, not least because its aware of complete syntax, and a universe of correct coding techniques out there, that individual developers are not aware of depending on their experience. There is another aspect of AI though, that is even more powerful, and valuable than coding - AI is now entering algorithms themselves. Coding logic has AI embedded in it, that affects the algorithm outcomes. Rather than "if else", or "switch" statements, increasingly, it's the AI that decides which code branches get executed. This is something impossible for humans to replicate.
Yes and no. 😄 I agree that this is a fascinating shift: with agents, the LLM can effectively become part of the runtime decision-making logic. It can decide which tool to call, in what order, and with which arguments, instead of us explicitly coding every possible branch.
BUT the important part is that we still shouldn’t let the LLM decide everything. It’s our job as engineers to define the boundaries around those decisions and make sure the user remains safe.
The model can decide which path it wants to take. We still have to decide which paths it is allowed to take, which actions require confirmation, what needs deterministic validation, and what should never be possible in the first place.
So yes, some of the control flow is moving into AI. But engineering the guardrails around that control flow becomes even more important.
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🤣
Exactly! 😂 And now sometimes, after all those meetings, requirements, and coordination, you finally get to the “reward”… write one prompt and watch the agent do it. So much for the relaxing part. 😅
AI is getting remarkably good at producing working code, but I think the bigger challenge is still knowing whether that code is actually production-ready.
Security, edge cases, maintainability, and understanding the business context are areas where human review remains extremely important. The advantage will likely go to developers who can use AI to move faster while still knowing what needs to be verified.
Exactly! Some of that can definitely be automated too. You can define a solid Definition of Done, add checks, tests, security scans, quality gates, and so on.
But in the end, someone still has to verify that the result actually makes sense in the real context and that nothing important slipped through. 😄
Hi Sylwia - your five minutes / four days ratio made me want to flip it 🙃
Imagine humans could code the change in five minutes, while four or six AIs spent the next four days discussing architecture, constraints, and business intent.
My first thought was that a human would eventually ship a small probe and let reality settle the argument.
Then I wondered: why wouldn’t one of the AIs do that?
Maybe AI wasn’t avoiding engineering after all. Maybe we just gave it a keyboard and forgot to invite it to the meeting.
I see what you mean, and it’s a really interesting thought experiment. 😄 But I wonder if at some point we’re taking it one step too far.
Because if the AIs are discussing the business intent, making the architectural decisions, running experiments, evaluating the results, and then building the system… who exactly are they building it for? Other AIs? 😂
Somewhere in this loop there still has to be a human with an actual problem, need, or goal. Otherwise we might end up with six agents having a four-day architecture meeting about a system nobody asked for. 😂
Ah yes - the old human problem: taking the next step toward what scares us, while still knowing which step should be the last 😊
the five minutes vs four days point is real. and even once everyone agrees, the actual shipping part (auth, db, https, backups) usually eats more time than the five minutes of code did. deploy still isn't a solved problem for anything past a toy app
Exactly! Coding really is just the tip of the iceberg. 😄 Even after everyone finally agrees on what should be built, there’s still everything around it: infrastructure, security, deployment, monitoring, backups, integrations… and all the weird production problems nobody anticipated. 😂
Copilot created app from scratch and deploy it but it has mistakes and no patterns. Coding with ai is high level of programming but does it boost speed. Easy pattern like creator could be faster and understandable.
Of course, it depends. And it depends on the developer too. Developers are perfectly capable of creating a complete mess in the codebase without any help from AI. 😂
Other times, yes, an experienced developer could probably implement something faster and better by themselves than by prompting AI and then fixing the result.
And when it comes to prototypes, sometimes “quick and dirty” is actually the right engineering decision. There’s no point spending three days designing the perfect architecture for something that might turn out to be completely unnecessary. 😄
The career arc you describe is real, and it has an awkward implication people skip: if coding was never the most valuable part, then most of how we evaluate developers was measuring the wrong thing. Interviews tested syntax recall and whiteboard puzzles because those were visible; judgment about what to build, what to refuse, and how a system fails at 3 AM was invisible and therefore untested. AI didn't create that gap, it just made the visible part cheap enough that the gap is now impossible to ignore. One thing I'd add from the senior end: the skill that ages best is knowing what NOT to build. Every experienced dev I respect has a longer list of things they talked a team out of than things they shipped. The models are getting very good at writing code; they are not getting better at telling you the feature shouldn't exist.
Hahaha, I couldn’t agree more with the “knowing what NOT to build” part. 😂
And I think this is also where expectations at different seniority levels have always been a little different. From a mid-level developer, you mostly expected them to deliver. But when interviewing seniors, I would deliberately ask questions like: “Why would you introduce a state manager here if you could solve the same problem with a simple service?”
And believe me, I met quite a few “senior” developers whose answer was basically: “Well… because that’s just how you do it.” 😂
The junior-to-senior path is the bit that worries me most. A lot of that learning came from doing the boring implementation work and breaking things yourself.
If agents take that work away, we need a new way to build that experience.
This worries me a bit too. A lot of the judgment I have today comes precisely from all those years of digging through code and figuring things out the hard way. 😄
On the other hand, nobody is stopping juniors from learning the fundamentals, reading, experimenting, and writing code themselves without immediately asking AI to do everything for them. The opportunity to learn is still there.
The harder question is whether people will actually choose that slower path when there’s a tool sitting next to them that can produce the answer in seconds. 😅
I think this is true in a very specific sense: AI is already better than many developers at producing code for well-defined problems.
But I don't think that means AI is better at software development.
Writing code is only one part of the job. A good developer has to understand the business problem, ask the right questions, choose the right architecture, recognize when the requirements are wrong, deal with ambiguous situations, debug production issues, and make trade-offs that aren't always visible in the prompt.
AI can generate a surprisingly good solution in seconds. But sometimes the hardest part isn't writing the solution — it's knowing what the solution should actually be.
And there's another interesting problem: AI can produce code that looks excellent while being subtly wrong. The more capable the model becomes, the harder it can be for an inexperienced developer to notice those mistakes.
So I would frame it differently:
AI is becoming better than most developers at writing code.
Developers who know how to think, review, and guide AI are becoming better than developers who don't.
The real competition may not be developers vs. AI.
It might be developers who can effectively use AI vs. developers who can't.
And that makes learning software development even more important, not less. If you don't understand the fundamentals, you may be able to generate more code — but you won't necessarily know whether you're generating the right software.
Exactly! A strong developer who also knows how to use AI effectively can become an even stronger developer. AI amplifies the judgment, experience, and technical understanding that are already there.
And those who feel that automation is already better than them at the actual technical work, while their main contribution is basically moving Jira tickets around… well, I think they might have a much harder time adapting to what comes next. 😅
Raw coding ability is only one axis, and the one that matters more for production is whether the agent can evaluate its own output. I have seen coding agents write textbook-perfect diffs that passed every test and still broke the system, because nobody scored the diff against the actual requirements.
Oh yes! 😂 And of course the agent will confidently assure you that everything is correct.
I still remember an agent proudly telling me it had fixed an XSS vulnerability. And technically… it had. It just forgot to mention that it had also broken text formatting, so instead of nicely formatted content, users could now see HTML elements on the page. 😂
Your post seems motivating the fresh developers.Many of them are frustated about their career because AI replacing everything nowadays but only the developers will decide what the AI need to do which was clearly explained in your thoughts.
I think it’s motivating in some ways… but perhaps not in others. 😄 I definitely don’t want to pretend that nothing is changing and everyone will simply keep doing the same jobs as before.
I suspect we’ll either need significantly fewer developers for the same amount of work, or the role itself will change quite dramatically. Probably some combination of both. 😅
But I do think understanding what should be built, making good decisions, and being able to guide and evaluate AI will become increasingly valuable skills.
I agree that AI is making coding faster, but I think the real value of a developer is shifting toward problem-solving, system design, debugging, and understanding the product.
AI can generate code in seconds, but deciding what to build, why to build it, and whether the generated solution is actually correct still requires human judgment.
Exactly! This is where the human still plays the leading role. AI can generate the implementation incredibly quickly, but understanding the problem, deciding what actually makes sense to build, and judging whether the result is good enough is a very different skill set. 😄
I think AI can make mistakes sometimes 😅 Once, it actually made up a person, their date of birth, and what they did, even though I asked it to write about a real space researcher. Then it even admitted that it had made everything up 😂 Sometimes AI honestly scares me a little!
Hahaha, mine loves inventing random names out of nowhere. 😂 But of course, this also depends a lot on the model. For research and finding information on the web, I think Gemini is probably the one I trust the most right now. 😄
I think that unpredictability is probably one of the biggest differences between managing humans and managing AI.
With humans, you gradually build a mental model of their strengths and weaknesses. With AI, that model can go out of date surprisingly quickly because the same system can behave very differently depending on the task, context, model, or even just the prompt.
Which makes me think that “AI management” might eventually be less about supervising individual outputs and more about designing the constraints, tests, feedback loops, and escalation paths around the AI.
Exactly! I actually made a very similar point somewhere else in this comment section. 😄 With humans, after a while you know your team. You know who is great at what, who needs more guidance, and who you can trust with a particular kind of task.
With AI, that mental model is much harder to build. The same model can be absolutely brilliant at one task and then produce complete garbage on the next one. 😂
So yes, I think you’re right: “managing AI” may ultimately be much more about engineering the environment around it than trying to supervise it like we would supervise a human.
This hit harder than I expected.
I just published my first Python articles this week — literally writing about if-else statements and loops. Basic stuff. And here I am, reading a post about how AI is already better at coding than most devs.
My first reaction was: "Well, what's the point of me learning this then?"
But your post answered it. Coding was never the hardest part. Figuring out what to build — and why — is the real skill. You spent four days deciding WHAT to change and five minutes actually changing it. That's the part AI can't do.
I'm not trying to become an "exceptional coder" anymore. I'm trying to become someone who understands the problem well enough to know what the code should do.
The dropdown that couldn't be collapsed made me laugh. That's exactly the kind of thing that makes me feel like I'm not completely obsolete yet.
Great Read.
Hey, thank you for this comment! And yes, exactly. 😄 I think this was already true long before AI entered the picture.
The most valuable developers in a company were often the ones who took ownership and really understood the context: not only how to implement something, but why we were building it, what actually mattered, and even when something needed to be done properly versus when “good enough” was genuinely good enough because deadlines were approaching. 😄
Of course, solid coding skills are still necessary, especially as you become more senior. You need to understand the code you’re working with and be able to judge whether a solution makes sense. But I don’t think you need to become some kind of “coding genius” to be an excellent software engineer.
So definitely keep learning those if-else statements and loops! 😄 They’re part of building the understanding that will eventually let you make those bigger decisions.
"At least for now. 😅"
Truth.
Hahaha let's hope we'll make it till retirement 🤣
unfortunately i haven't even started 🥲
Sometimes you give AI a problem and it just solves the damn thing. No need for a framework, an architecture discussion, or a 15-step investigation.
So true! Sometimes I run into a bug that I could absolutely fix myself, but figuring out what exactly is happening and where the problem comes from might take me a few hours. With AI, sometimes 20 minutes later the problem is solved. 😄
Of course, then you still have to review the solution and make sure it didn’t “fix” your bug by introducing three new ones somewhere else. 😂
🤦
we are cooked
🍪👩🍳🍽️
AI may code faster on boilerplate, but real value lies in solving messy, unseen problems and shaping architecture. If AI codes, we still need humans to set goals, review, and guard against edge cases.
Exactly! And I have a feeling those are precisely the people who will remain valuable in this industry: the ones who can understand the bigger picture, make decisions, deal with ambiguity, and take responsibility for the outcome rather than just produce code.
The five minutes of coding versus four days of engineering example says it perfectly. AI can build quickly, but deciding what should be built still requires experience, judgment, and coordination.
Exactly! It has always been like this to some extent, but AI makes the distinction so much more visible. When implementation suddenly takes minutes, you really start noticing how much of software engineering was never about writing the code in the first place. 😄
What specific coding tasks do AI tools currently outperform human developers in, and why?
I think it depends a lot on the developer. You can have an exceptional developer whom AI won’t outperform at almost anything meaningful, and you can have a weak developer whom AI will outperform at almost everything.
And then there’s speed. Even when AI isn’t necessarily better, it can often produce a good-enough solution much faster. From a business perspective, that can make the choice pretty obvious in many cases.
...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.
I think this distinction gets lost constantly. Being better at generating code and being better at software engineering are two very different claims.
Exactly! Those are two very different things. And I think even what we mean by “software engineering” is starting to shift as more and more of the implementation itself gets automated.
Facts. AI can spit out code fast, but it still can’t replace good judgment and knowing what the hell should actually be built.
Exactly, especially the second part! AI can execute incredibly well, but it still needs someone to define what should actually be built in the first place. That decision doesn’t magically disappear just because implementation got faster. 😄
what do you think about critical thinking and Decision making ,can your AI can do this ?💪🧠
It depends! 😄 Give it a good prompt, enough context, and clear constraints, and honestly, it can demonstrate better critical thinking and decision-making than quite a few humans I’ve met. 😂
code written by AI is hard to maintain!
So is code written by a bad programmer. 😂
Thank you, interesting
The "five minutes of coding, four days of engineering" example is the clearest illustration I've seen of what actually changes when AI gets better at coding. The implementation wasn't the hard part. It was never the hard part. Figuring out what should be implemented, getting everyone to agree on it, and holding the context of all the reasons why it looks the way it does, that's the part that doesn't compress.
What I keep thinking about from my own experience is that AI being good at coding also changes what "understanding your codebase" means. It used to mean you wrote most of it. Now it increasingly means you can reason about code you didn't write, at a speed that keeps up with how fast it's being generated. That's a different skill, and I'm not sure most conversations about AI and developers account for how much that shift actually demands.
The "vibe-code cleanup engineer" comment made me laugh because I've genuinely encountered that problem already, code that works on the surface but that nobody can confidently change because the understanding that should have been built during implementation never happened. The five minutes saved up front showed up as hours of archaeology later.
Hi Sylwia,
This was -again- a very interesting post.
In your post, "5 minutes of coding after 4 days of engineering" is a great example of the value in other aspects of the development. I am glad you brought this up, emphasizing the importance of architecture, decision making, customer and product/system/requirement management.
As coding becomes faster, the valuable skills shift toward problem-solving, architecture, domain knowledge, and making good technical decisions. AI changes the workflow, but those skills become even more important.
The “five minutes of coding, four days of engineering” example says it all. AI can speed up implementation, but understanding the real problem and making the right trade-offs still takes experience.
This resonates hard. I spent 6 years getting really good at writing code, then watched AI do in 30 seconds what took me 2 hours. The shift from "how do I implement this" to "should we even build this" is real.
But here's what I've noticed: AI is better at writing code, but still terrible at owning it. It can't sit in a meeting and defend why it chose Postgres over MongoDB. It can't feel the pain of a 3 AM outage and learn from it. It doesn't build the scar tissue that makes senior engineers valuable.
I wrote about my experience replacing $99/month of AI coding tools with a free local stack (Ollama + DeepSeek + Continue + MonkeyCode). The code it writes is 90% as good as Copilot, but the 10% gap is exactly what you described — the stuff that requires judgment, not just syntax.
What's your take: will AI ever develop "taste" in code, or is that fundamentally human?
Agree that coding was never the bottleneck — but I'd push back on one implicit assumption: that AI coding means paying $20-200/month for cloud tools. I ran a free-tier-only setup for 60 days (local 7B models via Ollama + free cloud inference as fallback), and the interesting result wasn't speed — it was that review quality went up because I stopped rationing AI usage. When each suggestion costs $0, you let the model draft three approaches and pick, instead of accepting the first one a paid quota makes you precious about.
The skill gap you describe (junior grinding Stack Overflow vs seniors knowing what to ask) maps exactly to AI: seniors get 10x because they know which of the three drafts is wrong. Juniors get maybe 1.2x because they can't tell.
Curious where you land on this: is the real divide "AI vs no AI", or is it "developers who can evaluate output vs those who can't"? Because the second one existed long before LLMs.
Agreed on the direction, with one measurement that complicates the shipping half. I ran four free models through the same agent harness on the same jobs: among the ones that passed a two-bug Python script the spread was 43s to 251s, and Gemma 4 31B never finished at all, hanging until a 900-second timeout. The uncomfortable result was that the model which won the debugging task outright later reported a file-organising job complete after 20 seconds without having touched a single file. It shipped nothing and said it shipped, which is not a coding-ability failure at all, it is the judgement layer you are describing, and it may be why "better at coding" and "better at shipping" are coming apart rather than together.
"Hi everyone, I’m building a vehicle tracking device designed to resist signal jammers, especially for high-end cars. I’ve done a prototype using Arduino and NeoPixels, and I’m looking for feedback and advice on how to take it to the next level. If you have experience in hardware or vehicle security, I’d love to hear your thoughts!"
Interesting perspective. AI is definitely getting better at coding, but I think the real advantage comes from developers who know how to use AI effectively. Writing code is only one part of software development—understanding the problem, making good decisions, and taking responsibility still matter a lot.
Lovely article again, I love the way you write
AI for me has been one game changer in my developer experience. For me though, I still love writing code, and what I am doing is to learn how to do things on my own, then later down the line, use AI to automate it. There are already things I can do that I just tell AI to speed up, and generate code for.
It's all about finding the balance. One thing which I have began to notice about myself, is not to let AI become your second brain. You still need to think, and upskill as a developer.
This is a great perspective on the difference between coding and software engineering. AI can handle repetitive implementation, but understanding the product, making architectural decisions, and knowing what to build still require real engineering judgment. The future belongs to developers who can use AI effectively while continuing to improve their problem-solving skills.
For more programming resources and developer tools, check out codecan.net.
The career arc you describe — from "handcrafting artisanal code" to "handing tasks to juniors and mids" — is exactly why AI landed so softly for you. You'd already stopped deriving identity from the typing.
But I want to push back gently on "AI is already better at shipping code than most software developers." Better at producing code, sure. Shipping is a different verb. The failure mode I keep hitting is that AI-generated code ships fine and then becomes archaeology six weeks later — nobody on the team can explain why the structure exists, because the structure was never a decision, it was a default. The "thinking things through and getting people to agree" work you're describing as the senior part of the job? That layer is exactly what gets skipped when the code appears without a decider.
Your research links point at task-completion benchmarks. I'd love to see one that measures "time-to-confident-2am-debug" six months after the AI wrote it.
Curious where you land: is the answer to accept that most code was always disposable, or do we need workflows that force the engineering artifacts (tests, invariants, design notes) out of the model alongside the code?
This matches my experience almost exactly — the part that clicked for me was realizing that "writing the code" was maybe 30% of what made me valuable, but it consumed 80% of my mental energy. AI flipped that ratio.
One thing I'd add from the economic side: the shift also changed which tools I pay for. I dropped my Copilot subscription and moved to a local stack (Ollama + a VS Code extension) — partly for cost, but mostly because once AI writes the boilerplate, I noticed I didn't need the premium autocomplete anymore. The value moved from "fast code generation" to "good code review," and that skill is free to develop but very expensive to skip.
Curious about your take on this: as AI absorbs more of the coding, do you think the junior developer pipeline survives? If juniors don't get to learn by writing the "boring redundant code" anymore, where do they build the intuition to review what the AI produces? That's the part of this transition I haven't seen anyone solve well yet.
good point on the four days vs five minutes gap. there is one more layer past that though. even after the decision is made and the agent writes the five minute change, someone still has to get it live. wire up the db, auth, https, backups. that part does not get faster just because coding got faster.