Ein CTO liest einen Business Case. Ein paar Analysten-Reports, zwei hitzige Hacker-News-Threads, eine Produktivitätsstudie aus San Francisco. Die Zahlen klingen verlockend: zweistellige Produktivitätsmultiplikatoren. Er bestellt Cursor-Lizenzen für fünfzig Entwickler. Der Rollout ist für den übernächsten Sprint geplant.
Drei Wochen später steht alles still.
Der Betriebsrat hat Fragen. Das Security-Team blockiert, weil Code und Prompts in eine nicht freigegebene Cloud-Umgebung fließen. Die Entwickler melden, dass der Agent den fünfzehn Jahre alten Java-Monolithen nicht versteht, in dem die Hälfte der Produkt-Roadmap steckt.
Die Tools sind nicht kaputt. Das Playbook ist falsch.
Das Valley-Playbook passt nicht
Die englischsprachige Literatur zu KI-Coding-Agents liest sich, als säße jeder Leser auf einem frischen Y-Combinator-Repo. Im deutschen Mittelstand sieht die Realität anders aus.
Die Codebasis ist alt. Fünfzehn Jahre Java, COBOL-Nachbarn, Geschäftslogik in den Köpfen von drei Personen. t3n hat Anfang April 2026 typische Architekturfehler bei KI-Agenten in Bestandssystemen beschrieben. Das Problem liegt selten beim Modell. Meistens bei der Architektur.
Deployment ist oft gar nicht der Engpass. In regulierten Unternehmen bremsen Compliance, Audit-Trails und der Betriebsratsprozess. In unregulierten eher Zeitmangel und unklare Zuständigkeiten. Die DIHK-Digitalisierungsumfrage 2026 nennt 58 % Zeitmangel und 56 % Komplexität an der Spitze der Hürden. Eine Lizenzentscheidung, die in San Francisco zwei Slack-Nachrichten kostet, braucht in Frankfurt manchmal einen Betriebsvereinbarungs-Entwurf, einen Rollout-Plan und eine Datenschutz-Folgenabschätzung.
Daten dürfen nicht einfach das Haus verlassen. DSGVO, NIS2-Richtlinie, Kundenverträge, interne Security-Vorgaben: Sobald ein Prompt das Unternehmen verlässt, brauchen Sie Antworten. Der erste Prompt mit echten Kunden-IDs in einer Test-Fixture kann je nach Inhalt, Empfänger und Rechtsgrundlage eine Datenverarbeitung im Sinne der DSGVO sein, auch wenn er in einer Entwickler-IDE entsteht.
ROI rechnet sich hier in drei Jahren Gesamtkosten, inklusive Security-Audit und lückenloser Dokumentation. Shipping-Velocity interessiert in der CapEx-Planung niemanden.
Und sobald ein Tool objektiv geeignet ist, Leistung zu messen, entstehen Mitbestimmungsfragen. Der Hebel liegt dann beim Team, nicht beim einzelnen Entwickler.
Wer diese Unterschiede übersieht, kauft Lizenzen, die nach sechs Monaten in der Schatten-IT landen. Wer den vollständigen Rahmen sucht, findet ihn im Leitfaden für Engineering-Leads.
Dieser Text argumentiert aus deutscher Perspektive. Für Österreich und die Schweiz verschieben sich einzelne Details, aber die Logik bleibt ähnlich: Brownfield-Code, sensible Daten und knappe interne Kapazität bestimmen den Rollout stärker als Benchmark-Tabellen.
Dem Agenten das eigene Haus erklären
Der höchste Hebel liegt darin, dem Agenten die eigene Codebasis zu erklären. Nicht in der Lizenzbeschaffung.
In der Praxis heißt das: eine sauber geschriebene CLAUDE.md oder AGENTS.md im Root des Repositories. Darin steht: das Domänenmodell, Namenskonventionen, verbotene Muster, Test-Anforderungen. Der Agent arbeitet dann innerhalb der realen Codebasis, statt seine Greenfield-Fantasie aus Stack Overflow zu extrapolieren.
Dahinter steht Context Engineering: die Kuratierung dessen, was der Agent sehen darf. Welche Module sind lesbar? Welche aus Sicherheitsgründen tabu? Welche Legacy-Muster sind historisch gewachsen und dürfen nicht „modernisiert" werden, weil drei Umsysteme auf genau dieses Verhalten angewiesen sind?
Der Ansatz von IBM zur agentischen Modernisierung nennt das die Strangler-Fig-Variante für Agenten. Die Idee: KI-Funktionen neben einem Legacy-Monolithen einführen, statt ihn zu ersetzen.
Wer diese Kuratierung überspringt, bekommt überzeugenden Code, der die Architektur leise zersetzt.
Die Datenklasse entscheidet
Welcher Agent die höchste Benchmark-Quote erreicht, ist zweitrangig. Wichtiger: Welche Daten verarbeitet er? Wo landen sie physisch?
Ein Prompt, der einen Funktionsnamen umbenennt, ist eine andere Risikoklasse als ein Agent, der sich gerade eine Test-Fixture mit echten Kunden-IDs gezogen hat.
Für Teams mit EU-Residenz-Anforderung gibt es inzwischen ernstzunehmende Optionen. Mistrals europäische Devstral-Modelle sind für Self-Hosting-Szenarien relevant. Für proprietäre Modelle entstehen EU-fähige Enterprise-Wege, etwa über Hyperscaler-Angebote mit regionalem Routing. Open-Source-Modelle wie Qwen laufen für Einzelplatz- oder Evaluationsszenarien auch quantisiert auf Apple Silicon. Jede Option hat ihre eigenen Kompromisse bei Betriebsaufwand, Latenz und Kontextfenster.
Die Entscheidungsmatrix hat sich verschoben: Welches Modell für welche Datenklasse? „Cloud ja oder nein" greift zu kurz.
Für einen großen Teil der Mittelständler, etwa export-orientierte Dienstleister oder B2B-SaaS-Anbieter ohne regulatorische Schwerlast, ist ein EU-gehosteter Managed-Service mit sauberer Governance der pragmatisch richtige Default. Die Debatte dreht sich dort selten um „must self-host". Sie dreht sich um „must govern".
Wer selbst hostet, übernimmt zusätzliche Plattformarbeit: Inferenz-Infrastruktur, Modell-Updates, Embedding-Pipelines, Zugriffskontrolle, Observability und Latenz-Budget verschwinden nicht, sondern landen im eigenen Haus. Für viele Mittelstands-IT-Abteilungen ist genau diese Betriebsfähigkeit die offene Flanke.
Alles, was BaFin-Aufsicht, die DORA-Verordnung für digitale Resilienz, KRITIS-Infrastruktur oder medizinproduktrechtliche Vorgaben berührt, braucht eine eigene Risikoentscheidung. Die BaFin-Fokusrisiken 2026 heben zusätzlich Konzentrationsrisiken bei wenigen großen Cloud-Anbietern hervor.
Wer jetzt segmentiert fährt, hat in zwei Jahren die ruhigere Prüfung.
Die Review-Pipeline kommt vor dem Agenten
Die METR-Studie aus Mitte 2025 hat etwas Unbequemes gemessen: Erfahrene Open-Source-Maintainer an ihren eigenen Repos waren mit früher KI-Assistenz 19 % langsamer, nicht schneller.
Das ist kein allgemeines Gesetz. Das Setup war spezifisch und nicht direkt auf gemischte Enterprise-Teams über wechselnde Task-Typen übertragbar. Aber der Befund ist ein Warnschuss für reife Codebasen.
Der Tenzai-Vendor-Benchmark liefert eine zweite Richtungszahl: Alle getesteten Agenten produzierten in nicht-trivialem Umfang unsicheren Code. In einem Startup ist das ein P1-Ticket. In einer regulierten Organisation ist es ein Compliance-Ereignis.
Erst die Review-Infrastruktur, dann die Agenten-Autonomie.
Konkret bedeutet das:
- Verpflichtende menschliche Freigaben für PRs auf regulierten Codepfaden
- Automatisiertes Security-Scanning im CI/CD, bevor ein Agent Richtung Merge arbeiten darf
- Separate Approval-Gates für Schema-Migrationen und Krypto-Code
Wer an dieser Reihenfolge spart, baut sich die Fehlerquote des Agenten direkt in den nächsten Audit-Report ein.
Audit-Trails entstehen von Tag eins
Die regulatorischen Rahmen unterscheiden sich in Details, laufen aber auf ein gemeinsames Muster zu: nachweisbare menschliche Aufsicht und kontrollierte Änderungsprozesse.
DORA und die BaFin-Aufsicht verlangen das für IKT-Risiko. KRITIS für Cyber-Maßnahmen. Die Medizinprodukteverordnung für Software-Änderungen. Wenn ein Agent eine 400-Zeilen-Änderung am Zahlungsprozess vorschlägt, müssen Sie dem Prüfer zeigen können, was der Mensch daran geprüft hat.
Die BaFin-Orientierungshilfe zu IKT-Risiken bei KI behandelt KI nicht als Tool-Thema, sondern als Governance-Thema mit Anforderungen an Risikomanagement und dokumentierte Verantwortlichkeiten.
Wer die Nachweise erst zusammensucht, wenn der Prüfer angekündigt ist, zahlt drauf.
Besser: Die Agent-Harness von Tag eins auf Audit-Fähigkeit auslegen. Die Harness ist die Schicht aus CLI, Logging und Approval-Regeln um den Agenten herum. Konkret: Strukturierte Commit-Messages, die festhalten, was der Agent vorgeschlagen und was der Mensch verändert hat. Session-Logs in manipulationssicherem Speicher. Klare Eskalationsketten für regulierte Codepfade.
Die Betriebsratsfrage verlangt parallel dieselbe Disziplin aus arbeitsrechtlicher Richtung. Eine Harness, die die Audit-Anforderung erfüllt, bedient die Transparenzanforderung des Betriebsrats fast nebenbei mit.
Erst ein Team, dann die Organisation
Die DIHK-Digitalisierungsumfrage 2026 nennt Zeitmangel (58 %) und Komplexität (56 %) als größte Digitalisierungshürden. Die Hochschule Karlsruhe ergänzt: Nur 21 % der befragten Mittelständler haben überhaupt eine KI-Strategie. Gartner prognostizierte, dass bis Ende 2025 mindestens 30 % der Generative-KI-Projekte nach dem Proof-of-Concept abgebrochen werden.
Die Versuchung heißt „schneller skalieren". Das funktioniert hier nicht.
Ein Team. Ein eng gefasster Use Case. Eine ehrliche Baseline-Messung gegen die tatsächliche Vorperformance. Erst dann Ausweitung, wenn das Team artikulieren kann, was sich verändert hat und warum.
Ein guter Einstiegsfall ist selten der Produktkern. Häufiger: Testabdeckung auf einem bestehenden Service. Pflege der API-Dokumentation. Beide sind messbar, umkehrbar, und sie erzeugen internes Erfahrungswissen, das in der nächsten Phase mehr wert ist als jede zusätzliche Lizenz.
Die Mittelständler, die 2028 vorne sind, haben auf einer langsameren Kurve echte Fähigkeit aufgebaut. Die Anzahl der Cursor-Seats in 2026 wird rückblickend irrelevant sein.
Souveränität als Wettbewerbsvorteil
Die DIHK-Zahlen enthalten noch einen Punkt: Die Mehrheit deutscher Unternehmen sieht sich als stark abhängig von nicht-europäischer Technologie. Geopolitische Spannungen verschieben diese Einschätzung von „Compliance-Haken" zu „strategisches Risiko".
Die traditionelle Mittelstands-Vorsicht wird plötzlich zum Asset. Ein Unternehmen, das jetzt auf EU-residente oder selbst betriebene KI-Infrastruktur setzt, hat 2028 einen auditfähigen Stack, während andere gerade merken, dass ihr Lieblingsanbieter in einer Jurisdiktion sitzt, die sich verschoben hat.
Self-Hosting ist keine Universallösung. Es bleibt eine Option neben gut verwalteten EU-Cloud-Pfaden. Der reife Ansatz für 2026: segmentierte Architektur. EU-gehostete Managed-Services für niedrig-sensitive Arbeit. Strengere Kontrollen oder Self-Hosting für hochsensitive Pfade. Und eine dokumentierte Entscheidung, welcher Pfad welchen Use Case aufnimmt.
Fazit
Die Teams, die im deutschen Mittelstand mit KI-Coding gewinnen, haben ihre Rahmenbedingungen früh verstanden: regulatorisch, architektonisch, organisatorisch. Sie haben die Strategie darum herum gebaut.
Das stärkste Modell bringt wenig, wenn es die eigenen Constraints ignoriert. Modelle wechseln alle paar Monate. Die Rahmenbedingungen bleiben.
Häufige Fragen
- Brauchen wir für regulierte Codepfade zwingend On-Premises?
- Beides ist möglich: On-Premises oder ein EU-gehosteter Managed-Service. EU-Hosting allein reicht aber nicht. Entscheidend bleiben: Auftragsverarbeitungsvertrag, Subprozessoren, Logging, Zweckbindung, Rechtsgrundlage, Zugriffskontrolle, Retention und Exit-Fähigkeit. Für viele Mittelständler ohne regulatorische Schwerlast ist ein EU-gehosteter Service der pragmatisch richtige Default. Für BaFin-, DORA- oder KRITIS-Scope braucht es eine eigene Risikoentscheidung. Eine kontrollierte EU-Betriebsumgebung kann praktikabler sein als Self-Hosting, wenn das Unternehmen die Plattformarbeit nicht selbst zuverlässig leisten kann.
- Sagen SWE-Bench-Werte etwas über unsere 15 Jahre alte Codebasis aus?
- Nur begrenzt. Benchmark-Suites messen isolierte Änderungen auf kuratierten Open-Source-Repos. Die METR-Studie fand bei erfahrenen Maintainern an reifen Repos 19 % Verlangsamung mit KI-Assistenz. Die entscheidende Variable im Brownfield ist Context Engineering, nicht die Benchmark-Zahl.
- Sollten wir mit einem Pilotteam starten oder sofort ausrollen?
- Ein Team zuerst. Ein eng gefasster Use Case. Eine ehrliche Baseline gegen die Vorperformance. Gartner prognostizierte, dass bis Ende 2025 mindestens 30 % der Generative-KI-Projekte nach dem Proof-of-Concept abgebrochen werden. Breites Ausrollen ohne internes Erfahrungswissen erhöht genau dieses Risiko.
- Was ist der erste konkrete Schritt, bevor wir Lizenzen einkaufen?
- Eine CLAUDE.md oder AGENTS.md im Repository-Root. Darin: Domänenmodell, Namenskonventionen, verbotene Muster, Test-Anforderungen. Das kostet einen Tag Senior-Engineering-Zeit und bestimmt, wie viel Wert ein Agent in Ihrer Codebasis tatsächlich heben kann.
Weiterführende Quellen
- IBM: Reimagining Brownfield Application Modernization
- METR: Early-2025 AI Experienced OSS Dev Study · arXiv 2507.09089
- Tenzai: Bad Vibes · Secure Coding Capabilities of Popular Coding Agents
- BaFin: Fokusrisiken 2026 · Digitalisierung · Orientierungshilfe zu IKT-Risiken bei KI
- DIHK: Digitalisierungsumfrage 2026 (PDF)
- Hochschule Karlsruhe: KI-Einsatz im deutschen Mittelstand
- Gartner: 30% of Generative AI Projects Abandoned After POC by End of 2025
- Mistral: Devstral · Devstral 2
- Qwen: Qwen3.6-35B-A3B Model Card · Qwen2.5-Coder-32B-Instruct Model Card · Qwen3-Coder Launch Post
