Diktering som overlever terminalen

Utviklere som prøver dikteringsverktøy, treffer ofte en svikt med en veldig bestemt form. Verktøyet fungerer nydelig i demoen. Det fungerer i Notater, i Slack, i nettleseren. Så gir du en terminal fokus, dikterer en setning, og enten dukker ingenting opp, eller det dukker opp noe som ikke er det du sa, eller halvparten dukker opp og den andre halvparten ligger nå mystisk nok på utklippstavlen. Noen ganger fungerer det lokalt og dør i det øyeblikket du går inn med SSH på en maskin.

Mønsteret er konsistent nok til at jeg ikke tror det er en feil i ett enkelt produkt. Det er en konsekvens av hvordan kategorien setter inn tekst — og det svikter nøyaktig på stedene en utvikler bor.

Det betyr mer nå enn for to år siden. Hvis du styrer Claude Code med stemmen — arbeidsflyten jeg beskrev i å styre Claude Code med stemmen — er ikke terminalen én app blant mange. Den er appen. Det er der promptene dine lander, der agentene dine venter på omdirigeringer, der hele greia med parallelle lanes enten fungerer eller ikke. Et dikteringsverktøy som er ustabilt i terminaler, er for en vibe coder ustabilt i sin eneste jobb.

Hvorfor brekker innliming nøyaktig der utviklere bor?

Her er mekanikken på kategorinivå. De fleste dikteringsverktøy setter inn tekst på samme måte: de legger den transkriberte setningen din på systemets utklippstavle og syntetiserer så et Cmd+V-tastetrykk mot appen med fokus. Det er en fornuftig standard — innliming er øyeblikkelig, det fungerer i nesten alle grafiske tekstfelt, og det krevde nesten ingen ingeniørarbeid per app.

Problemet er alt den antakelsen stilltiende hviler på.

Det hviler på at appen med fokus behandler Cmd+V som «lim inn». Terminaler gjør ofte ikke det — mange bruker Cmd+V til noe annet eller til ingenting, tmux og vim har sine egne ideer om hva innliming betyr, og en ekstern SSH-økt kan tolke et byge av innlimt tekst på måter den lokale maskinen ikke kan forutsi. Bracketed paste, copy-mode, insert-mode mot normal-mode: terminalverdenen er full av tilstander der en syntetisk innliming lander feil eller ikke lander i det hele tatt.

Det hviler på at utklippstavlen er tilgjengelig og ubeskyttet. Utklippstavlebehandlere skriver den om. Passordbehandlere tømmer eller beskytter den bevisst — en sikkerhetsfunksjon som gjør «lim inn dikteringen min» om til «lim inn ingenting», stille. Og selv når alt fungerer, overskrev verktøyet nettopp det du hadde kopiert. Commit-SHA-en du bar mellom vinduer, er borte, erstattet av din egen setning. For noen som sjonglerer flere lanes, er ikke det et papirkutt; utklippstavlen gjorde en jobb.

Og det hviler — dette er den som overrasker folk — på tastaturoppsettet ditt. Når et verktøy faller tilbake på å simulere tastetrykk, er den naive måten å sende tastekoder på: de fysiske tasteposisjonene. Tastekoder oversettes til tegn gjennom oppsettet ditt. På QWERTY gir koden for «V» en V. På Dvorak er den samme fysiske posisjonen en annen bokstav. Så et verktøy som simulerer scancodes på et Dvorak-, AZERTY- eller Colemak-oppsett, produserer tekst som ser ut som den har gått gjennom et substitusjonschiffer. Brukere melder om vrøvl og antar at talegjenkjenningen sviktet. Det gjorde den ikke — talen var perfekt, innsettingen rotet den til.

Ingenting av dette er ondskap eller latskap fra noens side. Innliming fra utklippstavlen er den riktige standarden for 90 %-tilfellet. Det er bare det at utviklere tilbringer dagen sin i de andre 10 %.

Hva «skriv det inn i stedet» faktisk betyr

Keebye har en innstilling som heter insert_mode, med to verdier: paste, som er standard, og type.

Skrivemodus limer ikke inn. På macOS bruker den CGEventKeyboardSetUnicodeString — et API som fester den faktiske Unicode-teksten til en syntetisk tastehendelse. Tegnet bæres i hendelsen selv, ikke slått opp gjennom tastaturoppsettet ditt. Det gjør den uavhengig av oppsett ved konstruksjon: Dvorak, AZERTY, Colemak, hva du enn skriver på, teksten som kommer frem, er teksten som ble transkribert, fordi det aldri fantes en oversettelse fra scancode til tegn som kunne gå galt.

Den andre egenskapen ved skrivemodus er den terminalbrukere bryr seg om: den rører aldri utklippstavlen. Null operasjoner mot utklippstavlen i den kodeveien. Innholdet på utklippstavlen din forblir ditt — SHA-en overlever, passordbehandleren har ingenting å beskytte mot, utklippstavlebehandleren har ingenting å logge.

Og fordi terminaler og eksterne økter kan sette seg på tekst som kommer raskere enn noe menneske skriver, går skrivemodus bevisst i takt: teksten går inn i biter på 16 tegn med et opphold på 4 millisekunder mellom bitene. Raskt nok til at en setning lander godt under ett sekund; avmålt nok til at et tmux-panel over SSH mottar den som tastetrykk den kan følge med på, ikke som en klump den må tolke.

Innlimingsmodus er der fortsatt, og fortsatt standard, fordi den er genuint raskere for store tekstblokker i vanlige grafiske apper — en Slack-melding på tre avsnitt kommer som én innliming i stedet for en strøm av biter. Selv innlimingsmodus tok lærdommen om oppsett, dog: den syntetiske Cmd+V bruker den fysiske V-tastekoden, så selve innlimingen brekker ikke på ikke-QWERTY-oppsett slik tilnærminger med tegnoppslag kan gjøre.

Det praktiske oppsettet for agentarbeid er enkelt: sett insert_mode til type, gi terminalen som kjører Claude Code fokus, hold inne tasten, si omdirigeringen, og slipp. Prompten kommer frem slik tastetrykk ville gjort, for så langt terminalen kan se, er det nettopp det de er. Det finnes en trinnvis versjon av dette oppsettet, inkludert detaljene for SSH og tmux, i stemmediktering for macOS-terminalen.

De ærlige grensene

Skrivemodus er tregere enn innliming for lang tekst — det er aritmetikk, ikke en defekt. Oppdelte tastetrykk med opphold tar lengre tid enn én enkelt innlimingshendelse, og dikterer du flere avsnitt inn i et dokument, vil innlimingsmodus føles kjappere. Det er nøyaktig derfor innliming forblir standard og skrivemodus er noe du velger til i innstillingene; riktig modus avhenger av hvor teksten din skal.

Enkelte applikasjoner rangbegrenser eller filtrerer syntetiske inndata, som regel av sikkerhetsgrunner, og ingen innsettingsstrategi slipper helt unna det — en app som nekter syntetiske hendelser, nekter dem fra ethvert dikteringsverktøy.

Og for å være tydelig på hva denne artikkelen påstår og ikke påstår: klagen om at innliming brekker i terminaler, er et mønster på tvers av dikteringskategorien, ikke en defekt som er unik for en konkurrent. Andre verktøy har sine egne svar og sine egne styrker — vi skrev ærlige sammenligninger på Keebye vs. Superwhisper og Keebye vs. Wispr Flow, inkludert hvor hver av dem kan passe deg bedre.

Innsetting er dikteringens uglamorøse halvdel

Talegjenkjenning får all oppmerksomheten — modellnavn, presisjonspåstander, språktellinger. Men et dikteringsverktøy har to jobber: å høre deg riktig, og så få teksten dit markøren din er uten å miste eller mishandle den. Den andre jobben høres triviell ut og er der kategorien stille svikter utviklere, for den andre jobben er lett i TextEdit og vanskelig i et tmux-panel på en ekstern maskin under et Dvorak-oppsett.

Hvis promptene dine lander i terminaler — og styrer du kodeagenter, gjør de det — er ikke innsetting en fotnote. Det er forskjellen mellom et verktøy du demonstrerer og et verktøy du bruker. Beslektede feilmoduser har forresten samme smak: at det første ordet i en diktering blir spist av mikrofonens kaldstart, er nok en klage på tvers av kategorien med en mekanisk forklaring, og den skrev vi om i derfor spiser dikteringsapper det første ordet ditt.

Keebye er i tidlig tilgang for macOS. Hvis dikteringen din noen gang har forsvunnet et sted mellom munnen din og en terminal, start den gratis prøveperioden nedenfor, slå på skrivemodus, og prøv den samme prompten på nytt. Den kopierte SHA-en blir liggende på utklippstavlen mens ordene kommer frem som skrevet Unicode.