Der Test, der besteht, weil Sie die falschen Beispiele gewählt haben

Was wir gerade gemacht haben, damit das Sinn ergibt

Der Hintergrund. Unsere Seite lag früher bei einem Website-Baukasten, der Sorte, bei der man Dinge im Browser verschiebt und jemand anderem die Maschine darunter gehört. Das ist ein vernünftiger Anfang und eine schlechte Fortsetzung. Wir waren gerade dabei, aus einem Prototyp ein echtes Produkt zu machen, und ein Produkt braucht eine Seite, die uns wirklich gehört: eigene Domain, eigener Code, eigene Pipeline, keine monatliche Gebühr für die Erlaubnis zu veröffentlichen, und nichts, das an einem Dienstag seine Bedingungen ändern und unsere Seiten mitnehmen kann.

Also haben wir sie umgezogen. Raus aus dem Baukasten, hinein in eine statische Seite, die wir selbst bauen und aus unserem eigenen Speicher ausliefern.

Und wir haben den Umzug so gemacht, wie wir hier alles machen, und genau darum geht es in diesem Unternehmen: Arbeiten gemeinsam mit einem KI-Assistenten. Nicht zusehen, wie er arbeitet. Nicht ihm die Schlüssel übergeben. Mit ihm arbeiten, so wie Sie mit einem sehr schnellen Kollegen arbeiten würden, der Ihr Geschäft noch nie gesehen hat.

Das ist, was wir vermitteln, und darum geht es in diesem Beitrag. Denn das Interessante an dieser Arbeitsweise ist nicht die Geschwindigkeit. Es ist das Wissen darum, wo sie schiefgeht.

Ein grüner Test ist ein Beleg für die Fälle, an die Sie gedacht haben. Für nichts sonst.

Was wir an diesem Tag gebraucht haben

Wenn eine Seite aus Dateien in einem Speicher besteht und nicht aus einem Programm, das auf einem Server läuft, muss irgendetwas zwischen dem übersetzen, was eine Leserin anfragt, und dem, was tatsächlich auf der Platte liegt.

Jemand fragt /about an. Im Speicher liegt /about/index.html. Etwas Kleines sitzt dazwischen und schreibt das eine in das andere um.

Wir wollten außerdem, dass /ConfirmEmail und /confirmemail dieselbe Seite sind und nicht zwei Adressen für eine Sache. Deshalb hat dasselbe kleine Stück Code die Adresse unterwegs in Kleinbuchstaben umgewandelt.

Es wurde geschrieben, es wurde getestet, jeder Fall war grün, und es wurde als funktionierend zurückgemeldet. Hier sind die Fälle, gegen die getestet wurde.

/ /about /ConfirmEmail /sitemap.xml

Schauen Sie sich die einen Moment an, bevor wir erzählen, was passiert ist.

Jeder einzelne davon ist entweder ohnehin schon klein geschrieben oder so offensichtlich eine Seitenadresse, dass Kleinschreibung nicht schadet. Vier Beispiele, die alle miteinander übereinstimmen, alle aus derselben Annahme geschrieben wie die Funktion, und alle bestätigen genau das, was diese Annahme ohnehin schon behauptet hat.

Was der Build tatsächlich erzeugt

Der Build schreibt nicht /about. Unter anderem schreibt er das hier.

/assets/index-D4kM9xRt.js

Die Buchstaben nach dem Bindestrich sind keine Dekoration. Sie sind ein Fingerabdruck des Dateiinhalts selbst, und genau der erlaubt es einem Browser, diese Datei für immer zwischenzuspeichern und trotzdem sofort eine neue zu holen, sobald sich etwas ändert. Ein einziges Zeichen in der Quelle geändert, und der Name ändert sich mit.

Und ein Fingerabdruck enthält Großbuchstaben, weil er zwischen Groß- und Kleinschreibung unterscheidet. Jeder Schlüssel im Speicher tut das auch.

Also hat die Funktion daraus index-d4km9xrt.js gemacht, eine Datei, die es nirgendwo je gegeben hat.

Die Seite ging live und lieferte jede einzelne Seite ohne Stylesheet und ohne JavaScript aus. Seiten mit schwarzem Text auf weißem Grund, ohne jede Gestaltung.

Wie wir es gefunden haben, und das ist die eigentliche Lektion

Nicht mit dem Test. Der Test war grün und blieb grün.

Gefunden haben wir es mit einem Gate: einer Prüfung, die gegen den fertigen Build läuft, und eine Minute nach der Veröffentlichung noch einmal gegen die Live-Seite, und die die Veröffentlichung blockiert, statt eine Warnung auszugeben.

Sie hat es im ersten Durchlauf gefunden. Nicht weil sie klug gewesen wäre, und nicht weil irgendjemand diesen speziellen Fehler vorhergesehen hätte. Sie hat ihn gefunden, weil sie auf die echte Ausgabe geschaut hat statt auf ein Beispiel, und die echte Ausgabe war voller Großbuchstaben.

Wie wir es behoben haben, und warum das der effizientere Weg ist

Die Korrektur in der Funktion war eine Zeile. Dieser Teil ist nicht interessant, und ihn abzuschreiben hilft Ihnen nicht.

Die Korrektur an unserer Arbeitsweise waren drei Regeln, und die lohnt es sich zu stehlen.

Erstens. Testen Sie gegen Artefakte, die das System erzeugt hat, nicht gegen Beispiele, die Sie getippt haben. Wenn eine Funktion Dateinamen verarbeitet, holen Sie sich die Dateinamen aus dem letzten Build. Sie liegen in einem Ordner auf Ihrer Platte. Vier echte zu lesen dauert kürzer, als vier erfundene auszudenken, und es ist der Unterschied zwischen etwas beweisen und sich selbst zustimmen.

Zweitens. Setzen Sie etwas in die Pipeline, das keine Meinung hat. Eine Prüfung, die auf der gebauten Ausgabe läuft und noch einmal auf der Live-Seite, und die die Veröffentlichung verweigert, wenn sie fehlschlägt. Keine Warnung. Eine Warnung ist etwas, über das man um elf Uhr abends hinwegscrollt, wenn man ins Bett will.

Drittens. Behandeln Sie einen bestandenen Test als Frage. Die Frage lautet: Was hat das hier tatsächlich bewiesen, und was konnte es strukturell überhaupt nicht beweisen? Vier kleingeschriebene Pfade haben bewiesen, dass kleingeschriebene Pfade funktionieren. Mehr nicht.

Warum das effizienter und nicht nur sorgfältiger ist: Ein Gate kostet Sie einmalig etwa zwanzig Minuten und danach gar nichts mehr. Das von Hand zu finden kostet Sie eine Live-Seite, einen Abend, und den Teil, in dem Sie nicht wissen, was kaputt ist.

Der ehrliche Teil, und es geht nicht darum, wer getippt hat

Die naheliegende Version dieser Geschichte lautet: „Die KI hat eine schlechte Funktion geschrieben." Das ist nicht passiert, und es ist auch keine nützliche Lektion.

Hier war es, wie immer, Zusammenarbeit. An manchen Tagen schreibt der Assistent den Code. An manchen Tagen schreiben wir ihn. In diesem Fall spielt es keine Rolle, und wir werden nicht so tun, als täte es das, denn der Fehler wäre so oder so derselbe gewesen.

Passiert ist Folgendes. Die Funktion wurde aus einer Annahme darüber geschrieben, wie Adressen aussehen. Die Testbeispiele wurden aus derselben Annahme geschrieben. Und das Review wurde von jemandem gemacht, der dieselbe Annahme im Kopf hatte, weshalb das Review bestanden wurde.

Das ist der Fehlermodus, und Sie werden bemerken, dass er nichts damit zu tun hat, wer die Tastatur in der Hand hatte.

Drei Dinge waren sich einig. Keines davon hatte die echte Ausgabe angesehen.

Die menschliche Ebene ist nicht optional, aber sie reicht auch nicht

Es spielt keine Rolle, wer den Code schreibt. Ein Mensch prüft das Ergebnis. Das ist die ganze Disziplin der Arbeit mit KI, und wir überspringen sie an keinem Tag der Woche.

Aber das hier wird übersehen, und es hat uns eine Live-Seite gekostet: Ein Mensch, der gegen dieselbe Annahme prüft, aus der der Code entstanden ist, fügt nichts hinzu. Sie lesen es, es passt zu dem, was Sie erwarten, Sie geben es frei. Sie haben Ihre eigene Überzeugung im Lesetempo bestätigt.

Die menschliche Ebene muss also auf das Richtige gerichtet sein. Nicht „sieht das korrekt aus", das ist eine Meinung. Sondern: Stimmt das mit dem überein, was das System tatsächlich erzeugt hat, und das ist eine Tatsache, die Sie nachsehen können.

Das ist eine andere Aufgabe, und es ist die, die Ihre Aufmerksamkeit verdient. Code auf Plausibilität zu lesen ist die billige Hälfte. Ihn gegen die Realität zu prüfen ist die Hälfte, die etwas findet.

Wenn Sie gerade irgendetwas mit KI bauen

Das ist der Fehlermodus, vor dem man Angst haben sollte. Nicht Unsinn. Selbstsicherheit.

Man wird Ihnen eine Funktion zeigen, eine Erklärung dazu und eine Liste bestandener Fälle, und alle drei werden miteinander übereinstimmen, weil alle drei aus derselben Quelle stammen. Nichts in dieser Kette hat Ihr tatsächliches System berührt.

Gut mit einem Assistenten zu arbeiten heißt nicht, bessere Anweisungen zu schreiben. Es heißt, dafür zu sorgen, dass irgendetwas im Raum auf das schaut, was wirklich herausgekommen ist, statt auf das, was alle erwartet haben.

Das ist die ganze Fähigkeit. Alles andere ist Tippen.