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.
Dollars to donuts that at some point someone is going to discover that senior engineers spend just as much time reviewing, fixing, and dealing with blowups caused by, shitty AI-generated code produced by more junior coders....as they did providing various forms of mentoring of said junior coders, except those junior coders become better developers in the latter case, whereas the AI generates the same shitty results or even worse, inconsistent quality code.
> 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.
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.
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.
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'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.
I was having this conversation at work, where if the promise of AI coding becomes true and we see it in delivery speed, we would need to significantly increase the throughput of all other aspects of the business.
Nice to see you here (Just reached out on bluesky over sandboxing - gandolin). I follow your work and agree and am hoping that you and others who have well earned audiences based on awesome open source work, can help with the advocacy on mental shifts, not just for developers but also non Devs that become builders.
I'm very focused on their minimalistic building experience as a way to make me and other traditional developers, not the bottleneck and empowering them end to end.
I think AI evals [1] are a big part of that route and hope that different disciplines can finally have probable product design stories [2] instead of there being big gaps of understanding between them.
The focus is on downstream, but is upstream ready for this speed up?
The linked blog post draws comparisons to the industrial revolution however in the industrial revolution the speed up caused innovation upstream not downstream.
The first innovation was mechanical weaving. The bottleneck was then yarn. This was automated so the bottleneck became cotton production, which was then mechanised.
So perhaps the real bottleneck of being able to write code faster is upstream.
Can requirements of what to build keep up with pace to deliver it?
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.
Or another way of looking at it: just because digging a ditch became cheap and fast with the backhoe doesn't mean you can just dig a bunch of ditches and become rich.
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.
Code you can’t just throw away is a liability because you have to keep supporting it / servicing it. Claude Code and friends also change that part of the cost equation:
You might not get gcc/llvm level optimization from a newly built compiler - but if you had a home-built one, which took $15,000/month engineer to support (for years!) you can now get a new one for $20,000 every 3 months, for a 50% cost saving, each time changing your requirements (which you couldn’t do before).
Code used to be a liability, like a car or an apartment for the average person. Now it’s a liability, like a car or apartment for Bill Gates.
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
> 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.
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.
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.
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.
This feels to me like peak sfba mentality on par with "move fast and break things". Outside of trying to create a unicorn, is this really how people create things?
It seems to me that in order to obtain the ability to build things that other people like, you need to go through the process of creating things they won't. Like a painter needs to paint a bunch of crappy paintings to learn how to create a good painting. If you have the LLM create these throwaway prototypes, how will you even know when you come across a good idea and how will you be able to build it.
I think the prototype thing is absolutely true but breaks down like all prototypes at the level of collaborating, sharing and evolving while handling entropy throug simplicity UNLESS you know what you're doing or the agent steers you with very opinionated tooling customized to your context. I'm thinking about empowering people to be builders and less so a software developer who can make the right tradeoffs.
Empowering people to work Tracer bullet style after they've selected their prototype of choice and thrown it away might be a powerful pattern that actually gets us into a nice collaborative space.
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.
> the interesting shift is where the time goes. before: thinking + typing. now: thinking + reviewing.
It's widely accepted that you can't learn just by reading, you have to write. So only thinking and reviewing is a great way to lose all the business domain knowledge.
> 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
It's very different - you lose business domain knowledge if you're only reading.
125 comments
[ 7.6 ms ] story [ 95.1 ms ] threadWriting good software is still expensive.
It's going to take everybody a while to figure that out (just like with outsourcing)
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.
> 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.
Owning code is getting more and more expensive.
SWEs sacrificed their jobs so that SREs could have unlimited job security.
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.
Not an employee market, that's for sure.
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.
> 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/
Do we? Spewing features like explosive diarrhea is not something I want.
I'm very focused on their minimalistic building experience as a way to make me and other traditional developers, not the bottleneck and empowering them end to end.
I think AI evals [1] are a big part of that route and hope that different disciplines can finally have probable product design stories [2] instead of there being big gaps of understanding between them.
[1] https://alexhans.github.io/posts/series/evals/measure-first-...
[2] https://ai-evals.io
The linked blog post draws comparisons to the industrial revolution however in the industrial revolution the speed up caused innovation upstream not downstream.
The first innovation was mechanical weaving. The bottleneck was then yarn. This was automated so the bottleneck became cotton production, which was then mechanised.
So perhaps the real bottleneck of being able to write code faster is upstream.
Can requirements of what to build keep up with pace to deliver it?
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.
Turned it into a Stripe revenue dashboard and notifier.
Even bought a couple more, flashed them, and gave to my cofounders, complete with AI written (personally tested, though) setup instructions!
Then "AI" code is even more of a liability.
You might not get gcc/llvm level optimization from a newly built compiler - but if you had a home-built one, which took $15,000/month engineer to support (for years!) you can now get a new one for $20,000 every 3 months, for a 50% cost saving, each time changing your requirements (which you couldn’t do before).
Code used to be a liability, like a car or an apartment for the average person. Now it’s a liability, like a car or apartment for Bill Gates.
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
When it’s trained on enough APL/K code, you’ll get minimal abstraction.
> 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.
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.
[0]: https://idiallo.com/blog/writing-code-is-easy-reading-is-har...
The real cost was never the code itself. It was the decision-making around what to build. That hasn't gotten cheaper at all.
It seems to me that in order to obtain the ability to build things that other people like, you need to go through the process of creating things they won't. Like a painter needs to paint a bunch of crappy paintings to learn how to create a good painting. If you have the LLM create these throwaway prototypes, how will you even know when you come across a good idea and how will you be able to build it.
Empowering people to work Tracer bullet style after they've selected their prototype of choice and thrown it away might be a powerful pattern that actually gets us into a nice collaborative space.
It's widely accepted that you can't learn just by reading, you have to write. So only thinking and reviewing is a great way to lose all the business domain knowledge.
> 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
It's very different - you lose business domain knowledge if you're only reading.