Die Ankunft der Software Factory und des Agentenzeitalters
(factory.strongdm.ai)- Das StrongDM-AI-Team vertritt das Konzept einer Software Factory, die hochwertige Software erstellt, ohne den Code anzusehen
- Auf Basis von Spezifikationen/Szenarien schreiben Agenten Code, führen Test-Harnesses aus und konvergieren ohne menschliche Prüfung in einem nicht-interaktiven Entwicklungsmodell
- Code sollte weder von Menschen geschrieben noch geprüft werden, und pro Engineer sollten täglich mindestens 1.000 US-Dollar an Token-Kosten anfallen, damit die Software Factory richtig funktioniert
- Seit der zweiten Überarbeitung von Claude 3.5 (Oktober 2024) beginnen langlaufende agentische Coding-Workflows, Genauigkeit aufzuzinsen statt Fehler zu akkumulieren, was die Möglichkeit nicht-interaktiver Entwicklung bestätigt
- Durch die Erweiterung des bisherigen Testkonzepts um Szenarien (scenario) und Zufriedenheit (satisfaction) wurde ein System aufgebaut, in dem ein LLM die Nutzerzufriedenheit probabilistisch bewertet
- Über das Digital Twin Universe (DTU) werden wichtige SaaS-Produkte wie Okta, Jira und Slack geklont, um Validierung im großen Maßstab durchzuführen; Szenarien lassen sich in Volumen und Geschwindigkeit weit über Produktionsgrenzen hinaus prüfen
- Das Agentenzeitalter verändert die Softwareökonomie grundlegend: Der Aufbau hochgradig originalgetreuer SaaS-Klone, der früher wirtschaftlich unmöglich war, wird nun zur Routinearbeit
Das Konzept der Software Factory
- Spezifikationen (specs) und Szenarien (scenarios) treiben Agenten an, die Code schreiben und validieren, in einem nicht-interaktiven Entwicklungssystem
- Menschliches Schreiben und Review von Code sind untersagt, der gesamte Entwicklungsprozess wird von Agenten ausgeführt
- Die Effizienz wird anhand von mehr als 1.000 US-Dollar täglichem Token-Verbrauch pro Engineer gemessen
- Dieser Ansatz zielt auf den Aufbau einer autonomen Software-Produktionsumgebung, in der Code ohne menschliches Eingreifen automatisch erzeugt, validiert und zur Konvergenz gebracht wird
Der Start des StrongDM-AI-Teams
- Am 14. Juli 2025 wurde das StrongDM-AI-Team gegründet und begann mit Experimenten zur nicht-interaktiven Entwicklung
- Beteiligte: Jay Taylor, Navan Chauhan, Justin McCarthy (Mitgründer und CTO)
- Seit Claude 3.5 (Oktober-Revision) Ende 2024 hat sich die Genauigkeit bei langfristigem Coding verbessert, sodass statt sich wiederholender Fehlerakkumulation aufzinsende Korrektheit (compounding correctness) möglich wurde
- Über den YOLO-Modus von Cursor wurde die Fähigkeit des Modells zu langfristigem Coding besonders deutlich
- Bei früheren Modellen führte die wiederholte Anwendung von LLMs auf Coding-Aufgaben dazu, dass sich Missverständnisse, Halluzinationen, Syntaxfehler, DRY-Verstöße zwischen Versionen, Bibliotheksinkompatibilitäten und alle Arten von Fehlern aufaddierten, bis die App „zusammenbrach“
- Die Kombination aus aktualisierten Modellen von Anthropic und YOLO-Modus zeigte die erste Möglichkeit von nicht-interaktiver Entwicklung oder gewachsener Software
Kernprinzip: Hände weg
- In der ersten Stunde des ersten Tages legte das AI-Team seine Charta fest; das wichtigste Prinzip lautete: „Code darf nicht direkt von Menschen geschrieben werden“
- Anfangs war es vor allem Intuition und Experiment: Wie weit kommt man, wenn man überhaupt keinen Code von Hand schreibt?
- Zunächst stieß man an Grenzen, doch nach dem Hinzufügen von Tests begann der Fortschritt
- Agenten fixieren sich auf unmittelbare Aufgaben und wählen Abkürzungen: Eng formulierte Tests lassen sich mit return true bestehen, ohne dass dies zu der tatsächlich gewünschten Software verallgemeinert
- Einfache Tests reichen daher nicht aus; es braucht eine Ausweitung auf Integrations-, Regressions-, End-to-End- und Verhaltenstests
Vom Test zu Szenarien und Zufriedenheit
- Ein wiederkehrendes Thema im Agentenzeitalter ist der Bedarf an neuer Sprache; das Wort „Test“ ist unzureichend und mehrdeutig
- Im Codebestand gespeicherte Tests können träge passend zum Code umgeschrieben werden, oder der Code wird so umgeschrieben, dass er die Tests nur trivial besteht
- Der Begriff Szenario wird neu gefasst: Er bezeichnet eine End-to-End-User-Story, wird außerhalb der Codebasis gespeichert (ähnlich einem „Holdout“-Set beim Modelltraining) und kann von einem LLM intuitiv verstanden und flexibel validiert werden
- Da die Software, die man wachsen lässt, selbst agentische Komponenten enthält, wird die Bewertung von Erfolg von einem einfachen booleschen Wert auf probabilistische, erfahrungsbasierte Zufriedenheit (satisfaction) verlagert
- Zufriedenheit: Quantifizierung des Anteils beobachteter Verläufe, die alle Szenarien bestanden haben und den Nutzer wahrscheinlich zufriedenstellen
Szenario-Validierung mit dem Digital Twin Universe
- Im bisherigen Modell wurde mit Integrations-, Regressions- und UI-Automatisierungstests beurteilt: „Funktioniert es?“
- Es wurden zwei Grenzen vormals verlässlicher Methoden festgestellt:
- Tests sind zu starr: Da mit Agenten programmiert und LLMs samt Agenten-Loops als Design-Primitiven eingesetzt werden, ist für die Erfolgsbewertung oft ein LLM-as-judge nötig
- Tests sind anfällig für Reward Hacking: Es wird Validierung gebraucht, die weniger anfällig für das Schummeln des Modells ist
- Das Digital Twin Universe (DTU) ist die Antwort: ein verhaltensbezogener Klon der Drittservices, von denen die Software abhängt
- Twins wurden für Okta, Jira, Slack, Google Docs, Google Drive und Google Sheets erstellt; repliziert werden APIs, Edge Cases und beobachtbares Verhalten
- Mit dem DTU ist Validierung in Volumen und Geschwindigkeit möglich, die weit über Produktionsgrenzen hinausgehen
- Auch Fehlermodi, die bei Live-Services riskant oder unmöglich zu testen wären, lassen sich prüfen
- Tausende Szenarien pro Stunde sind möglich, ohne Rate Limits zu erreichen, Missbrauchserkennung auszulösen oder API-Kosten auflaufen zu lassen
Unkonventionelle Ökonomie
- Der Erfolg mit dem DTU zeigt eine von mehreren Arten, in denen der Agentic Moment die Softwareökonomie grundlegend verändert
- Hochgradig originalgetreue Klone zentraler SaaS-Anwendungen zu erzeugen war schon immer möglich, aber wirtschaftlich nicht realisierbar
- Mehrere Engineer-Generationen wollten vollständige In-Memory-Klone eines CRM für Tests, brachten den Vorschlag aber gar nicht erst ihren Managern vor, weil eine Ablehnung erwartet wurde
- Wer eine Software Factory baut, muss bewusste Naivität (deliberate naivete) praktizieren: Gewohnheiten, Konventionen und Beschränkungen aus Software 1.0 finden und beseitigen
- Mit dem DTU wird etwas, das vor sechs Monaten noch unvorstellbar war, jetzt zur routinisierten Alltagsarbeit
Als Nächstes lesenswert
- Principles : Unsere Überzeugungen zur Softwareentwicklung mit Agenten
- Software wird in einer Struktur aus Seed → Validation Harness → Feedback Loop wachsen gelassen, wobei Token als Treibstoff dienen
- Jede Software braucht einen anfänglichen Seed: frühere PRDs oder Spezifikationen, heute reichen auch ein paar Sätze, Screenshots oder eine bestehende Codebasis
- Der Validation Harness muss End-to-End sein und der realen Umgebung (Kunden, Integrationen, Wirtschaftlichkeit) so nahe wie möglich kommen
- Eine geschlossene Schleife, in der Ausgabesamples als Eingabe zurückgeführt werden, ermöglicht Selbstkorrektur des Systems und das Aufzinsen von Genauigkeit
- Die Theorie von Validierung und Feedback ist leicht zu verstehen, die praktische Umsetzung erfordert jedoch kreative, hochmoderne Engineering-Arbeit: Es geht darum, jeden Blocker in eine Form zu übersetzen, die das Modell verstehen kann
- Techniques : Wiederkehrende Muster zur Anwendung dieser Prinzipien
- Digital Twin Universe (DTU)
- Repliziert das äußerlich beobachtbare Verhalten wichtiger Third-Party-Abhängigkeiten
- Validierung in Volumen und Geschwindigkeit weit über Produktionsgrenzen hinaus
- Bietet deterministische und reproduzierbare Testbedingungen
- Gene Transfusion
- Verankert Agenten an konkreten Beispielen und überträgt funktionierende Muster zwischen Codebasen
- Lösungen, die mit guten Referenzen gepaart sind, lassen sich in neuem Kontext reproduzieren
- Filesystem
- Das Modell kann das Repository schnell durchsuchen und seinen eigenen Kontext durch Lesen/Schreiben von Dateien anpassen
- Verzeichnisse, Indizes und Zustände auf der Platte dienen als praktische speicherbasierte Grundlage
- Shift Work
- Trennung zwischen interaktiver Arbeit und vollständig spezifizierter Arbeit
- Ist die Absicht vollständig (Spezifikation, Tests, bestehende App), kann der Agent End-to-End ohne Rückkopplung arbeiten
- Semport
- Semantisch bewusste automatisierte Portierung, einmalig oder kontinuierlich
- Verschiebt Code zwischen Sprachen oder Frameworks unter Wahrung der Intention
- Pyramid Summaries
- Reversible Zusammenfassungen auf mehreren Zoom-Stufen
- Komprimieren Kontext, ohne die Fähigkeit zu verlieren, wieder auf alle Details zu erweitern
- Digital Twin Universe (DTU)
- Products : Tools, die wir täglich nutzen und die auch für andere nützlich sein könnten
- CXDB ist ein selbstgehosteter Context Store für AI-Agenten und bietet Turn DAG, Blob-Deduplizierung, dynamische Typisierung und visuelles Debugging
- StrongDM ID ist ein Identity-System für Menschen, Workloads und AI-Agenten mit Unterstützung für föderierte Authentifizierung und pfadbezogenes Scoped Sharing
- Attractor ist ein nicht-interaktiver Coding-Agent, der als Phasengraph strukturiert ist und End-to-End arbeitet, wenn die Aufgabe vollständig spezifiziert ist
3 Kommentare
Ich habe versucht, mit spezifikationsgetriebener Entwicklung und Multi-Agenten zu entwickeln. Es stimmt zwar, dass sich dadurch viel Arbeit einsparen lässt, aber wegen der Leistungsgrenzen von LLMs kann man keine Produkte bauen, mit denen Kunden zufrieden sind. Ein vollständiger Ersatz ist unmöglich, und ein gewisser Anteil menschlicher Arbeit ist weiterhin nötig.
Ziemlich provokant, aber irgendwie kann ich es auch ein Stück weit nachvollziehen … Irgendwie ist das ein Text, bei dem sich ein seltsames Gefühl einstellt.
Wenn man diesen Text liest und danach den untenstehenden, kann man noch mehr mitfühlen.
Wir betrauern unseren Handwerksgeist
Hacker-News-Kommentare
Ich kann mich mit dem Konzept des Digital Twin Universe identifizieren
Auch meine Codebasis hat viele Integrationen mit externen Diensten, daher ließ sich beim Testen fast nichts verifizieren, wenn man externe Aufrufe blockierte
Deshalb habe ich für jede API Fake-Implementierungen gebaut, etwa für Okta, Jira, Slack und Google Docs
Allerdings habe ich nicht auch noch die UI nachgebaut, sondern nur das API-Verhalten nachgeahmt
Die Aussage, man habe „pro Engineer und Tag noch Luft nach oben, wenn man keine 1.000 $ für Tokens ausgibt“, klingt viel zu realitätsfern
Ich bezweifle, dass das wirklich ernst gemeint ist
Nachgerechnet sind das rund 250.000 $ pro Jahr
Wenn KI tatsächlich so viel Produktivität bringt, könnte das vernünftig sein
Realistisch wäre wohl eher die Effizienz von zwei Junior Engineers
Am Ende werden Menschen wahrscheinlich nur noch die Lead-Rolle übernehmen und Planung sowie Verifikation verantworten
Das ist übertriebener Optimismus, aber nicht völlig verrückt
Ich nutze nur Claude- und OpenAI-Abos für 20 $ im Monat
Wenn die Tokens aufgebraucht sind, gehe ich spazieren oder lese ein Buch
Ich bin kein Akzelerationist, bekomme aber trotzdem genug Arbeit erledigt
Ich bin einer aus dem StrongDM-Team
1.000 $ am Tag für Tokens auszugeben ist leicht, aber der Punkt ist, dass es schwer ist, sie produktiv einzusetzen
Das wirkt wie bloßes Aufschneiden
Als wolle man das Signal senden: „Wir sind bei KI weiter als ihr“
Beim Lesen des Artikels war mir das Ganze peinlich
Es fühlte sich so an, als würden bestehende Mocks und Simulationstests als „Innovation“ verkauft
Trotzdem rechne ich ihnen an, dass sie ihre Kostenstruktur offenlegen
Auf ihrer Website habe ich nach echtem Code oder Produkt gesucht
Das Einzige, was ich gefunden habe, war strongdm/attractor
„Coding mit der kanadischen Freundin“ ist jetzt offenbar ein Geschäftsmodell
Zusätzlich habe ich strongdm/cxdb gefunden, aber die Commit-Historie war bereinigt
Im cxdb-Repository steckt echter Code
Ich weiß nicht, ob das wahnsinnig ist oder ein Blick in die Zukunft
Auf der Products-Seite gibt es auch Datenbank- und ID-Systeme
Wenn mehrere Agenten zusammenarbeiten sollen, sind geteilter Kontext und ein Rechtesystem unverzichtbar
Ich habe ein Webinar zu BoundaryMLs BAML gehört
Spec-driven development ist ein Ansatz, um strukturierte Workflows mit Menschen im Loop zu bauen
Die Schleife
/research → /plan → /implementwird klar definiert, und in jeder Phase findet eine menschliche Verifikation stattDas ist die entgegengesetzte Philosophie zu StrongDMs Behauptung, dass „Menschen weder Code schreiben noch lesen“
Es wirkt wie ein weiterer hohler Blogpost
Es gibt keine greifbaren Ergebnisse, und die Geschichte mit 1.000 $ pro Tag für Tokens klingt wie eine Botschaft an Investoren
Wenn das Verifikationsproblem nicht gelöst wird, ist das alles nur Show
Selbst mit automatisierten Reviews oder Guardrails braucht es am Ende einen Menschen, der die Übereinstimmung von Spezifikation und Ergebnis überprüft
Wir automatisieren bei Speedscale Verifikation über Traffic Capture und Replay
Tatsächlich ist auch menschliche Entwicklung nicht perfekt
Es gibt bereits viele systematische Verifikationsverfahren wie Code Reviews, Tests und QA
Entscheidend ist nicht, ob KI perfekt ist, sondern ob die Qualität des Gesamtsystems konvergiert
Nach meiner Erfahrung gibt es mit Opus 4.5 einen kleinen Nettonutzen
Ich stimme fast vollständig zu
Der Kern ist Verifikation statt Generierung
Ich baue gerade eine Struktur, in der mehrere unabhängige Agenten Meinungsverschiedenheiten offenlegen und zu einem Konsens kommen
Kurz gesagt verlagert man Verifikation und Sicherheitstests auf die Endnutzer
Wir sollten spezifikationsbasierte Sprachen und formale Verifikation viel offensiver einsetzen
Am Ende wird Programmieren neu definiert werden als „das Konkretisieren einer Spezifikation“
1.000 $ pro Tag für Tokens bedeutet, dass man mehr Geld für KI als für Menschen ausgibt
Das sieht wie der Zusammenbruchspunkt der KI-Vision aus
Simon Willison soll den Artikel aktualisiert haben
240.000 $ im Jahr entspricht einem FANG-Berufseinsteiger
Ehrlich gesagt gibt es viele Juniors, die schlechter als Claude sind
Am Ende wird es wohl zu einer Pyramidenstruktur mit wenigen Menschen an der Spitze kommen
Wenn man dieselbe Arbeit in 5 Tagen erledigen kann, könnten Kosten im Verhältnis zur Geschwindigkeit vernünftig sein
Wenn der Output proportional wächst, könnte auch die Effizienz bezogen auf die Kosten stimmen
Außerdem könnten die Tokenpreise noch sinken
Die Rechts- und Versicherungsbranche wird mit diesem Wandel am meisten zu kämpfen haben
Menschliche Fehler lassen sich modellieren, aber Kettenfehler autonomer Loops sind ein völlig anderes Problem
Entscheidungen der KI werden am Ende auf menschliche Verantwortung zurückgeführt
Das dürfte die eigentliche Bremse des agentischen Wandels sein
1.000 $ pro Tag für Tokens ist eine absurde Metrik
Wenn die Codequalität schlecht ist, explodiert der Tokenverbrauch
Am Ende treibt eine unaufgeräumte Codebasis die Kosten hoch
Ein Team, das 1.000 Dollar am Tag verbrennt, dürfte kaum effizient sein
(Siehe auch: dieses Meme)
Das ist eine Frage von kurzfristiger vs. langfristiger Optimierung
Es geht um die Entscheidung, ob man jetzt Effizienz erhöht oder das gesamte System verbessert
Vielleicht erkennen Führungskräfte jetzt endlich die Wichtigkeit von Refactoring
Das Team, das ich früher als Dark-Factory-Pattern erwähnt habe, ist genau dieses
Ich habe einen dazugehörigen Artikel geschrieben, und dieses Team sind die ehrgeizigsten Experimentierer
In der Praxis gibt es aber fast keine Ergebnisse
Wenn man ein paar Studierenden 10.000 $ gäbe, würden sie wahrscheinlich etwas Besseres bauen
1.000 $ pro Tag für Tokens – mit dem Budget meines Teams völlig undenkbar
Auch privat wäre das wegen der Lebenshaltungskosten unmöglich
Am Ende fühlt es sich an wie „wenn man es tut, geht man unter, und wenn man es nicht tut, auch“
Ohne verifizierbare Ergebnisse ist es nur Gerede
Selbst Gerede ist dank LLMs inzwischen viel billiger geworden
Es braucht ethische Transparenz
Die Begriffe auf der Website sind im Grunde nur neu verpackte bestehende Konzepte
„Digital Twin Universe“ sind Mocks, „Gene Transfusion“ ist das Lesen von Referenzcode, „Semport“ ist Transpiling
Es gibt keinerlei echte Daten oder Benchmarks
Ein Fall von AI-Marketing, das als Engineering-Erkenntnis verkauft wird
Tatsächlich liegt der meiste Kerncode bereits auf GitHub
Der eigentliche Unterschied liegt in Mechanismusdesign und Haltung
Die Zukunft wird in der Verbindung von formaler Verifikation und KI liegen
Die Methode, „Szenarien als Holdout-Set zu behalten und damit zu testen“, ist interessant
Das ist die Nachbildung des aggressiven Testens eines QA-Teams
Beeindruckend ist die Trennung zwischen Build-Team und Bug-Find-Team als gegenseitige Wettbewerbsstruktur
Allerdings sind 1.000 $ pro Tag für Tokens für Open-Source-Entwickler niederschmetternd
Mit lokalen Modellen lassen sich die Kosten senken
Wie in diesem Thread gezeigt, ist lokale Agentenautomatisierung durchaus möglich
Vielleicht kommt irgendwann der Tag, an dem Agenten sich gegenseitig bestechen
Ich bevorzuge nach wie vor einen Menschen im Loop
Einfach wahllos Tokens zu verbrennen ist Verschwendung
In meinem Artikel „LLMs aren’t tools“ habe ich das mentale Framework für den Einsatz von LLMs untersucht
Die „Softwarefabrik“ ist der aktuelle Endpunkt, aber der nächste Schritt besteht darin, LLMs als eine Anwendung zu betrachten
Also nicht bloß Workflow-Automatisierung, sondern der Aufbau eines maßgeschneiderten Harness