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.
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.
"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.
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.
> Most of us work for business and on teams where performance matters.
It truly does:
performance – the action of entertaining other people by dancing, singing, acting, or peformative coding
The problem is, that shouldn't matter. If you work somewhere it does, well, you probably have to. But that's OK, it doesn't stop you from working to uplift the goal and conversation and deliverables, through these other definitions of performance:
performance – how well a person, machine, etc. does an activity
Now we get into how to define well, but activity, looking busy, may not be as valuable as outcomes.
performance – how well a person, machine, etc. does a piece of work
This is getting close, but here we need to define the nature of work, the qualia of work. It's not how well someone codes a line of code, or how well someone programs a piece of software. It's not even how well the engineer a solution.
What matters is return on equity, meaning: how well does what is delivered enable the business to turn capital investment in bringing ideas into being, into returns on that capital.
For good measure (pun intended), track long term, so resilience, maintainability, and evolvability, and really any ongoing costs, including delay costs, opportunity costs, or cash flow costs, are part of the definition of how well.
That matters.
Note this can be shorthanded to both GPT and Claude, and will change the machines’ suggestions.
Dunno about you but I work for a "business" (large company, you've heard of it) and the concept of "High Performer" is synonymous with "best politician". Sure, a lot of theater goes into things, especially dances around "data points", but at the end of the day the top tier goes to the fortunate sons.
You should not treat it as fact that "performance" of an individual, not a team is a thing that actually exists in any way that matters and is measurable.
I’m not sure that there is a consistent definition for matters in this context. What matters is completely subjective to an individual. Furthermore, performance is rarely correlated with success and compensation in an enterprise. I could just as easily say that playing the game is what matters.
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.
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
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.
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).
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.
How so? Let's say that over a year, a given section of code needs to be read and understood once a month. Taking some time to keep the code succinct and free of distraction will increase productivity all those occasions, as well as the rest of the lifetime of the system. Say the next decade.
Written exactly like that, yours is obviously cleaner.
But, if that original code had comments and traceability of each condition and return to a specific domain scenario, you would be doing a disservice by collapsing it to the one flat boolean expression. In that case, it may be better in its expanded form, and you should let an optimizing compiler do the collapsing.
If there were comments for each conditional, it should still be refactored as
return a || b // comment 1
|| c // comment 2
// long comment 3
// on multiple lines
|| d;
Many years ago, "lines of code" was the classic example of nonsense management metrics. Today, there are somehow HN users who argue that lines of code is indeed a good metric and ask "But what if the code had comments?" as if they have never seen comments interleaved with code.
> In that case, it may be better in its expanded form, and you should let an optimizing compiler do the collapsing.
This is nonsense. This optimization is not about compiler optimization for efficiency. It's an optimization for human readability and maintainability.
FWIW, I'm no advocate of "lines of code", or really any KPIs at all. All I'm saying is context matters.
Such branches could make sense if the conditions have to do with underlying domain concepts, but you expect the outcomes to be revised. It could just be a moment-in-time accident that they are all returning True right now.
This kind of tension is also where you often see indirection via configuration files or other auxiliary data structures. Or in the old days, things like bit fields instead of booleans, so that merging the conditions would encode different small integers to use as lookup table indices.
That's still going to make it hard to read. I'd have one big comment above talking about the different cases and then one line of code. Even with the slightly higher risk of getting code and comment out of sync. But that context switch between code and comments you need when you read this one return are pretty awful.
Right, and do you spend so much of your time doing that your net LoC is negative? If that's the case it implies people are writing code only for other programmers to clean it up. Programmers solving a problem created by programmers. That's dysfunctional. Effective engineering as I see it would be putting the processes in place to prevent having to constantly rewrite code.
> 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.
> 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.
Huh? If LoC weren't needed then adding them was unnecessary and a waste of time. Someone who is known at an organization for removing unnecessary code screams inefficiency to me. It's paying one person to create a mess then another to clean it up.
> Huh? If they weren't needed then adding them was unnecessary and a waste of time.
My previous reply already addressed this?
I can't help but think you are being purposefully obtuse if you can't acknowledge the concept of developers creating known (and hopefully temporary) technical debt due to various forms of deadline related time pressure or changing requirements.
Maybe it was temporarily needed, but the assumptions around it has changed and now it's unneeded. Then people built on top of that not understanding that they could simplify the whole system, and only later was that option discovered.
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.
I definitely agree with the GP, and the point is that most often someone else (or an LLM) added all those LOC that are removed to make the system sensible.
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.
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.
1. add tools to be able to do the job
2. work through the process using the agent interactively many times
3. have an llm read back through the session histories to create the full agent definition
4. run it and review
works fairly well, and does use llms for most of the steps
> 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?
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.
Saying "no" as in "this makes no sense" is not the same as "give it to another team". The first can be an engineering take while the second is just politics.
"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.
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.
> the fallout from this phase of the industry is going to be an exotic form of technical debt
This is a common sentiment and possibly motivated by the belief that writing "clean" code was right all along. Even odds that an AI 2 major model versions smarter will be able to eliminate that debt or rewrite from specs derived from the codebase.
I think it depends a little on how and where you work. In the energy industry of Europe where we are extremely regulated AI has been writing some excellent and maintainable code. Of course we can't do any of that CLEAN SOLID DRY stuff, or any abstraction and implicity really, and I imagine that AI would struggle with that. Though you have to wonder if any of those religions ever really worked when you consider that they've still failed to replace most COBOL systems 30 years later. Anyway, that's a different discussion and even Uncle Bob has moved on to functional programming.
I've yet to have Opus 4.8 fail me with defensive explict code. Often it'll write code that is better than what I might have done. I imagine it would be a nightmare to go through one of the OOP debug chains with implict error handling, but when every function has a runtime assertion which is basically the contract for how it is supposed to work and exactly what to do if it encounters a corrupt state, then things are just so much easier with AI.
I do agree with you on documentation. The amount we have has exploded in the post AI world. Which is a little ironic since the assertion is frankly what you'll need to know and not the 10 pages of prose the AI autogenerated in the shared loop (microsoft's terrible confluence). It is what it is though, and at least it's easier to meet EU compliance rules now, since those are more about the bureaucracy than actual security.
>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.
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.
>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.
I've been thinking about the manga Blame! a lot recently, where the entire story takes place in a run away machine built mega structure that is larger than at least the solar system.
>This is mostly due to incredible pressure from the C-level for every engineer to be using as much AI as possible
I think this is an important point. Software engineers always had the right instincts on how to approach AI for coding -- cautiously. Execs got too coked up on LinkedIn puff pieces from nobodies and adver-prophesizing CEOs selling their tokens and chips that they forced something unnatural upon their orgs.
Now what we see in the software dev space is incredible levels of malicious compliance ("you want slop, I'll give you slop").
I don’t know. I mean, I agree with you overall, but it seems like tons of engineers, especially here on HN, have been more than willing to go all-in on AI for at least the past year, with many dire warnings of “coding is a solved problem,” “if you’re not programming swarms of agents, you’re going to be left behind,” and so on.
This has not been my experience with my fellow engineers IRL on average, but I do feel like there is a significant contingent of us who are ready and raring to yield engineering in its entirety to the LLMs.
A lot of people who write code aren't professional SWEs. A lot of professional SWEs especially on Blind aren't typical SWEs at typical companies. A lot of people who claim to write code are lying. I mean would you take Gary Tan as a valid datapoint for how effective AI is at professional SWE coding? I wouldn't. But these are the kind of people who shill it the most on HN.
Also, I suspect that a lot of HN comments that generally state that AI has been useful for their work are actually not referring to programming work, but it's very easy to default interpret it that way. For example, I just recently saw a comment stating how AI can do 90% of their senior-level job, and when I looked into the guy's profile, he was actually a designer, which makes sense. But on first read I assumed the comment was referring to writing code.
There's also a lot of people whose jobs involve sitting in 3 hours meeting to decide where to add another textbox to the website, and that will then create a ticket to create the textbox, have a meeting to estimate the creation of the textbox, have several meetings with the design team about the placement and size of the textbox.
Some teams are incredibly inefficient. And in the end the AI is perfectly capable of creating the textbox.
Eh, are you using the loop engineering effectively? Remember, Boris can merge more than 200 PRs a week mostly with merely a phone and despite his busy schedule. Anthropic engineers do not write code manually any more, and they don't need to review most of the code either.
In all seriousness, though, I'm indeed curious about Anthropic's engineering practice, particular how they can achieve such level of autonomy.
This game-theory phase seems to go hand-in-hand with totally myopic grift/gig/hustle thinking too. There is no product but the confidence act needed to win each moment.
Chalk up yet another echo of the 1920s Gilded Age? Between all these economic spasms and the simultaneous tilting towards fascism, I think there is way too much historical rhyming going on right now...
So, in other words, all the "awesome engineers" can't really tell good code from bad unless it's really obvious? Why should we listen to you about AI code being crap, then? Maybe, in the end, you don't really know. Maybe AI is better at it than you?
No. Your AI tool that summarized the comment did you dirty. The key here was this:
> perfect formatting and at least superficial plausibility
Basically, a library full of books that have nice covers is going to take time to see that all those books are just filled with ipsum lorem. Before, they coudln't stand up a fake library.
> 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!
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.
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."
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.
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.
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.
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.
> 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.
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.
You might say in the same way that machine code stopped mattering when programming languages gained in popularity. Almost nobody will ever review machine code. I anticipate 90% of all programmers today wouldn't even know how. The move again is towards a higher level of abstraction; this time validation. Instead of describing how the program is to function, you define the properties of the system and let the fancy compiler figure out what the code should look like. If that means something that a human would call spaghetti, oh well.
I can be 99.99999999% certain when I write an if statement like "if (x > 1) do y" that the compiler will turn that into the equivalent machine code. So, yes, unless I hit some crazy performance bottleneck, I'm not concerned about reviewing the machine code.
However, LLM outputs change with slight re-wording of prompts and with each new model release. I could hand write a test that says if x > 1 make sure y happens, but then what productivity was gained?
Just like you can be 99.99999999% certain that your properties will eventually be satisfied when the fancy compiler turns it into equivalent code.
If your program is truly nothing more than that "if" statement then there is unlikely to be any productivity gain, just as there is no real productivity gain using a programming language over flipping toggle switches for something so simple. Programming languages would have never been invented if that bit of logic summed up the entirety of computer science. In the real world, the calculus starts to change when you are trying to solve bigger problems. A lot of solutions require way more code to implement than to describe the necessary properties of. That is where you can gain some huge productivity gains by being able to focus on declaring the properties over having to define the full implementation.
But, again, it is not a panacea. No such thing exists. Every abstraction brings its own set of tradeoffs. Your job is to find the tradeoffs you can accept for your unique circumstances. What others are doing is irrelevant to your situation, but it remains that others are doing things and it can be fun to learn about it.
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.
In terms of knowledge sharing and gathering hard-won human context I agree, sort of. An LM review can at least prompt some reasonable changes, catch performance issues, etc.
"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....
I do wonder what all this means for offshore development. What's the point of sending the work to another continent with different time zones and languages when your AI can do the same job directly.
Offshoring and contracting bulk work out is decreasing.
AI can give you 80-90% of the quality, but the feedback loop is hours or days, not weeks.
This means the inevitable iteration of "no make that a bit greener, move that there, that is the wrong style for this scene" can be done faster, which means cheaper.
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.
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.
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.
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.
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?
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:
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.
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 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.
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.
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.
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).
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.
That still so much assumes a "waterfall" ideal world where specs can be captured up front perfectly and coding is just an inevitable artifact of that with no creative input/feedback into the spec.
At least in my experience, that ideal has never existed. "Engineering" (and "re-engineering" and "re-re-engineering" in the agile worlds) was always what I was spending the majority of my time on. Coding was a medium for the engineering. By the time I finished the engineering the code was either already finished, being discovered in the written code and then documented, or the code was "the fun part" reward for all the hard engineering work that lead to it (and all the ugly specs documents it took to get there).
I agree that documentation should be made higher priority than "coding", but letting AI code everything is throwing the baby out with the bathwater.
It's from this perspective that a lot of engineers feel strong negative sentiment towards AI.
There are always going to be some critical sections of code that one must consider carefully. These tend to be at the extreme ends of choice. Either there's only one way to do it and it probably sucks, or there are many ways to do it and staying optimal is very slippery for maintainers. Identifying and describing these critical sections is also the most important part of the documentation. This is precisely where LLMs fail to do a good job and where people curse the original devs for not writing docs.
But as well, the overall architecture is just as important. The code for this tends to look like the "boring" boilerplate. This is the skeleton of the codebase and LLMs can be bad at this too, haphazardly jamming together design patterns that clash. We're in luck that, usually, a framework or library will provide this code along with documentation to be copypasted verbatim. The rub is when the developers are having to shoehorn it onto existing code they will have to carefully craft some custom interfaces and document them very well.
So in the end, what's left for the LLM to do? When it does a good job, it's usually cribbing so heavily from existing solutions by humans you could have copied it yourself if you knew where it got it from. The LLM is automating copypasta, not deliberate coding. When it's bad, it's making a mess only suitable for a rough proof of concept, if it even works.
From the perspective of a diligent engineer trying to avoid technical debt and other incidents down the road, burning an extra couple of days to get it done right by hand isn't that big of a deal. LLMs become about as useful as a google search. Assuming one does not work at a coding sweatshop, why not just use the google AI summary 90% of the time? The agentic workflow doesn't look promising for a significant chunk of experienced engineers working on maintenance more often than new projects.
> When it does a good job, it's usually cribbing so heavily from existing solutions by humans you could have copied it yourself if you knew where it got it from. The LLM is automating copypasta, not deliberate coding
I've been saying this a lot lately. I agree completely. Most of the impressive stuff I see people talking about AI, they could have just copied and pasted from open source repos in the past
I think that was sort of a taboo in the past though, for several reasons. First off, most teams I've worked on were reluctant to take on the additional maintenance of unvetted open source code if there were other options. For some reason this reluctance has flown completely out the window with AI, even though the cost of code maintenance hasn't really decreased.
Secondly, there was always the question of code licenses when copying from an open source repo. Companies were reluctant to risk anything that could be viewed as code theft
Now the code theft part is solved by training LLMs instead of just copying and pasting, which just feels like theft with extra steps to me
> From the perspective of a diligent engineer trying to avoid technical debt and other incidents down the road, burning an extra couple of days to get it done right by hand isn't that big of a deal. LLMs become about as useful as a google search. Assuming one does not work at a coding sweatshop, why not just use the google AI summary 90% of the time?
If there's one thing that seems unclear from AI proponents, that is the number of technology they're using at the same time. After months or so on a project there should be enough that should be in longterm memory or resources that are part of your browser history that things that require deep research should be a small part of each ticket. And it would be important enough to get it right.
"Asking the lead engineer" doesn't scale though. Writing shit down does.
So if your whole process is "just ask the lead eng" and you keep hiring new people, everyone keeps asking the lead and the lead quits beause nobody wants to do that.
If you write shit down, the new hires can ask your company internal AI system that has access to all of the docs and get the answer - with direct links to official decision documents telling the "why".
At the very least the lead engineer should write the answers down every time they're asked something and reply with RTFM after that =)
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'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.)
> 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?
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.
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.
> 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.
> 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.
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?
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.
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".
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.
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.
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?
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.
It’s pretty common for me to deliver a feature while removing more lines than I added in React. Just so many useless useEffects and states and divs. The caveat is I have to be allowed to refactor related code.
I find it’s less common for me in ruby, even refactoring bad ruby. Sure I can remove lines but bad JS/React balloons so fast.
My current org values this and my direct boss constantly praises those of us that try to remove more lines than we add. Very refreshing.
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.
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.
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.
Also I disagree with:
Lines of code are not the ideal artifact to review
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.
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.
> 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.
> 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.
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.
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?
> 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.
"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.
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
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!”)
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.
> 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?
I have a doubt that one of Three Virtues of a Programmer, laziness is still considered a virtue on AI coding era.
Now that AI coding speed and performance outperformed most of human. But AI still need human to be commanded. Yes, you can let AI agent manage sub-agents but still, human is at the top of manager who order AI what should be written.
So human must command and final say on when it's done.
As defined by Larry Wall: "Laziness: The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful and document what you wrote so you don't have to answer so many questions about it."
That is still an enormous virtue in the AI era. It is completely the opposite of what many AI-using programmers are doing, which is being lazy in the conventional sense, minimizing their individual energy expenditure at the price of increasing the overall energy expenditure.
Being big-picture lazy is a virtue. Being individually lazy is a vice.
> It was reasonable to be skeptical the first time
It's still reasonable to be skeptical. A few weeks ago a post was discussed here on HN [1] that asked:
> What would have to be true for us to ‘check English into the repository’ instead of code?
to which I replied:
> Code is already the cheapest path to working, correct software. LLMs do not change the calculus because figuring out what to make is the expensive part, not coding it up. Skipping code makes the specification of what to make even more expensive and throws away the tools that keep precision affordable. Programming in English would be more expensive than just using a programming language. [2]
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.
I liked the article overall but found it a little wishy-washy in some of the conclusions.
> People do not want to wake up every day and log in to Slack and find the buttons and menus all subtly moved around. People do not want financial transactions that complete most of the time. Determinism is not going anywhere, my friends.
Well, I can't reconcile people not wanting things moving around and determinism with the promises of acceleration made by AI. The way I see it either AI makes "massive, discontinuous returns on investment" by way of changing things or we get a sustainable rate of change; these seem like contradicting goals to me.
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.
I fully agree with the „AI demands more engineering discipline“ premise.
And I‘ve quickly realized that it’s also much easier to follow that premise.
Not only because agents obviously help with writing documentation, test cases, DX tools, and so on.
But also because it feels so much more rewarding to know that someone — even if it’s just a soulless agent — actually cares to read and use and follow these.
I have always been the guy on the team who would write the tools and documentation, and it’s always been a bit frustrating to know that only half the team would care to read and use and follow them, at best.
AI pushes this premise beyond infrastructure and into application code itself. When rewriting is cheap, editing in place becomes risky. Mutation accumulates entropy. Replacement resets it."
I've always found verifying some code works correctly much harder and time consuming than writing code. Replacing big chunks code means much _more_ verification and validation.
When you see a bug, and you "fix the running thing" you only need to verify what you changed.
This is the major part of her argument I didn't understand.
As I see it, the "infra as code" transition means going from more ad-hoc changes to less. Predictable, auditable.
Using LLMs to replace mostly-working code with a new, nondeterministically different version seems entirely different to me. You've identified a problem in the code, great, let's rewrite it from spec. Now it fixed the problem! But did it introduce more problems? Hope you used enough tokens, I guess!
> A few days back I wrote a piece called “AI enthusiasts are in a race against time, AI skeptics are in a race against entropy.”
Guess who the author is.
> > The enthusiasts are not wrong. We are starting to see real, non-imaginary, discontinuous leaps in capabilities from teams that lean in hard to working with AI. And this does not feel like a normal technology cycle where you can wait for the dust to settle; teams that sit this out while competitors are hustling could be out of business before the dust settles. That’s a real, existential threat.
It’s not imaginary. It’s real. This time it’s different. And on a higher level, the FOMO is real. It’s not imaginary. It’s even existential.
Why do they all write the same as well? It’s so emphatic.
> The tech is cool, but as a thinking, feeling, breathing human who cares about other people, it can be hard to get excited about anything that so many people are this upset about. It’s also hard to get excited about something when so many of the loudest voices are out there talking gleefully about putting everyone permanently out of work, and so many artists and writers and people from developing nations are talking openly about the impact on them.
> Hold your desire to jump in and berate me here, I beg you. Like I said, I will deal with the ethics and morality of using AI in my very next post. Be honest, your attention span is no more up for reading a 10,000-word essay than mine is up for writing one. (Can we blame AI for that too?)
More Inevitability Soothsaying. All our feelings are crashing with Existentinal Threat Reality.
This has been my position from the beginning of when agentic coding harnesses became genuinely useful.
I now do documentation driven development, and with very few exceptions I am committing code that is better written, better documented, easier to reason about and maintain, with less library overuse than I ever did as a senior lead with a smal team, and I’m doing it for 1/4 the price, at 4x the speed.
But it’s not vibe coding. Discipline is critical, as is deep systems understanding.
>"It’s easy to forget, but for most of 2025, the idea that AI-generated code was slop and might always be slop was not only a reasonable position to hold, it was the default, mainstream position.
That question was answered decisively last November."
It's easy to forget that people said this exact thing about every model after GPT 3.5. This is a standard trick the industry uses to invalidate negative experience with LLMs. 'You are prompting it wrong' becomes 'you are using Gemini, but you should use Clade' which then becomes 'well, all of your criticism is now irrelevant, because everything is fixed in this new version'.
This "discussion" about capabilities is set up to be asymmetrical and basically non-falsifiable.
You undermine your own point when you misrepresent the situation like this. Real human mathematicians, including at least one Fields Medal winner, have validated and complimented the result.
You interpretation of my comment is either very biased or just made in bad faith.
The claim made by Open AI has two necessary components. The first one is that the conjecture had been disproven. (This is what had been verified by "real human mathematicians".) The second necessary part of their claim is that the work to disprove the conjecture was done mostly by their AI model rather than by people employed by Open AI.
Funny thing is that even the explainer on OpenAI's own website points out the issue:
"This result does not show us all the times AI has claimed to have a proof of something and been wrong."
"I believe if the level and type of human expertise that is represented on this note had been assembled to find a counterexample to this conjecture a month ago, and those people put in similar amounts of time working on it than they did to reading and thinking about Chat GPT’s solution, the mathematicians would have found a counterexample."
You seem to be saying model capabilities aren't improving. They are. The fact that many mathematicians have looked at the result and confirmed it and solved some other problems with the technique elevates this above claims.
i mean i am very much still waiting for it to not be slop, but fable actually i think made a bit of headway in this direction, the code it writes what little of it i saw, makes me want to fall over dead slightly less than other models.
Given how many critical systems software touches these days, I am surprised that there they are not licensed. Imagine if civil engineers can just go building shit as minimum viable products? Sure prototype quickly but someone should be found liable for final product.
lmao excellent reference! While this is poking fun at the block chain hype a bit, a shocking amount of (good) software engs don't know good security practices. I'd be interested to hear arguments for and against being licensed to write software for particular applications (e.g J.Doe can work on this application but any auth code has to be signed off by someone licensed). AI tools are great but screwing up an implementation (for a well thought out spec) does happen, esp. in security applications and someone needs to be liable for life-ruining data breaches.
In general most developers are going to find themselves fighting incentives which will color their opinion. AI isn't there yet but if you are going to abase your whole world view on a point on a graph and not on the trajectory you are in for a bad time.
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
What worries me personally is the dopamine hit I seem to get from watching my ideas get built in front of me. There is a big temptation to just add feature after feature without really checking what the code actually looks like. So yes, more discipline is needed.
Chatbots enable unskilled developers to go in way out of their depth with little resistance. This creates problems of a new nature, not just more problems of the same nature as before.
Previously in my career, a junior making a mistake and being told why it was a mistake would learn from that and improve. The junior-chatbot duo will not. The junior will feed my comment into the chatbot, and the chatbot will superficially give the impression of having learned from the mistake and fix the code while introducing the same problem somewhere else, and the junior will have learned nothing.
This all requires that I review code as though it was created by some kind of cursed monkey's paw with an endless number of fingers that each grants a wish of the operator with a devastating caveat through idiotic interpretation.
If you give a toddler who can otherwise not operate a chainsaw -- for the simple reason that they don't have the strength to start it using the starter rope -- access to a robot who will turn on the chainsaw for them on command, you've created a problem which didn't exist before.
I understand that unskilled people are creating problems for themselves and others; but that doesn't interest me. I interpret everything from the point of view of the AI being used by skilled people.
Such as the claim "AI demands more engineering discipline, not less" ... of skilled people, not irrelevant unskilled people.
Unskilled people are not irrelevant if you intend on working with other people, in which case you will need to deal with them in one way or another.
I will probably be dealing with them in the future more than in the past because chatbots bypass the process by which unskilled people generally become skilled people.
the ur-text behind this piece is: people just not understanding exponential capability growth. including the author of the piece!
if you could look clearly at the progress from 2020 to 2023, as someone like Gwern did, and from 2023 to 2024 with the invention of reasoning modes, then it was not that hard to understand what would happen in late 2025. Opus 4.5 was not a surprise to anyone who was actually paying attention.
But people (including the author) still mistake the current state as a stable state and future gains as incremental. he says
“I am not asserting that all code will eventually be AI-generated to spec, bypassing human understanding”
I AM asserting that, and it’s incredibly easy to do so.
There's one thing that hasn't changed much with LLMs, and that's the notion of 'moving the needle'. People who sling slop don't meaningfully accomplish that if you're paying close attention to how your team or org or company actually needs to move. Although, if your team is focused on PRs and LOC, sure, the needle is popped off the gauge by LLMs. But your problem is not LLMs in that case.
I agree that AI demands more engineering discipline, but it also demands more domain knowledge, purpose, and intent. Suddenly we can actually accomplish most of our goals a little faster. I can take on work I couldn't before.
Before I even begin getting disciplined about engineering, I need to ask: does this work actually make sense? Should I do it? If it's done... What do I think will change for my team or organization? Will it have practical results that move us in the right direction?
The better you get at asking that question, the less you'll find yourself prompting and planning and shoving PRs into the chute. It's still somewhat difficult to find important work in many places.
Still, engineering discipline is and always has been critical when going ahead with important work.
My gut feeling is that many of us simply aren't doing important work, and the discipline might be nice but is ultimately irrelevant. The sloppers are doing a faster version of something they always have, and much of it will be lost to time just like our pre-slop work has been.
I find LLMs aren't as helpful when applied to well-thought and intentional work towards very specific goals in complex domains. They're still helpful, but, the deeper you go and the more specific you get, the more they tend to deliver results you can't use. If you're on the rails they can be incredible. Diverging from the track and having exacting requirements, eh, it gets pretty hit or miss and you can spend a lot of time herding a digital cat. This certainly demands a lot more engineering discipline.
Writing software begins with a solid design that is defensible. If you don't have that, the AI will produce slop.
Once you're happy with the design, you need a solid plan. If you don't have that, the AI will produce slop.
Once you're happy with the plan, you can set the AI loose, but don't get too complacent! Anything that you missed in the previous phases could very well lead to slop (although likely localized).
And then then, as your project matures and you gain more understanding of the space, you start to notice deficiencies in your model. This is where AI really shines: design and code changes to adapt to reality.
This is why I built https://saasufy.com/ - Vibe coders shouldn't trust themselves with backend security. Unfortunately, it's extremely difficult to get right. There's a lot to think about;
- Schema validation with appropriate size limits on all relevant fields.
- Authentication.
- Access control.
- Backpressure management and rate limiting in case a (possibly malicious) user tries to perform too many computationally expensive actions in a short time.
- Ensuring that the actions of one user doesn't throttle another user which is connected to the same process/host, e.g. using async constructs to avoid freezing the main process.
- DDoS mitigation.
- Avoiding race conditions.
- Designing a good database schema, with well chosen indexes, with deterministic IDs/idempotency to avoid double-insertion scenarios. You don't want to be forced to rely on overly complex queries with a lot of joins. This doesn't scale well and rarely necessary.
- Logging and error handling.
- Avoiding conflicts and accidental overwrite with old data when multiple users are editing different fields of the same resource concurrently.
- Efficient distribution of realtime messages.
- Scalability.
The list goes on and on... And every piece has to be implemented perfectly. This involves a huge number of carefully thought-out decisions.
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.
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.
"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.
Good revision!
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.
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.
They could just use AI to communicate. Why they they still on meetings?
"High performers". Can't believe we have normalized this vocabulary, among us, "hackers".
Most of us work for business and on teams where performance matters.
> Most of us work for business and on teams where performance matters.
It truly does:
performance – the action of entertaining other people by dancing, singing, acting, or peformative coding
The problem is, that shouldn't matter. If you work somewhere it does, well, you probably have to. But that's OK, it doesn't stop you from working to uplift the goal and conversation and deliverables, through these other definitions of performance:
performance – how well a person, machine, etc. does an activity
Now we get into how to define well, but activity, looking busy, may not be as valuable as outcomes.
performance – how well a person, machine, etc. does a piece of work
This is getting close, but here we need to define the nature of work, the qualia of work. It's not how well someone codes a line of code, or how well someone programs a piece of software. It's not even how well the engineer a solution.
What matters is return on equity, meaning: how well does what is delivered enable the business to turn capital investment in bringing ideas into being, into returns on that capital.
For good measure (pun intended), track long term, so resilience, maintainability, and evolvability, and really any ongoing costs, including delay costs, opportunity costs, or cash flow costs, are part of the definition of how well.
That matters.
Note this can be shorthanded to both GPT and Claude, and will change the machines’ suggestions.
Dunno about you but I work for a "business" (large company, you've heard of it) and the concept of "High Performer" is synonymous with "best politician". Sure, a lot of theater goes into things, especially dances around "data points", but at the end of the day the top tier goes to the fortunate sons.
You should not treat it as fact that "performance" of an individual, not a team is a thing that actually exists in any way that matters and is measurable.
I do treat it as a fact. Why shouldn’t I? Varying performance among my coworkers is obvious and blatant.
I’m not sure that there is a consistent definition for matters in this context. What matters is completely subjective to an individual. Furthermore, performance is rarely correlated with success and compensation in an enterprise. I could just as easily say that playing the game is what matters.
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.
in fact, i've sent over 20 variable rename prs and am now topping the leaderboard!
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
• LoC/LOC = Lines of Code
• sloc = Source Lines of Code
.. so I suppose nloc would mean Net LoC
[dead]
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.
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).
Every line of code is a liability. A potential security breach. An error waiting to corrupt customer data. A maintenance burden.
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.
Rewriting code to be more compact is orthogonal to productivity.
In a similar way to how a radial burn (https://space.stackexchange.com/questions/44608/what-happens...) may be orthogonal to your trajectory but still may be necessary to avoid becoming a fireball in half an orbit's time.
How so? Let's say that over a year, a given section of code needs to be read and understood once a month. Taking some time to keep the code succinct and free of distraction will increase productivity all those occasions, as well as the rest of the lifetime of the system. Say the next decade.
How is that not efficient?
Which is not what is being discussed. Often rewriting code to make it more understandable makes everybody more productive.
Simplification usually requires the most effort and results in simple and elegant systems easy to understand and maintain with reduced error surface.
So overall increases productivity by a lot
you have evidently been blessed to work only in places with acceptable level of quality code and above.
Or he's the one bringing down quality and productivity.
non-coding manager spotted
> 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
to and contributed various other negative lines of code in multiple areas.Every line of code removed is a line that was previously added.
Do you have any experience coding before LLMs?
Written exactly like that, yours is obviously cleaner.
But, if that original code had comments and traceability of each condition and return to a specific domain scenario, you would be doing a disservice by collapsing it to the one flat boolean expression. In that case, it may be better in its expanded form, and you should let an optimizing compiler do the collapsing.
There were no comments.
If there were comments for each conditional, it should still be refactored as
Many years ago, "lines of code" was the classic example of nonsense management metrics. Today, there are somehow HN users who argue that lines of code is indeed a good metric and ask "But what if the code had comments?" as if they have never seen comments interleaved with code.> In that case, it may be better in its expanded form, and you should let an optimizing compiler do the collapsing.
This is nonsense. This optimization is not about compiler optimization for efficiency. It's an optimization for human readability and maintainability.
FWIW, I'm no advocate of "lines of code", or really any KPIs at all. All I'm saying is context matters.
Such branches could make sense if the conditions have to do with underlying domain concepts, but you expect the outcomes to be revised. It could just be a moment-in-time accident that they are all returning True right now.
This kind of tension is also where you often see indirection via configuration files or other auxiliary data structures. Or in the old days, things like bit fields instead of booleans, so that merging the conditions would encode different small integers to use as lookup table indices.
That's still going to make it hard to read. I'd have one big comment above talking about the different cases and then one line of code. Even with the slightly higher risk of getting code and comment out of sync. But that context switch between code and comments you need when you read this one return are pretty awful.
Right, and do you spend so much of your time doing that your net LoC is negative? If that's the case it implies people are writing code only for other programmers to clean it up. Programmers solving a problem created by programmers. That's dysfunctional. Effective engineering as I see it would be putting the processes in place to prevent having to constantly rewrite code.
> 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.
> 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.
Huh? If LoC weren't needed then adding them was unnecessary and a waste of time. Someone who is known at an organization for removing unnecessary code screams inefficiency to me. It's paying one person to create a mess then another to clean it up.
> Huh? If they weren't needed then adding them was unnecessary and a waste of time.
My previous reply already addressed this?
I can't help but think you are being purposefully obtuse if you can't acknowledge the concept of developers creating known (and hopefully temporary) technical debt due to various forms of deadline related time pressure or changing requirements.
Old guard status games be like
> 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.
It’s not a failure that resources were spent writing code that was not needed?
Maybe it was temporarily needed, but the assumptions around it has changed and now it's unneeded. Then people built on top of that not understanding that they could simplify the whole system, and only later was that option discovered.
What would you keep from this?
It's only a failure if perfect information was available at the time, an impossibility for most people.
Write one (system) to throw away...
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.
I definitely agree with the GP, and the point is that most often someone else (or an LLM) added all those LOC that are removed to make the system sensible.
… by some fool who didn’t know what they were doing, since evidently the same behavior could be done with less.
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.
Numbers feels like outliers.
Not everybody is good at their job, or requirements changed over time.
Deleted code is debugged code.
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.
a process of
1. add tools to be able to do the job 2. work through the process using the agent interactively many times 3. have an llm read back through the session histories to create the full agent definition 4. run it and review
works fairly well, and does use llms for most of the steps
> 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?
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.
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.
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.
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.
Saying "no" as in "this makes no sense" is not the same as "give it to another team". The first can be an engineering take while the second is just politics.
"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.
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.
How is it clear though? It can be really hard to tell.
Surely the harder it is to tell the less of a problem the whole thing is.
> the fallout from this phase of the industry is going to be an exotic form of technical debt
This is a common sentiment and possibly motivated by the belief that writing "clean" code was right all along. Even odds that an AI 2 major model versions smarter will be able to eliminate that debt or rewrite from specs derived from the codebase.
I think it depends a little on how and where you work. In the energy industry of Europe where we are extremely regulated AI has been writing some excellent and maintainable code. Of course we can't do any of that CLEAN SOLID DRY stuff, or any abstraction and implicity really, and I imagine that AI would struggle with that. Though you have to wonder if any of those religions ever really worked when you consider that they've still failed to replace most COBOL systems 30 years later. Anyway, that's a different discussion and even Uncle Bob has moved on to functional programming.
I've yet to have Opus 4.8 fail me with defensive explict code. Often it'll write code that is better than what I might have done. I imagine it would be a nightmare to go through one of the OOP debug chains with implict error handling, but when every function has a runtime assertion which is basically the contract for how it is supposed to work and exactly what to do if it encounters a corrupt state, then things are just so much easier with AI.
I do agree with you on documentation. The amount we have has exploded in the post AI world. Which is a little ironic since the assertion is frankly what you'll need to know and not the 10 pages of prose the AI autogenerated in the shared loop (microsoft's terrible confluence). It is what it is though, and at least it's easier to meet EU compliance rules now, since those are more about the bureaucracy than actual security.
>at least it's easier to meet EU compliance rules now
Until the bureaucrats start using AI to create a flood of new rules.
>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.
> 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.
[flagged]
>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.
I've been thinking about the manga Blame! a lot recently, where the entire story takes place in a run away machine built mega structure that is larger than at least the solar system.
>This is mostly due to incredible pressure from the C-level for every engineer to be using as much AI as possible
I think this is an important point. Software engineers always had the right instincts on how to approach AI for coding -- cautiously. Execs got too coked up on LinkedIn puff pieces from nobodies and adver-prophesizing CEOs selling their tokens and chips that they forced something unnatural upon their orgs.
Now what we see in the software dev space is incredible levels of malicious compliance ("you want slop, I'll give you slop").
I don’t know. I mean, I agree with you overall, but it seems like tons of engineers, especially here on HN, have been more than willing to go all-in on AI for at least the past year, with many dire warnings of “coding is a solved problem,” “if you’re not programming swarms of agents, you’re going to be left behind,” and so on.
This has not been my experience with my fellow engineers IRL on average, but I do feel like there is a significant contingent of us who are ready and raring to yield engineering in its entirety to the LLMs.
A lot of people who write code aren't professional SWEs. A lot of professional SWEs especially on Blind aren't typical SWEs at typical companies. A lot of people who claim to write code are lying. I mean would you take Gary Tan as a valid datapoint for how effective AI is at professional SWE coding? I wouldn't. But these are the kind of people who shill it the most on HN.
Also, I suspect that a lot of HN comments that generally state that AI has been useful for their work are actually not referring to programming work, but it's very easy to default interpret it that way. For example, I just recently saw a comment stating how AI can do 90% of their senior-level job, and when I looked into the guy's profile, he was actually a designer, which makes sense. But on first read I assumed the comment was referring to writing code.
There's also a lot of people whose jobs involve sitting in 3 hours meeting to decide where to add another textbox to the website, and that will then create a ticket to create the textbox, have a meeting to estimate the creation of the textbox, have several meetings with the design team about the placement and size of the textbox.
Some teams are incredibly inefficient. And in the end the AI is perfectly capable of creating the textbox.
You'll recognise the good engineers as the ones that remove code.
I bet code removal is _not_ something that goes into LLM training sets much, unfortunately
Eh, are you using the loop engineering effectively? Remember, Boris can merge more than 200 PRs a week mostly with merely a phone and despite his busy schedule. Anthropic engineers do not write code manually any more, and they don't need to review most of the code either.
In all seriousness, though, I'm indeed curious about Anthropic's engineering practice, particular how they can achieve such level of autonomy.
Remember Facebook's original motto: Go fast and break things. That's where the speed is coming from.
Anthropic's speed of development is about 20% AI and 80% technical debt. We all could be faster if we stopped trying to build things right.
Once Anthropic floats, I predict a screeching halt in feature development to fix all the technical debt that they're accumulating.
AI usage perhaps will have to be monitored by AI.
This game-theory phase seems to go hand-in-hand with totally myopic grift/gig/hustle thinking too. There is no product but the confidence act needed to win each moment.
Chalk up yet another echo of the 1920s Gilded Age? Between all these economic spasms and the simultaneous tilting towards fascism, I think there is way too much historical rhyming going on right now...
So, in other words, all the "awesome engineers" can't really tell good code from bad unless it's really obvious? Why should we listen to you about AI code being crap, then? Maybe, in the end, you don't really know. Maybe AI is better at it than you?
No. Your AI tool that summarized the comment did you dirty. The key here was this:
> perfect formatting and at least superficial plausibility
Basically, a library full of books that have nice covers is going to take time to see that all those books are just filled with ipsum lorem. Before, they coudln't stand up a fake library.
The issue comes down to time and effort.
> Basically, a library full of books that have nice covers is going to take time to see that all those books are just filled with ipsum lorem
Worse if it’s a mixture of good content and ipsum lorem.
[dead]
> 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!
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.
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/
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.
I hope 99% of that was documentation and testing.
[dead]
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.
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
[dead]
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.
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.
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.
> 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.
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.
> 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.
How can the code no longer matter? It literally is the logic (not to mention performance, and reliability) of the software.
You might say in the same way that machine code stopped mattering when programming languages gained in popularity. Almost nobody will ever review machine code. I anticipate 90% of all programmers today wouldn't even know how. The move again is towards a higher level of abstraction; this time validation. Instead of describing how the program is to function, you define the properties of the system and let the fancy compiler figure out what the code should look like. If that means something that a human would call spaghetti, oh well.
I can be 99.99999999% certain when I write an if statement like "if (x > 1) do y" that the compiler will turn that into the equivalent machine code. So, yes, unless I hit some crazy performance bottleneck, I'm not concerned about reviewing the machine code.
However, LLM outputs change with slight re-wording of prompts and with each new model release. I could hand write a test that says if x > 1 make sure y happens, but then what productivity was gained?
Just like you can be 99.99999999% certain that your properties will eventually be satisfied when the fancy compiler turns it into equivalent code.
If your program is truly nothing more than that "if" statement then there is unlikely to be any productivity gain, just as there is no real productivity gain using a programming language over flipping toggle switches for something so simple. Programming languages would have never been invented if that bit of logic summed up the entirety of computer science. In the real world, the calculus starts to change when you are trying to solve bigger problems. A lot of solutions require way more code to implement than to describe the necessary properties of. That is where you can gain some huge productivity gains by being able to focus on declaring the properties over having to define the full implementation.
But, again, it is not a panacea. No such thing exists. Every abstraction brings its own set of tradeoffs. Your job is to find the tradeoffs you can accept for your unique circumstances. What others are doing is irrelevant to your situation, but it remains that others are doing things and it can be fun to learn about it.
You're over-indexing on the (erroneous) idea that my example meant that the program would be a single if statement.
> A lot of solutions require way more code to implement than to describe the necessary properties of.
That's true to an extent, the additional code often define the emergent and undiscovered properties of a system.
> the additional code often define the emergent and undiscovered properties of a system.
That's the cost of abstraction. Everything has tradeoffs.
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.
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.
Theres really no diff between a rubber stamp and an llm review, they both do the same thing.
In terms of knowledge sharing and gathering hard-won human context I agree, sort of. An LM review can at least prompt some reasonable changes, catch performance issues, etc.
"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....
I do wonder what all this means for offshore development. What's the point of sending the work to another continent with different time zones and languages when your AI can do the same job directly.
Offshoring and contracting bulk work out is decreasing.
AI can give you 80-90% of the quality, but the feedback loop is hours or days, not weeks.
This means the inevitable iteration of "no make that a bit greener, move that there, that is the wrong style for this scene" can be done faster, which means cheaper.
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.
I also would like to know more about those pedagogy lessons you're applying.
Would love to chat -- ping me tr at tern dot sh
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.
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.
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.
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?
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.
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/
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.
So many. The sibling comments, plus GitAI, plus empathic, plus many others
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
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.
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.
You guys get tickets that tell you what to do in detail?
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).
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.
That still so much assumes a "waterfall" ideal world where specs can be captured up front perfectly and coding is just an inevitable artifact of that with no creative input/feedback into the spec.
At least in my experience, that ideal has never existed. "Engineering" (and "re-engineering" and "re-re-engineering" in the agile worlds) was always what I was spending the majority of my time on. Coding was a medium for the engineering. By the time I finished the engineering the code was either already finished, being discovered in the written code and then documented, or the code was "the fun part" reward for all the hard engineering work that lead to it (and all the ugly specs documents it took to get there).
I agree that documentation should be made higher priority than "coding", but letting AI code everything is throwing the baby out with the bathwater.
It's from this perspective that a lot of engineers feel strong negative sentiment towards AI.
There are always going to be some critical sections of code that one must consider carefully. These tend to be at the extreme ends of choice. Either there's only one way to do it and it probably sucks, or there are many ways to do it and staying optimal is very slippery for maintainers. Identifying and describing these critical sections is also the most important part of the documentation. This is precisely where LLMs fail to do a good job and where people curse the original devs for not writing docs.
But as well, the overall architecture is just as important. The code for this tends to look like the "boring" boilerplate. This is the skeleton of the codebase and LLMs can be bad at this too, haphazardly jamming together design patterns that clash. We're in luck that, usually, a framework or library will provide this code along with documentation to be copypasted verbatim. The rub is when the developers are having to shoehorn it onto existing code they will have to carefully craft some custom interfaces and document them very well.
So in the end, what's left for the LLM to do? When it does a good job, it's usually cribbing so heavily from existing solutions by humans you could have copied it yourself if you knew where it got it from. The LLM is automating copypasta, not deliberate coding. When it's bad, it's making a mess only suitable for a rough proof of concept, if it even works.
From the perspective of a diligent engineer trying to avoid technical debt and other incidents down the road, burning an extra couple of days to get it done right by hand isn't that big of a deal. LLMs become about as useful as a google search. Assuming one does not work at a coding sweatshop, why not just use the google AI summary 90% of the time? The agentic workflow doesn't look promising for a significant chunk of experienced engineers working on maintenance more often than new projects.
> When it does a good job, it's usually cribbing so heavily from existing solutions by humans you could have copied it yourself if you knew where it got it from. The LLM is automating copypasta, not deliberate coding
I've been saying this a lot lately. I agree completely. Most of the impressive stuff I see people talking about AI, they could have just copied and pasted from open source repos in the past
I think that was sort of a taboo in the past though, for several reasons. First off, most teams I've worked on were reluctant to take on the additional maintenance of unvetted open source code if there were other options. For some reason this reluctance has flown completely out the window with AI, even though the cost of code maintenance hasn't really decreased.
Secondly, there was always the question of code licenses when copying from an open source repo. Companies were reluctant to risk anything that could be viewed as code theft
Now the code theft part is solved by training LLMs instead of just copying and pasting, which just feels like theft with extra steps to me
> From the perspective of a diligent engineer trying to avoid technical debt and other incidents down the road, burning an extra couple of days to get it done right by hand isn't that big of a deal. LLMs become about as useful as a google search. Assuming one does not work at a coding sweatshop, why not just use the google AI summary 90% of the time?
If there's one thing that seems unclear from AI proponents, that is the number of technology they're using at the same time. After months or so on a project there should be enough that should be in longterm memory or resources that are part of your browser history that things that require deep research should be a small part of each ticket. And it would be important enough to get it right.
"Asking the lead engineer" doesn't scale though. Writing shit down does.
So if your whole process is "just ask the lead eng" and you keep hiring new people, everyone keeps asking the lead and the lead quits beause nobody wants to do that.
If you write shit down, the new hires can ask your company internal AI system that has access to all of the docs and get the answer - with direct links to official decision documents telling the "why".
At the very least the lead engineer should write the answers down every time they're asked something and reply with RTFM after that =)
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'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.)
> 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.
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.
> 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.
> 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.
>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.
>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.
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?
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.
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".
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.
Before 2023 I remember everyone here on HN championed that removing lines of code was the strongest senior metric
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.
Removing lines of code without removing functionality.
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!
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?
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.
It’s pretty common for me to deliver a feature while removing more lines than I added in React. Just so many useless useEffects and states and divs. The caveat is I have to be allowed to refactor related code.
I find it’s less common for me in ruby, even refactoring bad ruby. Sure I can remove lines but bad JS/React balloons so fast.
My current org values this and my direct boss constantly praises those of us that try to remove more lines than we add. Very refreshing.
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.
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.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.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.
> 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.
> 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.
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.
My vibe sense tells me AI slop. It's just too much vacuous text in general and "not x, but y."
I enjoyed it, people post on blogs as a way to entertain themselves, not necessarily the reader.
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?
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 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!
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
"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.
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
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!”)
It was also trained on gcc and clang.
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.
> 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?
I have a doubt that one of Three Virtues of a Programmer, laziness is still considered a virtue on AI coding era.
Now that AI coding speed and performance outperformed most of human. But AI still need human to be commanded. Yes, you can let AI agent manage sub-agents but still, human is at the top of manager who order AI what should be written.
So human must command and final say on when it's done.
Is laziness still a good virtue in AI era?
As defined by Larry Wall: "Laziness: The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful and document what you wrote so you don't have to answer so many questions about it."
That is still an enormous virtue in the AI era. It is completely the opposite of what many AI-using programmers are doing, which is being lazy in the conventional sense, minimizing their individual energy expenditure at the price of increasing the overall energy expenditure.
Being big-picture lazy is a virtue. Being individually lazy is a vice.
I'd argue using AI is the epitome of laziness, at least in some sense.
If you buy that, then it follows that the more work you accomplish with AI, the "lazier" of a dev you are.
from the post:
> It was reasonable to be skeptical the first time
It's still reasonable to be skeptical. A few weeks ago a post was discussed here on HN [1] that asked:
> What would have to be true for us to ‘check English into the repository’ instead of code?
to which I replied:
> Code is already the cheapest path to working, correct software. LLMs do not change the calculus because figuring out what to make is the expensive part, not coding it up. Skipping code makes the specification of what to make even more expensive and throws away the tools that keep precision affordable. Programming in English would be more expensive than just using a programming language. [2]
[1] https://annievella.com/posts/finding-comfort-in-the-uncertai...
[2] https://www.slater.dev/2026/05/why-english-will-never-be-a-p...
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.
I liked the article overall but found it a little wishy-washy in some of the conclusions.
> People do not want to wake up every day and log in to Slack and find the buttons and menus all subtly moved around. People do not want financial transactions that complete most of the time. Determinism is not going anywhere, my friends.
Well, I can't reconcile people not wanting things moving around and determinism with the promises of acceleration made by AI. The way I see it either AI makes "massive, discontinuous returns on investment" by way of changing things or we get a sustainable rate of change; these seem like contradicting goals to me.
Plus humans are non-deterministic, so AI replacing humans is not adding more determinism to the development process.
Humans make up for being non-deterministic by being disciplined
AI doesn't have anything resembling discipline
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.
I fully agree with the „AI demands more engineering discipline“ premise.
And I‘ve quickly realized that it’s also much easier to follow that premise.
Not only because agents obviously help with writing documentation, test cases, DX tools, and so on.
But also because it feels so much more rewarding to know that someone — even if it’s just a soulless agent — actually cares to read and use and follow these.
I have always been the guy on the team who would write the tools and documentation, and it’s always been a bit frustrating to know that only half the team would care to read and use and follow them, at best.
Thanks, great to have the perspective of thoughtful engineers who have been in the trenches for a long time
"...never fix a running thing. Replace it.
AI pushes this premise beyond infrastructure and into application code itself. When rewriting is cheap, editing in place becomes risky. Mutation accumulates entropy. Replacement resets it."
I've always found verifying some code works correctly much harder and time consuming than writing code. Replacing big chunks code means much _more_ verification and validation.
When you see a bug, and you "fix the running thing" you only need to verify what you changed.
This is the major part of her argument I didn't understand.
As I see it, the "infra as code" transition means going from more ad-hoc changes to less. Predictable, auditable.
Using LLMs to replace mostly-working code with a new, nondeterministically different version seems entirely different to me. You've identified a problem in the code, great, let's rewrite it from spec. Now it fixed the problem! But did it introduce more problems? Hope you used enough tokens, I guess!
> A few days back I wrote a piece called “AI enthusiasts are in a race against time, AI skeptics are in a race against entropy.”
Guess who the author is.
> > The enthusiasts are not wrong. We are starting to see real, non-imaginary, discontinuous leaps in capabilities from teams that lean in hard to working with AI. And this does not feel like a normal technology cycle where you can wait for the dust to settle; teams that sit this out while competitors are hustling could be out of business before the dust settles. That’s a real, existential threat.
It’s not imaginary. It’s real. This time it’s different. And on a higher level, the FOMO is real. It’s not imaginary. It’s even existential.
Why do they all write the same as well? It’s so emphatic.
> The tech is cool, but as a thinking, feeling, breathing human who cares about other people, it can be hard to get excited about anything that so many people are this upset about. It’s also hard to get excited about something when so many of the loudest voices are out there talking gleefully about putting everyone permanently out of work, and so many artists and writers and people from developing nations are talking openly about the impact on them.
> Hold your desire to jump in and berate me here, I beg you. Like I said, I will deal with the ethics and morality of using AI in my very next post. Be honest, your attention span is no more up for reading a 10,000-word essay than mine is up for writing one. (Can we blame AI for that too?)
More Inevitability Soothsaying. All our feelings are crashing with Existentinal Threat Reality.
This has been my position from the beginning of when agentic coding harnesses became genuinely useful.
I now do documentation driven development, and with very few exceptions I am committing code that is better written, better documented, easier to reason about and maintain, with less library overuse than I ever did as a senior lead with a smal team, and I’m doing it for 1/4 the price, at 4x the speed.
But it’s not vibe coding. Discipline is critical, as is deep systems understanding.
>"It’s easy to forget, but for most of 2025, the idea that AI-generated code was slop and might always be slop was not only a reasonable position to hold, it was the default, mainstream position.
That question was answered decisively last November."
It's easy to forget that people said this exact thing about every model after GPT 3.5. This is a standard trick the industry uses to invalidate negative experience with LLMs. 'You are prompting it wrong' becomes 'you are using Gemini, but you should use Clade' which then becomes 'well, all of your criticism is now irrelevant, because everything is fixed in this new version'.
This "discussion" about capabilities is set up to be asymmetrical and basically non-falsifiable.
The old model couldn't do math, the new one solved a big open problem.
"Open AI claims that its model disproven an Erdős conjecture, therefore my crappy way of arguing about software quality is valid."
I really don't know how I'm supposed to reply to stuff like this.
> Open AI claims
You undermine your own point when you misrepresent the situation like this. Real human mathematicians, including at least one Fields Medal winner, have validated and complimented the result.
You interpretation of my comment is either very biased or just made in bad faith.
The claim made by Open AI has two necessary components. The first one is that the conjecture had been disproven. (This is what had been verified by "real human mathematicians".) The second necessary part of their claim is that the work to disprove the conjecture was done mostly by their AI model rather than by people employed by Open AI.
Funny thing is that even the explainer on OpenAI's own website points out the issue:
"This result does not show us all the times AI has claimed to have a proof of something and been wrong."
"I believe if the level and type of human expertise that is represented on this note had been assembled to find a counterexample to this conjecture a month ago, and those people put in similar amounts of time working on it than they did to reading and thinking about Chat GPT’s solution, the mathematicians would have found a counterexample."
[1] https://cdn.openai.com/pdf/74c24085-19b0-4534-9c90-465b8e29a...
You seem to be saying model capabilities aren't improving. They are. The fact that many mathematicians have looked at the result and confirmed it and solved some other problems with the technique elevates this above claims.
i mean i am very much still waiting for it to not be slop, but fable actually i think made a bit of headway in this direction, the code it writes what little of it i saw, makes me want to fall over dead slightly less than other models.
Given how many critical systems software touches these days, I am surprised that there they are not licensed. Imagine if civil engineers can just go building shit as minimum viable products? Sure prototype quickly but someone should be found liable for final product.
relevant xkcd : https://xkcd.com/2030/
lmao excellent reference! While this is poking fun at the block chain hype a bit, a shocking amount of (good) software engs don't know good security practices. I'd be interested to hear arguments for and against being licensed to write software for particular applications (e.g J.Doe can work on this application but any auth code has to be signed off by someone licensed). AI tools are great but screwing up an implementation (for a well thought out spec) does happen, esp. in security applications and someone needs to be liable for life-ruining data breaches.
If you ask a surgeon if you need surgery...
In general most developers are going to find themselves fighting incentives which will color their opinion. AI isn't there yet but if you are going to abase your whole world view on a point on a graph and not on the trajectory you are in for a bad time.
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
Broadly concur with this and in fact it’s all of this is going to make doing real engineering easier in my opinion
The author makes the wrong assumption though that the majority of people who are doing engineering want to do even more engineering.
It’s my experience that most technology workers just want a high paycheck and have some kind of association with being in tech and doing cool things
That is the problem imo. Most tech workers want a big check and no work. Gross. I like the work. But i do get wanting to get a nut with little effort.
> a high paycheck and have some kind of association with being in tech and doing cool things
yeh, I can see how that is now mistaken for a definition of 'engineer' or 'hacker'.
I am sorry you never knew what engineering truly means.
>AI demands more engineering discipline.
Well, that's a loaded statement. I'am yet to see a Claude session where Claude would tell me to hold off and make my prompts more disciplined.
So it does not demand more discipline.
It can, otoh, build better from disciplined prompts but people too, build better software from better specs.
What worries me personally is the dopamine hit I seem to get from watching my ideas get built in front of me. There is a big temptation to just add feature after feature without really checking what the code actually looks like. So yes, more discipline is needed.
Wrong!
AI demands more of your hours cranking out the same discipline, due to the volume of stuff that needs to be verified.
Normally the term "more discipline" is understood as increased rigor, not simply more work at the same level of rigor.
Chatbots enable unskilled developers to go in way out of their depth with little resistance. This creates problems of a new nature, not just more problems of the same nature as before.
Previously in my career, a junior making a mistake and being told why it was a mistake would learn from that and improve. The junior-chatbot duo will not. The junior will feed my comment into the chatbot, and the chatbot will superficially give the impression of having learned from the mistake and fix the code while introducing the same problem somewhere else, and the junior will have learned nothing.
This all requires that I review code as though it was created by some kind of cursed monkey's paw with an endless number of fingers that each grants a wish of the operator with a devastating caveat through idiotic interpretation.
If you give a toddler who can otherwise not operate a chainsaw -- for the simple reason that they don't have the strength to start it using the starter rope -- access to a robot who will turn on the chainsaw for them on command, you've created a problem which didn't exist before.
I understand that unskilled people are creating problems for themselves and others; but that doesn't interest me. I interpret everything from the point of view of the AI being used by skilled people.
Such as the claim "AI demands more engineering discipline, not less" ... of skilled people, not irrelevant unskilled people.
Unskilled people are not irrelevant if you intend on working with other people, in which case you will need to deal with them in one way or another.
I will probably be dealing with them in the future more than in the past because chatbots bypass the process by which unskilled people generally become skilled people.
Suppose I don't use AI, but have to work with people who are using it. Is AI demanding more/less engineering discipline of me?
I don't know anything about you, but I told you my experience a couple of messages back, which you effectively decided not to respond to.
It demands more and yet it makes it so, so much easier to get by with less. I don't quite understand who is supposed to be the winner here.
So, using artificial intelligence requires more expertise than not using it?
the ur-text behind this piece is: people just not understanding exponential capability growth. including the author of the piece!
if you could look clearly at the progress from 2020 to 2023, as someone like Gwern did, and from 2023 to 2024 with the invention of reasoning modes, then it was not that hard to understand what would happen in late 2025. Opus 4.5 was not a surprise to anyone who was actually paying attention.
But people (including the author) still mistake the current state as a stable state and future gains as incremental. he says
“I am not asserting that all code will eventually be AI-generated to spec, bypassing human understanding”
I AM asserting that, and it’s incredibly easy to do so.
The question of “when” is separate.
There's one thing that hasn't changed much with LLMs, and that's the notion of 'moving the needle'. People who sling slop don't meaningfully accomplish that if you're paying close attention to how your team or org or company actually needs to move. Although, if your team is focused on PRs and LOC, sure, the needle is popped off the gauge by LLMs. But your problem is not LLMs in that case.
I agree that AI demands more engineering discipline, but it also demands more domain knowledge, purpose, and intent. Suddenly we can actually accomplish most of our goals a little faster. I can take on work I couldn't before.
Before I even begin getting disciplined about engineering, I need to ask: does this work actually make sense? Should I do it? If it's done... What do I think will change for my team or organization? Will it have practical results that move us in the right direction?
The better you get at asking that question, the less you'll find yourself prompting and planning and shoving PRs into the chute. It's still somewhat difficult to find important work in many places.
Still, engineering discipline is and always has been critical when going ahead with important work.
My gut feeling is that many of us simply aren't doing important work, and the discipline might be nice but is ultimately irrelevant. The sloppers are doing a faster version of something they always have, and much of it will be lost to time just like our pre-slop work has been.
I find LLMs aren't as helpful when applied to well-thought and intentional work towards very specific goals in complex domains. They're still helpful, but, the deeper you go and the more specific you get, the more they tend to deliver results you can't use. If you're on the rails they can be incredible. Diverging from the track and having exacting requirements, eh, it gets pretty hit or miss and you can spend a lot of time herding a digital cat. This certainly demands a lot more engineering discipline.
This has been my experience with AI.
Writing software begins with a solid design that is defensible. If you don't have that, the AI will produce slop.
Once you're happy with the design, you need a solid plan. If you don't have that, the AI will produce slop.
Once you're happy with the plan, you can set the AI loose, but don't get too complacent! Anything that you missed in the previous phases could very well lead to slop (although likely localized).
And then then, as your project matures and you gain more understanding of the space, you start to notice deficiencies in your model. This is where AI really shines: design and code changes to adapt to reality.
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[dead]
[dead]
> Instead of being very hard, time-consuming, and expensive to generate code
Was this article written by AI? It's certainly stupid enough!
This is why I built https://saasufy.com/ - Vibe coders shouldn't trust themselves with backend security. Unfortunately, it's extremely difficult to get right. There's a lot to think about;
- Schema validation with appropriate size limits on all relevant fields.
- Authentication.
- Access control.
- Backpressure management and rate limiting in case a (possibly malicious) user tries to perform too many computationally expensive actions in a short time.
- Ensuring that the actions of one user doesn't throttle another user which is connected to the same process/host, e.g. using async constructs to avoid freezing the main process.
- DDoS mitigation.
- Avoiding race conditions.
- Designing a good database schema, with well chosen indexes, with deterministic IDs/idempotency to avoid double-insertion scenarios. You don't want to be forced to rely on overly complex queries with a lot of joins. This doesn't scale well and rarely necessary.
- Logging and error handling.
- Avoiding conflicts and accidental overwrite with old data when multiple users are editing different fields of the same resource concurrently.
- Efficient distribution of realtime messages.
- Scalability.
The list goes on and on... And every piece has to be implemented perfectly. This involves a huge number of carefully thought-out decisions.