Wie Enterprise-Teams KI-Agenten kontrolliert einsetzen. Vier-Säulen-Modell, Diagnose/Solve-Pattern, Review-Pipeline. Ohne Hype.
Wie Senior-Entwickler die Agent-Ära überleben. Ein Framework für Enterprise-Teams, die KI-Agenten in großen Codebasen kontrolliert einsetzen wollen.
Dieses Dokument richtet sich an Senior Developer, Staff Engineers und Tech Leads, die täglich mit Codebasen arbeiten, die hunderttausende Zeilen umfassen, gewachsene Architektur tragen und echte Legacy haben. Wer nach einem Cursor-Tutorial sucht, ist hier falsch. Wer verstehen will, warum erfahrene Entwickler mit KI schlechter performen als ohne — und was dagegen zu tun ist — liest weiter.
Es gibt eine Studie, die ich seit Monaten in jedem Gespräch über GenAI-Produktivität zitiere — nicht weil sie so bekannt wäre, sondern weil sie fast niemanden interessiert, der sie kennen sollte.
Das METR-Institut hat 2025 eine kontrollierte Studie mit erfahrenen Entwicklern durchgeführt.1 Die Aufgabe: reale Software-Tasks, mit und ohne KI-Unterstützung. Das Ergebnis: Erfahrene Entwickler waren 19 % langsamer, wenn sie KI-Tools einsetzten. Sie selbst schätzten sich 20 % schneller ein.
Das ist eine Fehleinschätzung von fast 40 Prozentpunkten.
Ich halte kurz inne bei dieser Zahl. Nicht 5 %, nicht 10 % — 40 Prozentpunkte Differenz zwischen wahrgenommener und tatsächlicher Performance. Das ist keine Messungenauigkeit. Das ist ein systematisches Problem in der Art und Weise, wie Senior-Entwickler KI einsetzen.
Die übliche Reaktion auf diese Zahl ist Ablehnung: „Das war bestimmt eine schlechte Studie.“ Oder: „Das trifft auf mich nicht zu, ich nutze die Tools richtig.“ Oder, am häufigsten: „Meine produktivsten Tage sind definitiv die mit KI.“
Das stimmt möglicherweise sogar. Die Frage ist, was an den weniger produktiven Tagen passiert — und warum die Selbstwahrnehmung systematisch daneben liegt.
Die Antwort ist nicht, dass KI-Tools schlecht sind. Die Antwort ist struktureller: Die überwiegende Mehrheit aller KI-Trainings, Tutorials, YouTube-Videos und Kurse ist für Greenfield-Projekte gebaut. 500-Zeilen-Repositories. Projekte ohne Legacy, ohne Compliance, ohne implizite Architekturen, die über Jahre gewachsen sind. Projekte, bei denen die gesamte Codebasis ins Kontextfenster passt.
Das ist nicht die Realität, in der erfahrene Entwickler arbeiten.
Dieses Dokument existiert, weil ich seit Jahren an der Schnittstelle zweier Perspektiven sitze: Als Senior-Entwickler, der Enterprise-Codebasen kennt, und als jemand, der an Brokk AI gearbeitet hat — einem GenAI-Tool, das speziell für diese Codebasen entwickelt wurde. Was ich hier teile, ist nicht aus einem Lehrbuch oder einer Konferenz. Es ist das, was ich beim Bauen dieser Tools gelernt habe. Die Fehler, die ich dabei gemacht habe. Die Patterns, die sich als tragfähig erwiesen haben.
Ich bin kein AI-Coach. Ich komme aus der Tool-Seite.
Die Demo, die jeder kennt, sieht so aus: Leeres Repository, neues Feature beschreiben, Cursor oder Claude Code generiert in Minuten lauffähigen Code. Der Entwickler klatscht, der YouTube-Kanal wächst.
Was die Demo nicht zeigt, ist der Kontext dieser Demo. Die Codebasis ist sauber. Die Dependencies sind bekannt. Die gesamte relevante Logik passt in einen einzigen Prompt. Das LLM kann das Problem vollständig „sehen“ — weil das Problem klein genug ist, um vollständig gesehen zu werden.
84 % der Entwickler nutzen heute täglich KI-Tools.2 Gleichzeitig stagniert die Enterprise-Produktivität. Die METR-Studie ist kein Einzelfall — sie ist symptomatisch für eine Branche, die ihre eigenen Demos zu ernst nimmt.
Das Kernproblem ist nicht mangelnde Tool-Qualität. Es ist eine fundamentale Fehlannahme über die Arbeitsbedingungen, für die diese Tools optimiert wurden.
Greenfield-Welt: Projekt neu anlegen, Feature beschreiben, AI setzt in Sekunden um, gesamte Codebasis passt ins Kontextfenster.
Enterprise-Welt: Die relevante Klasse liegt in einem anderen Microservice-Repo. Der Agent refaktoriert eine Methode, die in der Payment-Pipeline verwendet wird — das steht nirgendwo dokumentiert. Die fehlenden Dependencies führen zu Halluzinationen bei API-Calls. Security-Reviews dauern drei Monate. Compliance-Anforderungen schränken ein, welcher Code überhaupt an externe Dienste übermittelt werden darf.
Das ist die Welt, in der die Persona „Markus“ — Senior Backend Developer, Java/Spring Boot, Bank oder Versicherung, fünf bis fünfzehn Entwickler im Team — jeden Tag arbeitet. Er hat GitHub Copilot ausprobiert. Er hat Cursor getestet. Manche Sessions liefen gut. Die meisten waren enttäuschend. Er hat aufgehört zu suchen, warum.
Ein LLM sieht nur, was im Kontextfenster liegt. Das klingt trivial. Es ist die wichtigste Erkenntnis dieses gesamten Dokuments.
Bei 500.000+ Lines of Code mit impliziten Architekturen, verschachtelten Dependencies und Legacy-Logik, die über Jahrzehnte akkumuliert wurde, ist das Kontextfenster nicht mehr das Steuerungsinstrument — es ist das Nadelöhr. Das LLM wird nicht schlechter. Aber es arbeitet mit einem Bruchteil des relevanten Wissens. Und es weiß nicht, was ihm fehlt.
Codebasis: 500.000+ LOC Kontextfenster: 200.000 Tokens (~150.000 Zeilen) Tatsächlich relevanter Code: 500–2.000 Zeilen pro Task Problem: Welche 500–2.000 Zeilen?
Diese Auswahl — was ins Kontextfenster kommt und was nicht — ist Context Engineering. Sie ist nicht die sexieste Disziplin im KI-Stack. Sie ist die wichtigste.
Was bestimmt die Qualität eines KI-gestützten Entwicklungs-Workflows? Aus der Arbeit an Brokk AI und in Enterprise-Projekten hat sich folgende praxisbasierte Arbeitsgewichtung herauskristallisiert:
┌──────────────┬──────────────┬──────────────┬────────────────┐ │ KONTEXT │ MODELL │ PROMPT │ TOOLS / BP │ │ 40 % │ 20 % │ 15 % │ 25 % │ └──────────────┴──────────────┴──────────────┴────────────────┘
Die ungewöhnliche Aussage dieses Frameworks: Kontext macht 40 % aus — mehr als Modellauswahl, mehr als Prompt Engineering. Das ist das Ergebnis, das ich aus dem Bau von Brokk AI und aus hunderten Enterprise-Sessions gelernt habe. Wer sich ausschließlich auf den Prompt konzentriert und den Kontext ignoriert, optimiert an der falschen Stelle.
Jede der vier Dimensionen hat ihre eigene Fehlerklasse. Modell-Fehler (falsches Modell für den Task) führen zu sichtbaren, schnell erkannten Problemen. Prompt-Fehler führen zu fehlerhaften Outputs, die der Entwickler direkt sieht. Kontext-Fehler sind heimtückisch: Sie produzieren plausibel klingende, sachlich falsche Ergebnisse — die erst im Code Review auffallen, wenn es teuer wird.
Die meisten Entwickler denken bei „Kontext“ an den Text, den sie in die Eingabemaske tippen. Das ist ungefähr so präzise wie zu sagen, ein Eisberg ist das, was man über der Wasseroberfläche sieht.
Kontext ist die Gesamtheit aller Informationen, die dem LLM bei einem einzigen Inference-Call zur Verfügung stehen — sichtbar oder unsichtbar, beabsichtigt oder nicht.
Wenn ein Entwickler in Cursor eine Frage tippt, sendet das Tool nicht nur diese Frage an das LLM. Es sendet ein konstruiertes Gesamtpaket:
| Kontext-Typ | Sichtbar? | Wer befüllt ihn? |
|---|---|---|
| System Prompt | Nein | Tool-Anbieter |
| User Prompt | Ja | Entwickler |
| Conversation History | Teilweise | Automatisch akkumuliert |
| Tool-Call-Results | Teilweise | Tool-Execution |
| Injizierte Dateien | Ja | Tool / User |
| Tool-Beschreibungen (MCP) | Nein | Tool-Anbieter / Konfiguration |
Der kritische Punkt: Der Entwickler sieht und kontrolliert nur einen kleinen Teil davon. Der Rest passiert im Verborgenen.
Unsichtbares Volumen vor dem ersten Tastendruck: In einer typischen IDE-Integration mit KI-Unterstützung liegen zwischen 3.500 und 10.000 Tokens im Kontext, bevor der Entwickler eine einzige Zeile getippt hat.
Ich habe mir die Zeit genommen, den System-Prompt von Claude Code zu analysieren — mittels Man-in-the-Middle-Proxy, der den ausgehenden Traffic inspiziert. Das Ergebnis: rund 15.000 Tokens allein für den System-Prompt. Darin enthalten: ausführliche React-Beschreibungen, UI-Komponenten-Patterns, Frontend-spezifische Konventionen.
Für einen Java-Backend-Developer, der an einer Spring-Boot-Applikation arbeitet, ist das 15.000 Tokens irrelevanter Ballast — bei jedem einzelnen Request.
Claude Code System-Prompt: ~15.000 Tokens Davon für Java-Backend relevant: ~2.000–3.000 Tokens Overhead pro Request: ~12.000 Tokens Kostenimplikation bei 100 Requests/Tag: 12.000 × 100 × ~$0,000003/Token × 30 Tage ≈ $135/Monat — nur für irrelevanten System-Prompt
Das ist keine Kritik an Anthropic. Das ist ein strukturelles Problem: Ein Tool, das für alle sein will, ist für niemanden optimal.
Cursor geht noch einen Schritt weiter. Der System-Prompt wird serverseitig generiert und ist nicht per Man-in-the-Middle abfangbar — das hat Cursor bewusst so designed, vermutlich aus einer Kombination von Magie-Effekt und IP-Schutz.
Das Enterprise-Problem: Wenn ein Agent unerwartete Outputs produziert, liegt die Ursache häufig im System-Prompt. Den kann man bei Cursor nicht einsehen. Debugging wird zur Blackbox-Analyse. Das ist für Greenfield-Projekte ärgerlich. In einer Enterprise-Codebasis mit Compliance-Anforderungen ist es inakzeptabel.
Transparenz ist die Enterprise-Anforderung Nummer 1 — und genau die, die die meisten Tools nicht erfüllen.
Es gibt ein Phänomen, das fast jeder erfahrene Entwickler kennt, aber die wenigsten benennen können: Sessions werden über Zeit schlechter. Frühe Antworten sind präzise, spätere werden vager, widersprüchlicher, manchmal offen falsch.
Das ist kein Zufall. Das ist Kontextrott.
Wie Kontextrott entsteht: Mit jedem Tool-Call, jeder Dateiöffnung, jedem fehlgeschlagenen Versuch akkumuliert der Kontext. Jeder File-Read bleibt im Fenster. Eine 1.200-Zeilen-Datei, von der man nur eine 45-Zeilen-Methode braucht, liegt vollständig im Kontext. Drei fehlgeschlagene Lösungsversuche sind dokumentiert. Die gleiche Funktion wurde viermal in verschiedenen Kontexten erklärt.
Das Lost-in-the-Middle-Problem: LLMs verarbeiten Information am Anfang und Ende des Kontextfensters systematisch besser als in der Mitte.3 Ein aufgeblähter Kontext schiebt die tatsächlich relevante Information in die schlechteste Position — die Mitte.
Kontextrott ist kein Qualitätsproblem des LLM. Es ist ein Kontextmanagement-Problem des Entwicklers. Und es ist direkter Halluzinations-Enabler: Das LLM verwendet veraltete Kontext-Information — nichts Erfundenes, aber sachlich falsch für die aktuelle Situation. Diese Fehler sind schwerer zu debuggen, weil sie plausibel klingen.
Warnsignale:
| Indikator | Warnschwelle |
|---|---|
| Session-Länge | > 20 Messages ohne Reset |
| Context-Window-Nutzung | > 60 % belegt |
| Tool-Result-Akkumulation | > 5 große Tool-Results |
| Erkennbare Widersprüche im Kontext | jeder einzelne |
Aus allem, was ich über Kontextmanagement gelernt habe, lässt sich eine einzige Regel ableiten:
Gib dem LLM genau die Information, die es für die aktuelle Aufgabe braucht — nicht mehr. Kein Kontext ist besser als falscher Kontext.
Das klingt simpel. Es ist die Umkehrung der Intuition, die die meisten Entwickler mitbringen: „Je mehr Kontext, desto besser versteht das LLM mein Problem.“ Das ist falsch. Ein kleines, präzises Kontext-Paket übertrifft einen großen, diffusen Kontext fast immer.
Bisher war die Begründung für Context Engineering eine reine Qualitätsfrage: weniger Rott, weniger Lost-in-the-Middle, präzisere Outputs. Daneben steht ein zweites Argument, das heute noch nicht spürbar ist, aber gesetzt sein wird — ein ökonomisches.
Die aktuellen Token-Preise sind nicht margendeckend. Sie sind eine Mischung aus Marktanteils-Wettbewerb und Investoren-subventioniertem Land-Grab, nicht das Ergebnis operativer Profitabilität. Eine 200-Dollar-Subscription, die intern mehrere tausend Dollar Compute erzeugt, ist aus Anbietersicht kein tragfähiges Geschäftsmodell — sie ist Kundenakquise. Solange die Anbieter um Marktanteile kämpfen und Investoren die Verluste tragen, bleibt das geduldet. Sobald sich der Markt konsolidiert oder die Investorenlogik kippt, wird sich das normalisieren.
Wann das passiert, weiß niemand. Dass es passiert, ist die wahrscheinlichere Annahme als das Gegenteil.
Wer seinen Agenten-Workflow schon heute diszipliniert fährt — kleine Kontexte, gezielte Sessions, keine Dauer-Runtime ohne Checkpoint, kein frisch gestarteter Agent für jede Mikro-Frage — kauft Resilienz gegen die Preisrunde, die früher oder später kommen wird. Teams, die sich an heutige Token-Ökonomie gewöhnt haben, werden dann umlernen müssen. Teams, die Kontext als Ressource behandeln, werden den Shift kaum spüren.
Context Engineering ist damit nicht nur eine Qualitäts-, sondern auch eine Kosten-Disziplin. Die beiden Hebel ziehen in dieselbe Richtung — was die Output-Qualität heute verbessert, drückt morgen den Betriebspreis.
Bei der Entwicklung von Brokk AI ist aus dem Minimalprinzip ein konkretes Implementierungskonzept entstanden: Workspace-Fragments statt ganzer Dateien. Statt eine 1.500-Zeilen-Klasse in den Kontext zu laden, wurden nur die relevanten Fragmente — Methodensignaturen, die unmittelbare Implementierung, direkte Imports — extrahiert und injiziert.
Die Herausforderung damals (2025): Welche Fragmente sind relevant? Die verfügbaren Modelle konnten in einer 500k-LOC-Codebasis mit rohem grep oder rg die richtigen Stellen nicht zuverlässig finden. Zwei Mechanismen haben diese Lücke geschlossen.
TreeSitter-Summaries: Statt rohen Code zu injizieren, werden AST-basierte Zusammenfassungen generiert. Ein 500-Zeilen-Service wird zu einer strukturierten Beschreibung seiner öffentlichen Schnittstellen, seiner Dependencies und seiner wichtigsten Methoden — in einem Bruchteil der Tokens.
GitRank: Analog zu PageRank wird die Relevanz von Dateien durch Graphanalyse bestimmt: Welche Dateien werden am häufigsten importiert? Welche haben die meisten Abhängigkeiten? Welche wurden zuletzt verändert und sind damit wahrscheinlich relevant für den aktuellen Task?
Was sich 2026 verändert hat. Die aktuellen Frontier-Modelle — Claude Opus 4.7, GPT-5.4 — sind im Umgang mit bash, rg und iterativer Code-Navigation spürbar besser geworden. Sie greppen gezielt, lesen nur die Treffer, springen zu Referenzen, formulieren unterwegs Hypothesen. In der großen Mehrheit typischer Exploration-Aufgaben finden sie die relevanten Stellen heute selbstständig, ohne spezialisiertes Retrieval-Layer dazwischen.
Damit ist das Szenario, in dem GitRank und TreeSitter-Summaries wirklich den Ausschlag geben, kleiner geworden — nicht verschwunden. Es hat sich zum Spezialfall verschoben: sehr große, unbekannte Legacy-Monorepos in der ersten blinden Exploration. Exotische Sprachen oder Code-Konventionen, bei denen der Modell-Bias versagt. Langlaufende Agent-Workflows, in denen dieselbe Graphstruktur hunderte Male traversiert wird — dort rechnet sich Preprocessing weiter.
Konstant geblieben ist das Problem: das LLM ist blind für alles jenseits seines Kontextfensters. Verschoben hat sich nur der Hebel. 2025 war es Preprocessing (TreeSitter, GitRank, Workspace-Fragments). 2026 ist es in den meisten Fällen der Agent-Workflow selbst — explizite Diagnose-Phasen, saubere Task-Briefings, Wrap-Up-Logs als Handoff zwischen Sessions, isolierte Sub-Sessions für Teil-Aufgaben. Das Ziel ist dasselbe geblieben: dem Modell zur richtigen Zeit die richtige Information geben. Die Maschinerie dahinter ist leichter geworden, die Disziplin bleibt.
Nebenbei erklärt das auch, warum RAG-basierte Ansätze bei Quellcode strukturell limitiert sind — Standard-RAG chunkt Text nach Zeichenzahl, nicht nach syntaktischen Grenzen. Eine Methode, die über eine Chunk-Grenze gesplittet wird, verliert ihren Bedeutungskontext. Für natürliche Sprache ist das tolerierbar. Für Code nicht. Dort, wo Retrieval für Code überhaupt noch notwendig ist, muss es strukturorientiert arbeiten — nicht zeichenbasiert.
Der häufigste Fehler beim Einsatz von Coding-Agenten ist nicht falsches Prompting. Es ist, den Agenten zu früh implementieren zu lassen.
Ein Agent, der sofort mit der Implementierung beginnt, ohne das Problem vollständig verstanden zu haben, ist wie ein Chirurg, der ohne Diagnose operiert. Das Ergebnis ist technisch beeindruckend und sachlich falsch. Und am teuersten wird es, wenn der Fehler erst im Code Review auffällt.
Der Diagnose-Modus ist eine explizite Phase in jedem nicht-trivialen Agent-Task: Der Agent erkundet, sammelt Kontext, formuliert Hypothesen — führt aber keinen Code-Change durch.
Was ein Diagnose-Output enthält:
Erst wenn der Entwickler diesen Diagnose-Output gesichtet und freigegeben hat, wechselt der Agent in den Solve-Modus. Das ist das Solve-Gate.
Task-Eingang
│
▼
DIAGNOSE-MODUS
├── Code-Exploration
├── Dependency-Mapping
├── Hypothesis-Formulation
├── Confidence/Risk/Cost-Assessment
└── Assumptions & offene Fragen
│
▼
SOLVE-GATE — menschliche Freigabe
│
▼
SOLVE-MODUS
├── Klare Issues, definierter Scope
├── Implementierung
└── Self-Check vor PR
Ohne explizite Diagnose-Phase produzieren Agenten „plausibel falschen“ Code. Das ist die gefährlichste Kategorie von Fehlern: Code, der kompiliert, die Tests besteht und trotzdem ein subtiles Architektur-Problem einführt. Oder eine Methode refaktoriert, die in einer anderen Komponente auf spezifischem Verhalten basiert, das nirgendwo dokumentiert ist.
Das Template für jede Agent-Aufgabe:
| Dimension | Frage |
|---|---|
| Technical Risk | Wie kritisch ist der betroffene Code-Pfad? Gibt es implizite Abhängigkeiten? |
| Business Impact | Was passiert, wenn dieser Change einen Bug einführt? |
| Dev Time | Realistische Schätzung inkl. Review und möglicher Korrekturen |
| Recommended Path | Welchen Implementierungsansatz empfiehlt der Agent — und warum nicht die Alternativen? |
Das Diagnose/Solve-Pattern verändert auch die Qualität des Solve-Modus. Ein Agent, der explizit exploriert hat, implementiert mit mehr Präzision — weil er die Assumptions explizit gemacht hat, die sonst implizit und unkontrolliert ins Prompting einfließen.
Der unerwartete Nebeneffekt: Die Diagnose-Phase produziert Dokumentation, die ohnehin hätte entstehen müssen. Technical Debt-Awareness, Architektur-Hinweise, Annahmen über Business-Logik — das kommt aus dem Diagnose-Output fast kostenlos.
Agenten machen Code billig. Review teuer.
Das ist der zentrale Widerspruch der Agent-Ära: Die Geschwindigkeit der Codegenerierung ist nicht das Problem. Das Problem ist, dass Review nicht skaliert.
Ein Agent, der zwei Stunden an einer Feature-Implementierung arbeitet, kann 10.000 Zeilen Code produzieren. Wer prüft das? Ein erfahrener Entwickler kann in einer konzentrierten Stunde vielleicht 200–300 Zeilen sorgfältig reviewen — und dabei den eigentlichen Code-Kontext verstehen, Regressions-Risiken einschätzen, Architektur-Implikationen beurteilen.
Das Rechenbeispiel ist unbequem: Bei einem 10-zu-1-Verhältnis von Produktions- zu Review-Geschwindigkeit akkumuliert technische Schuld schneller als je zuvor — nicht durch schlechten Code, sondern durch nicht ausreichend reviewten Code.
Context-Switching-Kosten. Ein Reviewer, der zwischen fünf verschiedenen Agent-generierten PRs pro Tag wechselt, verliert pro Switch-Vorgang geschätzt 20–30 Minuten Einarbeitungszeit. Bei fünf PRs: zwei bis zweieinhalb Stunden täglich allein durch Kontextwechsel.
PR-Spam. Agenten tendieren dazu, große PRs zu produzieren, wenn die Scope-Definition nicht präzise genug war. Ein PR mit 2.000 Zeilen diff ist für einen menschlichen Reviewer nicht effektiv prüfbar — unabhängig von der Code-Qualität.
Fehlende Dokumentation. Menschlicher Code kommt mit implizitem Kontext: Der Entwickler kennt das System, weiß warum eine bestimmte Entscheidung getroffen wurde. Agenten-Code hat diesen impliziten Kontext nicht — es sei denn, er wird explizit erzeugt.
Die Lösung ist nicht weniger Agenten-Code. Die Lösung ist eine strukturierte Review-Pipeline.
Agent-Output
│
▼
SELF-CHECK (Agent reviewt eigenen Output)
├── Top-5-Risiken identifizieren
├── Scope-Verletzungen prüfen
└── Test-Coverage verifizieren
│
▼
REVIEW-BOT (automatisiert)
├── Architektur-Checks (Dependency-Violations, Layer-Verletzungen)
├── Security-Scan
└── Performance-Anti-Patterns
│
▼
CI-GATES (automatisiert)
├── Test-Suite
├── Linting / Static Analysis
└── Coverage-Threshold
│
▼
HUMAN REVIEW (fokussiert)
├── PR-Größe: ≤ 300–500 Zeilen
├── Triage: P0–P3 nach Business-Impact
└── Guided Review (Design Notes, Regressions, Architektur-Impact)
PR-Größe als harte Regel: Kein Agent-PR mit mehr als 300–500 Zeilen diff. Das ist keine Empfehlung — das ist eine Gate-Bedingung. Größere PRs werden automatisch zurückgewiesen und in Teilaufgaben zerlegt.
Guided Review geht über den Diff hinaus: Jeder Agent-PR enthält Design Notes — eine strukturierte Erklärung der Entscheidungen, die der Agent getroffen hat. Warum diese Implementierung? Welche Alternativen wurden verworfen? Welche Regressions-Risiken hat der Agent selbst identifiziert?
Manchmal ist der Agent als Vorarbeiter produktiver als als Implementierer.
Ein Agent, der ein komplexes Bug-Report analysiert, eine Reproduktionsstrategie entwickelt, drei Hypothesen formuliert und einen Testplan skizziert — das ist ein Review-fertiger Diagnose-Output. Der menschliche Entwickler nimmt diesen Output, validiert die Hypothesen in zehn Minuten und implementiert die Lösung in dreißig Minuten mit vollständigem Kontext.
Alternativ: Der Agent implementiert direkt, produziert 800 Zeilen Code-Änderungen, und der Entwickler verbringt zwei Stunden damit herauszufinden, ob die Implementierung korrekt ist — ohne den Kontext der ursprünglichen Diagnose zu haben.
Die zweite Variante fühlt sich effizienter an, weil Code entsteht. Die erste Variante ist tatsächlich effizienter, weil Review-Zeit spart.
Die Frage „Welches KI-Tool soll ich nehmen?“ ist die falsche Frage. Die richtige Frage ist: „Welcher Agent-Modus löst diese Aufgabe besser — und warum?“
Cloud-Agenten (Perplexity Computer, OpenAI Codex, ähnliche) und lokale Agenten (Cursor, Claude Code, Aider) sind nicht besser oder schlechter. Sie sind für fundamental verschiedene Aufgabentypen optimiert.
Cloud-Agenten sind stark für Aufgaben, die isoliert laufen können: Marktanalyse, Competitor Research, Marketing Copy, isolierte Coding-POCs, Dokumentationsgenerierung. Sie haben Zugang zum Web, laufen unabhängig vom lokalen Entwicklungskontext und können parallele Tasks ohne Interference bearbeiten.
Lokale Agenten sind stark für iterative Entwicklungsschleifen: Feature-Implementierung, Refactoring, Debugging, Architektur-Arbeit, Multi-File-Changes. Sie haben direkten Dateisystem-Zugang, kennen den lokalen Build-Zustand und können Feedback-Loops aus Compiler-Errors und Test-Ergebnissen verarbeiten.
Der entscheidende Unterschied: Iterative Dev-Loops brauchen Feedback. Cloud-Agenten haben keinen Control-Loop über den lokalen Build-Zustand und keine Live-Sicht auf den lokalen Repo-Kontext (sie laufen Sandbox-basiert). Eine Chrome-Extension bauen heißt: Build, Zip, Install, Fehler. Cloud-Agenten sehen den Fehler nicht — der Entwickler muss ihn manuell zurückübermitteln. Das erzeugt einen Download-Zyklus, der die Vorteile der Cloud-Geschwindigkeit neutralisiert.
Die korrekte Präzisierung lautet nicht: Cloud-Agenten sind schlecht für komplexe Software. Sondern: Cloud-Agenten sind schlecht für iterative Loops, aber gut für delegierbare Task-Pakete.
Das ist mehr als eine Tool-Entscheidung. Es ist ein fundamentaler Shift in der Frage, die Senior-Entwickler sich stellen müssen:
Nicht: Wie implementiere ich dieses Feature?
Sondern: Was delegiere ich an welchen Agenten-Typ — und wie strukturiere ich die Übergabepunkte?
Das klingt abstrakt. In der Praxis sieht es so aus:
| Aufgabe | Agent-Typ | Rationale |
|---|---|---|
| Feature-Implementierung (500+ LOC) | Lokal | Iterativer Feedback-Loop nötig |
| Architektur-Refactoring | Lokal | Multi-File-Context, Dependency-Awareness |
| Competitor-Recherche | Cloud | Isolierter Task, Web-Zugang sinnvoll |
| Marketing-Copy für Release | Cloud | Keine Code-Kontext-Abhängigkeit |
| Throwaway-POC (neues Framework) | Cloud | Wegwerfbar, kein lokaler Context nötig |
| Bug-Diagnose (unbekannte Codebasis) | Lokal | Dateisystem-Zugang, Build-Feedback |
| Dokumentation aus vorhandenem Code | Lokal oder Cloud | Abhängig von Code-Komplexität |
Aus dieser Trennung ergibt sich ein konkretes Workflow-Modell mit drei Ebenen:
EBENE 1: GitHub Agent Layer ├── Diagnose/Solve-Pattern ├── PR-Review-Gate ├── Nebenläufige Tasks └── Priorisierung (ROI-High, Strategic, Experimental) EBENE 2: Local Deep Work ├── Worktrees für parallele Branches ├── Architektur und Refactoring ├── Iterative Debugging-Loops └── Multi-File-Changes mit Context-Awareness EBENE 3: Cloud Research ├── Market und Competitor Analysis ├── Marketing und Dokumentation ├── POCs und Exploration └── Delegierbare, isolierte Tasks
Jede Ebene hat ihre eigene Session-Hygiene, ihre eigenen Review-Prozesse und ihre eigene Tooling-Konfiguration. Sie interagieren, aber sie vermischen sich nicht.
Das Model Context Protocol (MCP) verspricht: Verknüpfe dein LLM mit allem. Datenbankzugang, API-Integration, Dateisystem, Browser-Steuerung, Kalender-Integration, Search-Engines — alles in einem Agenten.
Das Versprechen ist real. Das Problem ist ebenfalls real.
Mehr Tools machen das LLM dümmer. Das ist kein Bug — es ist ein strukturelles Merkmal aller aktuellen LLMs.
Mechanismus 1: Entscheidungskomplexität. Mit drei Tools ist der Entscheidungsraum überschaubar. Das LLM trifft fast immer die korrekte Tool-Auswahl, weil es wenig Spielraum für Verwechslungen gibt.
Mit dreißig Tools ist der Entscheidungsraum exponentiell komplexer. Überlappende Semantiken — search_code, search_codebase, find_in_files, semantic_search, grep_pattern — alle bedeuten konzeptionell „suche in Code“. Das LLM gerät in Konfusion, wählt suboptimal oder kombiniert mehrere Tools unnötig, wo ein einzelner direkter Aufruf die Aufgabe erfüllt hätte.
Das Resultat: Tool-Call-Kaskaden. In Tool-reichen Systemen durchläuft das LLM sechs bis acht Suchoperationen, bevor es zur eigentlichen Analyse kommt. In Tool-armen Systemen: ein direkter Aufruf.
Mechanismus 2: Token-Budget für Tool-Definitionen. Tool-Definitionen sind Teil des System-Prompts. Jedes Tool belegt dort Tokens für Name, Beschreibung und Parameter-Schema.
Realbeispiel: Claude Code
~15.000 Tokens System-Prompt gesamt
Beispielrechnung 30 MCP-Tools:
30 Tools × ~400 Token/Definition = 12.000 Token
+ Base System-Prompt = 4.800 Token
──────────────
Summe = 16.800 Token
Davon für die eigentliche Aufgabe verfügbar: nichts.
Das sind Tokens, die das LLM für Tool-Beschreibungen
aufwenden muss, bevor die erste Anfrage formuliert wird.
Mechanismus 3: Semantische Überlappung. Menschen navigieren semantische Überlappungen durch Erfahrung und Intuition. LLMs navigieren sie durch statistische Pattern-Matching. Bei starker Überlappung — create_file vs. write_file vs. save_file — ist die statistisch beste Wahl nicht verlässlich die aufgabenoptimale Wahl.
Das Gegenmittel ist radikal einfach: weniger Tools.
5–7 Tools pro Agent ist die empirisch gestützte Obergrenze für konsistente Performance. Darüber beginnt die Entscheidungsqualität systematisch zu fallen.
Task-spezifische Tool-Sets: Ein Agent für Code-Exploration hat andere Tools als ein Agent für Implementierung. Ein Agent für Diagnose hat andere Tools als einer für Review. Diese Trennung ist keine Einschränkung — sie ist Präzision.
Final-Tool-Disziplin: Jeder Agent braucht ein klares Abbruch-Signal. Ohne explizites „Ich bin fertig“-Tool neigen Agenten zu überzogenen Aktionsspiralen — weitere Explorationen, weitere Searches, weitere Validierungen. Das Abbruch-Signal ist das unbeliebte Tool, das als erstes aus dem Set gestrichen wird. Das ist ein Fehler.
Es gibt in der Entwicklungswelt eine kollektive Obsession mit Produktivität: Jeder Agent soll laufen. Jede Pipeline soll gefüllt sein. Jede Idle-Zeit ist verschwendete Zeit.
Diese Intuition ist falsch — und in Agent-gestützten Workflows aktiv schädlich.
Agent-Pipelines haben ein Ideen-Inflations-Problem. Weil Agenten schnell und billig in der Konzeptphase sind, entstehen Tasks schneller als sie ausgeführt werden können. Der Backlog wächst. Die Priorisierung verschlechtert sich. Teams verlieren den Überblick, welche Agent-Projekte noch relevant sind und welche durch neue Erkenntnisse überholt wurden.
Kill Policy ist der bewusste Entscheid: Dieses Projekt wird gestoppt. Nicht pausiert, nicht deprioritisiert — gestoppt.
Das klingt einfach. In der Praxis ist der Zeitpunkt, an dem ein Agent-Projekt gestoppt werden sollte, fast immer der Zeitpunkt, an dem das Team das meiste investiert hat und die Sunk-Cost-Falle zuschnappt.
Drei Kategorien helfen bei der Priorisierung:
| Label | Bedeutung | Typischer Anteil |
|---|---|---|
| ROI-High | Klarer Produktivitätsgewinn, kurzer Feedback-Loop | 30 % |
| Strategic | Langfristiger Architektur-Wert, kein sofortiger ROI | 30 % |
| Experimental | Exploration, hohe Abbruch-Wahrscheinlichkeit | 40 % |
Experimental-Projekte bekommen ein explizites Timeout. Nach X Tagen ohne messbaren Fortschritt: Kill. Kein Meeting, keine Retrospektive — einfach stoppen.
Der Mythos der 100-%-Agenten-Auslastung ist das Äquivalent des Manager-Mythos, dass 100-%-Kalender-Auslastung Produktivität bedeutet.
Reactive Slots sind explizit reservierte Zeitfenster für unvorhergesehene Tasks, Bugs, dringende Reviews. Ein Workflow ohne Reactive Slots ist ein Workflow, der bei jedem Incident zusammenbricht, weil keine Kapazität für Reaktion eingeplant ist.
Deep Slots sind ungestörte Zeitblöcke für Architektur-Arbeit, komplexe Diagnosen, Code-Exploration ohne Zeit-Druck. Agenten sind in Deep Slots besonders effektiv — nicht weil sie mehr Output produzieren, sondern weil die Qualität des Outputs höher ist, wenn der Entwickler ausreichend Kontext für echtes Review hat.
Stabilität ist produktiver als permanenter Output. Ein Agent, der 20 % der Zeit läuft und ausnahmslos reviewte Ergebnisse produziert, schlägt einen Agenten, der 100 % der Zeit läuft und 60 % ungeprüften Code in die Codebasis pumpt.
Die Idle Time zwischen Agent-Tasks ist die Zeit, in der ein erfahrener Entwickler die eigentliche Arbeit macht: Architektur-Entscheidungen treffen, Technical Debt bewerten, Prioritäten setzen. Das sind Tätigkeiten, die kein Agent übernehmen kann — und die schlechter werden, wenn sie in die Lücken eines überfüllten Agent-Workflows gequetscht werden.
Die vorherigen Kapitel haben die Dimensionen einzeln beleuchtet. Dieses Kapitel bringt sie zusammen in ein konkretes, täglich anwendbares Modell.
Das ist kein idealisiertes Szenario. Das ist ein rekonstruierter Arbeitstag aus meiner eigenen Praxis und den Erfahrungen, die in Brokk AI eingeflossen sind.
Morgen (08:00–09:00): Triage und Priorisierung. Der Tag beginnt nicht mit einem geöffneten Agenten. Er beginnt mit einer Übersicht: Welche Agent-Tasks laufen? Welche PRs warten auf Review? Welche Diagnose-Outputs brauchen menschliche Freigabe?
Das Ziel dieser ersten Stunde ist nicht Implementierung. Es ist Orientierung. Welche Tasks sind heute ROI-High, welche können warten? Welche gestrigen Agent-Outputs erfüllen die Review-Kriterien — und welche müssen zurück in den Diagnose-Modus?
Vormittag (09:00–12:00): Deep Work mit lokalen Agenten. Das ist die primäre Implementierungszeit. Komplexe Tasks, Architektur-Entscheidungen, Refactoring. Lokale Agenten im Diagnose/Solve-Pattern. Strikte Session-Hygiene: neue Session für jeden separaten Task, keine Kontext-Akkumulation über Aufgabentypen hinweg.
Warnsignale werden aktiv überwacht: Mehr als 20 Messages? Session-Reset. Mehr als 60 % Context-Window? Kontext prunen. Mehr als 5 große Tool-Results? Zusammenfassen und komprimieren.
Mittag (12:00–13:00): Reactive Slot. Explizit reserviert. Keine geplanten Aufgaben. Bugs, dringende Reviews, Rückfragen aus dem Team. Wer diesen Slot mit geplanten Tasks füllt, rächt sich nachmittags.
Nachmittag (13:00–17:00): Review und Cloud-Tasks. Agent-generierte PRs reviewen — fokussiert, mit Guided Review. Cloud-Agenten für isolierte, delegierbare Tasks: Dokumentation, Recherche, Marketing-Copy. Experimental-Projekte evaluieren und bei Bedarf Killed erklären.
Ende (17:00–17:30): Status-Update und Session-Closing. Offene Agent-Sessions schließen. Diagnose-Outputs dokumentieren, die relevant für morgen sind. Backlog-Pflege: Welche Tasks bekommen morgen welches Label?
Jede Aufgabe, die zur Bearbeitung ansteht, durchläuft dieselbe Entscheidungsstruktur:
Aufgabeneingang
│
▼
Isoliert und delegierbar?
├─ JA ──► Cloud Agent Layer
│ └── Review bei Rückkehr
└─ NEIN
│
▼
Scope und Risiko klar?
├─ NEIN ──► Diagnose-Modus
│ └── Solve-Gate → Freigabe → Solve-Modus
└─ JA
│
▼
Context-Window-Budget verfügbar?
├─ NEIN ──► Session-Reset
│ └── Briefing-Pattern für neue Session
└─ JA
│
▼
Lokaler Agent, Solve-Modus
└── PR ≤ 300–500 Zeilen → Review-Pipeline → Merge
Session-Hygiene ist kein einmaliges Setup. Es ist eine tägliche Gewohnheit — ähnlich wie Code-Commits oder Backlog-Pflege.
Konkrete Praktiken:
Task-Start — Briefing-Pattern. Jede neue Session beginnt mit einem kompakten Briefing: Aktueller Stand des relevanten Codes, was der Agent wissen muss, was er nicht wissen soll. Zwei bis drei Absätze. Nicht mehr.
Während der Session — aktives Context-Pruning. Tool-Results komprimieren statt akkumulieren. Bei Kontextüberschreitung nicht „weiterreden“ — Session resetten.
Task-Ende — explizites Closing. Was wurde entschieden? Was ist offen? Diese Information gehört in ein Ticket oder ein Design-Doc — nicht in den Kontext der nächsten Session.
Das Paradox der Session-Hygiene: Sie spart Zeit, indem sie Zeit kostet. Wer drei Minuten am Task-Anfang in ein Briefing investiert, spart dreißig Minuten in der Mitte, wenn die Session nicht degradiert.
Dieses Dokument kratzt an der Oberfläche. Es beschreibt das „Was“ und das „Warum“ — die konzeptuelle Ebene eines Operating Models für die Agent-Ära.
Was es nicht enthält: Das konkrete „Wie“ in einer echten Enterprise-Codebasis. Die Hands-on-Arbeit mit Tools, die im realen Produktionseinsatz scheitern und warum. Die Feinheiten des Diagnose-Prompts, der tatsächlich Confidence/Risk/Cost-Assessments produziert, die man verwenden kann. Die Konfiguration eines Review-Bots, der Architektur-Violations erkennt, die automatisierte Tools nicht sehen. Den Unterschied zwischen einem Workspace-Fragment, das den Kontext präzise macht, und einem, das die Session vergiftet.
Das sind Dinge, die sich in einem Whitepaper nicht vermitteln lassen. Die brauchen echten Code, echte Fehler, echte Codebasen.
Für Entwickler, die sich in den beschriebenen Problemen wiederfinden — die mit Kontextrott zu kämpfen haben, die von der PR-Flut überrollt werden, die das Vier-Säulen-Framework als Diagnosewerkzeug für ihren eigenen Workflow nutzen wollen — gibt es einen nächsten Schritt.
Context Engineering für Enterprise-Codebasen ist ein 1- bis 2-tägiger Workshop für Senior Developers und Tech Leads. Kein Folienvortrag. Keine Einführung in die Basics. Hands-on-Arbeit mit echten Enterprise-Code-Strukturen, Live-Demos in realen Codebasen, Guided Review über echte Agent-Outputs.
Wer den Workshop besucht, arbeitet nicht mit synthetischen Beispielen. Wir arbeiten mit dem Code, den die Teilnehmenden mitbringen.
Wenn du dich in den beschriebenen Problemen wiederfindest, lass uns reden.
Senior Engineer mit 18+ Jahren Erfahrung in Enterprise-Softwareentwicklung. War Context Engineering Lead bei Brokk AI (2025–2026). Heute Independent Consultant, Context Engineering für Enterprise-Codebasen. Arbeitet an der Schnittstelle von Tool-Entwicklung und Enterprise-Praxis. Was er über Context Engineering weiß, hat er nicht aus Lehrbüchern, sondern aus dem Debugging von Tools, die er selbst gebaut hat.
Context Engineering. Die Disziplin, die Art und Menge der Information zu steuern, die einem LLM bei einem Inference-Call zur Verfügung steht — mit dem Ziel, maximale Aufgabenrelevanz bei minimalem Token-Overhead zu erreichen.
Kontextrott (Context Rot). Die progressive Degradierung der LLM-Performance innerhalb einer Session durch Akkumulation irrelevanter oder veralteter Kontext-Information.
Diagnose-Modus. Eine explizite Phase im Agent-Workflow, in der der Agent erkundet und Hypothesen formuliert — ohne Code-Changes vorzunehmen — bis zur menschlichen Freigabe (Solve-Gate).
Solve-Gate. Der Freigabepunkt zwischen Diagnose-Modus und Solve-Modus; menschlicher Checkpoint, der sicherstellt, dass der Agent das Problem vollständig verstanden hat, bevor er implementiert.
Workspace-Fragment. Ein selektiv extrahiertes Code-Fragment (Methode, Interface, Typ-Definition), das in den Kontext injiziert wird — statt der vollständigen Quelldatei.
Lost-in-the-Middle. Das empirisch belegte Phänomen, dass LLMs Information am Anfang und Ende des Kontextfensters besser verarbeiten als in der Mitte — mit direkter Auswirkung auf die Relevanz der Kontextpositionierung.
Kill Policy. Ein explizites Entscheidungsframework, das definiert, unter welchen Bedingungen ein Agent-Projekt gestoppt wird — als Gegenmaßnahme zu Sunk-Cost-Falle und Ideen-Inflation.
Session-Hygiene. Die Praxis des aktiven Kontext-Managements innerhalb und zwischen Agent-Sessions: Briefing-Pattern, Context-Pruning, Task-bezogene Session-Resets.