AI-Copiloten reichen jetzt aus, wir brauchen AI-HUDs

• Mark Weisers 1992 formulierte Kritik an der AI-„Copilot“-Metapher ist auch heute noch gültig
• Weiser plädierte nicht für einen „Assistenten“, sondern für eine Schnittstelle, die natürlich im Nutzererlebnis aufgeht
• Das Konzept des HUD (Head-Up Display) in modernen Flugzeugen veranschaulicht diese Philosophie gut
• Verschiedene Beispiele zeigen den Wert von HUD-artigen UIs, die die menschliche Wahrnehmung erweitern, statt auf Automation oder Agenten-UIs zu setzen
• Für alltägliche Aufgaben sind Copiloten effektiv, aber in kreativen oder unstrukturierten Situationen verstärken HUDs menschliche Fähigkeiten stärker

---

Mark Weisers Copilot-Kritik von 1992

• 1992 übte Mark Weiser bei einer Veranstaltung des MIT Media Lab zu „Interface Agents“ Kritik an der Sichtweise, AI als „Copilot“ zu begreifen
• Dabei wurden schon damals Themen wie Kontextbewusstsein und Automatisierung diskutiert, die auch heute noch relevant sind
• Statt eines „Copiloten“ (einer AI, die wie ein virtueller Mensch den Piloten unterstützt) befürwortete Weiser Systeme, mit denen Nutzer Informationen natürlich wahrnehmen können
• Sein Ideal war der „unsichtbare Computer“, eine Umgebung, die sich wie eine natürliche Erweiterung des Körpers des Nutzers anfühlt

HUD (Head-Up Display) und Weisers Philosophie

• Das HUD (Head-Up Display) moderner Flugzeuge blendet Schlüsselinformationen wie Horizont oder Flughöhe in ein transparentes Display ein und stellt sie so natürlich im Sichtfeld des Piloten bereit
• Anders als ein Copilot erfordert ein HUD kein Gespräch und erweitert die Wahrnehmungsfähigkeit auf natürliche Weise
• Dieses HUD-Konzept entspricht der von Weiser beschriebenen Nutzungsphilosophie

Die Umsetzung des HUD in Software

• Die Rechtschreibprüfung spricht nicht wie ein „AI-Kollaborateur“ mit dem Nutzer, sondern funktioniert, indem sie Tippfehler automatisch rot unterstreicht
• Diese Art der unmittelbaren visuellen Informationsbereitstellung ist ein Beispiel für ein HUD, das dem Nutzer einen neuen Sinn vermittelt
• Auch ein mit AI realisiertes benutzerdefiniertes Debugger-UI kann das Verhalten eines Programms intuitiv visualisieren, sodass Nutzer Probleme selbst erkennen und verstehen können
• Dieser Ansatz unterscheidet sich von traditioneller Automatisierung oder UIs im Stil eines „virtuellen Assistenten“ und erweitert menschliche Wahrnehmung direkt

Trade-offs zwischen HUD und Copilot

• Der Autor sagt ausdrücklich nicht, dass HUDs immer besser sind als Copiloten, sondern dass beide jeweils Vor- und Nachteile haben
• Für routinemäßige und vorhersehbare Aufgaben (z. B. Geradeausflug) ist der Copilot-Ansatz effizient
• Bei unstrukturierten und kreativen Problemen (z. B. Lageerfassung bei einer Notlandung) entfalten Werkzeuge, die wie ein HUD die menschliche Kognition unterstützen, große Stärke
• AI-Designer sollten sich nicht nur auf den „Assistenten“ beschränken, sondern auch UIs in Betracht ziehen, die menschliche Sinne erweitern, etwa HUDs

Fazit

• Für künftiges AI-Design ist es wichtig, den Wert und die Trade-offs sowohl des Copilot- als auch des HUD-Ansatzes zu verstehen
• Gewöhnliche Automatisierung kann man virtuellen Assistenten überlassen; wenn man herausragendere Ergebnisse will, kann der stärkste Ansatz darin liegen, menschlichen Experten wie mit einem HUD „neue Superkräfte“ zu verleihen

[GN⁺]

Hacker-News-Kommentare

• Ich wäre sehr neugierig, ob eine umschaltbare Heatmap nützlich wäre, die zeigt, wie überraschend jedes Token in einer Quelldatei für das Modell ist. Rote Tokens hätten dann mit höherer Wahrscheinlichkeit Fehler, schlechtes Naming oder falsche Kommentare
  • Manchmal ist unvorhersehbarer Code wegen eines neuartigen Algorithmus unvorhersehbar, aber in solchen Fällen ist bessere Dokumentation umso wichtiger. Wenn man den Code ordentlich erklärt, wird er dadurch selbst weniger überraschend. Anders gesagt: Es ist möglich, bestimmte Teile des Quelltexts so zu strukturieren, dass sie nicht überraschend sind, und das könnte eine gute Engineering-Praxis sein. Dank LLMs achten jetzt alle stärker auf die Bedeutung guter Dokumentation. Sie ist umso nötiger, wenn nicht nur andere Menschen, sondern auch AIs ein System lesen und verstehen sollen
  • Ich finde die Idee wirklich großartig. Umgekehrt wäre es auch extrem nützlich, wenn die Vorschläge der AI selbst eine Heatmap nach Vertrauensniveau hätten
  • Ich hätte so eine Funktion gern direkt im Editor. Das wäre auch gut, um zu prüfen, ob ein Text zu vorhersehbar oder abgedroschen ist. Perplexity zu berechnen ist auch nicht schwierig, man müsste es nur in die Editor-UI integrieren
  • Interessant. Ich habe oft das Gefühl, dass wir die „low-hanging fruits“ aus dem frühen LLM-Hype noch gar nicht richtig ausgeschöpft haben. Genau so eine Idee ist damit gemeint
  • Ich halte das für eine wirklich fantastische Idee
• Vor etwa 10 Jahren sagte Bret Victor einmal, dass die Minimierung von Feedback-Verzögerung ein Lebensprinzip sei. Er meinte, dass schnelle Iterationszyklen nicht nur beim Programmieren helfen, sondern auch zu kreativen Einsichten beitragen. Er zeigte verschiedene Beispielprogramme, die Alternativen demonstrierten, und das im OP erwähnte HUD-Beispiel ähnelt sehr seiner Demo, bei der er „durch die Zeit zurückgeht, um Code zu verstehen“. Passendes Video
• Mir gefällt die Idee, also habe ich darüber nachgedacht, wie sie sich aufs Programmieren allgemein anwenden ließe. Man könnte sich vorstellen: Während man Code schreibt, generiert ein LLM Tests, und die IDE führt diese Tests in Echtzeit aus. Bei jedem Tastendruck laufen 10 bis 100 Tests in <1ms, und die Ergebnisse werden unaufdringlich angezeigt. Die Tests erscheinen in einem separaten Panel neben dem Code, und ob der letzte Lauf bestanden oder fehlgeschlagen ist, wird durch rote/grüne Punkte markiert. Schon allein daran, welche Tests es gibt oder nicht gibt und in welchem Zustand sie sind, kann man erkennen, was der gerade entstehende Code „von außen“ tut. Wenn man denkt, dass ein Test nötig wäre, den das LLM nicht schreibt, könnte das ein Signal sein, dass der Prompt schlecht war oder der Code nicht der Absicht entspricht. Diese Echtzeit-Eigenschaft hilft stark beim Verfeinern des Codes. Wenn man klassisches TDD möchte, könnte der Nutzer auch die Tests schreiben und das LLM den Code erzeugen lassen, der sie besteht
  • Der Ansatz, dass zuerst ein Mensch die Tests schreibt und dann das LLM den Code erzeugt, ist deutlich besser. Denn die Tests sind die „Wahrheit“ und die „Absicht“ des Codes. Wenn man die Kontrolle darüber abgibt, was Eingaben und Ausgaben sind, sitzt der Entwickler nicht mehr auf dem Fahrersitz
  • In ernsthaften C++-Codebasen ist so etwas nicht umsetzbar. Allein die Compile-Zeiten machen es unmöglich, und dass ein LLM Tests errät, ist ebenfalls schwer, wenn es nicht gleich den gesamten Code schreibt. Wenn man zum Beispiel eine neue Datenstruktur baut, woher soll das LLM das wissen?
  • Dass ein LLM beim Schreiben von Code Tests generiert und die IDE sie jedes Mal ausführt, ist kein guter Ansatz. Tests sind Code, der Invarianten absichert; man kann nicht zulassen, dass ein LLM daran beliebig herumfummelt. Tests sollten sich nur ändern, wenn der Nutzer sie explizit ändert, und dann auch nur genau diese Tests. Unter diesen Einschränkungen ist das ohnehin schon ein alltäglicher Workflow. So wie der Watch-Modus von JavaScript-Test-Frameworks. Solche Workflows nutzen Entwickler bereits seit 10 Jahren
  • Braucht man dann nicht auch Tests, die prüfen, ob die Tests selbst korrekt geschrieben sind? Sonst bringt das LLM sie einfach zum Bestehen, selbst wenn die Tests falsch sind. Oder es schreibt nur Code, der das System austrickst. Am Ende funktioniert das Setup wohl am besten in einer Umgebung, in der LLM und Mensch ihre jeweiligen Grenzen flexibel überschreiten können. Klare Anforderungen zu schreiben und die AI den Großteil auf beiden Seiten erledigen zu lassen, wäre deutlich produktiver und schlanker
  • Bei jeder Eingabe die komplette Test-Suite laufen zu lassen, hat einen viel zu geringen ROI. Die meisten Tastendrücke betreffen ein noch „unvollständiges“ Programm, also müsste man den Ausführungszeitpunkt von Tests intelligenter wählen, um ein sinnvolles Gleichgewicht zu erreichen
• Am Ende läuft alles auf die Frage hinaus: „Was ist die ideale Schnittstelle dafür, wie Menschen mit digitalen Informationen umgehen?“ Wir nehmen jeden Tag immer mehr Informationen auf, und wegen AI wird diese Menge nicht kleiner, sondern größer. Wenn sogar komplexe und spezialisierte Informationen wie Fehler-Logs zusammengefasst werden, eröffnet das Menschen, die sie vorher nicht sehen konnten, neue Zugänge. Wie sollen wir also effizient mit all diesen Informationen umgehen? Im Moment gibt es alle möglichen Interfaces, Websites, Dashboards, E-Mails und Chats, aber ich frage mich, ob wir das in 10 Jahren alles noch brauchen. Wenn ich alle Informationen über eine einzige Chat-Oberfläche erhalten kann, muss ich dann überhaupt noch auf Websites gehen? Dass AI inzwischen auch noch Websites, Apps und Web-UIs für uns baut, fühlt sich inzwischen irgendwie … redundant an
  • Eine Website war bisher das Mittel, um „offizielle“ Informationen von vertrauenswürdigen Stellen wie Unternehmen oder Wikipedia zu bekommen. Dieses Vertrauen war so stark, dass wir uns mit Dingen wie der „line of death“, dem Schloss-Symbol, Phishing-Schutz und Abwehr gegen Homoglyphen-Angriffe beschäftigt haben. All das beruhte auf der Annahme, dass diese Website vertrauenswürdige offizielle Informationen liefert. In einer Welt, in der alle sich unkritisch auf LLMs verlassen, ist es wirklich schwer zu sagen, was „Vertrauen“ überhaupt noch bedeutet. Selbst wenn LLMs meistens richtig liegen: Kann man ihnen auch in wirklich kritischen Momenten trauen?
  • Designer von Kampfjets der 6. Generation stoßen auf genau dasselbe Problem. Das Cockpit ist die Schnittstelle zwischen Flugzeug und Pilot, aber seine Rolle wird immer kleiner. Bei der 7. Generation ist fraglich, ob der Mensch überhaupt noch eine wertvolle Rolle spielen kann. (Er könnte natürlich aus Gründen des Völkerrechts oder des Skynet-Risikomanagements weiterhin nötig sein.) Wahrscheinlich werden sich die Interfaces in allen Bereichen so weiterentwickeln. Die Komplexität wird immer weiter reduziert, und der Mensch muss dem System nur noch auf hoher Ebene erklären, was er will. Das muss nicht unbedingt natürliche Sprache sein; wenn präzise Spezifikationen nötig sind, könnte es auch eine entsprechend passende Schnittstelle sein
  • Da jeder Mensch anders ist, sollte man Interfaces nicht verallgemeinern, sondern sie spontan und dynamisch anpassen
  • Ich glaube nicht, dass Smartphones wirklich perfekt sind oder auch nur annähernd vollständig ausgereizt wurden. Für mich sind sie aber am attraktivsten
• Ich denke, die Fähigkeit von AI, in Echtzeit komplexe Visualisierungen zu erzeugen, wäre wirklich nützlich. Wenn man zum Beispiel ein Memory Leak auf einem bestimmten Codepfad debuggt, könnte AI die Speicherallokationen und -freigaben auf diesem Pfad visualisieren und so helfen, das Problem zu verstehen. Es scheint eine Zeit zu kommen, in der AI selbst die passenden Visualisierungstools für einzelne Probleme erstellt. Ein aktueller Vortrag von Jonathan Blow auf der LambdaConf berührt diese Idee ganz direkt. Er zeigte Tools, die Programme auf verschiedene Weise visualisieren, um potenzielle Probleme zu finden. AI könnte wahrscheinlich sehr gut darin sein, solche Tools zu bauen. Ganzes Video ansehen
• Ich möchte die Änderungen, die mit den TODO-Items von Claude Code verknüpft sind, direkt als HUD sehen. Inline-Kommentare will ich nicht, weil sie sich später anhäufen und das LLM sie nicht ordentlich aufräumt
• Einer der größten Gründe, warum sich HUDs noch nicht breit durchgesetzt haben, sind die Grenzen der heute verwendeten Display-Medien. Monitore und Mobilgeräte sind schlecht darin, periphere und nicht intrusive Informationen zu liefern. Wenn ein AI-Agent Bugs behebt oder komplexe Aufgaben bearbeitet, ist die Wartezeit auf Ergebnisse merkwürdig: zu kurz, um etwas anderes anzufangen, aber auch zu lang, um einfach nur auf den Bildschirm zu starren. Mit einem HUD hätte man viel kürzere Feedback-Loops. Man könnte mit einem Seitenblick sehen, was die AI gerade macht, und sofort eingreifen oder einfach frei mit etwas anderem weitermachen. Wichtig ist, dass man statt der extremen Wahl zwischen voller Aufmerksamkeit und völliger Passivität den Grad des Eingreifens je nach Situation innerhalb einer ambienten Wahrnehmung wählen kann. Deshalb glaube ich, dass VR/AR die zentrale Killer-App für AI-HUDs sein könnte. Durch Spatial Computing kann man AI-Unterstützung erhalten, ohne den Blick an einen 2D-Bildschirm zu fesseln. Dieser Ansatz wäre auch bei physischen Tätigkeiten wie Kochen oder Fahrradreparaturen besonders hilfreich
  • Ich nutze genau das bereits, indem ich einen Ultrawide-Monitor mit dem Laptop-Bildschirm kombiniere. Während ich in ein Spiel eintauche oder etwas anderes mache, habe ich in einer Ecke ein tmux-Fenster mit Claude offen und schaue sofort nach, wenn der nächste Schritt oder eine wichtige Veränderung auftaucht
• Ich denke, ein HUD-artiges Coding-Interface ist im Grunde genommen AREPL. Zum Debuggen passt das gut, aber Chatfenster oder Inline-Q&A lassen sich viel vielseitiger einsetzen. Insgesamt stimme ich der Logik alternativer Interfaces jenseits des Chats zu, aber realistisch gesehen ist Chat auf Smartphones bereits das dominante Interface. HUD passt wahrscheinlich besser zu echten HUDs wie AR-Brillen
• Ich halte auch AI-Modelle für möglich, die lange autonom im Hintergrund laufen und Informationen bei Bedarf „pushen“. Sie würden Situationen intelligent erkennen, filtern, zusammenfassen und Inhalte liefern, bei Bedarf auch mit Empfehlungen. Gerade in Business-Umgebungen, in denen man viele Kunden über 100 verschiedene Situationen hinweg überwachen muss, wäre das deutlich natürlicher
  • Tatsächlich ist der schwierigste Teil, die Situationen zu definieren und die relevanten Daten zu sammeln. Dass autonome Systeme das dann umsetzen, ist technisch eigentlich schon seit Langem gelöst
• Ich stimme der Aussage zu: „Wenn wir Design für AI ernst nehmen, müssen wir über simple Copiloten hinaus Formen finden, die das Innere des Menschen erweitern.“ Eigentlich erfüllt Auto-Complete diese Rolle bereits. Man kann zwar tatsächlich mit einem LLM sprechen, aber man kann ihm auch einfach Befehle geben oder Autovervollständigung nutzen. Was der Autor wohl betonen will, ist, dass AI mit uns auf derselben Seite und in dieselbe Richtung blickend arbeiten sollte. Nicht als eine Art „virtueller Mensch“-Copilot, der uns nur vom anderen Ende des Tisches aus widerspricht, sondern als echter Partner, der sofort tut, was wir wollen
  • Hier der Autor. Ja, die Autovervollständigungs-UI von GitHub Copilot ist tatsächlich (ironischerweise) ein gutes Beispiel für ein HUD. Tab-Autovervollständigung fügt sich fast wie ein Teil des Gehirns ein. Aber aktuelle Coding-Umgebungen entwickeln sich eher in Richtung Chat-Agenten. Man sollte sich vorstellen, wie eine „Tab-Autovervollständigungs“-UI auf einer höheren Abstraktionsebene aussehen könnte. Vielleicht wird das eine Art des Code-Designs, die sich wirklich direkt anfühlt und nicht von nebensächlichen Details ausgebremst wird