Vom Pair Programming zum KI-Tech-Lead: Wie Multi-Agent-Systeme die Softwareentwicklung verändern

Pair Programming mit KI war die erste Welle. Ein Entwickler, ein KI-Assistent, eine Aufgabe. Der Assistent schlägt vor, der Mensch entscheidet, der Code entsteht gemeinsam. Das hat sich schnell etabliert – und ist bereits überholt.

Was sich gerade abzeichnet, ist eine andere Kategorie: nicht mehr ein Assistent neben dem Entwickler, sondern mehrere spezialisierte Agenten, die parallel an unterschiedlichen Teilen eines Projekts arbeiten. Und der Entwickler, der dazwischen steht, koordiniert – keine Zeile Code selbst schreibend, aber für das Gesamtergebnis verantwortlich. Das ist weniger Pair Programming als Tech Lead. Mit einem Team aus KI-Agenten.

Agent View: mehrere Agenten gleichzeitig im Blick

Tools wie Claude Code oder ähnliche Systeme beginnen, visuelle Ansichten für laufende Agenten einzuführen — sogenannte Agent Views. Statt eines einzigen Chatfensters sieht man dort mehrere Agenten parallel: einer implementiert ein Feature, einer schreibt Tests, einer überprüft die Dokumentation, einer untersucht einen Bug in einem anderen Branch.

Das ist kein UI-Detail. Es ist der sichtbare Ausdruck eines Paradigmenwechsels. Bisher war KI ein Werkzeug, das man nacheinander für verschiedene Aufgaben einsetzt. Agent View macht aus dieser sequenziellen Nutzung etwas Paralleles — und stellt den Entwickler vor eine neue Frage: Nicht mehr „Was soll der Agent als nächstes tun?”, sondern „Wie koordiniere ich, was gerade gleichzeitig passiert?”

Vom Implementierer zum Koordinator

Die klassische Entwicklerrolle setzt voraus, dass man den Code selbst schreibt, im Detail versteht und direkt steuert. In Multi-Agent-Systemen verschiebt sich das. Die Fähigkeit, eine Aufgabe präzise zu beschreiben, in Teilaufgaben zu zerlegen und die Ergebnisse zu validieren, wird wichtiger als die Fähigkeit, sie selbst zu implementieren.

Das erinnert an die Rolle eines Tech Leads in einem kleinen Team: weniger Coder, mehr Koordinator. Spezifikationen schreiben. Aufgaben verteilen. Abhängigkeiten erkennen. Ergebnisse beurteilen. Den Überblick behalten, wenn mehrere Dinge gleichzeitig laufen.

Der Unterschied: Das Team besteht aus KI-Agenten. Sie schlafen nicht, wechseln sofort den Kontext und produzieren in Minuten, wofür ein Entwickler Stunden bräuchte. Was sie nicht können: selbst entscheiden, ob die Richtung stimmt. Dafür brauchen sie jemanden, der den Gesamtplan im Kopf hat — und der wird menschlich bleiben.

Context Engineering ersetzt Prompt Engineering

In der ersten Generation von KI-Nutzung war Prompt Engineering die Schlüsselkompetenz: Wie formuliere ich eine Anfrage so, dass das Modell das Richtige produziert? Eine wichtige Fähigkeit — aber zunehmend nicht mehr ausreichend.

In Multi-Agent-Systemen entsteht ein anderes Konzept: Context Engineering. Die Qualität des Ergebnisses hängt nicht mehr primär vom einzelnen Prompt ab, sondern davon, welchen Kontext ein Agent bekommt, bevor er anfängt. Das umfasst:

• Spezifikationen statt Prompts. Ein Agent, der eine Funktion implementieren soll, produziert bessere Ergebnisse, wenn er eine strukturierte Beschreibung bekommt: was genau erwartet wird, welche Randbedingungen gelten, wie Fehlerbehandlung aussehen soll — nicht nur „implementiere X”.
• Saubere Aufgabenaufteilung. Agenten, die zu viel gleichzeitig tun sollen, werden unscharf. Kleinere, klar abgegrenzte Aufgaben mit definierten Ein- und Ausgaben liefern konsistentere Ergebnisse.
• Validierungsschleifen einbauen. Ein Agent, der Code schreibt, sollte eine Möglichkeit haben zu prüfen, ob der Code funktioniert — durch Tests, durch einen zweiten Agenten, durch automatische Checks. Feedback loops sind kein Nice-to-have, sondern Teil der Architektur.
• Kontext zwischen Agenten weitergeben. Was Agent A herausgefunden hat, muss Agent B zugänglich gemacht werden. Ohne explizite Übergabe läuft jeder Agent in seiner eigenen Blase.

Das klingt nach Software-Engineering-Grundlagen — weil es das ist. Context Engineering überträgt bekannte Prinzipien auf KI-Systeme: Separation of Concerns, klare Interfaces, explizite Zustände.

Parallele Entwicklung mit getrennten Worktrees

Eine der praktischsten Ausprägungen von Multi-Agent-Entwicklung ist die Parallelisierung über Git Worktrees. Statt auf einem Branch sequenziell Features zu entwickeln, können mehrere Agenten gleichzeitig an verschiedenen Branches arbeiten — ohne sich gegenseitig in die Quere zu kommen.

Konkret bedeutet das: Feature A läuft im ersten Worktree mit Agent A, Feature B im zweiten Worktree mit Agent B, ein Bugfix im dritten. Jeder Agent hat seinen eigenen Kontext, seinen eigenen Working Directory, seine eigene Aufgabe. Der Entwickler reviewed die Pull Requests, löst Konflikte beim Merge, entscheidet über Prioritäten.

Was früher Multitasking war — zwischen mehreren Aufgaben manuell wechseln — wird zu echter Parallelisierung. Die Gesamtgeschwindigkeit steigt nicht weil jeder Einzelschritt schneller wird, sondern weil viele Schritte gleichzeitig stattfinden. Das ist ein struktureller Unterschied.

Ein typischer Ablauf in einem Webprojekt:

Der Mensch startet nicht vier Agenten mit derselben Aufgabe. Er zerlegt die Arbeit so, dass Schreibbereiche getrennt sind und Ergebnisse zusammengeführt werden können. Das ist der Unterschied zwischen Parallelisierung und Chaos.

Beispiel: Eine gute Agenten-Spezifikation

Ein brauchbarer Auftrag an einen Implementierungsagenten sieht eher wie ein kleines Ticket aus als wie ein Chat-Prompt:

Ziel:
Die mobile Navigation schließt sich nach Klick auf einen internen Link.

Scope:
- Datei: src/components/Header.astro
- Keine Änderung an Routing, Layout oder Design Tokens
- Bestehende Desktop-Navigation unverändert lassen

Akzeptanzkriterien:
- Menü öffnet und schließt per Button
- Klick auf einen internen Link schließt das Menü
- Escape schließt das Menü
- Playwright-Test für mobile Breite ergänzen

Validierung:
- pnpm --filter homepage test:e2e -- navigation
- pnpm --filter homepage check

Diese Form zwingt zur Klarheit. Der Agent weiß, wo er arbeiten darf, was nicht verändert werden soll und wie Erfolg geprüft wird. Genau diese Begrenzung reduziert Reibung beim späteren Merge.

Review wird wichtiger, nicht unwichtiger

Multi-Agent-Arbeit verschiebt den Engpass vom Schreiben zum Prüfen. Deshalb braucht der Review andere Fragen als bei handgeschriebenem Code:

• Hat der Agent den Scope eingehalten?
• Gibt es neue implizite Abhängigkeiten?
• Wurde ein Symptom gefixt oder die Ursache?
• Sind Tests sinnvoll oder nur passend zur Implementierung geschrieben?
• Wurde bestehendes Verhalten versehentlich geändert?
• Gibt es generierte Kommentare, überbreite Abstraktionen oder unnötige Defensive?

Der gefährliche Fall ist nicht der offensichtlich kaputte Patch. Der gefährliche Fall ist der plausible Patch, der am eigentlichen Produktverhalten vorbeigeht.

Was dabei schieflaufen kann

Multi-Agent-Systeme multiplizieren nicht nur Geschwindigkeit, sondern auch Fehler — wenn das Setup nicht stimmt.

Kontextverlust zwischen Agenten. Was Agent A entschieden hat, weiß Agent B nicht automatisch. Ohne explizite Übergabe entstehen inkonsistente Ergebnisse: zwei Agenten lösen dasselbe Problem unterschiedlich, oder einer macht Annahmen, die der andere bereits widerlegt hat.

Zu wenig Validierung. Geschwindigkeit verleitet dazu, Ergebnisse weniger sorgfältig zu prüfen. Agenten produzieren schnell — was nichts über die Korrektheit aussagt. Wer den Review-Schritt überspringt, akkumuliert technische Schulden schneller als je zuvor.

Unklare Spezifikationen skalieren schlecht. Ein vager Prompt an einen einzelnen Agenten produziert ein vages Ergebnis. Derselbe vage Prompt an fünf parallele Agenten produziert fünf verschiedene, inkonsistente Ergebnisse — die dann zusammengeführt werden müssen. Die Präzision der Aufgabenbeschreibung wird in Multi-Agent-Setups wichtiger, nicht unwichtiger.

Zu viele Agenten ohne Koordination. Agent Swarms, bei denen viele Agenten ohne klare Struktur laufen, können unübersichtlich werden. Nicht die Anzahl der Agenten entscheidet über die Qualität, sondern ob jeder Agent eine klar definierte Aufgabe und einen klar definierten Output hat.

Schreibkonflikte. Zwei Agenten ändern dieselbe Datei aus unterschiedlichen Gründen. Das ist nicht nur ein Git-Problem, sondern ein Architekturproblem der Aufgabenverteilung. Disjunkte Schreibbereiche sind bei paralleler KI-Arbeit wichtiger als bei menschlicher Teamarbeit, weil Agenten weniger gut erkennen, welche Änderung gerade anderswo entsteht.

Scheinsicherheit durch Tests. Ein Agent kann Tests schreiben, die exakt seine Implementierung bestätigen, aber den Nutzerfall nicht abdecken. Deshalb sollten kritische Tests aus der Anforderung kommen, nicht erst aus dem fertigen Patch.

Wann ein einzelner Agent besser ist

Multi-Agent-Setups lohnen sich nicht für jede Aufgabe. Ein einzelner Agent ist meist besser, wenn:

• der Codebereich klein und stark gekoppelt ist
• eine Änderung viel implizites Produktwissen erfordert
• die Aufgabe vor allem Debugging und nicht Umsetzung ist
• ein Ergebnis sofort manuell geprüft werden muss
• Merge-Konflikte wahrscheinlicher sind als Zeitgewinn

Parallelisierung ist ein Werkzeug, kein Ziel. Wer sie bei kleinen Änderungen erzwingt, erzeugt Koordinationsaufwand ohne Nutzen.

Die neue Kernkompetenz

Was sich abzeichnet, ist keine Abkehr vom Entwickler — sondern eine Verschiebung dessen, wofür Entwicklerkompetenz gebraucht wird. Wer die Architektur versteht, Aufgaben sauber zerlegen kann, Ergebnisse kritisch beurteilt und Abhängigkeiten zwischen parallelen Strängen erkennt, wird in Multi-Agent-Systemen effizienter als ohne KI.

Wer hofft, dass die Agenten das Denken übernehmen, wird feststellen: Sie übernehmen die Ausführung. Das Denken bleibt.

Context Engineering — gute Specs schreiben, Aufgaben klar abgrenzen, Validierung einbauen, Kontext explizit weitergeben — ist die praktische Antwort auf diese Verschiebung. Kein neues Konzept, aber eine neue Priorität.