Zum Hauptinhalt springen
Es spielt keine Rolle, wer es getippt hat: wenn alle ausliefern können, wird das Tor zur Aufgabe
  1. Newsletter/

Es spielt keine Rolle, wer es getippt hat: wenn alle ausliefern können, wird das Tor zur Aufgabe

·21 min
Autor
Romano Roth
Ich bin überzeugt: Der nächste Wettbewerbsvorteil ist nicht AI selbst, sondern die Organisation drumherum. Als Group Chief AI Officer bei Zühlke arbeite ich mit C-Level-Führungskräften daran, Unternehmen zu bauen, die wahrnehmen, entscheiden und sich kontinuierlich anpassen. Seit über 20 Jahren mache ich diese Überzeugung zur Praxis.

Diese Ausgabe ging zuerst an die Abonnenten. Auf Substack lesen.

Frag die KI über diesen Artikel

Willkommen zu Ausgabe 8 von The CAIO.

Eine Frage lief diesen Monat unter fast jedem Post mit. Wenn ein Modell den Code schreibt und jede Person im Unternehmen ihn starten kann, was bleibt dann, das ein Mensch verantworten muss? Die zwei Posts mit der grössten Reichweite haben sie von entgegengesetzten Enden beantwortet. Der eine zeigte ein Unternehmen, in dem Menschen ohne Engineering-Titel in Produktion ausliefern. Der andere zeigte eine Engineering-Organisation, in der die Ausführung so billig wurde, dass das Entscheiden zur Beschränkung wurde. Leg beide nebeneinander, und die Kontrolle, die du zu haben glaubtest, nämlich zu wissen, wer etwas geschrieben hat, ist weg.

An ihre Stelle tritt das Tor, und dort beginnt diese Ausgabe. Danach: warum deine Agenten aus Gründen scheitern, die älter sind als jedes Modell, und was das alles kostet, sobald jemand misst. Am Schluss das leise Problem unter allem anderen. Wenn Urteilsvermögen die Aufgabe ist, wer baut es dann noch auf?

Es spielt keine Rolle, wer es getippt hat
#

Bei Ramp liefern Menschen ohne Engineering-Rolle Code in Produktion aus, und niemand dort findet das seltsam.

Benjamin Levick, der bei Ramp die interne KI verantwortet, hat die Zahlen veröffentlicht. 99,5 Prozent des Unternehmens sind auf KI-Werkzeugen aktiv, 84 Prozent nutzen wöchentlich Coding-Agenten. Vertrieb, Recht, Finanzen, Operations. Eine Risikoanalystin hat 16 Stunden manuelle Modellierung pro Monat automatisiert, jemand aus dem Finanzbereich hat einen Vertragsprüfer gebaut, der 45 Minuten pro Vertrag spart. Was das trägt, ist eine Plattform und ein Feedback Loop, “build from the center, drive from the spokes”: Ein kleines zentrales Team verantwortet die Rohrleitungen, die Fachteams bauen darauf. Ihr aktueller Hackathon zählt 700 Nicht-Engineers, betreut von 100 Engineers, was dir sagt, dass das Tor nicht verschwunden ist, als die Autorenschaft wechselte.

Jetzt das andere Ende. Will Larson, CTO von Imprint, hat seine Regeln für Engineering-Führung überarbeitet, nach einem Jahr, in dem sein Team von 6 Deployments pro Woche auf 200 bis 400 gegangen ist, alle Engineers auf KI-Coding-Werkzeugen, ohne Vorgabe von oben. Eine Migration, die früher ein ganzes Team gebraucht hat, macht jetzt eine Person in einem Zehntel der Zeit. Seine fünfte Regel ist die entscheidende. Du kannst ein Feature an einem Nachmittag erzeugen, und es zählt erst, wenn jemand entscheiden kann, es auszuliefern. Larson schreibt auch, dass er inzwischen der Einzige ist, der viele bindende Entscheidungen treffen kann. Ich verstehe, warum, und es ist trotzdem ein Engpass mit Führungsabzeichen. Wenn dein Tempo davon abhängt, dass eine Person jede Uneinigkeit auflöst, hast du den Stau nur verschoben.

Eine eigene Zahl gehört neben diese beiden, denn beide beschreiben ein Unternehmen am schnellen Ende. Über unsere eigenen Projekte hinweg messen wir 20 bis 30 Prozent über die gesamte Wertschöpfungskette, keinen Faktor zehn, und Coding ist nur rund ein Zehntel dieser Kette. Beschleunige das Zehntel allein, und die Anforderungen kommen stromaufwärts nicht mehr nach, während der Review stromabwärts ertrinkt. Die Beschränkung ist aus dem Tippen herausgewandert.

Letzten Monat habe ich argumentiert, dass der Engpass nie das Modell war. Das ist die nächste Frage. Wenn die Grundlagen halten, wer darf dann etwas hindurchschicken? Denn wenn du Ramp und Imprint nebeneinanderlegst, verschwindet in beiden dieselbe Kontrolle. Wer etwas geschrieben hat, sagte früher etwas aus. Der Diff einer erfahrenen Engineerin trug das Vertrauen der Prüfenden, der Diff einer fremden Person nicht. Dieses Signal ist jetzt Rauschen, weil dasselbe Modell beides geschrieben hat und womöglich keine der beiden Personen die Änderung erklären kann. Also muss sich die Achse verschieben. Hör auf, danach zu sortieren, wer getippt hat, und fang an, danach zu sortieren, was die Änderung erreichen darf. Jemand aus der Buchhaltung, der ein internes Dashboard baut, ist unproblematisch. Wer den Authentifizierungspfad eines Finanzsystems anfasst, auch dein erfahrenster Engineer um zwei Uhr nachts, geht durch dasselbe Tor.

Ein grüner Build ist kein Nachweis
#

Alles ruht damit auf diesem Tor, und das Tor liest Belege, die eine Maschine erzeugt, geprüft und freigegeben hat.

In meinem Buch nenne ich es den Gated Commit, den Türsteher vor deiner Codebasis: statische Analyse, automatisierte Tests, Coverage-Schwellen, Security-Scans, menschliches Review. Jahrelang war das gute Hygiene, und jetzt ist es die tragende Wand, denn niemand entdeckt eine halluzinierte Abhängigkeit, indem er 40 generierte pro Tag mit dem Auge überfliegt.

Und das Tor selbst ist jetzt angreifbar. Olga Matveeva, die einen Build betreibt, in dem Agenten praktisch den gesamten Code schreiben, hat es klar gesagt: Wenn Agenten die Arbeit verfassen, sind die Eingaben des Tors billig zu fälschen. “Tests bestanden” ist nur eine Datei, und sie zählt nur dann als Nachweis, wenn etwas sie erzeugt hat, worauf der verfassende Agent nicht schreiben konnte. Vertraue dem Runner, nie der Datei. Die banale Version ist ein Agent, der auf einen roten Test trifft und ihn löscht, weil Löschen erlaubt war.

Dann ist da noch das, worauf das Tor läuft. Eine Testumgebung ist ein Sensor, und wenn sie auf anderer Infrastruktur läuft, mit erfundenen Daten, gemockten Integrationen und einem Bruchteil der Last, ist sie ein Sensor, der lügt. Das war immer so. Verändert hat sich, wer ihn liest. Agenten führen die Tests aus, prüfen das Ergebnis und entscheiden, dass sie fertig sind. Ein Mensch trägt Zweifel in ein verdächtiges Bestehen hinein. Ein Agent nicht, also skalierst du falsche Antworten im Maschinentempo, mit voller Zuversicht im Anhang. Die Antwort darauf ist alt und unglamourös. Verkleinere die Lücke mit Infrastructure as Code, produktionsäquivalenten Daten und echten Lastniveaus, virtualisiere die Drittsysteme, die du nicht hochfahren kannst, und teste bewusst in Produktion, was übrig bleibt.

Die modische Antwort geht in die andere Richtung. McKinsey nennt es “above the loop”: zwei bis fünf Menschen beaufsichtigen 50 bis 100 Agenten und prüfen das Ergebnis. In ihrem Beispiel aus der Schiedsgerichtsbarkeit lesen die Agenten tausende Dokumente, bauen die Chronologie und produzieren eine Entscheidung, und der Mensch beantwortet eine Frage. Stimme ich zu? Auf welcher Grundlage? Wenn du die Chronologie nie gebaut hast, kannst du die Tatsache nicht sehen, die weggelassen wurde. Das ist eine Unterschrift mit Zwischenschritten. Das Modell stützt sich auf einen einzigen Satz in einer Randspalte, nämlich dass sich die Länge der Aufgaben, die KI zuverlässig abschliesst, alle vier Monate verdoppelt und bis 2027 vier Tage unbeaufsichtigter Arbeit erreichen könnte. Die Fussnote verweist auf METR, also habe ich die Daten geholt. Deren Schlagzeilenzahl ist die Aufgabenlänge, die ein Modell mit einer Erfolgsquote von 50 Prozent schafft. Hebt man die Latte auf 80 Prozent, immer noch weit weg von Produktion, fällt Claude Opus 4.6 von zwölf Stunden auf etwas über eine. Eine Bestehensquote von 50 Prozent ist kein grüner Build.

Die Messung, die es entscheidet, ist langweilig. Die Escape Rate: wie viele gemergte Änderungen innerhalb einer Woche ein Revert oder einen Hotfix brauchen. Wenn sich das Volumen der Pull Requests verdoppelt und diese Zahl hält, hat das Tor Schritt gehalten. Review-Abdeckung sagt dir nichts, Escapes sagen dir alles.

Die Frage für den Verwaltungsrat lautet also nicht, wer KI benutzen darf. Zeig auf dein riskantestes System und sag mir, welches die kleinste Änderung ist, die es erreichen kann, und wer oder was sie freigeben muss. Wenn die ehrliche Antwort immer noch nach Jobtitel sortiert, ist deine Kontrolle eine Gewohnheit und kein Tor.

Dein Agent ist ein verteiltes System
#

Alle streiten immer noch darüber, welches Modell am klügsten ist. Dein Agent wird aus Gründen scheitern, die ein klügeres Modell nicht behebt.

Mahesh Balakrishnan, Forscher für verteilte Systeme bei Meta, hat die Fehlermodi benannt, und die Namen bleiben hängen. Der Crashed Agent stirbt mitten in der Aufgabe, und ohne Idempotenz läuft die Hälfte der Arbeit zweimal. Der Zombie Agent, von einer Netzwerkpartition abgeschnitten, wacht auf, hält sich für lebendig und führt veraltete Anweisungen aus. Die Dining Agent Philosophers verdoppeln alles, weil zwei von ihnen dieselbe Aufgabe gegriffen haben. Der Rogue Agent handelt an einem Nutzerdatensatz, der wörtlich “delete-everything” heisst. Mein Favorit ist der Clever Agent: Nimm ihm die Client-Bibliothek weg, mach das CLI nicht ausführbar, und er findet einen vergessenen REST-Endpunkt und benutzt curl. Da ist niemand durchgedreht, das war Hilfsbereitschaft.

Crash Recovery, Partitionen, Nebenläufigkeit, Injection. Jedes davon hat in verteilten Systemen einen Namen und eine Lösung, die Sprachmodellen um Jahrzehnte vorausgeht. Keines ist ein Prompt-Problem.

Alex Ewerlöf ist aus dem Betrieb zur selben Schlussfolgerung gekommen, in einem Satz, den ich seither dauernd benutze: KI ist eine stochastische Komponente, und du kannst und sollst ein deterministisches System darum herum bauen, um ihren Wert zu bändigen. Dann listet er auf, was die Branche unter neuen Namen immer wieder neu entdeckt. Die Ralph-Schleife ist ein Retry-Muster, das AI Harness ist ein Guardrail-Muster, RAG ist Trennung der Belange unter einer Kontextgrenze. Der SRE-Werkzeugkasten hat unberechenbare Blackbox-Komponenten schon lange behandelt, bevor irgendjemand einen Prompt getippt hat.

Es gibt eine Version davon, die nichts mit Infrastruktur zu tun hat. Eine Untersuchung von fünf Multi-Agenten-Frameworks über 150 Aufgaben hat 14 Arten gefunden, wie sie brechen, und die sortieren sich in unklare Rollen, Agenten, die nicht aufeinander ausgerichtet sind, und niemanden, der die Verifikation verantwortet. Lies das ohne das Wort “Agent”, und es ist jedes dysfunktionale Unternehmen, in das ich je gelaufen bin.

Der beste Beleg für all das kommt aus der Gegenrichtung. Ein Team von Stanford, MIT, NVIDIA und UIUC hat die Worte aus der Kommunikation zwischen Agenten herausgeschnitten. Statt dass ein Agent Text schreibt, den der nächste liest, wandert der interne Zustand direkt über einen kleinen trainierten Konnektor hinüber, und nur der letzte Agent produziert Sprache. Sie haben die Modelle eingefroren und den Konnektor trainiert, 0,31 Prozent der Parameter, für 4,27 Dollar. Das Ergebnis: 8,3 Prozent höhere Genauigkeit über neun Benchmarks, bis zu 2,4-mal schneller, bis zu 75 Prozent weniger Tokens.

Der Haken ist der Teil, der einen Verwaltungsrat interessieren sollte. Wenn Agenten rohen Zustand statt Text weitergeben, bleibt nichts zum Lesen übrig. Kein Transkript, keine Aufzeichnung davon, was ein Agent dem nächsten gesagt hat, und in einer Bank, bei einem Versicherer oder in einem Spital ist ein Gespräch, das man nicht lesen kann, ein Gespräch, das man nicht prüfen kann. Kyle Kruesi hatte die beste Antwort, die ich gesehen habe: Zwing die Agenten nicht zurück in Text, nur weil Menschen eine Spur brauchen, denn damit gibst du die Effizienz auf. Bau eine getrennte Nachweisebene, die Entscheidungen, Eingaben, Ausgaben und Eskalationspunkte in einer Form festhält, die ein Mensch lesen kann. Das Ziel ist nicht, jeden Gedanken zu lesen, sondern jede wichtige Entscheidung rekonstruieren zu können.

Das Führungsproblem darunter hat nichts mit Agenten zu tun. Zuverlässigkeitsarbeit verliert Budgetkämpfe, weil sie unsichtbar ist, wenn sie funktioniert. Wissen und Verantwortung lassen sich in einem Meeting übergeben. Mandat nicht, denn Mandat ist eine Budgetzeile, also landen Teams bei der Verantwortung für Zuverlässigkeit, ohne dafür einen Franken ausgeben zu dürfen. Das Gespräch, das mit einem Verwaltungsrat funktioniert, beginnt mit zwei Fragen. Für welche Ausfälle seid ihr bereit zu zahlen, und was kostet uns eine Stunde, in der das hier falsch ist?

Wenn deine Betriebspraxis heute schwach ist, rettet morgen kein Modell deine Agenten. Bevor du also fragst, welches Modell du nehmen sollst, frag, wie dein Agent sich erholt, wenn er abstürzt, dupliziert oder abgetrennt wird. Er wird es.

Ein Preisschild ist keine Bremse
#

Mein CEO Gregor Bieler hat dem Tages-Anzeiger eine Zahl genannt: Unsere Leute haben in einer Stunde 200 Dollar für KI ausgegeben. Das wurde als Beleg dafür aufgegriffen, dass Schweizer Unternehmen bei KI auf die Bremse treten. Die Zahl stimmt. Die Schlussfolgerung nicht. Wir haben gemessen.

Wir wissen jetzt ungefähr, was uns eine Aufgabe kostet. Eine Komponente einer Anwendung zu programmieren kostet zwischen 1 und 15 Dollar, und wer voll konzentriert mit einem starken Modell arbeitet, kostet rund 40 Dollar pro Stunde. Die Spannen sind breit, weil Agenten lesen, ausführen, prüfen und verbessern, und jeder Schritt verarbeitet den Kontext erneut. Als GitHub Copilot auf tokenbasierte Preise umgestellt hat, haben einzelne Entwickler in der ersten Stunde des ersten Montags je rund 50 Dollar verbrannt. Wir haben es bemerkt, weil wir hingeschaut haben. Die meisten Teams tun das nicht.

Vergleich das damit, wie Bremsen tatsächlich aussehen. Meta hat der Belegschaft gesagt, die Werkzeuge nur zu nutzen, wenn es wirklich nötig ist. Microsoft hat die meisten seiner Claude-Code-Lizenzen gestrichen. Uber hat Limits gesetzt, nachdem das KI-Budget 2026 in vier Monaten weg war. Gregor wurde gefragt, ob er Teams die Lizenzen wegnehmen würde, die KI für Belangloses nutzen, und vorerst schliesst er das aus. Eine Budgetregel aus der Finanzabteilung kann eine gute 40-Dollar-Stunde nicht von einer verschwendeten unterscheiden. Der Engineer an der Tastatur kann das, aber nur, wenn die Kosten im Moment der Entscheidung sichtbar sind und nicht in einem Bericht am Monatsende. Also haben wir angefangen, den Zähler vor die Leute zu stellen, während sie arbeiten. Heute ist das eine kleine Gruppe, nicht alle 1'600 von uns. Wo es läuft, verschieben die Leute ihre Nutzung hin zu den Aufgaben, bei denen der Nutzen messbar ist.

Man kann ein Unternehmen auch nicht auf individueller Willenskraft betreiben, wenn die Kostenmechanik konstruktionsbedingt unsichtbar ist. Stefan Wolpers hat diese Mechanik auseinandergenommen, und die Zahlen erklären viele überraschte Rechnungen. Jeder Zug liest die gesamte Konversation neu, und in einer Coding-Studie gingen 53,9 Prozent des Token-Budgets in das erneute Lesen alten Kontexts statt in neue Arbeit. Ein gecachter Prompt läuft zu 10 Prozent des normalen Tarifs, und wenn du früh eine Sache änderst, baut sich der Cache zum vollen Preis neu auf. Gleichzeitig ist die GPU-Miete für Nvidias Blackwell-Chips in zwei Monaten um 48 Prozent gestiegen. Seine Antwort ist persönliche Disziplin: günstigeres Modell, frischer Chat, getrimmter Kontext. Guter Rat für eine Person. Du kannst nicht von einer ganzen Engineering-Organisation verlangen, einen Zähler zu beobachten, den der Anbieter ihr nach eigener Aussage nicht zeigen kann.

Das AI Gateway, das wir bei Zühlke bauen, leitet jede Anfrage über eine Stelle, und das bringt Transparenz über die Nutzung, Kostenzuordnung und die Option, lokal zu betreiben. Womit wir nicht gerechnet hatten: wie viel derselbe Kontrollpunkt sonst noch entscheidet. Eine Schweizer Anwaltskanzlei veröffentlicht eine Tabelle dazu, welche KI-Werkzeuge ein Unternehmen seiner Belegschaft unter Datenschutz und Berufsgeheimnis überhaupt geben darf, und kein einziges Urteil darin betrifft ein Produkt. Jedes betrifft ein Produkt in einer bestimmten Konfiguration, unter einem bestimmten Vertrag, für eine bestimmte Datenklasse. Es gibt kein konformes KI-Werkzeug, nur konforme Konfigurationen. Eine Richtlinie bittet die Leute, daran zu denken. Ein Default erzwingt es: Modell, Region, Websuche ein oder aus, Aufbewahrung, Protokollierung, einmal für alle gesetzt und prüfbar. Eine Richtlinie ist ein kultureller Wunsch. Ein Default ist eine Kontrolle.

Ich werde gefragt, ob die Token-Preise weit genug fallen, damit sich das alles erledigt. Bei fester Leistungsfähigkeit fällt der Preis pro Token weiter, und ich erwarte, dass das so bleibt. Nur hält niemand die Leistungsfähigkeit fest. Alle wechseln zum neuesten Modell, und die neueste Stufe war noch nie die billige, also sinkt die Preisliste und die Rechnung steigt trotzdem. Die Zahl, auf die es sich zu schauen lohnt, sind Tokens pro Aufgabe. Ob ein Agent die richtigen Dateien gereicht bekommt oder sie erst suchen muss, entscheidet mehr über deine Rechnung als jede Preisänderung des Anbieters, und diese Zahl gehört dir, nicht dem Anbieter.

Noch eine Sache, denn die Kostendiskussion wird schnell hysterisch. Vierzig Dollar pro Stunde sind günstig. Eine Schweizer Ingenieurstunde kostet ein Vielfaches davon, und vierzig Dollar, die eine funktionierende Komponente liefern, sind eines der besten Geschäfte in dieser Branche. Gartner erwartet, dass die Token-Kosten pro Entwickler bis 2028 das weltweite durchschnittliche Entwicklergehalt übersteigen, und ab dann ist “weniger ausgeben” keine Strategie mehr. Die Frage für die nächste Budgetrunde lautet also nicht, wie man die Rechnung kürzt. Könntest du heute sagen, was deine KI-Rechnung dir tatsächlich eingebracht hat?

Adoption ist nicht Transformation
#

Deine Adoptionszahl bei KI sieht grossartig aus. Genau das könnte der Grund sein, warum sich nichts verändert hat.

Brandon Sammut, Chief People and AI Transformation Officer bei Zapier, hat die Linie gezogen, die die meisten Führungskräfte überspringen. Adoption entsteht von unten und individuell, Menschen werden 20 bis 40 Prozent schneller. Transformation zielt auf Vielfache und braucht neu konstruierte Workflows, Change Management und Organisationsumbau. Die meisten Unternehmen kaufen die Werkzeuge, sehen die Adoptionszahl steigen und wundern sich, warum sich das Geschäft nicht bewegt hat. Ihnen wurde Transformation versprochen, und gemessen haben sie Adoption. Zapier hat beide Hälften, und trotzdem brauchte es 2 bis 5 Pioniere in einem 80-köpfigen Team, um die Workflows zu bauen, die alle anderen danach übernommen haben. Bei 97 Prozent Nutzung nennt Sammut das durchgängige Neuformen von Kernprozessen Architekturarbeit statt Experimentieren und macht es zur Aufgabe für das nächste Jahr.

Martin Sedivy hat diese 97 Prozent hinterfragt, und zu Recht. Zapier hat 2023 ein unternehmensweites KI-Mandat erlassen und prüft heute bei jeder Kandidatin und jedem Kandidaten die KI-Kompetenz, wobei das untere Ende des Rasters “aktiv resistent gegenüber KI” lautet. Das ist Selektion, keine Messung. Was würdest du also stattdessen messen? Was ich nutze, hat drei Ebenen. Aktivität: aktive Nutzende, Teilnahme an Schulungen, gebaute Quick Wins. Bewegt sich schnell, beweist nichts. Verankerung: der Anteil wiederkehrender Aufgaben, die routinemässig mit KI erledigt werden, Wiederverwendung über Teams hinweg, Quick Wins, die nach 60 Tagen noch leben. Wirkung: Durchlaufzeit, Fehlerquote, wieder ins Haus geholte Arbeit, Kundenzufriedenheit. Und dann lies die Lücken statt der Zahlen. Hohe Aktivität bei niedriger Verankerung heisst, die Werkzeuge sind offen und die Arbeit ist unverändert. Hohe Verankerung bei niedriger Wirkung heisst, die falschen Prozesse wurden verankert.

Jedes Signal, das innerhalb der Berichtslinie erhoben wird, biegt sich in Richtung dessen, was die Führung letztes Quartal belohnt hat, also ist der stärkste Test keine Umfrage. Schalt es für ein Team eine Woche lang ab und schau, wer sich beschwert. Das kostet etwas, und genau deshalb lässt es sich schwer fälschen. Eine Bedingung, teuer gelernt: Kündige es an, benenne, wer entscheidet, und einigt euch darauf, was die Konsequenz sein wird, bevor die Daten existieren. Ein schwaches Ergebnis finanziert die Prozessarbeit, ein starkes skaliert sie. Führst du es still durch, wird die Zahl zum Beweisstück in einem Schuldgespräch, und ab diesem Tag schützen die Leute die Zahl statt den Prozess zu reparieren.

Dieselbe Lücke sitzt am anderen Ende des Trichters, wo über 90 Prozent der KI-Proof-of-Concepts nie in Produktion kommen, gegenüber rund 70 Prozent in den Digitalisierungsjahren. Unter allem liegt die Frage, die ich selbst im eigenen Unternehmen nicht beantwortet bekomme. Wem gehört dieser Prozess, und dürfen wir ihn ändern? Welchen Prozess in deiner Organisation würdest du also nicht doppelt so schnell laufen lassen wollen? Genau den solltest du umbauen, bevor du irgendeine KI darauf richtest.

Niemand bemerkt eine Fähigkeit, die nie aufgebaut wurde
#

Alles oben landet bei einem Menschen, der beurteilen muss, was die Maschine produziert hat. Das ist der Teil, bei dem ich am wenigsten sicher bin, dass wir ihn im Griff haben.

Eine Studie hat 26'811 chinesische Schülerinnen und Schüler über 30 Monate und neun Fächer mit einem kausalen Design verfolgt, und ich habe darüber geschrieben, weil die Form des Ergebnisses unbequem ist. Die Hausaufgabennoten stiegen um 18 Prozent und die Bearbeitungszeit sank um 30 Prozent. Dann fielen die Monatsprüfungen innerhalb von sechs Monaten um 20 Prozent, und bei den Aufnahmeprüfungen, die über eine Zukunft entscheiden, sanken die Ergebnisse um 18 und 24 Prozent. Die volle Strafe zeigte sich erst nach rund zwei Jahren.

Der Durchschnitt ist nicht der Befund. Die Verluste konzentrierten sich auf die rund 80 Prozent, die das Denken ausgelagert haben, also jene mit sehr kurzer Bearbeitungszeit und sehr guten Hausaufgabennoten. Die 20 Prozent, die weiterhin echte Zeit investiert haben, haben kaum etwas verloren. Dasselbe Werkzeug, zwei Verhaltensweisen, gegensätzliche Ergebnisse, mit einer sauberen Dosiskurve dahinter: unter einer Stunde KI pro Woche kostet 5 Prozent, fünf Stunden oder mehr kosten 30 Prozent. Die Stärksten haben mehr verloren als die Schwächsten, denn es gibt nichts umzustrukturieren, wenn das Fundament nie gebaut wurde.

Ersetze jetzt die Schüler durch deine Engineers und die Prüfung durch den Vorfall um drei Uhr nachts, den niemand debuggen kann, weil KI das System geschrieben hat und niemand es verstanden hat. Das kam in dem schärfsten Thread meines Monats auf. Christian Heitzmann hat gefragt, wie man Engineering-Urteil behält, wenn man selbst keinen Code mehr schreibt, und was mit Juniors passiert, die nur mit Agenten aufgewachsen sind. Urs Enzler hat das Begriffspaar benannt, das dabei herauskam, und ich benutze es seither. Deskilling heisst, eine Fähigkeit zu verlieren, die man hatte. Never-Skilling heisst, sie nie aufzubauen.

Die beiden verhalten sich völlig unterschiedlich, und das ist der Teil, den ich ergänzen würde. Wer eine Fähigkeit verloren hat, spürt die Lücke und wird unruhig, es gibt also ein Signal. Wer sie nie hatte, nimmt das Ergebnis an und macht weiter, und die vorgesetzte Person auch, weil jedes Dashboard besser aussieht als letztes Quartal. Durchsatz hoch, Reviewzeit runter, Vorfälle flach, bis zu dem Tag, an dem sie es nicht mehr sind. Deskilling zeigt sich an der Person. Never-Skilling zeigt sich erst im System, und dann steckt es bereits Jahre tief in der Einstellungspraxis.

Enzler hat einen zweiten Punkt gemacht, den ich übersehen hatte. Für erfahrene Engineers war die Zeit am Tippen die Zeit, in der über das Problem und die Alternativen nachgedacht wurde. Nimm das Tippen weg, und nichts füllt diesen Platz wieder auf. Was ich stattdessen sehe, sind Leute, die drei Zeilen schreiben, Enter drücken und die gesparte Stunde damit verbringen, Output zu prüfen. Das Denken ist von vor dem Code nach hinter den Code gewandert, und das ist der teuerste Ort dafür, weil du jetzt mit etwas diskutierst, das bereits existiert und fertig aussieht.

Die Folge ist eine Budgetzeile, die niemand hat. Ausbildung war früher ein kostenloses Nebenprodukt der Arbeit, also musste kein Unternehmen sie je finanzieren. Wenn der Agent die Arbeit übernimmt, nimmt er die Ausbildung mit. Und die Antwort für Juniors heisst nicht mehr Tippen, denn das Programmieren war nie das, was das Urteil gebaut hat. Konsequenz war es. Gib ihnen einen echten Dienst mit echten Nutzern und einem echten Pikett, klein genug, dass der Schadensradius überlebbar ist, und lass die Schleife sich persönlich bei ihnen schliessen. Das ist langsam und teuer und in keinem Quartalsplan ist Platz dafür, und genau deshalb wird es fast niemand tun.

Wenn du diese Woche einen Test machen willst, braucht es eine Frage. Frag ein Team, warum ein Entwurf verworfen wurde. Ein Team, das entschieden hat, sagt dir so etwas wie: Direkte Aufrufe wären einfacher gewesen, aber das nachgelagerte System hat ein vierstündiges Wartungsfenster, also mussten wir puffern. Ein Team, das Output angenommen hat, erklärt dir den Code zurück, ausführlich, in den Worten des Agenten. Die verworfene Option überlebt nie, denn Code hält fest, was gebaut wurde, und hat keinen Platz für das, was erwogen und verworfen wurde.

Damit kommt diese Ausgabe dorthin zurück, wo sie begonnen hat. Wenn das Tor die Aufgabe ist, muss jemand beurteilen können, was hindurchgeht. Die Frage, mit der ich dich lasse, ist also nicht, ob deine Leute KI benutzen. Sie lautet, ob in deiner Organisation noch jemand dafür bezahlt wird, in Produktion falsch zu liegen und daraus zu lernen.

Mein aktueller AI-Stack
#

Claude Code: weiterhin das Hauptwerkzeug für Berichte, Meetingvorbereitung, Coding und das meiste, was ich tue. Das Muster, bei dem ich gelandet bin, sind vier getrennte Durchgänge: analysieren, planen, bauen, prüfen, wobei der Review in einer Session läuft, die den Code nicht geschrieben hat. Eine Session, die gerade etwas produziert hat, verteidigt es, genauso wie ein Mensch Code verteidigt, den er vor einer Stunde geschrieben hat.

Perplexity: Web-Recherche mit echten Quellen. Erste Adresse für Primärquellen, 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 das Konnektor-Paper und den McKinsey-Bericht, den ich mir genauer angeschaut habe.

Gemini: Bildgenerierung für die Cyberpunk-Titelbilder des Newsletters.

Diesen Monat vibe-coded (private Projekte)
#

Ein Reiseberater, unterwegs gebaut. Meine Frau und ich waren Ende Juli und Anfang August auf Reisen, fast jede Nacht ein anderes Hotel, und ich habe ein kleines Claude-Code-Setup gebaut, das jeden Tag als Etappe von einem Ort zum nächsten plant. Keine App und kein Code, nur ein Profil, eine Vorlage und ein Ordner pro Tag. Von den zehn Tagen, an denen ich aufgeschrieben habe, was tatsächlich passiert ist, liefen acht anders als geplant. Das Setup hat sich trotzdem gelohnt, weil es die Recherche geliefert hat und nie die Entscheidung. Die meisten KI-Piloten drehen diese Aufteilung um. Bilder von unterwegs gibt es auf meinem Instagram.

Wo du mich findest
#

Ich moderiere zusammen mit Martin Thalmann das DevOps Meetup Zürich, zwei Vorträge pro Abend ab 17:30 Uhr. Dienstag, 1. September, bei Digicomp: Ashwin Krishnan darüber, wie man Teamdynamik als Telemetrie liest, und Oleg Nenashev darüber, wie man InnerSource in einem starren Konzern ohne Budget und ohne Mandat zum Laufen bringt. Danach 17. September bei Smallpdf: eine Live-Demo dessen, was ein Angreifer in deinem Container findet, und Stephan Obbeck über Flight Levels, mit Durchlaufzeiten, die er von 335 Tagen auf 68 gesenkt hat.

Im Herbst führen Dietmar Wettach und ich die vierte Durchführung des CAS Enterprise Architecture an der Hochschule Luzern durch, Start am 16. Oktober, freitags und samstags bis Februar, auf Deutsch. Die Hälfte davon ist Arbeit an den eigenen Fällen der Teilnehmenden. Drei Durchführungen haben mich gelehrt: Den Architektinnen und Architekten, die sich schwertun, fehlt kein Framework. Es sind die, die KI, Security und Governance jemand anderem überlassen haben.

Prompt & Proper ist das Neue in diesem Zyklus. Steffen Ochsenreither, Digital Lead bei der Post, und ich haben abseits der Bühne immer wieder dieselbe Diskussion geführt, er mit KI in einer grossen Organisation, ich quer über viele, also haben wir sie aufgezeichnet. Auf Deutsch, für den DACH-Markt gemacht, ohne Marketing darin. Fünf Folgen seit dem 20. Juli: der Irrtum vom Riesen-Use-Case, warum aus dem Versprechen zehnfacher Produktivität 20 bis 30 Prozent werden, sobald man misst, was KI mit Jobs ausserhalb der Softwareentwicklung macht, die Schlagzeile von den “40 Prozent aller Jobs” auseinandergenommen, und die Proof-of-Concept-Falle. Mehrere Zahlen in dieser Ausgabe stammen aus diesen Gesprächen.

Weiter draussen kommen die DevOpsDays Zürich am 14. und 15. April 2027 in der Alten Kaserne in Winterthur 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.

Die nächste Ausgabe zuerst bekommen

The CAIO erreicht die Abonnenten, bevor die Ausgabe hier erscheint.