Lange Zeit habe ich an einem komplexen KI-System gebaut.
Es begann als ein ziemlich spezifisches Produkt. Mit der Zeit wuchs es um Ausführung, Werkzeuge, Gedächtnis, Berechtigungen, langlaufende Aufgaben, externe Fähigkeiten und mehrere Produktformen. Je größer es wurde, desto weniger Zeit verbrachte ich damit zu fragen, wie ich ein weiteres Feature hinzufügen könnte, und desto mehr Zeit damit, eine andere Art von Fragen zu stellen: Wo sollte eine Fähigkeit hingehören? Wer hat die letzte Autorität, sie zu interpretieren? Welche Entscheidungen sollten dem Modell überlassen bleiben, und welche Garantien müssen von der Software kommen? Wird der Mechanismus, der uns heute hilft, auszuliefern, morgen zu einer Grenze werden, aus der wir nicht mehr herauskommen?
Diese Fragen sehen aus wie Architekturfragen. In der Praxis haben sie verändert, wie ich über Software selbst denke.
Traditionelle Software ist um Anweisungen herum gebaut. Ein Programmierer legt den Pfad im Voraus fest, und die Maschine folgt ihm präzise: Wenn A passiert, tue B; wenn die Eingabe C ist, gib D zurück. Ein Großteil des Werts von Software entstand daraus, menschliches Urteilsvermögen in stabile, wiederholbare Schritte zu verwandeln.
KI verändert diese Anordnung. Zum ersten Mal können Maschinen über eine bedeutsame Bandbreite von Situationen hinweg entscheiden, was als Nächstes zu tun ist. Wir müssen nicht mehr jeden Pfad aufzählen. Wir können ein Ziel beschreiben, eine Umgebung und Feedback bereitstellen und ein Modell einen Plan bilden, Werkzeuge wählen, das Ergebnis beobachten und sich anpassen lassen.
Das kann den Eindruck erwecken, dass Software weniger wichtig wird, je fähiger die Modelle werden.
Meine Erfahrung hat mich zum gegenteiligen Schluss geführt. Software verschwindet nicht. Der Gegenstand ihrer Verantwortung verändert sich.
Früher sagte Software der Maschine, was als Nächstes zu tun ist. Jetzt kann ein Modell den nächsten Schritt wählen, aber Software muss noch immer eine andere Reihe von Fragen beantworten: Was ist wahr? Was ist erlaubt? Was gilt als abgeschlossen? Wer ist verantwortlich, wenn etwas schiefgeht? Wie wird aus einer intelligenten Handlung ein Ergebnis, dem Menschen vertrauen können?
Ich bin zu der Überzeugung gelangt:
Modelle erzeugen Möglichkeiten. Software verwandelt Möglichkeit in Ordnung.
Software ist nicht länger nur der Befehlssatz um die KI herum. Sie wird zur institutionellen Schicht der Welt, die die KI bewohnt.
Die folgenden Prinzipien entstanden nach und nach, während ich verschiedene Teile dieses Systems baute, verwarf, neu baute und verifizierte. Sie sind kein Architekturleitfaden für ein bestimmtes Produkt und auch keine universelle Methodik. Sie sind einfach die Ideen, die ich heute für wert halte, in das mitzunehmen, was ich als Nächstes baue.
1. Definiere, was du baust, bevor die heutige Oberfläche das Ziel definiert
Die gefährlichste Drift in einem langlaufenden Projekt ist nicht, ein einzelnes Feature falsch zu machen. Es ist, nach und nach zu vergessen, was man ursprünglich bauen wollte.
Produkte beginnen immer über einen konkreten Einstiegspunkt. Es mag eine Chat-Oberfläche sein, ein Desktop-Werkzeug, ein Editor, ein Browser oder eine Werkbank. Weil diese Dinge sichtbar und nutzbar sind, beginnen sie leicht, das gesamte Projekt rückwärts zu definieren: Das Projekt wird zu dem, was an Bildschirmen heute existiert, und seine Zukunft wird zur Erweiterung desjenigen Features, das derzeit am ausgereiftesten ist.
Aber das aktuelle Produkt ist oft ein Vehikel zur Validierung des Ziels, nicht das Ziel selbst.
Ich habe gelernt, drei Dinge bewusst zu trennen: was ich letztlich bauen will, das gemeinsame Fundament, das nötig ist, um dieses Ziel zu tragen, und was Nutzer heute tatsächlich verwenden können.
Die drei müssen miteinander verbunden sein, aber sie dürfen sich niemals gegenseitig vortäuschen.
Wenn du nur über das Ziel sprichst, wird das Projekt zu einer Vision ohne Lieferbares. Wenn du nur über die Gegenwart sprichst, wird das Projekt von seiner aktuellen Oberfläche und temporären Implementierung gefangen genommen. Wenn es kein gemeinsames Fundament gibt, muss jede neue Produktform Ausführung, Zustand, Berechtigungen und Gedächtnis neu erfinden.
Diese Unterscheidung hat viele meiner Entscheidungen verändert. Ich hörte auf, den Ort eines Features allein danach zu bestimmen, wo es am schnellsten implementiert werden konnte. Ich begann zu fragen, ob es eine Erfahrung ist, die dem aktuellen Produkt eigen ist, oder eine Systemfähigkeit, die auch zukünftige Produkte brauchen werden. Eine temporäre Implementierung darf unvollkommen sein, aber man sollte ihr nicht erlauben, das langfristige Ziel neu zu definieren.
Das Erste, was ein langlebiges System braucht, ist keine Roadmap. Es ist ein Gefühl für Schichten: Was ist die Richtung, was ist das Fundament, und was ist bloß die Art und Weise, wie das System heute seine Nutzer erreicht.
2. Frage „Wem gehört das?“ bevor du fragst „Wie bauen wir es?“
Ein Großteil der Komplexität in Software wird nicht durch zu viel Code verursacht. Sie wird durch Verantwortung verursacht, die kein Zuhause hat.
Wenn ein Konzept keinen klaren Eigentümer hat, beginnt es auf natürliche Weise, sich zu vervielfältigen. Die Oberfläche behält eine Version des Zustands, das Backend behält eine andere, und eine Konfigurationsdatei behält eine dritte. Keine ist offensichtlich falsch, aber keine kann die endgültige Antwort geben, wenn sie sich widersprechen.
Das System beginnt dann, Synchronisationslogik zu wachsen. Eine Änderung an einer Stelle muss die anderen beiden benachrichtigen. Eine Benachrichtigung geht gelegentlich verloren, also wird Wiederherstellung hinzugefügt. Die Wiederherstellungsreihenfolge erweist sich als instabil, also wird Kompensation hinzugefügt. Kompensation erzeugt einen weiteren Zustand, also wird Abgleich hinzugefügt. Der Code arbeitet immer härter, während das System immer schwerer zu erklären wird.
Früher fühlte ich mich sofort zur Frage hingezogen, wie man alles verbindet. Jetzt stelle ich zuerst andere Fragen:
- Wem gehört dieses Konzept wirklich?
- Wer erzeugt es, interpretiert es und beendet es?
- Wenn es deaktiviert, migriert oder gelöscht wird, welcher Teil des Systems versteht die volle Bedeutung dieser Änderung?
- Erhalten andere Komponenten die Wahrheit oder bloß eine daraus projizierte Sicht?
Erst nachdem diese Fragen beantwortet sind, spielt die Verbindungsstrategie eine Rolle.
„Eigentum“ klingt wie ein Begriff aus der Code-Organisation, aber ich denke, es drückt ein viel breiteres Prinzip aus: Alles, was Bestand hat, braucht eine Partei, die für seinen gesamten Lebenszyklus verantwortlich ist. Sonst kann jeder es ändern, aber niemand versteht es wirklich.
Das hat mir auch eine starke Vorliebe für einen einzigen endgültigen Interpreten jeder Tatsache gegeben. Andere Komponenten mögen diese Tatsache beobachten, zwischenspeichern, darstellen und nutzen, aber sie sollten keine gleichermaßen autoritativen Versionen davon erfinden.
Komplexe Systeme haben keine Angst davor, viel Zustand zu haben. Sie haben Angst davor, zu viele Autoritäten zu haben.
3. Konsolidiere Mechanismen, nicht Nutzererfahrungen
Während ein System wächst, ist das Erschaffen eines neuen Mechanismus für jede neue Anforderung sowohl die naheliegendste als auch die gefährlichste Wahl.
Eine Fähigkeit ist etwas anders, also bekommt sie einen neuen Registrierungspfad. Ein Anwendungsfall ist etwas ungewöhnlich, also bekommt er einen neuen Modus. Ein Stück Zustand hat noch kein offensichtliches Zuhause, also bekommt es einen separaten Speicher. Ein neuer Ausführungspfad ist unbequem zu integrieren, also umgeht er den bestehenden Pfad und erzeugt einen weiteren.
Jede Entscheidung sieht für sich genommen vernünftig aus. Zusammen erzeugen sie parallele Systeme für Entdeckung, Berechtigungen, Laden, Aktualisieren, Deaktivieren und Wiederherstellung. Die wahren Kosten sind nicht ein paar zusätzliche Klassen. Sie bestehen darin, dass jede zukünftige Fähigkeit dieselben Fragen erneut über all diese parallelen Mechanismen hinweg beantworten muss.
Ich habe nach und nach gelernt, zwischen zwei Arten von Vielfalt zu unterscheiden: der Vielfalt, die Nutzer erleben, und der Vielfalt, die das System intern aufrechterhalten muss.
Nutzer können und sollten auf sehr unterschiedliche Produkte, Einstiegspunkte und Interaktionen treffen. Unterschiedliche Kontexte verdienen ihre eigene Sprache und ihre eigenen mentalen Modelle. Aber unterhalb dieser Erfahrungen können Fähigkeiten durch eine kleine Zahl stabiler Mechanismen in das System eintreten, Berechtigungen erhalten und Lebenszyklen erwerben.
Konsolidiere den Mechanismus, nicht die Erfahrung.
Das Schwierige an diesem Prinzip ist, der Versuchung zu widerstehen, etwas Neues zu schaffen, weil es einfacher zu verdrahten ist. Bevor ich einen weiteren Mechanismus einführe, frage ich mich heute, ob der aktuelle den Bedarf wirklich nicht ausdrücken kann oder ob ein neuer kurzfristig einfach bequemer ist.
„Es sieht ein bisschen anders aus“ ist normalerweise kein ausreichender Grund, eine neue Achse im System zu schaffen.
Stabile Mechanismen sind nicht dazu da, Architekturdiagramme sauberer aussehen zu lassen. Sie reduzieren zukünftige kognitive Kosten: Modelle, Entwickler und Produkte müssen nicht mehr zwischen mehreren fast gleichwertigen Wegen raten, dasselbe zu tun.
4. Software sollte Konsequenzen einschränken, nicht den Denkprozess des Modells vorschreiben
Hier hat sich mein Denken am stärksten verändert.
Wenn das Verhalten des Modells inkonsistent ist, ist der natürliche Impuls, den idealen Workflow in Software zu kodieren. Verlange Recherche vor der Planung, Planung vor der Ausführung und eine abgeschlossene Phase, bevor die nächste beginnen kann. Führe nach jeder Änderung eine Verifikation aus. Füge ein weiteres Laufzeit-Gate hinzu, wann immer das Modell wahrscheinlich den falschen Weg einschlagen wird.
Diese Systeme werden in der Regel mit guten Absichten entworfen. Aber sie verwandeln sich oft in starre Pipelines. Ein Modell, das seinen Ansatz an die Größe und Form der Aufgabe anpassen könnte, wird gezwungen, jede Phase abzuschließen, selbst bei einer einfachen Anfrage. Mehrere Schutzgeländer können auch interagieren und einen Deadlock erzeugen, aus dem das Modell keinen Ausweg hat.
Ich begann, einen einfacheren Test zu verwenden, um zu entscheiden, was in die Software gehört und was beim Modell bleiben sollte: Schränkt die Regel eineMethode ein oder eineKonsequenz?
„Vor dem Bearbeiten lesen“, „vor der Umsetzung einen Vorschlag vorlegen“ und „am Ende an die Verifizierung denken“ sind Methoden. Sie gehören in Prompts, Skills und Kontext, wo das Modell sie verstehen und flexibel anwenden kann.
„Ohne Autorisierung nicht auf Daten zugreifen“, „ohne Bestätigung keinen irreversiblen Verlust verursachen“ und „eine vom Nutzer ausdrücklich deaktivierte Berechtigung nicht umgehen“ sind Grenzen für Konsequenzen. Sie dürfen nicht davon abhängen, dass das Modell sich an sie erinnert. Software muss sie durchsetzen.
Auch mechanische Schutzgeländer gegen Wiederholung, Leerlauf und Schleifen sollten sparsam eingesetzt werden. Ein erster Versuch sollte erlaubt sein. Wenn das System eine Aktion blockiert, sollte es erklären, warum. Und es muss einen klaren Weg zur Wiederherstellung bieten, statt das Modell hinter dem Schutzgeländer einzusperren.
Dies veränderte mein Verständnis der Arbeitsteilung zwischen Modellen und Software:
Gib dem Modell Ziele und Methoden. Gib der Software nicht verhandelbare Grenzen.
Wenn Software jeden Schritt des Denkprozesses vorschreibt, haben wir lediglich eine Workflow-Engine mit KI darin nachgebaut. Wenn jede Grenze nur in einem Prompt lebt, haben wir echte Verantwortung an die Wahrscheinlichkeit übergeben.
Ein gutes System vermeidet beide Extreme.
5. Die Realität eindeutig halten, statt das Modell sicher klingen zu lassen
Die Argumentation eines Modells kann offen bleiben. Seine Sprache kann variieren. Seine Pläne können überarbeitet werden. Aber sobald es beginnt, auf die reale Welt einzuwirken, dürfen manche Fakten nicht mehrdeutig sein.
Hat eine Aufgabe tatsächlich begonnen? Ist eine Änderung wirklich eingetreten? Ist eine Berechtigung aktiviert? Welche Sitzung besitzt ein Ergebnis? Die Antwort auf diese Fragen sollte sich nicht danach ändern, welcher Bildschirm sie betrachtet.
Ich betrachte Software zunehmend als die Realitätsschicht eines KI-Systems. Ein Modell kann Interpretationen der Welt anbieten, aber Software zeichnet auf, was tatsächlich in ihr geschehen ist.
Das bedeutet, dass eine Schnittstelle einen Zustand ausdrücken kann, aber nicht selbst der Zustand werden darf. Parameter, die an eine Anfrage angehängt sind, können eine Absicht ausdrücken, aber dürfen nicht vorübergehend eine dauerhafte Befugnis außer Kraft setzen. Ein Cache kann die Leistung verbessern, aber darf nicht denselben Status wie seine Quelle erlangen. Wenn das System einen Fakt nicht feststellen kann, sollte es ehrlich anhalten, statt die bequemste Antwort zu raten, um ein Gefühl von Flüssigkeit zu bewahren.
Traditionelle Software braucht ebenfalls Konsistenz, aber KI macht sie noch wichtiger. Modelle sind außergewöhnlich gut darin, von unvollständigen Informationen aus weiterzumachen und Erklärungen zu produzieren, die plausibel klingen. Wenn die zugrunde liegenden Fakten bereits auseinandergedriftet sind, kann Intelligenz an der Spitze den Widerspruch kohärenter erscheinen lassen und das Problem länger verborgen halten.
Mein Prinzip ist daher einfach: Erlaube dem Modell, unsicher zu sein, aber erlaube nicht, dass Systemfakten mehrdeutig werden.
Wenn das System etwas nicht weiß, sollte es sagen, dass es es nicht weiß. Wenn autoritative Daten beschädigt sind, sollte es sich weigern zu handeln. Wenn zwei Quellen sich widersprechen, sollte es verlangen, dass der Konflikt gelöst wird, statt stillschweigend die einfachere zu wählen.
Intelligenz kann mit Mehrdeutigkeit arbeiten. Institutionen müssen die Realität bewahren.
6. Umkehrbarkeit ist eine Voraussetzung für Autonomie
Wir definieren KI-Autonomie oft als das Stellen weniger Fragen an den Nutzer. Aber was bestimmt, ob ein Nutzer bereit ist, loszulassen, ist nicht die Anzahl der Bestätigungsdialoge. Es ist, ob das System ihn sehen, stoppen, korrigieren und wiederherstellen lässt.
Wenn jeder Schritt eine Bestätigung erfordert, wird KI zu einem halbautomatischen Werkzeug, das ständiges Klicken verlangt. Wenn nichts eine Bestätigung erfordert und es keinen Datensatz oder Weg zurück gibt, wird Autonomie zu einem Kontrollverlust.
Ich begann, einer anderen Reihe von Eigenschaften mehr Aufmerksamkeit zu schenken: Ist der Prozess sichtbar? Kann die Aktion unterbrochen werden? Können Änderungen überprüft werden? Ist die Historie nachvollziehbar? Kann sich das System nach einem Fehler in einen Zustand wiederherstellen, dessen Bedeutung klar ist?
Umkehrbarkeit ist keine zusätzliche Versicherungsschicht für den Fall, dass etwas schiefgeht. Sie ist eine Vorbedingung dafür, überhaupt Befugnisse zu erteilen.
Wenn eine Aktion leicht rückgängig zu machen ist, kann das System dem Modell mehr Raum zum Ausprobieren geben. Wenn eine Aktion irreversibel ist, sollte das System die Berechtigungen verschärfen und die Entscheidung an den Nutzer zurückgeben. Der Grad der Autonomie sollte nicht davon bestimmt werden, wie optimistisch wir einem Modell gegenüberstehen. Er sollte davon bestimmt werden, ob die Konsequenzen wiederhergestellt werden können.
Dies veränderte auch meine Definition von „fertig“. Fertigstellung ist kein grüner Status in der Schnittstelle. Es bedeutet, dass das System das Ergebnis, das verbleibende Risiko und den Weg zur Wiederherstellung klar gemacht hat. Wenn eine lang laufende Aufgabe unterbrochen wird, darf die Animation nicht einfach verschwinden. Wenn eine Änderung abgelehnt wird, darf nicht die Hälfte des Ausführungszustands zurückbleiben. Wenn eine Fähigkeit deaktiviert wird, darf die Wiederherstellungslogik sie nicht stillschweigend beim nächsten Start der Anwendung zurückbringen.
Je unabhängiger wir wollen, dass KI handelt, desto sorgfältiger müssen wir die Art und Weise gestalten, wie sie anhält und zurückkehrt.
7. Nicht nur Fehler beheben. Jeder Fehler soll ein Prinzip hinterlassen
Jedes lang laufende Projekt wird vielen Fehlern begegnen. Was Projekte unterscheidet, ist nicht, ob Fehler auftreten, sondern in welcher Form sie danach bleiben.
Die schwächste Reaktion ist, das unmittelbare Symptom verschwinden zu lassen. Eine bessere Reaktion ist, die Grundursache zu identifizieren und zu beheben. Die wertvollste Reaktion geht einen Schritt weiter: Welche Klasse von Fehler war das? Über welche anderen Pfade könnte derselbe Fehler zurückkehren? Fehlt dem System eine Regel, ein einzelner Verantwortlicher oder eine Struktur, die verhindern kann, dass das Problem zurückwächst?
Ich entwickelte die Gewohnheit, mehr als das Symptom und die Behebung aufzuzeichnen. Ich zeichne auch die Grundursache, den Verantwortlichen und die Evidenz auf, die eine Regression verhindern würde. Ein Problem, das nur durch seine Symptome beschrieben wird, ohne verantwortliche Grenze und ohne Evidenz, ist noch kein Wissen geworden.
Ein Patch behebt einen Fehler. Ein Prinzip reduziert eine ganze Klasse von Fehlern.
Wenn ein Synchronisationsfehler behoben wird, indem eine weitere Benachrichtigung hinzugefügt wird, kann er später unter einer anderen Ereignisreihenfolge zurückkehren. Wenn der Fehler stattdessen das Prinzip begründet, dass jedes Stück Zustand einen einzigen Eigentümer hat, enthalten zukünftige Designs von Natur aus weniger Synchronisationsketten. Wenn ein alter Einstiegspunkt Mehrdeutigkeit bei Berechtigungen erzeugt, wird ein weiterer Sonderfall nur einen weiteren Zweig hinzufügen. Die Feststellung, dass eine Absicht einen kanonischen Einstiegspunkt hat, gibt dem System eine dauerhafte Entscheidungsregel.
Ich denke, das ist jetzt noch wichtiger, da KI an der Softwareentwicklung teilnimmt. Code wird schneller produziert, und lokale Korrekturen werden billiger. Ohne Prinzipien kann ein System plausible doppelte Implementierungen mit beispielloser Geschwindigkeit anhäufen.
KI kann uns helfen, Patches schneller zu schreiben. Menschen müssen immer noch entscheiden, was jeder Fehler das System lehren soll.
Die wirkliche Wertanhäufung in einem Projekt ist nicht sein Codevolumen oder die Anzahl der geschlossenen Tickets. Es ist, ob die Kosten vergangener Fehler in Prinzipien umgewandelt wurden, die verhindern, dass dieselben Kosten erneut bezahlt werden.
8. Den Anschein von Vollständigkeit nicht mit Evidenz verwechseln
KI ist sehr gut darin, ein Gefühl von Vollständigkeit zu erzeugen. Sie produziert gut strukturierte Erklärungen, syntaktisch gültigen Code und beruhigende Zusammenfassungen. Aber die schwierigsten Teile der Ingenieursarbeit liegen oft außerhalb dieser Oberfläche.
Eine Schnittstelle, die keinen Fehler anzeigt, beweist nicht, dass im Hintergrund nichts weiterläuft. Eine Fähigkeit, die in einer Entwicklungsumgebung funktioniert, beweist nicht, dass sie in dem an Nutzer ausgelieferten Artefakt existiert. Die Validierung auf einer Plattform beweist nicht identisches Verhalten auf einer anderen. Code, der einen Typprüfer besteht, beweist nicht, dass ein alter autoritativer Pfad aus dem Rest des Systems verschwunden ist.
Mit der Zeit habe ich seltener gefragt „Ist es fertig?“ und häufiger „Welche Evidenz wäre ausreichend, um zu beweisen, dass es fertig ist?“
Evidenz ist nicht ein universeller grüner Indikator. Verschiedene Schichten beantworten verschiedene Fragen. Codeprüfungen stellen die lokale Struktur fest. Laufzeitvalidierung stellt den tatsächlichen Ausführungspfad fest. Artefaktinspektion stellt fest, was Nutzer tatsächlich erhalten werden. Wiederherstellungstests stellen fest, ob das System die Bedeutung unter nicht idealen Bedingungen bewahrt.
Im KI-Zeitalter geht es bei der Validierung nicht nur darum, Modelle daran zu hindern, fehlerhaften Code zu schreiben. Sie wirkt auch einem subtileren Risiko entgegen: Ein Ergebnis kann so logisch überzeugend sein, dass alle bereit werden zu glauben, es existiere bereits in der Realität.
Eine meiner wichtigsten Regeln ist, nicht von Oberflächenzustand auf zugrunde liegende Fakten zu schließen, nicht von einem lokalen Bestehen auf die Korrektheit des Gesamtsystems zu schließen und eine unverifizierte Zukunft nicht als heute gelieferte Fähigkeit darzustellen.
Die Realität zu respektieren bedeutet manchmal zuzugeben: „Das ist noch nicht fertig.“ Diese Ehrlichkeit schwächt ein Produkt nicht. Sie gibt dem System einen verlässlichen Punkt, von dem aus es sich weiterentwickeln kann.
Software wandelt sich von Anweisungen zu Institutionen
Rückblickend war das, was ich aus dieser Arbeit mitgenommen habe, nicht eine bestimmte Architektur. Es war eine andere Sicht auf KI-Software.
Früher versuchte Software, Pfade aufzuzählen. In Zukunft werden mehr dieser Pfade im Moment von Modellen generiert. Software muss der Intelligenz nicht mehr jede Handlung vorschreiben, aber sie muss eine stabile Welt bereitstellen: klare Identitäten und Eigentumsverhältnisse, Grenzen, die nicht umgangen werden können, Zustand, der die Realität bewahrt, Wege zum Ausstieg und zur Wiederherstellung sowie Belege, die feststellen, ob ein Ergebnis real ist.
Dies ähnelt der Beziehung zwischen Institutionen und Individuen.
Institutionen denken nicht für jede Person, noch sollten sie jede Handlung in ein festes Verfahren verwandeln. Sie definieren gemeinsame Realität, Rechte, Verantwortlichkeiten und was geschieht, wenn etwas schiefgeht. Gute Institutionen lassen Raum für Handeln, während sie verhindern, dass Freiheit auf Kosten der Ordnung geht.
Software beginnt, im Zeitalter der KI eine ähnliche Rolle zu spielen.
Es ist nicht das Gehirn des Modells und sollte nicht um den Job des Modells konkurrieren. Es ist das Gesetz, das Register, die Grenze und das Gedächtnis der Welt, die das Modell bewohnt. Es verwandelt eine kluge, im Moment improvisierte Handlung in eine stabile Fähigkeit. Es verwandelt einen zufälligen Erfolg in ein wiederholbares Produkt. Es ermöglicht Nutzern, der KI wichtigere Arbeit anzuvertrauen, ohne blindes Vertrauen gegen Bequemlichkeit einzutauschen.
Ich glaube nicht, dass KI Software weniger wichtig machen wird. Im Gegenteil: Je fähiger die Modelle werden, desto mehr muss Software die Fragen beantworten, die Modelle nicht selbst entscheiden sollten.
Was ist wahr?
Was ist erlaubt?
Wem gehört es?
Wie kehren wir nach einem Fehler zurück?
Welche Beweise belegen die Fertigstellung?
Modelle erkunden die Antworten. Software schützt die Fragen.
Wir bewegen uns von einer Ära, in der Menschen jeden Schritt für Maschinen schrieben, zu einer, in der Menschen Prinzipien festlegen und Maschinen Pfade erkunden. Die Rolle der Software verschiebt sich damit: vom Beschreiben von Handlungen zum Herstellen von Ordnung.
Modelle erzeugen Möglichkeiten.
Software macht diese Möglichkeiten vertrauenswürdig.