Warum KI-Coding-Agenten-Piloten vor der Produktion scheitern

KI-Coding-Agenten sind sehr gut darin, eine erste Demo selbstverständlich wirken zu lassen.

Ein Gründer beschreibt ein Produkt. Ein Tool erzeugt ein Repository. Claude Code oder Cursor editiert Dateien, behebt Fehler, ergänzt Tests, öffnet einen Pull Request und deployed vielleicht sogar in eine Preview-Umgebung. Lovable oder ein Design-to-Code-Workflow macht aus einer Idee einen klickbaren Screen. Ein kleines internes Tool entsteht an einem Nachmittag.

Das ist nützlich. Es ist aber nicht der schwierige Teil.

Der schwierige Teil beginnt, wenn das Team fragt, ob dieser Workflow ein ernsthaftes Produkt berühren darf. Funktioniert er in einer bestehenden Codebasis? Respektiert er die Architektur? Kommt er mit unsauberen Anforderungen, wechselnden Prioritäten, Authentifizierung, Datenmigrationen, Compliance, Monitoring und Übergabe klar? Kann ein menschliches Team verstehen, was geändert wurde und warum? Kann sich das Unternehmen noch auf das Ergebnis verlassen, wenn die beeindruckende Demo vorbei ist?

Genau diese Frage taucht in der aktuellen X-Diskussion rund um KI-Coding-Agenten häufiger auf. Die Debatte verschiebt sich von “Schau, was das Tool gebaut hat” zu “Warum schaffen so viele Piloten den Weg in die Produktion nicht?” Die wiederkehrende Antwort ist nicht, dass die Modelle nutzlos sind. Sie lautet: Teams verwechseln Codegenerierung mit Softwarelieferung.

Das ist nicht dasselbe.

Für Gründer, CTOs, Product Owner und Mittelstandsteams ist diese Unterscheidung wichtig. KI-unterstützte Entwicklung kann Produktarbeit deutlich beschleunigen. Der Wert entsteht aber dann, wenn der Pilot von Anfang an als Produktionssystem gedacht wird, nicht wenn eine Demo nachträglich eines werden soll.

Die Demo versteckt die teuren Teile

Die meisten Demos sind für einen sauberen Pfad optimiert.

Die Aufgabe ist klein. Die Daten sind harmlos. Das Repository ist neu oder vereinfacht. Niemand muss fünf Jahre Produktentscheidungen bewahren. Es gibt keine Compliance-Prüfung, keinen verärgerten Kunden, keine halb migrierte Datenbank, kein Legacy-Modul, das nur eine Person versteht, kein Release-Fenster, kein internes Gerangel, kein Support-Team und keinen Audit-Trail.

Zum Lernen ist das völlig in Ordnung. Zur Beurteilung von Produktionsreife reicht es nicht.

Echte Software hat Gewicht. Sie hat Abhängigkeiten, Einschränkungen, Gewohnheiten, Kompromisse und Nutzer, denen der Build-Prozess egal ist, solange das System nächsten Monat zuverlässig funktioniert. An diesem Punkt werden viele KI-Coding-Piloten enttäuschend. Die erste Version kommt schnell. Danach verbringt das Team deutlich mehr Zeit damit, sie zu verstehen, umzubauen, abzusichern, zu erklären und zu betreiben.

Das Scheitern ist selten spektakulär. Es ist meistens langsam und praktisch:

• niemand weiss, wem die Änderungen des Agenten gehören;
• der Code funktioniert, passt aber nicht zur Architektur;
• duplizierte Muster verteilen sich über die Codebasis;
• Tests existieren, schützen aber nicht das wichtige Verhalten;
• Zugangsdaten und Umgebungsrechte sind zu breit;
• Pull Requests werden zu gross, um sie sauber zu prüfen;
• der Agent wiederholt Fehler, weil kein dauerhaftes Projektgedächtnis existiert;
• Logs, Tickets und Tool-Ausgaben werden als Anweisungen statt als Hinweise behandelt;
• niemand hat definiert, wann der Agent stoppen und einen Menschen fragen soll.

Deshalb kann ein erfolgreicher KI-Coding-Pilot nicht nur an erzeugtem Output gemessen werden. Output ist der sichtbarste Teil. Die teuren Teile sind Urteilskraft, Kontext, Verantwortung und Betrieb.

Produktionsreife ist ein Betriebsmodell

Teams fragen oft, welches KI-Coding-Tool das beste ist.

Das ist eine verständliche Frage, aber nicht die erste. Für ernsthafte Produktarbeit ist die bessere Frage: Welches Betriebsmodell umgibt das Tool?

Ein KI-Coding-Agent ist nicht nur Autocomplete. Er kann das Repository lesen, Commands ausführen, Pakete installieren, Fehler analysieren, Dateien ändern, externe Tools aufrufen, Branches öffnen, Issues zusammenfassen und Architekturänderungen vorschlagen. In manchen Setups interagiert er mit Datenbanken, Cloud-Systemen, Observability-Plattformen und Deployment-Workflows.

Damit ist der Agent Teil des Delivery-Systems.

Wenn das Delivery-System schwach ist, verstärkt der Agent diese Schwäche. Wenn das Delivery-System diszipliniert ist, kann der Agent disziplinierte Arbeit verstärken.

Ein produktionsreifer KI-Coding-Pilot braucht Antworten auf normale Engineering-Fragen:

• Welche Aufgaben darf der Agent übernehmen?
• Welche Bereiche der Codebasis sind tabu?
• Welche Commands dürfen automatisch laufen, und welche benötigen Freigabe?
• Welcher Kontext ist vertrauenswürdig, und was ist nur ein Hinweis?
• Wer reviewt Änderungen, die vom Agenten stammen?
• Wie werden Architekturentscheidungen dokumentiert?
• Wie werden Tests ausgewählt, erzeugt und bewertet?
• Was passiert, wenn der Agent mitten in der Aufgabe scheitert?
• Wie werden Kosten, Rate Limits und lange Sessions kontrolliert?
• Welche Metriken zeigen, ob der Workflow Lieferung verbessert oder nur versteckte Aufräumarbeit erzeugt?

Diese Fragen sind keine Bürokratie. Sie sind der Unterschied zwischen Experiment und Fähigkeit.

Bei McDougall Digital wird KI-unterstützte Entwicklung genau an dieser Stelle interessant für ernsthafte Kunden. Die Tool-Auswahl ist wichtig. Der grössere Wert liegt aber darin, eine Arbeitsweise zu entwerfen, die KI-Geschwindigkeit in wartbaren Produktfortschritt verwandelt.

Das erste Produktionsrisiko ist Scope

KI-Coding-Agenten werden oft mit vagen Aufgaben eingeführt, weil das Interface dazu einlädt. “Bau mir ein Dashboard.” “Repariere das Onboarding.” “Refactore den Billing-Flow.” “Mach das produktionsreif.”

Solche Prompts können Bewegung erzeugen. Bewegung ist aber nicht dasselbe wie Fortschritt.

Produktionsarbeit braucht Scope. Der Agent sollte wissen, welches Problem er löst, was er nicht ändern darf, welche Kompromisse akzeptabel sind und welche Hinweise beweisen, dass die Aufgabe erledigt ist. Ohne das löst der Agent möglicherweise das sichtbare Symptom und beschädigt das System drumherum.

Das ist besonders gefährlich in reifen Produkten. Ein Feature ist selten nur ein Screen. Es berührt Rechte, Analytics, Support-Prozesse, Edge Cases, Datenhoheit, Lokalisierung, Rechnungen, E-Mails, Performance, Accessibility und interne Erwartungen. Die Codeänderung ist nur ein Teil der Produktänderung.

Ein besserer Pilot beginnt mit engeren, überprüfbaren Aufgaben:

• einen kleinen internen Workflow hinter einem bestehenden Berechtigungsmodell ergänzen;
• eine bekannte Komponente verbessern, ohne öffentliches Verhalten zu ändern;
• Tests um ein fragiles Modul aufbauen, bevor es refactored wird;
• eine schlecht verstandene Integration dokumentieren;
• einen Prototyp in einer Sandbox bauen und danach manuell entscheiden, was ins Hauptprodukt wandert;
• Migrationspläne und Review-Checklisten erstellen, bevor Daten berührt werden.

Das wirkt weniger spektakulär als eine One-Prompt-Produktdemo. Es übersteht aber deutlich eher den Kontakt mit einem echten Unternehmen.

Review-Kapazität wird zum Engpass

KI-Coding verändert Engineering-Arbeit, weil es die Menge an plausibel wirkendem Code erhöht, die ein Team erzeugen kann.

Das klingt offensichtlich positiv. Oft ist es das auch. Mehr Code ist aber nur nützlich, wenn das Team ihn reviewen, verstehen, testen, mergen und warten kann. Sonst verschiebt sich der Engpass vom Schreiben zum Beurteilen von Code.

Aktuelle KI-Coding-Workflows zeigen diese Richtung bereits. Die interessanten Werkzeuge drehen sich nicht mehr nur um Generierung. Sie drehen sich um Diffs, selektive Übernahme, Multi-Agent-Review, Reproduktion in Sandboxes, CI-Gates und Wege, wie Menschen nachvollziehen können, was passiert ist.

Das ist der richtige Weg.

Für Produktionsteams ist Review kein zeremonieller Schritt nach der “eigentlichen” Arbeit. Im Review betreten Produkturteil, Architektur, Sicherheit, Wartbarkeit und Teamwissen das System. Wenn agentengenerierte Pull Requests zu breit, zu häufig oder zu undurchsichtig sind, hat das Team keine Delivery-Kapazität gewonnen. Es hat eine Review-Schuldenmaschine gebaut.

Nützliche Piloten begrenzen deshalb das Review-Problem:

• Agentenaufgaben klein genug halten, dass sie sauber prüfbar bleiben;
• den Agenten vor der Änderung die geplante Umsetzung erklären lassen;
• eine Zusammenfassung berührter Dateien, Risiken und Annahmen verlangen;
• mechanische Änderungen von Verhaltensänderungen trennen;
• Tests als Hinweis nutzen, nicht als Ersatz für Urteilskraft;
• beeindruckenden Output ablehnen, wenn er nicht zum Produkt passt.

Die beste menschliche Rolle in KI-unterstützter Entwicklung ist nicht passives Abnicken. Sie ist aktive Führung.

Senior Engineers, Product Owner und technische Gründer werden wertvoller, wenn sie das Problem klar definieren, die Architektur schützen und entscheiden können, welche generierte Arbeit ins Produkt gehört.

Sicherheit ist keine Schlussprüfung

Viele Teams behandeln Sicherheit als etwas, das nach einem funktionierenden Prototyp geprüft wird.

Bei KI-Coding-Agenten ist das zu spät.

Die Sicherheitslage eines agentischen Workflows wird dadurch bestimmt, was der Agent sehen kann, was er berühren kann und was er glauben darf. Ein Tool mit breitem Dateisystemzugriff, Shell-Zugriff, Paketmanager-Zugriff, Environment-Variablen, Repository-Rechten, Cloud-Zugangsdaten oder Produktionslogs hat ein völlig anderes Risikoprofil als ein Tool, das auf einen Sandbox-Branch und eine enge Aufgabe begrenzt ist.

Der Agent braucht keine böse Absicht, um Risiko zu erzeugen. Eine falsche Annahme reicht. Oder eine kopierte Anweisung aus einer unvertrauenswürdigen Quelle. Oder eine fragile Abhängigkeit. Oder ein zu breites Credential.

Für deutsche und europäische Teams ist das kein abstraktes Thema. Datenschutz, Vendor Risk, Zugriffskontrolle, Auditierbarkeit und langfristige Wartbarkeit gehören zur Kaufentscheidung. Mittelständische Unternehmen haben oft kleinere Teams, aber ernste Verpflichtungen. Sie können sich keinen Workflow leisten, bei dem niemand erklären kann, wie Code entstanden ist, welche Daten sichtbar waren oder warum eine riskante Änderung akzeptiert wurde.

Ein Produktionspilot sollte Sicherheit deshalb von Anfang an einbauen:

• eingeschränkte Zugangsdaten;
• getrennte Sandbox- und Produktionsumgebungen;
• explizite Freigabe für destruktive Aktionen;
• keine Kundendaten in lockeren Coding-Sessions;
• Logs von Tool-Aufrufen und generierten Änderungen;
• Review-Regeln für Auth, Payments, Berechtigungen, Datenverarbeitung, Migrationen und Infrastruktur;
• klare Regeln für externe Tools und verbundene Dienste.

Das nimmt den Produktivitätsgewinn nicht weg. Es schützt ihn.

Der nützliche Pilot hat einen Reifeweg

Ein häufiger Fehler ist, einen KI-Coding-Piloten als Ja-oder-Nein-Experiment zu behandeln.

Das Team probiert ein Tool, sieht beeindruckenden Output und erklärt entweder die Zukunft für angekommen oder hört nach dem ersten verwirrenden Pull Request still wieder auf. Beide Reaktionen sind zu grob.

Ein besserer Pilot hat Stufen.

Zuerst nutzt das Team den Agenten für risikoarme Arbeit, bei der Geschwindigkeit hilft und Fehler billig sind: Dokumentation, Testgerüste, isolierte Komponenten, interne Skripte, explorative Prototypen und Codebase-Analyse.

Dann geht es in kontrollierte Produktarbeit: kleine Bugfixes, Refactorings mit Tests, interne Tools, Feature-Slices hinter Flags und review-intensive Implementierungsaufgaben.

Erst danach sollte der Agent breiter an Delivery teilnehmen, wenn der umgebende Workflow bereit ist: Architektur-Notizen, Aufgabenbeschreibung, Teststrategie, begrenzte Rechte, Observability, Rollback-Pfade und Ownership.

Der Schlüssel ist nicht, ob der Agent Code erzeugen kann. Der Schlüssel ist, ob die Organisation diesen Code verantwortlich aufnehmen kann.

Das ist der Test auf Produktionsreife.

Was Kunden vor der Skalierung fragen sollten

Bevor ein KI-Coding-Pilot ausgeweitet wird, sollte ein Gründer oder CTO einige unbequeme Fragen stellen.

Können wir zeigen, in welchen Teilen der Codebasis Agentenarbeit erlaubt ist?

Wissen wir, welche Workflows schneller wurden und welche nur Arbeit ins Review verschoben haben?

Kann ein neuer Engineer agentengeschriebene Änderungen verstehen, ohne den Agenten zu fragen?

Beweisen unsere Tests Geschäftsverhalten, oder nur, dass generierter Code läuft?

Wissen wir, worauf der Agent zugreifen kann?

Können wir sauber wiederherstellen, wenn er eine falsche Änderung macht?

Werden Produktentscheidungen weiterhin von verantwortlichen Menschen getroffen?

Haben wir Delivery-Risiko reduziert, oder nur Codevolumen erhöht?

Diese Fragen sind einfach, aber sie zeigen den Unterschied zwischen Demo-Geschwindigkeit und Produktionsfähigkeit.

Das eigentliche Versprechen ist disziplinierte Beschleunigung

KI-Coding-Agenten verdienen ernsthafte Aufmerksamkeit.

Sie können Teams helfen, Ideen schneller zu erkunden, repetitive Arbeit zu reduzieren, Testabdeckung zu verbessern, Implementierungsoptionen zu erzeugen, alte Codebasen zu modernisieren und interne Tools zu bauen, die sonst nie auf die Roadmap gekommen wären.

Aber am meisten profitieren nicht die Teams, die Agenten als magische Entwickler behandeln. Am meisten profitieren die Teams, die eine disziplinierte Delivery-Umgebung um sie herum bauen.

Das bedeutet: Architektur vor Automatisierung. Klarer Scope vor Generierung. Review vor Merge. Grenzen vor Zugriff. Produkturteil vor Output-Volumen.

Für viele Unternehmen, besonders im deutschen Markt, ist das der praktische Weg. KI nicht ablehnen, weil sie riskant wirkt. KI nicht blind übernehmen, weil die Demo beeindruckend aussieht. Sondern einen kontrollierten Workflow bauen, in dem KI-unterstützte Entwicklung zu einer echten Fähigkeit wird.

McDougall Digital hilft Teams genau dabei: einschätzen, wo KI-Coding Delivery sicher beschleunigen kann, Architektur und Betriebsmodell darum herum entwerfen und vielversprechende Piloten in wartbare Produktarbeit verwandeln.

Die Frage ist nicht mehr, ob KI Code schreiben kann.

Die Frage ist, ob Ihr Team bereit ist, den Code zu verantworten, den sie schreibt.