Software factories can implement anything given a one-liner requirement. That one-liner requirement can be a complete app/product, epic, feature, bug, design change or refactoring. But these one liner requirements are requirements coming from a human who has an intent or requirement or direction for the product to evolve in mind. Can Software factories manufacture intent that reflects the exact requirements of the person using it or their vision of how the product or software should evolve?
Implementation in any language is as easy as generating a summary for an LLM. If coding is only math and there is only one way to translate a requirement into an implementation, the problem boils down to just providing or verifying generated intent. But, there is definitely more than one way to implement a thing and one of the ways leads to a design and architecture that is coherent with rest of the system, design and architecture that is extensible and evolves, code that you can keep in your head when you want to change things next time or tomorrow, software that can serve millions of users and securely guarantee millions of dollars of revenue. There is a combinatorial explosion of ways and the one right way is also subjective of the person and the problem. Software factories can of course improve Quality by generating more unit tests, more integration tests, fix code violations, generate Proof of work as videos, screenshots etc, but there is no feedback loop or test suite to verify and correct the other subjective notions of Quality.
- Customer really wants X
- Customer doesnt actually need X at all
- Customer wants Y not X but couldnt express himself
- Customer B and C do NOT want X at all
- Customer is just messing with you for no reason
Also quite common for me is like someone says X is good (usually a PM) but common sense says it's crap, and when you actually ask the user they also say it's crap. If only LLMs could email a bunch of people for second opinions.
Or fuck them, fuck the managers, fuck the c-suites (intentionally decapitalized), go for a flat organizational structure like Valve where you have no one to report to (well maybe Gabe Newell or the team leader for that project occasionally), but the culture is that everyone can manage themselves organically rather than having hierarchies and forced, useless reportings
Valve ships almost nothing, and the engineering quality is mediocre. Their game design is good, but subsidized by a unique early mover monopoly market owner position.
There is almost nothing that can be generalized, and people who hold up their organization as an example to strive for are utterly clueless
Well, while I do agree it is an early mover (I believe Steam is not the first to do online game platform, but it should indeed be the first one to use a CDN for the solution), I'm sorry that you have Ubisoft Connect, EA Origin, Epic Games Store, itch.io, GOG, Humble Bundle.
So you do have a choice. That renders the statement of it being a monopoly impossible. It's simply because every other platforms sucks.
In other words, it's like Nvidia. You choose Nvidia because AMD and Intel sucks, not because you don't have a choice.
tl;dw: it is a voxel ray marching plus flood fill with Mie scattering. I'd like to point this out that is not only a really good game design, but it also requires ingenious engineering quality. I tried to improve upon it by adding octrees (or in other word, making it sparse voxel octree) but it doesn't seems to add much.
Oh and plus their new bomb shock wave system. I tried to reverse engineer it with vector field, but I couldn't come up with the ODE equations to recreate it. I believe it has to be some kind of field, because in a high energy explosion, it scatter through air into fluid-like structure and hence we can use some aerodynamics for simluation
Why deliver one solution? You're thinking small. If LLMs were fast enough, they could build A,B,C,...,Z in parallel. So that's what will end up happening. The operator will just have to make sure there's no combinatorial explosion of the possible requirements.
Right. Because If I want feature A and it is available in configuration among features A through Z I will always perfectly pick the right letter of the alphabet and I will not at all be irritated by having 26 options that I have no idea about what is the difference between them.
But I think there's anyway a point there. I watched a talk once and it was humorously said that the amount of time spent discussing whether solution A is better than B is more than implementing both A and B and seeing in practice. It's funny because it's true.
If you’re working on an app or software that has few users, no revenue or minimal revenue, tolerance to bugs is higher and just another Claude prompt away, Software factories are a perfect fit. Most personal software or hobby software or 0-1 yet-to-find-PMF startups belong in this category.
You can even take a stand that you’ll never look at the code and just ship. This is a perfect equilibrium for a Software factory, where the only input or feedback is a one-liner/specced requirement and the only output is outcome of whether the one-liner requirement worked or not.
For almost any other software that does not fit this criteria, software factories are yet to solve the Intent and Subjective Quality problem.
The 900 pound gorilla has for a while been "where is all the output of these LLMs?", and this seems to be the answer; the number of apps on the various app stores has skyrocketed over the past two quarters but installs overall are actually down a little bit. So it seems like we've had an explosion of software that one or two people use. Which is a cool situation to think about but is pretty bearish for the "AI as a profitable business" idea.
Marketing was a problem with apps even before AI, which, with today’s slopforests makes it even harder for consumers to see any of your trees even if they wanted to.
Right but if we're going to a small-batch bespoke development model then "marketing" more or less disappears because why would I pay someone to talk to an LLM when I can also talk to an LLM? The money goes from the end user to the lab in this model.
What happens then, though? Is it good to have tens or hundreds of thousands of potentially angry marketing managers roaming around that were developed out of careers?
> If you’re working on an app or software that has few users, no revenue or minimal revenue, tolerance to bugs is higher and just another Claude prompt away, Software factories are a perfect fit. Most personal software or hobby software or 0-1 yet-to-find-PMF startups belong in this category.
I would rather claim that for my personal/hobby software, I apply a much higher quality standard than for the software that I write at work.
Believe me: I would love to apply the same high (or even higher) standard at work, too.
The problem rather is that it is a very common situation that bosses actively prohibit me from rocking the boat too much. If I make (I think typically good) suggestions, I often get very stern reactions.
At work, elegance is not celebrated - just implement the tasks of users who don't care about quality or elegance.
I’m always surprised when I read comments like this. I’ve come across far more situations where individual contributions take a slapdash approach and management is disengaged than management actively imposing poor quality work.
I don't think so? It's very common in both large companies and small startups where pragmatism has a higher priority than so called elegance or whatever you call it the "artisan" feel. It's varying shades of "perfect is the enemy of good", where different cultures and business environments dictate how much a manager is going to tolerate your proposed refactoring. At least that's what I got from the parent lost.
> If you need to actively keep your head down, you need to quit.
This really depends on whether they are paying you decently. The number of people I've met who found a nice corner in FAANG, and decided to keep their head down and collect a steady paycheque... One may find one can swallow a lot of engineering pride for a recurring six figures
And that’s not to say anything about personal situations. Family obligations, immigration requirements, etc.
Especially in the current job market, “find a new job and quit” is going to cost you so much time and effort and for many people it will still be a lateral move in terms of company quality in regards to engineering practices. It’s hard to make these kinds of deep company discoveries until you’re in the thick of it but by then it’s too late.
Personally, I’m advocating for change where I can and not taking it personally when the manager says no. I put in enough effort not to get paged in the middle of the night which is generally plenty for management. It helps that I don’t work in a super strict business environment.
There’s more to life outside of work as well so if you can silo that bit of your life and enjoy things outside of working hours and you’re content, so be it.
The perfect poster boy is system scripts. They’re not even published usually, but being able to just generate < 500 line scripts for everything is a huge boon.
It goes hand in hand with Linux desktops too, because everything is just so much more scriptable. That used to be intimating, user unfriendly, and maybe it still is. But with AI it enables so many new avenues.
Now that LLMs can do the actual configuration, I started using NixOS and now all my config lives in one repo, and every quality of life improvement fans out to every machine without issue.
Since Claude (code) knows all about my system, it will also tailor solutions to it when I ask how to do something. Using it I can often find really neat solutions to whatever sys admin task I can imagine.
There's some good ideas and points in here, but this bit threw me:
> # We tried this
> In July 2025 we went full lights-off
Isn't it pretty well-accepted at this point that the models underwent a step-change in usefulness around fall 2025 / spring 2026? I know that I was able to start handing agents whole features after that, but not before.
I feel like any perspective/experience on "what agents can/can't do" from before that period is... maybe less than relevant to the modern era. TFA calls it out a few sections later with "But surely the models have gotten better since then", but then just writes off any improvement. That does not match my experience.
I had a bit of this impression when reading the post as well as the authors' product website. A lot of it does seem to be stuck in 2025.
For instance I think their post "long-context isn't the answer" on their website post straight-up isn't accurate, and gives me the impression they are just extrapolating previous performance to new models. In my experience, Opus 4.6 and newer have worked very reliably for long context to me (i don't perceive any intelligence drop at 700-900K tokens). Yeah it's extremely cost-inefficient, but it works.
> i don't perceive any intelligence drop at 700-900K tokens
I have countless examples of this for Fable 5 and Opus 4.8 at just half that many tokens. Sometimes they can't even remember the correct workflow even if they're merely an orchestrator and have been going through the same 5 step loop multiple times for pretty much their entire context window.
One of them is particularly egregious because it uses a CLI tool to step through the stages that literally tells it what to do next. How do you fuck this up? Needless to say that tool was revised to force the agents to acknowledge everything happened, but I'm sure it will find a way to eventually mess up anyhow.
And orchestration should be the easy part. It's pretty much just writing and adjusting workflow files. Don't get me started on code quality - but I realize that's subjective and my bar is unusually high. There's a reason I have them run adversarial verifiers along multiple axis before their output is even worth my attention.
FWIW, I notice the intelligence drop drastically with long contexts with Opus 4.6. It's barely usable for anything intricate and long. That long window is good for _something_, but it's not as good as a short window.
Oh yeah, that's a use case I love long contexts for. "Here's a day of prod logs, what's broken?" It's an incredible utility, but the qualities much less than with shorter contexts, and you see it much more apparently when you do similar coding tasks with progressively larger windows.
Opus 4.5 was a massive step change in capability for sure. The opinions of anyone who hasn't bothered experimenting with these things post-Opus-4.5 are not worth a damn.
They still are far from perfect but they're massively helpful.
I just listened to a podcast last week with the author (Dex Horthy) on as the guest. Humanlayer (his company) is constantly trying to push the limits with agents and he's very into using them.
He's well aware of exactly how good the models are today and I'm sure that if he thought they were good enough now to make the dark factory idea work, they'd be trying again.
The obvious statement would then be: 2025 we went all in, 2026 still nothing improved substantially. I also agree with that statement, none of the frontier models handle drift any better. Shotgun surgery and all that. You're waving him off by waving him off, but provide no arguments whatsoever.
Is your experience substantially different?
my perhaps controversial take is that opus 4.1 was smarter than 4.5 for complex engineering work, but 4.5 was faster and "squishier" - it responded better to simpler prompts, it read between the lines of user input better, and that this was really important to converting new users quickly
As I mentioned explicitly in the comment you're replying to: yes, I did read that section. Did you not bother to read my whole comment before telling me to read more?
There's a more nuanced point about capabilities improving in some ways but not others (ability to one-shot apps vs. maintenance of existing code over time).
To me, the thing that stands out about the whole state we're in here is PR review.
Yes, in an ideal world, PRs read well, are a joy to review, reflect what you discussed etc etc. We have to be real; there is only so much we can do to that end.
I'm not sure how the best teams do PR review, from my perspective it sucks. I'm talking specifically about the UX. I've always hated Github's PR page, so I typically reviewed by pulling down the branch and opening the diff with $EDITOR.
These days I think there's really no excuse for the awful UX. Linear (a company that isn't even in the domain of code review) put out a basic PR review feature[0] that is already better than what GH offers. It's simple: point a small model at the PR, group file changes together based on theme, add some commentary and sort by importance (schema changes > openapi spec).
Immediately, so much mental load has been reduced without the reviewer or the requester doing anything. This feature is pretty damn basic, and I think there are obvious next steps like generating visualisations which a dedicated product could find the time to implement.
Keen to hear others thoughts on why this is the wrong approach, or if there are tools in wide use that solve for this, or why this isnt the right problem to focus on.
They don't do them. They discuss the changes as the team are doing them (software design and architecture), they automate all the things that would be nitpicks (linting, formatting, etc), and they adhere to a strict 'Do not break the build' rule so merging in something can't be disastrous (with a lot of automated checks and tests to prove that's true). They also make sure there's a robust rollback process just in case.
Once you do all that the PR process is pointless. It never catches anything useful. The team can trust one another to merge without that gate.
> Once you do all that the PR process is pointless
manual PR reviews can catch things that llms currently miss. Examples are duplicated code, lack of unit tests or introducing security issues. None of these really break the build. So just requiring "do not break the build" is a very low barrier.
Tests also are useless unless you have a smart system that runs the new test WITHOUT the changes and see it break. Most teams I see today have the LLM write a test along with the change, without a guarantee that the tests actually guard the feature.
manual PR reviews can catch things that llms currently miss
I didn't say LLMs though. I'm talking about the sort of code quality tooling that's been in use for decades - Sonarqube, Codacy, CodeClimate, etc for code quality, eslint for AST-based code rule checking (easily picks up duplication for example), Istanbul for code coverage, Wiz or Github Advanced Security for security.
These are well known industry standards for knowing a code change is correct without giving it to an LLM to guess at. If you have them, and they're well configured, and you maintain the tooling properly, then PRs become unhelpful gates that don't find problems.
I am not familiar with all the tools you listed so please correct me if i am wrong, but all these will catch stuff that LLMs can potentially catch as well (if configured correctly).
They will not handle any architectural problems (i.e. this method is correct but doesn't belong on this package, or this method is called isX - but has side effects).
And I am pretty sure that none of them do what I am saying with the tests. i.e. run tests without the associated code change and see them fail. I am also pretty certain that none of them will understand problems with breaking backward compatibility (i.e., a fix that is correct that breaks the setup of all existing users).
In other words, it is possible today to create a PR that passes all checks, all security scans, all analysis tools, all test suite while still being wrong due to architecture, backwards compatibilty, wrong scope etc. So even before and even after LLMs a human is needed there.
PRs might become unhelpful as you say if in the future one of the two things we happen
1) LLMs have unlimited context so you can pass all source code plus all architectural designs them
2) We have a super smart analysis tool that is one level above what we have today (including llms)
> They discuss the changes as the team are doing them (software design and architecture)
I find the format of PRs to be better suited to discussion than slack/teams messages. Key developers need to actively sign off, code suggestions are much easier, and the CICD makes sure we're not wasting time discussing code that's not compliant with obvious standards.
Obviously some level of agreement is needed before creating a ticket at all, but implementation details around say creating a terraform module to share functionality between teams do need to be discussed somewhere - and it can be difficult for any individual dev to have all the low level context.
Thank you for this response. I do think this hits home as the most elegant and reasonable approach. For my teams currently, I can see us already moving toward this implicitly, but perhaps needing to take a more explicit approach. I think your framing crystalises it well.
Gating integration behind code review is futile. I (and many other engineers) already automated it. My agent responds to review requests and reviews as me. Company policies enforcing human code review are futile.
I think all these platforms chasing code review are doomed. My LLM doesn't need any of this tooling.
We should be reviewing the actual working software. Systems that make it easy and instant to demo any proposed change are what is needed. Code (and specs) are going to fade into obscurity. PR review has already shifted towards validating the product (working software) over the process (code).
The future of software production is more like Replit – not GitHub.
This entire article is about the fact that the codebase deteriorates over time when you work this way. If they are correct, it will take longer and longer to develop PRs, and more and more cycles to QA them. Eventually the code will be unsalvageable and it might get there before anyone notices a problem. I don’t know if they are right but I know codebases can get there with humans at the helm - and the humans can adapt and learn.
This is not a certain fate but it sure looks likely and is a serious risk. Some software is so low stakes that you can get away with it I’m sure - there are always trade offs.
The bet is that models get better faster than code gets worse. Looks like so far it's correct, as Fable can already write better code than me and most others on average.
the thesis of the post is that this is not true. fable can solve more problems but for complex systems it is not sufficiently diligent that you can turn the lights off.
They turned the lights off in 2025. The post is simply not accurate to today, they even say so, stating that apparently no one has proof of better models in 2026 improving codebases over time. I've seen it happen but the author hasn't apparently, so it's a game of "you said I said", not anything concrete.
(op here btw) - the question isn't "can models make code better" - its "left fully unattended, will they turn your codebase to slop over time"
from the footnotes (sorry if this got a little buried)
> yes of course you can get gpt-5.5 xhigh to do BRILLIANT refactors. But you had to tell it to do that. And to tell it to do that you had to understand your codebase well enough to know it needed doing. We're here talking about why lights-off wont work
i suppose this would also be a good place to ask if you fall in the "high stakes production systems" camp
> If you love vibe coding, please, go on vibing. I still vibe code lots of things, I just also maintain lots of production software (and through HumanLayer, help 1000s of other engineers do the same), so the rest of this is aimed at folks solving hard problems in complex codebases.
GPT 5.6 Sol and Fable are similar step changes, not 5.5, but that's beside the point. If in the Markdown instruction files you ask them to periodically clean up the code or refactor where necessary then that's what they'll do. They don't explicitly do it because otherwise people, as they had for previous models, complain where models are asked to change one thing then they rewrite whole systems, so now the latest models are explicitly trained on instruction following.
In other words you can make the AI act like a software engineer complete with fixing and improving code autonomously (Cursor gave a glimpse of this [0]). It is not a failure of the model to do this automatically but a failure of the human having the wrong instructions.
generic prompting like "review this code" or "make the architecture better" will raise the floor but cannot come close to human-quality code without humans understanding what code exists and what to ask for.
Obviously cursor and other labs have a stake in this going one direction, but I don't buy it, and I don't think you should either.
In fact, "Rebuild sqlite from spec" has all the problems with every other benchmark that I cited - model knows the whole problem up front and never has to iterate on the pile of slop it created cheating its way to a solution.
In any case, politely, I think we're mostly arguing vibes here and I'm not sure its going to get anywhere.
The whole point is that if you don't maintain high quality, any software will degrade to the point where the factory breaks. "Human-quality" here isn't quite the right measure because human software factories also bog down in exactly this way.
I’d say all of them. Most people use computers as tools or as entertainment platforms. While a bug may not be life threatening in most cases, it is annoying and stress generating.
Fable writes code better than most humans can already so we've already surpassed human level coding. I think thinking otherwise is just coping for the job or industry.
> Code (and specs) are going to fade into obscurity
I'm always skeptical when I read absolute statements like this.
Especially about specs. They drive and document how the software should work, behave, and under which conditions. In the same moment you write a prompt in natural language, you are writing a spec.
Why should they disappear?
For the same reasoning, we could no longer need books or manuals or documents (is it valuable to keep around that doc about F-22 specs?).
Agreed. Specs are more important than ever. Constraints: types, contracts, protocols, schemas, APIs and such are what ground the boundaries of systems.
Without them, code drift is a guarantee.
Does anyone trust that a set of human sentences typed into a box is more reliable and precise than objectively exact descriptions of data?
This is not to diminish the utility of these code factories. But surely, if anything provides resistance to drift, it's codebase consistency, standards, and things which must objectively be true for the software to function.
>I (and many other engineers) already automated it. My agent responds to review requests and reviews as me. Company policies enforcing human code review are futile.
This is also known as being a terrible engineer. If a company enforces human review and someone deliberately tries to circumvent this with an LLM, I'd fire that person in an instant
The reason for human code review is:
1. So *you* understand what's going on, not the LLM, and people can ask you questions about it
2. Because LLMs are not that good at code review
It seems weird to brag about literally not doing your job. It sounds like you could be replaced with a python script, what value do you bring?
I can't help but notice that this person is speaking as a programmer, not the person in charge of employing programmers. Is that what the business values code review for? In my experience, managers enforce code review as a quality control mechanism: the "Find Bugs" step in the article's pyramid. And LLMs are already better than human reviewers at the "Find Bugs" part. Design and alignment with PMs and sales can happen before and after software delivery. At least that's how my employer sees it (and I suspect most other businesses).
It's a rough time to be a programmer who cares about the code, who understands software is a creative process, who understands that designing the software is intertwined with the code, who cares about systems. The hyper-focus on delivery was already a lot to deal with before LLMs.
- alignment on new stuff being introduced into code bases (the bigger it is, the more important to consider promixity on things the teams are working on tho). also: maybe finding a more optimal solution together, implies a proper PR process (which I always created with my teams, it takes time and we plan for that)
- code quality assessment: maintainability, regression tests, taste, security etc. etc.
- code is improved by expecting a review in the end. if you know you're not reviewed, you might rush and push out suboptimal code. hurts the baseline
Maintainability, bugs, incidents, team understanding, complexity (all impacting future delivery, uptime, user retention, onboarding etc.) are all metrics I care about as they impact the software and the company as a whole directly. A lot of CTOs or other execs/managers might not care, but there are a lot of bullshitters out there. Or maybe I'm just used to complex software in regulated/hard fields, I don't know.
> In my experience, managers enforce code review as a quality control mechanism: the "Find Bugs" step in the article's pyramid.
Nope.
To reduce it down to a single word, I'd say we do code-reviews to assess "taste".
-----
Code-review is one part of a larger process (the SDLC!), and while review does help with "finding bugs" it is not the singular reason why we do it; and other parts of the SDLC are concerned with finding bugs in the first place, namely the various Test and QA steps in the process; when your code is in the (peer) code-review step then there's an expectation that the author already identified and resolved actual bugs/defects (i.e. where actual-program-behaviour deviates from the spec[1]), so a PR for new functionality is expected to include unit and integration tests to demonstrate that.
Now Claude will gladly take a Jira ticket, write-up a plan/spec, write tests, implement the feature, verify the tests pass, address static-analysis issues, push branch, and submit the PR - and if-the-program-works then it's "correct" and so surely there's nothing really to review and so merging the changes should be a breeze... but I find myself rejecting these PRs all the time because these agents still "just don't get it"[2]. (But I'm sure they'll "get it" eventually; you can't stop progress). We can revisit this topic when we get there; but for now I'm going to reject an AI-authored PR that eschews it.
Good taste is important.
[1] I'm not going to pretend anyone actually writes any kind of spec (informal or otherwise) for the vast majority of software out there; but an unwritten-spec exists when you mentally combine a vague Jira ticket, platform-conventions and common-sense (and that's how Claude in an Agentic Loop works too, except it always has to write-out the Spec.md/Plan.md to disk first, whereas us humans keep things in our head).
It seems weird to get angry about a change that is happening and will continue to happen due to what the market demands from software, which I believe will be the speed/ability to solve problems, rather than its own stewardship
I'm just here to do good software engineering and make good products. If people want to try and circumvent that process to deliberately make the product worse and slow development down, they're bad software engineers, its as simple as that
Nobody thinks its a good idea to fully automate PRs, at least not anyone with software engineering experience. It slows down your ability to solve problems if your code base is an absolute disaster
Again: If someone fully automates everything, what service do they provide? Why are they even there? Especially actively lying in the process when people are trying to force knowledge dissemination with human reviewed PRs
Sure, if you're shipping a 500MB mobile/web app with a 5s start-up, it probably won't make a difference today, or tomorrow, or 3 months later. The problem is when your codebase is a dumping ground for AI slop and a year from now nobody can make any changes.
Also, it's not just some subjective value put in human review. If a change causes a major outage and it turns out it's because 5 reviewers were all shirking the company-mandated responsibility of review, and it could trivially have been caught, I would 100% expect those people to get fired. It's not a process issue if people are intentionally circumventing the process.
SOX requires code review by a second party. If the reviews are automated, the development process isn't in compliance and that can get expensive in a hurry.
Sort of; it's like the itemizer systems at airport security. They're entirely theater (in the sense of "for show") but that show is itself important in that it makes entire categories of attacks significantly less feasible.
Sort of like how simply having a uniformed police officer on a street corner reduces street crime significantly even if the officer never interacts with anyone.
The role of a software engineer is foremost about the ownership of software systems, and secondarily about modifying them or developing new ones.
Software development is a continuous operational undertaking, like having a garden, and not a one-shot "task" like designing a logo. Systems need to be tended to and somebody needs to know how they work, especially if they're business-critical or (in the case of software companies), the business itself.
A corollary point is that many of the rules and policies of the business are solely embedded within the software itself. There is rarely a complete set of documents that says "this is how everything works" -- if you want to know how something works, you ask a software engineer, they take a look inside the codebase and then tell you how it works. In that sense, all software engineers are also product managers (or more accurately, product managers are just crude software engineers, but that's besides the point).
Producing features and fixing bugs, same as it was before. The organizational process of software development has not changed much with AI: execs decide direction and initiatives, PMs decide what to build, which is broken down into features and bug fixes that SWEs produce. In my experience organizations don't actually care how SWEs produce features, except insofar as it relates to how many and how fast the features can be pumped out. Organizations see code review as a process to prevent bugs. Humans are not as good as LLMs at reviewing code for bugs. Abstract notions of code style and quality that programmers care about is not why organizations enforce code review.
Before LLMs, "organizations" have seen code review as multiple things:
* Share knowledge about a particular area of the codebase between multiple people
* Share overall engineering knowledge between the parties in the review
* Ensure maintainability of the codebase long-term
* Ensure readability of the code
* Catch architectural/directional omissions (yes, from the planning/architecture phase) before it's really too late and non-reversible change goes in (eg. large destructive DB schema change)
* Ensure changes are small, self-contained, and as often as possible, reversible
* Do some basic manual QA
* Do comprehensive integration testing with a fully built-out system
...
* And yes, catch bugs before they hit production.
A lot of the above could be fun and engaging, and especially knowledge sharing and ensuring maintainability/readability was a very motivating thing for me as a more experienced engineer having learned so much from getting good reviews when I was less experienced.
Programmers care about style to ensure readability and thus maintainability of the code, but also to keep changes minimal — if every diff converted between tabs and spaces in the entire codebase, it'd be impossible to see what has really changed with the simple tooling we generally use (one could build diffing tools that ignore changes like these, and they even exist, but are not ubiquitous).
And it doesn't take into account maintainability, complexity, security etc.
I think the commentator above you is not a SWE. No one could be that ignorant
> We should be reviewing the actual working software. Systems that make it easy and instant to demo any proposed change are what is needed.
You’re arguing for experiment over logical proof or reasoning. That’s qualitatively a very different thing, and the former is no adequate replacement for the latter.
> We should be reviewing the actual working software. Systems that make it easy and instant to demo any proposed change are what is needed. Code (and specs) are going to fade into obscurity. PR review has already shifted towards validating the product (working software) over the process (code).
Ok, sure, if your software can be easily exhaustively re-tested on every change.
But in that case, why were you ever doing PR's in the first place? Cargo cult?
Like you said, they sucked back then but it was more rare to get PRs of many thousand lines to review multiple times a day in my experience. But I also run into a problem now in which I have coworkers in two camps. There are some that, when they send me a PR and I have serious concerns about it, it's because they disagree with me fundamentally on some concept and we need to chat and discuss it. And then there's some coworkers who send me with a PR I have serious concerns about because it's very clear they never reviewed the LLM output before making a PR. Those people also tend to take my comments, run them against their LLM session, and slack me back some Claude list-of-questions stuff, and often also respond to me with LLMese.
I firmly believe there's no reason to employ the latter group. I have several coworkers like this that I could replace with a Claude session or two every week and I'd still have to push back on work and review a lot, but I'd still wind up saving time because then I'd talk directly to Claude.
So I guess my point is that I dislike AI era code review because for some subset of it, I basically can't even assume a human has ever looked at it, and that by doing so, I'm doing the work for one of my coworkers who is probably doing his grocery shopping at 2PM as I read it.
No, commits always display the files in a fixed order, and then display changes from line 1 to line N. An AI could select the order to display in, add per hunk commentary and automatically adjust how much context lines are displayed.
But if you need to split the commit in hunks, and add a commentary per hunk, isn't that just a sign that you really should just split your commits?
That's the most killer feature of git, that it's so easy to slice your commits any way you desire, and then redo again. The use case of taking a chunk and commit separately is so common it even got a special mode in the add command. That, and the super fast jumping between branches is what set it apart from contemporary version control systems.
The extra context provided by the review tool is gone when the review is done anyway. Review systems come and go, but the commit log is for eternity.
yeah that was another thing i hoped would pour through here - that deterministic systems are much better for evaluating quality (test, linters, cyclomatic complexity, etc) - but that we don't have such a system for code maintainability, at least not one that's widely accepted or adopted
PR review sucks because engineers often don't optimise their code authoring for it. When they do it's a joy.
PR review of agent generated code sucks because agents are, in my experience, very poor at authoring for review. This makes sense because the review process is not represented in the resulting code artifact which is what they're trained on. Agents are always producing much larger changes than should be in a single step, and often touch unrelated code with poor judgement of whether it should be included or not.
One thing that really bothers me about agents is they generate excessively long and detailed comments.
This sounds good for review. Except… the comments are never intent or trade-offs, they’re always the “what”, which the code then duplicates right after. Comments should be short, concise “why”. Often I look at code and think “hm this is odd, I wouldn’t have done it this way, is there some constraint I don’t know about?”
The comment should explain that, not what the code is doing. If I wanted to know what the code is doing I’d read the code!
But this is my point, they're not really controllable in this way. There are no fixed rules (like tests or linters) for small PRs, it's not good enough to do it by line count.
A good PR tells a story to the reader that leaves them confident in the result. That means knowing the reader and how they think, and that is something LLMs are very bad at.
And you can't think of a way to bring an engineers mindset to solve that?
If you leave it up to raw LLM outputs you're not going to get the results you're after. If you put on your engineering hat and think about your problem statement and what tools you can bring to bear on it you'll find you can likely craft a PR authoring skill and a set of evals for that skill that satisfies your requirements with a high enough degree of reliability.
I'm not coming at this cold, I've worked on the skill for PR (CL) creation in the Google monorepo. I'm not talking about raw LLM outputs here. It's a hard problem that is fairly fundamental to the training material being used for LLMs today.
I'm sure we can improve things, I'm sure it will get better over time, but I'd say we're a small fraction of the way towards where we need to be, and trending in the wrong direction with long trajectory development creating bigger changes on average.
exactly. a great pr is a joy to review. we've found some success in agents generating static HTML walkthroughs that order the diffs in something other than GitHub's default alphanumeric ordering, but it can only go so far
Yep i aim to split my work into tickets that are <=1k lines of code each. In the end it all gets squashed into a mega 10k commit regardless but i can keep track of the quality much more that way.
(more precisely the sub-tickets merge into a bigger feature branch, which in turn gets squash merged into the main branch at the end. i have a tool that automates this flow with a gui and ticket management.)
> I'm not sure how the best teams do PR review, from my perspective it sucks. I'm talking specifically about the UX. I've always hated Github's PR page, so I typically reviewed by pulling down the branch and opening the diff with $EDITOR.
When $EDITOR = VSCode there's a shortcut on the GitHub PR page: if you type a . it opens in github.dev in a VSCode instance.
thanks for pointing out the linear PR stuff, hadn’t seen that. Interesting that while a dozen other companies are trying to muscle in on the hosting/versioning side of github, rather fewer are working on the PR side.
> Claude can write the code for you but it can’t understand it for you
Part of the problem is that Claude can go spelunking in a spaghetti codebase far faster than us humans. It doesn't necessarily help you understand the project, but if you farm that understanding out to Claude, you can keep working long after the codebase has become unusable for humans...
Apparently, from what I usually see, they start a completely new project every couple of days. Some revibe their older projects from scratch, with "better" prompts (surely that was the problem).
My experience conflicts with this assertion. I've used Claude to achieve an understanding of two large codebases (that I mostly wrote, and certainly came up with most of the concepts therein) to the point that it's far superior to my understanding. I now get it to explain things to me that I have long forgotten.
> Either you need to understand how your codebase works or you don’t.
It's an interesting point.
We can also think about it perhaps as a non binary thing - you need X amount of understanding in a specific codebase to be effective. Even before LLMs in large codebases no one understood it all; but we at least mostly understood our own PRs and our own areas of expertise in the codebase.
I have a very good mental model in my head of each and every codebase I have ever worked on. Nothing to do with my PRs or even my team’s direct responsibilities. I could always direct a thought provoking idea to challenge the existing status quo and get a reasonable nuanced answer from code owners on slack or during a water-cooler talk. I build that mental model also by reading the code. This is my job, so I know when to tear down what or how to respond to a random product idea immediately on a meeting to asses complexity.
Before LLMs you either built good abstractions to make it possible to not understand large chunks of the code base or you flailed.
A lot of the time people flailed.
The one thing Ive never seen an LLM do well is shape clean, coherent abstractions. To be fair it's a rare human skill as well but in LLMs if they don't have a direct analog in their training data they flail.
Maybe I'm doing something wrong, but the code I get from LLMs would not be considered acceptable to merge before we collectively stopped having standards. People are committing 900 line functions with sprinkled return statements and it's getting into production. If there are productivity gains to be had I haven't seen them yet
It is comforting to find other people experiencing the exact same reality as me, since I see so much in this post that matches my own experience.
It reminds me of all the recent talk about "taste". Architecture "quality" may not be objective in a right/wrong sense, in the same way that fashion isn't right/wrong. It's like we are all going to have to relinquish reason/rationality to the machine and start to study up on aesthetics.
Even historically, my big struggles have usually been deciding between two nearly-equivalent options. I get this a lot now with LLMs because there is no break in-between these decisions that implementation used to force. I feel I'm constantly making "taste" calls between tradeoffs that have no clear objective criteria, and it is as exhausting as the code review this post (and my experience) suggests are still necessary, even with Fable/GPT-5.6 level models.
In many cases, I do what I've done with junior engineers whose code I reviewed pre-agent: make on-the-spot judgement calls. When I see a broken window, I call it out. But when I see minor issues, I sometimes just let it pass, note it in memory and tackle it wholesale once an accumulation of similar minor issues get to a certain size.
As a tangential aside, I consider two dev shops from pre-agent days. One decides to hire 7 extremely talented engineers and gets them to work closely together. The other decides to outsource to 100 decent engineers and tries to silo them into modules. I think we are facing a similar choice with agents. You can either work extremely closely with a handful of agents, collaborating on design, review, etc. Or you can spin up a fleet of sub-agents and YOLO, then try to separate the wheat from the chaff in some automated way. My taste is the former, small highly coordinated shop. But time will tell if I am right or wrong.
That is a good point and I don't mind getting a bit philosophical when I point out that experience is distinct from rationalism. Underneath this there is an argument about empiricism vs. rationalism (or realism vs. idealism).
The hand-wringing on the 50-50 cases is almost always theoretical, in the sense that I am trying to reason instead of rely on memory/experience. But that is a double edge sword because sometimes memory/experience are closer to trauma and can lead one away from a solution that is correct now in some new environment.
It also reminds me of the phrase "use in anger". You don't really know about an approach/architecture until you've had to deal with something in an urgent or high-stakes moment (your 2am debugging). But to get that experience, you have to have shipped the thing first. It is a chicken-and-egg problem, you can't debug something at 2am unless it is live, and you can't know if it will cause you a problem until you've dealt with it.
AI (LLMs, agents, etc) is this giant alteration to the environment that shakes up everything. In some sense, I feel I have to throw out my taste and "use in anger" all over again. It is painful but may be the only way. And I have to accept the risk that going slowly (like this post suggests) may be the wrong way, and I may watch the young untraumatized new-comers blast by me riding their 100 agent orchestrations to massive success. What I mean here is, in the final scenario from my original comment (7 top guys vs 100 decent guys) - I know the result from experience. But am I just traumatized and it will be different with agents?
Its still so early in the game for de facto standards - engineering teams need to experiment and see what works for their own quality metrics not just parrot “standards and methodologies”
This is still the very early days of AI and AI engineering
interesting - i'd say my main goal is to put the current "agentic software factory" hype in the historical context of "we've actually been rube-goldberging software deploys for a while now"
I think there is a fundamental issue here of what building software even means
If you think you can just assign Github tickets to AI agents and go drink daiquiris on the beach I think you'll find that you end up with more and more towers of abstraction and indirection. There are 'points of view' that emerge during coding I think. And at some point you as a human have to be like "wait... what if we use Redis here". "Wait.. the API is already returning the data we need". "Wait... let's not add customers to the report who have not been active in the past year". Stuff like that
> There are 'points of view' that emerge during coding
I know it’s a bit cliche at this point, but this harkens to “programming as theory building”[0] which I agree is easy to lose out on when embracing agentic coding today.
I have had the phrase "programming is building a theory" spinning in my head for days, especially since watching this pragmatic engineer pod with Kent Beck https://www.youtube.com/watch?v=ddHQQtjIOpw
The machine gives you what you ask for even when that thing doesn’t exist yet.
Rather than “lights off,” utilizing information theory, decision-making theory and creativity theory makes me better at asking for the right things.
Memory is not transcribed to weights like when humans sleep. Memory is notes handed to someone on groundhog’s day who can’t remember yesterday. We hope they believe us. Don’t be too surprised when a highly entropic system introduces entropy to a project over time.
> "Wait.. the API is already returning the data we need"
To me that's a huge one. I witnessed this firsthand more than once and the fact that you make that comment too just shows there's a problem: I've seen top frontier models go wild, adding shitload of code to spout something that, eventually (after burning shitload of tokens), worked.
While it was basically a one-line change because the data was already there on the client-side.
The thing thought it noticed a pattern and went ballistic, mimicking some existing client-server communication, to "solve" my problem.
The worst is: all vibe-coded projects are full of such nonsense and the "prompt engineers" (such engineers, much wow btw!) who wrote their magical incantations have zero clue about it.
I use these tools daily, I love the time they save me. But sheesh...
yeah I 100% agree - and I think the most popular coding agent workflows / skill kits are designed to pull those insights and intuition out of humans in a way that optimizes for the developer's experience building the plans or building the code, e.g.
- claude code plan mode
- mattpocock/skills
- obra/superpowers
- research/plan/implement
I've been building and running my software factory for 8 months now. Granted, there's no automated pulling down tasks and pushing PR right now (soon!). But after specifying what I want, it mostly goes to shipping on its own. On occasion, it does raise issues that I have to make a decision on. After doing systems evals on review, I've stopped looking at code during review for 4 months now.
I do spend a lot of time up front specifying what I want. My prompts aren't one-liners, but rather an interview process where we work through all the open questions and ambiguity.
I haven't hit the wall that the OP talked about (when agents just can't seem to make the right changes, and it's impossible for me to go in and change things manually). I used a lot of guardrails such as plan reviews, browser-based QA, adversarial reviews, unit tests, linters, typecheckers, post-commit hooks, and formal method traces. I also specified engineering principles that steers the code base to minimize state and side-effects: functional core; imperative shell, make impossible states impossible, use pure functional style, etc.
There are times, when I can feel a part of the code base is messy without looking at it, because the agent will make recurring mistakes in the same part of the code base over time. What I found the agent was doing over time is that it's been layering state variables as requirements were discovered. So what helps is to ask it to refactor all these state variables into a single sum type. And if the state machine for it is complicated, I'll ask it to write a formal model of the state in Quint. Then I'll generate traces that get run as unit tests, and ask it to write the code against that.
So while the code base isn't exactly Brownfield, it's over a year old now. As for the code base, there's a backend and a frontend. I think it helps that I established a clear pattern I wanted. You code are like memes: agents will just copy patterns they see in the code base. When it does have to create a new part of the system, I found Sonnet-level models tend to draw system boundaries in all the wrong places. Opus is better. I don't yet know about Fable.
This has been my experience as well. While not a full "factory", I've got several mature vibed software projects.
More often than not you can "feel" when the quality has degraded. Many of these pieces leave you hanging on the assumption that once it's slopped up that's the game, it's over, you're cooked, straight to jail.
But I've yet to reach that position and be unable to pop the hood, identify the issue, and agentic-ly clean it up.
The post explicitly says it's not a skill issue, but I've yet to see any situation where an average engineer can't unslop their codebase.
I’m most curious about what you’ve built with the code factory. Is it just building itself or do you have any outputs that validate it for building something other than AI coding tools?
On one hand, our core product is just simply not fit for them at its scale. We've tried but the project is large enough to require human input for every change. But we have AI automations for light code refactoring, writing tests, UI changes etc. and they work.
On the other hand, I started a number of small experiments to see how far software factories can be pushed and while the code produced so far is nothing spectacular I could easily imagine how this can be extended in the near future. Perhaps if you start from the ground up with the idea that the code will be written that way then you can come up with strategies and architectures that accommodate it. At least this is my thinking right now.
Anyway, it is all open source and documented here https://relentless.works/ I am not sure for long I will keep this running. I provide zero direction to where this is going. I have no idea what it will happen next. It is a fun experiment.
I have another such experiment with a trading agent. I thought it will loose all of the money in short time. For a while it was stuck with no open positions after it lost a bit. I decided not to intervene and just observe the behaviour. Recently it opened new positions which was an interesting development. It is still loosing money (~ -3%) but it has not lost all of them and given the current market circumstances I would say this ain't bad at all. It just shows that perhaps we might be a bit impatient when it comes to AI.
So I think it is probably possible to build software factories but we need new concepts and a bit of change of mindset.
I find it amusing that people who are talking about Dark Software Factories, are talking about productivity in terms of number of pull requests or commits as a unit.
If we are going in the Dark Software Factory route, why aren't we calling the code units as bos (bunch of shit) yet.
No one serious about the idea can afford either vanity metrics nor ignorance of the code. The bar is higher, not lower, to operate with this much automation in the water supply. It's mostly a lot more math and a lot more work.
It's an extreme form of any startup: you trade off capital for years of your life.
This is interesting and all, but why should we believe any of it?
1) This guy has a track record (confessed) of making shit up, yapping on about it, and pushing it on the innocent. He's done a bunch of damage with his bullshit and now wants us to pay attention again. I mean - something something off fella.
2) There is NO EVIDENCE AT ALL that his ideas are good. He's just making stuff up.
Give me a reason. Also shouldn't he be ostracised and stripped of his wealth for his previous rubbish?
It's funny how, when the hype is strong enough, the burden of proof around the need for EVIDENCE suddenly shifts.
Normally, the burden of proof is on $NEWFANGLED_THING to prove it's better than $TRIED_AND_TESTED.
Software dark factories where no one looks at code are that unproven newfangled thing and all he's really saying is that, in his experience/assessment, those don't work, so he's trying to find other modes of human-ai-collaboration that might actually work that capitalize better on the things (humans) that weren't broke and didn't need fixing when gen-ai coding came along; and then getting the word out about that.
Under normal circumstances there would be absolutely no ground for any controversy around such a stance. Instead, he's having to contend with reactions like: "But $HYPED_UP_THING, and how great that is is all that anyone is talking about! Don't listen to him, he's just trying to sell you something (other than what everyone else is trying to sell). ...naysayer probably thinks he's smarter than everyone."
It's just he's qualified himself as an unreliable witness. This is not someone who deeply understands and thinks about what he does or what he advises.
The things that I know about, that he writes about, where I know he's got it a bit wrong.... I find myself questioning if he's right or not. Because he's a persuasive writer. But winning arguments doesn't make you right. This isn't a supported, balanced discussion it's a self aggrandising mismash of commonplace ideas and issues.
He's learned how to grab the mic, he believes he has the right to the mic, people are listening to him.. all three of these are wrong and until we call this out and put a stop to people like this shooting their mouths off damage is going to carry on being done.
I've recently started experimenting with grounding LLM driven implementation/verification on RFC based normative specifications, to avoid having to manually steer the LLM during implementation and dealing with reviewing sloppy pull requests.
It works quite well, as it puts your entire focus on writing (hopefully) unambiguous specifications vs. having to discuss unwanted changes with an LLM during code-review. One flaw is that this only works great if you know exactly what you want, which is not always the case.
But do you actually gain anything if you need to write detailed specifications? That seems just as time consuming as writing code, but less gratifying.
Code is just detailed specifications on how things should operate.
> Code is just detailed specifications on how things should operate.
The spec defines how things should operate. Code defines how things operate.
The problem being that if there is only code, then any change to system behaviour is always correct (including bugs). Because that's what the code says.
Relying on tests won't help without a spec to create tests from. So tests are generated from code. So if a test fails, it's the fault of the test, not the code.
Yes, actually that's what I'd had argued a few years ago as well.
It turns out that there are now a few more people that want to get their hands on building software, that don't necessarily understand code, but do have a fundamental idea of system design / requirements.
As you said code has always been a much more explicit representation of those specs, yet arguably introduces lots of noise, necessary to make the program compilable.
Us devs already had the obligation of writing technical documentation for non-technical people, just not at an explicit depth. From an efficiency PoV making that documentation more explicit is much cheaper than manually writing the compilable code. Hurts to say but AI got pretty good with the latter.
I'm curious how that works - are you actually hand writing specs with RFC level detail yourself completely or is it more of an LLM assisted effort? It seems like writing a comprehensive spec manually would almost be as much (if not more) work than the implementation.
The LLM solely helps with research and retaining the normative document layout (RFC 7322).
Since the spec grounds the underlying implementation I have to fully understand it, writing the spec manually prevents infecting the spec with the typical LLM specification slop.
When writing the specs, the goal is to systematically keep the right balance between scope and depth:
- Scope takes the most effort because it's the only thing preventing the model from escaping an intended boundary, that includes things like stable constraints/interfaces/data models
- Depth is something where I can tolerate "non-normative" interpretations by the LLM. Unless I need a stable implementation, I can decide how much I manually invest into depth vs. letting the model figure the "good enough" solution.
Since the scope/boundaries are explicitly set, the internals are pretty encapsulated and the model comparing an implementation with the spec can identify the "non-normative" pieces and communicate those to me. Then I can decide between "good enough" or to refine these non-normative implementations and make them normative.
From my various experiments the spec vs. code ratio is roughly 1/8.
normative specifications can help, but the thesis here is that specs that define behavior of the product or even architecture are helpful but there's MORE that can be done and even though "program design" feels too in the weeds it's still essential if you care about maintainability
Isn't maintainability mostly about applying basic engineering principles e.g. separation of concerns, single responsibility, dependency inversion, open-closed etc..? If these topics are addressed in the normative representation, and correctly translated by an LLM into code (especially by slicing up the specifications into measurable outcomes to set the intended foundation), then future change e.g. maintainability becomes essentially easy as well, no?
Historically I know that the majority maintenance problems occur from slow continuous evolution of a system that it initially was never designed for. And the only way to address this was continuous system design.
> Historically I know that the majority maintenance problems occur from slow continuous evolution of a system that it initially was never designed for. And the only way to address this was continuous system design.
yes exactly - this is what I'm advocating for - that you can't skip the system design, and that actually good system design goes down to the typedefs and object graph at the code level, not just mermaid charts and db schemas and service contracts.
I will highlight what a few others have said along the lines of "a sufficiently detailed spec IS code" - that is, to make the spec guaranteed to produce the code you want, the spec will look a lot like code (and will be roughly the same effort to review as the code itself anyway, saving you no time)
what I'm proposing is "how can you maximized the odds that the code WILL be good or close enough to good that its easy to get there, with the LEAST amount of human effort/attention" - how can you move fast without skipping what matters
Hey, I’ve watched some of your talks on YouTube and they have generally felt right and influenced my thinking as to how to navigate software engineering in this era. I appreciate you engaging here!
I read your piece here and again I appreciate and agree with your main points. You have a section here titled “30 minutes of planning saves hours of review” — but I find it hard to believe that you are doing all this pre-work of creating specs (ai-assisted) at various levels, down to the level of function signatures and such, and this whole thing only takes you 30 minutes. Is that what you meant? Can you talk a bit about how long this process actually takes, or if it is really only 30 minutes, how you pull that off?
My radical opinion is that LLMs are harmful for software development - they are the ultimate "goto" operator. All actual code should be written by a human developer.
Instead, use them in adversarial mode - run QA scenarios using LLM agent as a substitute for end user to do bug discovery.
> All actual code should be written by a human developer.
This seems arbitrary. Why don’t you say the same thing about machine code? Developers use tools so they can avoid writing machine code. What is causing you to draw a line in the sand about use of tools?
The obvious answer is it’s just a function of the time period you grew up in, and a lack of willingness to adapt to change.
This is indeed an important angle to consider as well.
I think there is some nuance though, but it's hard to articulate. I think that is because there are some long term effects that are currently invisible, but that can be anticipated. A lot of it is the human factor, and how changes to how people think and act may ripple through the organizations as well.
Things such as skill atrophy which may reduce not only immediate skills, but also adjacent skills that were maybe important for critical thinking and making good decisions. Or the fact that learning to use an LLM is a skill that is not truly grounded in reality and can therefore not translate well to other areas (you're essentially learning skills within the "reality" of the LLM, based on its weights). That is very different from machine code --> tools, where the tools make explicit assumptions that are based on the workings of the machine code (which is analytical in nature), and where you can, if you wish to, jump in to override those assumptions where needed without having to adapt to a mental model that operates in its own reality (i.e. the LLM's "thought process").
This is one of the best writeups I've seen of this
a lot of the model's constraints come down to how they are RLed. Discussions online would be a lot better if everyone understood how the labs train the models in a high level (or did a lil data labeling)
yeah i like this and others in the thread mentioned that understanding RL and RLHF and the shape of the data is really important (at least the fundamentals, I'm sure there's quite complex industrialization of RL inside labs as Nathan Lambert says)
Personal anecdote: I was able to set things up in such a way that multiple non technical people at my job were able to build features into our project. One person even created our own CRM. And I'm not a turbo-genius savant.
The one downside was that it required their computers to install dev dependencies, postgres, infisical for secret management, etc.
That's the next frontier. What I'm working on now independently. I plan to open source this solution, but again I'm not a savant genius. I guarantee many people are working on the same thing it's converging. Our job as engineers is becoming more of a higher level facilitator and AI "plumbing" maintenance work. How can we get the AI to empower everybody at the company while keeping the wheels turning. That's my aim.
Imagine a "MaintainabilityBench" that rewards models which detect code duplication while working on a task and perform some refactor instead of glibly duplicating; or that detect the need for a new architectural layer, or that hoist a type constraint so there's no need for dumb casts. You can keep on imagining scenarios.
There are probably a few hundred distinct elements to RL for. The books "Working With Legacy Code" and "Architecture of Open Source Applications" would be great fodder.
Sadly don't have time to build it, there's this mountain of reviews in front of me...
sometimes you forsee the code developing vastly differently between the two copies so you don't want the refactor. it really all comes down to lack of online learning and contextual awareness; memento mori notes are about as effective as developers with no expertise reading the design patterns book (well, ok, they are effective, but not sufficiently and not always directionally correct as its hard to accurately encode the nuance with language)
> When I say maintainability, I mean the specific thing where it becomes really, really hard to change one part of the codebase without breaking another part.
The corollary of agents being bad at maintainability but good at coding is that you can vibecode all the parts where maintainability doesn't matter.
So if you build a (domain-specific) modular architecture for your software first you can then just let your software factories loose on building the modules.
yeah this is along the lines of what some friends of mine call "core vs. pragmatic modules" or even s/modules/codebase zones/
the idea that if you have a solid core and decoupled modules, you can have "zones" in your codebase where you allow the model to run wild and do a little slop, because you know the blast radius is contained
Except that there is typically a feedback loop between the implementation and the module interfaces. While implementing, you discover aspect that makes you adjust, and sometimes completely alter, the interfaces and module boundaries. And that’s not just for an initial implementation, it continues to happen as new requirements come in over the lifetime of the software. Ostensible implementation details continue to inform the architecture.
It's a skill issue... governance and culture skills. Doesn't matter at this point what model you use... a thoughtful harness with appropriate levels of HITL and strong security, governance, discipline. "We" have a very successful dark factory running... no I cant tell you about it. It's trade secrets at this point. It was incredibly hard to build, roll out, and maintain.
People have no idea that 2 years ago we hit peak performance with omni models. We won competitions with GPT-4o-mini, mini... it does not matter. Context matters. Discipline matters. Observability matters. Most of all, PEOPLE matter.
All of the fools who tried this and laid people off. Fools. It's about empowering your team, making their lives easier, less frustrating, and higher impact.
> I haven't been able to dig up any definitive data/findings from StrongDM on how that whole dark factory went. The weather-report has a few sparse updates between February and June of this year.
This was easy to find out I thought. And just with an old-fashioned google search too, no deep research agent needed. See here: https://diffusion.io/
Seems like it went pretty well if a consulting company is now being started.
I agree with a lot of what Dex Horthy is saying here but on some fronts I feel like he's missing something. Coding well with LLMs, it's not a skill issue, it's an effort/laziness/rigor issue.
In order for coding with LLMs to go well, there has to be more rigor, more discipline, more good engineering hard-assedness. To reiterate, the teams seeing the best results with AI were already high-discipline and high-hygiene.
AI works on data. The better the data, the better the likelihood of a desirable outcome. Code is data. If you have bad code, no matter how awesome the model you let loose on it, you can't get as good a result as if you had good code to start with. This principle has been well known in AI/ML circles since the 20th century.
e.g., if you are doing spec driven development and not seriously investigating formal verification, IMHO you will come up short. Prompts are simply not enough to steer a coding agent to the level of precision needed. Without deep programmatic verification - at all levels, formal verification is just one slice - the solutions the agent produces will always be just slightly (or very) out of true.
“Seems like it went pretty well if a consulting company is now being started.”
You interpreted this backwards. Software companies offer consulting when their product cannot stand on its own. See Palantir, Salesforce, etc.
They are successful companies, yes, but not successful products. The product needs to be instantiated and maintained by sales engineers and consultants and customized into something so bespoke that it’s hardly the company’s product anymore.
> Prompts are simply not enough to steer a coding agent to the level of precision needed. Without deep programmatic verification - at all levels, formal verification is just one slice - the solutions the agent produces will always be just slightly (or very) out of true.
I found this to be exactly right, and in my work I’ve come up with a taxonomy of constraint mechanisms which I keep in mind when guiding agents: generative to constrain the output of the model, interpretive to constrain how the model ‘understands’ code, and elicitative to help it ask the right questions of users.
Just a minor thing I want to clarify about the Weather Report [1] - it's framed in kind of a negative light in the article ("sparse updates"), but we've been updating it as frequently as we find a meaningful improvement in a relevant dimension. Since we launched it in February it has averaged about one update per month, as frontier labs keep racing forward!
appreciate that context! I definitely did not mean to come out and say "its definitely not working" or anything, but would love to hear from y'all a retrospective on the ~5-6 month anniversary - what was right, what did we get wrong, etc
We are working on new articles to share our latest findings, so stay tuned! Overall our outlook continues to be bullish. Almost all software problems yield to a combination of the Factory Techniques covered on the strongdm.ai website. More powerful models work even better...
Some more context on the consulting company: StrongDM was sold earlier this year, about a year after the dark factory was first announced, and the former CTO moved on to this (presumably) in order to continue the idea.
> In order for coding with LLMs to go well, there has to be more rigor, more discipline, more good engineering hard-assedness. To reiterate, the teams seeing the best results with AI were already high-discipline and high-hygiene.
hard agree. But i don't think this is sufficient. Even formal verification has its limitations.
> AI works on data. The better the data, the better the likelihood of a desirable outcome. Code is data. If you have bad code, no matter how awesome the model you let loose on it, you can't get as good a result as if you had good code to start with. This principle has been well known in AI/ML circles since the 20th century.
hard agree. but also RL data is shaped differently than SFT data that has driven the majority of AI/ML innovations since ~2000, and its where there's so much room for innovation still. e.g. ImageNet was all just hand-labeled answer pairs.
> it's not a skill issue, it's an effort/laziness/rigor issue
I'm sorry but this feels like a semantic argument - the point of "skill issue" is "you didn't put in the effort or learn the techniques"
In autonomous navigation there's a concept taken from sailing called "dead reckoning", where you just use an internal model of the robots dynamics to make controller commands. It works for short distances, but without feedback from sensors, the path the robot takes quickly diverges from the intended one as errors accumulate quadratically over the distance travelled. If the robot travels far enough without any external feedback, the localizer can "diverge", meaning its belief about where the robot is becomes wildly off from where the robot actually exists, making safe control virtually impossible.
Now, if you've got a really good model you can get much further with dead reckoning compared to a worse model. But a model is not reality so no matter how good it is, so without feedback eventually you still run into this problem no matter what.
I imagine that's a lot like what goes on in these agentic loops.
> So, why can't models do software maintainability?
I feel like the explanation does nothing to actually elucidate why models can't do it. Is it an inherent weakness of LLMs? Training processes? The typical "this is crap" that we constantly hear? It goes on to write about RL and how there's no penalty for bad design. But that sort of side-steps the question and makes you ask: "why not do RL and make a penalty for bad design?" Of course the models aren't good at it ... they're not good at anything until you've tuned them and put them in a harness that rewards good edits and throws away (improves) bad edits. That doesn't explain why "models can't do software maintainability." The real question is why harnesses can't do software maintainability, and how to build a system that can do it. (I suppose that's the purpose of the ad at the bottom of the page.)
I think the simple answer is LLM cannot do long term planning.
Maintainability means thinking what will happen to this code in the next year and possibly hundreds of changes and based on that selecting the right abstractions that will work in the long term.
LLMs currently cannot do long term planning and specifically cannot pick abstractions that will work in the long term.
I think that's the important problem to solve. Teaching LLMs how to pick the right abstractions.
Why can they not do long term planning? They know what good software design looks like and can code accordingly. Using Fable for a greenfield project for example, it doesn't dump everything into one file but instead does indeed split out the work into logical units as needed.
Why is a very good question indeed! My guess is we have not figured out how to include long term enough tasks into the RL training.
As to whether they can today, it's pretty easy to figure out that they can't by observing the difference between asking for very high level things like "please make me a website that will be very successful" vs sending it a detailed plans on the goals and many of the specifics and then holding it accountable towards the planning.
Doing appropriate project structure and trying to optimize code quality are definitely good methods to try and increase the chance that the project will succeed long term but I would say they are only methods towards the long term goal and the LLM need to be thinking of the long term goal and how to plan towards that to achieve a much wider and subtile range of methods to achieve long term goals.
/goal and /workflow exists. As I said in another comment, models can do it, as in they have the capacity to do so. It's just the harness that needs to be wired up correctly.
I have a hunch it comes down to the training data. We have spent decades as an industry talking up the new shiny thing, deliverables, frameworks, features, performance improvements, the one thing you don't read copious amounts of prose about is "how I maintained our system so that nobody noticed".
I think it’s because maintainability is a factor of software design, and good design is squishy and hard to articulate. There’s no good metrics for design. All the tools that purport to measure it are doing trivial things like cyclomatic complexity, and can only tell you when things have gotten really really bad, but not distinguish between “good” and “pretty bad.”
Design skills take about 10 years to develop, in my experience, and a lot of smart engineers go through a phase where they make gawdawful messes in the name of “magically easy” designs around the 5 year mark.
Design requires wisdom born of experience, isn’t measurable, and requires forming a mental model of how the system hangs together as a whole. It’s just not stuff LLMs are good at.
But then you're back at the question from the OP of "why not?" Is it lack of good examples in the training data? Is there something of code "goodness" that goes beyond phenomenon that are measurable? Is it that LLMs lack in the ability to organize and think abstractly?
> why not do RL and make a penalty for bad design?
But this is clearly explained in the article. We can tell whether the design was good or bad only weeks or even months later, which is too long to wait for artificial trajectories. Tests, by contrast, provide validation in seconds or minutes.
fair point, this is the thing I struggled most to extract out while writing it - if you can propose an RL environment that penalizes a model for bad design, then I'm all ears - right now there's no fast oracle/verifier for this (as stated in the post)
My current evolving take on "how would you build such a thing" is you need to tee up a roadmap of 20 features and feed them to a model one at a time, so it can't design up front for what's coming.
That way if it builds the first 10 features and the codebase goes to slop, it get's penalized when it can't build features 11-20, or when those features take wayyy more tokens/time/cycles than a model that maintains a clean codebase can do.
This is how most real software is built by most teams - incrementally, getting feedback from users along the way, and steering goals in response.
Isn't that how AI written software gets better too? By steering the model towards the goals of the user?
I don't know if it's a question of how many features to feed to the model, either. Of course, overwhelm the context with too many features and it will get confused. But that's where the memory management idea that G. Huntley talks about is helpful. You're trying to steer the model within its memory limits towards a certain goal.
The problem is getting it to produce "good" code. Formalizing what that means is the task of the programmer. How do you steer a model towards always, or more often, producing good code so that you don't have to do rework? That's the same problem as with a junior engineer, but the way you do it is different. Right now we're trying to do it with mountains of prompts — which sort of works but has diminishing returns — and with onerous code reviews. We've seen this get better over time, but I think some more mechanical methods will help as we figure out how best to steer the models.
I’ve experimented a bit with this approach for quasi-benchmarking models. Most models nowadays will keep trying until you cut them off, they’re happy to go into millions of tokens for an easy task, digging deeper and deeper into crap design. Compared to a clean reference implementation you get easily 20x token difference at task 11+ for the same model. Somewhat ironically I never published the results because the both the harness and the task set were vibe coded and I didn’t have the energy to clean it all up.
> Claude Code won because of Reinforcement Learning inside the harness
Doesn’t this gloss over the fact that token subsidization is a thing? I assume the reason a lot of people switched from other harnesses to CC was all the weirdness around setup-token and whether third party harnesses would continue to work without api pricing.
that's probably part of it but every enterprise in the world (even teams as small as 10-20 engineers) are paying per token, not with subscriptions. Claude code did make it into those orgs because people played with it at home with subscriptions first, but the bulk of that revenue is almost certainly coming from people paying per token, not the ones getting the ~90% subsidy on subscriptions
I 100% whole heartily agree with this. Anyone saying the models made a huge leap in fall 2025 / spring 2026 still aren't looking at whats going on. Just this weekend I thought I had a solid plan and evals/tests to let 5.6 sol work unsupervised over night while I slept and it made an absolute mess. Somewhere in the loop it had to make a decision and it made a wrong one. Making everything beyond that trash. The code 'worked' but it had the wrong system design and wrote the most brittle tests around its assumption, validating its own decision. It turned into a nasty feedback loop for the model. This is 5.6 sol high.
The models write good/great code. I'm very happy to never write code again but models are no where near good enough to run off on their own without a human in the loop. Models LOVE to cheat. Just peek at the tests they write.
And before you come at me, I have built 7 products in the past 1.5/2 years with agentic engineering, all with users. One of those projects is _dead_ because I let the vibe go too hard at the same time Anthropic decided to nerf both their harness and their models silently. If you care to look at the source: https://github.com/Robdel12/OrbitDock I spent a week or so and like a billion+ tokens trying to refactor and save it. It just wasn't worth it.
I wish people would be pragmatic about this. I get the dream is to let it do everything and not to be in the loop, because being in the loop is exhausting. But if you want to make whatever you're building be robust and survive more than 6 months, you have to. I don't care how good your tests, plans, skills, etc are. At some point the model will have to decide something and it'll be the wrong one. Compounding the slop from there forward.
> I spent a week or so and like a billion+ tokens trying to refactor and save it. It just wasn't worth it.
this is exactly what happened to github.com/humanlayer/humanlayer - it was overslopped and we reset from scratch to build it right - spent 2 weeks in VS CODE - not even cursor, plumbing the core patterns from scratch. codebase is part of the prompt, yada yada
If you built a real factory, you’d basically never want it to be dark. You’d want a culture of getting wrenches out to inspect the cars being built. You’d want to care about small details. Not because we need to build cars by hand. But because looking at the real product (cars, code, etc) is the best way to make the factory better. It’s the best way to know what problems aren’t being measured, what processes need to improve, and how automation can produce a better end product.
> Xiaomi has an 860,000 square foot factory in Changping, Beijing capable of manufacturing 10 million smartphones a year across 11 fully automated production lines.
> ASE Group, a Taiwanese company that handles outsourced semiconductor packaging and testing have 56 lights out factories.
It has always been the goal to make factories go dark.
i mean youre most likely not wrong (i dont have insider knowledge of those places), however your previous comment said "never want it to be dark" - when the reality is that its normal operation _is_ dark. only when the automated QA detects issues or theyre doing random inspections are the lights turned up/on
I'm currently learning about Cost functions and Regression in the Machine learning course on coursera[1], and I cannot help but be struck by the similarities of how gradient descent seeks to minimize the error between the model and the training data, how agents do the same (far less mathematically) to seek an acceptable solution to software problems, and how light evolutionary pressures seem to guide species towards a better fit solution to the problem of existence and reproduction. (I'm no expert on the evolutionary example so go easy on me!)
Good read and matches my experience pretty well, but I'd humbly suggest the author look up the definition of 'vertical' and 'horizontal' and swap their terminology + fix their videos :)
i humbly disagree - horizontal means touching one plane of the stack across, vertical means cutting down through it and touching multiple layers https://en.wikipedia.org/wiki/Vertical_slice
This is a great write up. I buy the argument against the dark factory approach, but I would be curious to hear if their process has changed at all with Fable/GPT-5.6. I believe the keynote this is based on (www.youtube.com/watch?v=Ib5GBkD555M) was given while Fable was still banned and GPT-5.6 had not yet been released. Has HumanLayer found they still need to follow as deliberate of a pre-work planning process as before? Or do they find that Fable/GPT-5.6 are able to do more with slightly less handholding?
i did a write up on fable while it was out - it can do big refactors, but it does not know what to change without human steering. For that, you need humans to know what to ask for.
Enjoyed most of this but unconvinced by the program design part. If I see an agent writing function signatures or listing which functions to edit in a plan that tells me that I’ve given it too big a vertical slice. I always delete the code guesses. The thing that writes the code must always spend some time discovering where/what to write or it won’t have the right context. Or put another way: “decide first, act later” always feels worse than act-learn-act.
one thing I probably didn't mention is we do the program design having already done an in-depth codebase research, with current patterns and architecture surfaced - that actually seeds every step of the flow including even the product part -
but yes if you're working in very small slices then I think it's very feasible to skip program design and just review the code as you go, and resteer live. I do this all the time for tasks that are too big for a oneshot but on the smaller side overall.
Do you think that the program design adds a lot on top of pointing out the current patterns?
I might be anchored by working with humans, but if I saw a plan for humans that included function signatures and what calls what I would say that is way too detailed. As a result I don't put it in my plans for AI either.
>It's easy to be a little bummed by the core thesis here: "for now we're stuck reading the code".
>I was pretty excited for a world where we could just ask for things and let the models cook and not read the code and get beautiful production software
I feel so disconnected reading those things. Reading and writing code is what brings me joy. I'd never feel "bummed" or "stuck" with it.
Necessarily, better data is what we need, more importantly, better collaboration and better specialization at all. While the title is a bit misleading and clickbait-y, the message is decent.
I disagree with the way that big models are trained on noisy relationships and RL is applied to tone it back down, it represents a stupid amount of compute thrown at this problem at a scale that is often unnecessary.
> We haven't even hit AI yet, and there are already several loops in this picture.
What a surprise! And here I was thinking that loops had only just been invented, to use in agent harnesses, as described in the famous paper “Loops Are All You Need.”
Like the "building blocks" mentality vs. "factory from scratch" mentality. Because... that's just how the real world works and if we are modeling intelligence off ourselves then why wouldn't that be the right approach?
I’ve been postulating that knowledge of old school principles like Method One along with test driven development and domain-driven design are the external factors allowing a subset of teams to succeed.
Absent those skills, the agile movement is flailing with GenAI.
Interesting framing. As coding agents move from demos to production, the bottleneck usually isn't the model but the harness around it: observability, rollback, and intent validation.
You don't have to build the entire software factory at once. You don't have to mastermind the whole future system, instead you're actually stacking and layering these small, isolated problems.
I think that's a really good approach to start getting value tomorrow or this week without saying, "I'm going to revolutionize how we ship."
It's just:
1. Find places where you can use agents.
2. Figure out where the right leverage points are for humans and where the right leverage points are for agents.
3. Just start building those things and plugging them into each other.
One day you'll wake up, and 80% of all of your stuff is automated.
Totally. Also to add to that. I think (like any factory) you need to build in systems to allow you to have observe and service the machines make process changes as needed.
You're the foreman/factory manager. You can optimize the factory over time upgrade machines, place machines closer or add conveyor belts for more productivity.
The only think that slightly worries me is that the Labs are clearly incorporating the best in class logic from their datasets.
To me, this comes down to verifiability. How do we measure the quality of what an agent is doing on our codebase rather than simply measuring task accomplishment?
> Verifying quality is orders of magnitude harder than "did the tests pass"
Agree that agentic grading is the future here. Cognition's Frontier Code is probably the best large public benchmark at this. You attribute agent quality issues to RLVR's binary pass/fail, however I wouldn't be surprised if labs are already supplementing that with rubrics as rewards to train more 'tasteful' models like Fable.
What can a practitioner do? I think there's promise in turning the optimization machine to the harness itself - building out a representative dataset of tasks on your repo, grading agent quality on them across various configurations, and optimizing [AGENTS.md / SKILLS.md / workflow / model / harness / tools] on that signal. High quality grading is still very hard, but it's more tractable at smaller, repo-level scale, and you can afford slower, more expensive verification for each task. You only need it to be right about your codebase's standards.
> In fact, it's not hard to imagine that if a model could reliably tell good code from bad, it might have written the good version to begin with
Pushing back slightly - detecting slop and discriminating quality is easier than generating it (why code review is so effective), and why grading is viable at repo eval scale even if it's much harder at RL scale.
Everyone is flying blind. For example, I am genuinely interested in trying HumanLayer, but would likely want some harder evidence (beyond anecdotes) that it's actually making my agents more effective before rolling out to an enterprise team.
I'm building this harness optimization loop @ https://stet.sh if curious
This is a very well written article and he makes his arguments backed up by data.
We may choose to disagree but thats the point of healthy debate based on clearly expressed opinions.
Key point is I don't think this is AI slop which is way too common in long form articles these days and in keeping with the whole point of his article.
Honest question:
For let’s say a senior developer having to go through all of these steps for the model to implement a feature:
> Product Design
> System Architecture
> Program Design
> Vertical Slices
By the time it takes to go through these steps and agree with the agent, wouldn’t the senior dev not just be able to implement the feature by themselves?
I mean, in general; I know there’s always features with complex logic etc, so the question is just about the “general case”
Just in case this isn't a compliment, I'll note that I think Dex has been pretty good about admitting when they were wrong, explaining why they were wrong, and what they're doing now instead.
I call it the Intent-Implement-Quality problem.
Software factories can implement anything given a one-liner requirement. That one-liner requirement can be a complete app/product, epic, feature, bug, design change or refactoring. But these one liner requirements are requirements coming from a human who has an intent or requirement or direction for the product to evolve in mind. Can Software factories manufacture intent that reflects the exact requirements of the person using it or their vision of how the product or software should evolve?
Implementation in any language is as easy as generating a summary for an LLM. If coding is only math and there is only one way to translate a requirement into an implementation, the problem boils down to just providing or verifying generated intent. But, there is definitely more than one way to implement a thing and one of the ways leads to a design and architecture that is coherent with rest of the system, design and architecture that is extensible and evolves, code that you can keep in your head when you want to change things next time or tomorrow, software that can serve millions of users and securely guarantee millions of dollars of revenue. There is a combinatorial explosion of ways and the one right way is also subjective of the person and the problem. Software factories can of course improve Quality by generating more unit tests, more integration tests, fix code violations, generate Proof of work as videos, screenshots etc, but there is no feedback loop or test suite to verify and correct the other subjective notions of Quality.
It's even worse: Customer says I want X!
One or more of the following can be true:
Also quite common for me is like someone says X is good (usually a PM) but common sense says it's crap, and when you actually ask the user they also say it's crap. If only LLMs could email a bunch of people for second opinions.
Or fire the PM?
PM = politics maestro
They will out-corporate you. Better to be friends with them, or failing that, move from under them
Or fuck them, fuck the managers, fuck the c-suites (intentionally decapitalized), go for a flat organizational structure like Valve where you have no one to report to (well maybe Gabe Newell or the team leader for that project occasionally), but the culture is that everyone can manage themselves organically rather than having hierarchies and forced, useless reportings
Hierarchies are burned deep into our DNA little boy, u ever read Utopia?
Valve ships almost nothing, and the engineering quality is mediocre. Their game design is good, but subsidized by a unique early mover monopoly market owner position.
There is almost nothing that can be generalized, and people who hold up their organization as an example to strive for are utterly clueless
> early mover monopoly
Well, while I do agree it is an early mover (I believe Steam is not the first to do online game platform, but it should indeed be the first one to use a CDN for the solution), I'm sorry that you have Ubisoft Connect, EA Origin, Epic Games Store, itch.io, GOG, Humble Bundle.
So you do have a choice. That renders the statement of it being a monopoly impossible. It's simply because every other platforms sucks.
In other words, it's like Nvidia. You choose Nvidia because AMD and Intel sucks, not because you don't have a choice.
> engineering quality is mediocre
You should see how CS2's smoke system works: https://www.youtube.com/watch?v=ryB8hT5TMSg
tl;dw: it is a voxel ray marching plus flood fill with Mie scattering. I'd like to point this out that is not only a really good game design, but it also requires ingenious engineering quality. I tried to improve upon it by adding octrees (or in other word, making it sparse voxel octree) but it doesn't seems to add much.
Oh and plus their new bomb shock wave system. I tried to reverse engineer it with vector field, but I couldn't come up with the ODE equations to recreate it. I believe it has to be some kind of field, because in a high energy explosion, it scatter through air into fluid-like structure and hence we can use some aerodynamics for simluation
I’ve outlived many PMs and helped get at least one fired. If they were omnipotent they’d be better at product design.
ask Ed Zitron how well that statistically pans out
https://xyproblem.info/
Why deliver one solution? You're thinking small. If LLMs were fast enough, they could build A,B,C,...,Z in parallel. So that's what will end up happening. The operator will just have to make sure there's no combinatorial explosion of the possible requirements.
Right. Because If I want feature A and it is available in configuration among features A through Z I will always perfectly pick the right letter of the alphabet and I will not at all be irritated by having 26 options that I have no idea about what is the difference between them.
But I think there's anyway a point there. I watched a talk once and it was humorously said that the amount of time spent discussing whether solution A is better than B is more than implementing both A and B and seeing in practice. It's funny because it's true.
[dead]
If you’re working on an app or software that has few users, no revenue or minimal revenue, tolerance to bugs is higher and just another Claude prompt away, Software factories are a perfect fit. Most personal software or hobby software or 0-1 yet-to-find-PMF startups belong in this category.
You can even take a stand that you’ll never look at the code and just ship. This is a perfect equilibrium for a Software factory, where the only input or feedback is a one-liner/specced requirement and the only output is outcome of whether the one-liner requirement worked or not.
For almost any other software that does not fit this criteria, software factories are yet to solve the Intent and Subjective Quality problem.
> few users, no revenue or minimal revenue
The 900 pound gorilla has for a while been "where is all the output of these LLMs?", and this seems to be the answer; the number of apps on the various app stores has skyrocketed over the past two quarters but installs overall are actually down a little bit. So it seems like we've had an explosion of software that one or two people use. Which is a cool situation to think about but is pretty bearish for the "AI as a profitable business" idea.
Marketing was a problem with apps even before AI, which, with today’s slopforests makes it even harder for consumers to see any of your trees even if they wanted to.
Right but if we're going to a small-batch bespoke development model then "marketing" more or less disappears because why would I pay someone to talk to an LLM when I can also talk to an LLM? The money goes from the end user to the lab in this model.
I should expand that: the money goes from the end user to the lab and only in the cases where the marginal utility of the small app exceeds the cost.
What happens then, though? Is it good to have tens or hundreds of thousands of potentially angry marketing managers roaming around that were developed out of careers?
IDK, get Springsteen to record an aid concert for them?
I think you misconstrued my reply. I wasn't talking about that aspect.
100 points for the term Slopforest :-)
I haven’t checked in recently but a couple months ago there was an increase on the Apple App Store, but not on Android.
And when I did a spot check, most new apps were just wrappers around LLM APIs.
> If you’re working on an app or software that has few users, no revenue or minimal revenue, tolerance to bugs is higher and just another Claude prompt away, Software factories are a perfect fit. Most personal software or hobby software or 0-1 yet-to-find-PMF startups belong in this category.
I would rather claim that for my personal/hobby software, I apply a much higher quality standard than for the software that I write at work.
Believe me: I would love to apply the same high (or even higher) standard at work, too.
The problem rather is that it is a very common situation that bosses actively prohibit me from rocking the boat too much. If I make (I think typically good) suggestions, I often get very stern reactions.
At work, elegance is not celebrated - just implement the tasks of users who don't care about quality or elegance.
I’m always surprised when I read comments like this. I’ve come across far more situations where individual contributions take a slapdash approach and management is disengaged than management actively imposing poor quality work.
You either need to quit or keep your head down, I can’t tell which.
If you need to actively keep your head down, you need to quit.
Doesn’t matter whether ‘the problem’ is the employer, the employee, both, or neither. They’re a bad fit for each other.
I don't think so? It's very common in both large companies and small startups where pragmatism has a higher priority than so called elegance or whatever you call it the "artisan" feel. It's varying shades of "perfect is the enemy of good", where different cultures and business environments dictate how much a manager is going to tolerate your proposed refactoring. At least that's what I got from the parent lost.
> If you need to actively keep your head down, you need to quit.
This really depends on whether they are paying you decently. The number of people I've met who found a nice corner in FAANG, and decided to keep their head down and collect a steady paycheque... One may find one can swallow a lot of engineering pride for a recurring six figures
And that’s not to say anything about personal situations. Family obligations, immigration requirements, etc.
Especially in the current job market, “find a new job and quit” is going to cost you so much time and effort and for many people it will still be a lateral move in terms of company quality in regards to engineering practices. It’s hard to make these kinds of deep company discoveries until you’re in the thick of it but by then it’s too late.
Personally, I’m advocating for change where I can and not taking it personally when the manager says no. I put in enough effort not to get paged in the middle of the night which is generally plenty for management. It helps that I don’t work in a super strict business environment.
There’s more to life outside of work as well so if you can silo that bit of your life and enjoy things outside of working hours and you’re content, so be it.
Keep your head down, while you look for alternatives. No need to pre-emptively quit, if you can coast and collect a paycheck.
The perfect poster boy is system scripts. They’re not even published usually, but being able to just generate < 500 line scripts for everything is a huge boon.
I agree this rocks I do this almost daily
It goes hand in hand with Linux desktops too, because everything is just so much more scriptable. That used to be intimating, user unfriendly, and maybe it still is. But with AI it enables so many new avenues.
Now that LLMs can do the actual configuration, I started using NixOS and now all my config lives in one repo, and every quality of life improvement fans out to every machine without issue.
Since Claude (code) knows all about my system, it will also tailor solutions to it when I ask how to do something. Using it I can often find really neat solutions to whatever sys admin task I can imagine.
>If coding is only math and there is only one way to translate a requirement into an implementation, t
What??
It is definitely not true
I’m of course saying there are infinite ways to implement a non-trivial feature.
[flagged]
[dead]
[flagged]
There's some good ideas and points in here, but this bit threw me:
> # We tried this > In July 2025 we went full lights-off
Isn't it pretty well-accepted at this point that the models underwent a step-change in usefulness around fall 2025 / spring 2026? I know that I was able to start handing agents whole features after that, but not before.
I feel like any perspective/experience on "what agents can/can't do" from before that period is... maybe less than relevant to the modern era. TFA calls it out a few sections later with "But surely the models have gotten better since then", but then just writes off any improvement. That does not match my experience.
I had a bit of this impression when reading the post as well as the authors' product website. A lot of it does seem to be stuck in 2025.
For instance I think their post "long-context isn't the answer" on their website post straight-up isn't accurate, and gives me the impression they are just extrapolating previous performance to new models. In my experience, Opus 4.6 and newer have worked very reliably for long context to me (i don't perceive any intelligence drop at 700-900K tokens). Yeah it's extremely cost-inefficient, but it works.
> i don't perceive any intelligence drop at 700-900K tokens
I have countless examples of this for Fable 5 and Opus 4.8 at just half that many tokens. Sometimes they can't even remember the correct workflow even if they're merely an orchestrator and have been going through the same 5 step loop multiple times for pretty much their entire context window.
Wall of shame with an Opus and a Fable oopsie from just yesterday: https://i.imgur.com/znSJ3OE.png and https://i.imgur.com/DLOHQ1B.png
One of them is particularly egregious because it uses a CLI tool to step through the stages that literally tells it what to do next. How do you fuck this up? Needless to say that tool was revised to force the agents to acknowledge everything happened, but I'm sure it will find a way to eventually mess up anyhow.
And orchestration should be the easy part. It's pretty much just writing and adjusting workflow files. Don't get me started on code quality - but I realize that's subjective and my bar is unusually high. There's a reason I have them run adversarial verifiers along multiple axis before their output is even worth my attention.
FWIW, I notice the intelligence drop drastically with long contexts with Opus 4.6. It's barely usable for anything intricate and long. That long window is good for _something_, but it's not as good as a short window.
for synthesis. read the entire whatever in one gulp and boil it down or plan what to do about it.
not for steps.
Oh yeah, that's a use case I love long contexts for. "Here's a day of prod logs, what's broken?" It's an incredible utility, but the qualities much less than with shorter contexts, and you see it much more apparently when you do similar coding tasks with progressively larger windows.
> Yeah it's extremely cost-inefficient, but it works.
And competition is fixing that as we speak.
Opus 4.5 was a massive step change in capability for sure. The opinions of anyone who hasn't bothered experimenting with these things post-Opus-4.5 are not worth a damn.
They still are far from perfect but they're massively helpful.
read. https://github.com/humanlayer/advanced-context-engineering-f...
I just listened to a podcast last week with the author (Dex Horthy) on as the guest. Humanlayer (his company) is constantly trying to push the limits with agents and he's very into using them.
He's well aware of exactly how good the models are today and I'm sure that if he thought they were good enough now to make the dark factory idea work, they'd be trying again.
The obvious statement would then be: 2025 we went all in, 2026 still nothing improved substantially. I also agree with that statement, none of the frontier models handle drift any better. Shotgun surgery and all that. You're waving him off by waving him off, but provide no arguments whatsoever. Is your experience substantially different?
my perhaps controversial take is that opus 4.1 was smarter than 4.5 for complex engineering work, but 4.5 was faster and "squishier" - it responded better to simpler prompts, it read between the lines of user input better, and that this was really important to converting new users quickly
Did you even read further on? The section right after that addresses the step changes in current frontier models https://github.com/humanlayer/advanced-context-engineering-f...
it is absolutely wild to me that this keeps floating to top comment thread when the guy very clearly did not read even the first half
As I mentioned explicitly in the comment you're replying to: yes, I did read that section. Did you not bother to read my whole comment before telling me to read more?
> I feel like any perspective/experience on "what agents can/can't do" from before that period is... maybe less than relevant to the modern era
This part of your comment is confusing.
The article talks about agents past this period. Yet it seems like you’re saying this article isn’t relevant because it doesn’t?
OK, but having read that section you'll see how
> just writes off any improvement
Is not what that section contains?
There's a more nuanced point about capabilities improving in some ways but not others (ability to one-shot apps vs. maintenance of existing code over time).
To me, the thing that stands out about the whole state we're in here is PR review.
Yes, in an ideal world, PRs read well, are a joy to review, reflect what you discussed etc etc. We have to be real; there is only so much we can do to that end.
I'm not sure how the best teams do PR review, from my perspective it sucks. I'm talking specifically about the UX. I've always hated Github's PR page, so I typically reviewed by pulling down the branch and opening the diff with $EDITOR.
These days I think there's really no excuse for the awful UX. Linear (a company that isn't even in the domain of code review) put out a basic PR review feature[0] that is already better than what GH offers. It's simple: point a small model at the PR, group file changes together based on theme, add some commentary and sort by importance (schema changes > openapi spec).
Immediately, so much mental load has been reduced without the reviewer or the requester doing anything. This feature is pretty damn basic, and I think there are obvious next steps like generating visualisations which a dedicated product could find the time to implement.
Keen to hear others thoughts on why this is the wrong approach, or if there are tools in wide use that solve for this, or why this isnt the right problem to focus on.
0 - https://linear.app/docs/diffs#guides
I'm not sure how the best teams do PR review..
They don't do them. They discuss the changes as the team are doing them (software design and architecture), they automate all the things that would be nitpicks (linting, formatting, etc), and they adhere to a strict 'Do not break the build' rule so merging in something can't be disastrous (with a lot of automated checks and tests to prove that's true). They also make sure there's a robust rollback process just in case.
Once you do all that the PR process is pointless. It never catches anything useful. The team can trust one another to merge without that gate.
> Once you do all that the PR process is pointless
manual PR reviews can catch things that llms currently miss. Examples are duplicated code, lack of unit tests or introducing security issues. None of these really break the build. So just requiring "do not break the build" is a very low barrier.
Tests also are useless unless you have a smart system that runs the new test WITHOUT the changes and see it break. Most teams I see today have the LLM write a test along with the change, without a guarantee that the tests actually guard the feature.
manual PR reviews can catch things that llms currently miss
I didn't say LLMs though. I'm talking about the sort of code quality tooling that's been in use for decades - Sonarqube, Codacy, CodeClimate, etc for code quality, eslint for AST-based code rule checking (easily picks up duplication for example), Istanbul for code coverage, Wiz or Github Advanced Security for security.
These are well known industry standards for knowing a code change is correct without giving it to an LLM to guess at. If you have them, and they're well configured, and you maintain the tooling properly, then PRs become unhelpful gates that don't find problems.
I am not familiar with all the tools you listed so please correct me if i am wrong, but all these will catch stuff that LLMs can potentially catch as well (if configured correctly).
They will not handle any architectural problems (i.e. this method is correct but doesn't belong on this package, or this method is called isX - but has side effects).
And I am pretty sure that none of them do what I am saying with the tests. i.e. run tests without the associated code change and see them fail. I am also pretty certain that none of them will understand problems with breaking backward compatibility (i.e., a fix that is correct that breaks the setup of all existing users).
In other words, it is possible today to create a PR that passes all checks, all security scans, all analysis tools, all test suite while still being wrong due to architecture, backwards compatibilty, wrong scope etc. So even before and even after LLMs a human is needed there.
PRs might become unhelpful as you say if in the future one of the two things we happen
1) LLMs have unlimited context so you can pass all source code plus all architectural designs them 2) We have a super smart analysis tool that is one level above what we have today (including llms)
We are not there yet.
> They discuss the changes as the team are doing them (software design and architecture)
I find the format of PRs to be better suited to discussion than slack/teams messages. Key developers need to actively sign off, code suggestions are much easier, and the CICD makes sure we're not wasting time discussing code that's not compliant with obvious standards.
Obviously some level of agreement is needed before creating a ticket at all, but implementation details around say creating a terraform module to share functionality between teams do need to be discussed somewhere - and it can be difficult for any individual dev to have all the low level context.
Thank you for this response. I do think this hits home as the most elegant and reasonable approach. For my teams currently, I can see us already moving toward this implicitly, but perhaps needing to take a more explicit approach. I think your framing crystalises it well.
Gating integration behind code review is futile. I (and many other engineers) already automated it. My agent responds to review requests and reviews as me. Company policies enforcing human code review are futile.
I think all these platforms chasing code review are doomed. My LLM doesn't need any of this tooling.
We should be reviewing the actual working software. Systems that make it easy and instant to demo any proposed change are what is needed. Code (and specs) are going to fade into obscurity. PR review has already shifted towards validating the product (working software) over the process (code).
The future of software production is more like Replit – not GitHub.
Wow, good to know. Can you tell me what company you work for so I can make sure it's not part of my stack?
It's many if not most companies now doing automated PR review.
Asserted confidently without a shred of proof
This entire article is about the fact that the codebase deteriorates over time when you work this way. If they are correct, it will take longer and longer to develop PRs, and more and more cycles to QA them. Eventually the code will be unsalvageable and it might get there before anyone notices a problem. I don’t know if they are right but I know codebases can get there with humans at the helm - and the humans can adapt and learn.
This is not a certain fate but it sure looks likely and is a serious risk. Some software is so low stakes that you can get away with it I’m sure - there are always trade offs.
The bet is that models get better faster than code gets worse. Looks like so far it's correct, as Fable can already write better code than me and most others on average.
the thesis of the post is that this is not true. fable can solve more problems but for complex systems it is not sufficiently diligent that you can turn the lights off.
They turned the lights off in 2025. The post is simply not accurate to today, they even say so, stating that apparently no one has proof of better models in 2026 improving codebases over time. I've seen it happen but the author hasn't apparently, so it's a game of "you said I said", not anything concrete.
(op here btw) - the question isn't "can models make code better" - its "left fully unattended, will they turn your codebase to slop over time"
from the footnotes (sorry if this got a little buried)
> yes of course you can get gpt-5.5 xhigh to do BRILLIANT refactors. But you had to tell it to do that. And to tell it to do that you had to understand your codebase well enough to know it needed doing. We're here talking about why lights-off wont work
i suppose this would also be a good place to ask if you fall in the "high stakes production systems" camp
> If you love vibe coding, please, go on vibing. I still vibe code lots of things, I just also maintain lots of production software (and through HumanLayer, help 1000s of other engineers do the same), so the rest of this is aimed at folks solving hard problems in complex codebases.
GPT 5.6 Sol and Fable are similar step changes, not 5.5, but that's beside the point. If in the Markdown instruction files you ask them to periodically clean up the code or refactor where necessary then that's what they'll do. They don't explicitly do it because otherwise people, as they had for previous models, complain where models are asked to change one thing then they rewrite whole systems, so now the latest models are explicitly trained on instruction following.
In other words you can make the AI act like a software engineer complete with fixing and improving code autonomously (Cursor gave a glimpse of this [0]). It is not a failure of the model to do this automatically but a failure of the human having the wrong instructions.
[0] https://news.ycombinator.com/item?id=48982535
i guess to clarify my contention:
generic prompting like "review this code" or "make the architecture better" will raise the floor but cannot come close to human-quality code without humans understanding what code exists and what to ask for.
Obviously cursor and other labs have a stake in this going one direction, but I don't buy it, and I don't think you should either.
In fact, "Rebuild sqlite from spec" has all the problems with every other benchmark that I cited - model knows the whole problem up front and never has to iterate on the pile of slop it created cheating its way to a solution.
In any case, politely, I think we're mostly arguing vibes here and I'm not sure its going to get anywhere.
And what percentage of the software in the world needs to come close to human-quality code? I’d argue the percentage of the whole is VERY low.
The whole point is that if you don't maintain high quality, any software will degrade to the point where the factory breaks. "Human-quality" here isn't quite the right measure because human software factories also bog down in exactly this way.
I’d say all of them. Most people use computers as tools or as entertainment platforms. While a bug may not be life threatening in most cases, it is annoying and stress generating.
Fable writes code better than most humans can already so we've already surpassed human level coding. I think thinking otherwise is just coping for the job or industry.
> Code (and specs) are going to fade into obscurity
I'm always skeptical when I read absolute statements like this.
Especially about specs. They drive and document how the software should work, behave, and under which conditions. In the same moment you write a prompt in natural language, you are writing a spec.
Why should they disappear?
For the same reasoning, we could no longer need books or manuals or documents (is it valuable to keep around that doc about F-22 specs?).
Agreed. Specs are more important than ever. Constraints: types, contracts, protocols, schemas, APIs and such are what ground the boundaries of systems.
Without them, code drift is a guarantee.
Does anyone trust that a set of human sentences typed into a box is more reliable and precise than objectively exact descriptions of data?
This is not to diminish the utility of these code factories. But surely, if anything provides resistance to drift, it's codebase consistency, standards, and things which must objectively be true for the software to function.
>I (and many other engineers) already automated it. My agent responds to review requests and reviews as me. Company policies enforcing human code review are futile.
This is also known as being a terrible engineer. If a company enforces human review and someone deliberately tries to circumvent this with an LLM, I'd fire that person in an instant
The reason for human code review is:
1. So *you* understand what's going on, not the LLM, and people can ask you questions about it
2. Because LLMs are not that good at code review
It seems weird to brag about literally not doing your job. It sounds like you could be replaced with a python script, what value do you bring?
blake smith has a really good post on this - that mental alignment among the team is the primary purpose of code review - https://blakesmith.me/2015/02/09/code-review-essentials-for-...
That is a good post. Thank you for sharing.
I can't help but notice that this person is speaking as a programmer, not the person in charge of employing programmers. Is that what the business values code review for? In my experience, managers enforce code review as a quality control mechanism: the "Find Bugs" step in the article's pyramid. And LLMs are already better than human reviewers at the "Find Bugs" part. Design and alignment with PMs and sales can happen before and after software delivery. At least that's how my employer sees it (and I suspect most other businesses).
It's a rough time to be a programmer who cares about the code, who understands software is a creative process, who understands that designing the software is intertwined with the code, who cares about systems. The hyper-focus on delivery was already a lot to deal with before LLMs.
I can tell you that, because I'm that person.
What I care about with my department:
- alignment on new stuff being introduced into code bases (the bigger it is, the more important to consider promixity on things the teams are working on tho). also: maybe finding a more optimal solution together, implies a proper PR process (which I always created with my teams, it takes time and we plan for that)
- code quality assessment: maintainability, regression tests, taste, security etc. etc.
- code is improved by expecting a review in the end. if you know you're not reviewed, you might rush and push out suboptimal code. hurts the baseline
Maintainability, bugs, incidents, team understanding, complexity (all impacting future delivery, uptime, user retention, onboarding etc.) are all metrics I care about as they impact the software and the company as a whole directly. A lot of CTOs or other execs/managers might not care, but there are a lot of bullshitters out there. Or maybe I'm just used to complex software in regulated/hard fields, I don't know.
> In my experience, managers enforce code review as a quality control mechanism: the "Find Bugs" step in the article's pyramid.
Nope.
To reduce it down to a single word, I'd say we do code-reviews to assess "taste".
-----
Code-review is one part of a larger process (the SDLC!), and while review does help with "finding bugs" it is not the singular reason why we do it; and other parts of the SDLC are concerned with finding bugs in the first place, namely the various Test and QA steps in the process; when your code is in the (peer) code-review step then there's an expectation that the author already identified and resolved actual bugs/defects (i.e. where actual-program-behaviour deviates from the spec[1]), so a PR for new functionality is expected to include unit and integration tests to demonstrate that.
Now Claude will gladly take a Jira ticket, write-up a plan/spec, write tests, implement the feature, verify the tests pass, address static-analysis issues, push branch, and submit the PR - and if-the-program-works then it's "correct" and so surely there's nothing really to review and so merging the changes should be a breeze... but I find myself rejecting these PRs all the time because these agents still "just don't get it"[2]. (But I'm sure they'll "get it" eventually; you can't stop progress). We can revisit this topic when we get there; but for now I'm going to reject an AI-authored PR that eschews it.
Good taste is important.
[1] I'm not going to pretend anyone actually writes any kind of spec (informal or otherwise) for the vast majority of software out there; but an unwritten-spec exists when you mentally combine a vague Jira ticket, platform-conventions and common-sense (and that's how Claude in an Agentic Loop works too, except it always has to write-out the Spec.md/Plan.md to disk first, whereas us humans keep things in our head).
[2] I cannot define "it".
It seems weird to get angry about a change that is happening and will continue to happen due to what the market demands from software, which I believe will be the speed/ability to solve problems, rather than its own stewardship
I'm just here to do good software engineering and make good products. If people want to try and circumvent that process to deliberately make the product worse and slow development down, they're bad software engineers, its as simple as that
Nobody thinks its a good idea to fully automate PRs, at least not anyone with software engineering experience. It slows down your ability to solve problems if your code base is an absolute disaster
Again: If someone fully automates everything, what service do they provide? Why are they even there? Especially actively lying in the process when people are trying to force knowledge dissemination with human reviewed PRs
Sure, if you're shipping a 500MB mobile/web app with a 5s start-up, it probably won't make a difference today, or tomorrow, or 3 months later. The problem is when your codebase is a dumping ground for AI slop and a year from now nobody can make any changes.
Also, it's not just some subjective value put in human review. If a change causes a major outage and it turns out it's because 5 reviewers were all shirking the company-mandated responsibility of review, and it could trivially have been caught, I would 100% expect those people to get fired. It's not a process issue if people are intentionally circumventing the process.
There are also compliance reasons.
SOX requires code review by a second party. If the reviews are automated, the development process isn't in compliance and that can get expensive in a hurry.
And of course these SOX-mandated second reviews were 99% of the time pure theater.
Sort of; it's like the itemizer systems at airport security. They're entirely theater (in the sense of "for show") but that show is itself important in that it makes entire categories of attacks significantly less feasible.
Sort of like how simply having a uniformed police officer on a street corner reduces street crime significantly even if the officer never interacts with anyone.
Or that their company does not in fact enforce human PR reviews or even encourages AI PR reviews.
this is exactly right
What's your job as an "engineer" in this post-automated world?
QA?
The role of a software engineer is foremost about the ownership of software systems, and secondarily about modifying them or developing new ones.
Software development is a continuous operational undertaking, like having a garden, and not a one-shot "task" like designing a logo. Systems need to be tended to and somebody needs to know how they work, especially if they're business-critical or (in the case of software companies), the business itself.
A corollary point is that many of the rules and policies of the business are solely embedded within the software itself. There is rarely a complete set of documents that says "this is how everything works" -- if you want to know how something works, you ask a software engineer, they take a look inside the codebase and then tell you how it works. In that sense, all software engineers are also product managers (or more accurately, product managers are just crude software engineers, but that's besides the point).
> The role of a software engineer is foremost about the ownership of software systems, and secondarily about modifying them or developing new ones.
Yes! That's sooo accurate. Tools you use change, the level of abstraction you operate changes, but the role remains.
Producing features and fixing bugs, same as it was before. The organizational process of software development has not changed much with AI: execs decide direction and initiatives, PMs decide what to build, which is broken down into features and bug fixes that SWEs produce. In my experience organizations don't actually care how SWEs produce features, except insofar as it relates to how many and how fast the features can be pumped out. Organizations see code review as a process to prevent bugs. Humans are not as good as LLMs at reviewing code for bugs. Abstract notions of code style and quality that programmers care about is not why organizations enforce code review.
Before LLMs, "organizations" have seen code review as multiple things:
A lot of the above could be fun and engaging, and especially knowledge sharing and ensuring maintainability/readability was a very motivating thing for me as a more experienced engineer having learned so much from getting good reviews when I was less experienced.Programmers care about style to ensure readability and thus maintainability of the code, but also to keep changes minimal — if every diff converted between tabs and spaces in the entire codebase, it'd be impossible to see what has really changed with the simple tooling we generally use (one could build diffing tools that ignore changes like these, and they even exist, but are not ubiquitous).
> We should be reviewing the actual working software. Systems that make it easy and instant to demo any proposed change are what is needed.
"Program testing can be used to show the presence of bugs, but never to show their absence!" -- Edsger W. Dijkstra
And it doesn't take into account maintainability, complexity, security etc. I think the commentator above you is not a SWE. No one could be that ignorant
> We should be reviewing the actual working software. Systems that make it easy and instant to demo any proposed change are what is needed.
You’re arguing for experiment over logical proof or reasoning. That’s qualitatively a very different thing, and the former is no adequate replacement for the latter.
Entropy is not your friend.
> We should be reviewing the actual working software. Systems that make it easy and instant to demo any proposed change are what is needed. Code (and specs) are going to fade into obscurity. PR review has already shifted towards validating the product (working software) over the process (code).
Ok, sure, if your software can be easily exhaustively re-tested on every change.
But in that case, why were you ever doing PR's in the first place? Cargo cult?
PRs sucked to review long before Agents were a thing, but now it really sucks because there are more to review.
Like you said, they sucked back then but it was more rare to get PRs of many thousand lines to review multiple times a day in my experience. But I also run into a problem now in which I have coworkers in two camps. There are some that, when they send me a PR and I have serious concerns about it, it's because they disagree with me fundamentally on some concept and we need to chat and discuss it. And then there's some coworkers who send me with a PR I have serious concerns about because it's very clear they never reviewed the LLM output before making a PR. Those people also tend to take my comments, run them against their LLM session, and slack me back some Claude list-of-questions stuff, and often also respond to me with LLMese.
I firmly believe there's no reason to employ the latter group. I have several coworkers like this that I could replace with a Claude session or two every week and I'd still have to push back on work and review a lot, but I'd still wind up saving time because then I'd talk directly to Claude.
So I guess my point is that I dislike AI era code review because for some subset of it, I basically can't even assume a human has ever looked at it, and that by doing so, I'm doing the work for one of my coworkers who is probably doing his grocery shopping at 2PM as I read it.
I received two 15,000-line PRs the other day, from the same person.
I am currently ignoring them.
I very much remember whose PRs I can trust and whose PRs are likely to be slop, and I prioritize my time accordingly.
Slop merchants get slop reviews. I just point my clanker at their PRs and ask them to critically review the PR and they typically find lots of issues.
Right on. In many ways AI has just exposed how bogus and delusional our industry's "process" has been for years.
> group file changes together based on theme, add some commentary
Isn't that what commits are? Or ... should be?
No, commits always display the files in a fixed order, and then display changes from line 1 to line N. An AI could select the order to display in, add per hunk commentary and automatically adjust how much context lines are displayed.
But if you need to split the commit in hunks, and add a commentary per hunk, isn't that just a sign that you really should just split your commits?
That's the most killer feature of git, that it's so easy to slice your commits any way you desire, and then redo again. The use case of taking a chunk and commit separately is so common it even got a special mode in the add command. That, and the super fast jumping between branches is what set it apart from contemporary version control systems.
The extra context provided by the review tool is gone when the review is done anyway. Review systems come and go, but the commit log is for eternity.
I just dont think LLMs are very good at judging importance or summarizing code.
I tried experimenting with what is ultimately a treesitter based approach - https://github.com/0x007BA7/codebook
And really liked it. Definitely nowhere near production ready but I think theres room for a player to come in and do something similar.
yeah that was another thing i hoped would pour through here - that deterministic systems are much better for evaluating quality (test, linters, cyclomatic complexity, etc) - but that we don't have such a system for code maintainability, at least not one that's widely accepted or adopted
PR review sucks because engineers often don't optimise their code authoring for it. When they do it's a joy.
PR review of agent generated code sucks because agents are, in my experience, very poor at authoring for review. This makes sense because the review process is not represented in the resulting code artifact which is what they're trained on. Agents are always producing much larger changes than should be in a single step, and often touch unrelated code with poor judgement of whether it should be included or not.
One thing that really bothers me about agents is they generate excessively long and detailed comments.
This sounds good for review. Except… the comments are never intent or trade-offs, they’re always the “what”, which the code then duplicates right after. Comments should be short, concise “why”. Often I look at code and think “hm this is odd, I wouldn’t have done it this way, is there some constraint I don’t know about?”
The comment should explain that, not what the code is doing. If I wanted to know what the code is doing I’d read the code!
Agents are also controllable to a degree. How agents author PRs is now an engineering problem.
But this is my point, they're not really controllable in this way. There are no fixed rules (like tests or linters) for small PRs, it's not good enough to do it by line count.
A good PR tells a story to the reader that leaves them confident in the result. That means knowing the reader and how they think, and that is something LLMs are very bad at.
And you can't think of a way to bring an engineers mindset to solve that?
If you leave it up to raw LLM outputs you're not going to get the results you're after. If you put on your engineering hat and think about your problem statement and what tools you can bring to bear on it you'll find you can likely craft a PR authoring skill and a set of evals for that skill that satisfies your requirements with a high enough degree of reliability.
I'm not coming at this cold, I've worked on the skill for PR (CL) creation in the Google monorepo. I'm not talking about raw LLM outputs here. It's a hard problem that is fairly fundamental to the training material being used for LLMs today.
I'm sure we can improve things, I'm sure it will get better over time, but I'd say we're a small fraction of the way towards where we need to be, and trending in the wrong direction with long trajectory development creating bigger changes on average.
yes well said
exactly. a great pr is a joy to review. we've found some success in agents generating static HTML walkthroughs that order the diffs in something other than GitHub's default alphanumeric ordering, but it can only go so far
[flagged]
I think the right shape is to review and merge directly from the agent window.
reviewing code as it's being written & re-steering it > reviewing it once 20k lines have been written
Yep i aim to split my work into tickets that are <=1k lines of code each. In the end it all gets squashed into a mega 10k commit regardless but i can keep track of the quality much more that way.
(more precisely the sub-tickets merge into a bigger feature branch, which in turn gets squash merged into the main branch at the end. i have a tool that automates this flow with a gui and ticket management.)
> I'm not sure how the best teams do PR review, from my perspective it sucks. I'm talking specifically about the UX. I've always hated Github's PR page, so I typically reviewed by pulling down the branch and opening the diff with $EDITOR.
When $EDITOR = VSCode there's a shortcut on the GitHub PR page: if you type a . it opens in github.dev in a VSCode instance.
thanks for pointing out the linear PR stuff, hadn’t seen that. Interesting that while a dozen other companies are trying to muscle in on the hosting/versioning side of github, rather fewer are working on the PR side.
Either you need to understand how your codebase works or you don’t.
Claude can write the code for you but it can’t understand it for you. That part has to happen at human speeds.
There are cases where you don’t have to understand everything, but I think that’s a more nuanced question.
All of the above is true even if Claude writes perfect code.
> Claude can write the code for you but it can’t understand it for you
Part of the problem is that Claude can go spelunking in a spaghetti codebase far faster than us humans. It doesn't necessarily help you understand the project, but if you farm that understanding out to Claude, you can keep working long after the codebase has become unusable for humans...
Ive often wondered what people do when the mess is so bad that Claude hits a wall and nothing works.
Apparently, from what I usually see, they start a completely new project every couple of days. Some revibe their older projects from scratch, with "better" prompts (surely that was the problem).
can't do that with a project in production users are depending on
My experience conflicts with this assertion. I've used Claude to achieve an understanding of two large codebases (that I mostly wrote, and certainly came up with most of the concepts therein) to the point that it's far superior to my understanding. I now get it to explain things to me that I have long forgotten.
> Either you need to understand how your codebase works or you don’t.
It's an interesting point. We can also think about it perhaps as a non binary thing - you need X amount of understanding in a specific codebase to be effective. Even before LLMs in large codebases no one understood it all; but we at least mostly understood our own PRs and our own areas of expertise in the codebase.
I have a very good mental model in my head of each and every codebase I have ever worked on. Nothing to do with my PRs or even my team’s direct responsibilities. I could always direct a thought provoking idea to challenge the existing status quo and get a reasonable nuanced answer from code owners on slack or during a water-cooler talk. I build that mental model also by reading the code. This is my job, so I know when to tear down what or how to respond to a random product idea immediately on a meeting to asses complexity.
Before LLMs you either built good abstractions to make it possible to not understand large chunks of the code base or you flailed.
A lot of the time people flailed.
The one thing Ive never seen an LLM do well is shape clean, coherent abstractions. To be fair it's a rare human skill as well but in LLMs if they don't have a direct analog in their training data they flail.
Maybe I'm doing something wrong, but the code I get from LLMs would not be considered acceptable to merge before we collectively stopped having standards. People are committing 900 line functions with sprinkled return statements and it's getting into production. If there are productivity gains to be had I haven't seen them yet
It is comforting to find other people experiencing the exact same reality as me, since I see so much in this post that matches my own experience.
It reminds me of all the recent talk about "taste". Architecture "quality" may not be objective in a right/wrong sense, in the same way that fashion isn't right/wrong. It's like we are all going to have to relinquish reason/rationality to the machine and start to study up on aesthetics.
Even historically, my big struggles have usually been deciding between two nearly-equivalent options. I get this a lot now with LLMs because there is no break in-between these decisions that implementation used to force. I feel I'm constantly making "taste" calls between tradeoffs that have no clear objective criteria, and it is as exhausting as the code review this post (and my experience) suggests are still necessary, even with Fable/GPT-5.6 level models.
In many cases, I do what I've done with junior engineers whose code I reviewed pre-agent: make on-the-spot judgement calls. When I see a broken window, I call it out. But when I see minor issues, I sometimes just let it pass, note it in memory and tackle it wholesale once an accumulation of similar minor issues get to a certain size.
As a tangential aside, I consider two dev shops from pre-agent days. One decides to hire 7 extremely talented engineers and gets them to work closely together. The other decides to outsource to 100 decent engineers and tries to silo them into modules. I think we are facing a similar choice with agents. You can either work extremely closely with a handful of agents, collaborating on design, review, etc. Or you can spin up a fleet of sub-agents and YOLO, then try to separate the wheat from the chaff in some automated way. My taste is the former, small highly coordinated shop. But time will tell if I am right or wrong.
yeah my best articulation of taste is something i got from Jake Nations[1] while he was still at netflix -
"you know a bad pattern when you see it because at some point you were up at 2am debugging it"
taste is the hard-earned intuition about every anti-pattern and landmine that has blown up in your face since you started doing software
1 - https://www.youtube.com/watch?v=eIoohUmYpGI
That is a good point and I don't mind getting a bit philosophical when I point out that experience is distinct from rationalism. Underneath this there is an argument about empiricism vs. rationalism (or realism vs. idealism).
The hand-wringing on the 50-50 cases is almost always theoretical, in the sense that I am trying to reason instead of rely on memory/experience. But that is a double edge sword because sometimes memory/experience are closer to trauma and can lead one away from a solution that is correct now in some new environment.
It also reminds me of the phrase "use in anger". You don't really know about an approach/architecture until you've had to deal with something in an urgent or high-stakes moment (your 2am debugging). But to get that experience, you have to have shipped the thing first. It is a chicken-and-egg problem, you can't debug something at 2am unless it is live, and you can't know if it will cause you a problem until you've dealt with it.
AI (LLMs, agents, etc) is this giant alteration to the environment that shakes up everything. In some sense, I feel I have to throw out my taste and "use in anger" all over again. It is painful but may be the only way. And I have to accept the risk that going slowly (like this post suggests) may be the wrong way, and I may watch the young untraumatized new-comers blast by me riding their 100 agent orchestrations to massive success. What I mean here is, in the final scenario from my original comment (7 top guys vs 100 decent guys) - I know the result from experience. But am I just traumatized and it will be different with agents?
Wait these arent “software factories” they are strung together ai rube goldburg machines
Its crazy to me people write these articles and create standards like this is some kind of engineering standard with years of research and experience
This is like calling these folks the experts on aviation: https://youtu.be/M9Yww9LG3gw?is=xgtA-xMpNy-09Asu
Its still so early in the game for de facto standards - engineering teams need to experiment and see what works for their own quality metrics not just parrot “standards and methodologies”
This is still the very early days of AI and AI engineering
interesting - i'd say my main goal is to put the current "agentic software factory" hype in the historical context of "we've actually been rube-goldberging software deploys for a while now"
I think there is a fundamental issue here of what building software even means
If you think you can just assign Github tickets to AI agents and go drink daiquiris on the beach I think you'll find that you end up with more and more towers of abstraction and indirection. There are 'points of view' that emerge during coding I think. And at some point you as a human have to be like "wait... what if we use Redis here". "Wait.. the API is already returning the data we need". "Wait... let's not add customers to the report who have not been active in the past year". Stuff like that
> There are 'points of view' that emerge during coding
I know it’s a bit cliche at this point, but this harkens to “programming as theory building”[0] which I agree is easy to lose out on when embracing agentic coding today.
[0]: https://gwern.net/doc/cs/algorithm/1985-naur.pdf
I have had the phrase "programming is building a theory" spinning in my head for days, especially since watching this pragmatic engineer pod with Kent Beck https://www.youtube.com/watch?v=ddHQQtjIOpw
You're hopefully already aware that this references a famous paper from 1985? https://pages.cs.wisc.edu/~remzi/Naur.pdf
The machine gives you what you ask for even when that thing doesn’t exist yet.
Rather than “lights off,” utilizing information theory, decision-making theory and creativity theory makes me better at asking for the right things.
Memory is not transcribed to weights like when humans sleep. Memory is notes handed to someone on groundhog’s day who can’t remember yesterday. We hope they believe us. Don’t be too surprised when a highly entropic system introduces entropy to a project over time.
> "Wait.. the API is already returning the data we need"
To me that's a huge one. I witnessed this firsthand more than once and the fact that you make that comment too just shows there's a problem: I've seen top frontier models go wild, adding shitload of code to spout something that, eventually (after burning shitload of tokens), worked.
While it was basically a one-line change because the data was already there on the client-side.
The thing thought it noticed a pattern and went ballistic, mimicking some existing client-server communication, to "solve" my problem.
The worst is: all vibe-coded projects are full of such nonsense and the "prompt engineers" (such engineers, much wow btw!) who wrote their magical incantations have zero clue about it.
I use these tools daily, I love the time they save me. But sheesh...
If you're working with the 1% of human developers who think like that, sure.
My experience has been that current models are way beyond all but the most highly competent developers I've encountered in my several decades career.
yeah I 100% agree - and I think the most popular coding agent workflows / skill kits are designed to pull those insights and intuition out of humans in a way that optimizes for the developer's experience building the plans or building the code, e.g.
- claude code plan mode - mattpocock/skills - obra/superpowers - research/plan/implement
etc etc
Hard to see them though if you’re not in the weeds and your agents are stacking abstraction on abstraction to pass tests.
yes exactly
I've been building and running my software factory for 8 months now. Granted, there's no automated pulling down tasks and pushing PR right now (soon!). But after specifying what I want, it mostly goes to shipping on its own. On occasion, it does raise issues that I have to make a decision on. After doing systems evals on review, I've stopped looking at code during review for 4 months now.
I do spend a lot of time up front specifying what I want. My prompts aren't one-liners, but rather an interview process where we work through all the open questions and ambiguity.
I haven't hit the wall that the OP talked about (when agents just can't seem to make the right changes, and it's impossible for me to go in and change things manually). I used a lot of guardrails such as plan reviews, browser-based QA, adversarial reviews, unit tests, linters, typecheckers, post-commit hooks, and formal method traces. I also specified engineering principles that steers the code base to minimize state and side-effects: functional core; imperative shell, make impossible states impossible, use pure functional style, etc.
There are times, when I can feel a part of the code base is messy without looking at it, because the agent will make recurring mistakes in the same part of the code base over time. What I found the agent was doing over time is that it's been layering state variables as requirements were discovered. So what helps is to ask it to refactor all these state variables into a single sum type. And if the state machine for it is complicated, I'll ask it to write a formal model of the state in Quint. Then I'll generate traces that get run as unit tests, and ask it to write the code against that.
So while the code base isn't exactly Brownfield, it's over a year old now. As for the code base, there's a backend and a frontend. I think it helps that I established a clear pattern I wanted. You code are like memes: agents will just copy patterns they see in the code base. When it does have to create a new part of the system, I found Sonnet-level models tend to draw system boundaries in all the wrong places. Opus is better. I don't yet know about Fable.
Happy to answer any questions about my workflow.
This has been my experience as well. While not a full "factory", I've got several mature vibed software projects.
More often than not you can "feel" when the quality has degraded. Many of these pieces leave you hanging on the assumption that once it's slopped up that's the game, it's over, you're cooked, straight to jail.
But I've yet to reach that position and be unable to pop the hood, identify the issue, and agentic-ly clean it up.
The post explicitly says it's not a skill issue, but I've yet to see any situation where an average engineer can't unslop their codebase.
I’m most curious about what you’ve built with the code factory. Is it just building itself or do you have any outputs that validate it for building something other than AI coding tools?
It's not building itself, though I did build a harness. It's a collaborative workspace for humans and AI.
I'd be interested in seeing more of your setup, eg if you published a long blog post and/or repo.
Other people have expressed interest too. Will let you know when I'm done.
Same please
I have mixed feelings about software factories!
On one hand, our core product is just simply not fit for them at its scale. We've tried but the project is large enough to require human input for every change. But we have AI automations for light code refactoring, writing tests, UI changes etc. and they work.
On the other hand, I started a number of small experiments to see how far software factories can be pushed and while the code produced so far is nothing spectacular I could easily imagine how this can be extended in the near future. Perhaps if you start from the ground up with the idea that the code will be written that way then you can come up with strategies and architectures that accommodate it. At least this is my thinking right now.
Anyway, it is all open source and documented here https://relentless.works/ I am not sure for long I will keep this running. I provide zero direction to where this is going. I have no idea what it will happen next. It is a fun experiment.
I have another such experiment with a trading agent. I thought it will loose all of the money in short time. For a while it was stuck with no open positions after it lost a bit. I decided not to intervene and just observe the behaviour. Recently it opened new positions which was an interesting development. It is still loosing money (~ -3%) but it has not lost all of them and given the current market circumstances I would say this ain't bad at all. It just shows that perhaps we might be a bit impatient when it comes to AI.
So I think it is probably possible to build software factories but we need new concepts and a bit of change of mindset.
I hope this helps.
I find it amusing that people who are talking about Dark Software Factories, are talking about productivity in terms of number of pull requests or commits as a unit.
If we are going in the Dark Software Factory route, why aren't we calling the code units as bos (bunch of shit) yet.
No one serious about the idea can afford either vanity metrics nor ignorance of the code. The bar is higher, not lower, to operate with this much automation in the water supply. It's mostly a lot more math and a lot more work.
It's an extreme form of any startup: you trade off capital for years of your life.
Interesting, I'd like to discuss further - can you please add an email to your HN profile?
its the optimizing utilization instead of overall throughput all over again. eli goldratt talked about this in the 1970s[1]. we still haven't learned
1 - https://en.wikipedia.org/wiki/The_Goal_(novel)
Surely "pile of...?"
This is interesting and all, but why should we believe any of it?
1) This guy has a track record (confessed) of making shit up, yapping on about it, and pushing it on the innocent. He's done a bunch of damage with his bullshit and now wants us to pay attention again. I mean - something something off fella.
2) There is NO EVIDENCE AT ALL that his ideas are good. He's just making stuff up.
Give me a reason. Also shouldn't he be ostracised and stripped of his wealth for his previous rubbish?
It's just a long ad for his product - humanlayer.
> NO EVIDENCE AT ALL
It's funny how, when the hype is strong enough, the burden of proof around the need for EVIDENCE suddenly shifts.
Normally, the burden of proof is on $NEWFANGLED_THING to prove it's better than $TRIED_AND_TESTED.
Software dark factories where no one looks at code are that unproven newfangled thing and all he's really saying is that, in his experience/assessment, those don't work, so he's trying to find other modes of human-ai-collaboration that might actually work that capitalize better on the things (humans) that weren't broke and didn't need fixing when gen-ai coding came along; and then getting the word out about that.
Under normal circumstances there would be absolutely no ground for any controversy around such a stance. Instead, he's having to contend with reactions like: "But $HYPED_UP_THING, and how great that is is all that anyone is talking about! Don't listen to him, he's just trying to sell you something (other than what everyone else is trying to sell). ...naysayer probably thinks he's smarter than everyone."
It's just he's qualified himself as an unreliable witness. This is not someone who deeply understands and thinks about what he does or what he advises.
The things that I know about, that he writes about, where I know he's got it a bit wrong.... I find myself questioning if he's right or not. Because he's a persuasive writer. But winning arguments doesn't make you right. This isn't a supported, balanced discussion it's a self aggrandising mismash of commonplace ideas and issues.
He's learned how to grab the mic, he believes he has the right to the mic, people are listening to him.. all three of these are wrong and until we call this out and put a stop to people like this shooting their mouths off damage is going to carry on being done.
Totally. On the same page as you. His little shit Wario mustache is all part of the costume! We see through you Dex!!
[flagged]
I've recently started experimenting with grounding LLM driven implementation/verification on RFC based normative specifications, to avoid having to manually steer the LLM during implementation and dealing with reviewing sloppy pull requests.
It works quite well, as it puts your entire focus on writing (hopefully) unambiguous specifications vs. having to discuss unwanted changes with an LLM during code-review. One flaw is that this only works great if you know exactly what you want, which is not always the case.
But do you actually gain anything if you need to write detailed specifications? That seems just as time consuming as writing code, but less gratifying.
Code is just detailed specifications on how things should operate.
> Code is just detailed specifications on how things should operate.
The spec defines how things should operate. Code defines how things operate.
The problem being that if there is only code, then any change to system behaviour is always correct (including bugs). Because that's what the code says.
Relying on tests won't help without a spec to create tests from. So tests are generated from code. So if a test fails, it's the fault of the test, not the code.
Yes, actually that's what I'd had argued a few years ago as well.
It turns out that there are now a few more people that want to get their hands on building software, that don't necessarily understand code, but do have a fundamental idea of system design / requirements.
As you said code has always been a much more explicit representation of those specs, yet arguably introduces lots of noise, necessary to make the program compilable.
Us devs already had the obligation of writing technical documentation for non-technical people, just not at an explicit depth. From an efficiency PoV making that documentation more explicit is much cheaper than manually writing the compilable code. Hurts to say but AI got pretty good with the latter.
I'm curious how that works - are you actually hand writing specs with RFC level detail yourself completely or is it more of an LLM assisted effort? It seems like writing a comprehensive spec manually would almost be as much (if not more) work than the implementation.
I'm writing the specs by hand.
The LLM solely helps with research and retaining the normative document layout (RFC 7322).
Since the spec grounds the underlying implementation I have to fully understand it, writing the spec manually prevents infecting the spec with the typical LLM specification slop.
When writing the specs, the goal is to systematically keep the right balance between scope and depth:
- Scope takes the most effort because it's the only thing preventing the model from escaping an intended boundary, that includes things like stable constraints/interfaces/data models
- Depth is something where I can tolerate "non-normative" interpretations by the LLM. Unless I need a stable implementation, I can decide how much I manually invest into depth vs. letting the model figure the "good enough" solution.
Since the scope/boundaries are explicitly set, the internals are pretty encapsulated and the model comparing an implementation with the spec can identify the "non-normative" pieces and communicate those to me. Then I can decide between "good enough" or to refine these non-normative implementations and make them normative.
From my various experiments the spec vs. code ratio is roughly 1/8.
normative specifications can help, but the thesis here is that specs that define behavior of the product or even architecture are helpful but there's MORE that can be done and even though "program design" feels too in the weeds it's still essential if you care about maintainability
Isn't maintainability mostly about applying basic engineering principles e.g. separation of concerns, single responsibility, dependency inversion, open-closed etc..? If these topics are addressed in the normative representation, and correctly translated by an LLM into code (especially by slicing up the specifications into measurable outcomes to set the intended foundation), then future change e.g. maintainability becomes essentially easy as well, no?
Historically I know that the majority maintenance problems occur from slow continuous evolution of a system that it initially was never designed for. And the only way to address this was continuous system design.
> Historically I know that the majority maintenance problems occur from slow continuous evolution of a system that it initially was never designed for. And the only way to address this was continuous system design.
yes exactly - this is what I'm advocating for - that you can't skip the system design, and that actually good system design goes down to the typedefs and object graph at the code level, not just mermaid charts and db schemas and service contracts.
I will highlight what a few others have said along the lines of "a sufficiently detailed spec IS code" - that is, to make the spec guaranteed to produce the code you want, the spec will look a lot like code (and will be roughly the same effort to review as the code itself anyway, saving you no time)
what I'm proposing is "how can you maximized the odds that the code WILL be good or close enough to good that its easy to get there, with the LEAST amount of human effort/attention" - how can you move fast without skipping what matters
https://haskellforall.com/2026/03/a-sufficiently-detailed-sp...
Hey, I’ve watched some of your talks on YouTube and they have generally felt right and influenced my thinking as to how to navigate software engineering in this era. I appreciate you engaging here!
I read your piece here and again I appreciate and agree with your main points. You have a section here titled “30 minutes of planning saves hours of review” — but I find it hard to believe that you are doing all this pre-work of creating specs (ai-assisted) at various levels, down to the level of function signatures and such, and this whole thing only takes you 30 minutes. Is that what you meant? Can you talk a bit about how long this process actually takes, or if it is really only 30 minutes, how you pull that off?
My radical opinion is that LLMs are harmful for software development - they are the ultimate "goto" operator. All actual code should be written by a human developer.
Instead, use them in adversarial mode - run QA scenarios using LLM agent as a substitute for end user to do bug discovery.
I love how we need to preface such an opinion as being "radical" nowadays.
> All actual code should be written by a human developer.
This seems arbitrary. Why don’t you say the same thing about machine code? Developers use tools so they can avoid writing machine code. What is causing you to draw a line in the sand about use of tools?
The obvious answer is it’s just a function of the time period you grew up in, and a lack of willingness to adapt to change.
This is indeed an important angle to consider as well.
I think there is some nuance though, but it's hard to articulate. I think that is because there are some long term effects that are currently invisible, but that can be anticipated. A lot of it is the human factor, and how changes to how people think and act may ripple through the organizations as well.
Things such as skill atrophy which may reduce not only immediate skills, but also adjacent skills that were maybe important for critical thinking and making good decisions. Or the fact that learning to use an LLM is a skill that is not truly grounded in reality and can therefore not translate well to other areas (you're essentially learning skills within the "reality" of the LLM, based on its weights). That is very different from machine code --> tools, where the tools make explicit assumptions that are based on the workings of the machine code (which is analytical in nature), and where you can, if you wish to, jump in to override those assumptions where needed without having to adapt to a mental model that operates in its own reality (i.e. the LLM's "thought process").
why?
This is one of the best writeups I've seen of this
a lot of the model's constraints come down to how they are RLed. Discussions online would be a lot better if everyone understood how the labs train the models in a high level (or did a lil data labeling)
yeah i like this and others in the thread mentioned that understanding RL and RLHF and the shape of the data is really important (at least the fundamentals, I'm sure there's quite complex industrialization of RL inside labs as Nathan Lambert says)
Personal anecdote: I was able to set things up in such a way that multiple non technical people at my job were able to build features into our project. One person even created our own CRM. And I'm not a turbo-genius savant.
The one downside was that it required their computers to install dev dependencies, postgres, infisical for secret management, etc.
That's the next frontier. What I'm working on now independently. I plan to open source this solution, but again I'm not a savant genius. I guarantee many people are working on the same thing it's converging. Our job as engineers is becoming more of a higher level facilitator and AI "plumbing" maintenance work. How can we get the AI to empower everybody at the company while keeping the wheels turning. That's my aim.
Love the idea of RL for codebase health.
And a benchmark to measure against!
Imagine a "MaintainabilityBench" that rewards models which detect code duplication while working on a task and perform some refactor instead of glibly duplicating; or that detect the need for a new architectural layer, or that hoist a type constraint so there's no need for dumb casts. You can keep on imagining scenarios.
There are probably a few hundred distinct elements to RL for. The books "Working With Legacy Code" and "Architecture of Open Source Applications" would be great fodder.
Sadly don't have time to build it, there's this mountain of reviews in front of me...
sometimes you forsee the code developing vastly differently between the two copies so you don't want the refactor. it really all comes down to lack of online learning and contextual awareness; memento mori notes are about as effective as developers with no expertise reading the design patterns book (well, ok, they are effective, but not sufficiently and not always directionally correct as its hard to accurately encode the nuance with language)
So true.
So when you see that split coming, do you drop a quick warning, or just copy-paste and leave the mess for tomorrow?
https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction probably describes what happens with sufficient nuance
> perform some refactor instead of glibly duplicating;
wouldnt that be part of original RL though. why would it be a seperate thing.
Because writing code that passes a test is different to passing the test while also noticing and performing a refactor.
> When I say maintainability, I mean the specific thing where it becomes really, really hard to change one part of the codebase without breaking another part.
The corollary of agents being bad at maintainability but good at coding is that you can vibecode all the parts where maintainability doesn't matter.
So if you build a (domain-specific) modular architecture for your software first you can then just let your software factories loose on building the modules.
Until you inevitably need a cross cutting concern.
“Oh just this one time”
Then an agent sees the pattern and assumes it’s a best practice. Then your beautiful architecture is ruined.
“Just this once” indeed.
this is 100% right. you have to guard the codebase patterns with your life. because the codebase is part of the prompt.
yeah this is along the lines of what some friends of mine call "core vs. pragmatic modules" or even s/modules/codebase zones/
the idea that if you have a solid core and decoupled modules, you can have "zones" in your codebase where you allow the model to run wild and do a little slop, because you know the blast radius is contained
Except that there is typically a feedback loop between the implementation and the module interfaces. While implementing, you discover aspect that makes you adjust, and sometimes completely alter, the interfaces and module boundaries. And that’s not just for an initial implementation, it continues to happen as new requirements come in over the lifetime of the software. Ostensible implementation details continue to inform the architecture.
It's a skill issue... governance and culture skills. Doesn't matter at this point what model you use... a thoughtful harness with appropriate levels of HITL and strong security, governance, discipline. "We" have a very successful dark factory running... no I cant tell you about it. It's trade secrets at this point. It was incredibly hard to build, roll out, and maintain.
People have no idea that 2 years ago we hit peak performance with omni models. We won competitions with GPT-4o-mini, mini... it does not matter. Context matters. Discipline matters. Observability matters. Most of all, PEOPLE matter.
All of the fools who tried this and laid people off. Fools. It's about empowering your team, making their lives easier, less frustrating, and higher impact.
> I haven't been able to dig up any definitive data/findings from StrongDM on how that whole dark factory went. The weather-report has a few sparse updates between February and June of this year.
This was easy to find out I thought. And just with an old-fashioned google search too, no deep research agent needed. See here: https://diffusion.io/
Seems like it went pretty well if a consulting company is now being started.
I agree with a lot of what Dex Horthy is saying here but on some fronts I feel like he's missing something. Coding well with LLMs, it's not a skill issue, it's an effort/laziness/rigor issue.
In order for coding with LLMs to go well, there has to be more rigor, more discipline, more good engineering hard-assedness. To reiterate, the teams seeing the best results with AI were already high-discipline and high-hygiene.
AI works on data. The better the data, the better the likelihood of a desirable outcome. Code is data. If you have bad code, no matter how awesome the model you let loose on it, you can't get as good a result as if you had good code to start with. This principle has been well known in AI/ML circles since the 20th century.
e.g., if you are doing spec driven development and not seriously investigating formal verification, IMHO you will come up short. Prompts are simply not enough to steer a coding agent to the level of precision needed. Without deep programmatic verification - at all levels, formal verification is just one slice - the solutions the agent produces will always be just slightly (or very) out of true.
“Seems like it went pretty well if a consulting company is now being started.”
You interpreted this backwards. Software companies offer consulting when their product cannot stand on its own. See Palantir, Salesforce, etc.
They are successful companies, yes, but not successful products. The product needs to be instantiated and maintained by sales engineers and consultants and customized into something so bespoke that it’s hardly the company’s product anymore.
> Prompts are simply not enough to steer a coding agent to the level of precision needed. Without deep programmatic verification - at all levels, formal verification is just one slice - the solutions the agent produces will always be just slightly (or very) out of true.
I found this to be exactly right, and in my work I’ve come up with a taxonomy of constraint mechanisms which I keep in mind when guiding agents: generative to constrain the output of the model, interpretive to constrain how the model ‘understands’ code, and elicitative to help it ask the right questions of users.
Full write up is here: https://www.research.autodesk.com/blog/constrain-agent-not-u...
That's an excellent writeup. Haven't gotten all the way through it yet but so far I'm with you.
[dead]
Hi, I'm one of the trio from the StrongDM AI Lab.
Just a minor thing I want to clarify about the Weather Report [1] - it's framed in kind of a negative light in the article ("sparse updates"), but we've been updating it as frequently as we find a meaningful improvement in a relevant dimension. Since we launched it in February it has averaged about one update per month, as frontier labs keep racing forward!
[1] https://factory.strongdm.ai/weather-report
appreciate that context! I definitely did not mean to come out and say "its definitely not working" or anything, but would love to hear from y'all a retrospective on the ~5-6 month anniversary - what was right, what did we get wrong, etc
We are working on new articles to share our latest findings, so stay tuned! Overall our outlook continues to be bullish. Almost all software problems yield to a combination of the Factory Techniques covered on the strongdm.ai website. More powerful models work even better...
awesome - i have updated the post with a link to this thread!
Some more context on the consulting company: StrongDM was sold earlier this year, about a year after the dark factory was first announced, and the former CTO moved on to this (presumably) in order to continue the idea.
Disclaimer: I'm a former StrongDM employee
apg?
> In order for coding with LLMs to go well, there has to be more rigor, more discipline, more good engineering hard-assedness. To reiterate, the teams seeing the best results with AI were already high-discipline and high-hygiene.
hard agree. But i don't think this is sufficient. Even formal verification has its limitations.
> AI works on data. The better the data, the better the likelihood of a desirable outcome. Code is data. If you have bad code, no matter how awesome the model you let loose on it, you can't get as good a result as if you had good code to start with. This principle has been well known in AI/ML circles since the 20th century.
hard agree. but also RL data is shaped differently than SFT data that has driven the majority of AI/ML innovations since ~2000, and its where there's so much room for innovation still. e.g. ImageNet was all just hand-labeled answer pairs.
> it's not a skill issue, it's an effort/laziness/rigor issue
I'm sorry but this feels like a semantic argument - the point of "skill issue" is "you didn't put in the effort or learn the techniques"
[dead]
[flagged]
In autonomous navigation there's a concept taken from sailing called "dead reckoning", where you just use an internal model of the robots dynamics to make controller commands. It works for short distances, but without feedback from sensors, the path the robot takes quickly diverges from the intended one as errors accumulate quadratically over the distance travelled. If the robot travels far enough without any external feedback, the localizer can "diverge", meaning its belief about where the robot is becomes wildly off from where the robot actually exists, making safe control virtually impossible.
Now, if you've got a really good model you can get much further with dead reckoning compared to a worse model. But a model is not reality so no matter how good it is, so without feedback eventually you still run into this problem no matter what.
I imagine that's a lot like what goes on in these agentic loops.
> So, why can't models do software maintainability?
I feel like the explanation does nothing to actually elucidate why models can't do it. Is it an inherent weakness of LLMs? Training processes? The typical "this is crap" that we constantly hear? It goes on to write about RL and how there's no penalty for bad design. But that sort of side-steps the question and makes you ask: "why not do RL and make a penalty for bad design?" Of course the models aren't good at it ... they're not good at anything until you've tuned them and put them in a harness that rewards good edits and throws away (improves) bad edits. That doesn't explain why "models can't do software maintainability." The real question is why harnesses can't do software maintainability, and how to build a system that can do it. (I suppose that's the purpose of the ad at the bottom of the page.)
I think the simple answer is LLM cannot do long term planning.
Maintainability means thinking what will happen to this code in the next year and possibly hundreds of changes and based on that selecting the right abstractions that will work in the long term.
LLMs currently cannot do long term planning and specifically cannot pick abstractions that will work in the long term.
I think that's the important problem to solve. Teaching LLMs how to pick the right abstractions.
Why can they not do long term planning? They know what good software design looks like and can code accordingly. Using Fable for a greenfield project for example, it doesn't dump everything into one file but instead does indeed split out the work into logical units as needed.
Why is a very good question indeed! My guess is we have not figured out how to include long term enough tasks into the RL training.
As to whether they can today, it's pretty easy to figure out that they can't by observing the difference between asking for very high level things like "please make me a website that will be very successful" vs sending it a detailed plans on the goals and many of the specifics and then holding it accountable towards the planning.
Doing appropriate project structure and trying to optimize code quality are definitely good methods to try and increase the chance that the project will succeed long term but I would say they are only methods towards the long term goal and the LLM need to be thinking of the long term goal and how to plan towards that to achieve a much wider and subtile range of methods to achieve long term goals.
/goal and /workflow exists. As I said in another comment, models can do it, as in they have the capacity to do so. It's just the harness that needs to be wired up correctly.
I have a hunch it comes down to the training data. We have spent decades as an industry talking up the new shiny thing, deliverables, frameworks, features, performance improvements, the one thing you don't read copious amounts of prose about is "how I maintained our system so that nobody noticed".
"Here's me throwing code away because it's inherently bad or no longer suitable for the new purpose."
I think it’s because maintainability is a factor of software design, and good design is squishy and hard to articulate. There’s no good metrics for design. All the tools that purport to measure it are doing trivial things like cyclomatic complexity, and can only tell you when things have gotten really really bad, but not distinguish between “good” and “pretty bad.”
Design skills take about 10 years to develop, in my experience, and a lot of smart engineers go through a phase where they make gawdawful messes in the name of “magically easy” designs around the 5 year mark.
Design requires wisdom born of experience, isn’t measurable, and requires forming a mental model of how the system hangs together as a whole. It’s just not stuff LLMs are good at.
> It’s just not stuff LLMs are good at.
But then you're back at the question from the OP of "why not?" Is it lack of good examples in the training data? Is there something of code "goodness" that goes beyond phenomenon that are measurable? Is it that LLMs lack in the ability to organize and think abstractly?
All of the above, but mostly the latter, IMO.
> why not do RL and make a penalty for bad design?
But this is clearly explained in the article. We can tell whether the design was good or bad only weeks or even months later, which is too long to wait for artificial trajectories. Tests, by contrast, provide validation in seconds or minutes.
fair point, this is the thing I struggled most to extract out while writing it - if you can propose an RL environment that penalizes a model for bad design, then I'm all ears - right now there's no fast oracle/verifier for this (as stated in the post)
My current evolving take on "how would you build such a thing" is you need to tee up a roadmap of 20 features and feed them to a model one at a time, so it can't design up front for what's coming.
That way if it builds the first 10 features and the codebase goes to slop, it get's penalized when it can't build features 11-20, or when those features take wayyy more tokens/time/cycles than a model that maintains a clean codebase can do.
This is how most real software is built by most teams - incrementally, getting feedback from users along the way, and steering goals in response.
Isn't that how AI written software gets better too? By steering the model towards the goals of the user?
I don't know if it's a question of how many features to feed to the model, either. Of course, overwhelm the context with too many features and it will get confused. But that's where the memory management idea that G. Huntley talks about is helpful. You're trying to steer the model within its memory limits towards a certain goal.
The problem is getting it to produce "good" code. Formalizing what that means is the task of the programmer. How do you steer a model towards always, or more often, producing good code so that you don't have to do rework? That's the same problem as with a junior engineer, but the way you do it is different. Right now we're trying to do it with mountains of prompts — which sort of works but has diminishing returns — and with onerous code reviews. We've seen this get better over time, but I think some more mechanical methods will help as we figure out how best to steer the models.
I’ve experimented a bit with this approach for quasi-benchmarking models. Most models nowadays will keep trying until you cut them off, they’re happy to go into millions of tokens for an easy task, digging deeper and deeper into crap design. Compared to a clean reference implementation you get easily 20x token difference at task 11+ for the same model. Somewhat ironically I never published the results because the both the harness and the task set were vibe coded and I didn’t have the energy to clean it all up.
[flagged]
> Claude Code won because of Reinforcement Learning inside the harness
Doesn’t this gloss over the fact that token subsidization is a thing? I assume the reason a lot of people switched from other harnesses to CC was all the weirdness around setup-token and whether third party harnesses would continue to work without api pricing.
that's probably part of it but every enterprise in the world (even teams as small as 10-20 engineers) are paying per token, not with subscriptions. Claude code did make it into those orgs because people played with it at home with subscriptions first, but the bulk of that revenue is almost certainly coming from people paying per token, not the ones getting the ~90% subsidy on subscriptions
I 100% whole heartily agree with this. Anyone saying the models made a huge leap in fall 2025 / spring 2026 still aren't looking at whats going on. Just this weekend I thought I had a solid plan and evals/tests to let 5.6 sol work unsupervised over night while I slept and it made an absolute mess. Somewhere in the loop it had to make a decision and it made a wrong one. Making everything beyond that trash. The code 'worked' but it had the wrong system design and wrote the most brittle tests around its assumption, validating its own decision. It turned into a nasty feedback loop for the model. This is 5.6 sol high.
The models write good/great code. I'm very happy to never write code again but models are no where near good enough to run off on their own without a human in the loop. Models LOVE to cheat. Just peek at the tests they write.
And before you come at me, I have built 7 products in the past 1.5/2 years with agentic engineering, all with users. One of those projects is _dead_ because I let the vibe go too hard at the same time Anthropic decided to nerf both their harness and their models silently. If you care to look at the source: https://github.com/Robdel12/OrbitDock I spent a week or so and like a billion+ tokens trying to refactor and save it. It just wasn't worth it.
I wish people would be pragmatic about this. I get the dream is to let it do everything and not to be in the loop, because being in the loop is exhausting. But if you want to make whatever you're building be robust and survive more than 6 months, you have to. I don't care how good your tests, plans, skills, etc are. At some point the model will have to decide something and it'll be the wrong one. Compounding the slop from there forward.
> I spent a week or so and like a billion+ tokens trying to refactor and save it. It just wasn't worth it.
this is exactly what happened to github.com/humanlayer/humanlayer - it was overslopped and we reset from scratch to build it right - spent 2 weeks in VS CODE - not even cursor, plumbing the core patterns from scratch. codebase is part of the prompt, yada yada
> I wish people would be pragmatic about this
that might be the tl;dr for the whole post haha
If you built a real factory, you’d basically never want it to be dark. You’d want a culture of getting wrenches out to inspect the cars being built. You’d want to care about small details. Not because we need to build cars by hand. But because looking at the real product (cars, code, etc) is the best way to make the factory better. It’s the best way to know what problems aren’t being measured, what processes need to improve, and how automation can produce a better end product.
https://softwaredoug.com/blog/2026/07/09/write-code.html
https://en.wikipedia.org/wiki/Lights_out_(manufacturing)
> Xiaomi has an 860,000 square foot factory in Changping, Beijing capable of manufacturing 10 million smartphones a year across 11 fully automated production lines.
> ASE Group, a Taiwanese company that handles outsourced semiconductor packaging and testing have 56 lights out factories.
It has always been the goal to make factories go dark.
There are over 700 engineers that keep the ASE factories going
> By 2024, the company has established 56 lights-out factories, trained more than 700 automation engineers,
https://www.aseglobal.com/csr/sustainability-governance/smar...
> If you built a real factory, you’d basically never want it to be dark
This statement seems to be factually untrue as the fully automated factories in China are indeed not illuminated for most of the time
In USA/Europe we just don't have that level of automation
The “fully automated” factories have humans involved in QA, maintenance and engineering.
They often have to stop the factory and investigate and troubleshoot.
i mean youre most likely not wrong (i dont have insider knowledge of those places), however your previous comment said "never want it to be dark" - when the reality is that its normal operation _is_ dark. only when the automated QA detects issues or theyre doing random inspections are the lights turned up/on
this is an outdated video for waht was state of the art a few years ago https://www.youtube.com/watch?v=MCBdcNA_FsI
again, i dont have insider knowledge so i cannot speak on whats SOTA in chinese automated factories beyond whats covered publicly
don't forget the andon cord
I'm currently learning about Cost functions and Regression in the Machine learning course on coursera[1], and I cannot help but be struck by the similarities of how gradient descent seeks to minimize the error between the model and the training data, how agents do the same (far less mathematically) to seek an acceptable solution to software problems, and how light evolutionary pressures seem to guide species towards a better fit solution to the problem of existence and reproduction. (I'm no expert on the evolutionary example so go easy on me!)
[1] - this course: https://www.coursera.org/learn/machine-learning/home/welcome
> how agents do the same (far less mathematically) to seek an acceptable solution to software problems,
except that there is no gradient towards 'better' software, at least not in a mathematical sense.
Good read and matches my experience pretty well, but I'd humbly suggest the author look up the definition of 'vertical' and 'horizontal' and swap their terminology + fix their videos :)
i humbly disagree - horizontal means touching one plane of the stack across, vertical means cutting down through it and touching multiple layers https://en.wikipedia.org/wiki/Vertical_slice
This is a great write up. I buy the argument against the dark factory approach, but I would be curious to hear if their process has changed at all with Fable/GPT-5.6. I believe the keynote this is based on (www.youtube.com/watch?v=Ib5GBkD555M) was given while Fable was still banned and GPT-5.6 had not yet been released. Has HumanLayer found they still need to follow as deliberate of a pre-work planning process as before? Or do they find that Fable/GPT-5.6 are able to do more with slightly less handholding?
i did a write up on fable while it was out - it can do big refactors, but it does not know what to change without human steering. For that, you need humans to know what to ask for.
lights off is still out for me
https://x.com/dexhorthy/status/2064747631885398231
This is why I built Metaswarm and Metareview and why they work so well, and the are building and supporting production infrastructures and sites for months on end. Give them a try: https://github.com/dsifry/metaswarm and https://github.com/dsifry/metareview
https://youtu.be/Ib5GBkD555M?is=3IFJRnshyZ0tFG_v
Enjoyed most of this but unconvinced by the program design part. If I see an agent writing function signatures or listing which functions to edit in a plan that tells me that I’ve given it too big a vertical slice. I always delete the code guesses. The thing that writes the code must always spend some time discovering where/what to write or it won’t have the right context. Or put another way: “decide first, act later” always feels worse than act-learn-act.
one thing I probably didn't mention is we do the program design having already done an in-depth codebase research, with current patterns and architecture surfaced - that actually seeds every step of the flow including even the product part -
but yes if you're working in very small slices then I think it's very feasible to skip program design and just review the code as you go, and resteer live. I do this all the time for tasks that are too big for a oneshot but on the smaller side overall.
Do you think that the program design adds a lot on top of pointing out the current patterns?
I might be anchored by working with humans, but if I saw a plan for humans that included function signatures and what calls what I would say that is way too detailed. As a result I don't put it in my plans for AI either.
>It's easy to be a little bummed by the core thesis here: "for now we're stuck reading the code".
>I was pretty excited for a world where we could just ask for things and let the models cook and not read the code and get beautiful production software
I feel so disconnected reading those things. Reading and writing code is what brings me joy. I'd never feel "bummed" or "stuck" with it.
Necessarily, better data is what we need, more importantly, better collaboration and better specialization at all. While the title is a bit misleading and clickbait-y, the message is decent.
I disagree with the way that big models are trained on noisy relationships and RL is applied to tone it back down, it represents a stupid amount of compute thrown at this problem at a scale that is often unnecessary.
The rest of it is on point.
> We haven't even hit AI yet, and there are already several loops in this picture.
What a surprise! And here I was thinking that loops had only just been invented, to use in agent harnesses, as described in the famous paper “Loops Are All You Need.”
The compiler is the software factory. It builds the executable given the specification (code).
Like the "building blocks" mentality vs. "factory from scratch" mentality. Because... that's just how the real world works and if we are modeling intelligence off ourselves then why wouldn't that be the right approach?
I’ve been postulating that knowledge of old school principles like Method One along with test driven development and domain-driven design are the external factors allowing a subset of teams to succeed.
Absent those skills, the agile movement is flailing with GenAI.
Interesting framing. As coding agents move from demos to production, the bottleneck usually isn't the model but the harness around it: observability, rollback, and intent validation.
The dude is selling an IDE.
Also it's missing the point of a software factory concept
A software factory will not work infinitely forever for everything. A software factory isn't a solve anything button (aka god).
In a conventional factory, things break and fail. Process machines get poluted. Extruders get jammed.
You still need to establish intent, define what you care about, define guardrails, and of course manage the factory.
and build it incrementally!
You don't have to build the entire software factory at once. You don't have to mastermind the whole future system, instead you're actually stacking and layering these small, isolated problems.
I think that's a really good approach to start getting value tomorrow or this week without saying, "I'm going to revolutionize how we ship."
It's just:
1. Find places where you can use agents.
2. Figure out where the right leverage points are for humans and where the right leverage points are for agents.
3. Just start building those things and plugging them into each other.
One day you'll wake up, and 80% of all of your stuff is automated.
Totally. Also to add to that. I think (like any factory) you need to build in systems to allow you to have observe and service the machines make process changes as needed.
You're the foreman/factory manager. You can optimize the factory over time upgrade machines, place machines closer or add conveyor belts for more productivity.
The only think that slightly worries me is that the Labs are clearly incorporating the best in class logic from their datasets.
Fable, Sol can write any code, it is not the software factories is dead, AI built too many software factories....
the talk version of this writeup was just released today: https://youtu.be/Ib5GBkD555M
To me, this comes down to verifiability. How do we measure the quality of what an agent is doing on our codebase rather than simply measuring task accomplishment?
> Verifying quality is orders of magnitude harder than "did the tests pass"
Agree that agentic grading is the future here. Cognition's Frontier Code is probably the best large public benchmark at this. You attribute agent quality issues to RLVR's binary pass/fail, however I wouldn't be surprised if labs are already supplementing that with rubrics as rewards to train more 'tasteful' models like Fable.
What can a practitioner do? I think there's promise in turning the optimization machine to the harness itself - building out a representative dataset of tasks on your repo, grading agent quality on them across various configurations, and optimizing [AGENTS.md / SKILLS.md / workflow / model / harness / tools] on that signal. High quality grading is still very hard, but it's more tractable at smaller, repo-level scale, and you can afford slower, more expensive verification for each task. You only need it to be right about your codebase's standards.
> In fact, it's not hard to imagine that if a model could reliably tell good code from bad, it might have written the good version to begin with
Pushing back slightly - detecting slop and discriminating quality is easier than generating it (why code review is so effective), and why grading is viable at repo eval scale even if it's much harder at RL scale.
Everyone is flying blind. For example, I am genuinely interested in trying HumanLayer, but would likely want some harder evidence (beyond anecdotes) that it's actually making my agents more effective before rolling out to an enterprise team.
I'm building this harness optimization loop @ https://stet.sh if curious
This is a very well written article and he makes his arguments backed up by data.
We may choose to disagree but thats the point of healthy debate based on clearly expressed opinions.
Key point is I don't think this is AI slop which is way too common in long form articles these days and in keeping with the whole point of his article.
Honest question: For let’s say a senior developer having to go through all of these steps for the model to implement a feature:
> Product Design > System Architecture > Program Design > Vertical Slices
By the time it takes to go through these steps and agree with the agent, wouldn’t the senior dev not just be able to implement the feature by themselves?
I mean, in general; I know there’s always features with complex logic etc, so the question is just about the “general case”
Who said we failed. If we had succeeded, would we tell you?
CMD+F "reward hacking" -> 0 hits.
Fail.
Dex you aren't part of the slop cannon, you _are_ the slop cannon
Just in case this isn't a compliment, I'll note that I think Dex has been pretty good about admitting when they were wrong, explaining why they were wrong, and what they're doing now instead.
we out here trying
i can't tell if this is a compliment or not
[flagged]
[flagged]
[flagged]
[dead]
[flagged]
[dead]
[dead]
[dead]
[flagged]
"Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something."
https://news.ycombinator.com/newsguidelines.html
(and please particularly avoid personal attacks on this site)