Die Strategen – Business Analyst & Solution Architect

Im vorherigen Post habe ich die vier systemischen Probleme beschrieben, auf die ich beim Einsatz von KI-Coding-Assistenten immer wieder gestoßen bin: das Konzept-Problem, das Regelverstoß-Problem, das Duplikations-Problem und das Fokus-Problem. Und ich habe dort eine Konsequenz formuliert: Ich denke nicht mehr in Prompts, sondern in Prozessen. Prozesse brauchen Rollen.

In diesem Post stelle ich die ersten beiden Rollen in meinem Agenten-Team vor: den Business Analysten und den Solution Architect. Beide übernehmen die Planungsphase, bevor auch nur eine Zeile produktiver Code entsteht. Und beide sind um ein Prinzip herum gebaut, das mir erst durch Erfahrung klar geworden ist: Human-in-the-Loop.

Warum zwei Agenten für die Planung?

Im Post über copilot-instructions.md und AGENTS.md habe ich beschrieben, wie man einem Assistenten projektspezifische Spielregeln gibt. Das hat die Qualität der Ausgaben verbessert – aber nicht das fundamentale Problem gelöst, das ich beschrieben hatte: Ein Modell, das gleichzeitig Anforderungen analysiert, ein Konzept entwirft und Code schreibt, macht bei allem drei nur halbe Arbeit.

Die Lösung klingt trivial, sobald man sie ausspricht: Trenne die Phasen und gib jeder einen eigenen, fokussierten Agenten.

Phase 1 lautet: Was soll gebaut werden? Welche Anwendungsfälle gibt es? Welche Abläufe müssen funktionieren, welche nicht?

Phase 2 lautet: Wie soll es gebaut werden? Welche Schichten sind betroffen, welche Schemaänderungen sind nötig, welche bestehenden Muster können wiederverwendet werden?

Diese saubere Trennung ist nicht neu. Sie spiegelt das wider, was in der klassischen Softwareentwicklung seit Jahrzehnten funktioniert: Erst die Anforderungen, dann die Architektur, dann die Implementierung. Die KI braucht dieselbe Struktur – nicht weil sie es nicht besser kann, sondern weil ein begrenztes Kontextfenster keine Ausnahme macht.

Der Business Analyst

Der erste Agenten in meinem Workflow heißt Business Analyst. Seine einzige Aufgabe: vage Anforderungen in präzise, maschinenlesbare Use-Case-Dokumente zu verwandeln.

Das klingt nach Bürokratie. Tatsächlich ist es das Gegenteil von Mehraufwand – es ist die Grundlage dafür, dass alle nachfolgenden Schritte überhaupt funktionieren.

Ein Use Case, den der Business Analyst ausspuckt, hat eine klare Struktur: einen Hauptablauf (der Happy Path), Alternativflüsse (die Abweichungen), Fehlerfälle (die Unhappy Paths), Vor- und Nachbedingungen sowie zwei Mermaid-Diagramme. Eines zeigt die technische Interaktion zwischen User, Komponente, Composable und Backend als Sequenzdiagramm. Das andere zeigt die User Journey – alle Screens, Entscheidungspunkte, Erfolgs- und Fehlerpfade in einem Flussdiagramm.

Die Grundidee für diesen Ansatz habe ich aus der BMAD-Methodik mitgebracht – einem Open-Source-Projekt, das sich mit dem strukturierten Einsatz von KI-Agenten im Entwicklungsprozess beschäftigt. Ich habe es mir angeschaut, ausprobiert und das für mich Relevante herausgezogen: konkret das Denken in expliziten Use-Case-Strukturen mit Happy und Unhappy Paths als Brücke zwischen Anforderung und technischer Umsetzung. Nicht alles aus BMAD hat zu meinem Workflow gepasst – ich habe bewusst selektiert und den Rest weggelassen.

Diese Artefakte landen als Markdown-Dateien im Projekt, in einem strukturierten docs/usecases/ Verzeichnis. Sie sind gleichzeitig für Menschen lesbar und für die nachfolgenden Agenten als Kontext verwendbar.

Was mir daran besonders wichtig ist: Der Agent stellt vor der eigentlichen Ausarbeitung gezielte Rückfragen. Er fragt nach Akteuren, nach Scope-Grenzen, nach bekannten Fehlerfällen. Maximal sechs Fragen, nur wenn nötig. Und dann wartet er – er geht nicht einfach weiter, sondern wartet auf eine explizite Bestätigung.

Jetzt hat der Mensch die Möglichkeit zu prüfen, ob der KI Agent ihn richtig verstanden hat und ob seine Anforderungen in dem aktuellen Projekt Sinn machen und gut passen oder nicht. Er kann Unklarheiten auflösen, die der Agent vorher angenommen hat. Er kann die Anforderungen präzisieren, bevor sie in ein Konzept gegossen werden. Und das ist der entscheidende Punkt: Je früher ich Unklarheiten auflöse, desto günstiger ist es.

Diese Use Case Beschreibung, dient dem Solution Architect als Kontext, um die technische Umsetzung zu planen. Sie ist die Single Source of Truth für die Anforderungen, die der Coding-Agent später umsetzen wird.

Der Solution Architect

Der zweite Agenten im Planungs-Duo ist der Solution Architect. Er nimmt den Use Case des Business Analysten und übersetzt ihn in ein technisches Lösungskonzept.

Sein Output ist ein strukturiertes Dokument unter docs/loesungskonzept/, das die aktuelle Codebase als Ausgangspunkt nimmt. Bevor er einen Entwurf macht, liest er den bestehenden Code. Er inspiziert das Datenbankschema. Er sucht nach vorhandener Logik, die wiederverwendet werden kann, statt neu gebaut zu werden. Erst dann entwirft er den Soll-Zustand – mit Klassendiagrammen, Sequenzdiagrammen und einem tabellarischen Maßnahmenkatalog, der jede Änderung mit Dateipfad, Aufwandsschätzung und Abhängigkeiten listet.

Das Lösungskonzept ist kein fertiger Code. Es ist eine Blaupause. Und diese Blaupause erfüllt eine wichtige Funktion: Sie ist der Kontext, den der Coding-Agent im nächsten Schritt bekommt – präzise, vollständig und auf das Wesentliche fokussiert.

Das Lösungskonzept beinhaltet so Punkte wie:

## 1. Management Summary

## 2. Ist-Zustand

## 3. Soll-Zustand

## 4. Technisches Design

## 5. Design-Entscheidungen

## 6. Maßnahmenkatalog

## 7. Testplan

## 8. Dateiübersicht

## 9. Risiken & Mitigation

Das gibt mir als Mensch die Möglichkeit, die vorgeschlagene Lösung auf einer technischen Ebene zu beurteilen, bevor sie in Code gegossen wird. Ich kann prüfen, ob die vorgeschlagenen Maßnahmen sinnvoll sind, ob sie mit der bestehenden Architektur harmonieren, und ob sie tatsächlich die Anforderungen erfüllen, die ich bestätigt habe.

Auch der Solution Architect endet nicht einfach mit dem Dokument. Er stellt das Konzept vor, fasst die Kernpunkte zusammen – und wartet dann. Erst nach einer expliziten Freigabe gilt das Konzept als abgenommen.

Die Artefakte als Single Source of Truth

Beide Agenten produzieren Dokumente. Und genau das ist der Punkt: Diese Dokumente sind keine Dokumentation im klassischen Sinne, die nachträglich geschrieben wird und schnell veraltet. Sie sind die Quelle, aus der der Coding-Agent später seinen Kontext zieht.

Wenn der Coding-Agent eine Implementierung beginnt, bekommt er kein chaotisches Transkript einer langen Diskussion. Er bekommt ein sauberes Use-Case-Dokument mit klaren Abläufen und ein Lösungskonzept mit konkreten Maßnahmen. Sein Kontextfenster ist dadurch nicht mit Hintergrundrauschen gefüllt, sondern mit präzisen, strukturierten Informationen.

Das ist die Antwort auf das Konzept-Problem aus dem letzten Post: Der Coding-Agent muss nichts mehr erfinden. Das Konzept steht bereits. Seine Aufgabe ist nur noch: umsetzen.

Als Inspiration für die Dokumentstruktur habe ich mir unter anderem OpenSpec angeschaut – einen Ansatz für maschinenlesbare, menschenfreundliche Spezifikationen. Den kompletten Standard habe ich nicht übernommen, weil das für mein Setup zu viel Overhead gewesen wäre. Was ich mitgenommen habe, ist die Grundidee dahinter: Eine Spezifikation soll gleichzeitig von Menschen verstanden und von Maschinen als strukturierter Kontext verarbeitet werden können. Genau das ist der Anspruch, den meine Use-Case- und Lösungskonzept-Dokumente erfüllen sollen.

Auch dieses Dokument muss vom Menschen geprüft und freigegeben werden, denn nur der Mensch kann beurteilen, ob die vorgeschlagene Lösung tatsächlich den Anforderungen entspricht und mit der bestehenden Architektur harmoniert und dem zukünftigen Produkt mit dem zukünftigen Funktionsumfang entspricht.

Human-in-the-Loop (HITL): Nicht Bremse, sondern Steuer

Jetzt komme ich zum Teil, der mich am meisten beschäftigt hat – und über den ich am längsten nachgedacht habe, bevor ich ihn so formulieren konnte.

Das Human-in-the-Loop-Prinzip klingt im ersten Moment nach einer Einschränkung. Als würde man der KI misstrauen und deshalb überall Kontrollpunkte einbauen. Und ja – ich misstraue der KI tatsächlich. Bewusst und aus gutem Grund.

Meine eigene Erfahrung und die wissenschaftliche Evidenz, die ich im vorherigen Post beschrieben habe, sind in diesem Punkt eindeutig: KI-Agenten produzieren plausibel klingende Ergebnisse, die im Detail falsch, unvollständig oder architektonisch problematisch sein können – und das oft so, dass man es ohne genaue Prüfung nicht erkennt. Wer diese Ergebnisse ungeprüft übernimmt, baut sich Probleme in den Code, die ihn später Stunden oder Tage kosten. Ich will die Ergebnisse der KI deshalb sehen, prüfen und freigeben können, bevor sie weiterverarbeitet werden.

Aber HITL ist nicht nur ein Prüfmechanismus. Es ist gleichzeitig etwas, das ich erst durch die Praxis verstanden habe: Ein Human-in-the-Loop-Checkpoint ist nicht nur Kontrolle. Es ist auch eine Richtungskorrektur, solange sie noch kostenlos ist.

Wenn ein Business Analyst einen Use Case entwirft und ich ihn lese und sage „nein, das ist nicht der Scope, den ich meinte" – dann kostet diese Korrektur eine Minute. Wenn dieselbe Fehlannahme erst im fertigen Code auftaucht, kostet sie im besten Fall Stunden.

Das ist kein akademischer Punkt. Es ist das Prinzip hinter dem bekannten Phänomen aus dem Software-Engineering, dass ein Fehler in der Anforderungsphase zehnmal billiger zu beheben ist als in der Design-Phase, und hundertmal billiger als in der Implementierungsphase (Barry W. Boehm, Software Engineering Economics, 1981). Die KI hat dieses Gesetz nicht außer Kraft gesetzt.

Was die Checkpoints außerdem leisten: Sie zwingen mich, selbst nachzudenken. Wenn ein Agent mir einen Use Case vorlegt und fragt „ist das der Scope?", muss ich die Frage beantworten. Ich kann nicht einfach weiterskippen. Und in dem Moment, in dem ich die Antwort formuliere, merke ich häufig, dass ich selbst noch nicht präzise genug gedacht hatte.

Das klingt ineffizient. Tatsächlich ist es das Gegenteil: Es zwingt mich, Unklarheiten früh aufzulösen – genau da, wo es am einfachsten ist.

Was Forschung und Praxis bestätigen

Das Prinzip ist inzwischen gut belegt. Eine empirische Studie mit 120 professionellen Softwareentwicklern untersuchte, was passiert, wenn man KI-Assistenten ohne menschliche Kontrolle einsetzt: Die Produktivität stieg um beachtliche 31,4 % – aber gleichzeitig schlichen sich 23,7 % mehr Sicherheitslücken in den Code ein (Empirical Analysis of AI-Assisted Code Generation, 2025). Geschwindigkeit und Qualität entkoppeln sich, sobald der Mensch aus dem Loop genommen wird.

Auf der ICSE 2025 (International Conference on Software Engineering) wurde das HULA-Framework vorgestellt – Human-in-the-Loop LLM-based Agents. Die Forscher belegten empirisch, dass autonome Agenten auf historischen Benchmarks zwar hervorragend abschneiden, in echten Projekten aber systematisch scheitern, wenn der Mensch nicht in jeder Phase – Planung, Architektur, Code – korrigierend eingreift (HULA Framework, ICSE 2025). Auch Atlassian kam 2025 in einer Field Study zu einem ähnlichen Ergebnis: Vollautonome Agenten zur Behebung von Jira-Tickets scheiterten an der Verifikation. Menschliches Eingreifen war nicht beim Schreiben des Codes nötig – sondern beim Beurteilen der Logik dahinter.

Die wissenschaftliche Einigkeit ist eindeutig: HITL ist kein nettes Extra. Es ist eine strukturelle Voraussetzung dafür, mit KI produktionsreife Software zu bauen.

Nicht alles ist Gold was glänzt: HITL als Schein-Kontrolle

Die Forschung warnt aber auch vor einer Variante, die ich für mindestens genauso wichtig halte: HITL kann scheitern, ohne dass man es merkt.

Der sogenannte „Inverted Loop" beschreibt eine Situation, die vielen vertraut sein dürfte (Spiceworks, 2026): Eigentlich sollte die KI dem Menschen zuarbeiten. In der Praxis dreht sich das Verhältnis um. Der Coding-Agent produziert einen kontinuierlichen Strom an Code, und der Entwickler mutiert zum Dauer-Reviewer. Was zuerst nach Kontrolle aussieht, wird zur kognitiven Erschöpfung. Man nickt durch, weil man schlicht nicht mehr kann. Das System kollabiert – nicht laut, sondern schleichend. Die Codequalität sinkt, während die Illusion der Kontrolle bestehen bleibt.

Eine ähnliche Analyse (Medium, 2026) warnt vor einer subtileren Variante: das reine Absegnen von KI-generierten Spezifikationen. Wenn ein Entwickler einen Markdown-Plan „reviewed", ohne die technologischen Entscheidungen darin wirklich nachvollziehen zu können, ist HITL nur noch eine Phrase. Der Mensch hat nominell die Kontrolle – aber nicht die kognitive Substanz, um die Entscheidungen dahinter zu hinterfragen. Und wer nicht wirklich versteht, was er freigibt, gibt nichts frei – er winkt durch.

Warum der Checkpoint vor dem Code entscheidend ist

Genau hier liegt der Unterschied in meinem Ansatz: Ich setze den Human-in-the-Loop-Checkpoint nicht auf Code-Ebene, sondern auf Konzept-Ebene.

Ich reviewe keine Tausend Zeilen Code, die mir ein Agent um die Ohren wirft. Ich reviewe einen Use Case. Ich reviewe ein Lösungskonzept. Beide Dokumente sind kompakt, in meiner Sprache, auf einem Abstraktionsniveau, das ich ohne tiefen Code-Dive beurteilen kann. Beide kommen zu einem Zeitpunkt, zu dem eine Richtungskorrektur noch nichts kostet. Und beide beschreiben das Was und das Wie – nicht das lauffähige Ergebnis, das ich müde durchwinken müsste.

Das vermeidet den Inverted Loop, weil ich nicht im Dauer-Review-Modus bin. Es vermeidet die Schein-Kontrolle, weil ich Anforderungen und Architektur auf einer Ebene beurteile, auf der ich tatsächlich urteilen kann. Und es stellt sicher, dass der Coding-Agent, der danach kommt, eine verlässliche Blaupause bekommt – keine improvisierte Aufgabenbeschreibung.

Aus meiner Sicht, ist das ein wichtiger Punkt, wir als Menschen sehen oft das große Bild des Software Projektes, auch wenn wir ein Contextfenster haben, ist es wesentlich größer als das von der KI, daher möchte ich jeden dazu ermutigen, die Checkpoints nicht auf Code-Ebene zu setzen, sondern auf Konzept-Ebene. Es ist der Moment, in dem wir tatsächlich noch Einfluss nehmen können – und das ist der Moment, den wir nutzen sollten.

Ein ehrlicher Punkt: Beschleunigung ist nicht das primäre Ziel

Ich möchte nicht den Eindruck erwecken, dass dieses Setup automatisch schneller ist. Das stimmt nicht.

Zwei Agenten, die Dokumente erstellen, Rückfragen stellen und auf Freigaben warten, bevor der eigentliche Code entsteht – das ist messbar mehr Prozess als ein einfaches Prompt-Response-Muster. Für kleine, isolierte Features wird dieser Overhead spürbar sein.

Aber die Frage ist nicht: „Ist es schneller als ein einzelner Prompt?" Die Frage ist: „Ist es schneller als ein einzelner Prompt plus die anschließenden Stunden, in denen ich Architekturbrüche repariere, Duplikationen entferne, Spaghetti Code aufräume und Anforderungsmissverständnisse korrigiere?"

Diese zweite Rechnung fällt für mich eindeutig aus – sobald die Aufgabe eine gewisse Komplexität überschreitet.

Und ja: Es ist auch ein Workaround

Ich will ehrlich sein dieses Setup ist, zumindest teilweise, ein Workaround für die aktuellen Grenzen der Modelle.

Ein LLM mit einem unbegrenzten Kontextfenster, das den gesamten Zustand eines Projekts jederzeit perfekt abrufen könnte, bräuchte diese Zerlegung vielleicht nicht. Es könnte Anforderungsanalyse, Architekturentwurf und Implementierung in einem Durchgang leisten, ohne dabei Qualität zu verlieren.

Das ist heute nicht die Realität. Kontextfenster sind begrenzt. Aufmerksamkeit ist begrenzt. Und je mehr Information in einem einzigen Prompt zusammenfließt, desto mehr Qualität verliert jede einzelne Teilaufgabe – das zeigt die Forschung (Liu et al., 2024), und das zeigt meine eigene Erfahrung.

Die Zerlegung in spezialisierte Agenten mit klar abgegrenztem Kontext ist daher auch eine Reaktion auf diese Einschränkung. Kleine Fenster, fokussierte Aufgaben, präzise Ausgaben.

Ob Modelle in zwei oder fünf Jahren diese Zerlegung überflüssig machen, weiß ich nicht. Vielleicht wird die Antwort irgendwann „kein Workaround mehr nötig" sein. Heute aber ist es die zuverlässigste Methode, die ich gefunden habe.

Fazit

Der Business Analyst und der Solution Architect sind nicht die Teile meines Workflows, die den meisten Code erzeugen. Sie erzeugen gar keinen Code.

Aber sie sind die Teile, die sicherstellen, dass der Code, der danach entsteht, das Richtige implementiert – auf die richtige Art, konsistent mit der bestehenden Architektur, und basierend auf Anforderungen, die ich tatsächlich bestätigt habe.

Das Human-in-the-Loop-Prinzip ist dabei kein nachträgliches Sicherheitsnetz. Es ist der eigentliche Mechanismus, der den Prozess in die richtige Richtung hält. Weil ich der KI nicht blind vertraue – und weil ich weiß, dass Richtungskorrekturen am Anfang kostenlos sind und am Ende sehr teuer.

Im nächsten Post zeige ich, wie der dritte Teil des Teams aussieht: der Coding-Agent, der die Blaupause bekommt und umsetzt.