Wie ich Software mit LLMs schreibe: Ein praktischer Multi-Model-Workflow
Am 10. März 2026 veröffentlichte Stavros einen Beitrag, der als ehrlichste und praktischste Anleitung zum Softwarebau mit großen Sprachmodellen gelten kann. Kein Hype-Artikel. Sondern ein echter Workflow, der über mehrere ausgelieferte Projekte getestet wurde.
Der Ausgangspunkt: Dinge machen, nicht programmieren
Stavros unterscheidet zwischen Programmieren als Selbstzweck und dem Ziel, funktionierende Software auszuliefern. LLMs haben die Gleichung verändert, indem sie Programmieren näher an direkte Konstruktion bringen.
Er hat diesen Ansatz für mehrere Projekte genutzt: einen persönlichen Assistenten namens Stavrobot, ein Sprachnotiz-Gerät, ein Kunst-Uhr-Projekt und eine Kleinstadt-Simulation namens Pine Town. Das sind keine Demo-Projekte, sondern gepflegte Codebasen mit echten Anforderern.
Die Drei-Modell-Architektur
1. Das Planungsmodell (Architekt)
Das erste Modell fungiert als Architekt. Stavros verbringt bis zu 30 Minuten im Gespräch mit diesem Modell, bevor Code geschrieben wird. Die Schlüsselanweisung: Beginne nicht mit der Implementierung, bevor ich den Plan ausdrücklich genehmige.
Diese Einschränkung ist entscheidend. LLMs sind darauf aus, Code zu generieren. Ohne eine harte Barriere rutscht das Planungsgespräch in die Implementierung, bevor das Design steht.
2. Das Entwicklungsmodell (Implementierer)
Nach der Planungsgenehmigung übernimmt ein günstigeres Modell die Implementierung. Dieses Modell bekommt begrenzten Spielraum — es setzt den Plan um, statt ihn neu zu gestalten.
3. Die Review-Modelle (Mehrere Prüfer)
Nach der Implementierung lässt Stavros den Code durch mehrere Review-Modelle laufen. Er nutzt Codex, Gemini und Opus. Die Vielfalt ist wichtig — verschiedene Modelle erwischen verschiedene Probleme.
Der Mensch schreibt die Agent-Anweisungen
Stavros schreibt Agent-Anweisungen von Hand. Er lässt kein LLM seine eigene Skill-Datei generieren. Der Mensch definiert die Einschränkungen. Die Modelle arbeiten innerhalb dieser Grenzen.
Wo es gut funktioniert
Der Multi-Model-Workflow funktioniert am besten, wenn Stavros den Technologie-Stack bereits versteht. In diesem Kontext fungieren LLMs als Produktivitätsmultiplikator.
Wo es scheitert
In unbekanntem Gebiet funktioniert der Workflow deutlich schlechter. Schlechte Entscheidungen kumulieren. Die Codebase sammelt technische Schulden an, die der Mensch erst erkennt, wenn es zu spät ist.
Praktische Erkenntnisse
Trennen Sie Planung von Implementierung. Nutzen Sie verschiedene Modelle für verschiedene Rollen. Diversifizieren Sie Ihre Reviewer. Schreiben Sie eigene Anweisungen. Bleiben Sie in vertrautem Gebiet. Achten Sie auf kumulierende Fehler.