Eine Softwarefabrik nutzt Loops in großem Maßstab. Du kannst den Loop mit Menschen betreiben (helle Fabrik): Du tauschst Urteilsvermögen und Konzentration gegen Geschwindigkeit und Bruchstellen. Oder du ignorierst die Menschen (dunkle Fabrik) und lässt die Agenten coden, bauen und ausliefern, ohne dass jemand wirklich die Details liest. Aber wenn die Leute aufhören zu lesen, hören sie auf, deine Software zu verstehen. Deine schwierigste Aufgabe ist jetzt zu wissen, welche Checks du einbauen und wie viel Autonomie du delegieren musst.
Die Idee der Softwarefabrik ist ein Begriff, der auf Bob Bemers Aufsatz "The economics of program production" von 1968 zurückgeht. Ein halbes Jahrhundert lang haben viele von einer Welt geträumt, in der Software ein wiederholbarer und messbarer Produktionsprozess ist (vergleichbar mit dem Ausstanzen von Autoteilen in einer Fabrik) und nicht das isolierte Handwerk Einzelner. Historisch gesehen ist dieser Traum meist (wenn auch nicht immer) gescheitert, unter anderem wegen der Schwierigkeit, Ideen auszustanzen.
Aber in den letzten zwei Jahren haben sich die Dinge so dramatisch verändert, dass es jetzt sinnvoll ist, den alten Traum neu zu betrachten. Und da manche Feinheiten leicht übersehen werden können, lohnt es sich, etwas genauer zu sein, was genau wirklich neu und anders ist und was sich als wiederkehrende Fallstricke tarnen könnte, die als neue Chancen daherkommen.
@dexhorthy, Mitbegründer von HumanLayer, hat kürzlich auf der AI Engineer World's Fair einen großartigen Vortrag mit dem Titel "Harness Engineering is not Enough: Why Software Factories Fail." gehalten, der sich zu diesem Thema lohnt.
Der Loop ist das Atom. Die Fabrik ist der Loop im großen Maßstab.
Struktur ist alles, und alles beginnt mit kleinen Einheiten. Der gesamte Stack besteht eigentlich aus drei Konzepten, die übereinander liegen: dem Loop, dem Harness und der Fabrik.
Ein Loop ist ein Agent, der eine einzelne Aufgabe wiederholt ausführt: Kontext sammeln, eine Aktion durchführen, das Ergebnis prüfen und wiederholen, bis eine Bedingung erfüllt ist. Es ist die kleinste Einheit agentischer Arbeit, und alles darüber ist nur ein Stapel von Loops.
Der Sinn des Loop Engineering ist, dass du aufhörst, den Agenten Schritt für Schritt zu prompten, und stattdessen das kleine System entwirfst, das ihn für dich promptet.
Ein Harness ist die Begrenzung um einen Loop: die Sandbox, in der er läuft, die Werkzeuge, die er erreichen kann, der Speicher, der zwischen den Durchläufen überlebt, und die Tore, die entscheiden, was "erledigt" bedeutet. Der Loop ist das Verhalten; der Harness ist die Umgebung, in der dieses Verhalten abläuft.
Gib einem rohen Modell keinen Harness, und es wird fröhlich ewig weitermachen. Der Harness ist alles darum herum, was es nützlich und sicher macht.
Eine Softwarefabrik ist eine Vielzahl von Loops mit Harness, die gleichzeitig laufen, gespeist von einer Aufgabenwarteschlange und durch ein Review-Tor in die Produktion entlassen, wobei der Mensch das Ganze von oben steuert. Es ist kein größerer Agent; es ist ein Organigramm aus Loops.
Der letzte Paradigmenwechsel ist der Weggang vom Schreiben von Code hin zum Bauen und Betreiben der Fabrik, die den Code schreibt. Die Arbeitseinheit steigt eine Ebene nach oben, zum Loop, zum Harness und zum Fluss zwischen ihnen, anstatt zum einzelnen Code-Diff.
Loop → Harness → Fabrik. Eine Fabrik ist kein schlauerer Agent; es sind viele Loops mit Harness, die ein einziges Review-Tor speisen, wobei ein Mensch den äußeren Loop besitzt. Die gezeichnete Fabrik
Die zentrale Folie, mit der Dex sich am meisten beschäftigte, war brillant, weil sie ein klärendes Verbindungsdiagramm ist, das visualisiert, was sonst ein offensichtlicher Loop wäre. Hier ist meine Interpretation davon:
Die Fabrik ist ein geschlossener Kreislauf: Absicht und Produktionssignale speisen eine Warteschlange, der Harness baut, automatisierte Prüfungen und das Review-Tor prüfen, das Deployment liefert aus, das Monitoring verwandelt die Produktion zurück in Signale. Die Absicht fließt aus der Vision der Engineering-Führung und direkt von den Ingenieuren in eine Warteschlange von zu erledigenden Aufgaben. Signale, die von Vorfällen und Benutzeranfragen ausgelöst werden, treiben dieselbe Warteschlange an.
Der Harness ist einfach das Ding, das einen Eintrag aus der Warteschlange nimmt und eine Änderung dafür baut. Jenseits des Harness sehen wir all die automatisierten Prüfungen, die nötig sind, um Änderungen sicher genug für die Produktion zu machen. Diese automatisierten Prüfungen laufen gleichzeitig und mühelos, ohne bewusstes Zutun der Ingenieure, dank CI, Tests, statischer Analyse und Scans aller Art. Der einzige Entscheidungspunkt hier ist das Review-Tor. Nach der Freigabe werden Änderungen deployed und in der Produktion überwacht, wobei die Überwachungsdaten zurück in die Signale fließen, die den Kreislauf ursprünglich in Gang gesetzt haben.
Im Großen und Ganzen ist fast jedes Kästchen in diesem Diagramm nahezu kostenlos: Generierung, Tests, Scans. Sie alle laufen im großen Maßstab zu vernachlässigbaren Kosten. Es gibt nur ein teures Kästchen, das sich hartnäckig der Skalierung widersetzt, und das ist das Review-Tor. Dieses glänzende amberfarbene Kästchen steht für "Urteilsvermögen", und hier liegt der Kern der Argumentation, ob wir die Entwicklung schneller und häufiger machen können.
Warum wir es "dunkel" nennen
Eine dunkle Fabrik läuft bei ausgeschaltetem Licht, weil die einzigen Dinge auf dem Boden Maschinen sind und Maschinen kein Licht zum Sehen brauchen. Eine dunkle Softwarefabrik macht den gleichen Schritt: Code wird ausgeliefert, den kein Mensch gelesen hat, der nur von anderen Maschinen verifiziert wurde.
Das Bild ist aus der Fertigung entlehnt. Seine Ursprünge sind physisch, nicht digital, und wurzeln in Anlagen, in denen das Licht ausgeschaltet ist und die Arbeit von Robotern erledigt wird. FANUC in Japan betreibt solche Dark Factories seit 2001; Xiaomi hat 2024 eine eigene hochautomatisierte Dark Factory eröffnet. Was sie gemeinsam haben, ist ein Produkt, das montiert und versandt wird, ohne dass ein einziger Mensch es gelesen hat. Das "Dunkle" kommt ins Spiel, wenn dieser Lesevorgang aus dem Prozess entfernt wird.
Ich übernehme das Konzept nicht wegen seiner Stimmung oder als Beleidigung. Bei all seinem gruseligen Buzz steht "dunkel" hier für eine einfache physische Behauptung: der ursprüngliche Fabrikboden, aber ohne Licht. In der Software ist der Boden der Diff. Wer auch immer den Diff geschrieben, wer ihn reviewed, wer ihn ausgeliefert hat – diese Menschen sind weg, und was bleibt, ist ein Diff, der nur von den Maschinen verifiziert wurde, die ihn gebaut haben.
Das ist überraschend einfach zu bewerkstelligen, zumindest anfangs. Es ist einfach, weil dieser fehlende Review-Schritt allem im Weg steht. Seine Abwesenheit lässt den vertikalen Durchsatz deines Teams plötzlich und radikal höher erscheinen. Es fühlt sich an, als hättest du die Schallmauer durchbrochen. Trotz aller scheinbaren Leichtigkeit ist es schwerer, diese dunklen Workflows mit ihren versteckten Kosten zu überleben.
Harness Engineering ist nicht genug
Der Harness aus Orchestrierung, Sandbox-Prototyping und Tool-Aufrufen, während Modelle mit der Welt und miteinander interagieren, wird immer leistungsfähiger und effektiver werden. Es gibt jedoch ein inhärentes Versagen im Modell, wenn es darum geht, langfristig und durch inkrementelle Änderungen mit der Codebasis-Qualität Schritt zu halten, und ich glaube, es gibt gute Gründe anzunehmen, dass Modelle allein diesen Kampf gegen die Verständnisschuld letztlich verlieren werden.
Verständnisschuld ist die wachsende Kluft zwischen der Menge an existierendem Code und dem, was ein Mensch noch versteht. Eine dunkle Fabrik baut diese Schuld nicht ab; sie nimmt sie so schnell auf, wie sie kann, und die Tests bleiben die ganze Zeit grün.
Das ist eine wichtige Unterscheidung, weil Modelle bei manchen Aufgaben gute Arbeit leisten. Aber für alles, was keine sofortige Änderung an einem kleinen Teil einer Codebasis ist, insbesondere in einem komplexen Brownfield-System, steht das reine KI-gestützte Coden vor einem unüberwindbaren Hindernis. Greenfield-Apps, Wochenend-Spielereien und Nebenprojekte haben gemeinsam, dass ein paar Monate Entwicklungszyklen normalerweise ausreichen, um die Dinge zum Laufen zu bringen, oder zumindest nahe dran.
Aber ein Unternehmenssystem, das seit einem Jahrzehnt oder länger entwickelt wird, ist ein anderes Biest; es muss gewartet werden, in einer professionellen Umgebung mit professionellem Tempo. Drei bis sechs Monate nach Projektstart ertrinkst du bereits in ungelesenem Code. Eine solche Umgebung, und insbesondere die Zwänge, die durch Produktionscode entstehen, würden selbst einen leistungsstarken Agenten schlecht abschneiden lassen, alles im Gegensatz zum Vibe-Coding, das Entwickler bei Wochenend-Spielereien genießen.
Dex berichtet aus Erfahrung, dass dies ein großes Versagen ist, so sehr, dass es mühsames manuelles Debuggen erforderte, um es zu identifizieren. Dies ergab sich aus dem Betrieb einer vollautomatisierten Codefabrik über etwa vier Monate, in denen kein Mensch den geschriebenen Code ansah. Dem Erlebnis liegt ein Trade-off zwischen zwei widersprüchlichen Metriken zugrunde. Die eine ist die Maximierung der Token-Auslastung, die Zahl, die wir derzeit als Fortschritt behandeln. Die andere, die stillschweigend minimiert wird, ist das Maß an Verständnis des Systems, das jeder menschliche Teilnehmer zu jedem Zeitpunkt noch hat.
Wo die dunkle Fabrik wirklich glänzt, ist ihre Fähigkeit, makellosen Code zu verbrennen, während die Tests grün bleiben. Die ultimative Abrechnung wird, wenn sie kommt, kein dramatischer Moment sein, in dem "alles schiefgeht". Sie wird leise und spät kommen.
Dunkel und hell sind dieselbe Pipeline, nur mit dem Licht an verschiedenen Stellen. Die helle Version fügt nicht einfach am Ende ein Review wieder hinzu – sie verlagert das menschliche Urteilsvermögen auch vorgelagert in Design und Architektur. Der Engpass war nie die Generierung
Die grundlegende Einschränkung in einer Softwarefabrik ist nicht, wie viel Code wir produzieren können: Es ist, wie schnell wir ihn verifizieren können.
Gegendruck ist die Regel, dass du einem Loop nur so viel Autonomie geben kannst, wie du billig und zuverlässig verifizieren kannst, und nicht einen Zentimeter mehr. Verifikation, nicht Generierung, ist die eigentliche Einschränkung einer Fabrik.
Weil die unbegrenzte Generierungskapazität in ständiger Spannung mit der endlichen, nicht skalierbaren Ressource der menschlichen Aufmerksamkeit steht, ist das Kernproblem die Lücke zwischen billiger Generierung und begrenztem Review. Schau dir den Trichter an: Solange sich der Hals, der die Verifikation darstellt, nicht verbreitert, wird sich ein Rückstau bilden. Wie Dex betont, ist das Volumen allein nicht das Problem: Was wir wirklich haben, ist ein Überangebot an schlechten PRs. Wenn du hohes Volumen ohne vertrauenswürdige Tore hast, sind hergestellte Defekte unvermeidbar. Das ist wieder nur Gegendruck: Autonomie kann nicht über das hinausgehen, was billig und zuverlässig verifiziert werden kann.
Das Problem zweiter Ordnung ist, warum die Verbesserung des Modells nicht automatisch die Lücke zwischen dem, was es generieren kann, und dem, was verifiziert werden kann, schließen sollte. Das Training auf gut architekturierten Systemen ist eine argumentativ schwierigere Aufgabe als das Bestehen einfacher Tests: Denk daran, die Kostenfunktionen, die architektonische Exzellenz messen, werden nicht in Sekunden oder Minuten gemessen, sondern in Monaten und Jahren. Saubere Gradienten sind funktional unmöglich zu berechnen, daher wird ein System, das eine klare, sofortige Bewertung komplexer Designentscheidungen erwartet, nicht mit guten Beispielen trainiert werden.
Generierung ist ein breiter Mund; Verifikation ist der enge Hals. Den Mund zu beschleunigen vertieft nur den Stau am Hals.
Das Licht wieder einschalten
Eine helle Fabrik ist dieselbe Pipeline, aber mit eingeschaltetem Licht, wo das Urteilsvermögen sitzt. Die Agenten erledigen immer noch den Großteil des Bauens, aber ein Mensch liest, was herauskommt, bevor es ausgeliefert wird, und das Licht bleibt an, wo immer ein Fehler teuer wäre.
Die helle Version hängt das Review nicht einfach ans Ende an, sondern verlagert den Punkt des menschlichen Urteilsvermögens vorgelagert, zum Produkt, zum Design und zur Architektur, bevor ein Agent einen Loop startet.
Das Tolle an dieser vorgelagerten Stunde ist, dass sie zu weniger Implementierungsstunden führt. Sie verwandelt ein langes, frustrierendes Code-Review in ein schnelles Lesen eines Zweihundert-Zeilen-Plans. Du reviewst eine Entscheidung, bevor sie gebaut wird, so dass du später nicht durch zweitausend Zeilen generierten Codes jagen musst, um herauszufinden, was die Entscheidung überhaupt war. Manche Entscheidungen sind teuer und langlebig genug, dass du eine Person frühzeitig einbeziehen möchtest, bevor sich die Kosten vervielfachen. Natürlich gibt es immer noch Zeiten, in du dir Diffs ansiehst, selbst wenn du vorab Zeit investiert hast.
Du denkst vielleicht, das klingt alles unglamourös. Du hast recht. Das Sicherheitsnetz besteht aus ganz gewöhnlichen architektonischen Praktiken, die wir schon immer kannten und meist ignoriert haben: gute Typen und Methodensignaturen, damit Fehler vom Compiler statt in der Produktion gefangen werden; Test-Nähte, an denen wir Verhalten festhalten und Änderungen beobachtbar machen können; den Code so anordnen, dass der nächste Leser, ob Mensch oder Modell, weiß, wo er das findet, was ihn interessiert; Call-Stacks kurz und lesbar halten; Komponentengrenzen gut definiert halten, damit eine Änderung keinen großen Explosionsradius hat; und Dependency Injection, damit wir ein Teil gegen ein anderes austauschen können. Nichts davon ist neu. Wir haben immer gesagt, dass uns gute Architektur wichtig ist. Aber jetzt, wo wir automatisierte Coding-Agenten einsetzen, leistet diese Architektur endlich einen zweiten Dienst als billiges und schwer zu fälschendes Sicherheitsnetz gegen die Fehler, die der Agent machen wird.
Dieses Sicherheitsnetz muss außerhalb des Modells existieren, weil das Modell es nicht liefern wird. Die Coding-Agenten, die sich am leistungsfähigsten anfühlen, darunter Claude Code und Codex, sind durch Reinforcement Learning gegen ihren eigenen Harness und ihre eigenen Werkzeuge trainiert: fließend im Umgang mit allen Werkzeugen und Idiomen des Handwerks, aber nicht mit Dingen wie langfristiger Wartbarkeit. Die bewusste Architektur, über die wir immer gesprochen haben, ist das Werkzeug, das diese Schuld einfängt, und die Investition, die wir darin tätigen, ist der Kauf unserer Autonomie zurück.
Kombiniere das mit einer sicheren Infrastruktur, und du bekommst einige enge, risikoarme Loops, die du unbeaufsichtigt laufen lassen kannst. Horthy hat das in einem kürzlichen Beitrag beschrieben: ein nächtlicher GitHub Actions Cron-Job, der genau ein Anti-Pattern behebt, eine Lint-Verletzung oder ein unnötig optionales Prop, committet und einen einzelnen kleinen Pull Request öffnet, ganz von allein, so dass das Team mit einer etwas besseren Codebasis und einem Diff aufwacht, der kurz genug zum Lesen ist. Aber bei Loops mit hohem Risiko willst du nicht riskieren, mit einem kaputten Auth-System, einer Abrechnungs-Engine oder einem öffentlichen API-Vertrag aufzuwachen. Lass das Licht dort an, und vertraue darauf, dass eine Person mit Urteilsvermögen und echtem Fachwissen über das System den Fehler bemerkt.
Was einen Loop verdient, dunkel zu sein
Diese Regel gilt, ob du es Gegendruck, Verifikation oder den Lichtschalter nennst.
Ein Loop kann sich den vollautomatischen Status nur verdienen, wenn der Check billig ist, mit hoher Frequenz läuft und auf etwas basiert, das nicht leicht gefälscht werden kann. Grün-Rot-Orakel, Typ-Gates, Property-Tests und ein Review-Agent gepaart mit einer echten Rubrik fallen alle darunter. Du brauchst auch, dass das Orakel sofort antwortet und nicht im Laufe der Zeit abweicht. Wenn "erledigt" nicht nur von dir, sondern auch von einer Maschine nachgewiesen werden kann, hast du die Automatisierung erreicht.
Kurze Loops sind einfacher zu verifizieren als lange. Dex' Faustregel: Ein Agent hält drei bis zehn Schritte durch, beginnt dann nach zwanzig Schritten den Faden zu verlieren. Der Grund ist die Kontextakkumulation: Je mehr der Agent mitschleppt, desto wahrscheinlicher schweift er ab. Wenn ein Loop kurz ist, ist die Verifikation billig. Ausufernde Loops verstecken Fehler in den Ecken, was eine andere Art zu sagen ist, dass sie sich den Dunkelstatus nie verdient haben.
Das Licht anzulassen ist der gegenteilige Fall. Ein Loop muss reviewed werden, wenn eine falsche Antwort teuer ist und nur eine Person sie fangen kann. Subtile Produktionsfehler, die nicht durch Tests abgefangen werden können, große Explosionsradien und eine Entscheidung, die die Arbeit eines Jahres oder länger prägen wird, qualifizieren sich alle. In diesen Fällen ist deine Aufmerksamkeit das eigentliche Produkt, das kostspielige, wesentliche.
Die Gefahr ist, zu vergessen, jeden Schalter umzulegen und sie einfach alle auf denselben Modus zu stellen. Alles dunkel, und du steckst vier Monate später fest, alles wieder abreißen zu müssen. Alles hell, und niemand kann die Reviews rechtzeitig erledigen, und du steckst in einem gigantischen Engpass. Die schwierige, qualifizierte Aufgabe ist zu entscheiden, wo jeder Schalter hingehört.
Loops, Graphen oder Zustandsmaschinen?
Du solltest "State machines in 2 minutes" von @DavidKPiano lesen.
Wenn du einem Agenten eine Aufgabe gibst, wirst du wahrscheinlich einen Graphen darum herum bauen, ob du diesen Graphen nun eine endliche Zustandsmaschine oder eine Menge bedingt verknüpfter Service-Aufrufe nennst. Es ist ein Rahmen, in dem die Software nicht nur einigen abstrakten Regeln folgt, sondern einem strukturierten Workflow: jeder Knoten ist ein expliziter Schritt, und jede Kante zwischen Knoten ist eine explizite Bedingung.
Das klingt nach viel Struktur, aber das meiste davon ist in jeder Software bereits vorhanden, da jeder Code als Kontrollflussgraph ausgedrückt werden kann. Die einzige wirkliche Neuerung ist also, dass ein Agent, der auf Autonomie besteht, wirklich nur auf einem bestimmten Graphen herumläuft, und seine Freiheit auf das Innere eines Knotens beschränkt ist. Und hier ist der Teil, den die Leute vergessen, den Dex vor einem Jahr aufgeschrieben hat: Software hatte diese Struktur schon immer. Es gibt einen Grund, warum wir Programme früher als Flussdiagramme gezeichnet haben.
Der wirklich neue Schritt war der Versuch, das Diagramm wegzuwerfen und sich auf einen Loop zu verlassen, in dem das Modell den Pfad Tool-Aufruf für Tool-Aufruf wählt, bis es sich selbst für fertig erklärt. Das fühlte sich wie Befreiung an, bis es auf eine zehn Jahre alte Codebasis traf, und die Disziplin, die jetzt alle wiederentdecken – die Kontrolle über den eigenen Kontrollfluss zu übernehmen – ist wirklich nur das Zurückführen des Graphen um den Loop herum. Die Frage, ob wir von Loops zurück zu Graphen wechseln sollten, ist fast ein Eingeständnis, dass wir das Flussdiagramm die ganze Zeit gebraucht hätten.
So sieht es in der Praxis aus. Nimm einen zu behebenden Fehler. Als reiner Loop setzt du dich hin und denkst: Finde heraus, was falsch ist, ändere etwas Code, führe die Tests aus, schau, was passiert, und wenn diese Runde den Durchlauf nicht beendet, gehe zurück zum Anfang und beginne von neuem. Die gesamte Reise wird während des Gehens entschieden: welches Problem du verfolgst, der genaue Code, den du änderst, welche Tests du in welcher Reihenfolge ausführst, ob du überhaupt Tests ausführst und ob du es erneut versuchst oder den Sieg erklärst.
Als Graph ist das Erste, was du tust, zu planen, was passieren soll. Reproduziere den Fehler oder fordere weitere Informationen an, finde die Ursache, versuche eine Lösung, führe die Tests aus, und lasse einen fehlgeschlagenen Durchlauf zurück zur Lösung führen, während ein bestandener Durchlauf zum Review übergeht, wo nur eine Freigabe den Zustand "erledigt" erreicht. Der Agent ist immer noch klug innerhalb jeder Box; er kann nur nicht von den von dir genehmigten Pfaden abweichen. Santi hat das mit einem Diagramm dargestellt, das den Unterschied deutlich macht.
Der wahre Reiz dieses Graphen ist natürlich, dass er Gegendruck als Diagramm gezeichnet ist. Du gibst einen Teil der Freiheit des Agenten auf und bekommst dafür obligatorische Checks und lesbare Fehlerpunkte, so dass du, wenn ein Durchlauf stirbt, auf den Knoten zeigen kannst, der ihn getötet hat. Es ist derselbe Instinkt hinter Dex' klarer Aussage, dass die meisten sogenannten Agenten überhaupt nicht sehr agentisch sind, "meist deterministischer Code, mit LLM-Schritten, die an den genau richtigen Stellen eingestreut sind." Und das ist nicht nur ein Artefakt davon, wie die Leute gerade Dinge bauen: du kannst das Muster in LangGraph und LlamaIndex Workflows sehen, in Jerry Lius hybridem Workflow-Graph-über-Agenten mit einem äußeren Loop, der Teile des Graphen während des Laufs wachsen lässt, und in David Khourshids Erinnerung, dass dies wirklich nur Zustandsmaschinen und das Actor-Modell sind, die in neuen Kleidern auftauchen.
Eine Klarstellung, weil der Begriff stark überladen ist: Wenn ich das immer wieder einen Graphen nenne, meine ich keinen Wissensgraphen. Ich meine einen vordefinierten gerichteten Graphen, wie die Arbeit fließen soll, mit bedingten Kanten und allem, der dem Loop eine Form gibt, der du vertrauen kannst.
Wo der Mensch tatsächlich hingeht
Beachte, dass die Person die Fabrik nie verlassen hat. Sie hat sich nur bewegt.
Ich denke, Ingenieure sollten zunehmend den äußeren Loop besitzen. Die Agenten können einen Fehler untersuchen, die Diagnose aufschreiben, eine Lösung implementieren, die Tests ausführen und einen Bericht schreiben. Das ist die Ausführung des inneren Loops, und sie können es so effizient wie jeder andere tun. Aber das war nie der Job. Die Teile, die du besitzt, nenne ich den äußeren Loop: entscheiden, ob es der richtige Weg ist, das Problem anzugehen, verifizieren, dass die Diagnose und Implementierung solide sind, die Änderung freigeben und die Konsequenzen tragen, wenn du falsch liegst. Die Grenze zwischen den beiden Loops sind Beweise: die Diffs, die Tests, die Logs und eine kurze Erklärung, die sie verbindet. Typen, Nähte und Rubriken machen es möglich, das alles zu überwachen, ohne bei jeder Änderung viel Arbeit zu investieren.
Es ist nützlich, es so zu formulieren: Du bist nicht mehr unten am Fließband und schreibst Änderungen; du bist am Ende der Produktionslinie, entwirfst sie und bewachst das Tor. Es gibt eine Menge, was du tun kannst, um das Modell besser und den Harness leistungsfähiger zu machen, aber ich habe beobachtet, dass das Identifizieren von Problemen, die langfristig teuer sind, nicht etwas ist, das man typischerweise automatisieren kann. Die Kernaufgabe, die immer noch der Job ist, ist es, menschliches Urteilsvermögen besser auszuüben als jeder Fluss von Papier und Rechenleistung.
Roboter können im Dunkeln gut arbeiten, aber Menschen müssen sehen, was sie tun. Wenn alles auf dem Fabrikboden dunkel ist und du nichts sehen kannst und nicht einmal den Lichtschalter findest, dann ist die Gefahr da.
Pangram hat bewertet , dass dieser Artikel zu 100 % von Menschen geschrieben wurde.
