Kategorie: Einblicke

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

Du hast einen KI-Agenten programmiert. Er kann reasoning, Daten aus Millionen Dokumenten suchen, Schritte planen. Aber im Unternehmen tritt er auf der Stelle. Kein Fortschritt. Frustration. Kommt dir bekannt vor?

Es liegt nicht an den Modellen. Die sind heute gut genug. Das Problem ist die Infrastruktur, auf der sie laufen. Das sagten drei Infrastruktur-Chefs auf der VB Transform 2026: Animesh Singh von LinkedIn, Desiree Gosby von Walmart und Sami Ghoche von Zendesk. Alle drei waren beim Skalieren von KI-Agenten auf Probleme gestoßen. Ihr Fazit: Die Probleme lagen nicht an den Modellen, sondern an der Infrastruktur.

Stell dir die klassische Unternehmens-IT wie ein altes Straßennetz vor. Gebaut für langsame Fußgänger, die an jeder Kreuzung anhalten. KI-Agenten sind wie autonom fahrende Sportwagen, die keine Zeit für Ampeln haben – es knallt. Genau das passierte.

LinkedIn: Kubernetes war der Flaschenhals

Bei LinkedIn stieß Singh auf zwei Hindernisse. Der erste war Kubernetes. Der Container-Orchestrator startet Container auf Anfrage – das dauert Sekunden. Für Menschen ist das okay, aber KI-Agenten arbeiten in Millisekunden. Singhs Team änderte den Ansatz: Statt Container bei Bedarf zu starten, legen sie jetzt vorgefertigte Container-Pools an, in die agentische Workloads in Echtzeit ein- und ausgeswappt werden. Das löste das erste Problem.

Der zweite war schwieriger. LinkedIn erlaubte Agenten, ihre eigene Orchestrierung zu steuern – sie sollten selbst entscheiden, welche Schritte als Nächstes kommen. Ein fünfteiliges Evaluierungssystem sollte Halluzinationen unterbinden. Trotzdem traten sie auf. Singh erkannte das strukturelle Problem: Ein LLM, das die Ausgabe eines anderen LLMs bewertet, hat denselben Denkfehler wie das, was es bewertet. LinkedIn baute das System um: 80 Prozent des Workflows sind jetzt deterministischer Code, skriptgesteuert. LLMs kommen nur dort zum Einsatz, wo Reasoning nötig ist. Jeder Schritt protokolliert seine Ergebnisse, bevor es weitergeht.

Walmart: Der Erfolg wurde zum Problem

Bei Walmart sah die Hürde anders aus. Desiree Gosby ließ ein Agent-Harness direkt an die Mitarbeiter ausrollen – ein Werkzeug, mit dem selbst Citizen Developer eigene Agenten bauen können. Es ging viral. Plötzlich entstanden Dutzende Agenten für dieselben Probleme. Keine Koordination, keine Governance. Die Lösung war nicht, das Harness zurückzuholen, sondern eine Governance-Struktur aufzubauen, die Duplikate erkennt, die beste Version eines Agenten auswählt und in Produktion bringt – ohne dass Engineering den Prozess verlangsamt.

Gosby sagte: Engineering soll nie wieder der Engpass sein. Stattdessen sollen die Mitarbeiter innovativ sein können, während die Infrastruktur die Qualität sichert.

Zendesk: Die Datenflut zähmen

Sami Ghoche von Zendesk hatte es mit einer anderen Art von Infrastruktur zu tun: den Datenpipelinen. Zendesk sitzt auf rund 20 Milliarden Kundengesprächen – ein großer Bestand. Der naive Ansatz wäre, alles in ein großes Kontextfenster zu stopfen und ein LLM daraus Agenten generieren zu lassen. „Das funktioniert nicht“, sagte Ghoche. Stattdessen investierte Zendesk massiv in Datenpipelines, die die relevanten Informationen filtern und strukturieren, bevor ein Agent sie sieht.

Große Kontextfenster sind verlockend, aber sie ersetzen keine saubere Dateninfrastruktur. Ohne sie verlieren Agenten den Überblick oder liefern falsche Ergebnisse.

Open Source als Strategie

Alle drei Unternehmen verfolgen eine ähnliche Strategie: Unabhängigkeit von einzelnen Modellanbietern. Ghoche sagte, die meisten Unternehmen besitzen lieber eigene Modelle und Infrastruktur, wenn möglich. Nur für reine Frontier-Reasoning-Aufgaben greifen sie auf die führenden Labs zurück. Dieser Anteil sinkt, je mehr normale Enterprise-Anwendungen hinzukommen.

LinkedIn hat dafür zwei Bausteine entwickelt: ein AI Gateway, durch das jeder ausgehende Aufruf an ein Modell läuft, egal ob öffentliche Cloud oder eigenes Rechenzentrum. Und ein Memory-Subsystem, das Kontext unabhängig vom Modellanbieter speichert. So kann das Unternehmen schnell zwischen verschiedenen Anbietern wechseln.

Walmart hat sein eigenes internes Gateway gebaut, das drei Workload-Typen unterstützt: vollständig deterministische Abläufe, Planer-und-Validierer-Workflows für offene Aufgaben und eine Mischung aus beidem. Governance, Sicherheit und Evaluation laufen immer durch dieses Gateway – egal welches Modell gerade am anderen Ende sitzt.

Für alle gilt: Die Wahl zwischen einem Frontier-Modell und einem Open-Weight-Modell erfolgt nach Effektivität für die Aufgabe, nicht nach ideologischen Gründen.

Drei Ratschläge

Aus den Erfahrungen ergeben sich drei Empfehlungen:

Erstens: Investiere früh in Evaluierung. Ghoche nannte Evals die Basis jedes Use Cases. „Ein robustes Set von Evals hilft dir, das Problem zu zerlegen, danach kannst du viel schneller vorankommen.“ Ohne klare Metriken weißt du nicht, ob dein Agent besser wird oder nur anders funktioniert.

Zweitens: Gib Mitarbeitern früh ein Agent-Harness in die Hand. Gosbys Erfahrung zeigt: Das schafft enorme Innovation. Aber baue parallel die Infrastruktur auf, die entstandene Agenten überwachen und koordinieren kann. Sonst entsteht Chaos.

Drittens: Setze auf Modell- und Kontextunabhängigkeit. Singhs Rat: „Sorge für Unabhängigkeit – egal ob Frontier-Modell heute oder Open-Source-Modell morgen. Behalte den Kontext in deinem Unternehmen, damit du ihn wiederverwenden kannst, wenn du nächstes Jahr ein anderes Modell oder Harness einsetzt.“

Konsequenzen für dein Unternehmen

Wenn du KI-Agenten in deinem Unternehmen einsetzen willst, wirf zuerst einen genauen Blick auf deine Infrastruktur. Die Modelle sind bereit, aber deine Systeme sind es meistens nicht. Kubernetes, Datenpipelines, Governance – das sind die wichtigen Komponenten. Nicht das nächste große Sprachmodell, sondern grundlegende Arbeit. Die drei Unternehmen auf der VB Transform haben gezeigt: zuerst die Infrastruktur aufbauen, dann die Agenten einsetzen. Erst dann funktionieren sie zuverlässig.

Quelle: venturebeat.com