KI-Strategie für CTOs

Die Millionen-Dollar-Frage: Was machen wir mit KI?

KI stellt die Softwareentwicklung auf den Kopf. Als CTO stehst du unter Dauerdruck von CEO, Product und Board, mit KI schneller zu liefern. Aber KI ist nicht nur Effizienz - KI lässt Unternehmen mehr Ideen ausprobieren und bessere Ideen auf den Markt bringen als je zuvor. KI macht Entwickler und CTOs wieder zu Erfindern. Gleichzeitig bringt KI neue Probleme: Code-Qualität halten, Entwicklerrollen neu definieren, mit Modellen und Tools Schritt halten, die sich alle drei Monate ändern. Aus hunderten Gesprächen mit CTOs und aus eigener KI-Arbeit sind diese Leitlinien entstanden.

Überkommuniziere

Kommuniziere, dass ihr KI macht. Und rede über KI. Und rede über KI. Und rede über KI. So lange, bis jeder weiß, dass du für KI stehst und dir die Leute sagen, du sollst aufhören zu nerven.

KI ist kein Nebenprojekt

KI gehört ins Zentrum deiner Tech-Vision und deiner Strategie, nicht in ein Innovation-Lab, das alle drei Monate eine Demo zeigt. KI ist nicht noch ein Tool. KI ist der Hauptgang.

KI ist nicht Cloud

Zu viele CTOs, die ich treffe, behandeln KI wie damals die Cloud: eine Technologie, die Kosten senkt und Effizienz erhöht. Ist sie nicht. KI ist disruptiv und wird die gesamte Softwareentwicklung um sich herum verändern. Die Firmen, die dachten, das Internet sei so etwas wie Telefax, gibt es nicht mehr.

Experimentiere mehr

Niemand weiß, was gerade passiert. Die Zukunft ist offen. Du musst mehr mit KI experimentieren - welche Tools für euch funktionieren, welche nicht. Braucht ihr ein eigenes Modell? Fine-Tuning statt Quellcode? Lokales RAG mit einer Vektordatenbank? Nur ständige Experimente zeigen dir, was KI für euch bedeutet - das kann dir niemand abnehmen und niemand von außen erzählen.

Stell Leute ein, die herausfinden, was KI für euch heißt

Mit euren Services, euren Daten und eurem Geschäftsmodell wisst nur ihr selbst, was KI für euch bedeutet. Stell Leute ein, deren Job genau das ist. Kein Budget? Dann Werkstudenten und Praktikanten - und zwar gestern.

Bau einen Prototypen-Funnel

Mehr experimentieren braucht einen Prozess. Einer, der funktioniert (abhängig von der Größe der Firma): ein Prototyp pro Tag. Prototypen sind zum Spielen da, um herauszufinden, ob eine Idee Sinn ergibt. Leute schauen sich den Prototypen an und diskutieren ihn.

Aus den Prototypen nimmst du den mit dem größten Potenzial und machst einmal pro Woche ein MVP daraus. Das MVP zeigst du Kunden, um herauszufinden, ob sie es brauchen (nicht wollen).

KI braucht mehr Leitplanken

Was früher in den Köpfen der Entwickler war, muss jetzt explizit werden. Wir haben vergessen, wie viel Entwickler im Kopf haben - in einem Ticket steht nur ein Bruchteil davon.

Architektur-Richtlinien, Screenshots, Domain-Modelle, Coding-Style, Security-Anforderungen: All das muss im Projekt dokumentiert sein, damit die KI das Richtige tut. KI ohne Leitplanken produziert Code voller Bugs, den keiner warten kann.

Wem gehört der Code - Mensch oder KI?

Erkläre jedes Modul und jeden Microservice zu KI-owned oder Human-owned. KI-owned Module brauchen andere Regeln und Leitplanken als Human-owned Module. Was brauchst du, um ein KI-owned Modul mit gutem Gewissen in Produktion zu deployen? Mein Tipp: Lies die Test-Zusammenfassung des Moduls - wie früher, als du als CTO auf die manuelle Testliste geschaut und entschieden hast: Wenn das alles funktioniert, können wir deployen.

Für Human-owned Module gilt: Aller KI-generierte Code gehört dem Entwickler, der ihn hat generieren lassen. In der Krise ist “das hat die KI geschrieben” keine Verteidigung. Du generierst ihn, er gehört dir - du musst den Code verstehen, reviewen, testen. Genau wie früher beim Autocomplete (“das hat die IDE vervollständigt” war nie eine Ausrede).

Über die Zeit migrierst du Human-owned Module zu KI-owned Modulen.

Leute mit KI im Titel, Teams mit KI im Namen

Nur wenn jemand KI im Titel hat, ist KI zu 100% in seinem Kopf. Dann gibt es jemanden in deiner Organisation, der morgens reinkommt und denkt: “Was können wir mit KI machen?” Alle anderen haben etwas anderes im Kopf.

Und du willst nicht, dass dir das Thema KI weggenommen wird. Damit klar ist, dass KI zu Tech gehört: Benenn das Data-Team in “AI & Data” um, “DevOps” in “AI Infrastructure”. Erwarte Widerstand von allen Seiten.

MCP überall

MCP ist ein einfacher Schritt, KI nutzbar zu machen. Füge MCP zu allen euren Services hinzu. Vielleicht ersetzt MCP sogar REST in euren Microservices oder eurer öffentlichen API. MCP (GitHub) hilft bei DevOps und der kaputten CI/CD-Pipeline, MCP (Linear) liest das Ticket, MCP (Figma) holt das Design, MCP (Playwright) prüft, ob der Code im UI tut, was er soll.

Setz Mindeststandards für KI-Nutzung

Zu wenige CTOs reden über ihre Erwartungen - bei KI ist das nicht anders. Sag deinen Entwicklern, was du bei KI erwartest. Setz einen Mindeststandard, etwa “Jeder nutzt Cursor” oder “Bugs werden zuerst mit Claude Code gefixt”.

Metriken

Fang mit Adoption an: Jeder Entwickler nutzt KI jeden Tag. Geh dann zu Impact über: Time-to-Market halbiert, doppelt so viele Tickets pro Sprint. Zeig den KI-Effekt so, dass er etwas bedeutet - der CEO wird dich nach genau dieser Zahl fragen.

Befördere Leute zum “Product Engineer”

Die Entwicklerrolle wird sich ändern - wie bei jeder Revolution (das Internet brachte uns DevOps, CTOs und Product Manager). Meine Vermutung: Mit KI übernehmen Entwickler mehr Produktverantwortung, und Product Engineers werden normal. Wenn das deine Strategie ist, definiere die Rolle und ihre Anforderungen und befördere Leute, die sie ausfüllen können. Das erzeugt Zug, nicht zurückzubleiben.

KI heißt nicht “mehr Code, schneller!”

KI nimmt Entwicklern die langweilige Arbeit ab: Variablen im ganzen Projekt umbenennen, Bugs finden, Bugs fixen, Code erklären, Migrationen vorschlagen, Framework-Nutzung zusammenfassen und vieles mehr. Wenn eure KI-Nutzung nur auf Code-Generierung zielt und das alles ist, was du kommunizierst, machst du es falsch. Was hat der Entwickler davon?

Investier in Prompt-Training

Prompting ist wie Projektmanagement. Jeder denkt, er kann es einfach so, ist ja nichts dabei. Aber zwischen gutem und schlechtem Projektmanagement liegen Welten - einer der Gründe, warum so viele Projekte schiefgehen. Mit Prompting passiert gerade dasselbe. Investier in Prompt-Training.

Hab eine KI-Strategie. Und eine KI-Policy.

Hab eine KI-Strategie. Und eine KI-Policy dazu: KI-Nutzung, Datennutzung, Drittanbieter, Datenschutz, Datenlecks, Ethik. Die meisten KI-Policies, die ich gesehen habe, sind 20 Seiten Absicherung, die niemand liest. Eine Seite reicht.

Wo anfangen?

Wenn du wissen willst, wo deine Organisation heute steht und was als Nächstes kommt: Dafür habe ich die neun KI-Adoptionsstufen aufgeschrieben - vom Stack Overflow Ersatz bis AI-Only.

Mehr davon in meinem Buch

Die erweiterte Ausgabe von Amazing CTO hat ein Kapitel mit 39 KI-Regeln - Strategie, Tools, Rollen, Kultur und Kontrolle. Das Buch ist auf Englisch.

Häufige Fragen zu KI für CTOs

Was haben Entwickler von KI?

Weniger langweilige Arbeit, vor allem. Entwickler hassen Boilerplate, Variablen über 50 Dateien umbenennen und den hundertsten CRUD-Endpoint. Das macht jetzt die KI. Der Gewinn ist nicht “schnellerer Code” - der Gewinn ist, dass deine Senior Engineers an den schweren Problemen arbeiten statt an den öden.

Wie bekomme ich Entwickler dazu, KI zu nutzen?

Erwartung setzen. “Jeder nutzt Cursor” oder “Bugs werden zuerst mit Claude Code gefixt”. Mach es zum Default, nicht zur Option. Dann geh aus dem Weg. Manche Entwickler werden sich wehren - gib ihnen drei Monate. Wer dann immer noch keine KI anfasst, während die Kollegen doppelt so schnell shippen, passt sich an oder sortiert sich selbst aus. Und mach es nie zum Thema “Entwickler ersetzen”. Mach es zum Thema Superkräfte.

Wie verändert KI die Rolle der Entwickler?

Das ist die große Frage, und niemand kennt die Antwort. Meine Vermutung: weniger “ich schreibe nur Code”-Entwickler, mehr Product Engineers, die Features end-to-end verantworten. Wenn die KI den Code schreiben kann, wandert der Wert dahin, zu wissen, welcher Code geschrieben werden soll - Kunden verstehen, Produktentscheidungen treffen, das Business mitdenken.

Warum Prompt-Training?

Weil Prompting eine Fähigkeit ist und die meisten Entwickler schlecht darin sind. Ich habe Entwickler “fix den Bug” in Claude tippen sehen, die sich dann beschweren, dass KI nicht funktioniert. Daneben sitzt jemand, der Kontext, Constraints und Beispiele in den Prompt schreibt - und bekommt funktionierenden Code im ersten Versuch.

Wie messe ich den Effekt von KI?

Erst Adoption: Nutzt es überhaupt jeder, jeden Tag? Dann Impact: Tickets pro Sprint, Zeit bis zum ersten PR, Bug-Durchlaufzeit. Vorsicht - diese Metriken lassen sich gamen. Der Test ist, ob ihr mehr Wert zum Kunden shippt. Und erwarte keine Wunder im ersten Monat, KI ist eine Fähigkeit, die Zeit braucht.