[kstenerud]

My experience over the past year has been the exact opposite. I work through a design with the agent, have it research any points I'm not confident on, drill down on details I feel fuzzy on, and then have it do an adversarial critique of it until it stops surfacing defects. By the time I'm setting it loose to do the actual implementation, there's very little left to decide and it's producing pretty tight code. Plus I now have some solid design documents, a decision history, an issues list, and a set of gotchas for the agent to keep in mind in future.

My LLM is an assistant that helps my designs and decision process, implements the final work expertly, and I'm always in the driver's seat. And the development speed is astronomical.

[AlotOfReading]

I used to do adversarial critique, but I found that "agents can't identify issues" was a surprisingly long way from a good implementation. I kept finding silly correctness issues and shortcuts taken whenever I expanded testing or dug deeply into the implementation.

Now, I'm back to rubber-ducking until I've built my own mental model over a few days of thinking.

[kstenerud]

I'm not doing adversarial critiques of the code; I'm doing adversarial critiques of the designs and plans. If it's still outputting bad code when it comes to the implementation, I do an interrogation round to find out why it's choosing that way, then update the principles, standards, or linting tools to fix it.

[AlotOfReading]

The skill I wrote did both. Design would go through an adversarial round, then a signoff by me, then implementation, then critique rounds by agents prompted to specific types of issues. And even then, LLMs were still struggling to put together complicated bits of code.