- Es wird eine konkrete Methodik vorgestellt, wie sich bei der Softwareentwicklung mit LLMs über einen Multi-Agenten-Workflow aus Architekt–Entwickler–Reviewer Projekte im Umfang von Zehntausenden Zeilen mit niedriger Fehlerrate pflegen lassen
- Das eigentliche Interesse galt weniger dem Programmieren als dem Bauen von Dingen; seit LLMs gut coden können, lässt sich der Fokus stärker auf das Erschaffen richten
- Wichtiger als die Fähigkeit, Code zu schreiben, sind inzwischen Engineering-Skills wie Systemarchitektur und das Treffen der richtigen Entscheidungen
- Durch die Kombination verschiedener Modelle steigt die Qualität von Code-Reviews; Stärken und Schwächen der einzelnen Modelle werden getrennt nach Rollen genutzt
- Eine komplette reale Session zum Hinzufügen einer E-Mail-Funktion wird offengelegt und der menschlich geführte Kollaborationsprozess mit LLMs von Architekturentscheidung bis QA detailliert dokumentiert
Vorteile des Bauens mit LLMs
- Ich dachte, ich würde Programmieren mögen, aber tatsächlich mochte ich vor allem das Bauen an sich; seit LLMs gut programmieren können, baue ich ohne Unterlass neue Dinge
- Rund um die Veröffentlichung von Codex 5.2 und zuletzt mit Opus 4.6 wurde es möglich, Software mit sehr niedriger Fehlerrate zu schreiben. Die Fehlerrate kann sogar deutlich niedriger sein als beim manuellen Codieren
- Früher war der Code nach 2–3 Tagen Arbeit oft nicht mehr wartbar, heute arbeite ich über Wochen hinweg kontinuierlich daran, nützlichen Code mit Zehntausenden Zeilen stabil wachsen zu lassen
- Engineering-Skills sind nicht nutzlos geworden, sondern haben sich verlagert: Nicht mehr die Fähigkeit, Code korrekt zu schreiben, sondern die Urteilsfähigkeit, ein System richtig zu architektieren und benutzbar zu machen, ist entscheidend
- Bei Projekten mit gut bekannten Basistechnologien, etwa im Backend, gibt es auch bei Zehntausenden SLoC keine Probleme; bei weniger vertrauten Technologien, etwa mobilen Apps, wird der Code durch die Akkumulation falscher Entscheidungen weiterhin chaotisch
- In der frühen LLM-Phase (nach davinci) musste jede einzelne Codezeile geprüft werden, in späteren Generationen nur noch auf Funktionsebene, und heute reicht meist eine Kontrolle auf Gesamtarchitektur-Ebene. Nächstes Jahr könnte selbst das unnötig werden
Mit dieser Methode gebaute Projekte
- Stavrobot: ein sicherheitsfokussierter persönlicher LLM-Assistent. Er verwaltet Kalender, bewertet Verfügbarkeiten, recherchiert, erweitert sich selbst durch das Schreiben von Code, erinnert an Dinge und organisiert eigenständig Hausarbeit. Der Kernwert ist nicht ein einzelnes Killer-Feature, sondern das Beseitigen Tausender kleiner Unannehmlichkeiten
- Middle: ein kleines Anhänger-Gerät, das Sprachnotizen aufnimmt, in Text umwandelt und per Webhook versendet. Entscheidend ist, dass es immer mitgeführt werden kann und sich reibungslos nutzen lässt
- Sleight of Hand: ein Wanduhren-Kunstprojekt, das in Sekundenabständen unregelmäßig tickt, auf Minutenebene aber immer exakt bleibt. Es bietet verschiedene Modi wie variable Ticks von 500 ms bis 1500 ms, zufällige Stopps nach kaum wahrnehmbaren Tempowechseln oder doppeltes Tempo mit anschließendem 30-Sekunden-Stopp
- Pine Town: eine unendliche Multiplayer-Canvas, auf der jede Person ein kleines Stück Land erhält, um darauf zu zeichnen – ein interaktives Wiesenprojekt
- Alle diese Projekte wurden mit LLMs erstellt, und obwohl ich den Großteil des Codes nie direkt gelesen habe, kenne ich die Architektur und die interne Funktionsweise jedes Projekts gut
Das Harness-Tool
- Als Harness wird OpenCode verwendet; mit Pi wurden ebenfalls gute Erfahrungen gemacht
- Zwei unverzichtbare Anforderungen an ein Harness:
- Verschiedene Modelle mehrerer Unternehmen nutzbar: Die meisten First-Party-Harnesses (Claude Code, Codex CLI, Gemini CLI) unterstützen nur die eigenen Modelle und erfüllen diese Anforderung daher nicht
- Custom Agents müssen sich gegenseitig autonom aufrufen können
Warum mehrere Modelle nötig sind
- Ein bestimmtes Modell kann wie eine Person betrachtet werden; selbst nach dem Zurücksetzen des Kontexts behält es tendenziell dieselben Meinungen, Stärken und Schwächen
- Wenn ein Modell seinen eigenen Code reviewen soll, neigt es zur Selbstbestätigung und das ist fast bedeutungslos; wenn jedoch ein anderes Modell das Review übernimmt, steigt die Qualität deutlich
- Stand heute eignet sich Codex 5.4 wegen seiner Gründlichkeit und Strenge gut für Reviews, Opus 4.6 stimmt besonders gut mit den Entscheidungen überein, die ich selbst treffen würde, und Gemini 3 Flash liefert mitunter Lösungen, die andere Modelle übersehen
- Für optimale Ergebnisse ist eine gemischte Nutzung aller Modelle nötig
Workflow: Architekt → Entwickler → Reviewer
- Der Workflow besteht aus Architekt, Entwickler und 1–3 Reviewern. Diese sind als OpenCode-Agents (Skill-Dateien) eingerichtet
- Drei Gründe für den Einsatz mehrerer Agents:
- Teure Modelle (Opus) werden für die Planung verwendet, günstigere Modelle (Sonnet) für das Schreiben des Codes, um Tokens zu sparen
- Reviews durch unterschiedliche Modelle erfassen jeweils andere Probleme
- Eine Trennung der Berechtigungen nach Rolle ist möglich, etwa schreibgeschützt vs. schreibend
- Zwei Agents mit demselben Modell und denselben Rechten zu verwenden, ist ungefähr so, als würde eine Person einfach einen anderen Hut aufsetzen – also wenig sinnvoll
- Skill-Dateien werden von Hand geschrieben. Ein LLM Skill-Dateien schreiben zu lassen, ist so, als würde man jemanden „Wie wird man ein großartiger Ingenieur?“ schreiben lassen, ihm diese Anleitung zurückgeben und sagen: „So, jetzt sei großartig.“
Die Rolle des Architekten
- Der Architekt (derzeit Claude Opus 4.6) ist der einzige Agent, mit dem direkt gesprochen wird, und sollte das stärkste Modell sein
- Es wird ein sehr konkretes Ziel für Feature oder Bugfix vorgegeben, und dann findet bis zu 30 Minuten lang ein Gespräch statt, bis Ziele, Einschränkungen und Trade-offs feststehen
- Das Ergebnis ist ein ziemlich detailreicher Plan bis auf Ebene einzelner Dateien und Funktionen
- Es geht nicht um simples Prompting, sondern darum, mithilfe des LLMs einen Plan zu formen. Wenn das LLM falsch liegt oder von meinem Ansatz abweicht, korrigiere ich es häufig; genau das ist der wichtigste Beitrag, der das Projekt „zu meinem“ macht
- Es ist so eingestellt, dass nicht mit der Implementierung begonnen wird, bis ich ausdrücklich das Wort „approved“ sage. Manche Modelle neigen dazu, vorschnell mit der Umsetzung anzufangen, sobald sie meinen, genug verstanden zu haben
- Nach der Freigabe zerlegt der Architekt die Arbeit in Tasks, dokumentiert sie detailliert in einer Plan-Datei und ruft den Entwickler auf
Die Rolle des Entwicklers
- Der Entwickler kann ein schwächeres, aber tokeneffizientes Modell wie Sonnet 4.6 verwenden
- Da der Plan kaum Ermessensspielraum lässt, besteht die Rolle strikt darin, die Änderungen aus dem Plan umzusetzen
- Nach Abschluss der Implementierung werden die Reviewer aufgerufen
Die Rolle des Reviewers
- Jeder Reviewer prüft unabhängig den Plan und den Diff und übt Kritik
- Mindestens Codex wird immer verwendet, manchmal zusätzlich Gemini, bei wichtigen Projekten auch Opus
- Das Feedback geht an den Entwickler zurück; bei Meinungsverschiedenheiten zwischen den Reviewern wird an den Architekten eskaliert
- Opus ist sehr gut darin, das richtige Feedback auszuwählen; Rückmeldungen, die zu pedantisch sind und trotz Aufwand kaum ein reales Problem verhindern würden, werden manchmal ignoriert
Allgemeiner Ansatz und Fehlermodi
- Mit dieser Methode habe ich alle Entscheidungen oberhalb der Funktionsebene im Blick und nutze dieses Wissen für spätere Arbeit
- Wenn das LLM beim Codebestand einen bestimmten Aspekt übersieht, reicht oft die Anweisung „Du solltest Y verwenden“, damit es die Existenz von Y erkennt und auf einen besseren Weg umschwenkt
- Wenn man mit einer Technologie nicht vertraut ist, erkennt man falsche Entscheidungen des LLMs nicht, und darauf stapeln sich weitere Fehlentscheidungen, bis am Ende ein unlösbarer Zustand entsteht
- Ein typisches Fehlermuster ist: Wenn man wiederholt sagt „Der Code funktioniert nicht“, antwortet das LLM mit „Verstanden! Ich repariere das“ und verschlimmbessert es nur noch weiter
- Deshalb versuche ich, selbst bei unbekannten Technologien in der Planungsphase so viel wie möglich zu verstehen
Reale Session: E-Mail-Support für Stavrobot hinzufügen
- Es wird die vollständige kommentierte Session veröffentlicht; Tool-Aufrufe und weitschweifige Passagen wurden ausgelassen, aber Gespräche und Entscheidungsprozess bleiben unverändert
- Erstes Gespräch: Ein hochrangiges Ziel wird vorgegeben („Ich möchte diesem Bot E-Mail-Support hinzufügen“) → Das LLM liest den Code, erkennt das bestehende Muster (eingehender Webhook →
enqueueMessage → LLM-Verarbeitung → Antwort) und stellt Fragen zum Design
- Eingehender Kanal (IMAP-Polling, Webhook, SMTP-Server), ausgehender Kanal, bidirektional oder nicht, Architektur (separater Container vs. in-process), Umgang mit HTML-E-Mails, Thread-Tracking, Anhänge usw.
- Designentscheidungen: eingehend per Cloudflare Email Worker Webhook, ausgehend per SMTP-Client, vollständig bidirektionale Kommunikation, Verarbeitung in-process, Markdown-Konvertierung, Behandlung als unabhängige E-Mails, Unterstützung für Anhänge
- Detaillierter Designvorschlag des LLMs: sieben Bedenken und konkrete Designvorschläge zu MIME-Parsing (
mailparser verwenden), Webhook-Authentifizierung (Shared Secret), Notwendigkeit einer Betreffzeile für ausgehende E-Mails, Umgang mit reinen HTML-E-Mails, Identität der From-Adresse, Verarbeitung weitergeleiteter E-Mails und ausgehenden Anhängen
- Vorgeschlagen wird, die Worker-Payload auf
{ from, to, raw } zu vereinfachen und das Parsing serverseitig vorzunehmen
- Zusammenstellung von Config-Struktur, eingehendem/ausgehendem Ablauf, Liste zu ändernder Dateien und expliziten Non-Goals (YAGNI)
- Verfeinerung des Plans: Der Mensch weist auf fehlende Punkte hin, etwa Updates für README.md und
config.example.toml sowie das Entfernen der E.164-Prüfung von der E-Mail-Allowlist-Seite → das LLM integriert diese Punkte
- Aufteilung in 6 Tasks: Config/Abhängigkeiten, Allowlist, UI/Backend-Validierung der Allowlist, eingehende E-Mail, ausgehende E-Mail, README/Tests
- Zusätzliche Verbesserung: Es wird die Idee vorgeschlagen, SMTP-Felder optional zu machen, damit eingehende E-Mails auch ohne SMTP-Konfiguration funktionieren → umgesetzt
- In der QA entdeckter Bug: Nachrichten wurden verworfen, weil die Eigentümer-E-Mail nicht registriert war → Ursache war, dass
seedOwnerInterlocutor den E-Mail-Kanal ausgelassen hatte → behoben
- Vorschlag zur Codeverbesserung: Statt hart codierter
if-Blöcke pro Kanal soll über eine gemeinsame Kanalliste iteriert werden. Nach Diskussion eines Sonderfalls bei der numerischen Umwandlung für Telegram wurde entschieden, die Schleife nur auf seedOwnerInterlocutor anzuwenden und getOwnerIdentities beizubehalten, da dort die Typunterschiede wesentlich sind
- Wildcard-E-Mail-Allowlist: Unterstützung für Wildcards auf Domain-Ebene in der Form
*@example.com hinzugefügt. Das wird für einen realen Anwendungsfall mit Wegwerf-E-Mail-Adressen benötigt
- Sicherheitsaspekt: Um Angriffe wie
"me@mydomain.com"@evildomain.com zu verhindern, wird * in [^@]* umgewandelt, damit keine @-Grenze überschritten werden kann
- Auch partielle Wildcards wie
myusername+*@gmail.com werden unterstützt
- Der Mensch weist darauf hin, dass bei der Verwendung von regulären Ausdrücken alle anderen Zeichen der E-Mail-Adresse escaped werden müssen
- Es wird bestätigt, dass Wildcards sowohl im Eigentümerfeld als auch in der Allowlist funktionieren; beide nutzen dieselbe Helper-Funktion
matchesEmailEntry
- Die Implementierung des gesamten Features dauerte etwa eine Stunde
Epilog
- Das Setup ist nicht extrem spektakulär, funktioniert aber sehr gut, und es besteht große Zufriedenheit mit der Zuverlässigkeit des Prozesses
- Stavrobot läuft seit fast einem Monat rund um die Uhr und ist sehr stabil
10 Kommentare
Ähnlich wie vor über 20 Jahren, als durch den Boom von Web-Editoren und massenhaft produzierten Blogs unzählige Homepages und Posts entstanden, die niemand las, zeigt sich im Zeitalter der Künstlichen Intelligenz ein ähnliches Bild. Dennoch ist es eindeutig ein großartiger und wertvoller Gewinn, eigene Custom-Apps zu bauen und deren Prozesse oder Routinen zu teilen. Ich persönlich denke, dass es in der heutigen Zeit nicht darum geht, mit Künstlicher Intelligenz Apps oder Services zu entwickeln, die Geld einbringen, sondern die eigenen benötigten Custom-Tools einfach zu erstellen und damit die Produktivität zu steigern.
Eigentlich scheint das bei Menschen auch so zu sein. Ist das nicht vielleicht auch ein Grund, warum Menschen Vielfalt anstreben sollten ...
Da es sich um ein Sprachmodell handelt, ist es richtig, dass ein teures Modell die Planung übernimmt.
> Teure Modelle (Opus) werden für die Planung, günstige Modelle (Sonnet) für das Schreiben von Code verwendet, um Tokens zu sparen
Oft machen es viele auch umgekehrt: Planung mit Sonnet, Implementierung des Codes mit Opus. Hier ist es genau andersherum.
Ich lasse sogar das Planen als Pingpong zwischen Opus und Codex laufen.
Das Coding überlasse ich Opus, und den Code-Review wiederum einem anderen Opus und Codex.
Dabei habe ich das Gefühl, dass sowohl AIs als auch Menschen wirklich gut darin sind, andere zu kritisieren..
https://code.claude.com/docs/ko/…
Ich nutze es auch mit der Modellkonfiguration von Claude auf
opusplaneingestellt.In der Standardkonfiguration von Oh my opencode übernimmt opus die Planung, während die Umsetzung von einem leichteren Modell ausgeführt wird.
In meinem Umfeld nutzen viele Sonnet für Planung/Design und schreiben den Code dann mit GLM-5..
Ich mache die Planung auch mit Sonnet und die Code-Implementierung mit Opus, aber vielleicht ist die Methode des Autors effizienter.
Ich plane auch mit Opus, Reviews mache ich mit Codex high, und das eigentliche Coding lasse ich mit sonet oder codex medium laufen.