For such workflows it barely matters which of a dozen models gets used.
Whereas if you're handing off all dev and no longer reading code, just making CTO-level architecture decisions, then there are only 2~3 models right now worth using, none cheap.
For such workflows it barely matters which of a dozen models gets used.
Whereas if you're handing off all dev and no longer reading code, just making CTO-level architecture decisions, then there are only 2~3 models right now worth using, none cheap.
I use frontier models every day and night, but not sure if the described approach is possible with any of them right now. Models still make stupid mistakes and people who do not read the code produced are bound for surprising discoveries in their codebase. Not trying to downplay the effectiveness of LLM-assisted coding and all that, but it's hard to imagine how much stupid shit i would've committed if I was not reading their output.
I used to find real dumb bugs in code reviews. With 2-3 different models doing a combative code review.. most of that is already fixed when I get it.
Another problem is that review changes can easily introduce new issues, so my review prompts go like that: if you find outright shit, fix it right away, but if you have slightest concern, just write your ideas and suggestions in the review and let me decide then. I try from time to time to omit the "slightest concern" part and make agent do all the shit it wants, and usually end up reverting those changes.
But as the sibling comment said, not all code needs quality and indeed I skip some code too, like user playwright journeys -- I only need one auto review pass to verify they indeed test things according to a doc, and I'm fine not reading them. Not all code like that though, some stuff would wreck havoc later if its not looked at.