Case Study: Wie planni mit Claude Code schneller und zuverlässiger entwickelt

Das Projekt in Kürze

Die Agile Heroes GmbH setzte das Projekt gemeinsam mit der planni GmbH um. Der Projektzeitraum lief vom 2. März bis zum 22. Mai 2026. Die Ergebnisse wurden vom 15. Juni bis zum 15. September 2026 gemessen. Das Projekt ist abgeschlossen und wurde an das Kundenteam übergeben.

Problemstellung Wenn KI zusätzliche Reviewarbeit erzeugt

planni entwickelt eine Software für die Seminar- und Weiterbildungsverwaltung im deutschen und österreichischen Markt. Jeder Mandant hat eine eigene Datenbank. Dahinter steckt ein gewachsenes Produkt: rund 1,7 Millionen Zeilen handgeschriebener Code, verteilt auf neun Frontend- und Satellitenanwendungen und zwanzig fachliche Backend-Domänen. Betreut wird all das von vier Entwicklern, drei davon in Vollzeit.

Anfang 2026 wurde klar, dass dieses Verhältnis das weitere Wachstum bremst. KI war zwar schon im Einsatz, aber jeder nutzte sie anders. Zwei Entwickler arbeiteten täglich damit, die anderen nur gelegentlich. Entsprechend unterschiedlich fielen die Ergebnisse aus. Woran das lag, war schwer zu sagen: Viele Regeln steckten nur in den Köpfen des Teams oder in einem Wiki, das im Arbeitsalltag kaum jemand öffnete.

Gleichzeitig lief fast jede größere Änderung über den CTO. Nur er konnte zuverlässig beurteilen, ob eine Lösung zur Architektur passte. Spezifikationen landeten als Kommentar in einem Ticket und waren zwei Wochen später kaum noch zu finden. Bei neuen Codezeilen wurden gerade einmal 41 Prozent Testabdeckung verbindlich geprüft. Und freitags wurde vorsichtshalber gar nicht ausgeliefert.

Zwei von vier Entwicklern waren deshalb bei größeren Umbauten schon wieder dazu übergegangen, den Code komplett von Hand zu schreiben. Genau an diesem Punkt verlieren viele Teams das Vertrauen in KI-Unterstützung.

‍

‍

KI-Nutzung war Privatsache

Zwei Entwickler nutzten KI jeden Tag, die anderen nur ab und zu. Jeder hatte seine eigene Arbeitsweise. Es gab weder ein gemeinsames Vorgehen noch feste Budgets. Am Monatsende blieb eine Sammelrechnung, die sich keiner konkreten Aufgabe zuordnen ließ.

Wissen war mündlich

Die wichtigsten Regeln steckten in den Köpfen einzelner Kollegen oder in einem Wiki, das im Alltag kaum jemand nutzte. Allein auf die Frage nach dem Umgang mit Zeitzonen bekam das Team innerhalb eines Quartals drei leicht unterschiedliche Antworten.

Der CTO war der Flaschenhals

Sobald eine Änderung etwas anspruchsvoller wurde, musste sie über den Schreibtisch des CTO. Nur dort konnte jemand sicher sagen, ob die Lösung zur Architektur passte. Trotzdem blieb die Reviewschlange abends oft voll. Freitags wurde deshalb vorsichtshalber gar nicht deployt.

Die Lösung: Ein Agentensystem für Code und Code Reviews

Wir haben ein Agentensystem aufgebaut, das nicht nur Code, sondern auch Code-Reviews automatisiert abbilden konnte.

Fünf Stufen, die jede Anforderung durchläuft

Früher wurde aus einer Idee oft sofort Code. Heute geht jede Anforderung Schritt für Schritt durch fünf klar verständliche Stationen. Weiter geht es erst, wenn eine konkret benannte Person die vorherige Station freigegeben hat.

1. Das Ziel klären: Das Team hält auf einer Seite fest, welches Problem gelöst werden soll und was bewusst nicht dazugehört. So verstehen alle dasselbe unter der Aufgabe.

2. Die Lösung abstimmen: Bevor etwas gebaut wird, beschreibt das Team den geplanten Weg. Ein Kollege prüft ihn und gibt ihn namentlich frei.

3. Die Lösung umsetzen: Erst jetzt beginnt die eigentliche Umsetzung. Gebaut wird nach dem abgestimmten Plan. Abweichungen müssen verständlich begründet werden.

4. Im Alltag prüfen: Die fertige Lösung läuft für eine festgelegte Zeit im echten Kundenbetrieb. Das Team beobachtet, ob sie zuverlässig funktioniert.

5. Sauber abschließen: Erst wenn die Lösung sich im Alltag bewährt hat, gilt die Aufgabe als erledigt. Eingebaut heißt also noch nicht automatisch fertig.

Die Agenten im Detail

Die Agenten sind kein zusätzliches Werkzeug, das irgendwo nebenher läuft. Ihre Regeln liegen direkt beim Code und werden gemeinsam mit ihm versioniert. Wenn jemand etwas ändert oder abschaltet, ist das für das Team sofort sichtbar. Im Folgenden zeigen wir die einzelnen Bausteine etwas genauer.

Ablauf: Der aktuelle Stand ist für alle sofort sichtbar

Jede Anforderung liegt als Datei direkt neben dem Code. Dort steht auch, in welcher der fünf Stufen sie sich gerade befindet und wer die vorherige Stufe freigegeben hat. Wer den Code prüft, sieht also sofort den vollständigen Stand. Ein zweites System, das zusätzlich gepflegt werden müsste und schnell veraltet, braucht das Team nicht.

Technisch: In der versionierten Datei gibt es das Feld "phase". Dafür sind genau fünf Werte erlaubt: layer1, layer2, build, soak und closed. Diese Vorgabe ist in Claude Code hinterlegt. Der aktuelle Prozessstand ist dadurch Teil jedes Pull Requests und wird automatisch mitgeprüft.

CLAUDE.md - Jeder Bereich bekommt seine eigenen Regeln

Eine einzige riesige Regelsammlung wäre schnell unübersichtlich geworden. Deshalb hat jeder Bereich seine eigenen Vorgaben. Arbeitet der Agent zum Beispiel am Rechnungsmodul, bekommt er automatisch die Rechnungsregeln. Bei der Infrastruktur gelten andere. Der Entwickler muss dafür nichts auswählen und auch keinen Prompt umschreiben.

Technisch: Es gibt eine zentrale CLAUDE.md für das gesamte Projekt und neun weitere Dateien für einzelne Bereiche. Claude Code lädt automatisch die passenden Regeln, sobald der Agent im jeweiligen Bereich arbeitet.

Skills und Commands: Wiederkehrende Fragen werden zu festen Regeln

Früher fragte jemand im Teamchat: „Wie gehen wir hier eigentlich mit Zeitzonen um?“ Darauf kamen schon mal drei verschiedene Antworten. Heute kennt der Agent die vereinbarte Regel und wendet sie von selbst an. Auch wiederkehrende Handgriffe, etwa ein Release oder eine Datenmigration, startet das Team inzwischen mit einem einzigen Kommando.

Technisch: Im Repository liegen 34 Claude Code Skills mit jeweils eigener Beschreibung. 22 davon hat planni selbst entwickelt. Externe Skills sind auf eine feste Version gesetzt, damit ein späteres Update nicht unbemerkt die Regeln verändert. Hinzu kommen 18 Slash Commands für wiederkehrende Abläufe.

Hooks: Fehler werden gestoppt, bevor sie teuer werden

Während der Arbeit laufen sechs automatische Prüfungen mit. Drei davon geben nicht nur einen Hinweis, sondern stoppen die Änderung sofort. Das passiert bei zu großen Änderungspaketen, bei fehlenden Tests für neue Codezeilen und bei einer unvollständigen Übergabe am Ende einer Sitzung. So beginnt der nächste Lauf nicht wieder bei null und teure Nacharbeit entsteht gar nicht erst.

Technisch: Die sechs Hooks greifen bei PreToolUse, PostToolUse, Stop und PreCompact. Muss die Arbeit wirklich angehalten werden, geschieht das über Exit-Code 2 oder eine Block-Entscheidung im zurückgegebenen JSON.

Leitplanken: Aus guten Vorsätzen werden verbindliche Leitplanken

Drei Regeln sind besonders wichtig. Datenbankzugriffe müssen erstens über einen geprüften Weg laufen. Zweitens wird jede schreibende Änderung im selben Arbeitsschritt weitergemeldet, damit unterwegs nichts verloren geht. Und drittens braucht neuer Code eigene Tests. Gemessen werden dabei genau die neuen Zeilen, nicht ein Gesamtwert, den alter Code besser aussehen lässt. Da jeder planni-Kunde eine eigene Datenbank hat, sind Abfragen über Kundengrenzen hinweg grundsätzlich nicht erlaubt.

Technisch: Roh-SQL läuft über eine typisierte Schnittstelle und nicht als freiformulierter Query-String. Events werden in derselben Transaktion über die Outbox-Tabelle geschrieben, statt sie ungesichert an Redis zu senden. Die CI misst außerdem die Testabdeckung jeder Änderung. Durchgesetzt werden diese Regeln von Hooks und CI, nicht von einem Wiki.

‍

‍

Modelle und Budget: Nicht jede Aufgabe braucht das stärkste Modell

Für Architekturfragen und große Umbauten nutzt das Team Opus. Sonnet übernimmt die tägliche Entwicklungsarbeit. Haiku kümmert sich um häufige Routineaufgaben wie Testgerüste, Changelogs oder die erste Sichtung von Tickets. Für jeden Entwickler und jede Aufgabenart gibt es ein eigenes Monatsbudget. Dadurch ist heute nachvollziehbar, was eine einzelne Aufgabe an KI-Kosten verursacht.

Technisch: Claude Code greift über ein selbst betriebenes Lite LLM-Gateway auf die Claude API zu. Virtuelle Schlüssel trennen Entwickler und Aufgabenklassen voneinander. Zu Beginn liefen Opus 4.x, Sonnet 4.6 und Haiku 4.5. Inzwischen nutzt das Team mit derselben Konfiguration Opus 5 und Sonnet 5, ohne dafür Prompts oder Skills neu schreiben zu müssen.

MCP: Der Agent kennt auch Tickets, Dokumentation und Kundendaten

Der Agent kann nicht nur den Code sehen, sondern auch das Ticketsystem, die interne Dokumentation und das CRM. Sobald ein Ticket freigegeben ist, übernimmt ein Dienst auf dem Rechner eines Entwicklers die Aufgabe. Er bearbeitet sie und liefert das Ergebnis als fertigen Änderungsvorschlag zurück. Auch der Ticketstatus wird automatisch aktualisiert. Gesteuert wird alles aus dem Ticketsystem, während die eigentliche Arbeit auf den Rechnern des Teams bleibt.

Technisch: MCP-Server verbinden Claude Code mit Ticketsystem, interner Dokumentation und CRM. Ein Webhook aus dem Ticketsystem stößt eine Lambda-Funktion an. Danach startet ein Dienst auf dem Entwicklerrechner Claude Code lokal. Das Ergebnis kommt als Pull Request zurück.

Der Projektplan: In zwölf Wochen vom Ist-Zustand zum Teamstandard

In zwölf Wochen haben wir das System gemeinsam mit dem Team aufgebaut, erprobt und in den Alltag überführt. Der laufende Betrieb ging währenddessen ganz normal weiter.

Woche 1 bis 2 - 02.03. bis 13.03.2026 - Ist-Analyse

Am Anfang haben wir bewusst noch nichts gebaut. Stattdessen sprachen wir mit allen vier Entwicklern und sahen uns die letzten 200 Änderungen am Produkt an. Gemeinsam hielten wir fest, wie lange typische Aufgaben dauerten, wo Arbeit liegen blieb und welche Fehler immer wieder auftauchten. So entstand ein ehrliches Bild des Entwicklungsalltags bei planni und eine belastbare Grundlage für alle weiteren Schritte.

Woche 3 bis 4 - 16.03. bis 27.03.2026 - Entwicklung eines Agenten-Umsetzungsplans

Aus den Erkenntnissen der ersten beiden Wochen entwickelten wir einen konkreten Umsetzungsplan. Darin stand, welche Regeln der Agent kennen musste, welche Aufgaben er übernehmen durfte und wo weiterhin ein Mensch entschied. Wir legten außerdem fest, an welchen Stellen das System eine Arbeit automatisch stoppen sollte. Auch der fünfstufige Ablauf für neue Anforderungen entstand in dieser Phase. Bevor die Umsetzung begann, stimmte das gesamte Team dem Plan zu.

Woche 5 bis 8 - 30.03. bis 24.04.2026 - Training der Agenten

Jetzt bekam das System das Wissen, das es für die Arbeit bei planni brauchte. Wir überführten die bisher mündlichen Regeln und die Inhalte aus dem Wiki in eine zentrale Grundlage und neun bereichsspezifische Dateien. Daraus entstanden 34 Regelbausteine, 18 aufrufbare Abläufe und sechs automatische Prüfungen. Vereinfacht gesagt lernten die Agenten in dieser Phase, welche Regeln bei planni gelten und wann sie welches Wissen anwenden müssen. Die Claude-Modelle selbst wurden dabei nicht verändert.

Woche 9 bis 11 - 27.04. bis 15.05.2026 - Training der Entwicklung und Übergabe in den Betrieb

Das Entwicklerteam lernte das neue System nicht in einer Präsentation kennen, sondern direkt an echten Tickets. Wir arbeiteten so lange gemeinsam, bis jeder die Abläufe sicher beherrschte. Für jeden Bereich benannte planni einen Ansprechpartner, der die Regeln künftig pflegt. Ergänzend entstand ein Betriebshandbuch für alle Aufgaben, die das Team später allein übernehmen sollte. Zum Abschluss prüften wir die Ergebnisse gemeinsam anhand der Werte aus der Ist-Analyse.

Woche 12 und danach - ab 18.05.2026 - Phase Testing und Support

In der letzten Woche arbeitete das Team bereits vollständig im Normalbetrieb. Wir beobachteten die Abläufe, beantworteten Fragen und besserten dort nach, wo es noch hakte. Am 05.06.2026 erhielt planni den Abschlussbericht. Seitdem betreibt das Team das System selbstständig und greift nur bei Bedarf auf unseren Support zurück.

Die Ergebnisse - Vorher und nachher

Die folgenden Werte vergleichen die Baseline aus Februar 2026 mit dem Messfenster vom 15. Juni bis 15. August 2026.

Tempo und Qualität

Durchlaufzeitvon der Spezifikation bis zur Produktion: von 19 Arbeitstagen auf 6 Arbeitstage (−68 %).

Menschliche Reviewzeit je Pull Request: von 42 Minuten auf 11 Minuten (−74 %).

Produktionsfehler je Release: von 3,4 auf 0,7 (−79 %).

Erzwungene Testabdeckung neuer Zeilen: von 41 Prozent, empfehlend auf 85 Prozent, blockierend (+44 Prozentpunkte).

Testdateien im Repository: von 611 Dateien auf 1.502 Dateien (+146 %).

Laufzeitder CI-Pipeline: von 22 Minuten auf unter 8 Minuten (−64 %).

Deploy-Fenster: von Montag bis Donnerstag auf Montag bis Freitag (jeder Werktag).

Architektur und Kosten

Backend-Laufzeit je Mandant: von 22 Services auf 3 Anwendungen und 1 Task (−86 %).

Durchschnittliche Entwicklungskosten je ausgeliefertem Feature: von 9.600 Euro beziehungsweise 12 Personentage auf 3.200 Euro beziehungsweise 4 Personentage (−67 %).

Infrastrukturkosten je Kunde und Monat: von 44 Euro auf 23 Euro (−48%).

Ungeprüfte Raw-SQL-Stellen im Review-Pfad: von rund 400 auf 0 (−100 %).

Offene Findings aus dem Sicherheitsaudit: von 24 auf 0 (−100 %).

KI-Kosten je abgeschlossenem Ticket: von 31 Euro, nicht zuordenbar auf 18 Euro, je Aufgabe sichtbar (−43 %).

Zur Einordnung der Feature-Kosten wurde mit 800 Euro Vollkosten je Entwicklertag gerechnet. Vorher lag ein durchschnittliches Feature bei rund zwölf Personentagen, heute bei vier. Die Durchlaufzeit von 19 auf 6 Arbeitstage enthält zusätzlich Wartezeiten; die Personentage bilden die tatsächlich aufgewendete Arbeit ab.

Verbreitung im Team

Entwickler mit täglicher Claude-Code-Nutzung: von 2 von 4 auf 4 von 4 (Teamstandard).

Anforderungen im Stufenprozess: von 0 auf 54, davon 15 abgeschlossen (etabliert).

Ausführbare Hausregeln im Repository: von 0 auf 34 Skills, 18 Commands und 6 Hooks (automatisiert).

Kontextdateien je Bereich: von 1 Wurzeldatei auf 10 Dateien (bereichsspezifisch).

Erster Produktionschange neuer Entwickler: von 18 Arbeitstage auf 2 Arbeitstage (16 Tage schneller).

Commits mit Claude als Co-Autor im Messfenster: von nicht erhoben auf 634 (neuer Messwert).

Ein typischer Arbeitstag vor und nach dem Claude Projekt

Zahlen zeigen viel, aber nicht alles. Deshalb vergleichen wir hier zwei ganz normale Arbeitstage, vor dem Claude Projekt und danach.

Vor dem Claude Projekt: Dienstag, 10. Februar 2026

08:00 Uhr: Der CTO startet mit sieben offenen Reviews in den Tag. Fünf davon liegen schon seit gestern da. Bei drei Änderungen kann nur er beurteilen, ob sie zur Architektur passen. Der Grund ist einfach: Die entscheidenden Architekturregeln sind nirgends verlässlich festgehalten.

10:20 Uhr: Ein Entwickler fragt im Teamchat, wie das Projekt mit Zeitzonen umgeht. Vierzig Minuten später kommt eine Antwort. Es ist bereits die dritte leicht andere Variante innerhalb eines Quartals.

14:00 Uhr: Eine Entwicklerin lässt Claude bei einem größeren Umbau helfen. Der Code läuft und sieht sauber aus. Trotzdem verletzter eine interne Konvention, die nie jemand aufgeschrieben hat. Das anschließende Review dauert länger als der Umbau selbst. Sie nimmt sich vor, es beim nächsten Mal wieder von Hand zu machen.

16:30 Uhr: Das Team trifft eine Entscheidung zur Rechnungsversionierung. Festgehalten wird sie in einem Kommentar unter einem Ticket. Ein halbes Jahr später wird sie dort niemand mehr finden.

18:30 Uhr: Feierabend ist eigentlich längst fällig, doch die Reviewschlange ist noch immer nicht leer. Das kommt häufig vor. Freitags wird deshalb gar nicht erst deployt.

Nach dem Claude Projekt: Dienstag, 11. August 2026, im Messfenster

08:00 Uhr: Heute warten nur zwei Reviews auf den CTO. In beiden geht es um Entscheidungen, für die seine Erfahrung wirklich gebraucht wird. Formale Dinge wie die Größe einer Änderung, fehlende Tests, Sicherheitsvorgaben oder der Umgang mit Zeitzonen hat das System bereits während des Schreibens geprüft.

10:20 Uhr: Die Zeitzonenfrage taucht im Teamchat nicht mehr auf. Die Regel ist im Projekt hinterlegt und wird vom Agenten automatisch angewendet. Wer davon abweichen möchte, muss den Grund direkt im Code dokumentieren.

14:00 Uhr: Dieselbe Entwicklerin hält zuerst das Ziel fest. Danach beschreibt sie die geplante Lösung und lässt sie von einem benannten Kollegen freigeben. Erst dann setzt sie den Umbau gemeinsam mit dem Agenten um. Was im Februar noch drei Tage Nacharbeit verursacht hätte, ist heute am selben Tag erledigt.

16:30 Uhr: Die Entscheidung zur Rechnungsversionierung liegt als nummerierte Anforderung vor. Datum, Prozessstufe, Freigabe und Bewährungszeit sind sauber dokumentiert. Selbst sieben Monate später kann jeder nachvollziehen, warum diese Lösung gewählt und welche Alternative verworfen wurde.

17:00 Uhr: Die Reviewschlange ist leer. Deployt wird inzwischen an jedem Werktag. Ein neuer Entwickler, der erst in der vergangenen Woche angefangen hat, konnte bereits an seinem zweiten Tag eine Änderung ausliefern. Er musste die Hausregeln nicht erst mühsam zusammensuchen, denn das System wendet sie direkt an.

Der Nutzen für planni heute

KI-Nutzung ist Teamstandard

Heute arbeiten alle vier Entwickler täglich mit dem System. Für jede Aufgabe wird das passende Modell genutzt, die Budgets sind klar festgelegt und die Kosten lassen sich einzelnen Aufgaben zuordnen. Neue Kollegen finden dadurch vom ersten Tag an dieselben Arbeitsbedingungen vor wie der Rest des Teams.

Wissen ist ausführbar

Die Hausregeln stehen nicht länger nur in einem Wiki. Sie greifen genau dann, wenn der Code entsteht. Im Team gilt inzwischen ein einfacher Maßstab: Kann der Agent eine Regel nicht eindeutig anwenden, ist sie noch nicht klar genug formuliert.

Der CTO ist wieder Architekt

Der CTO muss nicht mehr jede Kleinigkeit prüfen. Seine Zeit fließt wieder in die Architektur und in Entscheidungen, bei denen seine Erfahrung zählt. Am Abend ist die Reviewschlange leer, und auch freitags kann das Team ohne Bauchschmerzen ausliefern.

Stimme des Kunden zum Projekt:

Codeschreiben war nicht unser Constraint. Qualitativen Code zum Kunden zu liefern, war es. Agile Heroes hat uns hier ein System gebaut, das auf mehreren Dimensionen unsere Code-Qualität und unseren Outcome dermaßen geschärft hat,dass wir als Softwarefirma mit einem kleinen Team großen Konzernen echte Konkurrenz machen können.

Frank Montermann, Senior Software Engineer, planni GmbH

Fazit: KI wird dann wertvoll, wenn Regeln ausführbar werden

Der Fall planni zeigt, dass der größte Hebel nicht in einzelnen Prompts liegt. Entscheidend ist ein gemeinsames System, das Wissen dort verfügbar macht, wo gearbeitet wird, und wichtige Regeln automatisch durchsetzt.

So bleibt der Mensch bei Architektur- und Freigabeentscheidungen verantwortlich, während Claude Code wiederkehrende Prüfungen, Kontext und Routinen übernimmt. Das Ergebnis sind kürzere Durchlaufzeiten, weniger Reviewaufwand und eine höhere Qualität neuer Codezeilen.

Wer KI im Entwicklungsteam nachhaltig einführen will, sollte deshalb nicht mit dem stärksten Modell beginnen, sondern mit klaren Regeln, messbaren Ausgangswerten und einem nachvollziehbaren Prozess.

Du möchtest KI nicht nur punktuell einsetzen, sondern als Prozess in deinem Unternehmen verankern, der messbaren Mehrwert erzeugt? Erfahre mehr über die KI-Beratung der Agile Heroes.