Ehemaliger Meta-Technologiegründer erklärt drei Dinge, die jeder CTO tun muss, bevor er KI anfasst

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 Organisationen 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 die 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 Organisationen einen zentralen Ort bietet, um jeden Agenten in der Produktion bereitzustellen, zu verwalten, zu überwachen und zu optimieren. Wir haben 44 Mio. US-Dollar aufgenommen – eine Series A unter der Führung von Google Ventures, an der sich NFX, Acrew, Scribble Ventures, Khosla Ventures und Webb Investment Network beteiligt haben. Unser Team besteht aus etwa 35 Personen und hat seinen Sitz in San Francisco.

Davor war ich Vice President of Engineering bei Meta DevInfra und entwickelte und betrieb die zentralen Entwicklertools, Dienste und Plattformen, die Metas Produkte unterstützten. Mein Team entwickelte Metas ersten internen KI-Agenten und erzielte damit unmittelbare Auswirkungen darauf, wie die Entwickler von Meta KI-Werkzeuge nutzten. Während meiner Zeit bei Meta war ich außerdem an der Entwicklung von Diem beteiligt und leitete die Entwicklungsabteilung von Instagram.

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

Wie KI dabei half, 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, weil dies die verkehrsreichste Zeit für seine Produkte ist. Jahrelang wurde während der risikoreichsten Wochen nichts veröffentlicht, um Vorfälle in der Produktion zu vermeiden. Das war sicher, bremste jedoch auch die unternehmensweite Produktivität mehr als einen Monat lang aus.

Mein Team entwickelte Diff Risk Score als Open-Source-Lösung, ein LLM-gestütztes 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 betrachten, führte das Modell eine Risikoeinstufung durch. Es wies jedem Diff einen kontinuierlichen Risikowert zu, der auf eine hohe Trefferquote ausgelegt war – beispielsweise markierte es 10 % der Diffs und erfasste dabei 60 % der Änderungen, die tatsächlich Vorfälle verursachen. Das Modell erlaubte es, Diffs mit geringem Risiko auch während des Freeze-Zeitraums einzuspielen, hielt jedoch diejenigen zurück, die es als riskant einstufte.

Dadurch ist der Freeze nicht länger eine Alles-oder-nichts-Entscheidung. Und der Diff Risk Score ermöglicht es Meta, damit zu beginnen, den Code-Freeze vollständig abzuschaffen – Entwickler 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 übergreifende Philosophie: Gebt Entwicklern kein von oben verordnetes KI-Mandat, sondern eine Infrastruktur – eine zentrale Plattform, ein Risikosignal, eine Steuerungsebene – und lasst sie selbst herausfinden, wo sie den größten Nutzen erzielen können.

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

Wenn du es nicht erklären kannst, kannst du es nicht veröffentlichen.

Ich setze KI-Werkzeuge intensiv ein, um die Arbeit zu beschleunigen, rate Entwicklern jedoch, vor der Veröffentlichung immer eine Validierung zu verlangen. KI ersetzt nicht das Urteilsvermögen von Entwicklern, sondern verschafft ihnen 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 Werkzeugen 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 einbetten, erkennen sie schnell Governance-Probleme — Agenten vermehren sich schneller als erwartet, und Budgets lösen sich über Nacht auf. Sie benötigen dieselbe Governance-Ebene für nichtdeterministische Agenten, die Sie auch für Menschen einrichten würden, die diese Infrastruktur nutzen — das bedeutet, dass Menschen weiterhin Budgetgrenzen, Zugriffsbeschränkungen und Prüfanforderungen festlegen.
• Einführungsstrategie: Sie schreiben die Nutzung von KI-Tools nicht vor — eine aus eigener Überzeugung entstehende Nutzung ist besser als eine vorgeschriebene Nutzung, da Vorgaben nur zu oberflächlicher Nutzung führen. Die Entscheidung, wie KI in den Arbeitsablauf eines Teams integriert wird, ist eindeutig eine menschliche Führungs- und Kulturentscheidung — das Tool kann sich bewähren, aber die Entscheidung über die Einführung kann nicht automatisiert werden.

Warum Engineering-Teams ihre Architektur neu überdenken müssen

Die frühe Datenverarbeitung begann mit einem zentralen Großrechner, den sich alle teilten, und wechselte dann zu Server-Racks, auf denen spezialisierte Dienste liefen. Agenten folgen demselben Entwicklungspfad.

Die frühere 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. Unternehmen erkennen jedoch, dass ihre Realität nicht aus einer Handvoll gemeinsam genutzter Tools besteht, sondern eher aus einem Ökosystem spezialisierter, zweckgebundener Agenten. Das zwingt zu einer Neubewertung dessen, was „Architektur“ für eine Codebasis überhaupt bedeutet: weniger ein Monolith mit Plugins, mehr eine Welt der Microservices, nur dass die Dienste anstelle von Endpunkten aus Agenten bestehen.

Der Instinkt in den meisten Organisationen besteht 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 für das Budget verantwortlich ist und wer zur Verantwortung gezogen wird, wenn etwas schiefgeht — als Managementfragen und nicht als Fragen der Bereitstellung verstanden. Es ist eine andere Art, die Beziehung eines Teams zu seinen Werkzeugen zu strukturieren.

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

In meinen früheren Rollen hätte ich mir gewünscht, dass wir die Governance-Ebene eingerichtet hätten, 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 wuchs rapide, und das Infrastrukturteam geriet plötzlich unter erheblichen Druck, mit der Nachfrage Schritt zu halten — es versuchte buchstäblich, Zehntausende freie Server zu finden.

Im Rückblick wäre das vermeidbar gewesen. Wenn Sie davon ausgehen, dass sich die Nutzung intern viral verbreiten könnte, integrieren Sie die Kostenkontrollen und Zugriffsbeschränkungen von Anfang an in die Plattform und nicht erst als Notfallmaßnahme.

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

James teilt

\u003cstrong\u003eCTOs müssen die Grenze zwischen \u0022\u003cem\u003ewo KI lebt\u003c/em\u003e\u0022 und \u0022w\u003cem\u003eorauf KI zugreifen kann\u003c/em\u003e\u0022 neu gestalten — sie muss aus dem Editor in die Infrastruktur verlagert werden, denn dort entsteht das Risiko und dort muss die Governance angesiedelt sein.\u003c/strong\u003e

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 besteht nicht darin, „ein Modell zu prompten“, sondern darin, an einem zentralen Ort nachzusehen, welche Agenten für diese Aufgabe bereits existieren, und einen davon abzuzweigen, statt ganz von vorne anzufangen. Organisationen müssen Prozesse schaffen, die es ermöglichen, Agenten problemlos zu übernehmen.

Drei Ratschläge für CTOs, die KI in technische Organisationen integrieren

Hier ist mein Rat:

1. Schreibt es nicht vor – verdient es euch. Die vorgeschriebene Nutzung von KI zur Produktivitätssteigerung frustriert mich, weil sie zu einer oberflächlichen Einführung führt – die besten Entwicklertools setzen sich durch, und Entwickler sind klug genug, sich nicht vorschreiben zu lassen, welche Tools sie gut finden sollen. CTOs sollten der Organisation geschäftliche Herausforderungen von enormer Größenordnung präsentieren – Probleme, die so groß sind, dass KI die einzige realistische Lösung darstellt. Dann sollten sie den Ingenieuren, die diese Herausforderungen lösen, ermöglichen, zu überzeugten Fürsprechern zu werden. 
2. Hört auf, KI als Werkzeug zur Inhaltserstellung zu betrachten, und seht sie stattdessen als Infrastruktur. 2025 war das Jahr, in dem Programmiertools wie Cursor und Copilot den Mainstream erreichten; jetzt hören Modelle zur Schlussfolgerung und mehrstufige Agenten auf, Erweiterungen für Editoren zu sein, 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 der Produktion. Wenn sich eure KI-Strategie immer noch um die Frage dreht, "welches IDE-Plugin wir kaufen sollten", löst ihr ein Problem von gestern.
3. Verwaltet Agenten so, wie ihr eine Belegschaft verwalten würdet, nicht so, wie ihr Software verwalten würdet. Agenten, die von Modellen zur Schlussfolgerung angetrieben werden, sind nichtdeterministisch – gebt demselben Agenten zweimal dieselbe Eingabe, und ihr könnt unterschiedliche Ergebnisse erhalten. Das ist kein Fehler, der behoben werden muss, sondern die grundlegende Natur dieser Technologie. CTOs verwalten bereits täglich nichtdeterministische Systeme – mit ihren Mitarbeitern. Ihr müsst einige derselben Schutzmaßnahmen auf Agenten anwenden, die ihr auch auf eure Belegschaft anwendet. Gebt einem Agenten am ersten Tag keinen uneingeschränkten Zugriff auf die Produktionsumgebung, keine Root-Zugangsdaten und kein unbegrenztes Cloud-Budget – genauso wenig, wie ihr diese Dinge einem völlig neuen Mitarbeiter geben würdet.

Folgt seinen Aktivitäten

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

Weitere Experteninterviews im The CTO Club folgen!