KI-Coding-Agents im Team einführen

Drei Phasen, eine Entscheidung am Tag 90

90 Tage sind kein vollständiger Rollout, sondern ein Entscheidungsfenster für ein erstes Team-Experiment. Phase 1 testet die Hypothese, ob ein kleines Pilotteam den Agent auf der eigenen Codebasis zum Laufen bringt. Phase 2 prüft, ob der Produktivitätsgewinn die Messung übersteht, jenseits von Selbstauskunft. Phase 3 entscheidet, was bleibt, was Regel wird und was beerdigt wird. Wer alle drei Phasen parallel ansetzt, beantwortet keine sauber.

Wann der Betriebsrat ins Spiel kommt

Wenn Ihr Unternehmen einen Betriebsrat hat und Sie firmeneigene Agent-Accounts mit Admin-Zugriff einrichten, greift in den meisten Fällen das Mitbestimmungsrecht. Das klingt nach Bürokratie, ist aber lösbar. Der Schlüssel: Sprechen Sie früh mit dem Betriebsrat, nicht erst nach dem Pilotprojekt.

Warum US-Playbooks im deutschen Mittelstand nicht funktionieren

Die meisten Anleitungen für Coding Agents stammen aus dem Silicon Valley. Sie gehen von neuen Projekten aus, nicht von gewachsenen Systemen. Von kleinen Teams ohne Betriebsrat, nicht von deutschen Mittelständlern mit fünfzehn Jahre altem Java-Code. Wer diese Anleitungen eins zu eins übernimmt, kauft Lizenzen, die nach sechs Monaten verstauben.

Wenn erfahrene Entwickler skeptisch sind

Senior-Entwickler reagieren oft zurückhaltender auf Coding Agents als Juniors. Das ist kein Widerstand gegen Veränderung. Es ist ein Urteil, das auf Erfahrung beruht. Wer diese Skepsis als Problem behandelt, verliert das beste Frühwarnsystem im Team.

Wer in den Pilot gehört (und wer nicht)

Pilot-Teams werden in den meisten Organisationen aus Freiwilligen zusammengestellt. GitHubs eigene Rollout-Doku empfiehlt diesen Pfad explizit. Das ist auch der Grund, warum die meisten Pilotbefunde im Rollout zerfallen: Sie messen in der Population, die ohnehin wollte, und rollen an die Population aus, die nicht gefragt hat. Sieben konkrete Kriterien drehen das um, von Repräsentativität über mittlere Kritikalität bis zur eingeplanten Skeptikerin im Team. Zwei davon sind nicht handelbar, fünf sind echte Kompromisse mit echten Konsequenzen.

Pilot mit zwei Kohorten statt Big Bang

Ab vierzig Entwicklern ist ein Rollout für alle auf einmal riskant. Zwei kleine Pilotgruppen mit klaren Erfolgskriterien liefern nach sechs Wochen belastbare Daten. Eine Gruppe arbeitet an unkritischem Code, die andere an wichtigeren Stellen. Was beide trennt, ist die Review-Intensität.

Ausführlicher Beitrag folgt.

Gemeinsames Vokabular aufbauen

Ein Team, das dasselbe Werkzeug benutzt, aber unterschiedliche Begriffe dafür hat, produziert keine konsistenten Ergebnisse. Die Muster aus der Schulung sollten später in den Review-Kommentaren auftauchen. Sonst bleibt die Schulung ein Zertifikat ohne Wirkung.

Ausführlicher Beitrag folgt.

Der Engpass verschwindet nicht, er wandert

Nach dem Rollout schreiben Ihre Entwickler schneller Code. Aber Review, QA und Betrieb laufen weiter im alten Tempo. Das Ergebnis: mehr Pull Requests in der Warteschlange, mehr Incidents in der Rufbereitschaft. Die Engstelle ist nicht weg, sie ist umgezogen.

Token-Budget als Führungsaufgabe

Lizenzpreis ist nur die halbe Rechnung. Wer Claude Code, Cursor oder Copilot ernsthaft einsetzt, muss Token-Verbrauch, API-Aufschläge und Plan-Limits verstehen. Ein Senior, der Sonnet 4.7 unbegrenzt durchlaufen lässt, kostet schnell mehr als seine Lizenz. Ohne Budget-Disziplin auf Team-Ebene wird die Monatsabrechnung zur Überraschung.

Vier Metriken, drei Dimensionen, eine Attribution

DORA, SPACE und DX Core 4 wurden vor dem KI-Kontext stabilisiert. Keines beantwortet allein, ob der Agent etwas bringt. Ein bewusst kleines Vier-Metriken-Set über drei sich widersprechende Dimensionen, an Team-Ebene gebunden, mit Attribution am Commit, liefert die Antworten, die CFO und VP Engineering gleichzeitig brauchen. Acceptance Rate und Lines of Code gehören in keinen Bericht.

Fünf Variablen, ein Conversion Factor

Das Vendor-ROI-Modell scheitert beim CFO an einer einzigen Frage: Wo kommen die 30 Prozent her? Ein Modell, das Diligence übersteht, hat fünf Variablen statt einer Zahl. Brutto-Speedup, Tool-Kosten, indirekte Kosten, Downstream-Conversion-Faktor und Risiko-Aufschlag. Die durchgerechnete Bandbreite für ein 50-köpfiges Engineering-Team zeigt: Bei niedriger Conversion bleibt der Case auch über drei Jahre negativ, bei hoher Conversion trägt sich die Investition ab Jahr 2. Der Unterschied liegt nicht im Werkzeug, sondern im Conversion Factor.

Was BaFin und MaRisk für Coding Agents bedeuten

In regulierten Branchen (Banken, Versicherungen, Finanzdienstleister) gibt es zwei Schichten zu beachten. Der Agent selbst ist ein IT-System, das dokumentiert werden muss. Sein Output ist Software, die eigene Prüfungen braucht. Die BaFin-Orientierungshilfe vom Dezember 2025 macht diese Trennung zum ersten Mal aufsichtlich greifbar.

Wann die DSGVO bei Coding Agents wirklich greift

Drei Risikoebenen werden in der Praxis vermischt: Datenschutzrecht, Geschäftsgeheimnisschutz, Mitbestimmung. Die Datenschutzkonferenz hat das häufigste Coding-Szenario bereits 2024 eingeordnet. Wo personenbezogene Daten doch fließen, geben vier Architekturentscheidungen den Ausschlag im Termin mit dem Datenschutzbeauftragten. Tools sind nicht DSGVO-konform; Deployments sind es.

Urheberrecht und KI-generierter Code: Was Teams absichern müssen

Die BMJ-FAQ vom März 2024 ordnet den rein maschinellen Anteil als regelmäßig nicht urheberrechtlich geschützt ein, keine bindende Rechtsquelle, aber für die Praxis tragfähig. Das eigentliche Risiko liegt zwei Ebenen tiefer: in der unbemerkten Open-Source-Lizenzkette, im Vertragsdach zum Kunden und in der ab Dezember 2026 anwendbaren EU-Produkthaftung. Drei Controls (Lizenz-Scanner in der CI, Prompt-Provenance über den Git-Trailer Assisted-by, Vendor-Indemnification im Beschaffungsvertrag) bringen diese Risiken in gut zweieinhalb Engineering-Tagen und einem Procurement-Zyklus unter Kontrolle.

EU AI Act: Wann der Agent-Output zum Hochrisiko wird

Ein Coding Agent ist selten selbst ein Hochrisiko-System nach EU-Recht. Der Code, den er schreibt, kann aber Teil eines solchen Systems werden, zum Beispiel in der Kreditwürdigkeitsprüfung oder im Versicherungs-Scoring. Die Unterscheidung ist wichtig, weil sie ganz unterschiedliche Pflichten auslöst.

Ausführlicher Beitrag folgt.

Security-Review für Agent-Werkzeuge

Der gefährlichste Moment ist, wenn ein neues Werkzeug ohne Prüfung in den Agent-Zugriff wandert. Der Hebel liegt bei den Berechtigungen, nicht bei der Modellwahl. Ein Review auf Werkzeug-Ebene verhindert, dass der Agent in einer Schleife einen Cloud-Speicher umkonfiguriert.

Ausführlicher Beitrag folgt.