Програмування голосом: код, рев'ю, коміти

«Програмування голосом» зазвичай звучить як клоунада. Відео з 2017-го, де розробник кричить «open paren if foo equals equals null close paren» — це мем, а не workflow. Я теж довго думав, що ця ідея мертва.

Commander Flow змінив мою точку зору. Не тому, що додав якийсь магічний режим «диктування коду». А тому, що код — це не лише код. Код — це коміти, тікети, code-review, документація, коментарі, імена, чати з колегами. І все це навколо коду — тепер у мене голосом.

Де голос реально змінює життя розробника

Найчастіша моя голосова операція — це повідомлення комітів. Ставлю курсор у git commit -m "...", затискаю клавішу, кажу щось на кшталт «полагодив race condition у скасуванні пайплайна, коректно скасовуємо токен при повторному натисканні хоткея», і в термінал прилітає готове повідомлення за conventional commits, бо я один раз голосом задав правила — і вони запам'яталися.

Описи PR майже такі самі, тільки довші. Відкриваю шаблон GitHub-PR, диктую як пояснив би джуну — що змінюється, навіщо, що не чіпаємо, як перевіряти. За кілька секунд отримую охайний markdown із заголовками ## Context, ## Changes, ## Test plan. Раніше на це йшло хвилин п'ять, зараз — секунди.

Головне, що для мене перевернулося — це code-review коментарі. Я раніше лінувався писати розгорнуті рев'ю: забагато друку заради чогось, що почитають і забудуть. Зараз виділяю рядок, голосом надиктовую думку, отримую чіткий полірований коментар буквально за пару секунд. Мої рев'ю стали значно довші та помітно корисніші, і команда це бачить.

Окремим рядком — документація. Найболючіша частина професії. Я диктую docstring як пояснив би колезі, і Commander Flow приводить це до стилю XML-doc, TSDoc чи markdown — залежно від мови проєкту. Документація перестала бути податком, який я плачу до коду.

«Я не пишу код голосом. Я пишу все навколо коду голосом. І зрозумів, що це і є половина моєї роботи.»

Режим code-comments: окрема річ, яку я люблю

Тому я просто кажу голосом «лиши як код-коментар» — і Commander Flow:

• Не чіпає ідентифікатори латиницею (variable names, class names)
• Зберігає терміни (kubectl, async/await, useEffect, OAuth) у первісному написанні
• Не додає «зайвих» ввічливих зворотів (усе одно ніхто не пише «шановні читачі» в коментарях до коду)
• Коректно працює з обома алфавітами в одному коментарі: // перевіряємо, що Subscription.IsActive перед викликом BillingService.Refresh

Це звучить як дрібниця. Але без цієї голосової підказки перші альфа-збірки інколи «облагороджували» мій технічний коментар до стану «давайте перевіримо, чи коректний наш бізнес-об'єкт підписки».

Словник термінів — недооцінена фіча

У PolishOptions.Dictionary я закидаю власні терміни та абревіатури. У мене там:

• kubectl, helm, argocd, flux
• IDictionary, IAsyncEnumerable, Span<T>
• ConfigureAwait(false) (цілком, як фраза — щоб LLM не переписував)
• Абревіатури компанії, імена внутрішніх сервісів

Після цього LLM перестає «покращувати» специфічні терміни, залишаючи їх рівно як я їх назвав.

Сценарій, який мене переконує щодня

10:30, я в IDE, поряд телега команди, поряд Linear з тікетом. Я тримаю хоткей і кажу:

«Виніс ретрай-логіку в окремий клас RetryPolicy з експоненційним бекофом, додав тести, перевір додатково sequence diagram у тікеті перед мерджем»

Це йде в Linear як коментар до тікета. Далі — Alt+Tab у Slack, той самий хоткей:

«команда, я закинув PR на рев'ю, не блокуюче але бажано сьогодні»

У Slack-стилі, з малих літер, без «шановні колеги». Далі — назад в IDE.

Три дії в трьох застосунках, усе голосом, жодних пальців.

Де я спіткнувся

Punctuation в коді, який потрапляє між диктуванням. Якщо я диктую блок «ось ця функція повертає Task<bool>», інколи LLM «думає», що Task<bool> — це HTML, і намагається екранувати. Розв'язано додаванням терміна в словник, але спочатку дивувало.

Конфлікти хоткеїв з IDE. У моєї IDE свої гарячі клавіші. Хоткей Commander Flow довелося пару разів перепризначити, щоб не конфліктував. Зараз він у мене на Caps Lock — найзручнішій і найрідше використовуваній клавіші. Маленька незручність, розв'язалося одним кліком у налаштуваннях.

Найважчі режими можуть «міркувати» трохи повільніше в IDE. Для листа зайві мілісекунди не помітні. Для коментаря до коду «тут і зараз» — помітні. Я перемкнувся на середній режим для робочого ноутбука й залишив найпотужніший для десктопа з дискретною відеокартою. Латентність зникла.

Що я зрозумів про звук як інтерфейс програмування

Голос не замінює клавіатуру в IDE. Він доповнює її там, де клавіатура була найгіршим інструментом. Друкувати if (x != null && y != null) — клавіатура. Пояснювати, чому ця перевірка тут потрібна — голос.

Між цими двома задачами — прірва когнітивного навантаження, і вони не однаково «розв'язуються друком». Я перестав змушувати себе друкувати другий тип задач. Стало легше.

Що я взяв із цієї пропорції

Програмування голосом — це не «диктування коду». Це зсув того, що саме ти робиш голосом. Логіку пишеш руками, усе людське навколо логіки — голосом.

За десять років у професії я не знаходив пропорції зручнішої.