It's very obviously not "the easy part", it's definitely hard. It's just not the only hard part. And there may be other parts that are harder in some sense.
If it was the easy part, then why did they pay us hundreds of thousands, sometimes millions, sometimes more - to do it? The fact of the matter is that it wasn't easy, not for a brain that's architected the way a human's is. The fact that computers can now do it much more quickly and arguably - in many cases - better doesn't diminish the act itself - it just shows how far AI has come, and how easily human intelligence will be dwarfed as it continues to make progress.
Code was the easy part for people who wrote code day in day out with very strictly defined requirements. But even for someone like me that's been doing it for 30 years...new frameworks, languages, architectures, wiring up 3rd party apis, banging my head because I fat fingered something, greping debug logs, late nights, early mornings and lots of coffee. There were few times where I would call it "easy". I just ideated and built an app optimized for mobile and laptop, and deployed it globally in two hours and built a Roku companion app in a couple nights after the kids went to bed. I had never built a Roku app before and am pleased with the polish for something that went from an idea to launch in two hours.
Yes I have 30 years of experience and there were still areas that were not easy but man it was fun. Writing the code, building and deploying product is easier than it was before by a huge margin.
Skicamslive.con if you're wondering what I built. Feedback welcome
It's a bit like saying "Writing English was always the easy part" vs. writing a book that becomes a best-seller or classic.
I strongly believe that this is a false and outdated take.
Code being the easy part was predicated on how long it took to build a product, and the impact that had on product management, sales, and marketing.
When the time to build collapses, all product/sales/design/martketing mistakes are forgiven. You can pivot so fast, that mistakes in other domains dont matter as much and are reversible
All of the axioms we previously held true need to be rethought
> and nobody got into it because programming in Perl was somehow aesthetically delightful. (The language is referred to as write only line noise for a reason)
Today we call it "vibe coding" when people use an AI to write software without reading the code, or even learning how coding works. But people have been doing that for ages. Most "Perl programmers" back in the day never even attempted to learn the language, and often weren't software developers. But despite their horrible coding skills, the Perl worked anyway. And thus the language got a reputation for being hard to read, despite it being amazing that it worked at all.
Perl is still far and away my favorite language. I get things done so much faster in it, and programs I wrote 25 years ago work perfectly today on the latest systems. (Maybe that's the problem? If it were a real language, it would've broken 5 different times by now! And then I get paid to fix it... I think I understand software engineering now...)
The thing that makes me crazy about this article, others like it (and so many of the comments in response to them ) is the naive assumption that whatever the author is used to is always the case.
It's just not. I've been a developer for 25+ years, and in technical diligence looking at companies getting investments for seven, and have done diligence on 100+ companies. It's ALL OVER THE PLACE. It depends on the product, the company, the team, the way the company is managed, the business domain, etc.
For some companies, products, and teams.. the code absolutely is the hard part, and building that insanely sophisticated software is worth millions. I've seen scientific software that sold for millions of dollars per copy.
For others, the code is essentially commodity plumbing around some operational knowledge of a domain that makes nice dough with minimal code complexity. I've also seen founders who were going to spend the rest of their days floating around the bahamas because they wrote the right PHP-ball-of-mud in the right domain at the right time, sigh.
The world of software is vastly broader than the vast majority of programmers think. And there are a lot of very, very different ways to make money in it.
Some code has always been the easy part, similar to the way a lot of systems abstract the more complicated pieces of a software project away from you. I am not talking about the relationship between higher and lower level languages but rather the way in which certain large enterprise systems already made the code 'very' easy.
For example, I have worked with SAP a lot...the largest ERP system in the world by some margin and I have used it's internally built tools that extend a small amount of developer functionality to the 'IT department developer' that gives a user with knowledge or .NET and SQL the chance to make little validations or do some bespoke data visualisations pretty quickly. This was trivially easy and pretty sure AI tools will make a developer redundant in this context because the documentation is good and there's a lot of it.
Contrast eg hooking up a system like SAP to an unusual non-standard Ecommerce offering and you have a far more complex problem (that interestingly doesn't require huge amounts of code but does in fact take a long time because of lack of documentation and a certain amount of understanding required). I would also point to programming games, which I enjoy...compare using Unity with some C# scripts for making games, to building your own engine (which will pretty much become redundant soon anyway if it already isn't). AI is very good on the Unity stuff but I suspect would struggle with it's own engine for a specific game.
This discussion feels analogous to me to the age-old "we can do it fast now, and do it right later" tradeoff discussion, except now it's about knowledge, maintainability etc.. There are stages of companies and types of products where solution quality has a bigger buffer, some are more critical. We also know that in many places, once you shipped a crappy solution in a week, you've now set an expectation, and management will expect you do repeat that forever, not getting the time to actually fix/rearchitect when needed.
We used to brush that off with the "we'll fix all of that once we've shipped", now we brush it off with "doesn't matter, AI can fix it later easily". This applies to knowledge about the code, domains and quality itself, too.
To me, this is a reasonable tradeoff to discuss, and sticking to either extreme ("AI is cancer" and "AI is the silver bullet") feels silly.
There's real risk here, and I do see a lot of seniors act like kids in the candy store. That speaks volumes to what AI really unlocks (cheap experimentation, for one!), but also warrants caution.
Based on the data (not great quality tbh...) we have, the net speedup is more realistically around 5-10% of the total time of software engineers, and we're yet to see the cost of that speedup.
Yes, code has always been the easy part. LLMs produce it even more copiously, so it is ever easier now, and yes, that makes the bottlenecks worse:
- communication between humans
"what are we to build?"
"what is the architecture?"
"how shall we design this?"
etc
- architecture review
- design review
- code review
- docs review
- ...
- understand what is possible
- and how to achieve it
- architect
- design
- review
But even with that one constraint about human-to-human communications, LLMs are improving throughput: by writing better docs faster, by helping us get the gist faster (though using LLMs to read docs that could have prompts embedded is scary), and so on.
Personally, where the communication burden is intense I don't think we'll see 10x, 5x, not even 25% efficiency improvements. But now consider projects where the communication burden is minimal as there is only one human -- personal projects, open source projects, that sort of thing. In those cases a 5x, even 10x efficiency improvement is not out of the question. Many projects have communications burdens that are not so intense that they can't experience 2x efficiency improvements.
The challenge will lie in safely maximizing those improvements and doing it better than the competition.
Like saying putting paint on a brush and wiping it on paper is the easy part of painting.
Even with coding agents, there is still a need to understand what it’s doing, how it will interact with other systems, where bugs or edge cases will show up and many other aspects that become security risks when ignored by someone that YOLO’s their vibe coded app into production
I've written these words multiple times here on HN, and have a draft blog by virtually the same title. I can't agree more with the sentiment, though I think theres some nuance the author is missing out on. Regardless, thank you for sharing.
I think what the author is saying is akin to that old joke about a broken machine that nobody at the company can fix.
They bring in a high priced consultant who spends a few minutes looking at the machine, reaches in and pushes a switch and suddenly the machine starts working.
When the manager gets the invoice, he calls the consultant demanding an explanation for why it cost so much. After all, the consultant only spent a few minutes looking and then flipped one switch.
The consultant offered to send a more detailed invoice and the manager received one that said:
- Flipping a switch: $1 - Knowing which switch to flip: $999
In other words, the writing of the code is like flipping the switch. It’s the rest of “coding” that’s difficult.
I think it's better to say 'the artifact is not the product'. Code is actually very hard, because it is the act of formalizing vague problems. That's thinking. It can be separated from literally typing the code in, and some problems are solvable in so many isomorphic ways you might as well describe them to an LLM and let it pick one out of a hat (embarrassingly solved problems), but it's like saying "prose is the easy part".
I think what it means is that coding is difficult but predictable — in the sense that, you can solve it by throwing enough money at it. Figuring out what to build in a way that actually leads to product-market fit, on the other hand, is something you cannot solve just by throwing money at it. So in this frame, coding becomes 'the easy part' — not because it's truly easy, but because it can be solved relatively straightforwardly with resources
I do and always will belive this phrase to be wage suppression propaganda. I think the proof is self evident. ie salaries.
I guess we just hallucinated leet code too.
Easy or not, code is obviously a time-consuming part. Anything that can dramatically reduce the time surely have significant impact.
Trivializing code has reached an insufferable nadir. It is like saying math or medicine is the easy part, or cooking or carpentry. Often those who say it cannot code or read code, and are good at marketing, so they simply keep on promoting it and be dismissive of other work. Disillusioned to see it at the top of HN, and hand waving away methodical and substantial activities can only bode badly.
I as a "developer", I have probably used less than 10% of my time coding the last 15 or so years... I switched jobs to being a contractor in 2011, and after that it has been a downward slope towards less and less coding, and more of other things. Mostly validation and testing in various forms.
Did consider that your view might be skewed because you work in a CRUD app?
Every time computers master a skill that was previously thought to require a lot of intelligence/knowledge/ingenuity, people suddenly claim that it wasn't that hard after all.
- Non-trivial arithmetic
- Puzzles involving combinatorics
- Chess
etc. etc.
Previous discussion from 2 weeks ago: https://news.ycombinator.com/item?id=46966753
As a junior dev, it wasn't so easy for me :/
I’m out of my element here. At least I’m speaking as an observer and not a participant of the programming language debates that I feel are less prevalent in communities like here than they are in the past. Ostensibly due to the raise of LLMs and debates about them taking up most of the programming discourse now.
I wonder if someone with real experience/insight thinks that this claim is revisionist.
AI reduces the thinking time, too. And most of my time is spent either thinking or coding.
Brilliant. You can already see the HN users in here with emotional attachment issues who are sad because of the issues you talk about, and it’s causing them to bury their heads in the sand.
It’s going to be a hard transition, but we can’t pretend it’s not happening, that won’t get us anywhere.
This meme is just cope at this point, and it’s frustrating to watch engineers pretend that it was actually the architecture that was hard or whatever.
No author, this isn’t the same as SPAs and CI/CD.
This isn’t just happy tools helping us focus on the business side.
We’re devaluing all white collar work. The thing that keeps the US economy afloat. Even if this tech requires human oversight, why would companies keep you when they can hire someone overseas at 1/10th the cost and get to 80% of the productivity with AI.
Anthropic just dropped their safety pledge. Do you think they’ll hesitate as they transfer wealth from workers to their shareholders?
Please people. Stop being avoidant. Stop pretending it’s a meritocracy and you’re at the top. Stop pretending the one thing about the job AI can’t do is the job.
What a strange thing to say.
Code was never the easy part.
If it was, then AI and LLMs would have been of no interest for coding.
Self evidently wrong.
Lol. Lmao, even.
Software developers have spent the last twenty years blabbing about how product management is useless and coding is the one true skill.
...to the person who knows how to code.
I can only assume so many people are repeating this as "cope".
People are missing the forest through the trees. Producing code which implements business logic has always been easy. This has always been true, even decades ago. As of at the early 2000s you could have spent around a rather small amount of money and gotten an app written for you based off of your natural language description by someone in a developing country. But what you got was a big ball of mud. It might correctly implement your ideas, it might not. I know this because I’ve helped make take these big balls of mud and turn them into actual software.
The hard part is long term maintenance. The hard part is retrofitting new features. The hardest part of all is not building a big ball of mud.
Mythical Man Month is still an amazing read. 9 agents still cannot have a baby in 1 month because the problem has never been the speed at which we type.