Das 70%-Problem ist die Beobachtung, dass Generierung einen Software-Build den Großteil des Weges funktionsfähig trägt, dann am Rest scheitert, der Automatisierung widersteht. Dieser letzte Bruch ist kein weiteres Mal derselbe Code in kleinerem Maßstab. Es ist eine qualitativ andere Arbeit: Integration, Randfälle, Produktionshärtung und der Teil, den niemand spezifiziert hat. Der erste Abschnitt belohnt Beherrschung; der letzte Abschnitt belohnt Urteilsvermögen, und Urteilsvermögen lässt sich nicht so komprimieren wie Boilerplate.
- Der erste 70%-Abschnitt ist eine gut spezifizierte Oberfläche; der Rest ist das Nicht-Spezifizierte im Inneren.
- Eine Demo beweist den erwarteten Pfad und verbirgt die Bedingungen, die ihn brechen könnten.
- Randfälle vervielfachen sich schneller, als irgendein Prompt sie aufzählen könnte.
- Integrationsfriktion entsteht zwischen Systemen, wo kein einzelner Generator alles sehen kann.
- Die Produktionshärtung besteht größtenteils darin, sich gegen Eingaben zu verteidigen, die niemand beschrieben hat.
- Die Größe verschiebt sich im Laufe der Zeit, aber die Form der Schwierigkeit bleibt unverändert.
Warum ist der letzte Abschnitt qualitativ anders als der erste?
Der erste Abschnitt eines Builds ist reich an Strukturen, die tausende Male beschrieben wurden. Formulare, Listen, Routing, Zustand, eine Datenform mit vorhersehbaren Feldern. Generierung gelingt hier gut, weil Muster verbreitet sind und der Zweck lesbar ist. Es besteht kaum Zweideutigkeit darüber, was eine sortierbare Tabelle oder ein validiertes Formular tun sollte.
Der Rest ist in seiner Art anders. Es ist die Eigenschaft eines Systems, bei dem die Spezifikation ausläuft und die Realität weiterläuft. Was passiert, wenn zwei Schreibvorgänge gegeneinander konkurrieren? Wenn eine Upstream-Oberfläche eine Form zurückgibt, die sie niemals zurückgeben sollte? Wenn ein Benutzer das vernünftige, aber unvorhergesehene Ding tut? Diese Fragen sind nicht einfachere Versionen der frühen Fragen. Sie bilden eine eigenständige Kategorie, definiert weniger durch das Schreiben von Code als durch die Entscheidung, was der Code unter Bedingungen bedeuten soll, die die ursprüngliche Anfrage nie benannt hat.
Es gibt auch einen Feedback-Effekt. Der frühe Code wird schnell generiert, sammelt sich schnell an, und das Volumen selbst wird zu traversierendem Gelände. Ein Build, das in Minuten entsteht, muss dennoch in Stunden verstanden werden. Der Leser kommt zu einer Struktur, die er nicht geschrieben hat, mit Konventionen, die er nicht gewählt hat, und die Verstehenskosten treffen genau dann ein, wenn die harten Entscheidungen beginnen.
Deshalb ist der Anteil rutschig. Wenn Modelle besser werden, verschiebt sich die Grenze, aber sie verschiebt sich entlang derselben Fehlerlinie: Dort, wo explizite Spezifikation endet, verlangsamt Automatisierung sich. Die Steigung wird genau dort steiler, wo die Beschreibung dünner wird. Eine Figur, die wie Fortschritt aussieht, ist in Wahrheit ein Marker an einer Frontier, die sich weiter zu den Bereichen verschiebt, die immer am wenigsten lesbar waren.
Was versteckt eine Demo, was die Produktion offenbart?
Eine Demo ist eine kontrollierte Vorführung. Sie läuft einen Pfad, mit gewählten Eingaben, in einem nachsichtigen Netzwerk, vor einem Publikum, das Erfolg sehen will. Produktion ist die gegenteilige Inverse: Jeder Pfad gleichzeitig, feindliche Eingaben, Teilfehler, und niemand steuert. Die Distanz zwischen diesen beiden Zuständen ist die Demo-zu-Produktions-Kluft, und dort liegt der Großteil der letzten Meile der Arbeit.
Die Lücke ist groß, weil eine funktionierende Demo und ein funktionsfähiges System ein Erscheinungsbild teilen, aber keine Struktur. Die Demo optimiert für das Sichtbare. Das System muss das Unsichtbare berücksichtigen — die Wiederholungen, Idempotenz, das Timeout, das einmal pro Woche ausgelöst wird, die Migration, die laufen muss, während der Verkehr weiterläuft. All das zeigt sich nicht in einer Bildschirmaufnahme.
Ein Kompromiss, der sich zeigt, ist Geschwindigkeit gegen Haltbarkeit. Generierung liefert ein schnelles, plausibles Artefakt. Aus diesem Artefakt etwas zu machen, das realem Lasten standhält, ist langsamer, und es sieht selten so aus, als würde man mehr Code generieren. Es sieht aus wie Lesen, Nachverfolgen und das Einschränken dessen, was bereits existiert.
Die Lücke hat auch eine Wahrnehmungskoste. Eine überzeugende Demo setzt die Erwartung, dass die Arbeit fast erledigt ist, wodurch der verbleibende Aufwand wie eine Regression wirkt, nicht wie der Großteil der Arbeit. Stakeholder sahen, dass es funktioniert. Die Distanz zwischen diesem Moment und einem verlässlichen System ist real, aber schwer zu verteidigen, weil sie für jeden unsichtbar bleibt, der nur die Performance gesehen hat.
Warum lebt der schwierigste Rest in dem, was niemand spezifiziert hat?
Der unspezifizierte Rest bezieht sich auf das Verhalten, das ein System haben muss, das nie in einer Anfrage beschrieben wurde. Er ist die größte Quelle der Last-Mile-Kosten, weil er nicht aus einem Prompt erzeugt werden kann, der ihn nicht enthält. Ein Generator beantwortet die Frage, die gestellt wird. Die schwere Frage ist die Frage, die niemand zu stellen dachte.
Die Spezifikation ist genau dort teuer, wo es am wichtigsten ist. Niemand spezifiziert, was der Checkout tut, wenn die Zahlungsoberfläche bestätigt, aber der Bestellvorgang fehlschlägt, weil niemand daran denken will, bis es passiert. Die Lücke zwischen geäußertem Ziel und dem erforderlichen Verhalten wird so zur Arbeit. Jemand muss die Abwesenheit bemerken, sie benennen und entscheiden.
Noticing ist hier die unterschätzte Fähigkeit. Ein Generator füllt aus, was ihm gegeben wird, und bleibt still zu dem, was es nicht hat; dieses Schweigen wird von jedem, der nur den Happy Path prüft, als Vollständigkeit gelesen. Der Rest ist konstruktionsbedingt unsichtbar. Ihn sichtbar zu machen bedeutet, sich das System unter Stress vorzustellen, bevor der Stress eintritt, was eine Gewohnheit der Aufmerksamkeit ist, kein Merkmal, das irgendein Werkzeug mitliefert.
- Happy path
- Die einzige Abfolge von Ereignissen, die eine Demo zeigen soll, bei der jede Abhängigkeit funktioniert.
- Unspecified remainder
- Verhalten, das das System zeigen muss, das in keiner Anfrage, keinem Prompt und keinem Ticket beschrieben wurde.
- Integration seam
- Die Grenze zwischen zwei Systemen, bei der die Annahmen über das andere nicht angegeben werden.
- Production hardening
- Die Arbeit, generierte Strukturen so zu machen, dass sie Eingaben, Ausfälle und Last standhalten, die nicht gezeigt wurden.
Wohin verlagert sich menschliche Mühe, wenn Generierung die ersten 70% absorbiert?
Die Anstrengung verschwindet nicht; sie wandert. Wenn der frühe, gut spezifizierte Großteil eines Builds in Minuten erzeugt wird, verlagern sich die menschlichen Stunden, die früher in das Tippen dieser Struktur flossen, zu den Aktivitäten, in denen die Generierung am schwächsten ist. Lesen unbekannten Codes wird zur primären Fähigkeit. Zu entscheiden, was ein System an seinen Rändern tun soll, wird zur knappen Leistung.
Diese Verlagerung verändert den Tagesablauf. Weniger Zeit, Erstentwürfe zu produzieren, mehr Zeit, sie zu hinterfragen. Der Engpass verschiebt sich von der Erstellung zur Verifikation — zu bestätigen, dass das Plausible auch das Richtige unter Bedingungen ist, die der Generator nie getestet hat. Urteil, Geschmack bezüglich Fehlerarten und die Geduld, einen einmal pro Woche auftretenden Fehler zu verfolgen, werden die Arbeit, die Gewicht hat.
Es verändert auch, welchen Wert Erfahrung hat. Der Wert davon, viele Systeme scheitern gesehen zu haben, transferiert sich nicht auf einen Generator; er lebt in der Person, die einen bekannten Geruch im unbekannten Code erkennt. Diese Erkennung ermöglicht es jemandem, einen generierten Fluss zu überblicken und zu spüren, noch bevor Tests laufen, wo er brechen wird. Der frühe Code wird zu einer Commodität; der Instinkt für seine Ränder bleibt.
| Eigenschaft | Erster Anteil 70% (generiert) | Letzter Anteil 30% (menschlich) |
|---|---|---|
| Spezifikation | Explizit, gängig, lesbar | Implizit, selten, strittig |
| Dominierende Tätigkeit | Struktur erzeugen | Verhalten einschränken |
| Fehler-Sichtbarkeit | In einer Demo offensichtlich | |
| Kosten-Treiber | Codevolumen | |
| Verfügbare Komprimierbarkeit | Hoch |
Wie überqueren Teams den letzten Abschnitt gezielt?
Den letzten Meilenstein zu überschreiten folgt oft einer Reihenfolge, nicht weil es ein Rezept gibt, sondern weil die Fehler in einer vorhersehbaren Abfolge auftreten. Die Disziplin besteht darin, das generierte Artefakt als Hypothese zu behandeln und die verbleibende Arbeit als Falsifikation.
- Kartiere die Nahtstellen: liste jede Grenze auf, an der der Build ein System berührt, das es nicht kontrolliert.
- Enumeriere die Eingaben, die die Demo nie benutzt hat, insbesondere fehlerhafte, leere und duplizierte.
- Verfolge jeden Fehlerpfad zu einer Entscheidung: erneut versuchen, ablehnen, degradieren oder offenlegen.
- Mache das Implizite explizit, indem du das Verhalten niederschreibst, das niemand spezifiziert hat, und wähle es dann.
- Setze das Ergebnis realer Parallelität und realem Volumen unter Druck, bevor du es als fertig erklärst.
Jeder Schritt wandelt Unbekanntes in eine deklarierte Absicht um. Das generierte 70% liefert dir einen Code-Body, den man prüfen kann; Dieses Verfahren ist die Prüfung. Es ist langsamer als Generierung, weil sein Produkt Gewissheit statt Oberfläche ist.
Die Reihenfolge ist wichtiger als jeder einzelne Schritt. Das Zuerst-Abtasten der Nahtstellen verhindert den verbreiteten Fehler, das Innere zu härten, während die Grenzen ungeschützt bleiben. Eingaben zuerst zu erfassen, bevor man Fehler nachverfolgt, hält die Arbeit an dem fest, was tatsächlich ankommt, statt an dem, was man sich vorgestellt hat. Die Reihenfolge ist eine Methode, Aufmerksamkeit dort zu verwenden, wo der nächste Fehler am wahrscheinlichsten auftritt, statt dort, wo der Code am angenehmsten zu lesen ist.
Was wird zur Grenzlinie der Letzten-Meile, wenn die Generierung besser wird?
Die Grenze löst sich nicht auf; sie verlagert sich nach oben. Wenn Generierung mehr vom gut spezifizierten Mittelteil übernimmt, verschiebt sich die menschliche Grenze zu den Teilen, die immer am wenigsten beschreibbar waren — die Urteilsentscheidungen, das Fehlersemantik, die Entscheidungen darüber, was ein System seinen Nutzern schuldet, wenn etwas kaputtgeht. Der Anteil mag wachsen. Die Beschaffenheit des Restes wird härter, nicht leichter, weil das Verbleibende das Residuum all dessen ist, was sich einer Spezifikation widersetzt hat.
Was knapper wird, ist dann nicht Programmierfähigkeit, sondern die Fähigkeit, die Ränder eines Systems im Kopf zu behalten und klug über sie zu entscheiden. Das Feld belohnt tendenziell diejenigen, die schnell lesen, produktiv zweifeln und fertigstellen können. Der letzte Abschnitt eines generierten Builds bleibt so lange menschlich, wie irgendein Teil eines jeden Systems unbeziffert bleibt — was bedeutet, noch lange.
Es gibt eine ruhigere Implikation dafür, wie Teams sich organisieren. Wenn der generierte Mittelteil weiter wächst, konzentriert sich die Arbeit, die ein fertiges System von einem plausiblen System unterscheidet, auf weniger, dichtere Stunden. Das neigt dazu, Tiefe gegenüber Durchsatz zu belohnen, und es macht die Fähigkeit, zu sagen, was ein System im Fehlerfall tun soll, wertvoller als die Fähigkeit, mehr davon zu produzieren. Die Grenze bewegt sich; sie schließt sich nicht.
F.A.Q.