Warum AI-Adoption in gewachsenen Engineering-Organisationen stockt – und was hilft

In meinem LinkedIn-Feed überschlagen sich vollmundige AI-Versprechen. AI-Gründer versprechen 100-fache Performance-Gewinne, selbsternannte Experten präsentieren ihr perfektes AI-System, mit dem ich mein Business mit AI skalieren kann, und Solopreneure sammeln Millionen für ihr Ein-Personen-Unicorn ein.

Vielleicht geht es dir ähnlich: Einerseits bist du begeistert von den Möglichkeiten, die AI für dein Engineering-Team und dein Produkt bietet. Du siehst, wie AI die Produktentwicklung beschleunigen, die Qualität verbessern und die Innovationskraft steigern kann. Du erkennst das Potenzial, dass AI nicht nur Prozesse optimiert, sondern auch neue Geschäftsmöglichkeiten eröffnet.

Doch in deinem Team und in deiner Organisation erlebst du auch Unsicherheit und Skepsis.

AI-Adoption in AI-native Unternehmen vs. gewachsenen Organisationen

Die Erfolgsgeschichten haben oft eines gemeinsam: Sie berichten vom AI-Einsatz in AI-native Unternehmen. Unternehmen, die ohne die Constraints und den Kontext eines gewachsenen Unternehmens unterwegs sind. Teams mit einem „no rules“-Mindset. Neue Produkte, die auf der grünen Wiese entstehen. Sie bauen Features in Stunden, für die andere Monate brauchen. Sie shippen mehrfach am Tag statt einmal im Monat. Sie unterstützen jede Business-Funktion mit AI: von Marketing über Sales und Engineering bis zum Support.

In gewachsenen Engineering-Organisationen erlebst du oft eine andere Realität.

Für dich als Engineering Lead ist AI-Adoption dort zu einer strategischen Notwendigkeit geworden. Dein CEO sieht das Risiko, dass AI-native Wettbewerber eure Produktentwicklung mit einem deutlich kleineren Engineering-Team überholen. Dein Marketing möchte den AI-Hype nutzen, um mehr Aufmerksamkeit für das Produkt zu erzeugen. Sales fragt nach der Roadmap für AI-Features, weil die Kunden endlich mehr Innovation fordern. Und dein Engineering-Team pendelt zwischen überzogenen Erwartungen und einer tiefen existenziellen Krise.

Engineering Leads haben natürlich verstanden, welchen disruptiven Einfluss AI auf die Produkt- und Softwareentwicklung haben wird. Sie haben auch ihre Hausaufgaben gemacht: Lizenzen gekauft, die notwendigen rechtlichen Leitplanken für die AI-Nutzung gesetzt, eine AI-Community of Practice gegründet, Piloten gestartet und in AI-Weiterbildung investiert. Doch nach der ersten Begeisterung bleibt die Nutzung punktuell und ist ungleich verteilt, Diskussionen und Konflikte zwischen Einzelnen und Teams bleiben bestehen, und es fällt ihnen schwer, den Wert zu beziffern, den AI für ihr Engineering und ihr Business schafft.

Die AI-Adoption läuft seitwärts, während die Erwartungen wachsen, die Ängste nehmen zu und die Zeit vergeht.

Eine aktuelle McKinsey-Studie bestätigen: Das ist die Realität in der AI-Adoption. Fast zwei Drittel der Organisationen skalieren AI noch nicht unternehmensweit, weil sie die erwartete Business-Wirkung oder zumindest einen Return on Investment nicht erleben.

Warum die AI-Adoption ins Stocken gerät

Die gute Nachricht ist: Meistens gibt es kein Problem mit der Technologie an sich und auch keinen grundsätzlichen Widerstand gegen Veränderung.

Das Problem ist, dass die Adoption aktuell zwischen der Dringlichkeit des Managements und der Vorsicht des Engineerings festhängt. Die Aufgabe des Engineerings ist es, das bestehende Produkt stabil und die operativen Risiken gering zu halten. Senior Engineers haben also Recht, wenn sie eine große Veränderung in Kombination mit einem neuen, unbekannten Toolstack und dem Fehlen eines verstandenen Entwicklungsmodells für AI als großes Risiko sehen (Quelle: DORA AI Report 2025).

Je größer die Lücke zwischen den Erwartungen des Managements und den Bedenken im Engineering wird, desto defensiver und weniger konstruktiv werden die Diskussionen. Ein strategisches Ziel, die AI-Adoption auf 60% zu erhöhen, wird für das Management zum absoluten Minimum, für das Engineering zur verrücktesten Idee überhaupt und damit zum zentralen Konflikt in eurer Organisation.

Ich weiß das, weil wir selbst vor zwei Jahren genau dort standen. Als uns klar wurde, dass AI unser Kerngeschäft massiv verändern würde, machten wir die AI-Adoption in unseren Engineering-Teams zu einem strategischen Ziel. Viele meiner Kollegen hielten das für verrückt oder zumindest voreilig. Sie sahen, dass die AI-Tools noch unreif waren, erlebten, wie Coding Agents unseren Code auf sehr raffinierte Weise kaputt machten, und spürten die Skepsis unserer Kunden. Wenn ich in die Küche kam, hörte ich Leute über die dummen Fehler der AI lästern und Beschwerden über die Komplikationen rund um unseren eigenen unreifen AI-Stack. Und ich weiß es auch, weil wir dieselben Argumente im letzten Jahr in fast jedem Interview zum Thema AI-Adoption in Engineering-Organisationen gehört haben (siehe DevBoost AI Report).

AI-Adoption als Führungsaufgabe

„Macht einfach mehr mit AI“ ist nicht der richtige Weg, um Adoption voranzutreiben. Diese Ansage vergrößert die Lücke zwischen Erwartung und Realität und schiebt das Problem ins Engineering. AI-Adoption wird so als Effizienz-Ziel geframed: Wir machen dasselbe mit weniger Ressourcen. Und das wirft viele Fragen und Sorgen auf.

• Was muss ich lernen, um AI zu beherrschen?
• Welche AI-Tools sind die besten?
• Wer ist für den Output der AI verantwortlich? Für den Code und die Bugs?
• Werden wir unser eigenes System noch verstehen, wenn AI es baut?
• Wie behalten wir bei der AI-Nutzung die Kontrolle?
• Die AI macht das spannende Coding? Was bleibt dann für mich übrig? Langweilige Reviews? Anstrengender Support? Nerviges Debugging?
• Was passiert mit den frei werdenden Ressourcen? Also mit mir und meinen Kollegen? Verlieren wir unseren Job?
• Was wird aus dem, was ich in meiner Karriere gelernt habe?
• Was passiert mit der Menschheit, wenn AI superintelligent wird?

Diese Fragen wirken oft hemmend auf die AI-Adoption. Teams zerdenken die perfekte Adoptionsstrategie, bevor sie die notwendige Veränderung überhaupt verstehen. Endlose Diskussionen und langsame Entscheidungen töten Begeisterung und bremsen jeden echten Fortschritt.

Das ist ein klarer Auftrag an jeden Engineering Lead: Du musst eine überzeugende Zukunftsvision für den Einsatz von AI in eurer Entwicklung entwerfen. Du solltest dabei AI nicht als Instrument zur Effizienzsteigerung motivieren, sondern als Mittel, bessere Ergebnisse in Bezug auf die Ziele zu erreichen, die für euer Business und euer Engineering-Team wichtig sind. Und als eine Maßnahme, die den Job für Engineers sichert statt sie obsolet zu machen.

Hört auf, genutzte Lizenzen, gesendete Prompts und verbrauchte Tokens zu zählen. Konzentriert euch auf höherwertige Ergebnisse: mehr Kundennutzen, bessere Lieferqualität, weniger operativen Frust, stabilere technische Grundlagen und die Möglichkeit, kontinuierlich dazuzulernen.

Wie du eure AI-Adoption in Richtung gewünschter Ergebnisse steuerst

1. Verknüpfe AI-Arbeit mit Business-Zielen, die Engineers wichtig sind

Der prozentuale Anteil der AI-Adoption oder die Anzahl genutzter Tokens sind keine besonders hilfreichen Engineering-KPIs. Ja, sie sind leicht zu messen. Ja, sie geben einen ersten Hinweis auf Adoption. Und ja, sie sind leicht auszutricksen.

Als wir bei uns eine Rangliste zur Token-Nutzung eingeführt haben, begannen die Leute über ihre AI-Nutzung zu sprechen, und wir freuten uns, dass sie damit „spielten“. Eine Woche später fragten sich alle, was die Top-User eigentlich machten. Nach einer weiteren Woche wurde klar, dass sie viele Tokens dafür ausgaben, ein riesiges Repo zu verarbeiten, ohne brauchbare Antworten zu erhalten. Dieser Trend des Token-Maxing, also Geld für Tokens auszugeben, ohne den positiven Einfluss auf das Engineering zu hinterfragen, wird vielfach beobachtet und kritisiert (Salesforce takes on "tokenmaxxing").

Man kann Token-Maxing als Gaming der Metrik durch Engineers verstehen. Aber eigentlich ist es ein Folgefehler, wenn AI-Nutzung nicht von Anfang an strategisch an den richtigen KPIs ausgerichtet wird. Dafür gibt es viele Möglichkeiten: Time-to-Market in einem priorisierten Produktbereich, Experimentiergeschwindigkeit in der Produktinnovation, Onboarding- und Conversion-Raten, Qualität der Incident Behandlung oder Anzahl von schwerwiegenden Fehlern, die in die Produktion gelangen.

Die richtigen KPIs geben AI-Adoption einen Kontext und framen AI als Mittel, etwas Sinnvolles zu erreichen. Nicht als Selbstzweck.

Wenn du sichtbaren Wert mit AI liefern willst, beginne beim Wert, nicht bei den Adoption-KPIs.

2. Bring Business und Engineering an einem echten Problem zusammen

Wenn wir mit Engineering-Teams über AI-Adoption sprechen, drehen sich die Diskussionen oft sofort um technische Details: Was sind die besten AI-Tools? Welcher Ansatz ist besser: BMAD, Spec-Kit oder OpenSpec? Starten wir mit GitHub Copilot oder springen wir direkt in agentisches Coding? Welche Prozesse brauchen wir, damit AI unsere Software und unsere Verfügbarkeitszusagen nicht bricht? Das sind alles valide Fragen für eine verantwortungsvolle und wirksame Einführung von AI im Engineering. Aber sie drehen sich vorrangig um technologische Herausforderungen statt um echte Probleme.

In fast jedem Unternehmen ist Engineering selbst „nur ein Mittel zum Zweck“. Ein Werkzeug um ein echtes Business-Problem zu lösen: das Problem, das euer Produkt, eure Dienstleistung und damit euer Unternehmen für eure Kunden löst. Eine der besten Möglichkeiten, dieses Problem wieder „auf den Tisch“ zu bringen, ist, Mitarbeiter außerhalb des Engineering-Teams direkt mit Engineers zu paaren. Diese Mitarbeiter (aus Marketing, Sales, Support, Business Engineering etc.) erleben echte Business-Probleme aus erster Hand und können leicht Use Cases mit direkter Wirkung auf Geschäftsziele identifizieren. Für eine skalierbare Umsetzung (über Excel hinaus) sind sie allerdings oft auf die technische Expertise und den Zugang der Engineers angewiesen.

Wir haben solche Pairings vor Kurzem in einem zweitägigen Hackathon mit den skeptischen und zögerlichen Engineers eines unserer Entwicklungspartner gemacht. Die Ergebnisse waren erstaunlich. Aus technischen Debatten wurden Diskussionen um ein MVP. Statt um Risikovermeidung ging es um schnelle Experimente. Statt Angst davor, nicht mehr coden zu dürfen, waren die Teilnehmer voller Stolz darüber, wertvolle Lösungen in wenigen Stunden statt nach Wochen mühsamer Entwicklung abzuliefern. Am Ende standen schnelle Lösungen für echte Business Probleme, und wertvolle Erfahrung für den AI-Einsatz in risikoarmen Anwendungsfällen. Die Engineers waren optimistisch, ihre neuen Erkenntnisse direkt in ihren Engineering-Alltag übertragen zu können.

Die besten Use Cases für „frühe“ AI-Adoption entstehen an der Schnittstelle zwischen Business und technischer Realität.

3. Starte dort, wo das Engineering Herz schlägt: Qualität, Kontrolle und technische Schulden

Eine weitere Sorge, die wir von vielen Senior Engineers hören: AI in Brownfield-Projekten einzusetzen ist deutlich komplizierter und riskanter, als ein Produkt von Grund auf neu zu bauen. Veraltete Technologiestacks, undokumentierte Designentscheidungen, versteckte Systeminteraktionen und „gewachsene“ Schnittstellen legen die Messlatte für jeden „neuen Entwickler“ deutlich höher – egal ob AI oder für einen neuen Junior Engineer.

Und das ist ein völlig berechtigter Einwand. Gewachsene Systeme sind für AI-Coding aus denselben Gründen schlechter zugänglich, aus denen sie generell schlechter zugänglich sind. Der gängige Begriff für diese Beobachtung ist technische Schulden. Veraltete Libraries, undokumentierte technische Details, Annahmen und Wissen, das „in den Köpfen“ der Senior Engineers steckt, machen jede Änderung am Produkt, aber auch an der Art, wie es gebaut wird, von vornherein viel schwieriger.

Wenn wir mit Tech Leads über ihr Ziel sprechen, AI in ihre Entwicklungsteams zu bringen, entdecken wir häufig technische Herausforderungen, die es schon gab, bevor AI überhaupt ein Thema war. In einem konkreten Fall wurde ein Refactoring der Service-Schicht zwei Jahre lang vermieden, weil die Testsuite, die den Service testete, aufgrund eines nicht mehr unterstützten Test-Frameworks kaputt war. Im AI-Kontext würde man sagen: Dem System fehlte der Quality Harness, wodurch jedes Refactoring sehr riskant und teuer wurde.

In einer solchen Situation ist der unreflektierte Einsatz von AI-Coding ein ziemlich sicherer Weg in die Katastrophe.

Zum Glück ist die Aufmerksamkeit um AI und die Bereitschaft, in ihre Adoption zu investieren, auch eine große Chance, solche Herausforderungen „von Grund auf“ anzugehen. Die Testsuite auf ein aktuelles Test-Framework zu migrieren, war nun in Tagen statt in Wochen machbar. Sie gegen die bestehende Service-Schicht laufen zu lassen und anschließend einen AI-Agenten fehlende Assertions identifizieren und beheben zu lassen, zeigte, dass die Suite als Harness dienen kann. Auch das Refactoring der Service-Schicht hin zu einer konsistenten und modernen Architektur profitierte stark von der Fähigkeit der AI, Muster über eine große Codebasis hinweg zu replizieren. Am Ende brauchte es trotzdem anspruchsvolles und spannendes Engineering, um das Refactoring voranzutreiben und ein paar „sehr interessante“ Spezialfälle zu behandeln. Genau das war ein perfektes Szenario, um eine wünschenswerte Zukunft zu zeigen, Engineers die Kontrolle zu geben und die zentralen Werte des Engineering Handwerks zu stärken.

AI birgt enormes Potenzial, bestehende technische Herausforderungen endlich anzugehen und zugleich technische Hindernisse für den zukünftigen AI-Einsatz in komplexen, gewachsenen Codebasen abzubauen.

Warum diese AI-Adoption-Ansätze funktionieren

Diese beschriebenen Ansätze haben funktioniert, weil sie die Diskussion weg von Tools und hin zu wichtigen Problemen verschoben haben. Engineers suchten nicht erst nach einer universellen AI-Strategie, bevor sie angefangen haben, mit AI umzugehen. Sie arbeiteten an echten Problemen, erfuhren, wie eine gute Zusammenarbeit mit AI funktioniert, und an welchen Stellen sie ihre Expertise einbringen müssen.

Das schafft auch glaubwürdigere Argumente für den Nutzen von AI. Statt Lizenzen, Prompts oder Tokens zu zählen, kannst du AI-Adoption mit Business- und Engineering-Metriken verbinden, die deinem CEO, deinen Kollegen und deinen Kunden wichtig sind. Sichtbare und messbare Effekte statt Anekdoten und Annahmen.

Sie machten auch das Dazulernen einfacher und sicherer. Abgegrenzte Experimente gaben den Teams Raum zum Ausprobieren, ohne ihr bestehendes Produkt und den Nutzen für eure Kunden zu gefährden. Es gibt keinen Grund, am ersten Tag eine universelle AI-Strategie zu entwickeln. Die Aufgabe ist, den jeweils nächsten sinnvollen Schritt zu identifizieren, sichtbare Ergebnisse zu liefern und Vertrauen und Expertise aufzubauen.

Diese Beispiele der AI-Adoption lieferten die nötigen Antworten auf die drängenden Fragen der Engineers: Was macht AI mit unserem Produkt, meiner Arbeit und unserem Entwicklungsprozess. Am Ende war klar: AI bedeutet nicht weniger Engineering, AI ist ein Weg zu besseren Ergebnissen, höherer Qualität und mehr Kapazität für sinnvolle Arbeit.

Deine nächsten Schritte für eure AI-Adoption

Es gibt kein universelles Playbook für AI-Adoption. Der richtige Startpunkt hängt davon ab, wie gewachsen euer Produkt ist, von eurer Systemarchitektur, dem Vertrauen im Team, Daten- und Sicherheitsanforderungen, eurer aktuellen Delivery-Qualität und euren Business-Prioritäten ab.

Aber es gibt ein wiederkehrendes Muster: Stockende Adoption weist oft auf ein Problem mit Führung und Vertrauen hin – nicht auf mangelndes Interesse oder fehlende Sorgfalt.

Wenn sich Adoption festgefahren anfühlt, beginnt damit, eure tatsächlichen Bottlenecks zu identifizieren (Selbsttest im DevBoost AI Report). Liegen sie in der Produktvision, eurer Architektur oder euren Delivery-Methoden?

Der sinnvollste nächste Schritt ist oft ein fokussiertes Gespräch über die Ergebnisse, die ihr erreichen möchtet, die Einschränkungen, die im Weg stehen, und die Experimente, die es sich lohnt, gemeinsam durchzuführen. So findet ihr wirksame Ausgangspunkte für die AI-Einführung, statt blind in ein generisches AI-Transformationsprogramm zu starten.