Was macht ein Engineering-Team KI-nativ? Menschen, Projekte, Plattformen, Prozesse

Fast jedes Engineering-Team nutzt heute irgendwo KI. Nur sehr wenige wurden um sie herum neu gestaltet. Um diese Lücke geht es in einem aktuellen Brief von Andrew Ng, Gründer von DeepLearning.AI und Mitgründer von Google Brain. Er spricht regelmäßig mit Engineering-Verantwortlichen und fasst seinen Rat in vier Wörtern zusammen: People, Projects, Platforms, Processes.

Dieser Artikel nimmt seinen Rahmen und prüft ihn an der Beleglage: der globalen McKinsey-Umfrage 2025, dem ersten DORA-Bericht zu KI-gestützter Softwareentwicklung, dem Stack Overflow Developer Survey und einer randomisierten kontrollierten Studie von METR. Das Ergebnis ist weniger Hype, als man erwarten könnte, und praktischer als die meisten Ratschläge zur „KI-Strategie“.

KI-gestützt ist nicht KI-nativ

Ng zieht eine klare Linie. Das Ziel ist nicht ein klassisches Engineering-Team, das nebenbei KI nutzt. Es ist ein Team, das darauf ausgelegt ist, die Fähigkeiten von KI zu nutzen und ihre Schwächen zu umgehen. Bei einem ganz neuen Team aus zwei oder drei Personen kann man von Anfang an KI-native Entwicklerinnen und Entwickler holen. Die meisten Unternehmen können das nicht und müssen bestehende Teams weiterentwickeln.

Die breitere Datenlage zeigt, warum diese Unterscheidung zählt. Die McKinsey-Umfrage 2025 ergab, dass 88 % der Organisationen KI in mindestens einem Geschäftsbereich nutzen, die meisten sie aber nicht tief genug in ihre Abläufe eingebettet haben, um spürbaren Nutzen auf Unternehmensebene zu sehen. Von 25 getesteten organisatorischen Merkmalen hatte die Neugestaltung der Workflows den größten Einfluss darauf, ob ein Unternehmen finanziellen Ertrag aus KI erzielte. Nicht das Budget. Nicht das Talent. Nicht die Wahl des Modells.

KI zu nutzen ist verbreitet. Die Arbeit um KI herum neu zu gestalten unterscheidet die Teams, die davon profitieren.

Die Sicht der Diffusionskurve auf dasselbe Problem habe ich in Wo steht generative KI auf der Diffusionskurve der Innovation? beschrieben. Dieser Beitrag nimmt das Team in den Blick, das die Neugestaltung tatsächlich leisten muss.

1. Menschen: Kompetenz schlägt Richtlinie

Ein Team besteht aus Einzelpersonen, also braucht ein KI-natives Team Menschen, die im KI-Engineering gut sind. Ngs Rat an Führungskräfte ist konkret: Raum und Budget zum Experimentieren geben und eine Kultur schaffen, in der dieses Wachstum erwartet und nicht nur geduldet wird.

Er ergänzt einen Punkt, den viele Führungskräfte überspringen. Wie es sich anfühlt, einen Coding-Agenten zu steuern, lernt man nicht durch Zuschauen — so wenig wie man Radfahren vom Gehweg aus lernt. Führungskräfte, die selbst kleine Projekte bauen, entwickeln ein Gespür, das ihre technischen wie ihre geschäftlichen Entscheidungen verbessert.

Die Entwicklerdaten zeigen, warum dieses Gespür wichtig ist. Im Stack Overflow Developer Survey 2025 nutzen 84 % der Befragten KI-Werkzeuge oder planen es, und rund die Hälfte der professionellen Entwickler nutzt sie täglich. Doch mehr Entwickler misstrauen der Genauigkeit der Ergebnisse (46 %) als ihr zu vertrauen (33 %), und nur 3 % vertrauen ihr uneingeschränkt. Fast die Hälfte sagt, das Debuggen von KI-generiertem Code koste viel Zeit. Entscheidend ist nicht das Prompten, sondern zu wissen, wann man dem Ergebnis glauben darf.

Die METR-Studie belegt denselben Punkt mit Zahlen. Sechzehn erfahrene Open-Source-Entwickler bearbeiteten 246 echte Aufgaben in Repositories, die sie gut kannten; bei einer zufälligen Hälfte war KI erlaubt. Sie erwarteten 24 % Zeitersparnis. Sie brauchten 19 % länger und glaubten hinterher dennoch, KI habe sie um etwa 20 % schneller gemacht. Mit KI verbrachten sie weniger Zeit mit Programmieren und mehr mit Prompten, Warten und Prüfen.

Die ehrliche Einschränkung: Die METR-Autoren betonen, dass das Ergebnis zu einer bestimmten Situation gehört. Erfahrene Personen, große ausgereifte Codebasen, Werkzeuge von Anfang 2025 und viele Teilnehmende, die das Hauptwerkzeug noch nicht gut kannten. Sie behaupten nicht, dass KI nie hilft, und ein Teilnehmer, der das Werkzeug gut kannte, erzielte eine deutliche Beschleunigung. Das Ergebnis ist eine Warnung davor, etwas einfach anzunehmen — kein Urteil gegen KI.

2. Projekte: wenige stützen, auch für Wachstum

Ng plädiert weiterhin für Innovation von unten, bei der Menschen Ideen selbst ausprobieren. Er ergänzt aber, dass eine Handvoll vielversprechender Projekte Unterstützung von oben braucht, um zu skalieren und geschäftliche Wirkung zu zeigen. Engineering-Leitungen, die KI besser verstehen als andere Bereiche, können bei der Auswahl helfen.

Sein schärfster Punkt betrifft den Anspruch. Zu viele Unternehmen sehen KI noch vor allem als Mittel zum Kostensparen. Das kann sie, doch die größere Chance liegt laut Ng in neuen Produkten und neuen Wegen, Nutzer zu bedienen — das treibt Wachstum. Der Projektmix sollte also einige Wachstumswetten enthalten, nicht nur Effizienzarbeit.

• Experimente von unten zulassen, mit kleinem Budget und ohne Genehmigungsschlange.
• Wenige Projekte von oben stützen, mit klar benannten Verantwortlichen.
• Mindestens ein Projekt auf Wachstum ausrichten, nicht nur auf Einsparungen.
• Die Geschäftskennzahl festlegen, bevor der Bau beginnt.

3. Plattformen: den Kontext agentenfähig machen

Ein Agent ist nur so nützlich wie der Kontext, den er erreichen kann. Ngs Plattformebene sorgt dafür, dass dieser Kontext sicher verfügbar ist: Daten so organisiert, dass Agenten finden, was sie brauchen, Repositories für Agenten sichtbar, Designentscheidungen und Support-Tickets dort dokumentiert, wo Agenten sie lesen können, und interne Werkzeuge, die Agenten aufrufen können. Alles mit angemessener Sicherheit und Governance.

Drumherum steht die Auslieferungsmaschinerie: KI-gestütztes Code-Review, CI-Pipelines, die Agenten beim Debuggen und Ausliefern helfen, Sandboxes, in denen Agenten laufen, und ein Weg, wiederverwendbare Agenten-Fähigkeiten festzuhalten und zu teilen. Für manche Unternehmen ist der erste Schritt einfacher und schwerer zugleich: die Leitung zu überzeugen, dass Entwickler nicht mehr ausschließlich von Hand programmieren müssen. Auch das, so Ng, ist Fortschritt.

Der DORA-Bericht 2025, der erste, der sich ganz der KI-gestützten Softwareentwicklung widmet, stützt die Idee, dass dies eine Systemfrage ist. Sein zentraler Befund: Erfolgreiche KI-Einführung ist ein Systemproblem, kein Werkzeugproblem. Er stellt ein Modell aus sieben Fähigkeiten vor, die die Wirkung von KI verstärken, und warnt, dass lokale Produktivitätsgewinne in nachgelagertes Chaos umschlagen können, wenn der Rest des Auslieferungssystems nicht darauf vorbereitet ist.

Für Teams in Deutschland und der EU gehört Governance von Anfang an hierher: Welche Daten darf ein Agent lesen, wer prüft, was er erzeugt, und wo werden Entscheidungen festgehalten? Die Pflichten für Anbieter von KI-Modellen mit allgemeinem Verwendungszweck nach dem EU AI Act gelten seit dem 2. August 2025 — Verantwortung ist Teil der Plattform und kein späterer Zusatz.

4. Prozesse: dem Engpass folgen

Hier ist die Logik, die den Rahmen zusammenhält. Die Kosten, Software nach klarer Vorgabe zu bauen, sind stark gesunken. Dadurch wirkt alles andere langsam: entscheiden, was gebaut wird, es gestalten, dem Markt erklären, es prüfen lassen.

In einem früheren Brief zu KI-nativen Teams nannte Ng Beispiele. Ein Team kann ein Feature schneller bauen, als das Marketing überlegen kann, wie es das beschreibt. Oder es baut an einem Tag Software, für deren rechtliche Prüfung die Rechtsabteilung eine Woche braucht. Seine Antwort sind Teams mit viel Kontext und viel Entscheidungsfreiheit: Sie haben die Informationen, die sie brauchen, und die Befugnis zu handeln — mit maßvollen Schutzvorkehrungen gegen ernste Risiken wie den Abfluss vertraulicher Daten, einen großen Ausfall oder Datenverlust.

Generalisten statt Übergaben

In einem Team aus zwei bis zehn Personen braucht ein Produkt Beiträge aus Engineering, Produktmanagement, Design, Marketing und Recht. Gibt es weniger Personen als Funktionen, muss jede Person mehr als eine Rolle übernehmen. Entwickler entwickeln Produktgespür, Produktmanager lernen zu bauen.

Viel Kontext, viel Entscheidungsfreiheit

Wer das Produkt gut versteht, kann funktionsübergreifend entscheiden, statt jede Frage die Hierarchie hinaufzureichen.

Schutzvorkehrungen statt Schranken

Leichte Leitplanken für die echten Risiken: vertrauliche Daten, Ausfälle, Datenverlust. Alles andere läuft im Tempo des Teams.

Agenten, die Kontext teilen

Koordination zwischen Teams ist das alte Problem. Die Agenten verschiedener Teams Informationen austauschen zu lassen, ist eine vielversprechende Richtung, auch wenn sich die Praxis erst entwickelt.

Berichte darüber, wie führende KI-Unternehmen arbeiten, weisen in dieselbe Richtung. Laut dem Newsletter Engineering Leadership verantworten beim Codex-Team von OpenAI die Entwickler Projekte von Anfang bis Ende, und die Teams von Anthropic arbeiten ohne eigene QA-Rolle und betreuen mehrere Projekte gleichzeitig. Das sind Beispiele zum Lernen, keine Vorlagen zum Kopieren: Es sind Unternehmen, die KI-Produkte bauen, und das ist eine andere Aufgabe als Ihre.

Womit am Montag anfangen

Ngs Brief ist ein Rahmen, keine Checkliste. Das Folgende ist meine eigene Zusammenführung, wie ich daraus einen ersten Monat machen würde — seine vier Ebenen verbunden mit der Beleglage oben.

1. Einen echten Arbeitsablauf wählen und einen Ausgangswert festhalten: Durchlaufzeit, Review-Zeit, Fehler. Ohne Ausgangswert bleiben nur Gefühle.
2. Einem kleinen Team Zeit und Budget geben, diesen Ablauf mit Agenten neu aufzubauen — und die Führungskraft bitten, ebenfalls etwas zu bauen.
3. Kontext erreichbar machen: Entscheidungsprotokolle, Tickets und Code in einer Form, die Agenten lesen können, hinter sauberer Zugriffskontrolle.
4. Früh Leitplanken setzen: automatisierte Tests, KI-gestütztes Review mit menschlicher Verantwortung und keine Geheimnisse in Prompts.
5. Erneut messen und den nächsten Engpass suchen. Er liegt vermutlich außerhalb des Engineerings.
6. Ein Wachstumsprojekt finanzieren, neben der Effizienzarbeit.

Was das für kleine und mittlere Teams bedeutet

Die meisten europäischen Unternehmen haben keine Engineering-Organisation in der Größe eines Big-Tech-Labors. Für sie ist der nützliche Teil des Rahmens die Logik kleiner Teams: wenige Personen mit viel Kontext, die Ende-zu-Ende arbeiten, mit leichten Leitplanken und einer klaren Geschäftskennzahl.

So gehe ich auch in meiner eigenen Arbeit vor: das funktionierende System bauen, dem Team zeigen, wie es läuft, und es so übergeben, dass es selbst Verantwortung übernehmen kann. Wenn Sie klären wollen, wo KI in ein Team oder einen Ablauf passt, erklärt meine Leistungsseite, wie ich arbeite, und was ich gerade lerne, können Sie in der Learning Journey öffentlich verfolgen.

KI-nativ ist kein Werkzeug, das man kauft. Es ist ein Team, das man gestaltet.