Agentic Engineering – also Softwareentwicklung, bei der KI-Agenten mehrstufige Aufgaben weitgehend selbstständig abarbeiten, statt nur einzelne Codezeilen vorzuschlagen – klingt für viele noch nach Experiment. In der Praxis großer Entwicklungsorganisationen ist es das nicht mehr. Bei SAP gehört der Einsatz solcher Werkzeuge zum Alltag; Oliver Nocon und Lukas Heimann berichten über die Erfahrungen daraus. Der Kernsatz ihres Berichts ist unbequem: KI macht Teams schneller – leider auch bei schlechten Prozessen.

Der Verstärker-Effekt

Diese Beobachtung verdient mehr Aufmerksamkeit als jede Diskussion über Modellgrößen oder Tokenpreise. Denn sie beschreibt KI nicht als Lösung, sondern als Multiplikator. Wo Anforderungen klar formuliert, Tests belastbar und Reviews verbindlich sind, erhöht ein Agent den Durchsatz. Wo Anforderungen vage bleiben, Testabdeckung Lücken hat und Code-Reviews eher Formsache sind, erhöht derselbe Agent den Durchsatz genauso – nur produziert er dann eben mehr von dem, was ohnehin schon nicht gestimmt hat.

Der Unterschied zu früheren Produktivitätsversprechen liegt im Tempo. Ein Team, das ohne KI drei fragwürdige Pull Requests pro Woche erzeugt, hat Zeit, den Fehler zu bemerken. Ein Team, das dreißig erzeugt, hat diese Zeit nicht. Technische Schulden entstehen nicht langsamer, weil eine Maschine sie schreibt – sie entstehen schneller.

Der Engpass wandert

Wenn die Codeerzeugung günstiger wird, verschiebt sich der Flaschenhals. Er liegt dann nicht mehr im Schreiben, sondern im Prüfen, Verstehen und Verantworten. Genau dort sind viele Organisationen am schwächsten aufgestellt, weil Review-Arbeit selten sichtbar geplant und noch seltener honoriert wird.

Praktisch heißt das: Wer Agenten einsetzt, braucht mehr Review-Kapazität, nicht weniger. Und er braucht Reviews, die inhaltlich stattfinden – nicht als Klick auf einen Freigabe-Button unter einem Änderungssatz, den niemand mehr in vertretbarer Zeit lesen kann. Große, maschinell erzeugte Änderungen sind für menschliche Prüfung besonders unhandlich, weil sie oberflächlich plausibel aussehen und die eigentlichen Probleme in Randfällen, Fehlerbehandlung oder impliziten Annahmen stecken.

Was vor der Einführung stehen sollte

Aus dieser Logik ergibt sich eine unspektakuläre, aber wirksame Reihenfolge: erst die Abläufe, dann die Werkzeuge. Bevor KI-Coding-Workflows in einem Team verankert werden, sollten einige Punkte geklärt sein:

  • Definition of Done: Woran wird festgestellt, dass eine Aufgabe fertig ist – und zwar nachprüfbar, nicht nach Gefühl?
  • Automatisierte Qualitätssicherung: Tests, statische Analyse und Build-Pipeline müssen zuverlässig laufen und aussagekräftig sein. Ein Agent, der gegen eine grüne, aber inhaltsleere Testsuite arbeitet, optimiert auf das falsche Ziel.
  • Verbindliche Reviews: Klare Zuständigkeit, realistische Größenobergrenzen für Änderungen, dokumentierte Ablehnungsgründe.
  • Architektur- und Codekonventionen: Was nicht schriftlich festgelegt ist, kann ein Agent nicht einhalten – er erfindet dann eine eigene Variante.
  • Verantwortlichkeit: Wer haftet fachlich für Code, den ein Agent erzeugt hat? Die Antwort darf nicht "das Tool" lauten.

Prozessqualität wird messbar teuer

Interessant ist der ökonomische Nebeneffekt. Schwache Prozesse waren bisher vor allem ein Ärgernis, das sich über Monate in Verzögerungen und Nacharbeit ausdrückte – diffus und schwer zuzuordnen. Mit hoher Änderungsgeschwindigkeit werden sie zu einem unmittelbar spürbaren Kostenfaktor. Das ist unangenehm, aber auch eine Chance: Organisationen, die bisher keinen Anlass sahen, ihre Entwicklungsabläufe aufzuräumen, bekommen nun einen sehr konkreten.

Für Entscheiderinnen und Entscheider folgt daraus eine andere Fragestellung als die übliche. Nicht "welches KI-Werkzeug beschaffen wir?", sondern: Halten unsere Abläufe eine Verdopplung des Änderungsvolumens aus? Wenn die ehrliche Antwort nein lautet, ist die Einführung von Agenten kein Fortschritt, sondern eine Beschleunigung in die falsche Richtung.

Schrittweise statt flächendeckend

Bewährt hat sich erfahrungsgemäß ein enger Zuschnitt am Anfang: ein Team, ein klar abgegrenzter Bereich der Codebasis, eine überschaubare Klasse von Aufgaben. Dort lässt sich beobachten, wo Reibung entsteht – meist nicht bei der Codeerzeugung selbst, sondern an den Übergabepunkten: unklare Tickets, fehlende Testdaten, unentschiedene Architekturfragen, Abhängigkeiten zu anderen Teams.

Diese Reibungspunkte zu beheben, ist die eigentliche Arbeit. Sie zahlt sich unabhängig davon aus, welches Modell im nächsten Jahr aktuell ist, und sie ist der Grund, warum der Bericht aus dem Konzernalltag mehr ist als eine Anekdote: Er beschreibt keine Werkzeugfrage, sondern eine Organisationsfrage.

Was das für Projekte bedeutet

Für Web- und Softwareprojekte heißt das, die Prioritäten umzustellen: Wer KI-gestützte Entwicklung einführen will, investiert zuerst in Testabdeckung, Review-Disziplin und klare Anforderungen – nicht in Lizenzen. Erst dann wird aus Geschwindigkeit auch Qualität, statt nur mehr Volumen. Und in Ausschreibungen und Dienstleisterauswahl lohnt es sich, weniger nach eingesetzten KI-Tools zu fragen als danach, wie ein Team seine Ergebnisse prüft und verantwortet.

Quellen