Programowanie głosem: kod, review, commity

„Programowanie głosem” zwykle brzmi jak klaunada. Filmik z 2017 roku, na którym programista wykrzykuje „open paren if foo equals equals null close paren” — to mem, nie workflow. Też długo myślałem, że ta idea jest martwa.

Commander Flow zmienił mój punkt widzenia. Nie dlatego, że dodał jakiś magiczny tryb „dyktowania kodu”. Tylko dlatego, że kod to nie tylko kod. Kod to commity, ticketsy, code review, dokumentacja, komentarze, nazwy, czaty z kolegami. A wszystko wokół kodu — teraz mam głosem.

Gdzie głos realnie zmienia życie programisty

Najczęstszą głosową operacją są u mnie wiadomości commitów. Stawiam kursor w git commit -m "...", trzymam klawisz, mówię coś w stylu „naprawiłem race condition w anulowaniu pipeline'u, prawidłowo anulujemy token przy ponownym naciśnięciu skrótu”, i do terminala leci gotowa wiadomość zgodna z conventional commits, bo raz głosem ustawiłem reguły — i one się zapamiętały.

Opisy PR-ów wyglądają niemal tak samo, tylko dłużej. Otwieram szablon GitHub-PR, dyktuję jak tłumaczyłbym juniorowi — co się zmienia, po co, czego nie ruszamy, jak sprawdzać. Po kilku sekundach dostaję schludny markdown z nagłówkami ## Context, ## Changes, ## Test plan. Wcześniej szło na to z pięć minut, teraz — sekundy.

Najbardziej przewróciły się dla mnie komentarze code-review. Wcześniej leniwie pisałem rozbudowane recenzje: za dużo pisania w ramach czegoś, co przeczytają i zapomną. Teraz zaznaczam linijkę, dyktuję głosem myśl, dostaję jasny wypolerowany komentarz dosłownie w parę sekund. Moje review stały się znacznie dłuższe i wyraźnie bardziej pożyteczne, a zespół to widzi.

Osobnym wątkiem jest dokumentacja. Najbardziej bolesna część zawodu. Dyktuję docstring tak, jak tłumaczyłbym koledze, a Commander Flow doprowadza to do stylu XML-doc, TSDoc albo markdowna — zależnie od języka projektu. Dokumentacja przestała być podatkiem, który płacę kodowi.

„Nie piszę kodu głosem. Piszę wszystko wokół kodu głosem. I zrozumiałem, że to właśnie jest połowa mojej pracy.”

Tryb code-comments: osobna rzecz, którą uwielbiam

Dlatego po prostu mówię głosem „zostaw jako komentarz w kodzie" — i Commander Flow:

• Nie rusza identyfikatorów łacińskich (variable names, class names)
• Zachowuje terminy (kubectl, async/await, useEffect, OAuth) w oryginalnej pisowni
• Nie dodaje „zbędnych” uprzejmych zwrotów (i tak nikt nie pisze „szanowni czytelnicy” w komentarzach do kodu)
• Poprawnie działa z obu alfabetami w jednym komentarzu: // sprawdzamy, że Subscription.IsActive przed wywołaniem BillingService.Refresh

Brzmi jak drobiazg. Ale bez tej głosowej wskazówki pierwsze alpha-buildy czasem „uszlachetniały” mój techniczny komentarz do stanu „sprawdźmy, czy nasz biznesowy obiekt subskrypcji jest poprawny”.

Słownik terminów — niedoceniona funkcja

W PolishOptions.Dictionary wrzucam swoje terminy i skróty. U mnie tam są:

• kubectl, helm, argocd, flux
• IDictionary, IAsyncEnumerable, Span<T>
• ConfigureAwait(false) (w całości, jako fraza — żeby LLM nie przepisywał)
• Skróty firmowe, nazwy wewnętrznych serwisów

Po tym LLM przestaje „ulepszać” specyficzne terminy, zostawiając je dokładnie tak, jak je nazwałem.

Scenariusz, który przekonuje mnie codziennie

10:30, jestem w IDE, obok komunikator zespołu, obok Linear z ticketem. Trzymam skrót i mówię:

„Wyniosłem retry-logikę do osobnej klasy RetryPolicy z wykładniczym backoffem, dodałem testy, sprawdź dodatkowo sequence diagram w tickecie przed mergem”

Idzie do Linear jako komentarz do ticketu. Dalej — Alt+Tab do Slacka, ten sam skrót:

„zespole, wrzuciłem PR do review, nieblokujące ale pożądane na dziś”

W stylu Slacka, z małych liter, bez „szanowni koledzy”. Dalej — z powrotem do IDE.

Trzy działania w trzech aplikacjach, wszystko głosem, zero palców.

Gdzie się potknąłem

Punctuation w kodzie, który trafia w środek dyktowania. Kiedy dyktuję blok „ta funkcja zwraca Task<bool>”, czasem LLM „myśli”, że Task<bool> to HTML i próbuje go escape’ować. Rozwiązane przez dodanie terminu do słownika, ale na początku zaskakiwało.

Konflikty skrótów z IDE. Moje IDE ma własne skróty. Skrót Commander Flow musiałem przepiąć parę razy, żeby nie wchodził w kolizję. Teraz mam go na Caps Locku — najwygodniejszym i rzadko używanym klawiszu. Małe utrudnienie, rozwiązane jednym kliknięciem w ustawieniach.

Najcięższe tryby potrafią „myśleć” trochę wolniej w IDE. Dla maila dodatkowe milisekundy są niezauważalne. Dla komentarza do kodu „tu i teraz” — zauważalne. Przełączyłem się na średni tryb dla laptopa służbowego, a najmocniejszy zostawiłem dla desktopa z kartą graficzną. Latencja zniknęła.

Co zrozumiałem o dźwięku jako interfejsie programowania

Głos nie zastępuje klawiatury w IDE. On uzupełnia ją tam, gdzie klawiatura była najgorszym narzędziem. Stukać if (x != null && y != null) — klawiatura. Tłumaczyć, dlaczego ten check tu jest — głos.

Pomiędzy tymi dwoma zadaniami jest przepaść obciążenia poznawczego, i nie rozwiązują się one tak samo „pisaniem”. Przestałem zmuszać się do pisania drugiego rodzaju zadań. Stało się lżej.

Co wziąłem z tej proporcji

Programowanie głosem to nie „dyktowanie kodu”. To przesunięcie tego, co dokładnie robisz głosem. Logikę piszesz rękami, wszystko ludzkie wokół logiki — głosem.

Przez dziesięć lat w zawodzie nie znalazłem wygodniejszej proporcji.