Agentic Coding ist eine Falle

• Agentic Coding ist ein Ansatz, bei dem Menschen Anforderungen und Pläne erstellen und mehrere Coding-Agenten die Umsetzung übernehmen. Die Struktur vergrößert jedoch fortlaufend die Distanz zwischen dem erzeugten und committeten Code und dem Menschen.
• Damit dieser Ansatz erfolgreich ist, müssen erfahrene Entwickler ihn auf Architekturebene kritisch prüfen. Übermäßiger AI-Einsatz kann jedoch genau die dafür nötigen Fähigkeiten schwächen und zu kognitiver Schuld (cognitive debt) führen.
• Wie die von Anthropic behandelte Aufsichts-Paradoxie zeigt, braucht es Coding-Kompetenz, um Claude effektiv zu überwachen – und der Einsatz von Coding-Agenten kann genau diese Kompetenz schwächen.
• LLMs werden leicht so eingesetzt, dass sie vor allem die innerhalb einer bestimmten Zeit erzeugte Codemenge steigern, statt tiefes Verständnis und Knappheit zu fördern. Unklare Anforderungen füllen sie mit Annahmen oder Halluzinationen auf, was mehr Reviews, Korrekturen und Token-Verbrauch erzeugt.
• Ausfälle bei Claude und schwankende Token-Kosten legen Vendor Lock-in und Kostenunsicherheit offen. AI kann Verständnis-Schulden eher reduzieren, wenn sie statt als Orchestrator, der die Implementierung ersetzt, eher als Hilfe für Planung, Dokumentation, Recherche und begrenzte Delegation genutzt wird.

---

Strukturelle Trade-offs

• Coding-Agenten sind nützlich und leistungsfähig, aber es gibt bereits Trade-offs, die sich quantitativ und praktisch bewerten lassen.
  • Um die aus der Nichtdeterministik von AI entstehende Unschärfe abzumildern, steigt die Komplexität der umgebenden Systeme.
  • Die Fähigkeiten vieler Entwickler können verkümmern.
  • Ein Ausfall eines einzelnen Vendors kann – wie beim Claude-Code-Ausfall – ganze Teams zum Stillstand bringen.
  • Personalkosten sind fix, aber Token-Kosten können weiter schwanken und steigen.
• Damit dieser Ansatz funktioniert, müssen erfahrene Entwickler auf Architekturebene kritisch denken und Probleme in Tausenden Zeilen generierten Codes erkennen können, bevor sie größer werden.
• AI-Tools können jedoch das dafür nötige kritische Denken und die kognitive Klarheit negativ beeinflussen, wodurch kognitive Schuld (cognitive debt) wachsen kann.

Nicht einfach nur eine neue Abstraktion

• Die Deutung als „Programmierer steigen einfach auf eine höhere Abstraktionsebene auf“ reicht nicht aus.
• Mehr Unschärfe bedeutet nicht automatisch eine höhere Abstraktionsebene.
• Auch beim Aufkommen von FORTRAN, Compilern und Hochsprachen gab es Sorgen über Bugs, Instabilität, Effizienzverluste und mehr „Magie“.
• Frühere Bedenken waren meist normative oder theoretische Sorgen darüber, was mit neuen Technologien verloren gehen könnte. AI-Tools zeigen dagegen schon wenige Jahre nach ihrem Auftreten konkrete Auswirkungen.
• Diese Effekte betreffen nicht nur Junior-Entwickler, sondern auch Entwickler mit mehr als zehn Jahren Erfahrung.
• Junior-Entwickler stehen vor einer steileren Lernkurve, weil sie seltener direkt mit Code arbeiten und stärker in die Rolle gedrängt werden, generierten Code zu reviewen.
• Code Review ist wichtig, macht aber nur die Hälfte des Lernprozesses aus. Wenn die Reibung des eigenen Schreibens und Debuggens verschwindet, wird die Lernfähigkeit stark geschwächt.
• Weil Forschung dazu Zeit braucht, sind anekdotische Belege wichtig, um die Lage in Echtzeit zu erfassen. Es gibt aber auch stützende Quellen wie den MIT Media Lab-Bericht und Berichte zu Microsoft.

Warum dieser Wandel anders ist

• Ein C++-Entwickler klagte nicht über „Brain Fog“, nur weil er zu Java oder Python wechselte, und ein Systemadministrator hatte beim Wechsel zu AWS nicht das Gefühl, sein Verständnis von Netzwerken zu verlieren.
• Auch dass Senior Engineers in Management-Rollen wechseln, weniger coden und mit der Zeit „rusty“ werden, ist nichts Neues.
• In bisherigen Laufbahnen wechselten Engineers nach Jahrzehnten voller Coding, Reibung und Problemlösung in Rollen, in denen sie eher Architekturentscheidungen als Syntax behandelten.
• Jetzt wechseln Entwickler in höherstufige Workflows, in denen sie AI-Agenten managen sollen, ohne diese langjährige Erfahrung zu haben.
• Das Problem ist, dass diese Workflows Fähigkeiten verlangen, die sonst erst durch jahrzehntelange Erfahrung entstehen.
• Auch Senior Engineers sind keine Ausnahme.
  • Simon Willison sagt, dass mit fast 30 Jahren Erfahrung das Schlussfolgern mit jeder zusätzlichen Funktion schwieriger wird, wenn kein „stabiles mentales Modell“ davon vorhanden ist, was eine Anwendung kann und wie sie funktioniert.

Das Paradox des erfahrenen Orchestrators

• Eine aktuelle Studie von Anthropic behandelt als Risiko der häufigen Nutzung von Coding-Agenten die „Aufsichts-Paradoxie“.
• Der Kern: Um Claude effektiv zu nutzen, braucht es Aufsicht, und um Claude zu beaufsichtigen, braucht es genau jene Coding-Fähigkeiten, die durch übermäßigen AI-Einsatz geschwächt werden können.
• Sandor Nyako, der bei LinkedIn 50 Engineers führt, berichtet, dass sich Fähigkeitsabbau in seiner Organisation ausbreitet, und bat sein Team, AI nicht für „Aufgaben zu verwenden, die kritisches Denken oder Problemlösung erfordern“.
• Er meint, man müsse Schwierigkeiten durchstehen und die Muskeln trainieren, Probleme tiefgehend zu durchdenken, um Fähigkeiten aufzubauen. Ohne kritisches Denken sei es schwer, die Korrektheit von AI überhaupt infrage zu stellen.
• Auch der Maßstab für „übermäßige Nutzung“ ist unklar, aber datenbasierte Forschung und anekdotisches Material zeigen, dass Fähigkeiten schon innerhalb weniger Monate schnell nachlassen können.
• Der Einsatz von Coding-Agenten erzeugt also den Widerspruch, genau die Fähigkeiten zu schwächen, die man braucht, um Agenten gut zu steuern.

LLMs beschleunigen die falschen Dinge

• Es war nicht zwingend nötig, Code einfach nur schneller zu schreiben.
• Besonders unnötig ist es, schneller mehr Code zu erzeugen, den man nicht vollständig versteht oder nicht in angemessener Zeit reviewen kann.
• Vor AI lagen die Prioritäten guter Entwickler meist ungefähr hier:
  • den Zusammenhang zwischen Code und Codebasis verstehen
  • prüfen, ob er dokumentierten und effizienten Standards entspricht
  • die Zahl der Codezeilen auf das zur Zielerreichung notwendige Minimum reduzieren, ohne die Lesbarkeit zu verlieren
  • Laufzeit berücksichtigen
• Agentic Coding und LLMs kehren diese Prioritäten faktisch um.
• In ihrer heutigen Form und Nutzung tendieren sie dazu, Geschwindigkeit über die Menge des in einer bestimmten Zeit erzeugten Codes zu maximieren.
• Geschwindigkeit ist ein natürliches Nebenprodukt hoher Kompetenz, aber wenn man sie erzwingt, leidet die Genauigkeit.
• Man kann LLMs auch so einsetzen, dass sie tiefes Verständnis und Knappheit fördern, doch erzwungene Einführung und die organisationsweite Überhitzung rund um Token-Nutzung als Metrik zeigen, dass die reale Nutzung oft anders verläuft.

Coding ist auch Planung

• Manche Entwickler planen und denken besser in Code.
• In Code zu denken und zu arbeiten ist keine sinnlose Wiederholungsarbeit, sondern ein Prozess, der dazu zwingt, auf technischer Ebene über Sicherheit, Performance, User Experience und Wartbarkeit nachzudenken.
• Dax, der OpenCode entwickelt hat, sagt in einem Interview zu Spec Driven Development, dass er bei neuen oder schwierigen Aufgaben erst durch das eigene Tippen von Code herausfindet, was eigentlich getan werden muss.
• Statt zuerst eine riesige Spezifikation zu schreiben, bevorzugt er es, Typen, Interaktionen zwischen Funktionen und Ordnerstrukturen direkt anzufassen, um das Konzept zu erfassen.
• Was Menschen sagen, entspricht nicht immer ihrer eigentlichen Absicht, und LLMs füllen Unschärfen mit Annahmen oder Halluzinationen.
• Das Ergebnis sind mehr Reviews, mehr Korrekturen durch Agenten, mehr Token-Verbrauch und eine größere Entfremdung vom erzeugten Ergebnis.
• Umgekehrt können LLMs selbst bei sehr klaren und strukturierten Prompts halluzinierte Methoden ausgeben.
• LLMs sind keine Compiler, sondern Engines zur Vorhersage des nächsten Tokens. Daher kann man kein deterministisches System durch ein probabilistisches ersetzen und erwarten, dass die Unschärfe null wird.
• Selbst AI-affine Senior-Entwickler beginnen diese Entfremdung als wachsendes Problem zu sehen.

Vendor Lock-in und Kostenunsicherheit

• Während des Claude-Ausfalls erschienen Beiträge, dass einzelne Entwickler und ganze Engineering-Teams zum Stillstand kamen.
• Einige Workflows und Coding-Fähigkeiten haben bereits ein Maß an Abhängigkeit von bestimmten AI-Vendors erreicht.
• Fähigkeiten, die früher nur Tastatur und Texteditor brauchten, erfordern nun ein Abonnement bei einem AI-Modellanbieter.

• Token-Kosten sind schwer vorherzusagen

  • Modellanbieter werden massiv subventioniert, und auch die Modelle selbst stehen auf einer sich ständig verändernden Grundlage.
  • Neue Modelle folgen wiederholt einem Muster aus hohen Benchmarks, Hype und anschließenden Beschwerden, sie seien nach realer Nutzung „genervt“ worden.
  • Dazu kommen Klagen darüber, dass für dieselbe Arbeit 2- bis 3-mal mehr Token verbrannt werden.
  • Personalkosten lassen sich kennen, Token-Kosten aber schwer auf Tages-, Monats- oder Jahresbasis vorhersagen.
  • Wenn ein ganzes Team Agentic Coding als Default nutzt, muss das Kostenkonto extrem flexibel bleiben.
  • Primeagen sagt, bei einem vollständig agentischen Workflow „gehört man faktisch dem Modellanbieter“.
  • Es könnte eine Branchenstruktur entstehen, in der man für Token-Verbrauch bezahlen muss, um Arbeiten auszuführen, die früher mit kritischem Denken und Problemlösefähigkeit erledigt wurden.
  • Das wäre nicht bloß Vendor Lock-in auf Produktebene, sondern fast Vendor Lock-in in Bezug auf die technischen Fähigkeiten einer ganzen Branche.
  • Die finanzielle und intellektuelle Grundlage kann jederzeit ins Wanken geraten, und lokale LLMs sind noch nicht bereit, diese Nutzung in diesem Umfang aufzufangen.
  • Das ist keine Theorie, sondern wird bereits berichtet, und auch Modellanbieter selbst beleuchten das Thema.
  • Eine weitere Studie von Anthropic berichtet, dass Debugging-Fähigkeiten um 47 % zurückgingen.
  • Wenn AI am Arbeitsplatz, insbesondere im Software Engineering, aggressiv eingeführt wird, kann das dazu führen, dass Menschen sich für schnelle Ergebnisse auf AI stützen, statt die Kernkompetenz des Debuggens für Problemfälle aufzubauen.

Ein Ansatz mit kleinerer AI-Rolle

• LLMs können starke Werkzeuge für Lernen und Kompetenzaufbau sein.
• Sie können helfen, Konzepte und Techniken tiefer und breiter zu erforschen und neue Ideen mit weniger Aufwand als früher auszuprobieren.
• Code-Generierungswerkzeuge selbst sind nichts Neues.
  • Emmet, Autocomplete und Snippets waren schon Werkzeuge, mit denen man weniger direkt schreibt und mehr generiert.
  • Auch COBOL versuchte mit englischartigen Wörtern wie MOVE und WRITE, mit weniger Tipparbeit mehr Befehle auszudrücken.
  • Auch das Motto von jQuery lautete: „write less, do more“.
• LLMs lassen sich als weitere Ergänzung solcher Code-Generierungswerkzeuge verstehen.
• Der wichtige Unterschied liegt darin, LLMs und Coding-Agenten als unterstützenden Prozess einzusetzen.
• Es ist möglich, AI fürs Brainstorming in der Planungsphase zu nutzen, ohne dafür individuelle Fähigkeiten zu opfern, und zugleich an der Implementierung weiterhin aktiv beteiligt zu bleiben.
• Wer nur dann delegiert, wenn es nötig ist, kann Produktivitätsgewinne mitnehmen und zugleich Verständnis-Schulden verringern.

Ein alltagsnaher Nutzungsstil

• LLMs für Spezifikationen und Planung verwenden, aber die Implementierung von Menschen führen lassen.
• Das kehrt den „Orchestrierungs“-Workflow um; je nach Aufgabe wird zu 20 % bis 100 % selbst gecodet.
• Auch bei der Nutzung von Modellen wird oft Pseudocode geschrieben, um die Distanz zwischen Anfrage und generiertem Code zu verringern.
• Das Modell dient für temporäre Codegenerierung, interaktive Dokumentation und Recherche.
• Es wird als Werkzeug für verantwortungsvolle Delegation genutzt, um zu fragen, zu iterieren, zu refaktorieren und den Ansatz klarer zu machen.
• Es wird nie mehr Code auf einmal erzeugt, als sich reviewen lässt.
• Wenn es für ein Review zu viel ist, wird verlangsamt, die Arbeit aufgeteilt und bei Bedarf selbst refaktoriert, um das Endergebnis umfassend zu verstehen.
• Implementierungen, die man nie selbst gemacht hat oder allein nicht umsetzen könnte, werden nicht an LLMs oder Agenten delegiert.
• Ausnahmen gibt es für Lern- oder Tutorial-Zwecke; diese Ergebnisse werden danach oft verworfen.
• Kurz gesagt: AI sollte eher wie der Bordcomputer eines Raumschiffs als wie Data aus Star Trek genutzt werden.

Besser arbeiten statt nur schneller

• Die Produktivitätsgewinne von Modellen sind real.
• Gleichzeitig sind auch die Reibung und das Verständnis real und wichtig, die aus häufiger direkter Arbeit an Aufgaben entstehen.
• Versuche, Coding zu demokratisieren, ohne dass Menschen Code verstehen, sind wiederholt gescheitert.
• Um Code zu verstehen, muss man sich direkt mit ihm auseinandersetzen.
• Wer nicht weiter aktiv mit Code arbeitet und ihn schreibt, kann dieses Verständnis und diese Verbindung verlieren.
• Mit dem Verlust des Verständnisses nimmt auch die Fähigkeit ab, Agenten gut zu steuern, und die AI-Coding-Phase wird zu einer seltsamen und unnötig stressigen Übergangszeit.

Es könnte ein noch größeres Experiment sein

• Der aktuelle Trend wirkt wie ein weiteres groß angelegtes Experiment an uns selbst, dessen langfristige Auswirkungen noch nicht ausreichend verstanden sind.
• Auch bei der Einführung sozialer Medien wurden die langfristigen Folgen nicht verstanden; später zeigten sich zahlreiche Probleme wie weit verbreitete Aufmerksamkeitsdefizite.
• Diesmal steht noch mehr auf dem Spiel.
• Jeremy Howard, Gründer von fast.ai, sagt, wer alles auf AI-Agenten setze, garantiere sich selbst die eigene Entbehrlichkeit.
• Wer das gesamte Denken an Computer auslagert, hört auf, Fähigkeiten aufzubauen, zu lernen und kompetenter zu werden.

[GN⁺]

Hacker-News-Kommentare

• In den letzten Jahren, in denen ich mit agentischem Coding gearbeitet habe, habe ich mehr über die Sprachen, Systeme und Werkzeuge gelernt, die ich benutze, als in 35 Jahren direkten Programmierens von Hand.
  Beim Entscheiden über Systeme, Techniken und Ansätze bin ich den Tools zwar immer noch weit überlegen, aber diese Tools sind wie ein sehr belesener Praktikant, der eine Menge Kleinkram im Detail weiß. Wenig Erfahrung, macht mit Begeisterung Fehler, nimmt aber zumindest anfangs Feedback an und setzt es um. Es ist nur nicht wirklich verstanden und verinnerlicht, deshalb wird es oft wieder vergessen.
  Die Behauptung, man müsse alles vollständig kennen, woran man arbeitet, ist sehr naiv. Sobald man in zwei oder mehr Teams arbeitet, gibt es viele Teile, die man nicht vollständig versteht, und in einer alten Codebasis kann einem fast alles fremd sein. In einem riesigen Monorepo, das über Jahrzehnte gewachsen ist, hat man schon Glück, wenn man selbst den Bereich, in dem alle einen für den Experten halten, wirklich versteht.
  Leute, die so etwas behaupten, wirken meist entweder sehr juniorig, arbeiten fast allein oder klingen, als hätten sie 20 Jahre lang an einem einzigen Projekt gesessen. Niemand, der in einem Team oder einer großen Organisation arbeitet, kann behaupten, die gesamte Codebasis zu kennen, und das gilt auch für Menschen, die agentisch programmieren. Trotzdem kann man einem Agenten Fragen stellen und bekommt Antworten, und als jemand, der sein Leben lang den Code anderer gelesen hat, kann ich auch von LLMs geschriebenen Code lesen. Es ist mir völlig egal, ob schlechter Code von einer Maschine oder von einem Menschen stammt, und wenigstens setzt die Maschine mein Feedback in Handlungen um.

  • Meistens stimmt es, dass man nicht alles, nicht einmal den Großteil, kennen muss, aber man muss das, was man über das Projekt oder System, an dem man arbeitet, wissen muss, schnell finden und verstehen können.
    Ich habe viele Software-Teams gesehen, die schon bei kleinen Problemen komplett blockiert waren, sobald zusätzliches Fachwissen in Bereichen wie Low-Level-Sprachen, Assembler, weniger verbreiteten Algorithmen oder Netzwerkprotokollen nötig wurde.
    Umgekehrt wird man manchmal nicht deshalb blockiert, weil einem die Fähigkeit fehlt, das Gesehene zu interpretieren, sondern weil man etwas Blackboxartiges benutzt, etwa proprietäre Bibliotheken oder ein proprietäres Betriebssystem, in das man nicht hineinschauen kann und dessen tatsächliches Verhalten sich nicht verifizieren lässt.
    Deshalb finde ich, dass es immer möglich sein sollte, alles über alles herausfinden zu können, woran man arbeitet, auch wenn das nur sehr selten gebraucht wird.
  • Mit 35 Jahren Erfahrung hat man die Lernfähigkeit und den allgemeinen Rahmen für neues Wissen bereits aufgebaut und weiß außerdem, wie man agentisches Coding als Hilfsmittel einsetzt. Juniors, die heute anfangen, haben das nicht, verlassen sich daher zu stark auf agentisches Coding und wissen nicht einmal, was sie nicht wissen.
  • Dieser Beitrag sagt nicht: „Du musst alles vollständig kennen, woran du arbeitest“, sondern: Die Fähigkeit, Code zu schreiben, und die Fähigkeit, Code effektiv zu lesen, sind im Kern miteinander verknüpft.
  • Stimme zu. Ich arbeite gut, ohne zu wissen, wie aus Sand Transistoren werden oder ohne Assembler zu können, also kenne ich auch nicht den ganzen Stack.
    Wichtig ist, keine Angst davor zu haben, den Rest des Systems zu lernen, und einen Index im Kopf zu behalten.
    Vor allem muss man in der Lage sein, Dinge schnell zu erfassen. So kann man breit arbeiten. Wenn nötig, gräbt man sich tief ein, und wenn nötig, überfliegt man etwas auf hoher Ebene; man muss also die richtige Flughöhe für das jeweilige Problem finden.
    An der Uni hat man Informatikstudierenden früher Ingenieurwesen im Allgemeinen beigebracht. Auf die Frage „Wann werde ich jemals Chemieingenieurwesen oder analoge Regelsysteme brauchen?“ lautete die Antwort: „Wahrscheinlich nie. Aber du sollst es schnell genug durchdringen können, um damit zu programmieren, und es danach wieder vergessen dürfen. Wir geben dir ein solides Fundament.“
    Das gilt innerhalb großer Codebasen genauso.
  • Das Problem hier ist, dass in gewissem Sinne der Agent, der den Code geschrieben hat, und der Agent, der Fragen zu diesem Code beantwortet, nicht derselbe Agent sind. Wenn der ursprüngliche Agent seinen Gedankengang nicht hinterlassen hat, steht man meist im Dunkeln.
    Tools wie git-ai [0] zeichnen LLM-Sitzungen auf, verknüpfen Dateibearbeitungen mit konkreten Agentenaktionen und erlauben es dem Agenten, bei einem bestimmten Codeschnipsel den umgebenden Dialog nachzuschlagen, also etwa, was der Nutzer gefragt hat oder was die Überlegungen des LLMs hinter diesem Code waren. Das könnte das Gleichgewicht verändern, ist aber noch nicht weit verbreitet.
    [0] https://usegitai.com/

• Als Senior-Entwickler mit mehr als 25 Jahren Erfahrung wurde ich kürzlich mit so einem „Kannst du mal 5 Minuten dazukommen?“ in ein Meeting geworfen, und ich hasse Meetings dieser Art, in die man ohne Kontext mitten hinein gezogen wird.
  Es hagelte sofort Fragen ohne jede Einordnung, und es ging um eine externe Integration, eine von Dutzenden. Noch schlimmer: Dort benutzt man eine eigene Terminologie, die sich von unserer unterscheidet.
  Weil ich mich beim Bauen dieser Integrationen stark auf Modelle gestützt hatte, hatte ich große Mühe, die Fragen überhaupt zu verstehen. Es war eine extrem langweilige Arbeit, und es gab dicke externe Spezifikationen dazu.
  Ich sehe es trotzdem positiv, weil diese Integrationen ohne das Modell vermutlich selbst mit dem Zehnfachen an Zeit nie fertig geworden wären. Aber jetzt überlege ich ernsthaft, ob ich die „Aha“-Punkte noch einmal dokumentieren sollte, damit mir so ein unangenehmer Moment nicht wieder passiert.
  Noch nie habe ich mich in einem Meeting so ahnungslos und peinlich berührt gefühlt, und alles, was ich sagen konnte, war: „Das prüfe ich und melde mich“, „das auch“, „das auch“.
  Kognitive Schulden sind sehr real, und für mich persönlich tun sie mehr weh als technische Schulden. Technische Schulden trägt das ganze Team, kognitive Schulden sind persönlich, und wenn ich sie selbst verursacht habe, sollte ich es eigentlich besser wissen.
  Künftig werde ich eine Arbeit wohl erst dann als abgeschlossen betrachten, wenn ich dazu eine Art fünfminütige Flashcard-Liste in Markdown erstellt habe: „Was ist das?“, „Was ist jenes?“

  • Das ist ähnlich wie die Situation, über die sich Ärzte oft beklagen. Ein Patient kommt und sagt, er brauche nur ein Rezept für ein bestimmtes Medikament, aber gute Ärzte geben oft weder Medikamente noch Ratschläge, bevor sie die Gesamtsituation richtig verstanden haben.
    Als Senior-Entwickler bist du die Person, die bei Verhalten, das dir nicht gefällt, auf die Bremse treten sollte. Du hast die Autorität dazu. So etwas wie: „Spannende Frage. Um dazu meine Sicht zu geben, brauche ich mehr Kontext. Könnten Sie kurz die Systemarchitektur erklären oder schildern, welches Problem Sie mit diesem Ansatz konkret lösen wollen?“
  • Ich frage mich, was das für ein Arbeitsplatz sein muss, an dem man mitten in ein Meeting gezerrt wird, ohne Kontext mit technischen Fragen beschossen wird und dann auch noch sofort Antworten erwartet werden. Viele Leute würden so etwas gern vermeiden, also wäre es gut, das zu wissen.
    In so einer Situation ist „Um diese Frage sauber zu beantworten, muss ich die Dokumentation und den Code prüfen“ eine völlig legitime und ziemlich diplomatische Antwort.
  • Einfach das Ego runterschrauben und sich nicht darum scheren. Du hast ein Tool benutzt, und ohne dieses Tool wärst du noch viel schlechter dagestanden. Sag einfach: „Weiß ich nicht, ich frage die AI.“
  • Das erinnert mich an den siebenminütigen Sketch „The Expert“ von 2014: https://www.youtube.com/watch?v=BKorP55Aqvg
    Meetings, in denen Expertise nicht als etwas gesehen wird, das aufgebaut werden muss, sondern nur dazu dient, kreative Bestätigungsfehler abzusichern, machen keinen Spaß.
  • Ganz einfach. Lass den Agenten am Ende diese Liste schreiben. Und dann lies sie einfach nie.

• Um Probleme in generiertem Code zu finden, muss sich der Entwickler kümmern. Viele Entwickler, vor allem in Großunternehmen, sind innerlich ohnehin schon ziemlich ausgestiegen und suchen nur noch nach dem Weg mit dem geringsten Aufwand, um Tickets zu schließen und Verantwortung weiterzureichen.
  Solche Entwickler werden sich, selbst wenn sie dazu in der Lage wären, nicht die Mühe machen, generierten Code so weit zu verstehen, dass sie die Dinge finden, die der Agent übersehen hat. Besonders im aktuellen AI-getriebenen Geschwindigkeitsrausch gilt das erst recht.

  • Genau. Generierter Code ist schwerer zu lesen, weil er alle semantischen Erwartungen verletzt, die auf dem mentalen Modell eines menschlichen Autors beruhen.
    Er sieht sprachlich plausibel aus, ahmt aber gängige Idiome oft unbewusst auf inkohärente Weise nach, sodass sich echte Bugs zufällig auf Arten verstecken können, die einem normalen Menschen, selbst einem schlechten Programmierer, kaum einfallen würden.
    LLMs haben keine innere Bewertung, deshalb muss der Reviewer das mitdenken, alles Zeile für Zeile beurteilen und die verborgene Begründung sowie das implizite Wissen, das das LLM nie hatte, von Grund auf neu aufbauen. Dabei wird man manchmal auf Nicht-Probleme gezogen und verschwendet teure Zeit.
    An diesem Punkt ist der Aufwand oft größer, als den Code von vornherein selbst zu schreiben.
  • In großen Unternehmen gibt es Ausnahmen, aber in vielen Teams werden viele Entwickler dafür bestraft, dass sie sich überhaupt kümmern.
  • Manche sagen, der große Bruder verkauft erst Junkfood und verkauft dann die „Lösung“, um wieder abzunehmen.
    Vielleicht kaufen Unternehmen gerade Junk-AI und lassen sich im nächsten Schritt die „Lösung“ dafür versprechen. Der Kapitalismus funktioniert genau wie erwartet.

• Dieser Beitrag geht am Kern der Sache ein wenig vorbei.
  Wenn man viel AI benutzt, entsteht Skill-Verlust.
  Aber ich möchte den peinlich offensichtlichen Elefanten im Raum ansprechen. AI macht Menschen viel zu schnell. Das heißt nicht, dass schnelle Ergebnisse an sich schlecht wären, sondern dass Output und Code schneller kommen als das Gesamtverständnis und die Erfahrung, die zu ihnen gehören müssten. Belohnt werden nicht die Leute, die mit tiefem Wissen sichere Entscheidungen treffen, sondern die, die Business Value präsentieren können.
  AI kann gut sein und gute Lösungen erzeugen, aber am Ende weiß sie nicht, was sie tut, und selbst im besten Fall braucht sie einen starken Kurator.
  Wir stecken in der Jauchegrube businessgetriebener Entwicklung, und auf schlechte Entscheidungen folgen nicht annähernd harte genug Reputationsstrafen.

  • Skill-Verlust ist real. Aber ich beklage mich bei meinen Vorgesetzten buchstäblich seit zehn Jahren über Skill-Verlust. Insofern ist AI für mich nur eines unter mehreren Problemen. Aus irgendeinem Grund habe ich jedes Jahr weniger selbst programmiert.
    Anders gesagt: Ich bin mir nicht sicher, ob Skill-Verlust wirklich so ein großes Problem ist. Vielleicht ist es einfach ein Zeichen dafür, dass sich die Natur unserer Arbeit verändert. Vielleicht leben wir bald in einer Zeit, in der die Fähigkeit, gute Architektur zu kennen, höher bewertet wird als die Fähigkeit, den C++-Standard auswendig zu können und Hunderte Features korrekt einzusetzen.
  • Im Großen und Ganzen stimme ich zu, aber die brutale Wahrheit ist, dass die Prioritäten der meisten Unternehmen schon immer ungefähr auf grobe, schlampige businessgetriebene Entwicklung hinausliefen. Menschzentrierte Engineering-Prozesse waren nur zufällige Bremsmechanismen gegen die schlimmsten Folgen dieser Philosophie, keine bewusst eingebauten Sicherungen.
  • Ein weiterer Aspekt von „zu schnell“ ist, dass sich die Reihenfolge unserer Probleme verschiebt.
    In normaler Entwicklung wägt man häufiger hin und her: „Wollen wir das wirklich bauen?“ und „Was könnte dabei schiefgehen?“ — idealerweise vor PR-Freigabe, Merge und Deployment. Ein Teil davon verschiebt sich gerade zu „Mal sehen, wer sich später beschwert“. Wie man so schön sagt: Eine Unze Vorbeugung ist besser als ein Pfund Heilung.
  • In einer businessgetriebenen Welt, in der businessgetriebene Regierungen businessgetriebene Regeln schreiben, weiß ich nicht, was die Alternative wäre, wenn man auf Erfolg optimieren will.
  • Nicht nur Unternehmen machen das so. Auch in Open-Source-Projekten sehe ich oft, dass große PRs gemergt werden, die oberflächlich okay aussehen, aber tausend kleine Bugs enthalten. Nicht katastrophal, aber nervig genug.
    Außerdem war der Code nicht idiomatisches C++ für das jeweilige Projekt, und das LLM hat die vorhandene API komplett ignoriert. Das lässt sich beheben und der Maintainer hätte es auffangen müssen, aber allein die Menge des generierten Codes kostet allen zu viel Energie.

• Solche Blogposts sind zweifellos mit AI-Hilfe geschrieben worden, und dieses Thema taucht hier und im ganzen Internet seit Jahren in den Kommentaren auf. Kompetenzabbau ist eine ernste Sorge, und jeder, der seit 2022 skeptisch gegenüber AI ist, sagt das immer wieder, aber manche Leute und manche Orte scheint das einfach nicht zu interessieren.
  Wenn du irgendwann nur noch den Hebel einer Müllmaschine ziehst, ohne irgendeine Einsicht in den Code zu haben, dann ist es fair, wenn dein Chef fragt, warum du mehr als 50.000 Dollar Gehalt bekommen solltest.

• AI zu benutzen, um schneller zu werden, ist eine Optimierung des Falschen. An jedem Ort, an dem ich gearbeitet habe, hat das eigentliche „Code schreiben“ im Vergleich zu all dem anderen, was nötig ist, um ein Feature umzusetzen, am wenigsten Zeit beansprucht.
  Nehmen wir ein Feature, das man an einem Tag programmieren könnte. Zuerst muss alles über das Planungsritual des Unternehmens laufen, ob das nun Agile oder Waterfall heißt: alles planen, Arbeit aufteilen, JIRA-Tickets anlegen, zuständige Personen festlegen. Allein das kann Tage oder Wochen dauern. Danach muss man ein Design-Dokument mit dem vorgeschlagenen Entwurf schreiben und von Kollegen und Teammitgliedern reviewen lassen; bei einem echten Feature kostet das schnell noch einmal eine Woche. Wenn mehrere Teams beteiligt sind, braucht man deren Zustimmung und eine abgestimmte Design-Einigung, also noch eine Woche dazu. An manchen Orten braucht man vor Arbeitsbeginn noch eine Freigabe, und je nach Kalender und Verfügbarkeit der Genehmiger kommen noch ein paar Tage oben drauf.
  Dann schreibt man einen Tag lang den Code und bringt die Tests zum Laufen.
  Danach folgt das Code Review, oft mit viel Hin und Her im Team, mehreren Schleifen und zusätzlichen Reviews. Wieder ein paar Tage oder Wochen. In größeren Unternehmen müssen außerdem Reviews aus allen möglichen anderen Bereichen durchlaufen werden: Recht, Datenschutz, Performance, Accessibility, QA. Selbst wenn das parallel läuft, rechnen wir konservativ noch zwei Wochen dazu. Danach geht es auf Staging und muss dort unter internen Dogfoodern eine Weile reifen, bevor man Vertrauen in das Verhalten hat. Noch eine Woche. Jetzt ist es bereit für den Weg von Staging nach Production, aber kein ernstzunehmendes Unternehmen schickt etwas sofort auf 100 % Production. Man fährt langsam hoch und beobachtet Feedback und Metriken für den Fall, dass ein Rollback nötig wird. Bis zum vollständigen Rollout können noch einmal zwei Wochen vergehen.
  Dann haben wir bei einem Feature, das von Design bis Release rund zwei Monate braucht, einen einzigen Tag, den wir mit aller Gewalt von einem Tag auf fünf Minuten drücken wollen.

  • Das erinnert mich an diese Maxime des Software-Engineerings.
    Wenn man Software baut, sollte man daran denken, dass sie ein Schnappschuss des Verständnisses eines Problems ist. Sie sagt allen, auch deinem zukünftigen Ich, etwas über den Ansatz, die Klarheit und die Angemessenheit der Lösung für das vorliegende Problem. Also sollte man klug wählen, was man damit aussagen will.
    Die Formulierung, dass man bei einem Feature mit zwei Monaten Durchlaufzeit verzweifelt versucht, den einen Tag auf fünf Minuten zu kürzen, trifft es sehr gut.
  • Modelle sind inzwischen extrem gut darin, langweilige Arbeiten wie Dependency-Updates, Build- und Deployment-Skripte oder Unit-Tests fast vollständig zu automatisieren. Was früher Tage gedauert hat, kann jetzt Minuten dauern, und hier sind 50x Geschwindigkeitssteigerung leicht möglich.
    In stabilen Unternehmen machte so etwas einen nicht kleinen Teil des Alltags praktisch aller Engineers aus. Nenn es „Platform Engineering“ oder wie auch immer — dieser Bereich ist tot.
    Und technisch riskante Ideen, die man früher wegen des Missverhältnisses zwischen Risiko, Aufwand und Ertrag gar nicht erst versucht hätte, sind jetzt plötzlich erreichbar. Es geht also nicht nur darum, „schneller zu werden“, sondern darum, dass die Geschwindigkeit, mit der man etwas ausprobieren kann, den Charakter des Engineering-Prozesses selbst verändert.
  • Alle von dir beschriebenen Prozesse existieren, um die Zeit, in der Software-Ingenieure Code schreiben, zu maximieren [0]. In Unternehmen gehören Software-Ingenieure zu den teuersten Mitarbeitern, und verschwendete Zeit schlägt sich spürbar in der GuV nieder, deshalb gibt es diese Prozesse.
    Wenn Software-Ingenieure billig genug werden, entfällt ein großer Teil der Notwendigkeit für diese Prozesse. Unternehmen, die solche Prozesse bereits aufgebaut haben, werden Probleme bekommen, weil diese Bürokratie extrem schwer wieder abzubauen ist. Firmen, die solche Prozesse nie hatten oder sie entfernen können, werden dagegen einen erheblichen Wettbewerbsvorteil haben.
    Das ist nichts Neues. Startups haben schon immer mit ihrer Umsetzungsgeschwindigkeit gegen etablierte Unternehmen konkurriert. Neu ist nur die Fähigkeit, diese Geschwindigkeit länger aufrechtzuerhalten.
    Auch Reviews aus Bereichen wie Recht, Datenschutz, Performance, Accessibility und QA sind im Fadenkreuz. Wenn ein Unternehmen die rechtliche Haftung für solche Reviews an einen externen Anbieter auslagern kann, wird es das tun.
    [0] Ignorieren wir einmal die Ironie, dass ein beträchtlicher Teil dieses Prozesses letztlich genau den Mitarbeitern aufgeladen wird, deren Zeit er eigentlich sparen sollte.
  • Es hängt sehr stark davon ab, in welcher Art von Firma man arbeitet. Ein Startup kann man zum Beispiel nicht so führen.
  • Nicht alle Unternehmen arbeiten so.
    In Big Tech gibt es viel von diesem aufgeblasenen Prozessgehabe, aber kleinere Firmen können schnell und ungeschliffen agieren.

• Die Codequalität hängt am Ende von dir ab.
  Nichts hindert dich daran, iterativ mit dem Agenten zu arbeiten und so lange nachzuschärfen, bis der Code genau die gleiche Qualität hat wie etwas, das du selbst geschrieben hättest.

  • Wenn ich Code in meiner Qualitätsvorstellung will, war es für mich immer schneller und weniger frustrierend, ihn einfach selbst zu schreiben.
  • Ich will nicht meine Codequalität, ich will AGI-Codequalität. Das wurde mir versprochen, zusammen mit Jetpacks und fliegenden Autos.
  • Deshalb verstehe ich solche Texte nicht; sie wirken auf mich wie Fallstudien über menschliche Faulheit. Wenn man gute Ergebnisse will, muss man die Ergebnisse eben reviewen und iterieren. Wenn man ein gutes Fundament will, muss man dieses Fundament selbst schreiben, und später verhindert dieses Fundament ziemlich wirksam, dass ein LLM schlechten Code produziert.
    Solche Texte sind ziemlich frustrierend. Der vom Autor erwähnte Token-Kostenfaktor ist allerdings real und riskant.
  • Nichts hindert dich daran, aber es ist trotzdem langsamer, als es direkt selbst zu schreiben. Produktivitätsgewinne durch AI sind ein Mythos.
  • Nach meiner Erfahrung dauert es genauso lang oder länger, die AI bis dahin zu coaxen. Vor allem, wenn es keinen Beleg dafür gibt, dass es schneller ist, schreibt man besser direkt selbst und weiß dann auch, wie es funktioniert, statt ein LLM als Mittelsmann dazwischenzuschalten.

• Ich nutze AI-Tools, um über Ansätze zu brainstormen und gelegentlich Code generieren zu lassen, aber das eigentliche Tippen mache ich selbst. So ist die Wahrscheinlichkeit geringer, dass ich mit der Zeit Mechanik und Programmiersprache vergesse.

  • Ich mache es ähnlich: meistens bitte ich um einen Implementierungsplan, aber halte den Code minimal oder bitte ganz ohne Code beziehungsweise nur um Pseudocode und schreibe den eigentlichen Code selbst. Bei Open-Source-Arbeit ist genau das ja der Teil, an dem ich Freude habe.
    Ehrlich gesagt glaube ich nicht, dass ich Maintainer eines Open-Source-Projekts sein wollte, wenn es nur noch daraus bestünde, das LLM Code schreiben zu lassen und ihn zu reviewen. Das wirkt überhaupt nicht erfüllend.
    Bei einem bezahlten Job frage ich mich, ob sich meine Art, LLMs zu verwenden, ändern würde. Ich bin Softwareentwickler geworden, weil ich diese Technik selbst liebe. Ich mag den Akt des Bauens, den Einsatz meines Gehirns, um Ideen in Code zu verwandeln. Wenn es nur noch darum ginge, ein LLM zu prompten, weiß ich nicht, ob ich in dem Beruf bleiben würde. Wahrscheinlich würde ich zumindest anfangen, über einen Wechsel nachzudenken.
  • Ein möglicher Ansatz ist, das Modell explizit nie den Code selbst schreiben zu lassen. Dann zwingt man es zu Erklärungen, und wenn man die Ideen anschließend selbst programmiert, versteht man sie besser.
    Bei Code, den ich warten muss, mache ich das so. Trotzdem tappte ich schon öfter in die Falle, weil das Modell viele falsche Informationen einmischt. Oft sind das Dinge, die früher einmal richtig waren, heute aber falsch sind.
    Wegwerfskripte oder Skripte, die sich leicht überprüfen lassen, lasse ich generieren, bitte aber darum, Overengineering oder den Versuch zu vermeiden, jeden Randfall abzudecken. Bei Skripten ist es oft leichter zu verstehen, wenn ein fehlgeschlagener Schritt einfach sichtbar fehlschlägt.
    Ich meide Sprachen wie PowerShell, die ich als schwer lesbar empfinde, und bevorzuge generierte Dinge, die so kurz sind, dass sie auf einen Bildschirm passen und vollständig gelesen und verstanden werden können. Python, Bash und Batch sind meine typischen Skriptsprachen.
  • Ich habe mir sogar im System Prompt eingestellt, dass niemals eine vollständige Lösung oder kompletter Code geliefert werden soll. Wenn ich also etwas frage, bekomme ich eher ein kurzes 10-Zeilen-Beispiel oder Pseudocode. Das ist viel leichter nachzuvollziehen.
    Mehr als 50 % der AI-Vorschläge lehne ich immer noch ab. Sie sind zu banal, verschieben ohne Grund nur Code oder sind manchmal einfach falsch.
  • Wenn AI dir alles, was du vergessen hast, jederzeit wieder sagen kann, warum wäre Vergessen dann überhaupt wichtig?

• Das Lustige an dieser Technologie ist, dass sie entweder das eine oder das andere ist.
  Entweder eine Technologie für Manager, mit der man ohne Fachwissen delegieren kann, ohne zu merken, ob es falsch oder völlig unmöglich ist, oder eine Technologie für Coder, die zwar Fachwissen haben, dieses aber nach und nach verlieren.
  Deshalb weiß ich nicht so recht, für wen das eigentlich sein soll, außer für die VCs und Aktionäre bis zum nächsten Quartal.

• Etwas off topic, aber ich finde es lustig, dass der Artikel sagt, Spec Driven Development sei die Zukunft.
  Technisch gesehen haben wir das schon gemacht, damals in der Waterfall-Zeit. Gute Dokumentation vermisse ich manchmal ein bisschen. In den letzten zehn Jahren, vielleicht sogar länger, habe ich oft nur Ein-Zeilen-JIRA-Tickets bekommen, in denen fast nichts spezifiziert war, sodass man dauernd Leute anrufen musste.
  Ich vermeide es immer noch, mit AI zu arbeiten. Ich will zwar zum Experimentieren ein paar lokale Modelle ausprobieren, aber ich weigere mich, für etwas zu bezahlen, das aus der Arbeit anderer zusammengeklaubt wurde. Und bisher waren lokale Modelle enttäuschend.

  • Remote-Modelle werden immer teurer werden. Die Zukunft ihres Geschäftsmodells hängt davon ab, dass sich die Inferenzkosten verbessern. Man sollte sich nicht freiwillig an so ein Gefängnis ketten.