Kategorie: Einblicke

Stell dir vor, du stehst am Fuß eines gigantischen Gebirges, dessen Gipfel im Nebel verschwinden. Du weißt, dass dort oben etwas Unvorstellbares wartet – eine neue Welt, die alles verändern wird. Aber der Aufstieg ist gefährlich, und niemand hat eine Karte. Genau das beschreibt Google-CEO Demis Hassabis in seinem Essay „A Framework for Frontier AI and the Dawning of a New Age“. Er spricht von einem Wendepunkt in der Menschheitsgeschichte, von einer Technologie, die so mächtig ist wie die Entdeckung des Feuers. Während er das Potenzial betont, bleiben die Risiken unausgesprochen – das macht viele Beobachter nervös.

Aufsicht nach dem Vorbild der FINRA

Hassabis schlägt ein neues Gremium vor: ein „Frontier AI Standards Body“ innerhalb der US-Regierung, ähnlich der Finanzaufsicht FINRA. Dieses Gremium soll sogenannte Frontier Labs regulieren – Unternehmen, die Modelle an der technologischen Grenze entwickeln. Die Idee klingt vernünftig: Labs müssten ihre Modelle vor der Veröffentlichung von unabhängigen Prüfern testen lassen, Sicherheitslücken schließen und sich regelmäßigen Evaluierungen unterziehen. Im Fall einer Eskalation könnte dieses Gremium sogar eine Verlangsamung der Entwicklung koordinieren. Auf den ersten Blick ist das ein Schritt in die richtige Richtung. Auf den zweiten Blick zeigt sich ein grundlegendes Problem: Der Vorschlag ist vage, lässt viele Fragen offen – und geht nicht auf das größte Risiko ein.

Denn Hassabis spricht von Experten, die sich uneinig sind, aber er vermeidet es, konkret zu werden. Er sagt nicht, worüber genau sie streiten. Dabei ist die Kluft enorm: Einige Experten schätzen die Wahrscheinlichkeit einer totalen Katastrophe durch KI auf fünf Prozent, andere auf neunzig Prozent. Das ist kein kleiner Unterschied – es ist die Frage, ob wir als Zivilisation überleben. Aaron Scher von der Future of Life Institute bringt es auf den Punkt: Wenn Hassabis von „Sicherheit“ spricht, meint er nicht Jobs oder Datenschutz, sondern die Gefahr, dass KI außer Kontrolle gerät und alles vernichtet. Doch in seinem Essay klingt es, als ginge es um ein harmloses Update für dein Smartphone. Diese beschönigende Sprache ist gefährlich, weil sie den Eindruck vermittelt, das Problem sei beherrschbar – dabei ist es das vielleicht nicht.

Hassabis vergleicht KI mit Feuer und Elektrizität. Eine treffende Analogie, aber bedenke: Feuer kann Wärme und Licht bringen, aber auch ganze Städte niederbrennen. Elektrizität hat unser Leben revolutioniert, aber ohne Schutzschalter und Sicherungen wäre sie tödlich. Was Hassabis vorschlägt, ist im Grunde ein Sicherungskasten – aber er sagt nicht, was passiert, wenn die Sicherung durchbrennt. Sein Gremium könnte Modelle prüfen, aber was, wenn ein Modell intern weiterentwickelt wird und nie nach außen dringt? Eli Tyre von der Organisation „The Limits“ weist zu Recht darauf hin, dass der Vorschlag nur öffentliche Veröffentlichungen betrifft. Die größte Gefahr liegt jedoch in den Laboren selbst: Wenn ein System beginnt, sich selbst zu verbessern, ohne dass es jemand bemerkt, gibt es keinen Rettungsring.

Reaktionen und Googles Rolle

Die Reaktionen auf Hassabis‘ Essay sind gemischt. Jack Clark von Anthropic lobt den Vorstoß, weil er zeigt, dass die führenden KI-Unternehmen das Problem ernst nehmen. Samuel Hammond sieht darin ein deutliches Warnsignal: Wenn alle großen Labs gleichzeitig Alarm schlagen, dann ist die Lage ernst. Connor Leahy von Conjecture fordert ein vollständiges Verbot von Superintelligenz, nicht bloß eine freiwillige Selbstregulierung. Denn selbst eine starke Überwachungsbehörde wie die SEC in den USA – die nicht einmal perfekt funktioniert – wäre kein Ersatz für ein internationales Abkommen. Ein Standards Body allein kann den Wettlauf nicht stoppen, er kann ihn höchstens etwas verlangsamen. Und das reicht nicht, wenn die Gefahr so groß ist, wie viele Experten vermuten.

Ein weiterer Punkt: Der Vorschlag von Hassabis kommt von Google. Google hat sich in der Vergangenheit nicht als Vorreiter in Sachen KI-Sicherheit hervorgetan. Ende 2024 unterzeichnete Google einen Vertrag mit dem US-Verteidigungsministerium, der die Nutzung von KI-Modellen für „alle legalen Zwecke“ erlaubt – einschließlich autonomer Waffen. Das ist eine krasse Abkehr von den Prinzipien, die Hassabis einst bei der Gründung von DeepMind propagierte. Ein Forscher namens Alex Turner hat aus diesem Grund gekündigt. Er war Teil eines internen Widerstands, der versuchte, den Deal zu verhindern – vergeblich. In seinem Abschiedsbrief beschreibt Turner, wie Jeff Dean, eine wichtige Person bei Google, zwar mehr Druck gemacht habe als die meisten, aber letztlich nicht genug, um die Führung umzustimmen.

Warum der Vorschlag zahnlos bleibt

Turners Geschichte ist eine Warnung. Sie zeigt, wie Machtverhältnisse und Gewinninteressen Sicherheitsversprechen über den Haufen werfen können. Hassabis‘ Standards Body wäre vielleicht eine gute Idee, wenn er wirklich unabhängig wäre und echte Durchsetzungsbefugnisse hätte. Aber was passiert, wenn die gleichen Unternehmen, die ihn finanzieren, ihn politisch unterwandern? Das wäre wie ein Fuchs, der den Hühnerstall bewacht. Die FINRA ist kein ideales Vorbild, weil sie in der Finanzkrise versagt hat. Ohne eine starke staatliche Aufsicht – ein „SEC für KI“ – bleibt der Vorschlag ein zahnloser Tiger. Und selbst dann: Wie will eine Behörde die Entwicklung einer Superintelligenz kontrollieren, die sich in Millisekunden verbessern kann? Die Zeit drängt, und die Vorschläge sind nicht einmal ansatzweise so dringlich wie die Lage.

Dennoch sollten wir Hassabis nicht völlig unterschlagen. Er hat den Anstoß gegeben, über Regulierung zu reden – das ist mehr, als viele andere tun. Sein Essay ist ein erster Schritt, aber er bleibt stehen, wo die eigentliche Arbeit beginnt. Die Frage ist: Sind wir bereit für die Revolution? Wir sprechen über eine Technologie, die das Potenzial hat, die Menschheit in ein Zeitalter des Überflusses zu führen – aber auch in ein finsteres Zeitalter der Knechtschaft oder gar Auslöschung. Hassabis sagt, KI sei zehnmal so folgenreich wie die Industrielle Revolution, und das in einem Zehntel der Zeit. Stell dir vor, die gesamte Lebensqualität würde sich in zehn Jahren verfünfzigfachen – oder auf null fallen. Keine Übertreibung, das ist das Szenario, vor dem Experten warnen.

Was jetzt nötig wäre

Was bleibt? Zunächst die Erkenntnis, dass wir nicht nur auf die großen Unternehmen angewiesen sind. Jeder kann sich informieren, Druck ausüben, diskutieren. Die Politik muss handeln – aber sie handelt nur, wenn die Öffentlichkeit es einfordert. Der Fall Alex Turner zeigt, dass es in den Laboren Menschen gibt, die das Richtige tun wollen. Doch sie brauchen Unterstützung von außen. Der Vorschlag von Hassabis ist ein Anfang, aber er darf nicht das Ende sein. Wir brauchen ein internationales Moratorium für die Entwicklung von Superintelligenz, vergleichbar mit dem Stopp der Kernwaffentests. Wir brauchen Transparenz und echte demokratische Kontrolle. Und wir brauchen eine Debatte, die nicht von PR-Phrasen überlagert wird. Denn am Ende geht es nicht um Technologie – es geht um unsere Zukunft.

Die nächsten Monate werden zeigen, ob die Branche ihren Worten Taten folgen lässt. Oder ob wir weiterhin Rennen fahren, ohne zu wissen, ob die Strecke ins Nirgendwo führt. Lies die Essays, hör auf die Warnungen – und lass dich nicht von schönen Worten einlullen. Die KI ist da, und sie wartet nicht. Wir müssen uns jetzt entscheiden.

Quelle: thezvi.substack.com

Du arbeitest mit einem KI-Coding-Agenten. Du gibst eine Aufgabe, er generiert Code-Vorschläge, du übernimmst sie, machst einen Commit und pushst an das Remote-Repository. Dann wartest du. Minuten vergehen, bis die CI-Pipeline zurückmeldet: „Build fehlgeschlagen wegen eines Lint-Fehlers“. Der Agent hat längst weitergemacht, der Kontext ist verloren. Du musst den Fehler manuell beheben und neu pushen. Dieses Szenario ist typisch für Teams, die auf KI-gestützte Code-Generierung setzen. CircleCI hat mit „Chunk Sidecars“ ein Werkzeug vorgestellt, das diese Lücke schließen soll: eine lokale Validierung, die innerhalb von Sekunden abläuft, bevor die Änderung an die CI übergeben wird.

Die Idee ist einfach, aber wirkungsvoll. Statt den gesamten CI-Prozess durchlaufen zu lassen, führt Chunk Sidecars in einer lokalen MicroVM nur die nötigen Prüfungen aus – Build, Tests und Linting. Das dauert im Schnitt 27 Sekunden. Das ist 78 Prozent schneller als ein vollständiger CI-Durchlauf. Und weil der Agent direktes Feedback bekommt, während er noch im gleichen Kontext arbeitet, sinkt die Anzahl der Tokens, die er pro Zyklus benötigt, um das Fünffache. Laut CircleCI spart das bei 5.000 Builds rund 375 Stunden Entwicklerzeit. Das sind beeindruckende Zahlen. Im Kern geht es um etwas Grundsätzlicheres: um das Gleichgewicht zwischen schneller lokaler Iteration und verlässlicher Remote-Validierung.

Das Problem: KI beschleunigt den Inner Loop, aber CI bleibt der Flaschenhals

Klassische CI/CD-Pipelines sind für menschliche Entwickler gemacht. Sie pushen regelmäßig, die Pipeline läuft, und nach ein paar Minuten wissen sie Bescheid. KI-Agenten arbeiten in einem anderen Tempo. Sie generieren Code in Sekunden, committen sofort und wechseln dann zum nächsten Problem. Der Remote-CI-Prozess ist dagegen langsam und asynchron. Er kann nicht mithalten. Das führt zu einer immer größer werdenden Lücke zwischen der Aktivität im Inner Loop (der lokalen Arbeit) und der Rückmeldung aus dem Outer Loop (der CI). Die Pipelines werden überflutet mit fehlgeschlagenen Builds. Entwickler verschwenden Tokens. Die Produktivität leidet.

Chunk Sidecars adressiert genau diese Asymmetrie. Es verschiebt einen Teil der Validierung zurück in den Inner Loop, direkt auf die Maschine des Entwicklers. Der Agent führt die Prüfungen aus, bevor er den Code commitet. Er bekommt sofortiges Feedback, kann Fehler selbstständig beheben und liefert nur sauberen Code an die Pipeline. Das reduziert die Anzahl der CI-Läufe drastisch und senkt die Token-Kosten. Es stellt die ursprüngliche Balance wieder her: lokal iterieren, remote validieren – jetzt in der richtigen Reihenfolge.

Wie es funktioniert: Drei Befehle zum schnelleren Feedback

Chunk Sidecars ist ein CLI-Tool, das CircleCI kostenlos für seine Nutzer anbietet. Es ist agent-agnostisch. Es funktioniert mit Claude Code, Codex, Cursor oder selbst gebauten Agenten. Die Installation ist einfach: „brew install CircleCI-Public/circleci/chunk“. Danach initialisiert man das Projekt mit „chunk init“. Das Tool erkennt automatisch den verwendeten Stack, die Test-Befehle und das Build-System. Manuelle Konfiguration entfällt. Im dritten Schritt ruft der Agent die „chunk-sidecar“-Fähigkeit auf. Sie synchronisiert sich, startet die MicroVM, führt die Prüfungen aus, meldet Fehler zurück und gibt am Ende sauberen Code aus – ohne dass ein Entwickler eingreifen muss.

Die MicroVM ist der Schlüssel. Anders als eine vollständige CI-Umgebung startet sie in Sekundenschnelle und enthält nur das Nötigste: die Abhängigkeiten des Projekts und die Ausführungsumgebung für Build, Tests und Linting. Das macht sie leichtgewichtig und schnell. CircleCI gibt an, dass die durchschnittliche Laufzeit bei 27 Sekunden liegt. Das ist schnell genug, um den Agenten nicht zu unterbrechen, aber lang genug, um echte Validierung zu liefern. Weil die Umgebung isoliert ist, sind die Ergebnisse reproduzierbar und verlässlich.

Mehr als nur ein schneller Build: Warum Chunk Sidecars anders ist

Ein lokaler Build-Check ist nicht neu. Entwickler führen seit Jahren vor dem Push Tests aus. Der Unterschied liegt in der Integration in den KI-Workflow. Chunk Sidecars ist darauf ausgelegt, von Agenten gesteuert zu werden. Es liefert nicht nur eine Erfolgs-/Fehlermeldung, sondern strukturiertes Feedback. Der Agent kann aus den Fehlerausgaben direkt Korrekturen ableiten und anwenden. Das reduziert die Anzahl der Iterationen zwischen Agent und Entwickler drastisch. Statt dass der Entwickler jeden Fehler manuell behebt, tut es der Agent im Inner Loop – und zwar mit lokaler Geschwindigkeit.

Ein weiterer Vorteil ist die Token-Ersparnis. KI-Modelle wie Claude oder GPT berechnen die Kosten pro Token. Wenn der Agent seinen gesamten Code an einen Remote-Dienst sendet, um ihn validieren zu lassen, entstehen Kosten für die Übertragung und Verarbeitung. Indem die Validierung lokal erfolgt, bleiben die Tokens im Agenten selbst. CircleCI spricht von „fünfmal weniger Tokens pro Agentenzyklus“. Das kann bei häufiger Nutzung erhebliche Summen ausmachen. Für Unternehmen, die KI-Agenten in der Entwicklung einsetzen, ist das ein handfester Kostenfaktor.

Und dann ist da der Zeitgewinn. 27 Sekunden für eine lokale Validierung klingt nicht nach viel. Aber im Vergleich zu einer CI-Pipeline, die oft drei bis fünf Minuten braucht, ist es ein großer Sprung. Multipliziert mit Hunderten von Commits pro Tag ergeben sich Stunden, die Entwickler nicht warten müssen. CircleCI gibt für 5.000 Builds eine Ersparnis von 375 Stunden an. Das ist fast zehn Arbeitswochen. Was ein Team in dieser Zeit erreichen kann, ist beträchtlich.

Einordnung: Was das für die Zukunft der KI-gestützten Entwicklung bedeutet

Chunk Sidecars ist kein Allheilmittel. Es löst ein spezifisches Problem: die Diskrepanz zwischen der Geschwindigkeit von KI-Agenten und der Latenz von CI-Pipelines. Es setzt voraus, dass man bereits mit KI-Agenten arbeitet und CircleCI nutzt. Aber das Prinzip dahinter ist allgemeingültig: Jede Technologie, die den Inner Loop beschleunigt, muss auch den Feedback-Loop entsprechend anpassen. Sonst entstehen Engpässe, die den Fortschritt bremsen.

Für Entwicklerteams, die auf KI-Coding setzen, ist das ein logischer nächster Schritt. Es verbessert nicht nur die Durchlaufzeit, sondern auch die Qualität des generierten Codes. Der Agent lernt aus den Fehlern, die er selbst behebt. Die CI-Pipeline bekommt nur noch saubere Commits. Das reduziert Frustration auf beiden Seiten. Der Entwickler muss seltener manuell korrigieren. Die CI-Pipeline wird nicht mit fehlgeschlagenen Läufen überflutet. Gleichzeitig bleibt die Kontrolle gewahrt, weil die finale Validierung weiterhin im Remote-CI-System stattfindet.

Man sollte auch die Grenzen sehen. Chunk Sidecars validiert nur eine Teilmenge der CI-Checks. Komplexe Integrationstests, Deployment-Tests oder Sicherheitsscans lassen sich nicht in 27 Sekunden in einer lokalen MicroVM abbilden. Dafür ist die Remote-CI weiterhin zuständig. Das Tool ist eine Ergänzung, kein Ersatz. Es filtert die „low hanging fruits“ heraus. Die Pipeline kann sich auf die wirklich wichtigen Prüfungen konzentrieren. Das ist ein kluger Ansatz: schnell das Offensichtliche validieren, das Tiefgehende an die etablierte Infrastruktur delegieren.

KI-Coding-Agenten werden immer produktiver. Werkzeuge wie diese werden zur Notwendigkeit. Sie halten das Ökosystem im Gleichgewicht und verhindern, dass die Beschleunigung an einer Stelle zu Engpässen an einer anderen führt. Chunk Sidecars ist ein Beispiel dafür, wie man bestehende CI/CD-Praktiken an die neue Realität anpasst, ohne das Rad neu zu erfinden. Wer mit KI-Agenten arbeitet, sollte sich das ansehen. Es ist schnell installiert, kostenlos und bringt sofort spürbare Verbesserungen. Ein erster Schritt zu einem harmonischen Zusammenspiel von KI und klassischer Softwareentwicklung.

Quelle: circleci.com

Du startest eine tiefgehende Recherche mit einem KI-Assistenten, gibst eine komplexe Frage ein und wartest. Nach einer halben Stunde erhältst du eine Fehlermeldung: „Token-Limit erreicht“. Kein Ergebnis, keine Erkenntnis – nur eine leere Hülle und das Gefühl, dein Budget verbrannt zu haben. Genau das passierte einem Entwickler, der die Ökonomie von KI-Agenten erforschen wollte. Sein Ziel: die wahren Kosten von agentischem Coden verstehen und herausfinden, wie man sie optimieren kann. Der erste Versuch scheiterte – frustrierend und lehrreich zugleich.

Der Entwickler baute für sein Forschungsprojekt eine tiefe Recherche-Pipeline mit mehreren KI-Agenten auf. Sie sollten eine vertrauenswürdige Wissensdatenbank erstellen. Die erste Version dieser Pipeline verbrauchte das komplette Kontingent seines Claude Max 5x-Plans in nur 30 Minuten – ohne ein einziges brauchbares Ergebnis zu liefern. 111 Agenten wurden gestartet, 123 Behauptungen zur Überprüfung eingereiht, aber nur 25 überprüft, bevor das Limit riss. Die finale Synthese fand nie statt. Ironischerweise musste er schon beim ersten Tag damit beginnen, Tokens zu sparen, während er noch herausfand, wie man Tokens überhaupt spart. Learning by doing.

Die Strategie: Vorhandene Abos clever nutzen

Statt sofort in teure Zusatzpakete zu investieren, nutzte der Entwickler das, was er bereits hatte: drei separate KI-Abos – Claude, Codex und Antigravity. Warum nicht alle drei parallel nutzen, mit gemeinsamen Speicher? Er erweiterte das claude-mem-Plugin, sodass alle drei Tools während der Sitzungen auf denselben Speicher zugreifen konnten. Was ein Tool lernte, stand auch den anderen zur Verfügung. Das war der erste Schritt zur Kostenkontrolle, ohne zusätzliches Geld auszugeben.

Doch damit allein war es nicht getan. Der Entwickler erkannte, dass nicht jede Aufgabe den teuersten Frontiermodellen überlassen werden muss. Claude Opus 4.8, Claude Sonnet 5, GPT-5.5 und Gemini 3.1 Pro sind für viele Teilaufgaben bereits exzellent. Er durchforstete Benchmarks wie Terminal-Bench, SWE-bench Pro und Artificial Analysis, um herauszufinden, welches Modell für welche Rolle am besten geeignet ist. Die Benchmarks behandelt er nie als absolute Wahrheit, sondern als grobe Richtwerte, die sich monatlich ändern. Daraus entstand eine Aufgabenteilung:

• Finden übernimmt Claude Sonnet 5 – stark auf agentischen Benchmarks und günstig für Masseneinsätze.
• Verifizieren erledigt Claude Opus 4.8 – das genaueste Claude-Modell; Prüfung erfordert mehr Präzision als Suche.
• Bewerten und Planen bleibt Claude Fable 5 vorbehalten – dem teuersten Modell, nur für die Zerlegung von Problemen und die Lösung von Streitfällen.
• Kleine Aufgaben wie Extraktion und Formatierung übernimmt Claude Haiku 4.5 – günstig und schnell, aber zu schwach für mehrstufige Arbeit.
• Werkzeuge ausführen delegiert der Entwickler an Codex (GPT-5.5) – stark auf Terminal-Benchmarks, klont, installiert, führt aus und prüft Tools.
• Zweite Meinung liefert Antigravity (Gemini 3.1 Pro) – eine andere Modellfamilie, nicht dieselben blinden Flecken.

Das Besondere: Codex und Antigravity laufen als „headless“ Subagenten unter der Orchestrierung von Fable. Die Tokens werden aus den jeweiligen Abos verbraucht, nicht aus dem Fable-Topf. Ein kleines Bash-Skript überwacht die Ausgaben auf „usage limit“- und „out of credits“-Meldungen und gibt einen speziellen Exit-Code zurück. Sobald ein Subagent sein Limit erreicht, schaltet der Orchestrator automatisch auf ein Claude-Modell um – die Forschung läuft weiter, ohne Benutzereingriff. Das Ergebnis: Statt 30 Minuten durchgehender Forschung mit Fable allein konnte der Entwickler die Arbeit nun mehrere Stunden am Stück fortsetzen, ohne mehr zu bezahlen.

Halluzinationen reduzieren: Vertrauen durch harte Regeln

Das Kostenproblem war gelöst, aber ein zweites blieb: die Zuverlässigkeit der Ergebnisse. In der ersten Phase, als alles noch über Fable lief, stieß der Entwickler immer wieder auf Falschinformationen: eine falsche Lizenz in einem Repository, eine Einsparungszahl ohne Quellenangabe, eine Zahl, die auf der zitierten Seite gar nicht stand. Um Halluzinationen einzudämmen, führte er explizite Prüfregeln ein. Jede Behauptung muss diese bestehen, bevor sie in die Wissensdatenbank aufgenommen wird.

Die Grundregel: Wer eine Behauptung findet, darf sie nicht selbst überprüfen. Ein anderes Modell oder ein anderer Agent übernimmt die Verifikation von Links, Zitaten und Zahlen. Nichts landet im Wissensspeicher ohne eine URL und ein wörtliches Zitat aus der Primärquelle. Keine Zahl darf genannt werden, wenn die Quellseite sie nicht enthält. Diese Liste wuchs während der Forschung stetig – jedes Mal, wenn eine neue Fehlerklasse entdeckt wurde, floss sie zurück in die Prompts. Der Entwickler betont, dass ein solcher Rahmen nur dann wirklich effektiv ist, wenn man ihn ständig justiert: Funde durchgehen, nutzlose aussortieren und das Feedback zurück in die Pipeline speisen.

Das Tool /deep-research, das die ganze Geschichte auslöste, blieb im Prozess, aber nun als letzter Schritt, nicht als erster. Statt blindlos das Internet zu durchforsten, arbeitet es sich durch die bereits verifizierten Funde, vertieft sie, eliminiert Unrat und füllt Lücken. So verbraucht es auch weit weniger Tokens – zuletzt 61 Agenten in 22 Minuten, verglichen mit den 111 Agenten und dem leeren Ergebnis zu Beginn. Derselbe Befehl, nur eine viel kleinere Aufgabe.

Die Pipeline im Überblick

Der gesamte Ablauf gleicht einer mehrstufigen Fabrik: Finden mit Sonnet, Prüfen mit Opus, Bewerten mit Fable, Ausführen mit Codex für konkrete Belege, tiefe Validierung per Mehrheitsentscheid, dann menschliche Freigabe. Erst danach wandert das Ergebnis in ein LLM-Wiki in Obsidian – inspiriert von Karpathys LLM-Wiki-Muster: verknüpfte atomare Notizen, Agenten, die die Arbeit erledigen, und ein Mensch, der die Regeln vorgibt. Nach einer Woche enthielt das Wiki bereits Hunderte validierte Notizen zu Preisen, Tools, Benchmarks und Praktiken.

Aber auch automatisierte Prüfungen sind nicht unfehlbar. Einmal lehnte eine Triage-Regel stillschweigend das Projekt „Headroom“ ab, ein Projekt mit 56.000 Sternen und eines der größten seiner Kategorie. Die Agenten hatten korrekt gearbeitet, die Verifikation bestätigte die Legitimität des Projekts, und eine Anspruchsprüfung stellte korrekt fest, dass die Schlagzeilen-Einsparungszahlen nicht qualitätsgesichert waren. Doch die Regel des Entwicklers lautete: „Nicht validierte Behauptungen bedeuten kein Eintrag.“ Also blieb ein Projekt, das die halbe Branche nutzt, unsichtbar. Erst zwei Tage später fiel es auf. Die Lösung: lehne die Behauptung ab, nicht das Projekt. Agenten können suchen und prüfen, aber kein Agent wird dir jemals sagen, dass deine eigene Regel der Fehler ist.

Was die Forschung wirklich lehrte

Die Token-Ökonomie entpuppte sich als komplexer als erwartet. Hier einige Erkenntnisse aus dem aufgebauten Wissen:

1. Das Framework kann so wichtig sein wie das Modell. Auf Terminal-Bench zeigte dasselbe Modell eine ~66-fache Token-Spanne über verschiedene Frameworks hinweg, und die schlankeren Setups erzielten sogar höhere Punktzahlen. Eine andere Studie maß einen Ausschlag von etwa 54 Prozentpunkten beim selben Modell, nur durch Veränderung des Frameworks. Der Entwickler erlebte eine kleine Version davon, als er die wahren Kosten eines einfachen „Hallo“ zu einem KI-Agenten untersuchte.

2. Context Compaction kann die Rechnung verdoppeln, statt sie zu senken. Context Compaction klingt nach Kompression – man nimmt an, es sei immer gut –, aber es ist nicht kostenlos: Das Modell muss den Verlauf zusammenfassen, und dieser Zusammenfassungsaufruf verbraucht ebenfalls Tokens. Außerdem kann es Dateien entfernen, die der Agent noch benötigt, sodass dieser sie erneut einliest, der Kontext sich wieder füllt und die Kompaktion erneut feuert. Eine dokumentierte Regression zeigt, wie böse diese Schleife werden kann: Nachdem ein Framework seinen Kompaktionsschwellenwert angepasst hatte, stieg die Anzahl der Kompaktionen von 4 auf 12–26 pro Sitzung, und der Tokenverbrauch für identische Aufgaben kletterte von 89 Millionen auf 160–185 Millionen.

3. Eine einzige Tooländerung mitten in der Sitzung macht den Cache ungültig und erfasst alles neu. Cache-Lesevorgänge kosten etwa 0,1× des Basis-Input-Preises, aber der Cache invalidiert hierarchisch: zuerst Tools, dann System, dann Nachrichten. Füge ein einzelnes Tool-Schema in der Mitte einer Sitzung hinzu oder ordne es um, und der gesamte bisherige Cache-Abschnitt wird zum vollen Preis neu abgerechnet. Es gibt keinen Fehler, nur eine höhere Rechnung.

4. Dein Token-Zähler ist nicht deine Rechnung. In einem dokumentierten Fall landete ein berechneter Betrag von 3,60 $/Monat als Rechnung von 25–40 $/Monat – eine Lücke von 7–11×, die durch Kontextakkumulation, Wiederholungsverstärkung, Framework-Overhead und Auswertungsaufrufe entstand, die eine einfache Tokenschätzung nie erfasst hätte. Der Entwickler kennzeichnet die meisten dieser Erkenntnisse als mittlere Vertrauensstufe – 1 oder 2 solide Quellen – und macht dies transparent, anstatt sie als gesetzt zu behandeln.

Bevor du dein nächstes Limit verbrennst

Wenn du heute deine Limits mit tiefer Recherche aufbrauchst, versuche, die Reihenfolge umzukehren. Günstige Modelle finden, genaue Modelle prüfen, und die tiefe Recherche kommt zuletzt. Und sieh nach, wie viel Intelligenz du bereits bezahlst. Ein paar Abos mit einer klaren Rolle für jedes Modell geben dir weit mehr als ein blind genutztes Frontier-Modell. Baust du selbst eine Forschungspipeline auf oder wächst deine KI-Rechnung schneller als deine Nutzung – dann schau dir die Erkenntnisse dieses Entwicklers genau an. Die Kombination aus menschlicher Kontrolle, geschickter Modellaufteilung und ständiger Regelanpassung ist der einzige Weg, um sowohl Kosten als auch Vertrauen in den Griff zu bekommen. Denn am Ende zählt nicht, wie viele Tokens du verbrennst, sondern was du aus den Ascheresten zurückgewinnst.

Quelle: quesma.com

Dein KI-Editor schlägt dir Verbesserungen vor. Manche sind nützlich, andere nerven. Du klickst auf „Regenerieren“. Was, wenn das Werkzeug aus deinen Entscheidungen lernt – ohne jedes Mal ein großes Modell zu befragen? Ben O’Mahony, Principal AI Engineer bei Thoughtworks, hat sich das gefragt. In seinem Vortrag auf der QCon AI zeigte er, wie er aus den Daten eines Frontier-Modells ein maßgeschneidertes, günstiges kleines Sprachmodell destillierte – allein mit Daten aus der täglichen Nutzung. Der Schlüssel: OpenTelemetry, ein Standard für Beobachtbarkeit, den er von Anfang an in seinen KI-Agenten eingebaut hat.

Ausgangspunkt war ein persönliches Projekt: ein KI-gestützter Language Server Protocol (LSP). Normale LSPs wie pyright oder rust-analyzer prüfen Code nach festen Regeln. Sie sind schnell und zuverlässig, verstehen aber keine semantischen Zusammenhänge. Sie merken nicht, dass ein Funktionsname nicht mehr passt oder du eine Standardbibliothek neu erfindest. O’Mahony wollte diese Einsichten direkt in seinen Workflow integrieren – als Inline-Vorschläge im Editor. Sein AI-LSP sendet bei jedem Speichern Code an ein großes Sprachmodell und bekommt Diagnosen und Code-Aktionen zurück. Problem: Die Kosten für Token laufen hoch, wenn man den ganzen Tag codet. Und das Modell bleibt eine Blackbox – Verhalten ließ sich nicht anpassen oder verbessern.

Vom teuren Lehrer zum kleinen Schüler

Dann kam der entscheidende Gedanke. O’Mahony hatte bereits OpenTelemetry in seinem Setup: Jede Interaktion mit dem AI-LSP wurde aufgezeichnet – welcher Vorschlag angenommen, verworfen oder zur Neuerstellung aufgefordert. Diese impliziten Labels sind wertvoll. Sie zeigen nicht nur, ob ein Vorschlag gut war, sondern auch, wie der Benutzer reagiert. „Akzeptieren“ ist ein starkes Signal für Korrektheit, „Dismiss“ für Irrelevanz, „Regenerate“ für „Diagnose stimmt, Lösung nicht“. Aus diesen Daten lässt sich ein kleineres Modell trainieren – eines, das die Verhaltensweisen des großen Modells kopiert, die für den spezifischen Anwendungsfall relevant sind. Das Fachwort ist Distillation: Ein großes, teures Modell (Lehrer) gibt sein Wissen an ein kleines, günstiges Modell (Schüler) weiter, das auf den Produktionsdaten des Lehrers trainiert wird.

Bevor du ein eigenes SLM trainierst, lohnt sich ein Blick auf die Grundlagen. Das Language Server Protocol ist der Standard für die Kommunikation zwischen Editoren und Sprachwerkzeugen. Dein Editor ist der Client, der Server versteht die Programmiersprache und liefert Dokumentation, Fehler, Vorschläge. Ein traditioneller LSP parst Code in einen Abstrakten Syntaxbaum und wendet Regeln an. Ein AI-LSP kann sprachagnostisch arbeiten, weil er die Semantik über die Textrepräsentation erschließt – er braucht keinen AST. O’Mahony betont: Der AI-LSP ersetzt nicht die deterministischen Checker, sondern ergänzt sie. Die Regelchecker bleiben für Syntax und Typen, das KI-Modell kümmert sich um tiefere Einsichten. Diese Trennung hält Kosten niedrig und bewahrt Zuverlässigkeit.

OpenTelemetry als Fundament

Der zweite Grundpfeiler ist OpenTelemetry. O’Mahony ist überzeugt: „Jeder Agent sollte von Tag eins an instrumentiert werden.“ Warte nicht, bis du über Distillation nachdenkst, sammle die Telemetriedaten sofort. OTel liefert standardisierte Strukturen: Events (Eingaben und Ausgaben des Modells), Metriken (Tokenverbrauch, Latenz) und Spans (einzelne Arbeitsschritte wie Chat Completion oder LSP-Interaktion). Diese Daten sind nicht nur für das Training wertvoll, sondern auch fürs Debugging. Du siehst, was das Modell gesehen hat, wie lange es brauchte, wo Probleme auftreten. O’Mahony nutzte Logfire und Pydantic AI – wenige Zeilen Code für den OTel-Exporter und automatische Instrumentierung. Der Aufwand ist minimal, der Nutzen maximal.

Wie genau sieht der Kreislauf aus? Der AI-LSP sendet bei jeder Codeänderung eine Anfrage an das Frontier-Modell. Die Antwort enthält Diagnosen und Vorschläge. Der Benutzer interagiert: akzeptiert, verwirft oder fordert Neuerstellung an. Der OTel-Trace erfasst all das als Spans mit Attributen wie accepted: true oder action: dismiss. Diese Daten werden in einer Datenbank gespeichert. Aus diesen Produktionstelemetriedaten extrahiert O’Mahony repräsentative Fälle: klare Annahmen, eindeutige Ablehnungen, Situationen, in denen der Benutzer eine Alternative wollte. Mit diesem kuratierten Datensatz wird ein kleineres Modell (etwa ein quantisiertes Llama) feinjustiert. Ergebnis: ein Modell, das in der spezifischen Umgebung fast so gut abschneidet wie das große Vorbild – zu einem Bruchteil der Kosten und Latenz.

Das Data Flywheel

O’Mahony nennt diesen Prozess „Data Flywheel“: Je mehr du den AI-LSP nutzt, desto mehr Daten erzeugst du. Desto besser wird dein kleines Modell. Desto seltener musst du auf das teure Frontier-Modell zurückgreifen. In seinem Setup arbeitet der AI-LSP zunächst mit dem großen Modell, um Trainingsdaten zu sammeln. Nach einer Weile wird das kleine Modell deployt und für die meisten Anfragen verwendet. Nur in Grenzfällen – bei niedriger Konfidenz – wird auf das große Modell eskaliert. Das spart Token und verbessert die Latenz. O’Mahony betont, dass dieser Ansatz nicht auf LSPs beschränkt ist, sondern auf jeden KI-Agenten übertragbar ist, der mit einem großen Modell arbeitet und Benutzerinteraktionen als implizites Feedback nutzt. Beispiele: Code-Review-Assistenten, Chatbots im Kundenservice, automatische Dokumentationsgeneratoren.

Was bedeutet das für dich als Entwickler oder Team-Lead? Der Weg zur kosteneffizienten KI führt nicht immer über bessere, größere Modelle, sondern über intelligentere Nutzung vorhandener Daten. Der Aufwand für die Instrumentierung ist minimal – OpenTelemetry ist heute in fast jedem Framework vorhanden. Die Herausforderung liegt in der Datenqualität: Du brauchst klare, konsistente Labels, um implizites Feedback zuverlässig zu extrahieren. Und eine Pipeline zum Sammeln, Filtern und Umwandeln in Trainingsdaten. Das sind lösbare Engineering-Aufgaben. O’Mahony selbst sieht sein Projekt als Vorlage für eine Plattform-Fähigkeit: Teams sollten ein gemeinsames System aufbauen, das Telemetrie, Datensammlung und Modell-Distillation standardisiert. Dann profitieren alle Agenten im Unternehmen von denselben Prinzipien.

Werkzeuge, die uns formen

Am Ende seines Vortrags zitiert O’Mahony einen Satz aus der KI-Community: „We shape our tools, and thereafter our tools shape us.“ Wenn du einen KI-Assistenten baust, formst du nicht nur ein Werkzeug, sondern auch die Arbeitsweise der Menschen, die es nutzen. Ein Assistent, der aus den Fehlern und Vorlieben seiner Benutzer lernt, wird mit der Zeit besser – und macht seine Benutzer effektiver. Der vorgestellte Prozess der Distillation aus Telemetriedaten ist ein praktischer Weg, diese Rückkopplung zu institutionalisieren. Er erfordert Disziplin, aber kein Hype. Es ist solide Ingenieursarbeit, die aus der Notwendigkeit entsteht, KI nachhaltig und bezahlbar in den Arbeitsalltag zu integrieren.

Quelle: infoq.com

Du siehst eine Anzeige für ein Küchenmesser. Du hast Kochvideos angeschaut, aber nie nach Messern gesucht. Trotzdem erscheint die Anzeige und wirkt interessant. Das liegt an Hierarchical Interest Representation (HIR), einer Technik von Meta. Sie verbindet versteckte Nutzerinteressen mit Werbeangeboten in einer hierarchischen Landkarte. Ziel ist der Deep Funnel, die Phase kurz vor einer Conversion.

Der Deep Funnel ist schwierig, weil Signale spärlich sind. Ein Klick sagt wenig über Kaufabsicht aus. Ein Kauf ist ein seltenes Ereignis. Meta muss aus wenigen, verrauschten Daten lernen. Bisherige Systeme erkennen oft nur oberflächliche Muster. HIR löst das mit Graphen-Lernen, Transformer-Architekturen und Weltwissen.

Das Kernproblem: Graphen mit dünnen Verbindungen

Als Nutzer bist du ein Knoten in einem riesigen Graphen. Andere Knoten sind Werbetreibende, Produkte, Kampagnen, Anzeigen. Die Kanten sind deine Interaktionen: Like, Klick, Kauf. Der Graph hat Milliarden Knoten und noch mehr Kanten. Die meisten Verbindungen sind schwach. Du klickst auf eine Anzeige, kaufst aber nichts. Oder du kaufst einmal. Das erschwert das Erkennen stabiler Muster.

Interessen sind dynamisch. Was heute interessiert, kann morgen anders sein. Werbetreibende ändern ständig ihre Angebote. Ein Modell muss mit Spärlichkeit und Veränderung umgehen. Die hierarchische Repräsentation gruppiert ähnliche Entitäten in übergeordnete Interessen-Primitive – stabile Ankerpunkte. Statt zu lernen, dass Nutzer A auf Produkt B klickte, lernt das System: A interessiert sich für Küchenutensilien. Das ist robuster.

Die Lösung: Ein hierarchischer Encoder

Meta nutzt eine Transformer-basierte Architektur für den Graphen. Ein speziell trainierter Encoder analysiert Knoten und Kanten, nicht Sätze. Der Encoder hat mehrere Komponenten:

• Anreicherung mit Weltwissen: Produkte und Werbetreibende werden durch Metadaten beschrieben. Meta nutzt LLMs, um Text, Bilder und Videos von Produktseiten zu analysieren. So weiß das Modell, was ein Küchenmesser ist, selbst ohne Klick-Daten. Das hilft bei neuen Anzeigen.
• Strukturelle Encoder: Der Encoder erfasst die Position der Knoten im Graphen. Mit zufälligen Läufen und wichtigkeitssortierten Strategien wird die lokale Topologie abgebildet. Kanten haben Gewichte und Zeitstempel – eine aktuelle Interaktion zählt mehr als eine alte.
• Bias Composition Attention: Transformer nutzen paarweise Beziehungen zwischen Tokens. Hier werden Graphenstrukturen als Aufmerksamkeits-Bias eingebaut. Das Modell erkennt, ob zwei Knoten direkt verbunden sind oder nur über Umwege. Das verhindert Over-Smoothing bei klassischen Methoden.

Die Attention wird mit FlexAttention berechnet. Dieser Kernel materialisiert die Bias-Matrix nicht, sondern berechnet sie on the fly. Das spart Speicher und erlaubt variable Teilgraphen ohne Padding. So trainiert Meta den Encoder auf Milliarden Knoten.

Training durch Selbstüberwachung

Das System lernt ohne gelabelte Daten durch Cross-View Distillation. Ein Lehrer und ein Schüler sehen denselben Knoten. Der Lehrer bekommt eine weite Perspektive (viele Nachbarn), der Schüler eine enge. Der Schüler sagt vorher, welcher Interessen-Cluster aus der weiten Perspektive entsteht. Das zwingt das Modell, allgemeine Muster zu lernen. Es ist selbstüberwacht – keine manuellen Annotationen nötig.

Es entstehen universelle Embeddings für alle Entitäten: Nutzer, Anzeigen, Werbetreibende, Produkte. Sie liegen in einem gemeinsamen metrischen Raum. Das beantwortet Fragen wie: Welche Interessen-Primitive ähneln sich? Wie nah ist dieser Nutzer dieser Produktkategorie? Welche Anzeige passt zu einer Zielgruppe? Das ist die Basis für Personalisierung, Retrieval und Ranking.

Was bedeutet das für Meta und die Nutzer?

Meta sagt, HIR verbessert die Deep-Funnel-Optimierung – die Wahrscheinlichkeit einer Conversion. Konkret soll Werbung relevanter werden, besonders für Nutzer mit schwachen Signalen. Du könntest weniger irrelevante Anzeigen sehen. Werbetreibende erreichen eher die richtigen Personen, auch ohne vorherige Interaktion.

Das ist noch Forschung. Meta nennt es eine neue Forschungsrichtung. Wann es produktiv wird, ist offen. Die Richtung ist klar: Meta will das unsichtbare Interessennetz verstehen, das dich mit Produkten verbindet – nicht nur oberflächliche Klicks.

Ob man will, dass Meta die versteckten Interessen so genau kennt, ist eine persönliche Abwägung zwischen Bequemlichkeit und Privatsphäre. Technisch ist HIR ein Schritt, aus spärlichen Daten Bedeutung zu extrahieren.

Quelle: engineering.fb.com