Get the top HN stories in your inbox every day.
ryandvm
strix_varius
I'm sure this is gated by where you work (especially by how technically savvy your manager is), but the most effective contributors at my job tend to be the ones with near-zero (or sub-zero!) net LoC.
LLMs are prolific and they love to add shit. Truly capable engineers are able to achieve more business outcomes with less code / fewer moving parts.
tj-teej
"Truly capable engineers are able to achieve more business outcomes with less code / fewer moving parts"
I'd simplify to "Truly capable engineers are able to achieve more positive outcomes" - half of what makes a capable, dependable engineer is knowing what outcomes are needed and making them happen.
strix_varius
Good revision!
ecshafer
I really can't agree with this. Sure pure LoC is a bad metric. But there is a correlation between output and LoC. Outside of a very senior developer, maybe a Principal or Lead that is spending all day in architecture meetings and reviewing PRs, most high performers are also outputting code.
strix_varius
This is exactly what the article is addressing:
> But there is a correlation between output and LoC.
That is less true today than it ever has been, due to LLMs.
dlahoda
They could just use AI to communicate. Why they they still on meetings?
dakiol
"High performers". Can't believe we have normalized this vocabulary, among us, "hackers".
SwtCyber
Good code is absent code LLMs by nature work like autocomplete on steroids. They're always trying to write more than necessary to please the prompt. Seniority now is measured by the ability to break down a task so that the agent doesn't even think to drag in unnecessary abstractions
pydry
if you're trying to use sloc as a proxy for productivity in any way, shape or form you've already lost the game.
i tend to find that the most productive teams make better decisions and work fewer hours. the quality of decisions is such a huge force multiplier that it renders actual hours worked almost an irrelevant variable.
andrekandre
> if you're trying to use sloc as a proxy for productivity in any way, shape or form you've already lost the game.
in fact, i've sent over 20 variable rename prs and am now topping the leaderboard!
4lx87
The most effective contributors at your job remove more code than they add? That doesn't sound effective that sounds like digging ditches to fill them. Every line of code removed is a line that was previously added.
sarchertech
We had a library written by a former employee who was a prolific producer of code. He insisted we needed it and spent over a year developing it in company time.
The library was a masterpiece of what if driven development. It was about 50k LoC, and it had 300k LoC of dependencies. It was a nightmare to modify. And no one wanted to take over maintenance so people would submit PRs to the former employee when they did modify it.
I wanted to change something in the library to support a large migration I was in charge of. When I went digging it turned out that we were barely using any of the features in the 2 years since he’d finished it. I replaced the 50k LoC library and 300k LoC of dependencies with 300 lines in less time than it would have taken me to modify the library (a few days).
banannaise
Turning inefficient, unreadable code into efficient, readable code often results in an overall reduction in LoC.
High-quality code and high-volume code are highly anti-correlated. Incidentally, low-quality code that is excessively long just so happens to be common complaint with AI-generated code.
gitremote
> The most effective contributors at your job remove more code than they add?
Yes.
> That doesn't sound effective that sounds like digging ditches to fill them.
It sounds effective to me, like removing garbage from sidewalks so people can walk straight instead of walking around the trash.
> Every line of code removed is a line that was previously added.
Correct. Today I cleaned up
if (a || b)
return true;
if (c)
return true;
if (d)
return true;
return false;
return a || b || c || d;
Every line of code removed is a line that was previously added.
Do you have any experience coding before LLMs?
overfeed
> The most effective contributors at your job remove more code than they add
Perhaps they tackle non-code-editing tasks like architecture, design, mentoring and code review (think staff and principal tasks)
> Every line of code removed is a line that was previously added
Yes. This os not a failure. Code has a surprisingly short half-life.
nedt
It's all about YAGNI. Programmers try to be smart covering cases no one thought about, reviewer is happy that corner cases have been implemented, artificial tests report all good. But it's just more to read when you have to change the code.
BerislavLopac
Deleted code is debugged code.
strix_varius
Thought experiment: if you can solve a problem with 100 lines of dependency free code, or with 10,000 lines of code that depends on hundreds of things - which is better?
There's an obvious answer of course. And that is the direction that these effective senior engineers move towards.
georgemcbay
> That doesn't sound effective that sounds like digging ditches to fill them. Every line of code removed is a line that was previously added.
Because they were added doesn't mean they were needed and even if the same person added and then removed them, it doesn't mean they are digging ditches to fill them.
The idea that "I would have written a shorter letter, but I did not have the time" also applies to code, and sometimes later you are blessed with more time than you had when implementing something under deadline pressure.
QuantumGood
• LoC/LOC = Lines of Code
• sloc = Source Lines of Code
.. so I suppose nloc would mean Net LoC
ihsw
[dead]
thisisit
There are also people who think AI is magic. I have often heard - "we want to use AI to automate processes but we don't have full documentation about the processes, we hope AI can help". Despite being told that no one can create outputs from thin air - every AI topic turns into the same discussion.
Often the solution to create those document to feed into these AI automations? Use AI. Its like ouroboros. Create docs using AI, then summarize and ingest using AI, explained by AI.
Same thing is going to happen with code. Create 1000s of line of code using AI. Then explain it using AI etc.
sph
"I distinguish four types. There are clever, hardworking, stupid, and lazy officers. Usually two characteristics are combined. Some are clever and hardworking; their place is the General Staff. The next ones are stupid and lazy; they make up 90 percent of every army and are suited to routine duties. Anyone who is both clever and lazy is qualified for the highest leadership duties, because he possesses the mental clarity and strength of nerve necessary for difficult decisions. One must beware of anyone who is both stupid and hardworking; he must not be entrusted with any responsibility because he will always only cause damage."
— Kurt von Hammerstein-Equord
These days it is so easy to appear hardworking (by volume of contributions) when you have LLMs. The difference is that the inept now can literally create orders of magnitude more than the careful, experienced engineer.
Arthurian
The under-performers and coasters just don’t read their code, in my experience thus far it’s been pretty transparent. PRs aren’t a perfect gate, but they’re one of the only ones we have right now, and it’s pretty clear who’s putting in the effort and who isn’t.
beezlewax
How is it clear though? It can be really hard to tell.
giancarlostoro
> It is now significantly harder to figure out who understands the systems and is using AI effectively and who doesn't know shit and is just slinging LLM copypasta around.
It's okay, I'm sure the algorithm questions during the interview phase totally weeded out the fakers of systems knowledge right?
golly_ned
I've even seen AI-generated roadmap documents that promise the world, are broadcasted to director+, who sign off without a thought.
Words and code are so cheap they're meaningless, while human focus, attention, and understanding are so expensive and overloaded.
blensor
Maybe the solution is to look out for the most silent engineers. Those that output less despite having the ability to create near infinite output.
AStrangeMorrow
Not sure how to understand that. You mean as the best engineers?
Funnily at my company, the few engineer that did the majority of the work before AI still do the majority of the work now. By majority I mean tackling both more issues and better.
However there is a general verboseness and over engineering trend across the board.
blensor
Kind of yes. The person who does not spam the messages.
What I noticed for myself is that saying no to something is becoming harder by the day because, why wouldn't you try something if it's so cheap to do.
That makes having the strength to say no almost a quality in and of itself.
That is true both for external pressure and internal pressure.
protocolture
>I have a feeling that the fallout from this phase of the industry is going to be an exotic form of technical debt that is remarkable mostly in its enormity.
This.
I feel like it is going to become illegal for older engineers to retire until its all cleaned up. When the debt catches up its going to be civilisation level problem, like asbestos or lead.
aakresearch
> like asbestos or lead
Perfect framing! I was leaning towards "AI Chernobyl" analogy in my predictions, but I think "asbestos" or "fossil fuels" captures its nature much better. May I borrow it? I definitely see the harmful consequences of "AI" exceeding both, however with sad realization that it usefulness was absolutely below par with any.
deadbabe
Illegal? Get fucked. They will retire and you can deal with the mess, you have AI.
When you can no longer pay off technical debt, you turn to technical bankruptcy: start over from scratch, greenfield.
I predict what will happen is eventually the number of technical bankruptcies will rise, and there will be some new movement to only build codebases that fit within human heads, no AI required. This means no more architecture astronauts or code bases where you spiral around massive abstractions just to implement simple features. I look forward to this, as it will become a sort of competition between engineers to see who can do the most with the least amount of new code.
protocolture
>Illegal? Get fucked. They will retire and you can deal with the mess, you have AI.
Considering the balance of my job is cleaning up technical debt, that's my own retirement I am worried about.
>When you can no longer pay off technical debt, you turn to technical bankruptcy: start over from scratch, greenfield.
What that looks like in say, 2030, I can only guess. We saw this happen to a multinational shipping company due to cryptolocker, but I dont know if theres going to be any interest in replicating that. Certainly the AI barking in the ear of the CEO isnt going to recommend it.
>I predict what will happen is eventually the number of technical bankruptcies will rise
Outside of industries required for national security maybe.
> there will be some new movement to only build codebases that fit within human heads, no AI required.
I suspect that rational governments are probably going to require No AI clauses in their tenders, but that we will also get hundreds of high profile "Whoops we used AI in this contract when we shouldn't" scandals that come to nothing.
trjordan
> 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!
philbo
If a coworker dumped a 5k-line code review on you, you'd tell them to come back when it's broken down into smaller, reviewable chunks. Large dumps of code are basically unreviewable by humans, but it seems like a lot of people have forgotten about that when it comes to LLMs.
trjordan
I think it's worse than that. At least if I dumped 5k LoC on somebody in 2021, you knew I spent the time to write it, so it's "fair" to ask you to read it. But I didn't write it in 2026, so you shouldn't read it.
I think it's less about "break it down" and more about "let's communicate at the same altitude."
I wrote a (bait-titled) post about it: https://tern.sh/blog/stop-reading-prs/
fusslo
113 files +22913 −2423
305 files +15075 −13110
153 files +21934 −8698
125 files +28120 −2398
43 files +11188 −63
118 files +21564 −647
These are the largest (6 of 35) in the past 30 days. added: 190079 removed: 39696 in the last 6 months
from one person.
roncesvalles
You aren't allowed to block PRs for being too large anymore. The objective that every engineer should be 2x/3x/5x more productive can only be achieved if you go totally lax on code reviews.
Because if all your SWEs produce 5x more code, it also means they have to review 5x more code. But LLMs don't really help with code reviews. Then it becomes a Metcalfian paradox unless you just rubberstamp PRs, which is what is expected of you.
vanuatu
its pretty easy to point your terminal agent to your giant pr and ask it to break it up into small prs
if youre being asked to rubberstamp prs thats a management skill issue
SwtCyber
[dead]
darth_aardvark
Breaking up a giant PR can be a tedious, time-consuming hassle, and in the past I could sympathize in practice if someone had a giant PR they didn't have time to decompose once they got it working.
But it's also the exact sort of thing that LLMs are literally perfect for in my experience so there's really no excuse anymore. I've never seen Claude fail to turn a 5k PR into a well-decomposed Graphite stack.
xmodem
Hell, I've hand-written a large PR as a single commit and then asked claude to break it down for me at least once. But I think the fact doing this task by hand is a tedious, time-consuming hassle is not because it inherently has to be but because the tooling for doing it has barely changed in the past 15 years.
zmmmmm
Now you get not just the 5 LoC to review but a 5 page essay to read in the form an auto-generated review as well. Which makes the submitter even more indignant when you start nit picking things about how it's implemented.
win311fwg
It is not so much forgetting as much as it is acceptance that when welcoming AI into a codebase, the code can no longer matter; that all that matters is that the properties of the system are validated. That isn't a change that comes free, so nobody should be expecting magic, it is a different set of tradeoffs. There is no such thing as a panacea.
rienbdj
> all that matters is that the properties of the system are validated
I don’t think this is possible in practice without leaning on the stability of the code base.
ChrisLTD
How can the code no longer matter? It literally is the logic (not to mention performance, and reliability) of the software.
hootz
I think they expect you to also use an LLM to review, and I bet they are doing exactly that when asked to review someone else's code.
latentsea
That gets you 90% the way there. So, it it only really works if you accept the cruft and the risks associated with that last 10%. Been doing this day in a day out for the last few months and no matter how much and how good we get the automated reviews, we still can't skip the manual ones.
acedTrex
Theres really no diff between a rubber stamp and an llm review, they both do the same thing.
cmrdporcupine
> If a coworker dumped a 5k-line code review on you, you'd tell them to come back when it's broken down into smaller, reviewable chunks.
I would, and all my training at Google told me to do that. But what I found after I left that comfortable box was that somehow this kind of practice is acceptable in the industry at large and you're expected to just Deal With It(tm). 5k lines isn't even high by what I've seen.
Worse the "code review" tools that people have access to in GitHub make this absolutely and totally unworkable to incrementally improve review. Messy merge commits full of "responding to code review" comments. Threads impossible to follow. Just bad tooling.
So a lot of shops, from what I've seen, are just yeeting it with very shallow reviews.
This is my observation pre agentic AI. LLMs just threw kerosene on that dumpster fire.
vjvjvjvjghv
"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."
I think it's very similar to dealing with large offshore teams. Every day you get a huge pile of code to review. It's really exhausting.
I prefer dealing with AI because at least it tends to follow rules once I write them down. Not so much with a lot of offshore guys. Same mistakes every day.
I guess my company needs to hire better offshore devs....
gavinh
I agree that reading AI code all day is agonizing. We're relying on code review to develop parts of our mental model of the system that were previously developed through coding. We're having more difficulty comprehending and recall details of the system. This is probably unsurprising; people recall information better that they "generated" than information they read. I am applying some lessons from pedagogy to extend code review. If this resonates with you, I would like to talk.
mooreds
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?
sdesol
I am working on solving the AI Code Provenance problem and I believe my repos may be the first that provides AI code provenance. See the following example:
https://github.com/gitsense/gsc-cli/blob/main/internal/cli/r...
Notice how the code block header attributes the model. The UUID can be traced to the conversation so everybody can tell exactly how the code came about. For this to work though, you need to use my chat app as it ensures you can't tamper with things if you are truly serious about AI code provenance.
I also have a lot more human-focused method which is part of my CLI tool.
https://github.com/gitsense/gsc-cli
I am currently looking at making pi (https://github.com/earendil-works/pi) support AI code provenance, but for now if you want a more structured way to capture what you have done in an agent session that can be used in code reviews and be carried forward as knowledge that lives inside your repository, I have
gsc lessons
The basic idea is, after you have finished chatting/working with the agent, you would work with it to identify lessons worth carrying forward. You can store your session if you want, but really, the lessons should be something that can help you review code better and to prevent future mistakes.
I have a real working example at
https://github.com/gitsense/smart-ripgrep
This is a fork of the BurntSushi/ripgrep repository. It shows how you can use lessons to learn from past design decisions.
trjordan
We're working on it, thought it's all early. I'd love feedback: https://tern.sh
First product compares the code to the prompts and highlights places the agent made decisions you weren't involved in: https://tern.sh/docs/tours/
latentsea
We just have hook that runs on git push that instructs Claude to ensure the PR description is up to date. Works well enough for us.
mplanchard
So many. The sibling comments, plus GitAI, plus empathic, plus many others
deaton
It almost seems like the juice might not be worth the squeeze. If you want verifiable code that conforms well to a well-designed plan, you have to basically write pseudocode and have the AI translate it for you. At that point why use the AI to write the code at all? And then, personally, I find that I just have more fun planning, writing, and debugging myself. I think its kinda the part of programming that I fell in love with in the first place.
pydry
This is the core of the insanity nobody who vibe codes seems to be able to grasp.
It's not even that its more fun, AI can spew endless slop boilerplate but it simply can't handle boiling an application down to its component essence in a way that makes it straightforward to maintain and bug free.
keybored
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.
agumonkey
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
simonw
> 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.
eiwiwi
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.
zmmmmm
> Engineering for the sake of engineering has no value to the economy
I think that's the adventure we're on now. If recreating something is low cost, what is the value in investing in designing it well in the first place? We can empirically discover issues and the the AI to address them.
I certainly routinely find in supervising what the LLM is writing that it's making terrible internal design choices and correct them. Usually things one level up from code. "This will cache every image on the client and cause a huge amount of bloat. Change it to pull the image in real time from the server" kind of stuff. You do slowly build that up in the project documentation - "Never store unnecessary data on the client: we assume they are using low powered devices without substantial storage". But it takes time and the road to discovering that empirically is through a lot of unhappy users.
So I think there is still a lot of room for genuine engineering - that is, at the technical design level. Levels up from that - code structure etc - are much less clear. I am guessing that over time we will heavily optimise code written by AI for maintenance by AI. Which may be mostly about matching the context window to the code module size. Factoring something to 5 modules may be less of a good idea if it means the context window has to hold all of them for the LLM to work. But that is the path of discovery we are on which history tells us is a 20 year journey.
skydhash
> Engineering for the sake of engineering has no value to the economy - aka it’s irrelevant.
I would put that as my signature if HN supported that. I see a lot of systems being built where the whole point seems to be about the ritual, not anything valuable for the user.
jplusequalt
>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.
msteffen
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.
molsongolden
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.
LtWorf
You guys get tickets that tell you what to do in detail?
sublinear
Talking to an LLM is often still a lower quality result than asking the lead engineer themselves or the collaborators they left behind. You're making a tradeoff between time taken and result quality.
Even the most AI-positive teams prefer human discussion when things get that tough. Given enough time, things will "click" for humans. LLMs don't work that way.
Even a team of all-new unfamiliar devs forced to study an old codebase will eventually figure out what it was about and pick up tons of nuance the LLM cannot. This is the nature of writing. It exists in a time and place beyond the pure literal text. Humans live in this context and can get into the headspace of the original dev(s).
molsongolden
Agreed and I think the author agrees with this too. One of the ideas is that the devs should be discussing and documenting their intent outside of the code then letting AI tools generate the code as specified. "Engineering" should occupy the time that was previously occupied by "coding" and the context and writing should exist as intentional written context, not just poorly documented code.
undefined
onlyrealcuzzo
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.
msteffen
> I'm not sure how you get from "LLMs work in mysterious ways" to "So we need more discipline" to "everything is fine."
Are you referring to this part:
> I am not worried, at least in the near term, about AI creating massive, discontinuous returns on investment in the absence of engineering discipline. (Many will try, and it will be entertaining to watch.)
She's saying, "the amazing thing about LLMs isn't that they generate lots of code fast, so don't worry about people using LLMs for that taking over the industry"
She's making two points:
1. Before infra-as-code, people would be afraid to touch parts of production due to lost knowledge about how and why it got that way. Now that we have infra-as-code, you aren't allowed to change infra the old way (ad-hoc changes via dashboard/CLI), even if doing so would be faster and easier. Experienced SREs were required to abandon lots of their old skills with CLIs and dashboards and start working in a completely new way, because the knowledge captured in a terraform repo's commit history is so valuable.
2. In the past, the way code got written was through people making changes in ways that are specific to their current knowledge, the org's current problems, the current users, etc, some or all of which is not written down. Eventually, everyone is afraid to change certain things because they don't know or remember all the considerations that went into them (not just afraid to touch parts of the code, but afraid to delete seemingly-unused features, or migrate the schema, or whatever).
Charity is saying that problem 2 is a hidden/lost-knowledge problem like problem 1, and the amazing thing about LLMs is you have to write down all the knowledge you want them to have, which may lead to a better solution to the "lost knowledge" problem in software development, which would be so valuable that experienced software engineers have to abandon lots of old skills and start using it.
(Not only writing down all the knowledge you want the LLM to have, since they're flaky enough to ignore instructions and miss implications sometimes, but building test suites and tools and so on that adequately guide their solution. This is the "more discipline" she's referring to.)
jreynar
Articles like this are exactly why I doubt that SWE jobs are going away. The SWE job of 2026 doesn't look like one from 2020, let alone 1990 so why would anyone believe the false dichotomy that either the SWE jobs of 2026 will remain or all be eliminated? I worked at Google a zillion years ago when the idea of reviewing all code was novel. Before that, when I worked at MS things mostly didn't get reviewed until the end of the project when the stakes were high because code got burned onto a CD and put in a box. The way SWEs spent their time changed radically from 2000 to 2004 and I think for the better since it increased shared understanding and fostered more collaboration.
If AI writes the code and humans spend more time reviewing it, that might not be a bad thing, but when the AI code is good enough, people are going to view thorough reviews as optional. Then the job of a SWE will look very, very different than before since SWEs won't write much code or spend much time reviewing it. The IDE may go the way of the dodo. And maybe the focus will move to setting up the goals and tests that keep the AI coding team on task. Maybe SWEs will spend more time architecting since they're likely to know where projects are heading and won't want AI to rewrite things as goalposts legitimately move. Maybe more will be spent exploring: build it one way and another and another and compare and generate new ideas from the different approaches.
I have no better idea than anyone else, but I'd be heavily against the role going away and in favor of it evolving, like it's done many times before, though perhaps never as rapidly as it is right now.
ncruces
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?
Elzair
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.
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".
edot
George E.P. Box for anyone wondering. So true. “All models are wrong, but some are useful”. True of any abstraction unless you’re doing everything at the quantum level, but even then … are you sure you’ve captured all the details? But then … does it matter? As long as your model is sufficient to do the thing you need to do, it’s useful enough. Don’t make it any more complicated.
glouwbug
Before 2023 I remember everyone here on HN championed that removing lines of code was the strongest senior metric
hashmap
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.
bluGill
Removing lines of code without removing functionality.
esafak
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!
hungryhobbit
Ok, I like the idea and support that seniors value simplicity ... but how the hell do you stay employed for even a month (let alone until "manager time") without writing any code?
LtWorf
You don't just delete stuff… it's more that your pull requests remove more lines than they add. But I'm sure the person you're replying to is exaggerating, or they got promoted because of completely unrelated reasons.
workbox
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.
argee
I'm not sure this article had enough thought put into it. For example:
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:
Lines of code are not the ideal artifact to review
molsongolden
I think the point is that there are better engineering artifacts to review instead of lines of code. Encoding the decisions, structure, requirements, testing, monitoring, then reviewing those and having AI generate and regenerate code based on them. The code itself doesn't matter if enough thought and rigor has gone into the structure that produces the code.
> 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.
They're saying that the mental models and thought processes are incredibly important but that code is not the place for that work to live.
argee
> They're saying that the mental models and thought processes are incredibly important but that code is not the place for that work to live.
What I meant is that, insofar as some work has been produced with a human mind involved and where imperfect abstractions are used, one should not for whatever idealistic reasons push for reviewing the work at some coarser granularity than the details which are readily available. That's a way to foster and encourage mistakes, in both the work and in the mental model.
So when you say that code is not the place for that work to live (or more closely to the line I disagree with, that code is not an 'ideal' artifact to review), you are essentially purporting that there is a perfect abstraction that can generally be trusted, which I disagree is currently the case for an LLM spec versus produced code.
skydhash
> They're saying that the mental models and thought processes are incredibly important but that code is not the place for that work to live.
They’re important for discussion and brainstorming. They’re also important for sharing context before reviewing. But code is the only perfect representation in terms of semantics of what the computer will do.
You can have all the diagram and all the proses you want, but they’re still ambiguous.
z0r
As soon as I read the quoted paragraph, I rapidly scrolled to see how much more was written, then closed the tab. Generating a lot of code might be 'free' now but the generated code is very costly. I don't have the time to read an article written upon such a premise.
stephbook
My vibe sense tells me AI slop. It's just too much vacuous text in general and "not x, but y."
ed_elliott_asc
I enjoyed it, people post on blogs as a way to entertain themselves, not necessarily the reader.
BhavdeepSethi
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.
SrslyJosh
> 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!
nielsbot
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. shrug
dogleash
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?
BerislavLopac
It's interesting how most of the comments here seem to miss the most important part of the article, which is this:
> 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.
A little but further reinforced by this:
> I am just barely old enough that my first job title was “System Administrator”. [...] I lived through the shift from handcrafted server pets to immutable infrastructure cattle.
What is happening now is nothing new, we have seen it many times before: a shift in technology which is bringing changes in the ecosystem, required skills and so on. This happened with stocking frames, steam engines [1], automobiles, servers, and now the code. Just like before, many will be - and already are - harmed by this, but ultimately the world will adapt and accept the new paradigm.
[1] There's an infamous screenshot of a tweet being shared around, where someone suggests various names for writing code without AI, and someone else responds with "software engineering". Allow me to add my on contribution to this debate: codejamming.
SwtCyber
It's good to see the hype around "programmers are no longer needed" giving way to a more realistic view. Generating lines of code was never the hardest part of engineering. What's much harder is understanding exactly what we're building, how it integrates with legacy systems, and making sure it doesn't crash the database under load
youknownothing
"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.
Get the top HN stories in your inbox every day.
It is now significantly harder to figure out who understands the systems and is using AI effectively and who doesn't know shit and is just slinging LLM copypasta around. Before 2025, the underperformers/coasters were at least relatively identifiable by the paucity of their contributions. Now all of the sudden every single engineer is filing PRs, code reviews, technical design documents, and every other artifact under the sun with perfect formatting and at least superficial plausibility. This is mostly due to incredible pressure from the C-level for every engineer to be using as much AI as possible, but it's also just a game theory respopnse because it's in every engineer's best interest to be as prolific as possible.
We are absolutely drowning in documentation and code that seems legit and the only recourse is to lean on AI to help process the sheer quantity of it. I have a feeling that the fallout from this phase of the industry is going to be an exotic form of technical debt that is remarkable mostly in its enormity.