Vibe-Check verboten: Harte Probleme in komplexen Codebases lösen – Dex Horthy, HumanLayer

AAI Engineer
컴퓨터/소프트웨어경영/리더십AI/미래기술

Transcript

00:00:00(aufgeweckte Musik)
00:00:02- Hallo zusammen, wie geht's euch?
00:00:23Es ist aufregend, ich bin Dex.
00:00:25Wie schon in der tollen Einleitung erwähnt,
00:00:27beschäftige ich mich schon länger mit Agenten.
00:00:29Unser Vortrag "12-Factor Agents" auf der AI Engineer im Juni
00:00:32war einer der am besten bewerteten Vorträge überhaupt.
00:00:34Ich glaube, er war unter den Top Acht oder so,
00:00:35einer der besten der AI Engineer Konferenz im Juni.
00:00:38Vielleicht habe ich dort auch etwas über Context Engineering gesagt.
00:00:41Warum bin ich heute hier, worüber möchte ich sprechen?
00:00:44Ich möchte über einen meiner Lieblingsvorträge
00:00:46von der AI Engineer im Juni sprechen,
00:00:47und ich weiß, wir haben gestern alle das Update von Igor bekommen,
00:00:49aber man ließ mich meine Folien nicht mehr ändern,
00:00:50daher geht es hier um das, was Igor im Juni erzählte.
00:00:54Im Grunde haben sie 100.000 Entwickler befragt,
00:00:56über alle Unternehmensgrößen hinweg,
00:00:58und sie fanden heraus, dass man meistens,
00:01:00wenn man KI für Software-Engineering einsetzt,
00:01:01sehr viel nacharbeiten muss – viel Unruhe im Code.
00:01:04Und es funktioniert nicht wirklich gut bei komplexen Aufgaben
00:01:07oder bestehenden Altlast-Codebasen.
00:01:08Wie man in der Grafik sieht, liefert man
00:01:10zwar deutlich mehr Code aus,
00:01:11aber vieles davon ist nur das Überarbeiten des Mülls,
00:01:14den man letzte Woche produziert hat.
00:01:15Und die andere Seite war eben, dass
00:01:18bei Projekten auf der grünen Wiese, einem kleinen Vercel-Dashboard
00:01:21oder Ähnlichem, alles wunderbar klappt.
00:01:25Wenn man aber in eine 10 Jahre alte Java-Codebasis geht,
00:01:28eher weniger.
00:01:29Das deckte sich mit meiner Erfahrung.
00:01:30Sowohl persönlich als auch im Gespräch mit Gründern
00:01:32und Top-Entwicklern: Zu viel Pfusch,
00:01:35technische Schuld-Fabriken – das funktioniert nicht für unsere Codebasis.
00:01:37Vielleicht irgendwann, wenn die Modelle besser werden.
00:01:40Aber genau darum geht es beim Context Engineering.
00:01:42Wie holen wir das Beste aus den heutigen Modellen heraus?
00:01:44Wie verwalten wir unser Kontextfenster?
00:01:46Wir haben darüber im August gesprochen.
00:01:48Ich muss etwas gestehen.
00:01:49Als ich Claude Code das erste Mal nutzte, war ich nicht beeindruckt.
00:01:53Ich dachte: Okay, das ist ein bisschen besser,
00:01:54ich verstehe es, mir gefällt das Nutzererlebnis.
00:01:56Aber seither haben wir als Team etwas herausgefunden,
00:01:59wodurch wir tatsächlich in der Lage waren,
00:02:01den Durchsatz um das Zwei- bis Dreifache zu steigern.
00:02:02Und wir haben so viel produziert, dass wir gar keine Wahl hatten,
00:02:06als die Art unserer Zusammenarbeit zu ändern.
00:02:07Wir haben alles an unserer Softwareentwicklung neu verdrahtet.
00:02:11Wir waren ein Dreierteam, es dauerte acht Wochen und war verdammt hart.
00:02:12Aber jetzt, wo wir es gelöst haben, wollen wir nie wieder zurück.
00:02:14Das ist diese Sache mit dem "Vermeiden von Pfusch".
00:02:16Ich denke, wir haben da einen Weg gefunden.
00:02:18Das ging im September auf Hacker News extrem viral.
00:02:20Tausende Leute sind auf GitHub gegangen
00:02:23und haben sich unser "Research-Plan-Implement"-Prompt-System geholt.
00:02:25Die Ziele hierbei, die sich erst nach und nach ergaben:
00:02:28Wir brauchen KI, die in bestehenden Codebasen funktioniert.
00:02:31Die komplexe Probleme lösen kann.
00:02:35Kein Pfusch mehr, richtig? Schluss mit dem Müll.
00:02:38Und wir mussten die mentale Übereinstimmung wahren.
00:02:40Ich werde gleich noch mehr darüber sagen,
00:02:42was das genau bedeutet.
00:02:43Und natürlich wollen wir, wie bei allem,
00:02:44so viele Token wie möglich sinnvoll nutzen.
00:02:46Was wir sinnvoll an die KI auslagern können,
00:02:47ist wirklich extrem wichtig.
00:02:50Das ist ein enormer Hebel.
00:02:52Das hier ist also fortgeschrittenes Context Engineering für Coding-Agenten.
00:02:53Ich fange mal mit der Einordnung an.
00:02:56Die naivste Art, einen Coding-Agenten zu nutzen,
00:02:58ist, ihn um etwas zu bitten, ihm dann zu sagen, warum es falsch ist,
00:03:01ihn umzusteuern und immer weiter zu fragen,
00:03:03bis der Kontext voll ist, man aufgibt oder verzweifelt.
00:03:05Wir können das ein bisschen klüger angehen.
00:03:09Die meisten merken das recht früh
00:03:11bei ihren KI-Experimenten: Es ist oft besser,
00:03:13wenn man merkt, dass ein Gespräch in die falsche Richtung läuft,
00:03:17einfach ein neues Kontextfenster zu öffnen.
00:03:21Man sagt: Okay, dieser Weg war nichts.
00:03:24Fangen wir von vorne an.
00:03:25Gleicher Prompt, gleiche Aufgabe.
00:03:26Aber diesmal nehmen wir diesen Pfad hier.
00:03:27Und lass das da drüben weg, weil das nicht funktioniert.
00:03:29Aber woher weiß man, wann es Zeit für einen Neustart ist?
00:03:31Wenn man das hier sieht,
00:03:34(Publikum lacht)
00:03:37ist es wahrscheinlich Zeit für einen Neustart, oder?
00:03:39Das sagt Claude, wenn man ihm sagt, dass er Mist baut.
00:03:41Wir können aber noch cleverer vorgehen.
00:03:45Wir können das tun, was ich "absichtliche Kompaktierung" nenne.
00:03:47Dabei nimmt man, egal ob man auf dem richtigen Weg ist oder nicht,
00:03:50das bestehende Kontextfenster
00:03:53und lässt den Agenten alles in einer Markdown-Datei zusammenfassen.
00:03:56Das kann man prüfen und verschlagworten.
00:03:59Wenn dann ein neuer Agent startet,
00:04:00kann er sofort loslegen, anstatt erst mühsam
00:04:02nach Dateien zu suchen und die Codebasis zu verstehen
00:04:04und sich einarbeiten zu müssen.
00:04:05Was gehört in so eine Kompaktierung?
00:04:07Die Frage ist: Was nimmt eigentlich Platz weg
00:04:09in deinem Kontextfenster?
00:04:11Es ist die Suche nach Dateien, das Verständnis des Codeflusses,
00:04:13das Bearbeiten von Dateien, Test- und Build-Ausgaben.
00:04:17Und wenn ihr einen dieser MCPs habt, die JSON-Müll
00:04:20und haufenweise UUIDs in den Kontext schütten,
00:04:22dann gnade euch Gott.
00:04:25Was sollten wir also kompaktieren?
00:04:26Ich gehe gleich noch mehr ins Detail,
00:04:28aber das hier ist eine wirklich gute Kompaktierung:
00:04:30Genau das, woran wir gerade arbeiten,
00:04:31die exakten Dateien und Zeilennummern,
00:04:33die für das Problem, das wir lösen wollen, wichtig sind.
00:04:34Warum sind wir so besessen vom Kontext?
00:04:37Dafür wurden LLMs auf YouTube ziemlich verspottet.
00:04:39Sie sind keine reinen Funktionen, da sie nicht-deterministisch sind,
00:04:42aber sie sind zustandslos.
00:04:45Und der einzige Weg, mehr Leistung aus einem LLM herauszuholen,
00:04:46ist, bessere Token hineinzugeben,
00:04:49um dann bessere Token herauszubekommen.
00:04:51Bei jedem Schritt in der Schleife
00:04:52wählt Claude oder ein anderer Coding-Agent das nächste Werkzeug.
00:04:53Und es könnte hunderte richtige nächste Schritte geben
00:04:55und hunderte falsche.
00:04:56Aber das Einzige, was beeinflusst, was als Nächstes passiert,
00:04:58ist das, was bisher in der Konversation steht.
00:05:00Wir optimieren also dieses Kontextfenster
00:05:03auf Korrektheit, Vollständigkeit, Größe
00:05:05und ein Stück weit auch auf den Verlauf.
00:05:07Der Verlauf ist interessant,
00:05:10weil viele Leute sagen:
00:05:11"Ich habe dem Agenten gesagt, er soll etwas tun,
00:05:12und er hat es falsch gemacht."
00:05:13"Also habe ich ihn korrigiert und ihn ausgeschimpft,
00:05:16und dann hat er es wieder falsch gemacht."
00:05:17Und dann habe ich ihn wieder ausgeschimpft.
00:05:18Das LLM schaut sich diese Unterhaltung an
00:05:20und denkt: "Okay, cool, ich habe einen Fehler gemacht
00:05:21und der Mensch hat mich ausgeschimpft,
00:05:23dann habe ich noch einen Fehler gemacht und wurde wieder ausgeschimpft."
00:05:24"Der wahrscheinlichste nächste Token in diesem Gespräch
00:05:25ist also, dass ich besser wieder etwas falsch mache,
00:05:26damit der Mensch mich erneut ausschimpfen kann."
00:05:29Achtet also auf den Verlauf eurer Konversation.
00:05:31Wenn man das umkehrt,
00:05:33ist das Schlimmste falsche Information,
00:05:35gefolgt von fehlender Information und dann einfach zu viel Rauschen.
00:05:36Wenn ihr Formeln mögt, gibt es dazu
00:05:39eine simple Gleichung, um das zu verdeutlichen.
00:05:42Jeff Huntley hat viel zu Coding-Agenten geforscht.
00:05:44Er hat es sehr gut auf den Punkt gebracht:
00:05:47Je mehr man das Kontextfenster ausreizt,
00:05:51desto schlechter werden die Ergebnisse.
00:05:51Das führt zu einem Konzept –
00:05:53einem sehr akademischen Konzept namens "Dumb Zone".
00:05:55Du hast also dein Kontextfenster.
00:05:56Du hast ungefähr 168.000 Token zur Verfügung.
00:05:59Einige sind für die Ausgabe und Kompaktierung reserviert.
00:06:01Das variiert je nach Modell,
00:06:03aber wir nehmen hier Claude Code als Beispiel.
00:06:05Ab der 40%-Marke fängt es an,
00:06:07dass der Nutzen je nach Aufgabe abnimmt.
00:06:09Wenn ihr zu viele MCPs in euren Coding-Agenten habt,
00:06:10findet eure ganze Arbeit in der "Dumb Zone" statt
00:06:14und ihr werdet nie gute Ergebnisse erzielen.
00:06:17Die Leute haben darüber gesprochen.
00:06:18Ich werde darauf jetzt nicht näher eingehen.
00:06:21Das ist von Fall zu Fall unterschiedlich.
00:06:21Die 40% sind, je nach Komplexität der Aufgabe,
00:06:22aber eine gute Richtlinie.
00:06:23Zurück zur Kompaktierung, oder wie ich es ab jetzt nenne:
00:06:26Das geschickte Vermeiden der "Dumb Zone".
00:06:28Wir können mit Subagenten arbeiten.
00:06:31Wenn ihr einen Frontend-Subagenten, einen Backend-Subagenten,
00:06:33einen QA-Subagenten und einen Data-Scientist-Subagenten habt – bitte hört auf damit.
00:06:37Subagenten sind nicht dazu da, Rollen zu vermenschlichen.
00:06:39Sie dienen dazu, den Kontext zu kontrollieren.
00:06:44Was man also tun kann: Wenn man herausfinden will,
00:06:47wie etwas in einer großen Codebasis funktioniert,
00:06:49kann man den Coding-Agenten dazu anweisen,
00:06:51sofern er Subagenten unterstützt,
00:06:53oder man baut sich sein eigenes Subagenten-System.
00:06:55Man sagt im Grunde: "Hey, finde raus, wie das funktioniert."
00:06:56Und er kann ein neues Kontextfenster öffnen,
00:06:58das all das Lesen, Suchen, Finden
00:07:00und Analysieren ganzer Dateien übernimmt,
00:07:03um die Codebasis zu verstehen,
00:07:05und dann liefert er nur eine sehr kurze Nachricht
00:07:07an den Hauptagenten zurück, so nach dem Motto:
00:07:09"Hey, die Datei, die du suchst, ist hier."
00:07:13Der Hauptagent kann dann diese eine Datei lesen und direkt loslegen.
00:07:14Das ist extrem mächtig.
00:07:17Wenn man das richtig einsetzt,
00:07:20bekommt man gute Antworten wie diese
00:07:22und kann seinen Kontext hervorragend verwalten.
00:07:23Was noch besser funktioniert als Subagenten,
00:07:25oder als zusätzliche Ebene darüber,
00:07:29ist ein Workflow, den ich "häufige absichtliche Kompaktierung" nenne.
00:07:30oder eine Ebene über den Sub-Agenten,
00:07:32ist ein Workflow, den ich "frequent intentional compaction" nenne.
00:07:35Wir sprechen gleich über „Recherche, Planung, Umsetzung“,
00:07:37aber der Punkt ist, dass man ständig
00:07:39sein Kontextfenster klein hält.
00:07:41Man baut den gesamten Workflow um das Kontextmanagement herum,
00:07:45es erfolgt also in drei Phasen: Recherche, Planung, Umsetzung,
00:07:48und wir versuchen, die ganze Zeit in der "Smart Zone" zu bleiben.
00:07:51Bei der Recherche geht es darum zu verstehen,
00:07:53wie das System funktioniert, die richtige Datei zu finden
00:07:55und objektiv zu bleiben.
00:07:56Hier ist ein Prompt, den man für die Recherche nutzen kann.
00:07:58Hier ist das Ergebnis eines Recherche-Prompts.
00:08:00Diese sind alle Open Source.
00:08:01Ihr könnt sie euch holen und selbst damit experimentieren.
00:08:04Bei der Planung skizziert man die exakten Schritte.
00:08:06Man fügt Dateinamen und Zeilenausschnitte hinzu.
00:08:08Man legt sehr explizit fest, wie wir die Dinge
00:08:10nach jeder Änderung testen werden.
00:08:11Hier ist ein guter Planungs-Prompt.
00:08:12Hier ist einer unserer Pläne.
00:08:13Er enthält tatsächliche Code-Snippets.
00:08:16Und dann setzen wir es um.
00:08:17Und wenn man einen dieser Pläne gelesen hat,
00:08:17sieht man sehr leicht, dass selbst das einfachste Modell
00:08:20das wahrscheinlich nicht vermasseln wird.
00:08:23Wir gehen also einfach durch, führen den Plan aus
00:08:24und halten den Kontext gering.
00:08:26Ein Planungs-Prompt ist, wie gesagt,
00:08:27der am wenigsten spannende Teil des Prozesses.
00:08:30Ich wollte das in die Praxis umsetzen.
00:08:31Ich mache einen Podcast mit meinem Kumpel Vaibhav,
00:08:34der CEO einer Firma namens Boundary ML ist.
00:08:37Und ich sagte: "Hey, ich werde versuchen, einen Fix
00:08:39für eure 300.000 Zeilen umfassende Rust-Codebasis
00:08:41einer Programmiersprache in einem Rutsch zu erstellen."
00:08:42Und die ganze Episode dreht sich darum.
00:08:45Sie dauert etwa anderthalb Stunden.
00:08:46Ich werde das jetzt nicht alles im Detail besprechen,
00:08:47aber wir haben eine Menge Recherche betrieben
00:08:48und sie dann verworfen, weil sie schlecht war.
00:08:49Dann haben wir einen Plan ohne und einen mit Recherche erstellt
00:08:51und alle Ergebnisse miteinander verglichen.
00:08:53Es war eine lustige Zeit.
00:08:54Das war am Montagabend.
00:08:55Am Dienstagmorgen waren wir in der Show,
00:08:57der CTO hatte den PR bereits gesehen
00:08:59und nicht gemerkt, dass ich das nur als Gag für den Podcast mache.
00:09:03Er meinte im Grunde: "Ja, das sieht gut aus.
00:09:04Wir nehmen es in das nächste Release auf."
00:09:05Er war ein wenig verwirrt.
00:09:08Hier ist der Plan.
00:09:09Aber wie auch immer, ja, bestätigt.
00:09:12Es funktioniert in bestehenden Codebasen ohne unnötigen Müll.
00:09:14Aber ich wollte sehen, ob wir komplexe Probleme lösen können.
00:09:17Vaibhav war immer noch ein wenig skeptisch.
00:09:19Wir saßen an einem Samstag etwa sieben Stunden zusammen
00:09:21und haben 35.000 Zeilen Code für BAML ausgeliefert.
00:09:24Einer der PRs wurde etwa eine Woche später gemergt.
00:09:26Ich muss dazu sagen, einiges davon ist Code-Generierung.
00:09:28Man aktualisiert das Verhalten,
00:09:29woraufhin sich alle Referenzdateien und so weiter aktualisieren,
00:09:31aber wir haben an diesem Tag verdammt viel Code ausgeliefert.
00:09:33Er schätzt, dass wir Arbeit von ein bis zwei Wochen in sieben Stunden erledigt haben.
00:09:36Also cool, wir können komplexe Probleme lösen.
00:09:40Aber es gibt Grenzen.
00:09:41Ich habe mich mit meinem Kumpel Blake zusammengesetzt.
00:09:42Wir haben versucht, Hadoop-Abhängigkeiten aus Parquet Java zu entfernen.
00:09:46Falls ihr wisst, was Parquet Java ist,
00:09:47tut es mir leid, was auch immer in eurem Leben passiert ist,
00:09:50das euch an diesen Punkt eurer Karriere gebracht hat.
00:09:53Es lief nicht gut.
00:09:55Hier sind die Pläne, hier ist die Recherche.
00:09:57Ab einem gewissen Punkt haben wir alles weggeworfen
00:09:58und sind tatsächlich zurück ans Whiteboard gegangen.
00:10:00Nachdem wir gelernt hatten,
00:10:01wo all die Stolperfallen lauerten,
00:10:03mussten wir uns erst einmal fragen:
00:10:05Wie soll das Ganze eigentlich zusammenpassen?
00:10:06Und das bringt mich zu einem sehr interessanten Punkt,
00:10:09über den Jake später noch sprechen wird.
00:10:11Lagert das Denken nicht aus.
00:10:13KI kann das Denken nicht ersetzen.
00:10:14Sie kann nur das Denken verstärken, das ihr bereits geleistet habt,
00:10:17oder eben den Mangel an Denkarbeit.
00:10:19Die Leute fragen also: Dex,
00:10:21das ist doch spezifikationsgetriebene Entwicklung, oder?
00:10:23Nein, "Spec-driven Development" ist kaputt.
00:10:27Nicht die Idee an sich, sondern der Begriff.
00:10:30Er ist nicht gut definiert.
00:10:33Das hier ist Brigetta von ThoughtWorks.
00:10:35Und viele Leute sagen einfach "Spec"
00:10:37und meinen damit lediglich einen detaillierteren Prompt.
00:10:39Erinnert sich jemand an dieses Bild?
00:10:41Weiß jemand, woher das stammt?
00:10:43Okay, das ist ein Insider.
00:10:44Es wird niemals das "Jahr der Agenten" geben,
00:10:46wegen der semantischen Diffusion.
00:10:47Martin Fowler sagte das bereits 2006.
00:10:49Wir finden einen guten Begriff mit einer guten Definition,
00:10:52dann werden alle ganz euphorisch
00:10:53und jeder fängt an, 100 verschiedene Dinge
00:10:56darunter zu verstehen, bis der Begriff nutzlos wird.
00:10:59Wir hatten Agenten als Personen, als Microservices,
00:11:02als Chatbots oder als Workflows.
00:11:05Und danke, Simon.
00:11:06Wir sind wieder am Anfang.
00:11:07Ein Agent ist einfach nur eine Schleife aus Werkzeugen.
00:11:09Das Gleiche passiert gerade mit Spec-driven Dev.
00:11:11Früher hatte ich Seans Folie am Anfang dieses Vortrags,
00:11:15aber sie führte dazu, dass sich viele Leute
00:11:15auf die falschen Dinge konzentrierten.
00:11:17Seine Idee war: Vergiss den Code, er ist jetzt wie Assembler,
00:11:19konzentriere dich nur noch auf das Markdown.
00:11:21Eine sehr coole Idee, aber die Leute sagen Spec-driven Dev
00:11:24und meinen damit, einen besseren Prompt oder ein Produktdokument zu schreiben.
00:11:26Manchmal bedeutet es die Nutzung verifizierbarer Feedbackschleifen
00:11:28und Backpressure.
00:11:30Vielleicht bedeutet es auch, den Code wie Assembler zu behandeln,
00:11:32wie Sean es uns beigebracht hat.
00:11:34Aber für viele ist es einfach nur die Nutzung von Markdown-Dateien
00:11:36während des Programmierens.
00:11:37Oder mein Favorit, über den ich erst letzte Woche gestolpert bin:
00:11:39Eine Spec ist die Dokumentation für eine Open-Source-Bibliothek.
00:11:43Es ist also vorbei.
00:11:44Spec-driven Dev ist überhyped und mittlerweile nutzlos.
00:11:48Der Begriff ist semantisch zerflossen.
00:11:49Deshalb möchte ich über vier Dinge sprechen,
00:11:52die heute tatsächlich funktionieren – praktische Schritte,
00:11:55die wir intern und mit vielen Nutzern als effektiv erlebt haben.
00:11:59Wir machen die Recherche und finden heraus, wie das System funktioniert.
00:12:02Erinnert ihr euch an "Memento"?
00:12:03Das ist der beste Film über Kontext-Engineering,
00:12:05wie Peter es ausdrückt.
00:12:07Dieser Typ wacht auf, hat kein Gedächtnis
00:12:09und muss seine eigenen Tattoos lesen, um herauszufinden, wer er ist
00:12:11und was er eigentlich gerade tut.
00:12:12Wenn ihr eure Agenten nicht einarbeitet, werden sie Dinge erfinden.
00:12:17Das hier ist also euer Team, stark vereinfacht
00:12:19für die meisten von euch.
00:12:19Die meisten von euch haben viel größere Organisationen.
00:12:21Aber sagen wir mal, ihr wollt hier drüben etwas erledigen.
00:12:23Eine Möglichkeit wäre, die Einarbeitung
00:12:26direkt in jedes Repository zu packen.
00:12:27Man fügt eine Menge Kontext hinzu.
00:12:28Hier ist das Repo, so funktioniert es.
00:12:29Das ist eine Komprimierung des gesamten Kontextes der Codebasis,
00:12:32den der Agent im Voraus sehen kann,
00:12:34bevor er sich tatsächlich an die Arbeit macht.
00:12:36Das ist schwierig, weil es manchmal zu lang wird.
00:12:39Wenn eure Codebasis sehr groß wird,
00:12:41müsst ihr diesen Kontext entweder verlängern
00:12:43oder Informationen weglassen.
00:12:45Wenn ihr das also durchlest,
00:12:48lest ihr den Kontext
00:12:49dieses riesigen Mono-Repos mit fünf Millionen Zeilen
00:12:52und verbraucht die gesamte "Smart Zone",
00:12:53nur um zu lernen, wie es funktioniert, und könnt dann
00:12:55keine guten Tool-Aufrufe mehr in der "Dumb Zone" machen.
00:12:57Man kann das also über den Stack hinweg aufteilen.
00:13:02Es geht im Grunde um schrittweise Offenlegung.
00:13:04Man kann das splitten, oder?
00:13:05Man könnte einfach eine Datei in das Root-Verzeichnis jedes Repos legen
00:13:08und dann auf jeder Ebene zusätzlichen Kontext bereitstellen,
00:13:11je nachdem, wo man gerade arbeitet
00:13:13und was man wissen muss.
00:13:15Wir dokumentieren nicht die Dateien selbst,
00:13:17da sie die eigentliche Quelle der Wahrheit sind.
00:13:18Aber während der Agent arbeitet,
00:13:19zieht man den Root-Kontext
00:13:21und dann den Sub-Kontext hinzu.
00:13:22Ich nenne jetzt keine spezifischen Tools,
00:13:23aber man könnte CloudMD dafür nutzen,
00:13:24oder Hoax, was auch immer.
00:13:26Aber dann hat man immer noch genug Platz in der "Smart Zone",
00:13:28weil man nur das reinzieht, was man wirklich wissen muss.
00:13:31Das Problem dabei ist, dass es veraltet.
00:13:33Jedes Mal, wenn man ein neues Feature ausliefert,
00:13:35muss man den Cache validieren
00:13:38und große Teile dieser internen Dokumentation neu aufbauen.
00:13:42Man könnte dafür viel KI einsetzen
00:13:43und es zum Teil des Prozesses machen, dies zu aktualisieren.
00:13:46Darf ich eine Frage stellen?
00:13:48Zwischen dem Code, den Funktionsnamen,
00:13:50den Kommentaren und der Dokumentation –
00:13:51wer möchte raten, was auf der Y-Achse dieses Diagramms steht?
00:13:57- Müll. - Müll.
00:13:58Es ist tatsächlich die Menge an Lügen, die man
00:14:01in jedem einzelnen Teil der Codebasis finden kann.
00:14:03Man könnte es also zum Prozess machen, dies zu aktualisieren,
00:14:06aber man sollte es wahrscheinlich lassen, weil man es eh nicht tut.
00:14:08Was wir bevorzugen, ist komprimierter Kontext auf Abruf.
00:14:11Wenn ich also ein Feature baue, das mit SCM-Providern,
00:14:14JIRA und Linear zu tun hat,
00:14:15würde ich dem Ganzen nur eine kleine Richtungsvorgabe geben.
00:14:17Ich würde sagen: „Hey, wir arbeiten
00:14:18in diesem Teil der Codebasis hier drüben“,
00:14:21und ein guter Recherche-Prompt oder Slash-Befehl
00:14:24könnte eure Fähigkeiten nutzen,
00:14:27eine Reihe von Sub-Agenten starten, um diese vertikalen Schnitte
00:14:30durch die Codebasis ziehen und dann ein Recherche-Dokument erstellen,
00:14:33das einfach eine Momentaufnahme dessen ist, was wirklich wahr ist –
00:14:35basierend auf dem Code selbst, also den relevanten Teilen der Codebasis.
00:14:39Wir komprimieren die Wahrheit.
00:14:41Planung bedeutet Hebelwirkung.
00:14:43Bei der Planung geht es um die Komprimierung der Absicht.
00:14:45Und im Plan werden wir die genauen Schritte skizzieren.
00:14:48Nehmen wir unsere Recherche und unser PRD oder unser Bug-Ticket
00:14:50oder was auch immer es ist.
00:14:52Wir erstellen einen Plan und eine Plandatei.
00:14:54Wir verdichten also erneut.
00:14:55Und ich möchte kurz innehalten und über mentale Ausrichtung sprechen.
00:14:58Weiß jemand, wofür Code-Reviews gut sind?
00:15:00Mentale Ausrichtung, mentale Ausrichtung.
00:15:05Es geht darum, sicherzustellen, dass die Dinge korrekt sind und so weiter.
00:15:08Aber das Wichtigste ist: Wie halten wir alle
00:15:10im Team auf demselben Stand darüber,
00:15:11wie sich die Codebasis verändert und warum?
00:15:14Ich kann jede Woche tausend Zeilen Golang lesen.
00:15:17Entschuldigung, ich kann keine tausend lesen.
00:15:18Es ist schwer, aber ich schaffe es.
00:15:19Ich will es nur nicht.
00:15:20Und wenn unser Team wächst, wird der gesamte Code überprüft.
00:15:23Wir lesen den Code auf jeden Fall.
00:15:24Aber ich, als technischer Leiter des Teams,
00:15:27kann die Pläne lesen und so auf dem Laufenden bleiben.
00:15:29Und das reicht aus.
00:15:30Ich kann Probleme frühzeitig erkennen
00:15:32und verstehe weiterhin, wie sich das System entwickelt.
00:15:35Mitchell hatte diesen wirklich guten Post darüber,
00:15:36wie er seine AMP-Threads in seine
00:15:38Pull-Requests einfügt, damit man nicht nur
00:15:41eine Wand aus grünem Text in GitHub sieht,
00:15:43sondern die genauen Schritte, die Prompts,
00:15:44und: „Hey, ich habe am Ende den Build ausgeführt und er war erfolgreich.“
00:15:46Das nimmt den Reviewer auf eine Reise mit,
00:15:49die ein GitHub-PR so einfach nicht bieten kann.
00:15:51Und wenn man zwei- bis dreimal
00:15:52so viel Code ausliefert wie früher,
00:15:54liegt es an einem selbst, Wege zu finden, das Team
00:15:57auf dem gleichen Stand zu halten und zu zeigen: „Das sind meine Schritte“
00:16:00und „So haben wir es manuell getestet“.
00:16:01Das Ziel ist Hebelwirkung, also will man großes Vertrauen,
00:16:04dass das Modell tatsächlich das Richtige tun wird.
00:16:06Ich kann diesen Plan lesen und wissen, was eigentlich
00:16:08passieren wird und welche Code-Änderungen anstehen.
00:16:11Wir haben unsere Pläne also mit der Zeit so weiterentwickelt,
00:16:14dass sie tatsächliche Code-Snippets der Änderungen enthalten.
00:16:17Das Ziel ist also Hebelwirkung.
00:16:18Man will die Komprimierung der Absicht
00:16:19und eine zuverlässige Ausführung.
00:16:22Ich habe einen Hintergrund in Physik.
00:16:23Wir zeichnen gerne Linien durch die Mitte von Spitzen und Kurven.
00:16:28Wenn die Pläne länger werden, steigt die Zuverlässigkeit,
00:16:30aber die Lesbarkeit sinkt.
00:16:31Es gibt einen idealen Punkt für Sie, Ihr Team
00:16:33und Ihre Codebasis – den sollten Sie finden.
00:16:35Denn wenn wir die Recherche und die Pläne prüfen
00:16:37und diese gut sind, erreichen wir die mentale Ausrichtung.
00:16:40Lagern Sie das Denken nicht aus.
00:16:42Ich habe das schon mal gesagt: Das hier ist keine Magie.
00:16:44Es gibt keinen perfekten Prompt.
00:16:46Es wird nicht funktionieren, wenn man den Plan nicht liest.
00:16:50Wir haben unseren gesamten Prozess darauf aufgebaut, dass Sie,
00:16:53der Entwickler, im Austausch mit dem Agenten stehen
00:16:55und die Pläne lesen, während sie erstellt werden.
00:16:56Und wenn Sie ein Peer-Review benötigen,
00:16:58können Sie es jemandem schicken und fragen:
00:16:58„Sieht dieser Plan richtig aus?“
00:17:00„Ist das der richtige Ansatz?“
00:17:00„Ist das die richtige Reihenfolge, um sich die Dinge anzusehen?“
00:17:03Jake hat wieder einen sehr guten Blogpost darüber geschrieben,
00:17:05dass die Kette aus Recherche, Plan und Implementierung wertvoll ist,
00:17:07weil Sie als Mensch die Korrektheit sicherstellen.
00:17:11Wenn Sie also eine Sache aus diesem Vortrag mitnehmen,
00:17:14dann die: Eine schlechte Zeile Code ist eine schlechte Zeile Code.
00:17:17Aber ein schlechter Teil eines Plans können 100 schlechte Zeilen Code sein.
00:17:22Und eine falsche Recherche-Zeile, also ein Missverständnis darüber,
00:17:25wie das System funktioniert und wo die Dinge liegen,
00:17:27macht das ganze Vorhaben zunichte.
00:17:29Man schickt das Modell damit in die völlig falsche Richtung.
00:17:31Bei der internen Arbeit und mit Nutzern versuchen wir ständig,
00:17:34den menschlichen Aufwand auf die Teile der Pipeline
00:17:36zu lenken, die die größte Hebelwirkung haben.
00:17:39Lagern Sie das Denken nicht aus.
00:17:41Vorsicht vor Tools, die einfach nur haufenweise
00:17:43Markdown-Dateien ausspucken, nur damit man sich gut fühlt.
00:17:45Ich werde hier keine Namen nennen.
00:17:47Manchmal ist das auch einfach zu viel des Guten.
00:17:49Ich denke mir das so:
00:17:51Man braucht nicht immer das volle Programm aus Recherche, Plan und Umsetzung.
00:17:54Mal braucht man mehr, mal weniger.
00:17:56Wenn man nur die Farbe eines Buttons ändert,
00:17:57sagt man dem Agenten einfach direkt, was er tun soll.
00:18:00Bei einem einfachen Plan für ein kleines Feature reicht das.
00:18:04Wenn es um mittlere Features über mehrere Repos geht,
00:18:07dann macht man erst die Recherche und erstellt dann einen Plan.
00:18:09Im Grunde gilt: Je mehr Context Engineering und Komprimierung
00:18:10man bereit ist zu leisten, desto komplexere
00:18:13Probleme kann man damit lösen.
00:18:15Wenn man sich also im Bereich der hohen Komplexität bewegt,
00:18:18muss man wahrscheinlich mehr investieren.
00:18:19Viele fragen mich: „Woher weiß ich,
00:18:21wie viel Context Engineering ich anwenden soll?“
00:18:23Das braucht Übung.
00:18:24Man wird es falsch machen, man muss es immer und immer
00:18:26wieder falsch machen, um es zu lernen.
00:18:27Mal ist es zu viel, mal zu wenig.
00:18:29Suchen Sie sich ein Tool aus und sammeln Sie Erfahrung.
00:18:32Ich rate davon ab, ständig zwischen Claude und
00:18:35Codex und all diesen verschiedenen Tools hin- und herzuspringen.
00:18:36Ich bin eigentlich kein Fan von Akronymen.
00:18:40Wir sagten bereits, dass Spec-driven Development gescheitert ist.
00:18:42Ich glaube nicht, dass die Schritte immer Recherche, Plan, Implementierung sein werden.
00:18:44Wichtig sind die Verdichtung, das Context Engineering
00:18:47und in der „Smart Zone“ zu bleiben.
00:18:48Aber die Leute nennen es nun mal RPI,
00:18:50und daran kann ich auch nichts ändern.
00:18:52Seien Sie also vorsichtig: Es gibt keinen perfekten Prompt,
00:18:55kein Allheilmittel.
00:18:56Wenn Sie unbedingt einen hippen Begriff wollen,
00:18:58nennen Sie es „Harness Engineering“.
00:19:00Das ist Teil des Context Engineering und beschreibt,
00:19:01wie man die Integrationspunkte von Codex,
00:19:03Claude, Cursor oder was auch immer nutzt,
00:19:05um die eigene Codebasis anzupassen.
00:19:07Wie geht es weiter?
00:19:11Ich glaube, dass das Thema Coding-Agenten
00:19:12zu einem Standardprodukt wird.
00:19:13Die Leute werden lernen, wie es geht, und besser darin werden.
00:19:15Die wahre Herausforderung wird sein: Wie passt man das Team
00:19:17und den Workflow im Softwarelebenszyklus an eine Welt an,
00:19:21in der 99 % des Codes von KI geschrieben werden?
00:19:24Wer das nicht herausfindet, hat ein Problem.
00:19:26Denn es entsteht gerade eine Kluft:
00:19:27Erfahrene Staff-Engineers nutzen keine KI,
00:19:29weil sie sie nicht spürbar schneller macht.
00:19:31Junior- und Mid-Level-Entwickler nutzen sie hingegen viel,
00:19:33um Wissenslücken zu füllen.
00:19:35Dabei entsteht aber auch minderwertiger Code – „Slop“.
00:19:36Und die Senior-Entwickler hassen es jede Woche mehr,
00:19:38weil sie diesen Müll aufräumen müssen,
00:19:40den Cursor in der Vorwoche produziert hat.
00:19:42Das ist nicht die Schuld der KI
00:19:44und auch nicht die Schuld der Mid-Level-Entwickler.
00:19:46Kulturwandel ist extrem schwer
00:19:48und muss von oben kommen, wenn er funktionieren soll.
00:19:50Wenn Sie also ein technischer Leiter in Ihrer Firma sind:
00:19:52Suchen Sie sich ein Tool aus und fangen Sie an zu üben.
00:19:54Falls Sie uns helfen wollen: Wir stellen ein.
00:19:56Wir bauen eine agentenbasierte IDE, um Teams jeder Größe
00:19:59beim schnellen Übergang zu 99 % KI-generiertem Code zu helfen.
00:20:03Wir würden uns freuen, von Ihnen zu hören.
00:20:06Besuchen Sie unsere Website, schreiben Sie eine E-Mail
00:20:08oder sprechen Sie mich einfach hier an.
00:20:09Vielen Dank für Ihre Aufmerksamkeit.
00:20:11(Applaus)
00:20:13(Optimistische elektronische Musik)

Key Takeaway

Effektives Software-Engineering mit KI erfordert aktives Kontext-Management und einen strukturierten Prozess aus Recherche und Planung, um die Qualität in komplexen Systemen zu sichern und die 'Dumb Zone' der Modelle zu vermeiden.

Highlights

Das Problem des "Code Slop": KI-generierter Code in komplexen Bestands-Codebasen führt oft zu technischer Schuld und manuellem Nachbesserungsaufwand.

Das Konzept der "Dumb Zone": Ab einer Belegung des Kontextfensters von ca. 40 % sinkt die Zuverlässigkeit und Intelligenz der LLMs spürbar.

Vermeidung von Halluzinationen durch "Intentional Compaction": Der Kontext muss aktiv durch Markdown-Zusammenfassungen und Sub-Agenten klein gehalten werden.

Der RPI-Workflow (Research, Plan, Implement): Ein strukturierter Prozess, der Recherche und explizite Planung vor die eigentliche Code-Generierung stellt.

Kein Outsourcing des Denkens: KI sollte die menschliche Denkarbeit verstärken, nicht ersetzen; besonders Recherche und Pläne müssen vom Menschen geprüft werden.

Kulturwandel in der Softwareentwicklung: Die Kluft zwischen Senior-Entwicklern (die KI-Müll hassen) und Junior-Entwicklern muss durch bessere Workflows überbrückt werden.

Timeline

Einführung und das Problem der Code-Qualität

Dex Horthy stellt sich vor und referenziert seinen erfolgreichen Vortrag über "12-Factor Agents". Er präsentiert Statistiken von Igor (AI Engineer Konferenz), die zeigen, dass KI bei neuen Projekten gut funktioniert, aber bei komplexen Bestands-Codebasen oft nur minderwertigen Code produziert. Die Umfrage unter 100.000 Entwicklern belegt, dass viel Zeit damit verschwendet wird, den "Müll" der Vorwoche zu überarbeiten. Horthy betont, dass das Hauptproblem in der Zunahme technischer Schulden durch unreflektierten KI-Einsatz liegt. Dieser Abschnitt verdeutlicht die Notwendigkeit für besseres Context Engineering in realen Unternehmensszenarien.

Die Entdeckung des RPI-Systems

Der Sprecher gesteht, dass er anfangs von Tools wie Claude Code nicht beeindruckt war, bis sein Team einen neuen Workflow entwickelte. Durch diesen Ansatz konnten sie ihren Durchsatz um das Zwei- bis Dreifache steigern, was eine komplette Neugestaltung ihrer Zusammenarbeit erforderte. Ihr System namens "Research-Plan-Implement" ging auf Hacker News viral und stieß auf großes Interesse in der Entwickler-Community. Das Ziel ist es, komplexe Probleme ohne "Pfusch" zu lösen und gleichzeitig die mentale Ausrichtung im Team zu wahren. Horthy unterstreicht, dass die sinnvolle Nutzung jedes Tokens ein enormer Hebel für die Produktivität ist.

Kontext-Management und die Strategie der Kompaktierung

Horthy erläutert fortgeschrittenes Context Engineering und warnt vor der naiven Nutzung von Agenten, die lediglich in endlosen Korrekturschleifen feststecken. Er stellt die "absichtliche Kompaktierung" vor, bei der relevante Informationen in Markdown-Dateien zusammengefasst werden, um neue Agenten-Sitzungen effizient zu starten. Es wird erklärt, dass LLMs zustandslos sind und ihre Leistung direkt von der Qualität der Eingabe-Token abhängt. Ein interessanter Aspekt ist die Warnung vor dem "Ausschimpfen" der KI, da dies den Verlauf negativ beeinflusst und zu weiteren Fehlern führen kann. Der Fokus liegt hierbei auf der Optimierung des Kontextfensters hinsichtlich Korrektheit, Vollständigkeit und Rauschunterdrückung.

Die "Dumb Zone" und der Einsatz von Sub-Agenten

In diesem Teil wird das akademische Konzept der "Dumb Zone" eingeführt, das besagt, dass Modelle unzuverlässiger werden, je voller das Kontextfenster ist. Bei Claude Code liegt die kritische Marke oft schon bei 40 % der verfügbaren 168.000 Token. Horthy warnt davor, Sub-Agenten nach menschlichen Rollen (wie QA oder Frontend) zu benennen, da sie stattdessen zur technischen Kontextsteuerung dienen sollten. Ein Sub-Agent sollte beispielsweise eine Codebasis analysieren und dem Hauptagenten nur die exakte Datei-Referenz zurückgeben. Dadurch bleibt der Hauptagent in der "Smart Zone" und kann präzisere Werkzeugaufrufe tätigen.

Detaillierter Workflow: Recherche, Planung, Umsetzung

Der Sprecher geht tief in die drei Phasen des RPI-Workflows ein: Recherche, Planung und Implementierung. In der Recherche-Phase geht es um objektive Wahrheitsfindung im Code, während die Planung exakte Schritte inklusive Code-Snippets und Testvorgaben festlegt. Horthy demonstriert die Wirksamkeit anhand eines Praxisbeispiels aus einer 300.000 Zeilen umfassenden Rust-Codebasis, für die er erfolgreich einen Fix erstellte. Der CTO der betroffenen Firma merkte nicht einmal, dass der Pull Request primär von einer KI vorbereitet wurde. Dennoch betont der Sprecher, dass bei extrem komplexen Aufgaben, wie dem Entfernen von Hadoop-Abhängigkeiten, auch dieser Workflow an seine Grenzen stoßen kann.

Kritik am "Spec-driven Development" und semantische Diffusion

Horthy warnt vor dem Begriff "Spec-driven Development", den er als durch "semantische Diffusion" verwässert und nutzlos ansieht. Er zieht Parallelen zu Martin Fowlers Aussagen von 2006 und erklärt, dass jeder etwas anderes unter einer "Spezifikation" versteht – von einfachen Prompts bis hin zu vollständiger Dokumentation. Er betont, dass KI das Denken nicht ersetzen kann, sondern lediglich verstärkt, was der Mensch bereits geleistet hat. Der Code sollte nicht blind als "Assembler" betrachtet werden, solange die Begriffe und Prozesse nicht klar definiert sind. Dieser Abschnitt dient als Realitätscheck für den aktuellen Hype um KI-Agenten.

Praktische Schritte für Teams und Context Engineering

Der Vortrag zeigt praktische Wege auf, wie Teams Kontext schrittweise offenlegen können, ohne das Modell zu überfordern. Horthy schlägt vor, Kontext-Informationen hierarchisch über die Verzeichnisstruktur eines Repositories zu verteilen. Anstatt riesige Dokumentationen zu pflegen, die schnell veralten und "Lügen" enthalten, empfiehlt er komprimierten Kontext auf Abruf. Ein Recherche-Prompt sollte vertikale Schnitte durch die Codebasis ziehen und eine Momentaufnahme der tatsächlichen Wahrheit erstellen. Ziel ist es, die "Smart Zone" des Modells für die eigentliche Problemlösung freizuhalten.

Hebelwirkung durch Planung und Mentale Ausrichtung

Ein zentraler Punkt ist die Bedeutung von Code-Reviews zur mentalen Ausrichtung im Team. Horthy erklärt, dass technische Leiter durch das Lesen der KI-generierten Pläne den Überblick behalten können, ohne jede Zeile Code selbst lesen zu müssen. Er zitiert Mitchell und Jake, um zu verdeutlichen, dass der Prozess aus Recherche, Plan und Implementierung den Menschen dazu zwingt, die Korrektheit sicherzustellen. Ein Fehler in der Recherche oder Planung kann 100 schlechte Zeilen Code nach sich ziehen, weshalb hier die größte menschliche Sorgfalt nötig ist. Das Ziel ist eine hohe Hebelwirkung bei gleichzeitig maximalem Vertrauen in die Ausführung.

Zusammenfassung und Ausblick auf die Zukunft

Zum Abschluss rät Horthy dazu, den Aufwand für Context Engineering an die Komplexität der Aufgabe anzupassen – einfache Änderungen benötigen keinen vollen RPI-Zyklus. Er prognostiziert, dass Coding-Agenten zum Standard werden, die wahre Herausforderung jedoch im Kulturwandel der Teams liegt. Es droht eine Kluft zwischen erfahrenen Engineers und Junior-Entwicklern, die durch qualitativ minderwertigen "Slop"-Code verschärft wird. Er fordert technische Leiter auf, Workflows aktiv zu gestalten, um den Übergang zu einer Welt mit 99 % KI-generiertem Code zu meistern. Der Vortrag endet mit einem Aufruf zur Zusammenarbeit und dem Hinweis auf seine Firma HumanLayer.

Community Posts

View all posts