Definitely not - the biggest risk with this increased speed is going full-bore in the wrong direction. A product mindset (and a critical eye to architecture) matters more now than ever.
> I use LLMs for exploration and for review, but I write the code myself. I find it hard to believe why so many engineers try to avoid it. It’s not consuming much of my time. And it’s actually the most enjoyable part.
At my workplace, there is more work to be done than there is engineers, and approximately 2 engineers per service. I can spin off multiple Claude Code instances on unrelated work, steering them occasionally, and then finally reviewing the output. After I have reviewed it, I post it for team review.
You're absolutely right that my depth of familiarity is lesser with this code, but we are absolutely shipping more as a result of increased parallelization.
The bottleneck now is typically reviews - both pre-push and team reviews.
I find project-wide or subpackage-wide (for sufficiently large projects) CLAUDE.md's that document patterns (including for tests) solves this.
/init will make a project-wide one, or you can instruct it to "Create CLAUDE.md in any sub-directory that is sufficiently complex" then modify from there.
The model will still have read the entirety of the document before composing its response. And I believe that even in auto mode, there are thinking tokens behind the scenes.
Regarding seed ratio, generally by perma seeding. Many private sites either use seed time requirements instead of ratio or offer bonus points for seed time which can be exchanged for ratio. But also as new editions and formats are released, the library has a bit more turnaround than your music sites of yesteryear.