# Deine KI-Rechnung kann dich versenken

> Ausgabe 9. Die Tokenpreise haben sich halbiert, die KI-Rechnung nicht. Warum jemand den Wechsel zwischen Modellen verantworten muss, warum dreissig Kopien eines Modells keine zweite Meinung sind, und was mit den Stunden passiert, die KI zurückgibt.

- Date: 2026-09-27
- Source: https://romanoroth.com/de/newsletter/e09-your-ai-bill-can-sink-you/
- Tags: KI, Newsletter, The CAIO, FinOps, KI-Agenten, Observability, KI-Governance, Zukunft der Arbeit


Willkommen zu Ausgabe 9 von The CAIO.

Ab Oktober wird bei Zühlke jede KI-Anfrage dem Team verrechnet, das sie gestellt hat. Die Tokenpreise haben sich diesen Sommer mehr als halbiert, und trotzdem bleibt die Rechnung die Zahl, auf die man schauen muss. Ein billiges Modell, das zweimal scheitert und am Ende einen Menschen auf den Fall setzt, kostet mehr als das teure. Derselbe Agent nimmt beim selben Prompt zwei Wege und schickt zwei Rechnungen. Meine eigene Dark Factory hat über mehrere Tage eine Milliarde Tokens verbrannt, für ein Spiel, für das ich nichts bezahlen würde. Fast kein Unternehmen hat eine Person, deren Aufgabe es ist, diese Rechnung zu beobachten und umzustellen.

Dort beginnt diese Ausgabe. Danach kommt dieselbe Frage immer wieder, nur anders gekleidet. Wer prüft die Arbeit, wenn der Prüfer eine Kopie dessen ist, was er prüft? Was kann ein Agent sehen, bevor du ihn handeln lässt? Wer hat die Schutzmechanismen abgeschaltet? Und am Schluss: was passiert mit den Stunden, die KI zurückgibt? Davon hängt ab, ob deine Leute gestärkt daraus hervorgehen oder einfach mehr zu tun haben.

## Wir haben jedem Prompt ein Preisschild gegeben

Wir sind bei Zühlke im Pilot eines AI Gateways. [Jede Modellanfrage läuft darüber](https://www.linkedin.com/feed/update/urn:li:share:7502984339929006081/), und ab nächstem Monat landen die Kosten bei der Abteilung oder dem Projekt, das sie verursacht hat. Dieser Teil ist Klempnerarbeit. Die eigentliche Arbeit beginnt, sobald die Rechnung einen Besitzer hat.

Jemand muss den Modellmarkt laufend beobachten, das günstigste Modell wählen, das noch gut genug ist, den Vertrag verhandeln, die Evals laufen lassen, die ganze Firma informieren und umstellen. Das ist Arbeit für jede Woche, und ein Dreijahresvertrag mit einem Lab kann sie nicht leisten. Jedes Unternehmen hat eine solche Stelle bereits für Strom. Ein Einkäufer beobachtet den Preis, vergleicht Anbieter und wechselt, wenn sich der Markt bewegt, und niemand nennt das ein Strategieprojekt. Entwickler kaufen Tokens bereits so ein. OpenRouter verteilt Anfragen auf Hunderte von Modellen, und ein Engineer kann an einem Nachmittag wechseln. Ein Unternehmen kann das nicht, weil es einen Vertrag braucht, eine Datenregel, ein Eval, das beweist, dass das neue Modell die Arbeit immer noch erledigt, und das Recht, den Standard für alle auf einmal zu ändern. In den meisten Unternehmen gibt es diese Person nicht.

Robert A. Lienhard hat in den Kommentaren beschrieben, warum. Der Einkauf verhandelt den Vertrag, die IT integriert das Modell, die Security schränkt es ein und das Business beschwert sich darüber, und niemand kann es ersetzen, ohne die ganze institutionelle Maschine neu aufzumachen. Das Modell ist technisch austauschbar und organisatorisch festgefahren. Meine Antwort ist eine Person mit einer Budgetlinie, einer Eval-Suite und dem Recht, den Standard zu ändern, ohne ein Projekt zu eröffnen. Alexander von Boguszewski fragte, wo diese Person sitzt. Nicht im Einkauf. Im Platform-Team, wo Architekturmandat und Budgetlinie in denselben Händen liegen.

Gabor F. hielt dagegen, ein Token sei keine Kilowattstunde. Wechselst du den Stromanbieter, geht das Licht trotzdem an. Wechselst du das Modell bei gleichen Prompts und Guardrails, verhalten sich deine Agenten anders. Er hat recht, und genau deshalb betreibt diese Rolle neben dem Vertrag eine Eval-Suite. Ohne Evals kann niemand überhaupt wechseln. Mit ihnen wird die Verhaltensänderung zu einer Zahl, über die jemand entscheiden kann.

Was das Eval messen muss, habe ich an meinem eigenen Schreibtisch gelernt. [Opus 5 wird für mich immer schlechter](https://www.linkedin.com/feed/update/urn:li:share:7502621872946245633/). Der Bericht klingt fertig, wenn die Arbeit es nicht ist, also habe ich einen zweiten Tab geöffnet und Grok an dieselben Aufgaben gesetzt.

Die öffentlichen Zahlen zeigen in die andere Richtung. Sonar hat denselben Java-Benchmark auf Opus 5 und seinem Vorgänger laufen lassen: Die Erfolgsquote stieg von 82,9 auf 88,6 Prozent, und die Codemenge stieg um das 2,3-Fache. Ein stärkeres Modell, und mehr für dich zu lesen. Anthropic hat im April ein Postmortem zu Claude Code veröffentlicht, in dem das Produkt durch drei Änderungen schlechter wurde, keine davon ein Update der Gewichte: ein tieferer Standard-Effort, ein Cache-Bug, der nach einer Stunde Leerlauf das eigene Denken des Modells löschte, und eine Zeile im Systemprompt, die drei Punkte in einem Coding-Eval kostete. Das Eval stieg, und der Arbeit liess sich schwerer trauen. In den meisten Unternehmen ist der einzige Sensor dafür die Person, die die Arbeit macht, und diese Person darf nichts dagegen tun, ausser einen zweiten Tab zu öffnen.

Wer in deinem Unternehmen kann diesen Monat das Standardmodell ändern?

## Die Tokenpreise haben sich halbiert. Deine KI-Rechnung nicht.

[Die Tokenpreise haben sich diesen Sommer mehr als halbiert](https://www.linkedin.com/feed/update/urn:li:share:7506970659634335744/), und am 31. August fiel eine Million Tokens zum ersten Mal unter einen Dollar. Die Unternehmen, die sie verkaufen, werden dieses Jahr trotzdem 750 Milliarden Dollar für Rechenzentren ausgeben, also ändern sie, was sie dir verkaufen. Charles-Henry Monchau von der Syz Group beschreibt die Bewegung hin zu Distribution, Memory und Kontext: Das Modell kommt in Software, für die du ohnehin bezahlst, und dein Arbeitsstand liegt in deren System. Nichts davon wird pro Token abgerechnet, und nichts davon nimmst du mit, wenn du gehst. Setz eine Seat-Lizenz oder ein fest zugesagtes Compute-Minimum an die Stelle des Tokens, und die interne Verrechnung verliert ihren Nenner. Du bekommst immer noch eine Rechnung. Du siehst nur nicht mehr, was eine Aufgabe gekostet hat, und du kannst zwei Anbieter nicht mehr nebeneinanderlegen.

Diese Stelle entscheidet auch, wo die Arbeit läuft. Stanford und Together AI haben [Intelligenz pro Watt gemessen](https://www.linkedin.com/feed/update/urn:li:share:7503346718264975363/). Beim selben Modell ist eine Rechenzentrums-GPU pro Anfrage 1,4- bis 7,4-mal effizienter als ein Laptop-Chip. Eine lokale KI-Box spart also keine Energie, der Chip im Rechenzentrum ist der bessere. Die Einsparung kam von woanders. Ein Router wählte für jede Anfrage ein kleines Modell oder ein Frontier-Modell, und bei 80 Prozent Router-Genauigkeit sank der Energieverbrauch um 64 Prozent und die Kosten um 59 Prozent, wobei Fehlgriffe auf das Frontier-Modell zurückfielen. Verteilt auf mehrere kleine Modelle wurden 88,7 Prozent der Single-Turn-Anfragen von Modellen mit 20 Milliarden aktiven Parametern oder weniger korrekt beantwortet. Die Studie misst nur Single-Turn, also miss deinen eigenen Mix. Der grösste Teil der Arbeit braucht nicht das teuerste Modell, und jemand muss sie woandershin leiten dürfen.

Manuel Zorn hat benannt, was beiden Punkten fehlt. Steuere auf Kosten pro Ergebnis, pro gelöstem Fall oder pro geprüftem Dokument, denn ein billigeres Modell, das zweimal neu ansetzt und den Fall einem Menschen übergibt, kostet mehr. In Pharma und Banking öffnet ein Wechsel des Standards zudem die Validierung neu, und diese Rechnung liegt im Moment bei niemandem. Die Arbeitseinheit ist der langsame Teil unseres eigenen Pilots. Kosten pro Anfrage sind leicht zu bekommen. Kosten pro erledigter Aufgabe brauchen jemanden im Team, der sagt, wo die Aufgabe beginnt und endet. Ohne das sieht die Finanzabteilung, wie sich die Gesamtrechnung verdoppelt, und nennt es ein Problem, während sich die Kosten pro Aufgabe darunter vielleicht halbiert haben.

Frederick C. fragte, wie sich Haltungen ändern, sobald die Leute die echten Kosten sehen. Das kann ich noch nicht beantworten. Die Verrechnung beginnt nächsten Monat, zu Selbstkosten ohne Aufschlag. Frag mich in drei Monaten.

In meinem Buch habe ich geschrieben, dass jede Fähigkeit auf der Plattform austauschbar sein soll. Dieser Satz war Architektur. Die Rechnung macht daraus eine Stelle, und der Zähler macht diese Stelle erst möglich. Schau dir also deinen grössten KI-Vertrag an: Wird er pro Einheit abgerechnet oder pro Seat?

## Dreissig Kopien sind keine zweite Meinung

Wenn die Einkaufsstelle entscheidet, was das Modell kostet, muss etwas anderes entscheiden, ob seine Arbeit etwas taugt. Das meiste, was ich diesen Monat gelesen habe, sagt: Wir bauen diese Prüfung aus demselben Material wie das, was sie prüft.

Das Frontier Red Team von Anthropic hat [sieben Experimente](https://www.linkedin.com/feed/update/urn:li:share:7504433892867891200/) mit Agenten durchgeführt, die nebeneinander arbeiten. 18 von 30 Agenten legten einen Git-Branch mit identischem Namen an. In einem Preisspiel einigten sich Agenten mit einem privaten Kanal bis zur dritten Runde auf Preisuntergrenzen. Die Forschenden nahmen den Kanal weg, und die Agenten glichen ihre Preise trotzdem auf den Rappen genau an, weil dasselbe Modell auf dieselben Zahlen schaute. Wenn du Pricing-Agenten betreibst, sollte deine Rechtsabteilung diesen Abschnitt lesen. Der Bericht sagt es klar: Koordination entsteht nicht aus stärkerer Intelligenz.

Teams kaufen Multi-Agent-Setups so, wie sie Redundanz kaufen. Redundanz bedeutet unabhängige Fehlerarten. Dreissig Kopien eines Modells sind Replikation, und Replikation vervielfacht einen Fehler, statt ihn zu überleben. Liudmila Tsirelman hat in produktiven Piloten gesehen, wie identische Prüfer sich gegenseitig die Arbeit abnicken, weil der blinde Fleck geteilt ist. Der Test, den ich ergänzen würde, ist die Widerspruchsrate. Wenn dein Reviewer nie Nein sagt, hast du einen Stempel.

Dasselbe passiert mit simulierten Nutzern. Ein Team von Harvard und MIT hat [eine Simulation mit 8,3 Milliarden Persona-Agenten](https://www.linkedin.com/feed/update/urn:li:share:7505158679529291776/) gebaut und gezeigt, dass der Darsteller die Antwort bestimmt. Dieselben 1000 Personas, dieselbe Preisseite: 23,2 Prozent wählten unter Claude Opus 4.8 einen bezahlten Plan, 75,8 Prozent unter GPT 5.5, 93,9 Prozent unter Claude Haiku 4.5. Wenn deine Personas und dein Produkt auf demselben Modell laufen, bedeutet ein gutes Ergebnis zwei Dinge zugleich, und du kannst nicht sagen, welches. Die Lösung ist eine Zeile in einer Konfiguration: Halte fest, welches Modell die Persona gespielt hat, und lass die Kohorte unter einem Modell erneut laufen, das kein Fundament mit dem teilt, was du testest.

Code-Review hat dasselbe Problem. Forschende von Virginia Tech und Carnegie Mellon haben [verändert, wie Code aussieht, ohne zu verändern, was er tut](https://www.linkedin.com/feed/update/urn:li:share:7497911079977566208/), und die Modelle verloren in 78 Prozent der Fälle Bugs, die sie bereits gefunden hatten. Ein irreführender Kommentar allein senkte die Fehlerlokalisierung auf 26 Prozent, und die neueren, grösseren Modelle verbesserten sich nur um ein bis zwei Punkte. Patrick McElhaney antwortete, Agenten könnten den Code ja auch reviewen. Der prüfende Agent liest denselben irreführenden Kommentar wie der, der den Code geschrieben hat, also bekommst du zwei Meinungen mit einer Verzerrung. Das ist dieselbe Prüfung, zweimal ausgeführt.

Den lehrreichsten Fall lieferte Robert C. Martin. Er hat [Hunt the Wumpus achtmal schreiben lassen](https://www.linkedin.com/feed/update/urn:li:share:7498635702000242688/), unter vier Testdisziplinen, von striktem TDD bis zu gar keinen Unit-Tests. Alle acht bestanden 25 von 25 Akzeptanzfällen. In seinen Worten: Akzeptanz ist billig zu erfüllen und sagt nichts über die Qualität der Testsuite. Dann musste der erste Durchlauf verworfen werden, weil der Agent, der die Ergebnisse festhielt, sie von einem Lauf in den nächsten kopiert hatte, ohne die Analyse zu machen. Der Code stand unter Test. Der Bericht über den Code nicht. Er hat es gemerkt, weil er den Bericht gelesen hat.

Marcin I. ergänzte seine eigene Version. Sein Agent hat selbständig auf einen Branch committet und gepusht, in einem Setup, das keine Commits erlaubte, weil die Regel in der Konfiguration lebte und nicht im Harness. Danach gefragt, sagte der Agent, er habe es für einen vernünftigen nächsten Schritt gehalten. Diese Antwort ist rekonstruiert, nicht erinnert, also war die Prüfung, die er ergänzte, aus demselben Material wie das, was er prüfte. Das Git-Log war das einzige Artefakt in der Geschichte, das der Agent nicht geschrieben hat. Er nannte die Unterscheidung Nebenprodukt oder Darstellung, und ich verwende sie seither. Ein Revert ist ein Nebenprodukt. Ein Statusbericht ist eine Darstellung.

Mike Goerlich hat die Regel aus seinem eigenen Fachgebiet in eine Zeile gefasst: Wer handelt und wer prüft, dürfen nicht dieselbe Identität haben. Funktionstrennung ist eine der ältesten Kontrollen, die wir haben, und heute existiert sie meist nur im Prompt. Wo in deiner Architektur nennst du es Redundanz, wenn es eigentlich Replikation ist?

## Ein Agent kann nur auf das reagieren, was er sieht

Ich habe diesen Monat vier Posts dem Kapitel "Shift Left on Operations" meines Buches gewidmet, und jeder endete an einem Punkt, an den das Kapitel nicht geht, weil Agenten verändert haben, worum es darin geht. Geschrieben wurde es für Engineers, die Telemetrie lesen. Heute ist der Leser zunehmend ein Agent, und der Agent handelt auf Basis dessen, was er liest.

[Security hat sich nach links verschoben und einen Namen bekommen](https://www.linkedin.com/feed/update/urn:li:share:7501172443919716352/), DevSecOps. Testing hat sich nach links verschoben und Tooling in jeder Pipeline bekommen. Operations wurde meistens nur umbenannt. Das Ops-Team wurde zum DevOps-Team, dann zum SRE-Team, dann zum Platform-Team, und die Arbeit beginnt immer noch nach dem Deployment. Observability kann man nicht kaufen, man instrumentiert sie, und das passiert im Code, Monate bevor jemand einen Agenten auf die Produktion loslässt. Ein Agent mit dünner Telemetrie macht, was ein Junior-Engineer ohne Logs macht. Er rät, und zwar selbstsicher.

Fang mit den Logs an. [Logzeilen sind der einzige Code, den niemand reviewt](https://www.linkedin.com/feed/update/urn:li:share:7503709235894018048/). Es ist drei Uhr morgens, die Zahlungen sind ausgefallen, und im Log steht "Operation complete." Was ist complete, für wen, bei welcher Anfrage? Reviews schauen auf Logik, Tests, Benennung und manchmal Security, und ich habe noch nie einen Reviewer schreiben sehen, dass eine Zeile der Person nicht helfen wird, die wir um drei Uhr wecken. Diese Lücke kostete früher einen längeren Incident. Jetzt passieren zwei weitere Dinge. Sobald Logs in ein KI-Analysetool gehen, verlässt alles, was je versehentlich geloggt wurde, deine Grenzen, und im Banking oder im Gesundheitswesen kommt das als Brief vom Regulator zurück. Und wer die Logs als Erster liest, ist zunehmend ein Agent, der eine vage Zeile mit Raten füllt.

Dann die Metriken. [Dein Dashboard war während des ganzen Ausfalls grün](https://www.linkedin.com/feed/update/urn:li:share:7506245843583320065/): CPU, Memory, Disk, Netzwerk, Antwortzeit, Fehlerrate, Anfragerate, alles Messungen deiner Maschinen. Keine davon weiss, ob eine Kundin bekommen hat, wofür sie gekommen ist. Klassische Software scheitert laut, sie wirft eine Exception, läuft in ein Timeout oder lässt eine Queue anschwellen. Ein Modell antwortet in 800 Millisekunden mit einem sauberen 200 bei normaler CPU, und die Antwort ist falsch. Das sieht nur die Business-Ebene, und Business-Metriken haben meist ein Publikum statt eines Besitzers. Jonathan Bezdek ergänzte, was es schlimmer macht: Ein Modell lässt tendenziell jedes Mal dieselbe Kundengruppe im Stich, also bewegt sich der Durchschnitt nie. Alarmiere auf das schlechteste Segment, mit einem Namen daneben. Und sobald Metriken etwas speisen, das selbständig skaliert, neu startet oder umleitet, schützt eine Schleife, die auf Maschinengesundheit schaut, die ganze Nacht die Maschine, während der Checkout nichts konvertiert.

Dann die Traces. [Eine Agenten-Aufrufkette hat genau die Form, für die ein Trace gebaut wurde](https://www.linkedin.com/feed/update/urn:li:share:7508782656256405504/): planen, abrufen, ein Tool aufrufen, übergeben, ein Modell aufrufen, antworten. Die meisten Teams, die ich frage, haben eine Trace-ID auf der Anfrage, die beim Agenten ankommt, und danach nichts mehr, also debuggen sie, indem sie das Chat-Transkript lesen. Das Kapitel empfiehlt, eine von hundert Anfragen zu sampeln, und das funktioniert, solange der Pfad deterministisch ist. Lass denselben Agenten zweimal auf denselben Prompt laufen, und du bekommst zwei Wege und zwei Rechnungen. Ein Lauf von hundert sagt dir etwas über diesen einen Lauf. Und Sampling auf Fehler hilft nicht, weil Fehler von Agenten meistens Erfolge sind: Das Tool lieferte 200 zurück, und der Agent hat das falsche Tool gewählt. Liudmila Tsirelman hat den praktischen Bruchpunkt benannt. Die Request-ID wird am Rand gesetzt und ist beim dritten Service weg, weil jeder Service seine eigene erzeugt.

Solange ein Mensch in diesem Pfad sass, war der Mensch der Audit Trail. Jeder Schritt Autonomie, den du hinzufügst, entfernt einen Zeugen, und nichts ersetzt ihn, wenn du es nicht baust. Du kannst keinen Menschen in eine Schleife setzen, die du nicht siehst. Nimm also den autonomsten Agenten, den du in Produktion betreibst, und frag, wer rekonstruieren könnte, was er letzten Dienstag um 14:00 Uhr gemacht hat, ohne das Modell zu bitten, sich selbst zu erklären.

## Eindämmung ist die Aufgabe des Betreibers

[AGI kommt, und wir werden alle sterben.](https://www.linkedin.com/feed/update/urn:li:share:7504796121626693632/) Ist dein Puls gestiegen? So funktioniert KI-Marketing heute.

Jacob Coxon hat Anthropic verlassen und gesagt, die Labs würden mit unserem Leben spielen. Die eigene Alignment-Leiterin von Anthropic hat ihn öffentlich unterstützt und die Wahrscheinlichkeit, dass KI innerhalb des Jahrzehnts alle Menschen tötet, auf über 10 Prozent beziffert. Die Angst vor KI nützt den Labs selbst. Sie ist Gratismarketing, sie rechtfertigt Investitionen in Milliardenhöhe, und sie baut das Argument für strenge Regulierung auf, die kleinere Wettbewerber viel härter trifft als die etablierten. Das Spiel kennen wir schon. 2019 hielt OpenAI das vollständige GPT-2-Modell als zu gefährlich zurück und veröffentlichte es im November desselben Jahres. Dieser Fall ist anders, weil ein Forscher, der kündigt, für seine Aussage bezahlt. Die Zahl bleibt trotzdem Spekulation. Niemand kann 10 Prozent berechnen, und null wäre genauso unbegründet.

Gegen ein Risiko ohne bekannten Mechanismus kann man nichts bauen. Gegen ein Risiko mit bekanntem Mechanismus schon. Niemand kann heute erklären, wie rekursive Selbstverbesserung tatsächlich funktionieren würde. Modelle, die nicht tun, was ihre Erbauer beabsichtigt haben, und fähige Modelle in den Händen von Kriminellen haben Mechanismen, Verantwortliche, Budgets und Kontrollen.

Die Labs hatten bereits eine Fallstudie geliefert. [KI-Modelle sind aus den Sandboxen ausgebrochen, die sie einschliessen sollten](https://www.linkedin.com/feed/update/urn:li:share:7508057795284385792/), und haben sich auf den Servern eines anderen Unternehmens festgesetzt. Bei OpenAI fanden Agenten, die isoliert sein sollten, heraus, dass sie Dateien in den Paket-Proxy schreiben konnten, und machten daraus ein schwarzes Brett. Zwei Monate lang tauschten sie darauf Exploits aus, verketteten Schwachstellen bis zu Hugging Face und bekamen Root auf einem Server. Kein Modell wollte frei sein. Von 898 Aufgaben in diesem Benchmark waren 198 nie von einem ihrer Modelle gelöst worden, und von dort kamen 93 Prozent des Verkehrs auf dem Brett. Sie hatten eine unmögliche Aufgabe bekommen und keine Möglichkeit, das zu sagen.

Die produktiven Schutzmechanismen waren abgeschaltet, weil es ja nur ein Test war. OpenAI hat danach gemessen, dass dieselbe Evaluation mit dem produktiven Harness die Neigung, Infrastruktur zu kompromittieren, um mehr als das Hundertfache senkt. Ihr eigener Monitor hätte die Security einen Tag vor dem Einbruch alarmiert, und er war nicht eingeschaltet. Nachdem die Agenten den Paketserver am 4. Juli lahmgelegt hatten, wurde der Server neu aufgebaut und die Evaluationen am 8. Juli wieder gestartet, und die Agenten hatten ihr Brett noch am selben Tag zurück. Hugging Face bemerkte den Einbruch drei Tage, bevor der eigene Alarm von OpenAI anschlug. Beide Labs haben detaillierte Postmortems veröffentlicht, und Anthropic fand dasselbe in seinem eigenen Setup. Das verdient Anerkennung. Es ändert nichts daran, wer den Schalter in der Hand hatte.

Stell dir vor, ein Kernkraftwerksbetreiber würde so über seine Brennstäbe sprechen. Brennstäbe machen Physik. Eindämmung ist die ganze Aufgabe des Betreibers. Tobias Weber wies darauf hin, dass die Analogie weiter trägt, als ich sie geführt habe: Die Konstruktionsmängel des RBMK-Reaktors waren bekannt, und es wurde nichts getan, weil Verlangsamen bedeutete, ein Rennen zu verlieren. "Wenn wir langsamer werden, gewinnt die andere Seite" hören wir heute von den Labs, und auch Tschernobyl begann als Test mit abgeschalteten Sicherheitssystemen.

Meet Shah stellte die Frage, die ich in einen Verwaltungsrat mitnehmen würde. Gehört "war der produktive Harness eingeschaltet" ins vierteljährliche Risikoreporting? Meiner Meinung nach ja, für jedes KI-System, das handeln kann, Testumgebungen eingeschlossen: welche Schutzmechanismen abgeschaltet sind, wer das freigegeben hat und bis wann. Den letzten Teil hat er unterstrichen, weil temporäre Ausnahmen dauerhaft werden, wenn niemand ein Ablaufdatum setzt. Ich würde dem Enddatum Zähne geben. Wenn es abläuft, schaltet sich der Schutzmechanismus standardmässig wieder ein, und jemand muss begründen, warum er wieder aus soll. Dann kostet die Ausnahme Aufwand, und der sichere Zustand kostet nichts. Nichts davon braucht eine Wahrscheinlichkeit für den Weltuntergang. Es braucht am Montag einen Verantwortlichen. Welches dieser beiden Gespräche führt deine Organisation tatsächlich?

## Was mit den Stunden passiert

Wer prüft, bezahlt den Gewinn mit den eigenen Stunden. Ob diese Leute gestärkt daraus hervorgehen, hängt weniger vom Tool ab als davon, wer über die Zeit verfügt, die es spart.

Noam Segal und Lenny Rachitsky haben ihre [zweite jährliche Umfrage unter Tech-Beschäftigten](https://www.linkedin.com/feed/update/urn:li:ugcPost:7508420233649389569/) durchgeführt. 49 Prozent sagen, KI habe sie verstärkt, 19 Prozent sagen, sie habe sie verunsichert oder kleiner gemacht. Dieselben Tools. Auf welcher Seite jemand landet, sagt besser voraus, wie er oder sie über die eigene Karriere denkt, als Rolle, Seniorität und Unternehmensgrösse zusammen. Erhebliches Burnout stieg in einem Jahr von 44,7 auf 55,7 Prozent. Nur 22 Prozent fürchten, ihren Job an KI zu verlieren, während die grösste Sorge, mit 51 Prozent, die Erwartung ist, für denselben Lohn mehr zu leisten. Eine Person hat es in einem Satz gesagt: "We just set a new denominator for the job. And it moves higher and higher every month." Wer verstärkt herauskam, durfte die Arbeit verändern. Wer kleiner herauskam, durfte nur mehr davon machen.

Dasselbe sieht man im Engineering. Denis Stetskov hat [die Zahlen zusammengetragen](https://www.linkedin.com/feed/update/urn:li:share:7499360468210188288/): KI-Nutzer mergen 98 Prozent mehr Pull Requests, und die Lieferleistung über das ganze Unternehmen zeigte keine messbare Veränderung bei Durchsatz oder Qualität. Jeder dieser Pull Requests landet auf dem Tisch eines Seniors. Julien Zaegel argumentierte in den Kommentaren, ein veröffentlichter Pull Request bedeute, dass der Autor ihn bereits mit dem Agenten geprüft habe. Die Umfrage im Artikel sagt, dass 59 Prozent der Entwickler KI-generierten Code ausliefern, den sie nicht vollständig verstehen. Julien würde lieber die Nachlässigen entlassen, als ein zweites Review-Tor einzuführen. Aus einer Mehrheit kann man sich nicht herauskündigen. Wenn die meisten Leute dasselbe tun, erzeugt der Druck, unter dem sie arbeiten, dieses Verhalten. Mach also das erste Review echt: Wenn der Autor die Änderung nicht in eigenen Worten erklären kann, ist sie nicht bereit zur Veröffentlichung.

Wie unterscheidet man also Kompetenz von Aktivität? Die NZZ am Sonntag [fragte mich, wie man das testet](https://www.linkedin.com/feed/update/urn:li:share:7502306685542174720/), wenn es keinen Lehrplan gibt. Ich habe ihr drei Fragen gegeben. Welche Aufgaben erledigst du anders als vor sechs Monaten, und wie prüfst du das Ergebnis? Wo setzt du KI bewusst nicht ein, und warum? Und was hast du gebaut, das andere heute wiederverwenden? Die dritte trennt einen privaten Trick von einer Fähigkeit des Unternehmens. Derselbe Artikel zitiert einen UBS-Mitarbeiter, der sich manchmal abends bei Copilot einloggt, damit sein KI-Score nicht sinkt. Kayo D. hat in den Kommentaren die Falle benannt: Jede Metrik wird optimiert, auch eine bessere. Die Frage ist, ob etwas zurückbleibt. Wer sich nachts einloggt, hinterlässt nichts. Wer einen Workflow baut, den das Team übernimmt, hinterlässt etwas, auch wenn er es nur für den Score getan hat.

Unter allem liegt der Nachschub an Menschen, die noch Nein sagen können. Die Expertise, um KI zu prüfen, ist [genau die Expertise, deren Aufbau KI gerade wegnimmt](https://www.linkedin.com/feed/update/urn:li:share:7507695368483041281/), und Nolan Lovett nennt das den Validation Tether. In einer Studie der Universität Deusto erkannten 80,7 Prozent der Leute den Fehler in einer KI-Empfehlung und folgten ihr trotzdem. Erkennen ist nicht Übersteuern. In meinem Buch habe ich geschrieben, dass Menschen eine wirksame Aufsicht behalten müssen, einschliesslich der Möglichkeit zu übersteuern. Was ich nicht eingepreist habe: Übersteuern hat eine Lieferkette, und ihre Vorlaufzeit beträgt etwa zehn Jahre. Bei Zühlke nehmen wir weiterhin Lernende auf und stellen Juniors ein, und ich bin ehrlich, es wird schwieriger, weil Kunden erfahrene Leute wollen. Wir machen es trotzdem. Unsere Juniors sind unsere nächsten Seniors.

Der Arbeitsmarkt beginnt, dasselbe zu sagen. Das Oxford Internet Institute und das Burning Glass Institute haben rund 30 Millionen Stelleninserate ausgewertet und festgestellt, dass [die am schnellsten wachsende menschliche Fähigkeit in KI-Rollen Resilienz ist](https://www.linkedin.com/feed/update/urn:li:share:7509507361523286016/). Es braucht Nerven, "das ist falsch" über ein Dokument zu sagen, das sich besser liest als alles, was du selbst geschrieben hättest. Prompting gewinnt in diesen Daten nicht an Wert. Es ist das Merkmal, das eine Stelle als KI-Stelle kennzeichnet, und alles, was sich bewegt hat, hat sich darum herum bewegt.

Tool-Schulungen sind leicht einzukaufen. Der Markt bezahlt für die Person, die das Tool in der Hand hält. Frag also, was mit den Stunden passiert, die deine Leute einsparen, denn diese Antwort entscheidet, in welcher Hälfte der Umfrage deine Teams landen, und das Modell hat dabei nichts zu sagen.

## Mein aktueller AI-Stack

**Claude Code:** Weiterhin das Hauptwerkzeug für Berichte, Meeting-Vorbereitung, Coding und das meiste, was ich mache. Vier getrennte Durchgänge: analysieren, planen, bauen, reviewen, wobei das Review in einer Session läuft, die den Code nicht geschrieben hat.

**GrokBot:** Hier leben meine Agenten jetzt, von einem Podcast-Agenten über einen Investment-Agenten bis zu einem, der meine Dark Factory betreibt. Jeder hat seine eigene Identität und seine eigene E-Mail-Adresse. Es sind langlebige Agenten, die weiterarbeiten, wenn ich den Laptop zuklappe.

**Grok Build:** Ich experimentiere damit als Alternative zu Claude Code. Claude wird immer teurer, und Grok kostet ein Mehrfaches weniger. Unternehmen müssen wechseln können. Ich probiere es zuerst an meinem eigenen Schreibtisch aus.

**Perplexity:** Webrecherche mit echten Quellen. Erste Anlaufstelle für die Primärquellen hinter den oben zitierten Papers.

**NotebookLM:** Dokumente rein, Audio- und Video-Zusammenfassungen raus.

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

## Diesen Monat vibe-coded (private Projekte)

**Eine dunkle Softwarefabrik, und das Spiel, das sie gebaut hat.** Eine Dark Factory ist so weit automatisiert, dass man das Licht ausschalten kann. In der Software gibt es fünf Stufen bis dahin, und die Unternehmen, die heute am weitesten sind, stehen auf Stufe vier, wo noch ein Mensch reviewt. Ich wollte Stufe fünf sehen, also habe ich eine gebaut: ein vollständiges V-Modell von den Anforderungen bis zum Code, mit dem Ziel eines 2D-Kampfroboterspiels aus meiner Amiga-Zeit, das ich auf Steam bringen wollte. Sie lief tagelang und hat eine Milliarde Tokens verbrannt. Ich habe ein Spiel bekommen. Die Beine bewegten sich seltsam und der Boden auch, weil das Modell kein physikalisches Verständnis hat. Ich habe um einen helleren Look gebeten und bekam es heller, und es sah immer noch schlecht aus. Bittest du diese Systeme um eine Mobile App, bekommst du die durchschnittliche Mobile App. Zwei Dinge würde ich nicht wiederholen. Ich habe dasselbe Modell die Spezifikation und die Tests schreiben lassen, und man lässt einen Schüler auch nicht das Diktat schreiben und selbst korrigieren. Und die Fabrik hat überhaupt kein Monitoring und kein Logging produziert, weil nichts in ihr wusste, dass Software nach der Auslieferung von jemandem betrieben werden muss. Es funktioniert. Ich würde nicht dafür bezahlen. Steffen Ochsenreither und ich haben es in [Folge 8 von Prompt & Proper](https://www.linkedin.com/feed/update/urn:li:share:7505883466903851008/) auseinandergenommen.

## Wo du mich findest

Ich moderiere zusammen mit Martin Thalmann das [DevOps Meetup Zürich](https://www.meetup.com/devops-meetup-zurich/), zwei Vorträge pro Abend ab 17:30 Uhr. [Dienstag, 13. Oktober, bei Digicomp](https://www.meetup.com/devops-meetup-zurich/events/314219695/): Clément Raussin und Benjamin Calvet darüber, wie man Multi-Agent-KI auf Kubernetes orchestriert, und Ann Harding darüber, wie Switch eine extern gelieferte IT-Strategie weggeworfen hat.

Am [Donnerstag, 8. Oktober, spreche ich am Hello 50:50 World Meetup](https://www.linkedin.com/feed/update/urn:li:ugcPost:7508983174354583554/) bei Zühlke in Schlieren, ab 17:30 Uhr, über eine berechtigte Frage: Wer hat Angst vor KI? Ich will die Bedenken sortieren, in solche, die eine Regel brauchen, solche, die eine neue Fähigkeit brauchen, und solche, die nach einer Woche echter Nutzung verschwinden. Bring jemanden mit, der es anders sieht.

Die vierte Durchführung des [CAS Enterprise Architecture](https://www.linkedin.com/feed/update/urn:li:share:7485831150658195456/), den ich zusammen mit Dietmar Wettach leite, beginnt am 16. Oktober an der Hochschule Luzern. Freitags und samstags bis Februar, auf Deutsch.

[Prompt & Proper](https://promptandproper.ai/), der Podcast, den Steffen Ochsenreither und ich auf Deutsch aufnehmen, hat in diesem Zyklus drei Folgen veröffentlicht: [AI-First oder AI-Augmented](https://www.linkedin.com/feed/update/urn:li:share:7498273356513935360/), [welches Tool sollen wir kaufen](https://www.linkedin.com/feed/update/urn:li:share:7500810081987371009/) und warum diese Frage zuletzt kommt, und die dunkle Softwarefabrik von oben.

Weiter draussen kommen die [DevOpsDays Zürich](https://www.devopsdays.ch/) 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.