Prinzipien vor Werkzeugen

Vor ein paar Jahren bin ich immer wieder in dieselbe Diskussion gelaufen.

Anderes Projekt, anderes Team, dasselbe Streitgespräch. Angular oder React. Diese State-Bibliothek oder jene. Einer hatte einen Benchmark gelesen, ein anderer hatte einen Favoriten, und der Raum verbrachte einen Nachmittag damit. Währenddessen hatte niemand gefragt, wo der Zustand in dieser Anwendung eigentlich leben soll, oder was der Browser wissen darf, was der Server nicht weiß.

Es fühlte sich an, als würden Leute darüber streiten, welche Marke Hammer sie kaufen, bevor irgendjemand den Bauplan angesehen hat.

Ich war damals zwischen Kundenprojekten unterwegs, und das ist die Sache, wenn man viele davon sieht: Man hört auf, die Unterschiede zu bemerken, und fängt an, das Wiederkehrende zu sehen. Das hier kam überall vor.

Was tatsächlich gefehlt hat

Niemand hat darüber gesprochen, was eine Single-Page-App eigentlich ist.

Routing. Zustand, der an einer bestimmten Stelle liegt. Eine Grenze zwischen dem, was der Server weiß, und dem, was der Browser weiß. Rendering, das verlässlich bleibt, während Daten zu spät eintreffen. Diese Probleme gehören keinem Framework. Sie sind da, ob man sie mit Angular löst, mit React oder mit dreihundert Zeilen eigenem Code.

Ein Framework ist eine Sammlung von Antworten auf diese Fragen. Wer die Fragen nicht kennt, kann die Antworten nicht beurteilen. Er kann nur dem folgen, der dieses Quartal am lautesten ist.

Das erste Mal ausgesprochen habe ich das im Juni 2016, als interner Tech Talk bei Micromata. Aus diesem Vortrag ist alles andere entstanden: eine schriftliche Fassung für heise Developer Anfang 2017 und derselbe Vortrag auf der enterJS im selben Jahr.

Zehn Jahre später hat fast jeder, der diese Diskussionen gewonnen hat, mindestens zweimal das Framework gewechselt. Die Anwendungen, die gut gealtert sind, waren nicht die, die richtig gewählt hatten. Es waren die, bei denen jemand die Grenzen klar genug gezogen hatte, dass sich eine Schicht noch austauschen ließ.

Dasselbe Gefühl, nur schneller

Ich habe dieses Gefühl gerade wieder, und diesmal geht es schneller.

In den Jahren danach habe ich als Freiberufler viele Unternehmen von innen gesehen, von Marktplätzen bis Fintech, und das Muster ist nie verschwunden. Nur das Vokabular hat sich geändert.

Neue KI-Werkzeuge erscheinen schneller, als irgendjemand sie lernen kann. Jede Woche gibt es ein Modell, ein Framework, eine Agenten-Laufzeit, ein Protokoll, das alles verändern wird. Die Vergleichstabellen sind zurück. Die Grabenkämpfe auch.

Und dasselbe fehlt. Nicht welches Werkzeug, sondern worin das Problem eigentlich besteht.

Retrieval ist ein Suchproblem, bevor es ein Vektordatenbank-Problem ist. Ein Agent, der handelt, ist ein Grenzproblem: Was darf er anfassen? Was passiert, wenn er falsch liegt? Und wie würde man es überhaupt merken? Die Frage, ob ein System besser geworden ist, ist ein Messproblem, und Messen war schon schwer, lange bevor es KI hieß.

Nichts davon ist neu. Neu ist, wie billig es geworden ist, etwas zu bauen, das aussieht, als würde es funktionieren. Die Framework-Kriege haben schlechte Architektur langsam produziert. KI produziert sie schnell, und das Ergebnis ist in der Demo gut genug, dass niemand die nächste Frage stellt.

Routen und Karten

Werkzeuge lernen ist wie Routen auswendig lernen. Es funktioniert wunderbar, bis eine Straße gesperrt ist.

Prinzipien sind die Karte. Langsamer zu bekommen, und danach kommt man überall hin, auch dorthin, wo man noch nie war.

Zwei Karten braucht man, und zwar beide:

Software. Wo liegt der Zustand? Was ist eine Grenze, und wer darf sie überschreiten? Was passiert, wenn ein Aufruf fehlschlägt? Woran würde ich merken, dass das hier kaputt ist? Nichts davon hat sich geändert, und KI senkt die Anforderung nicht. Sie erhöht sie, weil der Code jetzt schneller entsteht, als ihn jemand lesen kann.

KI. Was Retrieval wirklich tut und wo es kippt. Warum ein Agent, der handeln darf, andere Leitplanken braucht als einer, der nur antwortet. Wozu eine Bewertungsschleife da ist, und warum ein System, das nicht sagen kann, dass es schlechter geworden ist, irgendwann schlechter wird.

Mit beidem ist ein neues Werkzeug eine kleine Frage: Beantwortet es ein Problem, das ich habe? Mit keinem von beidem ist jede Veröffentlichung eine Entscheidung, für die einem das Rüstzeug fehlt, und dann entscheidet man nach Gefühl.

Die eine Frage

Bevor KI in ein Produkt kommt, in meins oder in das eines Kunden, stelle ich immer dieselbe Frage.

Welches Problem löst das, und woran werde ich merken, dass es funktioniert hat?

Gibt es darauf keine Antwort, ist das Werkzeug nicht die Lösung, so gut es auch sein mag. Manchmal lautet die ehrliche Antwort, dass ein geplantes Skript und ein klarer Prozess einen Agenten schlagen, im Betrieb nichts kosten und nie halluzinieren. Das sage ich auch dann, wenn es mich das interessantere Projekt kostet, denn die Alternative ist ein System, das jemand pflegen muss und niemand erklären kann.

Prinzipien vor Werkzeugen hieß nie, Werkzeuge zu ignorieren. Ich benutze viele, und ich tausche sie oft. Es heißt, genug zu wissen, um zu wählen, und genug, um aufzuhören.

Die Werkzeuge haben sich seit diesem Vortrag von 2016 dreimal geändert. Die Prinzipien nicht.