Diktering, der overlever terminalen

Udviklere, der prøver dikteringsværktøjer, rammer ofte en fejl med en meget bestemt form. Værktøjet virker smukt i demoen. Det virker i Noter, i Slack, i browseren. Så giver du en terminal fokus, dikterer en sætning, og enten dukker der ingenting op, eller også dukker der noget op, som ikke er det, du sagde, eller halvdelen dukker op, og den anden halvdel ligger nu mystisk nok i din udklipsholder. Nogle gange virker det lokalt og dør i det øjeblik, du SSH'er ind på en maskine.

Mønstret er konsistent nok til, at jeg ikke tror, det er en fejl i ét bestemt produkt. Det er en konsekvens af, hvordan kategorien indsætter tekst — og det fejler præcis de steder, hvor en udvikler bor.

Det betyder mere nu end for to år siden. Styrer du Claude Code med stemmen — det workflow, jeg beskrev i Sådan styrer du Claude Code med stemmen — så er terminalen ikke én app blandt mange. Den er appen. Det er dér, dine prompts lander, dér dine agenter venter på kursændringer, dér hele det med parallelle lanes enten virker eller ikke gør. Et dikteringsværktøj, der er ustabilt i terminaler, er for en vibecoder ustabilt i sit eneste job.

Hvorfor fejler indsættelse præcis dér, hvor udviklere bor?

Her er mekanikken på kategoriniveau. De fleste dikteringsværktøjer indsætter tekst på samme måde: de lægger din transskriberede sætning på systemets udklipsholder og syntetiserer så et Cmd+V-tastetryk i den app, der har fokus. Det er en fornuftig standard — indsættelse er øjeblikkelig, det virker i næsten alle GUI-tekstfelter, og det krævede næsten ingen ingeniørarbejde per app.

Problemet er alt det, den antagelse stilfærdigt afhænger af.

Den afhænger af, at appen med fokus behandler Cmd+V som »indsæt«. Det gør terminaler ofte ikke — mange bruger Cmd+V til noget andet eller til ingenting, tmux og vim har deres egne idéer om, hvad indsættelse betyder, og en fjern SSH-session kan fortolke en byge af indsat tekst på måder, den lokale maskine ikke kan forudsige. Bracketed paste, copy-mode, insert-mode kontra normal-mode: terminalverdenen er fuld af tilstande, hvor en syntetisk indsættelse lander forkert eller ikke lander nogen steder.

Den afhænger af, at udklipsholderen er tilgængelig og ubevogtet. Udklipsholder-managere skriver den om. Adgangskodemanagere rydder eller beskytter den bevidst — en sikkerhedsfunktion, der lydløst gør »indsæt min diktering« til »indsæt ingenting«. Og selv når alt virker, overskrev værktøjet lige det, du havde kopieret. Den commit-SHA, du bar mellem vinduer, er væk, erstattet af din egen sætning. For en, der jonglerer flere lanes, er det ikke en papirskramme; udklipsholderen var i gang med et job.

Og den afhænger — og det er den, der overrasker folk — af dit tastaturlayout. Når et værktøj falder tilbage på at simulere tastetryk, er den naive metode at sende tastatur_koder_: de fysiske tastepositioner. Tastekoder oversættes til tegn gennem dit layout. På QWERTY giver koden for »V« et V. På Dvorak er den samme fysiske position et andet bogstav. Så et værktøj, der simulerer scancodes på et Dvorak-, AZERTY- eller Colemak-layout, producerer tekst, der ser ud, som om den er gået gennem et substitutionschiffer. Brugere melder om volapyk og antager, at talegenkendelsen fejlede. Det gjorde den ikke — talen var perfekt, indsættelsen rodede den sammen.

Intet af det er ondskab eller dovenskab fra nogens side. Indsættelse fra udklipsholderen er den rigtige standard i de 90 % af tilfældene. Det er bare sådan, at udviklere tilbringer deres dag i de andre 10 %.

Hvad »skriv den i stedet« faktisk betyder

Keebye har en indstilling, der hedder insert_mode, med to værdier: paste, som er standarden, og type.

Skrivetilstanden indsætter ikke. På macOS bruger den CGEventKeyboardSetUnicodeString — et API, der hæfter den faktiske Unicode-tekst på en syntetisk tastehændelse. Tegnet bæres i selve hændelsen og slås ikke op gennem dit tastaturlayout. Det gør den layout-uafhængig ved konstruktion: Dvorak, AZERTY, Colemak, hvad du end skriver på, den tekst der ankommer, er den tekst der blev transskriberet, fordi der aldrig var en oversættelse fra scancode til tegn, der kunne gå galt.

Skrivetilstandens anden egenskab er den, terminalbrugere går op i: den rører aldrig udklipsholderen. Nul operationer på udklipsholderen i den kodesti. Indholdet af din udklipsholder forbliver dit — SHA'en overlever, adgangskodemanageren har intet at værne mod, udklipsholder-manageren har intet at logge.

Og fordi terminaler og fjernsessioner kan sætte i halsen, når tekst ankommer hurtigere, end noget menneske skriver, tempoerer skrivetilstanden sig bevidst: teksten går ind i bidder på 16 tegn med et mellemrum på 4 millisekunder mellem bidderne. Hurtigt nok til, at en sætning lander på et godt stykke under et sekund; afmålt nok til, at et tmux-panel over SSH modtager den som tastetryk, det kan følge med i, og ikke som en klump, det skal fortolke.

Indsætningstilstanden er der stadig og er stadig standarden, for den er reelt hurtigere til store blokke tekst i almindelige GUI-apps — en Slack-besked på tre afsnit ankommer som én indsættelse frem for en strøm af bidder. Selv indsætningstilstanden har dog lært layout-lektien: det syntetiske Cmd+V bruger den fysiske V-tastekode, så indsættelsen i sig selv ikke går i stykker på ikke-QWERTY-layouts, sådan som tilgange med tegnopslag kan.

Den praktiske opsætning til agent-arbejde er enkel: sæt insert_mode til type, giv terminalen med Claude Code fokus, hold tasten nede, sig kursændringen, slip. Prompten ankommer, som tastetryk ville, for så vidt terminalen kan se, er det, hvad de er. Der findes en trin for trin-udgave af den opsætning, inklusive detaljerne om SSH og tmux, i stemmediktering til macOS-terminalen.

De ærlige grænser

Skrivetilstanden er langsommere end indsættelse til lang tekst — det er regnestykket, ikke en defekt. Tastetryk i bidder med tempo-mellemrum tager længere tid end en enkelt indsættelseshændelse, og dikterer du flere afsnit ind i et dokument, vil indsætningstilstanden føles kvikkere. Det er præcis derfor, indsættelse forbliver standarden, og skrivetilstanden er noget, du selv slår til i indstillingerne; den rigtige tilstand afhænger af, hvor din tekst skal hen.

Nogle programmer begrænser eller filtrerer syntetisk input, som regel af sikkerhedsgrunde, og ingen indsættelsesstrategi slipper helt uden om det — en app, der afviser syntetiske hændelser, afviser dem fra alle dikteringsværktøjer.

Og for at være klar om, hvad denne artikel påstår og ikke påstår: klagen over, at indsættelse fejler i terminaler, er et mønster på tværs af dikteringskategorien, ikke en defekt, der er unik for en konkurrent. Andre værktøjer har deres egne svar og deres egne styrker — vi skrev ærlige sammenligninger på Keebye vs. Superwhisper og Keebye vs. Wispr Flow, inklusive hvor hver af dem måske passer bedre til dig.

Indsættelse er dikteringens uglamourøse halvdel

Talegenkendelse får al opmærksomheden — modelnavne, påstande om præcision, antal sprog. Men et dikteringsværktøj har to job: at høre dig rigtigt og derefter få teksten hen, hvor din cursor er, uden at miste eller mishandle den. Det andet job lyder trivielt og er dér, hvor kategorien stilfærdigt svigter udviklere, for det andet job er nemt i TextEdit og svært i et tmux-panel på en fjern maskine under et Dvorak-layout.

Lander dine prompts i terminaler — og styrer du kodeagenter, gør de det — er indsættelse ikke en fodnote. Det er forskellen mellem et værktøj, du laver demo af, og et værktøj, du bruger. Beslægtede fejltilstande har i øvrigt samme smag: at det første ord i en diktering bliver ædt af mikrofonens koldstart er endnu en klage på tværs af kategorien med en mekanisk forklaring, og den skrev vi om i derfor æder dikteringsapps dit første ord.

Keebye er i early access til macOS. Er din diktering nogensinde forsvundet et sted mellem din mund og en terminal, så start din gratis prøveperiode nedenfor, slå skrivetilstand til, og prøv den samme prompt igen. Din kopierede SHA bliver liggende i udklipsholderen, mens ordene ankommer som skrevet Unicode.