alt Hacker NewsWriting code is cheap now
Comments
> 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.
> ...
> Writing good code remains significantly more expensive
I think this is a bad argument. Code was expensive because you were trying to write the expensive good code in the first place.
When you drop your standards, then writing generated code is quick, easy and cheap. Unless you're willing to change your standard, getting it back to "good code" is still an equivalent effort.
There are alternative ways to define the argument for agentic coding, this is just a really really bad argument to kick it off.
Code generation is cheap in the same way talk is cheap.
Every human can string words together, but there's a world of difference between words that raise $100M and words that get you slapped in the face.
The raw material was always cheap. The skill is turning it into something useful. Agentic engineering is just the latest version of that. The new skill is mastering the craft of directing cheap inputs toward valuable outcomes.
I basically fully agree with this. I am not sure how to handle the ramifications of this in my day to day work yet. But at least one habit I have been forming is sometimes 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. I try to think through, and improve, our testability such that a few hundred line of code change that modifies the DB really can be a couple of hours of work.
Also, I do want to note that these little "Here is how I see the world of SWE given current model capabilities and tooling" posts are MUCH appreciated, given how much you follow the landscape. When a major hype wave is happening and I feel like I am getting drowned on twitter, I tend to wonder "What would Simon say about this?"
The cost of code never lived in the typing — it lived in the intent, the constraints, and the reasoning that shaped it. LLMs make the typing cheap, but they don’t make the reasoning cheap. So the economics shift, but the bottleneck doesn’t disappear.
I'm going to shill my own writing here [1] but I think it addresses this post in a different way. Because we can now write code so much faster and quicker, everything downstream from that is just not ready for it. Right now we might have to slow down, but medium and long term we need to figure out how to build systems in a way that it can keep up with this increased influx of code.
> The challenge is to develop new personal and organizational habits that respond to the affordances and opportunities of agentic engineering.
I don't think it's the habits that need to change, it's everything. From how accountability works, to how code needs to be structured, to how languages should work. If we want to keep shipping at this speed, no stone can be left unturned.
[1]: https://lucumr.pocoo.org/2026/2/13/the-final-bottleneck/
I like using the analogy of 'living in a small apartment' when building systems with a small team. You need to choose carefully what furniture you can fit into your apartment, and that choice depends a lot on how you live your live. Do you want a large table to host friends, or a comfortable couch to fall asleep on in front of the TV? If you get both the space will probably be cluttered.
The same applies to a small software project - you need to choose what features you can fit. And while the cost of building is part of the consideration, I'd say most of it is about the cost of maintaining features, not only in code, but also in product coherence and other incidental 'costs' like documentation and user support.
Be careful of building too many features and ending up being overwhelmed by the maintenance, or worse, diluting the product's value to a point where you loose users.
I don't agree that the code is cheap. It doesn't require a pipeline of people to be trained and that is huge, but it's not cheap.
Tokens are expensive. We don't know what the actual cost is yet. We have startups, who aren't turning a profit, buying up all the capacity of the supply chain. There are so many impacts here that we don't have the data on.
When did we ever measure the value of code by quantity, not quality? The author is misguided.
I am pushing for this judicious Eval [1] Driven Development where tech/non tech users use intent when coding to minimally design some known aspects and try to build simply and using common standards across the team (that should be in the context of the agent) to produce the minimal amount of human readable and clean code that would do the job. The more the building blocks they work with are simple, easy to validate and rely on the proper unit tests, integration tests, data tests the more chance that things can be "one shotted".
One huge barrier is fighting entropy. You should be wary of prototypes which create false expectations and don't help product evolution whereas tracer bullets [2] might be better if you want to quickly show something and adjust.
Testing and testability are concepts that aren't intuitive or easy until you develop a feel for them so we should be preaching feeling that pain and moving slowly and with intent and working minimally [3] when you actually want to share or maintain your coding artifact. There should be no difference between judicious human and computer code. Don't suddenly start putting What instead of why in comments or repeating everything.
Helping non tech people become builders or sharers is a challenge beyond "vibe coding" and the agent skills [4] space is fascinating for that. Like most things AI (LLM), UX matters more than almost anything else.
[2] concept from the Pragmatic Programmer, https://www.aihero.dev/tracer-bullets
[3] https://alexhans.github.io/posts/series/evals/measure-first-...
[4] https://alexhans.github.io/posts/series/evals/building-agent...
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.
The cost has always been the sum of:
1. The time spent to think and iteratively understand what you want to build 2. The time spent to spell out how you want to build it
The cost for #2 is nearly zero now. The cost for #1 too is slashed substantially because instead of thinking in abstract terms or writing tests you can build a version of the thing and then ground your reasoning in that implementation and iterate until you attain the right functionality.
However, once that thing is complex enough you still need to burn time on identifying the boundaries of the various components and their interplay. There is no gain from building "a browser" and then iterating on the whole thing until it becomes "the browser". You'll be up against combinatorial complexity. You can perhaps deal with that complexity if you have a way to validate every tiny detail, which some are doing very well in porting software for example.
Writing code has been cheap for a while now.
Writing good software is still expensive.
It's going to take everybody a while to figure that out (just like with outsourcing)
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"
It's like the allegory of the retired consultant's $5000 invoice (hitting the thing with a hammer: $5, knowing where to hit it: $4995).
Yeah, coding is cheaper now, but knowing what to code has always been the more expensive piece. I think AI will be able to help there eventually, but it's not as far along on that vector yet.
> Here's what I mean by "good code":
> [...]
> - It’s simple and minimal - it does only what’s needed, in a way that both humans and machines can understand now and maintain in the future.
But do the humans need to actually understand the code? A "yes" means the bottleneck is understanding (code review, code inspection). A "no" means you can go faster, but at some risk.
Code is cheap is the same as saying "Buying on credit is easy". Code is a liability, not an asset.
I'm very curious to see how this will affect the job market. All the recent CS grads, all the coding bootcamp graduates - where would they end up in? And then there's medium/senior engineers that would have to switch how they work to oversee the hordes of AI agents that all the hype evangelists are pushing on the industry.
Not an employee market, that's for sure.
AI agents is like outsourcing to a bad team offshore - yeah they can build and maybe cheap but requires lots of hand holding.
This fact is opening the floodgates of low-end products, which are somehow better than nothing, but are embarrassing to use.
Writing code is cheap.
Owning code is getting more and more expensive.
SWEs sacrificed their jobs so that SREs could have unlimited job security.
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.
> 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!
Maybe I am spending my life working at the wrong corporations (not FAANG/direct tech related), but that doesn't match at all my experience. The `design` phase was reduced to something more akin to a sketch in order to get faster iterating products. Obviously that now, as you create and debate over more iterations, the time for writing code is increased (as you built more stuff that is discarded). What is that discarded time used for? Well, it's the way new people learn the system/business domain. It's how we build the knowledge to support the product in production. It's how the business learns what are the limits/features, why they are there, what they can offer, what they must ask the regulators etc.
Realistically, if you only count the time required to develop the feature as described, is basically nothing. Most of the time is spent on edge-cases that are not written anywhere. You start coding something and 15m in you discover 5-10 cases not handled in any way. You ask business people, they ask other people. You start checking regulation docs/examples, etc. etc. Maybe there are no docs available, so you just push a version, and test if you assumptions are correct (most likely not...so go again and again). At the end of this process everyone gains a better understanding on how the business works, why, and what you can further improve.
Can AI speedrun this? Sure, but then how will all the people around gain the knowledge required to advance things? We learn through trial and error. Previously this was a shared experience for everyone in the business, now it becomes more and more a solitary experience of just speaking with AI.
I think there's a good parallel with AI images - generating pictures has gotten ridiculously easy and simple, yet producing art that is meaningful or wanted by anyone has gotten only mildly easier.
Despire the explosion of AI art, the amount of meaningful art in the world is increased only by a tiny amount.
Software is rarely an end unto itself.
Thus, "Code" is a liability; Producing excess liabilities 'cheaply' is still a loss.
You only ever want to have just enough code to accomplish the task at hand.
LLMs may help you get to just enough faster, but you'll only know that you are there after doing the second 90%.
its funny how we're back again measuring lines of code as the sole indicator for cost/quality etc
> It’s simple and minimal
This. All LLM code I saw so far was lots of abstraction to the point that it’s hard to maintain.
It is testable for sure, but the complications cost is so high.
Something else that is not addressed in the article is working within enterprise env where new technologies are adopted in much slower paces compared to startups. LLMs come with strange and complicated patterns to solve these problems, which is understandable as I would imagine all training and tuning were following structured frameworks
If coding is so cheap, I hope people start vibing Rust. If the machine can do the work, please have it output in a performant language. I do not need more JS/Python utilities that require embarrassing amounts of RAM.
Time for schools to stop pushing coding skills onto the poor kids.
Yes writing code is easier than ever, my problem is that understanding it still costs the same if not more [0]. I get that when people use agents, understanding code is not the concern because it's not exactly catering to people, it's for other agents. But when maintaining applications that have been running for years now, I still believe we need to fully understand code before we commit.
[0]: https://idiallo.com/blog/writing-code-is-easy-reading-is-har...
> Good code still has a cost
> Delivering new code has dropped in price to almost free... but delivering good code remains significantly more expensive than that.
Writing code was always cheap to start with. Just outsource it to the lowest bidder. Writing good code remains as expensive.
The same when programmers from different languages are considered. How many Scala/Haskell engineers can I find compared to Java is not the question. It is about how many good engineers you can hire. With Haskell that pool is definitely denser.
One of the biggest challenges right now in my opinion is disambiguating what processes _were_ necessary from those that are _still_ necessary and useful in light of exactly this.
Writing code has always been cheap. Deciding what the logic should be, and being able to change course was the hard bit.
This is the first "chapter" in a not-quite-book I've started working on - I have an introductory post about that here: https://simonwillison.net/2026/Feb/23/agentic-engineering-pa...
The second chapter is more of a classic pattern, it describes how saying "Use red/green TDD" is a shortcut for kicking the coding agent into test-first development mode which tends to get really good results: https://simonwillison.net/guides/agentic-engineering-pattern...
I see lot of comments downplaying the significance of this but other than very large and/or mission critical infrastructure roles, your "taste and experience" is going to become cheap just like code.
Currently there is this notion that white collar workers and artists still have which is that they bring "taste" too to the experience but eventually AI will come for those as well, may or may not be LLM, and not sure about timelines.
Even as we speak, when I read through HN comments, I always ask : "Did an AI write this" or did someone use AI to help write their response. This goes beyond HN but any photo or drawing or music I hear now I ask the same question but eventually nobody will care because we are climbing out of uncanny valley very quickly.
LLM's have made code cheap in the same way McDonalds has made eating out at a restaurant cheap.
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?”
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?
"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....
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.
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.
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.
i’ve yet to see an agent that can take a figma design and produce high fidelity UI
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 can ask your agent to change a feature and be 100% sure they won't break other features then you don't care about how the code looks like.