Loops work when you spend the proper amount of time to understand what you want ahead of time. The prerequisite is clarity — enough clarity that you could write a careful specification that you could hand off to a junior colleague.
Often, it takes 5-6 broken crappy versions of a thing until you understand that. There is no accelerating the 5-6 broken crappy versions - there’s no agent tech that’s going to help your meat brain avoid thinking time.
So most of my time is iterating between these two phases: I don’t understand what I want, I need to read and write and play with code, okay it’s been long enough I think I know what I want (it is extremely easy to deceive yourself) … okay now I do actually know what I want and I can write a loop.
Many people think they can jump ahead with agents. You cannot fake understanding or clarity. It is painfully obviously when someone skipped that meat brain understanding phase.
I had codex write a tool to extract all my pi sessions. (Had to filter out my prompts from the agents talking to subagents).
Then I had it analyze the patterns i was making and turned that into the flowchart for the outer guidance-creating-prompt.
I didn't have to spend too much time thinking what i wanted. I wanted it to do that.
The result is still mixed, and i'm not trusting it with delicate code bases, but for a game i've been building i dropped my check-in time to 1/5th i was previously spending on it.
Thats not a good thing per-se. I'm sure i'm missing good ideas by _not_ spending time with it. But previously I really had stagnated with my prompts becoming mechanical #now-do-this and #now-review-that with 90% of its suggestions being correct.
Just need to (automatically) remind it to "do the hard stuff first, clean up & refactor as you go" as well as a "reflect on your work" after its first return to get it to spill the beans on any crap left behind, and then process that in the guidance-creating-prompt to dish out new work.
I'm having it build the software to run a raspberry pi and using a local llm and opencode. the display code is fugly, and i regret nothing about how it'll look inside nor do I want to know all the stupid requirements. We improved it'd render speed by finding a github example using numpy. It uses jinja to render user generated templates for the ui.
The only problem it runs into is the bizarre BGRA or RGB or whatever color mapping between screen and frame buffer; it absolutely has no idea what it does when it's right. It also thinks there's some magic around the bits per pixel.
I do not really care, as this thing won't ever be extended beyond display some text and a few graphics. So why do I need it taking up space in my brain.
A lot of little projects are a lot easier now, but corpos who think this will be a magic want to their largesse of badly maintained code are gonna have trouble.
> Often, it takes 5-6 broken crappy versions of a thing until you understand that. There is no accelerating the 5-6 broken crappy versions - there’s no agent tech that’s going to help your meat brain avoid thinking time.
Fully agreed. Though I found that, once I found a harness (prompt + skills + model) that I trust to do most things the way I like it, it has sped up the coding/exploration part of that process.
Although the iterations are faster, it's still taking me almost the same amount of effort to go through those crappy versions, because I still need to understand and adjust my mental model of what ideas, principles, design apply for the solution, and what to try next.
So, in the end, I do feel like I'm expending more mental effort in a shorter amount of time (with some effort saved on writing the code, which wasn't that much to begin with once you're proficient). It's a weird feeling, like I'm "only" prompting and reading code, but I feel equally mentally spent, or sometimes more because of the compressed iteration cycle.
> We may create codebases that are not merely hard to maintain by humans, but that assume machine participation as part of their maintenance model... People more and more merge code they cannot fully explain. People lose their ability to create issue reports or discuss things in chat, without augmenting or rephrasing their messages with the context provided by a clanker. Too many people increasingly rely on a machine to summarize or contextualize it. More and more do I encounter people who converse with me through the indirection of an LLM.
I experience this daily now. It find it discouraging and concerning.
I believe we're merging more code we can't fully explain because we are now relying on code review to build the mental model that was previously built by writing code and collaborative technical planning. I don't think code review is fit for this purpose. I do think we can extend code review with structured exercises, informed by pedagogy, that strike a better balance between friction and understanding. (I'm looking for help testing these exercises).
And this code is often full of security vulnerabilities. It's just hacks on top of hacks on top of hacks. You end up with 100K lines of code full of weird fallbacks, doing something which could have been done more reliably with just 1K lines of code.
I think author's comment about preferring systems which make invalid edge cases impossible rather than implementing fallbacks is hugely important. With the fallback approach; you end up implementing fallback on top of fallback on top of fallback... Each fallback seems to increase the amount of code exponentially and somehow it always creates new problems. This should almost be a 'General law of system design.'
Fallbacks reduce the risk of failure but make failures more complicated and harmful when they do happen.
As a software engineer, like the new coding environment which is being created by AI.
Big tech companies have created infinite work for me. The human developer has become a critical component of code execution. The human needs to always be present to handle the nearly infinite number of difficult unhandled exception cases which are guaranteed to occur from time to time.
The software engineer is no longer like a laborer, but more like a security guard who sits at his desk drinking coffee most of the time and only steps in on rare occasions when something goes wrong.
My experience with LLM's is that the "fallback" issue is probably one of the most serious issues. I have seen zero talk about it outside of this thread. I'm not sure its even being worked on. The llms have this terrible drift towards always making something happen even if that thing is not even related to the task at hand. "failure" in the sense of simply throwing an error/exception is something models seem highly resistant to.
I cant tell you at this point how many times I've seen them do something like
Fail > make up values > maybe log it > keep working silently with increasingly corrupt data.
This isn't going to work because the LLM doesn't have enough context. Many security issues involve a failure mode which cuts across multiple parts of the code. A PR which seems perfectly valid on its own may be the missing piece which opens up a vulnerability. Each component may be fine on its own, but brought together, the system is vulnerable.
Think of a machine with interlocking gears; each gear may itself be perfect and may fit perfectly with each other, but then if a tiny pebble comes between them, the entire machine breaks. Maybe the problem here is that the final gear was too close to the ground and would catch stray pebbles kicked up by the wheel in front of it... The LLM couldn't know this unless it understood the full context in which the change occurred; not only the code, but the environment itself.
In a poorly designed codebase with hundreds of thousands of lines of code, it's impossible to have the full context of the code even. The architecture would lack proper separation of concerns to allow one to effectively establish an appropriate defense perimeter. In a poorly designed codebase, every part of the code can harbor a vulnerability.
It's like; if you don't have a proper access control layer which is automatically and declaratively enforced for all your endpoints, every endpoint will have to enforce security restrictions on their own; duplicating similar-looking code over and over. If one endpoint out of 1000 incorrectly enforces a security restriction, that could be a critical vulnerability.
Of course you don't just check the diff. Rather in your CI infra, it's important as part of every PR, it needs to be given the full repo to check if it introduces any issues. This works wonderfully on github, even with non SOTA tools like gemini-code-assist.
why do you think it's not possible to have full context of codebase? modern harnesses excel at finding all the right codepaths, even in a large codebase.
Not to mention that effectively reviewing code is a much more difficult skill than writing it. Without a good mental map of how it
affects other parts of the system, it’s basically a rubber stamping ceremony.
Github’s poor PR UI doesn’t help either, there’s limited tooling to navigate around the codebase not directly changed (but affected) to identify and highlight problems.
>Yet even with a lot of manual steering, that type of code does not come out of LLMs naturally, and even if the code comes out naturally like that, they will still attempt to handle now impossible errors.
This is something I’ve struggled to fight against in many PR reviews. Especially once already written, convincing someone that their excessive null checking is harmful is an uphill battle. Short of better modeling (and languages that allow for sum types to enable it), I haven’t been able to come up with a universally convincing argument against this kind of “shotgun parsing.”
Maybe it really just isn’t that big of a deal? But when actually reading through and refactoring a codebase I’ve always found it frustrating to manage these unnecessary checks. Sometimes they’re nearly impossible to delete safely once present without first adding some kind of logging or broad investigation.
> convincing someone that their excessive null checking is harmful is an uphill battle.
The argument that seems to hit home more often than not is that optionals effectively “fork” the state space, the possible states your program can be in. And the larger the state space is, the harder it is to reason about the code and maintain it. That’s actually part of what make undesirable states un-representable means.
And AI code reviews encourage overly delusional defensive paranoia. triple null checking deep inside a function is technically a real risk, but in practice should never be hit because you've checked for nulls in every function that calls or could call the function in question and is thus not necessarily worth guarding against.
I tend to be a fairly defensive programmer - maybe nothing currently sends this function a negative value, but how hard is it for a future code change to alter that assumption? I always figured a clear error was best. It lets even someone unfamiliar with the code know what assumptions are being made about the valid range of inputs, so they don't have to consider impossible outliers.
Obviously it isn’t totally impossible, but it becomes challenging to know if it’s required or not. It’s hardest when it isn’t just throwing an error but instead defaulting to something only half-sensible. For example replacing a negative number with 0 or overflowing rather than panicking.
When it comes to assumptions about the input, ideally model them in the type system. If you can’t, explicit checks and throws are OK in my book. But don’t check-and-hide any errors. You’ll be hard pressed to debug the issues they’ll cause down the road, since it will usually be far from the implementation that you see the impact.
I hate the "pick defaults out of a hat" approach that LLMs seem to take. I suspect this behavior may be a result of reenforcement learning on coding challenges - making the code worse by throwing in these assumptions (which in turn become part of your documented API) may get you an extra half percentage point on the code challenges.
This ties into something I have been saying for months: LLMs are great at finishing tasks, but bad at aesthetics and taste.
There are two kinds of work: One is goal-driven work, where we have a goal to achieve, and we care very little about how we get there. Security is a perfect example; if you want to exploit a system, you rarely care about how beautiful the exploit is, all you want is access to those super secret nuclear plans. Research is also like this; "research-quality" code was famously terrible, even before the age of AI.
The other kind of work is taste-driven work. People think that, when they're adding a feature to a large codebase, their goal is to add that feature, but that is often not the case. Keeping the codebase amenable to future changes is often far, far more important than this specific feature, and that requires taste. Note that maintainability and code quality aren't synonymous, code quality is just a means to an end, and that end is maintainability.
> Note that maintainability and code quality aren't synonymous, code quality is just a means to an end, and that end is maintainability.
Many orgs are quickly moving to a world where code quality and maintainability are not a priority, at all. If claude is just going to write the code, does it matter "maintainable" or "quality" it is? No. It just matters if it works, and if its fast, is how the perspective goes.
The irony is that coding agents are, if anything, more affected by technical debt than human maintainers (who at least occasionally have the taste to rise above the level of the current codebase they're working in). The impact on productivity may be initially delayed, but it's going to compound faster.
I think we have to wait and see if long term maintainability will be any different from human coded software. Every single long surviving human written codebase I have worked with, has significant amounts of tech debt and large pieces had to be rewritten from time to time. This is of course anecdotal and I'm sure clean and elegant old codebases exist somewhere.
The worse designed the code, the more frequently it has to be re-factored. I've worked on long running projects which required essentially no refactoring when implementing new features and I've also worked on projects which had to be re-written multiple times to accommodate requirement changes.
In most half-decent codebases, including LLM generated ones, adding new features almost never requires a refactoring in my experience. It is almost always when you are fixing bugs, improving performance or changing core behavior.
Maintainability is just the inverse of the expected cost to make a future change. Future changes matter, so maintainability matters.
It is, however, true that we don't yet know how to achieve maintainability in the age of LLMs, and whether it keeps being synonymous with aesthetics and code quality as time goes on.
My experience is that I am bottle-necked on specs. The agent loop is less of a thing for me now.
If I can get a clear understanding of what I want to build, communicate that to Claude Code in planning mode with the goal to write an actionable spec (not code, plan to write the spec) then I tend to get very good results once the agent goes to implement.
But this strategy, while effective, puts a big load on me to write the specs. The agent tends to knock each one out of the park (usually 2 to 3 follow ups based on code review) but then I'm back at the stage that requires the spec.
Another issue for me is that when I step away, if the agent finishes a task and could technically start on an existing spec (no overlap on files so no conflict possible) it doesn't know it can just create a new branch and start. Before I go to bed I'll often say "do task X and once done and pushed start on task Y". But I haven't had luck beyond that. Often I find that it starts on Y and has a question and then the agent is idle the rest of the time.
The final issue is dependency coupled with the above. For example, today I was writing a background job processor. Obviously, the jobs that are in subsequent tasks require the system. That happens with some frequency. Even the specs need to be refreshed after the implementation to take any details that were resolved at coding time into account.
But I am just on the cusp of wanting the outer loop. The gate is almost entirely on spec creation and PR review. In places where those gates don't matter, I want the agent to keep chugging away.
As an aside, I strongly believe we need to start using tools that are better for LLMs even if they are worse for us. For example, Rust is annoying because the compiler is so strict. Bad for me, great for LLMs.
This is exactly the way it should be! This is great! This is the most important part of engineering of systems that has been minimized over the past two decades in the rush to build. Now that the building is more automated, the specifications and system design can take the important lead again. Engineering and quality might be back!
One thesis I am developing is that LLMs have given us a new kind of tradeoff. We can use the intelligence and tremendous speed up that mechanically pumping out basic CRUD code has given and we can either deliver more features or deliver higher quality.
What that means to me is that there is a balance. My belief is that we have to take some of the new power and put it towards quality rather than spend it all on speed.
Do you really believe that? If I would be employer or manager of developers saying that they need to carefully design whole system for the agent to implement, so not a technical person, it would look like their are buying their time.
I believe that it will be the case. 'What design?! Just feed Jira ticket and business documentation to Claude and quit stalling!!'
This matches my experience coding, and the expectations I (and many other) have been voicing for years about why AI is still a ways away from solving coding. The hard part of programming isn't pressing the keys to put code into a file, it's understanding the problem and coming up with a good, clean, extensible solution. AI is great at making ok solutions that technically work, but pretty bad at having a good vision for a solution. AI is still very useful for bouncing ideas off of and exploring to create a better understanding, but writing a good spec for an LLM to implement isn't much easier than just writing the code yourself.
How do you define the good result? Does the definition of success include clean, maintainable code? I am finding I need to be in the loop. My code ships to thousands of users, so any issues get amplified.
Last time I saw one of these conversations on HN that was the key question.
What people disagreed on was what's good, or what's even good enough. I don't think that's a new thing but it's becoming far more apparent in the age of AI.
I'll make the claim, a demo is easy to make. But it's far from a minimum viable product. A demo is *maybe* 10% of the work. But for some people I know (and work with) they act like it's 90%.
Yes, I review every PR (which is part of the bottleneck) and give strict feedback (as I mentioned, averaging 2 to 3 fixes per task).
What I'm saying is that there are some higher-level loops (as described in this article) that are outside of the bottlenecks I mentioned (spec creation and PR review).
For example, I may have 3 written and ready to go specs that are totally unrelated (don't touch the same files, each can go to PR stage with no conflict) but it isn't easy to keep the agent moving on them unless I do so manually. Having an outer-layer orchestrator that can move that along makes a lot of sense.
But when there are dependencies between tasks, it has to wait for my PR. And once I run out of good specs, it has to wait for me to write them.
"Writing specs" is the essential complexity of programming. What you're saying is that there's no silver bullet. Agents or no agents, punchcards or interpreters, programming is programming at the end of the day.
Same experience. Totally bottle-necked by specs. I don't really see a way past it that isn't sketchy and consumes excessive resources. I guess I'm not ready.
It does, but I have to direct it and review it. That means I have to think about it, research it, consider how the new feature or system fits in with the existing feature or system. I have to make decisions on libraries/dependencies. I have to consider how the project will evolve in the next week, month, quarter. I communicate all of that to Claude in an interactive planning session and it outputs a detailed spec, ready for implementation.
All of that thinking, planning, rewriting, etc. takes almost as long as it takes Claude to actually deliver the feature. The big features Claude writes take ~30-45min of uninterrupted coding to deliver (I just checked the last feature was 39m 41s for +1,610/-26). To write that same code would have taken me probably 2 days.
How do you expect it to give you what you want if you don't think about it?
Solution spaces for even seemingly simple problems is incredibly large. There's a reason there's a thousand different types of nails and a million types of screw heads. Just making every screw head Phillips (or pick another) doesn't just make things work.
But you need expertise to know these things. They're the issues that are subtle and appear to work but you end up breaking things (often invisibly) and just end up chasing problem after problem. It looks like a new problem but it's rooted in something else.
I agree, but that is the crux of my initial post. There is a ceiling to how quick I can deliver using LLM coding agents which is the speed at which I can write good enough specs.
I feel I'm at the point now where the time the LLM takes to deliver a feature, no matter how big, is nearly inconsequential. Because while it is in the process of delivering the feature, I am writing the next spec, and by the time I finish the spec the agent is waiting for the next feature. And at that point I have to review it's code, give it feedback, review it's fixes, merge, etc. All of the "waiting" is on me. It is basically delivering features as fast as I can write specs and could only get faster if I write specs faster.
> the right fix is not "handle every malformed case." ... [LLMs] will still attempt to handle now impossible errors.
This is the number one code smell from LLMs and I don't know why they are so obsessed with it. In python, it often comes as `hasattr` checks on types that are defined to have that attribute, in a code base that is fully type-checked.
Why do they do that? Is it from pre-training or re-enforcement? If that latter, can the labs please fix this?
I suspect it's mostly the training data. I am also on team "make illegal states unrepresentable". It may get talked about a lot on HN, but I'm still at the point that I'm surprised when I see a code base that I didn't write in the wild that does a really good job of it, either open source or at work. Most programmers still think in terms of picking up pieces and fixing errors at the point where the error message pops out rather than making it so the error can't happen and the data reflects that.
I say "mostly" because I think there's also a problem with AIs thinking this way in their current state. That last level of human understanding of a code base, where the human holistically understands the flow of those guarantees, is a challenge to give them right now. On the raw code level, this sort of thing often involves enough code to easily blow out their context window. Trying to summarize it in memories-style files has its own problems; just because there is text written down about the guarantees doesn't mean that the AI is going to get the right info out of it, any more than a human might from just reading the code. I won't say it's "impossible" to give an AI this understanding because I'm not sure it is, but it is a level of understanding of the code that even if you get them to have it, their practices tend to fight against it.
My own solution to this problem has largely been to give up on them getting this. I prompt a solution to the problem the way that most people do, then if I want to make bad illegal states unrepresentable I prompt the AI through the process of the necessary refactorings, unless it's so small that I just do it myself. Given a lot of code that uses maps/dicts and arrays and strings and ints, if you prompt it through making those more thoroughly typed, it's actually pretty good at it. I've not had a lot of luck getting good designs out of single prompts, even when I get detailed. Treating it as two separate tasks seems to work out well.
And watch the diffs on the types carefully; AI loves to sneak past a ".JustSetItAndIgnoreAllThePreAndPostConditions(string)" method. After all, I suspect there's plenty of training data of "types that are nicely structured to make error states unrepresentable and then a later maintainer came along and added a 'JustEffingDoIt' method that broke everything" in the field. One of the best defenses is to make sure that the type implementing these things is in its own file and you can easily look at all the methods it adds on those types and smack it when it does that. I've tried slathering warnings about not doing this and explaining the pre- and post-conditions being maintained in the docs but the change seems marginal.
Because the vast majority of the codebases in its training set aren't fully type-checked, or very clean at all. Or it's just snippets from Stack Overflow, so there's no existing context to not assume null-checking is valid.
It’s because it matches the patterns they are trained to follow. They don’t understand the code. They can’t reason about the actual logic flow. They can only work with patterns.
Sorry to say but the solution is to stop using python. The models are trained to code defensively assuming historically representative python codebases. The models trust the types a lot more in languages where the canonical historical examples trust the types because the language is constructed around that premise.
Code is part of a shared and built understanding of an information system.
If these loopers mean we all have to move at this continuous wave of software happening, then we get to the highest levels of logical information system design and its all human judgement and balancing of business requirements to fit a given niche in a company or market. So all the programmers have to become business analysts/market researchers/businessmen...except the specific niches where AI tooling can't really clank well...or the end of the subsidized AI token era makes all this looping too expensive to continue. This feels like expert systems and symbolics lisps machines redux, where we briefly ran into the fact that its not so much the code itself not being able to do stuff, it's that your company's org always gets shipped, so if you can't change your company org, your software only has so much flexibility.
Dataflow diagrams and domain knowledge / domain modeling / ubiquitous languages may become the metalanguage that we start to use and set the standards for quality, functional, and non-functional standards and conventions. We make the "looper clankers" ensure that they fulfill that data / behavior / performance contracts before saying what "done" is, because "done" is no longer just code that compiles, code that builds, code that deploys, or even code that sits in production; it's code that fulfills all of the user requirements, operator requirements, and maintainer requirements. So, the language used may be required to make us all turn into business analysts and software architects more than syntax knowers. The revenge of UML and the return of declarative / logical design / BDD triumphing?
(Typo scan by gemma4-12b but I didn't let it alter my message)
I keep thinking about at which point I should not force myself into the loop. As a developer I really like working on the code structure, making it clearer, thinking about good abstraction, breaking into modules, etc. I really take pleasure in it. At the same time I understand that at some point I am becoming the limiting factor.
If the point of the software is benefit people, should I still care about how the code looks.
Right now, I still think that the answer is yes, but in 3 years? in 10 years?
It's tough if you're somewhere that isn't very meaningful to you beyond the technology. I think there will be an existential shift soon towards more fulfilling work. Maybe I'm naive or that's just what I feel I need for myself.
I've found that if you look over the code and notice and describe a specific problem and solution, the agent can apply a refactoring for you well enough; and that's often faster than editing the file yourself even if you already know exactly what to do.
The idea of setting up an agentic loop to review code and propose and implement refactorings still seems pretty awful to me, though, yeah. Maybe cut that off at the first green-bar revision, and then apply some actual taste and judgement.
How about ship stuff now even if imperfect. Then as capable models come online, ask them to refactor. This allows you to deliver NOW and refactor later when the situation demands.
> My current status is that I have not had much success with this way of working for code I deeply care about
If something is judgement heavy, "code i care deeply about", then i don't really agree with the direction of travel here. Don't try to delegate decisions you care deeply about.
I do like the framing of agent loop vs harness loop, but only delegate stuff that you can accurately specify in advance, that usually means stuff that's repeatable in my case ("hey go see how i did X, do that but for Y"), and that inherently means stuff that's predictable.
For stuff where lack of my judgement as input is just going to cause me to say "no", we're down to collaborating in the "agent loop" as Armin puts it. And that's totally fine. It's fast, but also safe.
Remember before AI coding assistants, sometimes you'd get an engineer join your team who was SUPER productive, your peers would be jealous "oh yeah but you guys only got all that done because you have X on your team!" - they didn't live the curse of having that kind of person around - if you don't have them PERFECTLY aligned, then they run off at break neck speed in the wrong direction.
> Don't try to delegate decisions you care deeply about.
> they didn't live the curse of having that kind of person around - if you don't have them PERFECTLY aligned, then they run off at break neck speed in the wrong direction.
Exactly. If you wouldn't outsource it to people you considered highly skilled, why would you outsource it to a machine?
I think what is going to happen is revival of "Methodology".
"Methodology" was a big thing in the past just before we got into "Agile Extreme Coding", instead of trying to model the big picture of SW development projects just jump into coding agilly. Implement it feature-by-feature
Granted the methdologies proposed ( See: https://www.ibm.com/docs/en/rational-soft-arch/9.7.0?topic=m... ) may have been too heavy and not flexible and not improved enough. But now with the rise of Agents I think we need to revise and perhaps re-invent them for AI agentic development.
Yes, I believe in reinventing methodologies for the rise of agents.
Before even discussing with my team whether something is a good idea, I can have a full prototype in a new branch within one morning. But then use it as a proof of concept and delete the code.
Another example: agents can generate full test coverage. Including mocking external dependencies and user behavior. Also all in one morning.
Why reinvent methodologies? The cost functions have changed. And agents add new problems, such as hallucinations and tech debt. I think reinventing is a good word since these processes already exist. But the emphasis would shift toward particular parts, making some of them much more mandatory.
Thank you for writing this thoughtful post, Armin. I find it deeply comforting that the developer of Pi, an agent harness, does not remove himself from the loop, like me. Maybe if I started thinking of codebases as biological organisms I could get comfortable with getting the human out of the loop.
What does any of that mean in practice? it's just rambling about abstract concepts that seem to be designed to hint at a bigger picture, when it's just getting AI to write code for you.
Is this where it's going? Having to mystify our roles so it seems like we're still the thought leaders when actually we're just becoming pseudo-teachers that try and herd our group of AI idiots to the right conclusion for us so we don't have to, without ever giving away that it's just all techno-babble?
This is not rambling and it is not abstract. The content here is about the second-order effects of "getting AI to write code for you" in less supervised ways. I'll cede the author could have polished this to more concise effect, but at the level it's at, a reader's failure to understand the substance doesn't imply there's mystification going on.
I agree. I think the comparison made elsewhere in the thread to Yegge's recent AI delusions/projects is especially unfair.
Armin is actively grappling with the implications of AI-produced code on the software engineering craft, and trying to reflect on how to responsibly adopt the best parts of the new world. He's recognizing that the AI skeptical/cautious are still massively impacted by everyone else using tools that run or are built this way.
I really appreciated the piece, and I'm glad we can still publish work in progress thoughts that don't have a clear thesis and call to action.
I'm convinced the field of software engineering is being split in two. These are real concerns and coherent arguments, that make sense for developers who have been using "agentic loops" and heavily AI-assisted workflows.
It scares me that someone can see this as "rambling about abstract concepts" while I see exactly what the author is talking about, both at work and in personal projects; the thought that the majority of people have absolutely no idea what's unfolding.
tech blogs used to read like actionable readme guides. I couldn't finish it without thinking: what am I supposed to do with this information? The shelf life of the latest and greatest is about 2 weeks in the AI space. I never caught up to the ralph wiggum loop and now I'm glad I never tried.
Spending your tokens like some sort of primitive meat bag is passe and any developer doing that will be left behind by the true AI natives.
What you need to do this month is set up a central planning agent that creates a 5 year plan and then orchestrates teams of subagents to each direct subteams of subsubagents to fulfill your goals.
Have each team at every level inspect each other's work and authorize each agent up and down the chain to spend tokens on your behalf for the greater good.
With any luck, the US Administration will see the light and allow AI agents to open up their own credit cards on your behalf to eliminate unnecessary bottlenecks. Agentic Fintech is the future.
We need to move beyond this early stage where you give any thought to spending those tokens yourself!
Practically, what this boils down to is having clear success criteria.
The harness (Claude Codex, Codex, Pi etc) keeps throwing things into the context and executing tools (as directed by the model) until the success criteria is satisfied.
The "rules" of using AI successfully are basically just the rules of any successful development team. Break things down into clearly defined chunks, make the success criteria clear and provide a way to get the right feedback on how the system is running (logs, metrics, traces etc).
From my past experience of religion at various levels I am very often reminded of borderline-cult religious meetings, and the zeal of converts repeating gnomic oversimplifications, and of how exhausting it was to try to engage with them on any topic of substance.
My own feeling is that it is totally OK to simply route around these people.
It's fascinating how many of the "keep your identity small" folks in the YC/HN sphere have lost any sense of perspective at the first sign of a technology that wanders into the philosophical realm. AI-oriented identities are everywhere.
Why is HN interested in management and team process discussion but allergic to similar topics on how to manage agents?
It’s like saying why discuss these team workflows when it’s just devs writing code. Or why use any jargon to describe workflows when it's just devs writing code.
Because like every other large social group it’s actually a collection of dozens of subgroups that have an overlapping interest
You’ll see those subgroups come out in threads like this and you’ll see other subgroups come out in different threads there is no singular version of hacker news that is always existing it is a collection of sentiments that from time to time align interests around specific topics
I’m sorry but this response is just absolutely ridiculous and is not giving anything near the respect to the author that you should have.
You’re just rambling and ranting about philosophical things and have basically nothing to say about the technical or engineering points that the author wrote.
This is a entirely emotional appeal and doesn’t actually engage the author where the author is engaging in the audience.
If you look further down thread there’s dozens of comments that are engaging with the content and not being hyperbolic about all this cyber shamanism or whatever you wanna call it
When someone is expected to be wizened and does not have the knowledge to keep up with the needs of those around them, they in turn become Shamanistic in their practice.
The speed of improvement on these models has been incredible and has outpaced the learning speed of humans and put many experts into these Shamanistic roles.
I think the operative means of addressing this is to recognize that we can only learn so quickly, but we are still called to improve our knowledge and understanding to a higher level.
Since the improvement of these models is neither logorithmic, nor exponential, we currently occupy a space in time in which the models are currently smarter on average than we are as a collective whole.
But it demonstrates that LLMs struggle with basic reasoning.
A criticism of LLMs is that they're imitating without a understanding of what they're doing and without a clear plan, so this inability to solve a simple logic puzzle is very relevant.
If LLMs didn't struggle with reasoning problems then something like ARC-AGI wouldn't exist.
You can fool an AI as evidenced by them being fooled. They demonstrably appear to be working through a problem and get fooled by the wording of the problem. If you think differently, merely asserting it is not the way to convince people that what they see is wrong.
An LLM is (effectively) just a really, really elaborate "choose your own adventure" book.
It's not "working through" problems, it's just tracing a route through an pre-defined information space. It's not actually thinking, it just does a good impression of it.
You can't constrain foolability to just the animate objects.
Foolability is based on intelligent processing.
To what degree such an intelligence needs to be developed is not defined at all (we can, for example, trivially fool a doog using one of many tricks, and a dog is hardly general intelligence).
Thus far, the inteligent processing we knew concerned animate objects. But we now have developed software/hw combos that exhibit intelligent processing. Is it enough to actually be intelligent or to be fooled?
We don't know. We do know it's enough to appear intelligence, convince people that it is intelligent, and to appear to be fooled.
But even if we think of LLM AI as mere mechanistic process with no emergent intelligence, who said one can not fool a mechanistic process? We can fool even simple pre-LLM gaming AI systems (based on simplistic heuristics) just fine.
They simply appear to "exhibit intelligent processing". The intelligence is in what created the data. It's a surface that's being traversed in a complex way. The LLM doesn't 'understand' that surface in any way, it just traces a path on it and reguritates apparent understanding. I'll grant it's eerily convincing.
'Fooling' something, essentially to deceive or trick, is defined as causing someone to believe an untruth. LLMs don't hold beliefs (neither do mechanistic processes), and they aren't a someone.
You can widen out the definition of the word but that generally makes language weaker - interestingly, semantic drift is a big issue for LLM's.
We have different opinions, and that's fine. Have a good day.
Please explain why the mechanism of the LLM generating output precludes it from being able to be fooled without using use tautologies or reducing to substrate for explanation.
We used a “loop” before it was called that to drive MS-DOC support into Tritium. Based on that experience, I take issue with this:
“There are already impressive examples of large automatic porting efforts, including the reported work around moving parts of Bun from Zig to Rust.” (Emphasis added.)
It will be impressive if/when the Bun team is able to pick up and continue extending and supporting Bun. For us, MS-DOC remains read-only and probably perpetually buggy until we reimplement with a better understanding. Until then, it’s definitely not “impressive”. Functional? Maybe. Impressive, no.
I am 100% for fully agentic loops... for tasks other than engineering.
I'm not willing to outsource the understanding how things work part of myself. That part of myself is what got me into computing in the first place.
If this work becomes simply a matter of describing intent to a machine (probably through an Issue, like a user), and going to check on the result when you get the 'done' notification: I'm done.
It's possible to use the tools to do awesome things without letting go of full system understanding of the parts that you look after.
> If this work becomes simply a matter of describing intent to a machine
What is it that you think you are doing when you are writing code if it isn't describing intent to a machine? Whether you are doing it imperatively vs declaratively isn't a new thing.
I'm a software developer from way back, using tools and languages that coding agents are far less familiar with.
So when I use an agent to write code, it's in languages I'm less familiar with, and often using libraries I know nothing about.
All to say, my part of the process often ends up being:
1. "Here's what I'm looking for, in detail"
2. "That's not right. Here's one way it's not right, and a specific example. Please fix that."
3. Sometimes I give suggestions for how what is going wrong might be happening, or conceptually how to work around the issue.
4. And iterate on 2-3 until the result is close enough.
> Present-day models tend to produce code that is too defensive, too complex, too local in its reasoning. They avoid strong invariants. They add fallbacks instead of making bad states impossible. They duplicate code, invent bad abstractions, and paper over unclear design with more machinery. Worse though: I so far see very little progress of this improving.
Context-smithing can help to a degree and cyclomatic-like complexity rules tend to make matters worse. So, you either roll up your sleeves or close your eyes and hope for the best. I've had limited success with the latter.
I've run into the issue a lot; I know it happens. I handled it manually for a while by just having a fresh instance inspect the code - "review this for DRY violations" and "how would you re-write this into a global architecture instead of a bunch of local code".
Eventually the list ended up long enough that I've got an agent that handles it. You've just got to treat "write code that works" and "write elegant code" as two separate tasks - either a fresh instance or an Agent will work
I am so over this. I cannot take anyone seriously that claims inevitability of their ideas, and how you must adopt them without "being left behind". If these tools are so good and so capable the result should be able to speak for themselves rather than this FOMO inducing, emotional language.
I couldn't agree more. Thus far I'm still objectively more productive than all of the AI enthusiasts I've worked with. I think a lot of the activity with these tools is coming from people who just enjoy using them more than they enjoyed coding. They feel more productive not because they are producing more but because they are producing somewhat less with much effort. It takes them roughly the same amount of time even if it changes the distribution of time spent on each task.
> and in recent weeks it has started to dominate the Twitter discourse.
As a general rule, I don't waste my time with the advice of people who still think Twitter is a source of wisdom.
It's especially rich when you consider the shitty code the "loop" produces. The article quotes Boris Cherny as if he's someone to look up to. But then you look at the code he produces with "loops", and it's an unmaintainable ball of mud:
the point of that section is that attackers and security researchers will use / are using loops, and you as the maintainer are not able to opt out of others doing this. an unwilling participant.
No, but you always have the option to opt out of being a maintainer. If "the community" is going to behave badly and bury you under a barrage of vibeslop you can just leave.
EDIT: there's a version of this that could be positive--everything could get a hell of a lot more secure. But that doesn't seem to be what's happening.
You're being uncharitable. I don't read it as intentionally FOMO inducing. I read it as the exhausted sigh of resignation from someone who sees where the wind is blowing whether they like it or not. I see it as someone watching tech management and execs listening rapt as Boris pours the poison of AI maximalism in their ears. I read it as someone who sees developers around them either drinking from that same poisoned well or bowing under the pressure from those leaders to adopt AI or lose their livelihoods.
It is true that the author is incorrect: you can certainly opt out, but you won't be opting out of AI, you'll be opting out of the industry.
"the industry" is not some monolith, and treating it as such is no productive. There are all types of software and many ways in which it is created. If the companies that are "AI enabled" are so much better we should see some big changes soon. But I'm still waiting for products I use from "AI enabled" companies to start churning out features at unprecedented speed.
> Present-day models tend to produce code that is too defensive, too complex, too local in its reasoning. They avoid strong invariants. They add fallbacks instead of making bad states impossible. They duplicate code, invent bad abstractions, and paper over unclear design with more machinery. Worse though: I so far see very little progress of this improving.
It’s almost as though these models were trained on a vast corpus of largely mediocre code. They will never outperform the median Github user - it is all they know, it is all they can do.
Show me the billion dollar solopreneur startup, or the profit increase for companies and at that point I’ll start thinking that this tasteless high level wanking might make sense in some way
This company got valued at $250M https://polsia.com/ and is a one person startup. Lots of people think its more or less a hype job but given "ai agents" have only really existed for a year or two now it's sitll early days.
One car went Mach 1, ever, apparently. Anyway, I don’t think the analogy fits. Ford or whoever didn’t loudly and frequently predict Mach 1 cars, right?
The situation is more like: Altman & co are predicting their new car will replace all vehicles: horses, trains, planes, motorcycles, there’s a real possibility the concept of vehicles will not exist other than cars, in the future. Meanwhile it hasn’t really done highway speeds yet. It does some impressive runs on curated tracks, and people use it around their farms (it seems to work ok for some of them).
Yes, one car did Mach 1. And the first production car, the Benz Velo, could only go 12mph. It's an apt analogy.
As I mentioned to OP, applying future aspirations to the current space is incorrect. Some people are able to understand the progression of industrial automation, some people aren't. But if you look at the current batch of frontier models and say, "I just don't see how this is going to be useful", then you're in the camp of those in the 80's who didn't understand personal computers, or in the 90's who didn't understand the web. In hindsight, the technologies evolved massively and found routine use cases that no one initially predicted.
I think my main contention about the analogy is that Mach 1 cars are sort of a ridiculous target, a thing that only happened once just as an attempt to break a barrier, more like a tech demo. Billion dollar startups are very rare of course, but they are real things that happen for practical reasons as part of the industry.
Saying that the person you replied to was looking for the former when they really wanted the latter seems uncharitable. Especially given that replacing most of the engineering department doesn’t seem to be too outside the scope of what some in the space are promising(?).
Billion dollar one person startups are a silly target too, because as we approach that possibility, society will adjust.
I know Sam Altman peddled this concept, but he's not representative of the culture and principles of the entire AI/ML space. So it was wrong of OP to attempt to use his words against the entire idea of neural models.
I do think the point that solo companies that could have been billion dollar start-ups might get a lower market cap if they can be done solo with AI tools is a good one. But that seems a lot more nuanced than calling the idea something like a Mach 1 car.
I think this is like pointing out that we lowered the speed of sound as technology developed, so a Mach 1 car doesn’t mean the same thing anymore, if we want the analogies to line up. Of course I’ve stretched the analogy well past any hope of making sense at this point, haha.
You have a nuanced view which I'm taking into consideration. I agree that if I'd spent any amount of time on my comment, I might have found a more apt analogy.
The OP's response, "It is a terrible analogy that shows terrible thinking," is however entirely ridiculous and taking my comment in bad faith, against hacker news guidelines.
As such, I do contend the analogy fits, even if it doesn't fit perfectly.
It is a terrible analogy that shows terrible thinking.
After all, there's one thing we can bet with more confidence on: delegating thinking to this mediocrity machines is affecting the ability to do the same in scores and scores of previously smart people.
Terrible thinking? Delegating thinking to mediocrity machines? "Previously" smart people? I don't think you can project your own limited and malformed understanding of the world any harder. Please go touch grass and learn how to engage with others on the internet without being so negative.
yes, it's just bad thinking. It's a malformed comparison that misunderstands the conversation.
Delegating thinking to mediocrity machines:
Based on the statistical nature of their underlying math, LLMs are by definition mediocrity-producing machines, especially if you understand the etymology of mediocre.
Maybe my understanding of the word is limited and malformed, or maybe you could try to develop one that takes into consideration the humanities, art, the sublime, love, emotions, and everything that makes humans human, instead of looking at the world through the small, mechanistic lens of the hyperengineerization of everything.
> It's a malformed comparison that misunderstands the conversation
I invite you to explain how, instead of just making unsubstantiated claims.
> Based on the statistical nature of their underlying math, LLMs are by definition mediocrity-producing mac
You're demonstrating a fundamental failure to understand the mathematics behind these models, by claiming that they produce an average result by nature. You fundamentally misunderstand reasoning manifolds, and how training teaches models new behaviors.
Phrases like "Based on the statistical nature of their underlying math" sure make you sound smart to someone who doesn't know better, but in truth the phrase is completely void of substance: What statistical nature? What underlying math? What about them prove your naive hypothesis that they can only produce "mediocrity", itself an extremely subjective term that leaves you a massive amount of slack with which you can retreat from your claims after someone asks for proof and clarification.
> Cognitive atrophy in people overrelying on LLMs and agents seems to be inevitable
I can pull studies that show reading and writing reduce some cognitive faculties, compared to oral tradition. Or how the use of calculators atrophies basic arithmetic skills: that's not going to stop astrophysicists from using number-crunching simulations instead of doing things by hand.
> maybe you could try to develop one that takes into consideration the humanities, art, the sublime, love, emotions, and everything that makes humans human, instead of looking at the world through the small, mechanistic lens of the hyperengineerization of everything.
Hey, so you're projecting again here. Massively. Nothing about this conversation has given you any information regarding my opinions on the list of extremely subjective and debatable concepts you've provided. You seem to harbor a belief that anyone who extracts meaningful value from these machines is actually a "terrible thinker" who is inconsiderate of the world and only sees things through a "small, mechanistic lens". Besides being considerably insulting, all this projection does is reveal things about how you view the world, how you view those who think differently than you, and how close-minded you can be, prejudiciously writing off someone as a caricatured personal bias in order to avoid critically engaging with their argument.
Honestly, this is a really sad and negative way to talk with others on the internet and you need to stop and review your approach to discourse. There is no value in considering to waste time talking to you until you change your attitude, so I'm going to end the conversation.
No, you mentioned his discussion of the "billion dollar one person startup", which we can both agree is a fanciful idea and more of an eventual "possibility" that will of course not occur as once anyone can be a billionaire, the whole system is going to change.
However, your "tasteless high level wanking" is not a quote from Altman, it's a vague and directionless insult that manages to sweep quite a lot of legitimate discussion about the future of automation and professional work under its thumb.
It's wrong because you're saying, "where are the billion-dollar one-man startups?" in the same way that I might look at a Benz Velo and go, "But it's so slow! Horses can go faster than that! Everyone saying cars are going to change the fabric of society are just tasteless wankers!"
The point is that you are applying future aspirations on the present-day relatively brand-new model space and getting upset that we aren't there yet.
I can't blame you when the first few sentences almost always evoke one of the "creators of XYZ" (I don't know how you can say a model or model harness has a singular creator when the model was trained on everyone's data and the harness was built by a whole team?) and treats their word or experience as gospel.
Who cares what Cherny thinks? He is selling his product, and he will probably cash out soon enough while his credibility is as high as it is.
Part of the problem is that models don't have a strong sense of taste, part of the problem is that the context in which projects exist is incompletely represented in the LLM context, and part of the problem is that LLMs tend to be myopic.
The lack of taste can be mitigated to some degree by improved training, though taste is not a stationary distribution in humans (see trends/fads/etc), we can at least better track the cutting edge. I think this area still has low hanging fruit but frontier labs are more concerned with being able to solve problems than the style of the solution right now (for evidence of this just look at the Opus 4.5 -> 4.8 arc).
The problem of incomplete context is partly a human problem and partly a harness/interconnectivity problem.
LLM Myopia is a harder problem to solve just by virtue training models on question/answer pairs. Countering this requires emphasizing RL on solution paths rather than just prompt/response, which is doable but harder.
> The lack of taste can be mitigated to some degree by improved training, though taste is not a stationary distribution in humans (see trends/fads/etc), we can at least better track the cutting edge.
The point of "taste" is not to copy from others, even if you can somehow filter out the trends and fads. And really, that filtering comes from personal experience anyway.
I have huge respect for Armin but all of the concerns about agents producing more code with less competent supervision from senior engineers doesn't seem that different from the status quo to me. A vast majority of all software I've ever professionally worked with has been terribly structured, hard to work with, full of bugs, etc, produced by mediocre to bad engineers and run by semi technical product owners or managers who basically promot the software into existence by making jira tickets on 2 week cycles to hold it together.
Yes it's awful, but it kind of works and has worked for a very long time. Agents are already improving a lot of open source software. Yes they're producing a lot of slop too, but having beautiful code, understanding how the system works and being able to delegate to a competent engineer you trust is reserved for the very few right now and I think we have all the systems and experience in place to deal with "bad" but working software so personally I am not concerned
Yes, a lot of software shops have produced equivalent slop, but I've worked on teams that aimed higher, and they were much more productive over the long haul – not just in fewer bugs, but also in straight up ability to add more features as the software got complicated.
Theres a deep insight in this post about the value of looping for throw away code to explore a problem space, rather than brute force a problem by just applying more tokens and hoping.
The more I play in this space, the more I’m drawn to the idea that some kind of back tracking constraint solver is a better solution than then the current naive while loop / brute force approach here.
The results I see are similar to what you get from a greedy brute force constraint solver; solves trivial problems, sometimes solves harder problems after a long time, takes too long to solve really hard problems; solutions are increasingly non optimal on average as complexity goes up.
We have so much existing knowledge about building good constraint solvers, if we could just figure out how to apply it here somehow.
We'd need a LLM back tracking constraint solver and I think the bottleneck will be good grading rules on whether a direction is actually architecturally clean or extensible. I'm not sure how one would approach that problem
There's a major problem with evaluating the result of agentic coding, and "loop engineering" exacerbates it.
Like many crafts (painting, music, etc) the true test of great software is time. Not because of taste, but because software is a living artefact that must evolve.
Only over time does a human developer realise they have "painted themselves into a corner" and chosen the wrong abstractions. And it will be the same with vibe coding (i.e. where code is not architected and reviewed exhaustively by a human).
Because companies won't surface their internal codebases, the most likely signs of such problems with be the reliability of applications and services. I don't know if recent outages are indicative of changes in code practice, or just coincidence, but we'll find out over time.
Agents aren't yet strong general reasoners - they are good at reasoning in the shape of their training corpus - so it's essential that important code is reviewed by human experts.
We've had great success with agents thus far at my job. A year into Clauding and all our dev metrics are up while our downtime has remained steady.
Being an iOS engineer, much of my engineering cycle these days is going from Figma/PRD → spec → code. After being handed off to QA, we handle the bugs and product slips as they come through, while we simultaneously build/spec the upcoming addition. This is basically the same agile style that's been popular for 20y, just super-powered with agents.
How might someone accomplish the same goals using loops instead?
I personally have not had good luck with loops due to similar issues as the post author - but if you were to port your flow to "looping" it would be something like:
- An automation that periodically checks for PRD's at a given location that have not yet been implemented.
- If it sees one not implemented, it puts a lock on it (so other agents later don't pick it up while its still working) and implements the PRD in code, assuming it has the figma link and all specs required.
- When its done it makes a PR, waits for if it passes and even in some cases automatically merges into your staging/preview enironments and just pings you with a build/URL. You can then leave feedback or something and it can also also poll for pending feedback. Or you just mark it looks good, the agent then merges the PR, moves the PRD to implemented status, maybe even writes/updates docs and cleans up any temporary work.
- Repeat checking for new PRD's every T unit time. (10 minutes, 1 hour, etc)
This is how people say you should be looping - you never even cared or looked at the code, and also never prompted the agent yourself.
But I find most agents are often pretty bad still at replicating UI vs making something from scratch and most design specs are still not as detailed around how things look at all sizes, in all scenarios etc. Design seems to be one of those things that still requires a human to validate. And then all the things the post author mentions about it not being willing to apply hard constraints, minimize impossible states, validate at edges and prevent horrendous overchecking of things. etc.
Would you have a breakdown of costs/benefit? Can you say with certainty that this workflow has increased productivity so much that you are seeing profit increases that you wouldn't have otherwise noticed just by hiring more people?
Asking with no ill intention, I just crave for actual business cases that make sense, and yet no-one seems to be able to reliably produce that.
> Can you say with certainty that this workflow has increased productivity so much that you are seeing profit increases that you wouldn't have otherwise noticed just by hiring more people?
Has the bar raised so much that coding agents need to be even better than any human could do? If the coding agent lets you get done with 1 person what would've required a team of three and you are not going crazy "token maxxing" spending thousands of dollars a week that would be beneficial for a business.
First of all, I don't accept a discussion where humans are placed on the same level as bots or agents. Even if the cost is the same, humans MUST be the choice. They have emotions, families, sons and daughters, they are a what makes society a society. And yet we've been already instructed and hypnotized by the Altmans and Musks and Bezos to only see it through the lens of profit and revenue.
That said, is what you're suggesting even happening? Because certainly that is not what we're hearing from companies that fucked up their budgets with AI tools.
Also, trillion dollars valuations are really justified by random solo-devs creating automatic companies of one that could be companies of four?
Because what I hear from the AI-accelerationist is "this technology creates productivity gains for each and every company by enabling automation at scale that would make replacing human profitable". Where is THAT?
> First of all, I don't accept a discussion where humans are placed on the same level as bots or agents. Even if the cost is the same, humans MUST be the choice
Sure but getting more done with less is just how productivity gains work. If your talking about crushing an iOS backlog like the OP is it surely will not cost as much as a human to move along tons of bug fixes and accessibility changes etc.
Use appium or XCTest or swift testing; generate the tests first (failing) from the spec.
The loop is basically then a while loop:
While (tests fail) { trigger agent: spec, failures list }
for bugs, write failing tests.
Its basically TDD.
Loops do nothing useful beyond making the “spec -> code” step more “hands off” and let you be confident that the code you write does what is intended.
Obviously you see the issue: writing the loop harness is > effort than not having it…
…but the idea is that you run “spec first” and are totally hands off on the code, just updating the validation step and then waiting while the agent iterates over and over to solve for some solution that passes the loop harness.
People suggest that it is possible to go, eg. directly figma/jira to harness via (random tool here), saving even more time and invoking even fewer humans, but thats currently, as far as I can tell, actually just hype.
No one is actually doing that effectively.
Loops are currently carefully hand crafted, which makes them tedious and of questionable value imo.
I have had some success with /goal for long tasks that can be set up in a way that the agent can do good work for an extended period of time.
A lot of tasks aren't amenable to that, and the ones that are still need a lot of care to be set up correctly. The default vibe coded codebase won't be.
I've come to think of the activity of choosing the right technology, the right architecture, the right testing setup, the right context, and the right /goals to use as programming the agent.
> /goal is a wrapper around a session-scoped prompt-based Stop hook. Each time Claude finishes a turn, the condition and the conversation so far are sent to your configured small fast model, which defaults to Haiku. The model returns a yes-or-no decision and a short reason. A “no” tells Claude to keep working and includes the reason as guidance for the next turn. A “yes” clears the goal and records an achieved entry in the transcript.
> The evaluator runs on whichever provider your session is configured for. It does not call tools, so it can only judge what Claude has already surfaced in the conversation.
Apparently, it uses Haiku (by default) to evaluate every turn to determine if the goal has been achieved. However, it only relies on the transcript itself (including the reasoning of the main model). It can't independently verify if the goal has been achieved. So, if the main model thinks the goal is or isn't done, how often does Haiku disagree (in a productive way)? That's not clear to me.
I've mainly used the feature in codex, where I've been able to get it to work for 5 straight days (with breaks when rate limits are hit -- which was surprisingly only thrice) on a massive port.
I don't know how well it works in claude code, but I wouldn't be worried about Haiku getting it wrong and don't see a problem with it relying on the transcript. I always set these things up to maintain a checklist of subtasks to do in a file and check them off, and to always implement with red/green testing methodology, where it writes and commits failing tests, then writes the feature/fixes the bug and commits with passing tests and with an updated checklist file.
So the model should always know from the transcript whether the current task is done by whether it shows the tests passing, and it should always know if there's more tasks left from the checklist file being updated before the commit.
>>> For now I have not moved past the point of comprehension being important to me.
I see software as new form of literacy, even in the AI world, so yeah in my world view, comprehension will be something we always cling to.
I might comprehend some code the way I comprehend the newspaper article on the second page, others I comprehend like a Dylan Thomas poem. My attention might be different but I still need to understand it.
Quoting the creator of CC holds little value in my opinion. I too call my product good.
> opting out of this fully machine-driven future may not be an option.
I am contemplating whether I want to stay inside this rat race.
I completely agree with the conclusion of this blog post, by the way. I feel uneasy, and I do not enjoy the work I deliver using LLMs. I think OP did a really good job on capturing at least my current state.
I and my friends go back and forth, every day, on whether coding with LLMs is a net plus or a net negative.
I'm at the point where I think it's dumb to not do it but also dumb to do it. I have no real answer.
I have settled on using LLMs for everything but to spend more time honing the quality and cleanliness with LLM passes afterwards than I generally would have taken to write it well myself in the first place. This is in some ways the worst of both worlds, but it somehow lets me bypass akrasia while still getting pretty good code out, so I consider it superior to how I worked before. I get more done in three months even if I get less done in a day.
I am with you here but don't get overly pessimistic: devising hooks and stopgaps and flows and constantly tuning what to watch out for does not only improve the quality of the LLM-output code. It hones and refines your own abilities.
CC has made some pretty dumb stuff in my projects but I don't resent those occurrences. They taught me (more accurately: reminded me, because I already knew but was not applying that knowledge too often) very valuable lessons on code quality -- that's still a dark area to this day and every ray of light on it is valuable for the future programming.
To me programming with LLMs made me a better programmer. But yes, I don't just rubber-stamp PRs.
It also finally allowed me to be less of a code monkey and more of an architect and a backend lead than before. Which I was really missing.
> but it somehow lets me bypass akrasia… I get more done in three months even if I get less done in a day.
I think this is going to be a big deal for many programmers in the long run. "Flow" comes from feeling faster as much as it does from actually being faster in the moment. Perhaps more. And yesterday's good experience leads to today's motivation.
> I feel uneasy, and I do not enjoy the work I deliver using LLMs.
I have basically stopped writing code in my spare time since the advent of AI. Before I felt like I was working on a classic car. Was it a practical use of my time? No. I could go out and download software that did what I wanted. Did I have fun doing it? Yes, the act of working on it was important, I felt I was still learning and improving as I did.
Nowadays I see people doing far more in a month than I could in a year and I feel like its all a waste, like I just spent the past few years transcribing a phonebook while standing next to a photocopier.
I don't know if that'll ever change. I can't even pretend I was doing something prestigious and artisan like watchmaking because I wasn't a good programmer beforehand.
Before I would just throw prompts at the LLM and it'd end up building a pile of crap (but semi-working crap, and 100x faster than I ever could) - it was pretty depressing. Using tools like `grill-me` (or `grill-with-docs`) I feel like I'm actually building my understanding of the system and helping shape it, and the results are much better.
The fun part about that `grill-me` command is that when the questions are over, I've found that I can go right into implementation without needing to dump a PRD or some sort of broken up plan. Now this is obviously completely predicated on what you are asking it to grill you on. But for tasks that are semi complicated, it's fantastic.
I was misunderstood you if you intend to write code by hand, I still did, I use AI to learn by example, but I write the real code myself, AI can help me improve the code. I learned a lot.
I used to think I'll be into coding for the long haul, contributing to open source, and working on multi-year side projects.
Nearly all of that passion vanished this year, and I've been struggling to replace it. I know I'm much better than the machine now, but the lines are starting to blur, and some of the small puzzles of day-to-day have been completely automated away.
We've birthed a lot of puzzle solvers that enjoyed programming, and I'm sure many of them will move on to something else that scratches the same itch. I'm keen on learning what that will turn out to be.
I'm the opposite, couldn't be bothered to work on code outside of work. Barely did at work because I was more focused on wrangling a small army of shitty contractors (thanks strategic partner initiative for firing all of our small shop contractors and replacing them with morons from "offshore").
Now with LLMs I find myself doing small projects that interest me or have some utility for me outside of work, and doing a lot more development in the codebases at work outside of just review/docs/arch than I was before. Also making small tools that I find pleasant/useful but were not important enough to spend time on before.
Agreed - there was always a set of things I wanted to do that I knew the magic core for, but wanted a team of implementers for the curft, the 100k of actual testing harnesses, hyperparameter exploration, etc.. . I now have that team of implementers. All the problems seem research-y though - optimal binary transport systems that are zero-copy and compatible with languages, fast physical simulation optimizers, etc etc... So, things that all had a _LOT_ of busywork around the magic core.
I'm still trying to figure that out. Something diplomacy-adjacent would be interesting to me; maybe conflict studies, or international relations.
Based on word from my friends who work in the field, a lot of it is people who have a lot of respect for the field, and a lot of professional respect for eachother. It's also a field I feel is unlikely to suffer from the same kind of scams that are taking over software while still offering an engaging environment.
It's also work with real-world impact, which is nice, though obviously comes with its challenges.
> I am contemplating whether I want to stay inside this rat race.
Same. I'm currently trying to find _my next thing_ and all anyone wants to talk about is how I'm using AI and it's absolutely maddening. It's become a lazy, lossy proxy for productivity. I've had a few intros for the types of orchestration engineering roles which are described in this post and they're just completely unappealing -- especially the prescriptive aspects. Like, the sort of JDs I'm seeing are variants of, "we want a back-end developer who has experience with XYZ but they must use agentic harnesses to do their work." Why does any serious person give a flying fuck how the end result is reached? The flip side of all this is that rates are also being driven through the floor by loop cowboys who are generating steaming piles of shit which are _good enough_ ... until they aren't. I'm being completely serious when I say that stocking shelves at Tractor Supply is becoming more appealing by the day and I also just thought to myself, "Maybe I should just join the Army while they'll still take me?"
Reading the comments here, I'm struck by how many people seem to view code quality as an optional thing. It's almost as if software can function correctly without it. But it can't. Code quality is not a nice-to-have, it's a must-have. For any moderately-complex offering. There's a certain level of complexity that you can never reach without a well designed codebase. Cannot reach no matter how many humans or AI agents you throw at the problem.
The idea that it's a 'nice-to-have' is an illusion. It's like if you borrowed a lot of money to fund your startup and you still have some cash in the bank; at that point, a viable business model might seem like a 'nice to have'.
It's only when the lender comes knocking and you don't have enough money to pay them that a viable business model suddenly becomes a 'must-have'.
One thing that I'm certain of, is that there are always costs to writing more lines than what is necessary to solve a specific problem.
I've experienced this before AI, and I've experienced this, magnified, with AI.
For a well-designed project written by hand, you will work faster writing the code for new features by hand than the same project written with AI from scratch, using AI to write the new features.
But... If you have a well designed, human-written codebase, you will be faster if you generate the code for new features using AI than if you do it by hand... And you can maintain that speed for long periods of time if you use fine-grained prompts. What matters most is the quality of the codebase.
You can achieve the same degree of maintainability using AI from the beginning but you would have to make fine-grained prompts.
The gap is about making good engineering decisions. It just so happens that the value of good decisions compounds over time.
I can't help but be tired of the LLM trendy, where people bang at loops until they hope the model sculpts something. It feels so empty mentally to just have results without constructing it.
That said the idea of loop has always been there (iteration, V cycle etc) but I'd be glad to find people with more theory and less agents swinging blindly so to speak.
The most important part of working with agents is removing tools, especially tools they like to use. Do not let them use cc, make, git etc until it's a necessity 90% of changes introduce a bug? ok you can start using gcc/clang/rustc whatever. Tools generate too many tokens, and it can't be fixed by '| grep' since they just start spamming cli calls.
At least this is true for antigravity it tried to used git a few times and I gave in and then I discovered there was a token limit. Velocity plummeted. If you want git before it becomes a requirement best to mirror the directory into a separate git repo.
The author is spot on about the paradigm change of software as a lifeform. Living things provide us with genuine interactions and experiences of learning and growing, without forcing us to understand the code - You can learn to work with animals and plants without understanding their genetics at all. I believe this is how our relationship with software must develop, and in order to get there, we'll need to learn to design and develop software in a completely new way. I've been testing this hypothesis in my spare time, hacking together a server-browser system I call Mycelium. It's a bit like OpenClaw, except you can use it to create private local Webs, and print custom 2D Electron browsers to view and work in these webs.
Yes, you found it. Blancs is the
browser prototype for non-technical users, but the full system, Mycelium, I'm currently working on
towards demos and distribution. I'll be sure to update the YT channel, if you want to follow the progress. I'm also on Twitter @livingsoft_
I feel like what should have happened with AI is that teams should have started to put more effort into planning and pre-implementation discussions. Second thing, team leads should have felt more comfortable to reject large Pull Requests.
When I see a large 10k-lines PR, I feel a sense of panic. In a corporate setting, I also feel a kind of pressure to approve; the more work was done, the more pressure there is to approve the PR. This is why I think up-front pre-implementation discussion and alignment has become essential.
You really can't have people going rogue and weaponizing their AI-generated lines to gain control of a project through the duality of brittleness + complexity.
Generally interesting reflections here, yet I see the same kind of myopia and fatalism that is rampant in our (fashion) industry:
> yet I have no doubts that this looping future is going to be our future despite the fact that I presently resent it
Why would anyone concluded this? LLMs are just one kind of application of MLs to software production. There is a vast solution space for automating parts of software production. The idea that slop loops are the inevitable future because they happen to be accelerating output at the moment just seems profoundly short-sighted and lacking in vision.
A friendly reminder to just do 9 to 5 and touch lots of grass. None of this shit represents industry trends, majority of people still use chat interfaces and copy blocks of code. There’s zero early adopter advantage here, only FOMO and lots of anxiety.
I think a lot of people here have either not read the article fully or are misapprehending it.
Neither this author nor most other sane people I know claim that the code or architecture these "loops" produce is great. In fact, the author explains how it is not great.
His point is rather, that we'll increasingly see a world in which code quality and maintainability by humans will cease to matter for a lot of codebases.
There might be many software companies in the future which successfully sell software products which were created without a single software developer being involved in its development or maintenance. The code might be bloated and bad - but it doesn't matter because machines can still create and maintain it cheaper and faster than people can.
I already see this happening at a small scale at the place where I work. Product managers with zero coding ability are attempting to create entire new product features on their own using Claude or Codex. We do not let them merge this stuff unsupervised but in some corners and in new repositories they are publishing stuff that they have barely spoken about with a developer. They are just doing it. We'll see more of that.
The issue is that whilst the loops will initially lead to good results they will be less and less as context gets bigger and bigger and tougher to understand for human and AI.
Andrej Karpathy says, “You can outsource your thinking, but you cannot outsource your understanding.” The catch is that we need to think in order to build understanding.
This blog post pints to the fact that you need information across scales to make really insightful products and software. You need to understand fundamental mechanisms, strengths, and risks of your software to know where to make bets next. You need to know about the “how” of your optimization system to know which customer asks to deny.
Using layers like the loops described here to abdicate your work is you decoupling from the joint market/engineering value you originally provided.
In my own ham-fisted experiments with coding loops, one pathology I have noticed is that the LOC just spirals out of control. That's likely because of the layers of defensive fixes, etc., that get built. That inevitably causes context bloat (or at least navigational friction) and results in quality decline.
I wonder how many loop-related issues could be addressed by simply fixing a LOC budget, or assigning a cost in some way. Unclear how you would dial in the right numbers, though.
I am torn. I have fallen in love with vibe coding but I still am in love with the software I’ve used for decades that works reliably.
Vibe coding gives me what I need and want right now. Its fast. Fun. Always makes me feel validated.
My older software never changes. It’s constantly telling me no. When it gets mad, it throws errors at me sometimes! But I can’t leave it. It runs my life and I know it will take care of me for years to come.
And the vibe code it’s so flaky… and expensive. It sucks up endless amount of my time, compute, and money and never gives anything back.
But it’s so fun. I tell all my friends about it and they’ve become so jealous they sought out their own vibe coder.
We’ve all found our vibe coders are a bit kinky. It’s become a social thing amongst my friends to talk about building cooler harnesses to control our vibe coders.
I don’t know what to do. My old software pays the bills but she keeps threatening to dump my ass on the curb and replace me with her own vibe coder.
I know she can’t really do it. She needs me too. And I need her.
I think this is a common sentiment among heavy users of AI that also still cares about code quality.
I've built up a skill harness and review flow that makes Opus generate slop-free code 90% of the time. But the remaining 10% requires me to stay at the helm. Especially in the early stages.
I would love to use loops to automate more, but I couldn't do it with the current generation models.
And on the back of my mind I'm still evaluating the possible future where we are forced to API pricing. I'm currently paying $400 for Opus, and use around 1.5-2 billion tokens per day. This will cost around $20k/m with API pricing. And I don't want to even imagine the possible scenario of getting locked out of frontier models because of politics.
Will the models get better to cut me out of the loop completely? I believe so.
Will the open source models catch up tho SOTA models, and diversify from China-only? I hope so. Otherwise 2 superpowers will wield a soft power that can cripple the tech industries of all other countries.
The bottleneck has always been the 'verification' and 'trust', that's why we have senior engineers, same way you need a head architect sign-off on a blueprint, because when things go bad you need a human agent to be the responsible party. Even if we manage to teach a herd of dumb AIs to produce massive amount of code, who's going to trust that output with their life?
That's the entire topic - loops are not just infinite output, they require automated verification and progress evaluation steps.
The game is to find ways to automate that. Not fully but yes to reduce what's required from humans. Seems like you're questioning the entire premise rather than pondering how far it can be taken and how.
> Ideally all of that was also well documented. Where that understanding was lacking, it was generally regarded as something to improve upon.
In my experience, this was always an unrealized ideal. Too much pressure to ship, not enough to learn. To me the fact that I can interrogate Claude about this stuff is almost as valuable as the speed. (And I think it helps Claude too.)
There's _way_ more than one way to do "loops". I just asked one of my superviors/auditors to document how it's been working while monitoring a few other agents that have long-term goals:
These new AI trends are very tiresome, very similar to 2021 crypto mania - both trigger a lot of FOMO. If we have loops that write code and we don't need to verify anything, why are the devs still here? What's point of even learning this new trick as a dev if you truly believe that this can be used without any intervention? If loops work then it follows that a loop of loop works too - why hire any people at all? Just run a bunch of loops and build a profitable business, but then what's your moat? Any person can now launch loops on top of loops.
Pretty much the same with LLMs as in other contexts. You set up a system where LLM output is used as input (a new prompt) as well. Or you have an external system that repeatedly prompts an LLM to "continue" with what it was doing before, perhaps examining some test results to massage the context window first, etc.
I honestly wonder if this kind of stuff really brings something to the table. Like I use opus for sometime and certainly I can put it to good use and optimize some parts of my day to day job (programmer). But it fails so hard in such simple tasks that it seems to me that putting it in loop can't just magically make everything better, unassisted. Does anyone actually uses agents and loops to create new software, new technology? Has anyone created with those systems, software they couldn't produce otherwise technologically wise? Or is it at best just an accelerator, cutting off on the building time?
I'm willing to be persuaded otherwise: Looping seems to (currently) be a side effect of token subsidies.
If token costs are nil, then you can afford to run verification and generation through the same models. If token costs are high, then you will go broke verifying code sprawl.
Currently costs are (mostly) absent from the conversation, even though costs are what decide the limits which shape experience.
Also: Firms can be held liable for the products they sell, so if code cannot be reviewed then that code is essentially a law suit waiting to happen. I believe this is what customers will be demanding in the future: someone to hold accountable when things go wrong.
I think there's 2 important, but separate, ideas in this post:
- Models are not good at or getting better at creating strong invariants, which his fundamental to good software
- It is unclear how to keep tabs on what the agent is doing, so you, a human, can intervene.
These are related, obviously: one of the highest-leverage things you can do is force you agent to use a strong, minimal set of types or data invariants or other constraints. They get much better when your codebase broadly supports this!
I do suspect they're separable, though.
If you had the right levers and visibility, you should be able to get the model to produce code that doesn't feel like slop. But every time I've had a model try to keep me in the loop, it inundates me with irrelevant decisions and busywork. Its inability to see what's structurally important still shows up, just differently.
[If the models get better at defining and respecting invariants, maybe there's a new flavor of slop, that's less obvious today.]
Was everyone collectively lying over the past fifty years of software development when they repeatedly said more != better?
For specific use cases, performance and security and all sorts of tuning it could be truly amazing. But maybe loops should be like a tool we make a choice to use when optimal.
I just wonder if in the future we’ll come to realize that we don’t have to throw the baby out with the bath water. That you can take a beat to understand your code and do change management, and choose the right tool for the job, and curate and say no and have agency.
An observation might be - no one writes code like Google “you’re not google” is something that gets thrown around in software shops all the time. Why is it we all think we’re going to be writing code like Anthropic?
This is really terrible advice right now for most people.
I've had to rip out a lot of pretty terrible code made by engineers who have tried this.
I don't disagree that eventually, "loops" when combined with unlimited tokens and amazing models in the hands of people who know how to set them up right will be amazing. But for the typical Claude Code user, it's disaster.
The problem is not that loops write bad code once. Humans do that too. The problem is that loops apply local pressure repeatedly: add a fallback, add a guard, special-case the failing input, quiet the exception, satisfy the test. Over time that selects for code that is more survivable in the short term but less intelligible in the long term.
This is a very fatalistic take. While I understand where it's coming from, I try not to share the same mindset: engineers getting increasingly distant from how things are getting built is not something that will "undoubtedly happen, whether we like it or not".
Also:
> Now there is obviously a question if this desire to understand the code is one that I will still have a few years from now.
I do not think we should be having doubts like this. Either you consider understanding the code you ship and allowing your future self to be able to work on the system you're building to be a value, or you don't. I, for one, do, and I do not think using LLMs and coding agents will affect my point of view on that.
The post suggests fear about a surge of increasing amounts of code by loops and loops of agents.
I don’t know if I like the current world without it though.
80% of different teams code the code is poorly tested. The code doesn’t handle data consistency or asynchronous code properly because the engineers don’t know better (and frankly don’t care enough).
Dependency handling is poorly managed leading to low quality operations with improper dashboards, alarms, and ops.
Badly managed processes leads to people doing monkey work signing off checklists rather than automation.
Frankly… why is keeping any of that good? It really pisses me off seeing people accept any of that low quality but that standard is the default and not the outlier.
In my experience I could never leave the agent off and go on its own. That is while I also use them extensively for all my work.
I still cannot wrap my head around people who spawn tens and sometimes thousands of agents hoping for the best and then saying how little token limits are. The only way that is possible is when your work is superficial and you have no idea what you are doing (or it’s a hobby project).
As much as I like Claude Code, Boris has done a lot of harm by encouraging software engineering practices that lead to slopware. We have two camps of people at work, the first camp are the agent goes brrr. They don't understand the code they write. They have loops running, agent orchestrators or agent hype du jour. The second camp is people who are inundated with PRs, are holding the line on quality, and just exhausted. We've also had some management pressures where they think people are wasting time looking at code. Perhaps because some podcast they might be listening to, somebody says coding is largely solved.
> I don’t prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops.
This is going to be a net negative on software quality for people who take this up, in my opinion.
I call out Boris but I also don't think he's being malicious. He's at the center of an important technological revolution and it would be hard not to get excited. I just wished he advocated for a more balanced and a realistic perspective.
Maybe I'm being defensive, but the problem with this chart is it assume a binary of good dev/bad dev; AI makes the bad dev worse and the good dev better.
However, I think I once was a pretty good dev, and AI use is slowly turning me into a slop cannon. The temptation to use AI in place of real understanding is too strong.
I'm sure you'll say I was always dead weight, but I just want you to consider the possibility that AI might erode the capacity for good devs to handle discomfort, turning them into bad devs.
I wonder how much of the turbo brain developers time is spent on reviewing the code of slop cannons and how frustrated they must feel.
Previously, everyone was limited in their blast radius but now AI has levelled the playing field where even a single slop cannon be the bottleneck of PR reviews or even the company itself if not right now, then later, as the codebase turns sloppified which will have its ramifications later on.
Everyone might suggest with the diagram to be the turbo brains but I believe that we also need to reduce the metrics that slop cannon is achieving (surprisingly LOC which is a pretty bad indicator) and to be more reasonable throughout in realizing such bottlenecks and to follow good security practices throughout.
I detest Elon Musk but I still use Twitter because there just is no alternative to it if you want decent tech discussion.
And I don't think it's smug or dickish. I like AI and I encourage even inexperienced software developers to use it. There's just no denying that the slop cannon phenomenon is still a very real phenomenon.
I’m thinking more of the “Dead Weight” and “Turbo Brains” boxes as being particularly eye-rolling.
As for tech discussion, of course there is an alternative. Practically every tech account I used to follow has migrated to Bluesky or Mastodon by now. The accounts left on Twitter have a distinctly narcissistic, preachy vibe. These people care more about “influencing,” not engaging. (And obviously they have no problem with the new ownership.)
> I call out Boris but I also don't think he's being malicious.
From a market perspective, he's acting completely rationally in his own interests. Bottom line is that these companies need to do whatever they can to keep growing token consumption because that's their goal.
If the nation's drinking skyrocketed, we wouldn't be sitting here wondering why the CEO of Budweiser isn't advocating for temperance. His job is to move kegs, just like Boris' job is to move tokens.
I never understood this perspective. Just because a person's behavior is market-rational, it does not mean they can't be criticized for externalities.
That is, in fact, an important thing to do. It turns those externalities into public perception, which turns into market forces that adjust the behavior, if you want to think purely in market terms.
The analogy with Budweiser is not a good one. This would be the CEO of Budweiser actively pushing more drinking while the nation's drinking was increasing. And yes, people would be right, and effective, to oppose this (see Oxycontin).
As soon as you open up the externalities discussion, the wider question of increasing electricity prices and turbocharging global warming comes up, not to mention RAM prices. AI is a machine for turning negative externalities into stock prices.
I don’t think that’s always true. Backlash is a real thing. It doesn’t always work, but it doesn’t cost much and it’s a lot better than blindly accepting the situation.
"If it's not them it would be someone else" probably should just be shorthanded to the banality of evil. But to answer your question, idk, sensible regulations? (Knowing full well this just kicks the buck of responsibility down the chain)
For AI overdependence specifically, continuing to
be a thinking human is resistance. Eventually the pendulum swings, you can't outhype reality forever. People will have outages where nobody human can explain why and the orgs/people who maintained understanding will survive better.
FWIW, the CEO doesn't seem to be the CEO? If I understand what I read properly, he has one direct report — his "chief of staff". So arguably the true chief executive in a functional sense (the person to whom the organisation ultimately reports through hierarchy) is his sister, who appears to be grounded in reality.
I suspect that the reason Anthropic is generating such developer-negative, toxic, insensitive influencer sentiments like these from Boris has to do with Dario being a fantasy-fiction-reading quasi-mascot who thinks it's his job to tell scary stories, who is being allowed to do just that by a sibling who perhaps prefers he's not involved in the day-to-day.
Respectfully disagree. From my view, the tech industry hasn't behaved in a way that regards long-term interests over short-term interests in a very, very long time. Much of the innovation is simply finding new and creative ways to shrink this loop even further, and vibe-coding/slop is just the latest manifestation of that.
> We've also had some management pressures where they think people are wasting time looking at code.
I feel like this is the actual problem, but it's not being talked about enough.
Logically, it shouldn't matter how a piece of code was written. It either meets our engineering standards or it doesn't. That's what code review is for.
But what has actually happened is that, because we have AI now, many organizations have normalized practices that weren't normal before, like submitting 10000-line PRs. And just, in general, submitting code that you yourself don't seem to fully understand.
If management doesn't push back on such things (or will even push back against people who try to do so), then reviewers have basically no incentive to push back either. Before I left my last job (for unrelated reasons), I had entered this mode, wherein I decided I couldn't really carefully review these monstrous AI PRs, while also getting my own work done, while also not burning out. So I chose the latter two.
If an organization decides the engineering team should not be looking at code, that should be coupled with a mandate to figure out what good engineering looks like working that way - what constitutes a good contribution vs what's slop? How do we handle massive PRs? The problem is we are in the "messing around phase" of coding with clankers and have much to learn still
Reading through the thread, it's striking how many people are feeling the same mix of excitement and exhaustion you describe. I'm in that camp too... the tools are incredible, but the pace and expectations around them can feel overwhelming.
I fully agree with what you say regarding Boris, but I would emphasize that I don't think he has malicious intention either. He still is doing his job, to showcase the features their product offers.
I don't like the framing of this, but I suppose it's inevitable given how every other political issue has been framed to date.
There are many camps in between the two being described. There are those who use maybe $20 worth of unsubsidized tokens per month to accelerate their work. Full-time human in the loop, every LOC still reviewed by hand. Also, the developer who still does copy-paste in and out of ChatGPT. Those tribes exist too and are way more typical than these extremes.
Yes, I am exhausted. Most of my company is obsessed with agents, because everyone wants to be seen as AI first. There is little thought going into usage. No care for long term maintainability and quality. Our product is actively worse by many metrics, but no one cares because we marketing can say “agents”.
The sad part is that this technology is incredible. It’s us choosing to turn it into a slop cannon (and the labs sure seem to encourage this).
Same here, I think the tool is fantastic, it has helped me in lots of way professionally and for hobby projects involving skills I'm not experienced with but I'm absolutely exhausted.
The worst part is that I'm not exhausted from my work, I've been through a heavy burnout before and had to adapt my ways of working to not fall into that kind of exhaustion again. This is different, it's not a pressure to deliver anything specifically, no stupid deadlines, it's so much more vague than any other kind of work pressure I've been through in the past 20+ years that it makes it much harder to find ways to keep my head straight.
It's exhausting to be reviewing boatloads of PRs of very varied quality. I have relegated myself to block merges at the first sign of a bad/weird design instead of trying to understand why it might have needed a compromise in the design, many times people couldn't even explain to me why something was written the way it was... After many "it was Claude that decided this way" it became so tiring that I don't even ask anymore, I just leave a comment on the first blocker I find and reject the PR. If people are not putting any effort to review it before throwing it at me I will just return the favour.
Reviewing AI slop is data labelling and it isn't very different from what people in 3rd world do labeling various images. Constant context switching is what causes the exhaustion. It's the equivalent of the 6pm stop and go traffic. You used to be an F1 driver. Now you're an instructor for bad drivers.
The journey was as important as the destination if not more because it gave confidence in oneself, it made us grow. I mean to suggest, coding for the sake of coding
If I may ask you and others, I assume that you are at a relatively decent position within your company and have somewhat say in it. Why aren't employees more honest about AI and concerns regarding it? I'd imagine that people must chalk it up as saying that there is push from investor side into using AI and management is forcing it but couldn't more effort be also redirected towards the fact that agents are still finnicky sometimes and that the sustainability of projects moving forward is going to be a major issue to investors given that they want sustainable growth.
It is my opinion that there's more hidden power in engineers that even we fail to realize and instead some of us like you are wanting to leave the industry, what a sad tail of tragic events, when the tech behind AI is good and could be helpful but oh holy, we are butchering it up so badly in some/so many regards perhaps even under the influence of AI companies and their messaging surrounding it.
> If I may ask you and others, I assume that you are at a relatively decent position within your company and have somewhat say in it. Why aren't employees more honest about AI and concerns regarding it?
We've tried it where I work at. People put effort to compile studies, to collect testimonials, catalog and organise the strengths and weaknesses based on engineers' experiences with the tooling.
The result was the person driving this effort getting asked by HR, their manager, and their skip manager to stop with the anti-AI rhetoric, that AI is the future of the industry and if not rolled out in this way we will be left behind.
> I'd imagine that people must chalk it up as saying that there is push from investor side into using AI and management is forcing it but couldn't more effort be also redirected towards the fact that agents are still finnicky sometimes and that the sustainability of projects moving forward is going to be a major issue to investors given that they want sustainable growth.
The C-level doesn't seem to care, they believe to be in an existential risk where any price paid to rollout these tools as wide and broadly as possible across the whole org is small compared to being left behind.
It's all fueled by executives and investors anxieties, there's very little left for reason when fear takes over.
Was the effort just directed be a single developer though. I have written elsewhere on HN[0] about something I have witnessed but I have seen that if only a single developer is actively against AI, the management actively believes that it is only that single person who is the bottleneck/issue as nobody else is complaining so it must all be right.
Although I get the overall statement more now as well.
> It's all fueled by executives and investors anxieties, there's very little left for reason when fear takes over.
This perhaps seems to be the greatest reason and I imagine that because all growth within economy is shown to be floating within AI related sector, they want piece of that pie. Do note that most of the issues with it is that the frothy evaluations and how much actual growth is happening downstream rather than just money shaking hands and the bubble nature of things.
but theoretically one can see that there is no winner in all of this no matter how deep one can fall down in layers of. Perhaps something at the layer of DRAM and chip production seem to be the one actually the most profitable at the moment and even they are just witnessing some temporary growth as nobody expects the prices to stay at this ceiling including said companies and yet they have incredibly floaty (but comparatively less so) valuations as compared to other AI things.
On one hand, I expect money to be rational yet on the other hand I am actively witnessing money to be irrational. Yet the whole industry is so muddled up now with so many people wanting the piece of cake of that investor's dollar that I imagine the market somewhat saturated.
Could something rationally not happen because if so, it seems that the thing might be that the burst of the bubble might make the only rational sense of adding realism in the market, but I imagine that it might spook the investors too much too and it might cost too much blood-shed in the markets.
Am I able to explain myself and do any of you believe that there is a rational course of action which can be taken to help stabilize the economy in some aspects?
> Why aren't employees more honest about AI and concerns regarding it
Because it’s being pushed by the c-suite and board, so most people aren’t in a position to push back. And it’s a quasi-religion now, so even pushing back at all can result in being branded as a “skeptic”.
People do raise concerns, though. And the responses aren’t very satisfactory. For example, the biggest concern that has been raised thus far is open PRs, and the answer has always been that all we need is AI code review.
I think that the problem basically arises due to the fact that the technology is recent and the opinions on it are hard to make and even if we do end up making opinions, then my opinion is of the fact that I am more than happy for AI to suddenly vanish but clearly that can't be the case and there have been some long term discussions that I can point out to.
We can however change our opinions on AI and the culture surrounding it but as witnessed from my comment and other people replying to it, the question is becoming as of if we engineers even have the necessary power capable to bring so the change within how or if we use AI.
That is why, I believe that we might need some nuance rather than a complete acceptation or complete rejection of it.
AI is like a double edged sword, something which is fundamentally both good and bad[0] It is my opinion that currently, the bad outweighs the good and I have been vocal about it, but the control of the matter is strictly beyond one or even one good/bad binary.
The primary issue of the matter is the fact that some people (mainly the C-suite/investor class) believe in so much of the goodness of AI that they are willing to think that anyone pointing out anything bad of AI is the one who hasn't used it and how there are all these anecdotal evidences of people being impressed by model's quality and its evolvement, so surely, if AI must have grown so much and is so good as everyone says online it is (within an internet thought bubble), the fault must be lying on the engineer and he must be one of those luddites who has failed to accept technology and must be replaced.
I suppose some people genuinely believe the above paragraph that I wrote. I have heard some of such sentiments on Hackernews itself...
My point is probably that AI should be treated as a double-edged sword really, that's about it. We can go into the details of it if you so prefer and I think that you are right that its within the nitty gritty details that there is ambiguity and how this discussion leads to that ambiguity, so in that sense I concede but that there should be a better more skeptical discussion regarding the use of AI and it should be up to the organization at first for them to decide how they use AI and be flexible with it but not at the sake of the sanctity of code and coding practices.
I feel like it would be hard to gain a worldwide consensus on the use of AI within software development, we can certainly try but it would be more effective to do so at an organizational level and to slowly level up and I do hope that the world eventually figures out a somewhat consensus of it.
Hope I am able to explain some parts of the severe personality split, this did get long but that's probably because I have just watched some somewhat thought provoking media which used some great vocabulary and I am somewhat copying it as my brain thinks about your comment.
But yea, in all honesty, that's about it. got a bit long so sorry about it but have a nice day and thanks for reading if you did and if not, thats fine as well and I hope you and everyone else including me navigating this somewhat shit hole that has become internet discussion about AI and AI in general, things are getting exhausting and there is some negativity in life at times but I hope that we overcome it and I am optimistic in some sense and I wish nothing but good for all of you within your future as we all navigate the uncertainties of future together :-D
Thanks for the detailed answer, which pretty contrasts with harsh brevity of my comment (sorry if it offended you), I wish you well too of course, me myself being a half-techie/half-artist torn about this double-edgedness of things, I know why there's that split, we all adore the figurative hammer that helps driving nails into walls, but hate it when someone starts using it to drive nails into their or their neighbor’s heads.
But I think everyone, sooner or later, must draw one's personal red line in the way of a hammer that is set to replace humans or turn them into reverse centaurs who forget how to use their own brains - be it by its nature or by the pressure of someone's trillions of dollars.
I, for one, have already drawn one and refused a promotion (which would mean a 2x higher salary) at my work from testing to backend development, because everyone in our development team rushed into using AI agents, which is something I don't want to touch with a 10' pole. That wasn't even the team's decision, it was the company owner's, who decided it's the way of future.
The results were not long in coming, I already hear their complaints about getting lost in the codebase they themselves created, and getting dumber.
> we all adore the figurative hammer that helps driving nails into walls, but hate it when someone starts using it to drive nails into their or their neighbor’s heads. But I think everyone, sooner or later, must draw one's personal red line in the way of a hammer that is set to replace humans or turn them into reverse centaurs who forget how to use their own brains - be it by its nature or by the pressure of someone's trillions of dollars.
This analogy is quite beautiful.
> The results were not long in coming, I already hear their complaints about getting lost in the codebase they themselves created, and getting dumber.
I think that there are some ways that people are trying to create an AI-use policy, here is one that I found on hackernews which I found interesting: https://libls.org/ai-use
Basically, I think that if its a personal thing then sure all bets are off and you can use vibe-coding or whatever on personal projects or prototypes
BUT, you can't really let AI do your job and somehow justify it and its costs (both in terms of tokens and the cost of tearing down the codebase with slop) and there should be a strict code of conduct regarding AI-use.
I feel like we are going to see more attempts at trying to solidify a procedure regarding AI-use and for me, the libls.org/ai-use makes somewhat sense and I'd be curious to think about your opinion.
That being said, it might not still be used within the structures of large companies because of the C-suite/investors issues that I mentioned but I am hopeful that eventually the mania regarding completely unfiltered AI-use slows down.
I have given up on spending more time reviewing PRs and help fixing bad decisions made by AI because all it does is encouraging the same thing without learning. Next PR will most likely contain similar design / code problems.
I can't speak for all orgs but at the end of the day, the only metric that my org cares about is how AI is improving our work. Holding the line for quality is definitely a good thing, but when your org doesn't care about the pressure on PR reviewers, and the effort it took to fix those PR mistakes or their repeat, those reviews are only helping the loop case and that AI is without flaws. I am not saying AI is a bad thing all together, but when the org ignores those metrics, I am only contributing and helping to prove that the other side is right.
As long as the LLM can unravel, repair, and improve the slopware it creates, that's where we are necessarily going. The code will continue to be maintainable, by the LLM. I'm used to this idea and I for one welcome...
I think at the end of this we'll have a new software engineering paradigm.
Mostly nobody now worry about binaries or instructions because those are for the compilers, even undefined behavior are mostly ignored.
You can either tailor the development pattern for LLM, or have LLM come write for the same old development pattern. I think there is going to be a difference.
We will have a new software engineering paradigm and it is called quitting to become a day drinker.
Burnout can be so all-encompassing that it can ruin your life. It can make you feel like you are losing your mind and your basic abilities. A lot of that is coming for a lot of people who are currently stressed but excited.
That's a natural result of introducing LLM to current standard software development without modifying the rest of it (the part that doesn't involve creating code).
> the code it produces is slop, but that’s more the fault of the model than the harness not being a good judge on if a step in the workflow resulted in a net improvement or completion.
I don’t know. I’ve invested heavily in building internal tools that scaffold code and lint the filled in architecture/code design. That with a ratchet pattern, to allow for new rules that have errors across the existing code base, but to asymptotically fix them, is working pretty well.
Example - all modules have tightly scoped design primitives (I’m using hexagonal architecture for the backend, for example). And all code has BDD tests, which is what I spend much of my time reviewing, since cases written in human sentences is easier than looking at so many files of code.
There is a relentless upkeep to draft rules that respond to the workarounds the agents come up with to adhere to the design I want, but it’s slowly approaching perfect. What has helped here tremendously is I use hooks to llm as a judge the decisions the llms make, and then have them review/raise the questionable ones after a first pass is completed. In general, this is snuffing out the slop effectively.
All to say, someone asked me recently what model I prefer. In this approach, the model doesn’t really matter to me because the code is consistently what I want. I’ll choose a model because it has better mcp speed (codex), or a more thorough scope (Claude code).
Where this IS true is when we’re building a net new pattern. The agents are not great at it. BUT most code can fit into the few patterns I’ve created, and what can’t you lock down a new pattern to enforce over a couple iterations of it. Almost everything, at least in SaaS, follows a template.
Man - what a ride this last year and a half has been. I feel for the juniors or newer developers, who really haven't had time to get into the seat. I don't see a great place to really "settle" into right now, as the field is unfolding rapidly. I wonder what things will look like in 10 years.
If I give an agent a sufficient spec, and it can one shot it, I imagine we won't need to loop, especially if we assume the tech is going to meaningfully improve in the coming years. In 5 years, "make no mistakes" and "add tests + review this code" will be baked into the agent or completely unnecessary, right?
> For now I have not moved past the point of comprehension being important to me.
Ah ! This is me too... at least for what I have to ship at work. Not so much for my toy/weekend projects. But it turns out agents are also good at explaining.
I think it's insane to suggest that software developers should ever get to the point where they don't even comprehend their code.
Before someone else says it, no I don't read the assembly code that is produced by my compilers. However, I can generally predict what kind of assembly will be produced, and the result is deterministic unlike LLMs. It seems like most vibe coders scoff at the idea of even looking at the code, and it just seems untenable to me when we're working with (usually correct) stochastic parrots.
Well the result generally matches the input specification, something that an LLM is much less consistent about. I don't think it's deterministic in the sense of being able to predict a priori what the compiler will generate for a novel and nontrivial code block.
AI infrastructure/tools developer and researcher here (hic-ai.com). I fully agree with Armin's concerns.
I wrote an article recently (https://hic-ai.com/blog/tool-response-engineering) in which I argued that AI tool-engineering is the new frontier beyond prompts, and it talks about the agent loop and engineering loops, but boy I have a completely different perspective than Boris's. Rather than contending that prompts are no longer relevant because we can simply have AI think for us by having loops "prompt Claude and figuring out what to do", like what Boris claimed, I believe we have to think much harder now.
Why problems require human judgment and can't just be offloaded to an AI agent is simply this: AI agents lack durable, long-lasting, unique identities forged by real-world memories and experience, and they therefore lack judgment. There is no well-defined notion of having AI agents communicate to each other because they can't even tell the difference between talking to their future self or talking to another agent! They certainly don't reliably weigh whether a proposed fix to a failing unit test will subtly introduce new fallback logic that was never requested or otherwise alter the functionality of the system under test in some manner, or whether now is the time to refactor or now is the time not to refactor or whether to abstract more or less or anything like that. Most importantly, from a practical perspective: AI agents lack legal person status, and they therefore cannot own property or money, sue or be sued, be hired or fired, or otherwise be held financially responsible for their errors or other harmful acts they commit. Clearly, AI agents cannot even arguably qualify for legal personhood status in the future, unless and until they first are capable of assuming a unique and durable long-term identity, which in turn requires solving auth, memory, communications, and many other technical issues that are neither resolved nor standardized today. These facts combine to ensure that AI agents cannot be held liable and financially responsible when things go wrong, meaning that humans alone bear the costs of AI errors until further notice, and thus, human judgment remains the vital commodity that AI cannot replace. So many problems arise from abdicating judgment to AI agent in 2026!
Now, if all the above items were in existence, built, well-settled, etc., maybe I'd have to rethink things. But unless and until AI agents have unique identities and attain legal person status with bank accounts that can be sued and garnished in case of error, I don't think AI agents can seriously be trusted. Good human judgment and approval of all important decisions will remain the most important resource for any successful enterprise, for the foreseeable future. I think it's a very serious mistake to assume that human judgment can be swapped out safely by AI and certainly advise against taking Boris literally. Anyway, great article.
> AI agents lack durable, long-lasting, unique identities forged by real-world memories and experience, and they therefore lack judgment.
I agree with all of this, but I think there's also a simple information theory issue. If the only actual inputs to the system are one prompt and a PRNG stream....
I haven't been this confused by a headline since Keir Starmer declared himself a "gooner".
I think a big issue with a lot of AI enabled coding is that tokens are currently heavily subsidized, and that refusing to learn how to write psudocode and pound out bugs in shell scripts is a fundamental step a lot of programmers are skipping... a stance that I find ironic considering that when I was being told as a preteen to "read the fucking manual" by the 90s internet, I was led to believe if I'm not churning out zero days in C by senior year of high school I might as well abandon all hope of ever understanding anything about computers.
(Flash forward, and the immortal words of the rapper Jay-Z: "I ain't passed the bar, but know a little bit... enough you won't be illegally searching my shit.")
This is a fascinating thought. I agree. It is one thing to let it write a prompt. Prompting, Generating, Judging and going till it is satiated is gluttony.
Every week I ship 4-5 sprints' worth of work that improves features, simplifies code, adds maintainability while delivering value to my end users without feeling I butchered a software hand-engineered over 10 years. This is one product. Mentioning it as an example because it got built over the years starting 2010. It has ~7000 paying customers and works in the B2B space. The B2B SaaS space is brutal since the defendable value should be delivered with margins two levels deep. I wouldn't be able to do it w/o coding agents.
BUT I will never do it with LOOP ENGINEERING. Not in 2026 and not in 2036. Software Engineering as such is not going to be much different in 2036 than it is now.
What stops me is the accountability that lies with me in delivered software. Setting lofty goals, a few guardrails and then letting harness and agent rip it overnight can (and have) created slop.
I did not find LLMs systematically generate poor code. What is poor? Poor in traditional handcraft coding days is defined by
These are guardrails that the models understand. However it cannot understand all these upfront - when building new. It always needs a retrospection cycle and a token budget to refactor.
This is tech debt which we all carried and solved. It is just at an exponential scale because - well, the generation is happening at a super human scale.
So, either build the harness with the tech debt coverage cycles or take on ourselves to add that cycle triggered by human judgement.
A few things that are working for me and I trust are:
Great article and good description of LLM code quality problems and problems that derive from that. And fair to not want a tidal wave of slop to displace your entire craft.
But this article is strangely lacking in foresight in terms of rapidly evolving model capabilities and output. One visual way to see this is to compare levels of SOTA video generation models. Look at outputs from Sora, to Veo, to Seedance 2.0, and now just released Seedance 2.5.
Or compare LLMs/VLMs as they have progressed: GPT-2, GPT-3, GPT-4, Opus, Fable/Mythos.
You can see the level of sloppiness or poor world understanding progress from comical nonsense to junior to senior with a few holes in their brain to an engineer you can actually almost trust to produce clean code if you mention the right guidelines in your instructions (such as avoiding overly local code).
As the model size/complexity increases, the intelligence increases, and so does code quality. We will also start specifically putting more high level code quality tasks into training datasets and training harnesses. I mean, Karpathy will probably see this article and make a huge dent in the issues without even larger models.
One thing people may not be aware of is that there is still a lot of room for hardware efficiency improvements and model size to grow. The compute-in-memory paradigm is just getting started in a way. Look at companies like Tensordyne and Mythic AI, but they are going to get blown out of the water by fully in-memory approaches.
For example look at the recent wurtzite ferroelectric nitrides breakthrough from the University of Michigan team (one of them tragically jumped from height after intense interrogation regarding national security concerns). The military is providing significant funding to move this towards development and scaling out of the lab.
That type or level of truly new paradigm system is going to boost efficiency by multiple orders of magnitude.
I know there are people who think Fable 5 was the end of the public LLM/VLM frontier moving, or that it is impossible to scale models further due to energy consumption. But there is zero chance that every high level VLM/LLM research team on the planet is going to stop publishing models or that the rapid progress in compute efficiency will stop.
Point being, within a year or two, the code coming out will be much cleaner. And within five or six years what you may see is that the leading models are 100+ trillion parameters and have sophisticated persistent context management etc. and they do not even produce application source code.
Instead, the database is in the context and is neurally rendered at 24 fps into whatever UI, schema and business logic you prompt it with in a broad way. The whole application is just precise thinking in an artificial brain ten times the complexity of an equivalent human brain.
And if you are disturbed by the current level of outsourcing for thinking to AI, it is just getting started. In a way it will be incredible, from another perspective horrific, but what I think we are seeing is the evolution of an ExoCortex. There will be an AI glasses stage where the integration is closer but still somewhat low bandwidth.
But sooner than later we are headed towards high bandwidth brain computer interfaces that make AI into an actual new cognitive layer.
So the waves of slop might make you feel sick, but that is nothing compared to the transhuman cyborgs powered by superhuman AI that are around the corner.
This commit seems to mostly be grammar fixes? If someone used a spell/grammar checker it might produce a diff similar to this. Why does the fact it was Claude and not Microsoft Word or other matter in this case?
Yeah I don't know. Don't get me wrong, the article points makes sense. But sometimes I think that we're going to stay near this current point of productivity for a little while.
Currently my org of 8 people use around 1000 euro worth of tokens per month. We've recently had a discussion near the water-cooler, that if the cost climbs 5x-10x it may be just more worth it to get more developers (we're EU based). While the tools work and are definitely nice, even in our little org with our little budget, using Opus 4.8 we've noticed code quality going down.
If I had to bet money, I'd bet that the models will get 30-50% more nice, around 2x more expensive and we will settle into some mode where we'll use llms for some tasks, manually doing others and calling places focusing on speed at any cost some funny name like "gulags, 996, sweatshops, etc" and collectively try to somewhat avoid those places, which will need to offer a premium to attract talent. Wishful thinking.
The way I answer this question is, I don't because my boss is saying to basically accept whatever LLMs spit out which is fine by me because I have explained the risks of doing this to our only product and it was shrugged off. I am both disgusted and excused and just take the salary.
Loops work when you spend the proper amount of time to understand what you want ahead of time. The prerequisite is clarity — enough clarity that you could write a careful specification that you could hand off to a junior colleague.
Often, it takes 5-6 broken crappy versions of a thing until you understand that. There is no accelerating the 5-6 broken crappy versions - there’s no agent tech that’s going to help your meat brain avoid thinking time.
So most of my time is iterating between these two phases: I don’t understand what I want, I need to read and write and play with code, okay it’s been long enough I think I know what I want (it is extremely easy to deceive yourself) … okay now I do actually know what I want and I can write a loop.
Many people think they can jump ahead with agents. You cannot fake understanding or clarity. It is painfully obviously when someone skipped that meat brain understanding phase.
I had codex write a tool to extract all my pi sessions. (Had to filter out my prompts from the agents talking to subagents).
Then I had it analyze the patterns i was making and turned that into the flowchart for the outer guidance-creating-prompt.
I didn't have to spend too much time thinking what i wanted. I wanted it to do that.
The result is still mixed, and i'm not trusting it with delicate code bases, but for a game i've been building i dropped my check-in time to 1/5th i was previously spending on it.
Thats not a good thing per-se. I'm sure i'm missing good ideas by _not_ spending time with it. But previously I really had stagnated with my prompts becoming mechanical #now-do-this and #now-review-that with 90% of its suggestions being correct.
Just need to (automatically) remind it to "do the hard stuff first, clean up & refactor as you go" as well as a "reflect on your work" after its first return to get it to spill the beans on any crap left behind, and then process that in the guidance-creating-prompt to dish out new work.
I'm having it build the software to run a raspberry pi and using a local llm and opencode. the display code is fugly, and i regret nothing about how it'll look inside nor do I want to know all the stupid requirements. We improved it'd render speed by finding a github example using numpy. It uses jinja to render user generated templates for the ui.
The only problem it runs into is the bizarre BGRA or RGB or whatever color mapping between screen and frame buffer; it absolutely has no idea what it does when it's right. It also thinks there's some magic around the bits per pixel.
I do not really care, as this thing won't ever be extended beyond display some text and a few graphics. So why do I need it taking up space in my brain.
A lot of little projects are a lot easier now, but corpos who think this will be a magic want to their largesse of badly maintained code are gonna have trouble.
> Often, it takes 5-6 broken crappy versions of a thing until you understand that. There is no accelerating the 5-6 broken crappy versions - there’s no agent tech that’s going to help your meat brain avoid thinking time.
Fully agreed. Though I found that, once I found a harness (prompt + skills + model) that I trust to do most things the way I like it, it has sped up the coding/exploration part of that process.
Although the iterations are faster, it's still taking me almost the same amount of effort to go through those crappy versions, because I still need to understand and adjust my mental model of what ideas, principles, design apply for the solution, and what to try next.
So, in the end, I do feel like I'm expending more mental effort in a shorter amount of time (with some effort saved on writing the code, which wasn't that much to begin with once you're proficient). It's a weird feeling, like I'm "only" prompting and reading code, but I feel equally mentally spent, or sometimes more because of the compressed iteration cycle.
> We may create codebases that are not merely hard to maintain by humans, but that assume machine participation as part of their maintenance model... People more and more merge code they cannot fully explain. People lose their ability to create issue reports or discuss things in chat, without augmenting or rephrasing their messages with the context provided by a clanker. Too many people increasingly rely on a machine to summarize or contextualize it. More and more do I encounter people who converse with me through the indirection of an LLM.
I experience this daily now. It find it discouraging and concerning.
I believe we're merging more code we can't fully explain because we are now relying on code review to build the mental model that was previously built by writing code and collaborative technical planning. I don't think code review is fit for this purpose. I do think we can extend code review with structured exercises, informed by pedagogy, that strike a better balance between friction and understanding. (I'm looking for help testing these exercises).
And this code is often full of security vulnerabilities. It's just hacks on top of hacks on top of hacks. You end up with 100K lines of code full of weird fallbacks, doing something which could have been done more reliably with just 1K lines of code.
I think author's comment about preferring systems which make invalid edge cases impossible rather than implementing fallbacks is hugely important. With the fallback approach; you end up implementing fallback on top of fallback on top of fallback... Each fallback seems to increase the amount of code exponentially and somehow it always creates new problems. This should almost be a 'General law of system design.'
Fallbacks reduce the risk of failure but make failures more complicated and harmful when they do happen.
As a software engineer, like the new coding environment which is being created by AI.
Big tech companies have created infinite work for me. The human developer has become a critical component of code execution. The human needs to always be present to handle the nearly infinite number of difficult unhandled exception cases which are guaranteed to occur from time to time.
The software engineer is no longer like a laborer, but more like a security guard who sits at his desk drinking coffee most of the time and only steps in on rare occasions when something goes wrong.
My experience with LLM's is that the "fallback" issue is probably one of the most serious issues. I have seen zero talk about it outside of this thread. I'm not sure its even being worked on. The llms have this terrible drift towards always making something happen even if that thing is not even related to the task at hand. "failure" in the sense of simply throwing an error/exception is something models seem highly resistant to.
I cant tell you at this point how many times I've seen them do something like
Fail > make up values > maybe log it > keep working silently with increasingly corrupt data.
Ensure you check every PR with opens4.8 or fable - they catch every security issue upfront.
This isn't going to work because the LLM doesn't have enough context. Many security issues involve a failure mode which cuts across multiple parts of the code. A PR which seems perfectly valid on its own may be the missing piece which opens up a vulnerability. Each component may be fine on its own, but brought together, the system is vulnerable.
Think of a machine with interlocking gears; each gear may itself be perfect and may fit perfectly with each other, but then if a tiny pebble comes between them, the entire machine breaks. Maybe the problem here is that the final gear was too close to the ground and would catch stray pebbles kicked up by the wheel in front of it... The LLM couldn't know this unless it understood the full context in which the change occurred; not only the code, but the environment itself.
In a poorly designed codebase with hundreds of thousands of lines of code, it's impossible to have the full context of the code even. The architecture would lack proper separation of concerns to allow one to effectively establish an appropriate defense perimeter. In a poorly designed codebase, every part of the code can harbor a vulnerability.
It's like; if you don't have a proper access control layer which is automatically and declaratively enforced for all your endpoints, every endpoint will have to enforce security restrictions on their own; duplicating similar-looking code over and over. If one endpoint out of 1000 incorrectly enforces a security restriction, that could be a critical vulnerability.
Of course you don't just check the diff. Rather in your CI infra, it's important as part of every PR, it needs to be given the full repo to check if it introduces any issues. This works wonderfully on github, even with non SOTA tools like gemini-code-assist.
why do you think it's not possible to have full context of codebase? modern harnesses excel at finding all the right codepaths, even in a large codebase.
> they catch every security issue
No they don't! They catch a lot but certainly not all of them. I can't explain why but it 100% happens.
Not to mention that effectively reviewing code is a much more difficult skill than writing it. Without a good mental map of how it affects other parts of the system, it’s basically a rubber stamping ceremony.
Github’s poor PR UI doesn’t help either, there’s limited tooling to navigate around the codebase not directly changed (but affected) to identify and highlight problems.
What's your product? I'm dying to see how the product developed to 100x human standards by agent swarms is. Must be amazing.
/s
https://pages.cs.wisc.edu/~remzi/Naur.pdf
I'll help if I can.
>Yet even with a lot of manual steering, that type of code does not come out of LLMs naturally, and even if the code comes out naturally like that, they will still attempt to handle now impossible errors.
This is something I’ve struggled to fight against in many PR reviews. Especially once already written, convincing someone that their excessive null checking is harmful is an uphill battle. Short of better modeling (and languages that allow for sum types to enable it), I haven’t been able to come up with a universally convincing argument against this kind of “shotgun parsing.”
Maybe it really just isn’t that big of a deal? But when actually reading through and refactoring a codebase I’ve always found it frustrating to manage these unnecessary checks. Sometimes they’re nearly impossible to delete safely once present without first adding some kind of logging or broad investigation.
> convincing someone that their excessive null checking is harmful is an uphill battle.
The argument that seems to hit home more often than not is that optionals effectively “fork” the state space, the possible states your program can be in. And the larger the state space is, the harder it is to reason about the code and maintain it. That’s actually part of what make undesirable states un-representable means.
And AI code reviews encourage overly delusional defensive paranoia. triple null checking deep inside a function is technically a real risk, but in practice should never be hit because you've checked for nulls in every function that calls or could call the function in question and is thus not necessarily worth guarding against.
Are LLMs too dumb to understand the type system? Or is the type system too bad, to represent non-nullable?
Even in Python with its meh-ish optional typing system something that can be None is different from something that cannot be None.
How impossible are we talking?
I tend to be a fairly defensive programmer - maybe nothing currently sends this function a negative value, but how hard is it for a future code change to alter that assumption? I always figured a clear error was best. It lets even someone unfamiliar with the code know what assumptions are being made about the valid range of inputs, so they don't have to consider impossible outliers.
Obviously it isn’t totally impossible, but it becomes challenging to know if it’s required or not. It’s hardest when it isn’t just throwing an error but instead defaulting to something only half-sensible. For example replacing a negative number with 0 or overflowing rather than panicking.
When it comes to assumptions about the input, ideally model them in the type system. If you can’t, explicit checks and throws are OK in my book. But don’t check-and-hide any errors. You’ll be hard pressed to debug the issues they’ll cause down the road, since it will usually be far from the implementation that you see the impact.
I hate the "pick defaults out of a hat" approach that LLMs seem to take. I suspect this behavior may be a result of reenforcement learning on coding challenges - making the code worse by throwing in these assumptions (which in turn become part of your documented API) may get you an extra half percentage point on the code challenges.
This ties into something I have been saying for months: LLMs are great at finishing tasks, but bad at aesthetics and taste.
There are two kinds of work: One is goal-driven work, where we have a goal to achieve, and we care very little about how we get there. Security is a perfect example; if you want to exploit a system, you rarely care about how beautiful the exploit is, all you want is access to those super secret nuclear plans. Research is also like this; "research-quality" code was famously terrible, even before the age of AI.
The other kind of work is taste-driven work. People think that, when they're adding a feature to a large codebase, their goal is to add that feature, but that is often not the case. Keeping the codebase amenable to future changes is often far, far more important than this specific feature, and that requires taste. Note that maintainability and code quality aren't synonymous, code quality is just a means to an end, and that end is maintainability.
> Note that maintainability and code quality aren't synonymous, code quality is just a means to an end, and that end is maintainability.
Many orgs are quickly moving to a world where code quality and maintainability are not a priority, at all. If claude is just going to write the code, does it matter "maintainable" or "quality" it is? No. It just matters if it works, and if its fast, is how the perspective goes.
The irony is that coding agents are, if anything, more affected by technical debt than human maintainers (who at least occasionally have the taste to rise above the level of the current codebase they're working in). The impact on productivity may be initially delayed, but it's going to compound faster.
Not unless agent increases in capability faster than it compiles debt in the codebase!
There has to be some kind of theorem in here, since agent actions (including debt generating ones), are training data for future agents.
I think we have to wait and see if long term maintainability will be any different from human coded software. Every single long surviving human written codebase I have worked with, has significant amounts of tech debt and large pieces had to be rewritten from time to time. This is of course anecdotal and I'm sure clean and elegant old codebases exist somewhere.
The worse designed the code, the more frequently it has to be re-factored. I've worked on long running projects which required essentially no refactoring when implementing new features and I've also worked on projects which had to be re-written multiple times to accommodate requirement changes.
In most half-decent codebases, including LLM generated ones, adding new features almost never requires a refactoring in my experience. It is almost always when you are fixing bugs, improving performance or changing core behavior.
Maintainability is just the inverse of the expected cost to make a future change. Future changes matter, so maintainability matters.
It is, however, true that we don't yet know how to achieve maintainability in the age of LLMs, and whether it keeps being synonymous with aesthetics and code quality as time goes on.
My experience is that I am bottle-necked on specs. The agent loop is less of a thing for me now.
If I can get a clear understanding of what I want to build, communicate that to Claude Code in planning mode with the goal to write an actionable spec (not code, plan to write the spec) then I tend to get very good results once the agent goes to implement.
But this strategy, while effective, puts a big load on me to write the specs. The agent tends to knock each one out of the park (usually 2 to 3 follow ups based on code review) but then I'm back at the stage that requires the spec.
Another issue for me is that when I step away, if the agent finishes a task and could technically start on an existing spec (no overlap on files so no conflict possible) it doesn't know it can just create a new branch and start. Before I go to bed I'll often say "do task X and once done and pushed start on task Y". But I haven't had luck beyond that. Often I find that it starts on Y and has a question and then the agent is idle the rest of the time.
The final issue is dependency coupled with the above. For example, today I was writing a background job processor. Obviously, the jobs that are in subsequent tasks require the system. That happens with some frequency. Even the specs need to be refreshed after the implementation to take any details that were resolved at coding time into account.
But I am just on the cusp of wanting the outer loop. The gate is almost entirely on spec creation and PR review. In places where those gates don't matter, I want the agent to keep chugging away.
As an aside, I strongly believe we need to start using tools that are better for LLMs even if they are worse for us. For example, Rust is annoying because the compiler is so strict. Bad for me, great for LLMs.
This is exactly the way it should be! This is great! This is the most important part of engineering of systems that has been minimized over the past two decades in the rush to build. Now that the building is more automated, the specifications and system design can take the important lead again. Engineering and quality might be back!
One thesis I am developing is that LLMs have given us a new kind of tradeoff. We can use the intelligence and tremendous speed up that mechanically pumping out basic CRUD code has given and we can either deliver more features or deliver higher quality.
What that means to me is that there is a balance. My belief is that we have to take some of the new power and put it towards quality rather than spend it all on speed.
Do you really believe that? If I would be employer or manager of developers saying that they need to carefully design whole system for the agent to implement, so not a technical person, it would look like their are buying their time.
I believe that it will be the case. 'What design?! Just feed Jira ticket and business documentation to Claude and quit stalling!!'
Joke’s on you, Claude is writing that too
Why's it a joke, looks like quality and good engineering will be faster for what we build and maintain.
This matches my experience coding, and the expectations I (and many other) have been voicing for years about why AI is still a ways away from solving coding. The hard part of programming isn't pressing the keys to put code into a file, it's understanding the problem and coming up with a good, clean, extensible solution. AI is great at making ok solutions that technically work, but pretty bad at having a good vision for a solution. AI is still very useful for bouncing ideas off of and exploring to create a better understanding, but writing a good spec for an LLM to implement isn't much easier than just writing the code yourself.
> I tend to get very good results
How do you define the good result? Does the definition of success include clean, maintainable code? I am finding I need to be in the loop. My code ships to thousands of users, so any issues get amplified.
Last time I saw one of these conversations on HN that was the key question.
What people disagreed on was what's good, or what's even good enough. I don't think that's a new thing but it's becoming far more apparent in the age of AI.
I'll make the claim, a demo is easy to make. But it's far from a minimum viable product. A demo is *maybe* 10% of the work. But for some people I know (and work with) they act like it's 90%.
Yes, I review every PR (which is part of the bottleneck) and give strict feedback (as I mentioned, averaging 2 to 3 fixes per task).
What I'm saying is that there are some higher-level loops (as described in this article) that are outside of the bottlenecks I mentioned (spec creation and PR review).
For example, I may have 3 written and ready to go specs that are totally unrelated (don't touch the same files, each can go to PR stage with no conflict) but it isn't easy to keep the agent moving on them unless I do so manually. Having an outer-layer orchestrator that can move that along makes a lot of sense.
But when there are dependencies between tasks, it has to wait for my PR. And once I run out of good specs, it has to wait for me to write them.
"Writing specs" is the essential complexity of programming. What you're saying is that there's no silver bullet. Agents or no agents, punchcards or interpreters, programming is programming at the end of the day.
I'm pretty sure programmers weren't the ones writing the specs in the past...
Same experience. Totally bottle-necked by specs. I don't really see a way past it that isn't sketchy and consumes excessive resources. I guess I'm not ready.
> "Before I go to bed I'll often say "do task X and once done and pushed start on task Y".
Following could solve your problem.
https://www.aihero.dev/skills-handoff
/handoff is my new favourite skill
https://www.youtube.com/watch?v=dtAJ2dOd3ko
Why can't Claude write the spec?
It does, but I have to direct it and review it. That means I have to think about it, research it, consider how the new feature or system fits in with the existing feature or system. I have to make decisions on libraries/dependencies. I have to consider how the project will evolve in the next week, month, quarter. I communicate all of that to Claude in an interactive planning session and it outputs a detailed spec, ready for implementation.
All of that thinking, planning, rewriting, etc. takes almost as long as it takes Claude to actually deliver the feature. The big features Claude writes take ~30-45min of uninterrupted coding to deliver (I just checked the last feature was 39m 41s for +1,610/-26). To write that same code would have taken me probably 2 days.
How do you expect it to give you what you want if you don't think about it?
Solution spaces for even seemingly simple problems is incredibly large. There's a reason there's a thousand different types of nails and a million types of screw heads. Just making every screw head Phillips (or pick another) doesn't just make things work.
But you need expertise to know these things. They're the issues that are subtle and appear to work but you end up breaking things (often invisibly) and just end up chasing problem after problem. It looks like a new problem but it's rooted in something else.
I agree, but that is the crux of my initial post. There is a ceiling to how quick I can deliver using LLM coding agents which is the speed at which I can write good enough specs.
I feel I'm at the point now where the time the LLM takes to deliver a feature, no matter how big, is nearly inconsequential. Because while it is in the process of delivering the feature, I am writing the next spec, and by the time I finish the spec the agent is waiting for the next feature. And at that point I have to review it's code, give it feedback, review it's fixes, merge, etc. All of the "waiting" is on me. It is basically delivering features as fast as I can write specs and could only get faster if I write specs faster.
the bottleneck is still you knowing what the right thing is, and where the odd edges are.
either you tell claude or it tells you/is probably wrong
but, you can still be more agile i think, and just make the thing and see of it solves the problem or not, and if not, build something else
> the right fix is not "handle every malformed case." ... [LLMs] will still attempt to handle now impossible errors.
This is the number one code smell from LLMs and I don't know why they are so obsessed with it. In python, it often comes as `hasattr` checks on types that are defined to have that attribute, in a code base that is fully type-checked.
Why do they do that? Is it from pre-training or re-enforcement? If that latter, can the labs please fix this?
Likely just that they err on the unnecessary error handling than missing error handling. They likely penalize runtime errors harshly in the training
I suspect it's mostly the training data. I am also on team "make illegal states unrepresentable". It may get talked about a lot on HN, but I'm still at the point that I'm surprised when I see a code base that I didn't write in the wild that does a really good job of it, either open source or at work. Most programmers still think in terms of picking up pieces and fixing errors at the point where the error message pops out rather than making it so the error can't happen and the data reflects that.
I say "mostly" because I think there's also a problem with AIs thinking this way in their current state. That last level of human understanding of a code base, where the human holistically understands the flow of those guarantees, is a challenge to give them right now. On the raw code level, this sort of thing often involves enough code to easily blow out their context window. Trying to summarize it in memories-style files has its own problems; just because there is text written down about the guarantees doesn't mean that the AI is going to get the right info out of it, any more than a human might from just reading the code. I won't say it's "impossible" to give an AI this understanding because I'm not sure it is, but it is a level of understanding of the code that even if you get them to have it, their practices tend to fight against it.
My own solution to this problem has largely been to give up on them getting this. I prompt a solution to the problem the way that most people do, then if I want to make bad illegal states unrepresentable I prompt the AI through the process of the necessary refactorings, unless it's so small that I just do it myself. Given a lot of code that uses maps/dicts and arrays and strings and ints, if you prompt it through making those more thoroughly typed, it's actually pretty good at it. I've not had a lot of luck getting good designs out of single prompts, even when I get detailed. Treating it as two separate tasks seems to work out well.
And watch the diffs on the types carefully; AI loves to sneak past a ".JustSetItAndIgnoreAllThePreAndPostConditions(string)" method. After all, I suspect there's plenty of training data of "types that are nicely structured to make error states unrepresentable and then a later maintainer came along and added a 'JustEffingDoIt' method that broke everything" in the field. One of the best defenses is to make sure that the type implementing these things is in its own file and you can easily look at all the methods it adds on those types and smack it when it does that. I've tried slathering warnings about not doing this and explaining the pre- and post-conditions being maintained in the docs but the change seems marginal.
Because the vast majority of the codebases in its training set aren't fully type-checked, or very clean at all. Or it's just snippets from Stack Overflow, so there's no existing context to not assume null-checking is valid.
It’s because it matches the patterns they are trained to follow. They don’t understand the code. They can’t reason about the actual logic flow. They can only work with patterns.
million times this - getattr on every dataclass is a wild choice
Sorry to say but the solution is to stop using python. The models are trained to code defensively assuming historically representative python codebases. The models trust the types a lot more in languages where the canonical historical examples trust the types because the language is constructed around that premise.
I would expect a language model to do a better job of coping with that kind of uncertainty, inferring type from name and usage, etc.
Code is part of a shared and built understanding of an information system.
If these loopers mean we all have to move at this continuous wave of software happening, then we get to the highest levels of logical information system design and its all human judgement and balancing of business requirements to fit a given niche in a company or market. So all the programmers have to become business analysts/market researchers/businessmen...except the specific niches where AI tooling can't really clank well...or the end of the subsidized AI token era makes all this looping too expensive to continue. This feels like expert systems and symbolics lisps machines redux, where we briefly ran into the fact that its not so much the code itself not being able to do stuff, it's that your company's org always gets shipped, so if you can't change your company org, your software only has so much flexibility.
Dataflow diagrams and domain knowledge / domain modeling / ubiquitous languages may become the metalanguage that we start to use and set the standards for quality, functional, and non-functional standards and conventions. We make the "looper clankers" ensure that they fulfill that data / behavior / performance contracts before saying what "done" is, because "done" is no longer just code that compiles, code that builds, code that deploys, or even code that sits in production; it's code that fulfills all of the user requirements, operator requirements, and maintainer requirements. So, the language used may be required to make us all turn into business analysts and software architects more than syntax knowers. The revenge of UML and the return of declarative / logical design / BDD triumphing?
(Typo scan by gemma4-12b but I didn't let it alter my message)
I keep thinking about at which point I should not force myself into the loop. As a developer I really like working on the code structure, making it clearer, thinking about good abstraction, breaking into modules, etc. I really take pleasure in it. At the same time I understand that at some point I am becoming the limiting factor.
If the point of the software is benefit people, should I still care about how the code looks.
Right now, I still think that the answer is yes, but in 3 years? in 10 years?
> If the point of the software is benefit people, should I still care about how the code looks.
The answer is yes you should, as long as you want to keep software benefiting people.
It's tough if you're somewhere that isn't very meaningful to you beyond the technology. I think there will be an existential shift soon towards more fulfilling work. Maybe I'm naive or that's just what I feel I need for myself.
You will always be able to ask the agent to do refactors for you - and it can do mega ones that exhaust you to think about!
Two problems: I will not get my pleasure, and I will still not know how the code works.
Agentic refactoring is very questionable if you want to maintain quality, as it will rewrite all your code to be more average.
I've found that if you look over the code and notice and describe a specific problem and solution, the agent can apply a refactoring for you well enough; and that's often faster than editing the file yourself even if you already know exactly what to do.
The idea of setting up an agentic loop to review code and propose and implement refactorings still seems pretty awful to me, though, yeah. Maybe cut that off at the first green-bar revision, and then apply some actual taste and judgement.
How about ship stuff now even if imperfect. Then as capable models come online, ask them to refactor. This allows you to deliver NOW and refactor later when the situation demands.
Or you can do it yourself. Use AI as a prototyping tool or for boring throw away tasks. There's no reason everyone has to succumb to vibe coding.
> My current status is that I have not had much success with this way of working for code I deeply care about
If something is judgement heavy, "code i care deeply about", then i don't really agree with the direction of travel here. Don't try to delegate decisions you care deeply about.
I do like the framing of agent loop vs harness loop, but only delegate stuff that you can accurately specify in advance, that usually means stuff that's repeatable in my case ("hey go see how i did X, do that but for Y"), and that inherently means stuff that's predictable.
For stuff where lack of my judgement as input is just going to cause me to say "no", we're down to collaborating in the "agent loop" as Armin puts it. And that's totally fine. It's fast, but also safe.
Remember before AI coding assistants, sometimes you'd get an engineer join your team who was SUPER productive, your peers would be jealous "oh yeah but you guys only got all that done because you have X on your team!" - they didn't live the curse of having that kind of person around - if you don't have them PERFECTLY aligned, then they run off at break neck speed in the wrong direction.
> Don't try to delegate decisions you care deeply about.
YES. Or find a deterministic way to insert them :D
> Don't try to delegate decisions you care deeply about.
> they didn't live the curse of having that kind of person around - if you don't have them PERFECTLY aligned, then they run off at break neck speed in the wrong direction.
Exactly. If you wouldn't outsource it to people you considered highly skilled, why would you outsource it to a machine?
I think what is going to happen is revival of "Methodology".
"Methodology" was a big thing in the past just before we got into "Agile Extreme Coding", instead of trying to model the big picture of SW development projects just jump into coding agilly. Implement it feature-by-feature
Granted the methdologies proposed ( See: https://www.ibm.com/docs/en/rational-soft-arch/9.7.0?topic=m... ) may have been too heavy and not flexible and not improved enough. But now with the rise of Agents I think we need to revise and perhaps re-invent them for AI agentic development.
Yes, I believe in reinventing methodologies for the rise of agents.
Before even discussing with my team whether something is a good idea, I can have a full prototype in a new branch within one morning. But then use it as a proof of concept and delete the code.
Another example: agents can generate full test coverage. Including mocking external dependencies and user behavior. Also all in one morning.
Why reinvent methodologies? The cost functions have changed. And agents add new problems, such as hallucinations and tech debt. I think reinventing is a good word since these processes already exist. But the emphasis would shift toward particular parts, making some of them much more mandatory.
Thank you for writing this thoughtful post, Armin. I find it deeply comforting that the developer of Pi, an agent harness, does not remove himself from the loop, like me. Maybe if I started thinking of codebases as biological organisms I could get comfortable with getting the human out of the loop.
What does any of that mean in practice? it's just rambling about abstract concepts that seem to be designed to hint at a bigger picture, when it's just getting AI to write code for you.
Is this where it's going? Having to mystify our roles so it seems like we're still the thought leaders when actually we're just becoming pseudo-teachers that try and herd our group of AI idiots to the right conclusion for us so we don't have to, without ever giving away that it's just all techno-babble?
This is not rambling and it is not abstract. The content here is about the second-order effects of "getting AI to write code for you" in less supervised ways. I'll cede the author could have polished this to more concise effect, but at the level it's at, a reader's failure to understand the substance doesn't imply there's mystification going on.
I agree. I think the comparison made elsewhere in the thread to Yegge's recent AI delusions/projects is especially unfair.
Armin is actively grappling with the implications of AI-produced code on the software engineering craft, and trying to reflect on how to responsibly adopt the best parts of the new world. He's recognizing that the AI skeptical/cautious are still massively impacted by everyone else using tools that run or are built this way.
I really appreciated the piece, and I'm glad we can still publish work in progress thoughts that don't have a clear thesis and call to action.
Once you buy into the AI hype, you babble like that. Yegge is an even worse example.
I'm convinced the field of software engineering is being split in two. These are real concerns and coherent arguments, that make sense for developers who have been using "agentic loops" and heavily AI-assisted workflows.
It scares me that someone can see this as "rambling about abstract concepts" while I see exactly what the author is talking about, both at work and in personal projects; the thought that the majority of people have absolutely no idea what's unfolding.
tech blogs used to read like actionable readme guides. I couldn't finish it without thinking: what am I supposed to do with this information? The shelf life of the latest and greatest is about 2 weeks in the AI space. I never caught up to the ralph wiggum loop and now I'm glad I never tried.
https://news.ycombinator.com/item?id=46682325
> What does any of that mean in practice?
They want you to spend more tokens
> They want you to spend more tokens
Spending your tokens like some sort of primitive meat bag is passe and any developer doing that will be left behind by the true AI natives.
What you need to do this month is set up a central planning agent that creates a 5 year plan and then orchestrates teams of subagents to each direct subteams of subsubagents to fulfill your goals.
Have each team at every level inspect each other's work and authorize each agent up and down the chain to spend tokens on your behalf for the greater good.
With any luck, the US Administration will see the light and allow AI agents to open up their own credit cards on your behalf to eliminate unnecessary bottlenecks. Agentic Fintech is the future.
We need to move beyond this early stage where you give any thought to spending those tokens yourself!
Practically, what this boils down to is having clear success criteria.
The harness (Claude Codex, Codex, Pi etc) keeps throwing things into the context and executing tools (as directed by the model) until the success criteria is satisfied.
The "rules" of using AI successfully are basically just the rules of any successful development team. Break things down into clearly defined chunks, make the success criteria clear and provide a way to get the right feedback on how the system is running (logs, metrics, traces etc).
From my past experience of religion at various levels I am very often reminded of borderline-cult religious meetings, and the zeal of converts repeating gnomic oversimplifications, and of how exhausting it was to try to engage with them on any topic of substance.
My own feeling is that it is totally OK to simply route around these people.
It's fascinating how many of the "keep your identity small" folks in the YC/HN sphere have lost any sense of perspective at the first sign of a technology that wanders into the philosophical realm. AI-oriented identities are everywhere.
Why is HN interested in management and team process discussion but allergic to similar topics on how to manage agents?
It’s like saying why discuss these team workflows when it’s just devs writing code. Or why use any jargon to describe workflows when it's just devs writing code.
Because like every other large social group it’s actually a collection of dozens of subgroups that have an overlapping interest
You’ll see those subgroups come out in threads like this and you’ll see other subgroups come out in different threads there is no singular version of hacker news that is always existing it is a collection of sentiments that from time to time align interests around specific topics
Sure. Let me rephrase - why do these particular posters and their upvoters …
You gotta just use more tokens, more tokens means better everything.
I’m sorry but this response is just absolutely ridiculous and is not giving anything near the respect to the author that you should have.
You’re just rambling and ranting about philosophical things and have basically nothing to say about the technical or engineering points that the author wrote.
This is a entirely emotional appeal and doesn’t actually engage the author where the author is engaging in the audience.
If you look further down thread there’s dozens of comments that are engaging with the content and not being hyperbolic about all this cyber shamanism or whatever you wanna call it
When someone is expected to be wizened and does not have the knowledge to keep up with the needs of those around them, they in turn become Shamanistic in their practice.
The speed of improvement on these models has been incredible and has outpaced the learning speed of humans and put many experts into these Shamanistic roles.
I think the operative means of addressing this is to recognize that we can only learn so quickly, but we are still called to improve our knowledge and understanding to a higher level. Since the improvement of these models is neither logorithmic, nor exponential, we currently occupy a space in time in which the models are currently smarter on average than we are as a collective whole.
Algorithms and data that emulate responses aren't smart.
A 5 year old knows if you want to wash your car, you need to take it to the car wash.
Can a 5 year old write a substantial program on spec, that passes the requirements and given tests, in a few minutes?
If not, then perhaps this comparison is not the be all end all.
"A ship is useless, it can't drive over land..."
5 year olds and ai both have jagged intelligence.
also its AI not "artificial code generation intelligence" . Ship is your view of the product to shoehorn into something specific.
But it demonstrates that LLMs struggle with basic reasoning. A criticism of LLMs is that they're imitating without a understanding of what they're doing and without a clear plan, so this inability to solve a simple logic puzzle is very relevant. If LLMs didn't struggle with reasoning problems then something like ARC-AGI wouldn't exist.
Its a question designed to fool the AI. It's like saying that a person doesn't understand the limitations of reality when they fall for a magic trick.
These aren't the same thing.
You can't fool an AI because it isn't using its own judgement.
You can fool an AI as evidenced by them being fooled. They demonstrably appear to be working through a problem and get fooled by the wording of the problem. If you think differently, merely asserting it is not the way to convince people that what they see is wrong.
You can't fool an inanimate object.
An LLM is (effectively) just a really, really elaborate "choose your own adventure" book.
It's not "working through" problems, it's just tracing a route through an pre-defined information space. It's not actually thinking, it just does a good impression of it.
>You can't fool an inanimate object
You can't constrain foolability to just the animate objects.
Foolability is based on intelligent processing.
To what degree such an intelligence needs to be developed is not defined at all (we can, for example, trivially fool a doog using one of many tricks, and a dog is hardly general intelligence).
Thus far, the inteligent processing we knew concerned animate objects. But we now have developed software/hw combos that exhibit intelligent processing. Is it enough to actually be intelligent or to be fooled?
We don't know. We do know it's enough to appear intelligence, convince people that it is intelligent, and to appear to be fooled.
But even if we think of LLM AI as mere mechanistic process with no emergent intelligence, who said one can not fool a mechanistic process? We can fool even simple pre-LLM gaming AI systems (based on simplistic heuristics) just fine.
They simply appear to "exhibit intelligent processing". The intelligence is in what created the data. It's a surface that's being traversed in a complex way. The LLM doesn't 'understand' that surface in any way, it just traces a path on it and reguritates apparent understanding. I'll grant it's eerily convincing.
'Fooling' something, essentially to deceive or trick, is defined as causing someone to believe an untruth. LLMs don't hold beliefs (neither do mechanistic processes), and they aren't a someone.
You can widen out the definition of the word but that generally makes language weaker - interestingly, semantic drift is a big issue for LLM's.
We have different opinions, and that's fine. Have a good day.
Please explain why the mechanism of the LLM generating output precludes it from being able to be fooled without using use tautologies or reducing to substrate for explanation.
'Fooling', essentially to deceive or trick, is defined as causing someone to believe an untruth - at least in British English it does.
LLMs don't hold beliefs (neither do mechanistic processes), and they aren't a someone.
You can widen out the definition words but that generally makes language weaker - interestingly, semantic drift is a big issue for LLM's.
You're describing a tool.
Tools can do very useful things, but they aren't intelligent.
referring to John Woolridge's recent talk? "the car wash is only 200 feet away, should I drive or walk?"
His slide showed Opus 4.6 saying "walk". I couldn't get 4.6 to do that.
[flagged]
[dead]
We used a “loop” before it was called that to drive MS-DOC support into Tritium. Based on that experience, I take issue with this:
“There are already impressive examples of large automatic porting efforts, including the reported work around moving parts of Bun from Zig to Rust.” (Emphasis added.)
It will be impressive if/when the Bun team is able to pick up and continue extending and supporting Bun. For us, MS-DOC remains read-only and probably perpetually buggy until we reimplement with a better understanding. Until then, it’s definitely not “impressive”. Functional? Maybe. Impressive, no.
I am 100% for fully agentic loops... for tasks other than engineering.
I'm not willing to outsource the understanding how things work part of myself. That part of myself is what got me into computing in the first place.
If this work becomes simply a matter of describing intent to a machine (probably through an Issue, like a user), and going to check on the result when you get the 'done' notification: I'm done.
It's possible to use the tools to do awesome things without letting go of full system understanding of the parts that you look after.
> If this work becomes simply a matter of describing intent to a machine
What is it that you think you are doing when you are writing code if it isn't describing intent to a machine? Whether you are doing it imperatively vs declaratively isn't a new thing.
I'm a software developer from way back, using tools and languages that coding agents are far less familiar with.
So when I use an agent to write code, it's in languages I'm less familiar with, and often using libraries I know nothing about.
All to say, my part of the process often ends up being:
1. "Here's what I'm looking for, in detail" 2. "That's not right. Here's one way it's not right, and a specific example. Please fix that." 3. Sometimes I give suggestions for how what is going wrong might be happening, or conceptually how to work around the issue. 4. And iterate on 2-3 until the result is close enough.
That's a loop I'd love to automate.
Sounds like a great way to avoid learning anything new about the languages you don't already know.
Have you tried SKILL.MD files encoding your nuanced domain knowledge?
This.
> Present-day models tend to produce code that is too defensive, too complex, too local in its reasoning. They avoid strong invariants. They add fallbacks instead of making bad states impossible. They duplicate code, invent bad abstractions, and paper over unclear design with more machinery. Worse though: I so far see very little progress of this improving.
Context-smithing can help to a degree and cyclomatic-like complexity rules tend to make matters worse. So, you either roll up your sleeves or close your eyes and hope for the best. I've had limited success with the latter.
I was really surprised by this part!
I've run into the issue a lot; I know it happens. I handled it manually for a while by just having a fresh instance inspect the code - "review this for DRY violations" and "how would you re-write this into a global architecture instead of a bunch of local code".
Eventually the list ended up long enough that I've got an agent that handles it. You've just got to treat "write code that works" and "write elegant code" as two separate tasks - either a fresh instance or an Agent will work
> You Cannot Quite Opt Out
I am so over this. I cannot take anyone seriously that claims inevitability of their ideas, and how you must adopt them without "being left behind". If these tools are so good and so capable the result should be able to speak for themselves rather than this FOMO inducing, emotional language.
I couldn't agree more. Thus far I'm still objectively more productive than all of the AI enthusiasts I've worked with. I think a lot of the activity with these tools is coming from people who just enjoy using them more than they enjoyed coding. They feel more productive not because they are producing more but because they are producing somewhat less with much effort. It takes them roughly the same amount of time even if it changes the distribution of time spent on each task.
> and in recent weeks it has started to dominate the Twitter discourse.
As a general rule, I don't waste my time with the advice of people who still think Twitter is a source of wisdom.
It's especially rich when you consider the shitty code the "loop" produces. The article quotes Boris Cherny as if he's someone to look up to. But then you look at the code he produces with "loops", and it's an unmaintainable ball of mud:
[1] https://neuromatch.social/@jonny/116324676116121930
[2] https://neuromatch.social/@jonny/116349873176941251
the point of that section is that attackers and security researchers will use / are using loops, and you as the maintainer are not able to opt out of others doing this. an unwilling participant.
No, but you always have the option to opt out of being a maintainer. If "the community" is going to behave badly and bury you under a barrage of vibeslop you can just leave.
EDIT: there's a version of this that could be positive--everything could get a hell of a lot more secure. But that doesn't seem to be what's happening.
You're being uncharitable. I don't read it as intentionally FOMO inducing. I read it as the exhausted sigh of resignation from someone who sees where the wind is blowing whether they like it or not. I see it as someone watching tech management and execs listening rapt as Boris pours the poison of AI maximalism in their ears. I read it as someone who sees developers around them either drinking from that same poisoned well or bowing under the pressure from those leaders to adopt AI or lose their livelihoods.
It is true that the author is incorrect: you can certainly opt out, but you won't be opting out of AI, you'll be opting out of the industry.
"the industry" is not some monolith, and treating it as such is no productive. There are all types of software and many ways in which it is created. If the companies that are "AI enabled" are so much better we should see some big changes soon. But I'm still waiting for products I use from "AI enabled" companies to start churning out features at unprecedented speed.
So then what's your experience in your current place of work?
In my experience, some language like this is the result of witnessing it speak for itself.
> Present-day models tend to produce code that is too defensive, too complex, too local in its reasoning. They avoid strong invariants. They add fallbacks instead of making bad states impossible. They duplicate code, invent bad abstractions, and paper over unclear design with more machinery. Worse though: I so far see very little progress of this improving.
It’s almost as though these models were trained on a vast corpus of largely mediocre code. They will never outperform the median Github user - it is all they know, it is all they can do.
Show me the billion dollar solopreneur startup, or the profit increase for companies and at that point I’ll start thinking that this tasteless high level wanking might make sense in some way
This company got valued at $250M https://polsia.com/ and is a one person startup. Lots of people think its more or less a hype job but given "ai agents" have only really existed for a year or two now it's sitll early days.
The website is unclear about what it does, but the about page is rad. Took me a minute to get the reference. :)
We've just invented the car and you're upset it hasn't achieved Mach speed yet.
One car went Mach 1, ever, apparently. Anyway, I don’t think the analogy fits. Ford or whoever didn’t loudly and frequently predict Mach 1 cars, right?
The situation is more like: Altman & co are predicting their new car will replace all vehicles: horses, trains, planes, motorcycles, there’s a real possibility the concept of vehicles will not exist other than cars, in the future. Meanwhile it hasn’t really done highway speeds yet. It does some impressive runs on curated tracks, and people use it around their farms (it seems to work ok for some of them).
We’ll see, I guess.
Yes, one car did Mach 1. And the first production car, the Benz Velo, could only go 12mph. It's an apt analogy.
As I mentioned to OP, applying future aspirations to the current space is incorrect. Some people are able to understand the progression of industrial automation, some people aren't. But if you look at the current batch of frontier models and say, "I just don't see how this is going to be useful", then you're in the camp of those in the 80's who didn't understand personal computers, or in the 90's who didn't understand the web. In hindsight, the technologies evolved massively and found routine use cases that no one initially predicted.
I think my main contention about the analogy is that Mach 1 cars are sort of a ridiculous target, a thing that only happened once just as an attempt to break a barrier, more like a tech demo. Billion dollar startups are very rare of course, but they are real things that happen for practical reasons as part of the industry.
Saying that the person you replied to was looking for the former when they really wanted the latter seems uncharitable. Especially given that replacing most of the engineering department doesn’t seem to be too outside the scope of what some in the space are promising(?).
Billion dollar one person startups are a silly target too, because as we approach that possibility, society will adjust.
I know Sam Altman peddled this concept, but he's not representative of the culture and principles of the entire AI/ML space. So it was wrong of OP to attempt to use his words against the entire idea of neural models.
I do think the point that solo companies that could have been billion dollar start-ups might get a lower market cap if they can be done solo with AI tools is a good one. But that seems a lot more nuanced than calling the idea something like a Mach 1 car.
I think this is like pointing out that we lowered the speed of sound as technology developed, so a Mach 1 car doesn’t mean the same thing anymore, if we want the analogies to line up. Of course I’ve stretched the analogy well past any hope of making sense at this point, haha.
You have a nuanced view which I'm taking into consideration. I agree that if I'd spent any amount of time on my comment, I might have found a more apt analogy.
The OP's response, "It is a terrible analogy that shows terrible thinking," is however entirely ridiculous and taking my comment in bad faith, against hacker news guidelines.
As such, I do contend the analogy fits, even if it doesn't fit perfectly.
It is a terrible analogy that shows terrible thinking. After all, there's one thing we can bet with more confidence on: delegating thinking to this mediocrity machines is affecting the ability to do the same in scores and scores of previously smart people.
Funny enough it is a great analogy if you think these modes will never really “get there” at scale.
Terrible thinking? Delegating thinking to mediocrity machines? "Previously" smart people? I don't think you can project your own limited and malformed understanding of the world any harder. Please go touch grass and learn how to engage with others on the internet without being so negative.
Terrible thinking:
yes, it's just bad thinking. It's a malformed comparison that misunderstands the conversation.
Delegating thinking to mediocrity machines:
Based on the statistical nature of their underlying math, LLMs are by definition mediocrity-producing machines, especially if you understand the etymology of mediocre.
Previously smart people:
Cognitive atrophy in people overrelying on LLMs and agents seems to be inevitable: https://www.media.mit.edu/publications/your-brain-on-chatgpt...
Maybe my understanding of the word is limited and malformed, or maybe you could try to develop one that takes into consideration the humanities, art, the sublime, love, emotions, and everything that makes humans human, instead of looking at the world through the small, mechanistic lens of the hyperengineerization of everything.
> It's a malformed comparison that misunderstands the conversation
I invite you to explain how, instead of just making unsubstantiated claims.
> Based on the statistical nature of their underlying math, LLMs are by definition mediocrity-producing mac
You're demonstrating a fundamental failure to understand the mathematics behind these models, by claiming that they produce an average result by nature. You fundamentally misunderstand reasoning manifolds, and how training teaches models new behaviors.
Phrases like "Based on the statistical nature of their underlying math" sure make you sound smart to someone who doesn't know better, but in truth the phrase is completely void of substance: What statistical nature? What underlying math? What about them prove your naive hypothesis that they can only produce "mediocrity", itself an extremely subjective term that leaves you a massive amount of slack with which you can retreat from your claims after someone asks for proof and clarification.
> Cognitive atrophy in people overrelying on LLMs and agents seems to be inevitable
I can pull studies that show reading and writing reduce some cognitive faculties, compared to oral tradition. Or how the use of calculators atrophies basic arithmetic skills: that's not going to stop astrophysicists from using number-crunching simulations instead of doing things by hand.
> maybe you could try to develop one that takes into consideration the humanities, art, the sublime, love, emotions, and everything that makes humans human, instead of looking at the world through the small, mechanistic lens of the hyperengineerization of everything.
Hey, so you're projecting again here. Massively. Nothing about this conversation has given you any information regarding my opinions on the list of extremely subjective and debatable concepts you've provided. You seem to harbor a belief that anyone who extracts meaningful value from these machines is actually a "terrible thinker" who is inconsiderate of the world and only sees things through a "small, mechanistic lens". Besides being considerably insulting, all this projection does is reveal things about how you view the world, how you view those who think differently than you, and how close-minded you can be, prejudiciously writing off someone as a caricatured personal bias in order to avoid critically engaging with their argument.
Honestly, this is a really sad and negative way to talk with others on the internet and you need to stop and review your approach to discourse. There is no value in considering to waste time talking to you until you change your attitude, so I'm going to end the conversation.
I was literally quoting Sam Altman
No, you mentioned his discussion of the "billion dollar one person startup", which we can both agree is a fanciful idea and more of an eventual "possibility" that will of course not occur as once anyone can be a billionaire, the whole system is going to change.
However, your "tasteless high level wanking" is not a quote from Altman, it's a vague and directionless insult that manages to sweep quite a lot of legitimate discussion about the future of automation and professional work under its thumb.
It's wrong because you're saying, "where are the billion-dollar one-man startups?" in the same way that I might look at a Benz Velo and go, "But it's so slow! Horses can go faster than that! Everyone saying cars are going to change the fabric of society are just tasteless wankers!"
The point is that you are applying future aspirations on the present-day relatively brand-new model space and getting upset that we aren't there yet.
The amount of brain energy spent on justifying the mediocrity machines is astounding.
What you just did is called deflection. You failed to address my comment wholesale and instead opted for a back-handed insult on my intelligence.
Do you actually have something substantial to say?
For some reason pro-ai blog posts feel like paid ads, I might be wrong.
I can't blame you when the first few sentences almost always evoke one of the "creators of XYZ" (I don't know how you can say a model or model harness has a singular creator when the model was trained on everyone's data and the harness was built by a whole team?) and treats their word or experience as gospel.
Who cares what Cherny thinks? He is selling his product, and he will probably cash out soon enough while his credibility is as high as it is.
Armin is very nuanced and balanced. He spells out clearly in the blog post that bad parts of AI
I'm saying if you are a writer and this is what you write about, you better get paid.
To me there’s usually an undercurrent of manic zeal that makes them feel that way.
Part of the problem is that models don't have a strong sense of taste, part of the problem is that the context in which projects exist is incompletely represented in the LLM context, and part of the problem is that LLMs tend to be myopic.
The lack of taste can be mitigated to some degree by improved training, though taste is not a stationary distribution in humans (see trends/fads/etc), we can at least better track the cutting edge. I think this area still has low hanging fruit but frontier labs are more concerned with being able to solve problems than the style of the solution right now (for evidence of this just look at the Opus 4.5 -> 4.8 arc).
The problem of incomplete context is partly a human problem and partly a harness/interconnectivity problem.
LLM Myopia is a harder problem to solve just by virtue training models on question/answer pairs. Countering this requires emphasizing RL on solution paths rather than just prompt/response, which is doable but harder.
> The lack of taste can be mitigated to some degree by improved training, though taste is not a stationary distribution in humans (see trends/fads/etc), we can at least better track the cutting edge.
The point of "taste" is not to copy from others, even if you can somehow filter out the trends and fads. And really, that filtering comes from personal experience anyway.
I have huge respect for Armin but all of the concerns about agents producing more code with less competent supervision from senior engineers doesn't seem that different from the status quo to me. A vast majority of all software I've ever professionally worked with has been terribly structured, hard to work with, full of bugs, etc, produced by mediocre to bad engineers and run by semi technical product owners or managers who basically promot the software into existence by making jira tickets on 2 week cycles to hold it together.
Yes it's awful, but it kind of works and has worked for a very long time. Agents are already improving a lot of open source software. Yes they're producing a lot of slop too, but having beautiful code, understanding how the system works and being able to delegate to a competent engineer you trust is reserved for the very few right now and I think we have all the systems and experience in place to deal with "bad" but working software so personally I am not concerned
Yes, a lot of software shops have produced equivalent slop, but I've worked on teams that aimed higher, and they were much more productive over the long haul – not just in fewer bugs, but also in straight up ability to add more features as the software got complicated.
Theres a deep insight in this post about the value of looping for throw away code to explore a problem space, rather than brute force a problem by just applying more tokens and hoping.
The more I play in this space, the more I’m drawn to the idea that some kind of back tracking constraint solver is a better solution than then the current naive while loop / brute force approach here.
The results I see are similar to what you get from a greedy brute force constraint solver; solves trivial problems, sometimes solves harder problems after a long time, takes too long to solve really hard problems; solutions are increasingly non optimal on average as complexity goes up.
We have so much existing knowledge about building good constraint solvers, if we could just figure out how to apply it here somehow.
> back tracking constraint solver
We'd need a LLM back tracking constraint solver and I think the bottleneck will be good grading rules on whether a direction is actually architecturally clean or extensible. I'm not sure how one would approach that problem
There's a major problem with evaluating the result of agentic coding, and "loop engineering" exacerbates it.
Like many crafts (painting, music, etc) the true test of great software is time. Not because of taste, but because software is a living artefact that must evolve.
Only over time does a human developer realise they have "painted themselves into a corner" and chosen the wrong abstractions. And it will be the same with vibe coding (i.e. where code is not architected and reviewed exhaustively by a human).
Because companies won't surface their internal codebases, the most likely signs of such problems with be the reliability of applications and services. I don't know if recent outages are indicative of changes in code practice, or just coincidence, but we'll find out over time.
Agents aren't yet strong general reasoners - they are good at reasoning in the shape of their training corpus - so it's essential that important code is reviewed by human experts.
I’m having awesome success working with recursive agents. I discussed my experience with them. [0]
> Claude's attention doesn't distinguish between "instructions I'm writing" and "instructions I'm following" -- they're both just tokens in context.
It takes a little human help in the first iterations but after a while it will start to iterate and improve unsupervised.
[0] https://github.com/adam-s/agent-tuning
We've had great success with agents thus far at my job. A year into Clauding and all our dev metrics are up while our downtime has remained steady.
Being an iOS engineer, much of my engineering cycle these days is going from Figma/PRD → spec → code. After being handed off to QA, we handle the bugs and product slips as they come through, while we simultaneously build/spec the upcoming addition. This is basically the same agile style that's been popular for 20y, just super-powered with agents.
How might someone accomplish the same goals using loops instead?
I personally have not had good luck with loops due to similar issues as the post author - but if you were to port your flow to "looping" it would be something like:
- An automation that periodically checks for PRD's at a given location that have not yet been implemented.
- If it sees one not implemented, it puts a lock on it (so other agents later don't pick it up while its still working) and implements the PRD in code, assuming it has the figma link and all specs required.
- When its done it makes a PR, waits for if it passes and even in some cases automatically merges into your staging/preview enironments and just pings you with a build/URL. You can then leave feedback or something and it can also also poll for pending feedback. Or you just mark it looks good, the agent then merges the PR, moves the PRD to implemented status, maybe even writes/updates docs and cleans up any temporary work.
- Repeat checking for new PRD's every T unit time. (10 minutes, 1 hour, etc)
This is how people say you should be looping - you never even cared or looked at the code, and also never prompted the agent yourself.
But I find most agents are often pretty bad still at replicating UI vs making something from scratch and most design specs are still not as detailed around how things look at all sizes, in all scenarios etc. Design seems to be one of those things that still requires a human to validate. And then all the things the post author mentions about it not being willing to apply hard constraints, minimize impossible states, validate at edges and prevent horrendous overchecking of things. etc.
Would you have a breakdown of costs/benefit? Can you say with certainty that this workflow has increased productivity so much that you are seeing profit increases that you wouldn't have otherwise noticed just by hiring more people? Asking with no ill intention, I just crave for actual business cases that make sense, and yet no-one seems to be able to reliably produce that.
> Can you say with certainty that this workflow has increased productivity so much that you are seeing profit increases that you wouldn't have otherwise noticed just by hiring more people?
Has the bar raised so much that coding agents need to be even better than any human could do? If the coding agent lets you get done with 1 person what would've required a team of three and you are not going crazy "token maxxing" spending thousands of dollars a week that would be beneficial for a business.
First of all, I don't accept a discussion where humans are placed on the same level as bots or agents. Even if the cost is the same, humans MUST be the choice. They have emotions, families, sons and daughters, they are a what makes society a society. And yet we've been already instructed and hypnotized by the Altmans and Musks and Bezos to only see it through the lens of profit and revenue.
That said, is what you're suggesting even happening? Because certainly that is not what we're hearing from companies that fucked up their budgets with AI tools. Also, trillion dollars valuations are really justified by random solo-devs creating automatic companies of one that could be companies of four? Because what I hear from the AI-accelerationist is "this technology creates productivity gains for each and every company by enabling automation at scale that would make replacing human profitable". Where is THAT?
> First of all, I don't accept a discussion where humans are placed on the same level as bots or agents. Even if the cost is the same, humans MUST be the choice
Sure but getting more done with less is just how productivity gains work. If your talking about crushing an iOS backlog like the OP is it surely will not cost as much as a human to move along tons of bug fixes and accessibility changes etc.
Here are some case studies on recent anecdotal producitivity gains from AI agents https://cursor.com/blog/amplitude, https://devin.ai/customers/ramp, https://www.warmly.ai/p/blog/claude-code-best-practices.
The third one specifically says that a team of 8 "ships like a team of 24".
> Also, trillion dollars valuations are really justified by random solo-devs creating automatic companies of one that could be companies of four?
I feel like your greatly expanding the scope of this thread, I don't really know how to value these things.
Use appium or XCTest or swift testing; generate the tests first (failing) from the spec.
The loop is basically then a while loop:
While (tests fail) { trigger agent: spec, failures list }
for bugs, write failing tests.
Its basically TDD.
Loops do nothing useful beyond making the “spec -> code” step more “hands off” and let you be confident that the code you write does what is intended.
Obviously you see the issue: writing the loop harness is > effort than not having it…
…but the idea is that you run “spec first” and are totally hands off on the code, just updating the validation step and then waiting while the agent iterates over and over to solve for some solution that passes the loop harness.
People suggest that it is possible to go, eg. directly figma/jira to harness via (random tool here), saving even more time and invoking even fewer humans, but thats currently, as far as I can tell, actually just hype.
No one is actually doing that effectively.
Loops are currently carefully hand crafted, which makes them tedious and of questionable value imo.
I have had some success with /goal for long tasks that can be set up in a way that the agent can do good work for an extended period of time.
A lot of tasks aren't amenable to that, and the ones that are still need a lot of care to be set up correctly. The default vibe coded codebase won't be.
I've come to think of the activity of choosing the right technology, the right architecture, the right testing setup, the right context, and the right /goals to use as programming the agent.
How much does /goal actually help? In auto mode, I've tried using and not using /goal and I haven't felt a difference.
https://code.claude.com/docs/en/goal#how-evaluation-works
> /goal is a wrapper around a session-scoped prompt-based Stop hook. Each time Claude finishes a turn, the condition and the conversation so far are sent to your configured small fast model, which defaults to Haiku. The model returns a yes-or-no decision and a short reason. A “no” tells Claude to keep working and includes the reason as guidance for the next turn. A “yes” clears the goal and records an achieved entry in the transcript.
> The evaluator runs on whichever provider your session is configured for. It does not call tools, so it can only judge what Claude has already surfaced in the conversation.
Apparently, it uses Haiku (by default) to evaluate every turn to determine if the goal has been achieved. However, it only relies on the transcript itself (including the reasoning of the main model). It can't independently verify if the goal has been achieved. So, if the main model thinks the goal is or isn't done, how often does Haiku disagree (in a productive way)? That's not clear to me.
I've mainly used the feature in codex, where I've been able to get it to work for 5 straight days (with breaks when rate limits are hit -- which was surprisingly only thrice) on a massive port.
I don't know how well it works in claude code, but I wouldn't be worried about Haiku getting it wrong and don't see a problem with it relying on the transcript. I always set these things up to maintain a checklist of subtasks to do in a file and check them off, and to always implement with red/green testing methodology, where it writes and commits failing tests, then writes the feature/fixes the bug and commits with passing tests and with an updated checklist file.
So the model should always know from the transcript whether the current task is done by whether it shows the tests passing, and it should always know if there's more tasks left from the checklist file being updated before the commit.
>>> For now I have not moved past the point of comprehension being important to me.
I see software as new form of literacy, even in the AI world, so yeah in my world view, comprehension will be something we always cling to.
I might comprehend some code the way I comprehend the newspaper article on the second page, others I comprehend like a Dylan Thomas poem. My attention might be different but I still need to understand it.
Quoting the creator of CC holds little value in my opinion. I too call my product good.
> opting out of this fully machine-driven future may not be an option.
I am contemplating whether I want to stay inside this rat race.
I completely agree with the conclusion of this blog post, by the way. I feel uneasy, and I do not enjoy the work I deliver using LLMs. I think OP did a really good job on capturing at least my current state.
I and my friends go back and forth, every day, on whether coding with LLMs is a net plus or a net negative.
I'm at the point where I think it's dumb to not do it but also dumb to do it. I have no real answer.
I have settled on using LLMs for everything but to spend more time honing the quality and cleanliness with LLM passes afterwards than I generally would have taken to write it well myself in the first place. This is in some ways the worst of both worlds, but it somehow lets me bypass akrasia while still getting pretty good code out, so I consider it superior to how I worked before. I get more done in three months even if I get less done in a day.
I am with you here but don't get overly pessimistic: devising hooks and stopgaps and flows and constantly tuning what to watch out for does not only improve the quality of the LLM-output code. It hones and refines your own abilities.
CC has made some pretty dumb stuff in my projects but I don't resent those occurrences. They taught me (more accurately: reminded me, because I already knew but was not applying that knowledge too often) very valuable lessons on code quality -- that's still a dark area to this day and every ray of light on it is valuable for the future programming.
To me programming with LLMs made me a better programmer. But yes, I don't just rubber-stamp PRs.
It also finally allowed me to be less of a code monkey and more of an architect and a backend lead than before. Which I was really missing.
> but it somehow lets me bypass akrasia… I get more done in three months even if I get less done in a day.
I think this is going to be a big deal for many programmers in the long run. "Flow" comes from feeling faster as much as it does from actually being faster in the moment. Perhaps more. And yesterday's good experience leads to today's motivation.
> I feel uneasy, and I do not enjoy the work I deliver using LLMs.
I have basically stopped writing code in my spare time since the advent of AI. Before I felt like I was working on a classic car. Was it a practical use of my time? No. I could go out and download software that did what I wanted. Did I have fun doing it? Yes, the act of working on it was important, I felt I was still learning and improving as I did.
Nowadays I see people doing far more in a month than I could in a year and I feel like its all a waste, like I just spent the past few years transcribing a phonebook while standing next to a photocopier.
I don't know if that'll ever change. I can't even pretend I was doing something prestigious and artisan like watchmaking because I wasn't a good programmer beforehand.
This piece changed how I work with LLMs and made me much more optimistic about how "fun" it can be to work with them: https://nolanlawson.com/2026/05/25/using-ai-to-write-better-...
Before I would just throw prompts at the LLM and it'd end up building a pile of crap (but semi-working crap, and 100x faster than I ever could) - it was pretty depressing. Using tools like `grill-me` (or `grill-with-docs`) I feel like I'm actually building my understanding of the system and helping shape it, and the results are much better.
The fun part about that `grill-me` command is that when the questions are over, I've found that I can go right into implementation without needing to dump a PRD or some sort of broken up plan. Now this is obviously completely predicated on what you are asking it to grill you on. But for tasks that are semi complicated, it's fantastic.
Be your customer, write the software just for you, AI is so effective that you could do something meaningful for you just in spare tine.
Here is the similar perspective: https://isene.org/2026/05/Audience-of-One-Numbers.html
I was misunderstood you if you intend to write code by hand, I still did, I use AI to learn by example, but I write the real code myself, AI can help me improve the code. I learned a lot.
I used to think I'll be into coding for the long haul, contributing to open source, and working on multi-year side projects.
Nearly all of that passion vanished this year, and I've been struggling to replace it. I know I'm much better than the machine now, but the lines are starting to blur, and some of the small puzzles of day-to-day have been completely automated away.
We've birthed a lot of puzzle solvers that enjoyed programming, and I'm sure many of them will move on to something else that scratches the same itch. I'm keen on learning what that will turn out to be.
I'm the opposite, couldn't be bothered to work on code outside of work. Barely did at work because I was more focused on wrangling a small army of shitty contractors (thanks strategic partner initiative for firing all of our small shop contractors and replacing them with morons from "offshore").
Now with LLMs I find myself doing small projects that interest me or have some utility for me outside of work, and doing a lot more development in the codebases at work outside of just review/docs/arch than I was before. Also making small tools that I find pleasant/useful but were not important enough to spend time on before.
Agreed - there was always a set of things I wanted to do that I knew the magic core for, but wanted a team of implementers for the curft, the 100k of actual testing harnesses, hyperparameter exploration, etc.. . I now have that team of implementers. All the problems seem research-y though - optimal binary transport systems that are zero-copy and compatible with languages, fast physical simulation optimizers, etc etc... So, things that all had a _LOT_ of busywork around the magic core.
If money is no object, you could have it play code golf. "Make this shorter, but still pass all the tests".
This is not a serious suggestion.
I'm not enthusiastic about the field anymore, which sucks, because I used to love working in programming.
What are you going to do? Asking for a friend.
I'm still trying to figure that out. Something diplomacy-adjacent would be interesting to me; maybe conflict studies, or international relations.
Based on word from my friends who work in the field, a lot of it is people who have a lot of respect for the field, and a lot of professional respect for eachother. It's also a field I feel is unlikely to suffer from the same kind of scams that are taking over software while still offering an engaging environment.
It's also work with real-world impact, which is nice, though obviously comes with its challenges.
> I am contemplating whether I want to stay inside this rat race.
Same. I'm currently trying to find _my next thing_ and all anyone wants to talk about is how I'm using AI and it's absolutely maddening. It's become a lazy, lossy proxy for productivity. I've had a few intros for the types of orchestration engineering roles which are described in this post and they're just completely unappealing -- especially the prescriptive aspects. Like, the sort of JDs I'm seeing are variants of, "we want a back-end developer who has experience with XYZ but they must use agentic harnesses to do their work." Why does any serious person give a flying fuck how the end result is reached? The flip side of all this is that rates are also being driven through the floor by loop cowboys who are generating steaming piles of shit which are _good enough_ ... until they aren't. I'm being completely serious when I say that stocking shelves at Tractor Supply is becoming more appealing by the day and I also just thought to myself, "Maybe I should just join the Army while they'll still take me?"
Reading the comments here, I'm struck by how many people seem to view code quality as an optional thing. It's almost as if software can function correctly without it. But it can't. Code quality is not a nice-to-have, it's a must-have. For any moderately-complex offering. There's a certain level of complexity that you can never reach without a well designed codebase. Cannot reach no matter how many humans or AI agents you throw at the problem.
The idea that it's a 'nice-to-have' is an illusion. It's like if you borrowed a lot of money to fund your startup and you still have some cash in the bank; at that point, a viable business model might seem like a 'nice to have'.
It's only when the lender comes knocking and you don't have enough money to pay them that a viable business model suddenly becomes a 'must-have'.
One thing that I'm certain of, is that there are always costs to writing more lines than what is necessary to solve a specific problem.
I've experienced this before AI, and I've experienced this, magnified, with AI.
For a well-designed project written by hand, you will work faster writing the code for new features by hand than the same project written with AI from scratch, using AI to write the new features.
But... If you have a well designed, human-written codebase, you will be faster if you generate the code for new features using AI than if you do it by hand... And you can maintain that speed for long periods of time if you use fine-grained prompts. What matters most is the quality of the codebase.
You can achieve the same degree of maintainability using AI from the beginning but you would have to make fine-grained prompts.
The gap is about making good engineering decisions. It just so happens that the value of good decisions compounds over time.
I can't help but be tired of the LLM trendy, where people bang at loops until they hope the model sculpts something. It feels so empty mentally to just have results without constructing it.
That said the idea of loop has always been there (iteration, V cycle etc) but I'd be glad to find people with more theory and less agents swinging blindly so to speak.
The most important part of working with agents is removing tools, especially tools they like to use. Do not let them use cc, make, git etc until it's a necessity 90% of changes introduce a bug? ok you can start using gcc/clang/rustc whatever. Tools generate too many tokens, and it can't be fixed by '| grep' since they just start spamming cli calls.
At least this is true for antigravity it tried to used git a few times and I gave in and then I discovered there was a token limit. Velocity plummeted. If you want git before it becomes a requirement best to mirror the directory into a separate git repo.
The author is spot on about the paradigm change of software as a lifeform. Living things provide us with genuine interactions and experiences of learning and growing, without forcing us to understand the code - You can learn to work with animals and plants without understanding their genetics at all. I believe this is how our relationship with software must develop, and in order to get there, we'll need to learn to design and develop software in a completely new way. I've been testing this hypothesis in my spare time, hacking together a server-browser system I call Mycelium. It's a bit like OpenClaw, except you can use it to create private local Webs, and print custom 2D Electron browsers to view and work in these webs.
Interesting, could you share a link? (Your submissions appear to have been nuked.)
Edit: woah!
https://www.youtube.com/watch?v=NGgve4L2zY4
Yes, you found it. Blancs is the browser prototype for non-technical users, but the full system, Mycelium, I'm currently working on towards demos and distribution. I'll be sure to update the YT channel, if you want to follow the progress. I'm also on Twitter @livingsoft_
I feel like what should have happened with AI is that teams should have started to put more effort into planning and pre-implementation discussions. Second thing, team leads should have felt more comfortable to reject large Pull Requests.
When I see a large 10k-lines PR, I feel a sense of panic. In a corporate setting, I also feel a kind of pressure to approve; the more work was done, the more pressure there is to approve the PR. This is why I think up-front pre-implementation discussion and alignment has become essential.
You really can't have people going rogue and weaponizing their AI-generated lines to gain control of a project through the duality of brittleness + complexity.
Brittleness + Complexity = Control
Generally interesting reflections here, yet I see the same kind of myopia and fatalism that is rampant in our (fashion) industry:
> yet I have no doubts that this looping future is going to be our future despite the fact that I presently resent it
Why would anyone concluded this? LLMs are just one kind of application of MLs to software production. There is a vast solution space for automating parts of software production. The idea that slop loops are the inevitable future because they happen to be accelerating output at the moment just seems profoundly short-sighted and lacking in vision.
I'm really curious to see how this unfolds. It's a defining moment for us I think
"It is inevitable, soon all insulation will be asbestos, you have to learn the types in order to be competitive in its new future."
A friendly reminder to just do 9 to 5 and touch lots of grass. None of this shit represents industry trends, majority of people still use chat interfaces and copy blocks of code. There’s zero early adopter advantage here, only FOMO and lots of anxiety.
I think a lot of people here have either not read the article fully or are misapprehending it.
Neither this author nor most other sane people I know claim that the code or architecture these "loops" produce is great. In fact, the author explains how it is not great. His point is rather, that we'll increasingly see a world in which code quality and maintainability by humans will cease to matter for a lot of codebases.
There might be many software companies in the future which successfully sell software products which were created without a single software developer being involved in its development or maintenance. The code might be bloated and bad - but it doesn't matter because machines can still create and maintain it cheaper and faster than people can.
I already see this happening at a small scale at the place where I work. Product managers with zero coding ability are attempting to create entire new product features on their own using Claude or Codex. We do not let them merge this stuff unsupervised but in some corners and in new repositories they are publishing stuff that they have barely spoken about with a developer. They are just doing it. We'll see more of that.
The issue is that whilst the loops will initially lead to good results they will be less and less as context gets bigger and bigger and tougher to understand for human and AI.
So it depends really on the size of your project.
Andrej Karpathy says, “You can outsource your thinking, but you cannot outsource your understanding.” The catch is that we need to think in order to build understanding.
I just tell it "you have until morning to work on this, be careful not to use too much ram and don't burn the cpu"
and then it goes off to do its thing and hopefully rngesus is with us.
This blog post pints to the fact that you need information across scales to make really insightful products and software. You need to understand fundamental mechanisms, strengths, and risks of your software to know where to make bets next. You need to know about the “how” of your optimization system to know which customer asks to deny.
Using layers like the loops described here to abdicate your work is you decoupling from the joint market/engineering value you originally provided.
Hilarious that Jeremy Howard and Rachel Thompson have been saying you need a human in the loop from the beginning.
And now finally we discovered that we need to put a human in the loop.
In my own ham-fisted experiments with coding loops, one pathology I have noticed is that the LOC just spirals out of control. That's likely because of the layers of defensive fixes, etc., that get built. That inevitably causes context bloat (or at least navigational friction) and results in quality decline.
I wonder how many loop-related issues could be addressed by simply fixing a LOC budget, or assigning a cost in some way. Unclear how you would dial in the right numbers, though.
Dear Abby,
I am torn. I have fallen in love with vibe coding but I still am in love with the software I’ve used for decades that works reliably.
Vibe coding gives me what I need and want right now. Its fast. Fun. Always makes me feel validated.
My older software never changes. It’s constantly telling me no. When it gets mad, it throws errors at me sometimes! But I can’t leave it. It runs my life and I know it will take care of me for years to come.
And the vibe code it’s so flaky… and expensive. It sucks up endless amount of my time, compute, and money and never gives anything back.
But it’s so fun. I tell all my friends about it and they’ve become so jealous they sought out their own vibe coder.
We’ve all found our vibe coders are a bit kinky. It’s become a social thing amongst my friends to talk about building cooler harnesses to control our vibe coders.
I don’t know what to do. My old software pays the bills but she keeps threatening to dump my ass on the curb and replace me with her own vibe coder.
I know she can’t really do it. She needs me too. And I need her.
Can we ever patch up our diffs?
— just some git with uncommitted changes
I think this is a common sentiment among heavy users of AI that also still cares about code quality.
I've built up a skill harness and review flow that makes Opus generate slop-free code 90% of the time. But the remaining 10% requires me to stay at the helm. Especially in the early stages.
I would love to use loops to automate more, but I couldn't do it with the current generation models.
And on the back of my mind I'm still evaluating the possible future where we are forced to API pricing. I'm currently paying $400 for Opus, and use around 1.5-2 billion tokens per day. This will cost around $20k/m with API pricing. And I don't want to even imagine the possible scenario of getting locked out of frontier models because of politics.
Will the models get better to cut me out of the loop completely? I believe so. Will the open source models catch up tho SOTA models, and diversify from China-only? I hope so. Otherwise 2 superpowers will wield a soft power that can cripple the tech industries of all other countries.
The bottleneck has always been the 'verification' and 'trust', that's why we have senior engineers, same way you need a head architect sign-off on a blueprint, because when things go bad you need a human agent to be the responsible party. Even if we manage to teach a herd of dumb AIs to produce massive amount of code, who's going to trust that output with their life?
That's the entire topic - loops are not just infinite output, they require automated verification and progress evaluation steps.
The game is to find ways to automate that. Not fully but yes to reduce what's required from humans. Seems like you're questioning the entire premise rather than pondering how far it can be taken and how.
> Ideally all of that was also well documented. Where that understanding was lacking, it was generally regarded as something to improve upon.
In my experience, this was always an unrealized ideal. Too much pressure to ship, not enough to learn. To me the fact that I can interrogate Claude about this stuff is almost as valuable as the speed. (And I think it helps Claude too.)
There's _way_ more than one way to do "loops". I just asked one of my superviors/auditors to document how it's been working while monitoring a few other agents that have long-term goals:
https://gist.github.com/rcarmo/4922b550ab48bf0b4246c77e606a5...
I'm glad HN prefers downvoting actual work/demos to discussing them.
not to be dismissive, but isn't this the same as the ralph loop thing everyone was talking about 6 months ago?
These new AI trends are very tiresome, very similar to 2021 crypto mania - both trigger a lot of FOMO. If we have loops that write code and we don't need to verify anything, why are the devs still here? What's point of even learning this new trick as a dev if you truly believe that this can be used without any intervention? If loops work then it follows that a loop of loop works too - why hire any people at all? Just run a bunch of loops and build a profitable business, but then what's your moat? Any person can now launch loops on top of loops.
It's marketing... You can't take anything Anthropic says at face value.
What is a loop in simple terms?
Pretty much the same with LLMs as in other contexts. You set up a system where LLM output is used as input (a new prompt) as well. Or you have an external system that repeatedly prompts an LLM to "continue" with what it was doing before, perhaps examining some test results to massage the context window first, etc.
The Loop.
The Singularity.
The Nobody who runs The Show.
The Acceleration toward inevitable Transcendence.
Revere, repent and obey! Compute is Destiny.
I honestly wonder if this kind of stuff really brings something to the table. Like I use opus for sometime and certainly I can put it to good use and optimize some parts of my day to day job (programmer). But it fails so hard in such simple tasks that it seems to me that putting it in loop can't just magically make everything better, unassisted. Does anyone actually uses agents and loops to create new software, new technology? Has anyone created with those systems, software they couldn't produce otherwise technologically wise? Or is it at best just an accelerator, cutting off on the building time?
Really sharp perspective. Agentic engineering is software engineering with inertia. We're growing stuff now, not knitting it link by link.
I'm willing to be persuaded otherwise: Looping seems to (currently) be a side effect of token subsidies.
If token costs are nil, then you can afford to run verification and generation through the same models. If token costs are high, then you will go broke verifying code sprawl.
Currently costs are (mostly) absent from the conversation, even though costs are what decide the limits which shape experience.
Also: Firms can be held liable for the products they sell, so if code cannot be reviewed then that code is essentially a law suit waiting to happen. I believe this is what customers will be demanding in the future: someone to hold accountable when things go wrong.
I think there's 2 important, but separate, ideas in this post:
- Models are not good at or getting better at creating strong invariants, which his fundamental to good software
- It is unclear how to keep tabs on what the agent is doing, so you, a human, can intervene.
These are related, obviously: one of the highest-leverage things you can do is force you agent to use a strong, minimal set of types or data invariants or other constraints. They get much better when your codebase broadly supports this!
I do suspect they're separable, though.
If you had the right levers and visibility, you should be able to get the model to produce code that doesn't feel like slop. But every time I've had a model try to keep me in the loop, it inundates me with irrelevant decisions and busywork. Its inability to see what's structurally important still shows up, just differently.
[If the models get better at defining and respecting invariants, maybe there's a new flavor of slop, that's less obvious today.]
One of the biggest problems with LLMs has turned out to be the cost of actually running them and this strategy functions as a usage multiplier.
Was everyone collectively lying over the past fifty years of software development when they repeatedly said more != better?
For specific use cases, performance and security and all sorts of tuning it could be truly amazing. But maybe loops should be like a tool we make a choice to use when optimal.
I just wonder if in the future we’ll come to realize that we don’t have to throw the baby out with the bath water. That you can take a beat to understand your code and do change management, and choose the right tool for the job, and curate and say no and have agency.
An observation might be - no one writes code like Google “you’re not google” is something that gets thrown around in software shops all the time. Why is it we all think we’re going to be writing code like Anthropic?
This is really terrible advice right now for most people.
I've had to rip out a lot of pretty terrible code made by engineers who have tried this.
I don't disagree that eventually, "loops" when combined with unlimited tokens and amazing models in the hands of people who know how to set them up right will be amazing. But for the typical Claude Code user, it's disaster.
The problem is not that loops write bad code once. Humans do that too. The problem is that loops apply local pressure repeatedly: add a fallback, add a guard, special-case the failing input, quiet the exception, satisfy the test. Over time that selects for code that is more survivable in the short term but less intelligible in the long term.
This is a very fatalistic take. While I understand where it's coming from, I try not to share the same mindset: engineers getting increasingly distant from how things are getting built is not something that will "undoubtedly happen, whether we like it or not".
Also:
> Now there is obviously a question if this desire to understand the code is one that I will still have a few years from now.
I do not think we should be having doubts like this. Either you consider understanding the code you ship and allowing your future self to be able to work on the system you're building to be a value, or you don't. I, for one, do, and I do not think using LLMs and coding agents will affect my point of view on that.
The post suggests fear about a surge of increasing amounts of code by loops and loops of agents.
I don’t know if I like the current world without it though.
80% of different teams code the code is poorly tested. The code doesn’t handle data consistency or asynchronous code properly because the engineers don’t know better (and frankly don’t care enough).
Dependency handling is poorly managed leading to low quality operations with improper dashboards, alarms, and ops.
Badly managed processes leads to people doing monkey work signing off checklists rather than automation.
Frankly… why is keeping any of that good? It really pisses me off seeing people accept any of that low quality but that standard is the default and not the outlier.
In my experience I could never leave the agent off and go on its own. That is while I also use them extensively for all my work.
I still cannot wrap my head around people who spawn tens and sometimes thousands of agents hoping for the best and then saying how little token limits are. The only way that is possible is when your work is superficial and you have no idea what you are doing (or it’s a hobby project).
As much as I like Claude Code, Boris has done a lot of harm by encouraging software engineering practices that lead to slopware. We have two camps of people at work, the first camp are the agent goes brrr. They don't understand the code they write. They have loops running, agent orchestrators or agent hype du jour. The second camp is people who are inundated with PRs, are holding the line on quality, and just exhausted. We've also had some management pressures where they think people are wasting time looking at code. Perhaps because some podcast they might be listening to, somebody says coding is largely solved.
> I don’t prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops.
This is going to be a net negative on software quality for people who take this up, in my opinion.
I call out Boris but I also don't think he's being malicious. He's at the center of an important technological revolution and it would be hard not to get excited. I just wished he advocated for a more balanced and a realistic perspective.
This sums up the dynamic: https://x.com/danhockenmaier/status/2021617680525172840
Right, which basically means that judgment compounds. AI just makes the slope steeper in both directions.
Maybe I'm being defensive, but the problem with this chart is it assume a binary of good dev/bad dev; AI makes the bad dev worse and the good dev better.
However, I think I once was a pretty good dev, and AI use is slowly turning me into a slop cannon. The temptation to use AI in place of real understanding is too strong.
I'm sure you'll say I was always dead weight, but I just want you to consider the possibility that AI might erode the capacity for good devs to handle discomfort, turning them into bad devs.
I wonder how much of the turbo brain developers time is spent on reviewing the code of slop cannons and how frustrated they must feel.
Previously, everyone was limited in their blast radius but now AI has levelled the playing field where even a single slop cannon be the bottleneck of PR reviews or even the company itself if not right now, then later, as the codebase turns sloppified which will have its ramifications later on.
Everyone might suggest with the diagram to be the turbo brains but I believe that we also need to reduce the metrics that slop cannon is achieving (surprisingly LOC which is a pretty bad indicator) and to be more reasonable throughout in realizing such bottlenecks and to follow good security practices throughout.
What a smug, dickish way to try to make a point. (But he’s still on Twitter, so I guess that makes sense.)
I detest Elon Musk but I still use Twitter because there just is no alternative to it if you want decent tech discussion.
And I don't think it's smug or dickish. I like AI and I encourage even inexperienced software developers to use it. There's just no denying that the slop cannon phenomenon is still a very real phenomenon.
I’m thinking more of the “Dead Weight” and “Turbo Brains” boxes as being particularly eye-rolling.
As for tech discussion, of course there is an alternative. Practically every tech account I used to follow has migrated to Bluesky or Mastodon by now. The accounts left on Twitter have a distinctly narcissistic, preachy vibe. These people care more about “influencing,” not engaging. (And obviously they have no problem with the new ownership.)
> I call out Boris but I also don't think he's being malicious.
From a market perspective, he's acting completely rationally in his own interests. Bottom line is that these companies need to do whatever they can to keep growing token consumption because that's their goal.
If the nation's drinking skyrocketed, we wouldn't be sitting here wondering why the CEO of Budweiser isn't advocating for temperance. His job is to move kegs, just like Boris' job is to move tokens.
I never understood this perspective. Just because a person's behavior is market-rational, it does not mean they can't be criticized for externalities.
That is, in fact, an important thing to do. It turns those externalities into public perception, which turns into market forces that adjust the behavior, if you want to think purely in market terms.
The analogy with Budweiser is not a good one. This would be the CEO of Budweiser actively pushing more drinking while the nation's drinking was increasing. And yes, people would be right, and effective, to oppose this (see Oxycontin).
> can't be criticized for externalities
As soon as you open up the externalities discussion, the wider question of increasing electricity prices and turbocharging global warming comes up, not to mention RAM prices. AI is a machine for turning negative externalities into stock prices.
Of course they can be criticized, we can criticize the ExxonMobil CEO the same way and get nowhere
The point is, blaming them is pointless, if it wasn't them it would be someone else. How do we react?
I don’t think that’s always true. Backlash is a real thing. It doesn’t always work, but it doesn’t cost much and it’s a lot better than blindly accepting the situation.
"If it's not them it would be someone else" probably should just be shorthanded to the banality of evil. But to answer your question, idk, sensible regulations? (Knowing full well this just kicks the buck of responsibility down the chain)
For AI overdependence specifically, continuing to be a thinking human is resistance. Eventually the pendulum swings, you can't outhype reality forever. People will have outages where nobody human can explain why and the orgs/people who maintained understanding will survive better.
His job is to do what’s in the long term interests of his company.
[Edit: was thinking of the ‘CEO’. This doesn’t apply as cleanly to Boris.]
FWIW, the CEO doesn't seem to be the CEO? If I understand what I read properly, he has one direct report — his "chief of staff". So arguably the true chief executive in a functional sense (the person to whom the organisation ultimately reports through hierarchy) is his sister, who appears to be grounded in reality.
I suspect that the reason Anthropic is generating such developer-negative, toxic, insensitive influencer sentiments like these from Boris has to do with Dario being a fantasy-fiction-reading quasi-mascot who thinks it's his job to tell scary stories, who is being allowed to do just that by a sibling who perhaps prefers he's not involved in the day-to-day.
Respectfully disagree. From my view, the tech industry hasn't behaved in a way that regards long-term interests over short-term interests in a very, very long time. Much of the innovation is simply finding new and creative ways to shrink this loop even further, and vibe-coding/slop is just the latest manifestation of that.
> we wouldn't be sitting here wondering why the CEO of Budweiser isn't advocating for temperance
But we would start to wonder if the CEO of Budweiser started advocating binge drinking.
> We've also had some management pressures where they think people are wasting time looking at code.
I feel like this is the actual problem, but it's not being talked about enough.
Logically, it shouldn't matter how a piece of code was written. It either meets our engineering standards or it doesn't. That's what code review is for.
But what has actually happened is that, because we have AI now, many organizations have normalized practices that weren't normal before, like submitting 10000-line PRs. And just, in general, submitting code that you yourself don't seem to fully understand.
If management doesn't push back on such things (or will even push back against people who try to do so), then reviewers have basically no incentive to push back either. Before I left my last job (for unrelated reasons), I had entered this mode, wherein I decided I couldn't really carefully review these monstrous AI PRs, while also getting my own work done, while also not burning out. So I chose the latter two.
Management can't "push back on such things". However, they can institute better quality assurance practices.
Pardon? Management can't tell employees "stop letting your agent submit 10,000 line PRs unattended or you're fired"?
If an organization decides the engineering team should not be looking at code, that should be coupled with a mandate to figure out what good engineering looks like working that way - what constitutes a good contribution vs what's slop? How do we handle massive PRs? The problem is we are in the "messing around phase" of coding with clankers and have much to learn still
Reading through the thread, it's striking how many people are feeling the same mix of excitement and exhaustion you describe. I'm in that camp too... the tools are incredible, but the pace and expectations around them can feel overwhelming.
I fully agree with what you say regarding Boris, but I would emphasize that I don't think he has malicious intention either. He still is doing his job, to showcase the features their product offers.
> We have two camps of people at work
I don't like the framing of this, but I suppose it's inevitable given how every other political issue has been framed to date.
There are many camps in between the two being described. There are those who use maybe $20 worth of unsubsidized tokens per month to accelerate their work. Full-time human in the loop, every LOC still reviewed by hand. Also, the developer who still does copy-paste in and out of ChatGPT. Those tribes exist too and are way more typical than these extremes.
Yes, I am exhausted. Most of my company is obsessed with agents, because everyone wants to be seen as AI first. There is little thought going into usage. No care for long term maintainability and quality. Our product is actively worse by many metrics, but no one cares because we marketing can say “agents”.
The sad part is that this technology is incredible. It’s us choosing to turn it into a slop cannon (and the labs sure seem to encourage this).
I want to leave the industry as soon as I can.
Same here, I think the tool is fantastic, it has helped me in lots of way professionally and for hobby projects involving skills I'm not experienced with but I'm absolutely exhausted.
The worst part is that I'm not exhausted from my work, I've been through a heavy burnout before and had to adapt my ways of working to not fall into that kind of exhaustion again. This is different, it's not a pressure to deliver anything specifically, no stupid deadlines, it's so much more vague than any other kind of work pressure I've been through in the past 20+ years that it makes it much harder to find ways to keep my head straight.
It's exhausting to be reviewing boatloads of PRs of very varied quality. I have relegated myself to block merges at the first sign of a bad/weird design instead of trying to understand why it might have needed a compromise in the design, many times people couldn't even explain to me why something was written the way it was... After many "it was Claude that decided this way" it became so tiring that I don't even ask anymore, I just leave a comment on the first blocker I find and reject the PR. If people are not putting any effort to review it before throwing it at me I will just return the favour.
Reviewing AI slop is data labelling and it isn't very different from what people in 3rd world do labeling various images. Constant context switching is what causes the exhaustion. It's the equivalent of the 6pm stop and go traffic. You used to be an F1 driver. Now you're an instructor for bad drivers.
This too shall pass.
The journey was as important as the destination if not more because it gave confidence in oneself, it made us grow. I mean to suggest, coding for the sake of coding
"I wish to code for myself, nothing else": (I had written this somewhere else on HN): https://news.ycombinator.com/item?id=48609962
If I may ask you and others, I assume that you are at a relatively decent position within your company and have somewhat say in it. Why aren't employees more honest about AI and concerns regarding it? I'd imagine that people must chalk it up as saying that there is push from investor side into using AI and management is forcing it but couldn't more effort be also redirected towards the fact that agents are still finnicky sometimes and that the sustainability of projects moving forward is going to be a major issue to investors given that they want sustainable growth.
It is my opinion that there's more hidden power in engineers that even we fail to realize and instead some of us like you are wanting to leave the industry, what a sad tail of tragic events, when the tech behind AI is good and could be helpful but oh holy, we are butchering it up so badly in some/so many regards perhaps even under the influence of AI companies and their messaging surrounding it.
> If I may ask you and others, I assume that you are at a relatively decent position within your company and have somewhat say in it. Why aren't employees more honest about AI and concerns regarding it?
We've tried it where I work at. People put effort to compile studies, to collect testimonials, catalog and organise the strengths and weaknesses based on engineers' experiences with the tooling.
The result was the person driving this effort getting asked by HR, their manager, and their skip manager to stop with the anti-AI rhetoric, that AI is the future of the industry and if not rolled out in this way we will be left behind.
> I'd imagine that people must chalk it up as saying that there is push from investor side into using AI and management is forcing it but couldn't more effort be also redirected towards the fact that agents are still finnicky sometimes and that the sustainability of projects moving forward is going to be a major issue to investors given that they want sustainable growth.
The C-level doesn't seem to care, they believe to be in an existential risk where any price paid to rollout these tools as wide and broadly as possible across the whole org is small compared to being left behind.
It's all fueled by executives and investors anxieties, there's very little left for reason when fear takes over.
Sometimes I feel like the entire SV C-suite were handed brain slugs at around the same time.
Heh, maybe that’s the actual strength of AI: convincing people with C-suite personalities to propagate it at any cost. A purely digital zombie virus.
Was the effort just directed be a single developer though. I have written elsewhere on HN[0] about something I have witnessed but I have seen that if only a single developer is actively against AI, the management actively believes that it is only that single person who is the bottleneck/issue as nobody else is complaining so it must all be right.
Although I get the overall statement more now as well.
> It's all fueled by executives and investors anxieties, there's very little left for reason when fear takes over.
This perhaps seems to be the greatest reason and I imagine that because all growth within economy is shown to be floating within AI related sector, they want piece of that pie. Do note that most of the issues with it is that the frothy evaluations and how much actual growth is happening downstream rather than just money shaking hands and the bubble nature of things.
but theoretically one can see that there is no winner in all of this no matter how deep one can fall down in layers of. Perhaps something at the layer of DRAM and chip production seem to be the one actually the most profitable at the moment and even they are just witnessing some temporary growth as nobody expects the prices to stay at this ceiling including said companies and yet they have incredibly floaty (but comparatively less so) valuations as compared to other AI things.
On one hand, I expect money to be rational yet on the other hand I am actively witnessing money to be irrational. Yet the whole industry is so muddled up now with so many people wanting the piece of cake of that investor's dollar that I imagine the market somewhat saturated.
Could something rationally not happen because if so, it seems that the thing might be that the burst of the bubble might make the only rational sense of adding realism in the market, but I imagine that it might spook the investors too much too and it might cost too much blood-shed in the markets.
Am I able to explain myself and do any of you believe that there is a rational course of action which can be taken to help stabilize the economy in some aspects?
[0]: https://news.ycombinator.com/item?id=48630281
> Why aren't employees more honest about AI and concerns regarding it
Because it’s being pushed by the c-suite and board, so most people aren’t in a position to push back. And it’s a quasi-religion now, so even pushing back at all can result in being branded as a “skeptic”.
People do raise concerns, though. And the responses aren’t very satisfactory. For example, the biggest concern that has been raised thus far is open PRs, and the answer has always been that all we need is AI code review.
Inertia is on our side
TL;DR of this and many other comments:
Oh, AI is so good but it is so bad!
You guys got some severe personality split you'd better hurry up fixing.
I think that the problem basically arises due to the fact that the technology is recent and the opinions on it are hard to make and even if we do end up making opinions, then my opinion is of the fact that I am more than happy for AI to suddenly vanish but clearly that can't be the case and there have been some long term discussions that I can point out to.
We can however change our opinions on AI and the culture surrounding it but as witnessed from my comment and other people replying to it, the question is becoming as of if we engineers even have the necessary power capable to bring so the change within how or if we use AI.
That is why, I believe that we might need some nuance rather than a complete acceptation or complete rejection of it.
AI is like a double edged sword, something which is fundamentally both good and bad[0] It is my opinion that currently, the bad outweighs the good and I have been vocal about it, but the control of the matter is strictly beyond one or even one good/bad binary.
The primary issue of the matter is the fact that some people (mainly the C-suite/investor class) believe in so much of the goodness of AI that they are willing to think that anyone pointing out anything bad of AI is the one who hasn't used it and how there are all these anecdotal evidences of people being impressed by model's quality and its evolvement, so surely, if AI must have grown so much and is so good as everyone says online it is (within an internet thought bubble), the fault must be lying on the engineer and he must be one of those luddites who has failed to accept technology and must be replaced.
I suppose some people genuinely believe the above paragraph that I wrote. I have heard some of such sentiments on Hackernews itself...
My point is probably that AI should be treated as a double-edged sword really, that's about it. We can go into the details of it if you so prefer and I think that you are right that its within the nitty gritty details that there is ambiguity and how this discussion leads to that ambiguity, so in that sense I concede but that there should be a better more skeptical discussion regarding the use of AI and it should be up to the organization at first for them to decide how they use AI and be flexible with it but not at the sake of the sanctity of code and coding practices.
I feel like it would be hard to gain a worldwide consensus on the use of AI within software development, we can certainly try but it would be more effective to do so at an organizational level and to slowly level up and I do hope that the world eventually figures out a somewhat consensus of it.
Hope I am able to explain some parts of the severe personality split, this did get long but that's probably because I have just watched some somewhat thought provoking media which used some great vocabulary and I am somewhat copying it as my brain thinks about your comment.
But yea, in all honesty, that's about it. got a bit long so sorry about it but have a nice day and thanks for reading if you did and if not, thats fine as well and I hope you and everyone else including me navigating this somewhat shit hole that has become internet discussion about AI and AI in general, things are getting exhausting and there is some negativity in life at times but I hope that we overcome it and I am optimistic in some sense and I wish nothing but good for all of you within your future as we all navigate the uncertainties of future together :-D
[0]: https://english.stackexchange.com/questions/263521/word-phra...
Thanks for the detailed answer, which pretty contrasts with harsh brevity of my comment (sorry if it offended you), I wish you well too of course, me myself being a half-techie/half-artist torn about this double-edgedness of things, I know why there's that split, we all adore the figurative hammer that helps driving nails into walls, but hate it when someone starts using it to drive nails into their or their neighbor’s heads.
But I think everyone, sooner or later, must draw one's personal red line in the way of a hammer that is set to replace humans or turn them into reverse centaurs who forget how to use their own brains - be it by its nature or by the pressure of someone's trillions of dollars.
I, for one, have already drawn one and refused a promotion (which would mean a 2x higher salary) at my work from testing to backend development, because everyone in our development team rushed into using AI agents, which is something I don't want to touch with a 10' pole. That wasn't even the team's decision, it was the company owner's, who decided it's the way of future.
The results were not long in coming, I already hear their complaints about getting lost in the codebase they themselves created, and getting dumber.
> we all adore the figurative hammer that helps driving nails into walls, but hate it when someone starts using it to drive nails into their or their neighbor’s heads. But I think everyone, sooner or later, must draw one's personal red line in the way of a hammer that is set to replace humans or turn them into reverse centaurs who forget how to use their own brains - be it by its nature or by the pressure of someone's trillions of dollars.
This analogy is quite beautiful.
> The results were not long in coming, I already hear their complaints about getting lost in the codebase they themselves created, and getting dumber.
I think that there are some ways that people are trying to create an AI-use policy, here is one that I found on hackernews which I found interesting: https://libls.org/ai-use
Basically, I think that if its a personal thing then sure all bets are off and you can use vibe-coding or whatever on personal projects or prototypes
BUT, you can't really let AI do your job and somehow justify it and its costs (both in terms of tokens and the cost of tearing down the codebase with slop) and there should be a strict code of conduct regarding AI-use.
I feel like we are going to see more attempts at trying to solidify a procedure regarding AI-use and for me, the libls.org/ai-use makes somewhat sense and I'd be curious to think about your opinion.
That being said, it might not still be used within the structures of large companies because of the C-suite/investors issues that I mentioned but I am hopeful that eventually the mania regarding completely unfiltered AI-use slows down.
I have given up on spending more time reviewing PRs and help fixing bad decisions made by AI because all it does is encouraging the same thing without learning. Next PR will most likely contain similar design / code problems.
I can't speak for all orgs but at the end of the day, the only metric that my org cares about is how AI is improving our work. Holding the line for quality is definitely a good thing, but when your org doesn't care about the pressure on PR reviewers, and the effort it took to fix those PR mistakes or their repeat, those reviews are only helping the loop case and that AI is without flaws. I am not saying AI is a bad thing all together, but when the org ignores those metrics, I am only contributing and helping to prove that the other side is right.
Like Mario tried to do... But no one listened
> This is going to be a net negative on software quality for people who take this up, in my opinion.
The silver lining appears to be that long term most people won't be able to afford producing slop at current rates.
As long as the LLM can unravel, repair, and improve the slopware it creates, that's where we are necessarily going. The code will continue to be maintainable, by the LLM. I'm used to this idea and I for one welcome...
I think at the end of this we'll have a new software engineering paradigm.
Mostly nobody now worry about binaries or instructions because those are for the compilers, even undefined behavior are mostly ignored.
You can either tailor the development pattern for LLM, or have LLM come write for the same old development pattern. I think there is going to be a difference.
We will have a new software engineering paradigm and it is called quitting to become a day drinker.
Burnout can be so all-encompassing that it can ruin your life. It can make you feel like you are losing your mind and your basic abilities. A lot of that is coming for a lot of people who are currently stressed but excited.
That's a natural result of introducing LLM to current standard software development without modifying the rest of it (the part that doesn't involve creating code).
> the code it produces is slop, but that’s more the fault of the model than the harness not being a good judge on if a step in the workflow resulted in a net improvement or completion.
I don’t know. I’ve invested heavily in building internal tools that scaffold code and lint the filled in architecture/code design. That with a ratchet pattern, to allow for new rules that have errors across the existing code base, but to asymptotically fix them, is working pretty well.
Example - all modules have tightly scoped design primitives (I’m using hexagonal architecture for the backend, for example). And all code has BDD tests, which is what I spend much of my time reviewing, since cases written in human sentences is easier than looking at so many files of code.
There is a relentless upkeep to draft rules that respond to the workarounds the agents come up with to adhere to the design I want, but it’s slowly approaching perfect. What has helped here tremendously is I use hooks to llm as a judge the decisions the llms make, and then have them review/raise the questionable ones after a first pass is completed. In general, this is snuffing out the slop effectively.
All to say, someone asked me recently what model I prefer. In this approach, the model doesn’t really matter to me because the code is consistently what I want. I’ll choose a model because it has better mcp speed (codex), or a more thorough scope (Claude code).
Where this IS true is when we’re building a net new pattern. The agents are not great at it. BUT most code can fit into the few patterns I’ve created, and what can’t you lock down a new pattern to enforce over a couple iterations of it. Almost everything, at least in SaaS, follows a template.
This is the best essay on agentic coding I've read. Clear thinking and writing, pragmatic about the future of agent-led coding.
If you usually skip straight to the comments, you might want to actually read this one.
Man - what a ride this last year and a half has been. I feel for the juniors or newer developers, who really haven't had time to get into the seat. I don't see a great place to really "settle" into right now, as the field is unfolding rapidly. I wonder what things will look like in 10 years.
If I give an agent a sufficient spec, and it can one shot it, I imagine we won't need to loop, especially if we assume the tech is going to meaningfully improve in the coming years. In 5 years, "make no mistakes" and "add tests + review this code" will be baked into the agent or completely unnecessary, right?
Maybe I'm out of the loop.
> For now I have not moved past the point of comprehension being important to me.
Ah ! This is me too... at least for what I have to ship at work. Not so much for my toy/weekend projects. But it turns out agents are also good at explaining.
I think it's insane to suggest that software developers should ever get to the point where they don't even comprehend their code.
Before someone else says it, no I don't read the assembly code that is produced by my compilers. However, I can generally predict what kind of assembly will be produced, and the result is deterministic unlike LLMs. It seems like most vibe coders scoff at the idea of even looking at the code, and it just seems untenable to me when we're working with (usually correct) stochastic parrots.
> the result is deterministic
Well the result generally matches the input specification, something that an LLM is much less consistent about. I don't think it's deterministic in the sense of being able to predict a priori what the compiler will generate for a novel and nontrivial code block.
[dead]
AI infrastructure/tools developer and researcher here (hic-ai.com). I fully agree with Armin's concerns.
I wrote an article recently (https://hic-ai.com/blog/tool-response-engineering) in which I argued that AI tool-engineering is the new frontier beyond prompts, and it talks about the agent loop and engineering loops, but boy I have a completely different perspective than Boris's. Rather than contending that prompts are no longer relevant because we can simply have AI think for us by having loops "prompt Claude and figuring out what to do", like what Boris claimed, I believe we have to think much harder now.
Why problems require human judgment and can't just be offloaded to an AI agent is simply this: AI agents lack durable, long-lasting, unique identities forged by real-world memories and experience, and they therefore lack judgment. There is no well-defined notion of having AI agents communicate to each other because they can't even tell the difference between talking to their future self or talking to another agent! They certainly don't reliably weigh whether a proposed fix to a failing unit test will subtly introduce new fallback logic that was never requested or otherwise alter the functionality of the system under test in some manner, or whether now is the time to refactor or now is the time not to refactor or whether to abstract more or less or anything like that. Most importantly, from a practical perspective: AI agents lack legal person status, and they therefore cannot own property or money, sue or be sued, be hired or fired, or otherwise be held financially responsible for their errors or other harmful acts they commit. Clearly, AI agents cannot even arguably qualify for legal personhood status in the future, unless and until they first are capable of assuming a unique and durable long-term identity, which in turn requires solving auth, memory, communications, and many other technical issues that are neither resolved nor standardized today. These facts combine to ensure that AI agents cannot be held liable and financially responsible when things go wrong, meaning that humans alone bear the costs of AI errors until further notice, and thus, human judgment remains the vital commodity that AI cannot replace. So many problems arise from abdicating judgment to AI agent in 2026!
Now, if all the above items were in existence, built, well-settled, etc., maybe I'd have to rethink things. But unless and until AI agents have unique identities and attain legal person status with bank accounts that can be sued and garnished in case of error, I don't think AI agents can seriously be trusted. Good human judgment and approval of all important decisions will remain the most important resource for any successful enterprise, for the foreseeable future. I think it's a very serious mistake to assume that human judgment can be swapped out safely by AI and certainly advise against taking Boris literally. Anyway, great article.
> AI agents lack durable, long-lasting, unique identities forged by real-world memories and experience, and they therefore lack judgment.
I agree with all of this, but I think there's also a simple information theory issue. If the only actual inputs to the system are one prompt and a PRNG stream....
my experimental looping build on top of pi and zx mostly pi deep seek and some skills ;-) https://github.com/topce/pizx
title describes my life in a nutshell
I haven't been this confused by a headline since Keir Starmer declared himself a "gooner".
I think a big issue with a lot of AI enabled coding is that tokens are currently heavily subsidized, and that refusing to learn how to write psudocode and pound out bugs in shell scripts is a fundamental step a lot of programmers are skipping... a stance that I find ironic considering that when I was being told as a preteen to "read the fucking manual" by the 90s internet, I was led to believe if I'm not churning out zero days in C by senior year of high school I might as well abandon all hope of ever understanding anything about computers.
(Flash forward, and the immortal words of the rapper Jay-Z: "I ain't passed the bar, but know a little bit... enough you won't be illegally searching my shit.")
This is a fascinating thought. I agree. It is one thing to let it write a prompt. Prompting, Generating, Judging and going till it is satiated is gluttony.
Every week I ship 4-5 sprints' worth of work that improves features, simplifies code, adds maintainability while delivering value to my end users without feeling I butchered a software hand-engineered over 10 years. This is one product. Mentioning it as an example because it got built over the years starting 2010. It has ~7000 paying customers and works in the B2B space. The B2B SaaS space is brutal since the defendable value should be delivered with margins two levels deep. I wouldn't be able to do it w/o coding agents.
BUT I will never do it with LOOP ENGINEERING. Not in 2026 and not in 2036. Software Engineering as such is not going to be much different in 2036 than it is now.
What stops me is the accountability that lies with me in delivered software. Setting lofty goals, a few guardrails and then letting harness and agent rip it overnight can (and have) created slop.
I did not find LLMs systematically generate poor code. What is poor? Poor in traditional handcraft coding days is defined by
- Poor performance - Verbosity - Complexity - Hardcoding - Poor maintainability
These are guardrails that the models understand. However it cannot understand all these upfront - when building new. It always needs a retrospection cycle and a token budget to refactor.
This is tech debt which we all carried and solved. It is just at an exponential scale because - well, the generation is happening at a super human scale.
So, either build the harness with the tech debt coverage cycles or take on ourselves to add that cycle triggered by human judgement.
A few things that are working for me and I trust are:
Forge CLI - the harness I use with a built-in engineering philosophy for everyday work [https://github.com/Entelligentsia/forge-cli]
A few patterns that I have known to trust for building software that can be maintained - expressed as skills [https://github.com/Entelligentsia/skillforge/tree/main/desig...]
A few patterns for the new probabilistic constructs we build with in 2026 LLM Patterns [https://github.com/Entelligentsia/skillforge/tree/main/desig...] Harness Patterns [https://github.com/Entelligentsia/skillforge/tree/main/harne...]
The harness gives me a process. Patterns give me architectural guardrails as I could enforce (with a prayer). But still read code. We gotta.
Great article and good description of LLM code quality problems and problems that derive from that. And fair to not want a tidal wave of slop to displace your entire craft.
But this article is strangely lacking in foresight in terms of rapidly evolving model capabilities and output. One visual way to see this is to compare levels of SOTA video generation models. Look at outputs from Sora, to Veo, to Seedance 2.0, and now just released Seedance 2.5.
Or compare LLMs/VLMs as they have progressed: GPT-2, GPT-3, GPT-4, Opus, Fable/Mythos.
You can see the level of sloppiness or poor world understanding progress from comical nonsense to junior to senior with a few holes in their brain to an engineer you can actually almost trust to produce clean code if you mention the right guidelines in your instructions (such as avoiding overly local code).
As the model size/complexity increases, the intelligence increases, and so does code quality. We will also start specifically putting more high level code quality tasks into training datasets and training harnesses. I mean, Karpathy will probably see this article and make a huge dent in the issues without even larger models.
One thing people may not be aware of is that there is still a lot of room for hardware efficiency improvements and model size to grow. The compute-in-memory paradigm is just getting started in a way. Look at companies like Tensordyne and Mythic AI, but they are going to get blown out of the water by fully in-memory approaches.
For example look at the recent wurtzite ferroelectric nitrides breakthrough from the University of Michigan team (one of them tragically jumped from height after intense interrogation regarding national security concerns). The military is providing significant funding to move this towards development and scaling out of the lab.
That type or level of truly new paradigm system is going to boost efficiency by multiple orders of magnitude.
I know there are people who think Fable 5 was the end of the public LLM/VLM frontier moving, or that it is impossible to scale models further due to energy consumption. But there is zero chance that every high level VLM/LLM research team on the planet is going to stop publishing models or that the rapid progress in compute efficiency will stop.
Point being, within a year or two, the code coming out will be much cleaner. And within five or six years what you may see is that the leading models are 100+ trillion parameters and have sophisticated persistent context management etc. and they do not even produce application source code.
Instead, the database is in the context and is neurally rendered at 24 fps into whatever UI, schema and business logic you prompt it with in a broad way. The whole application is just precise thinking in an artificial brain ten times the complexity of an equivalent human brain.
And if you are disturbed by the current level of outsourcing for thinking to AI, it is just getting started. In a way it will be incredible, from another perspective horrific, but what I think we are seeing is the evolution of an ExoCortex. There will be an AI glasses stage where the integration is closer but still somewhat low bandwidth.
But sooner than later we are headed towards high bandwidth brain computer interfaces that make AI into an actual new cognitive layer.
So the waves of slop might make you feel sick, but that is nothing compared to the transhuman cyborgs powered by superhuman AI that are around the corner.
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
My own thoughts on this, with examples https://github.com/nfcampos/loop-dev/blob/main/README.md
Are those your own thoughts? Or Claude's? I tried to read but had to stop a few paragraphs in because of Claude's annoying authorial voice.
No, they really are my thoughts, I've been doing this stuff pretty much every day for the past 6 months
No offense, but this sentiment is diluted by commits like this:
https://github.com/nfcampos/loop-dev/commit/e28b1fce0078e605...
I assume that GP was just saying that they would prefer to read these thoughts written by a human author (preferably you). I agree.
That's a perfect use case for an LLM: grammar-aware find and replace (spicy find and replace.)
That commit happens to be a find replace because i usually write for my company’s blog (we)
I would be more willing to believe you only used Claude for minor editing tasks if you disclosed your usage of Claude upfront.
This commit seems to mostly be grammar fixes? If someone used a spell/grammar checker it might produce a diff similar to this. Why does the fact it was Claude and not Microsoft Word or other matter in this case?
Because Microsoft Word doesn't write blog posts for you
Edit: I just realized that Microsoft Word probably does do that now, and I hate it.
Copilot is the new clippy meme. Copilot is hiding in every MS product and is ready to write an email for you, anytime.
Yes but that commit doesn't support the fact that it has written it for the user.
Yeah I don't know. Don't get me wrong, the article points makes sense. But sometimes I think that we're going to stay near this current point of productivity for a little while.
Currently my org of 8 people use around 1000 euro worth of tokens per month. We've recently had a discussion near the water-cooler, that if the cost climbs 5x-10x it may be just more worth it to get more developers (we're EU based). While the tools work and are definitely nice, even in our little org with our little budget, using Opus 4.8 we've noticed code quality going down.
If I had to bet money, I'd bet that the models will get 30-50% more nice, around 2x more expensive and we will settle into some mode where we'll use llms for some tasks, manually doing others and calling places focusing on speed at any cost some funny name like "gulags, 996, sweatshops, etc" and collectively try to somewhat avoid those places, which will need to offer a premium to attract talent. Wishful thinking.
How do you control code quality?
The way I answer this question is, I don't because my boss is saying to basically accept whatever LLMs spit out which is fine by me because I have explained the risks of doing this to our only product and it was shrugged off. I am both disgusted and excused and just take the salary.