Writing code is cheap now
simonwillison.net73 points by swolpers 6 hours ago
73 points by swolpers 6 hours ago
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.
> The new skill is mastering the craft of directing cheap inputs toward valuable outcomes.
Strongly agree with this. It took me awhile to realize that "agentic engineering" wasn't about writing software it was about being able to very quickly iterate on bespoke tools for solving a very specific problem you have.
However, as soon as you start unblocking yourself from the real problem you want to solve, the agentic engineering part is no longer interesting. It's great to be solving a problem and then realize you could improve it very quickly with a quick request to an agent, but you should largely be focused on solving the problem.
Yet I see so many people talking about running multiple agents and just building something without much effort spent using that thing, as though the agentic code itself is where the value lies. I suspect this is a hangover from decades where software was valuable (we still have plenty of highly valued, unprofitable software companies as a testament to this).
I'm reminded a bit of Alan Watts' famous quote in regards to psychedelics:
> If you get the message, hang up the phone.
If you're really leveraging AI to do something unique and potentially quite disruptive, very quickly the "AI" part should become fairly uninteresting and not the focus of your attention.
It's funny that so many people are using AI and still hasn't really shown up in productivity numbers or product quality yet. I'm going to be really confused if this is still the case at the end of the year. A whole year of access to these latest agentic models has to produce visible economic changes or something is wrong.
I used to think this was a sign that AI code isn't really useful, but I've changed my tune (also I believe these numbers have changed in the last few months).
As an example: One of my most promising projects I was discussing with a friend and we realized together we could potentially use these tools to build a two person agency with no need to hire anyone ever. If this were to work, could theoretically make nice revenue and it shouldn't show up in any metric anywhere.
Additionally I've heard of countless teams cancelling their contracts with outsourced engineers because cheap but bad coders in India are worse that an LLM and still cost more. I'm not sure if there's a number around this activity, but again, these type of changes don't show up in the usual places.
My current belief is not that AI will replace traditional software engineering it will replace a good chunk of the entire model of software.
>funny that so many people are using AI and still hasn't really shown up in productivity numbers or product quality yet.
That's because the threat is now not other businesses, but your own users who decide to vibe-code their own "Claw" product instead of using your company's vibeslop, so there are no buyers for your single-week product. All these new harness developers are engaging in resume-driven development to save their own asses. The only ones that are not naked when the tide recedes are the ones that are able to jump to the next layer of abstraction on the infinite staircase, until the next tide comes five seconds later.
I think we’re falling into a trap of overestimating the value of incrementally directing it. The output is all coming from the same brain so what stops someone just getting lucky with a prompt and generation that one-shots the whole thing you spent time breaking down and thinking about. The code quality will be the same, and unless you’re directing it to the point where you may as well be coding the old way, the decision-making is the same too.
Raising $100M doesn’t even mean you have a good idea or an idea people like or an idea you can even make money on.
It’s probably a better indicator of a good business idea than if you get slapped in the face…
And yet, who would you trust more - a CEO that raised 100M on their "vision" or someone who got slapped in the face?
A raise is random noise, not signal, based a confidence game within the VC ecosystem. LP capital call->GP gamble based on waves arms around considering VC underperforms as an asset [1] [2] class even when accounting for the grand slam returns. It's 0DTE options gambling dressed up as skill and an art. But, you know [3] [4] [5], lottery still pays out sometimes.
TLDR A raise is not robust signal in this regard.
[1] https://news.ycombinator.com/item?id=7260137
[2] https://www.linkedin.com/posts/peterjameswalker_most-venture...
[3] https://en.wikipedia.org/wiki/There%27s_a_sucker_born_every_...
Indeed: The act of actually typing the code into an editor was never the hard or valuable part of software engineering. The value comes from being able to design applications that work well, with reasonable performance and security properties.
It wasn't the hard or valuable part of software engineering, but it was a very time-consuming part. That's what's interesting about this new era - the time-consuming-but-easy bit has suddenly stopped being time-consuming.
Agreed, often see cope from managers along the line of “writing the code was never the bottleneck”. Well, sure felt like it.
Then why did most software fail to do that even before the advent of LLMs?
Because designing systems that work well is difficult. It takes years of experience to develop the muscle memory behind quality systems architecture. Writing the code is an implementation detail (albeit a large one).
Because coding bootcamps and CS programs were churning out squillions of people who could type the code but had poor design and analytical skills, because there was a time where being able to implement Dijkstra on a whiteboard would get you 400k at a FAANG.
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/
One of the most interesting aspects is when LLMs are cheap and small enough so that apps can ship with a builtin one so that it can adjust code for each user based on input/usage patterns.
If this could ever happen, there will be no point in GUI apps anymore, your AI assistant or what have you will just interact with everything on your behalf and/or present you with some kind of master interface for everything.
I don't see a bunch of small agents in the future, instead just one per device or user. Maybe there will be a fleeting moment for GUI/local apps to tie into some local, OS LLM library (or some kind of WebLLM spec) to leverage this local agent in your app.
Agents will still have to communicate with each other, the communication protocols, how data is stored, presented and queried will be important for us to decide?
Will we stop using web browsers as we understand them today in the next few decades in favor of only interacting with agents? Maybe.
I've heard this referenced multiple times and I have yet to hear the value be clearly articulated. Are you saying that every user would eventually be using a different app? Wouldn't it eventually get to the point that negates the need for the app developer anyways since you would eventually be unable to offer any kind of support, or are we just talking design changing while the actual functionality stays the same? How would something like this actually behave in reality?
I don't know!
These are valid points, taken to the extreme we will have apps that cannot be supported.
In short term, we already have SQL/reports being automated. Lovable etc is experimenting with generating user interfaces from prompts, soon we will have complete working apps from a prompt. Why not have one core that you can expand via a prompt?
I am currently studying and depending heavily on Anki, its been amazing to use Claude Code to add new functionality on the fly. Its a holy mess of inconsistent/broken UX but it so clearly gives me value over the core version. Sometimes it breaks, but CC can usually fix it within a prompt or two.
> I've heard this referenced multiple times and I have yet to hear the value be clearly articulated.
Me too, and I see this as _incredibly_ wasteful.
I don’t think we can expect all workers at all companies to just adopt a new way of working. That’s not how competition works.
If agentic AI is a good idea and if it increases productivity we should expect to see some startup blowing everyone out of the water. I think we should be seeing it now if it makes you say ten times more productive. A lot of startups have had a year of agentic AI now to help them beat their competitors.
We're already seeing eye-watering, blistering growth from the new hot applied AI startups and labs
Imo the wave of top down 'AI mandates' from incumbent companies is a direct result of the competitive pressure, although it probably wont work as well as the execs think it will
that being said even Dario claims a 5-20% speedup from coding agents, 10x productivity only exists in microcosm prototypes, or if someone was so unskilled oneshotting a localhost web app is a 10x for them
"eye-watering, blistering growth from the new hot applied AI startups and labs"
Could you give us a few examples?
Claude Cowork was apparently built in less than two weeks using Claude Code, and appears to be getting significant usage already.
Only a personal anecdote, but the humans I know that have used it are all aware of how buggy it is. It feels like it was made in 2 weeks.
Which gets back to the outsourcing argument: it’s always been cheap to make buggy code. If we were able to solve this, outsourcing would have been ubiquitous. Maybe LLMs change the calculus here too?
That's certainly a good example of a tool developed quickly thanks to AI assistance.
But coding assistance tools must themselves be evaluated by what they produce. We won't see significant economic growth through using AI tools to build other AI tools recursively unless the there are companies using these tools to make enough money to justify the whole stack.
I believe there are teams out there producing software that people are willing to pay for faster than they did before. But if we were on the verge of rapid economic growth, I would expect HN commenters to be able to rattle these off by the dozen.
claude code 1B+ arr
ant 10xing ARR, oai
harvey legora sierra decagon 11labs glean(ish) base10(infra) modal(infra) gamma mercor(ish) parloa cognition
regulated industries giving these companies 7/8-fig contracts less than 2 years from incorporation
AI has been a lifesaver for my low performing coworkers. They’re still heavily reliant on reviews, but their output is up. One of the lowest output guys I ever worked with is a massive LinkedIn LLM promoter.
Not sure how long it’ll last though. With the time I spend on reviews I could have done it myself, so if they don’t start learning…
OpenClaw went from first commit in late November to Super Bowl commercial (it's meant to be the tech behind that AI.com vaporware thing) in February.
(Whether you think OpenClaw is good software is kind of beside the point.)
It’s very much not beside the point. Productivity is measured in how much value you get out from the hours your workers put in.
But that only gets you to a philosophical argument about what "value" is. Many would argue that being able to get your thing into a Super Bowl commercial is extremely valuable. I definitely have never built anything that did.
It's very much imperfect, but the only consistently agreed upon and useful definition of "value" we have in the West is monetary value, and in that sense, we have at least a few major examples of AI generating value rapidly.
OK but that also means VR was a success, and web 3, and NFTs.
Well, yes, these were definitely a success for some. And I personally still believe that VR will be a success in the longer-term.
In any case, I agree with the grandparent post about the distinction between being successful and good.
>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.
Why? Why do we need to "write code so much faster and quicker" to the point we saturate systems downstream? I understand that we can, but just because we can, does'nt mean we should.
> to the point we saturate systems downstream
But that's point of TFA, no? Now that writing code is no longer the bottleneck, the upstream and downstream processes have become the new bottlenecks, and we need to figure out how to widen them.
As I see it, the end goal for all of this is generating software at the speed of thought, or at least at the speed of speech. I want the digital butler to whom I could just say - "I'm not happy with the way things happened to day, please change it so that from here on, it'll be like x" - and it'll just respond with "As you wish", and I'll have confidence that it knows me well enough and is capable enough to have actually implemented the best possible interpretation of what I asked for, and that the few miscommunications that do occur would be easy to fix.
We're obviously not close that yet, but why shouldn't we build towards it?
> Now that writing code is no longer the bottleneck
I think it’s contestable that writing the code was ever the main bottleneck.
> As I see it, the end goal for all of this is generating software at the speed of thought, or at least at the speed of speech.
The question is what distinguishes that from having AGI, and if the answer is “nothing”, then that will change the whole game entirely again.
Oh, absolutely, my vision depends on AGI (and maybe even ASI), and I definitely agree that it'll be a whole new ball game.
If we want to continue to ship at that speed we will have to. I’m not sure if we should, but seemingly we are. And it causes a lot of problems right now downstream.
We were already rushing and churning products and code of inferior quality before AI (let's e.g. consider the sorry state of macOS and Windows in the past decade).
Using AI to ship more and more code faster, instead of to make code more mature, will make this worse.
I want to use AI to ship more and more code faster and better. If AI means our product quality goes down we should figure out better ways to use it.
I'm betting on it meaning the product quality going down - and technical debt increasing, which will be dealt with more AI in a downward spiral. Meanwhile college CS majors wont ever bother learning the basics (as AI will handle their coursework, and even their hobby work). Then future AI will train on previous AI output, with the degredation that brings...
Totally agree - that's what I was trying to get at with "organizational habits". The way we plan, organize and deliver software projects is going to radically change.
I'm not ready to write about how radically though because I don't know myself!
The linked article is worth reading alongside this one.
The thing I'd add from running agents in actual production (not demos, but workflows executing unattended for weeks): the hard part isn't code volume or token cost. It's state continuity.
Agents hallucinate their own history. Past ~50-60 turns in a long-running loop, even with large context windows, they start underweighting earlier information and re-solving already-solved problems. File-based memory with explicit retrieval ends up being more reliable than in-context stuffing - less elegant but more predictable across longer runs.
Second hard part: failure isolation. If an agent workflow errors at step 7 of 12, you want to resume from step 6, not restart from zero. Most frameworks treat this as an afterthought. Checkpoint-and-resume with idempotent steps is dramatically more operationally stable.
Agree it's not just habits - the infrastructure mental model has to change too. You're not writing programs so much as engineering reliability scaffolding around code that gets regenerated anyway.
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.
Writing code is cheaper than ever. Maintaining it is exactly the same as ever and it scales with the LOC.
Code is still liability but it's undeniable that going from thought to running code is very cheap today.
You completely ignored the post you're replying to.
To recap, the author disagrees that writing code is cheap, because we've collectively invested trillions of dollars and redirected entire supply chains into automating code generation. The externalities will be paid for generations to come by all of humanity; it's just not reflected in your Claude subscription.
GP is not totally ignoring the post he replied to: we have models that are basically 6-months behind closed SOTA models and that we can run in the cloud and we fully know how much these costs to run.
The cat is out of the bag: compute shall keep getting cheaper as it's always been since 60 years or something.
It's always been maintenance that's been the killer and GP is totally right about that.
And if we look at a company like Cloudflare who basically didn't have any serious outage for five years then had five serious outages in six months since they drank the AI kool-aid, we kinda have a first data point on how amazing AI is from a maintenance point of view.
We all know we're generating more lines of underperforming, insecure, probably buggy, code than ever before.
We're in for a wild ride.
Maintaining it is becoming more costly. The increasing burden of review on FOSS maintainers is one example. AWS going down because an agent decided to re-write a piece of critical infrastructure is another. We are rapidly creating new kinds of liability.
This burden of review will go down as FOSS maintainers involve AI more.
unlikely, FOSS is mostly driven by zero-cost maintenance but AI tools needs money to burn. So only few FOSS project will receive sponsored tools and some definitely reject to use by ideological reasons (for example it could be considered as poison pill from copyright perspective).
> We don't know what the actual cost is yet.
We kind of do? Local models (thought no state of the art) set a floor on this.
Even if prices are subsidized now (they are) that doesn't mean they will be more expensive later. e.g. if there's some bubble deflation then hardware, electricity, and talent could all get cheaper.
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)
Yeah, it’s odd watching the outsourcing debate play out again. The results are gonna be the same.
Which is a shame, cause I think LLMs have a lot more use for software dev than writing code. And that’s really what’s going to shift the industry - not just the part willing to cut on quality.
Code is cheap is the same as saying "Buying on credit is easy". Code is a liability, not an asset.
I would normally agree, but I think the "code is a liability" quote assumes that humans are reading and modifying the code. If AI tools are also reading and modifying their own code, is that still true?
You have to be able to express the change you want in natural language. This is not always possible due to ambiguity.
Next to that, eventually you run into the same issue that we humans run into: no more context windows.
But we as software engineers have learned to abstract away components, to reduce the cognitive load when writing code. E.g., when you write file you don't deal with syscalls anymore.
This is different with AI. It doesn't abstract away things, which means you requesting a change might make the AI make a LOT of changes to the same pattern, but this can cause behavior to change in ways you haven't anticipated, haven't tested, or haven't seen yet.
And because it's so much code to review, it doesn't get the same scrutiny.
I think you mean to say, "code you don't understand is a liability, not an asset"
But please correct me if I'm wrong.
No I said what I meant. Code is a liability, though to your point, code you don't understand is an even bigger liability.
Even if I understand all my code, when I go to make changes, if it's 100k lines of code vs 2k lines of code, it's going to take more time and be more error prone.
Even if I understand all my code, the intern I hired last week won't and I'll have to teach it to them.
Even if I understand all my code, I don't remember everything all the time and I can forget about an edge case handed in thousands of lines of code.
Even if I understand all my code, I don't understand my co-workers code, and they don't understand mine.
Even if I understand all my code, I might not want to work for this company the rest of my life.
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 fact is opening the floodgates of low-end products, which are somehow better than nothing, but are embarrassing to use.
True, however as these products have been designed and coded by LLMs from the ground up in 2025+, they are generally using modern (typed even) languages, the latest version of third party libraries, usually have documentation of sorts... sometimes they even have test suites.
As such, they can often be improved as easily as one can prompt, which is much faster and easier than before. Notably in the FOSS world where one had to ask the maintainer, get ghosted for a year and have them go back with a "close: wontfix (too tedious)".
Better languages do not necessarily mean better architectural decisions, or even better performance, unless the humans pressure for that and burn tokens on that. With no engineer in the room, more technical issues will be left unnoticed and unaddressed.
Compare it to visual arts. With a guidance form an artist, AI tools can help create wonderful pictures. Without such guidance, or at least expert prompting, a typical one-shot image from Gemini is... well, at best recognizable as such.
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.
Possibly even more important than knowing where to hit it (what to code), is knowing where not to hit it (what not to code). Hitting the thing in the wrong place can lead to catastrophe. Making a code change you don't need can blow up production or paint your architecture into a corner.
AIs so far seem to prefer addition by addition, not addition by subtraction or addition by saying "are you sure?".
This doesn't mean that "code is cheap" is bad. Rather, it means that soon our primary role will be to guide AIs to produce a high proportion of "code that was cheap", while being able to quickly distinguish, prevent, and reject "cheap code".
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.
Writing code is cheap.
Owning code is getting more and more expensive.
SWEs sacrificed their jobs so that SREs could have unlimited job security.
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.
Precisely, especially because habits have been bound up in the high (and difficult to measure!) cost of code. We got precious about it, really.
Not necessary: stand up meetings.
If your code output has been devalued then the strategy of lowering your input as a person might not be the best approach.
Stand up is where I find out what code I’ll have to fix 6 months from now after my team member finishes ignoring all my advice. Useful to me.
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.
>> oversee the hordes of AI agents
This is the thing I don't really get. I enjoy tinkering with AI and seeing what it comes up with to solve problems. But when I need to write working code that does anything beyond simple CRUD, it's faster for me to write the code than it is to (1) describe the problem in English with sufficient detail and working theory, then (2) check the AI's work, understand what it's written, de-duplicate and dry it out.
I guess if I skipped step 2, it might save time, but it would be completely irresponsible to put it into production, so that's not an option in any world where I maintain code quality and the trust of my clients.
Plus, having AI code mixed into my projects also leaves me with an uneasy sense of being less able to diagnose future bugs. Yes, I still know where everything is, but I don't know it as well as if I'd written it myself. So I find myself going back and re-reviewing AI-written code, re-familiarizing myself with it, in order to be sure I still have a full handle on everything.
To the extent that it may save me time as an engineer, I don't mind using it. But the degree to which the evangelists can peddle it to the management of a company as a replacement for human coders seems highly correlated with whether that company's management understood the value of safe code in the first place. If they didn't, then their infrastructure may have already been garbage, but it will now become increasingly unusable garbage. At some point, I think there will be a backlash when the results in reality can no longer be denied, and engineers who can come in and clean up the mess will be in high demand. But maybe that's just wishful thinking.
I'm in the same boat. Too often for me it feels easier to write code that I want to see by myself instead of opening some AI tool where I would have to describe what I need in plain English. After which I'd still have to review the code to make sure it does do what was requested.
Perhaps you have to be certain type of person or work in a peculiar company where second step (review) can be ignored as long as AI says that it does. Hardcore YOLO life.
the top % of talent is still extremely hard to get, perhaps moreso
saw an article recently where every sector is seeing a reduction in IT/devs except for tech and ai companies
if your company is in a sector where eng is a cost-center and the product is not directly tied to your engineers / your company is pushing for efficiency it's an employer's market
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.
> 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.
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.
It's already happening, particularly with "Ladybird Browser adopts Rust" [0] being at the top of HN today. It's now feasible to quickly iterate on a system's design with a dynamic language like Python, and then, once you're happy with the design, have AI rewrite it into something like Rust or Zig. I can even foresee a future where we intentionally maintain two parallel implementations, with machine-defined translation between them, such that we're able to do massive changes on the higher level implementation in minutes, and then once we finish iterating, have it run overnight to reimplement (or rewrite) it in the performant language. A bit like the difference between a unoptimized debugging version of a project, and the highly optimized one, but on steroids.
The sad reality is it will likely be the older languages (I tend to see Ruby vibed a lot) just because there is so much more to train on.
With a bit of AI sprinkled in, Rust code can surely also waste gigabytes of RAM on "Hello World" ;)
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.
If writing code is cheap now why is there so much money involved?
> 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
Writing code has always been cheap. Deciding what the logic should be, and being able to change course was the hard bit.
But that's the thing - changing course is suddenly no longer hard. We've already reached a state where I can have AI generate a decent set of tests from an existing codebase (or better yet, I'd already have them ahead of time), and to then do a massive refactoring or even a full rewrite while I get a good night's sleep. There is nothing "has always been" about this.
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.
The Airbus A320neo can already takeoff, ascend, cruise, descend, and land all by autopilot. It can even download your flight plan from the airline's servers.
But you still need the pilots because the system can only handle the happy path. As soon as there's any blockade or strong weather change, the autopilot will just turn off. And then you need the pilots.
I would say software engineering with AI is similar: The AI can handle CRUD just fine. But once things get messy, you need someone who can actually think.
To fly a plane with 300+ passengers you still only need 2-3 pilots. That has remained consistent with the invention of autopilot. While we might still need a few human engineer experts, maybe we only need a few for small to medium sized companies? That may not eliminate the career for the top % but it effectively does for the vast majority of engineers.
We do automate lots about flying, not just take-off and landing. It's why a 4-engine aircraft in the 1960s required flight crews of 6-8 people just to fly the thing when they can be routinely flown with 2-3 today.
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%.
"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....
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...
But writing good code is still not 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.
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.
Plagiarizing other people's code has always been cheap. Willison cannot see the distinction, since his only claim to fame is inserting himself into early Django development. Perhaps he should work on real issues like Rob Pike.
You say this is a personal attack? No, he is a public figure and is increasingly cited as a source for "what programmers think". Which could not be further from the truth.
Out of curiosity, are you the same person who's constantly creating brand new accounts to have a go at me or are there more than one of you?
Given the relatively large number of new accounts I've been seeing recently, on all threads not just in response to you, I'm torn between "Hacker News become normal-internet-famous" and "dead internet reached us".
I scored 0* on a HN-Turing-Test game: https://news.ycombinator.com/item?id=47070537
* or less, given everything I identified was a false positive
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.
For everyone who is responding to the "Writing code is cheap now" heading without reading the article, I'd encourage you to scroll down to the "Good code still has a cost" section.
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.
[dead]
[dead]
[flagged]