Kategorie: Erklärer

Stell dir vor, dein Unternehmen macht die ersten Schritte mit KI. Die Belegschaft ist begeistert, die Führung drückt aufs Tempo, jede Abteilung experimentiert. Die Finanzabteilung steckt vertrauliche Umsatzmodelle in öffentliche KI-Playgrounds. Die Personalabteilung lädt sensible Mitarbeiterdaten in externe Dienste hoch – ohne zu prüfen, wie lange die Daten dort bleiben. Für die Sicherheitsteams wird das zum Albtraum. KI hat die Unternehmenssicherheit härter gemacht – nicht durch neue, exotische Bedrohungen, sondern weil sie vorhandene Schwächen gnadenlos beschleunigt.

Der Autor ist kein KI-Gegner. Er nutzt die Technologie täglich, hält sie für transformativ und unvermeidlich. Aber er ist Pragmatiker. Jeder Technologieschub ändert nur die Gestalt der Probleme und verschiebt sie auf eine andere Architekturebene. Die rasche Demokratisierung von Large Language Models und autonomen Code-Agenten hat die Sicherheit in mehreren Punkten deutlich erschwert. Wir müssen über oberflächliche Verwundbarkeiten hinausblicken und die strukturellen Engpässe analysieren, die Sicherheitsteams zermürben.

Der Autor unterscheidet zwei Unternehmenstypen: solche mit ausgereifter KI-Infrastruktur und solche in der hektischen Experimentierphase. In reifen Unternehmen hat man gelernt, dass Nutzen und Risiken von KI variabel sind. Jede Bereitstellung wird geprüft: Datenherkunft, Modellgrenzen, Ausführungsebenen. Man weiß, ob ein Risiko die operative Reibung wert ist. In hyperoptimistischen Experimentierphasen herrscht eine gefährliche Anspruchshaltung. Die Führung ist überzeugt, dass die Vorteile von KI abstrakte Risiken automatisch überwiegen. Also wird uneingeschränkter Zugang gefordert – nicht nur von Entwicklern, sondern von jeder nicht-technischen Abteilung.

Diese Teams wollen die volle Erfahrung sofort. Jede Sicherheitsgrenze gilt als Bedrohung der Unternehmensgeschwindigkeit. Sie wollen die Schleusen öffnen und jeder internen Anwendung vollen Zugriff geben – ohne zu bedenken, dass der Datenzugriff einer KI abgeschottet werden muss. Granulare Identitäts- und Zugriffskontrollen brauchen Zeit. Optimistische, geschwindigkeitsbesessene Organisationen investieren diese Zeit nicht. Auf der Jagd nach einer reibungslosen Benutzererfahrung türmen sie strukturelle Risiken auf, bevor sie ihr erstes Produktionsfeature ausliefern.

Diese Reibung zeigt eine Asymmetrie des Scheiterns. Der Autor vergleicht die Bewertung eines autonomen Agenten durch ein Engineering-Team mit der Sicht eines CISOs. Ein Entwicklungsteam, dessen interner Agent zu 90 % erfolgreich Repositorys patcht oder Kunden-Tickets löst, feiert das als Triumph. Aus Produktsicht ist eine Fehlerrate von 10 % tolerierbar. Für einen CISO ist diese 10 %-Varianz eine katastrophale strukturelle Verwundbarkeit. Sicherheit verfolgt ein anderes Ziel: absolute Vermeidung von Systemversagen. Ein einziger unentdeckter Fehler oder eine halluzinierte Zugriffsgrenze reicht aus, um eine Datenpanne oder einen Betriebsvorfall auszulösen. Produktorientierte Organisationen können endlos experimentieren, weil sie nur einmal erfolgreich sein müssen. Ironischerweise nutzen Angreifer dasselbe Modell. Ein Gegner kann tausendmal scheitern, aber er muss nur eine lockere Prompt-Konfiguration finden, um zu gewinnen. Sicherheitsteams sitzen in der Zange: Sie müssen eine riesige, nicht-deterministische Angriffsfläche verteidigen und zu 100 % richtig liegen, während Entwicklerteams die Architektur aktiv bewaffnen.

Führungskräfte glauben oft, KI schaffe völlig neue Cyberbedrohungen. Der Autor argumentiert, KI erfindet selten neuartige Verwundbarkeiten. Stattdessen verstärkt sie bestehende schlechte Angewohnheiten, Architekturpraktiken und technische Schulden. Eine KI-Anwendung verhält sich wie ein Taschenrechner: Gibst du die falschen Zahlen ein, liefert sie eine falsche Antwort – um Größenordnungen schneller als ein Mensch. KI wendet diese mechanische Beschleunigung auf die Softwareentwicklung an. Wenn dein Team bereits unordentliche IAM-Konfigurationen oder schlechte Code-Review-Disziplin hat, vervielfacht KI diese Fehler sofort. Ein KI-Agent beurteilt keine Qualität. Er repliziert ein loses Berechtigungsmuster in Sekunden über Hunderte von Microservices. Das deckt latente Infrastrukturfehler auf und erzeugt eine massive Systemausbreitung, bevor ein Sicherheitsingenieur den ersten Commit-Log analysiert.

Angreifer nutzen diese Geschwindigkeitsdynamik. Sie setzen automatisierte Tools ein, um die maschinell erzeugte Ausbreitung zu kartieren und auszunutzen – schneller, als defensive Teams reagieren können. Es ist ein ermüdender Kampf gegen einen automatisierten Taschenrechner, der ständig die falschen Zahlen eingibt.

Weil die Technologie zu schnell für traditionelle defensive Frameworks ist, erleben wir eine schmerzhafte Umstrukturierung der Sicherheitsorganisation. Historisch wurden Sicherheitsteams mit einer Compliance-zuerst-Denkweise aufgebaut. Sie waren administrative Körper, die Kästchen ankreuzen, Audit-Logs sammeln und externe Anforderungen erfüllen. Selbst mit hochtechnischen Sicherheitsingenieuren fraß die Compliance-Maschine das Betriebsbudget. Da KI den Softwareentwicklungslebenszyklus einebnet, werden Engineering-Teams enorm gestärkt. Sicherheit kann Risiken nicht mehr durch administrative Richtlinien managen. Die Kluft zwischen Compliance und Engineering wird zu groß.

Um die Lücke zu schließen, spaltet sich die traditionelle CISO-Rolle in zwei Personas. Der compliance-fokussierte CISO wird zum Chief Compliance Officer, der externe Audit-Zyklen managt. Unternehmen holen echte Engineering-Leader als technische CISOs ins Boot – Menschen, die Plattformarchitektur verstehen. Ein neues Security Engineering Team entsteht als Puffer zwischen beiden Welten. Es übersetzt Compliance-Anforderungen in programmierbare Code-Guardrails, die Engineering verdauen kann. Dieser organisatorische Wandel ist unvermeidlich, macht den Sicherheitsjob kurzfristig chaotisch. Er sorgt für Prozessverwirrungen, stellt Eskalationswege auf den Kopf und lässt compliance-fokussierte Praktiker mit weniger Einfluss und Ressourcen zurück.

Diese Störung eröffnet eine Marktchance für Security-Startups. Die meisten KI-Sicherheitsanbieter leiden unter Tunnelblick. Sie bauen fortschrittliche Orchestrierungstools für Elite-Engineering-Teams. Aber diese Teams sind bereits kompetent und überlastet. Der unbediente Markt gehört dem Anbieter, der Software baut, die dem alten compliance-fokussierten Team hilft, sich mit KI in eine moderne Engineering-Einheit zu verwandeln. Ein schwieriges Produkt, dessen Gewinner-Oberfläche noch unklar ist. Wenn ein Startup unordentliche regulatorische Frameworks aufnehmen und elegante, versionierte Policy-as-Code-Konfigurationen ausgeben kann, die in Entwickler-Pipelines passen, erschließt es eine Elite-Kategorie von Unternehmensausgaben. Snyk schloss die Lücke zwischen Entwicklern und AppSec. Wiz verwandelte komplexe Cloud-Infrastruktur in einen priorisierbaren Risikographen. Der Gründer, der die Übersetzungsmaschine für die Compliance-Kluft baut, prägt das nächste Jahrzehnt der Enterprise-Security-Software.

KI hat die Sicherheit härter gemacht, weil sie die Illusion von Kontrolle zerstört hat. Wir können uns nicht länger hinter statischen Richtlinien oder manuellen Gates verstecken. Die Maschine des Unternehmens bewegt sich mit Runtime-Geschwindigkeit. Wenn unsere defensiven Frameworks nicht skalieren, bewachen wir einen leeren Perimeter. Hört auf, nach neuen, exotischen Bedrohungen zu suchen. Automatisiert eure grundlegenden Hygienepraktiken – das ist der Hebel, den KI zieht.

Quelle: franklyspeaking.substack.com

Suchmaschinen liefern oft Dutzende Ergebnisse, die nicht genau treffen, weil sie nur nach Wortübereinstimmungen suchen. Semantische Suche versteht die Bedeutung. HubSpot hat eine Infrastruktur aufgebaut, die für über zwanzig Milliarden Vektoren semantische Suche ermöglicht. Dieser Artikel beschreibt ihre Entscheidungen und Skalierung, von der Machbarkeitsstudie bis zur automatisierten Großanlage.

Eine Vektordatenbank ordnet jedes Objekt in einem mehrdimensionalen Raum an, sodass ähnliche Inhalte nahe beieinander liegen. Die Suche findet die nächsten Nachbarn zur Anfrage. Qdrant, das HubSpot einsetzt, ist ein zentraler Baustein moderner KI-Anwendungen, von Chatbots über RAG-Systeme bis zur Dubletten-Erkennung von Kontakten.

Warum eine zentrale Vektor-Plattform?

HubSpot begann vor einigen Jahren mit einem Proof of Concept. Damals reichte eine Handvoll Cluster, die mit Helm verwaltet wurden. Mit dem Wachstum der KI-Nutzung – heute nutzen über 38 Teams die semantische Suche – wurde eine zentrale, verwaltete Plattform notwendig. So entstand VaaS – Vector as a Service. Es ist die Schicht zwischen den Anwendungen und der Vektordatenbank. Sie übernimmt Zugriffskontrolle, generiert Embeddings, verwaltet Versionen und sammelt Feedback. Die Anwendungen rufen eine API auf und müssen sich nicht um die Komplexität kümmern. Schreiboperationen laufen asynchron, Leseanfragen synchron.

Warum Qdrant und warum selbst betrieben?

Die Wahl fiel auf Qdrant, eine quelloffene Vektordatenbank, die sich auf eigenen Servern betreiben lässt. Qdrant bietet eine umfangreiche API: benannte Vektoren, Hybridsuche, mehrstufige Abfragen und gewichtetes Ranking. Als ANN-Algorithmus verwendet es HNSW, das geringe Latenzen ermöglicht, aber mehr Arbeitsspeicher benötigt. Die HubSpot-Ingenieure nutzen Optimierungen wie Quantisierung und plattenbasierte Optionen, um Qualität und Kosten auszugleichen. Der Betrieb im eigenen Haus bietet volle Kontrolle über die Daten, Integration in die bestehende Infrastruktur (Tracing, Kostenverfolgung, Rate Limiting, Auto-Scaling) und Nutzung der eigenen AWS-Konditionen. Die Sicherheitsstandards von HubSpot lassen sich direkt anwenden.

Die aktuelle Dimension: Zahlen

VaaS verwaltet heute über 200 Indizes, verteilt auf mehr als 140 Qdrant-Cluster in fünf Rechenzentren und zwei Umgebungen. Insgesamt sind das über 20 Milliarden Vektoren – der größte einzelne Index umfasst 9,5 Milliarden Vektoren, der Durchschnitt liegt bei 95 Millionen. Die Plattform verarbeitet regelmäßig über 5.000 Schreiboperationen pro Sekunde, mit Spitzen bis zu 100.000. Leseanfragen liegen bei über 1.000 RPS. Besonders herausfordernd sind Traffic-Spitzen, wenn große Backfills gleichzeitig mit Live-Traffic laufen. Die Infrastruktur muss skalieren und zuverlässig bleiben. Eine Cluster-Isolation nach Produktteams stellt sicher, dass ein Ausfall nicht die gesamte Plattform lahmlegt.

Vom Helm-Proof-of-Concept zum Kubernetes Operator

2023 startete man mit Helm und einer Handvoll Cluster. Jeder Cluster bekam eine eigene Konfiguration, die manuell per YAML und Skripten angelegt wurde. Für zehn Cluster war das machbar, aber mit dem Wachstum wurde der Aufwand enorm. Jeder neue Cluster brauchte nicht nur die Qdrant-StatefulSets, sondern auch Kafka-Themen, Worker-Pods und Monitoring-Komponenten. Helm kann keine API-Aufrufe tätigen, kein automatisches Scaling basierend auf externen Metriken durchführen und keine komplexen Lebenszyklus-Management-Schritte ausführen. Deshalb entschied man sich für den Umstieg auf ein hauseigenes Kubernetes-Operator-Framework namens „Kube-operators“. Ein Operator überwacht ständig den gewünschten Zustand des Systems und bringt die Realität dorthin – automatisch.

Die Migration brachte eine wichtige Änderung: Statt eines gemeinsamen Namespace für alle Cluster gibt es jetzt einen Namespace pro Cluster. Das erhöht die Isolation, vereinfacht das Kosten-Tracking auf Teamebene und reduziert den Blast Radius bei Fehlern. Die Konfiguration eines neuen Clusters besteht heute aus genau einer Custom Resource (CR). Ein Translator (eine Komponente des Operators) überwacht diese CR und erzeugt oder aktualisiert daraus alle notwendigen Ressourcen: Namespace, StatefulSet für Qdrant, Indexer-Pods, Kafka-Themen und benutzerdefinierte Ressourcen für die Metadaten der Cluster. Die Plattform entdeckt neue Cluster automatisch, indem sie die entsprechenden CRs beobachtet. Ein zusätzlicher Translator kümmert sich um die Qdrant-Knoten selbst, ein dritter um die Indexer – die Arbeiter, die eingehende Schreiblast puffern und in Qdrant indizieren. Das alles läuft in einem 60-Sekunden-Zyklus, so dass Änderungen schnell wirksam werden.

Automatisierte Wartung – Shard-Evakuierung aus einem Guss

Ein besonders kniffliger Vorgang ist das horizontale Herunterskalieren eines Clusters. Früher waren mehrere manuelle Schritte nötig: zuerst einen Job ausführen, der die Shards von den zu entfernenden Knoten transferiert und diese aus dem Konsens entfernt; dann die Helm-Chart aktualisieren, die Pod-Anzahl reduzieren, und schließlich die PVCs der gelöschten Pods manuell löschen. Bei über hundert Clustern ein unhaltbarer Zustand. Mit dem Operator ist das heute ein einziger Schritt: einfach die Replica-Anzahl in der Cluster-CR reduzieren. Der Translator erkennt die Abweichung, startet automatisch die Evakuierung aller Shards von den zu entfernenden Peers, wartet auf erfolgreichen Transfer und entfernt die Peers dann aus dem Konsens – und zwar in einer strikten Reihenfolge, die Datenverlust und Verletzung der Replikationsfaktoren verhindert. Erst wenn alle Shards sicher umgezogen sind, werden die Pods heruntergefahren und die PVCs gelöscht. Diese Automatisierung ist entscheidend, um bei der Größenordnung von 140+ Clustern operativ effizient zu bleiben.

Die Architektur zeigt, wie Unternehmen KI-Infrastruktur als Dienst für interne Teams bereitstellen können. Die Teams müssen sich nicht um die Datenbank kümmern, sondern können sich auf die Geschäftslogik konzentrieren. Der Schlüssel liegt in der Automatisierung: Ein Kubernetes-Operator, der nicht nur Pods startet, sondern auch die Shard-Verwaltung von Qdrant übernimmt. Ein zentraler Dienst besteht aus mehr als nur einer API vor einer Datenbank. Es sind Komponenten wie Namespace-Isolation, dynamische Cluster-Entdeckung und automatisierte Skalierung mit Sicherheitsgarantien, die den Unterschied zwischen einer Labordemo und einer produktiven Umgebung mit Milliarden von Vektoren ausmachen. Die Zukunft der KI-Suche liegt nicht nur in besseren Algorithmen, sondern auch in der robusten, wartbaren Infrastruktur, die sie trägt.

Quelle: product.hubspot.com

Du arbeitest an einer Data Pipeline. Nach einem nächtlichen Lauf stellen die Zahlen, aber nur auf den ersten Blick. Irgendwo hat sich ein Fehler eingeschlichen: eine doppelte Zeile, ein falscher Join, der nicht auffällt, weil das Ergebnis nicht abstürzt. Ein Fehler, der nicht bricht, sondern leise falsche Werte liefert, kann in Berichten und Entscheidungen unbemerkt verheerend wirken. In der Datentechnik geht es nicht nur darum, Code zu produzieren, sondern Code, dem wir vertrauen können.

KI-Agenten sollen dabei helfen. Aber wie viel Vertrauen darf man ihnen schenken? Ein aktueller Artikel beschäftigt sich mit dieser Frage und stellt die Korrektheitsschicht vor – ein Sicherheitsnetz, das die Zuverlässigkeit von KI-generierten Datenpipelines erhöht. Der Artikel untersucht drei Ebenen von KI-Agenten in der Datentechnik, die Rolle deterministischer Validierung und wie sich Token-Kosten kontrollieren lassen. Fazit: Die Struktur eines Projekts und die richtigen Werkzeuge sind wichtiger als das neueste Sprachmodell.

Die drei Ebenen der KI-Agenten in der Datentechnik

Warum Agenten für die Datentechnik einsetzen? Und auf welchen Ebenen können sie produktiv helfen? Sprachmodelle haben, wie Menschen, eine gewisse Fehlertoleranz. Wir brauchen eine Möglichkeit, sicherer zu sein, dass der produzierte Code korrekt ist. Der Artikel unterscheidet drei Stufen.

Erste Ebene: die reine Chat-Phase. Hier prompten wir Claude oder ChatGPT. Das Modell versucht, den Kontext zu verstehen, basierend auf dem, worauf es Zugriff hat. Das verbraucht viele Tokens, weil es alles von Grund auf scannen muss. Das Ergebnis ist brauchbar, aber selten produktionsreif.

Zweite Ebene: der autonome Ansatz. Hier haben Agenten wie Claude Code oder Codex Zugriff auf dieselben Werkzeuge wie ein Mensch – die Kommandozeile. Sie können Postgres mit psql abfragen, mit DuckDB aus S3 oder Parquet lesen und so Daten und Queries direkt verifizieren. Die Qualität der Ergebnisse ist höher, weil der Agent nicht nur rät, sondern überprüft.

Dritte Ebene: dedizierte Agenten für die spezifische Aufgabe. Für die Datentechnik kennen diese Agenten dbt oder können SQL-Code deterministisch transpilieren – nicht aus Trainingsdaten, sondern mit einem Werkzeug, das schneller und zuverlässiger arbeitet. Sie haben eingebaute Prüfungen und Funktionen, die ein allgemeiner Agent nicht bietet. Ideal sind immer dedizierte Werkzeuge – aber es gibt nicht für jede Aufgabe ein solches.

Wo im Datenlebenszyklus jede Ebene wirklich hilft

Die Frage ist nicht nur, ob es dedizierte Agenten gibt, sondern in welchem Teil des Datenlebenszyklus sie den größten Nutzen bringen. Geht es um BI-Dashboards, Datenleitungen, Quell-Ingestionen oder Wartung? Der Lebenszyklus umfasst Extraktion, Transformation und Laden, das Verständnis der Geschäftslogik, die Visualisierung der Ergebnisse und die Fehlerbehebung bei nächtlichen Läufen. Grundsätzlich können Agenten im gesamten Zyklus helfen, aber die Antwort hängt stark von der Rolle und Erfahrung des Anwenders ab. Ohne Vorwissen oder Seniorität ist es gefährlich, von Grund auf etwas zu bauen. Man kann nicht überprüfen, ob der Code korrekt ist. Für Nebenprojekte oder Proof-of-Concepts ist das okay, aber nicht für die Produktion.

Die Ingenieursdisziplin im Umgang mit KI

Es gibt auch einen weniger technischen Teil: die Agenten in die richtige Richtung lenken. Wenn wir KI sicher in großen Projekten oder Organisationen einsetzen wollen, können wir sie nicht ohne Führung laufen lassen. Vier Punkte helfen dabei.

Erstens: eine klare Projektstruktur, in der die Agenten sich entfalten können. Je mehr vorgegeben ist, desto weniger Tokens werden verbraucht, desto einheitlicher wird das Projekt. Ein deterministischer Workflow wie uv init ist optimal, weil er immer gleich abläuft.

Zweitens: baue mit klaren Anweisungen – Agenten-Fähigkeiten oder Superkräfte – wie die Werkzeuge verwendet werden. Das bedeutet, dem Agenten CLI- und API-Dokumentationen bereitzustellen. Das ist der Hauptteil der Arbeit. Es geht um die Datenarchitektur, das Brainstorming mit Kollegen, bevor man etwas baut, damit man keine entscheidende Einsicht verpasst und den Agenten in die falsche Richtung laufen lässt. Ein Prompt wie „sei korrekt“ oder „verwende den neuesten Stand der Technik“ macht den Code nicht korrekter oder moderner, als das Modell trainiert wurde. Bei relativ neuen Architekturen muss man dem Agenten die entsprechenden Links und Hinweise geben.

Drittens: gestalte das Projekt modular, sodass die Agenten nicht das gesamte Projekt zerstören können, wenn sie eine kleine Änderung vornehmen. Kein Abhängigkeits-Chaos, bei dem alles von allem abhängt.

Viertens: verwende einen deklarativen Ansatz mit beschreibender Konfiguration, der das „Was“ und nicht das „Wie“ festlegt. So kannst du mit den Agenten an diesen Konfigurationen zusammenarbeiten, sie versionieren, leicht zurücksetzen oder ändern und die Implementierungslogik von der Geschäftslogik entkoppeln. Das Modell spielt eine geringere Rolle. Struktur und Workflow sind entscheidend. Plane ausgiebig, bevor du eine einzige Zeile schreibst, und korrigiere das Modell, bevor es in die falsche Richtung läuft. Ziel ist Nutzen aus der KI, nicht mehr Arbeit. Früher dachten die meisten Entwickler über das Problem nach. Heute ertrinken viele in Pull-Requests. Bessere KI-Werkzeuge können qualitativ hochwertigeren Code liefern, der weniger Überprüfung und weniger Iterationen erfordert – also weniger PRs und weniger Arbeit.

Die Korrektheitsschicht für Dateningenieure

KI-Agenten sollten den Menschen für Korrektheit unterstützen – oder eine Korrektheitsschicht. Statt mehr Arbeit zu verursachen, um mehr Code zu verifizieren, sollten wir Vertrauen in den Prozess haben und wissen, dass der produzierte Code verifiziert und korrekt ist. Eine deterministische Validierungsarchitektur ist dafür zentral. Der Artikel führt Altimate Code als Beispiel an. Dieses Tool teilt den Agenten in eine probabilistische Schicht oben und eine deterministische Rust/TS-Schicht unten auf, die die eigentlichen SQL-Operationen wie Parsen, Validieren und Äquivalenzprüfungen übernimmt. Der Agent selbst muss bei diesen Fragen nie vertraut werden.

Konkret: Der probabilistische Agent mit dem LLM übernimmt die kreative Arbeit – Intention lesen, Strategie wählen, SQL entwerfen, Ergebnisse zusammenfassen, sich von Fehlern erholen. Unter dieser Grenze liegt das deterministische Geschirr (deterministic harness), eine TypeScript-Schicht, die jeden Werkzeugaufruf abfängt. Ein Dispatcher prüft, ob ein nativer Handler existiert, und leitet den Aufruf entweder an einen nativen, deterministischen Handler oder zurück an das Modell. Diese Handler rufen die Logik nicht selbst auf, sondern ein deterministisches Core-Modul in Rust (altimate-core), das SQL-Operationen als reine Funktionen über ASTs und Schemata bereitstellt. Parsen, Validieren, Transpilieren, Query-Äquivalenz prüfen, Schema-Diffs, Column-Lineage extrahieren, Zeilen-Diffs über Data Warehouses hinweg – all das läuft sub-Millisekunde und liefert bei gleichem Input immer die gleiche Antwort. Wie ein Compiler: Der Agent entscheidet nie, ob zwei Queries äquivalent sind oder eine Spalte upstream existiert. Stattdessen ruft er eine Funktion auf, die es am geparsten AST und Schema beweist – so wie ein Type-Checker beweist, dass ein Programm kompiliert, anstatt zu raten.

Das macht die Ausgabe leichter überprüfbar: Faktische Prüfungen wurden ausgeführt, und die Ausgabe ist entweder korrekt, oder es gibt einen Bug, den der Agent direkt beheben kann. Den Rest kann ein Mensch verifizieren. Das Dilemma: Code wird schneller genehmigt, als geprüft werden kann. Dazu gibt es einen separaten Beitrag. Ein weiterer Faktor: Reiner Agenteneinsatz mag günstig erscheinen – aber nur, bis er falsch liegt. Dann sind die Kosten unbegrenzt.

Verbesserungen für eine bessere Token-Nutzung

Altimate Code oder ähnliche Agenten mit deterministischen Funktionen helfen, Tokens zu sparen und token-effizient zu arbeiten – das Gegenteil von Tokenmaxxing, einem Trend auf Social Media, bei dem möglichst viele Tokens verbraucht werden und Agenten rund um die Uhr laufen. In großen Unternehmen sind Token-Kosten ein echtes Budget-Thema. Ein einfacher Trick: Weist das Modell an, selbst weniger Tokens und Wörter zu verwenden – „Höhlenmensch-Stil“ ist ein Beispiel. Du kannst auch einen einzelnen Prompt in deine CLAUDE.md oder in Codex einfügen, in Kombination mit Altimate Code.

Es gibt einen zweiten, weniger offensichtlichen Kostenpunkt: Der Token selbst ist keine stabile Einheit. Als Anthropic Opus 4.7 auslieferte, kostete derselbe Prompt, der auf 4.6 X Tokens verbrauchte, auf 4.7 plötzlich etwa 1,4X – gleicher Input, gleiche Antwort, mehr Tokens, gleicher Preis pro Token. Der Artikel verweist auf einen Beitrag, der argumentiert, dass „Kosten pro Token“ die falsche Kennzahl sei, denn der Zähler selbst kann sich mit dem nächsten Modell-Update des Anbieters verschieben. Was wir stattdessen verfolgen sollten, sind Kosten pro Aufgabe. Deterministische Funktionsaufrufe umgehen diese Volatilität, indem sie für viele Aufgaben gar kein Modell und keine Tokens benötigen – das macht die Sache günstiger.

Typische Anwendungsfälle

Welche konkreten Einsatzmöglichkeiten gibt es für KI-Agenten in der Datentechnik? Die Liste ist lang. Du kannst sie nutzen, um dich oder dein Team weiterzubilden, produktive Datenpipelines zu bauen, Daten-Apps zu entwickeln und Daten auf innovative Weise zu visualisieren – meistens als HTML-Seiten mit React und anderen JavaScript-Frameworks. Die Anwendungsfälle lassen sich in verschiedene Ansätze gliedern: von der Unterstützung bei der Codeerstellung über die Automatisierung von Tests bis hin zur Generierung von Dokumentation. Der entscheidende Punkt bleibt: Ohne eine Korrektheitsschicht und eine durchdachte Projektstruktur wirst du auf Dauer keine verlässlichen Ergebnisse erzielen. Die Werkzeuge sind da, aber du musst wissen, wie du sie einsetzt.

Was bedeutet das für den Dateningenieuralltag? Vertraue nicht blind, sondern baue eine deterministische Validierung ein. So werden KI-Agenten von einer Blackbox zu einem verlässlichen Partner. Je besser die Werkzeuge, desto unabhängiger wirst du von jedem einzelnen Modell. Der deterministische Rahmen – die Korrektheitsschicht – ermöglicht es, Ergebnisse zu reproduzieren und ihre Herkunft nachzuverfolgen, unabhängig vom Modell. Das gilt besonders bei Wartungsarbeiten oder Erweiterungen, bei denen die Überprüfung die eigentliche Arbeit ist. Die Gefahr liegt nicht im Absturz, sondern in einer falschen Zahl, die nicht auffällt. Es mag eine saubere Query sein, aber sie führt zu doppelten Zeilen. Mit der richtigen Architektur kannst du solche stillen Fehler eliminieren. Hier liegt der Schwerpunkt: menschliche Expertise, Projektstruktur und Korrektheitsschicht machen den Unterschied.

Quelle: ssp.sh

Ein hochbegabter Mitarbeiter hat brillante Ideen, aber keinen Schreibtisch, keine Werkzeuge, keine klaren Anweisungen. Er scheitert an seiner Arbeitsumgebung, nicht an seiner Intelligenz. Diese Erkenntnis treibt einen Forschungszweig: Harness Engineering. Es geht nicht mehr nur um ein schlaues Modell, sondern um die Bühne, auf der es seine Fähigkeiten entfaltet.

Das Prinzip ist alltäglich. Jedes komplexe System braucht eine Hülle. Ein Betriebssystem verwaltet Hardware, eine IDE hilft beim Codieren, gutes Projektmanagement verhindert Chaos. In der KI heißt diese Hülle Harness – das Gerüst, das Modellen erlaubt zu planen, Werkzeuge zu nutzen, sich zu erinnern, Ergebnisse zu prüfen. Ohne dieses Gerüst bleibt selbst das beste Modell ein Denker ohne Hände.

Die Wiederentdeckung einer alten Idee

Die Vision einer sich selbst verbessernden Maschine ist nicht neu. Bereits 1965 skizzierte I. J. Good die ultraintelligente Maschine. Eliezer Yudkowsky prägte 2008 den Begriff der rekursiven Selbstverbesserung (RSI). Lange dachte man, RSI geschehe durch Umschreiben der eigenen Gewichte. Die aktuelle Forschung zeigt einen pragmatischeren Weg: Ein Modell verbessert seine Trainingspipeline und die Einsatzumgebung – also den Harness. Die Schnelligkeit, mit der KI-Labore wie Anthropic oder OpenAI Durchbrüche erzielen, spricht dafür: Die Optimierung des Gesamtsystems ist mindestens so wichtig wie rohe Rechenleistung.

Drei architektonische Muster für den idealen Harness

Die erste Lektion aus der Praxis: Ein Harness muss einfach und generisch sein. Ein Betriebssystem verbirgt Hardware hinter einer Schnittstelle – das soll auch ein Harness leisten. Drei Muster haben sich herauskristallisiert.

1. Automatisierung des Arbeitsablaufs. Der Kern jedes agentischen Systems ist ein Kreislauf: Modell plant eine Aktion, führt sie aus, beobachtet das Ergebnis, bewertet es, iteriert. André Karpathys öffentliches Repository „autoresearch“ zeigt einen eleganten Loop. Das Modell startet mit einer Aufgabe, generiert einen Plan, führt Experimente durch, analysiert Fehler und wiederholt den Prozess – ohne menschlichen Eingriff. Der Workflow steckt nicht in einer statischen Prompt-Vorlage, sondern existiert als dynamische Laufzeitumgebung, die das Modell selbst steuert.

2. Das Dateisystem als persistentes Gedächtnis. Ein Problem bei längeren Agenten-Einsätzen: Der Kontext wächst schnell über das Fenster hinaus, das das Modell verarbeiten kann. Die Lösung: Der Harness speichert Zustände in Dateien, auf die das Modell mit Bash-Befehlen wie grep oder cat zugreift. Das klingt banal, nutzt aber die Stärke moderner Sprachmodelle, die mit Dateisystemen umgehen können. Statt alles in den Kontext zu stopfen, managt der Harness Informationen wie ein Betriebssystem: auslagern, bei Bedarf laden, in überschaubaren Portionen präsentieren.

3. Sub-Agenten und Hintergrund-Jobs. Manchmal muss ein Hauptagent mehrere Hypothesen gleichzeitig prüfen. Ein guter Harness erlaubt, Tochteragenten zu starten, ihnen isolierte Aufgaben zu geben und Ergebnisse später einzusammeln. Die parallelen Arbeiten verschwinden nicht im Chat-Kontext, sondern bleiben als Dateien, Logs und Statusberichte persistent. So kann der Hauptagent auch nach einem Crash seinen Fortschritt rekonstruieren – eine Eigenschaft, die man von jedem soliden Betriebssystem erwartet.

Der Coding-Agent als Blaupause

Die konkreteste Anwendung dieser Muster sind Coding Agents wie Claude Code, Codex oder OpenCode. Sie arbeiten in einer Schleife: Sie lesen und bearbeiten Dateien, führen Bash-Befehle aus, verwenden Git und durchsuchen bei Bedarf das Web. Die Werkzeuge ähneln denen eines menschlichen Entwicklers: Editor, Terminal, Debugger, Patch-Erstellung. Der Harness stellt sie konsistent und kontrolliert bereit. Interessant ist die Standardisierung der Schnittstellen in den letzten Monaten. Die Toolgruppen sind fast überall gleich: Dateisystem-Operationen, Shell-Kommandos, Sprachserver-Funktionen, Git-Tools, Webzugriff und ein Mechanismus zum Starten und Verwalten von Sub-Agenten. Diese Standardisierung erlaubt, die Harness-Architektur unabhängig vom konkreten Modell zu verbessern – ähnlich wie Betriebssysteme von der Hardware abstrahieren.

Die Optimierung des Optimierers: Context Engineering

Je intelligenter die Modelle werden, desto wichtiger wird die Kunst, den Kontext zu gestalten. Einfach alle bisherigen Interaktionen aneinanderzureihen, funktioniert nur bis zu einer bestimmten Länge. Forscher sprechen von Context Engineering – dem gezielten Aufbereiten des Kontexts als ein sich entwickelndes Handbuch, nicht als endloses Prompt-Scrollen. Ein vielversprechender Ansatz heißt Agentic Context Engineering (ACE), entwickelt von Zhang und Kollegen 2025. ACE zerlegt die Aufgabe in drei Rollen: Ein Generator produziert Handlungsstränge, ein Reflector destilliert Erkenntnisse aus Erfolgen und Misserfolgen, und ein Curator aktualisiert den Kontext in strukturierten, nummerierten Bullet Points – schrittweise, dedupliziert, priorisiert. Das verhindert, dass das Modell den Faden verliert. ACE ist ein erster Schritt Richtung selbstverwaltendes Gedächtnis, aber die Update-Regeln sind noch von Menschen vorgegeben.

Der nächste Schritt heißt Meta Context Engineering (MCE), vorgestellt von Ye und Kollegen 2026. Hier wird nicht nur der konkrete Kontext optimiert, sondern die Methode, wie dieser Kontext erzeugt wird. Ein MCE-System lernt Skills – kleine Programme, die festlegen, welche statischen Komponenten und dynamischen Operatoren verwendet werden. In einer zweistufigen Optimierung sucht die innere Schleife den besten Kontext für eine Aufgabe, die äußere den besten Skill für eine ganze Aufgabenklasse. Das Ergebnis ist keine starre Regel, sondern eine sich selbst verbessernde Kontextfabrik – ein Schritt zur rekursiven Selbstverbesserung.

Die Meta-Ebene: Wenn der Harness sich selbst optimiert

Der radikalste Ansatz kommt von Lee und Kollegen 2026 mit dem Meta-Harness. Hier wird der gesamte Code des Harness zum Optimierungsziel. Ein Meta-Harness ist ein Werkzeug, das bessere Werkzeuge baut. Ein Coding-Agent bekommt die Aufgabe, einen neuen, besseren Harness für eine bestimmte Aufgabe zu entwickeln. Er startet Experimente, analysiert die Ergebnisse und generiert Code für neue Harness-Kandidaten. Die Ausführungshistorie bleibt im Dateisystem zugänglich, sodass der Agent mit Grep und Cat darauf zugreifen kann. Die Ausgabe ist eine Pareto-Front von Harness-Kandidaten mit unterschiedlichen Kompromissen zwischen Effizienz, Skalierbarkeit und Genauigkeit. Das zeigt eine klare Entwicklungslinie: Zuerst optimierten wir die Prompts, dann den Workflow, dann den Harness, dann den Optimierer. Mit jeder Ebene wird das System flexibler und passt sich an neue Anforderungen an, ohne dass ein Mensch jede Schraube neu justieren muss.

Was bedeutet das für die Zukunft?

Der Autor des Artikels zeichnet ein nüchternes Bild: Harness Engineering wird den Pfad zur rekursiven Selbstverbesserung in den nächsten Jahren wahrscheinlich stärker prägen als direkte Änderungen am Modell selbst. Das Modell, das seine eigenen Gewichte umschreibt, bleibt eine Vision. Der praktische Weg führt über die Optimierung der Umgebung: bessere Schleifen, schlauere Kontextverwaltung, selbstlernende Werkzeuge. Vorsicht vor Übertreibungen. Viele der heutigen Harness-Kniffe werden mit der Zeit in das Kernverhalten der Modelle einfließen – so wie frühere Prompt-Tricks durch verbessertes Instruction Tuning überflüssig wurden. Der Bedarf an einer Schnittstelle zur Außenwelt und an einem strukturierten Gedächtnis bleibt jedoch bestehen. Harness Engineering ist eine Brücke. Sie erlaubt, die wachsende Intelligenz der Modelle in geordnete Bahnen zu lenken, sie zu prüfen, zu korrigieren und zu skalieren – ohne den Überblick zu verlieren. Das ist handfeste Ingenieursarbeit, die gerade jetzt in den Laboren Gestalt annimmt.

Für Anwender: Die Werkzeuge von morgen sind heute als Entwürfe sichtbar. Wer versteht, wie ein Coding-Agent seinen Harness nutzt, versteht auch, warum manche KI-Ergebnisse brillant sind und andere scheitern. Nicht allein die Intelligenz des Modells zählt, sondern die Umgebung, in der es arbeitet. Diese Umgebung können wir gestalten.

Quelle: lilianweng.github.io

Du hast ein Kommandozeilen-Tool entwickelt, das die tägliche Arbeit erleichtert. Jemand schlägt vor, die Eingabe für KI-Agenten zu optimieren – alles in einen einzigen --json-Block packen, weil Maschinen strukturierte Daten lieben. Klingt plausibel. Waldek Mastykarz, Principal Developer Advocate bei Microsoft, hat diese Annahme getestet. Er wollte wissen, ob der Wechsel von klassischen Argumenten zu JSON wirklich Vorteile bringt. Das Messergebnis ist eindeutig – und überrascht viele.

Der Ansatz hinter JSON

Die Argumentation der Befürworter ist nachvollziehbar: KI-Agenten denken in hierarchischen Strukturen. JSON bildet tiefe Verschachtelungen natürlich ab, während flache Argumente mit mehrfach auftretenden Flags wie --service-name schnell mehrdeutig werden. Der Agent muss mühsam lernen, welcher Wert zu welchem Block gehört. Ein einzelner JSON-Payload verspricht klare Hierarchien: Jedes Service-Objekt steht für sich, Ressourcen sind logisch gruppiert – kein Ratespiel. So elegant die Theorie klingt, die Praxis zeigt etwas anderes.

Waldek Mastykarz hat ein Experiment entworfen, um die Behauptung zu prüfen. Er baute ein synthetisches CLI namens podctl, das ein komplexes Multi-Service-Deployment erzeugt – mit zwei Diensten, drei Verschachtelungsebenen, Arrays, gemischten Typen und Querverweisen. Insgesamt über 30 Einzelwerte. Eine Version des CLIs akzeptiert nur traditionelle Argumente (Flags), die andere nur einen --json-Payload. Beide nutzen denselben Validierungs-Backend und normalisieren zur gleichen kanonischen Struktur. Der Agent kennt das Tool nicht und muss es über die Hilfe entdecken. Fünf gängige Modelle wurden jeweils fünfmal pro Eingabemodus getestet – von Claude Haiku 4.5 bis GPT-5.3-Codex, mit GitHub Copilot Chat als Rahmen.

Die Ergebnisse: Args gewinnen durchgehend

Jedes Modell erreichte mit den klassischen Argumenten eine perfekte Korrektheit in allen fünf Läufen. Selbst das kleinste Modell, Claude Haiku 4.5, erzeugte zuverlässig korrekte Deployments. Bei der JSON-Variante sah es anders aus: Die drei stärksten Modelle hielten mit 5/5 mit, aber die beiden kleineren Modelle fielen ab. Haiku 4.5 schaffte nur 2 von 5 korrekten Aufgaben, MAI-Code-1-Flash immerhin 3 von 5. Argumente begrenzen den Eingaberaum so stark, dass auch schwächere Modelle konsistent korrekte Ausgaben liefern. JSON zwingt das Modell, seine eigene Struktur zu verwalten – eine Fähigkeit, die nicht jedes Modell beherrscht. Der Unterschied liegt in den Randbedingungen beim Generieren.

Noch deutlicher fällt der Kostenvergleich aus. Entwickler bezahlen für Token, nicht für Versuche. Waldek Mastykarz hat den Token-Verbrauch pro Aufgabe detailliert aufgeschlüsselt – Input, gecachte und Output-Token – und mit den Preisen der GitHub-Modelle multipliziert. Das Ergebnis: JSON-Modus kostete 4- bis 11-mal mehr pro Aufgabe als der Args-Modus – je nach Modell. Der rohe Token-Abstand war noch größer (4- bis 14-mal), aber Caching mildert die Wirkung etwas. Caching hilft nicht bei den Output-Token. Bei JSON führt das zu vielen Neuversuchen. Liest das CLI die JSON-Struktur nicht, analysiert der Agent den Fehler, baut einen neuen Payload und startet einen neuen Versuch. Diese Versuche werden kreativ: Piping durch Variablen, Schreiben in temporäre Dateien, verschiedene Escaping-Strategien. All das sind Output-Token – die teuerste Kategorie.

Das Problem mit Shell-Escaping

Die reinen Tokenkosten sind nicht alles. Ein oft übersehener Faktor beim JSON-Umstieg ist das Shell-Escaping. Wenn der Agent einen JSON-Payload auf der Kommandozeile übergibt, muss er die Anführungszeichen für die Shell maskieren. Verschiedene Shells haben unterschiedliche Regeln für verschachtelte Strings, keine ist trivial. Die Modelle produzierten regelmäßig valides JSON, das dann an der Shell scheiterte: doppelte Anführungszeichen in einfachen Anführungszeichen, Escaping, das die Shell anders interpretierte als beabsichtigt. Die Fehler von Haiku 4.5 bei JSON zeigen das Problem besonders deutlich: Drei von fünf Aufrufen erreichten nie eine erfolgreiche Ausführung. Der Agent erzeugte korrekte JSON-Inhalte, kam aber nicht durch die Shell. Er versuchte Base64-Kodierung, Piping, Here-Strings, cmd.exe-Durchleitung – alles vergebens. Die Token wurden verbrannt, ohne dass je ein gültiger Befehl zustande kam.

Um den Einfluss der Shell zu prüfen, führte Waldek Mastykarz denselben Test mit Claude Sonnet 4.6 auf macOS durch, wo standardmäßig Bash läuft. Auf PowerShell betrug der Kostenunterschied zwischen Args und JSON das 9-Fache. Auf Bash schrumpfte er auf das 1,5-Fache. Gleiches Modell, gleicher Payload, gleiche Korrektheit. Der Unterschied lag allein in der Art, wie jede Shell mit zitierten JSON-Strings umgeht. Args verhielten sich stabil über beide Shells hinweg: 0,05 $ auf PowerShell vs. 0,07 $ auf Bash. JSON führt eine Abhängigkeit vom Shell-Zitierverhalten ein, die je nach Umgebung stark variiert. Argumente tun das nicht.

Warum Einschränkungen dem Agenten helfen

Die Daten zeigen einen kognitiven Effekt von Einschränkungen. Bei Args legt der Hilfetext fest, welche Eingaben gültig sind. Jede Option hat einen Namen und einen Typ, manchmal eine Aufzählung erlaubter Werte. Das Modell muss von der Aufgabenbeschreibung auf konkrete Optionsnamen und Werte abbilden. Bei JSON erhält das Modell ein Schema (oder leitet es aus der Hilfe ab) und muss ein freies Objekt konstruieren, das diesem Schema genügt. Die Syntax muss gültig sein, die Verschachtelung korrekt, die Feldnamen und Typen müssen passen – und das Ganze muss das Shell-Escaping überleben. Jeder Punkt ist eine Fehlerquelle. Args vermeiden diese Fehlerquellen von vornherein. Stärkere Modelle lösen die JSON-Aufgabe irgendwann, aber mit Aufwand: Sie leisten sich Shell-Fehler, die sie dann reparieren müssen. Diese Reparatur kostet 4- bis 11-mal mehr als der Args-Pfad, selbst wenn die endgültige Korrektheit identisch ist. Kleinere Modelle scheitern an denselben Hürden und können sie nicht überwinden – dort sinkt die Korrektheit drastisch.

Die Einschränkung des gültigen Eingaberaums gleicht Modellschwächen aus. Das Modell muss kein korrekt verschachteltes JSON erzeugen, weil es gar kein JSON gibt. Es muss keine Shell-Zitierung beherrschen, weil die Argumente ohne Zitierung auskommen. Der kognitive Aufwand sinkt auf das Wesentliche: die Zuordnung von Werten zu Parametern. Selbst die kleinsten getesteten Modelle lösen das zuverlässig.

Was das für dein CLI bedeutet

Wenn du ein CLI baust, das auch von KI-Agenten verwendet werden soll, weisen die Daten in eine klare Richtung: Ersetze deine Argumente nicht durch einen --json-Payload. Behalte die klassischen Args. Sie funktionieren über das gesamte Modellspektrum hinweg, haben keine umgebungsabhängigen Fehlermodi und kosten weniger Token – und damit weniger Geld. Du darfst zusätzlich eine --json-Option anbieten, etwa für programmatische Batch-Aufrufe oder manuelle Nutzung. Aber entferne die Args nicht zugunsten von JSON, und erwarte nicht, dass JSON die Agentenerfahrung verbessert. In diesem Experiment hat JSON die Korrektheit nie erhöht und die Kosten immer gesteigert.

Die intuitive Annahme, dass JSON die Arbeit von Agenten erleichtert, ist auf dem Papier nachvollziehbar. In der Realität – mit tatsächlichen Modellen, die in tatsächlichen Shells auf tatsächlichen Betriebssystemen laufen – hält sie nicht stand. Args sind eingeschränkt und vorhersagbar über Shells hinweg. JSON ist ausdrucksstark, aber zerbrechlich. Für den agentengesteuerten CLI-Einsatz gewinnt das Eingeschränkte.

Waldek Mastykarz gibt eine praktische Empfehlung: Bevor du eine solche Änderung vornimmst, miss nach. Wähle ein Szenario, definiere Bewertungskriterien, wähle das für deine Zielgruppe relevante Modell und Betriebssystem, und führe ein paar Durchläufe mit beiden Ansätzen durch. Nach einem Tag hast du eine Antwort, ohne etwas umschreiben zu müssen, das du gar nicht umschreiben musstest. Die Lektion: Plausible Annahmen und gemessene Ergebnisse sind zwei verschiedene Dinge. Wenn sie auseinanderklaffen, haben die Ergebnisse recht.

Du musst dein bewährtes CLI nicht für Agenten umkrempeln. Es ist gut genug. Wenn du Zweifel hast, mach den Test. Die Antwort wird dich beruhigen – und dein Budget freut sich auch.

Quelle: developer.microsoft.com