Zum Inhalt springen
Jonas Fackelmeyer

Der Agent schreibt. Ich prüfe.

Ich schreibe Spezifikationen, steuere Coding-Agents wie Claude Code und sichere die Ergebnisse über automatisierte Tests, Reviews und Quality Gates ab. Der Agent liefert Tempo, die Verantwortung für jede Zeile bleibt bei mir.

Review-Fall ansehen
auth/session.tsAgent → Review: Jonas
  1. export async function getSession(req) {
  2. + const token = req.query.token ?? req.cookies.sid;
  3. Review: Token aus der URL landet in Logs und Referrern. Nur das Cookie zulassen, Test ergänzen.
  4. return verify(token);

Vereinfachtes Beispiel

Der Agent
Code vorschlagen
Jonas
Prüfen und freigeben

Prozess

Vom Plan bis zur Freigabe: Jeder Schritt hat eine klare Aufgabe.

  1. Spezifikation und Plan zuerst

    Bevor ein Agent Code schreibt, steht fest, was gebaut wird und woran ich das Ergebnis messe.

  2. Projektregeln statt Prompt-Glück

    CLAUDE.md und eigene Skills halten Konventionen, Befehle und Grenzen fest, damit jede Sitzung gleich startet.

  3. Kleine Diffs, jeder wird gelesen

    Ich übernehme keinen Code, den ich nicht gelesen habe und im Gespräch erklären kann.

  4. Tests als Gate

    Typprüfung, Lint und relevante Tests müssen grün sein, bevor eine Änderung als fertig gilt.

  5. Security-Review als eigener Schritt

    Auth, Injection und Secrets prüfe ich separat, nicht nebenbei im normalen Review.

Grüne Tests. Falscher Server.

Ein Fehler beim Aufbau dieser Website zeigt, warum automatisierte Prüfungen und Sichtprüfung zusammengehören.

Schematischer Vergleich zweier Browserfenster: Die Tests sind in beiden grün. Links verrät eine markierte Entwicklungswerkzeugleiste den Dev-Server auf Port 4321; rechts läuft der fertige Build auf Port 4329.
Illustrative Rekonstruktion: Beide Tests grün. Nur rechts wird der Build geprüft.

  1. Aufgabe

    Browser-Tests für diese Website: Barrierefreiheit (axe), Darstellung auf dem Smartphone, Inhalte ohne JavaScript. Sie sollen gegen den fertigen statischen Build laufen, also gegen genau das, was live geht.

  2. Was der Agent gebaut hat

    Eine Playwright-Konfiguration, die vor den Tests einen Vorschau-Server auf Port 4321 startet und einen dort bereits laufenden Server wiederverwendet. Alle Tests waren grün.

  3. Der Fehler darin

    Auf Port 4321 lief zur selben Zeit der Entwicklungsserver. Die Tests haben ihn wiederverwendet und damit den Entwicklungsstand geprüft statt des Builds. Grün hieß also nur: Der Entwicklungsserver ist in Ordnung.

  4. Wie der Prozess ihn gefunden hat

    Vor „fertig“ gehört bei mir eine Sichtprüfung im Browser dazu. Auf den Screenshots der angeblich gebauten Seite war die Werkzeugleiste des Entwicklungsservers zu sehen, die es im Build nicht gibt. Ein Blick auf den Port bestätigte den Verdacht.

  5. Ergebnis

    Die Tests laufen jetzt auf einem eigenen Port und verwenden nie einen fremden Server wieder; ein Kommentar in der Konfiguration hält den Grund fest. Danach liefen alle Tests erneut gegen den Build. Die Lehre: Grüne Tests beweisen nur etwas, wenn klar ist, was sie geprüft haben.

Grenzen

Daten, Freigaben und Prüfungen sind feste Regeln im Arbeitsablauf.

  • Daten & Secrets

    Gesundheitsdaten und Kundendaten gehen nie an ein KI-Tool. Secrets stehen nur in Umgebungsvariablen, nie im Code, im Repo oder in einem Prompt.

  • Änderungen mit Freigabe

    Der Agent fragt, bevor er eine Produktiv-Abhängigkeit hinzufügt, Lockfiles ändert, CI oder Infrastruktur anfasst, Dateien löscht oder force-pusht.

  • Prüfungen

    Prüfungen werden nie umgangen: kein --no-verify, kein @ts-ignore, keine abgeschaltete Lint-Regel, damit etwas grün wird. Der Agent behebt die Ursache oder fragt.

  • Commits & Pushes

    Commits und Pushes gibt es nur auf meine Anweisung.

  • Mechanische Leitplanken

    Was sich mechanisch prüfen lässt, setzt ein Guard-Hook in meinem Workflow-Plugin durch: Er blockiert umgangene Prüfungen und Secrets und fragt bei allem anderen nach, bevor es passiert.

Wirkung

  • OrthoOS

    OrthoOS: In drei Monaten (07–09/2026) habe ich als Founding Engineer eine mandantenfähige Praxisverwaltungsplattform aufgebaut, von Row-Level Security und MFA über zahnärztliche Abrechnungsformate bis CI/CD.

  • Dieses Portfolio

    Diese Website: vom ersten Entwurf zur zweisprachigen, getesteten Seite an einem Tag. Build-Tests prüfen SEO, strukturierte Daten und Mehrsprachigkeit, dazu kommen Browser-Tests mit axe und Lighthouse-Budgets in der CI.

Der Workflow zum Mitnehmen.

Regeln, Guard-Hook und Codex-Agent als installierbares Claude-Code-Plugin, mit Tests und Beispiel-Durchlauf:

Workflow-Plugin auf GitHub Kontakt aufnehmen
Vereinfachtes Guard-Beispiel
git commit --no-verify

Blockiert

Prüfungen dürfen nicht umgangen werden.

Der Guard erkennt Muster und ist keine Sandbox. Er ersetzt mein Review nicht.