Programar por voz: código, review e commits
«Programar por voz» soa normalmente a palhaçada. Aquele vídeo de 2017 em que o developer grita «open paren if foo equals equals null close paren» é um meme, não um workflow. Eu também durante muito tempo achei que a ideia estava morta.
O Commander Flow mudou-me a perspectiva. Não por ter um modo mágico de «ditado de código». Mas porque código não é só código. Código é commits, tickets, code-review, documentação, comentários, nomes, conversas com colegas. E tudo isto à volta do código — agora faço por voz.
Onde a voz muda mesmo a vida ao developer
A minha operação por voz mais frequente são as mensagens de commit. Ponho o cursor em git commit -m "...", mantenho a tecla premida, digo algo como «corrigi race condition no cancelamento da pipeline, cancelamos correctamente o token quando se volta a carregar no atalho», e no terminal aparece a mensagem pronta em conventional commits, porque uma vez ditei as regras por voz — e ficaram guardadas.
As descrições de PR são parecidas, só que mais longas. Abro o template de PR no GitHub, dito como explicaria a um júnior — o que muda, porquê, o que não tocamos, como testar. Em poucos segundos saí com um markdown arrumado com cabeçalhos ## Context, ## Changes, ## Test plan. Antes levava cinco minutos, agora — segundos.
O que mais mudou para mim foram os comentários de code-review. Antes tinha preguiça de escrever reviews completos: muita escrita para algo que se lê e esquece. Agora selecciono a linha, dito a ideia por voz, e recebo um comentário claro e polido literalmente em segundos. Os meus reviews ficaram bastante mais longos e visivelmente mais úteis, e a equipa nota.
À parte: a documentação. A parte mais dolorosa da profissão. Dito a docstring como explicaria a um colega, e o Commander Flow põe-na no estilo do XML-doc, TSDoc ou markdown — consoante a linguagem do projecto. A documentação deixou de ser o imposto que pago sobre o código.
«Não escrevo código por voz. Escrevo tudo o que está à volta do código por voz. E percebi que isso é metade do meu trabalho.»
O modo code-comments: uma coisa à parte de que gosto
Por isso digo simplesmente por voz «deixa como comentário de código» — e o Commander Flow:
- Não toca em identificadores em inglês (variable names, class names)
- Mantém os termos (kubectl, async/await, useEffect, OAuth) na grafia original
- Não acrescenta cortesias «desnecessárias» (ninguém escreve «caros leitores» em comentários de código)
- Lida correctamente com os dois alfabetos no mesmo comentário:
// verificar que Subscription.IsActive antes de chamar BillingService.Refresh
Parece pouca coisa. Mas, sem essa indicação por voz, os primeiros builds em alpha às vezes «requintavam» o meu comentário técnico até ficar tipo «vamos verificar se o nosso objecto de negócio de subscrição se encontra correcto».
O dicionário de termos — funcionalidade subestimada
Em PolishOptions.Dictionary meto os meus termos e siglas. Tenho lá:
kubectl,helm,argocd,fluxIDictionary,IAsyncEnumerable,Span<T>ConfigureAwait(false)(inteiro, como expressão — para o LLM não a reescrever)- Siglas da empresa, nomes de serviços internos
Depois disto, o LLM deixa de «melhorar» os termos específicos e mantém-nos exactamente como os defini.
O cenário que me convence todos os dias
10:30, estou no IDE, ao lado o chat da equipa, ao lado o Linear com o ticket. Mantenho o atalho premido e digo:
«Tirei a lógica de retry para uma classe RetryPolicy à parte com backoff exponencial, adicionei testes, vê também o sequence diagram no ticket antes do merge»
Sai como comentário no ticket do Linear. A seguir — Alt+Tab para o Slack, mesmo atalho:
«equipa, abri PR para review, não bloqueante mas idealmente hoje»
Em estilo Slack, com minúsculas, sem «caros colegas». A seguir — de volta ao IDE.
Três acções em três aplicações, tudo por voz, zero dedos.
Onde tropecei
Pontuação dentro de código que cai a meio do ditado. Se eu dito «esta função devolve Task<bool>», às vezes o LLM «pensa» que Task<bool> é HTML e tenta escapar caracteres. Resolvido adicionando o termo ao dicionário, mas no início surpreendia.
Conflitos de atalhos com o IDE. O meu IDE tem os seus próprios atalhos. Tive de remapear o atalho do Commander Flow uma vez ou outra para não conflituar. Hoje está em Caps Lock — a tecla mais conveniente e menos usada. Pequeno incómodo, resolveu-se num clique nas definições.
Os modos mais pesados podem «pensar» um pouco mais devagar dentro do IDE. Para um email, uns milissegundos extra não se notam. Para um comentário de código «aqui e agora», notam-se. Passei para o modo médio no portátil de trabalho e deixei o mais potente para o desktop com GPU dedicada. A latência desapareceu.
O que percebi sobre o som como interface de programação
A voz não substitui o teclado no IDE. Complementa-o onde o teclado era a pior ferramenta. Escrever if (x != null && y != null) — teclado. Explicar porque esta verificação está aqui — voz.
Entre estas duas tarefas há um abismo de carga cognitiva e não se «resolvem» igualmente bem com escrita. Deixei de me obrigar a escrever a segunda categoria. Ficou mais fácil.
O que retive desta proporção
Programar por voz não é «ditar código». É deslocar aquilo que se faz por voz. A lógica escreve-se com as mãos, tudo o que é humano à volta da lógica — por voz.
Em dez anos de profissão, nunca encontrei proporção mais confortável.
Experimente
Baixe o Commander Flow e segure Caps Lock em qualquer aplicativo. O reconhecimento é local, sem nuvem — teste grátis incluso.
