Sylwia Laskowska

Posted on Sep 10

AI Is Already Better at Coding Than Most Software Developers

#ai #programming #discuss #webdev

Real engineering replaces mere coding

...but let me say this right away: coding was never the most valuable part of software engineering.

I remember when I was a junior software dev. Nothing came easily to me. Every feature felt like an uphill battle. I can't even count how many hours I spent digging through Stack Overflow. And then there was the stress of PR reviews, where I sometimes got absolutely roasted in the comments (rightfully so!) 😅

Eventually, things started getting better and better. Shipping features took me less time, and there were fewer comments on my pull requests. Over time, I started handling more complex things, including architecture. I could choose the right solution, explain why a particular tool or design pattern made sense, and defend my decisions.

And I loved being good at coding. Domain knowledge or architectural concerns? Those were somewhere in the background.

Then Coding Stopped Being the Hard Part

The longer I worked as a developer, the more complicated the problems became, and the less they had to do with coding itself.

I stopped getting excited about every new framework feature. In fact, whenever I heard about another "revolutionary" solution, my first thought became something along the lines of: "Yet another state management solution..." (I'll probably write a whole article about that someday.)

Eventually, I ended up where every tech lead eventually ends up: spending most of my time thinking things through, sitting in calls, and getting people to agree on things, while handing coding tasks to juniors and mids. Much to their delight, actually, because they're happy to get a chance to learn something new.

Fortunately, I still code quite a lot, but these days it's usually the more horizontal stuff or the technically difficult features.

And that's exactly the point in my career when the AI revolution arrived.

And I Welcomed AI With Open Arms

I was genuinely happy about it! I'm not crying over the fact that I no longer have to handcraft every precious little piece of artisanal code myself. I didn't particularly want to anyway.

@nazar-boyko recently asked in his article, "Has AI Made You A Lazier Developer? Be Honest." I answered honestly: no. Quite the opposite. AI has made me less lazy. I do more because I don't have to spend as much time on the most boring part: writing redundant code.

And in my opinion, AI is already better at shipping code than most software developers.

There is actual research behind this, some of which I've linked at the bottom of this article, so you can check that I'm not just making things up. 😉 The research shows that AI can dramatically accelerate coding and that frontier AI agents can already complete some coding tasks that would take humans days or even weeks.

And we often see this in our own work. AI doesn't get tired. It doesn't get stressed. It doesn't get distracted. It doesn't have a "bad day." (Okay, sometimes I swear it does )

Not All Developers Are Equally Good at Coding

And let's face another uncomfortable truth: there are better and worse developers.

I know that's not particularly pleasant to say, but it's simply true. Some people are better at cooking. Some are better at singing. Some are exceptional at coding. And some are... a little less exceptional.

Sometimes I get the impression that here on DEV, we treat programmers as some kind of meritocratic class of geniuses. As if every developer, by definition, possesses an extraordinary set of irreplaceable skills. But everyone who has spent enough time in this industry knows that's simply not true.

And AI might actually level the playing field here. A developer who isn't an exceptional coder but is responsible, understands the product really well, makes good decisions, and knows what needs to be built can now go incredibly far.

But There's One Tiny Little Detail

There's just one small, tiny detail. Something we intuitively understand, and something the research I've linked below also hints at: The further the job moves away from simply generating code, the less spectacular the machine's advantage over humans becomes.

In an older study, experienced developers actually worked SLOWER when using AI.

More recent results suggest that newer AI tools probably do speed them up, but the effect is nowhere near as straightforward or spectacular as the raw coding benchmarks might make you think.

In general, the more the work depends on experience, judgment, coordination, and higher-level decisions, the less useful "how fast can this thing generate code?" becomes as a measure of productivity.

And I know exactly why.

Five Minutes of Coding. Four Days of Engineering.

Recently, I had to introduce a change to an application that would probably take a coding agent — even a not particularly brilliant one — about five minutes to implement.

So what was the problem? Discussing WHAT that change should actually look like, coordinating it with all the teams involved, and agreeing on the final solution with the client took FOUR DAYS. During those four days, the decisions changed several times.

And let me add something important here: having a developer in those meetings, and preferably an experienced one, was absolutely necessary.

The implementation took five minutes. Figuring out what should be implemented took four days. And that is exactly the difference between coding and software engineering.

Coding Is Becoming Cheaper. Engineering Isn't.

See what I'm getting at? AI is taking repetitive, derivative work off our shoulders. It does that work faster than we do. Often better than we do. It doesn't get tired while doing it, and it doesn't get stressed.

And because of that, the skills the market needs from developers are shifting. If all you can do is code, and an agent can now do that faster and better, you might soon have a problem on the job market.

But if you feel like an agent can do the work you used to give to your junior developers, while you still have to guide it by the hand when it comes to details, architecture, trade-offs, and all the weird little realities of an actual production system, you're in a very different position.

Mine, for example, generated a dropdown today that was permanently open and literally couldn't be collapsed. 🤣

If you understand the bigger picture, know how to make technical decisions, understand the product, and aren't afraid of innovation, your job is probably safe.

At least for now. 😅

So yes, AI getting better at coding doesn't make software engineers less valuable. It makes coding itself less valuable as a software engineering skill.

BTW if you liked this post, you can also follow me on LinkedIn.

Top comments (22)

Pascal CESCATO • Sep 10

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. 😄

Sylwia Laskowska • Sep 10

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.

Pascal CESCATO • Sep 10

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. 😂

Peter Vivo • Sep 10

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.

Sylwia Laskowska • Sep 10

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. 😄

Daniel Nwaneri • Sep 10

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.

Sylwia Laskowska • Sep 10

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.

Ranjan Dailata • Sep 10 • Edited

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

Sylwia Laskowska • Sep 10

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.

Tejas Shinkar • Sep 10 • Edited

"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.

Sylwia Laskowska • Sep 10

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. 😄

Tejas Shinkar • Sep 10

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.

xulingfeng • Sep 10

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.

Sylwia Laskowska • Sep 10

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. 😄

xulingfeng • Sep 10

Exactly! For me, writing test scripts is the relaxing part. After days of aligning requirements and coordinating teams, coding feels like a quiet reward🤣

Suraj Suradkar • Sep 10

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.

Sylwia Laskowska • Sep 10

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.

Varshith V Hegde • Sep 10

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.

Alexandra • Sep 10

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?

Glen Allen • Sep 10

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.