Live data from Hacker News

Writing code is cheap now

simonwillison.net

241–250 of 522 posts

Re: Writing code is cheap now

#241

Earlier quoted context omitted.

I wouldn't say it hasn't shown up. The number of ShowHN's per weekend has definitely gone up, and while that isn't rigorous scientific proof, I'd consider is a leading edge indicator of something . Unfortunately, we as an industry have yet to agree on anything approaching a scientific measure of productivity, other than to collectively agree that Lines of Code is universally agree that LoC is terrible. Thus even if s…

There was a post a few days ago about how the quality of SnowHN had gone down with people asking how they could block this category of submissions - so I wouldn't be too quick to equate an increase in ShowHN with anything positive.

Whether or not it is positive is a matter of opinion, but it undeniable that the ShowHNs exist.

Re: Writing code is cheap now

#242
Writing code was always cheap! You could outsource for inconsequential amounts of money and get massive amounts of code in return. Yet, the vast majority of companies do not do so. Because coding is not the hard part of being a software engineer / programmer.

That's like saying that photography killed painting because it saved you from having to draw things. Drawing is basically free now, I just take the photo. But the number of painters (and by that I mean, artists who paint) is dramatically higher today than in 1800. Artists didn't die because of mechanical reproduction, they flourished, because that wasn't the problem they were solving.

Re: Writing code is cheap now

#243
post #203

Every modern (and not so modern) software development method hinge on one thing: requirements are not known and even if known they'll change over time. From this you get the goal of "good" code which is "easy to change code". Do current LLM based agents generate code which is easy to change? My gut feeling is a no at the moment. Until they do I'd argue code generated from agents is only good for prototypes. Once you…

I'd add in "code is easier to write than it is to read" - hence abstraction layers designed to present us with higher level code, hiding the complex implementations.

But LLMs are both really good at writing code _and_ reading code. However, they're not great at knowing when to stop - either finishing early and leaving stuff broken, over-engineering and adding in stuff that's not needed or deciding it's too hard and just removing stuff it deems unimportant.

I've found a TDD approach (with not just unit tests but high-level end-to-end behaviour-driven tests) works really well with them. I give them a high-level feature specification (remember Gherkin specifications?) and tell it to make that pass (with unit tests for any intermediate code it writes), make sure it hasn't broken anything (by running the other high-level tests) then, finally, refactor. I've also just started telling it to generate screenshots for each step in the feature, so I can quickly evaluate the UI flow (inspired by Simon Willison's Rodney tool).

Now I don't actually need to care if the code is easy to read or easy to change - because the LLM handles the details. I just need to make sure that when it says "I have implemented Feature X" that the steps it has written for that feature actually do what is expected and the UI fits the user's needs.

Re: Writing code is cheap now

#244
post #174

Earlier quoted context omitted.

For most non-hobby project, the cost of code was in breaking a working system (whether by a bona fide bug, or a change in some unspecified implicit assumption). That made changes to code incredibly expensive - often much more than the original implementation. It sounds harsh, but over the lifetime of a project, 10-lines/person/day is often a high estimate of the number of lines produced. It’s not because humans type…

> if the constraints and tests are reasonably well specified. if they are, then why would a human be so slow? You're not comparing the same situation.

The human in that case is not "so slow", but at the current state it is slower than an LLM as simple as that.

The difference comes in confidence that the solution works and can be maintained in the future, but in terms of purely making the decisions and applying the changes an LLM is faster when it has all the required infos available

Re: Writing code is cheap now

#245
post #240
post #203

Every modern (and not so modern) software development method hinge on one thing: requirements are not known and even if known they'll change over time. From this you get the goal of "good" code which is "easy to change code". Do current LLM based agents generate code which is easy to change? My gut feeling is a no at the moment. Until they do I'd argue code generated from agents is only good for prototypes. Once you…

I am constantly getting LLMs to change features and fix bugs. The key is to micromanage the LLM and its context, and read the changes. It's slower that vibe coding but faster than coding by hand, and it results in working, maintainable software.

A study last year concluded that while AI coding feels faster it actually isn't. At least in mid 2025.

https://news.ycombinator.com/item?id=44522772

Re: Writing code is cheap now

#246
post #203

Every modern (and not so modern) software development method hinge on one thing: requirements are not known and even if known they'll change over time. From this you get the goal of "good" code which is "easy to change code". Do current LLM based agents generate code which is easy to change? My gut feeling is a no at the moment. Until they do I'd argue code generated from agents is only good for prototypes. Once you…

All the hype is on how fast it is to produce code. But the actual bottleneck has always been the cost of specifying intent clearly enough that the result is changeable, testable, and correct AND that you build something that brings value.

[dead]

Re: Writing code is cheap now

#248

The interesting thing nobody's talking about here is that cheap code generation actually makes throwaway prototypes viable. Before, you'd agonize over architecture because rewriting was expensive. Now you can build three different approaches in a day and pick the one that works. The real cost was never the code itself. It was the decision-making around what to build. That hasn't gotten cheaper at all.

I think the prototype thing is absolutely true but breaks down like all prototypes at the level of collaborating, sharing and evolving while handling entropy throug simplicity UNLESS you know what you're doing or the agent steers you with very opinionated tooling customized to your context. I'm thinking about empowering people to be builders and less so a software developer who can make the right tradeoffs. Empowerin…

[dead]

Re: Writing code is cheap now

#249
post #229

Earlier quoted context omitted.

> I find that even though the cost of writing code is immensely cheap, reviewing and validating that it works in certain code bases (like the millions of line mono repo I work in at my job) is extremely high. That is my observation as well. Churning code is easy, but making sure the code is not total crap is a completely new challenge and concern. It's not like prior to LLMs code reviews didn't required work. Far fro…

What tremendously helps is asking the LLM to add a lot a lot explanations by adding comments to each and every line or function. You can remove those comments afterwards if you feel they are too much but it helps a lot the reviewing. More a trick than a silver bullet but it's nice.

> What tremendously helps is asking the LLM to add a lot a lot explanations by adding comments to each and every line or function.

No, it doesn't. It's completely useless and unhelpful. These machine-generated comments are only realizations of the context that already outputted crap. Dumping volumes of this output adds more work to reviewers to parse through to figure out the mess presented by vibecoders who didn't even bothered to check what they are generating.

Re: Writing code is cheap now

#250
> Here's what I mean by "good code": [...]

What a fantastic list. I'll be saving it to show the junior developers.

My only nitpick is that "reliability" should have been a point by itself. All the other "ilities" can be appropriately sacrificed in some context, but I've never seen unreliable software being praised for its code quality.

Which is part of why LLMs are so frustrating. They're extremely useful and extremely unreliable.

Post reply on HN