Warum KI-Entwickler oft langsamer werden (und 3 Lösungen)

Wer nach einer Copilot-Session `git diff` liest, sieht es sofort: Code den kein Mensch so geschrieben hätte. Loops wo Comprehensions reichen. API-Calls in der falschen Reihenfolge. Fehlerbehandlung die funktioniert, aber nicht produktionsreif ist. Die METR-Studie (Juli 2025) zeigt das Ergebnis: Entwickler brauchen mit KI-Tools 19% länger für Tasks, nicht weniger.

Das ist nicht ein Problem von "Entwickler sind zu faul zum Prompt Engineering". Es ist ein Struktur-Problem: KI-Tools unterbrechen den Fluss, bauen technische Schulden auf, und schaffen Koordinations-Overhead in Teams die keine Best Practices haben. Wer nur "schreib mir einen REST-API-Client" in Claude tippt und hofft, bekommt genau das Problem. Drei Lösungen funktionieren: andere Prompting-Strategien, adapted Code-Review Prozesse, und explizite Team-Konventionen.

Das Context-Switching Problem

Der erste Druck-Punkt ist auch der sichtbarste: Im IDE zwischen Code schreiben und KI-Tool prompting zu springen kostet Attention. Nicht 5 Sekunden, sondern 5 Minuten kognitiver Overhead. Ihr verlasst eure aktuelle Task, schreibt eine Prompt, wartet auf Output, prüft den Code, integriert ihn oder schreibt die Prompt um. Die ganze Zeit baut sich die mentale Ladung ab die ihr für die eigentliche Architektur-Entscheidung braucht.

Die Lösung heißt nicht "bessere Prompts schreiben". Sie heißt: KI-Tools mit Kontext-Wissen integrieren. Cursor IDE macht das im Ansatz — es sieht euer ganzes Repo und kann dadurch bessere Completions machen ohne dass ihr extra prompting betreiben müsst. Ein CI/CD-System das KI nutzt um Logs zu interpretieren und Fehler vorzuschlagen, arbeitet am Kontext statt über den UI-Umweg. Das ist nicht "Prompt Engineering" im klassischen Sinn, das ist Architektur-Entscheidung.

AI Slop und Code Churn

GitClear hat das Code-Qualitäts-Problem dokumentiert: Code Churn — also Re-Writes, Fixes, Rollbacks innerhalb von zwei Wochen — hat sich seit Einführung von KI-Tools nahezu verdoppelt. Das ist nicht weil KI grundsätzlich schlechter ist, sondern weil KI-Code oft gemittelt ist — nicht für euer Projekt optimiert, nicht für eure Konventionen, nicht für eure Dependencies. Das führt zu Situationen wo der Code "funktioniert" aber nicht in euer System passt.

Ein anderes Problem ist noch deutlicher: Entwickler die neu mit KI-Tools arbeiten, übernehmen alles was rauskommt. Keine Review, keine Integration in die bestehende Architektur, keine Prüfung auf Edge Cases. Das ist nicht die Schuld der KI, das ist die Schuld eines Mindsets das sagt "jetzt geht es schneller, Qualitätskontrolle ist optional". Teams die das Problem gelöst haben, haben Code-Review-Prozesse eingeführt die speziell für KI-generierte Code ausgelegt sind: Fokus auf Architektur-Konsistenz statt nur auf Funktionalität, explizite Checklisten für Edge Cases, und die Anforderung dass reviewende Entwickler auch die Original-Prompt sehen.

Keine Best Practices = Chaos

Das dritte Problem ist das versteckteste: Jeder nutzt KI-Tools anders. Der eine nutzt Claude für Architektur-Entwürfe, der andere für Unit-Test-Generation. Jemand anderes passt Copilot-Completions direkt rein. Das führt zu Code der von unterschiedlichen "Autoren" kommt und sich dementsprechend unterschiedlich anfühlt. Error Handling ist an manchen Stellen grandios, an anderen nicht vorhanden. Naming-Konventionen driften auseinander. Das ist nicht neu — das problem gibt es auch ohne KI — aber KI multipliziert es, weil KI sehr flexibel ist und an jede Konvention angepasst werden kann, das aber nur funktioniert wenn die Konvention explizit gemacht wird.

Drei Lösungen

Das erste ist Prompt Engineering, aber nicht im Sinn von "bessere Prompts schreiben". Es ist spezifisches Prompt Engineering für euer Team: Was ist die beste Prompt-Strategie für REST-API-Design in eurem Stack? Wie formuliert ihr das so dass die KI-Tools nicht 5 verschiedene Patterns raushauen sondern genau das eine das mit euren Konventionen passt? Das ist kein Marketing-Training, das ist Ingenieur-Arbeit.

Das zweite ist Code-Review adaptieren. KI-generierter Code braucht andere Review-Kriterien als handgeschriebener. Ihr schaut nicht auf "ist das elegant", sondern auf "passt das in unsere Architektur, gibt es Edge Cases die KI nicht gesehen hat, ist das Dependencies richtig". Das ist schneller wenn ihr es richtig macht, und verhindert den Code Churn.

Das dritte ist Best Practices etablieren. Nicht "das ist beste Praxis", sondern "das ist unsere Praxis, und so prompted ihr KI-Tools damit sie das verstehen". Git-Konventionen, Naming Patterns, Error Handling, wo KI-Tools zum Einsatz kommen und wo nicht. Das ist nicht sexy, aber es ist der einzige Weg um als Team schneller zu werden statt langsamer.

Quellen: METR (Juli 2025) — RCT mit 16 professionellen Entwicklern, 246 Tasks. GitClear — "Coding on Copilot: 2023 Data Suggests Downward Pressure on Code Quality" (2024).