Kinder der magentafarbenen Linie

8 Min. Lesezeit

Wenn der Code richtig aussieht und trotzdem Unternehmen und Job zerstört

Woher die magentafarbene Linie kommt

Mitte der 1990er nahm Warren Vanderburgh, Ausbildungskapitän bei American Airlines, einen inzwischen berühmten internen Vortrag mit dem Titel “Children of the Magenta Line” auf. Er hatte beobachtet, wie eine Generation von Piloten mit Glascockpits und Flight Management Computern aufwuchs. Der Autopilot zeichnete eine magentafarbene Kurslinie auf das Navigationsdisplay. Die Aufgabe der Crew bestand immer häufiger darin, das Flugzeug auf dieser Linie zu halten und dem Kasten zu vertrauen.

Seine Warnung war schlicht. Die Linie ist ein Werkzeug. Das Flugzeug wird immer noch von Menschen geflogen. Wenn die Lage seltsam wird, ist der richtige Schritt oft, eine Ebene der Automatisierung zurückzugehen, manuell zu übernehmen und zu fliegen. Piloten, die das nicht mehr konnten, die den Computer weiter fragten, warum er tat, was er tat, während die Landebahn seitlich davonlief, waren die Gefährdeten.

Der Vortrag war nicht gegen Automatisierung. Er war gegen Passivität. Vanderburghs Punkt war, dass sich das Cockpit still von “das Flugzeug fliegen” zu “ein System betreuen, das das Flugzeug fliegt” verschoben hatte, während Ausbildung, Gewohnheiten und Instinkte nicht mitgezogen waren.

Ersetzen Sie “Flight Management Computer” durch “KI-Coding-Assistent”, und der Vortrag schreibt sich fast von selbst.

Der Berghang in Kolumbien

Die klarste Fallstudie ist auch die unbequemste. Am 20. Dezember 1995 flog American Airlines Flug 965 mit einer technisch einwandfreien Boeing 757 in einen Berg nahe Cali, Kolumbien. Der Kapitän war erfahren. Der Erste Offizier war kompetent. Das Flugzeug war gesund. Das Wetter in der Höhe war in Ordnung. Über die menschliche Seite dieses Unfalls habe ich in Dem Plan in den Berg folgen geschrieben.

Was diese 159 Menschen tötete, war keine kaputte Maschine. Es war eine Wegpunkt-Eingabe mit einem Buchstaben im Flight Management Computer, ohne Verifikation akzeptiert, die die magentafarbene Linie vom Flughafen weg und in Richtung Gelände bog. Die Crew dachte weiter über das System nach, statt darüber, wohin das Flugzeug tatsächlich flog. Als die Bodenannäherungswarnung schrie, war die Geometrie schon gnadenlos.

So sieht es aus, wenn Vertrauen in die Linie den Punkt der Urteilskraft überschreitet. Das ist keine Faulheit. Es ist ein antrainierter Reflex, sich dem Kasten zu beugen, weil der Kasten meistens recht hat.

KI-Coding-Werkzeuge haben meistens auch recht. Genau das ist das Problem.

Der GPS-100 und der Prüfungsflug

Eine kleine persönliche Erinnerung. Vor Jahren, als zivile GPS-Navigation neu war, flog ich mit einem eingebauten Gerät aus der Generation des Garmin GPS-100. Winziger Bildschirm. Begrenzte Datenbank. Ein Wunder verglichen mit dem, was davor kam.

Bei einem Prüfungsflug beobachtete der Prüfer, wie ich die Route eingab. Vor jedem Wegpunkt verglich ich die Breite und Länge, die das Gerät anzeigte, mit den veröffentlichten Koordinaten auf der Karte. Nicht, weil ich erwartete, dass das GPS lügt. Sondern weil eine falsche Eingabe in einem echten Flugzeug eine echte Abweichung bedeutete, während die Prüfung zehn Sekunden kostete.

Er bemerkte es. Später sagte er mir, dass die meisten Kandidaten damals schon die Gewohnheit entwickelt hatten, die Kennung einzutippen und dem Ergebnis zu vertrauen. Das neue Spielzeug war so gut, so schnell, so überzeugend, dass der Verifikationsschritt leise verdunstet war.

Genau diesen Moment muss man erkennen. Nicht wenn das Werkzeug schlecht ist. Sondern wenn es gut genug ist, dass der Mensch nicht mehr prüft.

Coding wurde nicht gelöst

“Coding ist gelöst” ist ein Satz, der nur überlebt, solange man “Coding” klein hält. Wenn Coding bedeutet, eine Funktion zu erzeugen, die kompiliert und grob das Richtige tut, dann ja: Die Modelle sind sehr gut und werden besser. Sie haben einen Teil der Arbeit gelöst, für den ein Junior Developer früher einen Nachmittag gebraucht hätte.

Wenn Coding aber den ganzen Akt der Softwareentwicklung meint, also das Problem benennen, die Domäne modellieren, Grenzen entwerfen, entscheiden, was nicht gebaut wird, Tests schreiben, die Verhalten festnageln, mit Systemen integrieren, die über ihre Verträge lügen, sicher liefern, beobachten, was passiert, und das Design ändern, wenn die Realität zurückschlägt, dann wurde es nicht gelöst. Es wurde an den Stellen schneller, die ohnehin mechanisch waren, und gefährlicher an den Stellen, die nie mechanisch waren.

Die Analogie zur magentafarbenen Linie passt genau. Der Autopilot hat Fliegen nicht gelöst. Er hat das Halten von Kurs und Höhe mit weniger Arbeitslast gelöst und der Crew damit Aufmerksamkeit für schwierigere Dinge zurückgegeben: Wetter, Verkehr, Treibstoff, Ausweichpläne, Entscheidungen. Die Crews, die besser wurden, nutzten diese Aufmerksamkeit für diese härteren Aufgaben. Die Crews, die abrutschten, nutzten sie zum Abschalten.

Ein KI-Coding-Assistent löst Softwareentwicklung nicht. Er entfernt einen Teil der Schreibarbeit und gibt Ihnen Aufmerksamkeit zurück. Was Sie mit dieser Aufmerksamkeit tun, entscheidet, ob Ihre Codebasis besser wird oder still schlechter.

Wie “Kinder der magentafarbenen Linie” in einer Codebasis aussehen

Der Cockpit-Fehlermodus hat ein Entwickler-Gegenstück. Man erkennt ihn ohne Stoppuhr.

• Pull Requests, in denen der Autor einen nicht trivialen Block nicht erklären kann, den er übernommen hat.
• Tests, die existieren, weil der Assistent sie vorgeschlagen hat, nicht weil sie ein Verhalten absichern, über das jemand nachgedacht hat.
• “Refactorings”, die Code verschieben, ohne zu ändern, was das System tut oder garantiert.
• Bugreports, die an drei Stellen geflickt werden, weil niemand die Ursache verfolgt hat, sondern nur das Modell nach einem Fix fragte.
• Architekturentscheidungen, die mit “die KI hat es empfohlen” begründet werden statt als Trade-off, den das Team gewählt hat.
• Eine schleichende Unfähigkeit zu sagen, warum eine Funktion so geformt ist, nur dass sie grün ist.

Jedes davon ist dasselbe Muster: Die magentafarbene Linie ist gezeichnet und wird befolgt. Niemand fliegt.

Eine Ebene zurückgehen

Vanderburghs Rezept war nicht, den Autopiloten zu verbieten. Piloten sollten jederzeit eine Ebene zurückgehen können: von voller Automatisierung zu manueller Moduswahl, zu Rohdaten, zum Fliegen nach Gefühl. Jede Ebene war eine Rückfallebene. Kompetenz auf den unteren Ebenen machte die oberen sicher.

Dieselbe Disziplin gilt für KI-gestützte Softwareentwicklung. Die Lösung ist nicht, die Werkzeuge zu verweigern. Sie besteht darin, auf den Ebenen darunter scharf zu bleiben.

• Lesen Sie den Diff, den Sie committen wollen. Den ganzen. Notfalls laut.
• Schreiben Sie oft genug zuerst den Test, damit Sie es nicht verlernen. Tests sind die Rohdaten des Developers. Die Agenten-Version davon behandle ich in Tests schlagen Anweisungen für KI-Coding-Agenten.
• Halten Sie kleine Änderungen klein. Wenn der Assistent eine große Umschreibung anbietet, lehnen Sie ab und fragen Sie nach dem kleinsten Schritt.
• Wenn sich etwas falsch anfühlt, legen Sie den Assistenten weg. Öffnen Sie die Datei. Denken Sie selbst. Wenn das nicht geht, ist das ein Signal, dass Sie im Problem an Höhe verloren haben, nicht dass das Modell einen besseren Prompt braucht.
• Befragen Sie den Code durch das Agenten-Werkzeug. Fragen Sie, wo eine Regel lebt, welche Dateien Preise parsen, welche Annahmen die Änderung eingeführt hat und ob dieselbe Entscheidung an mehreren Stellen auftaucht.

Dieser letzte Schritt zählt. Ein erfahrener Developer kann die Antwort eines Agenten lesen und den Ärger riechen, bevor der Vorfall existiert. “Ich parse Preise hier, hier und hier” ist keine harmlose Zusammenfassung. Es ist eine künftige Krise, die sich höflich ankündigt. Die richtige Antwort ist kein Gremiumstermin. Sie ist eine scharfe Anweisung: halte es DRY, zentralisiere die Preisregel, ergänze den Test, der es beweist. Der Mensch konkurriert nicht mit dem Agenten. Der Mensch befragt das System durch den Agenten, bevor die magentafarbene Linie leise abbiegt.

Nichts davon bremst einen starken Developer. Es ist das, was starke Developer ohnehin schon getan haben.

Was Führung tatsächlich fragen sollte

Wenn Sie CEO, CTO oder Beiratsmitglied sind und jemand Ihnen erklärt, Coding sei jetzt eine Ware, kosten ein paar Fragen nichts und sparen viel.

1. Kann das Team ohne Assistenten die letzte nicht triviale Änderung erklären, die es geliefert hat?

   Wenn die Antwort eine vage Geste in Richtung Prompt-Historie ist, sehen Sie Kinder der magentafarbenen Linie.

2. Was passiert, wenn der Assistent falsch und selbstsicher ist?

   Darauf braucht es eine echte Antwort. Tests, die laut scheitern. Developer, die die Antworten des Agenten befragen. Observability, die Drift sichtbar macht. Wenn das einzige Sicherheitsnetz "der nächste Prompt repariert es" lautet, liegt der Boden tiefer, als die Folie behauptet.

3. Wo übt das Team die Ebene unterhalb des Werkzeugs?

   Pairing, bewusstes Test-first-Arbeiten, Code-Lesesessions, kleine Refactorings von Hand. In der Luftfahrt heißt das Currency. Ohne sie sind die sichtbaren Produktivitätsgewinne gegen einen künftigen Vorfall geborgt.

4. Wer besitzt das Design, wenn der Assistent widerspricht?

   Wenn die Antwort lautet "wir nehmen, was das Modell produziert, weil es schneller ist", hat Design das Gebäude verlassen. Die magentafarbene Linie zeichnet sich jetzt selbst.

Der nützliche Rahmen

Coding wurde nicht gelöst. Ein Teil davon wurde automatisiert, und der verbleibende Teil ist der, der immer am wichtigsten war: Urteilskraft, Design, Verifikation und die Bereitschaft, ein selbstsicheres System zu überstimmen, wenn die Geometrie falsch ist.

Die Crews, die den Übergang zum Glascockpit überlebt haben, waren nicht die, die Automatisierung am wenigsten nutzten. Es waren die, die sich weigerten, Passagiere in ihrem eigenen Flugzeug zu werden. Die Developer und Teams, die aus dem KI-Übergang stärker herauskommen, sind dieselbe Art Menschen.

Die magentafarbene Linie ist ein Werkzeug. Irgendjemand muss immer noch fliegen.