Der Engpass war nie das Modell: der Monat, in dem das Disziplin-Argument seine Zahlen bekam

Willkommen zu Ausgabe 7 von The CAIO.

Ich argumentiere seit Jahren, dass das Modell der kleine Teil ist und die Disziplin drumherum die eigentliche Arbeit. Das ist eine Behauptung, bei der man leicht nickt und die man ebenso leicht als Beratersatz abtut. Im Juli hörte sie auf, ein Satz zu sein. Eine Forschungsgruppe hat sie an 5'000 Codebasen getestet und eine Zahl daran gehängt. Ein Systemingenieur hat eine virale Prahlerei über “37'000 Zeilen am Tag” auseinandergenommen und gezeigt, was dieses Volumen tatsächlich kostet. Beide Posts sind weit über mein übliches Publikum hinaus gelaufen, einer davon mit der höchsten Reichweite des Jahres. Das Publikum ist des Arguments nicht müde. Es will die Belege.

Diese Belege sind das Rückgrat dieser Ausgabe. Die Rechnung aus dem Juni ist nicht verschwunden, sie hat eine neue Schlagzeilenzahl für 2029, die in jede Verwaltungsratsunterlage gehört. Die Managementebene, die Unternehmen laufend wegkürzen, erreicht inzwischen die Leute, die kürzen. Und unter allem läuft dieselbe These, jetzt von anderen in ihren eigenen Worten formuliert: KI repariert deine Organisation nicht, sie verstärkt, was ohnehin schon da ist.

Diese Ausgabe folgt dem, was das Publikum tatsächlich geöffnet hat. Der Beleg dafür, dass Disziplin und nicht das Modell entscheidet, ob KI hilft. Die Verflachung, die über die Mitte hinaus nach oben klettert. Die KI-Rechnung, die noch niemand einem Verwaltungsrat erklären kann. Warum “KI verstärkt, was schon da ist” derzeit der meistwiederholte Satz in meinen Kommentarspalten ist. Und ein leises philosophisches Paper darüber, warum der Mensch die Schleife nie verlässt.

Der Engpass war nie das Modell

#

Zwei Jahre lang lautete das Versprechen, ein besseres Modell werde die Lücke schliessen. Der Juli hat den bisher saubersten Beleg geliefert, dass es das nicht tut.

Fang bei den Daten an, denn das ist der neue Teil. Markus Borg, Adam Tornhill und Kolleginnen und Kollegen von CodeScene und der Universität Lund haben den ersten harten Test einer Frage veröffentlicht, an der ich seit zwei Jahren mit Kunden arbeite: Ist für Menschen lesbarer Code auch KI-freundlicher Code? Sie haben 5'000 Python-Dateien genommen, jede von sechs verschiedenen Modellen refaktorieren lassen und die ursprünglichen Tests gegen das Ergebnis laufen lassen. Das Resultat war über jedes mittelgrosse Modell hinweg konsistent. Bei gesundem Code haben die Modelle 15 bis 30 Prozent weniger Tests gebrochen. Dasselbe Modell, derselbe Prompt. Verändert hat sich nur der Code, von dem sie ausgegangen sind. Ihr Wartbarkeitswert hat den Erfolg der Refaktorierung 3- bis 10-mal besser vorhergesagt als die Selbsteinschätzung des Modells zur eigenen Antwort. Code, der Menschen verwirrt, verwirrt Maschinen auf dieselbe Weise, und jetzt hängt eine Zahl daran.

Lies das als Führungskraft, nicht als Engineer. Die meisten KI-Gespräche in der Chefetage drehen sich um welches Modell, welchen Copiloten, welches Budget. Das sind die einfachen Fragen. Die schwierige lautet, ob deine Codebasis KI überhaupt aufnehmen kann. Auf einem schwachen Fundament erzeugt mehr KI nur mehr Fehler, schneller. Technische Schulden waren früher ein Kostenproblem der Lieferung, das man verschieben konnte. In einer Codebasis, die man mit Agenten teilt, sind sie ein Risikomultiplikator, den man nicht verschieben kann.

Bryan Cantrill hat denselben Punkt vom anderen Ende gemacht, und deshalb ist sein Essay so weit gelaufen, als ich darüber geschrieben habe. Larry Wall, der Perl erfunden hat, hat einmal Faulheit als Kardinaltugend eines Programmierers bezeichnet. Er meinte nicht, weniger zu tun. Er meinte, die harte Abstraktionsarbeit vorne zu machen, damit alle danach weniger tun: die Bibliotheken, die Compiler, die Scheduler, die entstanden sind, weil jemand sich geweigert hat, dasselbe Problem zweimal zu lösen. Ein Modell hat kein Danach, das es zu schützen gilt. Es wird, in Cantrills Worten, fröhlich immer mehr auf eine Schichttorte aus Müll kippen. Sein Beweisstück war eine virale Prahlerei über 37'000 Zeilen Code am Tag. Ein Engineer hat ein solches Projekt auseinandergenommen und darin mehrere Test-Harnesses gefunden, eine Hello-World-Beispiel-App, einen versehentlich mitgelieferten Texteditor und acht Kopien desselben Logos, eine davon null Byte gross. Zum Vergleich: das gesamte DTrace, das Observability-Werkzeug in macOS und Solaris, umfasst rund 60'000 Zeilen. Volumen ist kein Fortschritt. Die Begrenzung ist der Teil, den das Modell dir nicht liefern kann, und sie muss von einem Menschen kommen, der eine Zukunft schützt, die das Modell nicht sieht.

Hier will ich präzise sein, denn ich habe letzten Monat eine Variante dieses Arguments zu den Kosten gemacht, und man könnte denselben Ton zweimal hören. Letzten Monat war der Punkt ökonomisch: Generierung wurde billig, also explodierte die Rechnung, und die Verifikation blieb teuer. Diesen Monat ist der Punkt strukturell und gemessen: Die Qualität dessen, was du bereits besitzt, entscheidet, wie viel das Modell sicher tun kann. Das sind zwei verschiedene Engpässe. Der eine handelt davon, wie viel du ausgibst. Dieser hier handelt davon, ob dein Fundament überhaupt Last trägt.

Die gute Nachricht ist, dass die Gegenmittel alt und unglamourös sind, und genau deshalb funktionieren sie. Ich habe diesen Monat meine eigenen CLAUDE.md-Dateien geprüft, nach Andreas Horns Anstoss dazu, und Regeln gestrichen, die Narbengewebe aus einem einzigen schlechten Ergebnis waren statt echte Prinzipien. Ich argumentiere weiterhin, dass test-first keine Vorliebe mehr ist: Wenn ein Modell den Code schreibt, bestätigt ein danach geschriebener Test nur, dass das Modell getan hat, was das Modell getan hat, während ein zuerst geschriebener Test die eine Stelle ist, an der deine Absicht festgehalten wird, bevor die Maschine rät. Testautomatisierung ist der engste Feedback Loop, den ein Team besitzt, und ihn im Maschinentempo zu überspringen liefert nur Risiko schneller aus. Und der unglamouröseste Input von allen, Testdaten, entscheidet still darüber, ob jeder Test darüber die Wahrheit sagt oder eine Geschichte über deine Software prüft. Nichts davon ist exotisch. Das ist Disziplin, angewandt auf die langweiligen Teile, und die CodeScene-Zahlen sagen, dass in den langweiligen Teilen die echten Gewinne liegen.

Die unbequeme Frage für den Verwaltungsrat hat also nichts damit zu tun, welches Modell man kauft. Zeig auf die Codebasis, die du heute besitzt, und sag mir, wo du einen Agenten nicht heranlassen würdest. Diese Lücke ist deine eigentliche KI-Strategie, und kein Modell-Upgrade schliesst sie für dich.

Die Ebene löst sich auf

#

Drei Jahre lang lautete die Geschichte über Verflachung, dass sie die Mitte trifft. Die Daten von 2026 sagen, dass die Welle klettert.

Der LeadDev Engineering Leadership Report hat 600 Führungskräfte dazu befragt, wo Managementstellen gestrichen wurden, und die Bewegung im Jahresvergleich ist die ganze Geschichte. Erste Führungsebene: 42 Prozent, dann 67, jetzt 59. Mittleres Management: 43, dann 56, jetzt 65. Oberes Management, also CTOs und VPs: 13, dann 18, jetzt 23. Die Ausdünnung hat an der Linie begonnen, ist in die Mitte gewandert und erreicht jetzt die Führungsspitze. Der Bericht liest das so, dass die Kürzungen weniger selektiv werden. Ich lese es anders. Es geht nicht darum, wer sicher ist. Es geht darum, wofür die Ebene da war.

Über den grössten Teil ihrer Geschichte hat eine Managementebene zwei menschliche Grenzen gelöst: wie viele Menschen eine Person überblicken kann, und wie Informationen nach oben und unten fliessen. Wenn KI und moderne Werkzeuge das Routing übernehmen, verliert die Ebene, deren Hauptaufgabe Routing war, ihren Existenzgrund. Das gilt an der Linie, und es gilt genauso oben. Eine Welle, die Ebene für Ebene das Diagramm hochwandert, ist eine Funktion, die sich auflöst.

Und hier ist der Teil, den die Verflachungs-Enthusiasten übersehen. Flache Organisationen sind seit Jahrzehnten gescheitert, meist weil die Koordinationstechnologie fehlte, um den Kontext zu halten, sobald man die Ebene entfernt, die ihn gehalten hat. Schau in denselben Bericht: Reorganisation ist mit 67 Prozent die häufigste Veränderung, seit Jahren stabil, während die tatsächlichen Kürzungen flach blieben. Die meisten Unternehmen schieben Kästchen hin und her, statt das gemeinsame Verständnis aufzubauen, das flach überhaupt erst funktionieren liesse. Kürze die Ebene ohne dieses Substrat, und du bekommst keine flache Organisation. Du bekommst Chaos mit einem aufgeräumteren Organigramm.

Olivier Wulveryck hat dieselbe Idee eine Ebene tiefer geschärft, in einem Beitrag, der mich nicht losgelassen hat: das Produktteam ohne Softwareentwickler. Die Schlagzeile ist zur Hälfte richtig und zur Hälfte eine Falle. Die richtige Hälfte: Die Engineers sind immer noch da. Sie sind umgezogen. Jedes Stück Komplexität, das die Fachperson nicht mehr sieht, existiert weiterhin, verlagert in die Plattform als Leitplanken, Bewertungsrahmen und Kontextverwaltung, alles gebaut von sehr erfahrenen Leuten. Die Falle steckt im Wort “reif”. Das Modell funktioniert nur, wenn die Plattform darunter deterministische Leitplanken, messbare Zuverlässigkeit und volle Nachvollziehbarkeit trägt. Die meisten Unternehmen haben das nicht einmal für ihre menschlichen Teams, geschweige denn für ihre Agenten. Nimm die Plattform weg, und “ein Team ohne Engineers” heisst nur unbeaufsichtigter Output, der schneller ausgeliefert wird, als irgendjemand ihn prüfen kann.

Das wirft die naheliegende Frage auf: Was genau ist diese Plattform? Ich habe sie Kaspar von Grünberg gestellt, der die Internal Developer Platform bekannt gemacht hat, in einem Gespräch, das ich diesen Monat aufgeschrieben habe. Seine Definition ist die sauberste, die ich gehört habe. Eine Plattform ist ein Satz von Pfaden entlang eines Wertstroms zu einem Geschäftsergebnis, und eine agentische Plattform pflastert diese Pfade für Agenten statt für Menschen. Du behältst die saubere Basis, Versionskontrolle, CI, Hosting, und ergänzt die zwei Dinge, die Agenten tatsächlich brauchen: Pfadspezifikationen, damit sie nicht bei jedem Lauf umherirren und Tokens verbrennen, und die Agenteninfrastruktur, die einen Agenten sicher betreibt und Hunderte davon mit Identität, Sicherheit und Observability steuert. Sein Satz dazu, was das für das Organigramm bedeutet, ist der, den ich Kunden immer wieder sage: Das Plattformteam ist die neue IT.

Was die Welle überlebt, an der Linie wie in der Chefetage, ist also dasselbe: Urteilsvermögen und das Coachen von Menschen. Informationsweitergabe lässt sich automatisieren. Zu entscheiden, was zählt, eine Wette zu entschärfen, ein Team ehrlich zu halten, das nicht. Die LeadDev-Daten stützen das: Führungskräfte werden technischer, nicht weniger technisch, und die, die bleiben, machen ihren Wert über die Entscheidungen sichtbar, die sie beschleunigen, statt über die Informationen, die sie weiterreichen. Wenn dein Hauptbeitrag darin besteht, Informationen nach oben und unten zu bewegen, steht die Welle bereits auf deinem Stockwerk. Was bringst du ein, das kein Dashboard und kein Agent liefern kann?

Die beängstigende Zahl sind nicht 596'000 Dollar

#

Der Juni stand unter der Rechnung, die kommt. Der Juli hat dieser Rechnung eine Schlagzeilenzahl für die Chefetage gegeben, und eine schärfere Art, darüber nachzudenken.

Tomasz Tunguz hat die Entwicklung modelliert, und die Zahlen sind eine Verwaltungsratssitzung wert. Anthropic gibt bereits das 2,3-Fache seiner Lohnsumme für Compute aus, rund zwei Millionen Dollar pro Mitarbeitendem und Jahr. Der Rest des Markts ist weit davon entfernt: Das oberste eine Prozent der Softwareunternehmen gibt rund 89'000 Dollar pro Engineer und Jahr für KI aus, der Median gibt 137 aus. Das ist ein Faktor 680. Tunguz modelliert drei Pfade bis 2029. Token-Deflation hält es bei rund 106'000 Dollar. Der mittlere Fall landet bei 363'000. Der optimistische Fall erreicht 596'000, wo die KI-Rechnung eines Engineers dem gesamten Umsatzbeitrag eines Median-Mitarbeitenden entspricht.

Die meisten CTOs lesen das und greifen zum naheliegenden Hebel: Ausgaben deckeln, Lizenzen rationieren, wenn die Rechnung kommt. Das ist der falsche Reflex, und ich sehe ihn bereits im Feld. Die beängstigende Zahl sind nicht 596'000 Dollar. Beängstigend ist, 596'000 Dollar auszugeben, ohne zu wissen, was man dafür bekommen hat. Nach der Rechnung zu deckeln ist Kostensenkung. Was du willst, ist Kostenkontrolle per Entwurf: jeder Token instrumentiert, jeder Agentenlauf an das Ergebnis geknüpft, das er erzeugt hat, die Ausgaben sichtbar und steuerbar, bevor sie den Verwaltungsrat erreichen. Deshalb bauen wir in unserem CTO Office ein AI Gateway. Jede Anfrage läuft über eine Stelle, und das gibt uns Transparenz über die Nutzung, Kostenzuordnung auf das richtige Projekt und die Option, Workloads lokal zu betreiben, wo das günstiger oder nötig ist. FinOps für Tokens. Wenn du den Ertrag pro Token nicht siehst, fliegst du bei einer halben Million pro Kopf blind.

Der tiefere Punkt steckt in diesem Faktor 680. Es ist überwiegend keine Budgetgeschichte. Die Medianfirma mit 137 Dollar nutzt KI praktisch nicht. Das oberste eine Prozent mit 89'000 Dollar hat einen Zinseszinseffekt, weil jeder ausgegebene Token ihnen zeigt, wo der Ertrag liegt. Was sie trennt, ist das Wissen, was jeder Token kauft. Ein Kommentator hat mich zu Recht darauf gestossen: Wert lässt sich nicht auf Token-Ebene messen, sondern nur eine Ebene höher, beim Workflow, wo eine Entscheidung schneller fiel oder ein Fehler vor dem Release gefunden wurde. Also instrumentiere die Ausgaben am Token und den Wert am Workflow, und verbinde beides. Die meisten Werkzeuge hören nach der ersten Hälfte auf, weil das die einfache Hälfte ist, und genau deshalb kommt die ROI-Diskussion nicht vom Fleck.

Es gibt dazu eine weitere Perspektive, die ich nützlicher finde als die Blasendebatte. Ein Argument aus dem Kapitalzyklus, das Blasen seit 200 Jahren verfolgt, sagt: Hör auf, auf die Nachfrage zu schauen, die lässt sich vortäuschen, und schau auf das Angebot, also auf das real gebundene Kapital. Big Tech ist auf Kurs, dieses Jahr rund 725 Milliarden Dollar auszugeben, viel davon im Kreis zwischen einer Handvoll Firmen und bei jeder Runde erneut als frische Nachfrage gezählt. Eisenbahnen in den 1840er-Jahren, Glasfaser in den 1990ern, Schiefergas vor einem Jahrzehnt: jedes Mal eine echte Technologie, jedes Mal trotzdem eine Blase, und jedes Mal waren die Gewinner nicht die Pioniere, die die Infrastruktur gebaut haben, sondern die Siedler, die sie danach günstig gekauft und disziplinierte Geschäfte darauf betrieben haben. Für die meisten Unternehmen ist der Siedlerzug konkret: Setz nicht die Firma auf ein Modell oder einen Anbieter, besitze deine Plattformebene, halte das Modell austauschbar, steuere die Ausgaben per Entwurf. Wenn die Preise schwanken und die Erträge sich verengen, hält dich genau diese Disziplin auf den Beinen. Weisst du, was dich deine teuerste KI-Anfrage letzten Monat gekostet hat, und wer entschieden hat, dass sie es wert war?

KI verstärkt, was schon da ist

#

Der nützlichste Denkrahmen des Monats kam von Adam Bender bei Google, und er ist eine Stunde eines Führungsteams wert: Verstärkung ist ein Betrag, keine Richtung. KI gibt dir mehr von allem, mehr Code, mehr Tests, mehr Verwirrung, und es ist ihr gleichgültig, wohin das geht. Teams mit starken Grundlagen richten diese Kraft auf etwas Nützliches. Teams ohne sie machen ein grösseres Chaos, schneller. Sein Gedankenexperiment ist das, mit dem man sich hinsetzen sollte. Wenn deine Arbeit plötzlich zehnmal mehr Aktivität aushalten müsste, was bricht zuerst? Nicht die glamourösen KI-Teile. Die langweiligen. Compile-Zeiten. Test-Compute. Der Code Review, wo die Prüfenden aufhören, genau zu lesen, um nicht zum Bremsklotz zu werden, bis niemand mehr wirklich auf die Codebasis schaut.

Wenn die Kraft richtungslos ist, dann ist das Liefern der Richtung die ganze Aufgabe, und diese Richtung kommt aus deinem Operating Model.

An unserem DevOps Meetup hat Ralf Günthner es noch direkter gesagt: KI verstärkt, was schon da ist. Eine lernende Organisation lernt mit KI schneller. Eine dysfunktionale wird dysfunktionaler, schneller. Seine Zahlen waren unverblümt, 67 Prozent der KI-Initiativen verfehlen ihre Ziele und weniger als 30 Prozent der Piloten erreichen Skalierung, und seine Diagnose lautete, dass die Technologie selten bricht. Die Organisation drumherum bricht: unklare Verantwortlichkeiten, Entscheidungen zu weit oben, Rollen, die nie für die Arbeit mit KI gebaut wurden. Am selben Abend hat Dagmar Muth die Team-Version gezeigt, in der das Verhältnis von Produktmanagern zu Engineers kippt, weil Bots Tickets schliessen, und gewarnt, dass jetzt alle schneller laufen, oft in verschiedene Richtungen, sodass Ausrichtung mit der Autonomie mitwachsen muss.

Die kleine, absurde Version davon habe ich selbst erlebt und in einem Podcast diesen Monat erzählt. Ich wollte intern ein neues KI-Werkzeug und bekam ein Ticket und ein Word-Dokument zum Ausfüllen. Also habe ich Claude genommen, um es auszufüllen. Die Person auf der anderen Seite hat mein Dokument dann mit KI geprüft. Zwei Agenten, die dasselbe Formular ausfüllen und prüfen, und der einzige Gewinner ist der Anbieter, der die Tokens verkauft. So sieht gerade viel KI-Adoption aus: einen bestehenden Prozess nehmen, KI obendrauf schrauben, ihn schlechter machen. Der ehrliche Schritt wäre gewesen, den Prozess zu löschen statt ihn zu automatisieren. Technologie war nie der Blocker. Prozess und Organisation sind es.

Trail of Bits ist der schärfste Fall dafür, wie es aussieht, wenn man den Verstärker ausrichtet, und ich habe ihn hier aufgeschrieben. In einer Studie mit 6'000 Führungskräften haben 90 Prozent der Firmen über drei Jahre keine Produktivitätswirkung durch KI gemeldet. Mit denselben Werkzeugen ist Trail of Bits von rund 15 gefundenen Fehlern pro Woche auf 200 gegangen. Der Unterschied war nicht das Modell. Die meisten Unternehmen haben Lizenzen verteilt und gewartet. Trail of Bits hat ein System gebaut, das Wissen seiner Expertinnen und Experten in wiederverwendbare Skills gegossen und KI zu einem Mitglied des Teams gemacht statt zu einem Tab, den man öffnet, wenn man nicht weiterkommt. Das ist die Linie zwischen AI-assisted und AI-native, und sie ist eine Entscheidung am Operating Model, keine Beschaffungsentscheidung. Dieselbe Trennung habe ich auf einem Industrie-Panel in Berlin gehört: Rund 88 Prozent im Raum hatten KI eingeführt, und nur eine Handvoll konnte auf echten Wert zeigen, weil alle dasselbe Modell mieten und der Vorsprung in der Organisation liegt, die man darum herum baut.

Nichts davon ist ein Technologieproblem. Es ist das älteste Problem im Management, Aktivität mit Fortschritt zu verwechseln, jetzt mit einem viel grösseren Motor. Wenn du deinen Teams vor einem Jahr KI gegeben hast und sich nichts verändert hat, war die KI nie das Problem. Was in deinem Operating Model bist du also wirklich bereit umzubauen?

Die Karte ist nicht das Gebiet

#

Ich schliesse mit einem leiseren Ton, denn diesen Monat ist ein Paper erschienen, das sauber formuliert, worauf ich seit Jahren aufbaue.

Alexander Lerchner, der in einem Frontier Lab arbeitet, das aber auf eigene Rechnung veröffentlicht hat, hat ein Paper geschrieben mit dem Titel The Abstraction Fallacy. Seine Behauptung ist strukturell, nicht biologisch. Egal wie gross das Modell oder wie clever die Architektur, algorithmische Symbolmanipulation kann kein Erleben erzeugen. Sein Argument läuft rückwärts zur üblichen Erzählung. Die Standardgeschichte lautet Physik, dann Berechnung, dann Bewusstsein. Lerchner dreht das um: Berechnung ist eine Beschreibung, die wir der Physik auferlegen, und dieses Auferlegen braucht ein bewusstes Wesen, das die Schnitte setzt. Der Kartograf sitzt vor der Maschine, nie dahinter. Oder wie er es sagt: Wir konstruieren keine neue Lebensform, wir bauen zunehmend genaue Vorhersagekarten. Eine perfekte Karte einer Stadt ist immer noch nicht die Stadt.

Ich will beim Status davon ehrlich sein, so wie Lerchner es war. Es ist ein Preprint eines einzelnen Autors, andere ernsthafte Forschende argumentieren das Gegenteil, und er lässt eine schmale Tür für nichtbiologisches Bewusstsein unter der richtigen Physik offen. Es ist kein gesichertes Ergebnis. Aber es formuliert die Position, auf der ich The Cybernetic Enterprise aufgebaut habe: KI ist das Nervensystem, die Menschen sind die Seele, an der Kante, wo das Modell auf die Realität trifft. Seine praktische Schlussfolgerung, die er ontologische Erleichterung nennt, lautet: aufhören, auf künstliche allgemeine Intelligenz zu warten, und anfangen, angewandte Intelligenz zu bauen, angebunden an Feedback und eingesetzt, um Teams zu befähigen.

Das ist der rote Faden unter jeder Geschichte dieser Ausgabe. Disziplin, Organisationsentwurf, Kostenkontrolle, alles landet an derselben Stelle: Die Maschine trägt weder das Urteil noch die Verantwortung. Ein Mensch tut das. Die Frage, mit der ich dich lasse, ist also die, die das Paper für mich geschärft hat. Was verstärkt deine Organisation tatsächlich, das Verhalten der Maschine oder das Urteil der Person, die sie bedient?

Mein aktueller AI-Stack

#

Claude Code: weiterhin das Hauptwerkzeug für Berichte, Meetingvorbereitung, Coding und alles, was ich sonst tue. Die CLAUDE.md-Prüfung, die ich diesen Monat gemacht habe, gehört jetzt zum Ablauf: ein paar harte Prinzipien in der Wurzel, alles andere als Gerüst behandelt, das ich beim nächsten Modell-Upgrade ersetzen will. Die Disziplin, über die ich dauernd schreibe, fängt bei meinem eigenen Setup an.

Perplexity: Web-Recherche mit echten Quellen. Weiterhin die erste Adresse, wenn ich schnell Primärquellen brauche, und für die oben zitierten Papers hat es sich wieder bewährt.

NotebookLM: Dokumente hinein, Audio- und Video-Zusammenfassungen heraus. Diesen Monat nützlich für die längeren Texte, darunter das CodeScene-Paper und die Analyse von Tunguz.

Gemini: Bildgenerierung für die Cyberpunk-Titelbilder des Newsletters. Immer noch das schnellste für diesen Stil.

Wo du mich findest

#

Ich moderiere zusammen mit Martin Thalmann jeden Monat das DevOps Meetup Zürich bei Digicomp, zwei Vorträge pro Abend ab 17:30 Uhr. Das nächste ist am 20. August, mit Urs Enzler über die Trennung von Planungs- und Lieferzyklen und Oleg Mayko darüber, ob SRE der neue Betrieb geworden ist. Das Herbstprogramm läuft monatlich weiter, bis zu einem Abend im Februar 2027 über den Betrieb von Infrastruktur ohne ein einzelnes Gehirn in der Mitte, mit Tristan Smagghe über komponierbare Kubernetes-Controller und Torsten Boettjer über absichtsbasierte Infrastruktur für Agenten. Wir sind bis weit ins Jahr 2027 ausgebucht, es lohnt sich also, früh einen Platz zu nehmen.

Weiter draussen kommen die DevOpsDays Zürich zu ihrem zehnjährigen Jubiläum am 14. und 15. April 2027 zurück.

Wenn diese Ausgabe bei dir angekommen ist, gib sie an eine Person weiter, die dasselbe Gespräch braucht, und schreib mir den einen Satz aus dieser Ausgabe zurück, den du dir an die Wand hängen würdest.

Bis im August.

Romano

The CAIO ist ein monatlicher Newsletter für C-Level und Führungskräfte, die KI-Entwicklungen in Operating Models übersetzen. Ausgabe 7 deckt Posts vom 27. Juni bis 18. Juli 2026 ab. Friday-Fun-Posts ausgenommen.