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.
There's a lot of misconception about the intrinsic economic value of 'writing code' in these conversations.
In software, all the economic value is in the information encoded in the code. The instructions on precisely what to do to deliver said value. Typically, painstakingly discovered over months or years of iteration. Which is exactly why people pay for it when you've done it well, because they cannot and will not rediscover all that for themselves.
Writing code, per se, is ultimately nothing more than mapping that information. How well that's done is a separate question from whether the information is good in the first place, but the information being good is always the dominant and deciding factor in whether the software has value.
So obviously there is a lot of value in the mapping - that is writing the code - being done well and, all else being equal, faster. But putting that cart before the horse and saying that speeding this up (to the extent this is even true - a very deep and separate question) has some driving impact on the economics of software I think is really not the right way to look at it.
You don't get better information by being able to map the information more quickly. The quality of the information is entirely independent of the mapping, and if the information is the thing with the economic value, you see that the mapping being faster does not really change the equation much.
A clarifying example from a parallel universe might be the kind of amusing take about consultancy that's been seen a lot - that because generative AI can produce things like slides, consultancies will be disrupted. This is an amusingly naive take precisely because it's so clear that the slides in and of themselves have no value separate from the thing clients are actually paying for: the thinking behind the content in the slides. Having the ability to produce slides faster gets you nothing without the thinking. So it is in software too.
> 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.
Wasn't writing code always cheap? I see this more like a strawmen argument. What is clean code? Tested code? Should each execution path of a function be tested with each possible input?
I think writing tests is important but you can over do it. Testing code for every possible platform takes of course much time and money.
Another cost factor for code is organization overhead, if adding a new feature needs to go through each layer of the organization signing it off before a user can actually see it. Its of course more costly than the alternative of just pushing to production with all its faults.
There is a big difference of short term cost and long term ones. I think LLMs reduce the short time cost immensely but may increase the long term costs. It will take some real long studies to really show the impact.
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.
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.
Each line of code is a liability.
I think it’s funny that we’re all measuring lines of code now and smiling.
It was/is expensive because engineers are trying to manage the liability exposure of their employers.
Agents give us a fire hose of tech debt that anyone can point at production.
I don’t think the tool itself is bad. But I do think people need to reconsider claims like this and be more careful about building systems where an unaccountable program can rewrite half your code base poorly and push it to production without any guard rails.
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’d like to add an obvious point that is often overlooked.
LLMs take on a huge portion of the work related to handling context, navigating documentation, and structuring thoughts. Today, it’s incredibly easy to start and develop almost any project. In the past, it was just as easy to get overwhelmed by the idea of needing a two-year course in Python (or any other field) and end up doing nothing.
In that sense, LLMs help people overcome the initial barrier, a strong emotional hurdle, and make it much easier to engage in the process from the very beginning.
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.
Here's an easy to understand example. I've been playing EvE Online and it has an API with which you can query the game to find information on its items and market (as well as several other unrelated things).
It seems like a prime example for which to use AI to quickly generate the code. You create the base project and give it the data structures and calls, and it quickly spits out a solution. Everything is great so far.
Then you want to implement some market trading, so you need to calculate opportunities from the market orders vs their buy/sell prices vs unit price vs orders per day etc. You add that to the AI spec and it easily creates a working solution for you. Unfortunately once you run it it takes about 24 hours to update, making it near worthless.
The code it created was very cheap, but also extremely problematic. It made no consideration for future usage, so everything from the data layer to the frontend has issues that you're going to be fighting against. Sure, you can refine the prompts to tell it to start modifying code, but soon you're going to be sitting with more dead code than actual useful lines, and it will trip up along the way with so many more issues that you will have to fix.
In the end it turns out that that code wasn't cheap at all and you needed to spend just as much time as you would have with "expensive code". Even worse, the end product is nearly still just as terrible as the starting product, so none of that investment gave any appreciable results.
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.
code has never been expensive.
ridiculous asks are expensive. Not understanding limitations of computer systems are expensive.
The main problem is, and always will be communication. engineers are in general are quick to say "that won't work as you described" because they can see the steps that it takes to get there. Sales guys (CEOs) live a completely different world and they "hear" "I won't do that" from technical types. It's the ultimate impedance mismatch and the subject of countless seminars.
AI writing code at least reduces the cost of the inevitable failures, but doesn't solve the root problem.
Successful business will continue be those who's CTO/CEO relationship is a true partnership.
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)
Partially why I’m surprised there isn’t more focus on coding harnesses that lean towards strong typing / testing / quasi formal verification type paradigms
If you could funnel it through something like that then the ability to generate vast amounts of code is a lot more commercially useful
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.
Code is cheap is the same as saying "Buying on credit is easy". Code is a liability, not an asset.
Sponsored by: Teleport — Secure, Govern, and Operate AI at Engineering Scale
Gee what a surprise.
The key is what we consider good code. Simon’s list is excellent, but I’d push back on this point:
> it does only what’s needed, in a way that both humans and machines can understand now and maintain in the future
We need to start thinking about what good code is for agents, not just for humans.
For a lot of the code I’m writing I’m not even “vibe coding” anymore. I’m having an agent vibe code for me, managing a bunch of other agents that do the actual coding. I don’t really want to look at the code, just as I wouldn’t want to look at the output of a C compiler the way my dad did in the late ’80s.
Over the last few decades we’ve evolved a taste for what good code looks like. I don’t think that taste is fully transferable to the machines that are going to take over the actual writing and maintaining of the code. We probably want to optimize for them.
This is such a surface level take, it's embarrassing. Unless he's talking about the impression in society, but he is not.
Writing code is a social act even though few actually read it the code, they experience the result of that code.
Maybe, just maybe Simon means "code is disposable now", because some shortcut taker can spin up an apparent duplicate by coaxing and pleading with AI.
That is not a future worth participating in, that's intellectual begging death, because that will create an environment of worthless nonsense.
As someone who uses AI coding agents daily, the thing that still surprises me is how much faster I can iterate on the "problem space" vs the "solution space." I can try 5 different approaches to a problem in the time it used to take to implement one. The code itself is cheap now, but the expensive part—figuring out what to build—hasn't changed. If anything, being able to quickly test ideas makes it more important to be clear on what you're actually trying to solve.
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.
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%.
This fact is opening the floodgates of low-end products, which are somehow better than nothing, but are embarrassing to use.
> We need to build new habits
In my case, testing and documentation becomes even more important.
I’m currently rewriting a server backend that was originally written as a “general-purpose” server, and is very complex. It works extremely well, is robust and secure, but way overkill for my current application.
I'm using an LLM to write a lot of the code. The LLM-written code is quite verbose, and I’m having to learn to just accept that, as it also works well. For a while, I would go in and rewrite the code, but I'm learning to stop doing that. If there's a problem; even an obvious one, I am learning to ask the LLM to fix it, instead of going in and doing it, myself.
Right now, I am writing a headerdoc for the server that is going to be hundreds of lines long. It is a detailed, pedantic description of the API and internal structure of the application.
Its primary audience is LLMs. I need to make sure that future analysis understands exactly why the server does what it does, as well as what it does. The current server is a first step in a (probably years-long) process of migration away from the original server design.
It does seem to be coming along well.
Writing code is cheap.
Owning code is getting more and more expensive.
SWEs sacrificed their jobs so that SREs could have unlimited job security.
> 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.
> 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.
● When everyone has access to the same models, and those models can produce working software quickly and cheaply, the code itself stops being a moat. A reasonably skilled person can now build what used to take a team of engineers months to ship.
● A competitor can reach feature parity in days. The thing that used to protect a business, the sheer effort required to build it, is mostly gone.
● Think of it like oil. If every property owner had a well that was cheap to operate, the price of oil would fall toward the price of water. The resource is abundant, the extraction is easy, and the margin disappears. Software features are heading in the same direction.
> "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."
Well, yes and no. While producing two screens worth of high quality code, a.k.a. software engineering was always expensive, "coding" as such, as in producing Nth React SPA or merely typing out code that you engineered in your head, was never that expensive - most of the work is applying existing patterns. But either way, as you wrote the code yourself, you mostly had a consistent mental model of how your code should work and the key contribution was evolving this model, first in your head, then in typing out code. Now here comes the real problem for the LLMs: I think most of us would be fine if the LLMs could actually just type out the code for us after we engineered it in our heads and explained it to the LLM in English language. Alas, they do produce some sort of code, but not always, or often enough not in a way we desribed it. So unfortunately "AI" boosters like Simon are reverting back to the argument of fast code generation and an appeal to us as unwilling adopters, to "change our ways", as it shows they have no real advantage of the LLMs to put forward - its only ever the "coding" speed and an appeal to us as professionals to "adapt", i.e. serve as cleaners of LLM sh*t. Where is the superintelligence we were promised and single-person-billion dollar unicorns, unique use cases etc? Are you telling us again these are just advanced text generators, Simon?
When did we ever measure the value of code by quantity, not quality? The author is misguided.
> 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.
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.
> 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.
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.
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 agree, writing code is cheaper than ever ... but "writing the code" isn't the main challenge in SWE since decades.
Our IT infrastructures & applications run on a stack that has grown for the past 40 years and what we are currently doing with all this LLM & vibecode mania is adding more stuff (at an accelerated rate) on the top of the stack.
The main challenge today is combining the user requirements with the stack in a way it works, it's easy to maintain and it donesn't cost too much.
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...
Agentic coding are bringing new people to coding. But instead of reading some books about coding or looking at the history, they face the same problems as before, they have the same struggle and they re-invent the same solutions.
I am waiting for the vibe coding expert posts that will tell us that lines of code are not a good measure, it is a liability and you should instruct your agent to write less code ...
Writing code has always been cheap. Deciding what the logic should be, and being able to change course was the hard bit.
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.
Who's going to maintain all the cheap code and review it? Is the "software janitor" job title becoming reality now?
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.
AI agents is like outsourcing to a bad team offshore - yeah they can build and maybe cheap but requires lots of hand holding.
> 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.
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.
Not sure if “code has always been expensive” is the right framing.
Typing out a few hundred lines of code was never the real bottleneck. What was expensive was everything around it: making it correct, making it maintainable (often underestimated), coordinating across teams and supporting it long term.
You can also overshoot: Testing every possible path, validating across every platform, or routing every change through layers of organizational approval can multiply costs quickly. At some point, process (not code) becomes the dominant expense.
What LLMs clearly reduce is the short-term cost of producing working code. That part is dramatically cheaper.
The long-term effect is less clear. If we generate more code, faster, does that reduce cost or just increase the surface area we need to maintain, test, secure, and reason about later?
Historically, most of software’s cost has lived in maintenance and coordination, not in keystrokes. It will take real longitudinal data to see whether LLMs meaningfully change that, or just shift where the cost shows up.