Writing robust, bug free, efficient, maintainable, and readable code has never been easy and still isn’t. It’s an extremely difficult skill.
Are we seriously pretending that it was always easy now that an LLM can spit out some mediocre code? This seems to me a coping mechanism in response to the industry shifting.
The truth is we’re just realizing nobody, even the SWE’s, care about the code much as long as an LLM can grind it out for free.
There’s going to be a lot more of this coping as more and more human thinking gets automated. I can hear it now: “gathering business requirements was always the easy part”.
> Are we seriously pretending that it was always easy now that an LLM can spit out some mediocre code? This seems to me a coping mechanism in response to the industry shifting.
I also add that the skills required to write robust, bug free, efficient, maintainable, and readable code are also the same skills required to make LLMs generate code with those traits. Mediocre developers struggle to write mediocre code, but can easily prompt a LLM to output mediocre code. The output is always mediocre, both in the short run and moreso in the long run.
Hire excellent programmers who spent their lifetime learning how to write good code and build systems, and then the code is easy. Hire some bad ones and watch them struggle and fail and learn why maybe coding is not that easy. AI doesn't change this, it just shifts failure modes a bit since the volume of code produced is now larger, and AI-enabled bad programmers are still bad.
I remember a tennis survey where something like 70% of respondents believed they could win a game against a Tennis pro player (I can't find the source anymore, but it was discussed on Andy Roddick's podcast). If you watch Roger Federer effortlessly and elegantly make beautiful shots, it's very easy to fall into this trap and think -- it must be so easy, right?? Are people falling into the same trap watching Claude Code regurgitate CRUD apps for them?
At this stage the use this kind of rhetorical structure, whereby a series of affirmatory statements (sometimes alternatively a series of rhetorical questions) are used to hedge a following "but", is so regular and reliable a flagraiser that an article will be either propagandistic, blinded-by-science, or otherwise uncritically oleaginous towards AI, I know that I can close this article midway through already knowing that the title is both the substance of the argument and also incorrect.
"cost of producing code is going plunge towards something near to zero "
Until the AI orgs need to turn a profit.
Man, these "hot takes" on the impact of AI are all becoming so tiring. I'm especially sick of all these "code was always the easy part" missives I see everywhere now, mostly because I think they're flat out wrong.
As another comment said, "easy can still be time consuming". I've seen plenty of projects that were well defined take months in implementation time (and then still sometimes fail for technical reasons). But most importantly, if "code were the easy part", why were top programmers receiving kingly wages for over 20 years? Because business people knew the difference between a successful tech company and an also-ran usually was, in huge part, due to the quality of their software engineers. If "code was the easy part", then you go write Google Maps in 2005, or Netflix streaming in 2007, or self driving cars in 2010, or, heck, ChatGPT in 2022.
Sure, good code for a bad product still fails, but this revisionist history trying to pretend coding was so easy, so LLM-assisted coding tools won't have a big impact, is nauseating.
But the code is the easy part. Solving the right problem is the hard part.
Repeating this banality does not make it true. There were tons of tech companies over the past 30 years or so who, despite solving the same problems, lost out to competitors because they had worse programmers.
I actually agree that the code is one of the most important things to get right at a software company. Still. I would argue very few companies win on code merit alone either though. Strategy, customer communication, market timing, etc on the business side; design, system architecture, dev velocity on the technical side. So many factors are important beyond the quality of the code.
> Repeating this banality does not make it true.
If anything matches the definition of banality in this discussion, it's the puerile assertion that writing code is software development.
It isn't.
Even at FANGs the first thing they say to newjoiners and hiring prospects for entry level positions is that the workload involving writing code amounts to nearly 50% of your total workload.
And now all of a sudden are we expected to believe that optimizing the 50% solves the 100%?
Now we are shifting the goalpost. Who even claimed AI solves 100%. I would even be damned if AI can solve 50% and it would be huge. Personally I don't even think current AI solves even the 50%.
> Now we are shifting the goalpost. Who even claimed AI solves 100%.
I think you lost track of the discussion. I pointed out that in the absolute best case scenario LLMs only focus on tasks that represent a fraction of a software engineer's work.
Then, once you realize that, you will understand that the total gains of optimizing away the time taken on a fraction of a task only buys you a modest improvement on total performance. It can speed up a task, but it does not and cannot possibly eliminate the whole job.
To see what I mean, see Amdahl's law.
https://en.wikipedia.org/wiki/Amdahl%27s_law
Again, only a fraction of the tasks of a regular software engineering role involves writing code. Some high-profile roles claim their entry level positions at best spend 50% of their time writing code. If LLMs can magically get rid of said 50%,the total speedup is at best 2x speedup in delivery.
You can look at that and think to yourself "hey that's a lot". That is not what's being discussed here. I mean, read the blog post you are commenting on. What's being discussed is that LLMs reduce time spent on a fraction of the software development tasks, but work on other software engineering activities increases as it's no longer blocked by this bottleneck.
As others have wrote, the so-called AI doesn't reduce work: it intensifies it.
https://hbr.org/2026/02/ai-doesnt-reduce-work-it-intensifies...
Also, why do you think the phenomenon of AI-induced burnout, dubbed AI fatigue, is emerging? Processes are shifting, but the work is still there.
> the total speedup is at best 2x speedup in delivery
Which is just huge if we can get 2x speedup.
> But most importantly, if "code were the easy part", why were top programmers receiving kingly wages for over 20 years?
The vast majority of developers are not paid to write code. They are paid to produce, deploy, and run bug-free and efficient software systems. That does not necessarily require you to type anything at a keyboard.
Ask yourself this: how come the more you progress in seniority the less code you write?
> They are paid to produce, deploy, and run bug-free and efficient software systems.
> That does not necessarily require you to type anything at a keyboard.
That first thing do necessarily require you to type on keyboard.
> how come the more you progress in seniority the less code you write?
Because they delegate the work. Nothing to do with seniority. CTO of 2 person startup still needs to write code.
> That first thing do necessarily require you to type on keyboard.
Not exactly. Working on the problem domain to shift the solution domain is a tried and true technique to deliver higher-quality software. This happens away from a keyboard.
> Because they delegate the work. Nothing to do with seniority. CTO of 2 person startup still needs to write code.
No, that's quite wrong. The role of senior engineers is not defined by delegation. No organization pays someone a higher salary for a job description which focuses on shifting work onto everyone else around them.
Systems architecture, drafting and reviewing roadmaps, planning technical directions, tackling high-complexity work. Overall, figuring out what work we can and want to do. That does not involve a keyboard.
No, they are paid to write code.
Writing code is hard. It is just as hard today as it was 10 years ago. Maybe harder, because stacks have become much more complicated.
Leaving aside the world of a startup that needs a simple CRUD app written, when you write software that is successful, it gets large and complicated. It fills up with features, and is really hard to understand.
Onboarding new people into that codebase takes time. When you don't know the code, you are not very productive, you make mistakes because you don't understand the repercussions of what you are doing. Your code hurts performance, it interferes in subtle ways with other parts of the system. It breaks conventions.
I've worked in companies where it basically takes a year to get really productive, and you need to give people a lot of mentorship and supervision in that first year.
And the second year you are better than your first, and every year you get better, because you understand the code better. As you understand the code better, you get more productive and more valuable to the company.
You have to keep all that code in your head and really understand it well. Not many can do this for large codebases. Code has gotten easier to write, with more ergonomic problems, but understanding a complex code base and being able to add features to it while maintaining performance requirements and quality requirements remains as hard as it was, and being able to do that remains a skill that companies desperately need. AIs, with their limited context window and shaky reasoning ability have not changed this.
Now, what happens with developers who grow to rely on AI to write code? You lose comprehensibility of your own code.
Again, ignoring the simple CRUD app or demo project, if you are working on a million line codebase, after 6 months of having AI write code, you no longer understand large parts of that codebase.
But you are the one responsible for catching the AI bugs! How's that gonna work?
It takes a great effort to read and understand code that someone else wrote. It is much, much easier to understand code you wrote. As you write less and less code, your mind drifts away from that productive zone, and you become less valuable, not more.
Microsoft is a great example of a company that lost the ability to ship features in a timely manner and that meet basic quality checks. Windows is a large, complex codebase. I'm pretty sure I know what got MS into the problem it's in.
And AI is just headshotting tech company after tech company, causing them to miss deadlines and ship buggy features as they de-skill their own developers and lose the ability to stay ontop of the complexity of their code.
Fortunately it's not happening to every tech company, but a good chunk of them are slowly turning into companies staffed by people that don't understand their own codebase.
This is not going to end well for these companies, or for the developers that stop writing code. I am not worried about programming as a profession, as cleaning this mess up is gonna require massive labor, but I am certainly worried about what is happening to companies like Microsoft or Facebook as they go all in on AI. When those companies fail, a lot of people will lose their jobs.
We are already seeing many well known companies really struggle with shipping code on time and meet basic quality requirements.
Oh man, I was composing my own opinion, and I can see that Hacker News is brimming with opinions. But that’s perfectly fine, I believe. All the diverse perspectives that we engage in this intellectual sparring match is a positive thing, isn’t it? :)
Easy can still be time consuming. I think trying to get an LLM to spit out the whole program is a flawed approach, but I understand why you'd want to be able to spitball 12 different data models quickly.