Die Schattenseiten von KI-Agenten – Skill-Atrophie, kognitive Schulden und der Weg zurück zur Kontrolle

Ich habe in dieser Serie viele Posts damit verbracht zu beschreiben, wie gut das alles funktioniert: warum ich Vibe Coding für komplexe Projekte verlassen habe (Post 11), wie Planungs- und Implementierungsagenten zusammenspielen (Post 12, Post 13), wie ein Test-Agent den Kreis schließt (Post 14), und wie ich am Ende sogar versucht habe, den positiven Effekt zu messen (Post 18).

Dieser Post ist das ehrliche Gegengewicht.

Denn so sehr ich von dem Workflow überzeugt bin – es gibt eine Kehrseite, die ich nicht unterschlagen will. Eine, über die in der Tech-Community gerade heftig diskutiert wird, ausgelöst unter anderem durch den viralen Essay „Agentic Coding is a Trap" von Lars Faye, der einen regelrechten „Agentic Backlash" formiert hat. Die Kernthese ist unbequem: Die Produktivitätsgewinne durch autonome Agenten könnten sich langfristig selbst auffressen – weil das Überprüfen und Debuggen von KI-Code am Ende teurer ist als das Schreiben von Hand. Teurer kognitiv, teurer emotional, teurer finanziell.

Zwei Dinge vorweg, damit der Rahmen klar ist:

Erstens: KI geht nicht mehr weg. Das ist kein Plädoyer gegen den Einsatz von Agenten – ich nutze sie täglich und werde das weiter tun. Es ist ein Plädoyer dafür, die Risiken bewusst im Auge zu behalten und sich Gegenmaßnahmen zu überlegen.

Zweitens: Vieles davon könnte ein temporäres Problem sein. Die Modelle entwickeln sich weiter – zwar nicht mehr im Tempo von vor ein paar Jahren, aber sie tun es. Und die Tools und Agenten drumherum entwickeln sich noch schneller. Es ist gut möglich, dass wir manche dieser Workarounds in zwei Jahren gar nicht mehr brauchen. Aber heute, zum aktuellen Zeitpunkt, ist das Risiko real. Und genau darum geht es hier.

Kapitel 1: Der schleichende Kompetenzverlust

Das ironischste Argument der ganzen Debatte ist ein Henne-Ei-Problem, für das Anthropic in seinem Bericht „How AI is transforming work at Anthropic" den Begriff „paradox of supervision" (Paradox der Aufsicht) geprägt hat. Auf den Punkt gebracht:

Effektiv mit Claude zu arbeiten erfordert Aufsicht – und Claude zu beaufsichtigen erfordert genau die Coding-Fähigkeiten, die durch Übernutzung von KI verkümmern können.

Man muss sich diesen Kreislauf einmal in Ruhe ansehen, weil er so unscheinbar ist:

Um die oft über tausende Zeilen verteilten Änderungen eines Agenten sinnvoll zu überprüfen, braucht man die Fähigkeiten eines erfahrenen Entwicklers. Wenn man aber nur noch „den Hebel zieht" und reviewt, verlernt man genau diese Fähigkeiten. Eine randomisierte Studie von Anthropic – „How AI assistance impacts the formation of coding skills" – legt das nahe: 52 Junior-Entwickler sollten eine neue Python-Bibliothek lernen, einmal mit, einmal ohne KI-Unterstützung. Die Gruppe mit KI schnitt im anschließenden Verständnistest mit 50 % deutlich schlechter ab als die Handarbeit-Gruppe mit 67 % – und die größte Lücke zeigte sich ausgerechnet beim Debugging. Bezeichnend: Wer die KI zum konzeptionellen Nachfragen nutzte, lag bei 65 % und darüber; wer die reine Codegenerierung delegierte, fiel unter 40 %.

Besonders hart trifft es Junior-Entwickler. Code zu reviewen ist wichtig – aber es ist bestenfalls die Hälfte des Lernprozesses. Die andere Hälfte ist die Reibung: das Ringen mit dem Problem, das Sackgassen-Laufen, das Selbst-Debuggen. Wer von Anfang an nur generierten Code „vibe-checkt", baut nie das Fundament auf, auf dem später überhaupt erst gutes Urteilsvermögen wächst.

Und – das ist der unbequeme Teil – auch Senioren sind nicht immun. Simon Willison, ein Entwickler mit fast 30 Jahren Erfahrung und ausgesprochener KI-Enthusiast, berichtet, kein „festes mentales Modell" seiner KI-gestützten Anwendungen mehr zu haben, wodurch „jedes zusätzliche Feature schwerer zu durchdenken" wird.

„Diesmal ist es anders"

Der übliche Konter lautet: Das ist doch nichts Neues. Programmierer waren schon immer skeptisch gegenüber neuen Abstraktionen – bei FORTRAN, bei Compilern, beim Wechsel von C++ zu Java. Und ein Senior, der ins Management wechselt und „eingerostet", war auch noch nie ein Drama.

Der Unterschied: Ein C++-Entwickler, der zu Python wechselte, klagte nicht über „brain fog". Ein Sysadmin, der zu AWS migrierte, verlor nicht sein Verständnis von Netzwerken. Und der eingerostete Senior hatte vorher Jahrzehnte an Reibung und Erfahrung gesammelt – ein Fundament, auf dem er stehen konnte, als sein Job architektonischer wurde.

Was gerade passiert, ist das Gegenteil: Entwickler, die diese Jahrzehnte nie durchlaufen haben, werden direkt in die Orchestrator-Rolle gehoben – die exakt jene Fähigkeiten verlangt, die der Senior in 30 Jahren aufgebaut hat. Wir überspringen den Teil, der die Kompetenz überhaupt erst erzeugt.

Kapitel 2: Technische Schulden vs. kognitive Schulden

Simon Willison hat dafür in seinem Artikel „How Generative and Agentic AI Shift Concern from Technical Debt to Cognitive Debt" eine Unterscheidung geprägt, die ich für die hilfreichste der ganzen Debatte halte:

Technische Schulden sind ein altbekanntes Phänomen. Kognitive Schulden sind das eigentlich Neue: Der Agent produziert funktionierenden Code, aber der Mensch verliert das mentale Modell der Codebase. Solange alles läuft, fällt das nicht auf. Es fällt erst auf, wenn nachts um drei ein kritischer Fehler in Produktion auftritt – und niemand mehr versteht, warum die KI das System so und nicht anders aufgebaut hat.

Das verbindet sich mit etwas, das Dax (Dax Raad), der Schöpfer des Open-Source-Agenten OpenCode, in einem Interview zu Spec Driven Development gesagt hat – und das ich aus eigener Erfahrung unterschreibe:

„Wenn ich an etwas Neuem oder Schwierigem arbeite, ist das Tippen von Code der Prozess, durch den ich überhaupt herausfinde, was wir tun sollten."

Für manche von uns ist Code schreiben nicht nur stupide Fleißarbeit – es ist Denken. Es zwingt dazu, Dinge auf technischer Ebene zu durchdringen: Sicherheit, Performance, Wartbarkeit, Edge Cases. Wer diesen Schritt vollständig an einen Agenten delegiert, spart sich nicht nur das Tippen. Er spart sich auch das Denken – und damit das Verständnis.

Kapitel 3: Spaghetti im Maßanzug

Hier kommt das Problem, das in der Praxis am meisten unterschätzt wird, weil es so harmlos aussieht. KI-generierter Code sieht oft perfekt aus: saubere Syntax, schlüssige Benennung, besteht die ersten Unit-Tests. Addy Osmani nennt das in seiner Analyse das „80%-Problem": Die KI bringt einen schnell auf 80 % – und die restlichen 20 %, in denen die eigentliche Komplexität steckt, kosten überproportional viel.

Andere haben dafür das Bild „Spaghetti-Code im Maßanzug" geprägt. Die Optik täuscht über die Substanz hinweg. Und die Zahlen dahinter sind ernüchternd. Eine Analyse von Stack Overflow sowie ein Report von CodeRabbit (470 ausgewertete Open-Source-Pull-Requests) zeigen seit dem Mainstream-Einzug von Agenten klare Muster:

• Mehr Bugs insgesamt: KI-Code produzierte rund 1,7-mal so viele Fehler wie menschlicher Code – und 1,3- bis 1,7-mal mehr kritische bzw. schwere Probleme.
• Sicherheitsmängel baut KI-Code mit 1,5- bis 2-facher Rate ein – fehlerhaftes Passwort-Handling, unsichere Objektreferenzen.
• Performance-Probleme durch exzessive und teure I/O-Operationen traten bis zum 8-Fachen häufiger auf.
• Unkontrollierte Abhängigkeiten: Agenten installieren bereitwillig neue Bibliotheken, ohne Lizenzen oder bekannte Schwachstellen zu prüfen – und machten doppelt so häufig Fehler bei Nebenläufigkeit und Abhängigkeiten.

Dazu kommt die Annahme-Propagierung: Versteht der Agent eine Anforderung ganz am Anfang falsch, baut er auf dieser falschen Prämisse einen riesigen, in sich konsistenten Feature-Berg auf. Konsistent falsch ist schwerer zu erkennen als offensichtlich kaputt – und je weiter unten im Stapel die Fehlannahme sitzt, desto teurer wird sie.

Genau dieses Problem habe ich in Post 12 ausführlich angepackt: Statt die KI gleichzeitig analysieren, planen und coden zu lassen, setze ich einen spezialisierten Business-Analyst-Agenten davor, der vage Anforderungen erst in präzise Use Cases übersetzt – mit einem Human-in-the-Loop-Checkpoint auf Konzept-Ebene, bevor eine Zeile Code entsteht. Eine falsch verstandene Anforderung kostet dort eine Minute zum Korrigieren; dieselbe Fehlannahme im fertigen Code kostet Stunden. Es ist der alte Engineering-Grundsatz, dass ein Fehler in der Anforderungsphase um Größenordnungen billiger ist als in der Implementierung.

Wichtig ist mir aber auch hier: Das ist ein Workaround, kein Naturgesetz. Ich baue diese Struktur drumherum, weil das Modell heute Mehrdeutigkeit noch mit Annahmen (oder Halluzinationen) füllt, statt von sich aus an der richtigen Stelle innezuhalten und nachzufragen. Würden die Agenten zuverlässig selbst rückfragen, bräuchte es den vorgeschalteten Checkpoint in dieser Form nicht mehr. Bis dahin fange ich die Fehlannahme lieber früh ab, als sie später aus tausend Zeilen wieder herauszuoperieren.

Der Mensch als Flaschenhals

Genau hier – beim Menschen als Engpass – schließt sich ein gefährlicher Kreis mit dem Marketing. Das Versprechen von OpenAI und Anthropic lautet sinngemäß: Jeder Entwickler wird zum 10x- oder gar 100x-Entwickler. Boris Cherny, der Kopf hinter Claude Code, hat es in einem Interview noch zugespitzter formuliert: „Coding is largely solved" – das Programmieren sei ein gelöstes Problem, weil Claude es übernehmen könne. Er selbst habe seit November 2025 keine Zeile mehr von Hand editiert und shippe täglich Dutzende komplett von Claude geschriebene Pull Requests.

Diese Botschaft ist mächtig – und genau darin liegt ihre Tücke. Denn sie suggeriert, man könne sich darauf verlassen, dass der generierte Code korrekt ist. Cherny formuliert zwar eine wichtige Einschränkung mit („zumindest für die Art von Programmierung, die ich mache"), aber die geht im griffigen Slogan unter. Was hängen bleibt, ist die Schlagzeile: Coding ist erledigt. Agenten neigen ohnehin dazu, sehr viel Code zu schreiben – und wenn die Erwartungshaltung dann ist, dass das Ergebnis ohnehin stimmt und man nur noch um ein Vielfaches schneller werden muss, gerät der Mensch unter Druck, weniger genau hinzusehen.

Denn um alles sauber zu verstehen und zu reviewen, wären wir der Flaschenhals. Der ehrliche Reviewprozess skaliert eben nicht mit der Generierungsgeschwindigkeit. Die Folge ist vorhersehbar: Laut dem State of Code Developer Survey 2026 von Sonar prüfen nur 48 % der Entwickler KI-generierten Code immer, bevor sie ihn committen – obwohl 38 % zugeben, dass das Reviewen von KI-Logik anstrengender ist als das Reviewen von menschlichem Code. Gleichzeitig vertrauen 96 % dem KI-Code nicht vollständig, während er bereits 42 % des committeten Codes ausmacht: ein klassischer Verifikations-Flaschenhals.

Kapitel 4: Wenn die Kreditkarte glüht

Der letzte und zugleich nüchternste Risikoblock: Geld. Die Kosten eines menschlichen Entwicklers sind fix und bekannt – Gehalt, IDE-Lizenz. Token-Kosten sind ein bewegliches Ziel.

Ein Agent, der sich in einer Endlosschleife verfängt – weil er eine Datei sucht, die nicht existiert, oder versucht, eine Linter-Regel zu umgehen – kann die Token-Kosten eines Sprints von 200 auf 2.000 € in wenigen Tagen explodieren lassen. Man weiß, was die Mitarbeiter kosten; man weiß nicht, was die Token nächsten Monat kosten.

Dazu kommt ein Muster, das jeder kennt, der ein paar Modell-Releases miterlebt hat: hohe Benchmarks, Hype, dann die Realität – und kurz darauf die Klagen, das Modell sei „generft" worden und brauche 2- bis 3-mal so viele Token für dieselbe Aufgabe. Die Modelle stehen auf beweglichem Grund.

Und es gibt eine zweite, subtilere Kostenseite: Vendor Lock-in. Während des großen Claude-Ausfalls im Juni 2026 – betroffen waren Claude.ai, die API und Claude Code – standen ganze Engineering-Teams still: Ihre Workflows, teils ihre eigenen Fähigkeiten, waren bereits so von einem Anbieter abhängig, dass eine Aufgabe, die früher mit Tastatur und Texteditor lösbar war, plötzlich ein Abo bei einem Modellanbieter voraussetzte. Was einmal eine eigene Fähigkeit war, wird so zur Dienstleistung, die man monatlich mietet – und deren Verfügbarkeit, Preis und Qualität man nicht selbst in der Hand hat.

Auf Organisationsebene schlägt das bis in die Bilanz durch: Gartner prognostiziert, dass bis Ende 2027 über 40 % der agentischen KI-Initiativen abgebrochen werden – wegen eskalierender Kosten, unklarem Geschäftsnutzen oder unzureichenden Risikokontrollen, weil sie den Sprung vom Prototyp in die zuverlässige, skalierbare Produktion nicht schaffen.

Die Gegenseite: Vielleicht ist nicht das Agentic Coding die Falle

So weit die Anklage. Für ein ausgewogenes Bild gehört die Gegenrede dazu – und sie ist stark.

Der prominenteste Konter – der Artikel „Agentic Coding isn't the trap – supervising from your head is" – lautet: Nicht das agentische Arbeiten ist die Falle, sondern das Beaufsichtigen im eigenen Kopf. Wer die Validierung von KI-Code allein durch Drüberlesen leisten will, verliert – das ist Review-Müdigkeit mit Ansage. Die Lösung ist nicht weniger KI, sondern bessere Leitplanken: Policy as Code, strenge Compiler-Typen, unbestechliche Linter, automatisierte Runtime-Hooks, eine harte CI-Pipeline. Oder wie es der Artikel zuspitzt: „Der Compiler wird um 16 Uhr nicht müde." Der CI-Server wird zum „Gewissen" des Agenten – ein deterministisches System fängt ab, was ein müder menschlicher Blick übersieht.

Der entscheidende Kniff dabei: Die Prüfungen gehören in die Agenten-Schleife, nicht erst hinter den Pull Request. Fällt der Code durch Compiler, Linter oder Test, korrigiert sich der Agent in einer geschlossenen Schleife selbst – der Mensch reviewt am Ende geprüften, lauffähigen Code statt rohen Output (Guardrails for Agentic Coding, 2026). Dass das nicht nur Bauchgefühl ist, stützt auch die Forschung: Das ArXiv-Paper „ClayBuddy" (2026) ordnet die typischen Agenten-Fehler systematisch in Kategorien und plädiert dafür, Leitplanken direkt in den Agenten-Harness einzubauen, statt Fehler erst im Nachhinein zu überwachen.

Diese Leitplanken sind für mich kein abstraktes Ideal – sie decken sich präzise mit dem Workflow, den ich in dieser Serie beschrieben habe. Genau das ist der Unterschied zwischen „Ich passe schon auf" und einer Kontrolle, die auch dann greift, wenn ich müde bin. Wie ich sie in meinen Projekten konkret einziehe, dazu komme ich weiter unten im Abschnitt „Mein Umgang".

Das zweite Gegenargument ist das der neuen Abstraktionsebene – am prominentesten von Andrej Karpathy als „Software 3.0" formuliert, in dem die natürliche Sprache zur Programmierschnittstelle wird („the hottest new programming language is English"): Früher schrieben Menschen Assembler, heute überlassen wir den Maschinencode dem Compiler – und niemand trauert. Der Entwickler der Zukunft schreibe eben keine Zeilen mehr, sondern präzise Spezifikationen und Architektur. Die eigentliche Arbeit, so das Argument, war ohnehin nie das Tippen, sondern das Verständnis von Architektur, Abhängigkeiten und Geschäftslogik.

Dieses Argument hat eine Schwäche, die man kennen sollte – und auf die Lars Faye in seinem Essay pointiert hinweist: Ein Compiler ist deterministisch. Dieselbe Eingabe ergibt dieselbe Ausgabe, jedes Mal. Ein LLM ist ein probabilistischer Next-Token-Vorhersager. Mehr Mehrdeutigkeit ist nicht dasselbe wie eine höhere Abstraktionsebene. Man kann den perfektesten, eindeutigsten Prompt schreiben – und das Modell halluziniert trotzdem eine Methode, weil es eben kein Compiler ist: Es weiß nicht, ob eine Methode existiert, es schätzt nur, dass sie an dieser Stelle existieren sollte. Genau hier schließt sich der Kreis: Weil der Kern probabilistisch ist, muss die äußere Schale – CI, Compiler, Typen, Tests – umso deterministischer sein. Mit den richtigen Leitplanken außen herum lässt sich der probabilistische Kern bändigen.

Warum es vielleicht nur ein temporäres Problem ist

Bei aller berechtigten Sorge halte ich es für wichtig, das Ganze nicht statisch zu denken. Die heutige Risikolage ist eine Momentaufnahme – und fast alle Faktoren bewegen sich.

Die Modelle werden zuverlässiger, auch wenn die Sprünge kleiner geworden sind. Vor allem aber wird die Werkzeugschicht drumherum rasant besser: Agenten bekommen bessere eingebaute Selbstkorrektur, Tools integrieren Policy-as-Code und automatische Verifikation von Haus aus, Kostenkontrollen und Token-Budgets werden Standard. Vieles, was wir uns heute mühsam als Workaround zusammenbauen – harte CI-Gates, Review-Disziplin, manuelle Kostendeckel – könnte in zwei Jahren einfach Teil des Tools sein.

Es ist gut möglich, dass die Skill-Atrophie-Debatte rückblickend genauso aussehen wird wie die Angst vor dem Compiler: eine reale Sorge in einer Übergangsphase, die sich entspannte, als die Technologie reifte. Die Betonung liegt auf könnte und Übergangsphase. Heute sind wir mitten in dieser Phase – und deshalb lohnt es sich, jetzt bewusst gegenzusteuern, statt darauf zu wetten, dass das Problem sich von selbst erledigt.

Mein Umgang: Kontrolle durch Struktur, nicht durch Handarbeit

Und hier muss ich meinen eigenen Weg klar von einem verbreiteten Rat abgrenzen. Die naheliegende Reaktion auf all diese Risiken lautet: weniger generieren, wieder mehr selbst tippen, die KI zum Sekundärwerkzeug degradieren. Das ist ein legitimer Weg – aber es ist ausdrücklich nicht meiner.

Ich delegiere die Implementierung überwiegend an Agenten. Je nach Aufgabe schreibe ich oft nur zwischen 10 und 20 % selbst von Hand. Im Kontext dieses Posts klingt das zunächst widersprüchlich – ist es aber nicht. Denn meine Antwort auf die Risiken ist nicht weniger KI, sondern mehr Struktur. Genau das ist der rote Faden meiner ganzen Serie: Nicht das Delegieren ist das Problem, sondern das unstrukturierte Delegieren.

Wie ich die Kontrolle behalte, ohne den Code selbst zu schreiben:

• Ich reviewe keine tausend Zeilen Code, sondern Entscheidungen. Meine Human-in-the-Loop-Checkpoints sitzen auf Konzept-Ebene, nicht auf Code-Ebene (Post 12): Ich prüfe den Use Case, das Lösungskonzept und den Realisierungsplan – bevor eine Zeile entsteht. Eine falsche Annahme dort zu korrigieren kostet eine Minute, im fertigen Code Stunden.
• Ich zerlege die Arbeit in winzige, validierte Schritte. Der Developer-Agent bekommt nicht den ganzen Plan, sondern einen Schritt (Post 13). Nach jedem Schritt: Änderung anschauen, Build und Typecheck grün, weiter. Der Review-Happen bleibt klein genug, um ihn wirklich zu verstehen – nicht weil ich weniger generiere, sondern weil ich es portioniere.
• Ich verlasse mich auf deterministische Leitplanken statt auf meinen Blick. Projektregeln in copilot-instructions.md/AGENTS.md (Post 10), Typen, Linter, Build – und ein eigener E2E-Test-Agent, der jeden Use Case in einen ausführbaren Test übersetzt (Post 14). Das Gewissen liegt in der Pipeline, nicht in meiner Tagesform.
• Ich messe, statt zu glauben. Ob das Setup wirklich besser ist als ein direkter Prompt, beantworte ich nicht mit Bauchgefühl, sondern mit Metriken (Post 18).

Der entscheidende Punkt ist die Ebene, auf der ich Mensch bleibe. Nicht beim Tippen – das überlasse ich weitgehend den Agenten. Sondern beim Verstehen und Entscheiden: Was soll gebaut werden, in welcher Architektur, in welcher Reihenfolge – und deckt sich das Ergebnis am Ende mit der ursprünglichen Anforderung? In Post 15 habe ich an einem konkreten Durchlauf gezeigt, dass ich an vier von fünf Checkpoints eingegriffen habe – jeder Eingriff dauerte zwei bis zehn Minuten. Es ging nie darum, technische Fehler zu finden, sondern die Richtung zu halten, solange Korrekturen noch nichts kosten.

Und ja – Vibe Coding, also das Generieren ohne diese Struktur, habe ich für komplexe Projekte bewusst hinter mir gelassen (Post 11). Nicht weil Agenten schlecht wären, sondern weil unstrukturiertes Delegieren genau in die Qualitäts-Fallen läuft, die dieser Post beschreibt: hübsch verpackte Bugs, Sicherheitslücken, Annahme-Propagierung. Dagegen helfen die Checkpoints und Leitplanken zuverlässig.

Die ehrliche Grenze: gegen die Atrophie hilft das nicht

Hier muss ich allerdings sauber unterscheiden, sonst verkaufe ich einen Trugschluss. Alle vier Punkte oben sichern die Qualität des generierten Codes – dass das Richtige gebaut wird, dass es funktioniert, dass es zur Architektur passt. Gegen den Verlust der eigenen Fähigkeiten helfen sie nicht. Im Gegenteil: Wer die Implementierung delegiert und nur auf Konzept-Ebene reviewt, schreibt zwangsläufig weniger selbst – und genau das Selber-Schreiben ist die Tätigkeit, die den Skill erhält. Mein Workflow hält mich an den richtigen Stellen im Prozess – aber er hält meine Coding-Muskeln nicht automatisch trainiert. Um die Atrophie aufzuhalten, muss ich bewusst Aufgaben selbst durchdringen, die ich auch ohne Agenten lösen könnte – den schmerzhaften Weg einschlagen und ab und zu selbst schreiben, debuggen und optimieren. Es gibt immer wieder Momente, in denen ich ein Feature bewusst von Hand implementiere, nur um meine Fähigkeiten zu erhalten. Das ist ein bewusster Trade-off zwischen Geschwindigkeit und Kompetenz.

Diese Atrophie ist für sich genommen nichts Neues. Es ist der normale Lauf einer Karriere: Wer vom Entwickler zum Architekten und weiter ins Management wächst, schreibt mit der Zeit weniger Code und rostet in der Syntax ein. Das war immer so – und nie ein Drama, weil diese Menschen vorher jahrelang Reibung und Erfahrung gesammelt hatten, auf der sie aufbauen konnten.

Neu – und das ist, was mir Sorge macht – sind zwei Dinge. Erstens die Geschwindigkeit: Was früher langsam über Jahre geschah, passiert jetzt in Monaten. Auch erfahrene Entwickler, Architekten und ich selbst verlernen Teile schneller, als der natürliche Karriereverlauf es je verlangt hätte. Zweitens, und schwerwiegender, die Junioren: Ein Senior, der einrostet, hat sein Fundament bereits. Ein Junior, der von Anfang an nur reviewt, statt selbst zu ringen, baut dieses Fundament nie auf. Man kann keine Fähigkeit verlieren, die man nie erworben hat – aber man kann verhindern, dass sie überhaupt entsteht. Und genau hier wird das Paradox der Aufsicht aus Kapitel 1 für Junioren vollends zur Sackgasse: Wirksame Aufsicht über die KI verlangt exakt die Fähigkeiten, die ein Junior nie aufbauen durfte. Wie soll jemand beurteilen, ob der generierte Code korrekt ist, wenn ihm die Erfahrung fehlt, die dieses Urteil überhaupt erst möglich macht? Beim Senior verkümmert eine Fähigkeit, die einmal da war – beim Junior fehlt die Grundlage der Aufsicht von Anfang an.

Eine saubere Lösung dafür habe ich nicht – schon gar keine, die ein Agenten-Workflow liefern könnte. Für die nächste Generation bedeutet das vor allem: Junioren nicht nur Code abnicken zu lassen, sondern sie durch dieselbe Reibung gehen zu lassen, die ich selbst zum Lernen gebraucht habe. Das ist keine technische Leitplanke, sondern eine bewusste Entscheidung gegen die Bequemlichkeit.

Fazit

Seien wir ehrlich: Ich werde mit Agenten schneller – und die Qualität, die dabei herauskommt, ist vertretbar gut. Das ist kein netter Nebeneffekt, sondern der Grund, warum ich diesen Weg überhaupt gehe. Aber ich gehe ihn bewusst und mit offenen Augen für die Risiken, die ich in diesem Post beschrieben habe.

Und ich spüre sie selbst. Es ist tatsächlich unangenehm, wenn ich mich bewusst dazu entscheide, ein Feature einmal komplett von Hand zu schreiben – und genau dieser kleine Schmerz ist für mich ein ehrlicher Indikator dafür, dass die Bequemlichkeit bereits an mir arbeitet. Den kognitiven Schulden versuche ich über die Dokumentation der Use Cases und Lösungskonzepte entgegenzuwirken: Sie halten mein mentales Modell auf der Ebene des Was und Warum wach. Aber ich will es nicht schönreden – das hilft nur bedingt. In die technische Tiefe schaue ich oft nicht hinein, und entsprechend könnte ich bei manchem Feature nicht aus dem Stand sagen, wie es im Detail funktioniert.

Für mich überwiegen die positiven Aspekte trotzdem deutlich – und ich bin optimistisch, dass vieles von dem, was heute Sorge macht, mit der Zeit kleiner wird.

Vielleicht ist das alles in zwei Jahren ein gelöstes Problem, weil die Tools nachgezogen haben. Vielleicht aber auch nicht. Bis dahin trifft es für mich am besten, was Jeremy Howard (Gründer von fast.ai) und Chris Lattner in „Build to Last" beschreiben: eine Gabelung. Wer KI falsch einsetzt, werde „immer schlechter und schlechter"; wer sie richtig einsetzt, übertreffe die normale Geschwindigkeit des eigenen Wachstums. Oder mit Lattners Worten: Wissen an eine KI zu delegieren „und den Code nur zu reviewen, ohne darüber nachzudenken, was man eigentlich erreichen will", sei „sehr, sehr besorgniserregend".

Genau auf dieser Gabelung versuche ich, auf der richtigen Seite zu bleiben: schnell sein, ohne aufzuhören zu verstehen. Die Werkzeuge sollen mich besser machen – nicht überflüssig. Den Unterschied entscheidet nicht das Modell. Den entscheide ich.