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 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.
4. Halluzination von Test‑Erwartungen Wenn die Spezifikation unklar ist, erfindet das LLM Annahmen.
5. Unfähigkeit, Sicherheitslücken zu erkennen Sicherheitsdenken ist bösartig. LLMs sind höflich. Das passt nicht zusammen.
6. Fehlende Domänenexpertise Fachlogik kennt ein LLM nur als Muster, nicht als echte Regel.
7. Keine echte Abdeckungsmessung LLMs wissen nicht, welche Codepfade ungetestet bleiben.
8. Verstärkung eigener Fehler Wenn das LLM auf Basis seiner eigenen Tests Code verbessert, verstärkt es oft 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.

Der Prompt selbst war klar definiert:

„Erstelle die Migrations für alle MVP‑Tabellen und lege einen minimalen Domain‑Layer an.“

Keine Business‑Logik. Keine Services. Keine Use‑Cases. Nur Konstruktoren, Getter und die Interfaces, die später alles zusammenhalten.

Nach dem obligatorischen „Ja, ich habe SPEC.md vollständig gelesen und verstanden“ legt Codex los. Und diesmal merkt man, dass die Maschine richtig arbeitet: prüfen, planen, abgleichen, korrigieren. Ein technischer Ablauf, präzise und kontrolliert – eher eine choreografierte Routine als ein chirurgischer Eingriff.

Die Migrations

Zuerst die Migrations. Sechs Stück, wie in der SPEC gefordert:

• employee
• skill
• employee_skill
• evidence
• consent
• audit_log

Alle mit UUIDs, Timestamps, Constraints. Sogar der XOR‑Check für employee_skill (entweder skill_id oder custom_label) ist drin – ein Detail, das gerne übersehen wird, aber hier sauber umgesetzt wurde.

Der Domain‑Layer

Dann der Domain‑Layer:

• Entities für Employee, Skill, EmployeeSkill, Evidence, Consent, AuditLog
• Minimalistisch, wie gefordert: Konstruktoren, Getter, keine Logik
• Repository‑Interfaces für alle Aggregate
• Passende RepositoryDb‑Implementierungen – leer oder mit Platzhaltern, aber vorhanden

Codex prüft nebenbei noch die PHP‑Struktur, die Migrations‑Konfiguration, die UUID‑Typen, die Verzeichnisstruktur. Alles wird einmal gegen die SPEC gehalten.

Danach folgen die obligatorischen Syntax‑Checks, und am Ende landet alles in einem Commit. Der PR wird erstellt – neues Feature, neues Glück.

Was wurde umgesetzt?

• Sechs Phinx‑Migrationen für alle MVP‑Tabellen gemäß SPEC.md
• Minimaler Domain‑Layer mit Entities, Value Objects und Aggregate Roots
• Repository‑Interfaces für alle Aggregate
• Minimalistische RepositoryDb‑Implementierungen (save: no‑op, byId: null)
• Alle Änderungen committed und PR aktualisiert

Testing

• PHP‑Syntax: alle Migrations‑ und Domain‑Dateien fehlerfrei
• Scripts: nicht betroffen
• Docker: weiterhin nicht testbar in dieser Umgebung

Damit ist Prompt 3 abgeschlossen. Die Datenstruktur existiert jetzt nicht nur als Idee in der SPEC, sondern als echte Dateien im Repository. Der Domain‑Layer steht, die Migrations sind da – und das Projekt fühlt sich wieder ein Stück greifbarer an.

Aber genau hier beginnt das Projekt: mit Struktur.

Der Prompt selbst war simpel:

„Erstelle die Grundstruktur des Repositories gemäß SPEC.md.“

Keine Business‑Logik. Keine Migrationen. Kein Schnickschnack. Nur das Skelett, das später alles trägt.

Also: Ordnerstruktur anlegen. Docker Compose erstellen. PHP‑Dockerfile. nginx‑Konfiguration. Ein public/index.php mit einem schlichten „Hello Employee Management“. Leere Skripte für migrate.sh und seed.sh. Der node-build‑Service im Profil build. Mehr nicht.

Codex geht das erstaunlich methodisch an. Erst prüfen, was schon existiert. Dann die Struktur bauen, Datei für Datei.

Die docker-compose.yml enthält genau die Services, die in der SPEC stehen:

• nginx
• php‑fpm
• mariadb
• redis
• node‑build
• playwright

Keine Abweichungen, keine eigenen Ideen. So, wie es sein soll.

Das PHP‑Dockerfile landet unter ops/php/Dockerfile, mit den geforderten Extensions und aktiviertem Opcache. Composer wird über das offizielle Image gezogen. Die nginx‑Config richtet sich exakt nach den definierten Routen: /, /api, /docs, /health, /metrics.

Die Frontcontroller werden angelegt: public/index.php, public/api.php, public/ops.php. Dazu Platzhalter für db/phinx.php und openapi/openapi.yaml. Alles sauber, alles an seinem Platz.

Ein kurzer Testlauf: PHP‑Dateien syntaktisch okay. Docker selbst ist in der Umgebung nicht verfügbar, also kein Compose‑Test. Aber das Grundgerüst steht.

Am Ende erzeugt Codex sogar einen Commit und einen PR‑Eintrag. Ein nüchterner, technischer Abschluss für einen nüchternen, technischen Schritt.

Und damit ist die Bühne bereitet. Die Struktur steht. Das Projekt hat jetzt ein Zuhause. Ab hier wird es interessanter.

Und ja — die ehrliche Antwort ist: irgendwas mit Code. Vielleicht sogar funktionsfähig. Vielleicht aber auch nicht. Vielleicht etwas dazwischen, das man höflich „interessant“ nennt.

Es ist ein bisschen wie die Perspektive einer Product Ownerin oder eines Produktmanagers: Im Kopf existiert eine klare Vision. Man sieht Abläufe, UI‑Fragmente, Interaktionen, vielleicht sogar schon die fertige App vor sich. Und dann geht’s in die Umsetzung — und das, was am Ende rauskommt, ist… nun ja… eine Interpretation.

Im echten Leben heißt das dann oft:

„Das hatte ich mir aber anders vorgestellt.“

Genau hier beginnt das erste Problem: die Übersetzung vom Epic zum Task. Von „Ich weiß genau, was ich will“ zu „Was steht jetzt eigentlich im Ticket?“.

Für meinen POC ist mir das gerade egal. Ich weiß, dass ich mit 14 Prompts nicht einmal annähernd das bekomme, was ich denke, was das Ergebnis sein könnte. Und das ist völlig in Ordnung.

Denn das hier ist ein Test. Ein Experiment. Ein bewusst unromantischer Blick auf KI‑gestützte Entwicklung.

Ich glaube nicht an eine Wundermaschine. Ich glaube nicht an einen One‑Shot‑Product‑Ready‑Prozess. Ich glaube an Iteration. An Reibung. An das „Dazwischen“.

Wir — bzw. ich — sind noch ein gutes Stück entfernt von 99,9 % Industriestandard, wenn es um die Ergebnisse von VIBE‑Coding geht. Aber genau deshalb mache ich diese VIPe‑Iteration:

Hands‑on. Lernen. Verwerfen. Weiter.

Der Startprompt wartet. Und ich bin gespannt, was passiert, wenn Theorie und Realität zum ersten Mal aufeinandertreffen.

Oder: Warum ich mit einem ChatGPT‑Abo und einer SPEC.md anfange, statt mit einem „magischen“ Flow‑State

Vorbereitung

Cursor, Windsurf, Claude 3.5 Sonnet, Bolt.new, Cline, Lovable, Replit Agent, GitHub Copilot Edits. Die Liste der Tools, die angeblich „alles für dich erledigen“, wird täglich länger. Aber am Ende läuft es auf eine pragmatische Erkenntnis hinaus:

• Ich habe ein laufendes OpenAI‑ChatGPT‑Abo mit Zugriff auf Codex.
• Das wars.
• Kein Benchmark, kein Warm‑up, kein „Ich teste mal vorher ein paar Prompts“.
• Alles, was jetzt kommt, ist ein First Shot.

Zwar mit versilberten Kugeln, Erfahrung, einem Zielfernrohr und absolut windstillem Wetterfähnchen — aber eben trotzdem: erster Durchlauf.

Was auch bedeuten könnte, dass diese Post‑Serie sehr kurz wird. Oder sehr lang. Oder sehr chaotisch. Oder sehr lehrreich. (Realistisch betrachtet: alles gleichzeitig.)

Die eigentliche Vorbereitung

Eine Idee. Ein Ziel. Ein übersichtlicher Tech‑Stack. Und ein paar Prinzipien, die ich seit Jahren nicht loswerde:

KISS, YAGNI, VANILLA Meine drei Kugeln Eis. Ohne Sahne. Mit Streusel. Mit einem Streusel.

Also kein Hexenwerk. Wald‑ und Wiesen‑Anforderungen. Ein Projekt, das man in der Ausbildung bekommt, wenn der Dozent einen schlechten Tag hat.

Und all das nicht in der Waffel und nicht im Becher, sondern in einer SPEC.md.

SPEC.md – Die Grundlage für VIPe

Ich habe die SPEC nicht geschrieben, um die KI zu beeindrucken. Ich habe sie geschrieben, damit ich nicht den Überblick verliere.

Denn VIPe — Vibe‑Inspired Prompt Engineering — bedeutet nicht, dass man „aus dem Bauch heraus“ promptet. Es bedeutet, dass man den Vibe in Struktur übersetzt.

Und diese Struktur ist die SPEC.md.

Sie definiert:

• Runtime
• Docker Setup
• Routing
• Domain Layer
• Datenmodell
• JSON‑LD
• Auth
• Audit
• Observability
• Tests
• MVP Scope
• Implementierungsplan

Kurz: alles, was ein Mensch bräuchte, um das System deterministisch zu bauen. Und alles, was eine KI braucht, um nicht zu improvisieren.

CODING_FLOW.md – Der VIPe‑Prozess in Aktion

Der zweite Baustein ist der CODING_FLOW.md. Er ist das, was VIBE‑Coding nie hatte: eine exakte Reihenfolge.

Jeder Schritt besteht aus:

• einem Ausführungs‑Prompt
• einem Review‑Prompt

Codex arbeitet sie sequenziell ab. Keine Abkürzungen. Keine spontanen Eingebungen. Keine „Ich dachte, das wäre besser so“-Momente.

VIPe heißt: Der Vibe bestimmt die Richtung. Die SPEC bestimmt die Regeln. Der Flow entsteht aus der Iteration.

Warum das alles?

Weil ich sehen will, ob KI‑gestützte Entwicklung funktioniert, wenn man:

• nicht improvisiert
• nicht träumt
• nicht „mal eben“ etwas ausprobiert
• sondern strukturiert, reproduzierbar und dokumentiert arbeitet

Und weil ich wissen will, ob ein System wie dieses:

• API‑first
• DSGVO‑konform
• JSON‑LD‑basiert
• auditierbar
• testbar
• deterministisch

…von einer KI gebaut werden kann, wenn man ihr die richtigen Leitplanken gibt.

Der Moment vor dem ersten Prompt

Repo angelegt. Prompts geschrieben. SPEC steht. Flow steht.

Und so langsam juckt es mich in den Fingern, den ersten Prompt ins Chatfenster zu posten.

„Das könnte funktionieren. Kann man so machen. Und wird hoffentlich nicht scheiße.“

Warum ich meine Mitarbeiter‑Verwaltung nicht „vibe‑coded“, sondern systematisch mit VIPe gebaut habe

Infobox: VIBE‑Coding vs. VIPe

Einleitung

Es gibt diese Tage, an denen das Internet kollektiv beschließt, dass jetzt der Wendepunkt erreicht ist. Neulich war wieder so einer. Plötzlich sprach alle Welt von VIBE‑Coding – dieser Idee, dass man nicht mehr wirklich programmiert, sondern in einem techno‑spirituellen Flow‑State durch Prompts schwebt, während die KI den Rest erledigt.

Und wie immer, wenn die Tech‑Szene in Euphorie verfällt, taucht sofort die Gegenbewegung auf:

• Die Angst, dass „wir Entwickler“ bald nur noch nostalgische Fußnoten in einem Gartner‑Report sind.
• Die Angst, dass die KI uns ersetzt.
• Die Angst, dass wir irgendwann nur noch die Menschen sind, die den Stecker ziehen dürfen, wenn das Modell hängt.

Ich wollte wissen, was davon Substanz hat – und was nur die übliche Endzeit‑Romantik unserer Branche ist.

Also habe ich mir ein Projekt geschnappt, das so klassisch ist, dass es schon fast ironisch wirkt: eine Mitarbeiter‑Verwaltung. Der „Hello‑World“-Roman unter den Business‑Applikationen. Der Brot‑und‑Butter‑Use‑Case, den jeder Entwicklerin mindestens einmal gebaut hat, meistens unter Zeitdruck, selten mit Freude.

Ich habe ein Repository angelegt: 👉 https://github.com/blame76/a-vipe-coding-poc/ Und mir gesagt: Wenn KI wirklich so weit ist, dann sollte sie das hier mit links schaffen.

Warum ich nicht VIBE‑coded habe – sondern VIPe angewendet

Statt mich in einen esoterischen Prompt‑Flow zu werfen, habe ich mich für etwas entschieden, das sich eher nach Handwerk anfühlt – und das ich inzwischen als VIPe definiert ist:

• Vibe‑Inspired Prompt Engineering
• ein strukturierter, dokumentierter, iterativer Prozess
• der kreative Visionen in reproduzierbare Prompt‑Architekturen übersetzt

Also kein Hokuspokus. Keine Magie. Nur Struktur, Klarheit und ein bisschen Vertrauen in die Maschine.

Ich habe mich bewusst gegen den „Euphorie‑Modus“ entschieden und stattdessen:

• eine SPEC‑Datei geschrieben
• 15 Prompts definiert
• einen klaren VIPe‑Zyklus angewendet

Jeder Prompt baut auf dem vorherigen auf. Jede Iteration ist nachvollziehbar. Und jeder Schritt wird dokumentiert – nicht, um die KI zu beeindrucken, sondern um mich selbst nicht zu verlieren.

Warum VIPe besser funktioniert als VIBE‑Coding

VIBE‑Coding lebt vom Moment. VIPe lebt von der Struktur.

VIBE‑Coding ist ein Gefühl. VIPe ist ein Prozess.

VIBE‑Coding ist ein Flow‑State. VIPe ist ein Framework.

Und genau deshalb eignet sich VIPe für echte Projekte – nicht nur für Demo‑Tweets.

Was ich dokumentiere

Ich werde jeden Schritt festhalten:

• Jeder Prompt bekommt seinen eigenen Blogpost.
• Jede Iteration wird sichtbar.
• Jede Abweichung wird erklärt.
• Und am Ende gibt es ein Fazit – egal, ob das Ergebnis beeindruckend, ernüchternd oder einfach nur… interessant wird.

Vielleicht wird es ein Beweis dafür, dass KI uns nicht ersetzt, sondern uns zwingt, bessere Fragen zu stellen. Vielleicht wird es ein Beweis dafür, dass wir längst in einer Crichton‑Novelle leben, in der die Systeme schneller wachsen als unser Verständnis. Oder vielleicht wird es einfach ein Projekt, das Spaß macht.

Wie auch immer: Los geht’s.