alt Hacker NewsWriting code is cheap now
Comments
Putting text into a file is cheaper than before. Everything else remains the same cost in a well designed project, rather than a vibe coded one where you just tell the LLM to "make a todo list app"
The rule of good fast cheap still applies the same as always, but business leaders consistently choose to ignore this reality and insist upon fast and cheap without acknowledging that it will come at the cost of good.
What's worse, is that these decisions are usually made on a short-term, quarterly basis. They never consider that slowing down today might save us time and money in the long-term. Better code means less bugs and faster bug-fixes. LLMs only exacerbate the business leader's worst tendencies.
I like the idea of we will always need Pilots.
We have autopilot and i'm sure if we tried could automate take off and landing of commercial flights.
But we will keep pilots on planes long after they are needed.
If writing code is cheap now why is there so much money involved?
All writing is cheap now, but good writing is not cheap.
Same for images, same for videos, probably it's already the same for movies.
Let me get this straight so basically with the chatbots everyone is now running faster than ever. Every business thinks they can get an advantage by increasing their velocity relative to their competition. But the competitive is doing the same so what is the outcome?
It feels like businesses are just going to speedrun their lifecycles faster than ever and useful idiots are doing the work of 10 people while getting paid for 1. The asset owning class obviously win as they can squeeze more profits from smaller amount of workers on the short term.
It's like everyone going to Rammstein concert where the people at the seats start standing in order to see better. This forces other to stand too, end result everyone is standing, everyone is worse off and nobody sees any better.
Writing code is 20-100 USD per month now
its funny how we're back again measuring lines of code as the sole indicator for cost/quality etc
Simon gets alot of.. negative feedback, but this is a good description of the current state and I think he does a good job at distilling and expressing where things are currently at. With all the hate and hype for AI everywhere this is a good thing.
"Writing" code is cheap but this just scratches the surface. Its a completely different paradigm. All forms of digital generation is cheap and on the verge of being fully automated which comes with self recursion loops.
Automated intelligence is now cheap....
LLM's have made code cheap in the same way McDonalds has made eating out at a restaurant cheap.
Time for schools to stop pushing coding skills onto the poor kids.
the interesting shift is where the time goes. before: thinking + typing. now: thinking + reviewing. the thinking part didn't get cheaper -- domain knowledge, edge cases, integration constraints -- none of that is free. what changed is you now review AI output instead of type your own, which is genuinely faster but not as different as it sounds. the hard part was always understanding what to build, not the keystrokes.
you'd think this guy would get tired of writing about AI all day
(I wrote this mainly from the perspective of what it feels like on the inside to write code as a human. I think https://news.ycombinator.com/item?id=47138965 explains it better in terms of the business aspect.)
> Code has always been expensive. Producing a few hundred lines of clean, tested code takes most software developers a full day or more. Many of our engineering habits, at both the macro and micro level, are built around this core constraint.
> At the macro level we spend a great deal of time designing, estimating and planning out projects, to ensure that our expensive coding time is spent as efficiently as possible. Product feature ideas are evaluated in terms of how much value they can provide in exchange for that time - a feature needs to earn its development costs many times over to be worthwhile!
This doesn't seem quite right.
"Producing" code involves a lot more than just typing it. It's slow because the dev is planning things out at the same time, at a micro level. Suppose "a few hundred lines" is 10kB of text; actually typing that out at full speed is maybe half an hour of work for a reasonably accomplished typist. But basically nobody even writes blog posts that fast. As soon as you're writing more than a sentence or two and actually care about how you come across (never mind having to satisfy a compiler) you're invoking system 2 thinking. (I didn't even consider tab completion in my napkin math; it wouldn't really matter, because you have to already be thinking to get value out of it!)
Time spent planning isn't really about saving coding time, because it really can't be. It's not like ultra-cheap code production suddenly lets you just implement all the things and see what happens. Features can be net negative, or even outright harmful to the product. It takes resources to evaluate any unplanned change and then integrate it if accepted. (cf. the recent buzz about FOSS projects getting flooded with AI-generated PRs.) Deciding "this feature will/won't be worth the effort" is a rough guess at best, because the actual code/test loop is where you actually hit the unknown unknowns (presumably LLMs would feel the same way, if they were conscious).
And perhaps most importantly, simply meeting feature goals isn't enough. This might be slightly less true in a world where your developers (now partly LLM) don't care about the existing coding style or architecture and can readily adapt on the fly. But I'm still convinced that just letting everything accumulate without a clear vision — without oversight and accountability — will always ultimately lead to a tech-debt reckoning.
Besides which, "a few hundred lines... a full day" is a highly optimistic metric along an axis that has long been understood to make little to no sense. That's a day where things are only added and not removed or changed (to fix them), in a relatively new system (so that interactions with other stuff don't have to be considered). Extrapolating that rate gives you absurd results, e.g. a team of ten developers might re-create the entire Python standard library from scratch in a year.
Well, that becomes more realistic when you already know exactly everything that you're going to do. But the LLM doesn't know that either. In fact, it doesn't even have the advantage of sharing your team's vision and wanting to see it come to fruition. Ask the LLM: "We're creating a new programming language; what modules should the standard library have?" How helpful is that going to be compared to the (human) new guy?
So… XP was the right way all along?
Scathophagidae are flies that really like eating shit. We know how to cheaply produce massive amounts of shit.
But that doesn't mean we solved world hunger. In the same way, AIs churning out millions of lines of code doesn't mean we have solved software engineering.
Actually, I would argue that high LOCs are a liability, not an asset. We have found a very fast way of turning money into slop, which will then need maintenance and delay every future release. Unless, of course, you have an expert code reviewer who checks the AI output. But in that case, the productivity gains will be max 10%. Because thoroughly reviewing code is almost the same amount of work as writing it.
Another person that doesnt seem to understand that the cost of using ai agents is going to skyrocket at some point in the near future.
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.
Sometimes it feels what we are seeing is Code becoming just like any other "asset" in the globalised economy: cheap - but not quality; just like the priors of clothing (disintegrating after a few washes), consumer electronics (cheap materials), furniture (Instagram-able but utterly impracticable), etc: all made for quick turn-overs to rake in more profit and generate more waste but none made to last long.
Understanding computers and programming is not the same as coding.
Put another way: “reading code costs the same as it always did” arguably more when you consider that the cost of reading goes down when the ability read goes up. in other words if you wrote the thing it is likely you can read it fast. but reading someone elses stuff is harder.
Adding cast iron on airplane is cheap now.
On a higher level, this is wishful thinking. However, for people who think this way, getting code to compile at all used to be very "expensive". AI makes abstract code above machine level much easier to compile.
My benchmark for code being cheap is when AI is able to write machine level code. At that point, yes, code is cheap. Currently, the Dollar Store version of code is available.
First there's no "code". There are many different variations. Doing basic UI in React is way different from doing low-level embedded code with locking and mutexes, etc.
AI is quite good at what I call "code in-painting": you give the outlines, and it fills the boring stuff (writing out UI, writing out the test content, etc)
It's still VERY bad at maths. For technical reasons (you can't differentiate a SAT solver, so for now LLMs are mostly "hallucinating" plausible-sounding reasonings, but not doing any "solid math") And when you start reasoning about locks / mutexes, etc, what you're really doing is (some primitive form of) maths and logic.
For now, there's no easy-to-use framework (eg a streamlined way to encode the constraints in Lean / Coq etc) or AI capacities that allow to bridge something like this to make it safe for very "math-like" code. And it's easy to shoot yourself in the foot.
- posting on hackernews has also become cheap which is where there are Nx more Show HN posts but engagement on each has also dropped to 1/N
I think the framing is still too code-centric.
The real bottleneck isn’t writing (or even reviewing) code anymore. It’s:
1. extracting knowledge from domain experts
2. building a coherent mental model of the domain
3. making product decisions under ambiguity / tradeoffs
4. turning that into clear, testable requirements and steering the loop as reality pushes back
The workflow is shifting to:
Understand domain => Draft PRD/spec (LLM helps) => Prompt agent to implement => Evaluate against intent + constraints => Refine (requirements + tests + code) => Repeat
The “typing” part used to dominate the cost structure, so we optimized around it (architecture upfront, DRY everywhere, extreme caution). Now the expensive part is clarity of intent and orchestrating the iteration: deciding what to build next, what to cut, what to validate, what to trust, and where to add guardrails (tests, invariants, observability).
If your requirements are fuzzy, the agent will happily generate 5k lines of very confident nonsense. If your domain model + constraints are crisp, results can be shockingly good.
So the scarce skill isn’t “can you write good code?” It’s “can you interrogate reality well enough to produce a precise model—and then continuously steer the agent against that model?”
i’ve yet to see an agent that can take a figma design and produce high fidelity UI
maybe writing code is cheap . But writing unit tests that actually test stuff that matters is suddenly so much more important and expensive.
I'm consistently shocked at how much cope about AI is still in hacker news threads. Clinging to the idea that human taste and skill in writing code is still no match for AI.
Yes we still need humans in the code loop, but that window is tiny (relative to the lines of code written) and getting smaller quickly.
A new feature with 1000 lines of code can now be written in 2 minutes, and often work just as desired. Yes, almost always something can be refactored, etc, but it works, and it's good.
Denying that code is now MUCH cheaper than it was pre-AI is... head in the sand stuff, I think?
I feel like this article is completely backwards in its premise. It is confusing labor intensity with cost. Software used to be an incredibly labor intensive industry with extremely low automation costs. The cost of running a computer and its associated development environment is so low that it is a rounding error. While you might pay a monthly subscription for an IDE, even that cost barely even registers and it only assists the developer's productivity by a double digit percentage at most.
Here is an illustrative example: Copy paste and traditional code generation features in IDEs (automatically generating getters, setters, hashCode, equals implementations and so on) only reduced the typing of boiler plate code with low cognitive load. This type of code was never very labor intensive to begin with, because it can be reduced down to the act of typing. These tools have made writing code cheap decades ago and you could have written a similar blog post about these tools, because the premise fundamentally misses the actual point.
The cost of writing code has never been an issue in this industry. Software developers don't spend their entire day writing code the same way car mechanics don't spend their day screwing bolts. If you send a car to a mechanic, the mechanic must first diagnose the issue. In some cases the preparatory work is all of the work.
Well another consequence of that is that you’re going to have a lot more tools to maintain.
And LLMs aren’t half as good as maintaining code as they are to generate it in the first place. At least yet.
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.
[dead]
the real shift is that throwaway code became viable for production workflows. i used to spend days writing reusable utility libraries. now i generate single-purpose scripts, run them once, and delete them. the economics of code reuse have fundamentally changed when generation is cheaper than comprehension.
the downstream bottleneck is real though. built a video production pipeline recently - generating the python glue code took maybe 10% of total project time. the other 90% was testing edge cases, tuning ffmpeg parameters, and figuring out why API responses were subtly different between providers. cheap code just means you hit the hard problems faster.
[dead]
[dead]
[dead]
[dead]
[dead]
[flagged]
For everyone who is responding to the "Writing code is cheap now" heading without reading the article, I'd encourage you to scroll down to the "Good code still has a cost" section.
> any time our instinct says "don't build that, it's not worth the time" fire off a prompt anyway
I disagree with this sentiment. This approach leads down to huge maintenance burden.