Die These, dass KI-Coding den Aufbau von Expertise verhindern kann, ist für beide Seiten unbequem. Sie behauptet nicht, dass Coding-Agenten nutzlos sind, und fordert keine Rückkehr zu handgeschriebenem Boilerplate. Sie stellt eine praktische Frage: Was passiert mit technischem Urteilsvermögen, wenn Unternehmen bereits Claude Code, Cursor, Codex, Copilot-ähnliche Werkzeuge, Gemini CLI oder OpenCode nutzen und genau die Arbeit delegieren, an der Entwickler früher gelernt haben?

Entwickler zwischen KI-Coding-Agent, Architektur, Tests und Review

Auslöser war eine Hacker-News-Diskussion über Lars Fayes Essay “AI Coding will Prevent Expertise”. Im Zentrum steht der Verlust kognitiver Reibung: Debugging, Dokumentation, Irrtum, Verständnis für Grenzen und Tradeoffs. Die Diskussion traf einen Nerv, weil viele Teams das bereits spüren. KI erzeugt mehr Code, Tickets, Designnotizen und Review-Kommentare, als Menschen in Ruhe verstehen können.

Der wichtige Punkt

Faye beschreibt das Paradox des erfahrenen Orchestrators. Am meisten profitieren erfahrene Entwickler, weil sie Agenten widersprechen können. Sie erkennen schlechte Abstraktionen, erfundene APIs, versteckte Migrationskosten und Änderungen, die später schwer wartbar sind. Sie stellen bessere Fragen, weil sie schon eine Vorstellung guter Antworten besitzen.

Damit entsteht ein Ausbildungsproblem. Neue Entwickler bekommen Werkzeuge, die Expertensteuerung verlangen, bevor sie Experteninstinkte aufgebaut haben. Der Agent kann sie produktiv aussehen lassen, aber fehlende mentale Modelle verdecken: Datenflüsse, Systemgrenzen, Aussagekraft von Tests, Fehlermodi und Wartungskosten.

Das ist keine Sehnsucht nach Leid. Ein Teil der Reibung war Verschwendung; ein anderer Teil war Lehre. Wenn KI beides zugleich entfernt, gewinnt die Organisation sichtbare Geschwindigkeit und verliert möglicherweise dauerhaftes Verständnis.

Warum die Debatte verfing

Eine Seite verglich KI mit Compiler, IDE, Autovervollständigung und Stack Overflow. Jede Werkzeugschicht nimmt manuelle Arbeit ab. Die andere Seite antwortete: KI kann nicht nur Tipparbeit entfernen, sondern Denken überspringen. Ein Compiler liefert keine komplette Architektur; Stack Overflow lieferte Fragmente. Ein Agent kann Diff, Erklärung und Tests in einem Durchgang erzeugen.

Beide Seiten haben teilweise recht. Niedrigwertige Arbeit zu entfernen ist gut. Feedbackschleifen zu entfernen ist riskant. Die Frage lautet daher nicht, ob KI in die Entwicklung gehört, sondern welche Schleifen erhalten bleiben: Diff-Lesen, Design, relevante Tests und menschliche Verantwortung.

Die Unternehmensfalle

Unternehmen messen Einführung gern über Durchsatz: mehr Pull Requests, schnellere Tickets, mehr generierte Tests. Diese Zahlen helfen nur mit Qualitätssignalen. Ein Team kann mehr Code generieren, als es lesen und warten kann. Dann wird scheinbare Produktivität zu Verständnis-Schuld.

Gefährlich ist die Botschaft: Wer manuell schreibt, ist langsam. Sie verdrängt Arbeit, die Produkte schützt: Anforderungen hinterfragen, Diffs lesen, Randfälle verfolgen, große Änderungen ablehnen und fragen, ob eine Funktion überhaupt gebraucht wird.

KI vermehrt auch Begleitmaterial. Tickets werden länger, Designnotizen zahlreicher, Review-Tools gesprächiger. Teams filtern Artefakte, die präzise klingen, aber nicht immer echte Entscheidungen darstellen.

Junioren brauchen mehr als Antworten

Ein Senior nutzt den Agenten als ausdauernden Partner, weil er ihn prüfen kann. Ein Junior nutzt ihn leicht als Antwortmaschine. Das ist keine Moralfrage, sondern eine Frage des Vorwissens.

Gutes Lernen mit KI zwingt das Modell zuerst zur Erklärung: System beschreiben, Einschränkungen nennen, Optionen vergleichen, Fragen stellen und wichtige Tests benennen. Erst danach sollte Code entstehen. Der Agent soll Tutor und Reviewer sein, nicht Patch-Automat.

Direkte Übung bleibt nötig: Debugging ohne KI, fremden Code lesen, kleine Funktionen selbst schreiben, Design im Review erklären. Das sind keine nostalgischen Rituale, sondern Training für das Urteilsvermögen, mit dem Agentenantworten bewertet werden.

KI kann auch lehren

Richtig eingesetzt beschleunigt KI Lernen. Sie kann ein Legacy-Modul erklären, Framework-Beispiele liefern, Datenbankoptionen vergleichen oder eine Teststrategie kritisieren. Das ist wertvoll, wenn die Alternative stilles Feststecken ist.

Der Unterschied liegt in der Aufgabenstellung. “Schreib die Funktion” liefert Ergebnis. “Erkläre das System, stelle Fragen, nenne Alternativen und Risiken” liefert Verständnis. Dasselbe Muster gilt für Analyse, Recht, Marketing und Support: KI erzeugt schneller, als Menschen prüfen. Ohne Domänenwissen wird polierte Ausgabe zum Risiko.

Muss man KI-Code vollständig lesen?

Adam Tornhills Text über die Kontrolle der Unsicherheitsmaschine liefert Ausgleich. Vielleicht muss nicht jede Zeile gleich intensiv gelesen werden. Softwareentwicklung vertraut bereits Bibliotheken, Compilern und Datenbanken.

Selektives Vertrauen braucht jedoch Grenzen: klare Verträge, starke Tests, Beobachtbarkeit, kleinen Wirkungsradius und bekannte Architektur-Invarianten. Jemand muss wissen, welche Invarianten zählen. Wenn niemand erklären kann, warum eine Änderung sicher ist, reichen grüne Tests nicht.

Review sollte risikobasiert sein. Eine isolierte UI-Änderung ist nicht Authentifizierung, Zahlungen, Datenmigration, Nebenläufigkeit oder Security-Code. KI-generierter Code braucht keine mystische Angst, aber einen menschlichen Besitzer.

Auto Mode erhöht den Anspruch

Die Debatte um Claude Code auto mode zeigt die Dringlichkeit. Weniger Bestätigungen sind bequem, aber je weniger ein Agent fragt, desto wichtiger ist der Rahmen davor. Erlaubte Verzeichnisse, Kommandos, Abhängigkeiten, Migrationen, CI, generierte Dateien und menschliche Freigaben müssen definiert sein.

Autonomie ohne Politik wird Vertrauen aus Müdigkeit. Gute Abläufe beginnen mit Untersuchung, Plan, Fragen, Freigabe riskanter Aktionen und kleinen Diffs. So verschwindet Wiederholung, nicht Urteilskraft.

Praktische Regeln

Jede KI-unterstützte Änderung braucht einen menschlichen Owner, der Ziel, Risiko und Rollback erklären kann. Nicht triviale Arbeit braucht eine kurze Designnotiz: Umfang, Tests, Migration, Betriebsrisiken. Große unsichtbare Refactorings sollten selten sein.

Tests sind Pflicht, ersetzen Review aber nicht. Reviewer suchen erfundene APIs, unnötige Abstraktionen, neue Abhängigkeiten, versteckte Zustandsänderungen und Code, den der Autor nicht erklären kann. Übungen ohne KI halten Debugging, Lesen und Design lebendig.

Metriken sollten Fehler in Produktion, Rollbacks, Review-Last, Wartbarkeit und Verstehenszeit messen, nicht nur PR-Durchsatz. Steigen Codevolumen, Schulden und Incidents gemeinsam, ist die Einführung nicht erfolgreich.

Reife Position

Die Antwort ist nicht, Coding-Agenten zu verbieten. Sie müssen als Engineering-Management-Thema behandelt werden. Sie sind stark, wenn sie mechanische Last senken und Exploration erweitern. Sie sind gefährlich, wenn sie Urteil über Architektur, Risiko und Wartung ersetzen. Entwickler werden vielleicht weniger Rohcode schreiben; Systeme, Fehler und Verantwortung müssen sie weiterhin verstehen.