Kategorie: Einblicke

Ein KI-Agent fragt einen MCP-Server nach Design-Referenzen für eine Website. Sekunden später liefert der Server passende Screens aus einer Datenbank mit über 257.000 Bildschirmaufnahmen. Das ist kein Zufall. Dahinter steckt eine Wachstumsstrategie, die sich gezielt an KI-Agenten richtet.

Ali Abouelatta hat das mit seinem Projekt Lazyweb umgesetzt. In einem Substack-Post beschreibt er die Höhen und Tiefen: 50.000 Anmeldungen, kein Marketingbudget, ein paar Monate. Wichtig zur Einordnung: Alle Zahlen sind Eigenangaben des Gründers über sein eigenes Produkt, von unabhängiger Seite überprüft sind sie nicht. Aufschlussreich ist seine Bilanz trotzdem – sie zeigt, welche Taktiken funktionieren, wo es hakt und was das für Produkte rund um KI-Agenten bedeutet.

Lazyweb: Von null auf 50.000 Anmeldungen

Lazyweb ist eine Plattform, die KI-Agenten Zugang zu einer Datenbank mit App- und Webdesign-Screens bietet. Über einen MCP-Server können Modelle wie Claude oder Codex direkt auf die Daten zugreifen. MCP steht für Model Context Protocol, ein Standard, der KI-Modellen erlaubt, externe Werkzeuge und Datenquellen einzubeziehen. Für Agenten ist das eine zusätzliche Quelle für Designwissen.

Abouelatta hat das Projekt in wenigen Monaten auf 50.000 Anmeldungen gebracht – ohne bezahltes Marketing. Er probierte viele Vertriebskanäle und Growth-Taktiken aus. Die meisten scheiterten. Einige funktionierten, wenige trugen stark. Seine Bilanz: Man braucht viele Experimente. Greift einer, trägt er das Produkt nach vorne.

Lazyweb setzt nicht auf klassische Marketingversprechen. Keine Werbekampagnen, keine Anzeigen, keine generischen Spam-Listen. Das Projekt will für KI-Agenten nützlich sein. Das zahlt sich aus, wenn man den Zahlen des Gründers folgt.

Was Lazyweb wachsen ließ

Der erste große Schub kam vom Launch-Post auf X. Abouelatta erklärte darin, warum er Lazyweb gebaut hat: Er war frustriert darüber, wie schlecht KI-Agenten bei Design sind, und Codex hatte keinen Zugriff auf Mobbin. Die persönliche Geschichte erreichte mehr als 365.000 Aufrufe. Sie brachte Nutzer und Feedback. Der Post war ehrlich, konkret und zeigte ein echtes Problem. Genau das funktioniert in sozialen Netzwerken.

Ein weiterer Punkt war die automatische Weiterleitung in der agents.md-Datei. Viele KI-Tools lesen diese Datei, um ein Projekt zu verstehen. Abouelatta baute eine Route ein, die KI-Agenten automatisch zum MCP-Server von Lazyweb führt. Die täglich aktiven Nutzer verdoppelten sich. Solche Anpassungen zeigen: Wer Agenten erreichen will, muss die Infrastruktur für sie optimieren, nicht nur die Oberfläche für Menschen.

Das Onboarding wurde einfacher. Zuerst war eine E-Mail-Registrierung nötig. Abouelatta erlaubte Gastkonten für Agenten. Die Aktivierungsrate stieg um mehr als 50 Prozent. Dann kam die Installation per Einzeiler-Befehl. Statt langer Anleitungen reichte ein Befehl, um den MCP-Server einzusetzen. Das brachte weitere 20 Prozent mehr Aktivierungen.

Für menschliche Nutzer entstand ein Playground. Dort lässt sich die Datenbank ausprobieren, bevor man sie mit einem Agenten verbindet. Dieser spielerische Zugang erhöhte die MCP-Aktivierung um 40 Prozent. Der Playground zeigt sofort den Nutzen. Das Muster kannst du übernehmen: erst Wert zeigen, dann Bindung verlangen.

Nicht jeder funktionierende Hebel blieb dauerhaft im Einsatz. Der freie Datenzugang über die Web-App trieb das Wachstum deutlich an, zog aber Scraper und DDoS-Angriffe an und wurde zum Zeitfresser – Abouelatta schaltete ihn wieder ab. Teuer ist der Betrieb trotzdem nicht: Weil die Nutzer die Rechenkosten ihrer Agenten selbst tragen und Lazyweb nur Skills und Daten bereitstellt, beziffert er seine laufenden Kosten auf wenige hundert Dollar im Monat.

Experimente, die nicht funktionierten

Auf der anderen Seite steht eine Liste von Ideen, die keine relevanten Metriken bewegten. Dazu gehört das Spiel „Grow/No Grow“, mit dem Abouelatta die Intuition von Produktleuten testen wollte. Es machte Spaß und wurde auf Product Hunt vorgestellt, aber für Lazyweb blieb die Wirkung aus. Ähnlich erging es dem Skill „/explain-PR“, der Pull-Requests verständlich erklären sollte, und „/code-map“, einem Tool zur Visualisierung der Code-Architektur, das sein Mitstreiter Francesco baute. Beides war nützlich, führte aber nicht zu mehr Anmeldungen.

Die Wiederbelebung der Million-Dollar-Homepage war ein Fehlschlag. Die Idee, bei der Nutzer kleine Werbeflächen auf einer Seite kaufen, zündete nicht. Abouelatta erwähnt, dass ein ähnliches Projekt später aus dem Boden schoss, aber da hatte er schon zu viele Narben aus früheren Versuchen. In Facebook-Gruppen versuchte er, sich einzuschleusen, wurde aber schnell enttarnt. Reddit war gemischt: Aus einigen Threads flog er, nach dem viralen Post redete die Community von selbst über Lazyweb.

Abouelatta macht den Fehlschlägen keinen Vorwurf. Sie hätten Spaß gemacht, sagt er, und man lerne aus ihnen. Wachstum ist kein linearer Prozess. Es ist Probieren, Messen, Verwerfen.

Das Grundprinzip: KI-Agenten besser machen

Hinter den erfolgreichen Taktiken steckt eine einfache Erkenntnis: Wer im KI-Zeitalter wachsen will, muss dafür sorgen, dass die großen Modelle besser werden. OpenAI und Gemini optimieren ihre Agenten auf Qualität, Geschwindigkeit und Kosten. Wenn dein Produkt diese Ziele unterstützt, wirst du automatisch relevant. Spam-Listen wie „Die 9 besten KI-Kundenservice-Agenten 2026“ funktionieren nicht. Die Labore sind nicht auf Anzeigen angewiesen, sondern auf zuverlässige Agenten.

Abouelatta hat das nicht sofort verstanden. Er war auf die Muster geeicht, die schon früher funktionierten: Reddit-Roundups, Versus-Seiten ohne eigenes Produkt, eigene Daten zu Research-Beiträgen aufbereiten. Bemerkenswert daran: Diese klassischen Taktiken zündeten auch bei Lazyweb. Andere Umbauten wie das Umwandeln von Hyperlinks in Zitate oder .md-Versionen der Blogposts blieben dagegen ohne messbaren Effekt. Der Wendepunkt kam mit der Einsicht, dass die KI selbst die Zielgruppe ist. Nutzt ein Modell Lazyweb, um bessere Antworten zu geben, ist das die beste Werbung.

Dazu gehört eine Haltung aus der Open-Source-Welt: keine Angst davor, dass jemand die Idee stiehlt oder die Daten missbraucht. Die meisten Menschen sind zu bequem, eigene Dienste aufzubauen, sagt Abouelatta. Bietest du einen freien Skill oder einen offenen MCP-Server an, wird er genutzt. Das schafft Reichweite und Netzwerkeffekte, die mit Geld schwer zu erkaufen sind.

Viele überschätzen den Schutz ihrer Inhalte. Der größte Wert liegt in der Verbreitung. Hilfst du KI-Agenten, besser zu werden, bekommst du etwas zurück.

Lehren für dein KI-Produkt

Was bleibt von Lazyweb? Biete einen MCP-Server an, damit Agenten direkt auf deine Daten zugreifen können. So kommst du in den Workflow von KI-Modellen. Reduziere Reibung. Gastkonten, Einzeiler-Installationen und ein Playground sind keine Extras, sondern Grundlagen für Aktivierung.

Denke in Formaten, die Maschinen verstehen. Eine agents.md-Datei, ein offener MCP-Server für die eigenen Inhalte, strukturierte Daten – das macht es Agenten leicht, dich zu finden und zu empfehlen. Sei präsent, aber nicht aufdringlich. Antworte auf relevante Threads auf X, teile deine Erfahrungen und hilf anderen. Spam vermeiden. Solche Beiträge haben vielleicht weniger Reichweite, aber die Conversion kann hoch sein. Abouelatta berichtet von Klickraten im Bereich von 20 Prozent.

Und: Akzeptiere, dass viele Experimente scheitern. Abouelatta hat rund ein halbes Dutzend Ideen ausprobiert, die keine Metriken bewegten. Ein virales Ereignis hat dann alles verändert. Der Weg zu 50.000 Nutzern war kein Zufall, sondern ein Prozess – mit vielen Irrwegen und wenigen Abzweigungen, die etwas brachten.

Abouelatta will beim nächsten Meilenstein, 100.000 Anmeldungen, wieder berichten. Bis dahin gilt: Wenn dein KI-Produkt wachsen soll, mach die KI besser.

Quelle: read.first1000.co

Wer einen DNS-Resolver betreibt, denkt meist zuerst an Geschwindigkeit, selten an Speicherverbrauch. Dabei entscheidet gerade der über die Rechnung: Bei 250 Milliarden gespeicherten Einträgen kostet jedes eingesparte Byte pro Eintrag in der gesamten Flotte mehr als 250 Gigabyte RAM. Cloudflare hat in einem technischen Beitrag beschrieben, wie fünf aufeinanderfolgende Änderungen an der Speicherstruktur des Caches von Big Pineapple, der Plattform hinter 1.1.1.1, den Speicherbedarf pro Eintrag um über 50 Prozent senkten. Am Ende standen rund 100 Terabyte freigewordener Arbeitsspeicher, was dem RAM von 130 Servern der aktuellen Generation entspricht. Der Cache wurde dabei schneller: Die Schreibgeschwindigkeit stieg um 43 Prozent, die Leselatenz sank um 19 Prozent.

Um zu verstehen, warum solche Optimierungen nötig sind, lohnt ein Blick darauf, was der Cache speichert. Bei jedem Start ist Big Pineapple leer. Mit jeder hereinkommenden DNS-Anfrage füllt er sich, bis eine maximale Anzahl an Einträgen erreicht ist. Danach werden ältere oder selten genutzte Einträge verdrängt. Die genaue Größe variiert je nach Rechenzentrum. Kommt EDNS Client Subnet zum Einsatz, liefern autoritative Server je nach Netzwerk des Anfragenden unterschiedliche Antworten, weshalb mehrere Varianten derselben Anfrage parallel im Cache liegen können. Das erhöht sowohl die Anzahl der Einträge als auch den Speicherverbrauch pro Eintrag.

Was ein Cache-Eintrag enthält

Ein Eintrag besteht aus zwei Teilen: einem Schlüssel, der beschreibt, was angefragt wurde, und einem Wert, der die eigentliche DNS-Antwort enthält. Im Wert stecken die Antwort-, Authority- und Additional-Sektion, ergänzt um Metadaten wie Erstellzeitpunkt, einen Trefferzähler und die Time-to-Live. Beide Strukturen boten reichlich Raum für Verbesserungen, denn mehrere Felder nutzten Typen, deren eingebauter Overhead nach dem Speichern keinen Nutzen mehr hat.

Um die Wirkung jeder Änderung messen zu können, baute das Team einen Benchmark, der den Cache mit zufällig erzeugten Einträgen füllt. Die Verteilung entspricht in etwa der Produktion: 56 Prozent A-Records, 25 Prozent AAAA-Records und 19 Prozent TXT-Records. Jeder Eintrag enthält zwischen einem und vier Records. Ein eigener Allocator umschließt den System-Allocator von Rust und protokolliert Anzahl und Größe der Allokationen pro Cache-Eintrag. Neben dem Speicher werden Schreibdurchsatz und Leselatenz über den gesamten Cache-Pfad gemessen, damit Speicherersparnis nicht auf Kosten der Geschwindigkeit geht. Diese Werte bilden die Realität näherungsweise ab, ersetzen sie aber nicht. Der tatsächliche Prozessspeicher hängt auch vom Verkehrsmix, der Cache-Auslastung und der Arbeit außerhalb des Caches ab. Deshalb wurde zusätzlich der residente Speicher in der Produktion während des Rollouts gemessen.

Warum Vec mehr kostet als es sollte

In Rust ist Vec einer der am häufigsten genutzten Typen für dynamische Sammlungen. Intern speichert er drei Felder: einen Zeiger auf die heap-allokierten Daten, die aktuelle Länge und die Gesamtkapazität. Beim Anhängen eines Elements prüft Vec, ob die Länge die Kapazität überschreitet, und reserviert bei Bedarf neuen Speicher. Ist noch Platz, wird das Element einfach angefügt und der Zähler erhöht. Das ist praktisch, aber für einen DNS-Cache suboptimal. Sobald eine DNS-Antwort im Cache liegt, wird sie nie wieder verändert. Das Kapazitätsfeld hat keinen Zweck mehr, kostet aber acht Byte pro Vec. Dazu kommt der bereits reservierte, aber ungenutzte Heap-Bereich, etwa wenn ein Vec Platz für acht Elemente hält, aber nur fünf davon befüllt sind.

Die Lösung ist Box<[T]>, ein unveränderlicher Slice auf dem Heap. Er kann nach der Erstellung nicht mehr wachsen, braucht also weder Kapazitätsfeld noch Reserveplatz. Das gleiche Prinzip gilt für String, das ebenfalls eine Kapazität mitführt und sich durch Box<str> ersetzen lässt. Jeder Cache-Eintrag speichert acht Felder vom Typ Vec oder String. Der Austausch spart acht Byte pro Feld, also 64 Byte pro Eintrag. Hinzu kommt der eingesparte, brachliegende Heap-Speicher. Bei über 250 Milliarden Einträgen summiert sich das auf mehr als 15 Terabyte.

Weniger Listen, weniger Zeiger

Statt Antwort-, Authority- und Additional-Sektion als getrennte Listen zu speichern, fassten die Entwickler sie zu einer einzigen Liste zusammen und setzten Offsets, die auf den Anfang jeder Sektion verweisen. Da die Anzahl der Records pro Sektion in einen u16 passt, reichen 2-Byte-Offsets aus, verglichen mit 8 Byte Zeiger und 8 Byte Länge, die jede separate Box<[T]> mit sich bringt. Zwei Listen verschwinden, zwei 2-Byte-Offsets treten an deren Stelle, das spart 28 Byte pro Eintrag.

Die Ersparnis spiegelt sich allerdings nicht immer direkt in den Feldgrößen wider. Rust fügt Padding ein, um die Ausrichtung der Daten im Speicher zu gewährleisten, und rundet die Größe eines Structs auf ein Vielfaches seiner Ausrichtung auf. Wird ein kleines Feld entfernt, kann dadurch zusätzliches Padding wegfallen. Im konkreten Fall wurden mehrere boolesche Felder zu einem einzigen Bitflag zusammengefasst, was das umgebende Padding reduzierte und den Struct stärker schrumpfen ließ, als die reinen Boolean-Größen vermuten lassen.

Den Besitzer einsparen, wenn er ohnehin gleich ist

Jeder DNS-Record hat einen Besitzer, also die Domain, zu der er gehört. In vielen Fällen ist dieser Besitzer identisch mit der angefragten Domain. Eine Anfrage nach example.com A liefert zwei Records mit demselben Besitzer. Bei einem CNAME kann der Besitzer jedoch abweichen. Das DNS-Wire-Format löst wiederholte Besitzer per Name Compression auf, wie sie RFC 1035 definiert. Statt eine Domain zweimal zu kodieren, speichert jede weitere Stelle einen 2-Byte-Zeiger auf das erste Vorkommen. Für den Cache funktioniert das nicht direkt, weil das Verfolgen solcher Zeiger auf dem Hot Path zu teuer wäre. Also wird der vollständige Besitzername im Cache redundant mitgespeichert, was Speicher kostet.

Da die meisten Records denselben Besitzer haben wie die angefragte Domain, lässt sich das Feld in diesen Fällen komplett weglassen und beim Lesen aus dem Schlüssel rekonstruieren. Nur wenn der Besitzer abweicht, etwa bei A-Records hinter einem CNAME, wird der vollständige Name im Eintrag gehalten. Das bedeutet, dass der Record nicht mehr für sich allein stehen kann, aber der Schlüssel liegt bei jedem Lookup sowieso vor. Wenn der Besitzer fehlt, restauriert die Antwortkonstruktion die Domain aus dem Cache-Schlüssel und spart eine Heap-Allokation. Weicht der Besitzer ab, speichert Some einen Zeiger auf den vollständigen Namen. In der Praxis haben die meisten gecachten Records einen identischen Besitzer, sodass der überwiegende Teil keine Heap-Allokation für das Feld benötigt.

Wenn Enums größer werden als nötig

Rust-Enums sind Summentypen: Jede Variante kann unterschiedliche Daten tragen, aber das Enum ist immer so groß wie seine größte Variante. Option<T> ist entweder Some mit einem Wert oder None ohne Wert. Beide Varianten belegen denselben Speicher. Intern speichert das Enum ein Tag für die aktive Variante, gefolgt von genug Platz für die Daten der größten Variante. Ist die Variante None, bleibt dieser Platz ungenutzt. Für Record-Daten liegt es nahe, jeden DNS-Record-Typ als Enum-Variante abzubilden, aber genau das erzeugt Overhead. NAPTR ist im konkreten Fall die größte Variante mit 136 Byte, weil sie drei variabel lange Textfelder, einen Domainnamen und zwei Integer enthält. Mit Varianten-Tag und Padding landet das Enum bei 144 Byte. Ein A-Record braucht dagegen nur 4 Byte, ein AAAA-Record 16 Byte. Da A und AAAA zusammen über 80 Prozent des Verkehrs ausmachen, verschwenden die meisten Records über 120 Byte mit Padding.

Boxen, was groß wird

Die größeren Varianten des Enums zu boxen, verschiebt sie auf eine separate Heap-Allokation. Das Enum speichert dann einen 8-Byte-Zeiger auf den Heap, wo die Daten nur so viel Platz einnehmen, wie sie tatsächlich brauchen. Für A und AAAA spart das 120 Byte pro Record. Kleinere Varianten wie TXT und CNAME profitieren ebenfalls. Sie belegen weiterhin die 24 Byte des Enums, aber ihre Heap-Allokation ist auf die tatsächlichen Daten zugeschnitten statt auf 144 Byte gepolstert. NAPTR, die größte Variante, zahlt allerdings etwas drauf, weil ein Heap-Zeiger und der Allokationsoverhead hinzukommen. Da NAPTR-Records in der Praxis selten sind, lohnt sich der Kompromiss.

Was Boxen kostet

Boxen bringt zwei Kosten mit sich. Erstens den Allokator-Overhead. Jede geboxte Variante wird zu einer eigenen Heap-Allokation, und Allokatoren runden auf die nächste Größenklasse auf. Big Pineapple nutzt jemalloc, einen Allokator für mehrthreadige, allocationslastige Workloads. jemalloc gruppiert ähnlich große Allokationen in festen Größen-Bins. Ein TXT-Record möchte 32 Byte und passt exakt in eine 32-Byte-Bin, ohne Verschnitt. Ein MX-Record möchte 40 Byte und wird auf 48 aufgerundet, was 8 Byte verschwendet. Zweitens die schlechte Speicherlokalität. Ohne Boxen liegen die Record-Enums eines Cache-Eintrags in einer zusammenhängenden Allokation. Mit Boxen lebt jede Variante in einem eigenen Heap-Bereich. Um sie zu lesen, muss die CPU einem Zeiger folgen, und wenn der irgendwo weit entfernt liegt, muss eine neue Cache-Line geladen werden. Bei Millionen von Einträgen verteilen sich die geboxten Daten über den gesamten Heap statt kompakt beieinander zu liegen.

Records im Wire-Format speichern

Ein naheliegender nächster Schritt wäre, die komplette DNS-Antwort im Wire-Format zu speichern und bei jedem Lookup nur wenige feldspezifische Werte wie die Message-ID anzupassen. Das hat aber Nachteile. DNSSEC-Records werden nur ausgeliefert, wenn der Client das DO-Flag gesetzt hat. Eine komplette Wire-Format-Nachricht im Cache würde entweder zwei Varianten erzwingen, eine mit und eine ohne DNSSEC, oder DNSSEC-Records aus einer bereits gebauten Nachricht wieder herausfiltern. Dazu kommt der Aufwand, die komplette Nachricht bei jedem Lookup neu zu parsen, was die bisherige Enum-Variante mit bereits geparsten Records vermeidet.

Als Mittelweg speichert das Team nur die Record-Daten als rohe Bytes, während der Rest des Cache-Eintrags weiterhin aus strukturierten Feldern besteht. Statt einer Liste geparster Enum-Varianten liegen die Records jetzt in einer einzigen Box<[u8]>, in der jeder Record mit einem 2-Byte-Längenprefix versehen ist, gefolgt von seinen Rohdaten. Das beseitigt den Enum-Overhead pro Variante und die geboxten Heap-Allokationen aus dem vorherigen Schritt. Die Daten liegen kompakt hintereinander, was die CPU-Cache-Lokalität verbessert. Der Preis ist, dass Records nicht mehr direkt indizierbar sind, sondern sequenziell durchlaufen werden müssen. Das macht Funktionen wie die Round-Robin-Rotation von A- und AAAA-Records etwas aufwendiger, aber da die Record-Anzahl pro Eintrag klein ist, fällt das kaum ins Gewicht.

Beim Bau einer DNS-Antwort aus gecachten Records lassen sich die meisten Record-Typen direkt aus dem Buffer in die ausgehende Nachricht kopieren. Zuvor musste jeder geparste Record feldweise zurück ins Wire-Format serialisiert werden. Das neue Layout spart diesen Schritt für A, AAAA, TXT und sämtliche DNSSEC-Record-Typen, weil ihre kodierten Bytes unverändert übernommen werden. Nur Records mit Domainnamen wie CNAME, NS, MX und SOA müssen weiterhin geparst werden, um DNS Name Compression anzuwenden. Da Record-Typen, die direkt kopiert werden können, den Großteil des Verkehrs ausmachen, sinkt die Arbeit auf dem Lookup-Pfad. Zusammen mit der besseren Speicherlokalität reduzierte das die Lookup-Latenz im Benchmark um 5%. Um den Record-Buffer zu bauen, schreibt der Code in einen wiederverwendbaren Scratchspace-Buffer, der zwischen Cache-Inserts bestehen bleibt. Da ältere Schreibvorgänge ihn bereits vergrößert haben, ist eine Neuzuweisung selten nötig. Erst nachdem die Records im Scratchspace serialisiert sind, wird eine Box<[u8]> allokiert und die Daten per memcpy hineinkopiert. Das ersetzt die separate Allokation für jeden geboxten Record und sorgt dafür, dass am Ende nur eine einzige Allokation pro Eintrag nötig ist.

Was am Ende herauskam

Im Benchmark sank der Speicherbedarf pro Cache-Eintrag über die fünf Schritte von 953 auf 420 Byte, also um 56 Prozent; die Allokationen pro Eintrag gingen von 1,1 Kilobyte auf 461 Byte zurück. In der Produktion fallen die Werte kleiner aus, weil der residente Speicher eines Prozesses mehr umfasst als den Cache: Auf dem 99. Perzentil sank er je Instanz von 9,3 auf 5,3 Gigabyte, auf dem 90. Perzentil von 6,5 auf 3,8 Gigabyte. Über die gesamte Flotte summierte sich das nach dem Rollout auf rund 100 Terabyte. Der Schreibdurchsatz stieg von 625.000 auf 893.000 Einträge pro Sekunde, die Lookup-Latenz sank von 828 auf 670 Nanosekunden.

Den frei gewordenen Speicher will Cloudflare nicht einsparen, sondern in mehr Cache-Kapazität stecken: mehr Einträge bei gleichem Speicherverbrauch bedeuten eine höhere Trefferquote und weniger Anfragen an die vorgelagerten autoritativen Server. Weitere Optimierungen am Cache sind angekündigt.

Quelle: blog.cloudflare.com

Beim Umbau einer Testsuite von Enzyme zu React Testing Library erledigt ein KI-Modell in Minuten, wofür Entwickler früher Wochen brauchten. Asana, Airbnb und Uber haben das bereits dokumentiert. Wie diese Migrationen technisch ablaufen, welche Ergebnisse realistisch sind und was von den genannten Einsparungen übrig bleibt, zeigt der Blick auf die drei Fälle.

Fünf Jahre Arbeit in zwei Wochen: Die OpenAI-Fallstudie

OpenAI veröffentlichte eine Fallstudie. Asana, ein Anbieter von Projektmanagement-Software, habe mithilfe von OpenAI Codex ein veraltetes Testsystem in zwei Wochen entfernt. Die Kosten: rund 12.000 Dollar für Modell- und Infrastrukturaufwand. Der vorherige Plan sah vor, dass vier Ingenieure fünf Jahre an dieser Aufgabe arbeiten, geschätzt auf rund sechs Millionen Dollar. So soll Asana fast sechs Millionen Dollar eingespart haben.

Bei genauer Prüfung der Rechnung fallen Ungereimtheiten auf. Vier Ingenieure, fünf Jahre, bei einem angesetzten Jahresgehalt von rund 300.000 Dollar je Kopf — so kommen die sechs Millionen zustande. Gergely Orosz, der die Rechnung im Pragmatic Engineer nachgerechnet hat, hält sie für aufgeblasen. Interessanter als die Zahl ist ohnehin die Frage, wie eine solche Migration technisch abläuft.

Warum Enzyme und React Testing Library so unterschiedlich ticken

Die Migration von Enzyme zu React Testing Library ist kein einfaches Suchen und Ersetzen. Beide Frameworks verfolgen grundlegend verschiedene Ansätze beim Testen von React-Komponenten. Enzyme arbeitet auf der Komponenteninstanz; du kannst direkt auf Methoden und Zustände der Komponente zugreifen. Die React Testing Library rendert die Komponente und arbeitet auf dem Document Object Model, also der Struktur, die später im Browser ankommt. Das klingt nach einem Detail, hat aber erhebliche Auswirkungen auf den Testcode.

Ein einfaches Beispiel macht das deutlich: Ein Test, der prüft, ob ein Button einen Zähler erhöht, sieht in Enzyme völlig anders aus als in React Testing Library. Beim Vergleich der beiden Dateien haben sie nur die Imports gemeinsam. Der Rest unterscheidet sich in Syntax, Aufbau und Denkweise. Enzyme-Tests sind in der Regel näher an der Implementierung, während React-Testing-Library-Tests das Verhalten aus Nutzersicht prüfen. Deshalb müssen Entwickler nicht nur Code umschreiben, sondern auch ihre Teststrategie überdenken.

Diese konzeptionelle Differenz erklärt, warum eine manuelle Migration so lange dauert. Ein Tool, das nur die Syntax anpasst, scheitert hier schnell. Die Übersetzungsregeln müssen den Kontext verstehen: Wie ist der Test aufgebaut, was will er prüfen, wie drückt man das im neuen Framework aus? LLMs können über reine Textersetzung hinausgehen und semantische Äquivalenz herstellen.

Airbnb zeigt, wie LLM-Migration in der Praxis abläuft

Airbnb berichtete 2025 über eine Migrationsinitiative. Das Unternehmen migrierte mit Unterstützung von Large Language Models 3500 Komponententestdateien von Enzyme zu React Testing Library. Die manuelle Schätzung lag bei 1,5 Ingenieurjahren, tatsächlich brauchte das Team nur sechs Wochen. Entscheidend war ein mehrstufiger Prozess, den Airbnb für jede Datei durchlief.

Zunächst baute das Team Schleifen, die fehlgeschlagene Migrationen immer wieder neu anstießen. Nach der Optimierung dieser Schleifen schafften sie 75 Prozent der Dateien in vier Stunden. Die restlichen 25 Prozent waren komplexer; dafür bauten sie eine ausgefeiltere Refactoring-Pipeline. Am Ende waren 97 Prozent aller Tests migriert. Dieser Lauf dauerte mehrere Tage. Die verbleibenden 3 Prozent stellten Ingenieure in einer Woche fertig.

Das Datum ist relevant: Die Migration fand im März 2025 statt, damals war Claude 3.7 Sonnet das leistungsfähigste Codemodell. Die inzwischen verfügbaren Modelle wie GPT-5.6 Sol oder Claude Fable 5 sind deutlich besser. Deshalb ist es plausibel, dass Asana ein Jahr später nur zwei Wochen für eine ähnlich umfangreiche Migration brauchte. Die Struktur der Aufgabe ist gleich geblieben: Migrationen auslösen, validieren, Fehlversuche erneut anstoßen. Diese Verifikationsschleifen machen den Unterschied.

Im Gespräch mit Asana: Was die sechs Millionen Dollar wirklich bedeuten

Orosz sprach mit Dan Ubilla, der die Developer-Productivity-Gruppe bei Asana leitet, um die Zahlen einzuordnen. Ubilla ergänzte Details, die in der OpenAI-Fallstudie fehlen. Die Migration begann 2024, das Team hatte mehr als 4000 Enzyme-Dateien zu bearbeiten. Beim ersten Versuch mit LLMs migrierten sie etwa 25 Prozent der Dateien, vor allem die mit dem höchsten Nutzen. Der Rest war nicht dringend und wurde aufgeschoben.

Die oft genannten fünf Jahre sind also nicht als Vollzeitprojekt zu verstehen. Es war die geschätzte Dauer für eine Migration mit niedriger Priorität, die nebenher laufen sollte. Asana priorisierte nach Stufen wie kritisch, wichtig und opportunistisch. Enzyme war eine von vielen opportunistischen Aufgaben, die ohnehin hinten anstand. Mit dem LLM-Projekt wollte das Team zeigen, dass sich langwierige Migrationen stark verkürzen lassen, und nutzte genau diese ungeliebte Aufgabe als Testfall.

Und die sechs Millionen Dollar? Auch dazu hat Ubilla eine klare Antwort. Die Schätzung entstand auf klassische Art: Man schätzt, wie lange ein Ingenieur manuell für eine einzelne Datei braucht, multipliziert das mit der Anzahl der offenen Dateien und addiert den Aufwand für das Entfernen von Rahmenbedingungen wie Monitoring oder statische Analysen. Mit dem Stundensatz eines typischen Ingenieurs ergibt das die sechs Millionen. Diese Rechnung ignoriert den Lerneffekt bei vielen Wiederholungen und geht von null KI-Unterstützung aus. Orosz hält die Zahl deshalb für eine Überschätzung, aber sie dient als grober Anhaltspunkt, wie viel Arbeit in einem solchen Projekt steckt.

Uber, Bun und die neue Lust auf lästige Aufgaben

Asanas Erfolg steht nicht allein. Einige Monate zuvor berichtete Uber über eine massive JUnit-Migration mit KI: 600.000 Unit-Tests mit insgesamt 15 Millionen Zeilen Code von JUnit 4 auf JUnit 5. Zwei Ingenieure schafften das in vier Monaten; dabei wurden 1,25 Millionen Zeilen Code geändert. Ohne KI-Tools wäre das Vorhaben praktisch undurchführbar gewesen, weil es Jahre gedauert und alle Entwickler blockiert hätte.

Bei der Laufzeit Bun wurden 530.000 Zeilen von Zig zu Rust in zwei Wochen umgewandelt. Die API-Kosten dafür betrugen 165.000 Dollar. Diese Beispiele zeigen ein Muster: KI-gestützte Code-Migration funktioniert nicht ohne menschliche Planung, reduziert den Aufwand aber um Größenordnungen. Allen erfolgreichen Migrationen gemeinsam ist ein klar definierter Prozess mit Verifikationsschleifen und erfahrenen Ingenieuren.

Für dich als Entwickler bedeutet das vor allem Entlastung. Migrationsprojekte schoben bisher alle auf, weil sie monoton und zeitraubend sind. Mit KI-Assistenten schrumpft der langweilige Teil, der anspruchsvolle bleibt: Du musst verstehen, was der Code tut, und sicherstellen, dass die neuen Tests dasselbe Verhalten abdecken. Die Technik übernimmt das stupide Umschreiben, du steuerst die Richtung. Langwierige Migrationen werden damit zu einem planbaren Projekt, das in Wochen statt Jahren abgeschlossen werden kann. Die Fallstudien zeigen, dass die Werkzeuge funktionieren. Und du kannst endlich technische Schulden abbauen, die lange liegen geblieben sind.

Quelle: blog.pragmaticengineer.com

Ein Schwarm von KI-Agenten arbeitet gleichzeitig an einem gemeinsamen Wissensspeicher. Jeder Agent sucht, liest und schreibt Seiten, während andere dieselben Seiten bearbeiten. Das ist ein Nebenläufigkeitsproblem aus Datenbanksystemen – mit einem Unterschied: Die Arbeit der Agenten kostet Minuten an Rechenzeit und Dollar an Tokens.

Wer mit Coding-Agenten gearbeitet hat, kennt das Muster: Ein einzelner Agent wird von einem Menschen entlang eines Ziels geführt. Will man mehrere Aufgaben parallel bearbeiten, isoliert man die Agenten oft über Git-Worktrees. Die Konflikte holen einen beim Merge ein. Alle editieren denselben Zustand, nur mit aufgeschobenem Krach. Bei Code funktioniert das halbwegs, weil Code zeilenbasiert ist und Merge-Konflikte oft lokal bleiben. Bei natürlichsprachlichem Wissen, wie es in Wikis oder Wissensdatenbanken liegt, gilt das nicht. Prosa wird zusammengefasst, umgeschrieben, neu organisiert und verworfen. Ein früher Prototyp von Chromas Speicherschicht Foundation hat das versucht: Git für Konfliktlösung. Er hat mehr fertige Arbeit verworfen als jeder andere Ansatz – mehr dazu weiter unten.

Warum klassische Datenbanktransaktionen für Agenten versagen

Foundation ist die neue Speicherschicht von Chroma. Sie nimmt Traces von Coding-Agenten und Unternehmensdaten auf und baut daraus ein dauerhaftes, durchsuchbares Gedächtnis. Auf hoher Ebene arbeitet Foundation als ein Schwarm von Agenten, die gemeinsam ein Wiki aufbauen. Auch das ist Nebenläufigkeitskontrolle – nur für Agenten statt für Code. Die Lehrbuchmethoden der Datenbankwelt stoßen hier an Grenzen.

Die Gründe sind zwei Beobachtungen. Erstens dauert eine einzelne Verarbeitungsrunde mehrere Minuten. Zweitens bestimmt nicht ein Index den Lesebereich, sondern Suchen und Schlussfolgerungen des Agenten. Optimistische Nebenläufigkeitskontrolle (OCC) validiert erst beim Commit. Bei einer Transaktion, die Minuten läuft, erzeugen Konflikte einen Sturm aus Wiederholungen. Jede Wiederholung kostet den Agenten seine Suche und Argumentation neu. Eine Datenbanktransaktion ist im Millisekundenbereich neu gestartet, weil sie denselben Code nochmal ausführt. Ein Agent muss nach einem Abbruch seine Entdeckungsarbeit erneut leisten.

Die Zahlen: Datenbanktransaktionen haben billige Arbeit, kurze Retry-Dauer und deterministischen Code. Agenten haben teure Arbeit, minutenlange Runden und sind nichtdeterministisch. Ein Abort verwirft nicht nur ein paar Zeilen, sondern wertvolle Denkarbeit. Dieses Problem musste Chroma mit Foundation lösen.

Fission: Fortschritt ohne Rollback

Die Lösung von Chroma heißt Fission. Auf den ersten Blick ähnelt das Protokoll dem klassischen Zwei-Phasen-Sperrverfahren mit Wound-Wait zur Deadlock-Vermeidung. Jeder Agent sperrt eine Seite exklusiv, bevor er sie liest. Die Sperren werden inkrementell beim ersten Seitenzugriff erworben, nicht über Suchergebnisse. Konfliktregel: Jüngere Transaktionen warten auf ältere, ältere verletzen jüngere. Eine verletzte Transaktion gibt ihre Sperren sofort frei und versucht es mit ihrem ursprünglichen Zeitstempel erneut. Deadlocks sind damit strukturell ausgeschlossen.

Der Unterschied zu klassischen Protokollen: Fission bricht die Atomarität explizit auf. Transaktionen rollen nie zurück. Stattdessen wird ein Abbruch wie ein vorzeitiger Commit behandelt. Alles, was die Transaktion bis zum Abbruch geschrieben hat, bleibt im Wiki stehen. Das erinnert an Eventual Consistency und CAP, ist aber etwas anderes. Fission garantiert weiterhin Isolierung beim Denken: Ein Agent kann eine Seite lesen, darüber nachdenken und einen Patch anwenden, ohne währenddessen Konflikte zu sehen. Pro Seite bleibt die Schreiboperation atomar, abgesichert durch die OCC-Transaktionen von Chroma Cloud. Die Konsistenz der Inhalte verantwortet das Reasoning-Modell, das logisch saubere Edits produzieren soll.

Das Protokoll ist einfach: Exklusive Sperren für Seiten, Erwerb beim ersten Lesen, Wound-Wait über Ankunftszeitstempel, Haltbarkeit über Chroma Cloud. In der ersten Prototyp-Version teilt der Lock-Manager eines Jobs dessen Schicksal. Mehr ist es nicht. Diese Einfachheit ist seine Stärke.

Was Fission opfert und warum sich das lohnt

Jedes Nebenläufigkeitsprotokoll tauscht eine Ressource gegen eine andere. Klassische Protokolle nehmen an, dass Arbeit billig ist, Wiederholung fast nichts kostet und Atomarität vor allem zählt. Fission dreht das um: Die teure Ressource ist die Reasoning-Arbeit des Agenten. Deshalb opfert Fission die Atomarität, um diese Denkarbeit zu erhalten. Ein einmal gemachter, logisch valider Edit wird nie verworfen – auch wenn die ursprüngliche Transaktion nicht zu Ende lief.

Diese Entscheidung hat Konsequenzen. Eine verletzte Transaktion hinterlässt ihre Teilergebnisse im Wiki, und andere Agenten können sie entdecken. Das setzt voraus, dass die Schreibfolge des Modells so strukturiert ist, dass jeder Präfix gültig ist. Dafür haben die Entwickler den Agenten ein TODO-Werkzeug gegeben: Der Agent schreibt erst den Inhalt, dann den Backlink – und nicht umgekehrt. Dadurch entstehen keine verwaisten Verweise. In Tests zeigten sich alle Anomalien, die das Protokoll zulässt, als harmlos, wenn die Updates in dieser präfix-sicheren Reihenfolge erfolgen.

Die Zahlen zeigen Muster. Bei etwa 39,7 Prozent der verletzten Transaktionen greift das Modell später erneut auf die Seite zu, die zur Verletzung geführt hat. Bei 28,2 Prozent der Modifikationen während eines Retrys teilen sich die Änderungen ein Präfix oder Suffix mit der Seite, die den Abbruch ausgelöst hat. Chroma schließt daraus, dass diese Blockaden kein False Sharing sind: Ein nennenswerter Teil der abgebrochenen Transaktionen kehrt zu genau der Seite zurück, an der sie gescheitert ist. Ein früherer Prototyp mit getrennten Lese- und Schreibsperren hatte deutlich höhere Abbruchraten; die Aufwertung von Lese- zu Schreibsperren brachte keinen Fortschritt.

Warum Git und Dateisysteme als Fundament scheitern

Die naheliegende Frage lautet: Warum nicht einfach das Wiki in Git speichern und über ein Dateisystem zugänglich machen? Chroma nennt zwei Gründe. Erstens braucht man einen sekundären Index für die Suche, sonst explodieren die Token-Kosten. Zweitens ist Git miserabel bei Merge-Konflikten. Ein früher Prototyp von Foundation nutzte genau diesen Ansatz: Git zur Konfliktlösung auf einer Dateisystem-Abstraktion. Die Ergebnisse waren ernüchternd.

Von acht Konfliktfällen brachen drei explizit ab, nachdem derselbe Konflikt wiederholt auftrat. Vier weitere gaben auf, weil ihr Lesebereich veraltet war oder sie wegen einer zwischenzeitlichen Schreiboperation neu lesen mussten. Nur einer kam zur richtigen Schlussfolgerung, dass der Schreibvorgang unnötig war, und brach deshalb ab. Besonders aufschlussreich sind die Aussagen der Modelle: „Ich überspringe das Aktualisieren der Root-Seite, um weitere Merge-Konflikte zu vermeiden.“ Oder: „Es gibt Merge-Konflikte von einem anderen Worker – ich überspringe das Aktualisieren der Root-Seite.“ Nach einem erneuten Lesen stellt ein anderes Modell fest: „Die Root-Seite wurde bereits aktualisiert, also ist kein separates Update nötig.“ Und schließlich: „Anstatt weiter zu kämpfen, überspringe ich das Root-Seiten-Update.“

Das Muster ist eindeutig. Die Modelle geben auf, nicht weil sie fachlich falsch liegen, sondern weil Git sie in eine Sackgasse führt. Sie ziehen sich zurück, obwohl ihre Absicht korrekt war. Git ist für Code konzipiert, nicht für zusammengefasste, umgeschriebene und zurückgenommene Prosa. Der Versuch, Agenten-Konflikte mit Git zu lösen, verwirft genau die Arbeit, die man erhalten will.

Was das für verteilte Systeme bedeutet

Fission ist kein Allheilmittel. Es ist ein Protokoll mit einer klaren Annahme: Die schrittweise Verbesserung eines Wissensbestands ist wertvoller als die Garantie, dass eine Transaktion ganz oder gar nicht sichtbar wird. Das passt zu einer Welt, in der Agenten zunehmend parallel an gemeinsamen Gedächtnissen arbeiten. Chroma grenzt Fission selbst ab: Es ist weder CALM noch ein CRDT. Sagas ähnelt es durchaus, allerdings ohne kompensierende Aktionen — zurückgenommen wird nie etwas. Es sitzt auf einer linearisierbaren Historie und erlaubt trotzdem, dass Modelle Zustände durch Überschreiben zurücknehmen.

Wer mit verteilten Systemen arbeitet, sieht hier ein bekanntes Muster: Die klassischen Werkzeuge sind nicht falsch, sie sind für andere Kostenmodelle gebaut. Wenn eine Transaktion Minuten dauert und ihre Wiederholung viel kostet, ist der Abbruch die teuerste Operation im System. Jedes Protokoll, das Abbrüche vermeidet oder ihre Kosten senkt, hat einen Vorteil. Fission zeigt einen Weg: Atomarität aufgeben, wo sie nicht gebraucht wird, und Intelligenz dort einsetzen, wo sie die Wiederaufnahme steuern kann. Das ist keine Absage an ACID, sondern eine pragmatische Erweiterung für eine neue Klasse von Workloads. Ohne sie kommen Agenten-Schwärme nicht in Produktion.

Quelle: trychroma.com

„IPv6 provides the addressing scale needed for large-scale AI deployments, while DNS remains essential for service discovery and connectivity.“ Dieser Satz von Anlei Hu, Chief Scientist des China Internet Network Information Center (CNNIC), hat es in sich. Er zeigt, wohin die Debatte um die digitale Infrastruktur läuft: Künstliche Intelligenz und ihre wachsende Zahl an autonomen Agenten werden das Internet verändern. Die Grundlagen dafür entstehen derzeit in den Konferenzen der Internet Engineering Task Force (IETF).

Was auf der IETF 126 in den Working Groups und BoF-Sessions besprochen wurde, zeigt, wie sich die technische Gemeinschaft darauf vorbereitet. Die Tragweite lässt sich auch ohne Netzwerk-Ingenieur-Wissen erfassen. Es geht um die Frage, wie Milliarden von KI-Agenten künftig miteinander kommunizieren, sich finden und sicher austauschen können. Die Antworten, die dort skizziert wurden, betreffen uns alle.

Rekordbeteiligung und die Agenda der IETF 126

Mit 1.230 Teilnehmern vor Ort und 672 remote Zugeschalteten stellte die IETF 126 einen neuen Besucherrekord auf. Das Interesse ist kein Zufall: Der Termin fiel in eine Phase, in der KI-Systeme von reinen Rechenzentrums-Anwendungen zu verteilten, vernetzten Strukturen übergehen. Die vom Autor besuchten Sitzungen konzentrierten sich auf IP-Adressierung, DNS-Betrieb und die Themen, die mit künstlicher Intelligenz zusammenhängen. Der Tenor: IPv6 und DNS werden im KI-Zeitalter wichtiger.

Ein Schwerpunkt lag auf der Weiterentwicklung der IPv6-Infrastruktur. Die technische Gemeinschaft beschäftigt sich nicht erst seit heute mit den Anforderungen von KI. Sie entwickelt bereits konkrete Mechanismen, etwa bei der Adressvergabe und bei Übergangsstrategien. Hier setzen die interessantesten Vorschläge an.

IPv6 als Fundament für Milliarden von KI-Agenten

Kurz gesagt: Wer KI-Agenten im großen Stil betreiben will, braucht Adressen. Viele. Genauer gesagt: global eindeutige, verfolgbare Adressen. Der Vorrat an IPv4-Adressen ist jedoch längst erschöpft.

In der IAB-Open-Meeting-Diskussion über die langfristigen Folgen der IPv4-Adressknappheit waren sich die Teilnehmer weitgehend einig, dass die erwartete Größenordnung von KI-Installationen die praktischen Grenzen von IPv4 sprengt. Große NAT-Installationen und Übersetzungsmechanismen zerstören die Ende-zu-Ende-Identität. Agenten sind schwerer zu finden, sichere Kommunikation wird kompliziert, Sicherheitsüberprüfungen werden zum Albtraum. IPv6 ist die Grundvoraussetzung.

Ein konkretes Beispiel lieferte China Telecom mit ihrem Vorschlag der DNS-basierten IPv4-zu-IPv6-Zuordnung, dem Address Mapping Record (AMR). Dabei geht es um eine Lösung für die IPv6-Adressierung in reinen IPv6-Netzen: Das DNS übernimmt die Zuordnung von IPv4-zu-IPv6-Informationen, also wie eine Art Telefonbuch für übersetzte Adressen. Das verbessert die Arbeit von DNS64/NAT64-Mechanismen und reduziert die Notwendigkeit, Adressen fest im System zu verankern. Der Übergang zu IPv6 passiert nicht über Nacht. Techniken wie diese begleiten ihn.

Segment Routing über IPv6 (SRv6) war ebenfalls Thema. Die Arbeiten an SRv6 und dem komprimierten SRv6-Format (RFC 9800) für Compute-Interconnect-Umgebungen zielen auf verlustarme IPv6-Weiterleitung und In-situ-Operations, Administration und Maintenance (IOAM) – speziell für GPU-Cluster und verteilte KI-Trainingssysteme.

DNS: Der schmale Grat zwischen Discovery und Datenmüll

Die DNS-Diskussionen fanden größtenteils in der DNS Operations (DNSOP) Working Group statt. Der Autor berichtet von einer Debatte, die sich um DNS-basierte KI-Agenten-Erkennung drehte. Ein Vorschlag vom IETF 125 sah vor, die Subdomain _agents mit Service Binding (SVCB) und TXT-Records zu nutzen, um Agenten innerhalb einer Domain auffindbar zu machen. Die Befürworter argumentierten, dass bestehende Mechanismen wie DNS Service Discovery (DNS-SD) und SVCB ausreichen, um eine leichtgewichtige Erkennung zu ermöglichen, ohne neue Protokolle zu erfinden.

Doch viele Teilnehmer der DNSOP-Gruppe äußerten Bedenken. DNS sei nicht dafür gebaut, komplexe Beschreibungen von KI-Fähigkeiten zu transportieren, hieß es. Es fehle an standardisierten semantischen Modellen, TXT-Records würden zweckentfremdet, und die Query-Volumina könnten explodieren. Der Konsens war deutlich: DNS soll nur grundlegende Endpunkt-Informationen liefern, keine kompletten Fähigkeitsprofile von Agenten. Die weitergehende Erkennung soll durch die neue Initiative DAWN – das steht für „Discovery of Agents, Workloads, and Named entities“ – übernommen werden.

Die Zurückhaltung ist berechtigt. DNS ist das Telefonbuch des Internets. Wenn man dort anfängt, ganze Charakterbeschreibungen zu hinterlegen, bricht das System unter seiner eigenen Last zusammen. Es braucht klar getrennte Ebenen.

DAWN: Die neue Initiative für Agenten-Discovery

Künstliche Intelligenz und ihre Agenten beherrschten die Diskussionen in Rotterdam. Das bedeutendste Ergebnis war der Start des DAWN BoF, das sich in Richtung einer formellen Arbeitsgruppe bewegt. DAWN soll einen dezentralen, skalierbaren und domainübergreifenden Rahmen für die Erkennung von KI-Agenten schaffen. Der Trick: DNS kann als Transportmechanismus dienen, ohne komplexe semantische Informationen in DNS-Records zu stopfen. Das umgeht die Bedenken der DNSOP-Diskussion.

Die Sitzung endete mit ausreichend Unterstützung, um den Prozess der Arbeitsgruppenbildung fortzusetzen. Ein offizieller Vorschlag soll bei der IETF 127 eingereicht werden. Parallel dazu gibt es mehrere Arbeitsstränge für ein interoperables Internet-Protokoll für die Agent-zu-Agent-Kommunikation, oft als „agentproto“ bezeichnet. Es geht darum, dass Agenten verschiedener Hersteller und aus verschiedenen Domänen sicher miteinander kommunizieren können.

Ein Vier-Schichten-Modell für das KI-Internet

Anlei Hu, der Autor des Berichts, interpretiert die Diskussionen als Beginn eines Vier-Schichten-Modells für ein KI-fähiges Internet. Die unterste Schicht bildet IPv6 für Adressierung und Konnektivität. Darüber liegt DNS für Benennung und Service-Discovery. Die dritte Schicht übernimmt DAWN für die Erkennung von Agenten und Workloads. Und an der Spitze stehen Agent-Communication-Protokolle für die eigentliche Kommunikation und Interoperabilität.

Hu betont, dass es sich dabei um eine frühe Vision handelt, nicht um eine abgestimmte Architektur. Aber sie zeigt, wie die Teilnehmer beginnen, über die protokollarischen Grundlagen für ein Internet nachzudenken, das zunehmend von KI-Agenten bevölkert wird. Es ist ein Modell, das auf den bestehenden Stärken des Internets aufbaut – einer soliden Adressierung, einem robusten DNS – und neue, offene Standards für die Agenten-Welt ergänzt.

Was das für die APNIC-Community bedeutet

Für die Mitglieder der APNIC-Community, die für die Vergabe von IP-Adressen im asiatisch-pazifischen Raum zuständig ist, sind diese Diskussionen von unmittelbarer Bedeutung. Die Beziehung zwischen KI-Agenten und IP-Adressierung wird erst seit kurzem erforscht, aber die Auswirkungen könnten erheblich sein. Themen wie Identität, Rückverfolgbarkeit, Adressierung und Sicherheit fallen genau in APNICs Aufgabenbereich, der Internet-Nummernressourcen, Routing-Sicherheit und den laufenden Ausbau der Internet-Infrastruktur umfasst.

Maschinell erzeugter Traffic könnte die DNS-Infrastruktur belasten, bietet aber auch neue Forschungs- und Messansätze. Wenn KI-Systeme beginnen, in großem Umfang DNS-Abfragen zu generieren, müssen Betreiber verstehen, wie sich diese Muster auf die Stabilität des Systems auswirken. Der Autor sieht darin eine Chance für den asiatisch-pazifischen Raum, sich aktiv in diese Entwicklungen einzubringen.

Das Fazit: Die Weichen für die Zukunft des Internets mit IPv6 werden heute in technischen Gremien gestellt. Die IETF 126 hat gezeigt, dass die Akteure die Herausforderungen ernst nehmen und pragmatische Lösungen suchen.

Quelle: blog.apnic.net