Kompression als Via Negativa: Das günstigste Token ist das, das Sie nie verschicken
Nehmen Sie eine beliebige Session mit einem Coding-Agent und öffnen Sie das rohe Request-Log. Nicht das hübsche Protokoll - die tatsächliche Payload. Was Sie finden: ein JSON-Suchergebnis mit 100 Treffern, von denen 3 relevant waren. Eine Log-Datei, in der die entscheidende Zeile unter 800 Zeilen "INFO: still fine" begraben liegt. Und ein Verzeichnislisting eines Repos, das das Modell bereits zweimal durchlaufen hat.
Dann stellen Sie das unbequeme Verhältnis auf: Kosten des fertigen Outputs versus die Menge an Input, die tatsächlich nötig gewesen wäre. Das Modell brauchte vielleicht 2.000 Token echtes Signal. Bezahlt haben Sie 55.000. In der Fertigung wäre das ein Bauteil aus massivem Gold, nur um eine Plastikklemme zu halten.
Ich habe ein paar Wochen lang alles - Coding, Recherche, stumpfe Textarbeit - durch einen Komprimierungs-Proxy namens Headroom geschickt. Das Interessante war nicht das Geld. Es war die Erkenntnis, wie viel von dem, was ich dem Modell "gesendet" habe, nie Information war.
Was das Tool konkret macht
Es sitzt zwischen Ihrem Agent und der API und komprimiert alles, was das Modell liest - Tool-Outputs, Logs, abgerufene Chunks, Gesprächsverläufe - bevor es weitergeleitet wird. Die Kompression passiert lokal, nichts wird an Dritte geschickt. Das Modell kann bei Bedarf auf das Original zugreifen.
Jobsicherheit durch unverzichtbaren Spaghetti-Code funktionierte prächtig - bis es das plötzlich nicht mehr tat.
Jede Technikabteilung hat so einen. Den Kollegen, dessen Code aussieht, als wäre er im Fiebertraum geschrieben worden - in einer Sprache, die er spontan erfunden hat. Keine Kommentare. Keine Dokumentation. Variablennamen wie xTmp_v2_FINAL_real. Funktionen, die sich über drei Dateien hinweg selbst aufrufen, ohne jeden erkennbaren Grund.
Und niemand fasst den Code an. Weil niemand ihn versteht. Und niemand versteht ihn, weil genau das der Zweck ist.
Ich habe mit einem Techniker gearbeitet - nennen wir ihn Gerald - der diese Kunst über fünf Jahre perfektioniert hatte. Fünf Jahre, in denen er systematisch eine Geiselnahme aufbaute, getarnt als Codebase. Jedes Modul unter seiner Verantwortung war ein vermintes Labyrinth. Neue Entwickler, die seinem Bereich zugewiesen wurden, hielten ungefähr zwei Sprints durch. Dann beantragten sie eine Versetzung, eine Therapie oder beides.
Das Management wusste, dass der Code schlecht war. Man konnte es riechen. Aber Gerald hatte sich zum einzigen Menschen gemacht, der sich durch das Labyrinth navigieren konnte - und die Geschäftslogik darunter war geschäftskritisch. Ein klassischer Single Point of Failure, eingewickelt in einen Single Point of Attitude.
Die implizite Drohung wurde nie laut ausgesprochen, aber jeder verstand sie: Kündigt mir, und dann viel Spaß mit den nächsten sechs Monaten voller Ausfälle.
Wenn kaputte Tools mit immer mehr Prozessen zugedeckt werden
Es gibt einen unverkennbaren Geruch, der verrät, dass ein Unternehmen leise in den Abwärtsstrudel geraten ist. Es sind nicht die Massenentlassungen oder die verfehlten Quartalszahlen. Es ist der Moment, in dem die Führung ein richtig kaputtes Tool, eine miserable Oberfläche, ein fehlerhaftes Skript oder einen chaotischen Ablauf anschaut - und beschließt, die einfachste Lösung sei... ein neuer Prozess.
Es geht eine E-Mail raus. Ein neuer KB-Artikel erscheint. Jemand nimmt ein kurzes Erklärvideo auf. Ein frischer Slack-Kanal wird geboren. Das Wiki bekommt eine weitere Seite, die nächste Woche schon wieder niemand liest. Und schwups hat sich das Unternehmen dafür entschieden, schlechte Werkzeuge mit menschlichem Reibungsverlust auszugleichen.
Ich habe dieses Muster in einem mittelgroßen Software-Unternehmen beobachtet, das auf dem Papier noch ganz gesund aussah.
Das interne Eskalations-Tool hatte einen fiesen Bug in der Suchfunktion. Einfache Anfragen lieferten in 40 % der Fälle unvollständige Ergebnisse. Das ging schon monatelang so. Statt den eigentlichen Index-Fehler zu beheben (was die Entwickler mit "nur ein paar Sprints" abtaten), kam das klassische Memo der Führung: "Bitte nutzen Sie ab sofort diesen Workaround bei der Suche nach Eskalationen."
Der Workaround bestand aus drei Extra-Schritten, dem Kopieren von Ticket-IDs in eine separate Excel-Tabelle, Abgleich mit einem anderen System und einem Post in einem eigenen Slack-Kanal, damit jemand anders prüfen konnte, ob man nichts übersehen hatte.
Deutsch ist objektiv eine dichtere Sprache als Englisch. Und das hat nichts mit Dichtern zu tun sondern mit dem Informationsgehalt pro Wort/Satz. Trotzdem macht es Ihre KI Prompts schlechter. Und der Grund verrät Ihnen ziemlich genau, wohin die Reise geht.
Vor einer Weile fragte mich jemand mit der aufrichtigen Begeisterung eines Menschen, der gerade eine große Idee hatte: "Deutsch ist doch so präzise. Wäre AI Prompting auf Deutsch nicht viel tokeneffizienter?"
Als Deutscher wollte ich das so sehr glauben. Endlich ein Wettbewerbsvorteil aus der Sprache, die der Welt Schadenfreude, Kummerspeck und Weltschmerz geschenkt hat.
Es stimmt nicht. Aber warum es nicht stimmt, ist interessanter als die Idee selbst.
Die deutsche Hypothese ist linguistisch stichhaltig
Deutsch packt tatsächlich mehr Bedeutung pro Wort. Komposita verschmelzen Konzepte zu eindeutigen Einheiten. Datenbankverbindungspoolverwaltung ist ein Wort, ein Konzept, und die Struktur verrät exakt, was wozu gehört. Das englische Pendant "database connection pool manager" besteht aus vier Wörtern und lässt offen, ob der Manager den Pool verwaltet, die Verbindungen oder die Datenbank. Dazu ein Kasussystem, das Beziehungen ohne Präpositionen codiert, und ein Wortschatz, der spezifische Begriffe vagen Oberbegriffen vorzieht. In der Theorie ergibt das weniger Wörter für dieselbe Anweisung.
Weniger Wörter, weniger Token, günstigere und schärfere Prompts. Wunderschöne Theorie.
Eine Hardware-Wallet erzeugte Schlüssel mit einem Zufallsgenerator, den sie kein einziges Mal aufgerufen hat. Fünf Jahre lang. Der Quellcode war die ganze Zeit öffentlich zugänglich.
In einem Zeitfenster von 25 Minuten hat jemand rund 594 Bitcoin abgeräumt - etwa 38 Millionen Dollar - aus rund 500 voneinander unabhängigen Wallets. Kein Phishing. Keine Malware. Kein Angriff auf die Lieferkette. Kein 5-Dollar-Schraubenschlüssel.
Jede dieser Wallets war durch ein Gerät geschützt, das mit einem einzigen, bewundernswerten Versprechen verkauft wurde: Schlüssel offline erzeugt, auf isolierter Hardware, mit einem echten Hardware-Zufallsgenerator. Bitcoin-only, um die Angriffsfläche klein zu halten. Keine Cloud, keine Begleit-App, und Open-Source-Firmware, die Sie selbst überprüfen können.
Der Hardware-RNG saß auf der Platine. Unter Strom. Funktionsfähig.
Rund 1.900 Tage lang hat die Firmware ihn nicht ein einziges Mal nach einer Zahl gefragt.
Der Bug ist ein Zeichen lang.
Der Hersteller hat etwas völlig Vernünftiges getan: Er hat MicroPythons eingebauten Zufallspfad per Build-Flag abgeschaltet, weil er einen eigenen Wrapper um den echten RNG des Mikrocontrollers geschrieben hatte. Sauberes Embedded-Handwerk nach Lehrbuch.
Dann prüfte eine kryptografische Hilfsbibliothek dieses Flag mit #ifndef - was fragt: "Existiert dieses Makro?" Nicht: "Hat es einen Wert ungleich null?"
Das Makro existierte. Sein Wert war null. Also kam die Bibliothek zu dem Schluss, Hardware-Entropie sei verfügbar, und band sich fröhlich an MicroPythons Zufallsfunktion. MicroPython wiederum hatte dasselbe Makro korrekt gelesen und statt des Hardware-Peripheriegeräts einen nicht-kryptografischen Software-Fallback kompiliert.
Vor vielen Jahren, als ich noch in der Lehre war, kam ein großer Schuhhersteller auf unser Softwarehaus zu. Sein Anliegen war bestechend einfach: Wir sollten die Produktion seiner Schuhsohlen effizienter gestalten.
Der damalige Prozess: Die Sohlen wurden aus dem Rohmaterial gestanzt - in ordentlichen, akkuraten Reihen. Wie Plätzchenteig. Alle in die gleiche Richtung, mit großzügigen Abständen dazwischen. Diese Abstände wurden zu Ausschuss, der Ausschuss wurde zu Kosten, und die Kosten wurden zu unserem Projekt. Der Auftrag lautete: Entwickeln Sie eine Software, die die Sohlenform in einem zufälligen, komprimierten und rotierten Layout anordnet - eine Art Tetris für Schuhwerk -, damit so gut wie kein Material verloren geht.
Rein technisch gesehen? Eine amüsante kleine Optimierungsaufgabe. Ein Junior-Entwickler hätte das in einer Woche abgewickelt.
Doch unser leitender Techniker tat etwas, das nur zwanzig Sekunden dauerte, aber die gesamte Bedeutung des Projekts veränderte. Er nahm ein Stück Rohmaterial zur Hand, kniff die Augen zusammen und fragte:
"Verzeihen Sie - ich verstehe nichts vom Schuhmacherhandwerk. Aber die Fasern in diesem Material verlaufen alle in eine Richtung. Wenn wir die Sohlen in zufälligen Winkeln gegen die Faserrichtung stanzen... könnte das die Qualität der Schuhe beeinträchtigen?"
Der Kunde antwortete ohne eine Millisekunde zu zögern: "Absolut. Jede Sohle, die gegen den Faserfluss geschnitten wird, ist minderwertig. Diese Schuhe werden mit hoher Wahrscheinlichkeit frühzeitig undicht."
Vor einiger Zeit traf ich mich mit einem alten Kollegen auf einen Drink. Wir machen das regelmäßig - zwei Leute, die schon genügend Serverräume und Lenkungsausschüsse von innen gesehen haben, um zu wissen, dass die besten Analysen nach einem Vorfall bei einem Negroni entstehen.
Er war bester Laune. Die Nutzung von "Vibe Coding" (die Art, Software schnell via AI, z.B. Claude zu programmieren, ohne den Code selbst zu schreiben (oder sogar zu verstehen)) in seinem Unternehmen war durch die Decke gegangen. Nicht nur bei den Software-Entwicklern, sondern auch bei Beratern, Architekten, und Technikern im Support - kurz: Jeder mit einem Puls und einer Claude-Lizenz baute plötzlich eigene Tools. Das Management feierte das. Man warf mit Zahlen wie mit Trophäen um sich: Ein Techniker verbrauchte Token im Wert von 100 Dollar pro Tag. Applaus. High-fives. Präsentationen.
Und mal ehrlich? Das ist auch in Ordnung. Wenn eine Token-Rechnung von 100 Dollar am Tag ein Tool hervorbringt, das zehn Stunden Entwicklungsarbeit pro Woche einspart, ist das der günstigste Mitarbeiter, den Sie je eingestellt haben. Ich bin nicht hier, um Token-Budgets schlechtzureden. Übrigens: "Vibe Coding" hat es innerhalb von etwa zwölf Monaten von einem beiläufigen Tweet von Andrej Karpathy bis zum Wort des Jahres im Collins Dictionary geschafft. Das ist eine schnellere Einführung, als die meisten Unternehmen für eine neue Spesen-Abrechnungssoftware benötigen.
Wie Bürokratie und ein kaputtes Anerkennungssystem die Produktivität zerstörten
Vor einiger Zeit bin ich in ein mittelständisches Technik-Unternehmen gegangen und habe eine ganz klassische Geschichte erwartet.
Die hatten alles richtig gemacht. KI-Assistenten eingeführt. KCS-Workflows integriert. Hochmoderne Kollaborations-Plattformen eingerichtet. Die Checkliste für ein perfektes Unternehmen war vollständig abgehakt. Das Management war völlig ratlos, denn ihre Investition hatte genau das Gegenteil von dem gebracht, was man sich erhofft hatte.
Die Techniker beschwerten sich lautstark über eine hohe Arbeitsbelastung. Und zwar richtig heftig. Diese Art von Meckern tötet die Moral und breitet sich aus wie eine Erkältung im Büro.
Aber hier wurde es interessant. Das Volumen war tatsächlich gesunken. Deutlich sogar. Die KI-Assistenten und die Self-Service-Abläufe hatten die einfachen Fälle abgefangen, bevor sie überhaupt einen Menschen erreichten. Die Zahl der Tickets war ordentlich zurückgegangen.
Das Problem war: Die übriggebliebenen Aufgaben waren härter. Die leichte Beute war bereits geerntet. Jedes Ticket erforderte jetzt eine tiefergehende Untersuchung, häufigeres Wechseln zwischen verschiedenen Themen und eine viel höhere Denkbelastung. Aber das allein erklärte das ganze Elend noch nicht.
Nach zwei Wochen voller Einzelgespräche und ruhiger Beobachtung fand ich die wahren Übeltäter. Zwei an der Zahl. Und die sind viel häufiger, als Führungskräfte zugeben wollen.
(Warum KI bisher nichts wirklich verzehnfacht - geschweige denn verhundertfacht - hat)
Seit Monaten hören wir dieselbe Geschichte in jedem LinkedIn-Beitrag, jeder Betriebsversammlung und jedem Hochglanz-Vortrag: Künstliche Intelligenz wird die Software-Entwicklung verhundertfachen. Geschäftsführer berauschen sich an ihren eigenen Versprechen von tausendfacher Effizienz, "Vibe-Coding" und einer Zukunft, in der Menschen weitgehend überflüssig werden. Einfach prompten, fertigstellen, Gewinn machen.
Sechs Monate später sehen die Kennzahlen verdächtig vertraut aus. Keine hundertfache Steigerung. Nicht einmal eine höfliche Verdopplung, die man ohne ellenlange Fußnoten belegen könnte.
Komisch, wie das immer wieder läuft.
Das Versprechen klang wunderbar: Die KI schreibt den Code, die Menschen trinken Kaffee, und die Geschwindigkeit steigt ins Unermessliche. Die Wirklichkeit ist deutlich menschlicher. Schnell mal ein 40-Zeilen-Skript per KI zu erstellen, macht tatsächlich Spaß. Sobald man jedoch in den Unternehmensmaßstab kommt - mit klaren Anforderungen, Sicherheitsprüfungen, Skalierbarkeit, Plattform-Unterstützung, Regressionstests, Richtlinien und der ganzen langweiligen, aber notwendigen Erwachsenen-Checkliste -, verfliegt der Zauber schnell.
Halluzinationen? Immer noch eher ein Merkmal als ein Fehler. Debugging-Aufwand? Enorm. Sicherheitsrisiken? Sie spielen russisches Roulette mit Produktionsdaten. Und bei komplexen Zusammenhängen verlieren die Modelle schneller den Überblick als ein Gratis-Testabo am letzten Tag des Monats.
Aber der eigentliche Engpass ist nicht die KI selbst. Es ist die organisatorische Schicht, die weiterhin mit der Geschwindigkeit von 2005 arbeitet, während die Programmierung mit 2026-Tempo unterwegs ist.
TrenchOps DE 🇩🇪🐎 
