Die Rolle der Entwicklerkompetenz beim agentischen Coding

• Je leistungsfähiger agentische Coding-Assistenten werden, desto vielfältiger fallen die Reaktionen aus, und manche behaupten sogar: "In einem Jahr werden Entwickler nicht mehr gebraucht"
• Andere äußern Bedenken hinsichtlich der Qualität von AI-generiertem Code und der Frage, wie man Junior-Entwickler auf dieses veränderte Umfeld vorbereitet
• In den vergangenen Monaten wurden agentische Coding-Helfer wie Cursor, Windsurf und Cline verwendet, und sie erwiesen sich als sehr effektiv bei Änderungen an bestehenden Codebasen
• Besonders beeindruckend war die IDE-Integration: Testausführung und automatische Fehlerbehebung, Erkennung und Behebung von Lint-/Compile-Fehlern, Websuche und sogar Browser-Preview-Funktionen sind integriert
• Die Zusammenarbeit zwischen Entwickler und AI war äußerst eindrucksvoll und trug zu schneller Problemlösung und Feature-Umsetzung bei

• Dennoch waren weiterhin kontinuierliche Eingriffe, Korrekturen und Richtungsentscheidungen durch Entwickler nötig
• In vielen Fällen führte das Ergebnis nicht einmal bis zu einem echten Commit, und für nicht triviale Aufgaben reichte die Fähigkeit der AI zum autonomen Schreiben von Code nicht aus
• Deshalb bleiben Können und Erfahrung von Entwicklern weiterhin wichtig und müssen auch künftig fortlaufend trainiert werden

Momente, in denen Entwickler direkt eingreifen mussten

• AI-Tools zeigten in bestimmten Bereichen durchgehend schwache Leistung, und das bestätigte sich immer wieder
• Einiges lässt sich mit zusätzlichen Prompts oder Custom Rules teilweise abmildern, aber eine vollständige Kontrolle ist unmöglich
  • LLMs befolgen Anweisungen aus Prompts oft nicht exakt
  • Je länger eine Coding-Session dauert, desto stärker nimmt die Konsistenz der Ergebnisse ab
• Die unten vorgestellten Fälle sind daher Probleme, die unabhängig von Prompt oder Konfiguration jederzeit ausreichend häufig auftreten können
• Die Fehler der AI werden anhand ihres Wirkungsradius in drei Kategorien eingeteilt
  • a. Verlangsamung der Entwicklungsgeschwindigkeit und der Zeit bis zum Commit
    • Die AI bremst sogar aus
    • In manchen Fällen ineffizienter als Coding ohne Assistenz
  • b. Reibung im Team-Workflow
    • Konflikte oder Kollaborationsprobleme innerhalb einer Iteration
  • c. Verschlechterung der langfristigen Wartbarkeit des Codes
    • Anfangs scheint alles unproblematisch, doch bei späteren Änderungen oder Erweiterungen treten Probleme auf
• Je größer der Wirkungsradius, desto länger wird die Feedback-Schleife, bis das Team das Problem erkennt und behebt

Wirkungsradius: Verzögerung bis zum Commit

• Diese Kategorie umfasst Fälle, in denen die AI eher hinderlich als hilfreich war
• Weil dies die offensichtlichste Form des Scheiterns ist, stellt sie meist kein großes Problem dar
  • In den meisten Fällen können Entwickler das Problem noch vor dem Commit erkennen und abfangen

• Nicht funktionierender Code

  • Der von der AI erzeugte Code funktioniert grundsätzlich nicht
  • Entwickler müssen selbst korrigieren oder die AI-Session beenden und das Problem manuell lösen
  • Erfahrene Entwickler können schnell beurteilen, was schiefgelaufen ist, und entsprechend handeln

• Falsche Diagnose des Problems

  • Die AI beurteilt die Ursache eines Problems falsch und versucht eine Lösung in eine völlig falsche Richtung
  • Auf Basis früherer Erfahrungen konnten Entwickler die AI wieder auf den richtigen Pfad bringen

    Beispiel: Ein Docker-Build-Fehler wurde als Problem mit den Architektur-Einstellungen missverstanden und die Konfiguration wurde angepasst
    Tatsächlich lag die Ursache im Kopieren von node_modules, das für die falsche Architektur gebaut worden war
    Da dieses Problem schon oft aufgetreten war, konnte es schnell erkannt und korrigiert werden

Wirkungsradius: Team-Workflow innerhalb einer Iteration

• Diese Kategorie betrifft Fälle, in denen es wegen fehlender Reviews oder unzureichender Eingriffe durch Entwickler während einer Iteration zu Reibung im Team kommt
• Dank vielfältiger früherer Teamerfahrungen konnte der Autor solche Probleme oft schon vor dem Commit erkennen und aussteuern
• Auch Junior-Entwickler können solche Lehren durch Versuch und Irrtum gemeinsam mit AI mitnehmen
• Wenn AI jedoch die Coding-Geschwindigkeit erhöht, kann es sein, dass Teams diese Probleme nicht mehr bewältigen können

• Zu viel Arbeit zu früh

  • AI neigt dazu, nicht schrittweise zu implementieren, sondern gleich ein komplettes Feature auf breiter Front anzugehen
  • Wenn dabei technologische Entscheidungen ungeeignet sind oder Anforderungen falsch verstanden wurden, kann viel Arbeit verschwendet werden

    Beispiel: Bei einer Migration des Frontend-Stacks wurde versucht, alle UI-Komponenten auf einmal umzuwandeln
    Stattdessen hätte man mit einer einzelnen, ans Backend angebundenen Komponente schrittweise beginnen sollen

• Reparieren ohne Ursachenanalyse

  • Die AI analysiert die eigentliche Ursache eines Problems nicht, sondern versucht nur, den äußerlich sichtbaren Fehler zu beheben
  • Andere Teammitglieder, die das Problem später übernehmen, müssen es dann ohne Kontext erneut analysieren

    Beispiel: Bei einem Speicherfehler während eines Docker-Builds wurde nicht die Ursache gesucht, sondern nur das Speicherlimit erhöht

• Verkomplizierung des Entwickler-Workflows

  • Von der AI erzeugte Build-/Run-Wege verschlechtern die Developer Experience
  • Werden solche Änderungen sofort committed, wirken sie sich auch negativ auf die Workflows anderer Teammitglieder aus

    Beispiel: Separate Kommandos zum Starten von Frontend und Backend
    Beispiel: Fehlende Hot-Reload-Funktion
    Beispiel: Komplexe Build-Konfigurationen, die sowohl Entwickler als auch AI verwirren
    Beispiel: Docker-Fehler werden nicht frühzeitig erkannt, sondern erst spät im Build verarbeitet

• Missverstandene oder unvollständige Anforderungen

  • Werden Feature-Anforderungen nicht klar formuliert, kann die AI sie missverstehen und die Funktion in die falsche Richtung umsetzen
  • Frühzeitiges Eingreifen wäre ideal, doch sowohl bei autonomer AI als auch bei unreflektierten Entwicklern steigen die Kosten späterer Korrekturen
  • Solche Fehlumsetzungen werden oft erst später im Verlauf einer Story entdeckt und verursachen viel Nacharbeit und Kommunikationsaufwand

Wirkungsradius: Verschlechterung der langfristigen Wartbarkeit

• Der heimtückischste und gefährlichste Wirkungsradius
  • Anfangs funktioniert der Code zwar problemlos, doch später werden Änderungen und Erweiterungen schwierig
• Solche Probleme werden oft erst Wochen oder Monate später entdeckt
• Gerade in diesem Bereich kam die mehr als 20-jährige Entwicklungserfahrung des Autors am stärksten zum Tragen

• Ausufernder und redundanter Testcode

  • AI ist gut darin, Tests zu erzeugen, aber dabei treten häufig folgende Probleme auf:
    • Statt bestehende Tests zu integrieren, werden neue Testfunktionen erzeugt
    • Es werden übermäßig viele Assertions hinzugefügt, selbst für bereits abgedeckte Teile
  • Ein Punkt, den unerfahrene Entwickler missverstehen könnten: Mehr Tests ≠ bessere Tests
  • Je mehr Redundanz entsteht, desto schwieriger wird die Wartung, und bei Codeänderungen steigt das Risiko massiver Testausfälle
  • Es wurde versucht, dies mit Custom Commands abzumildern, doch das Problem tritt weiterhin häufig auf

• Mangelnde Wiederverwendbarkeit

  • Von der AI geschriebener Code ist oft nicht ausreichend modularisiert und daher schwer wiederzuverwenden

    Beispiel: Bereits vorhandene UI-Komponenten werden nicht erkannt und doppelt implementiert
    Beispiel: Statt CSS-Klassen zu verwenden, werden exzessiv Inline-Styles eingesetzt

• Übermäßig komplexer oder ausufernder Code

  • Die AI erzeugt oft mehr Code als nötig, sodass unnötige Teile manuell entfernt werden müssen
  • Das erhöht die Wartungskosten und vergrößert die Fehlerwahrscheinlichkeit bei Änderungen

    Beispiel: Bei einer CSS-Änderung müssen viele redundante Styles einzeln entfernt werden
    Beispiel: Für die Anzeige von JSON-Daten wird unnötig eine komplexe Web-Component erzeugt
    Beispiel: Beim Refactoring wird die bestehende Dependency-Injection-Kette nicht erkannt,
    und ein bereits injizierter Wert wird zusätzlich als weiterer Parameter weitergereicht, was das Design verkompliziert

    • value = service_a.get_value(); ServiceB(service_a, value=value)

Fazit: Kann AI irgendwann den gesamten Code schreiben?

• Nach den bisherigen Erfahrungen ist es realistisch ausgeschlossen, dass AI innerhalb eines Jahres 90 % des gesamten Codes autonom schreibt
• Als Unterstützung beim Schreiben von Code sind in manchen Teams und Codebasen jedoch 90 % Assistenz denkbar
• Tatsächlich erhält der Autor in einem Projekt mittlerer Komplexität mit 15K LOC bereits rund 80 % Unterstützung durch AI

Wie sich Fehler der AI verhindern lassen

• Was einzelne Entwickler tun können

  • Von der AI erzeugten Code immer sorgfältig reviewen
    • Es gibt fast immer etwas zu korrigieren
  • Die AI-Session sofort abbrechen, wenn sie chaotisch wird
    • Den Prompt anpassen oder direkt auf manuelle Arbeit umschalten (auch „Handmade Coding“ genannt)
  • Misstrauisch sein gegenüber "plausiblen" Lösungen, die in erstaunlich kurzer Zeit fertig sind
    • Dahinter können sich langfristige Wartungskosten verbergen
  • Pair Programming praktizieren
    • Vier Augen und zwei Gehirne führen zu besseren Entscheidungen

• Strategien auf Team- und Organisationsebene

  • Bestehende Tools zur Überwachung der Codequalität aktiv nutzen
    • z. B. Sonarqube, Codescene
    • Beim Einsatz von AI-Tools sollten Code-Duplikate, Code Smells usw. noch genauer beobachtet werden
  • Pre-commit-Hooks und in die IDE integrierte Code-Reviews einrichten
    • Die Shift-left-Strategie stärken, um Probleme früh im Entwicklungsprozess zu erkennen
  • Gute Gewohnheiten für Codequalität neu verankern
    • Problemfälle aus AI-generiertem Code („Go-wrong-Log“) in der wöchentlichen Retrospektive im Team teilen
  • Custom Rules aktiv einsetzen
    • Die meisten AI-Tools erlauben es, zusammen mit dem Prompt einen Satz von Regeln zu konfigurieren
    • Wenn das Team das Regelwerk gemeinsam verbessert, lassen sich Fehler der AI reduzieren
    • Allerdings steigt mit längeren Sessions auch die Wahrscheinlichkeit, dass Regeln ignoriert werden
  • Eine Teamkultur schaffen, die auf Vertrauen und Kommunikation basiert
    • Die Einführung von AI ist eine neue Veränderung, und man muss anerkennen, dass alle Anfänger sind
    • Druck nach dem Motto „Mit AI müsst ihr jetzt schneller liefern“ erhöht die Qualitätsrisiken
    • In Teams mit psychologischer Sicherheit werden Probleme offener geteilt und Lernprozesse aktiver vorangetrieben

[bus710]

Die Leute, die dieses Tool verwenden, sind doch unabhängig von ihren Fähigkeiten alle Entwickler .... Es wirkt etwas seltsam, damit zu werben, dass Entwickler in Zukunft nicht mehr nötig seien.

[prunusnira]

Ich weiß nicht, wie es sich künftig entwickeln wird, aber im Moment scheint es mir für den Einsatz im Mainstream noch nicht besonders geeignet zu sein ... Ich habe kürzlich Cursor ausprobiert, und es hat nicht einmal grundlegende Datei-Importpfade richtig erkannt. Trotzdem war es ziemlich erstaunlich, dass es bis zu einem gewissen Grad vorhersagen konnte, was ich erstellen wollte.

[daddy]

Wenn während eines Docker-Builds ein Speicherfehler auftrat, wurde eher die Speicherkonfiguration erhöht, statt von Anfang an zu fragen, warum überhaupt so viel Speicher verbraucht wurde
-> Das ist ... weil wir das in schon unzähligen Fällen genau so gemacht haben.
-> Die heutige AI sind wir aus der Vergangenheit

[GN⁺]

Hacker-News-Kommentare

• Ich nutze inzwischen für die meiste Entwicklung Cursor. Dieser Beitrag entspricht meiner Erfahrung sehr stark.

  • Es fühlt sich an, als wären AI-Agenten ungefähr 2021 stehen geblieben. Wenn man ein neues Paket installiert, greift Claude auf alte Pakete oder Implementierungen zurück, die vor vier Jahren populär waren. Das zu korrigieren ist extrem frustrierend. Klare Anweisungen können das Problem abmildern, lösen es aber nicht.
  • Besonders herausfordernd ist die Unvorhersehbarkeit dieser Fehler. Vor ein paar Monaten habe ich mit Claude in einem "One Shot" eine nützliche Web-App gebaut. Sie war vollständig funktionsfähig und überraschend ausgefeilt. Wenn ich sie allein gebaut hätte, hätte das Wochen oder Wochenenden gedauert. Als ich dann aber bat, das Favicon mithilfe der bereitgestellten Datei zu aktualisieren, drehte es sich eine Stunde lang nutzlos im Kreis (am Ende habe ich es in wenigen Minuten selbst gelöst). Vor ein paar Tagen wollte ich erneut eine Web-App mit ähnlichem Umfang bauen. Nach etwa vier Stunden mit dem Agenten war ich bereit, den Code komplett wegzuwerfen.
  • Dieser Ansatz gibt mir den Mut, Projekte anzugehen, die ich wegen fehlender Zeit, Expertise oder Motivation sonst nicht versucht hätte. Weniger Reibung ist spannend, aber etwas Bedeutungsvolles zu bauen bleibt schwierig. Selbst für ein ausgefeiltes MVP ist immer noch erheblicher Aufwand nötig.
  • Ich muss dabei ständig an Hase und Schildkröte denken. AI-Agenten zu vertrauen ist verlockend, weil es sich anfangs viel schneller anfühlt. Am Ende bleibt aber oft das Gefühl, dass ich mit langsamer, sorgfältiger Arbeit robuster vorangekommen wäre. Wenn ich etwas von Hand baue, muss ich nur selten zurückgehen oder den gesamten Ansatz verwerfen. Bei einem AI-getriebenen Ansatz kann ich mich zwar 10x schneller bewegen, dabei aber rund 70 % der Arbeit wieder wegwerfen.
  • Aufgrund dieser Erfahrungen kann ich mir nicht vorstellen, dass AI innerhalb eines Jahres 90 % des Codes autonom schreiben wird. Sie kann aber dabei helfen, 90 % des Codes zu schreiben.
  • Das aktuelle Umfeld ähnelt dem Hype-Zyklus um autonome Fahrzeuge. Es gab viele gewagte Versprechen und echte Fortschritte, aber ich sehe in den nächsten fünf Jahren keine Welt, in der AI eigenständig nützliche Software schreibt.

• Ich nutze AI so: als Schreibassistenz im IDE, die mir wie eine sehr coole und ausgefeilte Gummiente antwortet.

  • Ich führe oft wiederholt Diskussionen über bestimmte Codefragmente. Meistens werden sie fast ohne Kontext geliefert; ich feile daran, bis die Funktion korrekt arbeitet, und passe sie dann in den größeren Kontext ein (oder übernehme diesen Teil selbst).
  • So nutze ich sie nicht: als Agenten, der selbstständig ein großes Ziel erreichen soll.
  • Der Grund: Der Zeit- und Arbeitsaufwand, den man investieren muss, damit die Ausgabe eines Agentensystems tatsächlich mit dem übereinstimmt, was man erreichen will, ist viel zu hoch. Genau aus all den Gründen, die dieser großartige Artikel beschreibt.
  • Paradoxerweise beschleunigt AI meinen Workflow deutlich, wenn ich sie als sehr kompetente Schreibassistenz nutze. Dadurch macht mich eine weniger agentische AI in gewisser Weise kritischer — und zwar kritischer gegenüber der zusätzlichen Zeit, die ich investieren müsste, um mich an die Eigenheiten agentischer AI anzupassen.

• Ich verstehe es überhaupt nicht.

  • Ich verstehe nicht, warum erfahrene Entwickler so begeistert davon sind, sich an eine so offensichtlich schlechte und unbefriedigende Erfahrung zu ketten.
  • Ich schreibe gern Code und löse gern Probleme. Deshalb habe ich Softwareentwicklung als Beruf gewählt.

• Beispiel: Als während eines Docker-Builds ein Speicherfehler auftrat, wurde einfach die Speichergrenze erhöht, statt zuerst zu fragen, warum von Anfang an so viel Speicher verbraucht wurde.

  • AI ist wirklich genau wie wir.

• Entwicklerfähigkeiten sind weiterhin unverzichtbar — wenn man nicht fahren kann, kann man auch nicht steuern. Aber was ist mit der Energie von Entwicklern? Vor AI konnte ich pro Tag nur ungefähr zwei Stunden coden (echte Zeit zum Schreiben von Code). Mit Claude Code kann ich aber problemlos fünf Stunden am Stück coden. Es fühlt sich an, als würde ich statt eines Fahrrads ein E-Bike fahren. AI erinnert mich an Steve Jobs’ Metapher vom Fahrrad für den Geist — sie ersetzt mich nicht, aber ich komme jetzt viel weiter und schneller.

• Dieses Diagramm ist so nachvollziehbar — unser Team kann hier jeden Punkt abhaken. Obwohl wir AI noch gar nicht nutzen! Stellt euch vor, wie es wird, wenn wir sie irgendwann einsetzen ...

  • "Missverstandene Anforderungen" und "übermäßig komplexe Implementierung" sind praktisch unsere Maskottchen. Mit besseren Gesprächen am Anfang und iterativen Reviews entwirren wir dieses Chaos langsam. Aber Gewohnheiten verschwinden nicht leicht. Gibt es überhaupt Leute, die ohne Hilfe von AI durch diese Fallen navigieren?

• Für mich ist das Offensichtliche unsichtbar: Ich nutze AI ständig.

  • Oft muss ich Tools aufbauen und pflegen — für Entwicklungstools, Introspection, Logging, Transformationen und so weiter. Mit Agenten hatte ich viel Glück dabei, solche Dinge zu bauen und zu ändern. Zum Beispiel Tools, die Daten sammeln und Logs aus einem benutzerdefinierten Planungssystem zusammentragen.
  • Beim Aufbau solcher Tools fällt auf dem kritischen Pfad viel generierter Boilerplate-Code an. An den meisten Tagen möchte ich das nicht selbst machen.

• Ich muss AI zwar stark steuern, bin aber optimistisch, dass bessere Prompts zu besseren Agenten führen werden.

  • Nehmen wir ein Beispiel aus dem Artikel: Code-Wiederverwendung. Wenn ich Code schreibe, habe ich unbewusst bereits ein mentales Inventar des vorhandenen Codes. Unbewusst frage ich mich: "Ist diese neue Aufgabe dem bereits vorhandenen, funktionierenden und getesteten Code sehr ähnlich?" Ich habe mir die Details des initialen Prompts für Coding-Agenten nicht angesehen, aber mein Bauchgefühl sagt mir, dass man dem Agenten per Prompt auftragen sollte, ein Inventar dessen zu pflegen, was in der Codebasis vorhanden ist, und bei der Planung neuer Codeblöcke die Anforderungen der neuen Aufgabe gegen das bereits Vorhandene abzuwägen.
  • Ja, das fügt dem Planungsprozess viele zusätzliche Rechenzyklen hinzu. Aber man sollte ehrlich sagen: "Das ist der Preis dafür, dass der Agent den Code schreibt." Bessere Planung > bessere Problemlösungsfähigkeit.

• Ich möchte voranstellen, dass AI-Tools bei den Dingen, die ich aufgelistet habe, nicht immer schlecht sind.

  • Es scheint, als fehle dort ein "not". Warum sollte man voranstellen, dass sie immer schlecht sind? Die entgegengesetzte Aussage ergibt viel mehr Sinn.
  • Außerdem gibt es einen Grammatikfehler: Statt "effected" müsste es "affected" heißen.

• Vermietet Martin Fowler jetzt Platz auf seiner Website?