Zwei Tasten, drei Gesten, zwei Betriebssysteme

Acht Wochen, zwei Betriebssysteme, zwölf Auslieferungen. Am Ende kann das Programm drei Dinge zuverlässig und genau die eine nicht, für die wir es angefangen haben. Beides steht hier, und der zweite Teil ist der lehrreichere.

1 Die Herausforderung

Jeder, der mit KI arbeitet, kennt denselben Weg. Text markieren, kopieren, Fenster wechseln, einfügen, Anweisung tippen, warten, Antwort kopieren, zurückwechseln, einfügen. Neun Griffe für eine Sache, die man in einem Satz sagen könnte. Die KI ist dabei nie das Problem. Das Problem ist der Weg zu ihr.

Die naheliegende Antwort wäre ein weiteres Fenster gewesen: ein besseres Chatprogramm, eine schnellere Oberfläche. Wir wollten das Gegenteil. Kein Fenster, kein Programm, das man öffnet, sondern etwas, das schon da ist, wenn man es braucht, und wieder weg, wenn nicht. Daraus wurden drei Anforderungen, die sich gegenseitig im Weg standen:

• Es muss ohne Blickwechsel gehen. Wer im Schreibfluss ist, sieht ins Dokument, nicht auf eine Leiste am Bildschirmrand. Jede Anzeige, die man ansehen muss, ist damit tot.
• Es muss lokal laufen. Ein Werkzeug, das an eigene Dateien soll, kann nicht auf einem fremden Server sitzen. Ein Server ohne Zugriff aufs Laufwerk kann eine Datei nicht öffnen, egal wie klug er ist.
• Es muss auf beiden Betriebssystemen gut sein. Ein Programm, das sich in Tastenkürzel, schwebende Fenster und Audioaufnahme einhakt, greift so tief ins System, dass die bequeme Lösung ausfällt.

Die dritte war die teuerste, und sie wurde am ersten Tag bewusst so entschieden: zwei eigenständige Programme, von Anfang an parallel, ohne gemeinsame Oberfläche. Der Preis dafür ist jede Änderung zweimal. Der Grund ist einfach: Was das Programm können soll, geht ohne die Bordmittel des jeweiligen Systems nicht.

2 Die Lösung, Schritt für Schritt

Sechs Bauteile. Drei davon sieht man, drei nicht. Das erste ist das eigentliche Produkt.

1. Eine Tastenkombination, drei Gesten. Halten heißt sprechen. Einmal kurz tippen heißt: Nimm, was ich markiert habe, als Kontext dazu. Zweimal tippen wechselt den Modus. Unterschieden wird allein über die Zeit, und genau deshalb muss man nicht hinsehen.
2. Ein Ton statt einer Anzeige. Beim Sprechstart sagt ein kurzer Klang, in welchem Modus man ist. Das klingt nach einem Detail und ist die wichtigste Entscheidung der ganzen Oberfläche: Eine Anzeige müsste man ansehen, ein Ton nicht.
3. Der Text wird gespeichert, bevor das Modell ihn anfasst. Wer drei Minuten in ein Feld gesprochen hat und danach eine Fehlermeldung statt seines Textes sieht, verliert nicht Zeit, sondern Arbeit. Deshalb diese Reihenfolge.
4. Rückfall auf den Normalzustand. Nach fünf Minuten Ruhe geht die Leiste zurück aufs Diktieren. Ohne das wäre der Modus ein Zustand, den man sich merken muss, und gemerkt wird er nie.
5. Alles bleibt auf dem Rechner. Der Verlauf ist lokal. Das ist keine Sparmaßnahme, sondern die Bedingung dafür, dass das Werkzeug überhaupt an eigene Dateien darf.
6. Zwei Programme, zweimal gebaut. Für Windows und für den Mac, jeweils mit den Mitteln des Systems. Kein gemeinsamer Oberflächen-Code, und genau das war die Entscheidung mit dem höchsten Preis.

3 Was es gekostet hat, und was es gekostet hätte

Der ehrliche Teil zuerst: Nur die rechte Spalte ist erlebt. Die linke ist gerechnet und knapp geschätzt, also für ein Team, das solche Programme schon gebaut hat. Wer sich in Tastaturhaken, Audioaufnahme und Sprachschnittstellen erst einarbeiten muss, liegt darüber.

4 Was es im Alltag spart

Hier wird es dünn, und das sagen wir lieber selbst: Für dieses Projekt gibt es keine gemessene Zeitersparnis. Was wir zählen können, sind Griffe. Also zählen wir Griffe.

5 Was wir dabei gelernt haben

• Doku ist eine Behauptung, kein Messwert. Wir wollten den Modus per gesprochenem Schlüsselwort umschalten. Die Herstellerdokumentation sagte, die Spracherkennung könne nur Englisch, also fiel der Weg als Erstes raus. Später haben wir aus Verzweiflung nachgemessen: Sie kann Deutsch. Der zuerst ausgeschlossene Weg war der richtige. Seitdem gilt: Wenn eine Angabe eine Entscheidung trägt, wird sie gemessen, nicht gelesen.
• Ein Feature, das bei jedem zweiten Griff danebenliegt, ist schlimmer als keins. Dasselbe Umschalten war fertig gebaut und getestet, und wurde im Juli komplett wieder ausgebaut. Die Erkennung brauchte an echter Stimme mal zwei, mal drei Sekunden. Bei einem festen Lauschfenster macht das aus einer Funktion einen Münzwurf. Mit dem Feature fiel auch alles weg, was es gebraucht hatte: ein zusätzlicher Erkennungsdurchlauf, eine Kostenbremse, eine Echo-Erkennung, eine Sicherungsaufnahme. Eine Krücke am Leben zu halten kostet mehr Maschinerie als das Feature selbst.
• In derselben Schleife fanden wir ein Datenschutzproblem, das wir sonst ausgeliefert hätten. Der eingeschlagene Weg schickte das Gesagte an den Betriebssystem-Hersteller, und der Stand davor tat das stillschweigend, sobald ein Schalter zufällig an war. Die Annahme, es gehe dabei ja nur um ein einzelnes Wort, war falsch: Die Sitzung lief, solange die Taste gehalten wurde. Ein diktierter Absatz ging vollständig raus.
• Portieren heißt nicht abschreiben. Eine Live-Vorschau des Diktats direkt im fremden Dokument funktionierte auf dem Mac und wurde nach dem Praxistest trotzdem verworfen. Wer Zwischenergebnisse in ein fremdes Programm schreibt, muss dort auch wieder löschen. Dieselbe Idee, dieselbe Regel, auf der anderen Plattform ein anderes Ergebnis.
• Der Autor kann seinen eigenen Einführungsablauf nicht testen. Wir haben jemanden davorgesetzt, der das Programm nie benutzt hatte. Er kam nicht durch. Oben blinkte etwas, während unten etwas passierte, Lesen und Tun standen im selben Fenster, und die Führung lief automatisch weiter, statt auf ihn zu warten. Daraus wurde eine Regel: erst erklären, dann tun, nie beides gleichzeitig, und das Tempo bestimmt der Benutzer.
• Ein grüner Test, der die halbe Software nicht baut, ist eine Bestätigung, kein Test. Unsere Prüfstrecke läuft auf Linux und baut das Windows-Programm deshalb nicht. Ergebnis: alles grün, während der Windows-Bau kaputt war. Beide Fehler dieser Sorte lagen nie im neuen Code. Es waren alte Annahmen, die der neue Code stillschweigend gebrochen hat.

6 Was davon bei euch gilt

Die wenigsten Betriebe bauen sich ein eigenes Programm, und das sollten sie auch nicht. Übertragbar ist etwas anderes: Der teuerste Teil war nie die KI. Er war die Frage, wie ein Mensch sie im Arbeitsfluss anfasst, ohne aus dem Fluss zu fallen.

Dieselbe Frage stellt sich bei jedem Werkzeug, das ihr einführt. Nicht „was kann es“, sondern: An welcher Stelle des Tages soll es auftauchen, wie viele Griffe kostet es, und was passiert, wenn es sich irrt. Ein Werkzeug, das drei Griffe spart und einmal pro Woche Arbeit vernichtet, ist kein Fortschritt.

Die ersten sechs Punkte sind Entscheidungen. Der letzte ist eine offene Rechnung, und er steht bewusst in derselben Liste.