„KI macht Teams schneller.“ Den Satz hast du sicher schon oft gehört. Er stimmt. Ich arbeite jeden Tag mit KI-Agenten, die Code schreiben, und möchte nicht mehr ohne sie arbeiten.

Schneller heißt aber auch: schneller in die falsche Richtung, wenn niemand aufpasst. Dieser Beitrag geht darum, wo der Engpass in der Softwareentwicklung heute liegt, welche Probleme daraus entstehen und welche Regeln einem Team helfen.

Der Engpass hat sich verschoben

Lange war Zeit der Engpass in der Softwareentwicklung. Ein Feature dauerte Tage oder Wochen. Deshalb haben Teams genau überlegt, was sie wann bauen. Der Aufwand war ein natürlicher Filter.

Mit KI-Agenten hat sich das verschoben. Software zu bauen kostet immer noch Zeit, aber deutlich weniger. Den Satz „Dafür bräuchte ich zwei Wochen, lass uns das verschieben“ hört man seltener. Öfter heißt es: „Ich schaue mir das kurz an und melde mich morgen.“

Das ist ein echter Fortschritt. Er hat nur einen Haken: Was schnell gebaut ist, ist noch lange nicht verstanden oder richtig entschieden. Der Engpass ist nicht verschwunden. Er liegt jetzt an anderen Stellen.

Vier neue Engpässe

Fokus

Wenn Bauen billig wird, wird Weglassen schwer. Du kennst bestimmt Produkte, die am Anfang ein Problem sehr gut gelöst haben. Dann kam ein Feature nach dem anderen dazu, bis das Produkt kaum noch zu bedienen war.

Mit KI kann das schneller passieren, auch in kleinen Teams. Die Frage ist nicht mehr „Schaffen wir das?“, sondern „Sollten wir das überhaupt bauen?“. Diese Frage beantwortet kein Agent für dich.

Abstimmung

Früher hat der Aufwand eines Features für Abstimmung gesorgt. Wer zwei Wochen investieren will, bespricht das vorher mit dem Team. Heute ist auch eine große Änderung schnell umgesetzt, oft bevor jemand anderes davon weiß.

Ein ausgedachtes, aber typisches Beispiel: Eine selbst gebaute Text-zu-SQL-Lösung liefert nicht die gewünschte Verlässlichkeit. Also wird sie kurzerhand durch die API eines Drittanbieters ersetzt. Eine Stunde später zeigt sich: Die Datenstruktur der neuen API weicht leicht ab, und andere im Team müssen ihre Module anpassen. Die Rate Limits und Kosten des Anbieters hat niemand geprüft. Und die Änderung ist schon deployt.

Die Umsetzung war nicht das Problem. Das fehlende Gespräch vorher schon.

Verständnis

Früher musstest du Code verstehen, um ihn schreiben zu können. Das hat Zeit gekostet. Dafür kannte das Team sein System. Es konnte Fehler schneller finden und Fragen aus dem Fachbereich beantworten, etwa: „Wie entscheidet unser System eigentlich, welcher Antrag zuerst bearbeitet wird?“

KI trennt das Schreiben von Code vom Verstehen. „Läuft doch“ reicht dann schnell als Maßstab. Kurzfristig entsteht so mehr Code. Langfristig wächst ein System, das niemand im Team mehr ganz erklären kann. Solche Systeme sind schwer zu debuggen, für Menschen und für Agenten.

Das liegt nicht daran, dass generierter Code schlecht wäre. Oft ist er gut. Aber Code, den niemand im Team versteht, ist ein Risiko, egal wer ihn geschrieben hat.

Verantwortung

Eine Situation, die immer häufiger vorkommt: Jemand findet einen Fehler, der zugehörige Code ist schwer zu verstehen. Also fragt man die Person, die ihn eingebracht hat. Die Antwort: „Ehrlich gesagt hat das der Agent geschrieben. Warum er es so gelöst hat, weiß ich nicht.“

Das ist kein Charakterproblem einzelner Entwickler. Wer Code nicht mehr selbst tippt, fühlt sich schnell nicht mehr als Autor. Für das Team ändert das nichts. Irgendjemand muss den Code erklären, warten und reparieren können.

Sechs Regeln, die in der Praxis helfen

Diese Probleme entstehen nicht durch KI, sondern durch die Art, wie wir mit ihr arbeiten. Also lässt sich die Arbeitsweise anpassen. Die Grundidee: Du entscheidest, der Agent setzt um.

  1. Ziel und Grenzen klären. Bevor ein Agent loslegt, ist klar, was erreicht werden soll und was nicht. Welche Schnittstellen, Datenstrukturen, Kosten und Limits gelten? Was du offenlässt, entscheidet sonst der Agent.
  2. Architektur bewusst entscheiden. Struktur, Muster und Abhängigkeiten legst du fest, nicht der Agent. Größere Entscheidungen bespricht das Team, bevor sie gebaut werden, und hält sie kurz schriftlich fest.
  3. In kleinen, prüfbaren Schritten arbeiten. Eine neue Methode mit fünf Zeilen verstehst du im Review sofort. Tausend Zeilen in fünfzehn Dateien nicht. Lieber viele kleine Änderungen als eine große.
  4. Jeden generierten Code prüfen. Lesen, den Ablauf nachvollziehen, nachfragen, wo etwas unklar ist. Tests und Typen helfen dabei, ersetzen aber nicht das eigene Verständnis.
  5. Wissen im Team halten. Reviews, kurze Erklärungen in Pull Requests und festgehaltene Entscheidungen sorgen dafür, dass das Wissen über das System im Team liegt. Nicht in einem Chatverlauf, der morgen weg ist.
  6. Wer committet, verantwortet. Wer Code einbringt, ist sein Autor. Egal, wie er entstanden ist: Du musst ihn erklären, reparieren und vertreten können.

Wie das im Alltag aussieht, zeigt ein Auftrag an einen Agenten, bei dem die Entscheidungen schon gefallen sind:

Ziel: Anfragen pro Monat nach Kanal auswerten.
Entschieden: neues Model „Inquiry“ mit den Feldern channel, createdAt, status.
             Neuer Service „InquiryReport“ im bestehenden Reporting-Modul.
Nicht ändern: die öffentliche API und die Datenbanktabellen anderer Module.
Vorgehen: erst Model und Tests, dann der Service. Nach jedem Schritt anhalten.

Der Agent schreibt den Code. Was gebaut wird, wo es hingehört und was tabu ist, steht vorher fest. Das macht auch das Review leichter, denn du prüfst die Umsetzung einer Entscheidung, die du kennst.

Was das für mich bedeutet

Ich arbeite in beiden Rollen: allein und direkt für den Kunden, aber auch im bestehenden Team eines Kunden, etwa beim Multi-Agenten-System für einen deutschen Automobilkonzern. Dort gelten die Prozesse und Freigaben des Konzerns.

Die Regeln oben gelten für mich in beiden Fällen. Im Team, weil andere mit meinem Code weiterarbeiten. Allein erst recht, denn dann gibt es niemanden außer mir, der ihn erklären kann.

Fazit

KI macht Umsetzung billiger. Das ist ein Gewinn, und Teams, die sie gut einsetzen, werden schneller. Entscheidungen, Abstimmung und Verständnis werden dadurch aber nicht billiger. Sie werden wichtiger.

Am meisten profitieren nicht die Teams, die den meisten Code erzeugen. Sondern die, die wissen, was sie bauen, warum sie es bauen und wer dafür geradesteht.