KI-Coding-Agenten haben den Engpass nicht entfernt. Sie haben ihn verschoben.

Die interessante Diskussion über KI-Coding hat sich verschoben.

Lange ging es vor allem um die Frage, ob Werkzeuge wie Claude Code, Cursor, Codex-artige Agenten, Devin, Replit Agent, Lovable und ähnliche Systeme überhaupt brauchbaren Code schreiben können. Diese Frage ist nicht verschwunden, aber sie ist für ernsthafte Teams nicht mehr die wichtigste.

Die bessere Frage lautet jetzt:

Was passiert, wenn Code-Erzeugung nicht mehr der langsamste Teil der Softwareentwicklung ist?

Auf X war in den letzten 24 Stunden genau diese praktischere Diskussion sichtbar. Entwickler sprechen weniger über einzelne Prompts und mehr über Flotten von Coding-Agenten, parallele Branches, Preview-Umgebungen, agenten-native Planung, automatisierte Reviews, Context Engineering und die Frage, wie viele autonome Arbeitsstränge trotzdem zu einem zusammenhängenden Produkt werden.

Das ist die richtige Diskussion.

Denn KI-Coding-Agenten entfernen Engpässe nicht automatisch.

Sie verschieben sie.

Schnellerer Code erzeugt Druck an anderer Stelle

In klassischen Softwareteams ist Implementierung oft der sichtbare Engpass.

Ein Feature wartet auf eine Entwicklerin. Ein Bug wartet darauf, dass jemand den betroffenen Bereich versteht. Ein Prototyp wartet auf einen freien Nachmittag. Ein Refactoring wartet, weil Roadmap-Arbeit dringender ist.

KI-Coding-Agenten können einen Teil dieses Wartens tatsächlich reduzieren. Sie können Änderungen entwerfen, Lösungswege erkunden, Tests schreiben, Dokumentation aktualisieren, interne Tools bauen und repetitive Implementierung deutlich günstiger machen.

Das ist echter Wert.

Aber Softwareentwicklung besteht nicht nur aus Code-Produktion.

Ein ernsthaftes Produkt braucht auch:

• klare Produktabsicht;
• Architekturgrenzen;
• fachliche Entscheidungen;
• Datenmodellierung;
• Integrationsplanung;
• Teststrategie;
• Review;
• Sicherheitsurteil;
• Release-Management;
• operative Verantwortung.

Wenn Agenten Implementierung beschleunigen, werden diese anderen Teile sichtbarer. Ein Team hat plötzlich fünf Branches statt einem. Zehn vorgeschlagene Änderungen statt zwei. Mehr Prototypen, als irgendjemand sinnvoll bewerten kann. Mehr generierte Tests, bei denen trotzdem ein Mensch entscheiden muss, welches Risiko sie wirklich abdecken.

Das Team hat mehr Output.

Aber Output ist nicht dasselbe wie Fortschritt.

Fortschritt bedeutet, dass die richtigen Änderungen ins Produkt kommen, zur Architektur passen, in Produktion überleben und nach dem ersten Hype wartbar bleiben.

Der neue Engpass ist Koordination

Das Muster ist einfach:

KI macht es leichter, Arbeit zu starten, als Arbeit gut zu Ende zu bringen.

Ein Gründer kann einen Agenten bitten, drei Varianten eines Dashboards zu bauen. Eine CTO kann parallele Agenten auf verschiedene Tickets ansetzen. Ein Produktteam kann für jede Stakeholder-Idee einen Prototyp erzeugen. Ein Entwickler kann einen Agenten durch einen Backlog kleiner Fixes schicken.

Der schwierige Teil ist nicht mehr immer die erste Version.

Der schwierige Teil ist die Entscheidung:

• Welche Version sollte bleiben?
• Welcher Branch passt zur Produktstrategie?
• Welcher generierte Code verletzt eine Architekturregel?
• Welche Abhängigkeit ist unnötig?
• Welcher Test ist aussagekräftig und welcher prüft nur den Happy Path?
• Welche Änderung sollte geteilt, verschoben oder abgelehnt werden?
• Welcher Teil des Systems wird schwerer zu betreiben?

Das ist Koordinationsarbeit.

Es ist Planung, Priorisierung, Review, Integration und Urteilskraft. Es ist die Arbeit, die möglichen Code in produktfähige Software verwandelt.

Deshalb ist die aktuelle X-Diskussion über Agent-Orchestrierung für Kunden relevant. Es ist nicht nur ein Tool-Trend. Es ist ein Zeichen dafür, dass Teams auf die nächste Realitätsschicht treffen.

Wenn Agenten schneller Code erzeugen, als die Organisation ihn verstehen, prüfen und integrieren kann, ist der Engpass nicht verschwunden.

Er ist von der Tastatur ins Betriebsmodell gewandert.

Warum das für Gründer wichtig ist

Gründer sind für diese Falle besonders anfällig.

KI-Tools machen es möglich, beeindruckende Prototypen schnell zu bauen. Das kann hervorragend sein. Ein Gründer kann einen Workflow testen, einem Kunden etwas Greifbares zeigen, ein internes Tool erkunden oder validieren, ob eine Produktidee weitere Investition verdient.

Aber schnelle Prototypen erzeugen eine gefährliche Versuchung:

Wenn die Demo funktioniert, ist das Produkt fast fertig.

Oft stimmt das nicht.

Der Prototyp hat vielleicht kein klares Berechtigungsmodell. Das Datenmodell ist improvisiert. Fehlerbehandlung ist oberflächlich. Integrationen beruhen auf Annahmen, die im echten Betrieb brechen. Die Oberfläche deckt den Happy Path ab, aber nicht die operative Realität. Der Code ist gut genug zum Zeigen, aber nicht gut genug zum Besitzen.

KI macht es leichter, die Demo-Linie zu überschreiten.

Sie macht es nicht automatisch leichter, die Produktionslinie zu überschreiten.

Für Gründer lautet die nützliche Frage deshalb nicht: Können wir das mit KI bauen? In vielen Fällen lautet die Antwort zumindest teilweise ja.

Die bessere Frage lautet:

Was muss wahr sein, damit daraus ein verlässliches Produkt wird?

Dazu gehören Architektur, Sicherheit, Tests, Wartbarkeit, Datenschutz, Kundensupport, Deployment, Monitoring und ein klares Verständnis, welche Teile menschliche Engineering-Entscheidungen brauchen.

Bei McDougall Digital sehen wir genau hier den sinnvollen Einsatz von KI-gestützter Softwareentwicklung: nicht als Abkürzung um Produktverantwortung herum, sondern als Möglichkeit, schneller zu arbeiten und trotzdem die Entscheidungen zu treffen, die ernsthafte Produkte brauchen.

Warum das für CTOs und Product Owner wichtig ist

Für CTOs und Product Owner zeigt sich das Koordinationsproblem anders.

Das Team hat vielleicht bereits ein Produkt, Kunden, Produktionsvorfälle, technische Schulden und Lieferverpflichtungen. KI-Agenten kommen nicht auf eine leere Leinwand. Sie kommen in ein bestehendes System mit Gewohnheiten, Grenzen, Verantwortlichkeiten und Geschichte.

Das macht unkontrollierten Agenten-Durchsatz riskant.

Wenn jeder Entwickler Agenten unabhängig laufen lässt, bekommt das Team vielleicht mehr lokale Geschwindigkeit und weniger gemeinsame Kohärenz. Ein Agent baut einen neuen Helper, obwohl ein Muster schon existiert. Ein anderer ändert Validierung in einer Schicht, obwohl die Architektur sie woanders erwartet. Ein dritter fügt eine Abhängigkeit für ein Problem hinzu, das die Plattform bereits löst. Ein vierter aktualisiert Tests, verfehlt aber die fachliche Regel, die eigentlich zählt.

Keiner dieser Fehler ist für sich genommen spektakulär.

Zusammen erzeugen sie Entropie.

Deshalb sollte KI-Coding-Adoption als Änderung am Delivery-System behandelt werden, nicht nur als Tool-Rollout. Die relevanten Fragen werden:

• Wie werden Aufgaben für Agenten vorbereitet?
• Welchen Kontext erhalten Agenten?
• Welche Repositories und Pfade sind erlaubt?
• Wie werden generierte Branches benannt, geprüft und gemerged?
• Welche Änderungen brauchen Architekturreview?
• Welche Tests müssen vor menschlichem Review laufen?
• Wer löst Konflikte zwischen parallelen Agenten-Ergebnissen?
• Wie werden Produktentscheidungen festgehalten, damit Agenten sie nicht schlecht neu erfinden?

Das sind keine abstrakten Governance-Fragen.

Sie entscheiden darüber, ob ein Team durch KI mehr Hebel bekommt oder nur mehr Code zum Aufräumen.

Die Planungsschicht wird wichtiger

Ein nützliches Signal in der aktuellen Diskussion ist der Aufstieg agenten-nativer Planungs- und Orchestrierungswerkzeuge.

Ob das konkrete Tool Lightsprint, AG Kit, 49 Agents IDE, ein internes Workflow-System oder etwas anderes ist, ist weniger wichtig als der zugrunde liegende Bedarf. Teams suchen nach Möglichkeiten, viele Agentenaufgaben zu koordinieren, ohne das Repository in eine Sammlung unverbundener Vermutungen zu verwandeln.

Diese Planungsschicht muss praktische Fragen beantworten:

• Was ist das gewünschte Produktergebnis?
• Welcher Agent arbeitet an welcher begrenzten Aufgabe?
• Welche Dateien oder Module sind im Scope?
• Was ist ausdrücklich nicht im Scope?
• Welche Annahmen müssen vor der Implementierung geprüft werden?
• Was bedeutet “fertig”?
• Welchen Review-Pfad nimmt das Ergebnis?

Ohne diese Schicht werden parallele Agenten schnell zu paralleler Unklarheit.

Das schnellste Team ist nicht das Team mit den meisten laufenden Agenten.

Es ist das Team, das gute Arbeit definieren, sinnvoll aufteilen, Kontext bewahren und Änderungen integrieren kann, ohne die Form des Produkts zu verlieren.

Context Engineering ist keine Option

Die Qualität von KI-Coding hängt stark vom Kontext ab.

Aber Kontext heißt nicht einfach: mehr Dateien ins Modell.

Für echte Softwareteams umfasst guter Kontext die aktuelle Architektur, Fachsprache, Coding-Standards, Teststrategie, Deployment-Grenzen, Kundenversprechen, Sicherheitserwartungen und bekannte Trade-offs.

Schlechter Kontext umfasst veraltete Dokumente, widersprüchliche Tickets, alte Prototypen, laute Chat-Verläufe, Architekturentscheidungen, denen niemand mehr folgt, und breiten Repository-Zugriff ohne klare Aufgabenbegrenzung.

Wenn Agenten gelegentlich genutzt werden, ist schwacher Kontext ärgerlich.

Wenn Agenten im größeren Maßstab genutzt werden, wird schwacher Kontext teuer.

Jede unklare Anweisung erzeugt Review-Aufwand. Jede fehlende Architekturregel erzeugt Nacharbeit. Jede veraltete Entscheidung erhöht die Wahrscheinlichkeit, dass der Agent sehr gewissenhaft das Falsche umsetzt.

Deshalb wird architekturorientierte Entwicklung im KI-Zeitalter wertvoller, nicht weniger wertvoll. Je klarer das System ist, desto besser kann ein Agent beitragen, ohne seine eigene Struktur zu erfinden.

Auch Dokumentation verändert ihre Rolle.

Sie ist nicht mehr nur für Menschen, die in eine Codebase einsteigen. Sie wird zum operativen Input für KI-gestützte Arbeit. Kurze, aktuelle, konkrete Dokumente können Agentenoutput stärker verbessern als lange Strategiedokumente, die niemand mehr liest.

Review wird zur Produktfunktion

Wenn Implementierung günstiger wird, wird Review strategischer.

Ein Reviewer fragt nicht nur, ob der Code kompiliert. Er fragt, ob die Änderung überhaupt existieren sollte, ob sie zum Produkt passt, ob sie die Kundenrealität respektiert und ob sie das System leichter oder schwerer besitzbar macht.

Das bedeutet: Review braucht Produkturteil.

Zum Beispiel:

• Passt dieser generierte Workflow zur tatsächlichen Arbeitsweise der Nutzer?
• Macht er den Kernpfad einfacher oder erzeugt er einen weiteren Sonderfall?
• Versteckt er eine Geschäftsregel im UI-Code?
• Macht er Support schwieriger?
• Erzeugt er ein Migrationsproblem für bestehende Kunden?
• Führt er eine operative Abhängigkeit ein, die niemand besitzt?

Diese Fragen werden nicht dadurch gelöst, dass noch ein Agent läuft.

Agenten können Review vorbereiten. Sie können Diffs zusammenfassen, riskante Dateien markieren, Checks ausführen, Muster vergleichen und Tests vorschlagen. Aber die Verantwortung für das Produkt bleibt beim Team.

Hier werden sich viele KI-Adoptionsgeschichten trennen.

Einige Teams werden Agenten nutzen, um mehr Code zu erzeugen, und dann im Review ertrinken.

Bessere Teams werden Agenten nutzen, um die gesamte Delivery-Schleife zu verbessern: klarere Aufgaben, kleinere Diffs, bessere Tests, schnelleres Feedback, stärkere Dokumentation und bewusstere Produktentscheidungen.

Integration zeigt die Wahrheit

Generierter Code sieht am besten aus, bevor er auf den Rest des Systems trifft.

Integration ist der Moment, in dem Annahmen sichtbar werden.

Der Agent hat eine leicht andere Datenform verwendet. Der API-Vertrag hatte eine undokumentierte Regel. Die Migration funktioniert für neue Kunden, aber nicht für bestehende. Der UI-Zustand ist isoliert in Ordnung, bricht aber mit echten Berechtigungen. Die Tests laufen lokal, verfehlen aber den Produktionsfall. Das generierte Modul dupliziert ein Muster aus einem anderen Teil der Codebase.

Das ist normale Softwarearbeit.

KI entfernt sie nicht.

Sie kann sie schneller anliefern.

Deshalb brauchen ernsthafte Teams stärkere Integrationsgewohnheiten rund um KI-gestützte Entwicklung:

• kleine, begrenzte Änderungen;
• Preview-Umgebungen für Produktreview;
• automatisierte Tests, die echte Geschäftsregeln abbilden;
• Architekturchecks für riskante Bereiche;
• klare Merge-Verantwortung;
• Feature Flags, wo sie sinnvoll sind;
• Observability nach dem Release.

Der Punkt ist nicht, Agenten auszubremsen.

Der Punkt ist, ihre Geschwindigkeit nutzbar zu machen.

Wie ein ernsthaftes Betriebsmodell aussieht

Ein praktisches Modell für KI-gestützte Softwareentwicklung muss nicht schwergewichtig sein.

Es muss explizit sein.

Für viele Teams sieht ein guter Start so aus:

Erstens: Arbeit klassifizieren.

Niedriges Risiko sind zum Beispiel Copy-Änderungen, isolierte UI-Anpassungen, Dokumentation, einfache Tests und kleine Refactorings. Agenten können davon viel mit leichtem Review übernehmen.

Mittleres Risiko umfasst neue API-Endpunkte, Datenmodelländerungen, Geschäftslogik, Integrationen und Workflow-Änderungen. Diese Arbeit braucht bessere Aufgabenformulierung, Tests und Produktreview.

Hohes Risiko umfasst Authentifizierung, Autorisierung, Billing, Mandantentrennung, Datenmigrationen, Produktionsbetrieb, sicherheitskritische Integrationen und alles mit Kunden- oder Mitarbeiterdaten. Agenten können auch hier helfen, aber der Workflow braucht klare Grenzen und menschliche Verantwortung.

Zweitens: Kontext vor der Ausführung vorbereiten.

Ein Agent sollte Ziel, relevante Dateien, Architekturgrenzen, Nicht-Ziele, Testkommando und erwarteten Review-Pfad erhalten. Vage Aufgaben erzeugen vage Diffs.

Drittens: Änderungen klein halten.

Die beste Agentenarbeit ist oft eng begrenzt. Ein Problem, ein Branch, ein prüfbares Ergebnis. Große autonome Läufe wirken effizient, verschieben Komplexität aber häufig in Review und Integration.

Viertens: Ergebnisse messen.

KI-Adoption sollte nicht an generierten Codezeilen gemessen werden. Bessere Maße sind Durchlaufzeit, Review-Aufwand, Fehlerrate, Nacharbeit, Lieferzuverlässigkeit, Wartbarkeit und die Frage, ob das Team bessere Produktentscheidungen schneller trifft.

Fünftens: Das System verbessern.

Jeder schlechte Agentenoutput ist Feedback. Vielleicht war der Prompt unklar. Vielleicht ist die Architektur schlecht dokumentiert. Vielleicht war die Aufgabe zu groß. Vielleicht hat die Codebase versteckte Kopplung. Vielleicht drückt die Test-Suite die fachliche Regel nicht aus.

Ziel ist nicht nur, den Agenten zu loben oder zu kritisieren.

Ziel ist, das Delivery-System um ihn herum zu verbessern.

Die Chance für deutsche Unternehmen

Deutsche Unternehmen, besonders im Mittelstand, haben oft ein praktisches Verhältnis zu Software.

Software ist kein Spielzeug. Sie betreibt Kundenprozesse, interne Abläufe, Logistik, Produktionsplanung, Compliance-Workflows, Reporting, Service Delivery und kommerzielle Differenzierung.

Deshalb ist die Koordinationsfrage bei KI-Coding besonders relevant.

Die Chance besteht nicht darin, jeden AI-native Startup-Workflow blind zu kopieren. Die Chance besteht darin, KI dort einzusetzen, wo sie Hebel erzeugt, und gleichzeitig die Ernsthaftigkeit zu behalten, die Produktionssoftware braucht.

Zum Beispiel:

• Prototypen können schneller entstehen, ohne so zu tun, als wären sie fertige Produkte;
• interne Tools können mit klarerer Verantwortung und weniger Verschwendung gebaut werden;
• Legacy-Modernisierung kann in kleineren, testbaren Schritten passieren;
• Dokumentation kann nützlicher werden, weil sie Menschen und Agenten dient;
• Produktteams können Alternativen erkunden, ohne alle davon umzusetzen;
• Entwickler können weniger Zeit mit repetitiver Implementierung verbringen und mehr mit Architektur und Urteilskraft.

Das ist eine starke Chance.

Aber sie braucht Disziplin.

Am meisten profitieren nicht die Unternehmen, die einfach mehr Agenten laufen lassen. Am meisten profitieren die Unternehmen, die Agentengeschwindigkeit mit Produktklarheit, Architektur, Review, Betrieb und Geschäftswert verbinden.

Die praktische Schlussfolgerung

KI-Coding-Agenten werden gut genug, dass sich der alte Engpass verändert.

Das ist eine gute Nachricht.

Aber es bedeutet auch, dass Gründer, CTOs und Product Owner KI-gestützte Entwicklung nicht mehr als persönlichen Produktivitätstrick behandeln sollten. Sie wird Teil des Software-Delivery-Systems.

Die Frage ist nicht mehr:

Kann ein Agent diesen Code schreiben?

Die besseren Fragen lauten:

• Ist das die richtige Änderung?
• Ist die Aufgabe klar genug formuliert?
• Kennt der Agent die Architektur?
• Kann das Team das Ergebnis prüfen?
• Kann das Produkt die Änderung aufnehmen?
• Kann der Betrieb sie tragen?
• Ist das in sechs Monaten noch wartbar?

Bei McDougall Digital helfen wir Teams, diese Fragen zu beantworten und trotzdem mit KI schneller zu werden. Das bedeutet architekturorientierte Umsetzung, praktisches Produkturteil, kontrollierte KI-gestützte Implementierung und Betriebsmodelle, die Agentenoutput nutzbar statt chaotisch machen.

KI-Coding-Agenten haben den Engpass nicht entfernt.

Sie haben ihn dorthin verschoben, wo ernsthafte Softwareteams ohnehin gewinnen oder verlieren:

Koordination, Urteilskraft und die Fähigkeit, Code in ein Produkt zu verwandeln, auf das Menschen sich verlassen können.