- Mit mehreren AI-Agenten (claude/o3/sonnet usw.) wird ein persönlicher „AI-Factory“-Workflow betrieben, der von der Code-Generierung bis zur Verifikation automatisiert
- Wenn Probleme auftreten, werden nicht direkt der Code (Output) angepasst, sondern Plan, Prompts und Agenten-Konfigurationen als Input verbessert – das ist der Kern zur Steigerung des Automatisierungsgrads
- Durch diese wiederholte Verbesserung des Inputs entwickeln sich die Agenten kontinuierlich weiter und maximieren die Produktivität bei wiederkehrenden Aufgaben
- Aufgabenteilung der einzelnen Agenten: Planung (o3/sonnet4), Ausführung (sonnet3.7/4), Verifikation (o3/sonnet4) usw.; so werden Parallelverarbeitung und automatische Feedback-Loops umgesetzt
- Auch Codefehler oder Stilprobleme werden in die Planungsvorlagen zurückgespielt, damit sie ab der nächsten Generierung verbessert werden; durch iterative Input-Verbesserung wächst die Factory selbst
Überblick über die AI Factory und zentrale Prinzipien
- Mehrere claude-code-Fenster laufen in unterschiedlichen git-worktrees, um getrennte Arbeitsumgebungen aufrechtzuerhalten
- o3 und sonnet 4 werden für die Planung genutzt, sonnet 3.7 oder sonnet 4 für die Ausführung, und o3 übernimmt die Bewertung der Ergebnisse
- Planung, Ausführung und Verifikation werden parallel auf verschiedene Agenten verteilt, um die Effizienz zu erhöhen
Zentrales Prinzip – „Statt den Output zu ändern, den Input selbst verbessern“**
- Wenn Probleme auftreten, wird der generierte Code nicht direkt gepatcht; stattdessen werden Plan, Prompts und Agenten-Mix angepasst, um eine automatisierte Verbesserung zu erreichen
- Das Konzept ist, ähnlich wie im Spiel Factorio, ein automatisch wachsendes, fabrikartiges Netzwerk aus AI-Agenten aufzubauen
- In dieser Struktur zirkuliert ein Loop aus Planung, Coding, Verifikation und Verbesserung, der eine Umgebung schafft, in der AI-Agenten selbstständig Code produzieren, prüfen und verbessern
Täglicher Workflow – die Struktur der Factory
- Die Hauptoberfläche ist claude code; lokal kommen mcp, Goose (zur Anbindung von Azure-OpenAI-Modellen), o3 usw. zum Einsatz
Schritt 1: Planung (Planning)
- Eine übergeordnete Aufgabe (Task) wird in claude code eingegeben → o3 stellt zusätzliche Fragen und erstellt anschließend einen Plan (
<task>-plan.md)
- Der Plan enthält sowohl die ursprünglichen Anforderungen als auch den Implementierungsplan
Schritt 2: Ausführung (Execution)
- sonnet 4 prüft den Plan und wandelt ihn in eine Task-Liste um
- claude code führt die Arbeit aus und nutzt je nach Komplexität der Aufgabe sonnet 3.7 oder 4
- Da claude bei jedem Arbeitsschritt Commits hinterlässt, ist bei Problemen ein einfaches Rollback möglich
Schritt 3: Verifikation und Feedback (Verification → Feedback)
- sonnet 4 führt anhand des Plans eine erste Verifikation des generierten Codes durch
- Anschließend verifiziert o3 strenger durch Abgleich mit Plan und ursprünglichen Anforderungen
- o3 weist unnötigen Code (z. B. lint-ignore-Flags) oder veraltete Strukturen streng zurück
- Probleme, die in der Verifikation sichtbar werden, fließen nicht in direkte Codekorrekturen, sondern in die Verbesserung der Planungsvorlagen ein
- Mit git worktree werden mehrere claude-code-Instanzen parallel betrieben, wodurch mehrere Aufgaben gleichzeitig möglich sind
Warum „Input“ wichtiger ist als „Output“
- Ergebnisse (Output) kann man verwerfen, aber Pläne/Prompts (Input) werden fortlaufend angesammelt und verbessert – sie sind ein kumulativer Vermögenswert
- Debugging am Input-Bereich (Plan, Prompts) lässt sich auf alle zukünftigen Aufgaben ausweiten
- Dadurch werden Agenten von bloßen Generatoren zu Akteuren, die selbst lernen und zusammenarbeiten
- Beispiel: Code, der eine komplette CSV in den Speicher lädt, wird auf Stream-Verarbeitung umgestellt; anschließend wird dieses Muster in den Plan für alle CSV-Fälle übernommen, sodass spätere automatische Verifikation möglich wird
Ausbau der Factory und Zusammenarbeit der Agenten
- Über MCP werden spezialisierte Agenten verschiedenen Aufgaben zugewiesen und parallelisiert
- Beispiel: Ein dedizierter Agent sammelt den gesamten Clojure-Code und wendet lokale Stilregeln an; so korrigiert claude Stilprobleme, die im Zyklus aus lint/test/debug entstehen
- Auch in internem Bibliothekscode werden etwa Retry-Logik und
Thread/sleep aus älterem Code durch eine eigene Retry-Bibliothek ersetzt, um Produktivität und Konsistenz zu erhöhen
- Durch den Aufbau vieler kleiner Agenten lassen sich diese für spezifische Teilaufgaben kombinieren, sodass auch komplexe Workflows automatisiert werden können
- Beispiel: Aus API-Spezifikation und Business-Cases werden durch eine Agenten-Kombination Integration, Tests und Dokumentation automatisch erledigt
- Der Kern: den Input fortlaufend anpassen und wiederholt ausführen; bei Fehlschlägen, Stillstand oder fehlendem Kontext wird das Feedback in den nächsten Versuch übernommen und so verbessert
- Der Code selbst ist Verbrauchsmaterial, der eigentliche Vermögenswert sind Anweisungen (Input) und die Agenten-Konfiguration
- Erkenntnisse aus Fehlschlägen, Stillstand oder fehlendem Kontext fließen in den nächsten Input ein und vollenden so den Factory-Loop
Nächste Schritte und künftige Richtung
- Die übergreifende Koordination zwischen Agenten soll gestärkt werden, um den gesamten Workflow besser nachzuverfolgen und weiter zu automatisieren
- Business-Dokumente und Agenteninformationen sollen besser verknüpft und vor allem Informationen auf höherem Abstraktionsniveau erfasst werden, damit sie wirksamer genutzt werden können
- Ziel ist die Umsetzung von immer komplexeren Workflows sowie eine stärkere Zusammenarbeit und komplexere Interaktion zwischen Agenten
- Es werden außerdem Wege gesucht, Token-Kontingente mehrerer Anbieter maximal auszunutzen und leicht zwischen ihnen zu wechseln (insbesondere als Reaktion auf Token-Limits bei bedrock sonnet 4)
Fazit
- In der aktuellen AI Factory sind automatische Code-Generierung und Verifikation Alltag geworden; sogar während einer Kaffeepause kann Code bereit für das Deployment sein
- Vollständig automatisiert ist das Ganze noch nicht, aber das Prinzip „nicht den Output korrigieren, sondern den Input verbessern“ hat sich als Wesen der Factory etabliert
1 Kommentare
Hacker-News-Kommentare
Ich denke, dieser Beitrag ist für Leute, die mit Claude Code noch keinen „Aha“-Moment erlebt haben, fast unmöglich zu verstehen.
Wenn man mit
claude --dangerously-skip-permissionsdie Berechtigungsbeschränkungen aufhebt und ihm ein komplexes Problem überlässt, kann man beobachten, wie Claude frei verschiedenste Tools nutzt, um das Problem zu lösen.Heute habe ich es wieder dazu gebracht, einen Mandelbrot-Fraktalgenerator in 486-Assembly mit Docker selbst zu kompilieren, auszuführen und sogar zu debuggen.
Es hat das wirklich hervorragend erledigt.
Gist-Link
Ich halte das für ein extrem leichtes Beispiel für solche IDEs oder LLMs.
Assembly ist im Trainingsdatensatz reichlich vorhanden, und Docker ebenso.
Ich habe Cursor auch schon frei in meiner Codebasis herumlaufen lassen.
Ich hoffe, dass die neuesten Tools irgendwann wirklich so weit kommen, aber ich habe das Gefühl, dass wir diesen Punkt noch nicht erreicht haben.
Ich möchte zusätzlich dieses Video empfehlen, das Dagger (und der Gründer von Docker) auf der AI Engineer Conference vorgestellt hat.
Auch dieses Video kann etwas schwer zugänglich sein.
Ich schreibe das nur, falls es vielleicht hilfreich ist.
Ich bin bei Claude von Max auf Pro zurückgestuft und die Nutzungslimits für 20 Dollar im Monat sind für mich mehr als ausreichend.
Es scheint mit Gemini CLI zu konkurrieren, daher freue ich mich, jetzt weniger zu zahlen.
Ich denke, diese Größenordnung an Beispielen oder Kontext können fast alle LLMs ohne besondere Schwierigkeiten bewältigen.
Ich habe schon deutlich komplexere Rust-Abhängigkeits-Upgrades erlebt, über 30 Iterationen hinweg, die mit benutzerdefiniertem wasm-Code umgesetzt wurden.
Claude sammelt Details, indem es verschiedene Tools wie context7 oder mcp-lsp verbindet.
Aber wenn man es weiter benutzt, stößt man irgendwann an Grenzen, und sobald man es raffinierter und schwieriger macht, treten die Schwächen zutage.
Zu der Formulierung, dass
claude --dangerously-skip-permissionskomplexe Probleme übernimmt und dabei mehrere Tools nutzt, um sie zu lösen:Ich habe Claude schon dabei zugesehen, wie es über eine Stunde lang versucht hat, Code auf die falsche Weise zu reparieren.
Am Ende musste ich selbst eingreifen und anweisen: „Schreib zuerst Unit-Tests und sag mir dann wieder Bescheid, nachdem du den Code so geschrieben hast, dass die Tests bestehen.“
Claude Code ist wirklich ein beeindruckendes Tool, aber in der Praxis muss man ihm weiterhin immer wieder grundlegende Architekturkarten liefern.
Ich denke, es ist schwer, solche Setups zu bewerten, ohne zu wissen, wie die Code-Ergebnisse tatsächlich verwendet werden.
Wenn es um eine Vibe-Coding-App für den persönlichen Gebrauch geht, klingt das sehr leicht glaubhaft,
aber bei der Behauptung, in komplexen Produktionsumgebungen hochwertigen Code zu schreiben, bin ich nur schwer zu überzeugen.
Stimme vollkommen zu.
Mit Claude Code erhöhe ich meine Coding-Geschwindigkeit deutlich, aber bei jeder Codeänderung prüfe ich immer selbst nach, ob wirklich das bestmögliche System entsteht.
Bei einigen Versuchen, bei denen ich es einfach nur habe laufen lassen, hat es den Nutzern Bugs eingebrockt.
Ehrlich gesagt verstehe ich den in diesem Beitrag beschriebenen Workflow oder die Konzepte nicht besonders gut.
Wahrscheinlich liegt das an der etwas vagen Erklärung.
Ich arbeite im Alltag mit komplexen Produktionssystemen unter Einsatz von Strukturen, in denen mehrere Agenten miteinander sprechen, asynchronen Agenten und git work tree.
Ich ändere die Ausgabe nicht grundsätzlich nie, aber wenn nicht das gewünschte Ergebnis herauskommt, betrachte ich das eher als Signal, meinen Workflow zu verbessern.
Ich probiere gerade einen ähnlichen Workflow aus und möchte meine Erfahrungen teilen.
Die Go-Codebasis, mit der ich arbeite, umfasst mehrere Hunderttausend Zeilen und wird tatsächlich von Zehn- bis Hunderttausenden B2C-Nutzern verwendet.
Leistung ist ausreichend vorhanden, aber es handelt sich um den Finanzbereich, wo Korrektheit und Zuverlässigkeit extrem wichtig sind.
Ich arbeite in einer Umgebung, in der ich nur OpenAI-Keys nutze, und verwende daher nur codex-cli und einfache Skripte für das Basis-Setup wie Repository-Klonen, Agenten-Konfiguration und Prompt-Ausführung.
Die codex-Instanz meldet mir per Systembenachrichtigung, wenn ich dran bin, und bei Bedarf hänge ich mich mit fzf in eine tmux-Session ein.
MCP habe ich noch nicht ausprobiert, aber es steht auf meiner Interessensliste.
Für kleine, verstreute Tasks hilft diese Arbeitsweise enorm, und inzwischen produziere ich viel mehr kleine PRs.
Die Metapher „cattle not pets“ gilt weiterhin; kleine Aufgaben werfe ich einfach schnell als Prompt hinein, um Ablenkung zu reduzieren.
Für größere Arbeiten scheint es noch nicht besonders gut zu passen, vielleicht habe auch ich noch nicht genug Context-Flywheel aufgebaut.
Meist lese ich den resultierenden Code immer selbst und überarbeite ihn, bevor ich ihn zur Code-Review stelle.
Auch das Änderungsmanagement läuft fast vollständig manuell, und Branches, Commits und Pushes mache ich selbst.
Ich habe auch ein paar Automatisierungstools ausprobiert, bin aber noch nicht vollständig dazu übergegangen.
Dem Gedanken „Korrigiere nicht den Output, sondern den Input“ stimme ich zu 100 % zu.
Auch ohne AI ist das ein extrem starkes Prinzip, und die Branche übernimmt es zunehmend.
Bei nichtdeterministischen Prozessen wie LLMs ist es jedoch nicht leicht anzuwenden, und es fühlt sich eher nach Übung als nach Wissenschaft an.
Danke für den guten Beitrag.
Ich stelle in einem Text namens „Vibe Specs“ einen ähnlichen, aber etwas einfacheren Workflow vor.
Zugehöriger Blogaufsatz
Ich verwende diese Regel für die gesamte Codebasis und bringe die AI dazu, zwei Dinge anders zu machen.
(1) Vor allem anderen soll sie zuerst Fragen stellen.
(2) Vor dem Coden soll sie ein Dokument
spec.mderstellen.Die Grundidee ist ähnlich, aber ich beschränke mich auf ein einziges LLM.
Ich glaube, die meisten von uns probieren das auf ähnliche Weise aus.
Als Solo-Entwickler experimentiere ich mit verschiedenster produktionsbezogener Automatisierung aus einer stark engineeringgetriebenen Denkweise heraus.
Mein ultimatives Ziel ist, Vertrauen in den Code daraus zu gewinnen, dass Agenten automatisch e2e-Tests erzeugen, unabhängig von der Implementierung.
Vollständig gelungen ist mir das noch nicht.
Claude Code unterstützt diesen Flow inzwischen auch nativ mit einem „plan mode“.
.md-Dateien manuell anzulegen, fühlt sich ehrlich gesagt langsam und lästig an.Die Grundidee ist, dass man fortlaufend dokumentieren kann, welches Verhalten das System haben soll — sowohl auf hoher Ebene als auch in den Detailfunktionen —, wie dieses Verhalten nachgewiesen werden soll und sogar, wie die Umsetzung aussehen soll, etwa bei Architektur und Code-Stil.
Der Grund, mehrere Modelle zu verwenden, ist, Verzerrungen zu reduzieren und die Auswahl an Feinabstimmungen für bestimmte Aufgaben zu vergrößern.
Irgendwann könnten selbst große, komplexe Systeme auf Grundlage einer Menge von Anforderungen neu gebaut werden, und erst dann würde Software tatsächlich mit den Anforderungsspezifikationen übereinstimmen.
Der einzige verbleibende „Legacy-Code“ wären dann Legacy-Spezifikationsdokumente.
Die Perspektive lautet: Nicht den generierten Code korrigieren, sondern die Anforderungsspezifikation.
Passendes Meme-Bild
Ich frage mich ernsthaft, was hier tatsächlich gebaut wird.
Wenn über AI-Workflows gesprochen wird, ist schwer zu sagen, ob halb träumerische Abläufe gemeint sind oder ob das wirklich produktiv eingesetzt wird.
Wenn LLMs den Code komplett schreiben, verliere ich einfach das Interesse.
Von ungefähr 50 Projekten habe ich nur 2 mit LLMs gebaut, und selbst daran habe ich noch selbst Hand angelegt.
Beim Rest hatte ich nur den Gedanken „Es wäre schön, wenn es das gäbe“, aber am tatsächlichen Ergebnis hatte ich kaum echtes Interesse.
Am Ende steckt man dann in einer Schleife fest, ringt mit mehreren Modellen und Implementierungsdetails und bekämpft den Computer mit Designdokumenten, Prompts und Beispieldaten, wenn nicht das gewünschte Verhalten herauskommt.
Es ist viel schneller und weniger stressig, wenn einem nur schrittweise beim Code ergänzt wird.
Im Rückblick fühlt es sich an, als hätte ich nur Zeit und Geld verbrannt und am Ende Software bekommen, die gerade so läuft.
Wenn es klare Anforderungen oder eine bestehende Codebasis gibt und ich selbst aktiv die Richtung vorgebe, dann sind Agenten durchaus hilfreich, aber Vibe Coding macht mir außerhalb kleiner Skripte oder Nischen-Apps überhaupt keinen Spaß und liefert selten die Qualität, die ich will.
Außerdem ist es übermäßig teuer und der Code bleibt weiterhin unordentlich.
Letztlich fühlt es sich an, als würde ich meine Zeit in endlosen Diskussionen mit dem Computer verlieren.
Dann mache ich es lieber einfach selbst.
Das Problem, das auftritt, wenn mehrere Agenten jeweils in ihrem eigenen work tree arbeiten, ist, dass jeder Agent in allen Details völlig andere Ideen hervorbringt und dadurch die User Experience überhaupt nicht konsistent ist.
Zum Beispiel entwerfen Agenten für ein Documents-Dashboard und ein Design-Dashboard aus völlig unterschiedlichen Perspektiven.
Es gibt weder gestalterische Konsistenz noch strukturelle Einheitlichkeit, und auch DB-Schema und API-Design passen nicht zusammen.
Selbst bei gleichem Input ist der Output unterschiedlich.
Wenn man dann für Konsistenz immer mehr Instruction-Dateien hinzufügt, haben große Projekte schnell standardmäßig ein paar Tausend Zeilen, und dann reicht das Context Window nicht mehr aus.
Letztlich halte ich es deshalb für passender, ein kleines LLM zu verwenden, das nur bestimmte Regeln und Schemata gelernt hat.
Statt eines großen LLMs, das mit Prompting ein ideell universumweites Spektrum an Ideen abdeckt, scheint ein kleines LLM die richtige Antwort zu sein.
Pro Agent völlig unterschiedliche Ergebnisse, keine Konsistenz im Design.
Am Ende braucht man zwingend einen Senior.
Ob AI oder Mensch: Man muss die minimale Struktur und Flexibilität selbst bereitstellen, damit sich alles in die gewünschte Richtung bewegt.
Ohne Struktur ist es viel besser, einfach selbst zu coden.
Ich habe die erste Version selbst gebaut und danach Claude Code einfach gesagt: „Mach es wie dieses Beispiel.“ Damit ließ sich die Konsistenz leichter wahren.
ADHD-artiges Coden, bei dem man blind versucht, ein Produkt zu erzeugen, und so lange iteriert, bis es irgendwie passt?
Wäre es nicht besser, einfach selbst Code zu schreiben, der später erweiterbar ist?
Aus meiner Sicht vergrößert man sonst nur unnötig den CO2-Fußabdruck.
Das Endziel ist, den Entwickler aus diesem Prozess zu entfernen.
Der Business Owner soll eine neue CRUD-App anfordern und sie soll direkt in Produktion gehen.
Klar, das Ergebnis ist voller Bugs, langsam und speichert in einer nicht authentifizierten Datenbank, aber mit der Haltung: Das ist dann nicht mein Problem.
Zum Schluss endet es mit einer drastischen Formulierung, die sinngemäß dem Herunterstürzen von heißem Tee entspricht.
Programmieren hat sich für immer verändert, und man muss diesen Wandel schnell annehmen.
„Schreibt doch einfach den Code“ zu sagen ist, als würde man fordern, dass alle weiter ihre Pferdekutschen selbst warten sollen.
Autos gehen auch kaputt, aber das ist kaum ein Grund, auf den alten Weg zu beharren.
Ich frage mich, warum immer wieder dieses „Schreibt einfach selbst direkt erweiterbaren Code“ aufkommt.
Selbst heutige Coding-Assistenten können in Zero-Shot erweiterbaren und wartbaren Code schreiben; ich würde gern zurückfragen, ob man das überhaupt schon einmal wirklich so angefordert hat.
Auch Menschen finden die Antwort letztlich durch fortwährendes Trial and Error.
Je mehr Erfahrung man hat, desto größer ist nur der Unterschied in der gedanklichen Simulation.
Wenn man schon den CO2-Fußabdruck problematisiert, könnte man genauso fragen, ob es dann in Ordnung wäre, wenn AI-Rechenzentren mit erneuerbarer Energie laufen.
Ich denke, wir müssen Wege finden, AI wirksamer in den Workflow zu integrieren.
Wer AI aktiv eingeführt hat, wird ähnliche Schwierigkeiten erlebt haben, aber eine klare Lösung gibt es noch nicht.
In dieser Phase ist es entscheidend, der AI möglichst kleine Rollen präzise zuzuweisen.
Zum Beispiel kann man für einen Agenten-Workflow zur Aktienrecherche zwei AIs erstellen — „Bullish Guy“ und „Bearish Guy“ — und sie über Vor- und Nachteile einer einzelnen Aktie debattieren lassen.
Wenn man sie so aus gegensätzlichen Perspektiven recherchieren lässt, erhält man umfassendere und zugleich tiefere Analyseergebnisse.
Die Idee dazu kam mir tatsächlich, nachdem ich beobachtet hatte, wie auf Social Media diskutiert wird.
Bei vibe-coding scheint das Ergebnis selten über selbstreferenzielles Gerede hinauszugehen, und letztlich wirkt es wie das nächste teure Hobby nach dem 3D-Druck — eine endlose Beschäftigung mit dem Bauen von Spielzeug.
Ich frage mich, ob die „benchy“-Beispiele im heutigen Vibe Coding nicht am Ende einfach Todo-Apps sind.
Wer Produkte selbst entwirft oder Engineering betreibt, nutzt ihn sowieso.
Der einzige Grund, warum normale Verbraucher ihn nicht verwenden, ist, dass man heute fast jeden benötigten Plastikgegenstand direkt bei Amazon bestellen kann.
Vor dem Zeitalter des Online-Shoppings wäre das für durchschnittliche Menschen viel nützlicher gewesen.
In Zukunft wird es wohl wirklich nur für Menschen eine unverzichtbare Technologie sein, die eigene Custom-Dateien entwerfen können.