Wie man mit Agenten programmiert

• Dieser Text ist der zweite Teil darüber, wie man bestehende Programmiererfahrung an die Welt der interaktiven Computer (LLMs, Agenten) anpasst
• Im ersten Teil, „Wie man mit LLMs programmiert“, wurde erklärt, wie man LLMs in bestehende Werkzeuge integriert und sie für Autovervollständigung oder als Suchersatz nutzt
• Diesmal werden die praktische Erfahrung und die Erkenntnisse rund um agentenbasiertes Programmieren geteilt, das etwas schwieriger, aber auch lohnender ist

Definition und Praxis von Agenten

• Im Kontext von LLMs (Large Language Models) ist es sinnvoll, den Begriff „Agent“ zu definieren
• Er wurde in der AI-Branche lange wie ein Modewort verwendet, hat sich aber erst in jüngster Zeit als tatsächlich nützliche Struktur etabliert
• Dabei wurde er oft mit Marketingrhetorik und Mystifizierung überlagert

• Aus Ingenieurssicht lässt sich das inzwischen klar und einfach definieren: Ein Agent ist 9 Zeilen Code, also eine for-Schleife mit einem LLM-Aufruf
• Innerhalb dieser Schleife kann das LLM Anweisungen ausführen, die Ergebnisse direkt prüfen und ohne menschliches Eingreifen wiederholt arbeiten
• Das mag simpel klingen, aber in dieser Form verbessert sich die Programmierfähigkeit im Vergleich zur Nutzung eines reinen LLMs sprunghaft

Der Unterschied zwischen Whiteboard-Programmierung und Agenten

• Angenommen, man steht vor einem Whiteboard und soll mit einem Marker in C eine Funktion schreiben, die die Gültigkeit eines UTF-8-Strings prüft
  • (Eine reale Interviewsituation des Autors und eine häufige Interviewaufgabe)
  • Erfolg oder Misserfolg hängen dabei von der Erfahrung als Programmierer ab und von der Fähigkeit, die Grenzen zu kaschieren, weil man keine externen Materialien nachschlagen darf
  • Man muss sich an die Regeln der UTF-8-Kodierung erinnern und aufpassen, die C-Syntax nicht mit anderen C-artigen Sprachen zu verwechseln (Name-Typ- versus Typ-Name-Reihenfolge usw.)
  • Im Alltag kann man Code jedoch mit Compiler-Feedback, Dokumentation, printfs und vielen anderen Mitteln prüfen und Fehler finden
• Ohne Agenten ein LLM Code schreiben zu lassen, ist ähnlich dazu, an einem Whiteboard ohne externe Hilfe Code zu schreiben
  • Es ist eine Aufgabe, bei der man vage Erinnerungen hervorholen, auf ineffiziente Weise mit Syntax kämpfen und Fehler vermeiden muss, bei denen man sich falsche Interfaces ausdenkt
  • Dass ein LLM überhaupt vollständig neue Programme erzeugen kann, ist technisch beeindruckend, aber ein virtuelles Whiteboard mit angeschlossener GPU steigert die tatsächliche Produktivität beim Programmieren nicht dramatisch
• Aber was, wenn man dem LLM mehr als nur ein virtuelles Whiteboard gibt?
  • Was, wenn es den Compiler aufrufen, Kompilierfehler prüfen und sich selbst korrigieren kann?
  • Wenn es mit grep und cat bestehende Dateien lesen, mehrere Dateien (einschließlich Unit-Tests) patchen und Tests wiederholt ausführen kann?
• Ein Agent ist genau so ein feedbackbasiertes LLM.

Agent = LLM, das in einer Feedback-Umgebung arbeitet

• Ein LLM, das wie ein Mensch in einer Feedback-Umgebung gut arbeitet, kann schon mit einigen vertrauten Werkzeugen echte Programmierfähigkeit zeigen
  • bash(cmd): Terminalbefehle ausführen (find, cat, grep usw.)
  • patch(hunks): Dateien patchen, Codeänderungen anwenden
  • todo(tasks): Aufgabenliste verwalten
  • web_nav(url), web_eval(script), web_logs(), web_screenshot() usw.: Webnavigation, Auswertung, Logs, Screenshots usw.
  • keyword_search(keywords): Stichwortsuche
  • codereview(): Code Review
• Mit dem bash-Werkzeug wird die Codebase effizient erkundet, inklusive Automatisierung von Versionsverwaltung wie git add/commit
• Anders als ein LLM, das ohne solche Werkzeuge nur Code generiert, hat ein Agent die folgenden entscheidenden Vorteile
  • Deutlich höhere Genauigkeit bei der API-Nutzung (Dokumentation suchen und direkt in den Kontext einfließen lassen)
  • Compiler-Feedback reduziert Syntaxfehler und Missverständnisse bei Interfaces
  • Stärkere Fähigkeit bei Abhängigkeits-/Versionsverwaltung (Eigenschaften bestimmter Versionen erkennbar)
  • Fehlererkennung durch fehlschlagende Tests und bessere Gewohnheiten beim Schreiben von Testcode
  • Verarbeitung von Codebases über die Grenzen des Kontextfensters hinaus (nur die benötigten Teile selektiv lesen)
  • Direktes Experimentieren mit Ausführungsergebnissen: Code ausführen, Feedback über Browser-Screenshots, CSS automatisch anpassen, Fehler über Server-Logs verfolgen und Tests ergänzen
• Es gibt auch Nachteile
  • Schon eine Anfrage in einem Satz kann Zehntausende Zwischentokens erzeugen (Tool-Aufrufe, Websuche, wiederholte Tests usw.), und die Bearbeitung dauert mehrere Minuten oder länger
  • Auch API-Kosten fallen an, dürften aber mit fortschreitender Hardwareentwicklung allmählich verschwinden
• Letztlich übernimmt CPU/GPU die Zwischenarbeit, spart Entwicklerzeit und ermöglicht es, mehr der Programme fertigzustellen, die man schreiben wollte
• In der Praxis ist es leicht, Agenten in ein Projekt einzuführen, ihnen kleinere Aufgaben zu geben und die Ergebnisse zu prüfen

Beispiel: Entwicklung der Github-App-Authentifizierung

• Ein reales Beispiel, in dem mithilfe eines Agenten der Github-App-Authentifizierungsfluss von sketch.dev implementiert wurde
  • Mit nur 3–4 Feedbackrunden wurde der komplette Authentifizierungsfluss schnell fertiggestellt
  • Wenn Fehler oder Anforderungen entdeckt wurden, reichte ein kurzer Satz als Erklärung, und der Agent verbesserte sofort Code und Verhalten
  • Wiederholte, monotone API-Integration, Build-System-/Paketverwaltung-/Bibliotheks-Setup und ähnliche praktische „Nebentätigkeiten“ wurden minimiert, was stark half, das Produktivitätsmomentum aufrechtzuerhalten
• Als anfängliche Anforderung wurde vorgegeben: „Keine Speicherung benutzerspezifischer Tokens, nur globale Authentifizierungsinformationen der App verwenden“, und der Agent setzte das entsprechend um
  • Dadurch entstand jedoch eine schwerwiegende Sicherheitslücke (jeder konnte alle Repositories sehen)
  • Nach einem einzeiligen Feedback zur Problembeschreibung führte der Agent sofort benutzerspezifische Berechtigungsprüfungen ein und erzeugte einen korrigierten Commit
• Danach wurde ein Performance-Problem sichtbar
  • Durch eine Struktur wie die folgende wurde für jede Kombination aus Benutzer und Repository ein API-Aufruf ausgelöst, was zu Skalierbarkeitsproblemen führte

    for install := range allAppInstallations {  
    	for r := range install.Repositories() {  
    		if r.IsCollaborator(user) {  
    			// add to available repositories  
    		}  
    	}  
    }  
    

  • Es stellte sich heraus, dass die eigentliche Ursache des Problems die eigene Anforderung „keine benutzerspezifischen Tokens speichern“ war
  • Als die Anforderung geändert wurde (Speicherung benutzerspezifischer Tokens erlaubt), entwarf der Agent die Lösung mit einer effizienteren API-Aufrufstruktur neu
• Tatsächlich war die Anzahl der Wörter, die nötig waren, um diesen Prozess schriftlich zu erklären, größer als die Gesamtzahl der Wörter, die in Sketch eingegeben wurden, um den Authentifizierungscode zu erhalten
• Kurz gesagt: Agenten sind heute noch nicht auf einem Niveau, das Entwickler ersetzt, aber sie helfen dabei, wiederholte Arbeiten, die traditionell mehrere Tage dauerten, an einem einzigen Tag zu erledigen
• Die Automatisierung geht so weit, dass Entwickler die Arbeit weiterlaufen lassen können, während sie „das Zimmer ihres Kindes aufräumen“

Beispiel: Anwenden JSON-basierter SQL-Regeln

• Eine Aufgabe, die der Agent häufig bearbeitet, war die Anwendung eines ungewöhnlichen SQL-Stils, der bei Tailscale gelernt wurde
  • Jede Tabelle hat nur eine echte Spalte (JSON-Daten), die übrigen Spalten werden als aus dem JSON abgeleitete generated columns behandelt
  • Beispiel für eine Tabellenstruktur:

    CREATE TABLE IF NOT EXISTS Cookie (  
      Cookie   TEXT    NOT NULL AS (Data->>'cookie')  STORED UNIQUE, -- PK  
      UserID   INTEGER NOT NULL AS (Data->>'user_id') STORED REFERENCES User (UserID),  
      Created  INTEGER NOT NULL AS (unixepoch(Data->>'created')) STORED,  
      LastUsed INTEGER AS (unixepoch(Data->>'last_used')) CHECK (LastUsed>0),  
      Data     JSONB   NOT NULL  
    );  
    

  • Diese Methode funktioniert gewissermaßen als poor man’s ORM, erleichtert Schemaerweiterungen und hilft mit SQL-Constraints bei der Qualitätsprüfung der JSON-Daten
  • Nachteil ist, dass pro Zeile mehr Daten gespeichert werden und alle INSERT/UPDATE-Operationen auf JSON-Ebene erfolgen müssen
• Allerdings hielt sich der Agent nicht immer konsistent an diesen Stil
  • Beim Erstellen neuer Tabellen folgte er ihm meist gut, aber bei Ausnahmen geriet er ins Schleudern oder änderte den Stil eigenmächtig
• Eine einfache Lösung: Am Anfang der SQL-Schemadatei eine Erklärung in drei Sätzen hinzufügen
  • Einen Schlüsselsatz ergänzen wie: „Jede Tabelle hat nur eine echte Data-JSON-Spalte, alle anderen Spalten werden daraus abgeleitet“
  • Bei Tabellen, die dieser Regel nicht folgen, per separatem Kommentar ausdrücklich festhalten, dass es sich um eine Ausnahme handelt
  • Danach verbesserte sich das Verhalten des Agenten spürbar
• Interessant ist, dass menschliche Ingenieure solche Erklärungen und Kommentare meist ignorieren oder ihren Nutzen gering einschätzen,
  • während LLM-basierte Agenten Kommentare und Erklärungen aktiv in die Codeerstellung einbeziehen
  • Schon gute Erklärungen allein verbessern die Qualität der Codegenerierung deutlich

Modell von „Vermögenswert“- und „Schulden“-Code

• Eine häufige Kritik an LLM-basierten Tools zur Codegenerierung lautet, dass die Codegenerierung selbst nur einen winzigen Teil der gesamten Softwarekosten ausmacht
  • Tatsächlich geht der Großteil der Zeit dafür drauf, Abhängigkeiten, Verflechtungen und komplexe Interfaces im bestehenden Code zu verwalten
  • Bei großen, alten Produkten mit vielen Nutzern dominieren die Wartungskosten
  • In solchen Umgebungen wirkt eine Anfrage wie „schreib mir Bubble Sort in Fortran“ wie ein Spielzeug oder eine lästige Störung
  • Es gibt Diskussionen, die das mit den Finanzbegriffen „Vermögenswerte/Schulden“ vergleichen, aber auch das passt nicht perfekt
• Aber nicht jede Softwareentwicklung betrifft nur solche großen, langfristigen Projekte
  • Die meisten Programme haben nur wenige Nutzer oder sind kurzlebige Projekte
  • Man sollte Erfahrungen aus der Wartung großer Systeme nicht auf das Wesen der gesamten Branche verallgemeinern
• Der Wert von Agenten beschränkt sich nicht auf Codegenerierung
  • Agenten kombinieren verschiedene Werkzeuge und LLMs, um Code zu lesen, Dateien zu bearbeiten sowie Änderungen wie Löschen/Modifizieren von Code zu automatisieren
  • Nicht nur das Hinzufügen von Code, sondern auch das Löschen und Refactoring wird ganz natürlich ausgeführt
• Letztlich ist das Ziel von Ingenieuren Veränderung (change)
  • Im Veränderungsprozess entsteht zwar zusätzliche Arbeit, weil der Verantwortliche die Änderungen verstehen muss, aber Agenten zeigen bereits die Fähigkeit, auch in mittelgroßen Projekten schrittweise Veränderungen herbeizuführen
  • Selbst wenn sie heute noch nicht ausreichen, entwickeln sich Agenten schnell in die richtige Richtung
• Zusätzlich gibt es die Ansicht, dass komplexe Sprachen oder Build-Systeme als Eintrittsbarriere für Projekte dienen
  • Es wird argumentiert, dass Werkzeuge, mit denen man leichter Code schreiben kann (LLMs, Type Safety, Garbage Collection, Package Management, Agenten usw.), die Eintrittshürde senken und damit die Qualität leiden könnte
  • Wenn das Ziel darin besteht, Veränderungen zu verlangsamen oder stärker zu kontrollieren, dann passen Automatisierungswerkzeuge wie Agenten nicht dazu

Warum gerade jetzt Agenten?

• Anders als komplexe AI-Prinzipien wie Transformer ist es intuitiv klar, einem LLM eine Feedback-Schleife hinzuzufügen
  • Aus Sicht von Entwicklertools fühlt sich das wie eine natürliche Entwicklungsrichtung an
  • Tatsächlich war die erste Version von sketch.dev vor einem Jahr auch nur ein LLM mit angeschlossenem Go-Werkzeug, aber im Vergleich zum heute genutzten Agenten besteht ein großer Unterschied in der Praxistauglichkeit
  • Auch im ML-Bereich ist Reinforcement Learning (feedbackbasiertes Lernen) seit über 50 Jahren ein Grundprinzip
• Das tatsächliche Aufkommen von Agenten hängt direkt mit der Weiterentwicklung von LLMs zusammen
  • 2023 waren LLMs bei Tool-Aufrufen noch schwach, weshalb ihre Rolle als Agenten begrenzt war
  • 2025 sind LLMs für Tool-Aufrufe und iterative Arbeit optimiert, sodass eine praktische Nutzung als Agent möglich wird
  • Frontier-Modelle (modernste kommerzielle Modelle) liegen bei der Tool-Nutzung deutlich vor Open Models
  • Es wird erwartet, dass Open Models innerhalb der nächsten 6 Monate aufholen
  • Nützliche iterative Tool-Aufrufe sind die größte Veränderung der neuesten LLMs

Der weitere Weg: Container und parallele Ausführung

• Das Feld der LLM-Agenten befindet sich noch in einer frühen und sich schnell verändernden Phase, die von den meisten Ingenieuren noch nicht praktisch übernommen wurde
• Derzeit werden Agenten hauptsächlich so eingesetzt, dass sie in IDEs oder lokalen Repositories arbeiten
  • Der Einstieg ist leicht, etwa mit einem VSCode-Fork oder durch Installation eines Kommandozeilenwerkzeugs
  • Aber es gibt zwei wichtige Grenzen
    • Erstens fehlende Sicherheitsmechanismen: Risiko der Offenlegung sensibler Informationen wie echte Produktionszugangsdaten, die auf dem realen Computer gespeichert sind
      • Führt ein Agent unbeabsichtigt Befehle wie Deployment-Skripte aus, kann das zu schweren Sicherheitsvorfällen führen
      • Auch wenn für jede Befehlsausführung eine manuelle Bestätigung verlangt wird, bleibt das Risiko einer versehentlichen Preisgabe sensibler Daten bestehen
    • Zweitens Grenzen bei paralleler Ausführung und Automatisierung: Da jeder Entwickler Agenten nur einzeln in seiner eigenen Umgebung ausführen muss,
      • dauert ein einzelner Agentendurchlauf jeweils mehrere Minuten, sodass mehrere Aufgaben gleichzeitig schwer und ineffizient zu bearbeiten sind
• sketch.dev versucht, diese Grenzen mit einer Container-Umgebung zu lösen
  • Für jede Aufgabe wird ein isolierter Entwicklungscontainer erstellt, der Source Code wird kopiert, und nur Dinge wie git commits werden nach außen exportiert
  • Dadurch können mehrere Agenten gleichzeitig laufen, und auch andere Agentensysteme erkunden diesen Ansatz
• Praxisbeispiel: Parallel zur Github-Authentifizierungsaufgabe wurde die Verbesserung der Formular-UI in einer separaten Agentensitzung bearbeitet
  • Ohne Eintrag in einen separaten Issue-Tracker konnte Feedback zur Verbesserung des Formulardesigns mit einem Screenshot und einer kurzen einzeiligen Anfrage verarbeitet werden
  • Schon mit 30 Sekunden Aufwand entsteht die Erfahrung, Ergebnisse oberhalb eines gewissen Qualitätsniveaus zu erhalten
• Ergebnis von UX-Experimenten der letzten 6 Monate:
  • Für agentenbasierte Entwicklung sind Container (isolierte Ausführungsumgebungen) derzeit die praktikabelste Lösung

Was wird aus der IDE?

• In einer agentenbasierten Entwicklungsumgebung ist die Rolle der IDE (Integrated Development Environment) weiterhin eine offene Frage
  • Ein realer Workflow könnte darin bestehen, Anweisungen an den Agenten zu geben, die Arbeit in einer Container-Umgebung ausführen zu lassen, Änderungen als Diff zu prüfen und dann als Branch/PR zu pushen
• In der Praxis brauchen die meisten vom Agenten erzeugten Commits ein gewisses Maß an menschlicher Nachbearbeitung (Cleanup)
  • Anfangs müssen fast alle Commits manuell korrigiert werden, aber mit wachsender Erfahrung beim Schreiben von Prompts nimmt der Korrekturaufwand allmählich ab
  • Die Korrekturen reichen von einfachen Dingen wie dem Bearbeiten von Kommentaren oder dem Umbenennen von Variablen bis hin zu komplexerem Refactoring
  • Entscheidend ist, wie sich solche Korrekturen in einer Container-Umgebung effizient erledigen lassen
• Workflows, mit denen etwa bei sketch.dev experimentiert wird
  • Bereitstellung einer Schnittstelle, in der sich die Diff-Ansicht direkt bearbeiten lässt
    • Wenn man auf der rechten Seite der Diff-Ansicht von Sketch den Code direkt bearbeitet, wird das in den betreffenden Commit übernommen und sofort gepusht
    • Das ist für kleine einzeilige Korrekturen sehr effizient
  • Bereitstellung von SSH-Zugriff auf den Container, sodass
    • man direkt in eine Shell wechseln oder den Code über ein Web-Terminal bearbeiten kann
    • er sich über eine vscode://-URL in einer traditionellen IDE öffnen lässt
  • Code-Review-artige Kommentare direkt im Diff hinterlassen und als Feedback an den Agenten weitergeben
    • So kann man bestehende Code-Review-Erfahrung nutzen und notwendige Erklärungen/Anforderungen mit minimalem Input übermitteln
• Gesamtbewertung
  • Die Container-Umgebung integriert Codegenerierung, Korrektur, Verifikation und Review und ermöglicht damit echte agentenbasierte Entwicklung, die über bloßes Codeschreiben hinausgeht
  • Früher wollte man nicht in Containern entwickeln,
    aber die Erfahrung, von Agenten erzeugte Diffs in Containern aufzuräumen und zu korrigieren, ist sehr interessant und produktiv

Schlusswort

• Der Prozess, LLM-basierte Technologien zu lernen und damit zu experimentieren, war eine Lektion in Demut
  • Frühere Veränderungen wie Multi-Core, SSD-Einführung oder der Ausbau von Netzwerken fühlten sich schon erfreulich an, wenn sich das Wesen des Programmierens verschob,
    aber LLMs, insbesondere Agenten, gestalten den „Prozess selbst“ des Codierens vollständig neu
  • Anders als Veränderungen, die die Wahl von Algorithmen, Sprachen oder Bibliotheken beeinflussten,
    zwingen Agenten dazu, alle Annahmen über die Arbeitsweise selbst grundlegend zu überdenken
  • Mitunter wirkt die Veränderung so groß, dass man denkt: „Vielleicht wäre es besser, Programmieren völlig ohne Vorwissen von Grund auf neu zu lernen“
  • Und dieser Wandel ist immer noch im Gange
• Die Art und Weise, wie wir das heute erleben, unterscheidet sich völlig von vor 6 Monaten und ist noch nicht stabilisiert
  • Standards der Entwicklungskultur wie Teamarbeit und Reviews dürften sich bald stark verändern
  • Zum Beispiel lösen rein formalisierte Code Reviews reale Probleme nicht mehr wirklich
    • Es ist an der Zeit, den Code-Review-Prozess selbst neu zu erfinden
  • Auch IDEs müssen entgegen ihrem bisherigen Integrationsanspruch grundlegend neu gedacht werden
  • Die Branche nimmt diesen Wandel zwar wahr, aber ein agentenzentrierter Ansatz steht noch ganz am Anfang
  • Weitere große Veränderungen sind bereits absehbar,
    und Neugier und Demut sind die einzigen Wege, gut durch diesen Wandel zu kommen
  • Vielleicht ist es sogar besser, sich gerade jetzt von Tech-Internetforen fernzuhalten
    und solche Diskussionen und Zusammenfassungen lieber Agenten zu überlassen

[GN⁺]

Hacker-News-Kommentare

• Da ich meistens nur für meine eigenen Tools code, sehe ich nicht besonders viel Vorteil darin, dass jemand oder etwas anderes statt mir den Code schreibt und ich ihn danach lesen, verstehen und reparieren muss. Natürlich ist es ziemlich nützlich und spart Zeit, wenn ich ein LLM bitte, in der API-Dokumentation genau die Stelle zu finden, die ich brauche. Unabhängig davon, ob sich die zukünftige Leistung von LLMs verbessert, mag ich es einfach nicht besonders, fremden Code zu lesen.

  • Für mich gibt es Fälle, in denen LLMs hilfreich sind. In stark formalisiertem Code können sie zum Beispiel Makros oder Codegeneratoren überflüssig machen. Sie sind zwar langsam und können nicht wie Makros in einem Schritt alles aktualisieren, aber bei Code mit sich wiederholenden, leicht unterschiedlichen Strukturen sind LLMs oft nützlicher als Makros. Auch wenn ich eine API benutze, mit der ich vertraut bin, deren Aufrufe ich aber nicht auswendig kenne, kann ich direkt weiterarbeiten, statt erst zu googeln und die Doku zu durchforsten. Da ich typisierte Sprachen verwende, ist es kein großes Problem, wenn das LLM Unsinn schreibt, weil der Type-Checker oder die Tests das auffangen. Und wenn Änderungen über mehr als zehn Dateien verteilt nötig sind, spart es enorm Zeit, wenn ein Änderungsplan in Markdown erstellt wird. Schließlich neige ich bei Müdigkeit dazu, Stil- oder Naming-Regeln zu übergehen, während ein LLM den bestehenden Stil eines Projekts ziemlich gut beibehält.
  • In letzter Zeit gefällt mir diese Arbeitsweise immer besser. Zuerst plane ich das gesamte Coding-Design, dann erkläre ich dem LLM die konkreten Schritte, und während ich den Code lese, verstehe, korrigiere und den nächsten Schritt plane, arbeitet das LLM schon am nächsten Abschnitt. Es ist also ein Workflow, in dem ich und das LLM parallel arbeiten. Das ist wie ein Küchenchef im Restaurant, der, sobald eine Bestellung eingeht, sofort alle Kochschritte durchplant und nicht einfach darauf wartet, dass das Steak fertig brät, sondern parallel anderes vorbereitet. Das LLM ist eher wie ein Kochwerkzeug, etwa ein Ofen oder eine Küchenmaschine. Käse kann man zum Beispiel von Hand reiben, aber wenn man ihn in die Küchenmaschine gibt, spart man ein paar Minuten. Profiköche steigern ihre Effizienz durch Multitasking mit verschiedensten Werkzeugen; vielleicht entwickelt sich auch das Programmieren weg von einer rein zeilenweisen, schrittweisen Arbeit hin zu einer Multitasking-Struktur.
  • Auf die Frage, welchen Vorteil es habe, die Verantwortung fürs Schreiben des Codes an etwas anderes abzugeben, um ihn am Ende doch wieder selbst lesen, verstehen und korrigieren zu müssen, würde ich das Wort „Reibung“ verwenden. Vielen Menschen fällt es schwer, etwas Neues zu beginnen, ähnlich wie bei einer Schreibblockade. Wenn schon jemand anders eine Lösung aufgebaut hat, senkt es die Einstiegshürde deutlich, sie an die eigene Arbeitsweise anzupassen und zu modularisieren. Bei mir und meinen Kollegen empfinden viele schon das Aufsetzen eines Projekts von null an, also Toolchain-Konfiguration und Bootstrap, als erhebliche Last. Ein LLM kann mit genug Kontext und Ressourcen die gesamte Codebasis schnell durchsuchen und zum Beispiel erkennen: „Es gibt in diesem Code schon zwei Audit-Mechanismen, also lasst uns die gemeinsamen Teile extrahieren.“ Es kann sogar Dinge automatisch finden, die ich selbst übersehen hätte.
  • In einer Codebasis, an der ich arbeite, gibt es viele Aufgaben, bei denen man in mehreren Dateien wiederholt kleine Änderungen machen muss. Das ist weniger kreativ oder herausfordernd als einfach repetitive Arbeit: viele Dateien öffnen und anpassen. Früher hat so etwas drei bis vier Stunden gedauert; wenn ich die Aufgabe jetzt einem AI-Agenten erkläre, erledigt er 99 % davon selbst, und es dauert nur noch drei bis vier Minuten.
  • Manche Menschen sind der Typ, der ohne Werkzeuge praktisch nichts hinbekommt. Genau solche Leute werden zu Early Adopters und Power-Usern und verbreiten neue Entdeckungen. Der Wert von GitHub lag darin, durchschnittlichen Entwicklern eine Umgebung zu geben, in der sie mit PRs, Reviews, grünen Squares, To-do-Listen usw. produktiv wirken konnten. LLMs tun etwas Ähnliches: Sie ermöglichen es durchschnittlichen Entwicklern, mit eher unwichtigen Tools und Agenten produktiv auszusehen, und genau deshalb mögen Manager sie.

• Ich stimme dem Autor völlig zu, was den Punkt betrifft, dass Code-Reviews oft schwach sind und kaum richtig funktionieren. In einer Zeit, in der Agenten Code schreiben, liegt der eigentliche Flaschenhals nicht beim Schreiben, sondern beim Lesen von Code. Wenn Menschen Reviews nur oberflächlich machen oder sie bloß als Ventil für persönliche Vorlieben nutzen, können Agenten leicht gravierende Sicherheits- oder Performance-Probleme einbauen. Ehrlich gesagt sieht man die wirklichen Probleme oft nicht allein durchs Lesen des Codes; dafür braucht es Handarbeit wie Debugging oder das Prüfen von Annahmen.

  • Ich frage mich, wie Agenten-/AI-Code das Problem der „schlechten Reviews“ eigentlich lösen soll. Menschen haben schon auf Code-Reviews selbst keine Lust und finden sie langweilig. Ich mache mir Sorgen, dass wir den interessanten Teil, also das „Code schreiben“, an AI abgeben und stattdessen in endlosem Code-Lesen und Prüfen landen.
  • Der größte Mangel am aktuellen Markt ist aus meiner Sicht die Frage, wie man von LLMs erzeugten Code, Diffs und ganze Codebasen effizient liest, ordentlich reviewt und wirklich versteht. Wenn in einem Projekt nur wenige Menschen übrig bleiben, frage ich mich, ob diese den Code tatsächlich lesen oder einfach durchwinken.
  • Der Kern von Agenten ist, dass AI den Code schreiben und sogar Sicherheits- und Performance-Feedback bekommen kann, wenn die Testabdeckung ausreichend ist. Und dieselbe AI hilft auch beim Schreiben der Tests.

• Endlich mal ein realistischer Text über LLMs. Der Begriff „Agent“ nervt mich etwas, weil er im Grunde nur ein Name für eine for-Schleife ist, die rekursiv LLMs aufruft. Aber Namensgebung ist in dieser Branche im Durchschnitt ohnehin nicht besonders gut, also akzeptiere ich es einfach.

  • Ich sehe die Definition von „Agent“ etwas anders als der Autor. Eigentlich ist es eine Struktur, in der ein LLM in einer Schleife wiederholt Tools und Ressourcen aufruft. Das ist nur ein feiner Unterschied, aber es geht darum, wo man die eigentliche Handlungsinstanz verortet.
  • Mir gefiel die Formulierung: „Ein Agent ist ein Tool in einer Schleife.“ Ich meine, Simon habe das so gesagt.
  • Ich habe leichte Einwände gegen die Agenten-Definition des OP. Es geht nicht einfach nur darum, dass ein LLM in einer Schleife läuft, sondern darum, dass sein Verhalten durch andere logische Komponenten eingeschränkt oder gelenkt wird. Ein Teil davon ist deterministisch, ein anderer Teil basiert auf ML, einschließlich LLMs. Zusätzlicher Nutzen entsteht also dadurch, dass man das LLM in einem entworfenen System auf die eine oder andere Weise zu Planung zwingt oder nach Code-Edits automatisch Tests baut und ausführt. Die Erklärung „Ein Agent nimmt selbstständig Input auf und handelt“ ist nicht völlig falsch, aber wesentlicher ist eigentlich die Absicht, dass mehrere Komponenten das Verhalten des LLMs laufend überwachen und steuern.
  • Die Bezeichnung „Agent“ finde ich an sich in Ordnung, weil Menschen intuitiv sofort etwas damit anfangen können, aber als alternative Namen käme vielleicht auch so etwas wie LoopGPT infrage.

• In Bezug auf den Satz „Wir sind uns einig, dass Container in der Programmierung nützlich und notwendig sind“ erklärt das, warum Docker-Erfinder Solomon Hykes vor Kurzem das Open-Source-Projekt Container Use veröffentlicht hat: damit Agenten sicher parallel laufen können. Einige Plattformen wie Sketch bringen isolierte lokale Entwicklungsumgebungen mit, andere Coding-Agenten aber nicht. Als Zusatzempfehlung gibt es auch dieses YouTube-Video.

• Agentische Schleifen, Gehirne in der Maschine, im Grunde ein Ersatz für Rule Engines. Es gibt noch eigene Nachteile, aber ich finde, dass viele kluge Leute den Kern gut getroffen haben: „Agenten verknüpfen Tools, prompten sie auf Nutzeranfrage, lassen sie einfach laufen und iterieren weiter, und auch die Prompts selbst ändern sich je nach Kontext dynamisch.“ Ohne menschliche Interaktion oder Problemlösungsweisen unbedingt nachzuahmen, ist das bereits sehr nützlich für Orchestrierung, mehrstufige Abläufe und für die Ersetzung oder Automatisierung vager Tasks. Früher musste man diese Mehrdeutigkeit direkt in Code ausdrücken; vielleicht fällt das jetzt weg. Im Produktiveinsatz bleibt die Sorge, Dinge ohne Dry Run auszuführen, aber ich denke, dass sich Tools und Services selbst weiterentwickeln werden. Wenn mehr als hundert ähnliche Services über konsistente Interfaces mit der Außenwelt verbunden werden, z. B. SMS, Mail, Wetter oder soziale Netzwerke, könnten deutlich mächtigere Assistenten oder noch mehr daraus entstehen.

  • Es gibt ein interessantes Toy-Projekt, das Agenten mit Kalender, Wetter und anderen Diensten verbindet und daraus ein Game-Interface macht: Link
  • Wenn die Abstraktion über alle verwendeten Tools hinweg vereinheitlicht wird, könnte das viel leistungsfähiger werden als bestehende Assistenten, aber man muss dann auch mit enorm vielen Ausfällen und Fehlermöglichkeiten leben. Themen wie Reliability Engineering, Qualitätssicherung, Rechteverwaltung, Sicherheit und Datenschutz werden deshalb immer wichtiger. Vielleicht ist genau dieses Risikomanagement auch der Grund, warum Apple bisher keinen wirklich modernen Sprachassistenten veröffentlicht hat, der die Grenzen von Siri hinter sich lässt.

• Code zu lesen war immer genauso wichtig wie Code zu schreiben, aber jetzt wird es immer wichtiger. Das ist mein Albtraum. Code zu schreiben macht manchmal Spaß, Code zu lesen ist immer Arbeit.

  • Trotzdem könnte der „Spaß am Reparieren“ erhalten bleiben oder sogar größer werden.

• Ich frage mich, wie viele Menschen, die Agenten verwenden, tatsächlich „Programmierung“ mögen, also das Nachdenken über Problemlösungen und die Freude daran, sie in Code auszudrücken. Bei vielen Agenten-Workflows heute scheint genau dieser Prozess zu verschwinden, und stattdessen beschreibt man Anforderungen nur noch in natürlicher Sprache und hofft, dass das LLM keine Bugs einbaut.

  • Ich selbst programmiere gern, und als ein LLM mir einmal auf Anhieb einen Parser erzeugt hat, der mir eigentlich Spaß gemacht hätte, fühlte sich das fast ein wenig leer an. Andererseits konnte ich mich statt mit einem zeitfressenden Parser auf größere Ziele konzentrieren. Beeindruckend fand ich, dass ich nur die gewünschten Typen- und Funktionssignaturen entwerfen musste und das LLM die Details ausfüllte, sodass ich sofort zum nächsten Schritt übergehen konnte. Früher waren selbst globale Änderungen, bei denen man dachte „Wäre schön zu reparieren, aber viel zu lästig“, eine große Belastung. Jetzt hilft das LLM beim Feinschliff des Codes, beim Erzeugen von Tests, beim Synchronisieren des README und sogar mit Refactoring-Ideen, sodass der Fertigstellungsgrad und auch mein Ehrgeiz im Projekt eher steigen. Mit der richtigen Einstellung kann das für Menschen, die gern Software bauen, geradezu paradiesisch sein.
  • Umgekehrt habe ich bei Problemen, die schon tausendfach gelöst wurden, wenig Lust, sie selbst noch einmal zu implementieren. Dann benutze ich eben ein Dictionary, statt eine Hashtabelle neu zu schreiben. Wenn ich sagen könnte „Baue mir diesen Sprachcompiler“ oder „Lös das mit DFS“ und das Ergebnis käme perfekt zurück, würde das für mich den Spaß an der Programmierung nicht zwingend verringern. Natürliche Sprache hat zwar die Grenze, dass sie auf komplexem Niveau schnell ungenau wird oder Widersprüche erzeugt, aber unabhängig davon empfiehlt ohnehin niemand, LLMs gedankenlos zu verwenden. Die Verantwortung für das Ergebnis bleibt am Ende bei mir.
  • Als Beleg dafür, dass natürliche Sprache fürs Programmieren ungeeignet ist, verweise ich auf EWD667. Tatsächlich sind LLMs für Fragen und Antworten im Stack-Overflow-Stil nützlich, aber wenn die Datenbasis von SO künftig schrumpft, könnte selbst das an Grenzen stoßen.
  • Ich sehe das anders. Viel von dem, was LLMs tun, ist repetitive und langweilige Implementierungsarbeit. Die spannenden Teile behalte ich weiterhin für mich: Projektarchitektur oder kreative und schwierige Abschnitte, die auch für LLMs schwer sind. In einem Jahr mag das schon wieder anders aussehen, aber vorerst bin ich zufrieden, dass ich mich nur auf die Teile konzentrieren kann, bei denen wirklich nachgedacht werden muss.
  • Hier ist der Autor selbst: Ich mag sowohl Programmierung als auch Agenten.

• Es gibt ein paar Bereiche, in denen ich AI beim Coden gern verwende (wirklich von mir geschrieben!):

  • CSS: Ich habe CSS auf praktisch jeder Website gehasst, aber AI merkt sich all die komplexen CSS-Tricks und verkürzt dadurch die Arbeitszeit. Selbst auf komplizierten WordPress-Seiten kann man so nach ein paar Versuchen schnell ein bestimmtes div zentrieren.
  • Unit-Tests: Wenn die im Modell eingebauten Codedaten nicht veraltet sind, kann das Generieren von Tests durchaus angenehm sein.
  • Commit-Zusammenfassungen: Für einen ersten Entwurf absolut brauchbar.
  • Sehr kleine Aufgaben auf Erstsemester-Niveau lassen sich ebenfalls schnell erledigen.
  • Interessanterweise hatte ich selbst eher den Eindruck, dass AI bei CSS nicht besonders gut ist und deshalb wenig bringt. Trotzdem kann ich sehr gut nachvollziehen, wie wertvoll es ist, ungeliebte Aufgaben abzugeben. Bei mir wäre das zum Beispiel das Schreiben von Ticket-Beschreibungen; darin ist AI deutlich besser als ich.
  • Falls ich dich missverstanden habe, sorry, aber wenn du mit aktuellen CSS-Trends nicht vertraut bist: CSS ist heute deutlich weniger komplex und leichter zu pflegen als früher. Es kann sich also lohnen, ein paar Stunden in modernes CSS zu investieren. Trotzdem nutze auch ich AI oft fürs Styling.

• Den Teil über „Vermögenswerte“ und „Schulden“ fand ich interessant, stimme aber nicht zu. Viele Programme starten für einen kleinen Nutzerkreis und wachsen später unerwartet zu großen Projekten heran. Ich habe in der Vergangenheit viel zu oft erlebt, dass schnell zusammengeschriebener wissenschaftlicher Einweg-Code irgendwann unbeabsichtigt über lange Zeit und in viel größerem Umfang weiterverwendet wurde. Deshalb schreibe ich meinen Code mit deutlich längerer Lebensdauer und größerer Reichweite im Hinterkopf, auch aus Rücksicht auf mein zukünftiges Ich und auf andere. Wer schon erlebt hat, wie das persönliche Side-Project eines Kollegen vom Manager plötzlich zum Abteilungsprojekt hochgestuft wurde, wird dieses Problem nachvollziehen können.

  • Trotzdem bleibt die Frage: „Was ist die Alternative?“ Menschen können schlecht vorhersagen, was breite Akzeptanz findet. Häufig verschwinden gerade die mit viel Sorgfalt gebauten Projekte in der Bedeutungslosigkeit, während die schnell und schlampig gebauten erfolgreich werden; darauf wirkt in der Realität ein Evolutionsdruck. Dazu passt der klassische Text „worse is better“ (Link).

• Ich glaube, der eigentliche Killer-Use-Case von LLMs könnte nicht das Schreiben oder Entwerfen von Code sein, sondern das Reviewen von Code. Schon heute ist Code-Review in vielen Bereichen kaputt, und künftig dürften LLMs vor allem bei Sicherheit, Undefined Behavior, Fehlgebrauch von Funktionen oder beim Gegenprüfen von Compiler-Warnungen sehr nützlich werden. Ich selbst benutze LLMs eher wie eine Suchmaschine für Fehlerdiagnose und Debugging. Die Trefferquote liegt vielleicht bei 50 %, und damit bin ich schon ziemlich zufrieden.

  • Wenn ein Problem im Web schon ausführlich diskutiert wurde, ist ChatGPT beim Debugging bereits ziemlich stark. Es fasst das Wissen aus Stack Overflow zusammen und integriert es, was viel Zeit spart, die man sonst mit der Suche nach einzelnen Fällen verbringt. Allerdings enthalten LLM-Antworten immer noch Halluzinationen, also Rauschen. Wenn man ganzen Code reviewen lässt, kann das Modell Fehlerarten oder problematische Funktionen und Aufrufe zwar oft gut finden, produziert aber zwangsläufig auch viele False Positives. Ich frage mich, ob jemand LLMs bereits sinnvoll für automatisierte Code-Reviews einsetzt.
  • Wenn man wiederholt darum bittet, „diesen Code zu reviewen“, kommt es vor, dass der Chatbot erst X in Y ändert und kurze Zeit später Y wieder in X zurückändert. Für Code-Reviews ist das durchaus teilweise nützlich, aber man muss selbst entscheiden, welche Vorschläge man annimmt und welche man verwirft. Für Menschen mit ausreichend Urteilsvermögen ist das wirklich produktiv, weil gute Kandidaten für Änderungen vorgeschlagen werden.
  • Ich frage mich, warum darüber nicht viel breiter gesprochen wird. Unter den Entwicklern um mich herum variiert das Technikinteresse stark. Meist nutzen Jüngere solche Tools aktiver, während Seniors weniger Interesse zeigen. Über AI für Code-Review oder Verifikation höre ich fast nie; vermutlich bräuchte es eine Funktion, die das automatisch beim Commit erledigt.
  • Auf Code-Review spezialisierte LLMs gibt es im Vergleich zu Code-Review/Design bereits in GitHub Copilot als Reviewer-Modus. Das ist noch nicht absolute Spitzenklasse, aber qualitativ schon gut genug, um es in der Schleife einzusetzen.
  • Stimme zu, wir arbeiten bei sourcery.ai genau an so etwas.