Programmera med rösten: kod, review, commits

”Programmera med rösten” låter oftast som clownskap. Klippet från 2017 där en utvecklare ropar ”open paren if foo equals equals null close paren” är ett mem, inte ett arbetsflöde. Jag trodde också länge att idén var död.

Commander Flow ändrade min uppfattning. Inte för att den la till något magiskt ”dikteringsläge för kod”. Utan för att kod inte bara är kod. Kod är commits, ärenden, code review, dokumentation, kommentarer, namn och chattar med kollegor. Och allt runtomkring koden – det gör jag nu med rösten.

Där rösten faktiskt förändrar utvecklarens vardag

Min vanligaste röstoperation är commit-meddelanden. Jag sätter markören i git commit -m "...", håller in tangenten, säger något i stil med ”fixade race condition i avbrytandet av pipelinen, vi avbryter token korrekt vid upprepad knapptryckning”, och i terminalen landar ett färdigt meddelande enligt conventional commits, för jag har en gång angivit reglerna med rösten – och de finns kvar.

PR-beskrivningar fungerar nästan likadant, bara längre. Jag öppnar GitHub-PR-mallen, dikterar som om jag förklarade för en junior – vad som ändras, varför, vad vi inte rör, hur det testas. Några sekunder senare har jag prydlig markdown med rubriker som ## Context, ## Changes, ## Test plan. Det tog mig fem minuter förr, nu sekunder.

Det viktigaste skiftet för mig är code review-kommentarer. Förr orkade jag inte skriva utförliga reviews – för mycket skrivande för något som läses och glöms. Nu markerar jag en rad, dikterar tanken med rösten och får en putsad tydlig kommentar inom ett par sekunder. Mina reviews har blivit betydligt längre och tydligt mer användbara, och teamet ser det.

Och så dokumentationen, yrkets ömmaste punkt. Jag dikterar en docstring som om jag förklarade för en kollega, och Commander Flow lägger den i XML-doc, TSDoc eller markdown – beroende på projektets språk. Dokumentation är inte längre en skatt jag betalar bredvid koden.

”Jag skriver inte kod med rösten. Jag skriver allt runt koden med rösten. Och insåg att det är hälften av mitt jobb.”

Code-comments-läget: en grej jag älskar

Därför säger jag bara ”behåll det som en kod-kommentar” – och Commander Flow:

• Rör inte identifierare på engelska (variabelnamn, klassnamn)
• Behåller termer (kubectl, async/await, useEffect, OAuth) i ursprunglig stavning
• Lägger inte till ”överflödiga” artighetsfraser (ingen skriver ändå ”bästa läsare” i kodkommentarer)
• Fungerar korrekt med två alfabet i samma kommentar: // kontrollera att Subscription.IsActive innan BillingService.Refresh anropas

Det låter som en småsak. Men utan den röstledtråden ”förädlade” de tidiga alfa-byggena ibland min tekniska kommentar till ”låt oss kontrollera att vårt prenumerationsobjekt är giltigt”.

Termordboken — en underskattad finess

I PolishOptions.Dictionary stoppar jag in egna termer och förkortningar. Jag har:

• kubectl, helm, argocd, flux
• IDictionary, IAsyncEnumerable, Span<T>
• ConfigureAwait(false) (som hel fras – så LLM:en inte skriver om den)
• Företagets förkortningar och interna tjänstnamn

Efter det slutar LLM:en att ”förbättra” specifika termer och låter dem stå precis som jag sa dem.

Scenariot som övertygar mig varje dag

Klockan 10:30, jag är i IDE:n, teamchatten ligger bredvid och Linear med ärendet bredvid. Jag håller in snabbkommandot och säger:

”Bröt ut retry-logiken till en separat klass RetryPolicy med exponentiell backoff, lade till tester, kolla också sequence-diagrammet i ärendet innan merge”

Det åker iväg som kommentar i Linear-ärendet. Sedan – Alt+Tab till Slack, samma snabbkommando:

”teamet, jag har lagt upp PR för review, inte blockerande men gärna idag”

I Slack-stil, gemener, utan ”bästa kollegor”. Sedan – tillbaka till IDE:n.

Tre handlingar i tre appar, allt med rösten, inga fingrar.

Där jag har snubblat

Skiljetecken i kod som hamnar mellan dikteringen. När jag dikterar ”den här funktionen returnerar Task<bool>” så ”tror” LLM:en ibland att Task<bool> är HTML och försöker escape:a det. Löst med en post i ordboken, men det överraskade i början.

Snabbkommandokonflikter med IDE:n. Min IDE har egna genvägar. Jag fick byta Commander Flows snabbkommando ett par gånger för att slippa krock. I dag är det på Caps Lock – den bekvämaste och minst använda tangenten. En liten olägenhet, löst med ett klick i inställningarna.

De tyngsta lägena kan ”tänka” lite långsammare i IDE:n. För ett mejl är extra millisekunder osynliga. För en kommentar i koden ”här och nu” – märkbart. Jag växlade till medellägret på arbetsdatorn och sparar det tyngsta för stationära med dedikerat grafikkort. Latensen försvann.

Vad jag förstod om ljud som programmeringsgränssnitt

Rösten ersätter inte tangentbordet i IDE:n. Den kompletterar det där tangentbordet var det sämsta verktyget. Att skriva if (x != null && y != null) – tangentbord. Att förklara varför kontrollen behövs – röst.

Mellan de två uppgifterna finns en avgrund av kognitiv belastning, och de ”löses” inte lika bra med skrivandet. Jag har slutat tvinga mig att skriva den andra typen. Det blev lättare.

Vad jag drog ur den proportionen

Programmering med rösten är inte ”diktera kod”. Det är ett skifte i vad du gör med rösten. Logiken skriver du med händerna, allt mänskligt runt logiken – med rösten.

På tio år i yrket har jag inte hittat en bekvämare proportion.