- Ein Beitrag, der Prinzipien des Context Engineering und praktische Workflows vorstellt, um mit aktuellen Sprachmodellen in großen Produktions-Codebasen echte Ergebnisse zu erzielen
- Der Kern ist Frequent Intentional Compaction: Kontext wird über den gesamten Entwicklungsprozess hinweg strukturiert und komprimiert, um die Qualität der Entscheidungen des Agenten und seine Trajektorie zu stabilisieren
- In einem Drei-Phasen-Modell aus Research → Plan → Implement werden vorbereitende Research-Artefakte und Planungsdokumente erstellt, und menschliche Reviews werden an Hebelpunkten mit hoher Wirkung platziert, um Slop und Nacharbeit zu reduzieren
- An realen Beispielen aus dem Rust-basierten BAML mit 300.000 LOC – darunter Bugfixes sowie Unterstützung für Cancellation/WASM – wird gezeigt, dass der Ansatz auch in Brownfield-Umgebungen bei komplexen Aufgaben kurzfristig funktioniert
- Fazit: AI Coding ist kein Spielzeug, sondern präzise Engineering-Handarbeit, und ein Prozess-/Kulturwandel auf Teamebene ist der Schlüssel zum Wettbewerbsvorteil
Hintergrund: Grenzen von KI in komplexen Codebasen und das Problembewusstsein
- Die meisten Entwickler wissen, dass AI-Coding-Tools in echten Produktions-Codebasen oft nicht so gut funktionieren wie erhofft
- Es gibt Forschungsergebnisse, wonach AI-Coding-Tools in großen Codebasen und bei komplexen Aufgaben die Produktivität sogar senken können
- Laut Stanford-Studien besteht ein erheblicher Teil des von KI hinzugefügten Codes aus Wiederholungsarbeit, bei der zuvor von KI erzeugter mangelhafter Code erneut überarbeitet werden muss
- AI-Coding-Agenten sind bei neuen Projekten oder kleinen Änderungen effektiv, können in großen Codebasen aber die Produktivität von Entwicklern sogar verringern
- Deshalb ist die Reaktion in der Praxis oft vorsichtig: „Im Moment ist das schwierig – wenn intelligentere Modelle kommen, vielleicht.“
- Bei der Anwendung von Context Engineering auf eine große Rust-Codebasis mit 300.000 LOC zeigte sich jedoch, dass selbst mit bestehenden Modellen sowohl Produktivität als auch Qualität das Marktniveau übertreffen können
- Entscheidend ist frequent intentional compaction: der Kontext, den die KI erhält, wird während des gesamten Entwicklungsprozesses strukturiert und kontrolliert gehalten
- Letztlich ist „AI Coding“ ein Bereich, der technisches Handwerk erfordert
Ideelle Grundlage: „Specs are the new code“ und Produktivitätsforschung
- Zwei Vorträge auf der AI Engineer 2025 führten zu einem veränderten Denkansatz
- Im Vortrag Sean Grove's "Specs are the new code" heißt es sinngemäß: Weg von konversationellen Prompts, hin dazu, Spezifikationen als Code zu bewahren
- Prompts zu verwerfen und nur den erzeugten Code zu committen wird mit dem Einchecken reiner Binärdateien ohne Quellcode verglichen
- Die Stanford-Studie zu den Auswirkungen von KI auf die Produktivität von Entwicklern deutet darauf hin, dass KI zwar kurzfristig mehr Output erzeugen kann, der Nettoeffekt durch Qualitätsverlust und Nacharbeit aber sinkt
- Die Analyse von Commits von 100.000 Entwicklern zeigte, dass AI-Tools mehr Nacharbeit verursachen und damit Produktivitätsgewinne ausgleichen können
- In Greenfield-Szenarien ist der Effekt positiv, in Brownfield-Umgebungen und bei schwierigen Aufgaben tritt dagegen häufig das Gegenteil ein
Prinzip: Das Konzept von Frequent Intentional Compaction
- Das Kontextfenster wird konsequent bei 40–60 % gehalten; verfolgt wird eine Strategie kontinuierlicher Verdichtung, die Überfrachtung, Auslassungen und Fehlinformationen minimiert
- Komprimiert werden dabei Rauschen wie Dateisuch-Logs, Trace-Ausgaben zu Codeflüssen, Änderungshistorien, Test-/Build-Logs und große JSON-Dateien
- Die Artefakte jeder Phase werden als strukturierte Artefakte hinterlassen, um die Qualität der Eingaben für den nächsten Turn sicherzustellen
- Beispiel: ein Progress-Dokument mit Fortschrittszusammenfassung, Zielen und Vorgehen, abgeschlossenen Schritten sowie dem aktuellen Fehlerpunkt
Workflow: Research → Plan → Implement
- In der Phase Research werden relevante Dateien, Abläufe und Ursachenhypothesen untersucht und in einem kompakten Research-Dokument festgehalten
- Bei Bedarf übernehmen Sub-Agenten die Erkundung des Umfangs und die Zusammenfassung in frischem Kontext
- In der Phase Plan wird ein Implementierungsplan erstellt, der Ziel-Dateien, Art der Änderungen sowie Validierungs- und Testverfahren detailliert beschreibt
- Der Plan dient als Prüfstelle mit hohem Hebel, noch vor dem eigentlichen Code-Review
- In der Phase Implement wird der Plan schrittweise umgesetzt; nach jeder verifizierten Etappe wird der Status wieder in das Planungsdokument zurückkomprimiert und dort fortgeschrieben
- Bei komplexen Aufgaben erfolgt an jedem Zwischenzusammenfluss eine Neuordnung des Kontexts
Anti-Patterns und schrittweise Reifung
- Ein naiver Ansatz führt in chatbasierten Abläufen dazu, dass der Kontext verunreinigt wird und Schleifen aus Entschuldigungen oder thematische Entgleisungen entstehen
- Etwas besser sind Session-Resets und zusätzliche Instruktions-Prompts, aber die grundlegende Kontrolle des Rauschens bleibt unzureichend
- Intentional Compaction ist ein besserer Ansatz, bei dem Fortschrittszusammenfassungen in Dateien und Commit-Messages genutzt werden, um den Kontext neu aufzubauen
- Es werden Beispiele für ideale Kompressionsformate gezeigt; Ziele sind die Optimierung von Korrektheit/Vollständigkeit/Größe/Trajektorie
Technische Perspektive auf Kontextoptimierung
- LLMs sind zustandslose Funktionen, daher hängt die Qualität vollständig vom Eingabekontext ab
- Die Reihenfolge der schlimmsten Probleme lautet: Fehlinformationen > Auslassungen > zu viel Rauschen
- Je kleiner der Kontext, desto besser; entscheidend ist daher eine Verdichtung, die mit minimalem Input maximale Konsistenz erreicht
- Erwähnt werden auch alternative Blickwinkel wie einfache loop-basierte Agent-Ausführungsstrategien (z. B. der „Ralph“-Prozess)
Die Rolle von Sub-Agenten: keine Rollenspiele für Menschen, sondern Kontextkontrolle
- Sub-Agenten übernehmen Suchen/Zusammenfassen/Ordnen in einem unabhängigen Kontext und halten so das Fenster des Hauptagenten sauber
- Ideale Antworten kommen in Form strukturierter komprimierter Artefakte zurück, die Ziel/Status/Pfad enthalten
- Durch Sub-Agenten werden Explorationskosten lokalisiert und die Fokussierung des Arbeitskontexts erhöht
Fall 1: BAML-Bugfix geht im ersten Anlauf durch
- Für BAML mit 300.000 LOC in Rust wird ein Fall vorgestellt, in dem ein Neueinsteiger innerhalb weniger Stunden einen Bugfix-PR einreichte und genehmigt bekam
- Das Research-Dokument wurde mehrfach iteriert, um die Qualität zu erhöhen; die abschließende Implementierung auf Basis des finalen Plans schaffte den First-Pass-Erfolg
- Damit wurden mehrere Zielsetzungen erfüllt, darunter Brownfield-Tauglichkeit, Beseitigung von Slop und Wahrung der Ausrichtung
Fall 2: Unterstützung für Cancellation/WASM in BAML, 35k LOC
- Es wird eine größere Änderung demonstriert, bei der zwei Personen in 7 Stunden Unterstützung für Cancellation und WASM-Kompilierung ergänzten
- Laut Teamschätzung wurde Arbeit im Umfang von jeweils 3–5 Tagen durch die Pipeline aus Research/Plan/Implement stark verkürzt
- Einige PRs wurden sofort gemergt, andere blieben als funktionierende Demos offen und zeigten damit, dass auch hochkomplexe Aufgaben lösbar sind
Aus Misserfolgen und Grenzen lernen
- Der Versuch, in Parquet Java die Hadoop-Abhängigkeit zu entfernen, blieb wegen unzureichender Analyse des Dependency-Trees ein Fehlschlag
- Fazit: Nicht jedes Problem lässt sich mit 7 Stunden Prompting lösen; die Beteiligung von Domain-Experten ist nötig
- Der Hebeleffekt menschlicher Reviews steigt in der Reihenfolge Research > Plan > Code; eine einzige falsche Zeile im Research kann sich zu Tausenden fehlerhaften Zeilen auswachsen
Dokumente zuerst, für Team-Alignment
- Es wird die Sicht vertreten, dass der Kern von Code-Reviews darin liegt, mentales Alignment aufrechtzuerhalten
- Eine Kette großer PRs kann zum Verlust des Produktverständnisses im Team und zu Unsicherheit führen; mit Specs/Plänen/Research sinken die Kosten für Alignment
- Ingenieure können ein 200-Zeilen-Planungsdokument häufiger und präziser lesen als 2.000 Zeilen Code
- Auch bei Issues in unbekannten Bereichen kann ein Research-Prompt schnell Orientierung geben
Zusammenfassung und Kostenstruktur
- Alle Zielsetzungen wurden erreicht: Brownfield-Kompatibilität, Lösen komplexer Probleme, Minimierung von Slop und Wahrung des Team-Alignments
- Aus Betriebskostensicht arbeitet ein dreiköpfiges Team derzeit mit monatlichen Opus-Token-Kosten von etwa 12.000 USD
- Trotz Ausnahmen wird betont, dass sich die Methode insgesamt als funktionierendes Vorgehensmodell etabliert hat
Kommende Veränderungen und Produktisierung
- Coding-Agenten werden zur Commodity werden; die eigentliche Herausforderung liegt in der Transformation von Organisation und Workflow
- In einer Welt, in der KI 99 % des Codes schreibt, wird eine grundlegende Neugestaltung der Zusammenarbeit zum entscheidenden Wettbewerbsfaktor
- Zur Unterstützung wurde ein „Post-IDE“-Tool namens CodeLayer als Private Beta vorgestellt
- Es versteht sich als Superhuman for Claude Code und beschleunigt eine spec-first agentische Entwicklung
3 Kommentare
Werbeende...
Abschließend folgt die Vorstellung eines Dienstes namens CodeLayer ...
Hacker-News-Kommentare
Interessanter Lesestoff, und es waren auch frische Ideen dabei. Aber ich halte solche Behauptungen für problematisch. Sean prognostiziert, dass AI sich so weit entwickeln wird, dass Spezifikationsdokumente in Zukunft der eigentliche Code sein werden. Er behauptet, dass Menschen in den nächsten zwei Jahren Python-Dateien in einer IDE ungefähr so oft prüfen werden, wie man heute einen Hex-Editor öffnet, um Assembler anzusehen. Er sagt, es habe sich anfangs unangenehm angefühlt, aber inzwischen habe er akzeptiert, statt den Code in PRs Zeile für Zeile zu lesen lieber auf Tests zu fokussieren und die Spezifikation als wahre Quelle zu betrachten. Wegen des Non-Determinismus von LLMs kann man jedoch, egal wie gut der Prompt formuliert ist, nicht immer eine vernünftige Implementierung erwarten. Compiler sind deterministisch, und selbst wenn es Bugs gibt, lassen sie sich reproduzieren und debuggen — bei LLMs ist das nicht so
Selbst bei der Zusammenarbeit mit Junior-Entwicklern ist die Implementierung bis zu einem gewissen Grad deterministisch. Bei AI-Modellen kommen dagegen selbst bei klaren Anweisungen wiederholt völlig unterschiedliche Implementierungen heraus
Interessant ist, dass Spezifikationsdokumente selbst in Wahrheit bereits nicht deterministisch sind. Wenn man Anforderungen auf Englisch so formulieren will, dass sie von niemandem missverstanden werden können, endet man letztlich bei einer Programmiersprache
Ich teile die Sorge: „Ein Prompt kann perfekt sein, und trotzdem gibt es nicht einmal eine Garantie, dass ein LLM ihn in eine vernünftige Implementierung übersetzt.“ Eher ist es so, dass natürlichsprachliche Prompts oft inhärent mehrdeutig und unvollständig sind. Deshalb ist das ein guter Ansatz dort, wo kreative Ergebnisse gewünscht sind, aber wenn natürliche Sprache zur Definition von Software-Anforderungen geeignet wäre, dann hätte Software Engineering das Problem schon vor Jahrzehnten gelöst. Ich war von LLMs begeistert, aber zu glauben, man könne damit alle Probleme lösen, ist überzogen. Bei Anforderungsspezifikationen fühlt es sich an wie die alten Versuche mit formalen Systemen und mathematischer Verifikation, nur vom entgegengesetzten Ende her. Selbst wenn auch das teilweise scheitert, ist es ein Experiment, das neue Einsichten in die Softwareentwicklung bringen kann. In manchen Domänen wird echter Wert entstehen, in anderen könnte es komplett verworfen werden. Spannende Zeiten
Tatsächlich schreiben die wenigsten Leute überhaupt klare und detaillierte technische Spezifikationen oder Dokumentation. Und selbst wenn es sie gibt, glaube ich nicht, dass das innerhalb von zwei Jahren zum Mainstream wird. Würde ein technischer Dokumentationsautor, der Software Engineering wirklich tief versteht, zufrieden sein, dem AI-Agenten nur gute Prompts zu geben, ohne selbst den Code anzusehen? Ich glaube nicht. Das kommt dem typischen Denken nahe, bei dem Ingenieure Menschen wie Maschinen behandeln
Auch die Behauptung „Dank Compilern muss man beim Build nicht jedes Mal im Hex-Editor Assembler ansehen“ stimmt zwar insofern, als die Tools besser geworden sind, aber in der HPC-Forschung war es tatsächlich oft üblich, Assembler direkt auseinanderzunehmen, etwa mit Intel VTune, um zu prüfen, ob der Compiler wichtige Schleifen korrekt vektorisiert hat
Ich habe dieses Muster in zwei sehr unterschiedlichen Codebasen verwendet. Die eine war ein großes monolithisches Apache-Airflow-Repository mit 500.000 Zeilen, die andere ein persönliches Side-Project in Flutter, das ich von Grund auf neu gebaut habe. Flutter und Dart waren für mich völliges Neuland. Trotzdem hatte ich das Gefühl, dass der Ansatz funktioniert. Bei Greenfield-Projekten reicht fast schon nur /create_plan, und man kann die gesamte Unterstützung des Agenten nutzen. Wichtig ist, die von der AI erzeugten Dokumente sorgfältig zu prüfen. Man muss selbst kontrollieren, ob Edge Cases, die man im Blick hat, berücksichtigt wurden und ob die technischen Entscheidungen sinnvoll sind. Zum Beispiel merkt man sofort, wenn eine falsche Entscheidung getroffen wurde, etwa ein Wechsel weg von einem sqlite-Muster hin zu einer Empfehlung für Postgres. Meist kann man den Plan direkt im Chat mit dem Agenten anpassen. Im Unternehmen musste ich GitHub Copilot verwenden, daher musste ich die Prompts etwas anders formulieren, aber die bewusste Verdichtung zwischen den Schritten mache ich weiterhin. Copilot unterstützt keine Sub-Agenten wie Claude Code, aber die Produktivität bleibt trotzdem ordentlich.
Ich möchte auch eine persönliche Erfahrung teilen. Kurz vor dem Zeitalter der AI-Coding-Unterstützung war ich stark deprimiert, weil meine Arbeit immer langweiliger wurde. Durch mehrere Repos, Teams und unterschiedliche Persönlichkeitstypen war die Arbeit an großen Codebasen immer voller Kleinkram. Das Beste an AI-Coding war für mich, dass solche Nebentätigkeiten jetzt viel reibungsloser laufen. Ich ziehe große Erfüllung daraus, etwas zu bauen, das wirklich gut funktioniert, aber ständig wurde diese Freude durch solche Nebenarbeiten blockiert. Jetzt liefere ich konstant gute Ergebnisse und bin auch ein bisschen stolz auf mich selbst
Ich habe ein Paket gebaut, das ich für die Arbeit mit großen Codebasen nutze: [GitHub.com/iambateman/speedrun]. Zuerst gibt man über /feature eine Funktionsbeschreibung ein, dann beginnt die Analyse der Codebasis und es werden Fragen gestellt. Wenn ich antworte, wird ein Plan im Markdown-Format geschrieben. Dabei entstehen 8 bis 10 Markdown-Dateien mit einer Beschreibung dessen, was zu tun ist, und sogar mit Beispielcode. Danach folgt eine „code critic“-Phase, die Fehler finden soll, aber in Wahrheit in 60 % der Fälle falschliegt. Aus diesem Feedback filtere ich die irrelevanten Fehler heraus. An diesem Punkt gibt es dann einen sauberen Ordner mit den von mir gewünschten Änderungen und der Funktionsbeschreibung. Dann muss ich Claude Code nur noch „mach weiter“ sagen, und die Arbeit beginnt Schritt für Schritt. Diese Arbeitsweise verhindert, dass die Richtung abdriftet, und gibt mir mehr Sicherheit beim Ergebnis. Für große Aufgaben nutze ich diesen Workflow mehrmals täglich, bei vergleichsweise konkreten Aufgaben nehme ich einfach normales Claude code. Ich halte das für einen ziemlich effizienten Workflow
Ich verstehe überhaupt nicht, warum man durch so einen komplexen Prozess gehen möchte. Normales Coding mit ein bisschen Unterstützung durch LLMs ist meiner Meinung nach produktiver als dieser Ansatz
Ein großes Problem beim Einsatz von LLMs in großen Codebasen ist, dass sie dieselben Fehler wiederholen. Mich würde interessieren, wie du architekturbezogene Entscheidungen pro Aufgabe über den Kontext hinweg konsistent nachverfolgst
Sieht wirklich großartig aus. Es gibt darin eine Pseudocode-Phase, und ich frage mich, ob es tatsächlich geholfen hat, den Workflow oder Prozess im Voraus zu definieren. Außerdem hört man oft, dass es wichtig sei, jede Datei unter 100 Zeilen zu halten — hattest du denselben Eindruck?
Dieser Beitrag wirkt wie eine Zeitkapsel des Moments, in dem ich in Claude code beim Kontext-Management komplett aufgegeben habe. Ich hatte für jeden Teil des Codes eigene Spezifikationsordner angelegt und darin funktionsbezogene Logs gesammelt. Ich habe mehrere Subsysteme eines API-Servers in Python betreut, etwa Accounts, Benachrichtigungen und Abonnements. Als alles komplexer wurde, konnte Claude die Business-Logik nicht mehr richtig erfassen, und das Kontext-Management wurde extrem schwierig. Wenn man zum Beispiel ein einfaches RBAC-System bauen wollte, musste man sogar UML-Diagramme und Beispiele für die Beziehung zwischen Account und Profil liefern, damit es halbwegs wie erwartet funktionierte
Es gibt unzählige Erklärungen und Behauptungen zur Nutzung von AI, aber kaum jemand veröffentlicht den konkreten Prozess oder die tatsächlichen Prompts. Großspurig darüber reden ist leicht; wirklich nützlich wird es erst, wenn Prompt-Logs offengelegt werden. AI-generierte Commits sollten auch die verwendeten Prompts protokollieren, sodass man wie in einem Commit-Log auch durch ein Prompt-Log gehen und den Entstehungsprozess des Codes nachvollziehen kann
Der Autor prahlt damit, 35K Zeilen Code in 7 Stunden untersucht und implementiert zu haben, aber in Wirklichkeit sind über 7 Tage 40 Commits entstanden. Da fragt man sich, ob er nur eine Stunde pro Tag gearbeitet hat. Und dass einer der neuesten Commits „einige Tests ignorieren“ heißt, ist schon komisch
Da stand der Satz: „Ein paar Wochen später fügten wir zusammen mit @hellovai 35k LOC zu BAML hinzu und führten neue Features wie Cancel-Support und WASM-Kompilierung ein. Das bestehende Team hatte für jede Funktion 3 bis 5 Tage veranschlagt.“ Heißt das, man glaubte, dass ein Senior Engineer pro Tag 4–6 KLOC schreiben würde? (also noch vor GenAI?)
Was hier fehlt, ist die Tatsache, dass ein Senior Engineer das in Wirklichkeit wahrscheinlich mit 2 KLOC gelöst hätte
Und tatsächlich räumt der Autor an anderer Stelle ein, dass die Arbeit in Wahrheit eine Woche gedauert hat https://news.ycombinator.com/item?id=45351546
Dem Teil „Am Anfang war es unangenehm, aber ich habe aufgehört, jeden Code-Schnipsel in PRs zu lesen, und stattdessen nur die Tests gründlich geprüft. Die Spezifikation wurde zur eigentlichen Quelle“ stimme ich vollkommen zu. Ich habe das Gefühl, dass sich unsere Rolle von der direkten Ausarbeitung von Implementierungsdetails hin zur Definition und Validierung des Verhaltens verschiebt. Kürzlich musste ich einem Python-Operator für S3-to-SFTP rekursives Hochladen hinzufügen, mit vielen komplexen Pfad-Flags. Mein Prozess war folgender: 1) Das bestehende Verhalten in eine klare Spezifikation überführen, also über bestehende Unit-Tests absichern. 2) Diese Spezifikation für die neue Funktion erweitern. 3) Problem und Tests an den Coding-Agenten übergeben. Am Ende habe ich erkannt, dass ich den alten Code überhaupt nicht verstehen musste. Mein Fokus lag nur darauf, ob der neue Code die Spezifikation korrekt erfüllt. In der Zukunft wird unser Wert darin liegen, Korrektheit zu verifizieren, und der eigentliche Code wird nur noch ein Detail sein, das der Agent erledigt
Ich stimme zu, dass sich „unsere Rolle von der Ausarbeitung von Implementierungsdetails zur Definition und Validierung von Verhalten verlagert“. Eigentlich war das doch schon immer die Hauptaufgabe. Dank Hochsprachen, Compilern und anderen Abstraktionen sinkt die Zeit, die wir für das Schreiben von Implementierungsdetails aufwenden, ohnehin seit Langem stetig
Bei „Mein Fokus lag darauf, ob der neue Code gemäß der Spezifikation funktioniert“ muss ich an Postels Gesetz (Postel's Law) denken. Das beobachtbare Verhalten eines weit verbreiteten Systems wird de facto zu seiner öffentlichen Schnittstelle und Spezifikation, einschließlich aller Unsauberkeiten und Implementierungsfehler. Man muss also auch testen, ob die Client-Seite des Codes die Spezifikation wirklich sauber einhält, und Abweichungen gegebenenfalls erkennen und behandeln
Claude Plays Pokemon hat genau dasselbe gezeigt. AI ist schwach darin, zu beurteilen, ob etwas wirklich gut funktioniert. Stattdessen kreist sie oft immer wieder um dasselbe herum. Aber wenn Menschen zwischendurch die Richtung korrigieren, kann das eine starke Kombination sein
Wenn man tatsächlich versucht, jeden Aspekt des Verhaltens vollständig zu definieren, schreibt man am Ende praktisch den ganzen Code selbst. Wenn auch nur eine einzelne Zeile in einem PR nicht sofort verständlich ist, dann ist das Verhalten vermutlich noch nicht ausreichend definiert
Es gab die Behauptung: „In den nächsten Jahren werden Spezifikationsdokumente zum eigentlichen Code, und man wird Python-Dateien kaum noch öffnen.“ Damit das Realität wird, müsste AI-Codegenerierung zu 99,9 % korrekt sein, und Halluzinationen dürften praktisch nicht mehr vorkommen. Dass wir Compilern vertrauen und keinen Assembler lesen, liegt daran, dass wir sicher sind, dass das Ergebnis immer gleich und fehlerfrei ist — abgesehen von seltenen Bugs oder Optimierungsproblemen, die fast immer schnell behoben werden. Im Moment gilt aber: Wenn AI-generierter Code anders funktioniert als die Spezifikation, also der ursprüngliche Code, muss am Ende doch wieder ein Mensch nachbessern
Der Tipp, Implementierungen in Teilaufgaben aufzubrechen und pro Arbeitseinheit zu bearbeiten oder zu prüfen, war sehr eindrucksvoll.