Faktor 93: Was passiert, wenn ein Architekt eine Enterprise-Anwendung komplett mit KI entwickelt

Dieser Beitrag basiert auf dem Video eines Softwarearchitekten, der über sechs Monate hinweg ein vollständiges Enterprise-System ausschließlich mit KI-Unterstützung entwickelt hat. Das vollständige Video findest du hier:

Videos, in denen Leute innerhalb von Minuten ganze Apps per Sprache zusammenklicken, gibt es inzwischen hunderte auf YouTube. Für die professionelle Softwareentwicklung haben diese Demonstrationen keinen Wert. Wir arbeiten mit großen Infrastrukturen, tausenden von Anforderungen und einem hohen Qualitätsanspruch. Dieses Experiment ist anders. Es zeigt, was passiert, wenn ein erfahrener Architekt eine vollständige Enterprise-Anwendung mit Microservice-Architektur, API-Tests, Workflow-Tests und Dokumentation von Anfang bis Ende mit KI entwickelt.

Das Projekt: Vom 18 Jahre alten Monolithen zur Microservice-Architektur

Die Ausgangslage war eine private Backoffice-Anwendung, die seit 18 Jahren im Einsatz ist. Eine alte .NET-Framework-Anwendung mit veralteter UI-Technologie. Sie deckte nur einen Bruchteil der gewünschten Funktionalität ab. Rechnungen erstellen, Belege verwalten, Kunden pflegen. Alles Weitere fehlte.

Das neue System sollte den 12- bis 15-fachen Funktionsumfang haben und aus vier Hauptkomponenten bestehen. Erstens ein umfangreiches Backoffice mit moderner Oberfläche und automatisiertem E-Mail-Versand. Zweitens eine neue Homepage mit Workshop-Buchung, Newsletter-Anmeldung und Projektanfragen. Drittens eine Customer Area, in der Kunden Termine bestätigen, Angebote freigeben und Rechnungen herunterladen können. Viertens ein KI-Agent namens Hermes, der über lokale KI und MCP-Server den Großteil der Büroarbeit automatisieren soll.

Die Architektur: Microservices, API Gateway, Workflow Engine

Die gewählte Architektur ist bewusst Enterprise-tauglich. 10 Microservices, vorgeschaltet eine API Gateway mit Traefik. Darunter eine Workflow Engine (N8N) für die Orchestrierung von Geschäftsprozessen und Domänenevents. Externe Services wie Office 365, Google und Trello sind angebunden. Die lokale KI läuft auf Alibaba Qwen 3 (36 Milliarden Parameter, Mixture of Experts) und wird über einen MCP-Server mit 108 Tools nach oben angeboten.

Die DevOps-Umgebung besteht aus zwei Entwicklungsmaschinen, einem NAS-System mit Docker, einer Testumgebung und einer Produktionsumgebung. Der Coding Agent hat per SSH Zugriff auf das NAS, kann in der Testumgebung Container starten und Logfiles ziehen. In der Produktionsumgebung ist der Zugriff auf Logfiles beschränkt.

Die fünf Entwicklungsphasen: Vom Micromanagement zur Sprachsteuerung

Phase 1: Micromanagement

Der klassische Einstieg. Ein Prompt, Code generieren, reviewen, iterieren. Kleinteilig, fehleranfällig und mit dem ständigen Problem, dass die KI Architekturansätze ausspuckt, die nicht zur Gesamtanwendung passen. Das ist der Status quo bei den meisten Entwicklern.

Phase 2: Quality Driven

Der entscheidende Schritt. Ein sogenannter Harness wird definiert. Der Harness ist eine Sammlung von Dateien, die dem KI-Modell als Systemprompt übergeben werden. Er beschreibt nicht was implementiert werden soll, sondern wie. Welche Architektur, welche Codierrichtlinien, welche Strukturvorgaben gelten.

Zusätzlich kommen statische Analysetools zum Einsatz. NDepend für die Architekturanalyse mit 880 Regeln und ReSharper für die Codeebene. Nach jeder Codegenerierung prüft die KI automatisch, ob die Änderung im Rahmen der Richtlinien liegt. Abweichungen führen zur Korrektur des Harness. Dieser iterative Prozess nennt sich Harness Correction Development.

Genau dieser Punkt ist der Schlüssel. Ab Claude Opus 4.5 hat sich die Fähigkeit der Modelle, Richtlinien penibel einzuhalten, grundlegend verändert. Vorher wurden Vorgaben bei größeren Projekten irgendwann missachtet. Jetzt hält sich die KI an die Guardrails. Das hat die professionelle Nutzung erst ermöglicht.

Phase 3: Spec Driven

Der Harness bekommt beigebracht, wie Anforderungen in Entwicklungsaufgaben zerlegt werden. Statt einzelner Prompts werden vollständige User Stories mit Akzeptanzkriterien an die KI übergeben. Die KI zerlegt sie, arbeitet sie ab, generiert Quellcode und prüft diesen gegen die Richtlinien. Der Entwickler kontrolliert nicht mehr die Funktionalität im Detail, sondern ob die Anforderung korrekt zerlegt und die Architektur richtig implementiert wurde.

Phase 4: Test Driven

Tests werden direkt aus den Anforderungen und Akzeptanzkriterien abgeleitet, nicht aus dem bestehenden Quellcode. Das ist ein fundamentaler Unterschied. Ein Test, der aus Quellcode generiert wird, testet nur, ob der Code das tut, was er tut. Ein Test, der aus Akzeptanzkriterien generiert wird, verifiziert das spezifizierte Systemverhalten.

Der Harness definiert, wie Tests strukturiert, aufgebaut und ausgeführt werden. API-Tests prüfen die einzelnen Endpoints, die Responses und ob die richtigen Domänenevents auf den Message Bus gelegt werden. Workflow-Tests fahren die gesamte Umgebung mit allen Services hoch und verifizieren die End-to-End-Prozesse. Externe Aufrufe an Office 365 oder Google werden über WireMock abgefangen.

Phase 5: Voice Driven (Idea Driven)

Der Entwickler diktiert Ideen per Sprache. Die KI diskutiert kritisch mit, verweist auf bestehende Module, rechtliche Anforderungen und technische Implikationen. Aus der Diskussion entstehen Anforderungsdokumente, die dann automatisch in Spezifikationen, Tests und Code überführt werden.

Ein konkretes Beispiel: Das größte Modul (Workshop-Planung) wurde in einem vierstündigen Voicechat mit Claude auf der Autofahrt nach Wien durchgesprochen. Die KI kannte das gesamte System, alle Spezifikationen und alle Tests. Die resultierende Diskussion war laut dem Entwickler fachlich auf einem Niveau, das ihn selbst überrascht hat.

Die Ergebnisse in Zahlen

Kennzahl	Wert
User Stories	213
Akzeptanzkriterien	4.083
Microservices	10
API Endpoints	420
MCP Tools	108
Automatisierte E-Mails	135
N8N Workflows	88
Datenbanken / Tabellen	10 / 113
Dokumentation	1.300 Seiten
API Tests	2.900
Workflow Tests	392
Zeilen Code	420.000

Die eigentliche Sensation: Qualität, nicht Geschwindigkeit

Geschwindigkeit bei KI-generiertem Code überrascht niemanden mehr. Die Qualitätszahlen sind das Bemerkenswerte an diesem Experiment.

Die Testabdeckung liegt bei 85 Prozent für Backend und Workflows. Die fehlenden 15 Prozent betreffen ausschließlich Workflows mit externem Trigger (z.B. Outlook), die nicht gemockt wurden. Die strukturellen Schulden liegen bei 0 Prozent. Jede Klasse, jede Methode, jede Datei entspricht exakt den Architekturvorgaben. Die Dokumentation ist vollständig und wird jede Nacht per automatisiertem Build-Task neu generiert, sodass sie immer synchron mit der Implementierung ist.

Im Vergleich: Die zwei Referenzteams aus realen Kundenprojekten haben im Schnitt 13 Prozent strukturelle Schulden, 33 Prozent dokumentierten Code und 60 Prozent Testabdeckung. Die KI-gestützte Entwicklung hat in allen drei Kategorien bessere Ergebnisse geliefert als erfahrene Entwicklungsteams.

Faktor 93: Die Rechnung

Zwei erfahrene Entwicklungsteams haben den Umfang des Projekts geschätzt. Ein Team mit fünf Entwicklern schätzte 23 Personenjahre. Ein Team mit vier Entwicklern schätzte 15 Personenjahre. Claude und Codex schätzten 20 Personenjahre. Die eigene Schätzung des Entwicklers lag bei 18 Personenjahren. Der Mittelwert: 19 Personenjahre, also 4.180 Arbeitstage.

Die tatsächliche Entwicklungszeit mit KI: 45 Arbeitstage, eine Person. Das ergibt Faktor 93.

	Menschliches Team	KI-gestützt
Arbeitstage	4.180	45
Projektkosten	~2.000.000 €	~25.000 €
Strukturelle Schulden	~13%	0%
Dokumentation	~33%	100%
Testabdeckung	~60%	85%

Die Gesamtkosten setzen sich zusammen aus 22.500 Euro Personalkosten (45 Tage à 500 Euro Vollkostensatz) und 1.620 Euro für zwei Claude Max Abonnements über insgesamt neun Monate. Zum Vergleich: Mit den regulären Token-Preisen hätte die KI-Nutzung 21.000 Euro bei Anthropic oder 2.000 Euro bei einem chinesischen Modell wie DeepSeek V4 Pro gekostet.

Was dieser Faktor bedeutet und was nicht

Der Faktor 93 lässt sich diskutieren. Tests und Dokumentation machen einen Teil des Umfangs aus. Die Teamschätzungen basieren auf einer einzigen Begutachtung. Korrigiert man konservativ nach unten, landet man bei Faktor 25. Das wäre immer noch 25 mal schneller als ein menschliches Team, bei gleichzeitig besserer Qualität.

Dazu kommt ein Punkt, den man nicht unterschlagen sollte: Am Ende ist es eine Buchhaltungs- und ERP-Software. Rechnungen, Belege, Kundenverwaltung, Workflows. Diese Domäne existiert hundertfach als Open-Source-Projekt auf GitHub. Jedes einzelne Feature, das hier implementiert wurde, ist für sich genommen keine Neuerfindung. Die Trainingsdaten der aktuellen LLMs sind voll mit genau diesem Typ von Anwendung. Das macht die Leistung nicht weniger beeindruckend, aber es erklärt einen Teil des Faktors. Ob die KI bei einer hochspezialisierten Fachdomäne mit proprietärer Geschäftslogik, für die es kaum Referenzcode gibt, denselben Faktor erreicht hätte, bleibt offen.

Der Faktor ist also nicht direkt auf beliebige Projekte übertragbar. Er zeigt aber eine klare Richtung: KI-gestützte Entwicklung mit professionellem Harness, statischer Analyse und klaren Architekturvorgaben liefert Ergebnisse, die in Geschwindigkeit und Qualität weit über dem liegen, was die meisten Teams heute erreichen.

Der eigentliche Hebel: Der Harness, nicht die KI

Die Qualität am Ende ist nicht deshalb so hoch, weil die KI besonders gut ist. Sie ist so hoch, weil der Entwickler jahrelange Erfahrung in Softwarearchitektur und Qualitätssicherung mitbringt und diese Erfahrung in einen penibel gepflegten Harness überführt hat.

Der Harness enthält Architekturrichtlinien (wie die Systemarchitektur aussehen muss), Codierrichtlinien (wie der Code geschrieben werden muss), Testrichtlinien (wie Tests strukturiert und ausgeführt werden), Anforderungsrichtlinien (wie Stories zerlegt werden) und Ideenrichtlinien (wie Ideen formuliert und diskutiert werden). Jede Abweichung der KI führt zur Korrektur des Harness, nicht zur Korrektur des Codes.

Das deckt sich mit einer zentralen Erkenntnis, die sich durch unsere gesamte Artikelreihe zieht. Vibe-Coding ohne Architekturkontrolle produziert God-Objects und technische Schulden. Agentisches Coding ohne menschliche Aufsicht erodiert genau die Fähigkeiten, die zur Kontrolle nötig sind. Fundamente schlagen Tools. Dieses Experiment ist der empirische Beweis: Wer die Grundlagen beherrscht, kann KI so einsetzen, dass die Ergebnisse professionellen Standards entsprechen. Wer sie nicht beherrscht, wird auch mit der besten KI keine Enterprise-Qualität erreichen.

Die Konsequenz für die Branche

Ein einzelner Architekt liefert in 45 Tagen, wofür ein Team zwei Millionen Euro und 19 Personenjahre bräuchte. Die Qualität ist besser. Die Kosten betragen 1,25 Prozent des Teambudgets.

Diese Zahlen verändern die Kalkulation für jedes Softwareprojekt. Nicht heute, nicht für jedes Team und nicht für jede Domäne. Aber die Richtung ist eindeutig. Wer sich jetzt nicht mit den Methoden beschäftigt, mit denen solche Ergebnisse möglich sind, wird den Anschluss verlieren.

Die Frage ist nicht, ob KI die Softwareentwicklung verändert. Die Frage ist, ob du derjenige bist, der den Harness schreibt, oder derjenige, der durch ihn ersetzt wird.