Es gibt Abende, an denen ich mich zwischen Couch und Aufbruch entscheiden muss. Vergangene Woche fiel mir die Entscheidung leicht: Bei codecentric in Dortmund stand ein Tech&Talk an, und schon das Thema hatte mich gepackt – „Fire and Forget? Wie weit ein Coding-Agent dein Issue wirklich allein löst“. Dazu kommt, dass die Atmosphäre bei diesen Events einfach angenehm ist: gute Gespräche vor und nach dem Vortrag, interessante Leute, und ja, auch die gastronomische Versorgung muss sich nicht verstecken. Ich musste mich zu diesem Abend nicht überwinden. Ich habe mich darauf gefreut.
Was mich aber wirklich hinzog: In den sozialen Medien sehe ich täglich Versprechen, was KI in der Softwareentwicklung angeblich alles kann. Echte Einblicke in die Praxis – mit allen Herausforderungen und Fallstricken – sind dagegen selten. Genau das versprach dieser Vortrag: der Erfahrungsbericht eines Teams, das real mit KI-Agenten Software baut. Und wer Entscheidungen über den KI-Einsatz in der eigenen Organisation treffen muss, braucht genau solche Berichte – nicht die Hochglanzversion.
Der Vortrag ist übrigens vollständig auf YouTube verfügbar – aus meiner Sicht gut investierte 60 Minuten.
Erst mal gescheitert – und genau das war das Spannende
Dustin Chabrowski, CTO des Dortmunder Startups SIMPL Technologies, berichtete offen aus dem Maschinenraum. Die Idee seines Teams klang nach dem, was derzeit überall zu lesen ist: Ein KI-Agent bekommt ein Issue zugewiesen, checkt den Code aus, implementiert, testet – und am Ende liegt ein fertiger Pull Request bereit, der nur noch reviewt und gemergt werden muss. Fire and Forget eben.
Die Realität sah zunächst anders aus. Die ersten Pull Requests waren, freundlich formuliert, bereit für die Tonne. Der Agent ignorierte explizite Anweisungen, führte nur einen Teil der Tests aus und erklärte sich nach dem kleinsten Teilerfolg für fertig.
Hat mich das überrascht? Nein. In meiner eigenen Arbeit habe ich erlebt, wie nützlich KI-gestützte Entwicklung sein kann – und ich habe ebenso viele Grenzen gesehen. Es hätte mich sehr gewundert, wenn autonome Softwareentwicklung im ersten Anlauf funktioniert hätte. Dass es zunächst schiefging, entsprach meiner Erwartung. Spannend war etwas anderes: wie sich das Team Schritt für Schritt ein erfolgreicheres Setup erarbeitet hat. Drei Stellhebel haben dabei den Unterschied gemacht:
- Agententaugliche Issues: widerspruchsfrei, mit klarem Kontext, verifizierbar – denn bei einem autonomen Agenten ist das Issue der gesamte Kontext.
- Ein vorgeschalteter „Grounding Agent“: Er prüft jede Aufgabe gegen die Codebase auf Lücken und Widersprüche, bevor sie an den eigentlichen Agenten geht.
- Eine vollwertige Laufzeitumgebung: reproduzierbare Setups, echte Testdaten, vollständige Verifikationsmöglichkeiten – statt einer halbfertigen Sandbox.
Und siehe da: Für kleine, klar umrissene Aufgaben funktioniert Fire and Forget inzwischen tatsächlich.
Das Bemerkenswerte daran: Vieles davon ist klassisches Handwerk. Saubere Anforderungen, klare Konventionen, einheitliche Strukturen, reproduzierbare Umgebungen. Fast könnte man sagen, die KI zwingt Teams dazu, endlich das zu tun, was schon immer richtig gewesen wäre. Für alle, die Entwicklungsorganisationen verantworten, ist das eine gute Nachricht: Die Investition in handwerkliche Qualität zahlt doppelt ein – sie macht Teams besser und sie ist die Eintrittskarte für wirksame KI-Unterstützung.
Was davon in gewachsenen Systemlandschaften ankommt
In meiner Berufslaufbahn habe ich beides kennengelernt – Startups ebenso wie Konzerne. Den weitaus größten Teil meiner über zwanzig Jahre habe ich allerdings in größeren Organisationen mit gewachsenen Systemlandschaften verbracht: bei Versicherungen, Energieversorgern, in der Industrie. Die naheliegende Frage an diesem Abend war für mich daher: Lässt sich das übertragen?
Ich bin überzeugt: Agentic Coding ist in vielen großen Unternehmen längst Realität. Die Lernkurve ist steil, und niemand geht von null auf hundert. Teams tasten sich vor, lernen aus den ersten Erfahrungen, entwickeln sich weiter. Das Grundprinzip aus Dortmund gilt dabei auch im Konzern: Je handwerklich sauberer eine solche Umgebung aufgesetzt und mit Kontext und klaren Spezifikationen gefüttert wird, desto erfolgreicher kann sie entwickeln und das Team unterstützen.
Der Unterschied liegt in den Startbedingungen. Große Unternehmen haben eine bestehende Entwicklungslandschaft, eine gewachsene Entwicklungskultur – und sehr viel Bestandscode. Die Einführung KI-getriebener Entwicklung ist damit keine Tool-Entscheidung, sondern eine Gestaltungsaufgabe: Beginnt man mit neuen Projekten? Lässt man KI schrittweise in Bestandsumgebungen wirken? Beides hat seine Berechtigung – entscheidend ist aus meiner Erfahrung, dass jeder Schritt klein genug ist, um daraus zu lernen, und dass das Team den Code und das Setup jederzeit versteht und unter Kontrolle hat. Genau diese Kombination macht es möglich, gleichzeitig schnell zu sein und Qualität zu liefern. Wer eines von beidem opfert, zahlt später drauf.
Die eigentliche Frage: Wer kontrolliert hier wen?
Vor der technischen Entwicklung selbst habe ich keine Angst. Der Abend in Dortmund hat für mich noch einmal deutlich gemacht, wie wichtig menschliche Vernunft in solchen Projekten bleibt. Ganz ohne sie funktioniert es nicht – und das wird auf absehbare Zeit so bleiben.
Was mich mehr beschäftigt, ist eine strukturelle Frage: Wie verteilen sich künftig die Machtverhältnisse zwischen Menschen, Unternehmen und KI-Anbietern? In den Gesprächen am Rande des Meetups ging es auch um Praktisches: Manche Entwickler verbrauchen wenige KI-Tokens pro Tag, andere sehr viele – und kosten damit unterschiedlich viel Geld. Unternehmen werden entscheiden müssen, wer welches KI-Budget bekommt. Und die großen KI-Anbieter verdienen zuverlässig mit, wann immer irgendwo Software entsteht. Das schafft Abhängigkeiten – und Abhängigkeiten sind für Organisationen mit kritischer Infrastruktur und regulatorischen Pflichten kein Randthema, sondern ein Risikofaktor erster Ordnung.
Deshalb halte ich beim KI-Einsatz einen Grundsatz für zentral: die Exit-Fähigkeit. Ein Setup ist dann gesund, wenn das Team jederzeit auch ohne KI weiterarbeiten könnte – oder die darunterliegende KI austauschen kann. Konkret heißt das für mich:
- Code klein und verständlich halten – und zwar dauerhaft, nicht nur zu Projektbeginn.
- Keine Prozesse etablieren, die Abhängigkeit zementieren – jede Automatisierung braucht einen gangbaren Rückweg.
- Regelmäßig durchspielen, wie es ohne KI weiterginge – dieselbe Denkweise, die sich bei Cloud-Strategien und Sourcing-Entscheidungen längst bewährt hat.
Ein Punkt liegt mir dabei besonders am Herzen: Strategie und Implementierungsplanung sollten nicht ausgerechnet von den Unternehmen stammen, deren KI-Dienste anschließend genutzt werden. Das wäre Abhängigkeit mit Ansage. Digitale Souveränität entsteht dort, wo eigene IT-Kompetenz im Haus die strategischen Vorgaben entwickelt – und externe Anbieter das umsetzen, was das Unternehmen sich wünscht. Und nicht dort, wo freundliche Füchse entspannt darauf warten, einen verspeisen zu können.
Wer versteht in zehn Jahren noch den Code?
Es gab an diesem Abend einen Befund, der mich über den Vortrag hinaus beschäftigt hat: Studien zeigen, dass mit intensiver KI-Nutzung das Codeverständnis in Teams messbar sinkt, während Reviews deutlich länger dauern und die Zahl der Incidents steigt. Dustins Team hält bewusst dagegen – bei SIMPL gilt weiterhin: Wer baut, reviewt und deployt, muss verstehen, was passiert.
Dieser Befund führt zu einer Frage, die weit über einzelne Teams hinausreicht: Wie entsteht eigentlich künftig das Urteilsvermögen, das wir gerade jetzt so dringend brauchen? Die Erfahrung, aus der heutige Senior-Entwickler und Architekten ihre Einschätzungen speisen, ist über Jahre entstanden – durch selbst geschriebenen Code, selbst gemachte Fehler, selbst gelöste Probleme. Ich weiß aus meiner eigenen Laufbahn, wie viel von meinem heutigen Urteilsvermögen genau auf diesem Weg entstanden ist. Wenn die Implementierung zunehmend automatisiert wird, stellt sich für jede Organisation die Frage, wie die nächste Generation dieses Fundament aufbaut.
Meine Überzeugung: Die Grundlagen werden wichtiger, nicht unwichtiger. Mathematik. Sauberes Programmieren mit theoretischem Fundament und Best Practices. Die Fähigkeit, Probleme selbst zu lösen, bevor man sie delegiert. Sich nicht zu früh auf KI zu verlassen – und vor allem: nicht faul im Denken zu werden. Dazu kommt, was in einer Welt automatisierter Implementierung sogar an Wert gewinnt: Sprache und Kommunikation, Empathie, Allgemeinbildung, die eigene Leidenschaft. Wer Anforderungen präzise formulieren, Lösungen bewerten und begründet „Nein“ sagen kann, wird gebraucht – von Menschen wie von Agenten.
Für Unternehmen heißt das übrigens auch: Nachwuchsentwicklung ist ein strategisches Thema der KI-Einführung, kein HR-Nebenschauplatz. Juniors, die nur noch Agenten-Output durchwinken, werden nie zu den Seniors, die eine Organisation in zehn Jahren braucht.
Mein Fazit
Der Abend in Dortmund hat für mich drei Dinge bestätigt:
- KI-Agenten liefern heute schon echten Mehrwert – wenn das Handwerk stimmt. Der Erfolg entsteht nicht durch das Werkzeug, sondern durch saubere Anforderungen, klaren Kontext und eine durchdachte Umgebung.
- Kontrolle und Verständnis sind nicht verhandelbar. Wer Code und Setup jederzeit versteht, kann gleichzeitig schnell sein und Qualität liefern – und bleibt exit-fähig gegenüber jedem Anbieter.
- Die entscheidenden Fragen sind nicht technischer Natur. Wer behält das Verständnis? Wer behält die Kontrolle? Wer entwickelt das Urteilsvermögen von morgen?
Wir haben an diesem Abend über Coding-Agenten, Kontext-Engineering und Tokenbudgets gesprochen – und am Ende geht es um Denken, Verstehen und Verantwortung. Das war schon vor der KI so. Mit ihr gilt es umso mehr.
Wie sind Ihre Erfahrungen mit KI-Agenten in der Softwareentwicklung – und wie gehen Sie mit der Frage nach Kontrolle und Abhängigkeit um? Ich freue mich über den Austausch.
Transparenz-Hinweis: Ich nutze bei meinen Texten grundsätzlich KI-Unterstützung – so gehe ich dabei vor.