A Vipe Coding POC – Prompt 4 – Review + Spec-Abgleich

Prompt 4 — Review & Spec-Abgleich

Und täglich grüßt das Murmeltier. Prompt 4 ist wieder einer dieser Schritte, bei denen Codex zum Gärtner wird —
oder anders gesagt: Ich lasse ein LLM den eigenen Code überprüfen.
Du kennst den Spruch: den Bock zum Gärtner machen.
Genau so fühlt es sich an.

Der Auftrag war klar: „Prüfe alles gegen SPEC.md, liste Abweichungen auf, korrigiere sie.“
Tabellen, Constraints, Entities, Repositories — alles einmal durch den Filter.

Exkurs: Warum LLMs schlechte Tester sind

Bevor wir weitermachen, ein kurzer, aber notwendiger Exkurs.
Denn wenn man ein LLM seinen eigenen Code prüfen lässt, muss man verstehen, warum das grundsätzlich problematisch ist.

  1. Bestätigungsfehler (Confirmation Bias)
    Das LLM wurde mit denselben Annahmen gefüttert, die auch zur Codegenerierung geführt haben.
    Es hält den Code daher eher für korrekt, weil es seine eigenen Muster wiedererkennt.
  2. Mangel an echten Testfällen
    LLMs denken nicht wie menschliche Tester.
    Sie erzeugen Happy‑Path‑Tests, keine Grenzfälle, keine bösartigen Eingaben.
  3. Übersehen subtiler Logikfehler
    Race Conditions, Nebenwirkungen, Speicherlecks — alles Dinge, die ein LLM nicht „fühlen“ kann, weil es den Code nicht ausführt.
  4. Halluzination von Test-Erwartungen
    Wenn die Spezifikation unklar ist, erfindet das LLM Annahmen.
    Die Tests prüfen dann die falsche Realität.
  5. Unfähigkeit, Sicherheitslücken zu erkennen
    Sicherheitsdenken ist bösartig.
    LLMs sind höflich.
    Das passt nicht zusammen.
  6. Fehlende Domänenexpertise
    Fachlogik kann ein LLM nicht wirklich beurteilen — es kennt nur Muster, keine echten Regeln.
  7. Keine echte Abdeckungsmessung
    LLMs wissen nicht, welche Codepfade ungetestet bleiben.
    Sie raten.
  8. Verstärkung von Fehlern durch Iteration
    Wenn das LLM auf Basis seiner eigenen Tests Code verbessert, verstärkt es oft die eigenen Missverständnisse.

Fazit:
LLMs sind nützlich — aber nur als Werkzeug, nicht als Prüfinstanz.
Sie liefern eine Basis, aber die Verantwortung bleibt beim Menschen.

Zurück zum Prompt. Codex startet den Review: Tabellen prüfen, Constraints vergleichen, Entities abgleichen, Repositories durchgehen.
Und diesmal findet die Maschine tatsächlich echte Abweichungen.

Die wichtigste: organization_role fehlte komplett, obwohl sie im SPEC als MVP‑Tabelle definiert ist.
Codex ergänzt die Migration und zieht die Domain‑Struktur nach.

In employee gab es zusätzliche Annahmen — ein extra Unique auf internal_number, Default‑Werte, die nicht im SPEC stehen.
Alles wurde zurückgebaut auf den normativen Stand.

Auch audit_log war zu „fleißig“: zusätzliche Indexe, Defaults, die nicht vorgesehen waren.
Jetzt ist es wieder SPEC‑rein.

Die XOR‑Constraint in employee_skill bleibt korrekt: entweder skill_id oder custom_label.

Domain-Layer

  • EmployeeSkill nutzt jetzt ein eigenes Value Object EmployeeSkillId.
  • Für organization_role wurden Entity, Id‑VO und Repository‑Interface ergänzt.
  • RepositoryDb‑Implementierungen wurden erweitert, konsistent zur bestehenden Struktur.

Alles wurde committed (Commit: 56422db) und der PR aktualisiert.

Testing

PHP Syntax: alle Migrations- und Domain-Dateien fehlerfrei.
Docker: weiterhin nicht testbar in dieser Umgebung.

Damit ist Prompt 4 abgeschlossen.
Ein weiterer Schritt, der zeigt: LLMs können Code schreiben — aber sie brauchen jemanden, der ihnen sagt, wann sie danebenliegen.