Consider a team reviewing a system that has been running for a year. It has accumulated complexity: special cases, exception handlers, rules that only make sense if someone remembers the incident that produced them. Looking at the accumulation, a familiar impulse arises: the case for a clean restart becomes compelling. Build it right this time, knowing everything learned so far. Start fresh.
That reasoning has a structural flaw. The complexity of a long-running system is largely composed of memory. Each odd exception exists because something real happened. Each unusual check exists because a default behavior once produced a bad outcome. When a rebuild replaces all of that, it does not produce a cleaner system. It produces an amnesiac one, which will relearn every lesson the original system already learned, paying the full cost of each mistake again.
The practice of iteration offers a different path: find the piece that is genuinely wrong, change that piece, and leave the scars that are still doing their jobs. This is less immediately satisfying than a complete rebuild. It is also more effective over time. A system that evolves accumulates memory. A system that gets rebuilt discards it and must recreate it through the same difficult process.
The same principle governs responses to repeated AI failures. When an AI keeps producing the same wrong output, the instinct is often to restate the instruction more emphatically. Repetition applied to a structural mismatch rarely resolves the mismatch. The more effective move is to change what the AI can see: clearer rules, better examples, cleaner data, one source of truth. When the right behavior becomes the path of least resistance, the repeating failure stops. The intervention is structural, not a matter of restating the same thing more forcefully.
This applies equally to how designs should be held. A design is a current best guess, not a commitment. When evidence pushes back, the productive response is to update the guess. Defending a design that evidence has questioned costs more than updating it: it delays the correction, erodes confidence in the system, and usually requires a larger fix later. The goal is to defend the system and hold the design loosely.
When anything in a working setup resists, the diagnostic question is: which piece is genuinely wrong, and which piece is merely unfamiliar or inconvenient? The genuinely wrong piece warrants a targeted change. The inconvenient piece often warrants investigation to understand what it may be protecting before deciding whether to remove it.