Der grüne Haken ist eine Behauptung, kein Ergebnis

Ein Argument macht gerade die Runde: AI-Coding koste uns etwas, das die Syntax nie gekostet hat, nämlich das mentale Modell. Zwei Tage an einem Bug festzuhängen sei Verdichtung gewesen statt Verschwendung: Hinterher passe ein Stück mehr vom System in den Kopf. Ersetze „Hypothese, Inspektion, Verstehen, Änderung“ durch „beschreiben, generieren, ausführen, reparieren lassen“, und das Modell entsteht nie.

Ich halte es für richtig, aber aus einem engeren Grund als dem, der meistens genannt wird. Es geht nicht um Nostalgie nach Assembler. Es geht darum, dass ein mentales Modell der Grund ist, warum du einem grünen Haken misstraust.

Drei Dinge, die letzte Woche Erfolg gemeldet haben

Alle drei aus dem Repository dieser Seite, innerhalb einer Woche, und alle drei gefunden von einem Menschen, nicht von einer Prüfung.

Ein Parser, der null Tokens las und das eine funktionierende Anfrage nannte. Hetzners Inference-API sendet Server-Sent Events als data:{…}, ohne Leerzeichen nach dem Doppelpunkt. Mein Parser splittete auf das dokumentierte data: , traf nichts und lieferte eine erfolgreiche Antwort mit leerer Ausgabe. Ein paar Minuten lang hielt ich die Modelle für kaputt. Nichts wurde geworfen, kein Status war falsch, kein Test schlug fehl. Aufgefallen ist es nur, weil ich ungefähr weiß, wie eine gestreamte Antwort aussieht, und diese sah nach gar nichts aus.

Eine Middleware, die kompilierte und nie lief. Next.js 16 benennt middleware in proxy um. Ich habe die Datei an Ort und Stelle umbenannt, der Build lief durch. Die Route, die für zurückgezogene URLs 410 antwortet, antwortete still 404 — die Konvention will die Datei neben app/, meine lag im Repository-Wurzelverzeichnis. Der Build kann das nicht sagen. Das Manifest auch nicht: Es ist leer, ob proxy funktioniert oder nicht. Gesagt hat es mir eine URL, deren richtige Antwort ich vorher kannte.

Eine Datei, die behauptete, generiert zu sein, und es nicht war. Das Datenmodul hinter einem Diagramm trug im Kopf „Generated by scripts/bench-inference.mjs“. War es nicht. Das Skript schrieb JSON; das TypeScript hatte ich einmal von Hand erzeugt und war weitergegangen. Zufällig stimmte jede Zahl darin. Nichts hätte es bemerkt, wenn sie aufgehört hätten zu stimmen.

Was die drei gemeinsam haben

Keines davon ist ein Fehler in dem Sinn, den ein Typechecker, ein Linter oder ein Test erkennt. Jedes ist eine Lücke zwischen dem, was ein System meldete, und dem, was es tat. Geschlossen habe ich jede, indem ich mein Modell des Systems neben seine Ausgabe gehalten habe und beides nicht zusammenpasste.

Darin liegt die Fähigkeit, nicht im Schreiben des Parsers. Der sind fünfzehn Zeilen, und das meiste davon hat ein Modell geschrieben. Die Fähigkeit ist zu wissen, dass ein funktionierender Stream Hunderte kleiner Frames erzeugt und null deshalb keine kleine Zahl ist, sondern eine unmögliche.

Abstraktion war nie das Problem

Programmieren war immer Schichtung. Du schreibst TypeScript, daraus wird JavaScript, V8 parst es zu Bytecode, misst und kompiliert heiße Pfade zu Maschinencode für einen Befehlssatz, während ein Betriebssystem Speicher und Scheduling verwaltet, weit über Caches, Sprungvorhersage und Logikgattern. Niemand trauert handgeschriebenem Assembler nach, und die Abstraktion ist der Grund, warum Systeme dieser Größe überhaupt existieren.

Neu ist nicht die Höhe des Stacks. Neu ist, dass die oberste Schicht zurückredet. Ein Compiler, der dein Programm nicht erzeugen kann, sagt das. Ein Modell, das dein Programm nicht erzeugen kann, erzeugt etwas anderes, und zwar ohne zu zögern. Das Scheitern kommt als Ausgabe an, nicht als Fehler.

Die Schleife wird also nicht dadurch schlechter, dass eine Maschine darin sitzt. Sie wird schlechter, wenn der Bericht der Maschine das letzte Wort ist. „Es kompiliert“ ist eine Behauptung. „Der Test ist grün“ ist eine Behauptung über den Test. Ein Review-Agent hat einmal drei Befunde gegen einen meiner Posts eingereicht, und einer davon war erfunden. Ausgerechnet der zitierfähigste, weshalb er am schwersten abzulehnen war.

Was ich behalte

• Eine Vorhersage vor dem Lauf. Keine Vermutung über die Ausgabe, eine über ihre Form. Hunderte Frames. Ein 410, kein 404. Ungefähr vierzig Tokens pro Sekunde. Sich in der Form zu irren ist das Signal; recht zu haben kostet nichts.
• Eine Prüfung, die das Werkzeug nicht selbst machen kann. Die URL curlen. Das gebaute HTML lesen. Die Seite öffnen. Ein Werkzeug, das über sich selbst berichtet, liefert die Behauptung, nicht den Beleg.
• Aufschreiben, warum, nicht was. Ein Kommentar, der sagt, was der Code tut, ist redundant zum Code. Ein Kommentar, der sagt, welche falsche Fassung zuerst dran war, ist das mentale Modell in haltbarer Form, lesbar für alle, die danach kommen, Modelle eingeschlossen.

Nichts davon verlangt, weniger mit AI zu schreiben. Ich schreibe damit deutlich mehr als ohne. Es verlangt, den Teil der Schleife zu behalten, in dem es nie ums Tippen ging.

Next

Drei Fehler in einer Woche sind ein Muster, das mir aufgefallen ist, keine Rate, die ich gemessen habe. Die Fassung, die etwas taugt: einen Monat lang jedes Mal protokollieren, wenn ein Werkzeug Erfolg meldet und falsch liegt — samt dem, was es gefunden hat. Ist der Finder meistens eine vorher gemachte Vorhersage, ist das ein Befund. Ist es meistens Zufall, ein interessanterer.

Was hat deinen letzten stillen Fehler gefunden: ein Test, ein Nutzer, oder dass dir die Ausgabe falsch vorkam? Ich vermute, das Dritte ist häufiger, als wir zugeben, und es ist das, was nichts in der Toolchain ersetzt.