Agentic Coding ist eine Falle: Warum wir das Programmieren nicht verlernen dürfen
Inhaltsverzeichnis
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. Dieses Phänomen wird oft auch als „Vibe-Coding“ bezeichnet und führt ohne menschliche Architekturkontrolle schnell zu unlesbaren Codebergen, wie die Vibe-Coding-Falle eindrucksvoll zeigt.
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. Dieser Wissensverlust korreliert stark mit dem Problem des veränderten Lernverhaltens unter KI-Einfluss, bei dem wir tagesaktuelle Geschwindigkeit gegen zukünftige Kompetenz eintauschen.
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. Und Abhängigkeit von externen Systemen birgt nicht nur finanzielle Risiken. Wie der GitHub-Breach über eine vergiftete VS Code Extension zeigt, kann blindes Vertrauen in automatische Updates unsere gesamte Infrastruktur kompromittieren.
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.
Senior Full-Stack Developer mit Fokus auf stabiler Software-Architektur, pragmatischem Engineering und der Realität von KI im Entwickler-Alltag. Seine Wurzeln liegen im praktischen Lösen komplexer Probleme unter realen Bedingungen.
github.com/hyretic-devÄhnliche Artikel
Faktor 93: Was passiert, wenn ein Architekt eine Enterprise-Anwendung komplett mit KI entwickelt
KIEin Softwarearchitekt hat vier Monate lang eine komplette Microservice-Anwendung mit KI entwickelt. 420.000 Zeilen Code, 0 Prozent strukturelle Schulden, 85 Prozent Testabdeckung. Die Ergebnisse sind ernüchternd und lehrreich zugleich.
Gartner-Prognose: 2028 wird KI-Coding teurer als Entwicklergehälter
KIDie Tokenkosten für KI-gestütztes Coding werden laut Gartner bis 2028 den globalen Durchschnittslohn eines Entwicklers übersteigen. Die Produktivitätsrevolution wird zur Kostenfalle, wenn Unternehmen ihre Token-Budgets nicht aktiv steuern.
Warum KI Softwareentwickler nicht ersetzt hat und nicht ersetzen wird
KIMassenentlassungen wegen KI sind überwiegend AI-Washing. Die Forschung zeigt: KI komprimiert nur die Ausführungsebene der Softwareentwicklung. Entscheidungen und Verantwortung bleiben menschlich.