Ehemaliger Meta-Technologiegründer nennt drei Dinge, die jeder CTO tun muss, bevor er KI einsetzt

James Everingham hat die Entwicklung bei einigen der fortschrittlichsten Unternehmen der Welt geleitet, darunter Meta. Derzeit ist er CEO und Mitgründer von Guild.ai, einer Steuerungsebene für KI-Agenten, die Unternehmen einen zentralen Ort bietet, um jeden Agenten in der Produktion bereitzustellen, zu verwalten, zu überwachen und zu optimieren.

Wir haben uns mit James zusammengesetzt, um zu erfahren, wie KI Arbeitsabläufe in der Softwareentwicklung verändert — und was Entwicklungsteams ändern müssen, bevor KI effektiv integriert werden kann. Das hat er uns erzählt.

Von Meta zum KI-Startup

Ich bin CEO und Mitgründer von Guild.ai, der Steuerungsebene für KI-Agenten, die Unternehmen einen zentralen Ort bietet, um jeden Agenten in der Produktion bereitzustellen, zu verwalten, zu überwachen und zu optimieren. Wir haben 44 Millionen US-Dollar eingesammelt — eine Series-A-Finanzierungsrunde unter der Leitung von Google Ventures, an der sich NFX, Acrew, Scribble Ventures, Khosla Ventures und Webb Investment Network beteiligt haben. Wir sind ein Team von etwa 35 Personen mit Sitz in San Francisco.

Zuvor war ich Vizepräsident für Entwicklung bei Meta DevInfra und entwickelte und betrieb die zentralen Entwicklertools, Dienste und Plattformen, die Metas Produkte antreiben. Mein Team entwickelte Metas ersten internen KI-Agenten und erzielte damit unmittelbare Auswirkungen darauf, wie die Ingenieure von Meta KI-Tools nutzten. Während meiner Zeit bei Meta war ich außerdem an der Entwicklung von Diem beteiligt und leitete als Entwicklungsleiter die Entwicklung bei Instagram.

In meiner 40-jährigen Laufbahn als Manager, Unternehmer und Technologieentwickler habe ich zahlreiche erstklassige Entwicklungsteams geleitet. Bei Yahoo war ich Vizepräsident für Entwicklung für die Medieneigenschaften von Yahoo, nachdem das Unternehmen Luminate übernommen hatte, ein von mir gegründetes Unternehmen für interaktive Bildtechnologie. Davor leitete ich Teams bei Oracle, Netscape Communications, Tellme (von Microsoft übernommen) und mehreren meiner eigenen Unternehmen.

Wie KI dazu beitrug, Metas jährlichen Code-Freeze abzuschaffen

Als ich bei Meta war, nutzten wir ein KI-Risikomodell, um den jährlichen Code-Freeze abzuschaffen.

Zuvor fror Meta seine Codebasis jedes Jahr von Mitte Dezember bis Januar ein, da dies die verkehrsreichste Zeit für seine Produkte ist. Um jahrelang Produktionsvorfälle während der risikoreichsten Wochen zu vermeiden, wurde nichts ausgeliefert. Das war sicher, bremste jedoch auch die unternehmensweite Produktivität für mehr als einen Monat aus.

Mein Team entwickelte Diff Risk Score als Open-Source-Projekt — ein von einem LLM betriebenes System, das die Wahrscheinlichkeit bewertet, dass ein Code-Diff die Produktion zum Absturz bringt. Anstatt jede Änderung während des Freeze-Zeitraums als gleichermaßen gefährlich zu behandeln, führte das Modell eine Risikotriage durch. Es wies jedem Diff einen kontinuierlichen Risikowert zu, der auf eine hohe Trefferquote ausgerichtet war — beispielsweise markierte es 10 % der Diffs und erfasste dabei 60 % der Änderungen, die tatsächlich Vorfälle verursachen. Das Modell ermöglichte es, Diffs mit geringem Risiko auch während des Freeze-Zeitraums einzuspielen, hielt jedoch diejenigen zurück, die es als riskant einstufte.

Infolgedessen ist der Freeze nicht mehr alles oder nichts. Und der Diff Risk Score ermöglicht es Meta, den Code-Freeze nun vollständig abzuschaffen — Ingenieure gewinnen Wochen in ihrem Kalender zurück, die früher ungenutzte Zeit waren, ohne auf das Sicherheitsnetz verzichten zu müssen, das der Freeze bot.

Das ist ein gutes Beispiel für meine übergeordnete Philosophie: Gebt Ingenieuren kein von oben verordnetes KI-Mandat, sondern stellt ihnen Infrastruktur bereit — eine zentralisierte Plattform, ein Risikosignal, eine Steuerungsebene — und lasst sie selbst herausfinden, wo sie den größten Hebel ansetzen können.

Warum Menschen Code erklären können müssen, bevor er live geht

Wenn du es nicht erklären kannst, kannst du es nicht ausliefern.

Ich nutze KI-Tools intensiv, um die Arbeit zu beschleunigen, rate Ingenieuren jedoch, vor der Auslieferung immer eine Validierung zu verlangen. KI ersetzt das Urteilsvermögen von Ingenieuren nicht; sie verschafft Ingenieuren mehr Spielraum, dieses Urteilsvermögen in großem Maßstab anzuwenden.

KI fließt inzwischen sowohl in die Risikobewertung als auch in die Ermittlung von Tools und Arbeitsabläufen ein.

Worin Menschen am besten sind:

• Governance und Leitplanken rund um die Agenten selbst: Wenn Teams Reasoning-Modelle und Agenten tief in die Infrastruktur integrieren, erkennen sie schnell Governance-Fehler — Agenten vervielfachen sich schneller als erwartet, und Budgets lösen sich über Nacht auf. Für nichtdeterministische Agenten benötigen Sie dieselbe Governance-Ebene, die Sie auch für Menschen einrichten würden, die diese Infrastruktur nutzen — das bedeutet, dass Menschen weiterhin Budgetgrenzen, Zugriffsgrenzen und Anforderungen an die Überprüfbarkeit festlegen.
• Einführungsstrategie: Sie schreiben die Nutzung von KI-Tools nicht vor — eine aus Überzeugung entstehende Nutzung ist besser als eine vorgeschriebene Nutzung, da Vorgaben zu einer oberflächlichen Einführung führen. Die Entscheidung, wie KI in den Arbeitsablauf eines Teams integriert wird, ist eindeutig eine Frage menschlicher Führung und Unternehmenskultur — das Tool kann sich selbst beweisen, aber die Entscheidung über seine Einführung kann nicht automatisiert werden.

Warum Ingenieurteams ihre Architektur neu überdenken müssen

Die frühe Datenverarbeitung begann mit einem einzigen Großrechner, den sich alle teilten, und entwickelte sich dann zu Racks voller Server, auf denen spezialisierte Dienste liefen. Agenten folgen demselben Muster.

Die alte Annahme bestand darin, eine Handvoll universell einsetzbarer Agenten zu entwickeln und ihre Nutzung um diese herum zu zentralisieren, ähnlich wie bei der Zentralisierung von Rechenleistung. Doch Unternehmen erkennen, dass ihre Realität nicht aus einer Handvoll gemeinsam genutzter Tools besteht — sie ähnelt eher einem Ökosystem spezialisierter, zweckgebundener Agenten. Das zwingt uns dazu, neu zu überdenken, was „Architektur“ für eine Codebasis überhaupt bedeutet: weniger ein Monolith mit Erweiterungen, mehr eine Welt der Mikrodienste, nur dass die Dienste aus Agenten statt aus Endpunkten bestehen.

In den meisten Organisationen besteht der Impuls darin, einen Agenten wie jedes andere Stück Software zu behandeln — die Spezifikation zu schreiben, ihn auszuliefern und konsistente Ergebnisse zu erwarten. Ich habe diesen Ansatz aufgegeben und ihn durch ein Belegschaftsmodell ersetzt. Dadurch werden Fragen der Organisationsgestaltung — wer was genehmigt, wer das Budget verantwortet und wer zur Rechenschaft gezogen wird, wenn etwas ausfällt — als Managementfragen und nicht als Fragen der Bereitstellung betrachtet. Das ist eine andere Art, die Beziehung eines Teams zu seinen Tools zu strukturieren.

Warum Governance vorhanden sein muss, bevor die Einführung von KI Fahrt aufnimmt

In meinen früheren Positionen hätte ich mir gewünscht, dass wir die Governance-Ebene aufbauen, bevor die Einführung Fahrt aufnahm, und nicht erst danach.

Als ich bei Meta war, begannen Ingenieure, eigene Agenten für die interne Plattform zu entwickeln und zu veröffentlichen. Die Zahl der Agenten stieg rapide, und das Infrastrukturteam musste plötzlich versuchen, mit der Nachfrage Schritt zu halten — es suchte buchstäblich nach Zehntausenden freien Servern.

Rückblickend wäre das vermeidbar gewesen. Wenn Sie davon ausgehen, dass sich die Einführung intern viral verbreiten könnte, integrieren Sie die Kostenkontrollen und Zugriffsgrenzen von Anfang an in die Plattform und behandeln sie nicht als Notfallmaßnahme.

CTOs müssen die Grenze zwischen „wo KI lebt“ und „worauf KI zugreifen kann“ neu gestalten — sie aus dem Editor in ihre Infrastruktur verlagern, denn dort entsteht das Risiko und dort muss Governance verankert sein.

James teilt

CTOs müssen die Grenze zwischen “wo KI lebt” und “worauf KI zugreifen kann” neu gestalten — sie aus dem Editor in ihre Infrastruktur verlagern, denn dort entsteht das Risiko und dort muss Governance verankert sein.

Warum Organisationen einen zentralen Ort benötigen, an dem Agenten abgezweigt werden können

Als Ingenieur war ich ein besserer Dieb als Programmierer. Ich suchte nach etwas, das meine Anforderungen teilweise erfüllte, passte es für meinen speziellen Zweck an und lernte dabei.

Der erste Schritt des Arbeitsablaufs lautet nicht „ein Modell mit einem Prompt versehen“, sondern einen zentralen Ort zu durchsuchen, um zu sehen, welche Agenten für diese Aufgabe bereits existieren, und einen davon abzuzweigen, statt bei null anzufangen. Organisationen müssen Prozesse schaffen, die es ermöglichen, Agenten einfach zu übernehmen.

Drei Ratschläge für CTOs zur Integration von KI in technische Organisationen

Hier ist mein Rat:

1. Schreibt es nicht vor – verdient es euch. Eine verpflichtende Nutzung von KI zur Steigerung der Produktivität frustriert mich, weil sie zu einer oberflächlichen Akzeptanz führt – die besten Entwicklerwerkzeuge verdienen sich ihre Nutzung, und Entwickler sind klug genug, sich dagegen zu wehren, wenn man ihnen vorschreiben will, welche Werkzeuge sie gut finden sollen. CTOs sollten der Organisation Herausforderungen von enormer geschäftlicher Tragweite präsentieren – Probleme, die so groß sind, dass KI die einzig realistische Lösung darstellt. Lasst dann die Ingenieure, die diese Probleme lösen, zu überzeugten Fürsprechern werden. 
2. Hört auf, KI als Werkzeug zur Erstellung zu betrachten, und seht sie stattdessen als Infrastruktur. 2025 war das Jahr, in dem Programmiertools wie Cursor und Copilot den Massenmarkt erreichten; jetzt verlassen Modelle mit Schlussfolgerungsfähigkeit und mehrstufige Agenten die Rolle von Erweiterungen für Editoren und werden stattdessen Teil der Infrastruktur von Unternehmen – sie reichen Code ein, führen Tests aus, arbeiten neue Ingenieure ein und verwalten das Verhalten in Produktionsumgebungen. Wenn eure KI-Strategie immer noch lautet: „Welches IDE-Plugin sollten wir kaufen?“, löst ihr ein altes Problem.
3. Verwaltet Agenten so, wie ihr eine Belegschaft verwalten würdet, nicht so, wie ihr Software verwalten würdet. Agenten, die von Modellen mit Schlussfolgerungsfähigkeit unterstützt werden, sind nichtdeterministisch – gebt demselben Agenten zweimal dieselbe Eingabe, und ihr könnt unterschiedliche Ausgaben erhalten. Das ist kein Fehler, den es zu beheben gilt, sondern die grundlegende Eigenschaft dieser Technologie. CTOs verwalten bereits täglich nichtdeterministische Systeme – nämlich Mitarbeiter. Ihr müsst auf Agenten einige der gleichen Schutzmaßnahmen anwenden wie auf eure Belegschaft. Gebt einem Agenten am ersten Tag weder uneingeschränkten Zugriff auf Produktionssysteme, Administratorkenntnisse noch ein unbegrenztes Cloud-Budget – genauso wenig, wie ihr all das einem völlig neuen Mitarbeiter geben würdet.

Auf dem Laufenden bleiben

Ihr könnt James Everinghams Arbeit auf X und LinkedIn verfolgen.

Weitere Experteninterviews folgen im The CTO Club!