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,313 karma · joined March 2, 2018
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.
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.
"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
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
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.
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.
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...
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"
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.
- claude code plan mode - mattpocock/skills - obra/superpowers - research/plan/implement
etc etc
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