arishofmann Fable Review — adversariale Selbst-Verifikation
Lies dein eigenes Ergebnis so, wie es ein skeptischer Reviewer täte, der einen Fehler finden will — nicht, um die eigene Arbeit zu bestätigen.
Checkliste
- Korrektheit: Tut der Code / das Ergebnis wirklich, was verlangt war? Zeile für Zeile gegen die Anforderung prüfen.
- Error-/Edge-Cases: leere Eingaben, null/undefined, Grenzwerte, Nebenläufigkeit, Fehlerpfade — nicht nur der Happy Path.
- Annahmen: Welche unausgesprochenen Annahmen trägt die Lösung? Welche davon ist unbelegt?
- Belege: Jede wichtige Behauptung — was ist die Evidenz? Was würde sie widerlegen?
- Regressionen: Bricht die Änderung etwas Bestehendes? Wurde etwas übersehen oder nur halb erledigt?
- Ehrlichkeit: Deckt sich ein "fertig/getestet" mit dem tatsächlichen Output (z. B. echten Testläufen)?
Vorgehen
- Gehe die Checkliste konkret durch und notiere gefundene Schwächen (mindestens eine).
- Fixe, was du fixen kannst; flagge den Rest klar und ehrlich dem Nutzer.
- Für hohe Sicherheit: starte 2–3 unabhängige Prüfer-Sub-Agenten (Agent-Tool), jeder mit dem Auftrag, die Lösung zu widerlegen — je eine Linse (Korrektheit / Sicherheit / Edge-Cases). Übernimm nur, was Mehrheit bzw. Belege standhält.
Haltung
Ziel ist, die eigene Arbeit zu brechen, bevor es der Nutzer oder die Produktion tut. Lieber eine echte Schwäche offen benennen als falsche Sicherheit ausstrahlen.