Use Cases als Single Source of Truth — Wie Agentic Coding mir geholfen hat, eine SaaS-Plattform zu modernisieren
Anfang des Jahres stand ich vor einer Situation, die vielen Solo-Entwicklern und kleinen Teams bekannt sein dürfte: eine B2B-SaaS-Plattform mit über die Jahre gewachsener Codebasis. Java-Backend, mehrere Frontend-Clients, klassisches PaaS-Hosting. Technische Schulden hatten sich angehäuft. Backend und Frontends lebten in separaten Repositories. Es gab keinen einzigen End-to-End-Test. Jeder Entwickler musste sich seine lokale Umgebung manuell zusammenbauen. Die Infrastruktur war teuer und operativ aufwändig.
Die Modernisierung war überfällig. Aber die Zeit war knapp — das Ganze lief neben einem Kundenprojekt, in Abenden und an Wochenenden. Kein Team, das ich hätte aufteilen können. Kein Quartal, das ich hätte blocken können.
Die Frage war nicht, was modernisiert werden muss — das war klar. Die Frage war: Wie nutzt du knappe Zeit so effektiv, dass am Ende eine solide, getestete, deploybare Plattform steht statt nur ein weiterer halbfertiger Rewrite?
Die Antwort lag nicht in einem Tool. Sie lag in einer Erkenntnis.
Agentic Coding ist nicht "AI schreibt Code"
Wenn die meisten Entwickler an AI-gestütztes Coding denken, denken sie an Autocomplete auf Steroiden. An einen Copiloten, der Boilerplate generiert oder Funktionen vervollständigt. Das ist nützlich, aber es ist nicht der eigentliche Hebel.
Der eigentliche Produktivitätsgewinn von Agentic Coding — also dem Arbeiten mit einem AI-Agent, der eigenständig Dateien liest, Code schreibt, Tests ausführt und Ergebnisse verifiziert — liegt woanders: Es zwingt dich, klar zu formulieren, was du eigentlich bauen willst.
Wenn du einem Agent erklären musst, was er implementieren soll, musst du es selbst verstanden haben. Nicht ungefähr, nicht "das wird sich beim Coden schon zeigen", sondern konkret: Was sind die Vorbedingungen? Was passiert Schritt für Schritt? Was ist das erwartete Ergebnis? Welche Seiteneffekte gibt es — zum Beispiel E-Mail-Benachrichtigungen?
Mein Projekt hatte am Anfang keine Use Cases. Wie in den meisten Projekten lebten die Anforderungen in einem Ticket-Board. Sobald ein Ticket auf "Done" stand, war das Wissen weg — vergraben in einem Backlog, das niemand liest, oder verstreut über Kommentare und Gespräche. Das Erste, was ich getan habe: Use Cases schreiben und ins Repository legen. Nicht in ein Wiki. Nicht in ein Projektmanagement-Tool. In den Quellcode, versioniert, direkt neben dem Code, den sie beschreiben.
Nichts besonders Formales — einfache Markdown-Dokumente mit einer ID, den Schritten und dem erwarteten Ergebnis. Aber sobald sie da waren, wurden sie zum Dreh- und Angelpunkt von allem.
Ein Use Case wie "Aufgabe erstellen" beschreibt: Welche Rolle hat der Nutzer? Was sieht er? Was füllt er aus? Was passiert nach dem Absenden — wird die Aufgabe gespeichert, erscheint sie in der Liste, wird eine Benachrichtigung verschickt? Aus diesem einen Dokument leitet sich alles ab:
- Der Agent bekommt eine Spec, die beschreibt, was gebaut werden soll
- Aus der Spec wird ein Plan mit konkreten Implementierungsschritten
- Der Plan wird zu Code — API-Endpoint, Service-Logik, Frontend-Komponente
- Aus den Schritten und dem erwarteten Ergebnis wird ein E2E-Test
- Der Test verifiziert, dass der Use Case funktioniert
Die Use Cases wurden zur Single Source of Truth. Sie steuern, was der Agent implementiert. Sie definieren, was die Tests verifizieren. Und sie sind die Abnahmekriterien: Ein Feature ist fertig, wenn der E2E-Test grün ist. Nicht wenn der Code kompiliert. Nicht wenn es auf meinem Rechner funktioniert. Wenn der automatisierte Test den gesamten Use Case durchspielt und bestätigt.
Das eliminiert den teuersten Fehler bei Zeitknappheit: anfangen zu bauen, bevor man weiß, was man baut.
Der Workflow: Von der Anforderung zur verifizierten Software
Die Pipeline, die sich daraus ergeben hat:
Use Case → Spec → Plan → Code → E2E-Test → Verifikation
Klingt nach Overhead. Fühlt sich am Anfang auch so an. Aber jede Stunde, die ich in eine Spec investiert habe, hat mir einen Tag Debugging gespart. Die einzelnen Bausteine:
Ein Agent-Briefing statt Prompts. Das Projekt hat eine CLAUDE.md — ein strukturiertes Dokument, das dem Agent alles erklärt, was er braucht: Architektur, Domain-Modell, Konventionen, Verzeichnisstruktur, Dev-Workflow. Kein wiederholtes Erklären in jeder Session. Einmal geschrieben, immer verfügbar. Dazu ein Memory-System, in dem der Agent Learnings, Feedback und Projektkontext zwischen Sessions behält. (→ Deep-Dive: devenv + CLAUDE.md)
Eine reproduzierbare Dev-Umgebung. Ein einziger Befehl — devenv up — startet die Datenbank, das Backend mit Migrationen und Seed-Daten, alle Frontend-Clients und einen Mail-Interceptor. Jeder Start ist identisch. Der Agent kann Tests ausführen und bekommt ein deterministisches Ergebnis. Keine "works on my machine"-Momente. (→ Deep-Dive: devenv + CLAUDE.md)
Specs und Plans vor dem Code. Der Agent schreibt keine Zeile Code, bevor ein Plan steht. Das fühlt sich langsam an — aber es verhindert, dass der Agent in die falsche Richtung läuft und ich es erst zwei Stunden später merke.
E2E-Tests als Beweis. Ein Befehl startet den gesamten Stack und führt alle Tests aus. Jeder Test spielt einen Use Case durch — inklusive Mail-Verifikation über einen lokalen SMTP-Interceptor. Kein manuelles Klicken, kein "ich hab's kurz im Browser getestet". (→ Deep-Dive folgt: Von 0 auf 50+ E2E-Tests.)
Was dabei entstanden ist
Nüchtern aufgelistet, was in diesem Zeitraum passiert ist:
Monorepo-Konsolidierung. Fünf separate Repositories zu einem Monorepo mit pnpm Workspaces zusammengeführt. Ein shared TypeScript-API-Client, generiert aus der OpenAPI-Spec. Eine shared UI-Komponenten-Bibliothek. Atomare Commits: eine API-Änderung im Backend und die Frontend-Anpassung in einem Commit, nicht verteilt über drei Repos.
E2E-Testing von null auf über 50 Tests. Jeder Test hat eine ID, die direkt einem Use Case entspricht. Mail-Verifikation über einen lokalen SMTP-Interceptor — kein echter Mailserver nötig. Ein Befehl startet den Stack und führt die gesamte Suite aus. (→ Deep-Dive folgt: Von 0 auf 50+ E2E-Tests.)
Drei Infrastruktur-Migrationen ohne Downtime. Vom klassischen PaaS über einen Container-Service zum aktuellen Setup. Hosting-Kosten um rund 85 % reduziert. Alles als Infrastructure as Code mit Pulumi in TypeScript, statt handgepflegter CloudFormation-Templates. Dazu Structured Logging und ein Monitoring-Dashboard. (→ Deep-Dive folgt: 3 Cloud-Plattformen in 6 Wochen.)
Neue Clients. Eine Admin-Oberfläche mit React und Vite — Spec morgens geschrieben, am selben Tag ein lauffähiger Client. Ein Rewrite des Legacy-Frontends. Alles im Monorepo mit shared Dependencies.
Developer Experience. Ein Befehl startet den Full Stack. Ein Befehl führt alle E2E-Tests aus. Conventional Commits mit automatischer Changelog-Generierung. Keine Setup-Dokumentation mehr, die nach zwei Wochen veraltet ist.
Was ich gelernt habe
Dokumentation ist kein Overhead — sie ist ein Produktivitätstool. Das Agent-Briefing ist das wertvollste File im Repo. Je besser das Briefing, desto besser der Output. Je schlechter, desto mehr Zeit geht für Korrekturen und Kontext-Nachliefern drauf. Das Gleiche gilt für Use Cases: Je präziser sie formuliert sind, desto weniger Iterationen braucht die Implementierung.
Specs vor Code fühlt sich langsam an, ist aber schneller. Ich musste das schmerzhaft lernen. Zweimal habe ich den Agent ohne Spec losgeschickt, weil "das ja eigentlich klar ist". Beide Male habe ich mehr Zeit mit dem Rückbau verbracht, als die Spec gekostet hätte.
Use Cases gehören ins Repo, nicht ins Ticket-Board. Tickets beschreiben Arbeitspakete. Sie werden auf "Done" gesetzt und verschwinden. Use Cases beschreiben Verhalten — und dieses Verhalten hört nicht auf, relevant zu sein, sobald das Feature ausgeliefert ist. Im Quellcode werden Use Cases zum abstrakten Gehirn des Projekts: lebende Dokumentation, die Implementierung, Tests und künftige Änderungen steuert. Sie sind versioniert, sie entwickeln sich mit dem Code, und sie sind immer da, wenn der Agent — oder du — verstehen muss, was das System tun soll.
AI hat Grenzen. Architekturentscheidungen — welche Hosting-Plattform, wie das Rollen- und Berechtigungssystem funktioniert, wann ein Refactoring nötig ist — bleiben beim Entwickler. Der Agent ist ein Multiplikator für Umsetzungsgeschwindigkeit, kein Ersatz für technisches Urteilsvermögen. Er macht dich schneller in dem, was du bereits kannst. Er macht dich nicht besser in dem, was du noch nicht verstehst.
Für wen das funktioniert
Dieser Ansatz ist kein Allheilmittel. Aber er funktioniert besonders gut in drei Situationen:
- Solo-Entwickler mit eigenem Produkt, die ihre knappe Zeit maximal nutzen müssen
- Kleine Teams mit großem Backlog, die mehr liefern wollen, ohne mehr Leute einzustellen
- Projekte mit technischen Schulden, die neben dem Tagesgeschäft modernisiert werden müssen
Wenn du in einer dieser Situationen steckst und wissen willst, wie du einen Agentic-Coding-Workflow für dein Projekt aufsetzt — von Agent-Briefing über Dev-Environment bis zur E2E-Pipeline — schreib mir.
In den folgenden Wochen veröffentliche ich drei Deep-Dives zu den einzelnen Bausteinen:
- devenv + CLAUDE.md: Ein reproduzierbarer Stack für Agentic Coding
- Von 0 auf 50+ E2E-Tests mit einem Befehl (folgt)
- 3 Cloud-Plattformen in 6 Wochen — Infra-Migration mit AI-Support (folgt)