Diktering som överlever terminalen

Utvecklare som testar dikteringsverktyg stöter ofta på ett fel med en mycket specifik form. Verktyget fungerar utmärkt i demon. Det fungerar i Anteckningar, i Slack, i webbläsaren. Sedan fokuserar du en terminal, dikterar en mening, och antingen dyker ingenting upp, eller så dyker något upp som inte är det du sa, eller så dyker hälften upp och den andra hälften ligger nu mystiskt nog i ditt urklipp. Ibland fungerar det lokalt och dör i samma stund som du SSH:ar in på en maskin.

Mönstret är tillräckligt konsekvent för att jag inte ska tro att det är en bugg i någon enskild produkt. Det är en följd av hur kategorin matar in text — och det fallerar exakt på de ställen där en utvecklare bor.

Det spelar större roll nu än för två år sedan. Om du styr Claude Code med rösten — arbetsflödet jag beskrev i att styra Claude Code med rösten — då är terminalen inte en app bland många. Den är appen. Det är där dina prompter landar, där dina agenter väntar på omstyrningar, där hela grejen med parallella laner antingen fungerar eller inte. Ett dikteringsverktyg som är opålitligt i terminaler är, för en vibecodare, opålitligt i sitt enda jobb.

Varför går inklistring sönder exakt där utvecklare bor?

Här är mekaniken på kategorinivå. De flesta dikteringsverktyg matar in text på samma sätt: de lägger din transkriberade mening i systemets urklipp och syntetiserar sedan ett Cmd+V-tangenttryck mot appen med fokus. Det är ett förnuftigt standardval — inklistring är omedelbart, det fungerar i nästan varje grafiskt textfält, och det krävde nästan ingen apparbete per app.

Problemet är allt som det antagandet tyst vilar på.

Det vilar på att appen med fokus behandlar Cmd+V som ”klistra in”. Terminaler gör ofta inte det — många använder Cmd+V till något annat eller ingenting alls, tmux och vim har sina egna idéer om vad inklistring betyder, och en fjärransluten SSH-session kan tolka en skur av inklistrad text på sätt som den lokala maskinen inte kan förutse. Bracketed paste, copy-mode, insert-mode mot normal-mode: terminalvärlden är full av tillstånd där en syntetisk inklistring landar fel eller inte landar alls.

Det vilar på att urklippet är tillgängligt och obevakat. Urklippshanterare skriver om det. Lösenordshanterare rensar eller skyddar det medvetet — en säkerhetsfunktion som förvandlar ”klistra in min diktering” till ”klistra in ingenting”, tyst. Och även när allt fungerar har verktyget just skrivit över det du hade kopierat. Commit-SHA:n du bar mellan fönster är borta, ersatt av din egen mening. För någon som jonglerar flera laner är det inte ett myggbett; urklippet hade ett jobb.

Och det vilar — det här är den som överraskar folk — på din tangentbordslayout. När ett verktyg faller tillbaka på att simulera tangenttryck är det naiva sättet att skicka tangentkoder: de fysiska tangentpositionerna. Tangentkoder mappas till tecken genom din layout. På QWERTY producerar koden för ”V” ett V. På Dvorak är samma fysiska position en annan bokstav. Så ett verktyg som simulerar scankoder på en Dvorak-, AZERTY- eller Colemak-layout producerar text som ser ut att ha gått genom ett substitutionschiffer. Användare rapporterar rappakalja och antar att taligenkänningen fallerade. Det gjorde den inte — talet var perfekt, inmatningen förvrängde det.

Inget av det här är illvilja eller lättja från någons sida. Inklistring via urklipp är rätt standardval för 90-procentsfallet. Det är bara det att utvecklare tillbringar sin dag i de andra 10 procenten.

Vad ”skriv det i stället” faktiskt betyder

Keebye har en inställning som heter insert_mode med två värden: paste, som är standard, och type.

Skrivläget klistrar inte in. På macOS använder det CGEventKeyboardSetUnicodeString — ett API som fäster den faktiska Unicode-texten vid en syntetisk tangenthändelse. Tecknet bärs i händelsen själv, det slås inte upp via din tangentbordslayout. Det gör läget layoutoberoende genom sin konstruktion: Dvorak, AZERTY, Colemak, vad du än skriver på, texten som kommer fram är texten som transkriberades, för det fanns aldrig någon översättning från scankod till tecken som kunde bli fel.

Skrivlägets andra egenskap är den terminalanvändare bryr sig om: det rör aldrig urklippet. Noll urklippsoperationer på den kodvägen. Innehållet i ditt urklipp förblir ditt — SHA:n överlever, lösenordshanteraren har inget att skydda sig mot, urklippshanteraren har inget att logga.

Och eftersom terminaler och fjärrsessioner kan sätta i halsen när text kommer snabbare än någon människa skriver, håller skrivläget medvetet igen på takten: texten går in i bitar om 16 tecken med 4 millisekunders lucka mellan bitarna. Snabbt nog för att en mening ska landa på klart under en sekund; avmätt nog för att en tmux-panel över SSH tar emot den som tangenttryck den hinner med, inte som en klump den måste tolka.

Inklistringsläget finns kvar, och är fortfarande standard, för det är genuint snabbare för stora textblock i vanliga grafiska appar — ett Slack-meddelande på tre stycken kommer som en inklistring i stället för en ström av bitar. Även inklistringsläget tog dock till sig läxan om layouter: den syntetiska Cmd+V använder den fysiska V-tangentkoden, så själva inklistringen går inte sönder på icke-QWERTY-layouter på det sätt som teckenuppslagning kan göra.

Den praktiska uppsättningen för agentarbete är enkel: ställ insert_mode på type, fokusera terminalen som kör Claude Code, håll in tangenten, säg omstyrningen, släpp. Prompten kommer fram som tangenttryck skulle göra, för så vitt terminalen kan avgöra är det vad de är. En steg-för-steg-version av den uppsättningen, inklusive detaljerna för SSH och tmux, finns i röstdiktering för macOS-terminalen.

De ärliga gränserna

Skrivläget är långsammare än inklistring för lång text — det är aritmetik, inte en defekt. Tangenttryck i bitar med takthållande luckor tar längre tid än en enda inklistringshändelse, och om du dikterar flera stycken in i ett dokument kommer inklistringsläget att kännas snabbare. Det är precis därför inklistring förblir standard och skrivläget är något du väljer till i inställningarna; rätt läge beror på vart din text ska.

Vissa applikationer begränsar takten på eller filtrerar syntetisk inmatning, oftast av säkerhetsskäl, och ingen inmatningsstrategi undkommer det helt — en app som vägrar syntetiska händelser vägrar dem från alla dikteringsverktyg.

Och för att vara tydlig med vad den här artikeln påstår och inte påstår: klagomålet att inklistring går sönder i terminaler är ett mönster i dikteringskategorin, inte en defekt unik för någon konkurrent. Andra verktyg har sina egna svar och sina egna styrkor — vi skrev ärliga jämförelser på Keebye vs Superwhisper och Keebye vs Wispr Flow, inklusive var var och en av dem kan passa dig bättre.

Inmatning är dikteringens oglamorösa halva

Taligenkänning får all uppmärksamhet — modellnamn, träffsäkerhetspåståenden, antal språk. Men ett dikteringsverktyg har två jobb: att höra dig rätt, och sedan få texten dit din markör är utan att tappa eller mangla den. Det andra jobbet låter trivialt och är där kategorin tyst sviker utvecklare, för det andra jobbet är lätt i TextEdit och svårt i en tmux-panel på en fjärrmaskin under en Dvorak-layout.

Om dina prompter landar i terminaler — och om du styr kodagenter gör de det — är inmatning ingen fotnot. Den är skillnaden mellan ett verktyg du demonstrerar och ett verktyg du använder. Besläktade felmoder har förresten samma smak: att dikteringens första ord äts upp av mikrofonens kallstart är ett annat klagomål på kategorinivå med en mekanisk förklaring, och det skrev vi upp i varför dikteringsappar äter ditt första ord.

Keebye är i tidig åtkomst för macOS. Om din diktering någon gång har försvunnit någonstans mellan din mun och en terminal, starta din kostnadsfria provperiod nedan, aktivera skrivläget, och gör om samma prompt. Din kopierade SHA stannar i urklippet medan orden kommer fram som skriven Unicode.