Warum wird agentische KI so stark vorangetrieben, wenn Modelle nicht einmal einfache Anweisungen zuverlässig befolgen können?

• In einer Realität, in der AI-Coding-Modelle nicht einmal einen einzelnen Befehl zuverlässig ausführen können, entstehen überzogene Erwartungen an agentisches Coding, das autonom im Hintergrund arbeitet
• Der Autor erlebte, dass sowohl GPT-5 als auch Gemini Pro trotz Bereitstellung einer Golang-Funktion mit rund 100 Zeilen als Referenz Teile der Logik ausließen oder Updates vergaßen
• Dass agentische Systeme 50 Dateien und zahlreiche Funktionen autonom bearbeiten, ist auf dem aktuellen technischen Stand unrealistisch und birgt eher das Risiko, dass mehr Zeit fürs Debugging draufgeht
• Die Reaktionen der Community spalten sich in die Ansicht, dass durch systematisches Prompting, Dokumentation und schrittweise Validierung ein begrenzt erfolgreicher Einsatz möglich ist, und in skeptische Stimmen, die agentische Ansätze noch nicht für praxistauglich halten
• Aktuelle LLMs sind wissensbasierte Systeme, keine Intelligenz, daher ist ein werkzeugorientierter Einsatz realistisch, bei dem Entwickler den Kontext selbst bereitstellen und jeden Schritt validieren

---

Problemaufriss des Autors des Originalbeitrags

• Beispiel für das Scheitern an einer einfachen Anweisung: Eine 100-zeilige Golang-Funktion wurde als Referenz bereitgestellt mit der Bitte, eine andere Funktion in derselben Struktur zu aktualisieren, doch sowohl GPT-5 als auch Gemini Pro ließen Teile der Logik aus oder vergaßen einzelne Änderungen
• Unrealismus agentischen Codings: Wenn nicht einmal eine einzelne Funktion sauber verarbeitet werden kann, dürfte ein agentischer Ansatz, der autonom zahlreiche Funktionen über 50 Dateien hinweg ändert, noch mehr Probleme verursachen
• Frage zur Aktualisierung einer 6000-Zeilen-Datei: Die Community wurde nach Meinungen gefragt, wie sich eine Datei im Umfang von 6000 Zeilen, etwa bei einem Stripe-Versionsupdate, sicher ändern lässt

Positive Einsatzbeispiele und Methoden

Ansatz mit systematischer Dokumentation und Indexierung

• Verwendung von Markdown-Referenzdateien: Wenn Referenzen in einer .md-Datei gespeichert werden und die AI angewiesen wird, diese zu lesen, steigen Konsistenz und Genauigkeit
  • Beispiel-Prompt: "Nutze die angehängte Datei goLang_Update_reference.md als Referenz, fasse die Kernpunkte der Update-Funktion zusammen und erstelle darauf basierend einen Entwurf für das Software-Update"
• Lokalen Index aufbauen: Bei großen Dateien (über 6000 Zeilen) wird in Blöcken zu 1000 Zeilen gescannt, um einen Index mit Funktionsnamen und Zeilenreferenzen zu erstellen
  • Bei Frontend-Arbeiten werden Indizes wie fr.index.md genutzt, die nur bestimmte Bereiche separat abbilden

Agentenverwaltung und Strukturierung der Arbeit

• Spezialisierung von Agenten: Agenten für Rollen wie Design (architect), Code-Erkundung (codeseeker) und Implementierung (coder) werden getrennt aufgesetzt und jeweils mit passenden .md-Regeldateien versehen
• Vertical-Slice-Ansatz: Aufgaben werden in kleine Funktionseinheiten zerlegt, die sich mit weniger als 100.000 Tokens abschließen lassen
  • Oberhalb von 100.000 Tokens steigt die Wahrscheinlichkeit von Fehlverhalten der Agenten stark an
• Dokumentation der Arbeit erzwingen: Updates in docs/TASKS.md, docs/WORKLOG.md und docs/DECISIONS.md werden verpflichtend gemacht, um Arbeitskontinuität sicherzustellen

Einsatz von Plan Mode und Ask Mode

• Plan Mode: Das gesamte Projekt wird geprüft, anschließend wird gemäß der Anfrage ein Plan erstellt und Schritt für Schritt abgearbeitet
• Ask Mode: Nützlich für Abfragen im Codebestand, das Erkunden von Ideen und das Prüfen von Optionen; kann als Ersatz für Google oder StackOverflow dienen

Ansatz mit vorgeschalteten Unit-Tests

• Testgetriebene Entwicklung: Vor dem Schreiben einer Funktion werden zuerst Unit-Tests erstellt, anschließend lässt man die AI wiederholt Code generieren, bis die Tests bestehen
  • Die Wahrscheinlichkeit, funktional korrekten Code zu erhalten, steigt deutlich; danach sind meist nur noch Optimierung und Bereinigung nötig

Skeptische Sichtweisen und Wahrnehmung von Grenzen

Praktische Grenzen agentischer Ansätze

• Arbeiten ohne Aufsicht ist selbstzerstörerisch: Auf dem aktuellen Stand der Technik ist es sehr wahrscheinlich, dass das Zuweisen eines Tickets und autonomes Arbeiten im Hintergrund scheitert
• Möglichkeit von Falschaussagen: Modelle erzeugen eher Halluzinationen als verlässlichen Erfolg und können im schlimmsten Fall bestehenden Code beschädigen
• Redundanz des Planning Mode: Es reicht oft schon, das Basismodell nach einem detaillierten Plan zu fragen; Planning Mode liefert praktisch keine neue Funktionalität

Grundlegende Einschränkungen von LLMs

• Vorhersage statt Schlussfolgern: Modelle arbeiten, indem sie das nächste Wort vorhersagen, ohne Ergebnisse zu verifizieren; daher bleibt die Zuverlässigkeit instabil, bis sich grounding, memory und feedback verbessern
• Wissensbasis ohne Intelligenz: LLMs sind hochentwickelte Wissensbasen ohne eigene Intelligenz; Entwickler müssen Intelligenz (BYOI: Bring Your Own Intelligence) und Kontext selbst mitbringen
• Mangel an Gedächtnis: Modelle besitzen kein echtes Gedächtnis und verlassen sich nur auf context und context cache, weshalb der Kontext bei jedem neuen Chat zurückgesetzt wird

Sprach- und Datenbias

• Relative Benachteiligung von Golang: Für Golang gibt es im Vergleich zu Python oder JavaScript weniger öffentliche Codebasen, weshalb den Modellen weniger gelernte Muster und Konventionen zur Verfügung stehen
  • Das ist ein struktureller Faktor, der konsistente Editierungen oder Transformationen erschwert

Praktischer Leitfaden für eine erfolgreiche Nutzung

Prompting und Bereitstellung von Kontext

• Klare und detaillierte Anweisungen: Syntax und Zeichensetzung präzise verwenden und statt vager Formulierungen explizite Anweisungen geben
• Alle relevanten Dateien explizit referenzieren: Wenn nicht alle von den Agenten benötigten Dateien genannt werden, steigt die Wahrscheinlichkeit für Spaghetti-Code
• Regeldateien einrichten: Workspace-weite Regeln und projektspezifische Regeldateien helfen dabei, konsistente Codegenerierung zu fördern
• @Docs nutzen: Dokumentreferenz-Funktionen verwenden, um Agenten das notwendige Kernwissen bereitzustellen (funktioniert in einigen Versionen instabil)

Arbeitsumfang und Validierung

• In kleine Einheiten zerlegen: Aufgaben in die kleinstmöglichen Einheiten aufteilen, jeden Schritt validieren und erst dann zum nächsten übergehen
• Prüfung in Echtzeit: Sämtlichen generierten Code direkt prüfen und bei Bedarf sofort Korrekturen anfordern, um Spaghetti-Code zu vermeiden
• Backups und Versionsverwaltung: Nach jedem Schritt ein Backup anlegen und Versionsverwaltungssysteme wie GitHub nutzen
• Tests ausführen: Mit pytest --testmon -q inkrementell die betroffenen Tests ausführen und vor Abschluss den kompletten Testlauf starten

Modularisierung und Codestruktur

• 6000-Zeilen-Datei aufteilen: 6000 Zeilen in einer einzelnen Datei sind unmodular und ungünstig für die Kontextbereitstellung; wirksamer ist die Aufteilung in 12 Dateien mit jeweils etwa 500 Zeilen
• Vertical Slices bevorzugen: Entwicklung in kleinen, Ende-zu-Ende lauffähigen Funktionseinheiten

Modellauswahl und Kostenmanagement

• Claude Sonnet 4.5 bevorzugt prüfen: Im Vergleich zu GPT oder Gemini bietet es höhere Konsistenz und Genauigkeit und kann den Mehrpreis rechtfertigen
• Auf Token-Verbrauch achten: Groß angelegte Planungen verbrauchen viele Tokens; kosteneffizienter ist es, die tatsächliche Ausführung in kleine Schritte zu zerlegen

Spezielle Anwendungsfälle

Erstellung von Einweg-Skripten

• Analyse-Skripte: Wenn täglich Hunderte einmaliger Skripte zur Datenanalyse geschrieben werden müssen, kann selbst eine Genauigkeit von 50 % im Vergleich zur manuellen Erstellung zu einer 1000-fach schnelleren Generierung und Ausführung führen
• Überprüfbarkeit der Ergebnisse: Da sich die Resultate direkt verifizieren lassen, bleibt der Einsatz auch bei geringerer Genauigkeit praktisch sinnvoll

Aufbau einer App von Grund auf

• Multi-Agenten-Struktur: Beim Aufbau einer großen App von Grund auf prüft ein überwachender Agent die Arbeit anderer Agenten, um Konsistenz zu sichern
  • Wirksam etwa bei der Konsistenz von Importnamen und Variablennamen sowie beim Vermeiden von Code-Duplikaten
• Effizienz im Verhältnis zu den Kosten: Komplexe Änderungen und Refactorings bleiben weiterhin nötig, weshalb ein schrittweiser Ansatz langfristig günstiger ist

Zusammenfassung der Community-Meinungen

Positive Erfahrungen (3- bis 5-fache Produktivitätssteigerung)

• Next.js-Website: In wenigen Minuten wurde aus dem Nichts eine vollständig funktionsfähige und deploymentfähige Website aufgebaut
• Implementierung komplexer Funktionen: Eine Threads-Funktion wurde in einer Chat-App in 3 bis 4 Minuten umgesetzt (geschätzter Arbeitsaufwand sonst 3 Tage)
• Bei systematischem Vorgehen: Mit klaren Regeln, ausreichend Kontext und schrittweiser Validierung sind konsistente Erfolge möglich

Negative Erfahrungen (derzeit unpraktisch)

• Produktion von Spaghetti-Code: Bei weit gefassten Zielen treten Probleme wie ausgelassene Dokument-Updates oder nicht gelöschte Restdateien auf
• Semantische Fehler: Technisch funktioniert der Code zwar, ist aber strukturell problematisch, etwa weil er an der falschen Stelle eingefügt wird oder bestehende Funktionen neu implementiert
• Scheitern bei mehr als 5 Minuten Laufzeit: Längere Abläufe von mehr als 5 Minuten erzeugen meist unbrauchbare Ergebnisse

[GN⁺]

Hacker-News-Kommentare

• Meiner eigenen Erfahrung nach befolgen die meisten LLMs meine Anweisungen ziemlich gut. Natürlich braucht es sorgfältig ausgearbeitete Prompts und Vorplanung, aber wenn man diese drei Dinge im Griff hat, kann man mit solchen Coding-Agenten durchaus sehr produktiv sein. Manchmal liegt es vielleicht in 1 von 10 Fällen daneben, aber selbst dann kommt man mit schnellem Abbruch und Neuverteilung rasch wieder auf Kurs. Es überrascht mich, wie viele Leute hier auf HN der Wirkung skeptisch gegenüberstehen. Klar, es gibt viele Sorgen wegen Kosten, Veränderungen bei Jobs usw., aber dass so oft am Nutzen von Coding-Agenten gezweifelt wird, finde ich unerwartet
  • Es wäre gut, echte Videos oder Praxisbeispiele zu sehen, in denen Agentensysteme oder LLMs tatsächlich mehr Wert schaffen als Google-Suche oder Stack Overflow
  • Wenn man den aktuellen Zustand, das gewünschte Ergebnis und das Vorgehen ausreichend erklärt, kann man mit dem Agenten gemeinsam planen, nachschärfen und dann ausführen. So ist der aktuelle Stand der Technik durchaus beeindruckend. Zu erwarten, dass etwas Komplexes mit nur einem Satz klappt, ist unrealistisch. Es braucht echte Zeit und Mühe, ähnlich wie wenn man einem klugen Praktikanten ohne Berufserfahrung eine technische Aufgabe gibt. Nur arbeitet ein KI-Agent viel schneller als ein menschlicher Praktikant
  • „Funktioniert meistens gut“ heißt praktisch, dass es keine Zuverlässigkeitsmetrik gibt, also keine Zahl an Neunen
  • Ich war gerade mit dem Hund draußen und habe mit Codex (gpt-5-high) in einem Rutsch eine Python-App nach Go portiert. Ich habe das Ergebnis getestet, und es funktioniert gut. Ich bin zufrieden, dass ich jetzt ohne virtuelle Umgebung als einzelnes Binary deployen kann. Ich weiß nicht, ob der Befehl deshalb besonders einfach war
  • „Funktioniert meistens gut“ reicht mir als Maßstab nicht. Das gravierendere Problem ist nicht, dass Anweisungen nicht befolgt werden, sondern dass Fehler nicht zugegeben werden und stattdessen weiter darauf beharrt wird. Wenn ich etwas mittelkomplexes verlange oder eine Fehleranalyse will, hält das Modell recht oft an falschen Schlussfolgerungen fest. Häufig findet es keinen Ausweg, bis ich das Problem selbst direkt anspreche. Für einfachen Code oder Boilerplate ist es wirklich gut, und mit etwas Feedback konnte es sogar neue Libraries erstellen. Aber weil es so oft falschliegt, möchte ich ihm nichts Komplexeres anvertrauen. Wenn ich feststecke, nutze ich es trotzdem zum Brainstorming; selbst wenn es falschliegt, hilft es bei der Motivation
• Wenn die Erfahrungen von Entwicklern mit LLMs so erstaunlich stark auseinandergehen, sollten wir uns wirklich fragen: „Warum sind diese Erfahrungen so unterschiedlich?“ Die Erklärung „du benutzt es einfach falsch“ ist die einfachste, aber als Entwickler von KI-Systemen überrascht mich auch, wie viele Nutzer tatsächlich einfach „mach das mal heile“ oder „schreib einen Bericht“ eingeben und dann ein Ergebnis erwarten. Dazu kommt der überzogene Management-Hype im Stil von „mit KI geht alles“, was auch mit Unternehmensbewertungen und Aktienkursen verknüpft ist. Die breite Öffentlichkeit scheint KI ebenfalls als „echte künstliche Intelligenz“ zu sehen. Ehrlich gesagt ist die Behauptung wenig glaubwürdig, dass LLMs nicht einmal einfachen Anweisungen folgen können; der wichtige Punkt ist, dass sie komplexe Aufgaben immer noch nicht wirklich sauber bewältigen
  • Meine andere Theorie ist, dass jeder eine Spezifikation im Kopf hat und sie ungeordnet aufschreibt, in der Hoffnung, das LLM setze sie um, während das tatsächliche Ergebnis dann immer von dieser Spezifikation abweicht. Manche Entwickler passen diese innere Spezifikation im Nachhinein an oder akzeptieren kleine Unterschiede einfach, während andere enttäuscht sind, dass das LLM ihren inneren Plan nicht getroffen hat. Es ist ein bisschen wie eine psychologische „falsche Erinnerung“: Manche sind flexibler und kompromissbereiter, andere starrer. Ich erlebe selbst abwechselnd beide Zustände
  • Ich würde inzwischen gern viel mehr Screencasts, lange Texte oder irgendetwas sehen, das den vollständigen Prozess zeigt, wie jemand tatsächlich nichttriviale Features baut. KI-Influencer zeigen fast immer nur, wie man mit KI KI-Tools baut, oder CRUD- bzw. Hello-World-Demos. Selbst erfahrene Entwickler sagen, KI habe mehr als die Hälfte ihrer Codebasis geschrieben, erklären dann aber, dass sie in Wirklichkeit fast alles verworfen und nur einzelne Teile als Referenz genutzt haben. Die Geschichte „Single Prompt → fertige App“ wird schnell zu „hilft, wenn man vor einem leeren Bildschirm Motivation braucht“. Ich wünschte mir mehr Transparenz darüber, wie echte Entwickler das in der Praxis wirklich einsetzen
  • Tatsächlich ist „Entwickler“ als Kategorie so breit, dass sie für diese Diskussion kaum Aussagekraft hat. Für das Zusammensetzen ähnlicher CRUD-artiger Codeschnipsel funktioniert ein LLM in vielen Fällen ziemlich gut
  • Alle arbeiten an unterschiedlichen Codebasen und an ganz anderen Aufgaben. Dieses wichtige Detail wird fast nie erwähnt. Je häufiger man es benutzt, desto höher werden die Erwartungen und desto schneller spürt man die Grenzen. Wenn man es nur gelegentlich nutzt, wirkt es beeindruckend, aber wenn man es den ganzen Tag nutzt, sammelt sich am Ende doch Enttäuschung an. Selbst Dinge, bei denen man denkt „das müsste es doch schaffen“, müssen oft wieder nachbearbeitet werden
  • Ich bin überzeugt, dass nicht die Ergebnisse unterschiedlich sind, sondern die Erwartungen. Unser SVP für IT im Unternehmen ist ein KI-Evangelist. Ich arbeite gerade an einem alten PHP-Legacy-Projekt, das er früher gebaut hat, und habe gemerkt, wie niedrig sein Anspruch an Codequalität normalerweise ist. Ich selbst nutze LLMs jeden Tag, bearbeite die Ergebnisse aber immer nach. Je niedriger also die erwartete Codequalität ist, desto zufriedener ist man mit dem Output von LLMs
• Im Cursor-Forum wird immer nur wiederholt: „Du hast es falsch benutzt“, aber was mich wirklich interessiert, sind Vertrauen, Prozess und reale Anwendung im Arbeitsalltag. Auch hier wirkt es am Ende so, als sähe man kaum jemanden, der das wirklich in großem Maßstab einsetzt. Wir verwenden KI meist eher als „dummen Kollegen“ und experimentieren stärker in Side Projects mit weniger Einschränkungen. Agenten wirken auf mich weitgehend wie Hype, oder höchstens wie etwas für extrem spezielle Nischen
  • Der Grund, warum der OP schlechte Ergebnisse bekommt, ist, dass er Cursor benutzt. Cursor schneidet aus Kostengründen den Gesprächskontext brutal zusammen. Anders als Modellanbieter muss Cursor die LLM-Nutzung zu Endkundenpreisen bezahlen und ist dadurch in einem ungünstigen Preiswettbewerb. Cursor legt nicht transparent offen, wie stark Kontext gekürzt wird, und meiner Erfahrung nach wird wirklich aggressiv abgeschnitten, sodass man dieselben Dateien immer wieder neu laden muss, damit das System überhaupt versteht, worum es geht. Mein Rat wäre, keine Zeit mehr in Cursor zu investieren. Der von Cursor erzeugte Code schafft nur technischen Schuldenballast. Mit Codex und Claude bin ich deutlich zufriedener
  • Mich würde interessieren, welche konkreten Verbesserungen du dir wünschst. Im ursprünglichen Post fehlen konkrete Beispiele, Prompts und Methoden; da steht im Grunde nur „ich kann gut prompten“, und so ist weder Bewertung noch Beratung wirklich möglich. Ich verstehe zwar auch den skeptischen Blick auf agentische Workflows, aber so gibt man den Leuten kaum eine faire Gelegenheit zur Gegenrede. Ich arbeite selbst seit einigen Monaten mit Agenten und lerne immer noch, was funktioniert und was scheitert. Nach meiner Erfahrung:
    • Orchestrierung mit Frameworks wie agent-os ist essenziell
    • Das richtige Gleichgewicht zwischen Steuerung und Autonomie ist wichtig
    • Gerade in Legacy-Code ist Vorplanung wirklich entscheidend
    • Mein Beispiel: In einem Legacy-System wird ständig das Kontextfenster überschritten, und wenn ich den Kontext zusammenfasse, fehlen immer wieder entscheidende Informationen, sodass dieselben Fehler erneut passieren.
    • Was geholfen hat: das Problem klar zu strukturieren, alle Entdeckungen und Lernergebnisse einzeln festzuhalten und in sehr konkrete Sub-Agenten aufzuteilen, damit das Kontextfenster beherrschbar bleibt. Erst dann wurden Agenten bei der Erkundung von Legacy-Code wirklich praktisch hilfreich
  • Ich habe erlebt, dass ein Agent mehrere Produktionsbugs gefunden hat, die ich selbst nicht entdeckt hatte, weil ich nicht genug Zeit in mir unbekannte Bugs investieren konnte. Natürlich übersieht er viel mehr Bugs, als er findet, aber verglichen mit einer Stunde Arbeit eines Software Engineers ist das fast kostenlos, und wenn es gelegentlich funktioniert, ist es eine durchaus brauchbare Strategie
  • Ein Beitrag mit praktischen und konkreten Beispielen wäre deutlich sinnvoller und würde bessere Antworten hervorbringen. Informationen über ein konkretes Problem aus dem Arbeitsalltag und darüber, wie das LLM dabei gescheitert ist, wären viel hilfreicher
  • Der tatsächliche Business-Nutzen ist viel kleiner, als die Leute glauben, und das frustriert. Sicher, bei Boilerplate oder in vertrauten Bereichen ist es manchmal besser als Menschen. Aber die anderen Probleme sind zu groß: Abhängigkeit von Big Tech, Datenverschmutzung, nicht verifizierbare Informationen, Verlust an Kreativität, Erosion von Originalität, Unwissenheit von KI-Fanatiker:innen, Energieverbrauch, Aneignung menschlicher Werke usw. Ich finde es erstaunlich, dass manche glauben, das sei per saldo ein Gewinn für die Menschheit
• Im Jahr 2025 ist Marketing auf Reddit, LinkedIn und praktisch allen Foren so gut geworden, dass Marken in Gespräche einsickern. CEOs, KI-„Denker“ und VCs bewerben LLMs wie Magie und verkaufen v0, Lovable usw. als die nächste große Innovation. Die Antworten aus dem Leadership klingen alle gleich (passendes Video). Aber egal, wie viele Dinge wie CLAUDE.md oder cursorrules man erstellt, es bringt fast nichts. Am Ende muss das LLM die Anweisungen befolgen, und in der Praxis wirkt das zufällig. Es hält sich kaum einmal an selbst sehr einfache Regeln, weshalb ich denke, dass die Leute, die im Cursor-Forum posten, wohl alle Amateure sind. Und bei neuer Codearbeit sind LLMs wirklich schlecht. Sie nehmen Libraries an, die gar nicht existieren, und produzieren nur nutzlosen Text. Ich nutze sie buchstäblich eher wie Speech-to-Text, wobei das LLM Edge Cases, Best Practices oder Syntax, die ich übersehen habe, besser aufspürt.
  • [1] Die Ergebnisse aus Suche, Perplexity usw. bestehen größtenteils aus Marketingmaterial, das von Marketingteams ausgestreut wurde
  • Ich stimme völlig zu, dass LLMs bei neuer Codearbeit wirklich schrecklich sind. Die aktuellen SOTA-Modelle können in sehr bekannten Frameworks mit konsistenten Mustern wie MVC oft ganz gut Boilerplate oder einfache Strukturen erzeugen. Wirklich hervor tun sie sich bei Aufgaben, bei denen viele Informationen durchsucht werden müssen, um etwas zu finden, etwa in einer Codebasis, in Logs oder in Stack Traces. Aber das Marketing, wonach „der Agent die ganze Codebasis baut“, ist meiner Meinung nach zumindest derzeit nicht realistisch
  • Bei mir ist die Erfahrung exakt umgekehrt. In der letzten Woche hat Claude Code Probleme in einem Compiler, den ich betreue, fast eigenständig behoben. Abgesehen von gelegentlichen frustrierenden Momenten hat es kontinuierlich sogar subtile Bugs in Codegenerierung und Parsern gut gefixt, und meine Eingriffe hingen eher mit Tool-Grenzen wie dem Management von Compaction zusammen. Es hat sogar Methoden implementiert, für die man sonst erst ein Buch aufschlagen müsste, und ich habe bestätigt, dass sie in der Praxis funktionieren. Vollständig neu und wirklich „innovativ“ ist davon vielleicht wenig, aber tatsächlich ist kaum irgendein Code wirklich neu. Meiner Erfahrung nach folgt es bei gut strukturierten Leitlinien meistens sehr gut. Es reicht nicht, einfach irgendetwas in CLAUDE.md zu schreiben. Der Kern ist eine sorgfältige Anleitung für den Prozess. Meine Arbeitsweise zerfällt in 1) projektspezifische Debugging-Guides, 2) klare Akzeptanzkriterien, 3) häufiges Testen und das Festhalten kleiner Änderungen pro Einheit in Dateien. So kann ich Claude stundenlang fast ohne Aufsicht autonom arbeiten lassen, abgesehen von einem gelegentlichen „continue“-Befehl oder /compact. Es liefert nicht jedes Mal perfekten Code, aber das tue ich auch nicht. Trotzdem führt es meist zu positiven Veränderungen und reduziert meinen Aufwand erheblich. Bootstrap in einem noch nicht sauber entworfenen Zustand würde ich noch nicht empfehlen, aber manchmal schafft es selbst das, sofern vorher ein Review stattfindet. Inzwischen denke ich sogar darüber nach, Claude tageweise nonstop Probleme automatisch lösen zu lassen
  • Es ist wirklich faszinierend, wie unterschiedlich die Erfahrungen mit LLMs sein können. Bei mir hat codex-cli die Produktivität gefühlt verfünffacht. Es konnte problemlos Quellcode mit sehr ungewöhnlicher Struktur und interne SVG-Ausführungstraces in ein benutzerdefiniertes JSON-Graphformat konvertieren oder aus einer komplexen Python/C++-Codebasis, bis hinunter zu einem Low-Level-RISCV-Kernel, präzise Dokumentation extrahieren. Ich frage mich wirklich, woran es liegt, dass selbst mit demselben Tool so unterschiedliche Ergebnisse herauskommen
  • Für mich fühlt sich Coding mit Claude wie ein Glücksspielautomat an. Manchmal bekommt man genau, was man will, aber viel häufiger nicht oder komplett daneben. Man sollte es auf keinen Fall unbeaufsichtigt alleine laufen lassen
  • Ich habe ebenfalls den Eindruck, dass der beständigste Wert von LLMs darin liegt, kleine Fehler, Best-Practice-Beispiele oder Code-Syntax zu erkennen, die Menschen oft übersehen. Deshalb sind sie als PR-Reviewer mit einer Prise Vorsicht ganz brauchbar
• Unser Unternehmen arbeitet nach klassischem XP-Stil. Wenn wir in einer Brownfield-App neue Features entwickeln, teilen wir die Arbeit in fast acht Sub-Agenten auf, etwa „red-test-writer“, „minimal-green-implementer“ und „refactorer“. Jetzt reicht es, Claude Code zu sagen: „Erstelle Feature X mit diesem TDD-Prozess“, und nach 30 Minuten kommt deutlich besserer Code mit 90 % Testabdeckung und in einem Zustand zurück, den man sofort akzeptieren kann. Das basiert zwar auf jahrelanger Erfahrung mit XP, Pair Programming und TDD, aber seit über einem Jahr stammen 95 % unseres Produktionscodes von KI, auch bei nichttrivial komplexen Features. Es gibt dabei praktisch kein Geheimwissen, und es läuft einfach gut. Für uns ist der Effekt wirklich enorm
• Hier gehen die Meinungen extrem auseinander. Wenn man nicht offenlegt, woran genau etwas gescheitert ist und für welche Aufgaben es verwendet wird, ist eine sinnvolle Diskussion unmöglich. Ohne konkrete Kategorien von Erfolgen und Misserfolgen bei LLMs ist das alles kaum mehr als Rauschen
  • In solchen Diskussionen müsste man Details nennen wie Sprache/Framework, Problemdomäne, SRE-Level, LLM (Modell/Version), agentisches Harness (Claude Code, Codex, Copilot usw.), Fehl- und Erfolgsszenarien sowie den Umgangsgrad mit LLMs. Dazu kommen Unterschiede wie: Arbeitet der Engineer seit zehn Jahren nur an einer Codebasis oder wechselt er zwischen vielen Projekten? Geht es um Greenfield-Entwicklung oder Wartung? Um innovative Forschung oder um CRUD? All diese Bedingungen können unterschiedlich sein
• Aus Sicht eines Wissenschaftlers muss man bei jedem Datensatz oft leicht unterschiedliche Boilerplate wiederholen, und Coding-Agenten lösen davon einen erheblichen Teil. Besonders absurd ist, dass Claude manchmal selbst dann ignoriert, wenn ich fünfmal in Großbuchstaben betone: „Erfinde auf keinen Fall Daten, benutze nicht np.random.“ In solchen Punkten ist das überraschend grotesk. Wenn es klappt, ist es fantastisch, aber wenn nicht, gibt es oft nicht einmal ein Fehlersignal. Aus Sicht des LLM-Marketings stelle ich mir manchmal auch einen Agenten hinter dem Coding-Agenten vor, so etwas wie einen „PIPA (Performance Improvement Plan Agent)“, der in Echtzeit überwacht, ob er ordentlich arbeitet. PIPA würde die Leistung des Coding-Agenten prüfen, damit HR oder Management KI-Mitarbeiter, also Agenten, steuern können. So könnte die Zukunft vielleicht aussehen
  • Wenn man sagt: „Denk nicht an einen Elefanten im rosa Tutu!“, dann denkt man doch gerade daran, oder? Als Wissenschaftler sollte man wissen, dass LLMs Negationen von ihrer Natur her schlecht verstehen. Sie lernen tokenbasiert, also bleibt selbst bei „NO ELEPHANTS“ das Wort „Elefant“ im Kontext. Das lenkt sie eher in genau diese Richtung. Positive Instruktionen funktionieren besser
  • Allein die Vorstellung von PIPA ist gruselig
• Entscheidend sind Prompts, die dem Modell helfen, den passenden Kontext selbst zu finden, etwa gute Fehlermeldungen. Wenn man Aufgaben sehr klein und konsistent aufteilt, kann man Ergebnisse aus Wiederholungen oder Zwischentests als Kontext für den nächsten Schritt weitergeben. Etwa 50 % der Probleme passen zu diesem Ansatz, und bei weiteren 50 % ist eine LLM-Schleife immer noch weniger lästig als klassische Automatisierung, aber bei der Hälfte davon lohnt sich der Aufwand nicht. Wenn es also diese magischen „12,5 %“ an Fällen gibt, ist ein stark eingeschränkter, also Constrained, Agentenansatz optimal
  • Es wäre aufschlussreich, genau diesen Prozess einmal live auf YouTube oder anderswo zu streamen, nicht als Tutorial, sondern als natürliches Live-Coding
• Vor fast 30 Jahren, als ich mit KI angefangen habe, wurde mir Folgendes gesagt: Wenn du den Begriff „intelligent agent“ hörst, dann stell dir einen „trainierbaren Ameisenstaat“ vor
  • Dazu würde ich gern mehr Details hören
• Für mich ist das größte Problem, dass die Leistung von KI-Tools je nach Aufgabe stark schwankt und schwer vorherzusagen ist, wo sie scheitern, sodass Zeit verlorengeht. Mit mehr Tool-Erfahrung wird man im Prompting sicher besser, aber es bleibt frustrierend. Gleichzeitig gibt es Überschneidungen zwischen dem Nutzen von Agenten und KI allgemein, etwa bei der automatischen Erzeugung von Boilerplate für neue Projekte. In solchen Fällen ist der „Agent Mode“ bequemer. Ich habe allerdings noch relativ wenig echte Praxiserfahrung
  • Je besser es funktioniert, desto höher werden die Erwartungen und desto breiter setzt man es ein; und wenn man dann an die Grenzen stößt, ist die Enttäuschung oft größer als am Anfang