Ask HN: Ist agentisches Coding tatsächlich effektiv?

• Ich habe versucht, Agenten-Coding einzusetzen, aber der Widerspruch zwischen dem, was ich online sehe, und den Ergebnissen, die ich tatsächlich implementiere, bereitet mir Kopfzerbrechen. Gibt es Belege dafür, dass es in der Praxis wirklich positive Ergebnisse bringt?
• Falls jemand über den übertriebenen Hype hinaus Agenten-Coding erfolgreich eingesetzt hat, teilt bitte im Detail, wie ihr das gemacht habt
• „Erfolgreich eingesetzt“ bedeutet dabei Folgendes
  • mehr Wert schaffen als technische Schulden verursachen
  • strukturell robusten Code schreiben, den ein Architekturverantwortlicher freigeben könnte
• In letzter Zeit scheint es mit der Forderung nach einem Wechsel von „Architekturvalidierung“ zu „Verhaltensvalidierung“ einen Trend zu geben, Code-Reviews zu minimieren oder ganz abzuschaffen
• In der Praxis scheint das zu bedeuten, den Code gar nicht anzusehen und bereitzustellen, sobald Tests und CI bestanden werden, und ich frage mich, ob dieser Ansatz langfristig tragfähig ist

• Meiner Ansicht nach ist es bei der Nutzung von Codex sehr wahrscheinlich, dass auf dem normalen Pfad zwar alles funktioniert, der Code aber mit der Zeit zu „Spaghetti-Code“ wird, in dem sich subtile und schwer zu debuggende Fehler ansammeln
• Als ich Codex auf eine bestehende Codebasis angewendet habe, habe ich – mit oder ohne gesetzte Richtlinien – die Hälfte meiner Zeit damit verbracht, subtile Fehler oder doppelten Code zu beheben, die Codex erzeugt hatte

• Letztes Wochenende habe ich versucht, eine iOS-App für Erinnerungen an Tierfutter von Grund auf neu zu bauen
  • Ich bat Codex zunächst, einen Architekturentwurf auf Basis von SwiftUI zu recherchieren und vorzuschlagen, und habe dann gemeinsam mit Codex eine Spezifikation geschrieben, die erklärte, was implementiert werden sollte und wie
  • Die erste Implementierung hatte ein paar Bugs, war aber unerwartet ordentlich, doch danach verschlechterte sich die Lage rapide
  • Den Rest des Wochenendes verbrachte ich damit, Codex dazu zu bringen, korrekt zu arbeiten, Bugs zu beheben, ohne neue einzuführen, und Best Practices zu recherchieren, statt einfach willkürlich Code zu schreiben
  • Jedes Mal, wenn ich neue Richtlinien oder Leitlinien entdeckte, ließ ich Codex sie festhalten, aber es wurde nicht besser, und schließlich gab ich auf
• Für mich persönlich ist es inakzeptabel, ungeprüften Code zu deployen
• Irgendetwas scheint hier falsch zu laufen. Das Produkt muss korrekt funktionieren, aber auch die Codequalität muss hoch sein

[GN⁺]

Hacker-News-Meinungen

• Da LLMs als Schlüssel zur Kostensenkung gelten, steht enorm viel Geld auf dem Spiel
  Auch bekannte Influencer oder Experten neigen zu übertriebenen Aussagen, um ihr Image als „State of the Art“ zu bewahren
  Tatsächlich ist der optimale Ansatz für LLM-basierte Entwicklung aber noch nicht etabliert
  Statt es jetzt wie einen Glauben zu behandeln, halte ich es für wichtig, die interne Funktionsweise selbst genauer anzusehen

  • Ich habe kürzlich auch von einer Firma ein Angebot über 200 Dollar bekommen, damit ich ihre neue „agentic coding platform“ bewerbe
    Dass solche Angebote sogar an zufällige Nutzer gehen, bedeutet, dass bereits eine ziemlich große Marketingkampagne läuft
  • LLMs sind eindeutig ein sprunghaft leistungsfähiges Werkzeug, aber kein Universalschlüssel für vollständig autonome Entwicklung
    Für einfache CRUD-Arbeiten machen sie Spaß, bei komplexen Projekten sorgen sie eher für Frust
    Im Moment ist es wegen Benchmark-Wettläufen und VC-Geldern schwierig, nüchtern darüber zu diskutieren
  • Wie damals beim ersten Auftauchen von GUIs befinden wir uns wohl gerade in einer Phase, in der man den intuitiven Wert spürt
    Es gibt noch zu wenig quantitative Belege, aber auch wenn Entwickler nicht völlig verschwinden werden, hat sich die Art der Entwicklung dauerhaft verändert

• Ein Principal Engineer von Google hat getwittert, dass „Claude Code in 1 Stunde erledigt hat, wofür ich 1 Jahr gebraucht hätte“
  Später stellte sich jedoch heraus, dass die KI nur eine einfache „Toy-Version“ erstellt hatte
  Solche übertriebenen Aussagen verzerren die Erwartungen und führen zu Enttäuschung
  Link zum betreffenden Tweet

  • Hinter solchen Tweets steckt oft interner Druck, Ergebnisse der AI-Führung vorzuweisen
  • Jemand reagierte darauf mit: „So etwas zu sagen ist doch absurd.“
  • Eine andere Person wies darauf hin, dass AI-Ergebnisse vom Erfahrungsniveau und den Investitionskosten abhängen
  • Es gab auch eine zynische Reaktion: „AI liefert immer noch nur Code, den man nicht deployen kann.“
  • Jemand anderes stichelte, dass „so etwas Google ziemlich gut beschreibt“

• Rückblickend auf die letzten 6 Monate habe ich bei Infrastruktur-Code (z. B. Terraform) eine 10-fache Effizienz erreicht
  Aber spezialisierte Feature-Entwicklung ist weiterhin sehr schwankend
  Trotzdem konnte ich mit der durch weniger Wiederholungsarbeit gewonnenen Zeit die Qualität von Tests und Sicherheit verbessern
  Vor allem hat es mir wieder die Freude am Coden zurückgegeben

  • Ich entwickle seit 35 Jahren als Hobby, und AI nimmt mir das langweilige Tippen ab und fördert die Kreativität
  • Auch ich bin bei Build-Skripten oder CI-Arbeiten mehr als doppelt so schnell geworden, aber komplexe HPC-Projekte bleiben schwierig, und
    assisted coding war dabei am effizientesten
    Projektlink
  • Ich habe mit Claude eine Dateisuche für mein NAS gebaut und an einem Tag ein Go-Backend mit täglicher automatischer Indizierung sowie ein Web-UI fertiggestellt
    Solche persönlichen Projekte sind für mich der eigentliche Game Changer
  • Wenn man Aufgaben klein aufteilt, funktionieren Agenten deutlich besser
  • Allerdings ist die Qualität von Testcode nach wie vor niedrig. Die Trainingsdaten selbst sind beim Schreiben von Tests schwach

• Ich hatte großen Erfolg mit dem Ansatz, Agenten an bestehende Apps anzudocken
  Agenten sind schwach bei Architekturentwürfen, funktionieren aber sehr gut in bereits strukturiertem Code
  Je strenger das Typsystem und je breiter die Testabdeckung, desto größer der Nutzen

  • Aktuell experimentiere ich damit, ein Rust-Projekt direkt vom LLM verwalten und entwickeln zu lassen
    Es läuft auf Basis von ROADMAP.md, TASKS.md und STATUS.md, die Claude geschrieben hat, und
    überraschenderweise ist es bereits zu etwa 20 % fertig
  • C# passt gut zu Agenten, dank striktem Compiler und regelbasierter Umgebung
    Python oder JS sind dagegen wegen ihres schwachen Typsystems schwerer verlässlich zu nutzen
  • Je aufgeräumter die bestehende Codebasis ist, desto besser performen Agenten
    Ganz von vorne anzufangen ist schwierig, aber mit einer klaren Spezifikation steigt die Effizienz
  • Go ist für LLMs dank der einfachen Sprache und konsistenten Muster leicht zu handhaben
  • Typescript ist dank schneller Kompilierung und starkem Typsystem ideal für Agenten
    Die optionalen Typen von Python fördern dagegen eher die Fehlerfortpflanzung

• Ich habe mit Claude Code einen Bluetooth-Echtzeit-Herzfrequenzmonitor für Linux zu 100 % schreiben lassen
  Projektlink
  Er wurde in reinem C geschrieben, und Web-Interface samt Echtzeitgrafik war an einem Tag fertig
  Eine dBus–blueZ-Kommunikation, an der ich früher gescheitert war, konnte ich diesmal erfolgreich umsetzen

  • Als ein anderer Nutzer den Code geprüft hat, stellte sich jedoch heraus, dass die SSE-Implementierung in Wirklichkeit nicht funktioniert
    In der Doku steht zwar SSE, intern wird aber nur eine normale HTTP-Antwort zurückgegeben
  • Jemand anderes merkte an, dass von AI geschriebener Code anfangs gut aussehe, die Qualität aber mit der Zeit nachlasse
  • Eine andere Person bewertete es als nicht übertriebenes Beispiel und bedankte sich dafür, ein echtes Praxisbeispiel geteilt zu haben
  • Es gab auch einen Kommentar, der den UI-Stil interessant fand und nach dem Design fragte

• Ich nutze jeden Tag Augment + Claude Opus 4.5
  Ich schreibe kaum noch selbst Code und stelle Projekte durch spezifikationsbasierte iterative Arbeit fertig
  Besonders effizient ist die Methode, mehrere Agenten parallel laufen zu lassen und ihre Ergebnisse zu reviewen
  Klare Spezifikationen und schrittweises Feedback sind der Schlüssel

  • Obwohl ich Ruby nicht gut kenne, hilft es mir enorm bei der Entwicklung von Rails-Apps
    In 30 Jahren Berufserfahrung fühlt sich das für mich wie die revolutionärste Veränderung an, und ich bin überzeugt, dass sich die gesamte Branche verändern wird
  • Jemand machte scherzhaft die Bemerkung, ein einwöchiges Projekt als mittelgroß zu bezeichnen sei eher klein
  • Eine andere Person meinte, das sei weniger echte Agentenentwicklung als vielmehr kollaborative Entwicklung mit LLMs
  • Es gab auch die Meinung, dass spec-driven development der Schlüssel zu produktionsreifer Qualität sei
  • Ich habe zusätzlich den Schritt eingebaut, Claude zuerst Fragen stellen zu lassen, damit die Anforderungen klarer strukturiert werden
    Derzeit arbeite ich mit Claude an einem Japanisch-Englisch-Wörterbuchprojekt
    GitHub-Link, Website

• Als Entwickler mit 20 Jahren Erfahrung sorgt LLM-Unterstützung bei mir dafür, dass meine Zeitschätzungen für Aufgaben völlig danebenliegen
  Dinge, die früher 2 Wochen dauerten, sind jetzt in 2 Tagen erledigt
  Code-Review und Interaktion bleiben nötig, aber gefühlt ist es besser als die meisten menschlichen Entwickler
  Gespräche mit LLMs fühlen sich eher an wie Zusammenarbeit mit einem Senior-Entwickler, und
  meine langjährige Erfahrung mit Code-Reviews und Aufgabenverteilung hilft dabei enorm

  • Jemand fragte sich, bei welcher Art von Problemen so eine Geschwindigkeitssteigerung möglich sei, weil das schwer zu glauben sei
  • Eine andere Person erwähnte kurz, sie habe Belege erwartet, aber keine gesehen

• Am stabilsten war für mich bisher die Methode, Claude kleine, klar definierte Arbeitspakete zu geben
  Man plant, prüft, implementiert und reviewt dann wiederholt
  Es ist nicht perfekt, aber sehr nützlich, um festgefahrene Stellen zu überwinden
  Da Richtlinien jedoch schlecht eingehalten werden, sind eigene Verifikation und Bereinigung unverzichtbar

  • Ich nutze Claude auch ähnlich wie Rubber-Duck-Debugging
    Ich gebe immer nur eine Funktion auf einmal und nutze das Ergebnis, um auf bessere Ideen zu kommen
  • Bei Dokumentation oder Analyse sind LLMs besonders stark
    Bei designzentrierten Problemen zeigen sich die Grenzen jedoch deutlich
  • Auf die Frage, wo man Richtlinien ablegt, lautete der Rat, Build- und Testinformationen in CLAUDE.md zu schreiben

• Viele missverstehen AI-gestütztes Coding
  AI ist kein Teammitglied, sondern ein Hilfswerkzeug
  Bugs oder Fehlfunktionen als Misserfolg zu sehen greift zu kurz; entscheidend ist der Prozess, in dem ein erfahrener Entwickler dieses Chaos wieder ordnet

  • Jemand fragte, worin sich das bei so viel Handarbeit dann noch von IDE-Autovervollständigung unterscheide
  • Eine andere Person fragte, ob es Beispiele gebe, in denen moderne Methoden tatsächlich eine Qualitätsverbesserung belegt hätten
  • Jemand anderes spottete, am Ende klinge das doch nur nach „Du benutzt es einfach falsch“
  • Es gab auch den Scherz: Wenn du erwartet hast, beim Baseballschauen eine perfekte App bauen zu lassen, dann hast du keinen AI, sondern einen Zauberer gekauft

• Ich nutze Claude ebenfalls täglich, aber von AI erzeugter Testcode ist oft chaotisch
  In der Praxis produziert er massenhaft sinnlose Tests wie expect(true).to.be(true)

  • Frühere Modelle scheiterten daran, aber ich habe einen Beitrag gesehen, wonach neuere Modelle Code erzeugen, der sich mit Tricks durchmogelt
  • Deshalb schreibe und überprüfe ich Tests im TDD-Stil zuerst selbst
    Wenn man Implementierung und Tests gleichzeitig delegiert, entstehen Fehler durch Selbstbewertung
  • Jemand sagte, er habe aufgegeben, mit Claude Tests schreiben zu lassen
  • Eine andere Person lachte und meinte, das sei eine allzu menschliche Lösung