Writing code is cheap now

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.

> ...

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

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.

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.

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

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.

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.

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.

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.

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?"

Writing good software is still expensive.

It's going to take everybody a while to figure that out (just like with outsourcing)

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.

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.

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.

Not an employee market, that's for sure.

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

Despire the explosion of AI art, the amount of meaningful art in the world is increased only by a tiny amount.

Owning code is getting more and more expensive.

SWEs sacrificed their jobs so that SREs could have unlimited job security.

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

[0]: https://idiallo.com/blog/writing-code-is-easy-reading-is-har...

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.

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 you could funnel it through something like that then the ability to generate vast amounts of code is a lot more commercially useful

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

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.

Gee what a surprise.

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.

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

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.

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.

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?”

> [...]

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

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.

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.

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.

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

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

https://designexplained.substack.com/p/the-moat-has-moved

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.

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.

[1] https://ai-evals.io

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

Once you get blueprints, and a big enough industrial base, building vast sprawling expanses of factories like VLSI circuits is cheap, then planning reusable, modular, composable, efficient blueprints becomes the real game.

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.

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.

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.

They are right about new habits needed. And this is where everyone should start. Sometimes a quick prompt has killed 5 hours of meetings to discuss if it were worth it.

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

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.

Code is cheap. Show me the talk

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

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?

Automated intelligence is now cheap....

I disagree with this sentiment. This approach leads down to huge maintenance burden.

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.

Same for images, same for videos, probably it's already the same for movies.

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.

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.

after AI producing clean, well tested code takes a day (of reviewing, reprompting, and testing)

It's now so easy to generate, that, almost no matter what you do, there is nothing special or secret about it anymore. Especially when you already host at GitHub or Azure or whatever, it's already inside AI.( Even if you don't, they still get their fingers on it)

I know, because I created an AI help chat bot with a help document and API from a closed source product, made it public and then got accused feeding the AI the source code and needed to take it down.

Nope, it was already inside. The documents and help files etc. got the AI to print out part of the source code lmao.

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?

And LLMs aren’t half as good as maintaining code as they are to generate it in the first place. At least yet.

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

The real cost was never the code itself. It was the decision-making around what to build. That hasn't gotten cheaper at all.