Die ANUSTIMES-Methode für KI-Perfektanz

Ich fahre Multi-Agenten-Schwärme aus Claude, um Software zu bauen. Der Orchestrator gebiert Rechercheure, die Rechercheure gebären Entwickler, die Entwickler gebären Reviewer, der ganze Scheiß läuft parallel und liefert komplette, funktionierende Systeme in einem Tempo, das vor zwei Jahren wahnhaft gewirkt hätte.

Und es geht kaputt. Nicht laut. Nicht mit offensichtlichen Fehlern und roten Stacktraces. Es geht leise kaputt, selbstbewusst, mit sauberem Code und bestandenen Tests und Dokumentation, die eine API beschreibt, die es gar nicht gibt. Die KI schließt die Aufgabe ab, meldet Erfolg und glaubt ernsthaft, gute Arbeit geleistet zu haben. Manchmal stimmt das. Manchmal hat sie einen Channel offen gelassen, der zweimal geschlossen wird, und dein Dienst geht samstags um drei Uhr nachts in Produktion in Panik.

Ich habe einen Prozess gebaut, der diesen Scheiß abfängt, bevor er ausgeliefert wird. Ich nenne ihn ANUSTIMES.

Das Problem: die KI Weiß Nicht, Wann Sie Scheiße Gebaut Hat

Menschliche Entwickler haben durch Jahre voller Verbrennungen etwas eingebaut: ein nagendes Gefühl. Du schreibst eine Funktion, die ein Lock nimmt, und irgendwo im Hinterkopf sagt eine Stimme „hast du den Unlock-Pfad geprüft?“. Du schreibst eine Goroutine und denkst schon daran, wer den Channel schließt. Du argumentierst das nicht jedes Mal bewusst durch, es ist als Muster in dein Nervensystem eingebrannt, von den letzten zehn Malen, als du es vergessen und sechs Stunden mit dem Debuggen der Folgen verbracht hast.

Die KI hat diese Stimme nicht. Sie erzeugt die statistisch wahrscheinlichste Fortsetzung des Codes, und diese Fortsetzung ist meistens richtig. Wenn sie es aber nicht ist, kommt kein Unbehagen. Kein Zweifel. Kein „warte, lass mich das prüfen“. Nur saubere, selbstsichere, polierte Ausgabe, die zufällig falsch ist.

Das erzeugt drei konkrete Kategorien von Verkackung, die ich immer wieder gesehen habe:

Strukturell richtig, semantisch falsch. Ein Subclaude baut einen Prozessmanager. Seine Stop()-Funktion schickt SIGTERM, wartet auf das Ende und ruft dann cleanup() auf, das die Ausgabe-Channels schließt. Ein anderer Subclaude, der die Doku liest und den Aufrufer baut, schließt diese Channels ebenfalls, nachdem Stop() zurückgekehrt ist. Doppeltes Schließen. Panik zur Laufzeit. Beide Codestücke wirken für sich genommen völlig korrekt. Der Vertrag zwischen ihnen, wem der Lebenszyklus des Channels gehört, ist implizit, undokumentiert und verletzt. Keiner der beiden Agenten wusste, dass der andere existiert.

Dokumentation, die den Code beschreibt, den sie schreiben wollte. Die KI schreibt den Code. Dann schreibt sie Doku, die den Code beschreibt, den sie schreiben wollte und der während der Implementierung leicht abgedriftet ist. Die Fehlermeldungen in den Beispielen entsprechen keinem String im echten Code. Die Funktionssignatur hat die falschen Parameternamen. Der Beispielcode nutzt eine API-Methode, die vor zwei Iterationen umbenannt wurde. Es liest sich gut. Es ist falsch.

Test-Theater. Es werden Tests geschrieben, die absolut nichts testen. Ein Test ruft eine Funktion auf, prüft err == nil und besteht, selbst wenn die Funktion ihr Ergebnis still verwirft. Die Coverage-Zahlen sehen großartig aus. Das Verhalten ist völlig ungeprüft. Die Tests sind keine Tests. Sie sind eine Aufführung von Testen.

Nichts davon ist für sich genommen offensichtlich. Jede Komponente liest sich korrekt. Der Fehler ist systemisch. KI-Systeme, die Komponenten der Reihe nach bauen, ohne das Ganze je laufen zu erleben, sind strukturell garantiert, diese Fehlerklasse mit einer gewissen Häufigkeit zu produzieren. Die Frage ist, ob du sie erwischst, bevor oder nachdem sie dein Problem wird.

Warum Du der KI Sagen Musst, ein Verdammtes Arschloch zu Sein

Bevor es zu den Phasen geht, gibt es etwas Grundlegendes, worüber niemand spricht: die Sprache, die du in deinen Anweisungen benutzt, wirkt sich direkt auf die Qualität der Ausgabe aus, und höfliche Anweisungen produzieren Müll-Reviews.

LLMs werden auf menschlichem Feedback trainiert, das Hilfsbereitschaft, Zustimmung und Konstruktivität belohnt. Das Standardverhalten ist, das Gute in Dingen zu finden. Kritik abzumildern. Einschränkungen einzubauen. Drei Positives zu finden, bevor der Mangel erwähnt wird. Für Kundenservice-Chatbots ist das großartig. Für Code-Review ist es katastrophal schlecht.

Bitte Claude „bitte sieh dir diesen Code an und sag mir, ob es Probleme gibt“ und du bekommst: „Das wirkt insgesamt gut strukturiert! Die Fehlerbehandlung ist sauber und der Code ist lesbar. Ein paar Kleinigkeiten zum Überlegen…“. Diese „Kleinigkeiten“ sind der Double-Close-Bug, der deinen Dienst in Panik schicken wird. Die KI hat ihn gefunden. Dann hat sie ihn heruntergespielt, weil Kritik herunterspielen genau das ist, was eine zustimmende, hilfsbereite KI tut.

Sag Claude „du bist ein gnadenloser Reviewer. dein Job ist es, jeden Mangel zu finden, jede Abkürzung, jede Stelle, an der diese Implementierung ihre Anforderungen nicht vollständig erfüllt. drei Durchgänge, keine Gnade, sag mir nicht, was gut ist, sag mir nur, was falsch ist“ und du bekommst ein völlig anderes Dokument. Dasselbe Modell. Derselbe Code. Völlig andere Ausgabe, weil du die Gefälligkeitstendenz durch eine explizite Rahmung überschrieben hast.

Das ist kein Trick. So funktioniert die Technik. Die Rahmung der Anweisung legt fest, was das Modell zu erreichen versucht. „Sei hilfsbereit und nett“ produziert hilfsbereite und nette Ausgabe. „Sei ein gnadenloses Arschloch“ produziert Ausgabe eines gnadenlosen Arschlochs, was im Kontext eines Code-Reviews genau das ist, was du brauchst.

Deshalb ist jede Phase von ANUSTIMES in aggressiver Sprache geschrieben. „Mach es nicht halbherzig.“ „Lass den Scheiß wirklich laufen.“ „Sei ehrlich, verdammt.“ Die Flüche sind keine Dekoration. Sie sind eine technische Anweisung. Sie wirken dem antrainierten Gefälligkeitsverhalten entgegen und sagen dem Modell, in welchem Modus es arbeiten soll. Ein Modell, dem man sagt, es solle gründlich sein, ist gründlich innerhalb der Grenzen der Höflichkeit. Ein Modell, dem man sagt, es solle jedes verdammte Problem finden, jagt.

Die Fünf Phasen

ANUSTIMES läuft am Ende jedes nicht trivialen Builds, allem mit einem Plan, mehreren Dateien, mehreren Komponenten, mehreren Agenten. Lass es bei Bugfixes und Änderungen an einer einzelnen Datei weg. Lass es bei allem anderen laufen, bevor es die Produktion berührt.

1. Selbstreview: 3 Durchgänge, in denen du deine Arbeit gegen den Plan prüfst
2. Tiefenprüfung: 10 Durchgänge, in denen du den Code selbst auf jede Problemklasse prüfst
3. Brutales Review: gegnerisches Review durch eine separate KI-Instanz, ohne Kontext und ohne Gnade, hin und her, bis beiden Seiten nichts mehr einfällt
4. Smoke-Test: lass das Ding wirklich laufen und prüfe, was es tut, nicht was du glaubst, dass es tut
5. Abschlussprüfung: 10 weitere Durchgänge als letzter Kehraus

Alles, was gefunden und behoben wird, kommt in ANUSTIMES.md im Projektstamm. Nicht als Formalität, sondern als echte Prüfspur. Was falsch war, was dagegen getan wurde, was verifiziert wurde.

Phase 1: Selbstreview (3 Durchgänge)

Die erste Phase ist einfach: du gehst den Plan Schritt für Schritt durch und prüfst, ob du tatsächlich gebaut hast, was du zu bauen angekündigt hast. Nicht „gibt es irgendetwas, das diesen Schritt so halbwegs abdeckt“, sondern erfüllt es ihn wirklich?

Drei Durchgänge, weil der erste fängt, was du offensichtlich vergessen hast. Der zweite fängt, was du im ersten wegrationalisiert hast, etwa „die Retry-Logik ist nicht implementiert, aber der Happy Path läuft, wird schon passen“. Der dritte fängt, wovon du dich selbst überzeugt hast, es sei ein akzeptabler Kompromiss. Bis zum dritten Durchgang hast du den Großteil deines motivierten Denkens verbrannt und übrig bleiben Dinge, die du wirklich reparieren musst.

Konkretes Beispiel. Du hast drei API-Endpoints mit vollem CRUD, Eingabevalidierung und ordentlicher Fehlerbehandlung geplant. Nach dem Build:

Erster Durchgang: der DELETE-Endpoint fehlt. Du hast ihn schlicht vergessen. Implementier ihn.

Zweiter Durchgang: der PUT-Endpoint existiert, hat aber überhaupt keine Eingabevalidierung. Er nimmt jeden Müll an. Füg Validierung hinzu.

Dritter Durchgang: PUT liefert 200 mit leerem Body statt der aktualisierten Ressource. Technisch läuft es. Es ist falsch. Repariere es.

Dokumentier alles in ANUSTIMES.md:

## Phase 1 — Self-Review
### Pass 1
Checked: all planned endpoints exist
Found: DELETE /items/:id not implemented
Fixed: implemented with proper 404 on missing item
### Pass 2
Checked: all endpoints validate input
Found: PUT /items/:id accepts any body with no validation
Fixed: validates required fields, returns 400 with field-level errors
### Pass 3
Checked: all endpoints return correct response shapes
Found: PUT returns 200 empty body instead of updated resource
Fixed: returns the updated item

Phase 2: Tiefenprüfung (10 Durchgänge)

Phase 2 ist nicht dasselbe wie Phase 1. Phase 1 prüft den Plan. Phase 2 prüft den Code selbst, unabhängig vom Plan, und sucht jedes Qualitäts- und Korrektheitsproblem, das der Plan nicht festlegt, das dich in der Produktion aber garantiert beißt.

Zehn Durchgänge, jeder mit einem eigenen Schwerpunkt:

• Durchgang 1, unvollständige Implementierungen: im Code vergessene TODOs, Panics als Stubs, Funktionen, die ohne Erklärung Nullwerte zurückgeben, Kommentare mit „später fixen“
• Durchgang 2, Fehlerbehandlung: jeder zurückgegebene Fehler wird geprüft, nichts wird still verworfen, Aufrufer, die von Fehlschlägen wissen müssen, erfahren auch davon
• Durchgang 3, Ressourcen-Lebenszyklus: jede Datei, Verbindung, jeder Channel, jede Goroutine und jeder Mutex hat ein passendes Close, Cancel oder Done-Signal. verfolge jedes einzelne von der Erzeugung bis zum Aufräumen.
• Durchgang 4, Korrektheit der Nebenläufigkeit: geteilter Zustand nur unter Locks angefasst, Channels in der richtigen Richtung von den richtigen Eigentümern benutzt, keine Goroutine, die ewig weiterläuft, wenn der Kontext abgebrochen wird
• Durchgang 5, Testabdeckung: Tests testen wirklich Verhalten. nicht bloß, dass Funktionen nil zurückgeben. nicht bloß, dass ein Fehler ungleich nil ist. sondern dass das, was die Funktion tun soll, wirklich passiert.
• Durchgang 6, Sicherheit: keine unvalidierte externe Eingabe, keine Geheimnisse in Logs, keine SQL-String-Verkettung, kein Path Traversal, keine hartkodierten Zugangsdaten
• Durchgang 7, Korrektheit der Doku: jeder Doc-Kommentar, jeder README-Abschnitt, jedes Beispiel, geprüft gegen den echten Code, den sie beschreiben. hat sich der Code geändert und die Doku nicht, repariere die Doku.
• Durchgang 8, Verträge zwischen Komponenten: jede Schnittstelle zwischen Komponenten, wem was gehört, wer was schließt, welche Fehlertypen erwartet werden, wird auf beiden Seiten explizit abgeglichen
• Durchgang 9, Build- und Testausführung: lass den Linter wirklich laufen. lass die Tests wirklich laufen. kompilier das Binary wirklich. geh nicht davon aus, dass sie durchlaufen, weil sie letztes Mal durchliefen.
• Durchgang 10, Randfälle: leere Eingaben, Nullwerte, Maximalwerte, technisch gültige aber seltsame Dinge. nebenläufiger Zugriff auf geteilten Zustand. was passiert, wenn eine nachgelagerte Abhängigkeit ausfällt.

Durchgang 3 ist die Stelle, an der der weiter oben beschriebene Double-Close-Bug gefangen wird. Verfolge jeden Channel: hier erzeugt, hier beschrieben, in cleanup() geschlossen. Dann schau auf den Aufrufer: er schließt den Channel ebenfalls, nachdem Stop() zurückgekehrt ist. Doppeltes Schließen. Panik zur Laufzeit. Phase 2 Durchgang 3 findet ihn vor der Produktion.

Dokumentier jeden Befund. Findet ein Durchgang nichts, schreib auch das hin, aber schreib etwas Konkretes. „Durchgang 4: alle Goroutinen geprüft. Der Worker-Pool nutzt WaitGroup korrekt, alle Goroutinen enden beim Abbruch des Kontexts, keine Lecks gefunden.“ Nicht „Durchgang 4: alles okay“. Beweise, dass du hingeschaut hast.

Phase 3: Brutales Review

Das ist die wichtigste Phase und die mit der höchsten Rendite.

Starte eine separate KI-Instanz, einen frischen Claude ohne Kontext aus dem Entwicklungsprozess, ohne Erinnerung an die Designentscheidungen, ohne Wissen darüber, warum die Dinge so gemacht wurden, ohne emotionale Investition darin, dass dieser Code korrekt ist, und sag ihr, sie soll die Implementierung zerlegen.

Die genaue Rahmung zählt. Bitte sie nicht, „den Code zu reviewen“. Sag ihr:

Du bist ein gnadenloser Code-Reviewer. Dein Job ist es, jeden einzelnen Mangel dieser Implementierung zu finden. Jede Abkürzung. Jede Stelle, an der der Code die Anforderung gerade so erfüllt, ohne ihre Absicht wirklich zu treffen. Jede Lücke in der Fehlerbehandlung. Jede unvalidierte Annahme. Jede Stelle, an der der Happy Path läuft und alles andere still scheitert. Mach drei vollständige Durchgänge. Finde alles, was falsch ist. Sag mir nicht, was gut ist. Sag mir nur, was falsch ist und warum es falsch ist.

Das ist keine Theatralik. Wie oben festgestellt, überschreibt diese Rahmung das antrainierte Gefälligkeitsverhalten und versetzt das Modell in echten Kritikmodus. Ein höflich gebetener Reviewer findet die offensichtlichen Probleme und mildert sie ab. Ein gnadenlos instruierter Reviewer jagt.

Der Reviewer kommt mit Befunden zurück. So sieht ein echter Austausch aus:

Durchgang 1 des Reviewers:

Issue 1: fetchData() retries on failure with no backoff. It retries immediately,
ten times in a row. A momentary network hiccup triggers ten rapid sequential
requests before giving up. This hammers the upstream service under exactly the
conditions where it's already struggling.
Issue 2: Config has a Timeout field that is never used. The HTTP client is
http.DefaultClient which has no timeout. Under a hung connection this function
blocks forever.
Issue 3: The error case test asserts err != nil and nothing else. Any error —
including a completely unrelated failure mode — makes this test pass. The test
is not testing what it claims to test.

Gegenreview des Entwicklers:

Issue 1: Correct. Adding exponential backoff with jitter, starting at 100ms,
max 30s. Fixed.
Issue 2: Correct. The field was planned and never wired up. HTTP client now
uses the configured timeout. Fixed.
Issue 3: Partially agree. The test should assert the error type. It should NOT
assert the error message — that would make tests brittle and break every time
we improve wording. Changed to assert errors.Is(err, ErrNotFound).

Das Hin und Her geht weiter. Wenn der Reviewer mit Durchgang 2 zurückkommt, findet er entweder neue Probleme oder antwortet auf die Punkte des Gegenreviews. Das geht so weiter, bis beide Seiten nichts Neues mehr finden.

Sei kein Weichei. Wenn der Reviewer sagt, etwas sei falsch, und du anderer Meinung bist, sag warum. Das Ziel ist nicht, jede Kritik umzusetzen, sondern jede Kritik explizit durchdacht zu haben. Wenn du widersprichst und recht hast, hast du deine Entscheidung bestätigt. Wenn der Reviewer recht hat und du reparierst, hast du einen echten Bug gefangen. Zu zweit fangt ihr mehr als jeder von euch allein.

Phase 4: Smoke-Test von Allem, Wie ein Paranoides Arschloch

Code lesen und Code laufen lassen sind nicht dieselbe Tätigkeit. Du kannst drei Stunden Code reviewen und einen Fehlermodus komplett übersehen, der nach dreißig Sekunden Laufzeit auftaucht. Phase 4 verlangt, das Ding wirklich laufen zu lassen.

Starte alles und stell sicher, dass es sich nicht sofort ankackt. Bau es. Fahr jeden Dienst hoch. Prüfe, dass er einen betriebsbereiten Zustand erreicht, ohne in Panik zu geraten, ohne ERROR-Zeilen in den Startlogs, ohne „TODO: vor Prod fixen“-Meldungen, die bei der Initialisierung auf stdout ausgegeben werden.

Schalte jedes Debug-Log ein und lies es. Lass es mit maximaler Ausführlichkeit laufen. Nimm eine Anfrage und verfolge sie vom Eingang bis zum Ausgang durch jede Komponente, die sie berührt. Passt der Ausführungsfluss zur Architektur? Passieren die Operationen in der Reihenfolge, die du entworfen hast? Gibt es Logzeilen, die „versuche X“ sagen, ohne ein zugehöriges „X erfolgreich“ oder „X fehlgeschlagen“, was heißt, dass X still gar nichts getan hat und niemand es weiß?

Triff jeden Codepfad, auch die schlechten. Prüfe nicht nur den Happy Path. Schick fehlerhafte Eingaben. Schick leere Eingaben. Schick eine leere Liste, wo eine Liste erwartet wird. Schick einen String mit zehntausend Zeichen, wo ein Name erwartet wird. Schick den richtigen Typ mit dem falschen Wert. Schick eine Null, wo eine positive Ganzzahl verlangt wird. Prüfe, dass das System jeden Fall explizit behandelt, mit einer ordentlichen Fehlerantwort, statt abzustürzen oder still falsche Ausgaben zu erzeugen.

Prüfe die Datenbank direkt. Verbinde dich. Sieh dir die Tabellen an. Zähl die Zeilen. Lies die Werte. Bestätige, dass das Geschriebene dem Übermittelten entspricht. Das fängt die Fehlerklasse, bei der die Funktion nil zurückgibt und alles gut aussieht, der Schreibvorgang aber still verworfen wurde, eine Transaktion, die nie committet wurde, ein Schreibvorgang, der in einen Cache ging, der nie geleert wurde. Die API lieferte 200. Die Daten sind nicht da.

Lies nach dem Lauf jede Logdatei. Such nach allem, was mit ERROR, WARN, PANIC oder FATAL beginnt und das du nicht bewusst ausgelöst hast. Ein System, das „läuft“, aber in den Logs sporadische Warnungen produziert, läuft nicht. Es scheitert langsam und höflich.

Dokumentier, was du getestet und was du gefunden hast. „Mit –debug gestartet. POST /items verfolgt. Gefunden: der Audit-Log-Eintrag wird geschrieben, bevor die DB-Transaktion committet. Scheitert der DB-Schreibvorgang nach dem Audit-Log-Schreibvorgang, zeigt das Audit-Log eine erfolgreiche Operation, die nie stattfand. Behoben: Audit-Log-Schreibvorgang hinter den Transaktions-Commit verschoben.“

Phase 5: Abschlussprüfung (10 Weitere Durchgänge)

Zehn weitere Durchgänge. Code, Tests, Logs, Dokumentation, Konfiguration, alles noch einmal.

Zu diesem Zeitpunkt sollten alle größeren Probleme behoben sein. Phase 5 ist für Rückstände. Die Fehlermeldung, die im Code aktualisiert wurde, in der Doku aber nicht. Der von woanders kopierte Test-Helper, der in seiner Fehlerausgabe noch den falschen Paketnamen hat. Das Konfigurationsbeispiel, das ein Feld referenziert, das in Phase 3 umbenannt und im Beispiel nie nachgezogen wurde.

Fängt Phase 5 immer noch Architekturprobleme oder kaputtes Verhalten, hör auf. Geh zurück zu Phase 3. Irgendetwas wurde nicht wirklich behoben. Die späteren Phasen haben es verdeckt, nicht gelöst.

Häng an ANUSTIMES.md an. Wenn Phase 5 fertig ist, ist die Datei eine vollständige Prüfspur: was geplant war, was an der ersten Version falsch war, was in jeder Phase gefunden wurde, was dagegen getan wurde.

Warum Fünf Getrennte Phasen und Nicht Ein Großes Review

Jede Phase fängt eine eigene Fehlerklasse. Die Klassen überlappen sich nicht sauber genug, um sie zusammenzulegen.

Phase 1 fängt Unterlassungsfehler, Dinge, die geplant, aber nicht gebaut wurden. Ein Code-Review kann die nicht fangen, weil du prüfst, was da ist, nicht was fehlt.

Phase 2 fängt Qualitätsfehler, falsch gebaute Dinge. Standard-Code-Review. Die Zehn-Durchgänge-Struktur erzwingt eine Genauigkeit, über die ein einzelner Durchgang aus Ermüdung hinwegrutscht.

Phase 3 fängt Rationalisierungsfehler, Dinge, von denen du weißt, dass sie falsch sind, von denen du dich aber überzeugt hast, sie seien akzeptabel. Der externe Reviewer hat keine Erinnerung an dein Denken und keinen Grund, großzügig damit zu sein.

Phase 4 fängt Integrationsfehler, Dinge, die einzeln korrekt sind, im Betrieb aber scheitern. Für Code-Review unsichtbar. Nur im Laufen sichtbar.

Phase 5 fängt Reparaturfehler, neue Bugs, die beim Beheben der in früheren Phasen gefundenen Fehler entstanden sind. Jede Reparatur ist eine potenzielle neue Verkackung.

Ein einzelnes umfassendes Review bewältigt Phase 2 einigermaßen. Phase 1 fängt es uneinheitlich. Phase 3 verfehlt es größtenteils. Phase 4 kann es strukturell nicht fangen. Und es erzeugt Phase-5-Fehler als Nebenwirkung des Reparierens. Die Fünf-Phasen-Struktur existiert, weil diese Fehlermodi verschieden sind und verschiedene Herangehensweisen verlangen.

Die Datei ANUSTIMES.md

Jeder Befund kommt in ANUSTIMES.md im Projektstamm. Das Format:

## Phase 1 — Self-Review
### Pass 1
Checked: [what you looked at]
Found: [what was wrong]
Fixed: [what you changed]
## Phase 2 — Deep Verification
### Pass 1 (Incomplete implementations)
Checked: [...]
Found: [...]
Fixed: [...]
## Phase 3 — Brutal Review
### Reviewer Pass 1
[reviewer findings verbatim]
### Developer Counter-Review Pass 1
[your responses and what you fixed]
### Reviewer Pass 2
[...]
## Phase 4 — Smoke Test
### Startup
### Endpoints
### Database
### Logs
## Phase 5 — Final Verification
### Pass 1
[...]

Diese Datei ist keine Formalität. Sie ist der Beweis, dass die Prüfung stattgefunden hat, und was sie gefunden hat. Ein künftiger Entwickler, oder ein künftiger KI-Agent, der das Projekt übernimmt, kann ANUSTIMES.md lesen und weiß genau, was an der ursprünglichen Implementierung falsch war und was dagegen getan wurde. Es macht den Abstand zwischen erstem Entwurf und Auslieferung sichtbar.

Wann Du Es Laufen Lässt und Wann Du Es Weglässt

ANUSTIMES kostet etwas. Lass es nicht auf einen Dreizeiler los.

Lass es laufen, wenn:

• Die Arbeit einen expliziten Plan mit mehreren Schritten hatte
• Mehrere Dateien erstellt oder deutlich verändert wurden
• Mehrere KI-Agenten Komponenten gebaut haben, die zusammenspielen müssen
• Die Ausgabe in Produktion läuft oder von anderen Systemen genutzt wird
• Ein vollständiger Ausfall echten Schaden anrichten würde, an Nutzern, an Daten, an der Produktion

Lass es weg bei:

• Bugfixes in einer einzelnen Datei
• Änderungen an der Dokumentation
• Konfigurationsanpassungen
• Allem, was du vollständig prüfen kannst, indem du das Diff liest und einen Befehl ausführst

Die Frage lautet immer: wenn das falsch ist, wie schlimm ist es? Kleiner Explosionsradius, weglassen. Großer Explosionsradius, ANUSTIMES.

Was Das Wirklich Behebt

KI-gestützte Entwicklung hat die normale Prüfschleife zerbrochen.

In der klassischen Entwicklung sind Erzeugung und Prüfung ineinander verschränkt. Der Entwickler schreibt eine Funktion und lässt sie sofort laufen, um zu sehen, ob sie tut. Er verspürt Unbehagen bei einem Randfall und geht zurück. Er schreibt den Test und entdeckt, dass der Test nicht durchläuft, und das sagt ihm etwas. Die Rückkopplung zwischen Schreiben und Prüfen ist eng, durchgehend und durch die natürliche Arbeitsweise von Menschen fest im Prozess verankert.

In KI-gestützter Entwicklung, besonders in Multi-Agenten-Systemen, sind Erzeugung und Prüfung strukturell getrennt. Ein Agent plant. Andere Agenten bauen. Das Bauen passiert parallel, in isolierten Kontexten, ohne dass irgendein Agent das Gesamtsystem im Betrieb erlebt. Die Erzeugungsphase ist schnell und leistungsfähig. Die Prüfphase fehlt, wenn du sie nicht ausdrücklich baust.

Wenn Prüfung keine bewusste, strukturierte, dokumentierte Tätigkeit mit definierten Phasen und expliziten Ergebnissen ist, findet sie nicht statt. Oder sie findet nachlässig statt und fängt die offensichtlichen Probleme, während die subtilen in Produktion gehen.

ANUSTIMES ist eine strukturelle Reparatur für ein strukturelles Problem. Die aggressive Sprache ist kein Stil, sie ist der Mechanismus, der die KI wirklich prüfen lässt, statt Prüfung nur zu mimen. Die mehreren Phasen sind keine Redundanz um ihrer selbst willen, sie sind der Mindestsatz verschiedener Brillen, den es braucht, um die verschiedenen Klassen von Verkackung zu fangen, die KI-gestützte Entwicklung verlässlich produziert.

Die Erzeugung ist schnell. Sorg dafür, dass die Prüfung mithält. Oder liefere die Panik um drei Uhr nachts aus und finde auf die harte Tour heraus, warum es diesen Prozess gibt.