Kategorie: Meinung

Ein Entwickler sitzt vor seinem Terminal und versucht, eine GPU-Instanz in der Cloud zu starten. Die API antwortet nicht mit einem klaren Nein, sondern mit einem knappen Hinweis: Die angeforderte Kapazität sei derzeit nicht verfügbar, man solle es später erneut versuchen. Er weiß, dass Retry-Logik nicht helfen wird. Die Hardware, die er braucht, existiert in diesem Moment schlicht nicht in der Region, in der seine Daten liegen. Er schaut in die Dokumentation des Cloud-Anbieters und findet dort einen Satz, der ihm wie Hohn vorkommt: Die Cloud sei darauf ausgelegt, nahezu unbegrenzt zu sein, und es sei die Verantwortung des Anbieters, genügend Rechenkapazität bereitzustellen.

Dieser Satz war fünfzehn Jahre lang eine stabile Vertrauensbasis. Dann wollten alle gleichzeitig dieselben Beschleuniger kaufen – GPUs für Machine Learning, TPUs für Tensor-Berechnungen. Die Nachfrage explodierte, das Angebot blieb zurück, und die scheinbar unbegrenzte Cloud zeigte plötzlich harte Grenzen. Wer heute ernsthaft mit KI-Modellen arbeitet, kennt das Problem: Man fragt nach einem Knoten mit acht H100-GPUs, und die Antwort ist nicht „nein“, sondern „warte“. Dieses Warten kann Stunden, Tage oder Wochen dauern. Das ist keine temporäre Engpass-Situation, sondern eine strukturelle Veränderung. Wir müssen uns damit abfinden: Compute-Knappheit ist permanent. Die Frage ist nicht, ob wir mit der Knappheit leben müssen, sondern wie wir sie in unsere Architektur einbauen.

Warum die Knappheit bleibt: Die Hardware-Realität

Wer nicht tief in der Hardware-Welt lebt, braucht einen kurzen Exkurs. Eine GPU wie NVIDIA H100 ist ein allgemeiner Parallelbeschleuniger mit eigenem Hochgeschwindigkeitsspeicher, der direkt neben dem Rechenkern auf dem Chip sitzt. Eine TPU ist dagegen ein spezialisierter Chip für Matrix-Mathematik, das Herz des maschinellen Lernens. Beide haben gemeinsam, dass ihre Produktion an wenigen Engpässen hängt: dem Hochgeschwindigkeitsspeicher und der fortschrittlichen Verpackungstechnologie, die Speicher und Die verbindet. Diese Kapazitäten sind in der gesamten Industrie begrenzt. Man kann das Problem nicht mit einem größeren Cloud-Budget oder einer geduldigeren Retry-Schleife lösen. Der Flaschenhals liegt weit oberhalb des Cloud-Anbieters, in den Fertigungsstraßen, die Jahre brauchen, um neue Kapazitäten aufzubauen.

Die Nachfrage nach diesen Chips steigt schneller, als die Verpackungslinien gebaut werden können. Selbst wenn sich alle Hersteller sofort auf den Ausbau konzentrieren würden, wäre die Lücke nicht vor dem nächsten Jahrzehnt geschlossen. Wir müssen aufhören, auf das Ende des Engpasses zu warten. Stattdessen sollten wir unsere Systeme so entwerfen, dass sie auch mit einer dauerhaften Knappheit funktionieren. Genau das ist die Idee der Compute Fallback Ladder, einer Methode, die der Ingenieur Casey West beschrieben hat. Sie ist keine neue Physik, sondern eine systematische Antwort auf eine veränderte Realität.

Die Lücke in den Pattern-Katalogen

Wer die großen Musterkataloge für Cloud-Architekturen durchforstet, sucht vergeblich nach einem Muster, das das Problem „Die gewünschte Compute-Ressource ist nicht beschaffbar“ adressiert. Azure bietet Muster wie Throttling, Queue-Based Load Leveling oder Circuit Breaker – sie alle regulieren die Nachfrage gegen eine angenommene Kapazität. Google Cloud betont hohe Verfügbarkeit durch Redundanz und horizontale Skalierung. AWS setzt – wie eingangs zitiert – voraus, dass die Kapazität vorhanden ist. Kein einziges Muster behandelt den Fall, dass die Hardware selbst nicht verfügbar ist. Das ist kein Zufall, sondern eine Lücke in der gesamten Denkweise.

Diese Lücke ist die direkte Folge der ursprünglichen Cloud-Annahme: unbegrenzte Ressourcen. Jetzt, wo die Grenzen sichtbar werden, fehlt uns das Vokabular, um Lösungen zu beschreiben. Wir haben Muster für Lastspitzen, für Ausfälle, für Spitzenlast – aber nicht für das Nicht-Vorhandensein der Grundressource. Die Compute Fallback Ladder füllt genau diese Lücke. Sie ist kein weiteres Pattern neben den anderen, sondern eine Meta-Struktur, die die vorhandenen Muster wie Load Shedding oder Degraded Modes als unterste Sprossen integriert.

Die Leiter: Sprossen, Selektor und Aufstieg

Die Leiter besteht aus drei Elementen: den Sprossen, einem Selektor und einem Mechanismus zum Wiederaufstieg. Die Sprossen sind eine geordnete Liste von Ausführungszielen, von der bevorzugten Ressource hinunter zu Notlösungen. Typischerweise sieht das so aus: zuerst der bevorzugte Accelerator (z. B. H100), dann ein alternativer Accelerator (A100), dann ein kleineres Modell, das auf einen günstigeren Chip passt, dann CPU, und ganz unten gecachte Antworten oder approximative Ergebnisse. Jede Stufe erkauft sich eine höhere Wahrscheinlichkeit, tatsächlich zu laufen, mit geringerer Genauigkeit oder höherer Latenz.

Der Selektor entscheidet zur Laufzeit, welche Sprosse benutzt wird. Das ist entscheidend: Nicht beim Deployment, sondern wenn die Anfrage eintrifft, muss klar sein, welche Hardware in diesem Moment verfügbar ist. Eine statische Entscheidung wäre nach wenigen Stunden veraltet. Der Aufstiegsmechanismus sorgt dafür, dass das System zur bevorzugten Sprosse zurückkehrt, sobald Kapazität wieder da ist. Ohne diesen Mechanismus wäre die Leiter nur eine Einbahnstraße in die Degradation – ein dauerhafter Qualitätsverlust. Erst die Aufwärtsbewegung macht aus der Leiter ein Werkzeug, kein Falltür.

Casey West hat diesen Mechanismus nicht nur theoretisch beschrieben, sondern in einem Referenz-Repository implementiert. Er nutzt dafür die Custom ComputeClass in Google Kubernetes Engine, die genau diese Hierarchie aus Sprossen, Selektor und Migration abbildet. Das Objekt zeigt, dass die Idee praktisch funktioniert, und es offenbart auch die Tücken, die nur beim Bauen sichtbar werden.

Die Implementierung: Was das Objekt wirklich sagt

Beim Bauen der Leiter zeigten sich drei entscheidende Erkenntnisse. Die erste betrifft das Feld whenUnsatisfiable. Wer es weglässt, erhält den Standardwert DoNotScaleUp. Das bedeutet: Wenn die oberste Sprosse nicht verfügbar ist, skaliert das System nicht und der Pod bleibt im Zustand Pending hängen. Eine Leiter, deren unterste Sprosse „nichts liefern“ ist, ist keine Leiter. Der Wert ScaleUpAnyway ist es, der das Abstiegsszenario überhaupt ermöglicht. Man muss dieses Feld also bewusst setzen, sonst funktioniert das Muster nicht.

Die zweite Erkenntnis: activeMigration ist der eigentliche Kern. Ohne dieses Feld gibt es keinen Wiederaufstieg – man bleibt auf dem degradierten Niveau, auch wenn die bevorzugte Hardware wieder da ist. Mit optimizeRulePriority sorgt GKE dafür, dass bei verfügbarer Kapazität ein neuer Knoten der oberen Sprosse erstellt wird, der untere abgeschaltet und das Workload hinüberwandert. Das dauert – in Wests Test waren es fünf Minuten und 41 Sekunden für einen kompletten Zyklus. Das muss man einplanen, wenn man die Leiter als Teil der Architektur nutzt.

Drittens: Abstieg und Aufstieg sind nicht symmetrisch. Der Abstieg sollte niemals eine Hysterese haben, denn wenn die Hardware fehlt, kann man nicht warten. Der Aufstieg dagegen braucht eine Dämpfung, sonst flattert das System zwischen den Sprossen hin und her. Im Referenz-Repository gibt es daher einen Parameter promotion_hysteresis, der festlegt, wie oft eine höhere Sprosse verfügbar sein muss, bevor gewechselt wird. Außerdem gibt es max_degraded_seconds, das eine Warnung auslöst, wenn man zu lange im degradierten Modus arbeitet – aber keine automatische Eskalation, da diese wiederum zu Flattereffekten führen würde.

Die Mechanismen in der Cloud: Was schon existiert

Die gute Nachricht: Man muss das Rad nicht neu erfinden. Die Bausteine für die Leiter sind in den großen Clouds bereits vorhanden. Auf Google Cloud gibt es die AI Hypercomputer-Strategie mit Spot-VMs, die bis zu 91% günstiger sind, aber jederzeit beendet werden können, sowie Dynamic Workload Scheduler mit Flex-Start für bis zu sieben Tage Wartezeit. Auf AWS gibt es Capacity Blocks für ML und Spot-Instanzen für die unterste Sprosse, auf Azure Reservierungen und Spot-VMs. Was fehlt, ist das verbindende Konzept, das diese Mechanismen in eine geordnete Fallback-Struktur bringt.

Diese Struktur ist die Compute Fallback Ladder. Sie ist kein Produkt, sondern ein Architekturmuster, das sich auf verschiedene Clouds übertragen lässt. Casey West betont, dass die Idee nicht neu ist: Schon in den 1980er Jahren gab es das Cycle Scavenging, etwa das Condor-System, das ungenutzte Workstation-Zyklen einsammelte. Backfill Scheduling ist ebenfalls jahrzehntealt. Und das Brownout-Muster aus dem ICSE 2014 beschreibt, wie Systeme unter Last optionale Arbeit abwerfen. Neu ist nicht die Einzeltechnik, sondern die Zusammenführung in einer geordneten, aufsteigenden Struktur.

Was das für uns bedeutet

Die Botschaft ist klar: Compute-Knappheit wird uns nicht verlassen. Wer heute mit Machine Learning arbeitet, muss eine Fallback-Strategie für seine Compute-Ressourcen einplanen, und zwar keine einmalige Notlösung, sondern einen permanenten Bestandteil der Architektur. Das ist keine Kapitulation vor den Umständen, sondern eine notwendige Anpassung an die Realität. Die Cloud ist nicht mehr die unendliche Ressource, die sie einmal schien. Sie ist ein Markt mit begrenzten Gütern, und wer klug plant, hat verschiedene Bezugsquellen und eine Leiter, um bei Engpässen nicht komplett stillzustehen.

Die Compute Fallback Ladder ist ein konkretes Werkzeug, das uns hilft, mit dieser Knappheit umzugehen. Sie zwingt uns, über die Sprossen nachzudenken, über den Selektor zur Laufzeit und über den Wiederaufstieg. Sie macht die GPU-Knappheit in der Cloud zu einem beherrschbaren Risiko, statt zu einem Katastrophenszenario. Und sie zeigt, dass Cloud-Zuverlässigkeit nicht bedeutet, dass alles immer verfügbar ist, sondern dass wir angemessen reagieren können, wenn es nicht so ist. Das ist die gelassene Haltung, die wir brauchen: nicht Panik, sondern Vorbereitung. Die Hardware-Verfügbarkeit wird volatil bleiben, aber unsere Systeme müssen es nicht sein.

Quelle: caseywest.com

„Die Industrie etabliert ihre Standards“, schreibt Salvatore Princi in seinem Manifest, „und diese Standards taugen nichts.“ Wer heute ein KI-Tool für den Arbeitsalltag oder ein Unternehmen aufsetzt, stößt bei jedem Anbieter auf dasselbe Muster: Chat-Sessions, Modellauswahl, Toneinstellungen, MCP-Verbindungen, Skills, Memories. Dieses Menü wird als „Best Practice“ verkauft – dabei ist es eine Sammlung technischer Notlösungen, die dem Endanwender die Verantwortung zuschiebt. Du musst entscheiden, wann eine Konversation zu lang ist, welches Modell das richtige ist und welche Connectors aktiviert werden sollen. Du sprichst plötzlich Ingenieursdeutsch, obwohl du nur deine Arbeit erledigen willst.

Princi spricht damit ein Phänomen an, das viele aus dem Alltag mit generativen KI-Tools kennen: Die Tools sind nicht an den Bedürfnissen der Nutzer gebaut, sondern an den Möglichkeiten der Technologie. Die großen Anbieter geben diese Strukturen vor, Startups und interne Entwicklerteams übernehmen sie unkritisch. Sie glauben, dass das eben der Standard ist. Dabei lohnt ein Blick auf die Geschichte der Computernutzung, um zu verstehen, warum dieser Standard in die falsche Richtung führt.

Vom Computerterminal zum iPhone: Lektionen aus der Benutzerfreundlichkeit

Der Autor zieht einen einfachen Vergleich: das iPhone, das nur wenige Einstellmöglichkeiten bietet, gegenüber dem Android-Gerät, das unzählige Optionen bis ins letzte Reglerdetail anbietet. Als Technikbegeisterter mag man die Freiheit von Android schätzen – Launcher, Buttons und Widgets lassen sich bis zum Exzess anpassen. Doch für die breite Masse, für Menschen, die einfach ein Telefon bedienen wollen, ist das iPhone die Wahl, weil es ohne Bedienungsanleitung funktioniert. Man nimmt es aus der Box, tippt auf das App-Symbol, und die Dinge erledigen sich.

Genau dieses Prinzip überträgt Princi auf KI-Agenten im Unternehmenskontext. Unternehmen, die Hunderte oder Tausende Mitarbeiter zum Einsatz von KI bewegen wollen, brauchen kein weiteres komplexes Werkzeug mit zahlreichen Einstellungen. Sie brauchen eine Lösung, die sofort funktioniert. Ein iPhone-Erlebnis für KI: ohne Modellauswahl, ohne Kontextmanagement, ohne Anschlussprobleme. Princi sagt klar: Wenn du als Entwickler oder Entscheider ein KI-System nicht so gestaltest, dass es ohne Einarbeitung nutzbar ist, wirst du keine Adoption erreichen. Der Mensch ist nicht das Problem, sondern das Tool.

Ein durchgehender Chat statt Dutzender Sitzungen: Das Kontext-Gespräch als Vorbild

Schauen wir uns an, wie wir im echten Leben kommunizieren. Wenn du mit einem Kollegen an einem Projekt arbeitest, öffnest du nicht jedes Mal eine neue Konversation. Du schreibst in den bestehenden Chatverlauf, referenzierst auf das, was schon gesagt wurde, und hast den gesamten Kontext im Blick. Princi fordert nichts anderes für KI-Agenten. Die Antwort des Agenten hängt vom gesamten Verlauf ab – genau wie bei einem menschlichen Gesprächspartner. Es ist absurd, dass aktuelle Interfaces dich zwingen, nach einiger Zeit eine neue Sitzung zu starten oder eine „Konversation zu komprimieren“, nur weil das Fenster des Sprachmodells voll ist.

Princi macht hier einen bemerkenswerten Punkt: Die Beschränkung des Kontextbudgets – also wie viel Text ein Modell gleichzeitig verarbeiten kann – ist eine technische Hürde, die nicht auf die Anwender abgewälzt werden darf. Wenn ein KI-System sich nicht merken kann, was vor einer Stunde in derselben Konversation passiert ist, liegt das an der Architektur, nicht an der Unfähigkeit des Nutzers. Eine Lösung? Princi verweist auf das menschliche Gehirn, das ebenfalls einen begrenzten Arbeitsspeicher hat – und dennoch in langen Gesprächen nicht ständig den Faden verliert. Es vergisst Dinge, aber es kompensiert durch Abstraktion und Zusammenfassung. Genau das müsste ein KI-Agent tun: automatisch Prioritäten setzen und alte Informationen verdichten, ohne dass der Nutzer Hand anlegen muss.

Keine Kopierorgien mehr: Integration in die vorhandene Chat-Plattform

Einer der irritierendsten Aspekte heutiger KI-Tools ist die Trennung zwischen dem Ort, wo die Arbeit geschieht (dein Chat-Kanal wie Slack, Teams oder Mattermost), und dem Ort, wo der KI-Agent lebt (eine separate Weboberfläche). Du markierst eine Nachricht mit relevantem Projektkontext, kopierst sie in das KI-Tool, fügst deine Frage hinzu, wartest auf die Antwort, kopierst sie zurück und fügst sie in den Original-Chat ein. Das ist nicht nur Zeitverschwendung, sondern auch eine Einladung zum Fehler: Kontext geht verloren, wichtige Nuancen werden abgeschnitten, die Kommunikation wird fragmentiert.

Princi fordert eine radikale Verlagerung: Der KI-Agent gehört in dieselbe Chat-Umgebung, in der alle anderen Gespräche stattfinden. Er soll die Konversationen mitlesen können – nicht invasiv, sondern als Teil des Teams – und direkt angesprochen werden wie ein Kollege. Du schreibst dem Agenten in deinem bestehenden Kanal, er antwortet im selben Thread, die gesamte Historie bleibt bestehen. Kein Tab-Wechsel, kein Copy-Paste, kein Kontextbruch. Und genau hier liegt die Chance für Unternehmen: Die Adoption steigt massiv, weil die Nutzer das Werkzeug dort abholen, wo sie ohnehin täglich arbeiten.

Ein Agent für alles statt vieler Spezialisten: Der leere Behälter

Ein weiterer Trend, den Princi kritisch sieht, ist der Bau hochspezialisierter Agenten: einen für den Vertrieb, einen für den Support, einen für die Personalabteilung. Jeder wird separat konfiguriert, trainiert und betrieben – ein riesiger Aufwand, den sich nur wenige leisten können. Princi stellt eine radikale Gegenfrage: Warum nicht einen einzigen, allgemeinen Agenten bauen, der wie ein leeres Gefäß funktioniert und je nach Anfrage die passenden Fähigkeiten lädt? Der gleiche Agent kann als Vertriebsassistent arbeiten, wenn du ihm das entsprechende Skill-Paket gibst, und als Support-Tool, wenn die Session eine andere Anfrage bringt.

Dieser Ansatz hat handfeste Vorteile. Ein einziges System ist einfacher zu warten, zu überwachen und zu sichern als zwanzig Insellösungen. Die Governance-Beauftragten bekommen einen einzigen Ort, an dem sie Zugriffsrechte, Datenrichtlinien und Versionen verankern können. Für den einzelnen Mitarbeiter fühlt sich der Agent wie ein persönlicher Assistent an, der sich an seine Vorlieben gewöhnt – nicht wie ein sperriges Firmenwerkzeug. Princi vergleicht das mit einem intelligenten Chamäleon: Es passt sich an die Umgebung an, ohne seine Identität zu verlieren.

Werkzeuge, die niemand konfigurieren muss: `curl` als gemeinsamer Nenner

Zur technischen Umsetzung hat der Autor eine interessante These. Er kritisiert den Trend, KI-Agenten über eigene CLI-Tools (Kommandozeilen-Programme) oder spezielle Konnektoren an Systeme anzuschließen. Wer jemals versucht hat, einen `jira-cli` oder einen `confluence-cli` einzurichten, weiß, wie schnell man in einer Welt aus Parametern, Authentifizierungstoken und Endpunkt-Konfigurationen versinkt. Das ist nichts für Endanwender. Stattdessen schlägt Princi ein radikal einfaches Konzept vor: Nutze `curl`, das universelle Werkzeug für HTTP-Anfragen, um jede API zu erreichen. Der KI-Agent muss nur wissen, wohin die Anfrage geht, wie er sich authentifiziert und was er mit der Antwort anfangen soll. Diese Informationen lassen sich als einfache Textanweisung hinterlegen – kein Code, keine CLI-Gebräuche.

Der Clou dabei: Die großen Sprachmodelle kennen bereits die öffentlichen API-Dokumentationen vieler Systeme (Atlassian, Microsoft Graph, Google Workspace). Sie wissen, wie die Daten aussehen, auch wenn sie nicht trainiert wurden, um sie zu nutzen. Wenn du deinem Agenten die richtige Anweisung gibst, kann er direkt mit dem jeweiligen Backend kommunizieren – auf dem modernen Weg über HTTP. Das spart Entwicklungsressourcen und reduziert die Fehlerquelle: Weniger benutzerdefinierte Schnittstellen, weniger Wartung, weniger Missverständnisse. Wenn dein Unternehmen zehn verschiedene Systeme anbinden will, ist der Unterschied zwischen zehn einzelnen CLI-Tools und einem generischen HTTP-Client gewaltig.

Wissen ohne RAG-Wahnsinn: Die Kraft der direkten API-Anbindung

Ein weiterer heikler Punkt ist die Wissensanbindung. Viele Unternehmen bauen aufwendige RAG-Pipelines – Systeme, die Dokumente in Vektordatenbanken speichern, Ähnlichkeitssuche betreiben und Textbausteine an das Modell liefern. Princi hat sich diese Praxis genau angesehen und kommt zu einem ernüchternden Ergebnis: Der Aufwand ist riesig, die Wartung endlos, und die Ergebnisse sind oft nicht besser als eine einfache Lösung. Er empfiehlt stattdessen, dem Modell „ungesäuberte“ Daten aus unterschiedlichen Quellen zu geben – über API-Aufrufe, wie oben beschrieben – und die Aufforderung klar zu formulieren.

Das klingt kontraintuitiv, funktioniert aber erstaunlich gut, wie der Autor aus eigener Erfahrung berichtet. Die modernen Sprachmodelle können aus mehreren Textfragmenten synthetisieren, Widersprüche erkennen und die relevanten Passagen herausfiltern – ohne komplexe Retrieval-Architektur. Der Vorteil liegt auf der Hand: Du sparst dir den ständigen Abgleich der Datenbasis, die Konfliktlösung bei Aktualisierungen und das Ranking der Suchergebnisse. Die Genauigkeit leidet nicht darunter – im Gegenteil, oft ist sie höher, weil das Modell den vollen Kontext sieht und nicht nur isolierte Paragraphen.

Ja, es gibt Bedenken: Was, wenn die Daten aus unterschiedlichen Quellen widersprüchlich sind? Was, wenn zwei Nutzer dieselbe Frage stellen und dasselbe API aufgerufen wird? Diese Punkte sind relevant, aber lösbar. Der Autor verweist auf das Prinzip „Genauigkeit schlägt Optimierung“: Ein System, das hin und wieder redundant arbeitet, aber korrekte Antworten liefert, ist besser als ein hochoptimierter Apparat, der in zehn Prozent der Fälle falsche Informationen ausliefert – allein weil die Datenbasis nicht aktuell ist. Vertrauen der Nutzer ist das höchste Gut, und man gewinnt es durch verlässliche Antworten, nicht durch Effizienz-Rekorde.

Was das für Unternehmen bedeutet: Einfachheit ist der neue Wettbewerbsvorteil

Salvatore Princi zieht am Ende seines Manifests eine klare Linie: Die KI-Branche profitiert von der Komplexität. Wer viele Werkzeuge, viel Konfiguration und viele Abhängigkeiten schafft, verkauft damit Lizenzen, Token und Support. Aber der Kunde – das Unternehmen, das seine Mitarbeiter zu besserer Arbeit führen will – hat davon nichts. Im Gegenteil, er zahlt drauf: an Entwicklungszeit, an Schulungskosten und letztlich an der Produktivität seiner Belegschaft.

Die Alternative ist keine Technologie-Euphorie, sondern schlichtes Design: KI-Agenten, die wie ein guter Kollege funktionieren – zugegen, kontextbewusst, anpassungsfähig. Ein einziger Agent, der mit einem universellen Werkzeug (curl) spricht und dessen Wissensbasis die Live-Daten deines Unternehmens sind. Kein Modell-Cockpit für den Endanwender, keine Session-Verwaltung, keine Copy-Paste-Schleifen. Die Botschaft ist klar: Wenn du KI wirklich einführen willst, hör auf, Standardkonfigurationen zu übernehmen, und bau dir dein eigenes, benutzerfreundliches System. Das klingt nach Mehrarbeit – ist es aber nicht. Es ist die einzige Möglichkeit, die Akzeptanz zu erreichen, die dieses Technologiezeitalter verspricht.

Die Industrie wird dir die komplexe Lösung weiterhin anbieten. Sie passt zu ihrem Geschäftsmodell. Aber dein Geschäftsmodell ist nicht der KI-Verkauf, sondern die Produktivität deiner Mitarbeiter. Frag dich bei jeder neuen Konfigurationsoption: Wer braucht diese Wahl wirklich – der Nutzer oder der Anbieter? Und dann treffe die Entscheidung, die im Zweifel einfacher ist.

Quelle: imphan.substack.com

1975 – Fred Brooks formulierte sein Gesetz: „Adding manpower to a late software project makes it later.“ Diese Erkenntnis aus „The Mythical Man-Month“ gilt bis heute. Matthew Brunelle erinnert in seinem Essay über agentisches Engineering daran. Seine These: Agentisches Engineering ist im Kern die Summe all jener Praktiken, die wir als Softwareentwickler längst hätten befolgen sollen – und die wir unter Zeitdruck gerne weglassen.

Brunelle beobachtet mit einer Mischung aus Erleichterung und Wehmut, wie plötzlich alles darum kreist, dass KI-Agenten saubere Issues bekommen, Dokumentation lesen, Tests bestehen und Code-Reviews durchlaufen. Das sind keine neuen Praktiken – aber sie wurden oft als lästige Pflicht betrachtet, die man unter Zeitdruck weglässt. Jetzt, da die Agenten nicht über das implizite Wissen eines erfahrenen Entwicklers verfügen, werden explizite Beschreibungen, klare Konventionen und vollständige Dokumentation überlebenswichtig.

Du fragst dich vielleicht, warum dein Team so viel Wert auf Issue-Tracking legt, nur weil ein Bot daran hängt. Brunelle bringt es auf den Punkt: Wir halten die Bots auf einem Standard, den wir für uns selbst nie akzeptiert hätten. Wir verlangen von ihnen, dass sie jede Anforderung nachlesen, jeden Test bestehen und jedes Feedback dokumentieren – während wir Menschen uns oft mit vagen Notizen und mündlichen Absprachen zufriedengeben. Das ist der Kern seiner Beobachtung: Agentisches Engineering zwingt uns, die Tugenden zu praktizieren, die wir längst hätten verinnerlichen sollen.

Die Wiederentdeckung der Grundlagen

Brunelle listet Beispiele auf, die zeigen, wie banal die Anforderungen an gute Agenten sind. Ein Issue-Tracker, in dem nicht nur der Titel steht, sondern auch Kontext, Akzeptanzkriterien und der Stand der Arbeit. Dokumentationsstrings an Methoden, die erklären, warum etwas existiert, nicht nur was es tut. Deskriptive Pull Requests, die Änderungen nachvollziehbar machen. Aktuelle Dokumentation, die nicht veraltet ist, sobald sie geschrieben wurde. Sinnvolle Tests – oder überhaupt Tests. Automatisches Linting, das für einheitlichen Stil sorgt. Und die gute alte Gewohnheit, vor der Implementierung einen Entwurf zu besprechen, anstatt direkt loszucoden.

All diese Praktiken werden gemeinhin unter „Best Practices“ zusammengefasst – und meistens bleiben sie genau das: praktisch, aber nicht praktiziert. Der Grund ist simpel: Sie kosten Zeit, und unter Termindruck wird die Doku aufgeschoben, der Test als entbehrlich abgetan, das Review zur Formalie. Wir Menschen können das kompensieren, weil wir einander im Gespräch klären können, was nicht dokumentiert ist. Ein Agent kann das nicht. Er hat nur das, was explizit aufgeschrieben ist – sei es in Form von Kommentaren, Tickets oder Konventionen.

So entsteht eine Ironie: Was wir als lästige Pflicht empfanden, wird zur essenziellen Grundlage für den Einsatz von KI. Plötzlich ist nicht mehr die Frage, ob wir uns an unsere eigenen Regeln halten, sondern ob wir sie überhaupt haben. Brunelle berichtet von einem Kollegen, der nach einem Code-Review ein grundlegendes Prinzip im Team feststellen wollte und es in der Dokumentation verankerte – mit der Begründung, dass alle künftigen Agenten es dann automatisch befolgen würden. Hätte man das vorher getan, hätte man das gesamte Team belehren müssen. Jetzt reicht eine Textdatei.

Warum wir es bisher nicht getan haben

Die Frage liegt nahe: Warum haben wir diese Praktiken nicht längst umgesetzt? Brunelle glaubt, es liegt nicht an fehlendem Wissen, sondern an fehlender Konsequenz. Softwareentwickler automatisieren ihr Handwerk seit Jahrzehnten – von Skripten für Code-Formatierung bis zu Continuous-Integration-Pipelines. Aber was nicht leicht zu automatisieren ist, wie das Verstehen von Kontext oder das Treffen von Abwägungen, wurde gerne auf später verschoben. Es gibt keine CI-Pipeline, die prüft, ob deine Code-Kommentare den Zweck hinreichend erklären. Kein Linter erkennt, dass du das Meeting-Protokoll nicht verschickt hast. Also unterbleibt es.

Hinzu kommt ein psychologischer Effekt: Solange du mit deinen Kollegen interagierst, gleicht ihr Lücken durch Gespräche aus. Du fragst nach, du erklärst, du erinnerst dich. Diese informellen Absprachen sind flexibel und anpassungsfähig – aber sie sind auch flüchtig. Wer nicht in einem Meeting war, hat Pech gehabt. Wer später ins Team stößt, muss alles mühsam rekonstruieren. Die mündliche Überlieferung funktioniert nur so lange, bis jemand den Raum verlässt. Agenten können nicht fragen, wenn etwas fehlt. Sie können nur das tun, was sie gelernt haben.

Das führt zu einer paradoxen Situation: Wir erwarten von KI-Agenten, dass sie sich strikt an Regeln halten, die wir selbst über Bord geworfen haben, sobald es unbequem wurde. Brunelle formuliert es treffend: „Warum halten wir die Bots auf höherem Standard als uns selbst?“ – und zielt damit auf eine tiefere Frage ab: Sollten wir uns nicht an dieselben Standards halten, die wir von unseren Tools verlangen? Vielleicht braucht es manchmal einen externen Anstoß, um gute Gewohnheiten zu etablieren. Agentisches Engineering, so scheint es, ist dieser Anstoß.

Die Grenze des Expliziten: Mētis und Erfahrung

Doch es gibt einen Haken, und Brunelle macht das mit einem Konzept aus James C. Scotts Buch „Seeing Like a State“ deutlich. Scott spricht von „mētis“ – dem praktischen Wissen, das man nur durch langjährige Erfahrung erwirbt. Es ist die Fähigkeit, Regeln im konkreten Kontext angemessen anzuwenden. Ein erfahrener Koch schmeckt, ob die Sauce mehr Salz braucht; ein erfahrener Entwickler sieht, ob eine Architektur überdimensioniert ist. Diese Urteilskraft lässt sich nicht vollständig in Dokumentation oder Regeln fassen. Sie ist lokal, situativ, ständig in Anpassung begriffen.

Agenten fehlt diese mētis. Sie operieren mit explizit formulierten Anweisungen und Mustern aus Trainingsdaten. Das funktioniert gut für klar definierte Probleme – wie das Formatieren von Code, das Befolgen von Lint-Regeln oder das Schreiben von Standard-Doku. Aber sobald eine Situation unvorhergesehene Nuancen aufweist, stoßen sie an Grenzen. Denk an einen Roboter, der einen Baum fällen soll, aber nie gelernt hat, dass der Boden nass sein kann. Er wird nach Plan arbeiten, und das Ergebnis wird unzureichend sein.

Diese Erkenntnis hat praktische Konsequenzen. Wenn wir agentisches Engineering nutzen wollen, müssen wir akzeptieren, dass wir niemals alles in Textform abbilden können. Wir müssen also entscheiden, welche Aspekte wir explizit machen können und welche nicht. Code-Syntax ist gut beschreibbar, stilistische Konventionen auch – aber das Verständnis für den Geschäftskontext, für politische Dynamiken im Team oder für den ungeschriebenen Code of Conduct lässt sich nur schwer kodifizieren. Brunelle weist darauf hin, dass eine schriftliche Regel immer weniger flexibel ist als das Urteilsvermögen eines Menschen. Sie ist aber besser als gar keine Regel.

Das ist der Punkt, an dem viele Projekte scheitern: Sie versuchen, alles explizit zu machen, und enden mit einer Flut von Dokumenten, die niemand liest. Oder sie machen nichts explizit und überfordern die Agenten mit vagen Anweisungen. Die Kunst liegt darin, das richtige Maß zu finden. Dazu gehört, sich bewusst zu machen, dass mētis nicht via Text übertragbar ist. Agenten können sie nicht erwerben – sie können höchstens lernen, typische Muster zu erkennen. Deshalb müssen wir als Entwickler mehr Verantwortung übernehmen und die Lücken schließen, die die Agenten nicht sehen können.

Wenn das System dysfunktional ist, hilft auch kein Agent

Brunelle erzählt von einem Freund, dessen Team eine Abhängigkeit mitten im Sprint änderte, ohne die anderen zu informieren. Der Freund musste einen Agenten verwenden, um ein Refactoring durchzuführen, aber das Ergebnis war nutzlos, weil die Umgebung sich ständig veränderte. Seine Schlussfolgerung: „Wenn agentisches Engineering nur normales Engineering mit Robotern ist, dann gilt auch: Alles, was Engineering schwieriger macht, macht agentisches Engineering noch schwieriger.“ Genau das ist der Kern – und es ist eine Lektion, die weit über den Einsatz von KI hinausreicht.

Wenn dein Team Schwierigkeiten hat, sich abzustimmen, wenn deine Codebasis keine klaren Grenzen hat, wenn deine Spezifikationen unklar sind, dann wird ein Agent diese Probleme nicht lösen. Im Gegenteil, er wird sie vergrößern. Ein Mensch kann improvisieren, wenn sich die Anforderungen kurzfristig ändern. Ein Agent kann das nicht – er ist auf Angaben angewiesen, die sich im Nachhinein als falsch erweisen. Das macht ihn nicht unbrauchbar, aber es macht ihn abhängig von der Qualität deines Prozesses.

Diese Erkenntnis erinnert an das Brooks’sche Gesetz: Mehr Leute machen ein verspätetes Projekt nicht wieder flott, sie machen es schlimmer. Ein KI-Agent ist eine weitere Person – wenn auch eine synthetische. Wenn du ein Team hast, das an der Überlastung scheitert, wirst du mit einem Agenten nicht besser. Du wirst nur eine zusätzliche Quelle von Fehlern und Missverständnissen haben. Deshalb lohnt es sich, die zugrunde liegenden Probleme zu lösen, bevor du automatisierte Helfer einschaltest.

Was bedeutet das für die Praxis?

Brunelles Botschaft ist nicht, dass agentisches Engineering überflüssig ist. Es ist eine Chance, unsere eigenen Defizite zu erkennen und zu beheben. Aber sie wirkt nur, wenn wir bereit sind, die harte Arbeit zu leisten, die wir bisher aufgeschoben haben. Das bedeutet, dass wir unsere Dokumentation endlich ernst nehmen – nicht als lästige Pflicht, sondern als Grundlage für kollaborative Arbeit. Es bedeutet, dass wir klare Konventionen aufstellen und sie automatisch prüfen lassen. Und es bedeutet, dass wir uns bewusst machen, wo die Grenzen des Expliziten liegen – und dass wir diese Lücken durch menschliche Interaktion füllen müssen.

Für dich als Entwickler bedeutet das: Wenn du mit einem Agenten arbeiten willst, fang nicht mit dem Werkzeug an, sondern mit deinem Projekt. Überprüfe, ob deine Issues aussagekräftig sind, ob deine Doku aktuell ist, ob deine Tests den Anforderungen entsprechen. Wenn du feststellst, dass das fehlt, dann ist das ein klares Signal – nicht für den Einsatz von KI, sondern für die Verbesserung deiner eigenen Arbeitsweise. Agenten sind kein Ersatz für Engineering-Disziplin, sie sind ihr vielleicht größter Antreiber.

Die Ironie ist offensichtlich: Wir haben jahrelang über den Mangel an Best Practices geklagt, aber ohne konkrete Notwendigkeit haben wir nichts geändert. Jetzt, wo wir Bots ans Laufen bringen wollen, stellen wir fest, dass wir uns selbst nicht auf dem Niveau bewegen, das wir von unseren Tools erwarten. Vielleicht ist das der eigentliche Gewinn des agentischen Engineerings: Es zwingt uns dazu, die Grundlagen zu beherrschen, bevor wir die nächste Stufe erklimmen. Es ist wie beim Klettern: Du kannst nicht das nächste Seil anbringen, ohne den Standplatz zu sichern. Und wenn du es doch tust, wirst du fallen – egal wie gut der Roboter ist, der dir den Rucksack trägt.

Brunelles Text endet mit einem Beinahe-Zitat von Brooks: „Ein Fake-Mensch ist nicht besser.“ Das ist eine nüchterne Warnung, aber auch eine Bestätigung: Die Prinzipien der Softwareentwicklung sind zeitlos. Sie gelten für Menschen und Maschinen gleichermaßen. Wenn wir das akzeptieren, können wir agentisches Engineering nutzen, um unsere eigene Arbeit zu verbessern – nicht als Ersatz, sondern als Verstärker. Die Werkzeuge ändern sich, aber die Regeln, die gute Arbeit ausmachen, bleiben dieselben.

Quelle: blog.matthewbrunelle.com

Die milliardenschweren KI-Investitionen stehen womöglich nicht auf solidem Grund. Ein Blick in die Geschichte zeigt: Ähnliche Infrastruktur-Booms endeten schon einmal in einer tiefen Finanzkrise. Die Parallelen zur Gegenwart sind deutlich. Ein Autor zieht Vergleiche zwischen der Eisenbahnkrise von 1873 und der heutigen KI-Investitionswelle – und erklärt, warum Nvidia betroffen sein könnte.

Tech-Riesen nehmen Schulden in schwindelerregender Höhe auf, um Rechenzentren und KI-Chips zu kaufen. Der Beitrag „Nvidia’s Risky Business“ argumentiert, dass diese Entwicklung an die Eisenbahnblase im 19. Jahrhundert erinnert. Übermäßige Kreditaufnahme führte damals zu einer weltweiten Depression. Heute könnte die KI-Blase ähnliche Risiken bergen.

Die erste große Investitionsblase

Ein Blick zurück ins Jahr 1870: Jay Cooke, ein gefeierter Finanzier des amerikanischen Bürgerkriegs, unterschrieb einen Vertrag mit der Northern Pacific Railway. Diese Eisenbahngesellschaft sollte die Großen Seen mit dem Pazifik verbinden – ein ehrgeiziges Projekt, das an fehlendem Kapital scheiterte. Cooke, der sich zunächst geweigert hatte, das Unternehmen zu finanzieren, wurde durch eine Provision von zwölf Prozent pro Anleihe und zusätzliche Aktienpakete überzeugt.

Cooke konnte institutionelle Investoren nicht überzeugen. Also wandte er sich an die breite Bevölkerung – eine Neuheit. Er setzte auf patriotische Appelle, kontrollierte Medien und versprach den Käufern von Anleihen große Gewinne. Mit 1.500 Verkäufern und der finanziellen Unterstützung von 1.300 Zeitungen schuf er ein System, das an moderne Marketingkampagnen erinnert. Die Eisenbahnanleihen wurden zum Volksinvestment, doch die Kapitalbedürfnisse der Northern Pacific waren unersättlich.

Im September 1873 wurden die Kredite weltweit knapper – ausgelöst durch einen Börsencrash in Wien und die Demonetisierung von Silber. Cooke fand keine Käufer mehr für seine Anleihen. Seine Bank, Jay Cooke & Company, meldete Konkurs an. Das löste die Panik von 1873 aus: massenhafte Eisenbahnpleiten, eine jahrelange Depression und eine jahrzehntelange Deflation. Historiker sehen darin sogar einen Auslöser für spätere europäische Konflikte.

Die Northern Pacific wurde schließlich fertiggestellt – nach mehreren Insolvenzen. Sie ging in der Burlington Northern Railroad auf, die später mit der Santa Fe fusionierte und schließlich von Berkshire Hathaway übernommen wurde. Solche Investitionswellen enden nicht unbedingt im Nichts, aber sie bringen enorme Turbulenzen mit sich.

Parallelen zu den heutigen KI-Investitionen

Liaquat Ahamed, Autor des Buches „1873“, zieht direkte Verbindungen zwischen der damaligen Eisenbahnblase und der aktuellen KI-Euphorie. Er rechnet historische Summen in heutige Verhältnisse um: Die 500 Millionen Dollar, die jährlich in US-Eisenbahnanleihen flossen, entsprechen heute etwa 600 Milliarden Dollar – ungefähr so viel, wie die großen Tech-Konzerne im Jahr 2026 in KI-Infrastruktur investieren wollen.

Microsoft-CEO Satya Nadella hat das Buch als Pflichtlektüre bezeichnet. Microsoft ist der einzige Hyperscaler, der noch über beträchtliche freie Cashflows verfügt – 19,6 Milliarden Dollar im letzten Quartal. Während Microsoft aus eigener Kraft finanziert, haben andere Unternehmen den Weg der Verschuldung eingeschlagen. Zwischen September und November des Vorjahres haben Oracle, Meta, Alphabet und Amazon zusammen 80 Milliarden Dollar an Anleihen begeben. Dieses Jahr sind es bereits 194 Milliarden Dollar, nachdem es im gesamten Jahr 2025 noch 108 Milliarden waren.

Die Zeichen mehren sich, dass diese Schulden nicht ohne Folgen bleiben: Die Spreads steigen, und 86 Prozent der in diesem Jahr begebenen Anleihen handeln bereits über ihrem Ausgabekurs. Der Deckungsgrad für neue Emissionen ist von 5x im Februar auf unter 2x gefallen. Anleger werden zögerlicher. Der Autor sieht hierin eine verblüffende Ähnlichkeit zu Jay Cooke, der ebenfalls feststellen musste, dass die Nachfrage nach seinen Anleihen versiegte.

Google kündigte im Juni an, 85 Milliarden Dollar an Eigenkapital aufzunehmen – inklusive einer speziellen Emission von 10 Milliarden Dollar an Berkshire Hathaway. Der Autor kommentierte dies als Signal: Google ist bereit, alle Finanzierungsmöglichkeiten auszuschöpfen, um die erwartete Nachfrage nach Rechenleistung zu bedienen. Gleichzeitig bestätigt es, dass die KI-Investitionen weitergehen – solange das Kapital reicht.

Googles Dilemma: DeepMind und der Wettlauf um KI

Während Google Milliarden für Infrastruktur ausgibt, kämpft sein Forschungsbereich DeepMind mit massiven Problemen. Der langjährige CEO Demis Hassabis wurde befördert, verlor aber die operative Kontrolle. Auch Gemini-Mitbegründer Jeff Dean hat das Tagesgeschäft verlassen, zusammen mit vielen anderen prominenten Forschern. Das Analyseunternehmen SemiAnalysis kommentierte dies mit den Worten: „Gemini is Cooked.“ Für alle Zwecke ist DeepMind kein Frontier-Labor mehr.

Die Einschätzung von SemiAnalysis ist hart: Google werde weiter Modelle veröffentlichen, aber die Chancen, wieder den Spitzenplatz zu erreichen, seien auf null gesunken. Das Problem liege nicht nur in der Führung, sondern in einer bürokratischen, langsamen und strategisch ängstlichen Unternehmenskultur. DeepMind hatte bereits ein Jahr vor ChatGPT einen Chatbot entwickelt, durfte ihn aber nicht veröffentlichen, weil man Angst vor Kannibalisierung des Kerngeschäfts hatte.

Der Autor vermutet, dass die unterschiedliche Vision von Hassabis – der an Weltmodelle glaubte, nicht nur an Text und Code – zu Konflikten führte. Google scheint nun auf einen pragmatischeren Ansatz zu setzen, der sich an den Fähigkeiten von Anthropic orientiert. Diese Neuausrichtung könnte helfen, zeigt aber auch, wie volatil die Lage in der KI-Forschung ist.

Die interessanteste Wendung: Googles Infrastruktur-Wette geht unabhängig vom DeepMind-Drama weiter. Laut SemiAnalysis werden mehr als 20 Prozent der TPU-Lieferungen von 2026 bis 2027 direkt an Anthropic verkauft – der Kunde, der Googles Cloud-Angebote stark nachfragt. Sundar Pichai, CEO von Google, hat erklärt, dass kurzfristige Kosten für langfristige Verträge in Kauf genommen werden. Google setzt trotz interner Turbulenzen auf die wachsende Nachfrage nach KI-Infrastruktur.

Was bedeutet das für Nvidia?

Nvidia profitiert am meisten von dieser Investitionswelle. Die Nachfrage nach seinen Grafikprozessoren für KI-Anwendungen ist gigantisch. Doch genau das macht Nvidia verwundbar. Wenn die Schulden der Tech-Giganten nicht zu den erwarteten Renditen führen – oder wenn Kreditgeber vorsichtiger werden –, könnte die Nachfrage nach Nvidia-Chips schlagartig einbrechen. Der Autor zieht hier die Parallele zu den Eisenbahnunternehmen, die nach der Krise von 1873 massiv an Wert verloren.

Ein weiterer Punkt ist die Abhängigkeit von einer Handvoll Großkunden. Google, Meta, Microsoft und Amazon bestellen Chips in riesigen Mengen, aber ihre Investitionen sind zum Teil fremdfinanziert. Wenn die Schuldenlast zu hoch wird, könnten sie gezwungen sein, ihre Ausgaben zu kürzen – mit direkten Folgen für Nvidia. Hinzu kommt die Konkurrenz durch eigene Chips, etwa Googles TPUs oder Amazons Trainium. Nvidia muss nicht nur mit einer möglichen Blase, sondern auch mit alternativen Technologien kämpfen.

Der Autor vergleicht Nvidia mit den Zulieferfirmen der Eisenbahnzeit, die ebenfalls von der Expansion profitierten. Als die Blase platzte, waren sie mit über großen Lagerbeständen und sinkenden Bestellungen konfrontiert. Ähnlich könnte es Chip-Herstellern ergehen, wenn die KI-Investitionen abflauen. Die Anzeichen mehren sich, dass nicht alle Versprechen der KI-Revolution erfüllt werden können – dann wird die Schuldenlast zum Problem.

Die KI-Blase ist real – aber sie muss nicht platzen

Die Parallelen zwischen der Eisenbahnkrise von 1873 und der heutigen KI-Investitionswelle sind deutlicher, als viele wahrhaben wollen. Unternehmen nehmen Schulden auf, um in Infrastruktur zu investieren – das erinnert stark an die Vorgehensweise von Jay Cooke. Auch damals wurden Anleihen als sichere Geldanlage beworben, und auch damals endete die Euphorie in einer weltweiten Depression.

Dennoch wäre es zu einfach, das Ende des KI-Booms vorherzusagen. Die Geschichte zeigt auch, dass die Eisenbahnlinien letztlich gebaut wurden – allerdings unter großen Verlusten für die Anleger. Ähnlich könnte es mit der KI-Infrastruktur sein: Die Rechenzentren werden entstehen, aber viele der heutigen Investoren könnten dabei viel Geld verlieren. Nvidia wird möglicherweise auch in zehn Jahren noch existieren, aber der Aktienkurs dürfte deutlich unter den aktuellen Höchstständen liegen, wenn die Blase platzt.

Für Investoren und Technik-Enthusiasten bedeutet das: Vorsicht vor der aktuellen Euphorie. Die Risiken von KI-Investitionen sind real, und die Schuldenberge der Tech-Konzerne sollten ernst genommen werden. Ein Blick auf die Geschichte hilft, die Lage nüchtern einzuschätzen – auch wenn die Technologie selbst ein enormes Potenzial hat. Die Frage ist nicht ob, sondern wann die Märkte die Realität einpreisen.

Quelle: stratechery.com

Die meisten Unternehmen bauen ihre KI-Strategie bis heute um einen einzigen Anbieter herum. 2026 ist genau diese Konzentration zum größten Risiko geworden.

Ein einzelner Modellanbieter ist inzwischen ein Single Point of Failure. Das erste Halbjahr hat es vorgeführt: Eine Regierung hat ein Spitzenmodell abgeschaltet, mehrere Anbieter fielen aus und legten Produktivsysteme lahm, und ein US-Softwarehaus prüfte ernsthaft ein chinesisches Modell, um seine Agentenflotte bezahlbar zu halten. Wenn deine kritischen Geschäftsprozesse an einer einzigen KI-Quelle hängen, trägst du ein Konzentrationsrisiko, das von theoretisch zu dringend geworden ist.

Fünf Treiber hinter der Multi-Modell-Strategie

Anfangs sah „mehrere Modelle einsetzen“ nach einem reinen Spartrick aus: einfache Aufgaben an günstige Modelle, komplexe an die teuren Spitzensysteme. Diese Logik gilt weiterhin und spart weiterhin Geld. Die Begründung für eine Multi-Modell-Strategie ist inzwischen aber breiter. Fünf Treiber machen sie unverzichtbar, und jeder einzelne hat in diesem Jahr ein konkretes Beispiel geliefert.

Erstens Verfügbarkeit und Modellwechsel – der Treiber, der 2026 am meisten an Gewicht gewonnen hat. Dann die Kosten für den Betrieb von Agenten, die alles Bisherige übersteigen. Regulierung und Compliance verlangen in verschiedenen Märkten verschiedene Regeln. Souveränität und Rechtsraum spielen hinein: Wer kontrolliert den Zugang zum Modell? Und schließlich die schlichte Frage, welches Modell zu welcher Aufgabe am besten passt. Kostenersparnis ist längst nicht mehr das stärkste Argument.

Verfügbarkeit und Modellwechsel: Wenn der Anbieter zum Flaschenhals wird

KI ist in Produktivumgebungen angekommen – bekommt dort aber weniger Ausfallsicherheit zugestanden als eine Datenbank oder eine Cloud-Region. Die Zahlen belegen das: Eine Auswertung von über 400 Tagen Downdetector-Daten großer KI-Dienste zeigt einen Anstieg der Ausfalltage von sechs im ersten Quartal 2025 auf 51 im ersten Quartal 2026. Auf Anthropic mit Claude entfielen 39 dieser 51 Tage – nicht aus Nachlässigkeit, sondern weil das Unternehmen das stärkste Wachstum bei agentischen Coding-Aufgaben erlebte. Skalierungsspitzen treffen den am schnellsten wachsenden Anbieter. Nächstes Jahr ist es jemand anderes. Deshalb solltest du deine Architektur auf diese Realität auslegen, statt auf den „besseren“ Anbieter zu setzen.

Die veröffentlichten Verfügbarkeitswerte liegen bereits unter dem, was du von einem verwalteten Datenbankdienst erwartest. Modelle bei Hyperscalern haben erst seit Kurzem Service-Level-Agreements, und die bleiben deutlich hinter üblichen Unternehmenserwartungen zurück. Direkte APIs der Frontier-Labs bieten meist gar keine Zusage. Eine Service-Gutschrift für einen Ausfall ist keine Lösung für Geschäftskontinuität. Der Modellwechsel ist dabei die leisere Hälfte des Risikos: Anbieter nehmen ältere Versionen binnen Wochen vom Netz, während ein reguliertes Unternehmen Monate für die Revalidierung braucht. Ein Modell, das verschwindet, stoppt nicht eine Anwendung, sondern die gesamte Workflow-Kette und jeden angeschlossenen Geschäftsprozess.

Die architektonische Lehre ist eindeutig. Ein fest verdrahteter Endpunkt eines einzigen Anbieters war in der Anfangszeit vertretbar. 2026 ist er ein ernsthafter Single Point of Failure. Ein zweites Modell als Ausweichpfad macht aus einem Totalausfall einen eingeschränkten Betrieb. Für die kritischsten Prozesse planst du zusätzlich einen komplett KI-freien Rückfall – regelbasiert oder mit einem Menschen in der Schleife. Die eigentliche Frage lautet nicht, auf welches Modell du umschaltest, sondern was mit dem Geschäft passiert, wenn gar kein Modell verfügbar ist. Die Antwort ist eine zweistufige Strategie: Multi-Modell als erste Verteidigungslinie, bewusst gestalteter Notbetrieb als zweite. Nicht jeder Workflow braucht eine LLM-Abhängigkeit.

Slack liefert ein bemerkenswertes Beispiel. Nach drei Jahren mit AWS als einzigem Anbieter stellte das Unternehmen fest, dass selbst die regionale und anbieterweite Zuverlässigkeit eines einzelnen Hyperscalers nicht genügte. Es nahm Google Vertex AI als zweiten vollwertigen Anbieter mit automatischem Failover hinzu – ohne jeden Druck durch Compliance oder Souveränität. Die reine Verfügbarkeitslogik reichte aus.

Agentenkosten: Der Turbo für Multi-Modell-Routing

Agenten haben die Ökonomie der KI-Nutzung grundlegend verändert. Ein Chatbot beantwortet eine Anfrage und hört auf. Ein Agent plant, liest, ruft Werkzeuge auf, versucht es erneut und verbraucht dabei durchgehend Token – auch dann noch, wenn der Nutzer längst weitergezogen ist. Eine gemeinsame Studie von Microsoft Research und dem Stanford Digital Economy Lab hat es gemessen: Agentische Coding-Aufgaben verbrauchen etwa tausendmal so viele Token wie klassischer Code-Chat. Die Streuung zwischen zwei Durchläufen derselben Aufgabe erreicht das Dreißigfache – und diese Schwankung sprengt ein Budget zuverlässiger als der absolute Verbrauch.

Die Rechnungen kamen mit voller Wucht. Uber hat sein gesamtes KI-Budget für 2026 in vier Monaten aufgebraucht, nachdem es Claude Code und Cursor an 5.000 Entwickler ausgerollt hatte. Danach führte das Unternehmen eine Obergrenze von 1.500 Dollar pro Entwickler und Monat ein. Die Botschaft ist deutlich: Eine pauschale Lizenz pro Arbeitsplatz überlebt diese Last nicht. Die Branche bewegt sich bei Agenten auf verbrauchsabhängige Abrechnung zu.

Microsoft ist der jüngste Beleg. Das Unternehmen hat seinen Enterprise-Agenten auf verbrauchsabhängige Preise umgestellt und angekündigt, neben den bestehenden Premium-Anbietern ein günstigeres Modell zu prüfen. Das ist kein politisches Signal, sondern ein architektonisches. Agenten mit hohem Volumen laufen auf einer Mischung von Modellen, ausgewählt nach Kosten und Aufgabe: Routinearbeit auf günstigen Maschinen, anspruchsvolles Schlussfolgern auf Spitzenmodellen. Microsoft hätte bei einem Anbieter bleiben können – der Kostendruck hat das Routing über mehrere Modelle zur besseren Alternative gemacht.

Compliance und Souveränität: Zwei Seiten derselben Medaille

Ein global tätiges Unternehmen sieht sich nicht einem Regelwerk gegenüber, sondern vielen, die sich teilweise widersprechen. Der EU AI Act wirkt extraterritorial – auch für Unternehmen außerhalb der EU, die dort Marktteilnehmer bedienen. Die Fristen haben sich dieses Jahr verschoben: Der Digital Omnibus hat die schweren Hochrisiko-Pflichten auf Ende 2027 und 2028 vertagt, während Transparenz- und Kennzeichnungspflichten kurzfristig in Kraft bleiben. Dazu kommen sektorale Regeln für Finanzwesen, Gesundheit und den öffentlichen Sektor sowie unterschiedliche Anforderungen an den Speicherort der Daten. Kein einzelner Anbieter erfüllt alle Regime gleichzeitig, die dein Geschäft berühren – eine Multi-Modell-Aufstellung ist der einzige Weg, über Märkte hinweg zu arbeiten, ohne die Plattform neu zu bauen.

Der zweite Teil ist die Souveränität. Der größte Bruch des Jahres kam im Juni: Die US-Regierung untersagte Anthropic über Exportkontrollen der nationalen Sicherheit, seine beiden leistungsfähigsten Modelle (Fable 5 und Mythos 5) an ausländische Staatsangehörige auszuliefern. Das Unternehmen musste diese Modelle daraufhin für alle Nutzer abschalten, während andere Modelle online blieben. Nach 19 Tagen kehrte der Zugang mit neuen Beschränkungen zurück. Überleg dir, was das bedeutet. Ein Modell, das am Freitag verfügbar war, war am Samstag weg – per Regierungsentscheidung, nicht weil der Anbieter einen Fehler gemacht hätte. Am Speicherort der Daten hätte sich dadurch keine Minute lang etwas geändert.

Die EU reagierte institutionell. Im Juli veröffentlichte die Europäische Kommission einen Aktionsplan für KI-Sicherheit mit Notfallmaßnahmen bis Ende 2026 für den Fall, dass ein Drittstaat den Zugang zu kritischen KI-Fähigkeiten kappt. Wenn Regulierer anfangen, Notfallpläne für solche Szenarien zu schreiben, ist das Risiko von der Konferenzbühne in die amtliche Politik gewandert. Chinesische Modelle tragen dieselbe Risikokategorie, nur in die andere Richtung. Jedes Modell, dessen Fortbestand von der Rechtsmacht eines einzelnen Staates abhängt, ist ein Konzentrationsrisiko – unabhängig von der Flagge. Die Lösung ist dieselbe wie bei allen anderen Treibern: Halte eine souveräne oder offene Option auf Infrastruktur am Laufen, die du selbst kontrollierst.

Das passende Modell für jede Aufgabe

Kein Modell führt in allem gleichzeitig. Eines glänzt bei langen Kontexten, ein anderes bei niedriger Latenz, ein drittes beim strukturierten Schlussfolgern, ein viertes bei Code. Latenz- und datenschutzkritische Schritte gehören oft auf ein kleines Modell direkt auf dem Gerät oder im eigenen Rechenzentrum. Erst wenn die Aufgabe es wirklich verlangt, sollte ein Spitzenmodell ins Spiel kommen. Diese Routing-Strategie senkt den Zugriff auf teure große Modelle spürbar, ohne dass die Qualität leidet.

Cursor liefert dazu einen überzeugenden Praxisfall. In einer Agentensimulation bauten vier verschiedene Modellkonfigurationen SQLite aus einem 835-seitigen Handbuch in Rust nach – ohne Quellcode, ohne Tests, ohne Internetzugang. Am Ende bestanden alle Konfigurationen die vollständige Testsuite, die Kosten unterschieden sich jedoch erheblich. Genau darum geht es: Mit einer durchdachten Modellmischung erreichst du dasselbe Ergebnis zu einem Bruchteil der Kosten.

Alle fünf Treiber zusammen machen eine umfassende Multi-Modell-Strategie unausweichlich. Wer bei einem einzigen Anbieter bleibt, nimmt eine Verfügbarkeitslotterie in Kauf, dazu die Kostenfalle bei Agenten, rechtliche Grauzonen, staatlichen Zugriff und eine Leistung, die für die jeweilige Aufgabe selten die beste ist. Die gute Nachricht: Die Werkzeuge sind da. Eine Orchestrierungsschicht, die Anfragen über Modelle verteilt, ein Failover-Mechanismus, der bei Ausfall automatisch umschaltet, und ein Portfolio aus gehosteten APIs und selbst betriebenen offenen Modellen sind inzwischen Standard. Wer das ignoriert, lernt die Lektion von 2026 auf die teure Art: durch einen Ausfall, den kein SLA abdeckt.

Quelle: kai-waehner.de