Kontext und Produktivität

Unsere Position. Für uns ist die eigentliche Grenze das Kontextmanagement, nicht die Intelligenz des Modells (öffnet in einem neuen Tab). KI vervielfacht, was ein Team schon hat, also gilt: erst das Fundament reparieren, dann vervielfachen (öffnet in einem neuen Tab).

Warum ist Kontext der Bottleneck für KI-Coding-Tools?

Der Harness unterscheidet sich vielleicht kaum noch. Das Material, das hineingeht, unterscheidet sich weiterhin. Wer bei Baz den Review-Agent baut, traut Prompting allein höchstens rund 30 bis 60 % des Ergebnisses zu. Den Kontext der Codebasis zu sammeln, sei der schwierige und schwer nachzuahmende Teil: “prompting everybody can do”, der Kontext dagegen sei “the secret sauce of your company” und schwer nachzubauen (Baz über den Bau eines Code-Review-Agents (öffnet in einem neuen Tab), Juni 2025). Der Talk zum Context Development Lifecycle verallgemeinert das zu einem Lebenszyklus mit vier Phasen. Jede Agent-Session ist wie eine neue Kollegin, die bei null anfängt. Das implizite Wissen, das Seniors längst verinnerlicht haben, muss deshalb explizit werden, und Kontext verdient dieselbe Engineering-Sorgfalt wie Code.

Die vier Phasen des Context Development Lifecycle heißen generate, evaluate, distribute und observe. Zwei Punkte betont der Ansatz am stärksten. Kontext braucht Tests, denn “every evaluation failure is a specification you didn’t write”. Außerdem muss er sich als versioniertes, gesichertes Paket verteilen lassen, so wie npm und pip Code wiederverwendbar gemacht haben. Größere Kontextfenster lösen das Problem nicht auf. Wer alles lädt, vervielfacht nur die Widersprüche, und die Arbeit wandert vom Kuratieren zur Governance (The Context Development Lifecycle (öffnet in einem neuen Tab), Februar 2026).

Praktisch folgt daraus: Was menschlichen Mitwirkenden hilft, hilft auch Agents. Engineering-Grundlagen wiegen schwerer, sobald Agents den Code schreiben. Ein Talk auf einer DX-Konferenz rät Teams, auf branchenübliche Tools zu standardisieren, gerade weil diese in den Trainingsdaten stecken. Eigene Paketmanager und obskure Sprachen zwingen den Agent, gegen sein eigenes Training zu arbeiten. Den größten Hebel hat deterministische Validierung mit klaren Fehlermeldungen, denn ein Agent “cannot divine what you mean by a 500 internal error with no other message”. Diese Validierung muss zur Entwicklungszeit in etwa 30 Sekunden laufen, nicht erst in einem CI-Job von 15 bis 20 Minuten. Agents drehen mehrmals die Schleife aus Run und Test, und langsames Feedback frisst den Gewinn auf (DX – No-regrets investments for the agentic era (öffnet in einem neuen Tab), Dezember 2025). Derselbe Talk benennt einen Fehler, in den Teams immer wieder laufen: Agents schreiben Fake-Tests gegen untestbaren Code (“I pushed the button and the button pushed successfully; test passed”). Legacy-Code muss deshalb erst testbar und nachvollziehbar werden, bevor Agents daran arbeiten.

Demos aus der Praxis zeigen Kontextdateien weniger als statische Konfiguration, eher als lebende, geschichtete Artefakte. In einem Google-Talk behob jemand aus der Praxis live ein Issue im Repository von Gemini CLI selbst. Bei jedem Lauf kamen drei Markdown-Schichten zusammen. Eine persönliche Workflow-Datei legte Plan-Modus, Branch-Namen und testgetriebene Schritte fest. Eine vom Team gepflegte Best-Practices-Datei hielt Konventionen bis hin zu bevorzugten Befehlen fest (npx vitest statt npm test). Generierte Dateien zur Projektstruktur dienten als “city guide” zur Codebasis. Diese Dateien hatte größtenteils selbst ein LLM geschrieben. Nach einer Session reflektiert der Agent, wo er hängen blieb, und schreibt die Lehren zurück ins Markdown. So startet der nächste Lauf klüger, ein praktisches Beispiel für die generate-and-observe-Schleife des Talks.

Der Talk argumentiert so: Mit einfachem Tool Calling darunter passiert die meiste Steuerung in den Instruktionen in natürlicher Sprache, nicht im Harness. Markdown schlage ein validierbares Konfigurationsformat, gerade weil auch Nicht-Entwickler:innen es schreiben können. Modelle können es gut synthetisieren, und dank seiner Unschärfe greift eine Instruktion über viele Aufgaben hinweg. Gemini CLI kann außerdem vorhandene CLAUDE.md- oder Cursor-Rule-Dateien eines Projekts lesen, statt ein eigenes Format zu erzwingen (Google über Gemini CLI (öffnet in einem neuen Tab), Juni 2025).

Der meiste Kontext beschreibt den Code, wie er geschrieben ist. Eine neuere Kategorie ergänzt, wie sich der Code in Produktion verhält. Hud betreibt neben der Anwendung einen Sensor, der Fehler und Performance pro Service und pro Funktion aufzeichnet. Tritt ein Fehler oder eine Verlangsamung auf, erfasst er Ausführungspfade, Parameter und Maschinenzustand. Diese Zahlen zeigt Hud direkt neben der Funktion in VS Code, JetBrains oder Cursor. Wer als Engineer oder Agent eine Funktion bearbeitet, sieht so zuerst Aufrufvolumen, Latenz und Fehlerrate. Hud unterstützt Node.js, TypeScript, Python und Java. Laut den Kundenberichten von Hud schrumpfen Incident-Analysen von Tagen auf Minuten. Das sind Anbieterangaben ohne veröffentlichte Methode (Hud (öffnet in einem neuen Tab), Stand September 2026).

Was sagt die Evidenz zur Produktivität?

Das gemessene Bild ist bescheidener als die Angaben der Anbieter. In der randomisierten Studie von METR waren 16 erfahrene Open-Source-Entwickler:innen mit KI-Tools (vor allem Cursor) in ihren eigenen Repositories etwa 19 % langsamer. Vorab hatten sie erwartet, etwa 20 % schneller zu sein. Selten zitiert wird ein methodischer Vorbehalt: Die Teilnehmenden starteten mit einem 30-minütigen Einführungs- und Onboarding-Call samt Grundschulung in Cursor, und METR kann Lerneffekte jenseits von 50 Stunden Cursor-Nutzung nicht ausschließen (METR-Paper, Anhang G.3 (öffnet in einem neuen Tab); METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (öffnet in einem neuen Tab)). Der Benchmark von DX für Q1 2026 über mehr als 400 Unternehmen zeigt 92,7 % Adoption, 3,9 Stunden selbst berichtete Zeitersparnis pro Woche und 27,4 % KI-geschriebenen Code. Die Langzeitstudie von DX fand über mehr als ein Jahr aber nur 10 bis 15 % mehr PR-Durchsatz. Das liegt deutlich unter dem, was die selbst berichteten Ersparnisse nahelegen (DX AI Impact Report).

Die Wahl des Tools zeigt sich durchaus in den Benchmark-Daten. Tägliche Cursor-Nutzer:innen lieferten 4,1 PRs pro Woche (46 % mehr als im Vorquartal), Claude-Nutzer:innen über 4,0. Bei GitHub Copilot waren es 3,61 PRs, bei Tabnine 1,83, und neuere KI-native und agentische Tools führen mit wachsendem Abstand (DX AI Impact Report). Erfahrungen aus der Praxis ergänzen, was die Benchmarks übersehen. Das sechsköpfige Team von Rotational Labs testete Cursor und Copilot drei Monate lang. Zu viel Delegation rächte sich, eng geschnittene Aufgaben funktionierten, und eine schnellere Einzelperson machte noch kein schnelleres Team. Die Tools beschleunigten die Einzelarbeit und erschwerten zugleich die Zusammenarbeit. Das Team musste deshalb bewusst Zeit für Abstimmung einplanen (Rotational Labs - What We’ve Learned From 3 Months Living with AI Coding Tools (öffnet in einem neuen Tab)).

Die Studien kommen zum selben Schluss, und der spricht dafür, zuerst das Fundament zu bauen: KI verstärkt die vorhandene Engineering-Qualität. Reife Teams werden schneller, unreife langsamer. Über das Ergebnis entscheiden strukturiertes Enablement und Messung, nicht der Rollout der Tools (KI-Produktivitätsstudien, DX AI Impact Report). Der DORA-Report 2025 formuliert das Bild vom Verstärker unverblümt: Agentische KI “magnifies the strengths of high-performing organizations and the dysfunctions of struggling ones” (Your AI Coding Assistants Will Overwhelm Your Delivery Pipeline (öffnet in einem neuen Tab), Januar 2026).

Diese Verstärkung legt einen Bottleneck hinter der Codegenerierung offen: die Delivery-Pipeline. Etwa 90 % der Entwickler:innen nutzen inzwischen KI, um schneller Code zu schreiben, und laut DX liefern tägliche KI-Nutzer:innen 60 % mehr Pull Requests. Dieser Output trifft auf Pipelines, die für geringere Mengen gebaut sind. Die Arbeit staut sich an manuellen Gates für Merge, Test und Deploy, und Software kommt später statt früher heraus. Laut DORA 2025 deployen 77 % der Organisationen einmal pro Tag oder seltener, 20 % nur monatlich oder quartalsweise. Die besten 23 % deployen dutzende bis hunderte Male pro Tag. Die Empfehlung lautet, testgetriebene Entwicklung, Continuous Integration auf dem Trunk und Continuous Deployment zu stärken, bevor KI skaliert, nicht danach (Your AI Coding Assistants Will Overwhelm Your Delivery Pipeline (öffnet in einem neuen Tab), Januar 2026).

Selbstauskünfte der Anbieter liegen weit über den gemessenen Zahlen und sind auch so zu lesen. GitHub behauptet, Copilot-Nutzer:innen seien “up to 55% more productive” bei “up to 75% higher” Arbeitszufriedenheit. Als Kundenbeispiel führt GitHub Grupo Boticário mit einem Wert von 94 % an (GitHub, Anbieterangaben, GitHub Copilot (öffnet in einem neuen Tab)). Dem stehen die 10 bis 15 % mehr PR-Durchsatz gegenüber, die die Langzeitstudie von DX gemessen hat. Die Gewinne bringen zudem neue Kosten, die keine Token-Rechnung erfasst. Ein Report von Thoughtworks meldet, dass die von DORA berichtete Stabilität schlechter wird. Die Änderbarkeit lässt nach, weil sich Änderungen über mehr Dateien ausbreiten als nötig. Dazu kommen wachsende kognitive Last und Burnout durch das Beaufsichtigen schneller Agents (A year of AI coding (öffnet in einem neuen Tab), Juni 2026). Verlässlich gewinnt KI bei eng umrissenen Aufgaben, beim Prototyping gegen unbekannte APIs, beim Generieren von Tests und Boilerplate und beim Debugging. Verlässlich scheitert sie an vollständiger Automatisierung, an Architekturentscheidungen und an zentraler Geschäftslogik (Rotational Labs - What We’ve Learned From 3 Months Living with AI Coding Tools (öffnet in einem neuen Tab)).

Verwandte Seiten

• Supervision und Drift: was Review und Verifikation kosten, sobald der Output wächst.
• Preise für Agentic Coding: warum längerer Kontext jede Session teurer macht.
• Context Engineering: die Praxis, zu entscheiden, was ins Fenster kommt, angewandt in einem Tool.
• Das Qualitätssystem rund um den Coding-Agenten: die Delivery-Praktiken, die entscheiden, ob KI ein Team schneller macht.
• Der DORA-Report zu KI-gestützter Entwicklung: der Befund vom Verstärker vollständig, mit den Pipeline-Praktiken, die er empfiehlt.

Quellen

Runtime-Kontext

• Hud (öffnet in einem neuen Tab) - Runtime-Sensor für Code, der Produktionsfehler und Performance auf Funktionsebene in die IDE und an Coding-Agents liefert.