Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- > PLEASE do not rest your killer argument for humans in software on us being the best quality gate
Rather than dismissing humans for quality control, we should take an asymptotic approach, where humans verify less and less as more verifications are automated, but are never out of the loop. Get down to 1% of the things, then 0.1%, then 0.01% and so on.
Automate all the linting you can before the agent is allowed to make a PR, make sure it passes the tests, add custom linting for dumb AI-isms you’re sick of telling the agent not to do - yes, you can lint for that fallback & backcompat code you never asked for, you just have the agent generate a script that walks the AST and flags the problem by line and file, then put that in your pre-commit checks - the agent treats it like just another lint error. Now you never have to review for that thing again.
But you still have value!
Even when you automated everything you can think of, there’s still tremendous value in human review. It’s your last chance to fully understand the implementation before it melds with the codebase. You also pick up more antipatterns to add to your automated reviewer (the automated reviewer is just a long prompt with an ever growing list of bullet points)
And the asymptotic nature of QC extends to observability and production. You cannot really ever automate a loop directly from observability to code fixes? Even when the agent presents a fix to an unhandled exception in production - if it was bad data, should you clean it in a backfill? If a key business metric dropped off a cliff because of a bug, should you add an alert once you fix the bug?
by cadamsdotcom - Great article. I'm not sure the author is correct - but I think something is happening to the adage:
> A sufficiently detailed specification is runnable code.
In a way I think LLMs will enable the dream of 4gl and "sufficiently smart compilers"[c].
LLMs aren't smart, but they are capable. Especially capable of translation and transformation.
I can certainly see them help move the abstraction horizon at which we work - so that rigid high level descriptions of the desired logic/process along with the process for quality testing - become the relevant curated artifacts - and the generated go/rust/java/python/etc code become incidental and mutable; subject to constant rewriting as part of the deployment of systems.
[c] You know, the ones that take naive C/C++ and produce executables that fully leverage RISC/EPIC platforms to be better than CISC. See also: Intel Itanium
by e12e - This is what Anthropic did with agents and $20k to write a C compiler that survived gcc’s torture suite. But the LLM knew:
1. What a C compiler was
2. What a C compiler looked like
3. What the C compiler had to do at runtime to pass gcc’s torture suite through some sort of collaborative iteration (compile, run, did it get stuck at some torture suite test or fail?)
Remove 1 and 2, or replace it with imperfect business logic, and you’re left with a system that is built to _only_ pass the tests you supply it, or in the most extreme case, print(“unit and functional tests pass!”)
by glouwbug - We don't even have to go that deep: If anything accelerates our rate of code change, but doesn't lower our incidents per change, we are still stuck in a larger pile of incidents, and that's if the code quality is exactly the same as before.
Without more, better testing, hopefully more invariants stored in type systems that are easy to reason about, and more recording of the reasons why we change things, we get a more unstable system in practice. One were fewer people can work at once.
by hibikir - "We treated code as permanent because the labor to produce it was the bottleneck."
I don't think that's true. We treated code as permanent because we considered code to be the source of truth. Computers don't run documents, computers run code. If the requirements document contradicted the code, then the default was to assume that the requirements document was wrong.
You can't separate code from spec because the code is the spec.
- I did not enjoy reading this article. The writing was fine, and each individual paragraph was fine, but the whole thing together was meandering and dare I say pointless. It was so many words and yet so little seems to have been said.by workbox
- meta, but: I gave up. I found the language really hard to follow and the point of the piece didn’t stand out to me. shrugby nielsbot
- > The writing was fine, and each individual paragraph was fine, but the whole thing together was meandering and dare I say pointless. It was so many words and yet so little seems to have been said.
I bet that I know why!
by SrslyJosh - Same, I like the general idea of that post. But the structure and verbosity made it such that I wouldn't want to share it with others.
- The intro lobbed up a clear cut point of contention for the article to address. I found the following writing to loose steam on that point. I turned to skimming, and did not manage to find a conclusion.
I suspect the stance they described as one readers mistakenly took away from their previous article to in fact be their stance. Otherwise why dance around it so hard?
by dogleash - I enjoyed it, people post on blogs as a way to entertain themselves, not necessarily the reader.
- I'm not sure this article had enough thought put into it. For example:
It's not so much as "the economics [...] were turned upside down", but that a manufacturing process that used to be strictly additive (akin to 3D printing) is now complemented by a subtractive process (akin to CNC milling). The "shape" that is demanded hasn't really changed, and nor has the human effort (as long as you care about achieving certain tolerances). You still have to "treasure, reuse, care for, and curate" your product to whatever degree the market demands.What happened in 2025 was this: the economics of code production were turned upside down. Instead of being very hard, time-consuming, and expensive to generate code, it became effectively free and instant. Lines of code went from being treasured, reused, cared for and carefully curated, to being disposable and regenerable, practically overnight.Also I disagree with:
What does "ideal" mean here? When I was growing up "show your work" was the rule for all examinations. Why? Because we're working to improve mental models and thought processes for the next generation, not just products we will release tomorrow.Lines of code are not the ideal artifact to reviewby argee - Before 2023 I remember everyone here on HN championed that removing lines of code was the strongest senior metricby glouwbug
- Simplification is still good. I remember one senior that only removed code when he joined the company I was at until he became a manager!by esafak
- Removing lines of code without removing functionality.by bluGill
- arent they still? or at least a lot. its too much current to win the swim race against the deluge of llm LOC. but i also disagree with some of the things the author just casually lays out, which is whether the LLMs can write good code. they write working code, but it looks written by a demogorgon and i get a bit ill seeing it. its bad but not bad in a way that a human would ever write, like i dont get that kind of sick reading spaghetti code written by new devs. it's a kind of sick like cthulhus eggs are hatching somewhere in your guts.by hashmap
- I read the article, and it seems she is forgetting the aphorism "all models are wrong". This is a common mistake that people who like "realistic" "simulation" RPGs often make. Any suitably comprehensive model of a thing is just the thing itself. To have a model of a location that includes all the detail of the actual location, you would need a 1:1 scale model, which is just a copy of the location. Any plan (i.e. prompt to a model) sufficiently capable of reliably replicating 100% of the functionality of a system is likely the source code of the system itself.by Elzair
- However the second part of that aphorism is "but some are useful". I have often wondered how much of IT/Programming is just sticking well understood pieces together. I remember 8 years ago wondering why we could not replace LLVM with a much simpler system that replaced all the manual optimization with a simple AI "optimizer" trained to transform simple compiled code into "optimized" code. I remember the consensus being that the AI system could likely not produce correct code reliably enough to be used. If AI cannot replace such "low level" code, then surely "high level" problems are widely out of reach. Yet people use it for "high level" problems. What gives? My hypothesis is that a lot of modern digital engineering is "plug and play".by Elzair
- I just spent a week reviewing this ~200 LoC PR: https://github.com/ncruces/wasm2go/pull/37
It was submitted by a seasoned user, who probably asked a frontier LLM. It still felt… wrong. I didn't understand it, and I wouldn't merge it without understanding it.
I also suspected it was wrong, in a way that would cause issues in the future.
So I reviewed it 4 different ways: (1) try to understand/improve it; (2) do it with better algorithms; (3) avoid it by fixing the issue upstream; (4) rewrite it from scratch probably just to match my brain.
I expected either (2) or (3) would be the answer. (2) didn't work, rather it's the correct answer but I need to redo the project from scratch to use it; (3) I wanted really bad to work, but didn't.
So I got to a blend of (1) and (4). I'm still not entirely convinced, but now I understand the issue/solution. I obviously think my approach is better.
Still, I still stripped both of comments, and asked my LLM to review.
The LLM came back and said the original one was clearly better. I explained why not, it then answered I was correct.
If I try it with comments, LLMs say the mine is better. Because I found a real issue (one that I pointed at in the original comment thread). But is it saying mine is better because I coerced it to say so?
by ncruces - > What happened in 2025 was this: the economics of code production were turned upside down. Instead of being very hard, time-consuming, and expensive to generate code, it became effectively free and instant. Lines of code went from being treasured, reused, cared for and carefully curated, to being disposable and regenerable, practically overnight.
I've been thinking about this a whole lot recently. So much of my intuition about software development is based on 25 years of accumulated experience on how long it will take to write different bits of code.
Should I add validation for this one edge-case which won't break everything but will make a little bit of a mess if someone hits it? If that's an extra couple of hours of code I might skip it. If it's one more prompt, why wouldn't I?
This new feature would be a lot easier to understand if there was a custom API explorer for it. There's no way I could justify investing in that... unless it's just 10 minutes with Codex, and it was: https://tools.simonwillison.net/datasette-extras-explorer#ur... (linked from the release notes https://docs.datasette.io/en/latest/changelog.html#extra-sup...)
That's just on the small scale. There are entire projects that I'd never previously have considered, because I don't need a custom SQLite SELECT query parsing library enough to justify spending a week or more building one. But now... https://github.com/simonw/sqlite-ast
People get VERY upset (and condescending) any time you suggest that being able to produce lines of code faster is a valuable thing. And sure, measuring output through "lines of code" is stupid.
But measuring "lines of verified code that deliver valuable" isn't stupid at all. That's the thing we can do faster now.
by simonw - >People get VERY upset (and condescending) any time you suggest that being able to produce lines of code faster is a valuable thing.
I think some people care about understanding things they have to attach their names to. Many obviously don't care, but others do.
by jplusequalt - >But measuring "lines of verified code that deliver valuable" isn't stupid at all. That's the thing we can do faster now.
Except measuring the value of an individual piece of code is still very difficult if not impossible.
- I’m gonna say this in the most polite way that I can but who cares?
Look around you - google is valuable because it hoovers up data to generate revenue from advertising and has minimal expenditures compared with the revenues. All those bets? Lol yeah what about them?
Engineering for the sake of engineering has no value to the economy - aka it’s irrelevant. It’s the hard truth nobody wants to hear. There’s a limited set of things that can existence in the economy at any given moment in time - only those that provide value and can be sustained w.r.t economics stay the course.
by eiwiwi - I liked this article, and I see a lot of other commenters didn't, so I'll give my take:
When starting on a new codebase, how do you make yourself into a helpful contributor as quickly as possible? I go straight for the humans and their human docs. What problem was the system originally built to solve? What was the original design, and what were its biggest problems? Who is currently using it? If you know these, reading the code is much easier because you can guess why things were done the way they are.
Also, this blog post has gotten popular: https://blog.gpkb.org/posts/just-send-me-the-prompt/
I think Charity is observing a very old problem and expecting the new technology to lead to a new solution of some kind. I doubt she thinks even the current generation of tools are the end of the AI software development story. She's not saying we'll drop design docs right into Claude code and walk away (design docs aren't complete either, that's why when you're ramping up you also have to talk to people, read old tickets and postmortems, etc.)
What she's observing is that, in prod, people don't like infra where it's hard to tell how it got into is current state, and so infra-as-code is what we do now. She's also observing that, "it's hard to tell how it got into its current state" is the status quo with codebases, which other people have observed going back to "Programming as Theory Building" and earlier. And she's expecting that, analogous to infra, software development will somehow be done with tools focused on making "how the code got into its current state" clearer.
by msteffen - I liked the article. It was a long (and entertaining) build up to the conclusion, but I'm scratching my head how the author got there.
AI needs more discipline, yes. But theoretically that discipline can be learned much easier than becoming a good engineer.
Think of it this way... 20 years ago, to write good, scalable C code - you needed to 1) either be a genius, or 2) dedicated to the craft.
You need to learn dozens of tools like the back of your hand.
* ASan
* LSan
* UBSan
* TSan
* GDB
etc... God forbid if you needed to manually read DWARF files. Unless you're a pure genius, this is not feasible to master in a short amount of time. And in parallel, you need to learn how to design systems, too, otherwise, you're still not very good, and that's an almost completely orthogonal skillset.
Now, you simply need to be aware of the hazards in your language/framework, tell your LLM to test for them, have the infrastructure set up to see if they've adequately tested for those hazards, and maybe read the actual tests and implementation.
It is pretty easy to be able to read and understand Rust compared to debugging all the sorcery-like errors that come during Rust development... It is easy to see that you need a Loom test for certain scenarios, and to write a tool to detect if you did it.
Even if you're still working in C or Zig, it far easier to know and detect when you need to use those tools then to learn to use them all individually.
It is not hard to learn to read SQL. Almost ~50% of business professionals can. Python is barely harder. Rust can look like sorcery if you don't read a 50 page guide to understand to read it, but that's a VERY small price to pay compared to spending ~10 years learning the craft painfully by trial and error.
I'm not sure how you get from "LLMs work in mysterious ways" to "So we need more discipline" to "everything is fine."
I agree that everything is fine. I just don't think this is the clear path and thought process.
Anyone who has the determination to get things to actually work, and takes a little bit of time to understand what makes them not, should be able to leverage LLMs to work wonders.
In my opinion, LLMs are going to make things far more complicated, because the cost of building something complicated is becoming almost free.
Engineering was always about discipline and getting things to work. But you needed a set of prerequisite skills to have much value. Most of those are gone now.
It is simply far easier than before. It does require discipline, yes. But discipline is cheap compared to ~10 years of trial by fire.
- I wonder if the reception is so variable due to differing exposure to 1) infra as code and 2) engineering teams that don't produce any artifacts outside of their code.
> When starting on a new codebase, how do you make yourself into a helpful contributor as quickly as possible? I go straight for the humans and their human docs. What problem was the system originally built to solve? What was the original design, and what were its biggest problems? Who is currently using it? If you know these, reading the code is much easier because you can guess why things were done the way they are.
This is the way but plenty of engineering teams don't have any human docs at all. Decisions are made in one engineer's head or in a chat that isn't saved. The spec was just a few notes in a ticket that was deleted during cleanup or lost when the team changed trackers. There's no map of the codebase or features, no ADRs, minimal observability. All you have is the code. You read the code to try and figure out what is going on then ping an engineer who made a recent commit to a specific area to ask if they remember why something was done the way it was. Someone makes a change and it breaks something on the other side of the codebase that they thought was totally unrelated, etc.
by molsongolden - > Those are not code problems. They are evaluation problems.
> Code becomes precious when it is the only place knowledge lives.
Reading AI code all day is _agonizing_. Just, a horrible way to live, and it melts people's brains at the moment you need them to be the most capable.
Manual programming has this really productive and gratifying feedback loop, where you read the code, write the code, and fix it until it compiles/runs/does what you want. AI code not only does half that for you, but it makes the "click" at the end uninspiring because you're never sure if it's cheated a bit to get to that moment.
Trying to operate with AI-generated code as the only durable artifact of programming is a dead end for the industry. Charity points to (and correct discards) architecture diagrams/specs as an interesting space to work in. My suspicion is that it's closer to the thing that's hand-written: prompts, markdown plans, and other nudges. Focus on the thing that you, as a human, produce, and that's the basis for both the core loop of "did the AI follow my instructions" and it's higher-leverage when you go to code review.
By the time you get to the PR, you've probably typed enough to Claude that you can regenerate the code, but the current industry default is to just throw away all those sessions and ship the code. That's backwards!
by trjordan - the act, eval, adjust loop is probably neurologically important.. reading about things you didn't dive into is really a dread
depending on your industry, you might be able to ship half-slop and then fix some bugs downstream though
by agumonkey - Are there any products out there that are capturing the prompts/sessions? I imagine you could do it in an adhoc way, asking Claude to write up a summary of the session as part of the commit message. But is there anything else that's more structured/higher level?by mooreds
- Flintstone Engineering is applying Space Age synthetic intelligence (in a metaphorical sense) technology with code generation. Babysitting, version controlling, etc. generated code should be a thing of the past. But that is what GenAI is.
At the very least apply it at a higher level: specification, proofs, anything but generating Rust/Java/C and then letting yourself or an agent babysit it.
by keybored