Transcript
00:00:00SQLite wurde in Rust neu geschrieben.
00:00:02Und ich weiß, erst kürzlich gab es den Bun-Rewrite in Rust,
00:00:04und Sie fragen sich vielleicht, warum plötzlich alle
00:00:06alles in Rust neu schreiben – aber darum geht es hier nicht.
00:00:09Es geht nicht einmal um SQLite.
00:00:11Mir ist klar, dass es die Turso-Datenbank gibt,
00:00:15die bereits eine modernisierte Neuimplementierung
00:00:18von SQLite in Rust ist.
00:00:19Das ist genau die Wahl, die Sie treffen sollten,
00:00:21wenn Sie eine produktionsreife,
00:00:23auf Rust basierende SQLite-Datenbank suchen.
00:00:26Stattdessen dreht sich dieses Experiment, mini-sqlite,
00:00:29das unten verlinkt ist und das Sie sich ansehen können,
00:00:32weder um SQLite noch um Rust.
00:00:34Es ist vielmehr ein Experiment des Cursor-Teams,
00:00:37bei dem sich alles um Agentenschwärme und die Entwicklung
00:00:40eines Systems aus KI-Agenten dreht, um herauszufinden,
00:00:44was funktioniert und was nicht, wenn man etwas
00:00:47wie SQLite rein aus der Dokumentation nachbauen lässt.
00:00:51Denn genau darum geht es bei diesem Versuch.
00:00:53Es gibt dazu einen sehr detaillierten, äußerst spannenden Blogbeitrag,
00:00:56in den wir nun eintauchen werden.
00:00:57Darin stecken viele interessante Erkenntnisse,
00:00:59über die wir sprechen müssen und die ebenfalls unten verlinkt sind.
00:01:02Dort erklären sie, wie sie das Experiment durchgeführt haben, sowie den Ausgangspunkt.
00:01:07Die Grundidee war, die Dokumentation von SQLite zu nehmen,
00:01:12die zusammengefasst immerhin 835 Seiten umfasst,
00:01:18und natürlich primär für Menschen geschrieben wurde.
00:01:23Ich meine, es ist nicht die zugänglichste Dokumentation, die ich je gesehen habe,
00:01:27aber sie richtet sich logischerweise an Menschen, da sie viel älter als der ganze KI-Agenten-Hype ist.
00:01:32Dennoch dient sie gewissermaßen als extrem detaillierte Spezifikation,
00:01:37da sie präzise beschreibt, wie SQLite verwendet wird
00:01:43und welches Verhalten beziehungsweise welche Funktionen vorgesehen sind.
00:01:48Das Cursor-Team nahm also diese Dokumentation
00:01:52und kombinierte sie mit einem öffentlichen Testset, dem SQLogic-Test,
00:01:57einer Reihe von Tests, die das Verhalten von SQLite prüfen
00:02:02oder speziell Abfragen testen.
00:02:05Damit überprüften sie, ob die Implementierung,
00:02:09die ihre Agenten auf Basis dieser Doku gebaut hatten,
00:02:13tatsächlich mit dieser offiziellen, riesigen Testsuite funktioniert.
00:02:19Vorab aber noch ein paar wichtige Hinweise zur Vorsicht.
00:02:23Bei dieser Testsuite geht es rein um das Testen von Abfragen und Abfrageverhalten.
00:02:29Sie prüft keineswegs alle Features und Fähigkeiten von SQLite.
00:02:35Ebenso wenig wird die allgemeine Performance getestet.
00:02:38Auch Nebenläufigkeit bleibt unberücksichtigt.
00:02:40Es gibt viele Aspekte in SQLite, die hier nicht getestet werden.
00:02:44Dieses mini-sqlite-Ergebnis aus dem Experiment – eines der Ergebnisse,
00:02:49denn sie haben SQLite mehrfach mit verschiedenen Agentenkombinationen nachgebaut –
00:02:53worauf wir noch eingehen, dient rein der Veranschaulichung.
00:02:57Es ist keineswegs produktionsreif.
00:02:59Es ist nichts für den praktischen Einsatz.
00:03:01Es ist lediglich das Resultat eines Experiments, bei dem das Ziel war, anhand der Doku
00:03:06SQLite neu aufzubauen und diese Nachbildung alle Tests bestehen zu lassen.
00:03:13Das Cursor-Team nutzte hierbei unterschiedliche Modellkombinationen.
00:03:17Warum Kombinationen?
00:03:18Weil sie, wie wir gleich sehen werden, einen Ansatz wählten,
00:03:21bei dem mehrere Agenten zusammenarbeiteten: Planer, Worker und Reviewer.
00:03:28Sie bauten die SQLite-Datenbank mit verschiedenen Konfigurationen nach und verglichen die Ergebnisse bei ähnlicher Qualität.
00:03:37Alle Kombinationen erzielten ein vergleichbares Qualitätsniveau mit der gleichen Testabdeckung, doch die Kosten fielen extrem unterschiedlich aus.
00:03:45Wurde beispielsweise GPT-5.5 durchgehend für Planer und Worker eingesetzt, beliefen sich die Kosten für den SQLite-Nachbau in Rust auf rund 10.000 Dollar.
00:03:59Die Kombination von Opus 4.8 mit Composer 2.5 – dem extrem schnellen, günstigen und effizienten, wenn auch weniger intelligenten Cursor-Modell – lieferte hingegen dieselbe Qualität und dieselbe Anzahl bestandener Tests für nur einen Bruchteil der Kosten, nämlich für gerade einmal 1.300 Dollar.
00:04:24Der Ansatz bestand darin, Opus 4.8 als leistungsfähigeres Modell für die Planung und die Strukturierung der Aufgaben einzusetzen, die dann an die Worker-Agenten mit Composer 2.5 übergeben wurden.
00:04:39Und das ist bereits eine zentrale Erkenntnis aus dem Artikel, die natürlich nicht ganz neu ist.
00:04:44Das lässt sich auch auf die eigene Softwareentwicklung übertragen.
00:04:47Es ist ratsam, die Arbeit je nach Komplexität in einzelne Aufgaben zu unterteilen, die von verschiedenen Subagenten ausgeführt werden – wobei sich einige Agenten rein auf die Planung fokussieren,
00:05:03um konkrete Teilaufgaben des Gesamtziels zu definieren, woraufhin spezialisierte Worker-Agenten die Umsetzung übernehmen.
00:05:14Denn es zeigt sich: Um sauberen Code zu generieren, braucht es nicht zwingend Spitzenintelligenz, sofern der Kontext stimmt.
00:05:24Wenn also die Aufgabe klar umrissen ist und alle relevanten Informationen in der Beschreibung stecken, spielen natürlich noch weitere Faktoren mit hinein.
00:05:33Wichtig ist etwa die Struktur der bestehenden Codebasis oder die Qualität der bereitgestellten Beispiele.
00:05:39All das beeinflusst das Ergebnis, aber reine Coder-Agenten können bei präziser Aufgabenstellung und gutem Kontext wesentlich schlanker gehalten werden.
00:05:49Und genau darauf lag der Schwerpunkt des Experiments:
00:05:52Wie entwirft man ein System, das einer Aufgabe dieser Größenordnung gewachsen ist?
00:05:57Denn wie erwähnt, ist das Zusammenspiel aus Planer- und Worker-Agenten auch für eigene Projekte eine Überlegung wert.
00:06:07Natürlich nicht für jede Kleinigkeit.
00:06:10Bei einem schnellen Bugfix oder einer einfachen Aufgabe reicht es völlig aus, dem jeweiligen Coding-Agenten – ob Codex, Claude Code oder was auch immer – Bescheid zu geben:
00:06:19“Hey, hier ist das Problem.
00:06:20Bitte kümmere dich darum.”
00:06:21Geben Sie ihm den nötigen Kontext und lassen Sie ihn arbeiten.
00:06:24Je nach Umgebung erstellt die KI womöglich von selbst Subagenten.
00:06:28Claude Code nutzt dieses Verfahren teilweise.
00:06:31Andere Frameworks wie Pi machen das ohne passende Erweiterungen nicht.
00:06:36Aber auch ohne Unteragenten lässt sich ein Großteil der Routineaufgaben problemlos mit einem einzelnen Agenten lösen.
00:06:43Bei komplexeren Projekten lohnt sich die Aufteilung jedoch enorm, insbesondere wenn man auch Reviewer-Agenten einbindet.
00:06:51Das ist ein Ansatz, den ich persönlich sehr schätze –
00:06:54stets abhängig von der Komplexität der Aufgabe.
00:06:56Diese klare Rollentrennung funktioniert in der Praxis hervorragend.
00:06:59Das Prinzip an sich ist zwar keine Neuentdeckung.
00:07:02Neu ist jedoch, dass bei einem solchen SQLite-Rewrite zahlreiche parallele Prozesse aus Planern, Workern und Reviewern gleichzeitig laufen – also mehrere Worker, aber eben auch mehrere Planer und Reviewer.
00:07:18Und diese geraten ständig aneinander.
00:07:19Genau das hat das Cursor-Team letztlich festgestellt.
00:07:22In diesem äußerst lesenswerten Blogbeitrag
00:07:26erwähnen sie, dass sie Anfang des Jahres bereits ein Experiment durchgeführt hatten, bei dem ein Agentensystem einen Webbrowser von Grund auf baute.
00:07:33Dasselbe System nutzten sie nun für die Reimplementierung von SQLite.
00:07:40Aufgrund ihrer Erfahrungen entwickelten sie jedoch auch ein völlig neues Testsystem.
00:07:47Im Artikel vergleichen sie diese Ansätze und gehen im Detail auf die Hürden ein, die beim Aufsetzen und Betrieb dieses SQLite-Rekonstruktionssystems auftraten.
00:07:59Eines der ersten Probleme bei Systemen mit hunderten oder tausenden gleichzeitig agierenden Workern war, dass die traditionelle Versionsverwaltung Git an ihre Grenzen stieß.
00:08:13Wie sie in einem früheren Beitrag zum Schwarm schrieben, beruhen Tools wie Git und Cargo auf grobkörnigen Sperren zur Nebenläufigkeitssteuerung, womit derselbe Datenblock gesperrt wird, um zeitgleiche Schreibzugriffe zu verhindern.
00:08:30Das funktioniert für einen einzelnen Entwickler gut, ist aber bei der Arbeitsmenge von hunderten parallelen Agenten unpraktikabel.
00:08:36Der Browser-Schwarm erreichte in Spitzenzeiten rund 1.000 Commits pro Stunde.
00:08:41Das war also der Schwarm, der den Browser nachbaute.
00:08:45Das neue System für dieses Experiment schafft in der Spitze jedoch etwa 1.000 Commits pro Sekunde.
00:08:52Der alte Schwarm hatte 1.000 Commits pro Stunde, was natürlich schon deutlich über dem menschlichen Pensum liegt.
00:09:02Das neue System kommt dagegen auf ca. 1.000 Commits pro Sekunde – ein wahrhaft astronomischer Wert, für den Git schlicht nicht ausgelegt ist.
00:09:14Ganz offensichtlich.
00:09:15Um diese enorme Aktivität zu bewältigen, bauten sie ein eigenes Versionsverwaltungssystem von Grund auf neu.
00:09:21Der Durchsatz war jedoch nicht der einzige Grund dafür.
00:09:25Jede Änderung im System läuft zwingend durch die Versionsverwaltung.
00:09:29Sie ist also der Ort, an dem Konflikte zuerst sichtbar werden.
00:09:31Mehrere Koordinationsmechanismen wurden daher direkt in diese Ebene integriert.
00:09:37Das ist extrem spannend.
00:09:39Sie haben ein Versionskontrollsystem speziell für das KI-Zeitalter entwickelt.
00:09:43Denn das gewohnte Git ist zwar hervorragend – keineswegs falsch verstehen –
00:09:48um das klarzustellen.
00:09:49Wir sprechen hier von Dimensionen und Aufgaben, die die meisten von uns so schnell nicht bewältigen müssen.
00:09:57Aber dennoch: Git ist nicht darauf ausgelegt, dass hunderte Agenten zeitgleich an derselben Codebasis arbeiten.
00:10:07Daher entwickelten sie ein System, das extrem hohe Nebenläufigkeit bewältigt und zugleich bei der Konfliktlösung durch Agenten hilft.
00:10:19Schließlich treten Konflikte genau dort zutage, wo zwei Änderungen dieselbe Stelle in einer Datei betreffen.
00:10:28Das ist also die erste wichtige Erkenntnis.
00:10:30Sie haben für diesen Versuch eine völlig neue Versionsverwaltung gebaut, um den Durchlauf effizient zu ermöglichen.
00:10:37Bei 1.000 Commits pro Sekunde traten naturgemäß etliche Hürden auf.
00:10:48Die aufgetretenen Probleme und deren Lösungen sind hochinteressant, da sie einen Ausblick darauf geben, wie Softwareentwicklung in Zukunft aussehen könnte.
00:11:01Ein Beispiel ist das “Split-Brain”-Designproblem.
00:11:03Zwei Planer setzen unabhängig voneinander dasselbe Konzept an verschiedenen Stellen im Code unterschiedlich um.
00:11:10Es entsteht also Redundanz durch abweichende Lösungen für dieselbe Logik.
00:11:16Eigentlich möchte man solche gemeinsamen Teile auslagern und wiederverwenden.
00:11:21Gelöst haben sie das schlicht über das Prompting.
00:11:24Keine komplexe neue Architektur, sondern gezieltes Prompting.
00:11:28Die Planer-Agenten treffen Architekturentscheidungen nun selbst, statt sie weiterzudelegieren.
00:11:34Zudem müssen sie sicherstellen, dass keine zwei untergeordneten Aufgaben dieselbe Frage entscheiden.
00:11:39Es ist also eine Frage des Setups.
00:11:40Es kommt darauf an, beim Aufteilen in Planer und Worker zu gewährleisten, dass die verschiedenen Planer klar abgegrenzte Aufgaben erhalten, die sich nicht überschneiden oder in Konflikt geraten.
00:12:02Das beginnt folglich bereits beim menschlichen Design.
00:12:08Wie stellt man die Aufgabe bereit, wie formuliert man den Prompt?
00:12:11“Wir haben das über Prompting gelöst.”
00:12:13Das setzt sich dann im Agentenbaum über alle verzweigten Knoten fort: Wenn Agenten Aufgaben weiter unterteilen, müssen sie per Prompt angewiesen werden, schnittstellenfreie Teilaufgaben zu wählen.
00:12:34Letztlich ist das eine planerische Herausforderung für den Menschen, das System von Grund auf richtig zu konfigurieren.
00:12:43So sind sie dieses Problem angegangen.
00:12:47Ein weiteres Problem waren Zielkonflikte zwischen den Planern.
00:12:51Eine härtere Form entsteht, wenn zwei Planer voneinander wissen und sich durch gegenseitiges Überschreiben in denselben Dateien blockieren.
00:12:59Kommen zwei unterschiedliche Ansichten zusammen, stößt automatische Merge-Software an ihre Grenzen.
00:13:04Stattdessen halten die Agenten ihre Entscheidungen in zentralen Designdokumenten fest.
00:13:08Code, der auf einer Entscheidung aufbaut, verweist mit einer kompilierbaren Referenz auf das Dokument.
00:13:13Widersprechen sich Planer unbemerkt, führt ein Reconciler-Agent die Dokumente zusammen und reicht die Lösung nach unten weiter.
00:13:21Selbst bei bester Aufgabenverteilung lassen sich Überschneidungen und gemeinsame Logikbereiche in einer Codebasis nie völlig vermeiden.
00:13:43Um Konflikte bei der Implementierung zu verhindern, wurde ein Reconciler nachgeschaltet, der die Konzeptionen der Planer abgleicht.
00:13:59Diese überarbeiteten Vorgaben gingen erst danach an die Worker.
00:14:02Dieser Zwischenschritt vereinheitlichte die Vorgaben konkurrierender Planer und verhinderte doppelte, abweichende Reimplementierungen im Code.
00:14:21Beide Schritte greifen also ineinander.
00:14:24Natürlich kam es dennoch zu Merge-Konflikten.
00:14:29Präzise Planung und eine gemeinsame Sprache sind der erste wichtige Schritt, um Überschneidungen zu minimieren.
00:14:38Dennoch ändern mehrere Worker am selben Plan rasch dieselben Dateien und geraten aneinander.
00:14:50Viele Worker weichen schlicht nicht automatisch auf andere Dateien aus.
00:14:55Sie bearbeiten weiterhin dieselben Stellen.
00:14:57Das lässt sich schwer vermeiden.
00:14:58Zur Konfliktlösung müssten sie innehalten, den Kontext des anderen erfassen und den Code zusammenführen.
00:15:03Wenn zwei Parteien an derselben Datei arbeiten – ob Mensch oder KI –, müssen normalerweise beide kurz stoppen, um eine gemeinsame Lösung zu finden.
00:15:19So wird der Konflikt sauber aufgelöst.
00:15:23Worker-Agenten tun sich damit jedoch schwer; sie überschreiben fremde Änderungen meist oder verwerfen die eigenen.
00:15:29Vielleicht ist Ihnen das auch schon aufgefallen.
00:15:31Ich habe diese Erfahrung jedenfalls gemacht.
00:15:32Wenn man gemeinsam mit KI-Agenten in einer Codebasis arbeitet und selbst etwas anpasst –
00:15:38auch wenn man noch selbst Coden kann –
00:15:40geschieht oft Folgendes:
00:15:42Man ändert etwas im Code,
00:15:44und der Agent macht es rückgängig oder überschreibt es einfach.
00:15:48Er nimmt keine Rücksicht darauf.
00:15:50Er verfolgt starr sein Ziel.
00:15:52Wenn vorgegeben ist, diese Datei zu ändern, tut er das exakt so.
00:15:57Und es kümmert ihn nicht, ob Sie in der Zwischenzeit Änderungen daran vorgenommen haben.
00:16:01Es ist etwas anderes, wenn Sie die Änderung committet haben, da diese Agenten feinjustiert wurden, um Commits nicht so leicht zu überschreiben.
00:16:13Aber wenn es eine nicht committete Änderung ist, kümmert das den Worker einfach nicht.
00:16:17Dem Agenten ist das völlig egal.
00:16:19Und genau das ist auch hier passiert.
00:16:21Um das zu lösen, haben wir ein System entwickelt, in dem ein neutraler Dritt-Agent bei Merge-Konflikten eingreift und diese löst.
00:16:29Sein einziges Ziel ist es, unparteiisch und effizient zu sein, ähnlich wie Merge-Queues in Entwicklerteams.
00:16:35Und ich finde, das ist ebenfalls sehr interessant.
00:16:38Es ist wieder eine Form der Abstimmung.
00:16:41So wie ich es verstehe, geht es darum, diese Agenten kurz anzuhalten – genau wie früher, als man kurz innehalten musste, um
00:16:49eine Lösung für einen Konflikt zu finden.
00:16:51Was das aber klar zeigt – und das ist keine neue Erkenntnis –, ist, wie enorm wichtig ein frischer und passender Kontext ist.
00:17:03Egal ob Sie wie hier bei Cursor an einer riesigen Aufgabe arbeiten oder an einem kleineren Projekt:
00:17:12Der große Vorteil der Aufteilung in Planner-, Worker- und Reviewer-Agenten ist meist, dass Sie mit frischen Kontextfenstern arbeiten.
00:17:24Das bedeutet nicht, dass diese Kontextfenster leer sind.
00:17:26Es bedeutet nur, dass Sie neue Agenten-Sitzungen haben, die genau mit dem richtigen Kontext befüllt sind.
00:17:33Ein Worker ist zum Beispiel schlecht darin, seine eigene Arbeit zu überprüfen, weil sein Kontextfenster voller Details der Umsetzung ist.
00:17:41Er ist also befangen, wenn man es so nennen will.
00:17:44Deshalb sollte ein Reviewer-Agent in einem frischen Kontextfenster starten und nur Infos über den Plan, die Änderungen und bearbeiteten Dateien erhalten.
00:17:55Damit er die Arbeit objektiv bewerten kann.
00:17:59Darum sind frische, richtig befüllte Kontextfenster so entscheidend.
00:18:04Und genau das Gleiche ist hier der Fall: Merge-Konflikte wurden durch einen neuen, unbefangenen Agenten mit exakt dem nötigen Kontext gelöst.
00:18:17Ich nehme an, das System war so aufgebaut, dass die Worker die Konfliktlösung erhielten und sie nicht überschreiben durften, oder es wurden neue Worker gestartet.
00:18:30Das ist mir hier nicht ganz klar.
00:18:32Ein weiteres Problem waren sogenannte Mega-Dateien.
00:18:35Manche Dateien sind bei Agenten für Änderungen besonders beliebt.
00:18:39Jeder Agent fügt vielleicht nur wenig Code hinzu, und kein einzelner Agent ist dafür zuständig, die Datei klein zu halten.
00:18:45Diese Mega-Dateien bringen alles zum Stocken.
00:18:49Sie sind aufwendig zu übertragen, zu vergleichen und zu mergen und werden zum Ort ständiger Konflikte.
00:18:54Auch das ist etwas, das Sie in kleinerem Rahmen vielleicht schon erlebt haben.
00:19:00Ich auf jeden Fall.
00:19:01Eines der Dinge, die wir haben.
00:19:02Besonders beim Testen.
00:19:03Meiner Erfahrung nach lieben es Agenten, immer mehr Tests in dieselbe Datei einzufügen.
00:19:08Und das gilt natürlich nicht nur für Tests, aber dort sehe ich es besonders häufig.
00:19:13Vor allem, wenn mehrere Agenten arbeiten und jeder seine eigene Agenda verfolgt.
00:19:18Es ist ihnen egal, weil sie keine Menschen sind.
00:19:21Wie sollte es ihnen auch wichtig sein?
00:19:23Sie führen einfach nur Aufgaben aus, richtig?
00:19:24Sie kümmern sich nicht um die Dateigröße oder die allgemeine Architektur eines Systems.
00:19:30Wenn einfach eine Gruppe von Agenten ihre Aufgaben abarbeitet, driftet eure Codebasis irgendwann ins Chaos ab.
00:19:37Weil es den Agenten egal ist.
00:19:39Sie konzentrieren sich nur auf ihre eigene Aufgabe.
00:19:42Und diese Mega-Dateien sind natürlich ein klares Anzeichen für dieses Problem.
00:19:48Sie entstehen umso mehr, je länger und je mehr Agenten in eurem Projekt arbeiten.
00:19:55Es gibt keinen Agenten, der dafür zuständig ist, diese Datei aufzuteilen oder die Codebasis sauber zu strukturieren.
00:20:02Das gehört einfach nicht zu ihrer Aufgabe.
00:20:04Um das zu lösen, gaben wir Worker-Agenten die Möglichkeit, überfüllte Dateien zu markieren.
00:20:09Sobald sie markiert waren, blockierten wir neue Commits, und ein separater Agent zerlegte die zu groß gewordene Datei in kleinere Module.
00:20:16Es kommt also wieder ein unverbrauchter Agent zum Einsatz.
00:20:19Das ist ein Muster, das wir hier sehen.
00:20:21Bei all diesen Problemen ging es darum, ein Hindernis zu erkennen und dann frische Agenten mit der richtigen Aufgabe
00:20:28und dem passenden Kontext einzusetzen, um es zu lösen, damit die anderen Agenten ihre Arbeit fortsetzen können.
00:20:35Und genau das Gleiche gilt hier für die Mega-Dateien.
00:20:38Verknöcherung war ein weiteres Problem, auf das sie stießen.
00:20:40Agenten haben aus der Arbeit in bestehenden Codebasen mit menschlicher Aufsicht gelernt,
00:20:44zentralen Code nicht anzurühren, selbst wenn er geändert werden müsste.
00:20:48Das ist also nicht das, was ich vorhin meinte.
00:20:50Wenn man eine Änderung in einer Datei macht, an der der Agent arbeitet, und er sie einfach verwirft.
00:20:55Es geht vielmehr um das Allgemeine.
00:20:57Ein Agent hat eine klare Aufgabe, basierend auf einem Plan und dem Prompt, den man ihm gegeben hat.
00:21:03Und das beinhaltet natürlich das Ändern bestimmter Dateien.
00:21:07Eine Sache, die wir bereits wissen oder täglich bei der Arbeit mit Agenten beobachten, ist, dass je nach Modell
00:21:16manche Modelle extrem zögerlich sind, bestehenden Code loszulassen.
00:21:21Sie fügen lieber 10 Fallbacks, 10 If-Prüfungen und immer mehr Altmüll hinzu, anstatt ihn zu löschen und aufzuräumen.
00:21:31Man muss explizit prompten, um sicherzustellen, dass ein Agent eine Funktion wirklich löscht oder eine Codedatei entfernt.
00:21:39Von sich aus machen sie das wegen ihres Fine-Tunings kaum, denn die Modellanbieter wollen natürlich keine Modelle bauen,
00:21:47die dann freidrehen und sämtlichen Produktionscode kaputtmachen.
00:21:50Wenn man aber nicht an einem Bestands Projekt arbeitet, das vielleicht schon live in Produktion läuft,
00:21:57dann kann diese Tendenz, Code nicht wirklich anzutasten und alles für immer aufzubewahren, extrem problematisch und nervig sein.
00:22:05Und es kann auch zu weiteren Nebeneffekten führen, wie sie sie hier erlebten: Agenten verbesserten den von anderen Agenten geschriebenen Code einfach nicht,
00:22:16sondern bauten immer weiter darauf auf, was letztendlich natürlich zu einer aufgeblähten Codebasis führte.
00:22:23Um das zu beheben, erlaubten wir bewusstes Brechen von Strukturen.
00:22:27Ein Agent, der eine zentrale Änderung für sinnvoll hält, kann außerhalb seines Bereichs einen gezielten Patch vornehmen und einen Kommentar hinterlassen, der erklärt, warum.
00:22:36Und das ist im kleineren Rahmen genau das, was ihr in euren Projekten tun könnt und was ich auch tue.
00:22:41Man muss es explizit erlauben und den Agenten sagen: Hey, wir bauen das hier gerade erst auf.
00:22:46Wir sind in der frühen Entwicklung.
00:22:48Das ist noch nicht live.
00:22:49Ich will Breaking Changes.
00:22:51Räumt den Code also aggressiv auf.
00:22:54Refactorings sind willkommen.
00:22:56Solche Sachen eben.
00:22:58Man muss die Agenten und KI-Modelle ermutigen und ihre Fine-Tuning-Vorgaben überschreiben.
00:23:04Sozusagen ihr eingebautes Wissen aushebeln, um sicherzustellen, dass sie eine Codebasis tatsächlich weiterentwickeln, anstatt nur mehr Code anzuhäufen.
00:23:14Auch das ist etwas, das wir im Kleinen beobachten können und das sich hier im Großen zeigt.
00:23:19Für die Überprüfung nutzten sie einen Ansatz namens Review-Linsen.
00:23:24Wir haben also Planer- und Worker-Agenten, aber diese Arbeit muss natürlich überprüft werden, um Folgeaufgaben zu erstellen und die Schleife neu zu starten, bis ein Bug behoben ist oder die Codebasis einen besseren Zustand erreicht.
00:23:38In einem System, das sowohl langläufig als auch aus mehreren Agenten besteht, summieren sich Fehler, und der Schwarm braucht einen Weg zur Selbstkorrektur, bevor kleine Fehler grundlegend werden.
00:23:47Auch das macht Sinn.
00:23:48Das haben wir alle schon im Kleinen erlebt.
00:23:50Wir haben mit vielen Arten von Review-Linsen experimentiert, wie etwa einem Review-Agenten das vollständige Transkript des Workers zu geben, nur dessen Ausgabe oder ausschließlich die Codebasis.
00:24:00Wir haben auch Reviewer getestet, die auf unterschiedlichen Modellen mit verschiedenem Training und anderer Persönlichkeit liefen.
00:24:05Keine einzelne Linse erfasst alles, aber die kombinierten Linsen ergänzen sich so, wie autonome Fahrsysteme übermenschliche Zuverlässigkeit erreichen, ohne dass eine einzelne Komponente perfekt ist.
00:24:16Die für die Überprüfung aufgewendete Rechenleistung zahlt sich aus, da ein Review viel günstiger ist als die Arbeit, die es prüft.
00:24:21Wir vermuten, dass dieses gestapelte Review-System wesentlich zur anhaltenden Qualität der Durchläufe beigetragen hat.
00:24:28Hier ist also die Kernerkenntnis.
00:24:30Es ist unmöglich, dass ein oder mehrere Reviewer-Agenten jeweils die gesamte Codebasis prüfen.
00:24:39Das ist viel zu viel.
00:24:41Stattdessen experimentierten sie mit verschiedenen Ansätzen, wie dem Übergeben des vollen Transkripts, nur der Ausgabe oder rein der Codebasis.
00:24:47Und was sie am Ende herausfanden, war, dass es ihnen half, verschiedene Reviewer mit unterschiedlichen Personas und Fokus-Linsen zu haben, die sich auf verschiedene Aspekte konzentrierten.
00:25:00Man gibt ihnen die Codebasis, so wie ich das verstehe, und vielleicht ein paar Informationen darüber, was der Worker gemacht hat.
00:25:06Und genau diese Kombination, die gebündelte Ausgabe mehrerer Reviewer, führte im Wesentlichen zu einem Gesamtergebnis, das dann wieder von einem Planer aufgegriffen werden konnte, um daraus einen Plan zu machen und die Worker den Code korrigieren zu lassen.
00:25:23Und auch im kleineren Maßstab ist das etwas, das wir anwenden können.
00:25:28Natürlich bauen wir im Alltag nicht direkt solche gigantischen Systeme.
00:25:34Aber was nach meiner Erfahrung ebenfalls sehr gut funktioniert, ist, mehrere Reviewer-Agenten mit unterschiedlichen Aufgaben zu haben, wo sich einer etwa darauf konzentriert: Hey, ist das idiomatisch sauberer Rust-Code?
00:25:46Ein anderer achtet vielleicht auf Performance- und Sicherheitsfragen, sofern das Modell das hergibt.
00:25:51Ein weiterer Reviewer prüft eventuell Benennungsmuster, falls das ein Schwerpunkt sein soll, und so weiter.
00:25:58Man hat also verschiedene Linsen und gibt diesen Reviewern genau den richtigen Kontext.
00:26:03Wieder nach dem Motto: Hey, Worker haben an diesem Feature gearbeitet.
00:26:07Man gibt ihnen vielleicht den Plan des Workers und ein paar Infos über die groben Schritte, die gemacht wurden, aber mehr auch nicht.
00:26:15Dann hat man all diese Rückmeldungen der verschiedenen Reviewer und kann sie zusammenführen – vielleicht sogar mithilfe eines weiteren Reviewers.
00:26:22Was ich auch sehr gerne mag: Einen Reviewer die Ergebnisse der anderen prüfen zu lassen. Das hilft, weil Modelle – je nach Typ – neigen dazu, überall Probleme zu finden.
00:26:36Egal welchen Code man ihnen vorlegt, selbst bei einem Einzeiler.
00:26:40Manchmal habe ich das Gefühl, sie finden selbst darin fünf Fehler.
00:26:43Ein Reviewer, der diese Funde kategorisiert und die verwirft, die keine echten Probleme sind, kann meiner Erfahrung nach hervorragend funktionieren.
00:26:55Und genau diese Kombination aus Reviewern, dieser Stapel an Prüfinstanzen, hilft dabei, gute Ergebnisse zu erzielen, die dann wieder aufgegriffen und umgesetzt werden können.
00:27:06Das hängt natürlich immer vom Umfang eurer Aufgabe und der Software ab, die ihr baut.
00:27:11Für viele Softwareprojekte ist das alles viel zu komplex, aber es ist ein schöner Einblick darin, wie Softwareentwicklung und solche Systeme in Zukunft aussehen könnten, was ich persönlich extrem spannend finde.
00:27:27Eine letzte Sache war, dass sie die Agenten die Umgebung mitgestalten ließen.
00:27:32Die Idee war, dass die Agenten einen Leitfaden verfassten – letztlich ein Dokument oder eine Sammlung von Dokumenten, bei denen sie den Agenten keine Vorgaben machten, außer dass dieser Leitfaden als Kontext für die Gesamtaufgabe dienen sollte. So konnten die Agenten ein gemeinsames Gedächtnis aufbauen, in dem Erkenntnisse oder identifizierte Hauptprobleme festgehalten wurden.
00:28:00Sie hatten also dieses zusätzliche Speichersystem für die Agenten eingerichtet, um Notizen zu machen und Entscheidungen zu dokumentieren.
00:28:10Insgesamt finde ich dieses Experiment – genau wie den Bun-Rewrite in Rust – extrem faszinierend.
00:28:16Es kann auch etwas unheimlich sein.
00:28:17Das verstehe ich vollkommen.
00:28:18Und wir sollten nicht Schlussfolgern, dass ab jetzt jede Software so gebaut werden sollte.
00:28:24Einerseits handelt es sich hierbei noch nicht einmal um eine produktionsreife Software.
00:28:28Und sie produktionsreif zu machen, würde sicherlich beträchtliche Zeit in Anspruch nehmen.
00:28:33Das darf man nicht unterschätzen.
00:28:35Es ist nicht so, dass man so etwas in ein paar Stunden baut und die Produktionsreife dann nur noch wenige Stunden mehr dauert.
00:28:43Die ersten 80 % lassen sich oft viel schneller erreichen als die letzten 20 %.
00:28:48Das wissen wir alle.
00:28:49Das ist also eine wichtige Erkenntnis.
00:28:51Es ist natürlich auch wichtig zu verstehen, dass bei dieser speziellen Aufgabe, SQLite neu zu schreiben, diese Dokumente und diese Test-Suite genutzt wurden.
00:29:04Aber das ist eine unglaublich detaillierte Spezifikation – etwas, das man bei neuen Projekten schlicht nicht hat.
00:29:13Wenn man eine neue Software entwickelt, hat man keine Spezifikation, die so detailliert ist wie die Dokumentation einer über 20 Jahre alten Software.
00:29:24Und selbst wenn den Agenten nur die Dokumentation gegeben wurde, ist es sehr wahrscheinlich, dass der Quellcode von SQLite und andere Re-Implementierungen – wie die in Rust von Turso – Teil der Trainingsdaten fast aller genutzten Modelle waren.
00:29:46Es war für diese Modelle also nicht völlig neu.
00:29:51Das ist nicht vergleichbar mit der Entwicklung einer komplett neuen Software von Grund auf, bei der Iteration ein wesentlicher Bestandteil ist.
00:29:58Es wird äußerst schwierig sein, und ich würde sogar behaupten unmöglich, eine neue Software, egal welcher Art, von Grund auf zu entwickeln, ohne dass sie sich ständig verändert.
00:30:11Denn man kann nicht im Voraus eine perfekte Spezifikation schreiben und damit fertig sein.
00:30:17Man entdeckt beim Bauen immer neue Dinge oder Details, die man ändern möchte, egal in welchem Maßstab.
00:30:26Deshalb ist das natürlich nicht repräsentativ dafür, wie Software im Allgemeinen gebaut wird oder werden sollte.
00:30:34Es ist dennoch ein sehr interessantes Experiment.
00:30:37Es ist ein extrem spannender Versuch, der zentrale Erkenntnisse für uns alle bereithält.
00:30:43Erkenntnisse, die natürlich nicht brandneu sind, wie das Aufteilen von Arbeit oder frische Kontextfenster mit genau den passenden Informationen.
00:30:50Ebenso spannende Einblicke, dass in Zukunft vielleicht neue Versionskontrollsysteme entstehen und benötigt werden.
00:30:57Und natürlich, dass Multi-Agenten-Orchestrierung immer wichtiger wird.
00:31:01All das beweist aber auch, dass Menschen diese Agentensysteme entwerfen müssen – und bei neuer Software weiterhin die Entscheidungen treffen, wie die Architektur aufgebaut sein soll.
00:31:21Spezifikationen verfassen, selbst wenn sie nicht so detailliert sind, Architekturen entwerfen und dann Agentensysteme bauen, die das umsetzen und anschließend überprüfen.
00:31:33Das ist die Richtung, in die wir uns bewegen. Und obwohl sich alles verändert und ganz anders ist als vor sechs Jahren, begeistert mich das extrem.
00:31:45Ich finde es wirklich spannend, dass wir uns in diesen Bereich des systemischen Denkens bewegen – sowohl beim Bau agentischer Systeme als auch beim Entwurf der Softwarearchitektur selbst.
00:31:59Und dann lassen wir beides zusammenarbeiten.
00:32:01Ich finde solche Experimente extrem faszinierend.
00:32:04Die Erkenntnisse hier sind super aufschlussreich.
00:32:07Und manche dieser Lerneffekte lassen sich im kleineren, vereinfachten Maßstab auch auf alltägliche Software- und Entwicklungsprojekte übertragen.
00:32:17Aber wie immer: Lasst mich wissen, was eure Gedanken sind und was ihr von solchen Experimenten haltet.