Oder: Der Moment, in dem man merkt, wie viel Naming‑Pain einem ein LLM erspart
Das Beste an diesem Prozess? Wer selbst schon einmal Code geschrieben hat – Zeile für Zeile, ohne Copy & Paste von StackOverflow – kennt diesen Moment:
„Wie nenne ich diese Funktion? Diese Variable? Diesen Endpoint? So, dass Kolleg:innen verstehen, was ich wollte, was ich gemacht habe, welche Akzeptanzkriterien ich im Kopf hatte?“
Dieser ganze Naming‑Pain fällt hier einfach weg.
Okay, das eine oder andere musste ich in der SPEC.md festnageln. Aber das bedeutet: einmal den Kopf rauchen lassen – und dann ab dafür. Der Rest ist Fließband.
Prompt 7 – Skills, Evidence, Graph Endpoint
Der Auftrag war klar:
Implementiere gemäß SPEC.md:
Skills
POST /employees/{id}/skillsPATCH /employees/{id}/skills/{skillId}
Evidence
POST /employees/{id}/evidence
Graph Endpoint
GET /employees/{id}/graph- Aggregierter DTO: Employee + Skills + Evidence
- JSON‑Ausgabe (noch ohne JSON‑LD)
Validierung
- PSR‑7 Request
- Symfony Validator
- Fehlerformat: RFC7807 Problem Details
Logging
- App‑Log für alle Requests
- Audit‑Log für alle Write‑Operationen
Kein JSON‑LD in diesem Schritt. Keine Extras. Nur SPEC.
Codex legt los
Und wie immer beginnt alles mit dem Murmeltier‑Prompt:
„Lies die SPEC.md vollständig. Du implementierst das Projekt strikt nach dieser Spezifikation. Du darfst keine eigenen Patterns, Libraries oder Strukturen erfinden…“
Dann geht’s los. Und der Codex‑Log liest sich wie eine Mischung aus To‑Do‑Liste und innerem Monolog eines sehr gewissenhaften Juniors:
- Starting repository inspection
- Planning dependency management
- Implementing API entrypoints
- Adding secure session cookie parameters
- Implementing repo mapping
- Validating PHP syntax
- Preparing commit with spec checks
Nichts Magisches. Aber sehr zuverlässig.
Was tatsächlich umgesetzt wurde
Neue Endpunkte
Verdrahtet in FastRoute:
POST /api/v1/employees/{id}/skillsPATCH /api/v1/employees/{id}/skills/{skillId}POST /api/v1/employees/{id}/evidenceGET /api/v1/employees/{id}/graph
Controller‑Logik
- Skill‑Erstellung inkl. XOR‑Constraint: genau eins von
skill_idodercustom_label - Skill‑Update
- Evidence‑Erstellung
- Graph‑Aggregation: Employee + Skills + Evidence als JSON
Validierung
- Symfony Validator integriert
- RequestValidator ergänzt
- RFC7807‑konforme Fehler‑Responses (
application/problem+json)
Audit‑Logging
- Zentral über
AuditWriter - Für alle neuen Write‑Operationen angebunden
- Auch Employee‑Writes profitieren davon
Repository‑Erweiterungen
employee_skill,evidence,skill,audit_logkonkret implementiertbyEmployeeId‑Methoden ergänzt, damit der Graph‑Endpoint aggregieren kann
Bootstrap‑Erweiterungen
- Validator
- Neue Repositories
- AuditWriter
- OpenAPI aktualisiert
symfony/validatorals Dependency ergänzt
Testing
Composer
⚠️ composer install scheitert wie immer an der Umgebung (Tunnel‑Fehler, 403).
PHP‑Syntax
Alles grün:
php -l app/Http/Controller/SkillEvidenceGraphController.php &&
php -l app/Http/Controller/EmployeeApiController.php &&
php -l app/Http/Request/RequestValidator.php &&
php -l public/api.php &&
php -l app/Infrastructure/Persistence/RepositoryDb/EmployeeSkillRepositoryDb.php &&
php -l app/Infrastructure/Persistence/RepositoryDb/EvidenceRepositoryDb.php &&
php -l app/Infrastructure/Persistence/RepositoryDb/AuditLogRepositoryDb.php &&
php -l app/Infrastructure/Persistence/RepositoryDb/SkillRepositoryDb.php &&
php -l app/Http/bootstrap.php &&
php -l app/Http/Response/JsonResponseFactory.phpCommit erstellt, PR angelegt.
Fazit
Prompt 7 ist einer dieser Schritte, die man im klassischen Coding gerne vor sich herschiebt, weil sie viel Kleinkram enthalten: Validierung, Aggregation, Repositories, Logging, Fehlerformate.
Im VIPe‑Prozess ist es einfach ein weiterer Baustein. Ein klarer Schritt. Ein definierter Output.
Und genau das macht diesen Workflow so angenehm: Kein Naming‑Pain. Keine Architektur‑Diskussionen. Keine spontanen „Ich mach das mal anders“-Momente.
Nur SPEC → Prompt → Output.
Weiter geht’s. Prompt 8 wartet.