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.

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

LLMs are also being used to:

  - understand what is possible
  - and how to achieve it
  - architect
  - design
  - review

Only the communications part is an inherent bottleneck that we cannot completely fix with LLMs -- we're humans selling to humans, humans buying from humans, humans managing humans, humans trying to convince other humans. LLMs cannot make this part much more efficient than it already is.

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.

This has always seemed like a paradox to me. Once I got past the initial learning curve, coding seemed easy and fun. But most people can't or won't get past that learning curve, for reasons that I don't think we understand.

But if coding were hard, then writing small pieces of code would be as hard as writing big pieces. To make an analogy, playing the violin in tune doesn't get any easier, the shorter the piece that you have to play.

Developing software is hard. Some sort of "phase transition" occurs when a project gets big and complex, where coding is no longer what makes it hard. And writing software in a way that is not a net burden to a project or organization is hard, involving not just complexity but humanity. Most smart people in an organization have subtly arranged their affairs so that their career progress doesn't hinge on the success of a software project.

I admit that I only say these things as an observer, since I can code all day, but didn't pursue a software development career.

I also admit that I'm waiting for AI to handle the second two levels of software development. I'll concede that AI can develop software when The Mythical Man Month no longer reads like it was written yesterday.

You aren't paid to write lines of code, you are paid to build, ship and maintain products and services, usually in a complex corporate setting with ambiguous and ever-changing requirements. Code is a very small part of the overall picture.

Why do you think in most technical organizations the higest ranking and highest paid engineers generally write the least amount of code (often none)?

My experience is that the higher paid someone is generally the less they actually code. I'm sure some places have very difficult code but in my experience there's a reason that engineers fresh out of college mostly code and the highest paid engineers do things like design, planning, and coordination.

Folks have little appreciation for how soon we're all about to transition to something new.

I don't know what that entails, but something is going to happen.

I got into a discussion with some Rust compiler folks yesterday. I called Rust the "final human language we'll serialize our thoughts to": it's easy to write for LLMs, is super type safe, ergonomic, easy for humans to read and reason about, and has really nice deploy characteristics - single binary, no GC, bare metal, etc. If Python and Rust are equivalently easy to emit, you'll probably choose Rust if you're not bound to other choices.

People quipped back that this was absurd and that Rust is built for decades of future human use, that this kind of talk would put people off of Rust, and that they need to think of the future.

As if anything will be human in the coming decades.

Programming languages were punch cards.

    struct Zero;
    struct Succ<N>(N);

    trait Add<Rhs> {
        type Output;
    }

    impl<M> Add<M> for Zero {
        type Output = M;
    }

    impl<N, M> Add<M> for Succ<N> 
    where 
        N: Add<M> 
    {
        type Output = Succ<<N as Add<M>>::Output>;
    }

    fn add(a: u32, b: u32) -> u32 {
        a + b
    }

Because they could.

Try running a business that doesn't have the revenues to support high wages and you'll quickly figure out why you will pay as much as possible every single time: It means you can buy your way out of hiring the riffraff. Why do you think these high paying jobs were premised on weird trivia tests and other things that had absolutely nothing to do with the job? Hint: It was a social test to see if you'd fit in to the culture.

There have always been legions of people in India ready and able to write code for practically nothing. It was never hard or expensive. But they didn't fit in socially.

Because SWEs don't get paid for code. The code is just one byproduct of making business wants into business reality. We get paid to go figure out how to turn a management wishlist into a reliable money machine.

Most developers in the US are “enterprise” developers working in 2nd tier cities working in banks, government, airlines and unknown startups (including most YC companies) that will never make over $175K inflation adjusted their entire career. Hell the way enterprise developer comp has stagnated over the last decade, they may not see that in nominal terms.

If they paid us for coding they would pay by LOC but that's not the case.

They didn’t. No one getting paid that much was getting paid for their code.

coding is getting your foot in the door to software engineering, which is really like, computer systems engineering. We do so much more than code...

> Now - since you have solved the hardest problem and have all this valuable code - how long will it take you to turn your product into a business and generate enough money to support yourself?

> That's the hard part.

It's now even harder because SNR fell off a cliff. As the effort to produce a product approaches zero, the financial viability of that product goes to zero as well.