Mein LLM-Codegenerierungs-Workflow

• tldr: Spezifikation brainstormen, einen Plan erstellen und dann mit LLM-Codegen umsetzen. Einzelne Iterationsschleifen. Dann passiert Magie
• Ich baue mit LLMs schnell verschiedene kleine Produkte. Das macht Spaß und ist nützlich
• Mit dem falschen Ansatz kann man jedoch auch sehr viel Zeit verschwenden
• Viele Entwickler haben einen ähnlichen Ansatz, und unten ist mein Workflow

  „Im Moment funktioniert es gut, aber in zwei Wochen funktioniert es vielleicht nicht mehr oder doppelt so gut“

• Es gibt 2 Arten zu entwickeln
  • Greenfield-Code: ein neues Projekt starten
  • Modernisierter Legacy-Code: eine bestehende Codebasis verbessern oder erweitern

Greenfield: Von Grund auf neu starten

• Das ist ein Prozess, der gut zu Situationen passt, in denen man „von Grund auf“ anfängt
• Der Ablauf besteht darin, die Idee zu brainstormen, zu dokumentieren, einen kleinen schrittweisen Plan aufzustellen und sie dann mit Codegenerierungs-Tools umzusetzen
• Schritt 1: Idee konkretisieren
  • Man erklärt einem LLM wie ChatGPT die Idee und verfeinert sie, indem man sich nacheinander Fragen stellen lässt, bis eine konkrete Spezifikation entsteht
  • Am Ende erstellt man eine detaillierte Spezifikation (spec.md) und bereitet sie als Dokument auf, das man an Entwickler weitergeben kann
  • Falls nötig, kann man mit Tools wie Deep Research auch Hintergrundmaterial zur Idee beschaffen
• Schritt 2: Planung
  • Auf Basis der Spezifikation bittet man ein stärkeres Modell für „Verstehen und Schlussfolgern“, einen detaillierten Blueprint mit einzelnen Schritten zu erzeugen
  • Ob im TDD-Stil oder nicht: Für jeden Schritt werden kleine Arbeitseinheiten erstellt und in eine Reihenfolge gebracht
  • Durch diesen Prozess entstehen prompt_plan.md und todo.md
    • prompt_plan.md enthält das Prompt-Design für die Codegenerierung, todo.md eine Checkliste
  • Diese Planungsphase dauert meist nur etwa 15 Minuten und ist später leicht nachzuschlagen
• Schritt 3: Umsetzung
  • Mit verschiedenen Codegenerierungs- und Hilfstools wie Aider, Cursor oder Claude wird der eigentliche Code geschrieben
  • Typische Beispiele sind Claude und Aider
  • Claude-Variante
    • Zuerst richtet man die Projektstruktur vorab ein (Boilerplate usw.) und gibt Claude dann die Prompts Schritt für Schritt
    • Den erzeugten Code kopiert man in die IDE und führt Tests aus
    • Wenn Probleme auftreten, übergibt man Claude mit Tools wie repomix die aktuelle Codebasis und debuggt so
    • Workflow
      • Repo einrichten (Boilerplate, uv init, cargo init, etc)
      • Prompt in Claude einfügen
      • Von claude.ai per copy & paste in die IDE
      • Code ausführen, Tests ausführen usw.
      • …
      • Wenn es funktioniert, zum nächsten Prompt wechseln
      • Wenn es nicht funktioniert, mit Repomix die Codebasis an Claude schicken und debuggen
      • Das wiederholt sich immer wieder (rinse repeat)
  • Aider-Variante
    • Auch in Aider arbeitet man prompt_plan.md der Reihe nach ab
    • Es unterstützt dabei, automatisch Tests auszuführen oder Fehler zu finden und zu beheben
    • Falls nötig, löst man Probleme per interaktivem Debugging
      • Repo einrichten (Boilerplate, uv init, cargo init, etc)
      • Aider starten
      • Prompt in Aider einfügen
      • Aider beim Tanzen zusehen ♪┏(・o･)┛♪
      • Aider kann Tests ausführen oder die App starten, um sie zu prüfen
      • Wenn es funktioniert, zum nächsten Prompt wechseln
      • Wenn es nicht funktioniert, im Q&A mit Aider nachbessern
      • Das wiederholt sich immer wieder (rinse repeat)
• Ergebnis
  • Mit diesem Ansatz kann man in kurzer Zeit verschiedene Projekte wie Skripte, Expo-Apps oder Rust-CLIs umsetzen
  • Wenn du größere oder kleinere Projekte vor dir herschiebst, lohnt sich ein Versuch
  • Ein Vorteil ist, dass man dabei schnell experimentieren und neue Sprachen oder Technologien lernen kann

Non-Greenfield: Inkrementelle/iterative Arbeit an bestehendem Code

• Diese Methode nutzt man, wenn man kleine Aufgaben wiederholt auf eine bereits existierende Codebasis anwendet
• Statt eines großen Gesamtplans läuft es eher so, dass man pro Arbeitseinheit konkrete Anforderungen und Ergebnisse austauscht
• Kontext beschaffen
  • Mit Tools wie repomix kann man die Codebasis zusammenfassen und an ein LLM übergeben
  • Mit mise usw. verwaltet man wiederkehrende Setups und speichert die Zusammenfassung in einer Datei namens output.txt
  • Bei sehr großen Codebasen passt man an, damit nur die benötigten Teile zusammengefasst werden
• Beispiel-Workflow
  • Mit einem Befehl wie mise run LLM:generate_missing_tests lässt man das LLM Stellen mit fehlenden Tests identifizieren
  • Diese Vorschläge (Issues) setzt man dann mit Claude oder Aider um und testet das Ergebnis erneut
  • So verbessert man die bestehende Codebasis schrittweise

Wichtige Prompt-Beispiele

• Code-Review
  „Bitte führe als Senior-Entwickler ein gründliches Code-Review durch. Mit Zeilennummern und Kontext. Keine oberflächliche Review, sondern eine tiefgehende Analyse.“
  “You are a senior developer. Your job is to do a thorough code review of this code. You should write it up and output markdown. Include line numbers, and contextual info. Your code review will be passed to another teammate, so be thorough. Think deeply before writing the code review. Review every part, and don't hallucinate.“
• GitHub-Issue-Erstellung
  „Bitte prüfe als Senior-Entwickler den Code und schreibe die wichtigsten Probleme im Format von GitHub-Issues auf.“
  “You are a senior developer. Your job is to review this code, and write out the top issues that you see with the code. It could be bugs, design choices, or code cleanliness issues. You should be specific, and be very good. Do Not Hallucinate. Think quietly to yourself, then act - write the issues. The issues will be given to a developer to executed on, so they should be in a format that is compatible with github issues“
• Fehlende Tests
  „Bitte prüfe als Senior-Entwickler den Code und nenne konkret fehlende oder notwendige Tests.“
  “You are a senior developer. Your job is to review this code, and write out a list of missing test cases, and code tests that should exist. You should be specific, and be very good. Do Not Hallucinate. Think quietly to yourself, then act - write the issues. The issues will be given to a developer to executed on, so they should be in a format that is compatible with github issues“

Ski ᨒ↟ 𖠰ᨒ↟ 𖠰

• Wenn man mit LLMs in hohem Tempo Code schreibt, kommt irgendwann der Punkt, an dem sich Komplexität oder Kontext verheddern und alles verwirrend wird
• Dann hilft es, die Dokumente aus der Planungsphase (z. B. im Greenfield-Prozess) noch einmal anzusehen oder Tests systematisch zu schreiben
• So schnell man auch vorankommt: Es ist wichtig, zwischendurch kurz Pause zu machen oder die Gedanken zu ordnen

Ich bin sehr einsam (｡•́︿•̀｡)

• Die meisten LLM-basierten Workflows sind derzeit für den „Einzelspieler-Modus“ optimiert
• Wenn man im Team gemeinsam coden will, werden Konflikte oder Merge-Probleme schnell kompliziert
• Ich hoffe auf die Weiterentwicklung einer „multiplayerartigen“ Kollaborationsumgebung, in der mehrere Personen gleichzeitig mit LLMs arbeiten können

Zeit

• LLMs haben die Effizienz beim Schreiben von Code stark erhöht, aber es gibt auch „Downtime“ durch Wartezeiten bei der Token-Verarbeitung
• Diese Zeit nutze ich, um über andere Projektideen nachzudenken, Musik zu hören oder Gespräche zu führen
• Ich erlebe, dass meine persönliche Produktivität im Vergleich zu früher stark gestiegen ist

Haterade ╭∩╮( •̀_•́ )╭∩╮

• Viele Freunde haben eine Haltung wie „Verdammte LLMs, total nutzlos“, und ich schenke dieser Perspektive nicht allzu viel Beachtung
• Natürlich teile ich diese Haltung auch nicht, aber ein skeptischer Blick ist durchaus nötig
• Es gibt unzählige Gründe, AI nicht zu mögen, und meine größte Sorge sind Stromverbrauch und Umweltauswirkungen
• Trotzdem … „Code muss fließen“ – tja … seufz
• Wenn du mehr wissen willst, aber nicht unbedingt ein Cyborg-Programmierer werden möchtest, ist meine Empfehlung: „Ändere deine Meinung nicht, sondern lies Ethan Mollicks ‘Co-Intelligence: Living and Working with AI’.“
  • Das Buch erklärt die Vorteile von LLMs sehr gut, ohne die Übertreibungen eines technikanarchistischen Kapitalismus-Stils
  • Mir persönlich hat es sehr geholfen, und mit Freunden, die das Buch gelesen haben, konnte ich auch viel tiefere Gespräche führen
  • Sehr zu empfehlen

[devs5]

Ethan Mollicks „Co-Intelligence: Living and Working with AI“ scheint
im März unter dem Titel „Dual Brain“ veröffentlicht zu werden.

[kipsong133]

Es gab also etwas namens Repomix. Ich habe jedes Mal per Copy-and-Paste gearbeitet.. T_T

[chugue85]

Danke!

[ahwjdekf]

Ob das LLM wohl auch die Beschimpfungen anderer Entwickler für mich einstecken kann?

[aer0700]

Ich nutze LLMs bisher noch eher wie ein weiterentwickeltes Google oder ein freundliches Stack Overflow, aber ich sollte wohl darüber nachdenken, wie ich sie besser einsetzen kann.
Wie ich etwas baue, ist für mich zwar auch wichtig, aber ich glaube, es ist ebenso wichtig, gemeinsam mit der KI darüber nachzudenken, warum es funktioniert. Wenn man nach alten technischen Dokumentationen oder Standards sucht, sind LLMs nützlich.

[GN⁺]

Hacker News-Kommentar

• LLMs sind ein Werkzeug, um schnell Prototypen für neue Projekte zu erstellen. Wenn sie jedoch Änderungen an bestehendem Code oder ausgereiften Projekten vornehmen, fehlt ihnen oft der Kontext, wodurch sie die Komplexität erhöhen oder unnötige Frameworks hinzufügen. LLMs sind kein Ersatz dafür, Code zu verstehen.

• Bei der Zusammenarbeit mit LLMs ist es wichtig, Kontext durch Fragen aufzubauen. Das ist effektiver, als den Kontext direkt vorzugeben.

• In letzter Zeit wird versucht, gemeinsam mit LLMs Mob Programming zu praktizieren. Ein LLM übernimmt die Implementierung, ein anderes schlägt Kritik und Verbesserungen vor.

• Es ist wünschenswert, dem Projekt keine meinungsstarken Frameworks hinzuzufügen. Dadurch vergrößert sich nämlich der Umfang des Kontexts, den das Modell erfassen muss. Zum Beispiel wird das Setup für Browser-Erweiterungen lieber dem LLM überlassen als Plasmo zu verwenden.

• Ich würde gern Erfahrungsberichte von Leuten hören, die mit Cursor Chat angefangen und dann bessere Workflows entwickelt haben. Mich interessiert, ob sich die in Planung investierte Zeit gelohnt hat, ob Halluzinationen zurückgegangen sind und ob insgesamt Zeit gespart wurde.

• Dieser Artikel erklärt, wie man LLMs richtig einsetzt. Vielen Menschen fehlt die Übung darin, effektiv mit Sprachmodellen zu kommunizieren. Der Autor beherrscht die Kommunikation mit LLMs, und dieser Workflow maximiert die Effizienz.

• Um die Effizienz in einem Workflow mit LLMs zu maximieren, braucht man hohe Tippgeschwindigkeit, gutes Urteilsvermögen und Vertrautheit mit den Stärken und Schwächen der einzelnen Modelle.

• Coding-Tools mit LLMs machen Spaß, aber um festzustellen, ob sie wirklich hilfreich sind, sollte man konkrete Ziele und Fristen setzen. Unter solchen Bedingungen scheitern LLMs mit hoher Wahrscheinlichkeit.

• Viele Junior-Programmierer vergessen den Teil der Spezifikation und Ausführungsplanung beim Programmieren. Um LLMs erfolgreich zu nutzen, sollte man sie dazu bringen, Spezifikation und Ausführungsplan zu erstellen.

• Ich verstehe die Erwartungen an Claude nicht. Bei Fragen zu Apache Spark treten viele Halluzinationen auf. Ich würde gern verstehen, warum Claude besser sein soll als andere Modelle.

• Für Einzelentwickler ist das in Ordnung, aber mehrere LLM-Instanzen, die in einem Team dieselbe Codebasis analysieren, sind weder wirtschaftlich noch frei von Risiken. Ich frage mich, ob es Produkte gibt, die einem Team einen zentralisierten Kontext bereitstellen.