What I have found: all that stuff that was evolving over the last 30 years: roadmap definition, sprint planning, unit tests, regular independent code reviews, etc. etc. etc. that those of us who “knew what we were doing” mostly looked down on as the waste of time that it was (for us), well… now you’ve got these tools that spew out 6 man-months of code in a few hours, and all those time-wasting code quality improvement / development management techniques… yeah, they apply, in spades. If you do all that stuff, and iterate at each quality gate until you’ve got what you’re supposed to have before proceeding, those tools actually can produce quality code - and starting around Opus 4.6 I’m not feeling the sort of complexity ceiling that I was feeling with its predecessors.

Transparency is key. Your code should provide insights to how it is running, insights the agent can understand (log files) insights you can understand (graphs and images, where applicable), if it’s just a mystery box it’s unlikely to ever do anything complex successfully, but if it’s a collection of highly visible white boxes in a nice logical hiearchical structure - Opus 4.6 can do that.

Unit tests seem to be well worth the extra time invested - though they do slow down progress significantly, they’re faster than recovering from off-rails adventures.

Independent reviewer agents (a clear context window, at a minimum) are a must.

If your agent can exercise the code on the target system, and read all the system log files as well as the log files it generates, that helps tremendously.

My latest “vibe tool” is the roadmap. It used to be “the plan” - but now the roadmap lays out where a series of plans will be deployed. As the agent works through a plan, each stage of the plan seems to get a to-do list… Six months ago, it was just to-do lists, and agents like Sonnet 3.5 would sometimes get lost in those. Including documentation, both developer facing architecture and specifications (for the tests), and user facing, and including updating of the documentation along with removal of technical debt in the code at the end of each roadmap plan stage also slows things down, and keeps development on track much better than just “going for delivery.” So, instead of 6 months of output in a day, maybe we’re making 2 months of progress, in a day, and generating about 10x the tests and documentation as we would have in those 2 months traditionally - in a day of “realtime” with the tool. 40:1 speedup, buried under 500:1 volume of documents created.