[HN Gopher] Writing code is cheap now
___________________________________________________________________
Writing code is cheap now
Author : swolpers
Score : 340 points
Date : 2026-02-23 17:20 UTC (1 days ago)
(HTM) web link (simonwillison.net)
(TXT) w3m dump (simonwillison.net)
| some_random wrote:
| 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 wrote:
| Not necessary: stand up meetings.
| righthand wrote:
| 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 wrote:
| If your code output has been devalued then the strategy of
| lowering your input as a person might not be the best
| approach.
| selridge wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| nine_k wrote:
| This fact is opening the floodgates of low-end products, which
| are somehow better than nothing, but are embarrassing to use.
| vntok wrote:
| 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 wrote:
| 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 wrote:
| 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.
| hansonkd wrote:
| 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 wrote:
| 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 wrote:
| Autolands absolutely do exist.
| fxtentacle wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| _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 wrote:
| 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 wrote:
| This burden of review will go down as FOSS maintainers
| involve AI more.
| strobe wrote:
| 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 wrote:
| 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.
| TacticalCoder wrote:
| 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.
| whoisthemachine wrote:
| > compute shall keep getting cheaper as it's always been
| since 60 years or something
|
| past success is not a strong indicator for future
| success.
| xnx wrote:
| > 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.
| Ronsenshi wrote:
| 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 wrote:
| >> 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 wrote:
| 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.
| ej88 wrote:
| 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
| Ronsenshi wrote:
| I don't think it makes sense to consider top % of the talent
| - relative to the total amount of engineers I imagine it
| would be minuscule.
|
| It's the rest who will have to deal with shrinking number of
| positions, higher competition and possibly decrease in
| compensation due to said competition.
| ej88 wrote:
| Unfortunately agreed, i see swe (already) going the way of
| finance
|
| most jobs are okay comp 9-6s with a small group of elite
| talent making extremely outsized comp
|
| more emphasis on pedigree, exclusive hiring pipelines from
| top schools
| matthewkayin wrote:
| 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 wrote:
| 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/
| jdahlin wrote:
| 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 wrote:
| 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 wrote:
| 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.
| bryanrasmussen wrote:
| >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.
|
| sort of how the hammer is the most useful tool ever and all
| we have to do is to make every thing that needs doing look
| like a nail.
| skandinaff wrote:
| a new kind of operating system, that instead of having all
| those annoying apps, will just be an agent, that does
| whatever stuff you need|want|it can - why not? But still,
| we gonna need to be able to maintain many contexts, access
| remote servers, local file system, sort, present data, be
| it local or remote. One screen, one button, philosopher's
| stone made of silicon
| a_better_world wrote:
| LISP returns!
| jazzypants wrote:
| 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?
| jdahlin wrote:
| 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.
| baal80spam wrote:
| > 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.
| awepofiwaop wrote:
| The clear intent is to stop allowing regular people to be
| able to compute...anything. Instead, you'll be given a screen
| that only connects to $LLM_SERVER and the only interface will
| be voice/text in which you ask it to do things. It then does
| those things non-deterministically, and slower than they
| would be done right now. But at least you won't have control
| over how it works!
| chickensong wrote:
| Weather or not the intent is as nefarious as you suggest,
| that type of UI is going to be a boon for _a lot_ of
| people. Most people on the planet are incredibly computer
| illiterate.
| LtWorf wrote:
| Imagine what they could achieve with a non-deterministic
| computer that requires extremely detailed requests and
| weird language tricks to be convinced to do what you
| want!
| fmbb wrote:
| 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.
| ej88 wrote:
| 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
| sjaiisba wrote:
| 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...
| HWR_14 wrote:
| > With the time I spend on reviews I could have done it
| myself, so if they don't start learning...
|
| Then? Your job is still to review their code. If they are
| your coworker, you can not fire them.
| whoisthemachine wrote:
| Then just start rubber-stamping their code. Say you
| "vibe" read it.
| bwestergard wrote:
| "eye-watering, blistering growth from the new hot applied
| AI startups and labs"
|
| Could you give us a few examples?
| simonw wrote:
| Claude Cowork was apparently built in less than two weeks
| using Claude Code, and appears to be getting significant
| usage already.
| sjaiisba wrote:
| 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?
| bwestergard wrote:
| 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.
| ej88 wrote:
| 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
| simonw wrote:
| 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.)
| fmbb wrote:
| 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.
| falcor84 wrote:
| 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.
| fmbb wrote:
| OK but that also means VR was a success, and web 3, and
| NFTs.
| falcor84 wrote:
| 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.
| qudat wrote:
| OpenClaw is not going to be a thing in 6 months. The core
| idea might exist but that codebase is built on a house of
| cards and is being replicated in 10% of the code.
|
| I don't think anyone is arguing against code agents being
| good at prototypes, which is a great feat, but most SWE
| work is built on maintaining code over time.
| coldtea wrote:
| > _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.
| the_mitsuhiko wrote:
| 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.
| coldtea wrote:
| 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.
| simonw wrote:
| 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.
| coldtea wrote:
| 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...
| slopinthebag wrote:
| Shouldn't you want to ship less code that does more?
| Since when was LoC the relevant benchmark for
| engineering?
| simonw wrote:
| Less code isn't as important as it used to be, because
| the cost of maintaining (simple) code has gone down as
| well.
|
| With coding agent projects I find that investing in DRY
| doesn't really help very much. Needing to apply the same
| fix in two places is a waste of time as a human. An agent
| will spot both places with grep and update them almost as
| fast as if there was just one.
|
| It's another case where my existing programming instincts
| appear to not hold as well as I would expect them to.
| slopinthebag wrote:
| When you talk about maintaining code, do you mean having
| the LLM do it and you maintain a write-only codebase?
| Because if you're reading the code yourself and you have
| a bloated tangled codebase it would make things much
| harder right?
|
| Is the goal basically a codebase where your interactions
| are mediated through an LLM?
| simonw wrote:
| The goal is "good code" based on my list of criteria,
| which includes both "simple and minimal" and "the design
| affords future changes".
|
| A bloated table codebase isn't good code, because it's
| harder to understand and makers changes to than the
| equivalent non-bloated codebase.
|
| But... bloat does look a little bit different when you no
| longer need to optimize code for saving humans typing
| time.
|
| Much of the confusing code I've encountered during my
| career has been confusing because it had too many layers
| of indirection, which happened because someone was
| applying DRY too aggressively because they didn't want to
| duplicate even the smallest pieces of logic in more then
| one place.
|
| Good coding agents will only DRY like that if you tell
| them to.
| falcor84 wrote:
| > 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?
| layer8 wrote:
| > 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.
| falcor84 wrote:
| Oh, absolutely, my vision depends on AGI (and maybe even
| ASI), and I definitely agree that it'll be a whole new
| ball game.
| SignalStackDev wrote:
| 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.
| simonw wrote:
| 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!
| username223 wrote:
| > If we want to keep shipping at this speed
|
| Do we? Spewing features like explosive diarrhea is not
| something I want.
| ehnto wrote:
| I was having this conversation at work, where if the promise of
| AI coding becomes true and we see it in delivery speed, we
| would need to significantly increase the throughput of all
| other aspects of the business.
| alexhans wrote:
| Nice to see you here (Just reached out on bluesky over
| sandboxing - gandolin). I follow your work and agree and am
| hoping that you and others who have well earned audiences based
| on awesome open source work, can help with the advocacy on
| mental shifts, not just for developers but also non Devs that
| become builders.
|
| I'm very focused on their minimalistic building experience as a
| way to make me and other traditional developers, not the
| bottleneck and empowering them end to end.
|
| I think AI evals [1] are a big part of that route and hope that
| different disciplines can finally have probable product design
| stories [2] instead of there being big gaps of understanding
| between them.
|
| [1] https://alexhans.github.io/posts/series/evals/measure-
| first-...
|
| [2] https://ai-evals.io
| salty_frog wrote:
| The focus is on downstream, but is upstream ready for this
| speed up?
|
| The linked blog post draws comparisons to the industrial
| revolution however in the industrial revolution the speed up
| caused innovation upstream not downstream.
|
| The first innovation was mechanical weaving. The bottleneck was
| then yarn. This was automated so the bottleneck became cotton
| production, which was then mechanised.
|
| So perhaps the real bottleneck of being able to write code
| faster is upstream.
|
| Can requirements of what to build keep up with pace to deliver
| it?
| DrJid wrote:
| 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 wrote:
| 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 wrote:
| Then why did most software fail to do that even before the
| advent of LLMs?
| sethops1 wrote:
| 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 wrote:
| Are we sure it's not failing anymore after the advent of
| LLMs?
| stackghost wrote:
| 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.
| LtWorf wrote:
| And you think these people will now produce better
| results with the assistance of an LLM that was trained on
| their work?
| stackghost wrote:
| No, that's the opposite of what I think.
|
| Bootcamp grads are basically obsolete now. The real skill
| has always been the ability to make good design decisions
| and that's still the case in the LLM era.
| locknitpicker wrote:
| > Bootcamp grads are basically obsolete now.
|
| I beg to differ. I know for a fact that some companies
| started hiring people with LLM experience, whose only
| expertise is spending all Copilot enterprise account
| tokens on their first week at the job and proceed to
| whine that the lack of tokens was stifling their
| creativity.
|
| Say what you may about boot camps, but at least the
| people getting hired could do things and understand what
| they are doing.
| margorczynski wrote:
| > The real skill has always been the ability to make good
| design decisions and that's still the case in the LLM
| era.
|
| For now maybe yes but the goal is totally removing the
| human from the decision loop regarding technical stuff.
| simonw wrote:
| 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.
| rhubarbtree wrote:
| Agreed, often see cope from managers along the line of
| "writing the code was never the bottleneck". Well, sure
| felt like it.
| LtWorf wrote:
| For most people who can type with more than 2 fingers,
| thinking what to type is slower than typing it.
| fmbb wrote:
| 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.
| arijun wrote:
| It's probably a better indicator of a good business idea than
| if you get slapped in the face...
| arghwhat wrote:
| And yet, who would you trust more - a CEO that raised 100M
| on their "vision" or someone who got slapped in the face?
| toomuchtodo wrote:
| 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_e
| very_...
|
| [4] https://en.wikipedia.org/wiki/Overconfidence_effect
|
| [5] https://en.wikipedia.org/wiki/Survivorship_bias
| LtWorf wrote:
| I mean, juicero got the money instead of the slaps in the
| face it deserved. And there's thousands of startup like
| that. I think VCs are terrible at picking and a dice would
| probably do a better job.
| kneel25 wrote:
| 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.
| crystal_revenge wrote:
| > 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.
| dw_arthur wrote:
| 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.
| sillyfluke wrote:
| >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.
| crystal_revenge wrote:
| 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.
| sillyfluke wrote:
| >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...My current belief is not that AI
| will replace traditional software engineering it will
| replace a good chunk of the entire model of software
|
| You're not following your last line to its logical
| conclusion regarding your own prospects: no one is going
| to buy the vibeslop your two person agency is selling
| because they'd rather create and maintain their own
| vibeslop instead of dealing with yours.
|
| If you follow some of your thoughts to their logical
| conclusion you'll realize the parent is right: there will
| be limited productivity that ends up fueling the economy
| when nobody is buying each other's vibeslop.
| crystal_revenge wrote:
| We're not selling vibe slop, the "vibe slop" tools which
| work for one person enable of automation of tasks for the
| services we sell. Whether or not we use AI behind the
| scenes is entirely irrelevant to the service we're
| providing other than that it allows _our_ margins to be
| higher and our speed of implementation to be faster.
|
| I absolutely agree that it's not logical to think "oh
| we'll sell our AI stuff", that's the old model (which is
| just a variation on SaaS). I suspect a lot of HNers can't
| imagine a "product" that isn't code, but that's not at
| all what I'm describing.
|
| The products that most people on HN have traditionally
| built are used by other companies to make money by
| allowing those processes to be scaled. AI, in many new
| cases, eliminates the need for a 'software' middle man.
| The case I'm describing is "I know how to make money
| doing X if only I could scale it up with out hiring
| people" and my offering is "I can scale it up without
| hiring people".
|
| This is increasingly where I think the future of work is
| headed, and it's more than fine if you aren't convinced.
| halfcat wrote:
| > it allows our margins to be higher and our speed of
| implementation to be faster
|
| Faster than what? You will be faster than your previous
| self, just like all of your competitors. Where's the net
| gain here? Even if you somehow managed to capture more
| value for yourself, you've stopped providing value to
| 5-10x that many employees who are no longer employed.
|
| When costs approach zero on a large scale, margins do not
| increase. Low costs = you're not paying anyone = your
| competitors aren't paying anyone = your customers no
| longer have money = your revenue follows your costs
| straight to zero.
|
| Companies that provide physical services can't scale
| without hiring. A one-man "crew" isn't putting a roof on
| a data center.
|
| I want to be wrong. Tell me why you think any of this is
| wrong.
| jasondigitized wrote:
| But they can scale hiring
| HWR_14 wrote:
| > If this were to work, could theoretically make nice
| revenue and it shouldn't show up in any metric anywhere.
|
| Except production GDP, the standard measure of economic
| activity.
| FrojoS wrote:
| Correct me, but if two people create a SAAS that can
| replace a 50 people SAAS, compete on price and the
| competitor is forced out of the market, wouldn't this
| show up as an reduction in GDP? Efficiency
| (GDP/time_worked) should be up though, and AFAIK it
| isn't.
| ahtihn wrote:
| 2 people are now producing what took 50 people
| previously.
|
| What are the 48 other people doing now? Presumably some
| other economic activity.
| HWR_14 wrote:
| Yes, when prices of goods and services go down so will
| GDP. I've not seen evidence of the prices of SaaS going
| down in the past few years.
| bryanrasmussen wrote:
| >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.
|
| potentially...if this were to work...theoretically
|
| shouldn't show up? I would worry that something with so
| many variables wouldn't show up.
| fragmede wrote:
| I wouldn't say it hasn't shown up. The number of ShowHN's
| per weekend has definitely gone up, and while that isn't
| rigorous scientific proof, I'd consider is a leading edge
| indicator of _something_. Unfortunately, we as an industry
| have yet to agree on anything approaching a scientific
| measure of productivity, other than to collectively agree
| that Lines of Code is universally agree that LoC is
| terrible. Thus even if someone was able to quantify that,
| say, they 're having days where they generate 5000 LoC when
| previously they were getting O(500) LoC, that's not
| something we could agree upon as improved productivity.
|
| So then the question is, lis there anything other than
| feels to say productive has or has not gone up? What would
| we accept as _actual_ evidence one way or another? Commits-
| per-day is similarly not a good measure either. Jira
| tickets and tshirts sizes? We _don 't_ have a good measure,
| so while ShowHN's per weekend is equally dumb, it's also
| equally good in the bag of lies, damn lies, and statistics.
| bitdiffusion wrote:
| There was a post a few days ago about how the quality of
| SnowHN had gone down with people asking how they could
| block this category of submissions - so I wouldn't be too
| quick to equate an increase in ShowHN with anything
| positive.
| fragmede wrote:
| Whether or not it is positive is a matter of opinion, but
| it undeniable that the ShowHNs exist.
| kakapo5672 wrote:
| This is actually an old syndrome with technology. It takes
| a longt ime for the effect to be reliably measured.
| Famously, it took many years for the internet itself to
| show up in significant productivity gains (if the internet
| is actually useful why don't the numbers show that? - a
| common comment in the 1990s and 2000s). So it seems to me
| we're just the usual dynamic here. Productivity in
| trillion-dollar economies do not turn on a dime
| joe_mamba wrote:
| _> Famously, it took many years for the internet itself
| to show up in significant productivity gains_
|
| Yeah but the actual productivity gains that the internet
| and software tools introduced has had diminishing returns
| after a while.
|
| Like, are people more productive today when they use
| Outlook and Slack than they were 20 years ago when using
| IBM Lotus Notes and IBM Sametime? I'm not. Are people
| more productive with the Excel of today than with Excel
| 2003/2007? I'm not. Is Windows 11 and MacOS Tahoe making
| people more productive than Windows 7 and Snow Leopard?
| Not me. Are IDEs of today offering so much more
| productivity boost than what Visual Studio, CodeWarrior
| and Borland Delphi did back in the day? Don't think so.
|
| To me it seems that at least on the productivity side,
| we've mostly been reinventing the wheel "but in
| Rust/Electron" for the last 15 or so years, and the
| biggest productivity gains came IMHO from increased
| compute power due to semiconductor advancement, so that
| the same tasks finished faster today than 20 years ago,
| but not that the SW or the internet got so much more
| capable since then.
| simonw wrote:
| I think the biggest productivity improvements in software
| development over the last ~20 years came from open source
| (NPM install X / pip install Y save _so much time_
| constantly reinventing wheels) and automated tests.
| ehnto wrote:
| My intuition from talking to people across different parts
| of the industry, is that adoption at bigger companies is
| really limited or slow, or totally banned. Additionally
| some developers are not seeing it help their specific roles
| all that much anyway. This is hard to level with success
| other people are having, but software is a super broad
| discipline which I think explains a lot of the mixed
| success stories.
|
| It seems to depend a lot on the industry and niche you're
| in, working at an agency I get experience across many
| different projects and industries and sometimes you are
| just at the edge of AIs training and it can get very
| unhelpful. Noting many if not most companies are working on
| proprietary code in donain specific problems, that isn't
| all that surprising either.
| LtWorf wrote:
| I think if you're doing front-end development AI is good.
| If you are reading a db and sending a json to said webpage
| AI is decent, if you are doing literally anything else AI
| is next to useless.
|
| At least, in my own experience.
| ehnto wrote:
| That's a great insight about iterating on bespoke tools. I
| have seen the most speed up when diving into new tools, or
| making new tools as AI can make the initial jump quite
| painless, and I can get straight to the problem solving. But
| I get barely any speedup using it on legacy projects in tools
| I know well. Often enough it slows me down so net benefit is
| nil or worse.
|
| Another commentor said it makes the easy part easy, and the
| hard part harder, which I resonate with at the moment.
|
| I am pretty excited by being able to jump deep into real
| problems without code being the biggest bottleneck. I love
| coding but I love solving problems more, and coding for fun
| is very different to coding for outcomes.
| mjevans wrote:
| That's my observation / fear as well. It makes delivering
| something that sort of works easy. It makes doing that well
| more difficult by obscuring the problem domain from the
| humans and expanding the standard library of tools into
| patterns of using said standard library. Hope they're
| correct for your use case.
|
| There's also the question of the true cost of all the
| hardware, electricity, and potential output that's being
| tossed onto the pyres. We aren't getting the real Cortana
| from the books / games; we're getting GIR trained on the
| corpus of fallible human code, prompted by fallible humans.
| slopinthebag wrote:
| Or another way of looking at it: just because digging a ditch
| became cheap and fast with the backhoe doesn't mean you can
| just dig a bunch of ditches and become rich.
| scuff3d wrote:
| Yeah but there were a lot less ditch diggers in the world
| after the invention of the backhoe
| slopinthebag wrote:
| If true, only because people knew where to dig and did it
| with purpose.
| locknitpicker wrote:
| > Yeah but there were a lot less ditch diggers in the world
| after the invention of the backhoe
|
| As a specialization? Sure. But the ditch diggers moved
| since to machine operators, handymen and the like.
|
| In the past there were sysadmins. Do we have less software
| engineers since sysadmins ceased to be a thing?
| wiseowise wrote:
| > As a specialization? Sure. But the ditch diggers moved
| since to machine operators, handymen and the like.
|
| All of them? What if they liked digging ditches?
|
| > In the past there were sysadmins. Do we have less
| software engineers since sysadmins ceased to be a thing?
|
| Software Engineers were never sysadmins in the past,
| you're thinking DevOps maybe?
| simonw wrote:
| The software engineers who like "digging ditches" are
| going to have a bad time in the new agentic engineering
| world, unfortunately.
|
| Here "digging ditches" corresponds to somebody else
| figuring out the detailed requirements and specification
| and handing it to the engineer to transcribe into code.
|
| That's what the coding agents replace. Thankfully for
| most engineers I've worked with that's only a small part
| of their overall jobs, albeit one of the most time
| consuming.
| 0cf8612b2e1e wrote:
| 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 wrote:
| Worth reiterating due to the skyrocketing costs of RAM.
| fxtentacle wrote:
| With a bit of AI sprinkled in, Rust code can surely also waste
| gigabytes of RAM on "Hello World" ;)
| cube00 wrote:
| 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 wrote:
| 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
| duggan wrote:
| 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 wrote:
| Code is cheap is the same as saying "Buying on credit is easy".
| Code is a liability, not an asset.
| danesparza wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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?
| OptionOfT wrote:
| 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.
| qudat wrote:
| What happens when there's a service outage and you cannot
| debug code without an agent?
| duggan wrote:
| Like any service outage out of their control, people will
| find other things to do until it's over.
| wiseowise wrote:
| Afternoon latte and useless meetings won't do themselves!
| simonw wrote:
| Switch to a rival service that doesn't have an outage.
| There are at least half a dozen competent hosted LLM
| vendors for coding now (Anthropic, OpenAI, Gemini, Mistral,
| Kimi, MiniMax, Qwen, ...)
| leptons wrote:
| > _Code is a liability, not an asset_
|
| Then "AI" code is even more of a liability.
| beagle3 wrote:
| Code you can't just throw away is a liability because you have
| to keep supporting it / servicing it. Claude Code and friends
| also change that part of the cost equation:
|
| You might not get gcc/llvm level optimization from a newly
| built compiler - but if you had a home-built one, which took
| $15,000/month engineer to support (for years!) you can now get
| a new one for $20,000 every 3 months, for a 50% cost saving,
| each time changing your requirements (which you couldn't do
| before).
|
| Code used to be a liability, like a car or an apartment for the
| average person. Now it's a liability, like a car or apartment
| for Bill Gates.
| Oras wrote:
| > 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 wrote:
| Because it has been trained on Java class spaghetti.
|
| When it's trained on enough APL/K code, you'll get minimal
| abstraction.
| alex-nt wrote:
| > 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 wrote:
| 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.
| dgeiser13 wrote:
| If writing code is cheap now why is there so much money involved?
| firefoxd wrote:
| 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...
| octoclaw wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| slopinthebag wrote:
| Hmm interesting, I didn't realise people were using it as
| a typing replacement instead of having it work
| agentically. Does that mean when you want to change a
| line of code somewhere, you just prompt the LLM to
| replace line 334 with your changes etc? So do you not use
| the LLM autonomously at all then? Sounds like it since
| you're still doing the iteration yourself.
| simonw wrote:
| I do both. A lot of changes are "autonomous" like "add a
| new Django model to record a change every time the title
| or body is edited in the admin", but I also do more fine
| grained edits like "have the import script truncate to
| 400 chars" (instead of 250.)
|
| Sometimes I'll make edits like 400 to 250 by hand, but if
| I'm prompting on my phone it's faster to have the model
| do it as navigating code in an editor and changing it at
| the exact right point is fiddly on a mobile keyboard -
| models can spot and account for typos, direct code
| editing can't.
| Cyphase wrote:
| > 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.
|
| Okay, granted. What does that have to do with how the code is
| written? Do people generally care if a web app is running
| from nicely formatted JS or minified JS? Is a product manager
| not getting better at building things people like because
| they're not iterating on the code themselves?
|
| Without agreeing or disagreeing with the premise, I think a
| relevant metaphor* here is that the painter can practice and
| iterate and go from creating crappy paintings to creating
| good paintings, without needing to make their own paint and
| canvas and brushes. If they're particular, they can have
| their assistant go to the supply shop and get just the right
| things they want, with increasing specificity as needed, but
| they don't need to manufacture them by hand.
|
| * Like most metaphors, it's not perfect; please try to
| understand the intent.
| slopinthebag wrote:
| I agree mostly with your metaphor, I think perhaps I
| disagree slightly on how it's applied. You don't need to
| create your own tools to create art, but I don't
| necessarily map the "tools" to code. The act of programming
| is mapping information to hardware, the value is in the
| information, and using LLM's to bypass the phase where you
| obtain, synthesise, and extend that information is the part
| where you lose the benefits of iteration. If you're just
| using the LLM as a mechanical tool to output code, it's
| mostly not different from, say, using speech-to-text to
| output code. When you start hearing things like "I don't
| care about the quality of the code, just it's outputs" that
| starts sounding like someone isn't iterating on the
| information which is the crucial bit.
| alexhans wrote:
| I think the prototype thing is absolutely true but breaks down
| like all prototypes at the level of collaborating, sharing and
| evolving while handling entropy throug simplicity UNLESS you
| know what you're doing or the agent steers you with very
| opinionated tooling customized to your context. I'm thinking
| about empowering people to be builders and less so a software
| developer who can make the right tradeoffs.
|
| Empowering people to work Tracer bullet style after they've
| selected their prototype of choice and thrown it away might be
| a powerful pattern that actually gets us into a nice
| collaborative space.
| efilife wrote:
| I shit you not, this is an AI generated comment. All recent
| comments from this profile are AI generated. This is so ironic
| mentalgear wrote:
| 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 wrote:
| 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.
| lelanthran wrote:
| > 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 wrote:
| 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 wrote:
| 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...
| eesmith wrote:
| 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 wrote:
| 100%. That's why if you want _good_ code you need to pay
| attention to what it 's writing and testing and throw
| feedback like that at it.
| eesmith wrote:
| My points though are
|
| 1) the development isn't actually using red/green TDD, and
|
| 2) the result doesn't show "really good results", including
| not following a very well-defined specification
|
| so doesn't work as a concrete example of your description
| of what the second chapter is supposed to be about.
|
| Perhaps you could show the process of refining it more, so
| it actually is spec compliant and tests all the implemented
| features?
|
| What's the outcome difference between this approach vs.
| something which isn't TDD, likes test-after with full
| branch coverage or mutation testing? Those at least are
| more automatable than manual inspection, so a better fit to
| agentic coding, yes?
|
| (Of course regular branch coverage doesn't test all the
| regexp branches, which makes regexp use tricky to test.)
| simonw wrote:
| Yeah I'm going to ditch those examples and find better
| ones. I was hoping to illustrate the idea as simply as
| possible but they're not up to scratch.
| eesmith wrote:
| I think the problem-to-solve is a good one. The Google
| Markdown spec is very clear, with plenty of examples, and
| I think the problem is well-defined.
|
| I've seen entirely too many examples of how to use TDD
| which give under-specified toy problems, where the
| solution is annoyingly incomplete for something more
| realistic.
|
| And I've seen TDD projects which didn't follow the spec,
| but instead implemented the developers' misconceptions
| about the spec.
|
| That's exactly what we see here with Markdown, where
| there's a spec, along with a lot of non-conformant
| examples in the training set by people who didn't read
| the spec but instead based it on their experiences in
| using Markdown.
|
| The code generated by ChatGPT is almost correct. Seeing
| the process of how to get from that to a valid and well-
| tested solution would make for a good demonstration of
| the full process.
|
| I'll again add that showing how to integrate something
| like branch coverage or hypothesis testing for automatic
| test suite generation would be really useful.
| alexjray wrote:
| "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 wrote:
| Related:
|
| _Code is cheap. Show me the talk_
|
| https://news.ycombinator.com/item?id=46823485
| torginus wrote:
| 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 wrote:
| 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 wrote:
| I for one would rather see the doodles
| simonw wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Writing code has always been cheap. Deciding what the logic
| should be, and being able to change course was the hard bit.
| falcor84 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Spot on
| frizlab wrote:
| But writing good code is still not cheap.
| simonw wrote:
| See my heading half way down the page!
| tabs_or_spaces wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| inejge wrote:
| > 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.
|
| Which is nuance that will get overlooked or waved away by
| upper management who see the cost of hiring developers, know
| that developers "write code", and can compare the developer
| salary with a Claude/Codex/whatever subscription. If the
| correction comes, it will be late and at the expense of rank
| and file, as usual. (And don't be naive: if an LLM
| subscription can let you employ fewer developers, that
| subscription plus offshore developers will enable even more
| cost saving. The name of the game is cost saving, and has
| been for a long time.)
| dasil003 wrote:
| Sure, but clueless leadership is not a new thing. While big
| companies with structural moats can shamble along with a
| surprising amount of dysfunction (which is why they
| tolerate so many muppets in middle management), even they
| rely on some baseline of system integrity that will erode
| pretty quickly if they let go of the people who know how
| things work.
|
| Don't get me wrong, I think SWE headcounts will reduce over
| time, but the mechanism will be teams that know how to
| leverage AI effectively will dominate ones who don't. This
| takes more market cycles though, and it's even hard to nail
| down the specifics of these skills with the speed agentic
| coding tools are currently evolving. My advice is make
| yourself part of the second group, and worry less about bad
| management decisions that are inevitable.
| jimbokun wrote:
| Value of Claude subscription: $0
|
| Value of developer + Claude subscription: N * value of
| developer without Claude subscription where N is still the
| subject of intense debate.
| kranner wrote:
| > I was careful to say "Good code still has a cost" ...
|
| Misleading headline, with the qualifier buried six paragraphs
| deep. You have a wide enough readership (and well deserved
| too). Clickbait tactics feel a little out of place on your
| blog.
| simonw wrote:
| This is the chapter title for a sort-of book I'm working
| on, and it's the central philosophy I'm building the book
| around.
|
| I'm not going to change a good chapter title (and I do
| think it's a good chapter title) just because people on
| Hacker News won't read a few paragraphs of content.
|
| A dishonest title would be "Code is cheap now" or
| "Programming is cheap now". I picked "Writing code is cheap
| now" to capture that specifically the bit where you type
| code into a computer is the thing that's cheap.
| kranner wrote:
| Fairly esoteric and self-serving definition of "writing
| code" if it represents just the typing part. I wouldn't
| call it a dishonest title, but perhaps not a fully honest
| one either.
| mexicocitinluez wrote:
| > I chose this words because I don't think good code is
| nearly as expensive with coding agents as it was without
| them.
|
| Still navigating this territory, but I think a lot of people
| are getting caught up on the idea that producing code is
| simply a matter of typing it at the keyboard.
|
| One of the benefits of something like Claude Code _isn 't_
| just the code it produces, but the ability to quickly try out
| ideas, get some feedback, AND THEN write the good code.
|
| > than the more aesthetically pleasing
|
| Agreed. What even is "good" code? So much of the bad code I
| write isn't necessarily that it's ugly, it's bad because it
| misses the mark. Because I made too many assumptions and
| didn't take the time to actual learn the domain. If I can eek
| out even a few more hours a week to actually build worthwhile
| solutions because I was able to focus a bit more, it's a win
| to me. My users in particular have a really difficult time
| imagining features without actually seeing them. They have a
| hard to articulating what's wrong/right without something
| tangible in front of them. It would be hard to argue that
| having the ability to quickly prototype and demo features to
| people is a bad thing.
| jimbokun wrote:
| This was the single worthwhile point behind "agile"
| development: getting new code in front of users as quickly
| as possible to know whether or not you're building the
| right thing.
|
| With agile that meant delivering something to evaluate
| every two weeks instead of 6 months or a year. Now with AIs
| maybe it should be a new version every day? Are current
| processes outside of writing the code capable of supporting
| that cadence? Do users even want to try new versions that
| often?
| mmsc wrote:
| Spaghetti code was always a thing though
| chasd00 wrote:
| Yeah people going on and on about peerless human generated
| code reminds me of that scene in iRobot when the cop asks
| sonny "can a robot create a work of art?" And the robot
| replies "can you?". In 30 years in this industry I've yet
| seen what I would describe as perfect and maintainable code.
| It's an aspirational dream not SOP.
| unfunco wrote:
| Computer programming is cheap. Software engineering is
| expensive.
| wlruys wrote:
| Definitely the market incentives for "good code" have never
| been worse, but I'm wouldn't be so sure the cost of migrating
| decent pieces of generated code to good code is worse than
| writing good code from whole cloth.
| strogonoff wrote:
| I find that implementing a sound solution from scratch is
| generally lower effort than taking something that already
| exists and making it sound.
|
| The former: 1) understand the problem, 2) solve the problem.
|
| The latter: 1) understand the problem, 2) solve the problem,
| 3) understand how somebody or something else understood &
| solved the problem, 4) diff those two, 5) plan a transition
| from that solution to this solution, 6) implement that
| transition (ideally without unplanned downtime and/or
| catastrophic loss of data).
|
| This is also why I'm not a fan of code reviews. Code review
| is basically steps 1-4 from the second approach, plus having
| to verbally explain the diff, every time.
| locknitpicker wrote:
| > This is also why I'm not a fan of code reviews.
|
| That's specious reasoning. Code reviews are a safeguard
| against cowboy coding, and a tool to enforce shared code
| ownership. You might believe you know better than most of
| your team members, but odds are a fresh pair of eyes can
| easily catch issues you snuck in your code that you
| couldn't catch due to things like PR tunnel vision.
|
| And if your PR is sound, you certainly don't have a problem
| explaining what you did and why you did it.
| strogonoff wrote:
| Code reviews have their place. I just personally don't
| like being the reviewer, because it's more effort on your
| part than just writing the damn thing from scratch while
| someone else gets the credit for the result[0]. Of
| course, having multiple pairs of eyes on the code and
| multiple people who understand it is crucial.
|
| [0] Reviews are OK if I enjoy working with the person
| whose work I'm reviewing and I feel like I'm helping them
| grow.
| bfbf wrote:
| In my experience, it's even _more_ effort to get good code with
| an agent-when writing by hand, I fully understand the rationale
| for each line I write. With ai, I have to assess every clause
| and think about why it's there. Even when code reviewing
| juniors, there's a level of trust that they had a reason for
| including each line (assuming they're not using ai too for a
| moment); that's not at all my experience with Codex.
|
| Last month I did the majority of my work through an agent, and
| while I did review its work, I'm now finding edge cases and
| bugs of the kind that I'd never have expected a human to
| introduce. Obviously it's on me to better review its output,
| but the perceived gains of just throwing a quick bug ticket at
| the ai quickly disappear when you want to have a scalable
| project.
| cpursley wrote:
| Throw your next bug at this:
| https://skills.sh/obra/superpowers/systematic-debugging
| mixologic wrote:
| I find it amazing that skills are essentially excellent
| tools for humans to understand too.
| Vegenoid wrote:
| I really wish they were called lessons instead of skills.
| It makes way more sense and prevents the overloading of
| the term "skill".
| soulofmischief wrote:
| We'd just be overloading "lessons" as well, and even more
| so because it takes more work to ground the concept,
| given its larger semantic distance from what we're
| describing.
| mycall wrote:
| There is some papers [0] showing that the skill and agent
| files reduce the reasoning effectiveness in some use
| cases (e.g. autogenerated)
|
| [0] https://arxiv.org/abs/2602.11988
|
| reference: https://news.ycombinator.com/item?id=47034087
| frgturpwd wrote:
| I hear you, but it seems quicker to predict whether the
| agent's solution is correct/sound before running it than to
| compose and "start" coding yourself. Understanding something
| that's already there seems like less effort. But I guess it
| highly depends on what you are doing and its level of
| complexity and how much you're offloading your authority and
| judgment.
| zozbot234 wrote:
| You need to have the AI write an increasingly detailed design
| and plan about what to code, assess the plan and revise it
| incrementally, then have it write code as planned and assess
| the code. You're essentially guiding the "Thinking" the AI
| would have to perform anyway. Yes, it takes more time and
| effort (though you could stop at a high-level plan and still
| do better than not planning at all), but it's way better than
| one-shotted vibe code.
| edgyquant wrote:
| This works but still lacks most context around previous
| tasks and it isn't trivial to get it to take that into
| account.
| pdhborges wrote:
| The problem is those plans become huge. Now I have to
| review a huge plan and the comparatively short code change.
| zozbot234 wrote:
| It shouldn't be any longer than the actual code, just
| have it write "easy pseudocode" and it's still something
| that you can audit and have it translate into actual
| coding.
| mycall wrote:
| TDD is a great way to start the plan, stubbing things it
| needs to achieve with E2E tests being the most important.
| You still need to read through them so it won't cheat, but
| the codebase will be much better off with them than without
| them.
| heisenbit wrote:
| There is demand for non scalable, not committed to be
| maintained code where smaller issues can tolerated. This
| demand is currently underserved as coding is somewhat
| expensive and focused on critical functions.
| Retr0id wrote:
| What are some examples of when buggy code can be tolerated?
| simonw wrote:
| If the code is being used by a small group of people who
| are willing to figure out and share workarounds for those
| bugs - internal staff, for example.
| skydhash wrote:
| Aren't you also paying internal staff for their time.
| Waisting their time is waisting your money.
| simonw wrote:
| I've been in these situations before. If there's a known
| bug in an internal tool that would take the development
| team a day to investigate and fix - aka $10,000s - it's
| often smarter to send around an email saying "don't click
| the Froople button more than once, and if you do tell
| Benjamin and he'll fix it in the database for you".
|
| Of course LLMs change that equation now because the fix
| might take a few minutes instead.
| dns_snek wrote:
| > development team a day to investigate and fix - aka
| $10,000s
|
| What about the non-fictional 99.999999999% of the world
| that doesn't make $1000/hour?
| bubblewand wrote:
| Large companies are often very bad at organizing work, to
| the tune of increasing the cost of everything by a large
| multiple over what you'd think it should be. Most of that
| cost wouldn't be productive developer time.
| simonw wrote:
| It costs them single digit thousands instead.
| zahlman wrote:
| > If there's a known bug in an internal tool that would
| take the development team a day to investigate and fix -
| aka $10,000s - it's often smarter to send around an email
| saying "don't click the Froople button more than once,
| and if you do tell Benjamin and he'll fix it in the
| database for you".
|
| How much will Benjamin's time responding to those calls
| cost in the long run?
| simonw wrote:
| Hopefully none, because your staff will read the email
| and not click the button more than once.
|
| Or one of them will do it, Benjamin will glare at them
| and they'll learn not to do it again and warn their
| coworkers about it.
|
| Or... Benjamin will spend a ton of time on this and use
| that to successfully argue for the bug to get fixed.
|
| (Or your organization is dysfunctional and ends up
| wasting a ton of money on time that could have been saved
| if the development team had fixed the bug.)
| jimbokun wrote:
| The alternative is the staff having no software at all to
| help with their task which wastes even more of their
| time.
| dktp wrote:
| From recent personal examples
|
| We have a somewhat complicated OpenSearch reindexing
| logic and we had some issue where it happened more
| regularly than it should. I vibecoded a dashboard
| visualizing in a graph exactly which index gets reindexed
| when and into what. Code works, a little rough around the
| edges. But it serves the purpose and saved me a ton of
| time
|
| Another example, in an internal project we made a recent
| change where we need to send specific headers depending
| on the environment. Mostly GET endpoint where my workflow
| is checking the API through browser. The list of headers
| is long, but predetermined. I vibecoded an extension that
| lets you pick the header and allows me to work with my
| regular workflow, rather than Postman or cURL or
| whatever. A little buggy UI, but good enough. The whole
| team uses it
|
| I'm not a frontend developer and either of these would
| take me a lot of time to do by hand
| Itoldmyselfso wrote:
| _Points at the public sector_
| jodrellblank wrote:
| You are setting up to say "I wouldn't tolerate that" for
| any example given, but if you look at the market and what
| makes people actually leave, instead of what makes people
| complain, then basically anything that isn't life-and-
| death, safety critical, big-money-losing, or data
| corrupting is tolerable. There's plenty of complaints
| about Microsoft, Apple, Gmail, Android, and all kinds of
| 3rd party niche business systems.
|
| [Edit: DanLuu "one week of bugs":
| https://danluu.com/everything-is-broken/ ]
|
| All the decades people tolerated blue-screens on Windows.
| All the software which regularly segfaulted years ago.
| The permeation of "have you tried turning it off and on
| again" into everyday life. The "ship sooner, patch later"
| culture. The refusal to use garbage collected or memory
| managed languages or formal verification over C/C++/etc
| because some bugs are more tolerable than the
| cost/effort/performance costs to change. Display and
| formatting bugs, e.g. glitches in video games. When error
| conditions aren't handled - code that crashes if you
| enter blank parameters. Bugs in utility code that doesn't
| run often like the installer.
|
| One software I installed yesterday told me to disable
| some Windows services before the install, then the
| installer tried to start the services at the end of the
| install and couldn't, so it failed and finished without
| finishing installing everything. This reminded me that I
| knew about that, because that buggy behaviour has been
| there for years and I've tripped over it before; at least
| two major versions.
|
| Another one I regularly update tells me to close its
| running processes before proceding with the install, but
| after it's got to that state, it won't let me procede and
| it has no way to refresh or rescan to detect the running
| process has finished. That's been there for years and
| several major versions as well.
|
| One more famous example is """I'm not a real programmer.
| I throw together things until it works then I move on.
| The real programmers will say "Yeah it works but you're
| leaking memory everywhere. Perhaps we should fix that."
| I'll just restart Apache every 10 requests.""" - Rasmus
| Lerdorf, creator of PHP. I've a feeling that was admitted
| about 37 Signals and Basecamp, it was common to restart
| Ruby-on-Rails code frequently, but I can't find a source
| to back that up.
| vips7L wrote:
| > Even when code reviewing juniors, there's a level of trust
| that they had a reason for including each line (assuming
| they're not using ai too for a moment)
|
| Even my seniors are just copy pasting out whatever Claude
| says. People are naturally lazy, even if they know what
| they're doing they don't want to expend the effort.
| renegat0x0 wrote:
| I think the cost and work remains the same. What has change is
| efficiency. Previously people had to manually program byte
| after byte. Then came C and streamlined it, allowing faster
| development.
|
| With python I can write a simple debugging UI server with a few
| lines.
|
| There are frameworks that allow me to complete certain tasks in
| hours.
|
| You do not need to program everything from scratch.
|
| The more code, the faster everything gets, since the job is
| mostly done.
|
| We are accelerating, but we still work 9 to 5 jobs.
| shiroiuma wrote:
| C, Python, and frameworks don't generate all-new code for
| every task: you're taking advantage of stuff that's
| thoroughly tested. That simple debugging UI server is
| probably using some well-tested libraries, which you can
| reasonably trust to be bug-free (and which can be updated
| later to fix any bugs, without breaking your code that relies
| on them). With AI-generated code, this isn't the case.
| renegat0x0 wrote:
| Depends on what you think with AI-generated code. Do you
| mean vibe-coded? If yes, then I agree, but there are also
| other scenarios of AI-generated code.
|
| I use regularly AI in my hobby projects, it provides me
| feedback, proposed other libraries to use, or other
| solutions. It generates some classes for which I write
| tests. I also need to understand the code it generates. If
| I don't I don't use it. It does speed up my process of
| creation of code.
|
| If other people also are accelerated lets say 30% then,
| everything is sped up, cheaper. I think many people use it
| AI like that. It is just a tool, like a hammer, with which
| you can harm yourself if you do not know how to use it.
| skydhash wrote:
| > I think the cost and work remains the same. What has change
| is efficiency. Previously people had to manually program byte
| after byte. Then came C and streamlined it, allowing faster
| development.
|
| I think you got your history wrong. People didn't program bit
| by bit. They programmed on paper (flowcharts, pseudo-code,
| diagrams,...), then encoded that afterwards. There was a lot
| of programming languages before C like Lisp and APL (which
| are high-level, btw). Why would they waste precious computer
| time, when you could plan out procedures on a notepad or a
| whiteboard.
| thih9 wrote:
| > When you drop your standards, then writing generated code is
| quick, easy and cheap.
|
| Not as cheap as generating code of equivalent quality with an
| LLM.
| ap99 wrote:
| Code has a generation cost and a maintenance cost.
|
| If you just look at generation then sure it's super cheap now.
|
| If you look at maintenance, it's still expensive.
|
| You can of course use AI to maintain code, but the more of it
| there the more unwieldy it gets to maintain it even with the
| best models and harnesses.
| kakacik wrote:
| I 'love' that folks are seemingly inching slowly towards more
| acceptance of crappy llm code. Because it costs marginally
| less to produce to production if you just pass some smoke
| tests? Have we not learned anything about technical debt and
| how it bites back hard? Its not even seniority question,
| rather just sane rational approach to our craft unless one
| wants to jump companies every few months like a toxic useless
| apple (not sure who would hire such person but world is big
| and managers often clueless).
|
| There are of course various use cases, for few this is an
| acceptable tradeoff but most software ain't written once and
| never touched (significantly) again, in contrary.
| hnthrow0287345 wrote:
| People aren't interested in long-term thinking when
| companies are doing layoffs for bullshit reasons and making
| vague threats about how most of us will have to go find a
| new career which causes a heck of a lot of stress and
| financial costs. That isn't being petty, it's having self-
| respect. They get the quality when the companies treat the
| craftspeople with respect.
| pdhborges wrote:
| I wouldn't say acceptance of crappy code. I think the issue
| is the acceptance of LLM plans with just a glance and the
| acceptance of code without any code review by the author at
| all because if the author would waste any more time it
| wouldn't be worth it anymore.
| kranner wrote:
| The inching-towards-acceptance of crappy processes is quite
| influencer-driven as well, with said influencers if not
| directly incentivised by LLM providers, then at least
| indirectly incentivised by the popularity of outrageous
| exhortations.
|
| There's definitely a chunk of the developer population
| that's not going to trade the high-craft aspects of the
| process for output-goes-brrr. A Faustian bargain if ever I
| saw one. If some are satisfied by what comes down to vibe-
| testing and vibe-testing, I guess we wish them well from
| afar.
| Majromax wrote:
| > Have we not learned anything about technical debt and how
| it bites back hard?
|
| I think LLMs are changing the nature of technical debt in
| weird ways, with trends that are hard to predict.
|
| I've found LLMs surprisingly useful in 'research mode',
| taking an old and badly-documented codebase and answering
| questions like "where does this variable come from, and
| what are its ultimate consumers?" Its answers won't be as
| natural as a true expert's, but its answers are nonetheless
| useful. Poor documentation is a classic example of
| technical debt, and LLMs make it easier to manage.
|
| They're also useful at making quick-and-dirty code more
| robust. I'm as guilty as anyone else of writing personal-
| use bash scripts that make all kinds of unjustified
| assumptions and accrete features haphazardly, but even in
| "chat mode" LLMs are capable of reasonable rewrites for
| these small problems.
|
| More systematically, we also see now-routine examples of
| LLMs being useful at code de-obfuscation and even
| decompilation. These forward processes maximize technical
| debt compared to the original systems, yet LLMs can still
| extract meaning.
|
| Of course, we're not now _immune_ to technical debt. Vibe
| coding will have its own hard-to-manage technical debt, but
| I 'm not quite sure that we have the countours well
| defined. Anecdotally, LLMs seem to have their biggest
| problem in the design space, missing the forest of
| architecture for the trees of implementation such that they
| don't make the conceptual cuts between units in the best
| place. I would not be so confident as to call this problem
| inherent or structural rather than transitory.
| skydhash wrote:
| > taking an old and badly-documented codebase and
| answering questions like "where does this variable come
| from, and what are its ultimate consumers?"
|
| Why do you even need an LLM for this? Code is formal
| notation, it's not magic. Unless the code is obfuscated,
| even bad code is pretty clean on what they're doing and
| how various symbols are created and used. What is not
| clear is "why" and the answer is often a business or a
| technical decision.
| simonw wrote:
| > Why do you even need an LLM for this?
|
| Once you get above a few hundred thousand lines of legacy
| undocumented code having a good LLM to help dig through
| it is really useful.
| jimbokun wrote:
| None of what you describe is free.
|
| After the LLM helps untangle the mess, if you leave the
| mess in place, you will have to ask the LLM untangle it
| for you every time you need to make a change.
|
| Better to work with the LLM to untangle the technical
| debt then and there and commit the changes, so neither
| you nor the LLM have to work so hard in the future.
|
| I've even seen anecdotal evidence that code that's easier
| for humans to work with is easier for LLMs to work with
| as well.
| neilwilson wrote:
| Once writing code is cheap you don't maintain code. You
| regenerate it from scratch.
|
| What you maintain is the specification harness, and change
| that to change the code.
|
| We have to start thinking at a higher level, and see code
| generation in the same way we currently see compilation.
| simonw wrote:
| I'm not sold on that idea yet.
|
| I don't just have LLMs spit out code. I have them spit out
| code and then I try that code out myself - sometimes via
| reviewing it and automated tests, sometimes just by using
| it and confirming it does the right thing.
|
| That upgrades the code to a status of _generated and
| verified_. That 's a lot more valuable than code that's
| just generated but hasn't been verified.
|
| If I throw it all away every time I want to make a change
| I'm also discarding that valuable verification work. I'd
| rather keep code that I know works!
| manuelabeledo wrote:
| Unless the specification is also free of bugs and side
| effects, there is no guarantee that a rewrite would have
| fewer bugs.
|
| Plenty of rewrites out there prove that point.
| jimbokun wrote:
| Seems relevant again:
|
| https://www.joelonsoftware.com/2000/04/06/things-you-
| should-...
| jimbokun wrote:
| Tokens aren't free.
|
| Far more expensive than compilation and non deterministic
| so you're not sure if you will get the same software if you
| give the AI the same spec.
| AyanamiKaine wrote:
| I really like the idea of Ousterhout's tactical vs strategic
| programming. Where we either create a new feature as fast as
| possible vs focusing on architecture and keeping complexity in
| check.
|
| I truly believe that LLMs are replacing tactical programming.
| Focusing on implementing features as fast as possible with not
| much regards to the overall complexity of a system.
|
| Its more important then ever to focus on keeping complexity low
| at a system level.
| pmontra wrote:
| The problem is to know what to write. I spent a whole day
| yesterday to understand what the problem was with a PDF file we
| were failing to process. Once I understood the cause it took
| one line of code to fix it and another dozen of lines for a
| unit test. A LLM helped me to write the code to explore several
| possible candidate problems but it did not find the problem by
| itself.
|
| So code is both cheaper (what the LLM wrote for me much faster
| than I could have typed it) and is also expensive (the only
| line that we deployed to production today.)
| zahlman wrote:
| Yeah, I have to agree. Worth noting that deterministic "code-
| generation" systems have existed for quite some time. It's just
| that once you saw something like that being useful for your
| system, that gave pause to critique the existing system design.
|
| Boilerplate is boilerplate, whether filling it in is purely
| mechanical or benefits from an LLM's fuzzy logic.
| manishsharan wrote:
| maybe writing code is cheap . But writing unit tests that
| actually test stuff that matters is suddenly so much more
| important and expensive.
| simonw wrote:
| Yeah it's more important, but I think that has become a whole
| lot cheaper too.
| andrewstuart wrote:
| Understanding computers and programming is not the same as
| coding.
| wolfcola wrote:
| i've yet to see an agent that can take a figma design and produce
| high fidelity UI
| simonw wrote:
| Have you tried Gemini 3.1 Pro for that yet? They put a ton of
| work into improving its frontend abilities.
| slopinthebag wrote:
| LLM's have made code cheap in the same way McDonalds has made
| eating out at a restaurant cheap.
| analog31 wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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.
| LtWorf wrote:
| In what world is an LLM generating text faster than you
| can type?
|
| They are certainly slower than me at text generation.
| simonw wrote:
| Wow you must be fast at typing!
|
| Can you beat this one? https://chatjimmy.ai/
|
| (It is to be fair running a pretty trash model, a
| quantized Llama 3.1 8B from ~18 months ago)
| gbalduzzi wrote:
| The human in that case is not "so slow", but at the current
| state it is slower than an LLM as simple as that.
|
| The difference comes in confidence that the solution works
| and can be maintained in the future, but in terms of purely
| making the decisions and applying the changes an LLM is
| faster when it has all the required infos available
| alexhans wrote:
| It doesn't disappear but it does easy up some instances of
| fighting configuration, documentation, syntax or even comparing
| three approaches that are similar but you don't know their full
| effect.
|
| I think it's a very fun space, finally being able to empower
| many people who in the past wouidve been bottlenecked unless
| they were using very simple tools for their domain and
| upskilled enough. Those 2 things will still be true, but the
| speed at which some things can happen at the exploration and
| other layers has seen a significant speedup.
|
| Other problems like entropy/slop, security, system testing,
| lack of automation fundamentals arise but it's a good problem
| to start tackling.
|
| I'm very focused on evals [1] because is what allows me to not
| to be the bottleneck with economists who I want to empower to
| code end to end and I'd like that mental shift to happen for
| anyone becoming a builder so non traditional developers and
| developers by trade have a common language for product building
| [2]. That part of speaking to different audiences and combating
| hype that promises to do everything for you Vs the intent
| that's actually needed is hard, but trying gets you to advance
| quite a lot.
|
| [1] https://alexhans.github.io/posts/series/evals/measure-
| first-...
|
| [2] https://ai-evals.io
| saezbaldo wrote:
| Agree, and I'd add: the feedback loop between decision and
| consequence got dramatically shorter. You can test an
| architectural hypothesis in hours instead of weeks. That part
| is genuinely powerful.
|
| But faster feedback also means bad decisions propagate faster.
| The skill isn't generating three implementations in parallel --
| it's knowing which one won't page you at 3am. That judgment
| comes from having been paged at 3am enough times to recognize
| the patterns.
| simonw wrote:
| > The skill isn't generating three implementations in
| parallel -- it's knowing which one won't page you at 3am.
|
| 100% this.
| cryptonector wrote:
| > 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 wrote:
| > 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 wrote:
| > If anything, I think AI will increase human understanding
|
| How?
| Quothling wrote:
| 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 wrote:
| 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..
| Quothling wrote:
| Splitting your code up into multiple functions across
| multiple files is computer unfriendly code. It'll cause L1,
| L2 and L3 cache misses. Yet it's heailed as very human
| friendly and maintainable by Uncle Bob and his disciples.
| As far as code reviews go, do you have any form of evidence
| that it's not a pseudo science? If I look at our industry
| today, it's not like it's in better shape compared to where
| it was decades ago. Hell, some of our most important
| systems are still running COBOL. If all these methodologies
| and principles that people swear by actually worked, I'd
| argue that things would have improved over the previous 40
| years.
| AlexCoventry wrote:
| OpenAI is implying that code may no longer be human readable in
| some circumstances.
|
| > The resulting code does not always match human stylistic
| preferences, and that's okay. As long as the output is correct,
| maintainable, and legible *to future agent runs*, it meets the
| bar.
|
| https://openai.com/index/harness-engineering/
| farhanhubble wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| > 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.
| pjerem wrote:
| You don't get me. I don't say that those are good
| comments, I even say that you should probably delete them
| afterwards.
|
| But as you say, they are realization of the context of
| the LLM. Their role is not helping you to understand what
| the code is doing, but how the LLM understood the problem
| and how it tried to solve it. Now you can compare its own
| understanding with yours.
|
| Now I need to add context myself : I'm not talking about
| vibe coding entire apps, here adding verbosity wouldnt
| help a lot. My main usage of LLMs is at $JOB where I need
| to execute "short" tasks into codebases I barely know
| most of the times, that's where I use this trick. It also
| have the side benefit to help me understand the codebase
| better.
| democracy wrote:
| AI agents is like outsourcing to a bad team offshore - yeah they
| can build and maybe cheap but requires lots of hand holding.
| DaedalusII wrote:
| its going to replace outsourcing to offshore teams pretty
| robustly though I suspect
| d--b wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| 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.
| kakacik wrote:
| There are limits how badly can such senior screw up, or more
| likely forget some corner case situation. And he/she is on
| top of their own code and whole codebase and getting better
| each time, changing only whats needed, reverting unnecessary
| changes, seeing bigger picture. That's (also) seniority.
|
| Llm brings an illusion of that, a statistical model that may
| or may not hit what you need. Repeat the question twice and
| senior will be better at task the second time. LLM will
| produce simply different output, maybe.
|
| Do you feel like you have a full control over whats happening
| here? Business has absolutely insatiable lust for control,
| and IT systems are an area of each business that C-suite
| always feel they have least control of.
|
| Reproducibility and general trust is not something marginal
| but core of good deliveries. Just read this thread - llms
| have 0 of that.
| ozim wrote:
| Irrelevant because you are not going to make new changes by
| hand. You will use AI for that.
| jannelammi wrote:
| All the hype is on how fast it is to produce code. But the
| actual bottleneck has always been the cost of specifying intent
| clearly enough that the result is changeable, testable, and
| correct AND that you build something that brings value.
| g_b wrote:
| > Do current LLM based agents generate code which is easy to
| change?
|
| They do. I am no longer writing code, everything I commit is
| 100% generated using an agent.
|
| And it produces code depending on the code already in my code-
| base and based on my instructions, which tell it about clean-
| code, good-practices.
|
| If you don't get maintainable code from an LLM it's for this
| reason: Garbage in, garbage out.
| vips7L wrote:
| Doesn't this preclude that you already know how to produce
| good code? How will anyone in the future do this when they
| haven't actually programmed?
| alexhans wrote:
| We won't be able to be sure of 100% with LLMs but maybe proper
| engineering around evals get us to an acceptable level of
| quality based on the blast radius/safety profile.
|
| I'd also argue that we should be pushing towards tracer bullets
| as a development concept and less so prototypes that are nice
| but meant to be thrown away and people might not do that.
|
| The clean room auto porting, after a messy exploratory
| prototyping session would be a nice pattern, nonetheless.
| chr15m wrote:
| I am constantly getting LLMs to change features and fix bugs.
| The key is to micromanage the LLM and its context, and read the
| changes. It's slower that vibe coding but faster than coding by
| hand, and it results in working, maintainable software.
| foepys wrote:
| A study last year concluded that while AI coding feels faster
| it actually isn't. At least in mid 2025.
|
| https://news.ycombinator.com/item?id=44522772
| fragmede wrote:
| 6 months ago in AI development is too old to be relevant.
| KronisLV wrote:
| The comments explain the nuance there pretty well:
|
| > This study had 16 participants, with a mix of previous
| exposure to AI tools - 56% of them had never used Cursor
| before, and the study was mainly about Cursor.
|
| > My intuition here is that this study mainly demonstrated
| that the learning curve on AI-assisted development is high
| enough that asking developers to bake it into their
| existing workflows reduces their performance while they
| climb that learing curve.
|
| Giving people a tool, that have no experience with it, and
| expecting them to be productive feels... odd?
| chr15m wrote:
| That's a good point. Myself is the easiest person to fool.
|
| I knocked together a quick analysis of my commit graphs
| going back several years, if you're interested:
| https://mccormick.cx/gh/
|
| My average leading up to 2023 was around 2k commits per
| year. 2023 I started using ChatGPT and I hit my highest
| commits so far that year at 2,600. 2024 I moved to a
| different country, which broke my productivity. I started
| using aider at the end of 2024 and in 2025 I again hit my
| highest commits ever at 2,900. This year is looking pretty
| solid.
|
| From this it looks to me like I'm at least 1.4x more
| productive than before.
|
| As a freelancer I have to track issues closed and hours
| pretty closely so I can give estimates and updates to
| clients. My baseline was always "two issues closed per
| working day". These are issues I create myself (full stack,
| self-managed freelancer) so the average granularity has
| stayed roughly constant.
|
| This morning I closed 8 issues on a client project. I
| estimate I am averaging around 4 issues per working day
| these days. I know this because I have to actually close
| the issues each day. So on that metric my productivity has
| roughly doubled.
|
| I believe those studies for sure. I think there is nuance
| to using these tools well, and I think a lot of people are
| going backwards and introducing more bugs than progress
| through vibe coding. I do not think I have gone backwards,
| and the metrics I have available seem to agree with that
| assessment.
| rahoulb wrote:
| I'd add in "code is easier to write than it is to read" - hence
| abstraction layers designed to present us with higher level
| code, hiding the complex implementations.
|
| But LLMs are both really good at writing code _and_ reading
| code. However, they're not great at knowing when to stop -
| either finishing early and leaving stuff broken, over-
| engineering and adding in stuff that's not needed or deciding
| it's too hard and just removing stuff it deems unimportant.
|
| I've found a TDD approach (with not just unit tests but high-
| level end-to-end behaviour-driven tests) works really well with
| them. I give them a high-level feature specification (remember
| Gherkin specifications?) and tell it to make that pass (with
| unit tests for any intermediate code it writes), make sure it
| hasn't broken anything (by running the other high-level tests)
| then, finally, refactor. I've also just started telling it to
| generate screenshots for each step in the feature, so I can
| quickly evaluate the UI flow (inspired by Simon Willison's
| Rodney tool).
|
| Now I don't actually need to care if the code is easy to read
| or easy to change - because the LLM handles the details. I just
| need to make sure that when it says "I have implemented Feature
| X" that the steps it has written for that feature actually do
| what is expected and the UI fits the user's needs.
| simonw wrote:
| > Do current LLM based agents generate code which is easy to
| change?
|
| Yes, if that's your goal and you take steps to achieve that
| goal while working with agents.
|
| That means figuring out how to prompt them, providing them good
| examples (they'll work better in a codebase which is already
| designed to afford future changes since they imitate existing
| patterns) and keeping an eye on what they're doing so you can
| tell them "rewrite that like X" when they produce something
| bad.
|
| > Once you can ask your agent to change a feature and be 100%
| sure they won't break other features
|
| That's why I tell them to use red/green TDD:
| https://simonwillison.net/guides/agentic-engineering-pattern...
| softwaredoug wrote:
| This is the brake on "AI will replace all developers".
|
| Coding is a correctness-discovery-process. For a real product
| you need to build to know the right thing. As the product
| matures those constraints increase in granularity to tighter
| bits of code (security, performance, etc)
|
| You can have AI write 100% of the code but more mature products
| might be caring about more and more specific low level
| requirements.
|
| The time you can let an agent swarm just go are cases very well
| specificed by years of work (like the Anthropic C compiler)
| MagicMoonlight wrote:
| No. They're great at slopping out a demo, but god help you if
| you want minor changes to it. They completely fall apart.
| alexhans wrote:
| 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
|
| [2] concept from the Pragmatic Programmer,
| https://www.aihero.dev/tracer-bullets
|
| [3] https://alexhans.github.io/posts/series/evals/measure-
| first-...
|
| [4] https://alexhans.github.io/posts/series/evals/building-
| agent...
| KnuthIsGod wrote:
| Time for schools to stop pushing coding skills onto the poor
| kids.
| trwhite wrote:
| When did we ever measure the value of code by quantity, not
| quality? The author is misguided.
| simonw wrote:
| Did you read my list of characteristics of "good code" further
| down the article?
|
| That's all about quality, not quantity.
| voidUpdate wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Are you familiar with the cathedral vs the bazaar?
| dirkc wrote:
| 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 wrote:
| Curious if your mental model is similar or how you see them
| being different.
| BlueHotDog2 wrote:
| its funny how we're back again measuring lines of code as the
| sole indicator for cost/quality etc
| simonw wrote:
| 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 wrote:
| 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.
| BoppreH wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| I do the same, plus add tests from early on. New features
| then naturally are accompanied by more tests.
| animal531 wrote:
| 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.
| xyzAbc_ wrote:
| Sounds like every other software project to me ...
| samusiam wrote:
| Did you tell it to consider future usage? Have you tried using
| it to find and remove dead code? In my experience you can get
| very good code if you just do a few passes of AI adversarial
| reviews and revisions.
| mattclarkdotnet wrote:
| So... XP was the right way all along?
| smallnix wrote:
| > 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 wrote:
| 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.
| vivzkestrel wrote:
| - 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 wrote:
| _> 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 wrote:
| 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 ...
| imtringued wrote:
| 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 wrote:
| > 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?...
| kaffekaka wrote:
| 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 wrote:
| Adding cast iron on airplane is cheap now.
| Havoc wrote:
| 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 wrote:
| 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 wrote:
| Can't say I've notice much of a difference switching from CC
| to opencode?
| i_love_retros wrote:
| Sponsored by: Teleport -- Secure, Govern, and Operate AI at
| Engineering Scale
|
| Gee what a surprise.
| co_king_5 wrote:
| I asked Simon W point blank if he was funded by AI companies
| about a week ago and he said no, so I am actually surprised by
| this.
| lnkl wrote:
| No way that he would lie about this, right?
| simonw wrote:
| 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 wrote:
| He posted about it here:
| https://simonwillison.net/2026/Feb/19/sponsorship/
| simonw wrote:
| 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/
| kaizenb wrote:
| * 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
| bsenftner wrote:
| 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 wrote:
| Did you read the whole thing or just the headline?
|
| What did you think of my list of characteristics of "good
| code"?
| htrp wrote:
| What are you thinking about for the new best practices for
| software engineering?
| simonw wrote:
| 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-
| pa...
|
| I'm not sure anyone has a confident answer to that yet
| though - I certainly don't.
| bsenftner wrote:
| 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.
| bsenftner wrote:
| I re-read to make sure I was not reacting off the cuff. Your
| list of good code practices is obvious what we want, but that
| is not going to happen with the way you describe working with
| AIs.
|
| You don't seem to be aware of cognitive load; when you say:
|
| "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."
|
| That is going to fracture a person's understanding, leading
| to mentally fatigue them. People, and I see this coming from
| you too Simon, seem to be treating software development like
| it's a sprint, when it is absolutely a marathon. One that
| requires consideration before acting, and now with LLMs the
| common act of figuring it out along the way is now dangerous
| because they will happily guide one to create a CMS when all
| they want is a one off function.
| simonw wrote:
| I've written quite a bit about cognitive debt and load
| recently https://simonwillison.net/tags/cognitive-debt/.
| It's a very real issue - working with these tools is
| _exhausting_ if you don 't figure out how to pace it, and
| I've not figured out how to pace it yet.
|
| I'm currently expecting this will be a temporary thing,
| brought on by the significant new abilities of the November
| model releases.
| AyanamiKaine wrote:
| > 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 wrote:
| > 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 wrote:
| > 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 wrote:
| Startups, famous for writing clean, quality code.
| solumunus wrote:
| Not sure what relevancy that has to what you're responding
| to.
| softwaredoug wrote:
| More like developers - infamous for not writing the shit
| code needed to test PMF :)
| zeroonetwothree wrote:
| I made a SO clone in 1 week at a previous job (ok not 100%
| feature complete obviously but good enough to start using).
| This is by myself with no AI of course (10 years ago).
|
| With Claude Code today I could do it maybe 2x faster? Maybe
| not that much even though, a lot of time is spent not on
| purely mechanically typing out characters so it's not a huge
| savings necessarily.
| gchamonlive wrote:
| I think code was always expensive. If it seemed cheap, the cost
| was hidden somewhere else.
|
| When I started coding professionally, I joined a team of only
| interns in a startup, hacking together a SaaS platform that had
| relative financial success. While we were very cheap, being
| paid below minimum wage, we had outages, data corruption, db
| wipes, server terminations, unresolved conflicts making their
| way to production and killing features, tons of tech debt and
| even more makeshift code we weren't aware of...
|
| So yeah, while _writing_ code was cheap, the result had a
| latent cost that would only show itself on occasion.
|
| So code was always expensive, the challenge was to be aware of
| how expensive sooner rather than later.
|
| The thing with coding agents is that it seems now that you can
| eat your cake and have it too. We are all still adapting, but
| results indicate that given the right prompts and processes
| harnessing LLMs quality code can be had in the cheap.
| ryanackley wrote:
| > The thing with coding agents is that it seems now that you
| can eat your cake and have it too. We are all still adapting,
| but results indicate that given the right prompts and
| processes harnessing LLMs quality code can be had in the
| cheap.
|
| It's cheaper but not cheap
|
| If you're building a variation of a CRUD web app, or
| aggregating data from some data source(s) into a chart or
| table, you're right. It's like magic. I never thought this
| type of work was particularly hard or expensive though.
|
| I'm using frontier models and I've found if you're working on
| something that hasn't been done by 100,000 developers before
| you and published to stackoverflow and/or open source, the
| LLM becomes a helpful tool but requires a ton of guidance.
| Even the tests LLMs will write seem biased to pass rather
| than stress its code and find bugs.
| gchamonlive wrote:
| > It's cheaper but not cheap
|
| It's quite cheap if you consider developer time. But it's
| only as cheap as you can effectively drive the model,
| otherwise you are just wasting tokens on garbage code.
|
| > LLM becomes a helpful tool but requires a ton of guidance
|
| I think this is always going to be the case. You are
| driving the agent like you drive a bike, it'll get you
| there but you need to be mindful of the clueless kid
| crossing your path.
|
| For some projects I had good results just letting the agent
| loose. For others I'd have to make the tasks more specific
| and granular before offloading to the LLM. I see nothing
| wrong with it.
| zahlman wrote:
| > I never thought this type of work was particularly hard
| or expensive though.
|
| Maybe not _intrinsically_ hard, but hard because it 's so
| boring you can't concentrate.
|
| > the LLM becomes a helpful tool but requires a ton of
| guidance. Even the tests LLMs will write seem biased to
| pass rather than stress its code and find bugs.
|
| ISTR some have had success by taking responsibility for the
| tests and only having the LLM work on the main code. But
| since I only seem to recall it, that was probably a while
| ago, so who knows if it's still valid.
| lp4v4n wrote:
| So code was apparently cheap, but in fact it was expensive
| because it was low quality.
|
| Now with LLMs, code is cheap and it also has quality,
| therefore "quality code can be had in the cheap".
|
| Do you really believe this is the case? Why don't companies
| fire all their developers if they can have an algorithm that
| can output cheap and quality code?
| fragmede wrote:
| I don't know if you've heard, but there _have_ been a large
| number of layoffs in the tech sector recently. Whether they
| 're actually related to AI as executives claim, and not
| section 174 of the US IRS tax code in the BBB, is known
| only to them, but if your argument hinges on people having
| not been fired when there have been layoffs, you may need a
| different one.
| lp4v4n wrote:
| As you said, it's impossible to determine how many of the
| current layoffs are caused by AI, they probably also have
| a lot to do with the broader economic downturn. But
| you're still missing the point, if companies truly have a
| black box that can produce cheap, high-quality code as
| the GP put it, why don't they just fire 95% of their
| developers and keep only a small core of AI
| orchestrators?
| AyanamiKaine wrote:
| I think a major contributor to the layoffs is companies
| hiring to much people around covid[1]. I cant find good
| stats for the years 2019-2026 besides looking at now and
| the past directly. There are some data for the ukranin
| side djinni[1][2] and for US IT job postings[3].
|
| I dont think AI is the reason for the layoffs. Its just
| easier to say "because of AI we are firing" than to say
| "because we overhired and its actually our fault".
|
| [1]https://djinni.substack.com/p/2021-in-review
| [2]https://blog.djinni.co/post/q1-analytics-en
| [3]https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE
| nthj wrote:
| We didn't fire all our developers when we invented
| compilers either, and for much the same reason we didn't
| stop hiring laborers when we first built ships and
| established overseas trade routes: business will always
| expand to meet its reach
|
| Many enterprises are currently exploring to see if they can
| invite developers to leverage AI tools--like they leveraged
| the compiler--to be more productive. To operate on a higher
| plane of agency, collaborating on what we should be
| building and not just technical execution. Those actively
| hostile or just checked out with the idea of relearning
| skills are being laid off. (Some unprofitable business
| sections are being swept up opportunistically too.) The
| idea that all developers would be fired if AI tools can
| write good code doesn't meet the lessons of history
| skydhash wrote:
| > Many enterprises are currently exploring to see if they
| can invite developers to leverage AI tools--like they
| leveraged the compiler--to be more productive. To operate
| on a higher plane of agency, collaborating on what we
| should be building and not just technical execution.
|
| The thing is, developers have been hired to automate
| process, and as for any professional doing a good job,
| that means the output should perform reliably. But now
| they are forcing us to use a tools that everyone knows is
| not reliable, but the onus is still on us to keep the
| same reliability. So do you see why we are not thrilled?
|
| It's like providing a faulty piano (that shuffles the
| notes when a key is pressed) and expecting a good
| rendition of the Moonlight Sonata.
|
| Or a crane that will stall and drop its load randomly. It
| would have been sent to the scrapyard on the first day.
| jodrellblank wrote:
| > "Or a crane that will stall and drop its load randomly.
| It would have been sent to the scrapyard on the first
| day."
|
| The only reason you have the concept that engines can
| "stall" is because people have bought engines that can
| stall by the hundreds of millions, instead of the
| earliest people refusing to buy them at all and all
| waiting for the perfect engine.
|
| Container ships can sink with all the containers lost at
| sea. Still used.
|
| Steam train engines could explode, derailing the train
| and killing some passengers and employees. Still used.
|
| Buildings can collapse. Still used.
|
| Pneumatic tyres can burst. Still used.
|
| Here[1] is Tom Scott using a recreation walking crane
| from the 13th century, a technology going back to Roman
| times, which has no evidence that it ever had brakes on
| it historically. Look at that and tell me you think the
| rope never snappped, the wood never broke, the walker
| never tripped and the thing never unreeled the load back
| to the ground with the walker severely injured, because
| if it went wrong builders would refuse to use it? No
| chance.
|
| Nothing functions like you're claiming; that's where we
| get the saying "don't let perfect be the enemy of good
| enough", as soon as stuff is better than not having it,
| people want to make use of it.
|
| [1] https://www.youtube.com/watch?v=pk9v3m7Slv8
| skydhash wrote:
| You forgot to address the random aspect of the failure
| cases.
|
| Real world is chaotic, technology was always first about
| controlling, then improving said control. A lot of the
| risks in the situations you described have been brought
| down that the savings (time, money,...) are magnitude
| more than the cost of the failure.
|
| I'm not asking for perfection, but something good enough
| that we can demonstrate the savings outweigh the costs.
| So far there's none. In fact, we are increasing it. And
| fast.
| AyanamiKaine wrote:
| This what I really wonder, what is even the cost of code?
| Or what is real code quality.
|
| I know that things like "clean code" exists but I always
| felt that actual code quality only shows when you try
| adding or changing existing code. Not by looking at it.
|
| And the ability to judge code quality on a system scale is
| something I don't think LLMs can do. But they may support
| developers in their judgment.
| simonw wrote:
| > Why don't companies fire all their developers if they can
| have an algorithm that can output cheap and quality code?
|
| Because it takes an experienced developer to get the
| machine to output cheap and quality code well enough to be
| useful.
|
| That developer is just a whole lot more valuable now,
| because they can do more work at a higher quality.
| gchamonlive wrote:
| Because cheap and quality code is only part of the story.
| The code needs to solve the _right problem_ and that is a
| domain only a human can operate, at least for now. Back
| then when I was inexperienced I couldn 't write good code,
| but I could sit with the company's CTO while he explained
| the domain, the challenges and the goal of the project. I
| could talk with domain experts and understand what the
| common solutions to the problems were. These are things
| that for an LLM to do would require untold amounts of
| context or a specialized model that understands the domain.
|
| But the thing is, there are many unknowns. We humans are
| very capable of adapting as we go. LLMs have a fixed data
| they were trained on and prompt engineering can only get
| you so far.
|
| I think anyone asking this with the intention of actually
| replacing humans with LLMs don't really understand neither
| humans nor LLMs. They are just talking money.
| agentultra wrote:
| 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 wrote:
| Writing code is expensive. Maintaining code is expensive.
| Whatever way, it ain't cheap.
| saezbaldo wrote:
| 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 wrote:
| you'd think this guy would get tired of writing about AI all day
| simonw wrote:
| I also write about museums https://www.niche-museums.com and
| parrots https://simonwillison.net/2026/Feb/17/first-kakapo-
| chick-in-...
| vips7L wrote:
| Grifters gonna grift.
| Rover222 wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| > 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)
| ericol wrote:
| He definitely was paying attention.
|
| He had to pause for a second there, arrested by the
| realization, and was one of the reasons I got an "Exceeds
| expectations" in one of my KRAs.
| thefaux wrote:
| It is interesting though that he evidently didn't notice
| this 2.5X productivity increase until you pointed it out
| to him.
| kldg wrote:
| This has been my experience, too. In dealing with hardware,
| I'm particularly pleased with how vision models are shaping
| up; it's able to identify what I've photographed, put it in a
| simple text list, and link me to appropriate datasheets.
| yday, it even figured out how I wanted to reverse engineer a
| remote display board for a just-released inverter and
| correctly identified which pin of which unfamiliar Chinese
| chip was spitting out the serial data I was interested in;
| all I actually asked for was chip IDs with a quick vague note
| on what I was doing. It doesn't help me solder faster, but it
| gets me to soldering faster.
|
| A bit OT, but I would love to see some different methods of
| calculating economic productivity. After looking into how BLS
| calculates software productivity, I quit giving weight to the
| number altogether and it left me feeling a bit blue; they
| apply a deflator in part by considering the value of features
| (which they claim to be able to estimate by comparing feature
| sets and prices in a select basket of items of a category,
| applying coefficients based on differences); it'll likely
| never actually capture what's going on in AI unless Adobe
| decides to add a hundred new buttons "because it's so quick
| and easy to do." Their methodology requires ignoring FOSS
| (except for certain corporate own-account cases), too; if
| everyone switched from Microsoft365 to LibreOffice, US
| productivity as measured by BLS would crash.
|
| BLS lays methodology out in a FAQ page on "Hedonic Quality
| Adjustment"[1], which covers hardware instead of software,
| but software becomes more reliant on these "what does the
| consumer pay" guesses at value (what is the value of S-Video
| input on your TV? significantly more than supporting picture-
| in-picture, at least in 2020).
|
| [1] https://www.bls.gov/cpi/quality-adjustment/questions-and-
| ans...
| gofreddygo wrote:
| code was expensive, is and will be expensive. the real cost is
| hidden. takes a mature eye to see a codebase that works and is
| not a dumpster fire.
|
| correctness (doing what its supposed to, nothing else),
| maintainability (accommodating unknown future changes), cost (
| deployment, refactoring, integrations) and performance (making
| the right tradeoffs) are not obvious, don't come naturally till
| you burn your fingers and differentiate a good from a horrible
| end result.
| duxup wrote:
| Honestly, if I would just get what the end user "really wants"
| (they often don't even know) that would save a huge percentage
| of the overall cost, and that's not code that's human nature.
| ako wrote:
| That is also getting cheaper, you can now quickly present him
| with a few working prototypes so he can quickly make up his
| mind what best suites him.
|
| Another problem is that most users want different things,
| that's why you get these big bloated software suites. With
| LLMs it now also becomes more achievable to build custom
| software per user.
| duxup wrote:
| I find it is more a rubber hits the road thing where they
| have to use it to really understand.
| simonw wrote:
| "What was expensive was everything around it" - when I say that
| code has always been expensive that's part of what I'm
| factoring in.
|
| But even typing that first few hundred lines used to have a
| much more significant cost attached.
|
| I just pasted 256 lines of JavaScript into the 2000s-era
| SLOCount tool (classic Perl, I have a WebAssembly hosted
| version here https://tools.simonwillison.net/sloccount) and it
| gave me a 2000s-era cost estimate of $6,461.
|
| I wouldn't take that number with anything less than a _giant_
| fist of salt, but there you have it.
| trgn wrote:
| people became millionaires writing html 30 years ago. there's
| been these shifts in the past.
| gitlinuxgreat wrote:
| People became billionaires from domain names in the dot com
| era.
| trgn wrote:
| haha! do you know details, what domains?
| simonw wrote:
| Mark Cuban sold broadcast.com to Yahoo for $5.7bn
|
| It was a bit more than a domain name - they had 330
| employees and $13.5 million in revenue for a quarter -
| but that acquisition was definitely peak dot-com boom.
| trgn wrote:
| thanks!
|
| i would love another bubble. i feel like tech has been in
| a corner for going on ten years now (covid spike was so
| brief). it's so concentrated in ai it sucks up
| everything.
| zahlman wrote:
| > when I say that code has always been expensive that's part
| of what I'm factoring in.
|
| Fair, but when an LLM writes code in response to a prompt I
| really don't get the sense that it's doing as much of that
| "everything around" part as you might expect.
| simonw wrote:
| Yeah it absolute isn't, but the time it's saving you means
| you can spend more effort on all of that stuff.
| hluska wrote:
| I don't understand why you would agree with the entire article
| yet frame it as disagreement.
| juanre wrote:
| 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 wrote:
| Who's going to maintain all the cheap code and review it? Is the
| "software janitor" job title becoming reality now?
| trumbitta2 wrote:
| Writing code is 20-100 USD per month now
| exabrial wrote:
| 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 wrote:
| > "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 wrote:
| > 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.
| hansmayer wrote:
| > That's exactly what they do for me - especially since the
| November model releases (GPT-5.1, Opus 4.5).
|
| I mean it's inherently impossible, given the statistical
| nature of LLMs, so I am not sure are you claiming this out of
| ignorance or other interests, but again, what you claim is
| impossible due to the very nature of LLMs.
| lunar_mycroft wrote:
| It's impossible for human developers too. Natural language
| descriptions of a program are either much more painful and
| time consuming to write than the code they describe, or
| contain some degree of ambiguity which the thing
| translating the description into code has to resolve (and
| the probability of the resolution the entity writing the
| description would have chosen and the one entity
| translating it into code chose matching perfectly approach
| zero).
|
| It can make sense to trade off some amount of control for
| productivity, but the tradeoff is inherent as soon as a
| project moves beyond a single developer hand writing all of
| the code.
| hansmayer wrote:
| I agree - the whole BS of "Hottest new programming
| language is English" is complete nonsense. There is
| something about writing the code directly from your mind
| that skips over the "language circuits" and makes it much
| more precise. Perhaps as humans with education we obtain
| an ability to think in programming language itself I
| suppose? It's probably similar to what happens in the
| mind of a composer or painter. This is why the natural
| language will never be the interface the big "AI"
| companies are making it to be.
| simonw wrote:
| It's impossible, and yet I experience it on a daily basis.
|
| YMMV. I've had a _lot_ of practice at prompting.
| hansmayer wrote:
| > YMMV. I've had a lot of practice at prompting.
|
| Ah, the old "you suck at prompting" angle again, isn't
| it? If you're going to shill this hard, at least come up
| with something new and original, this is sounding more
| than desperate.
| simonw wrote:
| Most people suck at playing the piano. Most people suck
| at prompting coding agents. If you practice either of
| those things you'll get better at them.
|
| I really don't understand the "stop telling me I'm
| holding it wrong" argument. You probably are holding it
| wrong!
|
| Is this born out of some weird belief that "AI" is meant
| to be science fiction technology that you don't ever need
| to learn how to use?
|
| That would help explain why conversations like this are
| full of people who claim to get great results and other
| people who say every time they've tried it the results
| have been terrible.
| hansmayer wrote:
| > Most people suck at playing the piano. Most people suck
| at prompting coding agents. If you practice either of
| those things you'll get better at them.
|
| It would be funny, if by now I weren't convinced you are
| pushing these false analogies on purpose. The key
| difference between a piano and LLMs being, the piano will
| produce the same sounds to a same sequence of keys. Every
| single time. A piano is deterministic. The LLMs are not,
| and you know it, which makes your constant comparison of
| deterministic with non-deterministic tools sound a bit
| dishonest. So please stop using these very weak
| analogies.
|
| > I really don't understand the "stop telling me I'm
| holding it wrong" argument. You probably are holding it
| wrong!
|
| Right, another weak argument. Writing English language
| paragraphs is not a science you seem to imply it is.
| You're not the only person using the LLMs intensively for
| the last years, and it's not like there this huge secret
| to using them - after all they use natural language as
| their primary interface. But that's besides the point.
| We're not discussing if they are hard or easy to use or
| whatever. We are discussing if I should replace the
| magnificent supercomputer already placed in my head by
| mother nature or God or Aliens or whatever you believe
| in, for a very shitty, downgraded version 0.0.1 of it
| sitting in someone's datacenter, all for the sake of
| sometimes cutting some corners by getting that quick
| awk/sed oneliner or some boilerplate code? I don't think
| that's a worthy tradeoff, especially when the relevant
| reports indicate an objective slowdown, which probably
| also explains the so-called LLM-fatigue.
|
| > Is this born out of some weird belief that "AI" is
| meant to be science fiction technology that you don't
| ever need to learn how to use?
|
| No, actually it is born out of the weird belief which
| _your_ sponsors have been either explicitly or implicitly
| promoting, now for the 4th year, in various intensities
| and frequencies, that the LLM technology will be equal to
| a "country of PhDs in a datacenter". All of this based
| on the super weird transhumanist ideology a lot of the
| people directly or indirectly sponsoring your writing
| actively believe in. And whether you like it or not, even
| if you have never implied the same, you have been a
| useful helper by providing a more "rational" sounding
| voice, commenting on the supposed incremental
| improvements and progress and what not.
| simonw wrote:
| Fine, if you don't like the piano analogy:
|
| Most people suck at falconry. If you practice at falconry
| you'll get better at it.
|
| Falcons certainly aren't deterministic.
|
| > it's not like there this huge secret to using them -
| after all they use natural language as their primary
| interface
|
| That's what makes them hard to use! A programming
| language has like ~30 keywords and does what you tell it
| to do. An LLM accepts input in 100+ human languages and,
| as you've already pointed out many times, responds in
| non-deterministic ways. That makes figuring out how to
| use them effectively really difficult.
|
| > We are discussing if I should replace the magnificent
| supercomputer already placed in my head by mother nature
| or God or Aliens or whatever you believe in, for a very
| shitty, downgraded version 0.0.1 of it sitting in
| someone's datacenter
|
| We really aren't. I consistently argue for LLMs as tools
| that augment and amplify human expertise, not as tools
| that replace it.
|
| I never repeat the "country of PhDs" stuff because I
| think it's over-hyped nonsense. I talk about what LLMs
| can actually do.
| hansmayer wrote:
| > Falcons certainly aren't deterministic.
|
| Well falcons are not deterministic and are trained to do
| something in the art of falconry, yes. Still I fail to
| see an analogy here as it is the falcon gets trained to
| execute a few specific tasks triggered by specific
| commands. Much like a dog. The human more or less needs
| to remember those few commands. We don't teach dogs and
| falcons to do everything do we ? Although we do teach
| specific dogs do to specific tasks in various domains.
| But no one ever claimed Fido was superintelligent and
| that we needed to figure him out better.
|
| > That's what makes them hard to use! A programming
| language has like ~30 keywords and does what you tell it
| to do. An LLM accepts input in 100+ human languages and,
| as you've already pointed out many times, responds in
| non-deterministic ways. That makes figuring out how to
| use them effectively really difficult.
|
| Well yes and no. The problem with figuring out how to use
| them (LLMs) effectively is exactly caused by their
| _inherent un-predictability_ , which is a feature of
| their architecture further exacerbated by whatever
| datasets they were trained on. And so since we have no
| f*ing clue as to what the glorified slot machines might
| pop out next, and it is not even sure as recently
| measured, that they make us more productive, the logical
| question is - why should we, as you propose in your
| latest blog, bend our minds to try and "figure them out"
| ? If they are un-predictable, that means effectively that
| we do not control them, so what good is our effort in
| "figuring them out"? How can you figure out a slot
| machine? And why the hell should we use it for anything
| else other than a shittier replacement for pre-2019
| Google? In this state they are neither augmentation nor
| amplification. They are a drag on productivity and it
| shows, hint - AWS December outage. How is that amplifying
| anything other than toil and work for the humans?
| simonw wrote:
| I've found that using LLMs has had a _very_ material
| effect on my productivity as a software developer. I
| write about them to help other people understand how I 'm
| getting such great results and that this is a learnable
| skill that they can pick up.
|
| I know about the METR paper that says people over-
| estimate the productivity gains. Taking that into
| account, I am still 100% certain that the productivity
| gains I'm seeing are real.
|
| The other day I knocked out a custom macOS app for
| presenting web-pages-as-slides in Swift UI in 40 minutes,
| complete with a Tailscale-backed remote presenter control
| interface I could run from my phone. I've never touched
| Swift before. Nobody on earth will convince me that I
| could have done that without assistance from an LLM.
|
| (And I'm sure you could say that's a bad example and a
| toy, but I've got several hundred more like that, many of
| which are useful, robust software I run in production.)
| lunar_mycroft wrote:
| > I really don't understand the "stop telling me I'm
| holding it wrong" argument. You probably are holding it
| wrong!
|
| I can't speak for others, but from my end it really seems
| like there's no actual way to detect whether someone is
| holding it right or wrong until after the implications
| for LLMs are known. If someone is enthusiastic about
| LLMs, we don't see claims that they're holding it wrong.
| It's only if an LLM project fails, or someone tries them
| and concludes they don't work as well as proponents say,
| that the accusations come out, even if the person in
| question had been using these tools for a long time and
| previously been a supporter. This makes it seem like
| "holding it wrong" is a post hoc justification for
| ignoring evidence that would tend to contradict the pro-
| LLM narrative, not a measurable fact someone's LLM usage.
| lunar_mycroft wrote:
| What you've experienced is different from what was
| originally mentioned though. Even with the best human
| developers, you can't provide a normal natural language
| prompt and get back the _exact_ code you would have
| written, because natural language has ambiguities and the
| probability that the other person (or LLM) will resolve
| all of them exactly as you would is approaches zero.
|
| Collaborating with someone/something else via natural
| language in a programming project inherently trades
| control for productivity (or the promise of it). That
| tradeoff can be worth it depending on how much
| productivity you gain and how competent the collaborator
| is, but it can't be avoided.
| samiv wrote:
| 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 wrote:
| 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 wrote:
| > 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/
|
| 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 wrote:
| 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.
| Stromgren wrote:
| I very much appreciate this take. I will say though that I've
| had experience myself where using coding agents lead me to what
| I'd consider (in your terminology) a better mapping between
| information and code. Not because the agent was able to do
| things better than myself, but because, as my project grew and
| I got wiser on how to best map the information, it was
| incredibly fast for me to change the code in the right
| direction and do refactorings that I otherwise might not have
| gotten around to.
| sillyboi wrote:
| 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.
| bhekanik wrote:
| As someone who uses AI coding agents daily, the thing that still
| surprises me is how much faster I can iterate on the "problem
| space" vs the "solution space." I can try 5 different approaches
| to a problem in the time it used to take to implement one. The
| code itself is cheap now, but the expensive part--figuring out
| what to build--hasn't changed. If anything, being able to quickly
| test ideas makes it more important to be clear on what you're
| actually trying to solve.
| alt227 wrote:
| 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 wrote:
| (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 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 wrote:
| > 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.
___________________________________________________________________
(page generated 2026-02-24 23:01 UTC)