Zum Inhalt springen

Wissensbasis

State of AI-Native Engineering Report

Augment Code hat 219 Engineering-Führungskräfte befragt: Rund die Hälfte ihres Codes generiert KI, doch nur 57 haben ihr Code-Review geändert, noch weniger Rollen, Onboarding oder Messung. 55% sorgen sich um das gemeinsame Verständnis der Codebase. Das ist die größte Sorge und die, gegen die am wenigsten passiert.

Verfasst von

Aktualisiert:

Belege 7

Unsere Position. Die Lücke, die diese Umfrage misst, sehen wir in den meisten Rollouts: Sie ändern die Codebase, aber nicht das Team. Agentic Engineering heißt, dass sich Codebase, Engineers, Reviews und Nicht-Engineers gemeinsam bewegen (Codebase gegen Menschen und Prozesse (öffnet in einem neuen Tab)). Sorgen wegen KI sind kein Trainingsproblem, denn über Rollen entscheidet das Management. Deshalb kommen sie vor den Tools auf die Agenda.

DORA und Faros messen, was mit dem Code passiert. Diese Umfrage misst, was mit der Organisation passiert, und findet: Sie hat sich nicht bewegt. Befragt wurden 219 Engineering-Führungskräfte von Manager:innen bis zu CTOs, die meisten mit Teams unter 50 Personen (Augment Code - The State of AI-Native Engineering in 2026 (öffnet in einem neuen Tab)). Die Stichprobe wurde über Netzwerke von Engineering-Führungskräften rekrutiert und ist KI-affin verzerrt. Außerdem verkauft Augment eine Plattform für Agent-Orchestrierung. Lest die Zahlen als Richtung, von Führungskräften, die weiter sind als der Durchschnitt.

Wie viel Code generiert KI, und vertrauen die Führungskräfte ihm?

In diesen Organisationen generiert KI inzwischen rund die Hälfte des gesamten Codes (Mittelwert 48,3%, Median 48%). Menge ist aber keine Zuversicht. 39% der Befragten sind besorgt oder sehr besorgt, ob sie noch mit Zuversicht ausliefern, wenn Agents mehr Code schreiben und PRs freigeben. Nur 12 von 219 sorgen sich gar nicht. Ihre Wettbewerbsfähigkeit bewerten die Führungskräfte im Ausblick höher als im Rückblick (3,96/5 gegen 3,66/5). Gleichzeitig vertrauen sie dem nicht, was sie ausliefern. Beides gilt zugleich, bei denselben Menschen.

Die Telemetrie von CircleCI zeigt dasselbe aus Sicht der Pipeline (The 2026 State of Software Delivery (öffnet in einem neuen Tab)). Über 28 Millionen CI-Workflows stieg der durchschnittliche Durchsatz im Jahresvergleich um 59%. Die Erfolgsquote auf dem Main-Branch fiel dagegen auf 70,8%, den niedrigsten Wert seit fünf Jahren. Es entsteht mehr Code, und mehr davon bricht.

Was bereitet Engineering-Führungskräften die größte Sorge?

55% der Befragten sind besorgt oder sehr besorgt, dass Menschen das gemeinsame Verständnis dafür verlieren, wie sich die Codebase entwickelt. Das ist das lauteste Signal im Datensatz. Und gerade dagegen tun die wenigsten Organisationen etwas. Die Umfrage lässt sich auf ein Drei-Schichten-Modell der Systemgesundheit abbilden: Technical Debt, Cognitive Debt und Intent Debt. Wie das Modell funktioniert, steht auf Qualität und Verifikation.

Das Verhaltensrisiko darunter hat einen Namen. Forschung aus Wharton unterscheidet kognitives Offloading von kognitiver Surrender:

  • Offloading ist strategisch. Ihr wisst, was ihr delegiert habt.
  • Surrender ist passiv. Ihr hört auf, selbst zu urteilen, weil das Ergebnis richtig aussieht und das Prüfen teuer ist.

Surrender wirkt wie Effizienz, bis etwas bricht und niemand die Ursache mehr zurückverfolgen kann.

Was haben Organisationen tatsächlich geändert?

Bewegt haben sich nur die zwei Artefakte, die am nächsten am Code liegen. Von 219 Führungskräften haben 57 ihr Code-Review formal geändert und 57 ihre Specs. Alles andere steht still:

  • Produktivitätsmessung: 32
  • Engineering Operations: 24
  • Rollendefinitionen: 19
  • Onboarding: 15

Für alle, die eine KI-Transformation verantworten, ist das der schärfste Befund. Die Messlatte beim Hiring hat sich schon verschoben. Führungskräfte stellen das Bewerten und Verifizieren von KI-generiertem Code, das Orchestrieren von Agents und Produkturteil inzwischen über klassisches Programmieren. Stellenbeschreibungen, Interviewprozesse, Karrierestufen und Onboarding-Pfade schreiben diese Messlatte fest, und sie haben sich nicht bewegt. Specs, Karrierestufen und die Definition von “gut” sind noch für die alte Welt geschrieben, für Menschen wie für Agents.

Genau in dieser Lücke verstärken sich die drei Schulden. Wird der Code weniger verstanden und sind die Specs veraltet, die sein Sollverhalten beschreiben, bleiben technische Schulden unsichtbar, bis etwas bricht.

Wie nehmen Engineers den Wandel auf?

63% der Führungskräfte sagen, dass Engineers in ihrem Team die Sorge äußern, ihre Skills verlören an Relevanz. In großen Teams (201 bis 1.000 Engineers) sind es 89%, in den kleinsten 55%. Die Angst wächst mit der Größe der Organisation. Dagegen stehen 19, die Rollendefinitionen geändert haben, und 15, die das Onboarding geändert haben. Der Schluss ist unbequem und direkt: Die meisten Manager:innen fangen diese Gespräche auf und tun dann nichts. Gefühle ohne Antwort verschwinden nicht. Sie tauchen ab, als passiver Widerstand und stiller Rückzug.

Zwei Formulierungen aus dem Team hinter dem Report benennen den Wandel genau. Engineers beschreiben den Weg vom “proud builder” zum “proud coordinator”. Und das Ziel heißt nicht “ticket to PR”, sondern “intent to production”.

Der Headcount bricht derweil nicht ein. 81 halten ihn stabil, 68 erhöhen ihn leicht und 14 deutlich. Dem stehen 30 gegenüber, die leicht reduzieren, und 6, die deutlich reduzieren. Mittelgroße Organisationen bewegen sich in beide Richtungen am stärksten: 61% planen Wachstum, 22% einen Abbau. Jobs werden hier neu definiert, nicht abgeschafft.

Was bedeutet “AI-native”?

219 Führungskräfte sollten den Begriff in eigenen Worten definieren. Die Antworten reichten vom kompletten Umbau der Organisation über Autocomplete mit Extraschritten bis zu “a nonsense marketing term”. Teams sollen sich also auf etwas zubewegen, für das es keine gemeinsame Definition gibt. Bevor ihr ein Adoptionsprogramm startet, definiert das Ziel so konkret, dass ein Team erkennt, ob es dort angekommen ist.

Was empfiehlt der Report?

  • Testet die Fähigkeit, die ihr angeblich schätzt. Hat das Bewerten KI-generierter Arbeit beim Hiring oberste Priorität, sollte der Interviewprozess genau das prüfen.
  • Macht Specs zu einem lebenden Vertrag statt zu einem Dokument. Spec-Driven Development scheitert wie jede Documentation-first-Initiative davor: als Wartungsarbeit, die niemand belohnt. Es hält nur, wenn Agents aus der Spec lesen und in sie zurückschreiben. Entdecken sie eine falsche Annahme, aktualisieren sie die Spec.
  • Schreibt auf, was das Team weiß. Agents reproduzieren, was schon da ist. Konventionen und Architekturbegründungen, die nur in den Köpfen leben, erreichen den Agent nie.
  • Gebt Agents Unabhängigkeit und Autonomie. Unabhängigkeit ist Kontext, Autonomie ist die Erlaubnis zu handeln. Ein Agent mit nur einem von beiden ist nicht produktiv.
  • Schafft Raum für Gefühle. Nehmt euch Zeit abseits der Roadmap und fragt nach. Organisationen, die das tun, halten ihre besten Leute.

Verwandte Seiten

Quellen

Studien