Über grep hinaus: Plädoyer für ein kontextreiches KI-Harness

Die These: Die Qualität eines KI-Code-Assistenten hängt weniger von seinem Modell ab als von seinem "Harnisch" - der Schicht, die entscheidet, welche Teile des Codebasis ihm vorgelegt werden. Eine Analyse eines Artikels, der die Kontext-Ingenieurkunst in den Mittelpunkt stellt.

Der Ausgangspunkt

Ein konkreter Fall, den jeder Senior-Entwickler erlebt hat: Man öffnet seine IDE, fragt den Assistenten « Refaktoriere diese Funktion, um die neue interne API zu verwenden » - und er produziert einen plausiblen, syntaktisch sauberen Code, der jedoch drei Projektkonventionen, zwei interne Abhängigkeiten und einen bereits 30 Zeilen weiter unten vorhandenen Helper ignoriert. Das Modell ist nicht « dumm », es hat einfach nicht gesehen, was es sehen musste.

Genau diese These vertritt Vinay Perneti (Augment Code) in einem Interview mit Ars Technica mit dem Titel « Beyond grep : The case for a context-rich AI coding harness »: das Gestell - die Gesamtheit der Mechanismen, die auswählen, ordnen und den Kontext in den Prompt injizieren - wiegt heute mehr als die Wahl des zugrunde liegenden Modells.

Was ein « armer » Gestell macht

Es handelt sich im Wesentlichen um ein raffiniertes grep:

• eine naive Embedding-Suche in den Dateien des Repos,
• ein Kontextfenster, das um den Cursor geöffnet wird,
• gegebenenfalls die gesamte aktuelle Datei.

Das funktioniert für lokale Aufgaben (Umbennen einer Variablen, Korrigieren einer Signatur). Es bricht zusammen, sobald es darum geht zu verstehen, warum ein Test drei Module weiter fehlschlägt.

Was ein « reicher » Gestell macht

Drei Bausteine, die sich kumulieren, in der Linie dessen, was Perneti bei Augment Code vertritt:

1. Code-Abhängigkeitsgraph - Importieren, Aufrufen, Vererben: Das Gestell folgt den Kanten, um die wirklich nützlichen Definitionen zu bringen, nicht die textuell nahen Dateien.
2. Ausführungsverlauf - Testspuren, Protokolle, Ausgabe des letzten pytest oder cargo test. Das Modell sieht, was kaputt gegangen ist, nicht nur den Code, der kaputt geht.
3. Sitzungsspeicher - Die in den vorherigen Interaktionen getroffenen Entscheidungen (« wir haben die Lib X gewählt, nicht Y »), um zu verhindern, dass der Assistent sie bei jeder Runde erneut infrage stellt.

Neuere Open-Source-Projekte veranschaulichen jeden dieser Bausteine - das tree-sitter-Ökosystem für die strukturelle Analyse, die Tools rund um ripgrep in Kombination mit semantischen Indizes und die Agenten-Frameworks, die ein « scratchpad » persistent halten.

Warum das der entscheidende Faktor ist

Zwei wirtschaftliche Gründe:

• Der Preis des Tokens sinkt, das Kontextfenster steigt: Man kann es sich leisten, mehr zu senden. Aber man kann nicht alles senden - ein Monorepo mit 500.000 Zeilen bleibt unerreichbar. Man muss also auswählen.
• Das Modell argumentiert besser über das, was man ihm zum richtigen Zeitpunkt zeigt, als über das, was man ihm in roher Form eingibt. Das Gestell, das richtig priorisiert, schlägt das Modell, das in seinem eigenen Fenster schlecht sortiert.

Mit anderen Worten: Der Unterschied zwischen einem Assistenten, den man toleriert, und einem Assistenten, auf den man sich stützt, liegt nicht mehr im Gewicht des Modells. Er liegt in der Software-Ingenieurskunst seiner Wahrnehmungsumgebung.

Zu beachten

• Das « Gestell » (Kontext-Engineering) ist zum echten Differenzierungsmerkmal der Code-Assistenten geworden - eine These, die öffentlich von Vinay Perneti bei Augment Code vertreten wird.
• Ein reiches Gestell kombiniert Code-Graph, Ausführungsverlauf und Sitzungsspeicher - nicht nur textuelle Suche.
• Ein Werkzeug heute auszuwählen, bedeutet ebenso, sein Gestell zu bewerten wie das Modell, das es integriert.