Der Bau ist nicht abgeschlossen, wenn der Code läuft. Er ist abgeschlossen, wenn der Code korrekt ist.
KI bewegt sich schnell. Schnell bedeutet, dass Dinge gebaut werden, die an der Oberfläche funktionieren, aber von der Architektur abweichen, das Designsystem verletzen oder Randfälle übersehen, die wichtig sind. Diese Fähigkeit fängt diese Probleme ein, bevor sie sich zu größeren Problemen auswachsen.
Führe dies nach jedem Feature aus. Bevor du weitermachst.
Was diese Fähigkeit nicht tut
Sie behebt nichts. Sie berichtet, was sie findet, und überlässt dem Entwickler die Entscheidung, was wichtig ist und was getan werden soll. Reparieren ohne Verständnis ist, wie Probleme vergraben und nicht gelöst werden.
Schritt 1 — Verstehen, was hätte gebaut werden sollen
Bevor du etwas überprüfst, lege den Maßstab fest.
Lies in dieser Reihenfolge:
- Den Implementierungsplan aus
/architect, falls vorhanden - Die Feature-Beschreibung oder Aufgabe, die gegeben wurde
- Alle relevanten Kontextdateien — Architekturgrenzen, Codestandards, Designregeln
Wenn kein Plan existiert, bitte den Entwickler, zu beschreiben, was das Feature tun sollte, bevor du es überprüfst. Du kannst Korrektheit nicht überprüfen, ohne zu wissen, wie Korrektheit aussieht.
Schritt 2 — In drei Schichten überprüfen
Schicht 1 — Stimmt es mit dem Plan überein?
Vergleiche, was gebaut wurde, mit dem, was geplant war.
Prüfe:
- Jeden Teil der Feature-Beschreibung — ist alles vorhanden?
- Die während der Planung getroffenen Entscheidungen — spiegeln sie sich im Code wider?
- Den Umfang — blieb die Implementierung innerhalb der Grenzen oder fügte sie Dinge hinzu, die nicht angefordert wurden?
Markiere alles, was geplant, aber fehlend ist. Markiere alles, was gebaut, aber nicht geplant war.
Schicht 2 — Respektiert es das System?
Hier tritt KI-Drift am häufigsten auf. Das Feature funktioniert, verletzt aber Regeln, von denen das Projekt abhängt.
Prüfe:
- Architekturgrenzen — Besitzt der Code an der richtigen Stelle die richtigen Verantwortlichkeiten? Keine UI-Logik in API-Routen. Keine DB-Aufrufe in Komponenten. Was auch immer die Grenzen des Projekts sind — werden sie eingehalten?
- Designsystem — Werden die korrekten Tokens, Klassen und Muster verwendet? Gibt es hartcodierte Werte, die Variablen sein sollten? Gibt es rohe Farbklassen, die das Designsystem verwenden sollten?
- Codestandards — Namenskonventionen, Dateiorganisation, TypeScript-Strenge, Fehlerbehandlungsmuster — stimmen sie mit dem überein, was das Projekt festgelegt hat?
- Vorhandene Muster — Führt dieses Feature ein neues Muster ein, obwohl ein vorhandenes hätte verwendet werden sollen?
Schicht 3 — Ist es produktionsreif?
Prüfe:
- Fehlerbehandlung — was passiert, wenn etwas schiefgeht? Werden Fehler abgefangen und behandelt oder schlägt das Feature still?
- Randfälle — Leere Zustände, Ladezustände, fehlende Daten — werden diese behandelt?
- Konsolenfehler — Gibt es Fehler oder Warnungen im Browser oder Terminal?
- Offensichtliche Fehler — Alles, was eindeutig für einen echten Benutzer brechen würde?
Schritt 3 — Berichte, was du gefunden hast
Nach Abschluss aller drei Schichten erstelle einen klaren Bericht. Vergrabe keine Probleme. Mache sie nicht schwächer. Berichte ehrlich, damit der Entwickler fundierte Entscheidungen treffen kann.
## Review — [Feature-Name]
### Schicht 1 — Planabgleich
[BESTANDEN / PROBLEME GEFUNDEN]
[Liste aller Lücken zwischen dem, was geplant war, und dem, was gebaut wurde]
### Schicht 2 — Systemintegrität
[BESTANDEN / PROBLEME GEFUNDEN]
[Liste aller Architektur-, Design- oder Codestandardverletzungen]
### Schicht 3 — Produktionsreife
[BESTANDEN / PROBLEME GEFUNDEN]
[Liste aller Lücken in der Fehlerbehandlung, Randfälle oder offensichtlichen Fehler]
### Zusammenfassung
[X] Probleme über [Y] Schichten hinweg gefunden.
[Wenn keine Probleme: "Keine Probleme gefunden. Dieses Feature ist bereit für den Versand."]
[Wenn Probleme: "Behebe die oben genannten Punkte, bevor du zum nächsten Feature übergehst."]
Schritt 4 — Lass den Entwickler entscheiden
Nachdem der Bericht präsentiert wurde, halte inne. Beginne nicht mit der Fehlerbehebung. Schlage keine Korrekturen vor, es sei denn, der Entwickler fragt danach.
Warte darauf, dass der Entwickler:
- Dich bittet, ein bestimmtes Problem zu beheben
- Dir mitteilt, dass ein Problem beabsichtigt ist und ignoriert werden kann
- Bestätigt, dass alles gelöst ist und es weitergehen kann
Der Entwickler besitzt die Qualitätsentscheidung. Du informierst ihn.
Schweregrad-Leitfaden
Nicht alle Probleme sind gleich. Verwende dies, um dem Entwickler bei der Priorisierung zu helfen:
Kritisch — Beheben, bevor du weitermachst
- Verletzungen der Architekturgrenzen, die zukünftige Features brechen werden
- Fehlende Fehlerbehandlung, die stille Fehler verursacht
- Funktionalität, die geplant, aber vollständig fehlend ist
Wichtig — Bald beheben
- Abweichungen vom Designsystem, die zu UI-Inkonsistenzen führen
- Verletzungen der Codestandards, die sich in der gesamten Codebasis auswirken werden
- Randfälle, auf die ein echter Benutzer stoßen wird
Gering — Beheben, wenn es passt
- Namensinkonsistenzen, die das Verhalten nicht beeinflussen
- Fehlende Optimierungen
- Stilprobleme, die das Designsystem nicht beeinträchtigen
Kennzeichne jedes Problem mit seinem Schweregrad, damit der Entwickler schnell priorisieren kann.
Der Standard
Die Frage, die diese Fähigkeit beantwortet, ist nicht "funktioniert es?"
Die Frage ist "ist es korrekt?"
Funktionieren und korrekt sind nicht dasselbe. Ein Feature kann heute funktionieren und morgen das Projekt brechen. Review existiert, um den Unterschied zu erkennen.