Was wir einander noch fragen

Etwas hat sich daran verändert, was Entwickler einander fragen, und ich habe es zuerst an meinem eigenen Verhalten bemerkt. Über ein Jahrzehnt lang, quer durch Enterprise-Teams und Startups, waren die Fragen, die zwischen Menschen hin- und hergingen, von Mechanik dominiert. Warum matcht dieser Regex nicht. Was bedeutet dieser Fehler eigentlich. Wie bringe ich diese beiden Libraries dazu, sich auf eine Version zu einigen. Ich habe sie gestellt, ich habe sie beantwortet, und irgendwann in den letzten zwei Jahren habe ich mit beidem aufgehört, weil eine Maschine sie jetzt in Sekunden beantwortet, zu jeder Uhrzeit, ohne dass sich jemand fürs Fragen klein fühlen muss. Die Fragen, die noch zwischen Menschen unterwegs sind, wurden weniger, und sie wurden schwerer.

Ich vermisse den alten Strom nicht. Dieselbe mechanische Frage zum vierzigsten Mal zu beantworten war nie der schöne Teil dieses Berufs, und dass eine unermüdliche Maschine das jetzt abfängt, ist ein Geschenk. Aber zu beobachten, welche Fragen die Lücke zwischen Menschen noch überqueren, nachdem alles andere sie nicht mehr überqueren muss, hat mir etwas darüber beigebracht, wohin der Wert eines Entwicklers wandert. Drei Arten treten die Reise noch an, und sie sind nicht gleich haltbar.

Neuer als der Trainingslauf

Die erste Art wird schneller geboren, als irgendein Modell lernen kann. Ein Release erscheint am Dienstag, und am Mittwoch geht es auf Arten kaputt, die niemand dokumentiert hat, weil noch niemand lange genug damit gelebt hat, um sie zu dokumentieren. Ich schreibe täglich Code mit zwei verschiedenen Modellen, und in dem Moment, in dem sich ein Werkzeug unter mir aktualisiert, wechseln beide vom Weisen zum selbstsicheren Rater, ohne ihren Ton auch nur ein wenig zu ändern. Diesen Umschlag zu erkennen ist inzwischen eine eigene Fähigkeit.

Der naheliegende Einwand ist, dass Modelle browsen können. Sie können Release Notes und Issue-Threads auf Abruf laden, und das hat dieses Fenster deutlich verkleinert. Aber Retrieval liest Text, und in den ersten Tagen, nachdem etwas kaputtgegangen ist, existiert der Text noch nicht. Das Wissen lebt in den Köpfen der fünfzig Leute, die in derselben Woche gegen dieselbe Wand gelaufen sind, und in den Nachrichten, die sie austauschen, sobald sie einander gefunden haben. Für diese Handvoll Tage sind diese Leute der einzige Ort, an dem die Antwort existiert. Alles, was die Maschine irgendwann über den Bruch wissen wird, muss zuerst durch sie hindurch, denn jemand muss etwas aufschreiben, bevor irgendetwas es abrufen kann. Das Fenster wird immer enger, aber jedes Release öffnet es wieder bei null, also brauchen die Fragen, die darin leben, weiterhin einen Menschen. Nur nie lange denselben.

Tiefer als eine plausible Antwort

Die zweite Art geht in die Tiefe statt nach vorn. Die dunkle Ecke eines Compilers. Der Absatz einer Spezifikation, den zwei Implementierungen unterschiedlich lesen. Die Frage, bei der eine plausible Antwort nutzlos ist, weil eine beweisbar korrekte gebraucht wird, mit Herkunftsnachweis, von jemandem, der auf genau die Klausel zeigen kann, die die Sache entscheidet. Wenn jemand fragt, warum der Optimizer diese beiden Writes umsortieren darf, will er keinen Absatz, der nach Dokumentation klingt. Er will das Memory Model, mit Kapitel und Vers.

Ich sollte meine eigene Position hier offenlegen, denn sie spricht gegen mich. Ich habe einen guten Teil der letzten Jahre an Retrieval-Systemen für Rechts- und Gesundheitsdomänen gearbeitet, wo eine Antwort, die ihre Quelle nicht zeigen kann, nichts wert ist, egal wie sie klingt, und der ganze Engineering-Aufwand darin besteht, jede Behauptung an das Dokument zu heften, auf dem sie steht. Diese Arbeit ist eine Wette darauf, dass sich diese Kategorie automatisieren lässt, und die Wette läuft gut. Eine Maschine, die mit der exakten Klausel im Anhang antwortet, ist keine Fantasie; sie ist ungefähr meine Stellenbeschreibung. Von den drei Arten ist das also die, von der ich erwarte, dass sie weiter schrumpft. Der Spezialist, der die Spezifikation in- und auswendig kennt, behält den Vorsprung in den Ecken, in denen sich die Dokumente widersprechen, und bei den Fragen, die die Dokumente nie vorausgesehen haben. Aber ich werde keinen Essay auf einem Burggraben bauen, den ich in meiner Arbeitszeit trockenlege.

Die Frage, bei der es um dich geht

Die dritte Art klingt am wenigsten technisch und erweist sich als die haltbarste. Schau dir mein Projekt an. Welches dieser Werkzeuge für mein Team, bei unserer Codebasis und unserer Deadline und den zwei Leuten, die das wirklich warten werden. Was würdest du tun.

Stell einem Modell diese Fragen, und du bekommst etwas wirklich Nützliches, eine Übersicht über den Optionsraum, mit allen Tradeoffs sauber ausgebreitet. Hak nach, und es trifft sogar eine Wahl, ich werde also nicht so tun, als würde die Maschine sich vor Entscheidungen drücken. Was sie nicht kann, ist die Tradeoffs so zu gewichten, wie gelebte Konsequenz sie gewichtet, und ich glaube, der Grund dafür ist konkret, nicht mystisch. Die schriftliche Überlieferung, aus der die Maschine gelernt hat, ist verzerrt. Dramatische Ausfälle bekommen Postmortems; schleichende nicht. Niemand schreibt einen Incident-Report mit dem Titel "diese Library war für unser Team leicht daneben und hat uns zwei Jahre lang drei Stunden pro Woche gekostet". Die Person, die das Ding gewartet hat, das sie einmal empfohlen hat, trägt genau diese fehlenden Daten in sich: welche Tradeoffs aus der Übersicht wirklich zugebissen haben, wie hart, und wie lange der blaue Fleck geblieben ist. Wenn sie den Optionsraum zu einer Entscheidung für deine Situation eindampft, sind es diese fehlenden Daten, die das Eindampfen erledigen.

Es gibt eine weniger schmeichelhafte Lesart von alldem, und einen Teil davon gestehe ich zu. Manche, die "was würdest du tun" fragen, wollen eher Rückendeckung als Rat, einen Namen, auf den sie zeigen können, wenn die Wahl schiefgeht. Aber selbst das ist ein Bedürfnis, das keine Maschine erfüllen kann, denn auf ein Modell kann man nicht zeigen. Und die bessere Version desselben Instinkts ist gesund. Sie wollen, dass die Entscheidung von jemandem kommt, der für einen Irrtum einen Preis zahlt, und sei es nur mit seinem Ruf, denn eine Empfehlung, die ihren Urheber nichts kostet, ist schnell schlampig ausgesprochen.

Die Umkehrung

Die Maschine hat also die Mitte übernommen. Das ganze Archiv gelöster Mechanik fließt jetzt augenblicklich aus einem Prompt, und von meinem Platz aus betrachtet ist der Strom dieser Fragen zwischen Menschen fast versiegt. Was noch fließt, neigt sich stark zur letzten Art, den Bitten um Geschmack und Empfehlung und Urteil.

Das ist eine Umkehrung, bei der es sich lohnt zu verweilen, denn unsere Kultur hat Entwicklern beigebracht, genau diese Fragen als minderwertig zu behandeln. Wer fragte, was jemand wählen würde, bekam den Reflex zu spüren, das als bloße Meinung abzutun, keine echte Frage, weil es keine überprüfbare Antwort gab. Der Reflex hatte eine gewisse Logik. Subjektive Entscheidungen haben wir den Leuten überlassen, die wir dafür bezahlt haben, den Tech Leads und den Architekten, und unter Kollegen haben wir die Fragen geschätzt, die sich mit Belegen klären ließen.

Die Fragen, die sich mit Belegen klären lassen, klärt jetzt eine Maschine, bevor sie überhaupt einen Menschen erreichen. Was bleibt, ist die Art ohne überprüfbare Antwort, die Art, die früher abgetan wurde. Sie ist vom Rauschen im Kanal zum Großteil dessen geworden, was der Kanal trägt. Und die Leute, die sie noch stellen, haben sehr wohl verstanden, wie das alles funktioniert. Sie haben korrekt identifiziert, was sie aus keinem Prompt bekommen, und sie fragen an dem einzigen Ort nach, an dem es existiert.

Werde jemand, den zu fragen sich lohnt

Ich sollte sagen, wo ich stehe. Ich baue einen Teil der Maschinerie auf der billigen Seite dieses Handels, Werkzeuge, die den ganzen Tag Code und Antworten generieren, und jedes einzelne davon endet bei einem Menschen, der eine Entscheidung treffen muss, die das Werkzeug ihm nicht abnehmen kann. Wenn ich sage, der Wert sei zu der Person gewandert, die bereit ist, die Entscheidung zu treffen, beschreibe ich genau den Punkt, an dem meine eigenen Werkzeuge aufhören.

Für einen Entwickler folgt daraus direkt die praktische Frage. Bist du jemand, den zu fragen sich lohnt? Gibt es eine Ecke dieses Fachs, in der du lange genug mit deinen eigenen Entscheidungen gelebt hast, dass dein Urteil dort etwas bedeutet?

Und wenn die Frage kommt, antworte mit der Begründung, nicht nur mit dem Urteil. Ein Urteil veraltet mit dem nächsten Release, und es ist der eine Teil deiner Antwort, den der Fragende auch aus einem Prompt hätte holen können. Was er nicht prompten kann, ist die Gewichtung: wie du die Optionen verglichen hast, was es dich gekostet hat, als du falsch gewählt hast, worauf du jetzt achten würdest. Genau das weiterzugeben macht den Fragenden besser, und macht ihn eines Tages selbst zu jemandem, den zu fragen sich lohnt.

Ich behaupte nicht, dass dieses Fenster ewig hält. Jedes andere Fenster in dieser Geschichte hat sich verschoben, und dieses kann sich auch verschieben. Aber heute, wenn dir jemand sein Projekt bringt und fragt, was du tun würdest, halte kurz inne und sieh, was da passiert ist. Er hatte eine Maschine, die alles beantwortet, und hat die Frage trotzdem zu dir gebracht. Nimm sie ernst, und antworte so, dass man deine Gründe sieht.