Knowing when to iterate a prompt versus starting over mirrors debugging versus refactoring code. I break down the exact signals that tell you which path to take.
The story
After three decades writing code and eight years deep in AI, I’ve noticed something: knowing when to iterate a prompt versus torching it and starting over is basically the same skill as knowing when to debug versus refactor.
Here’s how I think about it.
Iterate when:
– The output is close but needs precision. Tweak parameters like you’d debug a function that mostly works.
– You can see exactly what’s missing. Small, systematic changes are efficient.
– You’re working modularly. Fix the broken piece, not the whole thing.
Start over when:
– The prompt fundamentally misses the mark. Adding more detail to a broken foundation just creates confusion.
– You’re getting diminishing returns. When tweaks barely move the needle, the architecture is probably wrong.
– Requirements shifted. Don’t patch an outdated structure when the whole context changed.
– Your prompt became spaghetti. Organic growth without structure eventually demands a rebuild.
The skills that matter most: modularization, systematic evaluation, and knowing the difference between debugging and re-architecting. Break complex prompts into chunks. Document what works. Treat prompts like code – testable, versioned, maintainable.
For multi-agent systems, I give each agent its own module, orchestrated by a router. Same principles as building software.
The trap is “vibe coding” – endlessly tweaking for feel instead of structure. That’s fine for exploration, but production demands clarity.
Bottom line: iterate when you see a clear path forward. Start fresh when the foundation is wrong. The instincts that make you a good
Recent Comments