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