Eine Software-Factory ist eine wiederholbare Schleife rund um Software-Arbeit. Wenn du eine Software-Factory baust, braucht Code, der gut genug zum Ausliefern ist, immer noch menschlichen Geschmack und Verantwortung. Wir werden dies diskutieren, einschließlich der Frage, ob du überhaupt eine Factory brauchst.
Wenn ja:
- Du wirst wahrscheinlich zu Beginn Menschen in der Schleife brauchen, um über die Produktabsicht, das Systemdesign (falls dir das wichtig ist) und deine Qualitätslatte zu entscheiden.
- Überprüfe Code (Licht-an-Factory), aber sei bewusst, wo es am meisten gebraucht wird. Ich habe festgestellt, dass man aufpassen muss, wo der automatisierte Gegendruck nachlässt. Oder wo Kompromisse bei der Wartbarkeit gemacht werden müssen.
- Strebe danach, dass Qualitätsprüfungen so früh und kontinuierlich wie möglich stattfinden. Nicht alle müssen es sein, aber dies umfasst Typsysteme, automatisierte Tests, Mutationstests, Sicherheitsscanner und Linting für Architekturregeln.
- Anzahl der Prüfungen != Qualität. Du wirst wahrscheinlich experimentieren müssen, welche Prüfungen dir das beste Signal-Rausch-Verhältnis geben. Sei bereit, deine Einschränkungen bewusst zu verschärfen oder zu lockern.
Du möchtest deine Factory so bauen, dass einige Aspekte des menschlichen Geschmacks in der Umgebung kodiert werden, der Agent dir Beweise für seine korrekte Arbeit liefert und ein Mensch immer noch "besitzt", was in die Produktion ausgeliefert wird.
Brauchst du wirklich eine Software-Factory?
Meiner Erfahrung nach kommt man mit seinem Standard-Coding-Harness erstaunlich weit! D.h. Claude Code oder Codex, mehrere Sitzungen, gute Spezifikationen mit eingebauter Verifikation und Einschränkungen. Du kannst ihnen sogar einen Stapel von GitHub-Issues mit Implementierungs- und menschlichen Beteiligungskriterien vorwerfen. Claude Code Routinen und Copilot/Codex Cloud Agents geben dir bereits eine geplante oder ereignisgesteuerte Schleife ohne benutzerdefinierte Infrastruktur.
Eine Factory lohnt sich, wenn du wiederholbare, konsistente Läufe brauchst, Arbeit zwischen Agenten übergibst, verhinderst, dass zwei Sitzungen dasselbe Issue bearbeiten, Beweise aufbewahrst und die Produktion anhältst, wenn Reviews im Rückstand sind.
Also habe ich damit begonnen, zu sagen: Eine Software-Factory ist eine wiederholbare Schleife rund um Software-Arbeit. Wir können uns tatsächlich einen Prompt ansehen, der eine sehr kleine Factory-Schleife demonstriert:
Lies GitHub Issue #123 und die Repository-Anweisungen, bevor du Code änderst.
Implementiere nur die angegebenen Akzeptanzkriterien. Ändere keine Authentifizierung, Abrechnung, Migrationen oder bestehenden Test-Assertions. Arbeite in einem Branch und halte den Diff überprüfbar.
Führe npm run lint, npm test und npm run build aus. Wenn eine erforderliche Prüfung nicht ausgeführt werden kann, stoppe und erkläre warum. Öffne einen Draft-Pull-Request mit den von dir ausgeführten Prüfungen, den verbleibenden Risiken und allen Entscheidungen, die ein Mensch noch treffen muss. Führe keinen Merge durch.
Ein Ziel kann dies in Bewegung halten, bis die Prüfungen bestanden sind, und wir können jeden Morgen GitHub Issues auf bestimmte Labels abfragen oder offene Pull-Requests überprüfen. Branch Protection könnte eine Merge-Grenze durchsetzen, und der Mensch kann in der Schleife bleiben, indem er auswählt, was bereit wird, reviewed und die endgültigen Merge-Entscheidungen trifft usw.
Füge eine Software-Factory hinzu, wenn du eine ereignisgesteuerte Warteschlange von Arbeit (z. B. Slack-Trigger, GitHub Issues, Linear, ein Backlog) benötigst, die in einer isolierten Cloud-Umgebung läuft, um Triage, Implementierung und Tests mit etwas explizitem menschlichem Babysitting zu handhaben. Einige beenden ihre Schleife mit einem Monitor-Agenten, der die Produktion beobachtet und Issues erstellt, die erneut triagiert werden.
Meiner Erfahrung nach wird die Factory nützlich, wenn der schwierige Teil darin besteht, deine verschiedenen Läufe konsistent zu machen, Arbeit zwischen Agenten zu übergeben, zu vermeiden, dass verschiedene Sitzungen dasselbe Issue beanspruchen, Beweise aufzubewahren und die Produktion zu stoppen, wenn menschliche Reviews im Rückstand sind.
Was dies löst, klingt vielleicht etwas langweilig. Zum Beispiel erwähnt Warp das Triagieren jedes eingehenden Issues in einen von vier Zuständen - bereit-zur-Implementierung, bereit-zur-Spezifikation, braucht-Info, warte-auf-Implementierung - und das Label ist das, was den nächsten Agenten auslöst.
Dieses Label erledigt mehrere Aufgaben auf einmal: Es ist die Warteschlange, die Sperre, und da eine Sitzung nur aufnimmt, was als bereit markiert ist, ist es der Ort, an dem ein Mensch Dinge parken kann, ohne dauerhaft Nein zu sagen.
Was den Workflow betrifft, gibt es einige Ähnlichkeiten und Unterschiede zur bloßen Verwendung von Claude/Codex:
- Steuerung: Der Agent braucht eine Kurskorrektur, du kannst Input geben und ihn umleiten
- Benachrichtigungen: Wie die Factory sagt, dass sie blockiert ist. Dies kann daran liegen, dass eine Anforderung mehrdeutig war, sie etwas Riskantes gestartet hat oder menschlichen Input (Steuerung) benötigt
- Übergabe: Verschiebe die Aufgabe, ihren Zustand und Kontext zwischen der Cloud-Factory/einem anderen Agenten/menschlichen Reviewer. Gute Übergaben verfolgen, was passiert ist, was noch zu tun ist und warum die Übergabe benötigt wird.
In einer guten Factory ist der Mensch nicht nur darauf beschränkt, den endgültigen Diff am Ende zu reviewen und zu genehmigen. Sie können die Arbeit frühzeitig formen, sie während der Implementierung steuern, sie durch eine Übergabe bringen oder verhindern, dass sie in die Produktion ausgeliefert wird.
Verifikation ist das, womit eine verantwortungsvolle Factory viel Zeit verbringt. Wir werden dies später genauer behandeln.
Wenn du entscheidest, dass du doch eine Software-Factory brauchst, ist der Bau nicht die einzige Option. Die Infrastruktur aufzubauen, um eine Factory zu skalieren, kann viel Arbeit sein, und du solltest in Betracht ziehen, zu kaufen statt zu bauen. Factory.ai, Devin, Warp und HumanLayer verkaufen alle Teile dieser Schleife.
Worauf ich meine Aufmerksamkeit tatsächlich verwende
Meine tägliche Erfahrung mit der Softwareentwicklung hat sich im letzten Jahr stark verändert. Ich habe zunehmend darüber gesprochen, viel parallele Arbeit mit Agenten zu erledigen und mich in Richtung einer Licht-an-Software-Factory zu bewegen. Und viele Leute haben mich gefragt, was diese Dinge eigentlich bedeuten? Was baust du? Welche Arten von Projekten verwendest du für diese Dinge? Es ist vieles davon:
An einem ganz durchschnittlichen Tag habe ich also eine einfachere Licht-an-Software-Factory. Ich kann Aufgaben haben, die in der Cloud laufen. Die Hälfte dieser Aufgaben könnte an Produktions-Client-Anwendungen für kleinere Unternehmen arbeiten, mit denen ich zusammenarbeite. Sie werden echte Benutzer haben. Sie werden echte Authentifizierung, Zahlungen, Abonnements haben, echte dicke Risiken, bei denen man vorsichtig sein muss. Man kann nicht einfach sagen: "Oh, Agent, geh und mach das Zeug", ohne Tests, Einschränkungen und Qualitätsprüfungen.
Ich könnte an meinen Open-Source-Projekten arbeiten. Ich könnte Begleitseiten für meine Bücher erstellen. Ich könnte an Tools arbeiten. Ich könnte meine eigenen Apps bauen. Und das sind alles sehr, sehr unterschiedliche Arten von Anwendungen, an denen ich arbeite. Und manchmal haben sie nur das Tool gemeinsam, das ich verwende, um daran zu arbeiten, oder? Vielleicht arbeite ich an einer Migration. Bei anderen mache ich vielleicht richtige dicke Feature-Arbeit. Und der Schadenradius der Arbeit kann auch sehr, sehr unterschiedlich sein.
Wenn du also anfängst, darüber nachzudenken, an einen Punkt zu gelangen, an dem wir zunehmend viel parallele Arbeit erledigen, versuchen wir, die Geschwindigkeit zu verbessern, versuchen wir, die Produktivität zu steigern, und versuchen wir, die Autonomie zu erhöhen, was bedeutet, das System an einen Punkt zu bringen, an dem wir ihm mehr vertrauen, musst du darüber nachdenken, welche Bereiche unbedingt menschliche Code-Reviews, menschlichen Input erfordern.
Und vieles davon wird am Anfang erforderlich sein, oder? Wenn du deine Spezifikation, deine Anforderungen definierst, wie wird das Design des Produkts aussehen? Wie wird die Absicht des Produkts aussehen? Und wie überprüfst du dann, dass die Agenten die Arbeit tatsächlich richtig erledigt haben? Wie überprüfst du, dass sie das bestehende System nicht kaputt gemacht haben? Wie stellst du sicher, dass es deine Qualitätslatte erfüllt?
Und so ist das Generieren von Code nicht unbedingt der Teil, um den du dir am meisten Sorgen machen musst. Mit genügend Kontext können Agenten die Implementierung schreiben, die Tests ausführen, Fehler inspizieren und Code für uns überarbeiten. Wir müssen an einen Punkt gelangen, an dem wir das Gefühl haben, dass genug menschlicher Geschmack in der Umgebung kodiert ist, dass wir dem, was gebaut wird, vertrauen können, damit unsere menschliche Aufmerksamkeit auf die Bereiche konzentriert werden kann, in denen sie am meisten benötigt wird.
Nun gibt es Gegenwind von Leuten, die sagen: "Hey, ich kaufe dir nicht ab, dass man einfach so vieles davon automatisieren kann." Es soll nicht heißen, dass wir alles davon automatisieren, oder? Aber angesichts der Menge an Code, die generiert wird, glaube ich nicht, dass es realistisch ist, dass Menschen alles davon lesen, besonders wenn wir nicht die ganze Zeit Raketen bauen, oder? Wir bauen UI, wir bauen Full-Stack-Anwendungen.
Unser Urteilsvermögen, unser Geschmack ist am besten auf die Bereiche konzentriert, in denen er am meisten gebraucht wird. Was sind die riskantesten Teile der Systeme? Wo müssen wir menschlichen Geschmack anwenden? Und das kann im Frontend sein. Das kann darin sein, wie das System funktioniert. Es muss nicht 100% davon sein.
Meine kognitive Bandbreite skaliert nicht mit den Agenten
Die Realität ist, ja, wir können jetzt Dutzende, Hunderte, Tausende von Agenten parallel starten, aber deine eigene kognitive Bandbreite skaliert nicht auf die gleiche Weise. Dies kann zu kognitiven oder Verständnisschulden führen, über die ich bereits gesprochen habe.
Wenn du dich an vor nur fünf, zehn Jahren erinnerst, gab es in der Engineering-Community viele Diskussionen über Kontextwechsel und deren Kosten. Wir sprachen darüber, wie Leute es hassten, wenn ein Kollege oder jemand an deinen Schreibtisch kam, während du mitten in einer Aufgabe warst. Es dauerte dann so lange, wieder in deinen Flow-Zustand zu kommen, weil du dich wieder einfangen musstest: Wo war ich? Was habe ich gemacht? Selbst wenn du noch ein bisschen Residuum hattest, hat es trotzdem Zeit gekostet.
Wir wechseln jetzt noch mehr den Kontext als zuvor. An einem bestimmten Tag, wenn ich außerhalb einer Software-Factory arbeite, kann ich an fünf oder zehn verschiedenen Projekten mit Agenten gleichzeitig arbeiten, oder an fünf oder zehn verschiedenen Funktionen an einem einzigen Projekt gleichzeitig. Ich kann fünf oder zehn verschiedene Sitzungen haben, könnte man sagen.
Das bedeutet, dass ich in der Lage sein muss, zumindest ein paar davon im Auge zu behalten. Es ist möglich, dass ich die Autonomie, die ich einigen Aufgaben gebe, erhöhen kann, wenn ich darauf vertraue, dass ich die Aufgabe gut genug definiert habe, das Ergebnis definiert habe, wie es überprüft wird, dass es gut genug gemacht ist. Aber dann wird es Aufgaben geben, bei denen ich das vielleicht nicht unbedingt so empfinde und bei denen mehr Risiko oder mehr Nuancen involviert sind. Ich werde aufpassen müssen.
Erwäge, die Software-Factory für deinen Reviewer zu optimieren. Da jeder dieser Ansätze seine Ausgabe immer noch auf die Aufmerksamkeit einer Person lenkt, solltest du fragen, wie viel billiger die Factory die Entscheidungen macht, die du immer noch treffen musst.
Ein Fehler im falschen Projekt
Ich erinnere mich, als ich an mehreren parallelen Projekten mit meinen Agenten gearbeitet habe, und es gab Zeiten, in denen ich versehentlich Dinge getan habe wie, vielleicht habe ich an einer Web-App gearbeitet, der ich einen Dark Mode hinzufügen wollte, und so hatte ich im Kopf: "Okay, so muss die Form davon aussehen." Aber ich bin versehentlich zu der Sitzung für ein anderes Projekt gegangen und habe angefangen, denselben Prompt einzugeben.
Also begann ich, einen Dark Mode für etwas zu implementieren, das es absolut nicht brauchte. Und so kann ich diesen Fehler machen. Ich möchte nicht, dass meine Software-Factory diese Art von Fehler macht.
Du musst wirklich in Bezug auf ein System darüber nachdenken. Du versuchst im Wesentlichen, eine Software-Engineering-Kultur, eine Teamkultur, in ein System zu kodieren, damit es dieselben Verhaltensweisen hat, damit es eine Verantwortung hat, die irgendwo hingehört, damit immer noch jemand für das, was passiert, verantwortlich ist, und du sehr explizit darin bist, wie du über diese Dinge denkst.
Wenn Grün irreführend ist
Selbst bei diesen Systemen musst du sehr vorsichtig sein, oder? Viele von uns haben gesehen, dass, wenn man KI bittet, beim Bestehen eines Tests zu helfen, wie wir über einen Programmiertest, einen Unit-Test sprechen, sie den Unit-Test ändern kann, um diese Bedingung zu erfüllen, oder sie die Logik des Codes ändern kann, um diese Bedingung zu bestehen. Das bedeutet nicht, dass sie tatsächlich deine Absicht befolgt hat, um sowohl das funktionale Verhalten als auch das, was der Test testen sollte, in Einklang zu bringen, oder?
Nur weil eine Software-Factory anzeigt, dass alles grün ist, heißt das nicht, dass es tatsächlich grün ist, besonders am Anfang, wenn du diese Dinge einrichtest. Du musst viel Aufmerksamkeit darauf verwenden, sicherzustellen, dass deine Prüfungen, deine Verifikationen, alle richtig geformt sind. Sie tun, was du erwartest. Du möchtest nicht, dass sie irreführend sind.
Du möchtest keine Situation, in der du Tests hattest, die sagten: "Hey, eigentlich habe ich geändert, welche Authentifizierungsanbieter unterstützt werden. Du hast mich gebeten, zum Beispiel GitHub als Authentifizierungsanbieter hinzuzufügen, aber hey, meine UI hatte nur Platz für drei, also habe ich einen der anderen fallen gelassen. Und hey, das war zufällig einer, den deine Kunden eigentlich wollten." Du musst also nur sehr explizit sein, wie du möchtest, dass diese Systeme funktionieren.
Übrigens ist Sicherheit auch super wichtig, und wenn deine Factory nicht vertrauenswürdige Eingaben wie ein GitHub-Issue/Slack-Nachricht liest, könnte sie feindselig sein und Probleme wie Supply-Chain-Angriffe enthalten. Einige Produkte rund um Software-Factories, wie Vercel Sandbox/AI ADK Factory, führen ihre Agenten in isolierten Sandboxes aus, die nur die Geheimnisse enthalten, die eine Aufgabe benötigt. Auf diese Weise kann ein kompromittierter Lauf nicht auf das zugreifen, was der Job nicht braucht. Deine Verteidigung ist letztendlich mehrschichtig.
Welche alten Projekte verdienen ein zweites Leben?
Ich denke auch, dass ein großer Teil unserer heutigen Arbeit darin besteht, zu entscheiden, was existieren sollte. Wenn du dich an vor vielen Jahren vor KI erinnerst, gab es so viele verlassene Software-Engineering-Projekte, so viele verlassene Wochenendprojekte, persönliche Projekte, die einfach nicht gestartet wurden, weil wir keine Zeit hatten, sie zu beenden. Wir hatten nicht die Bandbreite, sie zu priorisieren, weil sie uns einfach nicht so wichtig waren oder wir keine Zeit fanden.
Jetzt ist es für uns ziemlich trivial, diese Projekte abzuschließen, aber die gleiche Frage des menschlichen Urteils kommt auf. Verdienen diese Projekte zu existieren? Sollten sie gestartet werden? Denn du bringst sie in die Welt, und selbst wenn es nur fünf Benutzer hat, musst du es vielleicht warten. Vielleicht hast du jetzt eine Qualitätslatte, die du halten möchtest.
Ich weiß, dass ich im Laufe der Jahre so viele GitHub-Projekte hatte, bei denen ich jetzt, wo ich einen Agenten habe, als Erstes dafür sorge, dass das Ding baut. Denn natürlich klonst du es, und jetzt baut es nicht, weil sich alle Abhängigkeiten geändert haben. Die Hälfte der Dinge ist veraltet oder hat überall Sicherheitslücken, also musst du das aktualisieren.
Dann musst du Tests hinzufügen, wenn du keine Tests hattest, damit du weißt, dass das Verhalten zumindest vorhanden sein wird, wenn du das Projekt auf irgendeine Weise aktualisierst oder wenn du es zu einer moderneren Sprache oder einem moderneren Framework oder so migrierst.
Dann fängst du an, dich zu fragen: "Nun, vielleicht, ein dummes Beispiel, aber vielleicht habe ich früher Twitter Bootstrap dafür verwendet, aber jetzt benutzt jeder Tailwind und shadcn, also muss ich die UI neu implementieren." Und was du bemerken wirst, ist, dass dich das plötzlich mehr Zeit kostet, oder? Ja, der Agent kann vieles davon schneller erledigen, aber du musst jetzt Produktgefühl und Geschmack und all diese Dinge einbeziehen.
Du fragst dich immer noch: "Für wen ist das? Hat es einen Markt? Ist es für mich selbst? Ist es für andere? Wenn ich es in die Welt bringe, wird es dann immer noch so interessant sein, wenn jetzt jeder diese Dinge so schnell aufziehen kann?"
Ich denke also, dass diese menschliche Frage, ob diese Dinge es verdienen zu existieren, wie wir unseren Geschmack und unser Urteilsvermögen einbeziehen, ich habe das Gefühl, dass diese Dinge weiterhin extrem wichtig sind. Hier kommt diese knappe Ressource der menschlichen Aufmerksamkeit wirklich ins Spiel. Früher hatten wir nur eine begrenzte Anzahl von Stunden am Tag. Wir hatten Meetings. Wir mussten Zeit für Design und Codierung usw. einplanen.
Jetzt, wo wir Agenten haben, die uns helfen, denke ich, dass du wirklich sehr explizit sein musst, wo und warum du deine Zeit verbringst.
Was passierte, als ich eine Beispiel-Factory baute
Ich werde also über den 82-minütigen Factory-Lauf sprechen. Die Leute fragen mich schon seit geraumer Zeit: "Wie baue ich eine Software-Factory?" Oder: "Ich bin es gewohnt, Claude Code oder Codex zu verwenden. Wie entwickle ich mein Setup weiter, um eine Software-Factory zu nutzen?"
Das erste, was ich gesagt habe, ist: "Du kommst vielleicht gut klar. Deine Arbeit kommt vielleicht völlig ohne Factory aus." Aber ich wollte den Leuten dennoch ein Referenz-Setup geben, das sie sich ansehen können. Also habe ich ein Repository namens Factory zusammengestellt, das du dir ansehen kannst. Ich habe auch eine Demo-Anwendung und einen Workshop erstellt.
In den letzten Jahren war meine Go-to-Demo-Anwendung für viele Dinge eine Filme-App. Ich bin ein großer Filmfan. Ich liebe es, Filme zu schauen. Ich schaue ständig Filme, und so habe ich eine Demo-Anwendung, die wirklich als eine sehr einfache Filme-App beginnt. Und was ich möchte, dass die Factory tun kann, ist, eine Reihe von Funktionen zu implementieren. Es gibt ein paar verschiedene Funktionen. Ich möchte eine Favoriten-Funktion. Ich möchte, dass sie vielleicht eine Suche durchführen kann, und vielleicht möchte ich auch ein dunkles Thema darin haben, solche Dinge.
Also lasse ich meine Factory loslegen und mit diesen Dingen arbeiten. Du kannst dir die Implementierung ansehen. Einer der Vorteile war, dass sie tatsächlich echte Probleme aufgedeckt hat. Diese Probleme wären vielleicht nicht Dinge gewesen, die ich bemerkt hätte, wenn ich sie nur um eine einmalige Implementierung gebeten hätte.
Vielleicht um die 60-Minuten-Marke herum hatte ich das Gefühl: "Wow, das geht ungewöhnlich langsam." Ich fragte meinen Harness mit der Factory: "Warum geht es langsam?" Es sagte: "Das ist völlig in Ordnung. Alle Verifizierer laufen noch."
Du hättest vielleicht erwartet, dass einzelne Aufgaben 10 Minuten, 15 Minuten, 20 Minuten dauern, aber sie können zwei- bis viermal so lange dauern, wenn du beginnst, Verifikation, Wiederholungen, Browser-Checks, menschliche Reviews und all diese zusätzlichen Verzögerungen einzubeziehen.
Ich denke, dass diese sich zu besserer Qualität und besserem Vertrauen in das System summieren können. Aus einer Messperspektive könntest du Metriken wie Kosten pro gemergtem PR und Code-Haltbarkeit als Metriken für Verständnisschulden betrachten.
Du musst auch darüber nachdenken, was eine nützliche Verzögerung im Vergleich zu Factory-Overhead ist. Die Verifizierer haben in meinem Fall einige echte Probleme aufgedeckt. Ein bisschen Zeit wurde vielleicht darauf verwendet, Beweise zu produzieren, die ich wollte. Ein Teil davon war Overhead beim Betrieb der Factory. Ich habe keine Zeit damit verbracht, sie zu optimieren, aber eine Factory, die nur viele Prüfungen durchführt, die du nicht wertvoll findest, bedeutet nicht, dass sie eine hochwertige ist.
Du möchtest studieren, wie bei wiederholten Prüfungen: Sind sie irrelevant? Sind sie verrauscht? Machen sie das System tatsächlich sicherer?
Verifikation braucht ein Budget
Die Art und Weise, wie ich über das Budget für die Verifikation denke, ist im Grunde das, worüber wir sprechen. Wir sprechen über ein Verifikationsbudget. Ich denke darüber auf die gleiche Weise, wie ich historisch über Performance-Budgets gedacht habe.
Es wird bestimmte Arten von Prüfungen geben, die du früh in deinem Softwareentwicklungslebenszyklus durchführen kannst, und es wird einige Dinge geben, die so schwer sind, aber so viel Wert bieten, dass du sie später ausführen möchtest. Es gibt einige Arten von schnellen Prüfungen, Linting zum Beispiel, Typprüfung. Dies sind relativ schnelle Prüfungen, die du früh durchführen kannst.
Unsere vollständige Testsuite kann kurz vor der Erstellung eines Draft-PRs oder danach ausgeführt werden. Dies kann Mutationstests, Browser-Tests, Sicherheitschecks und ähnliches umfassen.
Ich denke, dass du diese nicht unbedingt durch Zusammenfassungen ersetzen möchtest. Du willst echte Tests, aber du musst nur sicherstellen, dass du sie an den richtigen Stellen budgetierst, weil du deine Entwicklungs-Schleife nicht verlangsamen möchtest. Ich möchte meine Entwicklungs-Schleife sicherlich nie verlangsamen. Eine schnelle Iterations-Schleife ist mir wichtig, aber ich möchte dennoch diese Kontrollen und Balancen haben.
Wenn ein Lauf nicht ausliefert
Ein Großteil von dem, was ich oben geschrieben habe, betrifft die Prüfungen.
In ihrer Software-Factory markiert Vercel jeden Agentenlauf als "Erfolg", "fehlerhaft", "blockiert" oder "manuell" und nur "Erfolg" wird in die Produktion ausgeliefert. Der Rest tritt wieder in das System ein. Ich habe über Läufe in ähnlichen Begriffen nachgedacht.
"Fehlerhaft" bedeutet hier, dass das Falsche implementiert wurde oder es vielleicht nicht den vollständigen Kontext hatte, also muss das behoben werden. Blockiert bedeutet, dass der Umgebung möglicherweise eine Berechtigung fehlte, also musst du sie bereitstellen. Manuell ist eine Grenze, die die Factory noch nicht überschreiten darf.
Zwei der drei Dinge hier haben möglicherweise mechanische Korrekturen, und das letzte dreht sich um Vertrauen.
Während dies großartig ist, zeigt dir die Sortierung nicht die Kosten. Zurück zu meiner Factory-Implementierung mit der TMDB-App: Der schnelle Finder ohne Ablehnungen dauerte 7 Minuten. Favoriten, mit zwei Ablehnungen und einer menschlichen Entscheidung dazwischen, dauerte 56. Gleiche Factory. Also würde ich die Taxonomie mit dem Timing pro Phase paaren, sonst weißt du, dass ein Lauf fehlerhaft zurückkam, ohne zu wissen, was dich das Herausfinden gekostet hat. Das andere, was ich beheben würde, ist die Übergabe an der Grenze: Meine Beispiel-Factory stoppte das erste Issue und verschob es zu factory:braucht-info, was richtig war, aber ich wusste nicht, wo ich meine Antwort hinsetzen sollte. Ein manueller Lauf ist nicht beendet, wenn die Factory stoppt, sondern wenn der Mensch weiß, was als nächstes zu tun ist.
Autonomie ist keine einzelne Einstellung
Ich habe vor ein paar Wochen einen Artikel über agentische Autonomie geschrieben und wie man über Autonomie denkt, weil Autonomie keine einzelne Einstellung für jedes einzelne Projekt sein wird.
Verifikation erkauft dir Vertrauen, und sie erkauft die Fähigkeit, deinen Agenten mehr Autonomie zu gewähren. Wenn ich zum Beispiel an einer nicht-trivialen Änderung arbeite, aber eine Reihe von Prüfungen vorhanden sind, alles richtig verifiziert wird und ich es vielleicht selbst von Hand überprüft habe, dann werde ich mich das nächste Mal, wenn ich eine ähnliche Aufgabe im selben Projekt mache, vielleicht wohl dabei fühlen, dem Agenten ein bisschen mehr Autonomie zu geben.
Das ist das Ding, über das du nachdenken musst, wenn du diese Software-Factories baust. Deine Verifikation wird sich mit dem Risiko ändern. Dein Ziel ist das beste Signal-Rausch-Verhältnis. Du willst nicht nur eine große Checkliste haben, die du abarbeitest.
Die Funktion, die ich neu lernen musste
Es gab eine Funktion, die ich aufgeschoben hatte, an einem Tag, an dem ich mehrere Sitzungen mit Claude verwendet habe, und ich habe an ein paar verschiedenen Projekten gleichzeitig gearbeitet, ein paar verschiedenen Funktionen gleichzeitig pro Projekt. Und so hatte Claude die Funktion implementiert, an der ich arbeitete. Es sah so aus, als ob die Tests bestanden wurden. Ich hatte nicht viel über Verifikation nachgedacht, aber die Tests bestanden, und so dachte ich, es funktioniert. Ich habe es gemerged.
Und das war eine Favoriten-Funktion. Ich dachte, dass das eigentlich ziemlich gut war. Ich habe versucht, es im Browser zu überprüfen. Es schien in Ordnung zu sein, aber ein paar Tage später bin ich tatsächlich zum Code zurückgekehrt, weil es einige Anpassungen gab, die ich vielleicht daran vornehmen könnte.
Ich wollte nicht einfach meinen Agenten bitten, die Änderungen vorzunehmen, denn es war eine subtile Sache, wie es funktionierte. Man tippt auf das Symbol, und es zeigte nicht den richtigen Effekt beim Tippen, und ich wollte es einfach anpassen. Ich wollte verstehen, wie es funktioniert, damit ich meinen Agenten richtig anleiten kann.
Ich bin zum Code zurückgekehrt, und ich hätte dir nicht erklären können, wie die Funktion funktioniert. Dieses Repository war meins, oder? Ich hatte die Änderung genehmigt. Ich verstand, wie vieles davon funktionierte, wie ein Großteil des Repos funktionierte, aber mein Verständnis hatte nicht mit dem ganzen Code Schritt gehalten, der sich angesammelt hatte.
Was ich nicht verinnerlicht hatte, war, wie diese hinzugefügte Funktion tatsächlich funktionierte, wie die Benutzeroberfläche funktionierte, wie der Effekt darauf funktionierte. Ich musste diese Funktion neu erstellen und tatsächlich Schritt für Schritt vorgehen: „Wie funktioniert das? Wie kann ich es verstehen?“
Was parallele Arbeit mit dem Verständnis macht
Wenn man parallele Arbeit leistet, verstärkt das dieses grundlegende Problem, und es wird noch verstärkt, wenn man es in einer Softwarefabrik tut. Wenn man fünf oder zehn Sitzungen durchführt, erzeugen sie viel mehr als nur ein Problem mit dem Prüfvolumen. Sie erzeugen mehrere mentale Modelle, die ziemlich kalt werden können, während man woanders arbeitet.
Wir haben in der Vergangenheit über die Herausforderungen des Kontextwechsels gesprochen, und sobald der Chat komprimiert wird, lehnt man einige Ansätze ab, probiert verschiedene Dinge aus, arbeitet mit dem Agenten zusammen, und es wird schwer, sich an alles zu erinnern, was in der Sitzung passiert ist.
Man kann nach oben scrollen, und da die Komprimierung stattgefunden hat, wird nicht alles da sein, und man wird nicht alles im Kopf behalten können. Code bewahrt oft eine getroffene Entscheidung, aber nicht, warum die Entscheidung getroffen wurde.
Das ist etwas, von dem ich denke, dass es eine nützliche Lektion für dich sein kann, bei der es wichtig ist, deinen Agenten zu bitten, tatsächlich Informationen über seinen Werdegang oder interessante Erkenntnisse darüber, wie er ein Problem angegangen ist, zu speichern, damit du später darauf zurückgreifen kannst.
Das kann etwas sein, das du in ein Repository einchecken kannst oder nicht. Du kannst es lokal behalten, wenn du möchtest, du kannst es mit einem Team teilen, wenn du möchtest, aber es kann etwas sein, das später konsultiert werden kann. Anstatt darauf zu vertrauen, dass es vielleicht in einer Sitzung ist oder du dich später vielleicht daran erinnerst.
Was produziert es eigentlich?
@threepointone und @bentlegen haben einige Beiträge über Softwarefabriken veröffentlicht, denen ich voll und ganz zustimmte:
Es ist leicht, sich von der Maschinerie des Tuns faszinieren zu lassen, die Maschinerie zu optimieren und zu vergessen, was sie produzieren sollte. Wenn deine Fabrik hauptsächlich eine bessere Fabrik produziert, hast du Software gebaut, deren Produkt sie selbst ist.
Ich denke, in die Schleife zu investieren, ist in Ordnung und es summiert sich. Das Versagen tritt ein, wenn sich die Schleife schließt, wenn alles, was die Fabrik produziert, von der Fabrik verbraucht wird und niemand außerhalb es bemerken würde, wenn man sie abschalten würde. Der Test, den ich anwenden würde, ist der Sog. Etwas außerhalb muss die Verbesserung verlangen. Wenn du nicht sagen kannst, wer den Sog erzeugt, polierst du nur.
Eigentum verschwindet nicht
Es gibt ein breiteres Prinzip, das dem allen zugrunde liegt.
Der Prozentsatz des Codes, der physisch von Menschen getippt wird, könnte drastisch sinken. Ich glaube nicht, dass das menschliche Eigentum damit sinken muss.
- Jemand wählt immer noch das Problem aus.
- Jemand wählt immer noch die Architektur.
- Jemand setzt immer noch die Qualitätslatte.
- Jemand entscheidet, welchen Verifikationssignalen vertraut werden kann.
- Jemand entscheidet, wann die Beweise ausreichen, um auszuliefern.
Und wenn das resultierende System versagt, ist „der Agent hat es geschrieben“ keine Ausrede. Deshalb glaube ich nicht, dass die Zukunft der Softwareentwicklung am besten als „Menschen verlassen die Schleife“ beschrieben wird. Stattdessen wird menschliches Urteilsvermögen verlagert.
Wir sollten Menschen aus den Teilen der Schleife entfernen, in denen Maschinen stärkere, schnellere, deterministischere Signale erzeugen können. Gleichzeitig sollten wir Menschen dort konzentrieren, wo Kontext, Geschmack, Risiko und langfristiges Eigentum am wichtigsten sind.
Die besten Softwarefabriken werden nicht dadurch definiert, wie vollständig sie menschliche Beteiligung eliminieren.
Sie werden dadurch definiert, wie intelligent sie sie platzieren.
Halte menschliches Urteilsvermögen vorgelagert in Bezug auf Absicht, Systemform und die Qualitätslatte. Überprüfe Code, wo der automatisierte Gegendruck schwach wird oder die Konsequenzen subjektiv werden. Schiebe jedes deterministische Signal so früh und kontinuierlich wie möglich in die Schleife. Ziehe Einschränkungen bewusst an oder lockere sie, je nachdem, ob das System Vertrauen gewinnt oder verliert.
Ein Mensch muss immer noch dafür verantwortlich sein, welcher Code letztendlich ausgeliefert wird. Code, der gut genug zum Ausliefern ist, beginnt immer noch mit jemandem, dem es wichtig ist, ob er existieren sollte.
