Warum erfahrene Entwickler bei KI-Agenten zögern

Sie haben Lizenzen für Coding-Agenten freigegeben, also KI-Werkzeuge, die selbstständig Code schreiben, testen und einreichen. Und ausgerechnet Ihre erfahrensten Entwickler halten sich zurück. Die naheliegende Erklärung lautet: Sie programmieren lieber selbst oder fürchten um ihren Job.

Ein Beitrag auf martinfowler.com aus dem Umfeld von Thoughtworks, dem Beratungsunternehmen hinter dem Technology Radar, hält diese Erklärung für zu bequem. Für Ihre Einführungsentscheidung ist das ein wichtiger Unterschied.

Das eigentliche Bedenken: gebaut ist nicht betrieben

Laut Beitrag zögern gute Entwickler nicht, einen KI-Assistenten zu nutzen. Sie zögern, die Hand ganz vom Steuer zu nehmen und Agenten die gesamte Ausführung zu überlassen. Der Grund ist eine Frage, die sich jeder Entscheider auch stellen sollte: Wie sehr kann man einem System vertrauen, wenn noch niemand Erfahrung damit hat, Software auf diese Weise zu bauen?

Fast alles, was heute in Produktion läuft, wurde von Hand gebaut, von Menschen, denen man vertraut. Was jetzt mit Agenten entsteht, hat noch niemand über Jahre betrieben. Ob ein weitgehend agentengebautes System funktioniert, zeigt sich laut Beitrag erst, wenn es eine Weile in Produktion gelaufen ist und mehrere Änderungsrunden überstanden hat.

Für Sie heißt das: Die Vorsicht Ihrer Senior-Entwickler ist kein Bremsklotz, sondern das Risikomanagement, das Sie für den Betrieb brauchen.

Ein Experiment: eine Woche ohne menschlichen Code

Thoughtworks ließ ein Team aus erfahrenen Entwicklern, Infrastruktur-Beratern und Produktverantwortlichen eine Woche lang so arbeiten, dass niemand selbst Code schrieb. Alles bauten Agenten. Ziel war nicht, eine Airline-Anwendung in einer Woche fertigzustellen, sondern zu verstehen, wie sich die Arbeit des Teams verändert. Das Experiment lief zweimal mit unterschiedlichen Teams.

Drei Beobachtungen sind für die Leitung relevant:

• Die Arbeit verlagert sich. Nach eigener Schätzung verbrachte das Team etwa zwei Drittel der Zeit am Whiteboard: Fachlichkeit klären, Grenzen ziehen, Pläne machen, nach denen Agenten arbeiten können. Ein Drittel floss in den Harness, also das Gerüst aus Tests, Verträgen zwischen Systemteilen, Architekturprüfungen und Auslieferungs-Pipeline.
• Rollen verschieben sich. Am Ende hatte die für das Produkt verantwortliche Person mehr Feature-Code eingebracht als alle anderen im Team.
• Fast fertig ist nicht fertig. Nach einer Woche waren rund 80 Prozent der Anwendung gebaut. Sie lief, aber der Build war häufig rot.

Warum der rote Build die Kernfrage ist

Ein Build ist der automatische Prüflauf, der bei jeder Änderung zeigt, ob die Software noch zusammenpasst. Ist er rot, heißt das eigentlich: anhalten, prüfen, beheben. Ist er ständig rot, schaut niemand mehr hin, und der nächste echte Fehler geht unter. Umgekehrt beruhigt dann auch ein grüner Build nicht mehr.

Die Ursache war im Experiment nicht eindeutig. Infrage kamen zu viele parallel arbeitende Agenten, die sich gegenseitig in die Quere kamen, ein noch nicht ausreichend modulares System oder Änderungen, die schneller eintrafen, als die Prüfungen fertig wurden. Der Beitrag nennt auch die Größe der Arbeitspakete als offene Frage: Größere Pakete beschleunigen die Entwicklung, aber hält die Prüfstrecke damit Schritt?

Für Sie als Entscheider ist das die Stelle, an der Geschwindigkeit in Risiko umschlägt. Wie Sie das messen, behandelt der Beitrag zu Kennzahlen für KI-Coding.

Was das für Ihre Entscheidung bedeutet

Der Beitrag formuliert eine klare Aufgabe für die Leitung: Unterscheiden Sie berechtigte Bedenken von bloßem Widerstand gegen Veränderung. Und schaffen Sie echten Raum für Experimente, mit Zeit, mit der Erlaubnis, Fehler zu machen, und ohne den Erfolg an der Menge des von Agenten erzeugten Codes zu messen.

Daraus ergeben sich drei Fragen für Ihre nächste Runde mit der Entwicklungsleitung:

• Wer kartiert das Gelände? Setzen Sie Ihre skeptischen Senior-Entwickler in das Pilotteam, statt sie zu übergehen.
• Wie gut ist unser Harness? Fragen Sie, welche Tests, Prüfungen und Pipelines es gibt, bevor Agenten mehr Freiheit bekommen.
• Wie sieht Erfolg aus? Legen Sie fest, dass ein Pilot erst gelingt, wenn die Software verlässlich läuft und sich ändern lässt, nicht wenn sie gebaut ist.

Wie Sie eine Einführung insgesamt aufsetzen, ohne nur zu sperren oder alles freizugeben, beschreibt der Beitrag KI-Richtlinie durchsetzen.

Fazit

Die Zurückhaltung erfahrener Entwickler ist ein Signal, kein Hindernis. Sie zeigt auf die Lücke zwischen schnell gebaut und verlässlich betrieben. Wer diese Lücke ernst nimmt und die Skeptiker an der Einführung beteiligt, trifft die bessere Entscheidung.

Sie wollen mit Ihrem Führungsteam klären, wie viel Freiheit Agenten in Ihrer Entwicklung bekommen sollen und woran Sie den Erfolg messen? Fragen Sie ein Inhouse-Seminar an oder melden Sie Ihr Interesse am offenen Seminar an.