Agentic Coding ist eine Falle: Warum wir das Programmieren nicht verlernen dürfen

Dieser Beitrag fasst den Artikel “Agentic Coding is a Trap” von Lars Faye zusammen. Den Originalartikel findest du unter larsfaye.com/articles/agentic-coding-is-a-trap.

Ich teile seine Ansichten zu hundert Prozent. Der Text analysiert nüchtern und präzise die Risiken unserer aktuellen Arbeitsweise. Er ist eine essenzielle Lektüre für jeden professionellen Softwareentwickler. Hier sind die wichtigsten Erkenntnisse aus dem Text. Zudem ergänze ich meine persönliche Einordnung zu diesem Thema.

Die neue Erwartungshaltung in der Branche

Aktuell dominiert ein klares Narrativ die Softwareentwicklung. Die KI schreibt den Code. Der Entwickler agiert nur noch als Orchestrator.

Wir sollen Spezifikationen schreiben und Ergebnisse bewerten. Das nennt sich Spec Driven Development. In der Theorie klingt das extrem effizient.

Wir lagern die detaillierte Implementierung einfach aus. Wir konzentrieren uns nur noch auf das große Ganze. Die Praxis zeigt jedoch ein völlig anderes Bild.

Wir vergrößern massiv die Distanz zum eigenen Code. Wir generieren täglich tausende Zeilen. Wir verstehen diese Zeilen oft nicht mehr vollständig.

Das Paradox der Aufsicht

Lars Faye zitiert eine aufschlussreiche Studie von Anthropic. Die Studie benennt das sogenannte Paradox der Aufsicht. Um KI effektiv zu nutzen, müssen wir sie streng kontrollieren.

Diese Kontrolle erfordert exzellente Programmierkenntnisse. Genau diese Kenntnisse verkümmern zusehends. Das passiert zwingend, wenn wir die KI die meiste Arbeit machen lassen.

Anthropic selbst verzeichnet einen dramatischen Rückgang der Debugging-Fähigkeiten. Bei starker KI-Nutzung sinkt diese Kompetenz um 47 Prozent. Wir machen uns abhängig von einem komplexen System. Gleichzeitig verlieren wir die Fähigkeit, dieses System bei Fehlern zu korrigieren.

Der schleichende Verlust der kognitiven Fähigkeiten

Wahre Erfahrung in der Softwareentwicklung entsteht ausschließlich durch Reibung. Wir lernen aus eigenen Fehlern. Wir lernen durch tagelanges Suchen nach komplexen Bugs.

Junior Developer überspringen heute genau diesen essenziellen Prozess. Sie lesen fast nur noch Code, den sie nicht selbst geschrieben haben. Code-Reviews sind wichtig.

Ein Review ersetzt aber nicht das eigene Schreiben. Ohne die direkte Konfrontation mit Problemen findet kein tieferes Lernen statt. Das Problem betrifft nicht nur Berufsanfänger.

Auch Senior Developer spüren die spürbaren Auswirkungen. Entwickler mit jahrzehntelanger Erfahrung verlieren das mentale Modell ihrer eigenen Anwendungen. Wer den Code nicht mehr tippt, durchdenkt die Architektur weniger tief. Jedes neue Feature wird dadurch massiv schwerer zu integrieren.

Programmieren ist gleich Planen

Viele von uns nutzen Code aktiv zum Denken. Das Tippen von Typisierungen und Schnittstellen ist Teil der Lösungsfindung. Es zwingt uns unweigerlich zur Präzision auf allen Ebenen.

Wir prüfen dabei Sicherheit, Performance und Wartbarkeit quasi automatisch. Natürliche Sprache ist im Gegensatz dazu immer unpräzise. Wenn wir der KI eine Spezifikation in Textform geben, füllt sie Lücken mit eigenen Annahmen.

Das Resultat sind unweigerlich Halluzinationen. Wir verbringen dann deutlich mehr Zeit mit der Fehlerbehebung der KI. Wir korrigieren Dinge, die wir selbst schneller und fehlerfrei programmiert hätten.

Wir tauschen ein deterministisches System gegen ein probabilistisches ein. Wir können keine perfekte Vorhersagbarkeit mehr erwarten.

Die gefährliche Abhängigkeit von Anbietern

Früher brauchte ein Entwickler nur einen Texteditor und einen Compiler. Heute benötigen ganze Teams zwingend kostenpflichtige Abonnements für KI-Modelle. Das ist extrem gefährlich für die Branche.

Wenn Claude oder ChatGPT ausfallen, stehen Entwicklerteams komplett still. Das haben jüngste Serverausfälle bereits mehrfach eindrucksvoll gezeigt. Was eine Kernkompetenz war, ist nun eine gemietete Dienstleistung.

Zudem sind die Kosten absolut unkalkulierbar. Mitarbeiterkosten sind planbar und fix. Tokenkosten variieren ständig und unvorhersehbar.

Die Modelle verändern sich im Hintergrund kontinuierlich. Ein Prompt, der gestern effizient funktionierte, kostet heute vielleicht doppelt so viele Token. Wir begeben uns in einen vollständigen Vendor-Lock-in für eine elementare Branchenfähigkeit.

Die falsche Prioritätensetzung

Vor der KI war das Verständnis der Codebasis die oberste Priorität. Wir achteten auf etablierte Standards und Effizienz. Schnelligkeit war ein logisches Nebenprodukt von hoher Kompetenz.

KI-Tools invertieren diese Liste komplett. Sie fokussieren sich primär auf rohe Geschwindigkeit. Es geht nur noch um die Menge an generiertem Code pro Zeitspanne.

Erzwungene Geschwindigkeit führt immer zu geringerer Genauigkeit. Tieferes Verständnis und Prägnanz bleiben völlig auf der Strecke.

Was wir aktiv tun können

Lars Faye fordert absolut keinen Verzicht auf KI. Wir müssen KI vielmehr als reines Werkzeug begreifen. Sie darf niemals der primäre Entwickler im Team sein.

Wir müssen die Rolle der KI aktiv herabstufen. Sie ist hervorragend für interaktive Dokumentation geeignet. Sie hilft exzellent beim Brainstorming. Sie kann einfachen Boilerplate-Code fehlerfrei generieren.

Die Kernlogik müssen wir jedoch weiterhin selbst schreiben. Das erhält unsere grundlegenden Fähigkeiten. Das zwingt uns zum vollständigen Verständnis der Anwendung.

Konkrete Regeln für den Alltag

Generiere niemals mehr Code, als du in einer einzigen Sitzung prüfen kannst. Teile große Aufgaben in sehr kleine Einheiten auf. Refaktoriere generierten Code immer manuell.

Lass die KI niemals Probleme lösen, die du nicht auch selbst lösen könntest. Nutze sie ausschließlich zur Beschleunigung bereits bekannter Vorgänge.

Schreibe vorab detaillierten Pseudocode. Das verringert den Interpretationsspielraum der KI enorm. Es zwingt dich, die Logik vorher selbst zu durchdenken.

So profitieren wir weiterhin von der echten Geschwindigkeit der Werkzeuge. Gleichzeitig schützen wir unsere mit Abstand wichtigste Ressource. Unsere Fähigkeit zum kritischen Denken und eigenständigen Problemlösen.