20 ms·

Writing code is cheap now

• some_random 8mo ago
  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.
  • dboreham 8mo ago
    Not necessary: stand up meetings.
    • righthand 8mo ago
      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.
    • whywhywhywhy 8mo ago
      If your code output has been devalued then the strategy of lowering your input as a person might not be the best approach.
  • selridge 8mo ago
    Precisely, especially because habits have been bound up in the high (and difficult to measure!) cost of code. We got precious about it, really.
• danesparza 8mo ago
  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)
  • sjaiisba 8mo ago
    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.
  • KennyBlanken 8mo ago
    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.
• deleted 8mo ago
  [deleted]
• nine_k 8mo ago
  This fact is opening the floodgates of low-end products, which are somehow better than nothing, but are embarrassing to use.
  • vntok 8mo ago
    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)".
    • nine_k 8mo ago
      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.
    • bagacrap 8mo ago
      I've tried very earnestly to use opus 4.5 to get rid of some backlog tasks that were too tedious to do manually. It turns out that they're still extremely tedious because I have to make every single non trivial decision for the model, unless I don't care one iota about the long term sustainability of the code base. And by long term, I mean more than a week. They're good for saving keystrokes or doing fuzzy searches for me. "Design"? No, that is an anthropomorphism.
      • habinero 8mo ago
        I actually had a perfect use case for slopcoding - I needed to scrape a search result and turn it into a csv and a bunch of files. Totally possible with a hour or so or coding but annoying and not that fun. Completely trivial, tons of stuff like it, piece of cake Claude got something that looked like it was worked, and didn't. I figured out why, told it what to fix, and it didn't. Finally after several rounds, it kicked off...and then hung on...something? idk what, it doesn't look like it was rate limited Also it said the code would check to see it had already downloaded the file and if so, skip it. It definitely did not do that lol At this point it was 90 minutes--an hour of yelling at the computer and another 30 minutes of my ADHD ass forgetting that I had it running I like it as fancy autocomplete because it's usually helpful and I can silence it for 20 minutes if it's annoying me, but man.
• hansonkd 8mo ago
  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.
  • ikety 8mo ago
    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.
  • movedx01 8mo ago
    Autolands absolutely do exist.
  • fxtentacle 8mo ago
    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.
  • selridge 8mo ago
    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.
• spockz 8mo ago
  > 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.
• toprerules 8mo ago
  Writing code is cheap. Owning code is getting more and more expensive. SWEs sacrificed their jobs so that SREs could have unlimited job security.
• cpuguy83 8mo ago
  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.
  • xandrius 8mo ago
    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.
    • allthetime 8mo ago
      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.
      • vntok 8mo ago
        This burden of review will go down as FOSS maintainers involve AI more.
        • strobe 8mo ago
          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).
    • tadfisher 8mo ago
      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.
• throwaway613746 8mo ago
  [dead]
• Ronsenshi 8mo ago
  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.
  • noduerme 8mo ago
    >> 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.
    • Ronsenshi 8mo ago
      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.
• matthewkayin 8mo ago
  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.
• the_mitsuhiko 8mo ago
  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/ https://lucumr.pocoo.org/2026/2/13/the-final-bottleneck/
  • jdahlin 8mo ago
    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.
    • candiddevmike 8mo ago
      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.
      • jdahlin 8mo ago
        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.
• DrJid 8mo 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.
  • stackghost 8mo ago
    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.
    • ok123456 8mo ago
      Then why did most software fail to do that even before the advent of LLMs?
      • sethops1 8mo ago
        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).
      • fxtentacle 8mo ago
        Are we sure it's not failing anymore after the advent of LLMs?
      • stackghost 8mo ago
        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.
• 0cf8612b2e1e 8mo ago
  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.
  • tadfisher 8mo ago
    Worth reiterating due to the skyrocketing costs of RAM.
  • fxtentacle 8mo ago
    With a bit of AI sprinkled in, Rust code can surely also waste gigabytes of RAM on "Hello World" ;)
  • cube00 8mo ago
    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.
  • falcor84 8mo ago
    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. [0] https://news.ycombinator.com/item?id=47120899 https://news.ycombinator.com/item?id=47120899
  • duggan 8mo ago
    I’ve used Claude to write custom firmware in Rust for an ESP32-driven desktop clock. 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!
• malfist 8mo ago
  Code is cheap is the same as saying "Buying on credit is easy". Code is a liability, not an asset.
  • danesparza 8mo ago
    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.
    • malfist 8mo ago
      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.
      • leptons 8mo ago
        I've worked at so many places in my career that "not understanding code" is not an excuse. It is a skill to be able to read and follow code and get up to speed quickly, even on shit codebases. But "AI" generated code makes that so much more difficult, and the "AI" isn't going to walk you through it, and neither will your new coworkers. We aren't in a race to the bottom with "AI", we're in a speedrun to the bottom, and I don't think it's going to end up going too well for whatever developers are left in a few years.
  • mehagar 8mo ago
    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?
• jsdkkdkdkedj 8mo ago
  [flagged]
• marcoduval 8mo ago
  [dead]
• Oras 8mo ago
  > 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
  • beagle3 8mo ago
    Because it has been trained on Java class spaghetti. When it’s trained on enough APL/K code, you’ll get minimal abstraction.
• dgeiser13 8mo ago
  If writing code is cheap now why is there so much money involved?
• alex-nt 8mo ago
  > 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.
• fxtentacle 8mo ago
  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.
• firefoxd 8mo ago
  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-hard https://idiallo.com/blog/writing-code-is-easy-reading-is-har...
• octoclaw 8mo ago
  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.
  • slopinthebag 8mo ago
    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.
    • beagle3 8mo ago
      This is how successful things are created. By iterating on less successful things until they become successful. The cost of iterating (with software) dropped by a few orders of magnitude in the last few months.
      • slopinthebag 8mo ago
        But you need to actually be the one doing the iterating, you can't outsource it. The entire point to doing the iteration is the process, not the artefacts.
        • simonw 8mo ago
          I'm finding I can iterate significantly faster if the coding agent is doing the typing for me, and learn at a faster rate as a result.
• mentalgear 8mo ago
  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.
• snowhale 8mo ago
  [dead]
  • lelanthran 8mo ago
    > 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.
• lkey 8mo ago
  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%.
• simonw 8mo ago
  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-patterns/ 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-patterns/red-green-tdd/ https://simonwillison.net/guides/agentic-engineering-pattern...
  • eesmith 8mo ago
    I believe the ChatGPT code has a bug, in that it accepts three spaces or tabs before a code fence, while the Google Markdown spec says up to three spaces, and does not allow a tab there. I also see that the tests generated by ChatGPT are far too few for the code features implemented. The cannot be the result of actual red/green TDD where the test comes before the feature is added. For examples, 1) the code allows "~~~" but only tests for "```", 2) there are no tests when len(fence) < fence_len nor when len(fence) > fence_len, and 3) there are no tests for leading spaces. There's also duplicate code. The function _strip_closing_hashes is used once, in the line: text = _strip_closing_hashes(m.group("text")).strip() The function is: def _strip_closing_hashes(s: str) -> str: s = s.rstrip() # remove trailing " ###" style closers s = re.sub(r"[ \t]+#+\s*$", "", s).rstrip() return s The ".rstrip()" is unneeded as the ".strip()" does both lstrip and rstrip. I think that rstrip() should be replaced with a strip(), the function renamed to "_get_inline_content", and used as "text = _get_inline_content(m.group("text")). Also, the Google spec also says "A sequence of # characters with anything but spaces following it is not a closing sequence, but counts as part of the contents of the heading:" so is it really correct to use "\s*" in that regex, instead of "[ ]*"? And does it matter, since the input was rstrip'ped already? So perhaps: def _get_inline_content(s: str) -> str: s = s.rstrip(" ") # remove trailing spaces s = s.rstrip("#") # removing "#" style closers return s.strip() # remove leading and trailing whitespace would be more correct, readable, and maintainable?
    • simonw 8mo ago
• alexjray 8mo ago
  "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....
• ChrisArchitect 8mo ago
  Related: Code is cheap. Show me the talk https://news.ycombinator.com/item?id=46823485 https://news.ycombinator.com/item?id=46823485
• benakj 8mo ago
  [flagged]
  • simonw 8mo ago
    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?
    • ben_w 8mo ago
      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 https://news.ycombinator.com/item?id=47070537 * or less, given everything I identified was a false positive
• torginus 8mo ago
  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.
  • beagle3 8mo ago
    But the amount of pleasing useful art has gone up x1000; If I had a blog, I would now have access to art that would be a perfect fit for my words, whereas 5 years ago, I would have to do with a my own (talent-lacking) doodles. Would some people prefer no art/illustration to AI generated art? Sure. But even more would prefer no art to my doodles.
    • xyzsparetimexyz 8mo ago
      I for one would rather see the doodles
    • habinero 8mo ago
      Not really, it's all samey blandness. It makes good copies of bland samey stock photos
• simonw 8mo ago
  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.
• joe8756438 8mo ago
  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.
• agentifysh 8mo ago
  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.
  • danny_codes 8mo ago
    Exactly. I feel like the latest models are basically a couple MCP servers away from just doing the whole thing. You just say, here’s what I want the system to do, and it’ll just do everything. No knowledge required. You need only know how to ask.
• i-e-b 8mo ago
  Writing code has always been cheap. Deciding what the logic should be, and being able to change course was the hard bit.
  • falcor84 8mo ago
    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.
• daxfohl 8mo ago
  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.
  • daxfohl 8mo ago
    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".
    • xyzsparetimexyz 8mo ago
      Spot on
• frizlab 8mo ago
  But writing good code is still not cheap.
  • simonw 8mo ago
    See my heading half way down the page!
• tabs_or_spaces 8mo ago
  > Code has always been expensive. Producing a few hundred lines of clean, tested code takes most software developers a full day or more. Many of our engineering habits, at both the macro and micro level, are built around this core constraint. > ... > Writing good code remains significantly more expensive I think this is a bad argument. Code was expensive because you were trying to write the expensive good code in the first place. When you drop your standards, then writing generated code is quick, easy and cheap. Unless you're willing to change your standard, getting it back to "good code" is still an equivalent effort. There are alternative ways to define the argument for agentic coding, this is just a really really bad argument to kick it off.
  • random3 8mo ago
    Code is cheaper. Simple code is cheap. More complex code may not be cheaper. The reason you pay attention to details is because complexity compounds and the cheapest cleanup is when you write something, not when it breaks. This last part is still not fully fleshed out. For now. Is there any reason to not expect things to improve further? Regardless, a lot of code is cheap now and building products is fun regardless, but I doubt this will translate into more than very short-term benefits. When you lower the bar you get 10x more stuff, 10x more noise, etc. You lower it more you get 100x and so on.
  • simonw 8mo ago
    I was careful to say "Good code still has a cost" and "delivering good code remains significantly more expensive than [free]" rather than the more aesthetically pleasing "Good code is expensive. I chose this words because I don't think good code is nearly as expensive with coding agents as it was without them. You still have to actively work to get good code, but it takes so much less time when you have a coding agent who can do the fine-grained edits on your behalf. I firmly believe that agentic engineering should produce better code. If you are moving faster but getting worse results it's worth stopping and examining if there are processes you could fix.
    • akiselev 8mo ago
      Totally agreed. I’ve been reverse engineering Altium’s file format to enable agents to vibe-engineer electronics and though I’m on my third from scratch rewrite in as many weeks, each iteration improves significantly in quality as the previous version helps me to explore the problem space and instruct the agent on how to do red/green development [1]. Each iteration is tens of thousands of lines of code which would have been impossible to write so fast before so it’s been quite a change in perspective, treating so much code as throw away experimentation. I’m using a combination of 100s of megabytes of Ghidra decompiled delphi DLLs and millions of lines of decompiled C# code to do this reverse engineering. I can’t imagine even trying such a large project for LLMs so while a good implementation is still taking a lot of time, it’s definitely a lot cheaper than before. [1] I saw your red/green TDD article/book chapter and I don’t think you go far enough. Since we have agents, you can generalize red/green development to a lot of things that would be impractical to implement in tests. For example I have agents analyze binary diffs of the file format to figure out where my implementation is incorrect without being bogged down by irrelevant details like the order or encoding of parameters. This guides the agent loop instead of tests.
• manishsharan 8mo ago
  maybe writing code is cheap . But writing unit tests that actually test stuff that matters is suddenly so much more important and expensive.
  • simonw 8mo ago
    Yeah it's more important, but I think that has become a whole lot cheaper too.
• andrewstuart 8mo ago
  Understanding computers and programming is not the same as coding.
• wolfcola 8mo ago
  i’ve yet to see an agent that can take a figma design and produce high fidelity UI
  • simonw 8mo ago
    Have you tried Gemini 3.1 Pro for that yet? They put a ton of work into improving its frontend abilities.
• slopinthebag 8mo ago
  LLM's have made code cheap in the same way McDonalds has made eating out at a restaurant cheap.
  • analog31 8mo ago
    I wonder if they will make code fast in the way that McDonalds made food fast. For many business needs, knowing when a project will finish would be equally or even more valuable than knowing that it will contain more code or employ fewer programmers.
• gormen 8mo ago
  The cost of code never lived in the typing — it lived in the intent, the constraints, and the reasoning that shaped it. LLMs make the typing cheap, but they don’t make the reasoning cheap. So the economics shift, but the bottleneck doesn’t disappear.
  • locknitpicker 8mo ago
    > LLMs make the typing cheap, but they don’t make the reasoning cheap. LLMs lower the cost of copy/pasting code around, or troubleshooting issues using standard error messages. Instead of going through Stack Overflow to find how to use a framework to do some specific thing, you prompt a model. You don't even need to know a thing about the language you are using to leverage a feedback loop. LLMs lower the cost of a multitude of drudge work in developing software, such as having to read the docs to learn how a framework should be used to achieve a goal. You still need to know what you are doing, but you don't need to reinvent the wheel.
  • beagle3 8mo ago
    For most non-hobby project, the cost of code was in breaking a working system (whether by a bona fide bug, or a change in some unspecified implicit assumption). That made changes to code incredibly expensive - often much more than the original implementation. It sounds harsh, but over the lifetime of a project, 10-lines/person/day is often a high estimate of the number of lines produced. It’s not because humans type so slow - it is because after a while, it’s all about changing previously written lines in ways that don’t break things. LLMs are much better at that than humans, if the constraints and tests are reasonably well specified.
    • LtWorf 8mo ago
      > if the constraints and tests are reasonably well specified. if they are, then why would a human be so slow? You're not comparing the same situation.
      • theshrike79 8mo ago
        Because humans need to type with a keyboard, then click around with a mouse. In that time the LLM has made a change, ran tests, committed, pushed, checked that the CI build failed, looked at the CI logs, fixed the issue and the PR is now passing.
• umairnadeem123 8mo ago
  [dead]
• cryptonector 8mo ago
  > Here's what I mean by "good code": > [...] > - It’s simple and minimal - it does only what’s needed, in a way that both humans and machines can understand now and maintain in the future. But do the humans need to actually understand the code? A "yes" means the bottleneck is understanding (code review, code inspection). A "no" means you can go faster, but at some risk.
  • Quothling 8mo ago
    > 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. I always thought of things like code reviews as semi pseudo-science in most cases. I've sat through meetings where developers obviously understand the code that they are reviewing, but where they didn't understand anything about the system as a whole. If your perfect function pulls on 800 external dependencies that you trust. Trust because it's too much of a hazzle to go through them. I'd argue that in this situation you don't understand your code at all. I don't think it matters and I certainly don't think I'm better than anyone else in this regard. I only know how things work when it matters. If anything, I think AI will increase human understanding without the need to write computer unfriendly code like "Clean Code", "DRY" and so on.
    • xyzsparetimexyz 8mo ago
      > If anything, I think AI will increase human understanding How?
      • Quothling 8mo ago
        Have you met the average programmer on a thursday afternoon after a terrible week of little sleep, family issues and unnecessary meetings? When I'm in that state of mind myself I'm fairly confident that any LLM could explain my weeks work better than I could.
    • hansmayer 8mo ago
      Code reviews are pseudo-science now? Computer unfriendly code? What are you talking about? Do you understand that this babble makes zero sense ? Are you one of those product managers who recently learned to vibe-code? If so, make sure your latest Replit project does not delete your production database..
• farhanhubble 8mo ago
  The cost has always been the sum of: 1. The time spent to think and iteratively understand what you want to build 2. The time spent to spell out how you want to build it The cost for #2 is nearly zero now. The cost for #1 too is slashed substantially because instead of thinking in abstract terms or writing tests you can build a version of the thing and then ground your reasoning in that implementation and iterate until you attain the right functionality. However, once that thing is complex enough you still need to burn time on identifying the boundaries of the various components and their interplay. There is no gain from building "a browser" and then iterating on the whole thing until it becomes "the browser". You'll be up against combinatorial complexity. You can perhaps deal with that complexity if you have a way to validate every tiny detail, which some are doing very well in porting software for example.
• orange_puff 8mo ago
  I basically fully agree with this. I am not sure how to handle the ramifications of this in my day to day work yet. But at least one habit I have been forming is sometimes I find that even though the cost of writing code is immensely cheap, reviewing and validating that it works in certain code bases (like the millions of line mono repo I work in at my job) is extremely high. I try to think through, and improve, our testability such that a few hundred line of code change that modifies the DB really can be a couple of hours of work. Also, I do want to note that these little "Here is how I see the world of SWE given current model capabilities and tooling" posts are MUCH appreciated, given how much you follow the landscape. When a major hype wave is happening and I feel like I am getting drowned on twitter, I tend to wonder "What would Simon say about this?"
  • locknitpicker 8mo ago
    > I find that even though the cost of writing code is immensely cheap, reviewing and validating that it works in certain code bases (like the millions of line mono repo I work in at my job) is extremely high. That is my observation as well. Churning code is easy, but making sure the code is not total crap is a completely new challenge and concern. It's not like prior to LLMs code reviews didn't required work. Far from it. It's just that how the code is generated in a completely different way, and in some cases with barely any oversight from vibecoders who are trying to punch way above their weight. So they generate these massive volumes of changes that fail in obvious and subtle ways, and the flow is relentless.
    • pjerem 8mo ago
      What tremendously helps is asking the LLM to add a lot a lot explanations by adding comments to each and every line or function. You can remove those comments afterwards if you feel they are too much but it helps a lot the reviewing. More a trick than a silver bullet but it's nice.
      • locknitpicker 8mo ago
        > What tremendously helps is asking the LLM to add a lot a lot explanations by adding comments to each and every line or function. No, it doesn't. It's completely useless and unhelpful. These machine-generated comments are only realizations of the context that already outputted crap. Dumping volumes of this output adds more work to reviewers to parse through to figure out the mess presented by vibecoders who didn't even bothered to check what they are generating.
• democracy 8mo ago
  AI agents is like outsourcing to a bad team offshore - yeah they can build and maybe cheap but requires lots of hand holding.
  • DaedalusII 8mo ago
    its going to replace outsourcing to offshore teams pretty robustly though I suspect
• d--b 8mo ago
  Well another consequence of that is that you’re going to have a lot more tools to maintain. And LLMs aren’t half as good as maintaining code as they are to generate it in the first place. At least yet.
• arkh 8mo ago
  Every modern (and not so modern) software development method hinge on one thing: requirements are not known and even if known they'll change over time. From this you get the goal of "good" code which is "easy to change code". Do current LLM based agents generate code which is easy to change? My gut feeling is a no at the moment. Until they do I'd argue code generated from agents is only good for prototypes. Once you can ask your agent to change a feature and be 100% sure they won't break other features then you don't care about how the code looks like.
  • TheDong 8mo ago
    > 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. That bar is unreasonably high. Right now, if I ask a senior engineer to change a feature in a mature codebase, I only have perhaps 70% certainty they won't break other features. Tests help, but only so far.
    • arkh 8mo ago
      But if push come to shove any other engineer can come in and debug your senior engineer code. That's why we insist on people creating easy to change code. With auto generated code which almost no one will check or debug by hand, you want at least compiler level exactitude. Then changing "the code" is as easy as asking your code generator for new things. If people have to debug its output, then it does not help in making maintainable software unless it also generates "good" code.
    • Antibabelic 8mo ago
      This bar only seems high because the bar in most companies is already unreasonably low. We had decades of research into functional programming, formal methods and specification languages. However, code monkey culture was cheaper and much more readily available. Enterprise software development has always been a race to the bottom, and the excitement for "vibe coding" is just the latest manifestation of its careless, thoughtless approach to programming.
      • 8mo ago
• alexhans 8mo ago
  I am pushing for this judicious Eval [1] Driven Development where tech/non tech users use intent when coding to minimally design some known aspects and try to build simply and using common standards across the team (that should be in the context of the agent) to produce the minimal amount of human readable and clean code that would do the job. The more the building blocks they work with are simple, easy to validate and rely on the proper unit tests, integration tests, data tests the more chance that things can be "one shotted". One huge barrier is fighting entropy. You should be wary of prototypes which create false expectations and don't help product evolution whereas tracer bullets [2] might be better if you want to quickly show something and adjust. Testing and testability are concepts that aren't intuitive or easy until you develop a feel for them so we should be preaching feeling that pain and moving slowly and with intent and working minimally [3] when you actually want to share or maintain your coding artifact. There should be no difference between judicious human and computer code. Don't suddenly start putting What instead of why in comments or repeating everything. Helping non tech people become builders or sharers is a challenge beyond "vibe coding" and the agent skills [4] space is fascinating for that. Like most things AI (LLM), UX matters more than almost anything else. [1] https://ai-evals.io https://ai-evals.io [2] concept from the Pragmatic Programmer, https://www.aihero.dev/tracer-bullets https://www.aihero.dev/tracer-bullets [3] https://alexhans.github.io/posts/series/evals/measure-first-optimize-last.html https://alexhans.github.io/posts/series/evals/measure-first-... [4] https://alexhans.github.io/posts/series/evals/building-agent-skills-incrementally.html https://alexhans.github.io/posts/series/evals/building-agent...
• KnuthIsGod 8mo ago
  Time for schools to stop pushing coding skills onto the poor kids.
• trwhite 8mo ago
  When did we ever measure the value of code by quantity, not quality? The author is misguided.
  • simonw 8mo ago
    Did you read my list of characteristics of "good code" further down the article? That's all about quality, not quantity.
• voidUpdate 8mo ago
  Putting text into a file is cheaper than before. Everything else remains the same cost in a well designed project, rather than a vibe coded one where you just tell the LLM to "make a todo list app"
• submeta 8mo ago
  I think the framing is still too code-centric. The real bottleneck isn’t writing (or even reviewing) code anymore. It’s: 1. extracting knowledge from domain experts 2. building a coherent mental model of the domain 3. making product decisions under ambiguity / tradeoffs 4. turning that into clear, testable requirements and steering the loop as reality pushes back The workflow is shifting to: Understand domain => Draft PRD/spec (LLM helps) => Prompt agent to implement => Evaluate against intent + constraints => Refine (requirements + tests + code) => Repeat The “typing” part used to dominate the cost structure, so we optimized around it (architecture upfront, DRY everywhere, extreme caution). Now the expensive part is clarity of intent and orchestrating the iteration: deciding what to build next, what to cut, what to validate, what to trust, and where to add guardrails (tests, invariants, observability). If your requirements are fuzzy, the agent will happily generate 5k lines of very confident nonsense. If your domain model + constraints are crisp, results can be shockingly good. So the scarce skill isn’t “can you write good code?” It’s “can you interrogate reality well enough to produce a precise model—and then continuously steer the agent against that model?”
• dirkc 8mo ago
  I like using the analogy of 'living in a small apartment' when building systems with a small team. You need to choose carefully what furniture you can fit into your apartment, and that choice depends a lot on how you live your live. Do you want a large table to host friends, or a comfortable couch to fall asleep on in front of the TV? If you get both the space will probably be cluttered. The same applies to a small software project - you need to choose what features you can fit. And while the cost of building is part of the consideration, I'd say most of it is about the cost of maintaining features, not only in code, but also in product coherence and other incidental 'costs' like documentation and user support. Be careful of building too many features and ending up being overwhelmed by the maintenance, or worse, diluting the product's value to a point where you loose users.
  • djb_hackernews 8mo ago
    Are you familiar with the cathedral vs the bazaar?
    • dirkc 8mo ago
      To some extent, although I've never read the actual text. Care to elaborate, I don't want to infer things on your behalf?
      • djb_hackernews 8mo ago
        Curious if your mental model is similar or how you see them being different.
• BlueHotDog2 8mo ago
  its funny how we're back again measuring lines of code as the sole indicator for cost/quality etc
  • simonw 8mo ago
    See my list of characteristics of "good code" half way down the article for my thoughts on quality that go way beyond lines of code produced.
• light_hue_1 8mo ago
  Writing code was always cheap! You could outsource for inconsequential amounts of money and get massive amounts of code in return. Yet, the vast majority of companies do not do so. Because coding is not the hard part of being a software engineer / programmer. 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.
• huflungdung 8mo ago
  [dead]
• BoppreH 8mo ago
  > Here's what I mean by "good code": [...] What a fantastic list. I'll be saving it to show the junior developers. My only nitpick is that "reliability" should have been a point by itself. All the other "ilities" can be appropriately sacrificed in some context, but I've never seen unreliable software being praised for its code quality. Which is part of why LLMs are so frustrating. They're extremely useful and extremely unreliable.
• oulipo2 8mo ago
  First there's no "code". There are many different variations. Doing basic UI in React is way different from doing low-level embedded code with locking and mutexes, etc. 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.
• vb-8448 8mo ago
  I agree, writing code is cheaper than ever ... but "writing the code" isn't the main challenge in SWE since decades. Our IT infrastructures & applications run on a stack that has grown for the past 40 years and what we are currently doing with all this LLM & vibecode mania is adding more stuff (at an accelerated rate) on the top of the stack. The main challenge today is combining the user requirements with the stack in a way it works, it's easy to maintain and it donesn't cost too much.
• CrzyLngPwd 8mo ago
  All writing is cheap now, but good writing is not cheap. Same for images, same for videos, probably it's already the same for movies.
• kittikitti 8mo ago
  On a higher level, this is wishful thinking. However, for people who think this way, getting code to compile at all used to be very "expensive". AI makes abstract code above machine level much easier to compile. 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.
• animal531 8mo ago
  Here's an easy to understand example. I've been playing EvE Online and it has an API with which you can query the game to find information on its items and market (as well as several other unrelated things). It seems like a prime example for which to use AI to quickly generate the code. You create the base project and give it the data structures and calls, and it quickly spits out a solution. Everything is great so far. Then you want to implement some market trading, so you need to calculate opportunities from the market orders vs their buy/sell prices vs unit price vs orders per day etc. You add that to the AI spec and it easily creates a working solution for you. Unfortunately once you run it it takes about 24 hours to update, making it near worthless. The code it created was very cheap, but also extremely problematic. It made no consideration for future usage, so everything from the data layer to the frontend has issues that you're going to be fighting against. Sure, you can refine the prompts to tell it to start modifying code, but soon you're going to be sitting with more dead code than actual useful lines, and it will trip up along the way with so many more issues that you will have to fix. In the end it turns out that that code wasn't cheap at all and you needed to spend just as much time as you would have with "expensive code". Even worse, the end product is nearly still just as terrible as the starting product, so none of that investment gave any appreciable results.
  • kmlx 8mo ago
    been there. for these kinds of projects i never start with code, i start with specs. i sometimes spend days just working on the specs. once the specs are clear i start coding, which is completely different monster. basically not that different from a common workflow (spec > ticket > grooming > coding; more or less), but everything with AI.
    • dygd 8mo ago
      I do the same, plus add tests from early on. New features then naturally are accompanied by more tests.
    • animal531 8mo ago
      Yeah, I make sure to spend my time on the hard problems and where you need to design for the future. I use AI up to around method level after that, have it do the drudge work of typing up tedious text, or to complete required boilerplate etc.
• mattclarkdotnet 8mo ago
  So… XP was the right way all along?
• smallnix 8mo ago
  > any time our instinct says "don't build that, it's not worth the time" fire off a prompt anyway I disagree with this sentiment. This approach leads down to huge maintenance burden.
  • simonw 8mo ago
    In context, this bit is about how to deal with the fact that our intuitions on what's worth it vs not worth it in terms of the time it takes to build are likely out-of-date with these new tools: > For now I think the best we can do is to second guess ourselves: any time our instinct says "don't build that, it's not worth the time" fire off a prompt anyway, in an asynchronous agent session where the worst that can happen is you check ten minutes later and find that it wasn't worth the tokens. This shouldn't lead to huge maintenance burden because most of the time you'll throw away the result. It's a learning exercise.
    • smallnix 8mo ago
      I think I misread this as an encouragement to pick up work out of order w.r.t prioritization. That coding got cheaper shouldn't change prioritization post planning. It should definitely factor into prioritization at planning time.
• vivzkestrel 8mo ago
  - posting on hackernews has also become cheap which is where there are Nx more Show HN posts but engagement on each has also dropped to 1/N
• ChrisMarshallNY 8mo ago
  > We need to build new habits In my case, testing and documentation becomes even more important. I’m currently rewriting a server backend that was originally written as a “general-purpose” server, and is very complex. It works extremely well, is robust and secure, but way overkill for my current application. I'm using an LLM to write a lot of the code. The LLM-written code is quite verbose, and I’m having to learn to just accept that, as it also works well. For a while, I would go in and rewrite the code, but I'm learning to stop doing that. If there's a problem; even an obvious one, I am learning to ask the LLM to fix it, instead of going in and doing it, myself. Right now, I am writing a headerdoc for the server that is going to be hundreds of lines long. It is a detailed, pedantic description of the API and internal structure of the application. Its primary audience is LLMs. I need to make sure that future analysis understands exactly why the server does what it does, as well as what it does. The current server is a first step in a (probably years-long) process of migration away from the original server design. It does seem to be coming along well.
• vmaurin 8mo ago
  Agentic coding are bringing new people to coding. But instead of reading some books about coding or looking at the history, they face the same problems as before, they have the same struggle and they re-invent the same solutions. I am waiting for the vibe coding expert posts that will tell us that lines of code are not a good measure, it is a liability and you should instruct your agent to write less code ...
• i_love_retros 8mo ago
  Sponsored by: Teleport — Secure, Govern, and Operate AI at Engineering Scale Gee what a surprise.
  • co_king_5 8mo ago
    [dead]
    • lnkl 8mo ago
      No way that he would lie about this, right?
      • simonw 8mo ago
        How is having a banner at the top of my page saying "Sponsored by:" lying about something? A lie would be taking money from sponsors and not announcing it.
    • DavidMcLaughlin 8mo ago
      He posted about it here: https://simonwillison.net/2026/Feb/19/sponsorship/ https://simonwillison.net/2026/Feb/19/sponsorship/
    • simonw 8mo ago
      I couldn't find that in your comment history, where/when/what did you ask? I'm frequently asked if companies pay me to write about them on my blog, and the answer is no. More on my policy here: https://simonwillison.net/2026/Feb/19/sponsorship/ https://simonwillison.net/2026/Feb/19/sponsorship/
• imtringued 8mo ago
  I feel like this article is completely backwards in its premise. It is confusing labor intensity with cost. Software used to be an incredibly labor intensive industry with extremely low automation costs. The cost of running a computer and its associated development environment is so low that it is a rounding error. While you might pay a monthly subscription for an IDE, even that cost barely even registers and it only assists the developer's productivity by a double digit percentage at most. 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.
  • simonw 8mo ago
    > The cost of writing code has never been an issue in this industry. What do you think of this part of Paul Ford's recent NYT essay? > I was the chief executive of a software services firm, which made me a professional software cost estimator. When I rebooted my messy personal website a few weeks ago, I realized: I would have paid $25,000 for someone else to do this. When a friend asked me to convert a large, thorny data set, I downloaded it, cleaned it up and made it pretty and easy to explore. In the past I would have charged $350,000. > That last price is full 2021 retail — it implies a product manager, a designer, two engineers (one senior) and four to six months of design, coding and testing. Plus maintenance. Bespoke software is joltingly expensive. Today, though, when the stars align and my prompts work out, I can do hundreds of thousands of dollars worth of work for fun (fun for me) over weekends and evenings, for the price of the Claude $200-a-month plan. From https://www.nytimes.com/2026/02/18/opinion/ai-software.html?unlocked_article_code=1.NFA.UkLv.r-XczfzYRdXJ&smid=url-share https://www.nytimes.com/2026/02/18/opinion/ai-software.html?...
• kaffekaka 8mo ago
  Simon gets alot of.. negative feedback, but this is a good description of the current state and I think he does a good job at distilling and expressing where things are currently at. With all the hate and hype for AI everywhere this is a good thing.
• ReptileMan 8mo ago
  Adding cast iron on airplane is cheap now.
• Havoc 8mo ago
  Partially why I’m surprised there isn’t more focus on coding harnesses that lean towards strong typing / testing / quasi formal verification type paradigms If you could funnel it through something like that then the ability to generate vast amounts of code is a lot more commercially useful
  • ap99 8mo ago
    100% This is what explains the difference in using apps like Claude Code versus almost any other harness/wrapper. And the model can be the same, but if the harness sucks then the usefulness of the harness+model tanks. It's like harness * model = usefulness.
    • Havoc 8mo ago
      Can’t say I’ve notice much of a difference switching from CC to opencode?
• kaizenb 8mo ago
  ● When everyone has access to the same models, and those models can produce working software quickly and cheaply, the code itself stops being a moat. A reasonably skilled person can now build what used to take a team of engineers months to ship. ● A competitor can reach feature parity in days. The thing that used to protect a business, the sheer effort required to build it, is mostly gone. ● Think of it like oil. If every property owner had a well that was cheap to operate, the price of oil would fall toward the price of water. The resource is abundant, the extraction is easy, and the margin disappears. Software features are heading in the same direction. https://designexplained.substack.com/p/the-moat-has-moved https://designexplained.substack.com/p/the-moat-has-moved
• bsenftner 8mo ago
  This is such a surface level take, it's embarrassing. Unless he's talking about the impression in society, but he is not. Writing code is a social act even though few actually read it the code, they experience the result of that code. Maybe, just maybe Simon means "code is disposable now", because some shortcut taker can spin up an apparent duplicate by coaxing and pleading with AI. That is not a future worth participating in, that's intellectual begging death, because that will create an environment of worthless nonsense.
  • simonw 8mo ago
    Did you read the whole thing or just the headline? What did you think of my list of characteristics of "good code"?
    • htrp 8mo ago
      What are you thinking about for the new best practices for software engineering?
      • simonw 8mo ago
        That's the question I'm hoping to answer as I write the rest of this guide, which I expect to take several months: https://simonwillison.net/2026/Feb/23/agentic-engineering-patterns/ https://simonwillison.net/2026/Feb/23/agentic-engineering-pa... I'm not sure anyone has a confident answer to that yet though - I certainly don't.
        • bsenftner 8mo ago
          Simon, I'd be interested in a voice conversation with you on this topic. I've developed my own chain-of-thought system that is very different from what others are doing. Mine is a Socrate Agent that leads the developer, does not write their code, but guides them to become a better developer. It completely opposite the direction the larger industry seems to be going. Augmented synergy between the AI and developer, not the AI coding and the human overseeing.
    • 8mo ago
• AyanamiKaine 8mo ago
  > Code has always been expensive. Producing a few hundred lines of clean, tested code takes most software developers a full day or more. Many of our engineering habits, at both the macro and micro level, are built around this core constraint. Wasn't writing code always cheap? I see this more like a strawmen argument. What is clean code? Tested code? Should each execution path of a function be tested with each possible input? I think writing tests is important but you can over do it. Testing code for every possible platform takes of course much time and money. Another cost factor for code is organization overhead, if adding a new feature needs to go through each layer of the organization signing it off before a user can actually see it. Its of course more costly than the alternative of just pushing to production with all its faults. There is a big difference of short term cost and long term ones. I think LLMs reduce the short time cost immensely but may increase the long term costs. It will take some real long studies to really show the impact.
  • softwaredoug 8mo ago
    > Wasn't writing code always cheap? No. If you’re a startup that wanted to ship your product, you were stuck hiring developers and waiting 6 months. I’m old enough to remember th “6-8 weeks” it was supposed to take to build the first version of Stackoverflow (hint it was more like several months). Creating a v1 of a product / feature is now cheap. When you’re a mature product and need to make complicated / iterative decisions - that’s not cheap and requires expertise to make good decisions.
    • jraph 8mo ago
      > I’m old enough to remember th “6-8 weeks” it was supposed to take to build the first version of Stackoverflow (hint it was more like several months). And they had to do this without help from Stack Overflow! :-)
    • throwaway27448 8mo ago
      Startups, famous for writing clean, quality code.
      • 8mo ago
• agentultra 8mo ago
  Each line of code is a liability. I think it’s funny that we’re all measuring lines of code now and smiling. It was/is expensive because engineers are trying to manage the liability exposure of their employers. Agents give us a fire hose of tech debt that anyone can point at production. I don’t think the tool itself is bad. But I do think people need to reconsider claims like this and be more careful about building systems where an unaccountable program can rewrite half your code base poorly and push it to production without any guard rails.
  • gitprolinux 8mo ago
    Writing code is expensive. Maintaining code is expensive. Whatever way, it ain't cheap.
  • saezbaldo 8mo ago
    This is the under-discussed part. We spent decades building authorization layers around code deployment -- review gates, CI checks, staging, rollback. That infrastructure exists because code changes are high-consequence operations that compound. "Code is cheap" means generation is cheap. But the authorization to ship it remains expensive for very good reason. Removing the generation bottleneck without replacing the judgment layer is a control gap, not a productivity gain. The parallel is giving someone a master key because they're fast at opening doors. Speed was never the constraint that justified the lock.
• kobe_bryant 8mo ago
  you'd think this guy would get tired of writing about AI all day
  • simonw 8mo ago
    I also write about museums https://www.niche-museums.com https://www.niche-museums.com and parrots https://simonwillison.net/2026/Feb/17/first-kakapo-chick-in-four-years/ https://simonwillison.net/2026/Feb/17/first-kakapo-chick-in-...
  • vips7L 8mo ago
    Grifters gonna grift.
• Rover222 8mo ago
  I'm consistently shocked at how much cope about AI is still in hacker news threads. Clinging to the idea that human taste and skill in writing code is still no match for AI. 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?
• nikolasdimi 8mo ago
  Not sure if “code has always been expensive” is the right framing. Typing out a few hundred lines of code was never the real bottleneck. What was expensive was everything around it: making it correct, making it maintainable (often underestimated), coordinating across teams and supporting it long term. You can also overshoot: Testing every possible path, validating across every platform, or routing every change through layers of organizational approval can multiply costs quickly. At some point, process (not code) becomes the dominant expense. What LLMs clearly reduce is the short-term cost of producing working code. That part is dramatically cheaper. The long-term effect is less clear. If we generate more code, faster, does that reduce cost or just increase the surface area we need to maintain, test, secure, and reason about later? Historically, most of software’s cost has lived in maintenance and coordination, not in keystrokes. It will take real longitudinal data to see whether LLMs meaningfully change that, or just shift where the cost shows up.
  • ericol 8mo ago
    > 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? My take is that the focus is mostly oriented towards code, but in my experience everything around code got cheaper too. In my particular case, I do coding, I do DevOps, I do second level support, I do data analysis. Every single task I have to do is now seriously augmented by AI. In my last performance review, my manager was actually surprised when I told him that I am now more a manager of my own work than actually doing the work. This also means my productivity is now probably around 2.5x what it was a couple of years ago.
    • randito 8mo ago
      > In my last performance review, my manager was actually surprised when I told him that I am now more a manager of my own work than actually doing the work. I think this is very telling. Unless you have a good manager who is paying attention, a lot of them are clueless and just see the hype of 10x ing your developers and don't care about the nuance of (as they say) all the surrounding bits to writing code. And unfortunately, they just repeat this to the people above them, who also read the hype and just see $$ of reducing headcount. (sorry, venting a little)
• dras227 8mo ago
  [dead]
• scottoreily 8mo ago
  [dead]
• juanre 8mo ago
  The key is what we consider good code. Simon’s list is excellent, but I’d push back on this point: > it does only what’s needed, in a way that both humans and machines can understand now and maintain in the future We need to start thinking about what good code is for agents, not just for humans. For a lot of the code I’m writing I’m not even “vibe coding” anymore. I’m having an agent vibe code for me, managing a bunch of other agents that do the actual coding. I don’t really want to look at the code, just as I wouldn’t want to look at the output of a C compiler the way my dad did in the late ’80s. Over the last few decades we’ve evolved a taste for what good code looks like. I don’t think that taste is fully transferable to the machines that are going to take over the actual writing and maintaining of the code. We probably want to optimize for them.
• snowstormsun 8mo ago
  Who's going to maintain all the cheap code and review it? Is the "software janitor" job title becoming reality now?
• trumbitta2 8mo ago
  Writing code is 20-100 USD per month now
• exabrial 8mo ago
  code has never been expensive. ridiculous asks are expensive. Not understanding limitations of computer systems are expensive. The main problem is, and always will be communication. engineers are in general are quick to say "that won't work as you described" because they can see the steps that it takes to get there. Sales guys (CEOs) live a completely different world and they "hear" "I won't do that" from technical types. It's the ultimate impedance mismatch and the subject of countless seminars. AI writing code at least reduces the cost of the inevitable failures, but doesn't solve the root problem. Successful business will continue be those who's CTO/CEO relationship is a true partnership.
• hansmayer 8mo ago
  > "Code has always been expensive. Producing a few hundred lines of clean, tested code takes most software developers a full day or more. Many of our engineering habits, at both the macro and micro level, are built around this core constraint." Well, yes and no. While producing two screens worth of high quality code, a.k.a. software engineering was always expensive, "coding" as such, as in producing Nth React SPA or merely typing out code that you engineered in your head, was never that expensive - most of the work is applying existing patterns. But either way, as you wrote the code yourself, you mostly had a consistent mental model of how your code should work and the key contribution was evolving this model, first in your head, then in typing out code. Now here comes the real problem for the LLMs: I think most of us would be fine if the LLMs could actually just type out the code for us after we engineered it in our heads and explained it to the LLM in English language. Alas, they do produce some sort of code, but not always, or often enough not in a way we desribed it. So unfortunately "AI" boosters like Simon are reverting back to the argument of fast code generation and an appeal to us as unwilling adopters, to "change our ways", as it shows they have no real advantage of the LLMs to put forward - its only ever the "coding" speed and an appeal to us as professionals to "adapt", i.e. serve as cleaners of LLM sh*t. Where is the superintelligence we were promised and single-person-billion dollar unicorns, unique use cases etc? Are you telling us again these are just advanced text generators, Simon?
  • simonw 8mo ago
    > 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. That's exactly what they do for me - especially since the November model releases (GPT-5.1, Opus 4.5). > 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? I never promised anyone a superintelligence, or single-person-billion dollar unicorns. I do think these things are just advanced text generators, albeit the word "just" is doing a whole lot of work in that sentence.
    • 8mo ago
• samiv 8mo ago
  Let me get this straight so basically with the chatbots everyone is now running faster than ever. Every business thinks they can get an advantage by increasing their velocity relative to their competition. But the competitive is doing the same so what is the outcome? 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.
• davnicwil 8mo ago
  There's a lot of misconception about the intrinsic economic value of 'writing code' in these conversations. In software, all the economic value is in the information encoded in the code. The instructions on precisely what to do to deliver said value. Typically, painstakingly discovered over months or years of iteration. Which is exactly why people pay for it when you've done it well, because they cannot and will not rediscover all that for themselves. Writing code, per se, is ultimately nothing more than mapping that information. How well that's done is a separate question from whether the information is good in the first place, but the information being good is always the dominant and deciding factor in whether the software has value. So obviously there is a lot of value in the mapping - that is writing the code - being done well and, all else being equal, faster. But putting that cart before the horse and saying that speeding this up (to the extent this is even true - a very deep and separate question) has some driving impact on the economics of software I think is really not the right way to look at it. You don't get better information by being able to map the information more quickly. The quality of the information is entirely independent of the mapping, and if the information is the thing with the economic value, you see that the mapping being faster does not really change the equation much. A clarifying example from a parallel universe might be the kind of amusing take about consultancy that's been seen a lot - that because generative AI can produce things like slides, consultancies will be disrupted. This is an amusingly naive take precisely because it's so clear that the slides in and of themselves have no value separate from the thing clients are actually paying for: the thinking behind the content in the slides. Having the ability to produce slides faster gets you nothing without the thinking. So it is in software too.
  • simonw 8mo ago
    > You don't get better information by being able to map the information more quickly. This ties quite neatly into the concept of "cognitive debt" that's doing the rounds at the moment: https://simonwillison.net/tags/cognitive-debt/ https://simonwillison.net/tags/cognitive-debt/ Cognitive debt accumulates when you move so fast on the implementation that your mental model of what the software does and how it works falls behind.
  • mojoe 8mo ago
    nicely said. I've been thinking a lot about how the bottleneck in the limit is getting your intent into the machine. Over time as AI improves it'll get better and better at extracting your intent just from situational context, but this only helps if you're willing to abdicate more and more judgement to the machine. Eventually you may get to the point where the machine has all the context about the scenario and all the knowledge about how you think, and so will always perfectly be aligned with your intent, but when that day comes the thing will have far surpassed your decision-making capability and you won't be in the loop anymore anyway.
• sillyboi 8mo ago
  I’d like to add an obvious point that is often overlooked. LLMs take on a huge portion of the work related to handling context, navigating documentation, and structuring thoughts. Today, it’s incredibly easy to start and develop almost any project. In the past, it was just as easy to get overwhelmed by the idea of needing a two-year course in Python (or any other field) and end up doing nothing. In that sense, LLMs help people overcome the initial barrier, a strong emotional hurdle, and make it much easier to engage in the process from the very beginning.
• vicchenai 8mo ago
  [dead]
• bhekanik 8mo ago
  [flagged]
• alt227 8mo ago
  Another person that doesnt seem to understand that the cost of using ai agents is going to skyrocket at some point in the near future.
• zahlman 8mo ago
  (I wrote this mainly from the perspective of what it feels like on the inside to write code as a human. I think https://news.ycombinator.com/item?id=47138965 https://news.ycombinator.com/item?id=47138965 explains it better in terms of the business aspect.) > 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?
• rc1 8mo ago
  > any time our instinct says "don't build that, it's not worth the time" fire off a prompt anyway, in an asynchronous agent session where the worst that can happen is you check ten minutes later and find that it wasn't worth the tokens. 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.
• DonHopkins 8mo ago
  Factorio is so much about juggling and re-juggling the trade-offs of doing things by hand versus progressively higher and higher level automation, as you research new technologies like conveyor belts, inserters, logistics and constructor robots, blueprints, etc. 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.
• verma6uc 8mo ago
  This is exactly what we're seeing building Glue. Writing code got cheap but understanding a codebase didn't — it might have actually gotten harder because there's more of it. We built Glue for the PM and EM who needs to answer "what does this codebase actually do?" without reading every file the AI just generated. The problem isn't generation anymore, it's comprehension and ownership. Curious if others are building tooling around this.
• Bombthecat 8mo ago
  Yap, tell my clients now that source code isn't a secret sauce anymore. 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.
• boombapoom 8mo ago
  producing clean, well tested code takes a day after AI producing clean, well tested code takes a day (of reviewing, reprompting, and testing)
• deterministic 8mo ago
  I routinely generate about 90% of my code using custom code generators (not AI), so that portion is relatively inexpensive. The remaining 10%, however, is the business logic. That’s the part that takes time to understand and implement — and it’s ultimately what the customer cares about and pays for.
• aussiegreenie 8mo ago
  Writing code might be cheap, but debugging code is VERY EXPENSIVE.