- 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
- 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
Noch keine Kommentare.