Fallbacks are like the box of Pandora. Once implemented, one will them only with difficulty again lose.
At the beginning is everything totally great, it functions everything and one is astonished how fast certain apps are built….
They suspect it already ?
Exactly …
Fallbacks are like Pandora’s box; once implemented, they are hard to get rid of. In the beginning, everything is excellent, everything works, and you are amazed at how quickly certain apps can be built.
You sit in front of the screen and can hardly wait to see the new feature that was just developed at light speed. In complex architectures, something suddenly stops working, and the model—humorously enough—determines that the fallback didn’t trigger this time—which fallback exactly? Furthermore, there is no log information, as fallback info shouldn’t unnecessarily clutter the log file.
One solution that I like to use is a POLICY tag, which can be added to a prompt at any time during development. This tag instructs Claude Code to write a policy file and continue, which is then read repeatedly. This ensures that certain things no longer happen in 99% of cases.