Case Study · SaaS · Agentic Engineering
Ein Betriebssystem für Handwerksbetriebe.
Von Beginn an mit Agentic Engineering entwickelt.
Eine mandantenfähige SaaS-Plattform bündelt Kunden, Aufträge, Angebote, Rechnungen und Baustellendokumentation. Entwickelt mit Coding Agents, gesteuert durch Spezifikationen, Architekturregeln und überprüfbare Qualitätskriterien.
Die Ausgangssituation
Ein Betrieb, fünf Werkzeuge, kein Überblick.
Ein Handwerksbetrieb mit einer Handvoll Leuten organisiert sich selten in einem System. Das Angebot entsteht in Excel, der Auftrag kommt per WhatsApp, die Rechnung geht per E-Mail raus, und die Fotos von der Baustelle liegen auf einem Telefon. Dazwischen Papier und einzelne Programme, die nichts voneinander wissen.
Die Folgen sind unspektakulär und teuer. Dieselben Daten werden mehrfach erfasst. Zwischen den Werkzeugen gehen Informationen verloren. Welche Rechnung noch offen ist und was heute ansteht, weiß im Zweifel nur, wer alles im Kopf hat. Und die Verwaltung frisst die Zeit, die auf der Baustelle fehlt.
Die Aufgabe
Eine Plattform statt fünf Inseln.
Gebaut wird eine zentrale SaaS-Plattform für die kaufmännischen und operativen Abläufe eines Handwerksbetriebs mit einem bis fünfzehn Mitarbeitenden: Kundenverwaltung, Aufträge, Angebote und Rechnungen, offene Posten, Baustellendokumentation und Reporting.
Das Produkt ist mandantenfähig angelegt. Jeder Betrieb arbeitet auf derselben Plattform, und die Daten des einen tauchen beim anderen nicht auf. Diese Trennung ist keine spätere Ausbaustufe, sondern die Grundlage, auf der alles andere steht.
Gleichzeitig muss die Architektur tragen, was noch kommt: Sprachsteuerung, ein Telefonassistent und später agentische Funktionen im Produkt selbst. Sprachmodelle sind bereits angebunden, Gemini und Mistral. Für den Rest wird heute die Grundlage gebaut, nicht die Funktion.
Meine Verantwortung
Architekt, der selbst implementiert.
Das Produkt entsteht in einem vierköpfigen Gründerteam, drei davon entwickeln. Meine Verantwortung liegt in der technischen Architektur und der praktischen Umsetzung. Ich habe es nicht allein gebaut, und diese Seite behauptet das auch nicht.
Architektur. Das technische Fundament der Plattform, einschließlich der Mandantentrennung, und die Regeln, an die sich jede Änderung hält.
Anforderungen strukturieren. Aus fachlichen Wünschen werden Spezifikationen, die ein Agent umsetzen und ein Review daran messen kann.
Umsetzung zentraler Produktbestandteile. Selbst und mit Coding Agents.
Der Agentic-Engineering-Workflow. Wie aus einer Anforderung eine geprüfte Änderung im System wird, und woran eine Änderung scheitert, bevor sie ankommt.
Qualitätskontrolle und Bereitstellung. Die Regeln, gegen die geprüft wird, automatische Prüfungen, ein mehrstufiges Review durch Agenten und eine produktionsnahe Auslieferung.
Mein Ansatz
Erst das Modell.
Dann der Prozess.
Dann das Tempo.
Fachliche Grundlage und Mandantentrennung
Bevor ein Agent eine Zeile schreibt, muss klar sein, was ein Auftrag ist, wann aus einem Angebot eine Rechnung wird und wann ein Posten offen ist. Eine Fachdomäne, die in Excel, Chatverläufen und Köpfen verteilt ist, wird zu einem Produktmodell mit festen Begriffen. Die Mandantentrennung gehört von Anfang an dazu, weil sie sich später nur mit großem Aufwand nachrüsten lässt.
Agentischer Entwicklungsprozess
Der Code entsteht mit Coding Agents. Was sie schreiben, bestimmen Spezifikationen und dokumentierte Architekturregeln, und was davon übernommen wird, bestimmen automatische Prüfungen und ein mehrstufiges Review durch Codex und CodeRabbit. Der Ablauf dahinter steht unten Schritt für Schritt.
Produktionsnahe Plattform und Erweiterbarkeit
Neben der Produktivumgebung steht eine vollständige Staging-Umgebung mit eigener Datenhaltung. Die CI läuft auf eigenen Runnern, ausgeliefert wird in Containern. Refactoring und Betrieb laufen als eigene Arbeitsstränge mit, damit Tempo nicht zu technischen Schulden wird und die Plattform für Sprachsteuerung und KI-Funktionen offen bleibt.
Der eigentliche Kern
Acht Schritte je Aufgabe.
Der Agent ist einer davon.
Anforderung
Was ein Betrieb erledigen will, in seiner Sprache. Ob und wann es gebaut wird, entscheidet ein Mensch. Priorisierung ist Produktarbeit, keine Aufgabe für ein Modell.
Spezifikation
Vor der Implementierung steht fest, was gebaut wird und woran man erkennt, dass es fertig ist. Bei Oberflächen gehören alle Zustände dazu: Liste, leerer Zustand, Detail, Bearbeiten, Erfolg und Fehler. Was nicht spezifiziert ist, erfindet der Agent, und genau das soll er nicht. Wie eine solche Spec-Schicht für Agentic Coding aufgebaut ist, steht im Artikel dazu.
Architekturkontext
Architekturentscheidungen sind dokumentiert und liegen dem Agenten als verbindlicher Kontext vor. Die Mandantentrennung verhandelt er nicht in jeder Aufgabe neu, er setzt sie um. Eine Entscheidung, die nur im Kopf existiert, kennt der Agent nicht.
Abgegrenzte Agentenaufgabe
Eine Aufgabe, ein klarer Schnitt. Der Agent verändert den Teil des Systems, um den es geht, nicht das ganze. Mehrere Aufgaben laufen parallel, jede in einer eigenen Arbeitsumgebung mit eigenem Klon des Repositorys, damit sich zwei Agenten nicht gegenseitig die Arbeit überschreiben.
Implementierung
Hier arbeitet der Agent: Analyse des bestehenden Codes, Implementierung, Tests, Refactoring und Dokumentation. Eingesetzt werden Claude Code, Codex und Grok. Der Agent ist schnell, aber er entscheidet nichts, was nicht in Schritt zwei und drei schon entschieden wurde.
Automatische Prüfung
Tests und Linting laufen in der CI auf eigenen Runnern. Sie sind eine Bedingung für die Übernahme, keine Empfehlung. Scheitert eine Prüfung, geht die Aufgabe zurück an den Agenten, nicht weiter zum Review.
Review
Jede Änderung durchläuft ein mehrstufiges Review durch Codex und CodeRabbit, bevor sie übernommen wird. Die Frage ist nicht mehr, ob sie läuft, das haben die Prüfungen beantwortet. Die Frage ist, ob sie in das System passt, das es in einem Jahr noch geben soll. Findet ein Review etwas, geht die Aufgabe zurück an den Agenten, der sie umgesetzt hat.
Integration
Übernommen wird über Pull Requests, in fünf Monaten mehr als 2.000. Jede Änderung ist damit nachvollziehbar: Anlass, Prüfungen und Review. Ausgeliefert wird über GitHub Actions, mit einer eigenen Staging-Umgebung neben der Produktion.
Der Unterschied
Was das von Vibe Coding trennt.
Keine unkontrollierten Prompts. Der Agent bekommt eine Spezifikation und einen Architekturkontext, keinen Wunsch in einem Satz. Was er bauen soll, steht fest, bevor er anfängt.
Keine Übernahme, weil es lokal läuft. Dass Code auf einem Rechner funktioniert, ist kein Kriterium. Kriterium sind bestandene Prüfungen in der CI und ein bestandenes Review.
Keine Architektur durch Zufall. Ein Agent, der ohne Regeln arbeitet, trifft in jeder Aufgabe eigene Entscheidungen, und nach hundert Aufgaben hat das System hundert Architekturen. Hier trifft sie ein Mensch, einmal, und schreibt sie auf.
Keine Geschwindigkeit ohne Qualitätssicherung. Das Tempo kommt vom Agenten. Die Disziplin kommt vom Prozess, und sie wird nicht verhandelt, wenn es eilt.
Die Aufteilung ist dabei eindeutig. Produktentscheidungen, Architektur, Priorisierung und die Regeln, gegen die geprüft wird, liegen beim Menschen. Die Agenten beschleunigen Analyse, Implementierung, Tests, Refactoring und Dokumentation, und sie prüfen sich gegenseitig: Geschrieben wird mit Claude Code, Codex und Grok, geprüft von der CI und in mehreren Stufen von Codex und CodeRabbit. Wer das in einem bestehenden Team einführen will, findet den Ablauf unter Claude Code einführen, und welche Voraussetzungen eine Codebasis dafür braucht, im Artikel Ist Ihr Code zu alt für Coding-Agenten?
Stand heute
Umgesetzt. In Arbeit. Vision.
Funktionsfähige Plattform
Kundenverwaltung, Aufträge, Angebote und Rechnungen, offene Posten, Baustellendokumentation und Reporting, dazu eine LLM-Integration mit Gemini und Mistral. Die Produktivumgebung ist eingerichtet, die erste Produktwebsite ist live.
Pilotbetrieb
Zehn bis fünfzehn Betriebe haben ihre Teilnahme zugesagt. Produkt, Bedienung und Funktionsbereiche werden für den Pilotbetrieb weiterentwickelt.
Noch nicht gebaut
Sprachsteuerung, ein Telefonassistent, eine offene API schon im kleinsten Tarif und später weitergehende agentische Funktionen. Geplant, nicht produktiv.
Das Ergebnis bis hierher: Aus einer Produktidee ist in fünf Monaten eine funktionsfähige SaaS-Plattform geworden, gebaut von drei Entwicklern über mehr als 2.000 Pull Requests. Eine verzweigte Fachdomäne ist in ein strukturiertes Produktmodell übersetzt. Agentic Engineering war dabei kein Versuch neben der eigentlichen Entwicklung, sondern das Entwicklungsmodell selbst. Die technische Grundlage für den Pilotbetrieb und für weitere KI-Funktionen steht.
Was hier fehlt, fehlt mit Absicht: Einsparungen, Nutzungszahlen oder Zufriedenheitswerte. Die gibt es erst nach dem produktiven Piloteinsatz, und bis dahin steht auf dieser Seite keine.
Eingesetzte Technologien
Ein gewöhnlicher Stack. Ungewöhnlich ist der Ablauf.
- Claude Code
- Codex
- Grok
- CodeRabbit
- Gemini
- Mistral
- Ruby
- Go
- PostgreSQL
- Redis
- Elasticsearch
- Sidekiq
- Git
- GitHub Actions
- Eigene CI-Runner
- Docker
- Staging-Umgebung
Häufig gefragt
Was Auftraggeber vorher wissen wollen.
Ist das nicht einfach Vibe Coding?
Nein. Beim Vibe Coding entscheidet der Prompt, was am Ende im System steht. Hier steht vor jeder Agentenaufgabe eine Spezifikation, der Agent arbeitet gegen dokumentierte Architekturregeln, und übernommen wird nur, was die automatischen Prüfungen und ein mehrstufiges Review durch Codex und CodeRabbit bestanden hat. Dass Code lokal läuft, ist kein Kriterium.
Was entscheidet der Agent, und was entscheide ich?
Produktentscheidungen, Architektur, Priorisierung und die Regeln, gegen die geprüft wird, bleiben beim Menschen. Die Agenten beschleunigen Analyse, Implementierung, Tests, Refactoring und Dokumentation, und sie übernehmen das Review. Sie bekommen abgegrenzte Aufgaben, nicht das ganze System.
Wie schnell ging das?
Von der Produktidee bis zur funktionsfähigen Plattform vergingen fünf Monate. In dieser Zeit sind mehr als 2.000 Pull Requests durch den Ablauf gegangen, von drei Entwicklern, die jeweils mit Coding Agents arbeiten.
Gibt es schon Ergebnisse aus dem Pilotbetrieb?
Noch nicht. Die Plattform ist funktionsfähig, die Produktivumgebung ist eingerichtet, und zehn bis fünfzehn Betriebe haben ihre Teilnahme zugesagt. Belastbare Zahlen zu Einsparungen oder Nutzung gibt es erst nach dem Pilotbetrieb. Bis dahin steht hier keine.
Warum wird das Produkt nicht genannt?
Es ist ein eigenes Vorhaben in einem Gründerteam und steht vor dem Markteintritt. Für diese Seite zählt ohnehin nicht der Produktname, sondern wie es gebaut wird.