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)