6 ms·

AI demands more engineering discipline. Not less

429 points by BerislavLopac 3mo ago

otabdeveloper4 3mo ago
[flagged]
workbox 3mo ago
I did not enjoy reading this article. The writing was fine, and each individual paragraph was fine, but the whole thing together was meandering and dare I say pointless. It was so many words and yet so little seems to have been said.
- argee 3mo ago
  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.
  - molsongolden 3mo ago
    I think the point is that there are better engineering artifacts to review instead of lines of code. Encoding the decisions, structure, requirements, testing, monitoring, then reviewing those and having AI generate and regenerate code based on them. The code itself doesn't matter if enough thought and rigor has gone into the structure that produces the code. > What does "ideal" mean here? When I was growing up "show your work" was the rule for all examinations. Why? Because we're working to improve mental models and thought processes for the next generation, not just products we will release tomorrow. They're saying that the mental models and thought processes are incredibly important but that code is not the place for that work to live.
    - argee 3mo ago
      > They're saying that the mental models and thought processes are incredibly important but that code is not the place for that work to live. What I meant is that, insofar as some work has been produced with a human mind involved and where imperfect abstractions are used, one should not for whatever idealistic reasons push for reviewing the work at some coarser granularity than the details which are readily available. That's a way to foster and encourage mistakes, in both the work and in the mental model. So when you say that code is not the place for that work to live (or more closely to the line I disagree with, that code is not an 'ideal' artifact to review), you are essentially purporting that there is a perfect abstraction that can generally be trusted, which I disagree is currently the case for an LLM spec versus produced code.
    - skydhash 3mo ago
      > They're saying that the mental models and thought processes are incredibly important but that code is not the place for that work to live. They’re important for discussion and brainstorming. They’re also important for sharing context before reviewing. But code is the only perfect representation in terms of semantics of what the computer will do. You can have all the diagram and all the proses you want, but they’re still ambiguous.
  - z0r 3mo ago
    As soon as I read the quoted paragraph, I rapidly scrolled to see how much more was written, then closed the tab. Generating a lot of code might be 'free' now but the generated code is very costly. I don't have the time to read an article written upon such a premise.
  - stephbook 3mo ago
    My vibe sense tells me AI slop. It's just too much vacuous text in general and "not x, but y."
- ed_elliott_asc 3mo ago
  I enjoyed it, people post on blogs as a way to entertain themselves, not necessarily the reader.
- nielsbot 3mo ago
  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
- SrslyJosh 3mo ago
  > 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!
- dogleash 3mo ago
  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?
- BhavdeepSethi 3mo ago
  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.
glouwbug 3mo ago
Before 2023 I remember everyone here on HN championed that removing lines of code was the strongest senior metric
- esafak 3mo ago
  Simplification is still good. I remember one senior that only removed code when he joined the company I was at until he became a manager!
  - hungryhobbit 3mo ago
    Ok, I like the idea and support that seniors value simplicity ... but how the hell do you stay employed for even a month (let alone until "manager time") without writing any code?
    - LtWorf 3mo ago
      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.
      - vyaa 3mo ago
        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.
- bluGill 3mo ago
  Removing lines of code without removing functionality.
- hashmap 3mo ago
AndrewKemendo 3mo ago
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
- rustystump 3mo ago
  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.
- lstodd 3mo ago
  > 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.
e12e 3mo ago
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
- glouwbug 3mo ago
  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!”)
  - LtWorf 3mo ago
    It was also trained on gcc and clang.
0x59 3mo ago
[flagged]
kstenerud 3mo ago
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.
msteffen 3mo ago
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/ https://blog.gpkb.org/posts/just-send-me-the-prompt/ I think Charity is observing a very old problem and expecting the new technology to lead to a new solution of some kind. I doubt she thinks even the current generation of tools are the end of the AI software development story. She's not saying we'll drop design docs right into Claude code and walk away (design docs aren't complete either, that's why when you're ramping up you also have to talk to people, read old tickets and postmortems, etc.) What she's observing is that, in prod, people don't like infra where it's hard to tell how it got into is current state, and so infra-as-code is what we do now. She's also observing that, "it's hard to tell how it got into its current state" is the status quo with codebases, which other people have observed going back to "Programming as Theory Building" and earlier. And she's expecting that, analogous to infra, software development will somehow be done with tools focused on making "how the code got into its current state" clearer.
- molsongolden 3mo ago
  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.
deleted 3mo ago
[deleted]
ezoe 3mo ago
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?
- hungryhobbit 3mo ago
  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.
- AnimalMuppet 3mo ago
  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.
romaniv 3mo ago
>"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.
- wbl 3mo ago
  The old model couldn't do math, the new one solved a big open problem.
  - romaniv 3mo ago
    "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.
    - wbl 3mo ago
      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.
    - scubbo 3mo ago
      > 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.
      - romaniv 3mo ago
ryandvm 3mo ago
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.
- blensor 3mo ago
  Maybe the solution is to look out for the most silent engineers. Those that output less despite having the ability to create near infinite output.
  - AStrangeMorrow 3mo ago
    Not sure how to understand that. You mean as the best engineers? Funnily at my company, the few engineer that did the majority of the work before AI still do the majority of the work now. By majority I mean tackling both more issues and better. However there is a general verboseness and over engineering trend across the board.
    - blensor 3mo ago
      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.
sdicker 3mo ago
Thanks, great to have the perspective of thoughtful engineers who have been in the trenches for a long time
trjordan 3mo ago
> 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!
- mooreds 3mo ago
  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?
  - trjordan 3mo ago
    We're working on it, thought it's all early. I'd love feedback: https://tern.sh 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/ https://tern.sh/docs/tours/
  - latentsea 3mo ago
    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.
bilater 3mo ago
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.
socketcluster 3mo ago
This is why I built https://saasufy.com/ 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.
SrslyJosh 3mo ago
So, using artificial intelligence requires more expertise than not using it?
keybored 3mo ago
> 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.
K0balt 3mo ago
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.
EastLondonCoder 3mo ago
[flagged]
simonw 3mo ago
> 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#url=https%3A%2F%2Flatest.datasette.io%2Ffixtures%2Ffacetable.json https://tools.simonwillison.net/datasette-extras-explorer#ur... (linked from the release notes https://docs.datasette.io/en/latest/changelog.html#extra-support-for-row-and-query-pages 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 https://github.com/simonw/sqlite-ast People get VERY upset (and condescending) any time you suggest that being able to produce lines of code faster is a valuable thing. And sure, measuring output through "lines of code" is stupid. But measuring "lines of verified code that deliver valuable" isn't stupid at all. That's the thing we can do faster now.
- eiwiwi 3mo ago
  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.
Elzair 3mo ago
I read the article, and it seems she is forgetting the aphorism "all models are wrong". This is a common mistake that people who like "realistic" "simulation" RPGs often make. Any suitably comprehensive model of a thing is just the thing itself. To have a model of a location that includes all the detail of the actual location, you would need a 1:1 scale model, which is just a copy of the location. Any plan (i.e. prompt to a model) sufficiently capable of reliably replicating 100% of the functionality of a system is likely the source code of the system itself.
- Elzair 3mo ago
  However the second part of that aphorism is "but some are useful". I have often wondered how much of IT/Programming is just sticking well understood pieces together. I remember 8 years ago wondering why we could not replace LLVM with a much simpler system that replaced all the manual optimization with a simple AI "optimizer" trained to transform simple compiled code into "optimized" code. I remember the consensus being that the AI system could likely not produce correct code reliably enough to be used. If AI cannot replace such "low level" code, then surely "high level" problems are widely out of reach. Yet people use it for "high level" problems. What gives? My hypothesis is that a lot of modern digital engineering is "plug and play".
  - edot 3mo ago
    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.
kazinator 3mo ago
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.
- boomlinde 3mo ago
  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.
  - deleted 3mo ago
    [deleted]
  - kazinator 3mo ago
    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.
    - boomlinde 3mo ago
      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.
steve_adams_86 3mo ago
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.
ManuelKiessling 3mo ago
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.
sandover 3mo ago
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.
cadamsdotcom 3mo ago
> 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?
KaiShips 3mo ago
[flagged]
amatheus 3mo ago
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.
- therealdrag0 3mo ago
  Plus humans are non-deterministic, so AI replacing humans is not adding more determinism to the development process.
  - bluefirebrand 3mo ago
    Humans make up for being non-deterministic by being disciplined AI doesn't have anything resembling discipline
ncruces 3mo ago
I just spent a week reviewing this ~200 LoC PR: https://github.com/ncruces/wasm2go/pull/37 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?
deaton 3mo ago
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.
hibikir 3mo ago
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.
nullorempty 3mo ago
>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.
youknownothing 3mo ago
"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.
jay_kyburz 3mo ago
"...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.
- Sivart13 3mo ago
  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!
QuantumNoodle 3mo ago
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.
- goldenarm 3mo ago
  relevant xkcd : https://xkcd.com/2030/ https://xkcd.com/2030/
  - QuantumNoodle 3mo ago
    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.
jameslaneno9 3mo ago
[flagged]
schmuhblaster 3mo ago
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.
BerislavLopac 3mo ago
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.
deleted 3mo ago
[deleted]
SwtCyber 3mo ago
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
jreynar 3mo ago
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.
rambojohnson 3mo ago
[dead]
magwa101 3mo ago
[dead]
akmal_codes 3mo ago
[flagged]
sltr 3mo ago
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-uncertainty https://annievella.com/posts/finding-comfort-in-the-uncertai... [2] https://www.slater.dev/2026/05/why-english-will-never-be-a-programming-language/ https://www.slater.dev/2026/05/why-english-will-never-be-a-p...
adam3562 3mo ago
[flagged]
Galine3728 3mo ago
[flagged]

429 points by BerislavLopac 3mo ago

[flagged]

I did not enjoy reading this article. The writing was fine, and each individual paragraph was fine, but the whole thing together was meandering and dare I say pointless. It was so many words and yet so little seems to have been said.

argee 3mo ago
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.
- molsongolden 3mo ago
  I think the point is that there are better engineering artifacts to review instead of lines of code. Encoding the decisions, structure, requirements, testing, monitoring, then reviewing those and having AI generate and regenerate code based on them. The code itself doesn't matter if enough thought and rigor has gone into the structure that produces the code. > What does "ideal" mean here? When I was growing up "show your work" was the rule for all examinations. Why? Because we're working to improve mental models and thought processes for the next generation, not just products we will release tomorrow. They're saying that the mental models and thought processes are incredibly important but that code is not the place for that work to live.
  - argee 3mo ago
    > They're saying that the mental models and thought processes are incredibly important but that code is not the place for that work to live. What I meant is that, insofar as some work has been produced with a human mind involved and where imperfect abstractions are used, one should not for whatever idealistic reasons push for reviewing the work at some coarser granularity than the details which are readily available. That's a way to foster and encourage mistakes, in both the work and in the mental model. So when you say that code is not the place for that work to live (or more closely to the line I disagree with, that code is not an 'ideal' artifact to review), you are essentially purporting that there is a perfect abstraction that can generally be trusted, which I disagree is currently the case for an LLM spec versus produced code.
  - skydhash 3mo ago
    > They're saying that the mental models and thought processes are incredibly important but that code is not the place for that work to live. They’re important for discussion and brainstorming. They’re also important for sharing context before reviewing. But code is the only perfect representation in terms of semantics of what the computer will do. You can have all the diagram and all the proses you want, but they’re still ambiguous.
- z0r 3mo ago
  As soon as I read the quoted paragraph, I rapidly scrolled to see how much more was written, then closed the tab. Generating a lot of code might be 'free' now but the generated code is very costly. I don't have the time to read an article written upon such a premise.
- stephbook 3mo ago
  My vibe sense tells me AI slop. It's just too much vacuous text in general and "not x, but y."
ed_elliott_asc 3mo ago
I enjoyed it, people post on blogs as a way to entertain themselves, not necessarily the reader.
nielsbot 3mo ago
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
SrslyJosh 3mo ago
> 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!
dogleash 3mo ago
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?
BhavdeepSethi 3mo ago
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.

glouwbug 3mo ago

Before 2023 I remember everyone here on HN championed that removing lines of code was the strongest senior metric

esafak 3mo ago
Simplification is still good. I remember one senior that only removed code when he joined the company I was at until he became a manager!
- hungryhobbit 3mo ago
  Ok, I like the idea and support that seniors value simplicity ... but how the hell do you stay employed for even a month (let alone until "manager time") without writing any code?
  - LtWorf 3mo ago
    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.
    - vyaa 3mo ago
      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.
bluGill 3mo ago
Removing lines of code without removing functionality.
hashmap 3mo ago

AndrewKemendo 3mo ago

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

rustystump 3mo ago
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.
lstodd 3mo ago
> 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.

e12e 3mo ago

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

glouwbug 3mo ago
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!”)
- LtWorf 3mo ago
  It was also trained on gcc and clang.

0x59 3mo ago

[flagged]

kstenerud 3mo ago

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.

msteffen 3mo ago

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/ https://blog.gpkb.org/posts/just-send-me-the-prompt/ I think Charity is observing a very old problem and expecting the new technology to lead to a new solution of some kind. I doubt she thinks even the current generation of tools are the end of the AI software development story. She's not saying we'll drop design docs right into Claude code and walk away (design docs aren't complete either, that's why when you're ramping up you also have to talk to people, read old tickets and postmortems, etc.) What she's observing is that, in prod, people don't like infra where it's hard to tell how it got into is current state, and so infra-as-code is what we do now. She's also observing that, "it's hard to tell how it got into its current state" is the status quo with codebases, which other people have observed going back to "Programming as Theory Building" and earlier. And she's expecting that, analogous to infra, software development will somehow be done with tools focused on making "how the code got into its current state" clearer.

molsongolden 3mo ago
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.

deleted 3mo ago

[deleted]

ezoe 3mo ago

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?

hungryhobbit 3mo ago
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.
AnimalMuppet 3mo ago
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.

romaniv 3mo ago

>"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.

wbl 3mo ago
The old model couldn't do math, the new one solved a big open problem.
- romaniv 3mo ago
  "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.
  - wbl 3mo ago
    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.
  - scubbo 3mo ago
    > 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.
    - romaniv 3mo ago

ryandvm 3mo ago

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.

blensor 3mo ago
Maybe the solution is to look out for the most silent engineers. Those that output less despite having the ability to create near infinite output.
- AStrangeMorrow 3mo ago
  Not sure how to understand that. You mean as the best engineers? Funnily at my company, the few engineer that did the majority of the work before AI still do the majority of the work now. By majority I mean tackling both more issues and better. However there is a general verboseness and over engineering trend across the board.
  - blensor 3mo ago
    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.

sdicker 3mo ago

Thanks, great to have the perspective of thoughtful engineers who have been in the trenches for a long time

trjordan 3mo ago

> 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!

mooreds 3mo ago
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?
- trjordan 3mo ago
  We're working on it, thought it's all early. I'd love feedback: https://tern.sh 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/ https://tern.sh/docs/tours/
- latentsea 3mo ago
  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.

bilater 3mo ago

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.

socketcluster 3mo ago

This is why I built https://saasufy.com/ 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.

SrslyJosh 3mo ago

So, using artificial intelligence requires more expertise than not using it?

keybored 3mo ago

> 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.

K0balt 3mo ago

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.

EastLondonCoder 3mo ago

[flagged]

simonw 3mo ago

> 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#url=https%3A%2F%2Flatest.datasette.io%2Ffixtures%2Ffacetable.json https://tools.simonwillison.net/datasette-extras-explorer#ur... (linked from the release notes https://docs.datasette.io/en/latest/changelog.html#extra-support-for-row-and-query-pages 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 https://github.com/simonw/sqlite-ast People get VERY upset (and condescending) any time you suggest that being able to produce lines of code faster is a valuable thing. And sure, measuring output through "lines of code" is stupid. But measuring "lines of verified code that deliver valuable" isn't stupid at all. That's the thing we can do faster now.

eiwiwi 3mo ago
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.

Elzair 3mo ago

I read the article, and it seems she is forgetting the aphorism "all models are wrong". This is a common mistake that people who like "realistic" "simulation" RPGs often make. Any suitably comprehensive model of a thing is just the thing itself. To have a model of a location that includes all the detail of the actual location, you would need a 1:1 scale model, which is just a copy of the location. Any plan (i.e. prompt to a model) sufficiently capable of reliably replicating 100% of the functionality of a system is likely the source code of the system itself.

Elzair 3mo ago
However the second part of that aphorism is "but some are useful". I have often wondered how much of IT/Programming is just sticking well understood pieces together. I remember 8 years ago wondering why we could not replace LLVM with a much simpler system that replaced all the manual optimization with a simple AI "optimizer" trained to transform simple compiled code into "optimized" code. I remember the consensus being that the AI system could likely not produce correct code reliably enough to be used. If AI cannot replace such "low level" code, then surely "high level" problems are widely out of reach. Yet people use it for "high level" problems. What gives? My hypothesis is that a lot of modern digital engineering is "plug and play".
- edot 3mo ago
  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.

kazinator 3mo ago

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.

boomlinde 3mo ago
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.
- deleted 3mo ago
  [deleted]
- kazinator 3mo ago
  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.
  - boomlinde 3mo ago
    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.

steve_adams_86 3mo ago

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.

ManuelKiessling 3mo ago

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.

sandover 3mo ago

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.

cadamsdotcom 3mo ago

> 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?

KaiShips 3mo ago

[flagged]

amatheus 3mo ago

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.

therealdrag0 3mo ago
Plus humans are non-deterministic, so AI replacing humans is not adding more determinism to the development process.
- bluefirebrand 3mo ago
  Humans make up for being non-deterministic by being disciplined AI doesn't have anything resembling discipline

ncruces 3mo ago

I just spent a week reviewing this ~200 LoC PR: https://github.com/ncruces/wasm2go/pull/37 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?

deaton 3mo ago

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.

hibikir 3mo ago

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.

nullorempty 3mo ago

>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.

youknownothing 3mo ago

"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.

jay_kyburz 3mo ago

"...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.

Sivart13 3mo ago
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!

QuantumNoodle 3mo ago

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.

goldenarm 3mo ago
relevant xkcd : https://xkcd.com/2030/ https://xkcd.com/2030/
- QuantumNoodle 3mo ago
  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.

jameslaneno9 3mo ago

[flagged]

schmuhblaster 3mo ago

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.

BerislavLopac 3mo ago

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.

deleted 3mo ago

[deleted]

SwtCyber 3mo ago

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

jreynar 3mo ago

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.

rambojohnson 3mo ago

[dead]

magwa101 3mo ago

[dead]

akmal_codes 3mo ago

[flagged]

sltr 3mo ago

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-uncertainty https://annievella.com/posts/finding-comfort-in-the-uncertai... [2] https://www.slater.dev/2026/05/why-english-will-never-be-a-programming-language/ https://www.slater.dev/2026/05/why-english-will-never-be-a-p...

adam3562 3mo ago

[flagged]

Galine3728 3mo ago

[flagged]