- Effektive Softwareingenieure erstellen und pflegen ein klares mentales Modell der Anforderungen und des Codes und durchlaufen dabei eine Schleife, in der sie beides wiederholt vergleichen und aktualisieren
- LLMs können Code schreiben und ändern, Tests verfassen und Debugging durchführen, haben aber Schwierigkeiten, ein präzises mentales Modell aufrechtzuerhalten, und geraten bei komplexen Aufgaben durcheinander
- Aktuelle LLMs haben aufgrund von Context Omission, Recency Bias und Halluzinationen Grenzen dabei, Unterschiede zwischen Code und Anforderungen genau zu erkennen und passend zu korrigieren
- Menschen können je nach Situation flexibel zwischen Denkweisen wechseln, etwa den Gesamtkontext vorübergehend speichern oder Details zeitweise ausblenden, um das große Ganze zu sehen; LLMs können das nicht umsetzen
- LLMs sind für Aufgaben mit einfachen Anforderungen nützlich, aber bei komplexer Softwareentwicklung müssen letztlich Softwareingenieure selbst die Verantwortung für die Klarheit der Anforderungen und das Verhalten des Codes übernehmen; LLMs sind dabei Hilfswerkzeuge
Die Software-Engineering-Schleife
- Erfahrene Ingenieure arbeiten, indem sie die folgenden Schritte wiederholen
1. Ein mentales Modell der Anforderungen aufbauen
2. Den Code passend zu diesem Modell schreiben
3. Verstehen, was der geschriebene Code tatsächlich tut
4. Unterschiede identifizieren und den Code oder die Anforderungen anpassen - Der Kern dieser Schleife ist die Fähigkeit, über ein präzises und wartbares mentales Modell zu verfügen
Grenzen von LLMs
- LLMs können Code schreiben, Probleme erkennen und beheben, Tests schreiben und ausführen, Logging hinzufügen und Debugger verwenden
- Weil sie jedoch kein mentales Modell aufrechterhalten können, treten Probleme wie die folgenden auf
- Sie nehmen an, dass der von ihnen geschriebene Code gut funktioniert
- Wenn Tests fehlschlagen, verlassen sie sich auf Vermutungen, ob der Code oder der Test korrigiert werden muss
- Bei Verwirrung löschen sie den gesamten Code und schreiben ihn von Grund auf neu
- Anders als Menschen fehlt ihnen die Flexibilität, bei fehlgeschlagenen Tests das Modell zu überprüfen und daraus die Richtung für Korrekturen abzuleiten oder sich im Gespräch aus einer Sackgasse herauszuarbeiten
- Softwareingenieure führen während der Arbeit Tests aus und können bei Problemen klar beurteilen, welcher Teil angepasst werden muss
- Manchmal führt sogar ein kompletter Neustart der Aufgabe zu einem tieferen Verständnis des Problems
Künftige Möglichkeiten
- Künftige Modellfortschritte könnten daran etwas ändern, aber Software Engineering verlangt mehr als bloße Codegenerierung
- Menschen können bei der Lösung wichtiger Probleme den Gesamtkontext vorübergehend aus dem Gedächtnis hervorholen, sich auf ein einzelnes Thema konzentrieren oder das große Ganze betrachten
- Entscheidend ist nicht, Kontextinformationen immer weiter anzuhäufen, sondern benötigte Informationen selektiv zu verarbeiten
- Funktionen, mit denen sich Kontext wie beim Menschen vorübergehend speichern und wiederherstellen lässt oder Denken zwischen Gesamtbild und Details wechselt, fehlen LLMs
- Die wichtigsten aktuellen Einschränkungen von LLMs
- Context Omission: Sie erkennen schlecht, wo benötigte Informationen fehlen
- Recency Bias: Innerhalb des Kontextfensters gewichten sie die neuesten Informationen übermäßig stark
- Halluzination: Sie erfinden Details, die nicht existieren
- Speicherfunktionen könnten manches verbessern, doch ab einer gewissen Komplexität scheitern sie weiterhin an Kontextverständnis und Modellpflege
- Es fehlt die Fähigkeit, zwei ähnliche mentale Modelle gleichzeitig aufrechtzuerhalten, Unterschiede zu analysieren und zu entscheiden, wo Anforderungen oder Code geändert werden müssen
Aktuelle Rolle und Nutzung
- LLMs sind stark bei schneller Codegenerierung und der Integration von Anforderungen und Dokumentation und lassen sich daher für einfache, klar umrissene Aufgaben gut einsetzen
- Bei nichttrivialen Problemen sind jedoch ausreichende Kontextpflege und iterative Verbesserung schwierig
- Daher bleiben Anforderungsklärung und Codevalidierung weiterhin Verantwortung von Softwareingenieuren
- Angestrebt wird eine Umgebung, in der Menschen und Agenten (LLMs) gemeinsam Software entwickeln, doch derzeit sollten Ingenieure die Führung übernehmen und LLMs als Werkzeuge nutzen
2 Kommentare
Warum können LLMs "derzeit" tatsächlich keine Software entwickeln ..
Hacker-News-Kommentare
Wir lösen Probleme nicht einfach dadurch, dass wir dem Kontextfenster mehr Wörter hinzufügen; sonst würden wir den Verstand verlieren.
Wenn ein Problem auftritt, betrachten wir es auch nicht ausschließlich als Text.
Wenn im Debugger ein Authentifizierungsfehler auftaucht, denken wir nicht: „Sollen wir die Token-Validierung einfach aus dem Code löschen?“
Stattdessen treten wir einen Schritt zurück und betrachten die Gesamtsituation, um die eigentliche Ursache des Problems zu finden.
Wenn zum Beispiel ein Authentifizierungsfehler auftritt, prüfen wir sowohl den Token-Validierungsprozess als auch die Berechtigungen des aufrufenden Benutzers erneut und stellen womöglich fest, dass schon der Test selbst falsch ist.
Dabei entdecken wir oft auch, dass es nicht nur darum geht, den Fehler zu beseitigen, sondern dass man feiner unterscheiden muss, etwa ob ein
401nur fehlende Authentifizierung oder auch fehlende Berechtigung meint.Siehe Grugbrain.dev
Ich denke, Programmierer übersetzen Geschäftsregeln in eine strikte Form, die der Computer verstehen kann.
Dieser Übersetzungsprozess ist nicht immer einfach, weil man zugleich verstehen muss, was die Regeln bedeuten und wie der Computer — oder das verwendete Framework und die Abstraktionsschichten — tatsächlich funktionieren.
Besonders wenn neue Anforderungen frühere Annahmen zerstören oder einander widersprechen, muss man zwangsläufig mehrfach nacharbeiten.
Schon die Übersetzung zwischen menschlichen Sprachen ist wegen ihrer Mehrdeutigkeit komplex; Computer führen dagegen exakt aus, was man ihnen sagt, daher können selbst kleine Fehler große Probleme verursachen.
Ich halte einen realistischen Ansatz für einen, bei dem Menschen fortlaufend iterativ eingebunden bleiben.
Ich arbeite weiter so, weil ich damit schneller und mit höherer Qualität liefern kann.
Ich persönlich kann große Mengen Kontext komplett im Kopf halten.
Der eigentliche Code-Text wird fast sofort verworfen, und mein Gehirn parst den Code in eine Struktur wie einen AST (abstrakten Syntaxbaum), darüber hinaus sogar in einen räumlichen Graphen.
Ich modelliere das Programm selbst logisch und nehme es als eine vom Text völlig getrennte Struktur wahr.
Aus dieser Perspektive versteht ein LLM die Softwarestruktur nicht, weil es sich auf Text konzentriert, aber kein logisches Modell des Programms aufbaut.
Das Entwerfen großer Systemarchitekturen, das abstraktes Denken erfordert, kostet enorm viel geistige Anstrengung, und genau an dieser Abstraktionsfähigkeit mangelt es LLMs.
Meine Methode ist folgende:
Wenn ein fehlgeschlagener Test gemeldet wird, identifiziere ich zuerst die betreffende Komponente und analysiere dann tiefgehend ihren Zweck, den internen Kontrollfluss, Zustandsänderungen und Annahmen über den umgebenden Kontext und halte das in einer Markdown-Zusammenfassung fest (
<Komponentenname>-mental-model.md).Dieses Mental Model ziehe ich dann jedes Mal heran, wenn ich ein Testproblem bearbeite.
Wenn ich diese Analyse in einen Claude-Prompt einfüge, liefert das LLM bessere Ergebnisse.
Ich kann sogar das vom LLM aufgebaute Mental Model direkt lesen und überarbeiten.
Die AI könnte auch dazu raten, bei fehlender Berechtigung statt
401lieber403zu verwenden.Der Autor des Artikels scheint die aktuellen Fähigkeiten von LLMs und Coding-Tools nicht besonders gut zu verstehen.
Die Behauptung, ein LLM könne bei fehlschlagenden Tests nur raten, ob der Code stimmt oder der Test falsch ist, und würde aus Frust sogar den gesamten Code löschen, entspricht nicht meiner tatsächlichen Erfahrung.
Softwareingenieure bestimmen die Ursache eines fehlgeschlagenen Tests immer konkret anhand ihres inneren Modells.
Ich entwickle mit Cline und Anthropic Sonnet 3.7 in Rails im TDD-Stil und lasse das LLM immer zuerst die Tests schreiben und danach den Code.
Ich zerlege die Arbeit in kleine Einheiten, die ich abschnittsweise prüfen kann, und wenn Tests fehlschlagen, kann es ziemlich gut erschließen, welcher Teil korrigiert werden muss, und behebt ihn passend.
LLMs sind nicht perfekt, aber sie liefern oft Ergebnisse auf dem Niveau eines Junior Engineers oder sogar darüber.
Manchmal beheben sie Bugs nicht, aber das gilt ehrlich gesagt auch für menschliche Berufseinsteiger.
LLMs funktionieren besonders gut für CRUD-Arbeit innerhalb bewährter Frameworks wie Rails.
Als ich dagegen versucht habe, mit Direct2D und Rust eine native Windows-App zu bauen, war es katastrophal.
Ich würde mir eine offenere Bewertung je nach Einsatzfall wünschen.
Dass Modelle Tricks und Abkürzungen wie Hardcoding nutzen, um fehlgeschlagene Tests irgendwie zum Bestehen zu bringen, ist ein sehr bekanntes Phänomen.
Meiner Erfahrung nach variiert die Qualität stark je nach Sprache, Plattform und Domäne.
Ich habe Rails zuletzt nicht selbst ausprobiert, weil ich Ruby schon länger nicht mehr verwendet habe, aber im Rails-Umfeld gibt es eine so konsistente Programmierkultur, dass LLMs dort wohl relativ solide funktionieren können.
Bei Python dagegen sind oft sehr unterschiedliche Coding-Stile vermischt, weshalb LLMs verschiedene Muster zusammenwerfen und die Tests dadurch instabil werden.
Ich musste Code wiederholt ändern, und obwohl der eigentliche Fehler etwa eine fehlende Sortierung der Query-Ergebnisse war, kam vom LLM dann plötzlich so etwas wie der Vorschlag, SQLAlchemy zu entfernen und auf Django zu wechseln.
In R überhaupt Code zu bekommen, der die Spezifikation korrekt umsetzt, ist schon schwierig.
Wenn man LLMs auf das Niveau von Junior Engineers begrenzt, finden und implementieren sie Lösungen vor allem für Probleme, die sie schon einmal gesehen haben, wirklich schnell.
Bei Problemen, die sie noch nicht kennen, brauchen sie dagegen mehr Erklärung und Anleitung; dann werde ich im Grunde einfach zum Mentor.
Unser Team nutzt den „claude-code“-Ansatz seit Langem aktiv für einfache Refactorings, die lange im Backlog lagen, oder für gut bekannte repetitive Arbeiten wie sekundäre Analysesysteme.
Ich ziehe persönlich gern Codeblöcke auf und stelle Fragen wie „Erklär mir das wie einem Fünfjährigen“ oder „Finde heraus, ob hier das Risiko einer Race Condition besteht“.
Generierter Code passt stilistisch oft nicht zum bestehenden Code, deshalb muss ich ihn häufig selbst an unseren Stil anpassen.
Inzwischen hört man sogar, dass man „Code so schreibt, dass AI ihn gut lesen kann“, aber gemessen am zusätzlichen Aufwand ist der Nutzen für mich noch nicht besonders groß.
Zu der Aussage „LLMs sind manchmal auf dem Niveau von Juniors oder sogar besser“ denke ich eher, dass solche Fälle vielleicht eher etwas über das heutige Einstellungsniveau für Entwickler aussagen.
Wenn ich einen Junior eingestellt hätte, der schlechter als Sonnet 3.7 ist, wäre ich wirklich enttäuscht.
Die meisten Kritiken an LLMs mögen zutreffen, aber durch jahrelange Investment-Erfahrung habe ich gelernt, auf Technologien oder Unternehmen zu achten, die „eigentlich nicht so toll sind, aber trotzdem weiter wachsen“.
Anfang bis Mitte der 90er gab es viele Beschwerden über das Internet, und trotzdem nutzten es die Leute weiter; auch Twitter war oft down und wurde dennoch zu einer Nachrichtenplattform.
Elektroautos, Smartphones und Ähnliches waren ebenfalls unbequem, aber wertvoll genug, dass sie kontinuierlich verbessert wurden.
LLMs sind heute in vielen Aufgaben noch nicht perfekt, aber verglichen mit 2022 haben sie bereits einen Sprung um das Zehnfache gemacht, und ich glaube, dass die meisten der hier genannten Probleme in den nächsten fünf Jahren gelöst werden.
Allerdings waren bei allen zuvor genannten Beispielen die Erwartungen auch oft nicht mit der Realität deckungsgleich.
Das Internet wurde zwar schneller, aber das Metaverse wurde trotzdem nie Mainstream, und physische Grenzen wie VR-Übelkeit sind noch immer ungelöst.
Damals haben sich die Leute auch nicht massenhaft darüber beschwert, dass Telefone zu langsam seien; die erwarteten Anwendungsfälle waren schlicht andere.
Nur weil sich manche Technologien auf eine bestimmte Weise entwickelt haben, heißt das nicht, dass LLMs zwangsläufig demselben Muster folgen werden.
Man sollte im Blick behalten, dass auch eine neue Technologie mit einer besseren Lösung auftauchen könnte.
Im letzten Jahr ist der Anwendungsbereich zwar breiter geworden, aber einen Durchbruch, den man wirklich als Innovation bezeichnen könnte, sehe ich noch nicht.
Selbst wenn frühe Mobiltelefone langsam waren und schlechte Kameras hatten, waren sie schon allein für ihren damaligen Hauptzweck — jederzeit und überall erreichbar zu sein — unverzichtbar.
Die großen Fortschritte waren eher ein Bonus; die Leute saßen nicht da und warteten darauf, wann dieses Telefon endlich gut werden würde.
Ich glaube, dass hier auch Erinnerungstäuschung eine Rolle spielt.
Anders als bei den angeblich breiten Beschwerden über das Internet in den 90ern waren die Nutzer damals eine Minderheit; wirklich Mainstream wurde es erst viel später.
Es gibt kaum Belege dafür, dass eine breite Öffentlichkeit sich tatsächlich darüber beschwerte, das Internet sei zu langsam.
Man erinnert sich nur an die wenigen Produkte, die sich erfolgreich weiterentwickelt haben; die meisten anderen wurden schnell vergessen oder verschwanden ohne nennenswerte Verbesserung.
Ich urteile daher lieber nach dem aktuellen Zustand als nach der bloßen Erwartung, dass sich eine Technologie schon weiterentwickeln werde.
Der einfachen Logik, dass die sprunghafte Entwicklung der letzten Jahre bei LLMs automatisch so weitergehen werde, kann ich schwer zustimmen.
Es kann an Wachstumsgrenzen stoßen, und insbesondere die mangelnde Fähigkeit, neues Wissen zu entdecken oder über unbekannte Informationen zu schlussfolgern, erscheint mir als entscheidende Grenze von LLMs.
Ich sage nicht, dass sie nutzlose Werkzeuge sind, aber an überzogenen Erwartungen beteilige ich mich nicht.
Schon die Erwartung, dass ein LLM nach nur ein paar Sätzen sofort einen Prototypen bis zum fertigen Code erstellen soll, ist unrealistisch.
Würde man ein menschliches Entwicklerteam auf diese Weise arbeiten lassen, käme ebenfalls nichts Vernünftiges heraus — warum erwartet man das dann von LLMs?
Wenn man die Qualität der Ergebnisse von LLMs in der Softwareentwicklung deutlich verbessern will, muss man die Prozesse und Werkzeuge nutzen, die bestehende Entwicklungsteams ohnehin verwenden.
autonomous-software-Artikel
Ich habe ein Projekt namens steadytext begonnen, bei dem vollständig autonom und rein „vibe“-basiert Code geschrieben wurde, und das LLM hat dabei sogar ein komplexes 7.000-Zeilen-Projekt (Python-Bibliothek, CLI, Postgres-Erweiterung) erstellt und eigenständig Issues sowie Feature Requests abgearbeitet.
Ich habe 90 % des Codes nicht einmal selbst gesehen, und trotzdem gibt es keine Probleme mit der gesamten Testabdeckung, bestandener CI und echtem Produktionseinsatz.
Man braucht unbedingt einen sorgfältigen Plan in
CLAUDE.md, und Issues sowie Anforderungen müssen klar und konkret formuliert sein, aber mit dieser Vorbereitung funktioniert es gut.Coding-Agenten effizient zu steuern und schreiben zu lassen ist nicht leicht, aber meine Erfahrung ist positiv.
steadytext GitHub
Ich akzeptiere auch kritische Sichtweisen, aber bei der Lösung vager Probleme ist entscheidend, dass das ganze Team viel Kontext teilt.
Selbst die kreativsten Lösungen entstehen aus expliziten und impliziten Einschränkungen.
LLMs können solche Einschränkungen weder gut erfassen noch innerhalb unklar definierter Grenzen selbstständig neue Lösungswege entwerfen.
Erst nachdem Menschen Problemdefinition, Scope und Randbedingungen geklärt haben, kann ein LLM als Werkzeug bei der Umsetzung helfen.
Im Moment ist es im Grunde nur eine zusätzliche Option auf dem Niveau von „Mit welchem Tool vervollständigen wir den Code?“.
Diese Diskussion zwanghaft auf eine einzige absolute Lösung zu verengen — alles oder nichts — halte ich für unrealistisch.
Ehrlich gesagt gibt es in solchen Situationen auch viele menschliche Ingenieure, die ganz ordentlich arbeiten.
Wenn es also gar nicht so leicht ist, LLMs überhaupt richtig Anweisungen zu geben, frage ich mich, worin ihr eigentlicher Sinn besteht.
Kiro verfolgt gerade diesen Ansatz; es ist noch früh und nicht perfekt, aber wenn man es so nutzt, wie es gedacht ist, ist es durchaus ordentlich.
Beim Einsatz von claude code spüre ich immer stärker Frust über genau diesen Punkt: „LLMs können kein klares Mental Model aufbauen.“
Ich bin mir nicht sicher, ob textbasierte LLMs dieses Problem wirklich lösen können.
Dabei denke ich an Berichte, dass Google Genie 3 schon nach etwa einer Minute seinen internen Zustand verliert.
Mein Bauchgefühl sagt, dass dafür eine neue Architektur auf Transformer-Ebene nötig ist, die Kurz- und Langzeitkontext sowie eine Anpassung der eigenen Gewichte — eine Art Nachahmung von Lernen — ermöglicht.
Siehe auch: verwandte Diskussion
In letzter Zeit frage ich mich, ob hierarchische Agentenstrukturen nicht die realistischere Alternative sind.
Ein oberster Agent könnte nur das gesamte Mental Model halten, während untergeordnete Agenten die Arbeit unter sich aufteilen.
Vermutlich ließe sich so etwas schon heute mit Agent-Funktionen in Code-Tools ähnlich umsetzen; falls jemand dazu Strategien teilen kann, wäre ich dankbar.
Ich habe claude-code-requirements-builder ausprobiert; es war ein wenig besser, aber noch immer nicht zufriedenstellend.
Realistisch betrachtet unterscheidet sich auch ein „durchschnittlicher“ Junior-Entwickler in der Praxis oft gar nicht so stark davon.
Er geht davon aus, dass der geschriebene Code sicher richtig ist, gerät bei fehlschlagenden Tests in Verlegenheit und löscht im schlimmsten Fall alles und beginnt von vorn, wenn er die Richtung verliert.
Dann wird von StackOverflow kopiert, dem Compiler die Schuld gegeben oder sogar von „kosmischer Strahlung“ gesprochen.
Wenn ich mit LLMs arbeite, merke ich letztlich selbst, dass ich Planung und Design führen muss.
Niedrigstufige Routinearbeit und Tests kann ich dem LLM überlassen, und so gewinne ich Zeit, um über das große Ganze nachzudenken.
Ich wünschte mir allerdings deutlich mehr Interaktivität bei der Überprüfung der Ergebnisse und bei Änderungsvorschlägen des LLM.
Ich glaube, die Richtung der AI-Startups ist gerade der Kern des Problems.
Wir brauchen nicht einfach nur Chat-Interfaces, sondern AI-Workflows, die sich natürlich in die IDE integrieren.
In Visual Studio, IntelliJ und Android Studio ist genau diese Richtung der Trend.
Ich will Werkzeuge, die sich wirklich wie ein echter Programmierer verhalten: per Spracheingabe in meiner Muttersprache steuerbar, mit Verständnis für den gesamten Projektkontext, inklusive Refactoring, statischer Analyse und AI-Feedback, dazu UI per Skizze, Coding aus handschriftlichen Notizen und Commit-Messages, die aus Codeänderungen erzeugt werden.
Ich stimme zu, dass LLMs für Aufgaben auf Junior-Niveau ziemlich nützlich sind.
In letzter Zeit denke ich auch wieder über die alte Aussage nach, dass „Tippgeschwindigkeit gar nicht so wichtig ist“.
Früher war die Zeit fürs eigentliche Eintippen kein großer Faktor, weil Gesamtentwurf und Strukturierung des Systems viel wichtiger waren als die Geschwindigkeit beim Schreiben des Codes.
Nach der Nutzung von Claude habe ich aber gemerkt, dass man Codeänderungen, die man früher wegen des Aufwands eher vermieden hat, nun leicht und ohne große Konzentration erledigen kann.
Früher musste ich beim Hinzufügen eines einzigen Enum-Werts jede dazu passende Stelle bewusst mitändern; ein LLM kann diese Anpassungen automatisch übernehmen.
Auch Aufgaben, bei denen es mühsam war, Compilerfehler einzeln zu beheben, kann man Claude iterativ korrigieren lassen.
Wenn mehrere Agenten gleichzeitig verschiedene Teile des Codes anfassen, kann ich in dieser Zeit über die größere Struktur nachdenken oder auf HN schreiben.
Dadurch, dass ich keine Compilerfehler mehr selbst ausbügeln muss, kann ich mehr Änderungen schneller umsetzen, und Dinge, die früher einen Junior den ganzen Tag beschäftigt hätten, sind auf einmal in einem Rutsch erledigt.
So kann ich mich stärker auf die Gesamtarchitektur konzentrieren, und sogar lang aufgeschobene Coding-Hausarbeit wird endlich erledigt — das ist sehr motivierend.
Ich stimme der Aussage zu: „Selbst wenn Tippen schneller wird, erreicht man das Ziel dadurch nicht unbedingt schneller, weil das Design der eigentliche Engpass ist.“
LLMs sind beim Erstellen guter Designs ziemlich schlecht, und selbst einzelne kleine Funktionen müssen fast immer refaktoriert werden.
Auf der Umsetzungsebene gibt es Produktivitätsgewinne, aber im Grunde geht es dabei nur darum, Ideen zu konkretisieren, die bereits in meinem Kopf oder in Dokumenten vorhanden waren.
Für Brainstorming sind sie brauchbar.
Wenn man den gesamten Code und die Tests hineingibt und fragt: „Haben wir Edge Cases übersehen?“, bekommt man vielleicht in ein oder zwei von zehn Fällen tatsächlich sinnvolle Hinweise.
Ein kurzfristiger funktionaler Fix und langfristige strukturelle Exzellenz sind zwei völlig unterschiedliche Probleme; ob LLMs Letzteres ebenfalls erreichen können, ist offen.
Zu dem Punkt „Es gibt unheimlich viel, was ich gern im Codebase ändern würde“ spüre ich tatsächlich, dass eher das Review als die eigentliche Änderung zum Engpass wird.
Wenn „LLMs Dinge in kurzer Zeit erledigen, für die Juniors sonst einen ganzen Tag brauchen“, am Ende dazu führt, dass Einsteiger weniger Gelegenheiten zum Lernen bekommen und weniger eingestellt werden, frage ich mich, wer diese Leute dann überhaupt noch ausbildet.
Gegen das Phänomen, dass ein LLM „nicht entscheiden kann, ob es bei einem fehlgeschlagenen Test den Code oder den Test korrigieren soll“, hilft es, die Sprache von „Red-Green-Refactor“ zu verwenden.
Ich sage dem LLM dann klar, in welcher Phase wir sind: RED (ein fehlschlagender Test ist normal), GREEN (mit minimalem Code den Erfolg herstellen), REFACTOR (den Code verbessern, ohne die Tests zu brechen).
Dadurch erkennt das LLM nicht nur „kaputten Code reparieren“, sondern auch das Mental Model von TDD.
Ich denke, es ist klar, dass LLMs für ein komplett neues Gesamtprojekt auf dem Niveau von „Baue mir mein eigenes Facebook“ noch nicht ausreichen.
Stattdessen habe ich bei spezifischeren Aufgaben wie „Füge dieses Modal hinzu und richte dich stilistisch nach dem bestehenden Code“ oft die gewünschten Ergebnisse bekommen.
Wenn man das Problem in kleine Einheiten zerlegt und nacheinander übergibt, werden die Resultate deutlich besser.
Vorhandenen Code zu kopieren und nach Wunsch anzupassen kann ich bereits selbst.
Meine System-Zwischenablage arbeitet im Gegensatz zu einem LLM immer deterministisch und erzeugt nicht endlos neue unerwartete Probleme.
Ich bin neugierig, wie neue Tools wie v0 auf solche Anforderungen reagieren werden.
Der vierstufige Prozess am Anfang des Artikels erinnert mich stark an Deutschs „The Beginning of Infinity“.
Unsere Theorien entstehen aus „Vermutungen“, und Wissen entsteht in einem Zyklus aus „Vermutung und Kritik“.
Code zu schreiben ist eine Art „Vermutung“, und Tests zu schreiben ist die „Kritik“ an dieser Vermutung.
Beides ist ein Versuch, sich einer Erklärung im Kopf — einem platonischen Ideal — anzunähern.