5 Häufige Muster, die zu KI-Fehlschlägen führen

Adam Horner hat Ingenieurteams im Bereich Fintech und Unternehmenssoftware aufgebaut. Heute ist er Gründer von The CTO Playbook, wo er als Fractional CTO arbeitet und Wissen vermittelt.

Wir haben uns mit ihm zusammengesetzt, um zu erfahren, welche Muster er in Bezug auf Erfolg und Misserfolg bei der Integration von KI beobachtet. Hier ist, was er uns erzählt hat.

Irgendeine Variante derselben Herausforderung

Ich bin Adam Horner, CTO-Coach und Fractional CTO bei The CTO Playbook. Den Großteil meiner frühen Karriere habe ich als Ingenieur und Mitgründer-CTO verbracht, wo ich Ingenieurteams im Bereich Fintech und Unternehmenssoftware aufgebaut und geführt habe, unter anderem mehrere Jahre bei Palantir als einer der ersten Mitarbeiter im Vereinigten Königreich.

Der Schritt ins Coaching kam aus einer einfachen Beobachtung: Eine effektive Technologie-Führungskraft zu werden, ist wirklich schwierig, und die meisten gehen den Weg ohne Roadmap oder jemanden, der diesen Weg bereits gegangen ist. Das ist jetzt meine Aufgabe – CTOs dabei zu helfen, was ich die CTO-Kluft nenne, zu überbrücken.

Die KI-Thematik ist für mich kein separates Thema. Sie zieht sich durch nahezu jedes Coaching-Gespräch, das ich führe, denn jede CTO-Person, mit der ich arbeite, bewältigt irgendeine Version derselben Herausforderung: Wie führe ich eine Organisation durch eine Transformation mit dieser Tragweite, in ihrer spezifischen Phase, mit genau diesem Team – und mache daraus ein stärkeres Unternehmen?

Das chaotische Mittelfeld der Wachstumskurve

Meine eigene Organisation ist klein und bewusst schlank gehalten – ein Gründerteam von vier Personen, das KI als Fundament nutzt, um ganz nah an der Realität der Produktentwicklung im Frühstadium zu bleiben. Zudem arbeite ich als Fractional CTO für ein Fintech-Startup in der Vor-Akkreditierungsphase und navigiere dort die besonderen Herausforderungen, ein reguliertes Produkt mit einem externen Entwicklungsteam auf den Markt zu bringen.

Das große Ganze – und der eigentliche Einblick in Organisationsstrukturen – kommt aber durch die CTOs, die ich coache. Das reicht von Gründerteams und frühen, selbstfinanzierten Startups über wachstumsstarke, von Risikokapital oder Private Equity unterstützte Scale-ups bis hin zu mittelgroßen Unternehmen mit echter Komplexität und sogar zu Konzernen mit mehreren Abteilungen.

Im chaotischen Mittelfeld der Wachstumskurve verbringe ich die meiste Zeit, und genau dort sind die Führungsherausforderungen am schärfsten.

Wie KI Ingenieur:innen den Blick aufs große Ganze erlaubt

Für mich war die bedeutendste Veränderung weder ein neues Tool noch ein Prozess, sondern eine Erwartungshaltung. Wenn man dem Team als Führungskraft den Freiraum – und, noch wichtiger, die Verpflichtung – gibt, den gesamten Auslieferungszyklus von Grund auf neu zu hinterfragen, ist der Umfang dieser Hinterfragung entscheidend. Es geht nicht nur darum, wie Code geschrieben oder ausgeliefert wird, sondern alles, was der Delivery-Prozess berührt: Kundensupport, Nutzer:innen-Mehrwert und die geschäftliche Absicht hinter jeder Aufgabe.

Als die Kosten für das Schreiben und Warten von Code noch hoch waren, war es sinnvoll, Ingenieur:innen auf das technische Problem zu fokussieren. Doch diese Kosten sind drastisch gesunken. Entscheidend ist heute nicht mehr, wie schnell gebaut werden kann, sondern wie klar allen Beteiligten ist, was eigentlich gebaut werden soll – und warum.

Ingenieur:innen, die das Produkt, die Kundschaft und die Geschäftsziele hinter einer Änderung verstehen, können Entscheidungen treffen und sich bewegen, wie es früher nicht möglich war. Was sich verbessert hat, war keine Kennzahl – sondern die Qualität der Fragen, die das Team gestellt hat, bevor auch nur eine Codezeile geschrieben wurde.

Adams Gedanken

Entscheidend ist heute nicht mehr, wie schnell gebaut werden kann, sondern wie klar allen Beteiligten ist, was eigentlich gebaut werden soll – und warum.

Wie Triage- und Fehlerbehebungszyklen mit KI verkürzt werden können

Ein Beispiel war es, das Zusammenspiel von Kundensupport und Engineering bei bestätigten Fehlern neu zu denken. Früher wurden Triage- und Fixzyklen in Tagen oder Wochen gemessen, während Supportteams verärgerte Kund:innen betreuten und Ingenieur:innen durch die Live-Probleme und ihre Ablenkung zusätzliche Belastung hatten. Als der Auslieferungszyklus mit KI-unterstützter Entwicklung neu bewertet wurde, komprimierten sich die Fehlerbehebungen dramatisch – ein Großteil des Ablaufs wurde automatisiert.

Das bedeutete zunächst mehr Aufwand für den Support, um Probleme eindeutig zu erfassen und zu kategorisieren – aber die Belohnung war eine Lösung in Stunden statt Tagen. Ingenieur:innen konnten fokussiert arbeiten, Kund:innen bekamen schneller Antworten. Die Schnittstelle zwischen beiden Funktionen, die immer als langsam akzeptiert wurde, entpuppte sich als vollständig verhandelbar.

Warum Organisationen nicht überall KI einsetzen sollten

Welche Aufgaben von Menschen und welche von KI übernommen werden sollten, ist in jedem Unternehmen unterschiedlich. Der richtige Ausgangspunkt ist keine Liste von Aktivitäten, sondern ein klares Verständnis darüber, wo Ihr Wert entsteht und wo Ihr Risiko konzentriert ist.

Die Teile des Prozesses, die zum Kerngeschäft gehören – die Logik, die Differenzierung, die Bereiche, in denen Versagen sichtbar oder teuer ist – verdienen menschliche Erstellung und menschliche Überwachung. Alles andere bewegt sich auf einem Spektrum.

Ein Cybersecurity-Unternehmen wird seiner Code-Sicherheit besondere Aufmerksamkeit widmen, weil das ihr Geschäft ist. Ein Unternehmen für Workflow-Automatisierung wird diese Prüfung vielleicht auf die Entscheidungslogik eines kritischen Workflows anwenden, während Sicherheitstools eher als Aufgaben gelten, die von KI ausreichend übernommen werden können.

Was falsch ist, ist eine generelle Vorgehensweise in die eine oder andere Richtung. Die Frage sollte nicht lauten: "Kann KI das machen?" Sondern: "Was kostet es, wenn das schiefgeht?"

Und noch etwas: Ein überraschend großer Teil der Komplexität, die Menschen automatisieren möchten, ist eigentlich unbehandelte Prozessschuld. Räumen Sie diese zuerst auf. Das macht die spätere Einführung von KI sauberer und kostengünstiger.

Adam teilt mit

Der richtige Ausgangspunkt ist keine Liste von Aktivitäten, sondern ein klares Verständnis darüber, wo Ihr Wert entsteht und wo Ihr Risiko konzentriert ist.

Warum CTOs mit der Automatisierung der Lieferung und nicht des Codes beginnen müssen

Es ist tatsächlich schwierig, KI-Ergebnisse zwischen Organisationen zu vergleichen, weil die meisten Führungskräfte – in der Technik und im restlichen Unternehmen – immer noch damit kämpfen, den Einfluss und ROI ihrer KI-Investitionen eindeutig zu messen. Ohne dies ist es schwer zu wissen, wie ein gutes Ergebnis eigentlich aussieht, und noch schwerer, den Fall dafür zu machen, mehr davon zu tun.

Insgesamt ist die Bandbreite der KI-Ergebnisse groß. Auf der einen Seite habe ich mit Organisationen gearbeitet, die ihre Rückstände effektiv beseitigt haben und nun direkt an Kundenwert und Geschäftsabsicht arbeiten – was eine grundlegende Änderung darin darstellt, wie die Technik mit dem Rest des Unternehmens zusammenarbeitet.

Ich habe ein gemeinsames Muster bei den Unternehmen bemerkt, die dies erreicht haben: Keines davon hat am linken Ende des Softwareentwicklungszyklus begonnen. Sie starteten nicht mit der Codegenerierung. Sie begannen am rechten Ende: CI/CD-Pipelines, Deployment-Sicherheit, automatisierte Code-Reviews. Zuerst das Lieferende des Prozesses robust und vertrauenswürdig zu gestalten, schuf die Bedingungen für alles andere. Von dort verlagerte sich der Fokus auf Tests, Einschränkungen und Prüfungen vor der Generierung, sowie auf Struktur statt Geschwindigkeit.

Die Teams, die die größten Fortschritte gemacht haben, waren diejenigen, die am autonomsten arbeiteten – nicht weil sie menschliches Urteilsvermögen entfernt hatten, sondern weil sie genug davon in ihre Prozesse eingebettet hatten, sodass sie deutlich größere Arbeitsumfänge selbstbewusst übernehmen konnten. Die Rückstände verschwanden nicht, weil sie schneller Code schrieben. Sie verschwanden, weil die Beziehung zwischen Absicht und Lieferung unmissverständlich wurde.

Am anderen Ende habe ich echten Mitarbeiterverlust erlebt, ausgelöst durch die zunehmende Kluft zwischen denen, die schnell mit KI vorankommen, und denen, die das nicht tun. Wenn KI-Einführung beginnt, gibt es fast immer eine kleine Gruppe, die schnell vorangeht, und eine größere, die es nicht tut, und der natürliche Instinkt ist es, die Schnelleren laufen zu lassen. Das schafft leise und rasch Reibung, Misstrauen und Verdacht zwischen Teams, die die Vorteile schneller aufheben, als der anfängliche Fortschritt sie ansammeln kann. Der Rat, den ich zu Beginn jedes Engagements gebe, ist immer derselbe: Lassen Sie niemanden zurück. Das Tempo der Einführung sollte davon abhängen, wie schnell die gesamte Organisation mitgenommen werden kann – nicht davon, wie schnell die motiviertesten Ingenieure einzeln vorankommen.

Eine Organisation mit zwei Geschwindigkeiten fühlt sich aus der Sicht der Schnelleren wie Fortschritt an. Aus der Sicht der Hinteren fühlt es sich wie Zurücklassen an – und dieses Gefühl hat Konsequenzen.

Warum die Wissensbasis einer Organisation für KI neu gestaltet werden muss

Die offensichtlichste Lücke, die ich in den Fähigkeiten von KI gesehen habe, liegt in der Entscheidungsfindung unter Unsicherheit.

KI ist im Kern eine Vorhersagemaschine, und Vorhersage ist nicht dasselbe wie Urteilsvermögen. Sie hat nichts zu verlieren, kein Gespür für Konsequenzen, keine Verantwortung für das Ergebnis. Von ihr zu erwarten, Entscheidungen in Ihrem Namen zu treffen, wird immer nur so gut sein wie ihre Fähigkeit, Vorhersagen zu treffen – und die ist in wirklich unsicheren oder neuartigen Situationen eben begrenzt. Die Organisationen, die von KI am meisten enttäuscht wurden, sind meistens genau diejenigen, die sich in genau solchen Momenten auf sie verlassen haben.

Ein weiteres Feld, in dem die Wirkung leise, aber ebenso erheblich zurückbleibt, ist dort, wo die Bedeutung von Kontextfenstern nicht verstanden wird. Gibt man einer KI unvollständigen oder schlecht strukturierten Kontext, erhält man trotzdem eine selbstsichere Antwort. Den Unterschied zwischen einem gut informierten und einem bloß plausibel klingenden Output zu erkennen, erfordert menschliches Urteilsvermögen, das die meisten Teams bisher nicht ausreichend entwickelt haben.

Deshalb ist die Wissensbasis einer Organisation so entscheidend. Damit meine ich all das Wissen, das derzeit nur in den Köpfen der Mitarbeitenden existiert: die bewährten Abläufe, die Standardvorgehensweisen, die ungeschriebenen Regeln, wie die Organisation tatsächlich funktioniert. KI kann nicht mit unternehmensweitem Wissen arbeiten, das nie explizit festgehalten wurde – und die meisten Organisationen sitzen auf einer riesigen Menge davon.

Die gute Nachricht ist: Es muss für die Auslagerung nicht perfekt strukturiert sein. Multi-modale KI erlaubt als sinnvolle Eingabe sowohl einen Videowalkthrough, eine grobe Skizze als auch ein unbearbeitetes Dokument. Das Wichtigste ist die Auslagerung, erst danach kommt die Strukturierung.

Was ich immer wieder feststelle, ist, dass allein das Herausholen dieses Kontexts aus den Köpfen der Menschen und in irgendeine Form von Dokumentation zu bringen, schon einen enormen Wert an sich darstellt – noch bevor KI überhaupt damit arbeitet. Es bringt Widersprüche ans Licht, entlarvt fragwürdige Annahmen und deckt ineffiziente Arbeitsabläufe auf, die niemandem aufgefallen sind, weil alle zu sehr darin gefangen waren.

Dieses Fundament vervielfacht dann alles, was KI danach leisten kann. Es ist eine der wirkungsvollsten Investitionen, die ein CTO im Moment tätigen kann – und wird dennoch konstant übersehen, obwohl uns Vertriebsmitarbeitende für Business Process Automation das schon seit Jahren erzählen!

Wie man verhindert, dass skeptische Entwickler die Organisation ausbremsen

Ein häufiges Problem, das ich beobachte, ist nicht wirklich ein Versagen der KI selbst. Es ist ein Versagen bei der Einführung – und folgt häufig einem wiederkehrenden Muster.

Ein skeptischer Entwickler – und davon gibt es überraschend viele – probiert mit minimalem Kontext halbherzig etwas aus, erhält ein schlechtes Ergebnis und präsentiert dieses als Beweis dafür, dass KI die Aufgabe nicht leisten kann. Das Fazit wird selbstbewusst gezogen; die Methodik dahinter selten infrage gestellt. Was das Ganze über den Einzelfall hinaus brisant macht, ist die Kettenreaktion.

Die Integration von KI in ein Team oder einen Entwicklungsprozess ist ein Mannschaftssport, und ein paar Ingenieure, die unbedingt zeigen wollen, dass es nicht funktioniert, können die gesamte Organisation verlangsamen – nicht nur ihre eigene Produktivität.

Die Lektion, die ich daraus ziehe, betrifft nicht die Grenzen von KI, sondern die Herausforderung bei der Einführung. Die Qualität der Ergebnisse von KI ist untrennbar mit der Qualität des eingebrachten Kontexts und der Zielsetzung verbunden. Dieses Verständnis teamweit zu fördern, braucht dieselbe gezielte Anstrengung wie jede andere signifikante Veränderung im Arbeitsalltag. So gelingt der Wandel von unausgereifter "Magie" hin zu nutzbarer "fortschrittlicher Technologie".

Adam teilt

Ein skeptischer Entwickler unternimmt einen halbherzigen Versuch mit minimalem Kontext, erzielt ein schlechtes Ergebnis und präsentiert dieses Ergebnis als Beweis dafür, dass KI die Aufgabe nicht erledigen kann. Das Fazit wird mit Selbstbewusstsein verkündet. Die Methodik wird selten hinterfragt.

Warum kleine Teams bei KI von Vorteil sind

Die Annahme, dass ein funktionierendes, produktives Entwicklerteam eine bestimmte Anzahl von Mitgliedern braucht, um genug Kontext mitzuführen und ein sinnvolles Tempo einzuhalten, hat sich angesichts KI-gestützter Entwicklung nicht gehalten.

Der begrenzende Faktor in jedem Team war immer kognitiv: wie viel Kontext jede Person erfassen kann, wie klar sie ihn an die Menschen um sie herum kommunizieren kann und wie viel Energie diese Kommunikation verbraucht. Was sich geändert hat: Die Einheit, die die Arbeit erledigt, ist nicht mehr nur ein Mensch. Jedes Teammitglied steuert mehrere Agenten, und diese Agenten tragen und wenden Kontext auf eine Weise an, die die gesamte Rechnung verändert. Amazons Zwei-Pizzen-Regel war eine vernünftige Daumenregel für eine Zeit vor KI.

Hier ein Beispiel.

Eine von mir betreute Organisation wollte schon immer eine interne Administrationsoberfläche für ihre Plattform, konnte jedoch die Investition nie rechtfertigen. Zuvor wurde das Vorhaben als mehrmonatige Aufgabe für das gesamte Team kalkuliert. Stattdessen wurden zwei Personen damit beauftragt: Beide verfügten über tiefes Wissen über das Unternehmen und die bestehende Plattform, eine hohe Eigenständigkeit und einen klaren Rahmen an Vorgaben. Sechs Wochen später gab es eine funktionierende erste Version.

Die Kenntnis des Geschäfts dieser beiden Personen war letztlich genauso wichtig wie das KI-Tooling. Weniger Rückfragen, weniger Overhead, schnellere Entscheidungen. Doch das wertvollste Ergebnis war nicht das Tool selbst – sondern die Lehren, die die Organisation über diese neue Arbeitsweise gewonnen hat.

Die Teams, die ich derzeit am effektivsten arbeiten sehe, bestehen aus zwei bis drei Personen, von denen jede mehrere Agenten steuert – und das ist kein Nachteil. Für die richtige Art von Aufgaben ist es sogar ein Vorteil.

Warum häufige Kommunikation bei KI-gestützten Arbeitsabläufen entscheidend ist

Zusammenarbeit kann mit KI schwieriger werden.

Viel häufigere Kommunikation ist notwendig, weil sich alles schneller bewegt. Das ist einer der Gründe, warum kleinere Teams derzeit besser funktionieren.

Es scheint schlicht zu anstrengend, den Zustand und die Konsistenz bei größeren Teams und mehreren parallelen, agentengestützten Coding-Prozessen pro Person aufrechtzuerhalten. Einige Teams, mit denen ich zusammenarbeite, sind daher dazu übergegangen, zweimal täglich ein Standup durchzuführen, um Konsistenz zu gewährleisten.

Warum CTOs auf Schatten-KI achten müssen

Schatten-KI ist das bereits beobachtete Problem der Schatten-IT – nur mit einem neuen Budget und einem neuen Namen.

Unkontrollierter und ungebremster Einsatz von KI-Tools im Unternehmen kann die Risiken von Daten- und IP-Verlust – „Exfiltration“, wie es der CISO nennt – leicht erhöhen, oft völlig unbeabsichtigt durch die Nutzer.

Die meisten Organisationen verlassen derzeit zügig Stufe 1 des CMM (die „Wilder Westen“-Experimentierphase), um Richtlinien und technische Beschränkungen einzuführen, die die Risiken reduzieren.

Warum CTOs sich auf ihre eigene Entwicklung konzentrieren müssen

Adams Gedanken

Die Führungskräfte, die diese Phase am stärksten verlassen, sind nicht unbedingt diejenigen mit den besten Tools oder den größten Teams. Es sind die, die Urteilsvermögen, Einfluss und Klarheit im Denken entwickeln, um gut zu führen, wenn niemand einen klaren Plan hat.

In der Branche gibt es derzeit viel Unsicherheit darüber, was KI für Entwicklerteams, für den Personalbestand und die Rolle an sich bedeutet.

Ob diese Unruhe berechtigt ist, ist fast schon nebensächlich. Entscheidend ist, dass wir uns in einer Phase tiefgreifender und rascher Veränderungen befinden, und dass es Führungskräfte braucht, die nicht nur das Umfeld managen, sondern aktiv an der eigenen Entwicklung arbeiten, um dies gut zu meistern.

Was mich angesichts der aktuellen Entwicklungen immer noch überrascht: Wie viele CTOs und leitende Technolog:innen sich keinerlei Zeit für ihre eigene Weiterentwicklung nehmen. Kein Coach, keine strukturierte Entwicklung, kein Sparringspartner. Ich habe diesen Fehler einmal selbst gemacht, und die daraufhin verlorene Zeit und die Fehler waren nicht unausweichlich.

Die Führungskräfte, die diese Phase am stärksten verlassen, sind nicht unbedingt diejenigen mit den besten Tools oder den größten Teams. Es sind die, die Urteilsvermögen, Einfluss und Klarheit im Denken entwickeln, um gut zu führen, wenn niemand einen klaren Plan hat.

Mitverfolgen

Sie können die Arbeit von Adam Horner auf LinkedIn verfolgen. Für 1:1 Coaching, Gruppenkurse und den Podcast besuchen Sie The CTO Playbook. Und für einen kostenlosen 5-tägigen E-Mail-Kurs für CTOs in der frühen Phase schauen Sie bei Early CTO Map vorbei.

Weitere Experteninterviews folgen demnächst im The CTO Club!