Como programar uma feature por voz no Codex e revisar o PR antes do merge

Fala aí, beleza? O Simon Willison acabou de mostrar que dá pra entregar uma feature inteira de Django conversando com o laptop enquanto faz a janta 😀

Em 9 de outubro de 2026 ele publicou a página Newsletters do blog dele, um índice das newsletters semanais gratuitas do Substack e das mensais exclusivas para sponsors

E construiu isso quase todo por voz!

O setup dele foi a aba Codex do app ChatGPT para desktop, no modo de conversa por voz, com o GPT-6 Astra High rodando sobre o checkout local do repositório simonwillisonblog

No fim? Um pull request revisado no GitHub antes do merge

Se liga: este guia segue o fluxo que ele contou no relato original, não é teste meu, beleza?

O que é o modo de voz do Codex no app ChatGPT desktop?

O ChatGPT Voice no app desktop foi lançado em 23 de julho de 2026, quando a OpenAI anunciou e começou a liberar o recurso no mundo todo no mesmo dia

Ele adiciona uma interface de voz ao vivo ao Work e ao Codex dentro do app do ChatGPT para desktop. Com ela, você fala e interrompe naturalmente, igual numa ligação. Quem fala, ouve e coordena o trabalho ao mesmo tempo, por baixo dessa interface, é o modelo GPT-Live

Já o modelo que o Simon usou pra trabalhar no código, o GPT-6 Astra, foi liberado ao público em 4 de setembro de 2026 para usuários pagos, numa versão restrita (depois de um preview mais limitado em 3 de setembro)

Ou seja, no caso dele a voz foi o jeito de conversar, o GPT-Live cuidou da interface falada, e o GPT-6 Astra High foi o modelo que efetivamente mexeu no projeto

O que você precisa antes de começar:

• App ChatGPT para desktop no macOS ou no Windows, que é onde a ajuda oficial da OpenAI lista o Codex por voz (a OpenAI também disse ao TechCrunch que dá pra usar o ChatGPT Voice no Codex pelo app de iOS via acesso remoto)
• Acesso ao ChatGPT Voice no app desktop, que a OpenAI começou a liberar globalmente em 23 de julho de 2026 (confira se já apareceu na sua conta)
• Permissão de acesso ao microfone, que o app pede quando você inicia a conversa por voz
• Se quiser usar o contexto do computador, o app também pode pedir as permissões Screen & Audio Recording e Accessibility
• Um projeto local já clonado na máquina
• Uma feature simples e bem delimitada que você já saiba descrever

Esse último item é o mais importante haha

O Simon escolheu a tarefa justamente por ser uma feature de Django simples o bastante pra ele ter certeza de que o modelo daria conta

E ele já tinha uma boa ideia do que queria construir antes de abrir a boca 🙂

Passo a passo: da conversa por voz ao pull request

O fluxo abaixo segue a ordem que o Simon descreveu, do primeiro prompt até a revisão do PR

1. Suba o servidor e abra o navegador (digitando, não falando)

Antes de falar qualquer coisa, na sessão do Codex sobre o checkout local, ele digitou:

Start dev server and open in browser

Por que isso primeiro? Porque te dá um preview do site em que o modelo vai trabalhar

Depois tu pode pedir pra ver as páginas novas e acompanhar o progresso visualmente, sem parar pra abrir arquivo

Erro comum deste passo: começar a falar sem o preview aberto, e aí ficar sem jeito de conferir o que está saindo

2. Inicie a conversa por voz

Pela ajuda oficial da OpenAI: abra o app ChatGPT para desktop, escolha Codex e selecione o controle de Voice (ou use um atalho configurado em Settings)

O nome muda conforme a fonte: a ajuda oficial fala em controle de Voice, e no relato do Simon o botão aparece como "Start new voice chat", à direita do botão de microfone

Erro comum deste passo: clicar no microfone achando que é a conversa. Não é! O da conversa por voz é o que fica do lado direito dele

3. Descreva escopo e restrições em linguagem natural

Pode falar do jeito que sai, com "hum", "não, espera" e tal

O trecho da transcrição dele é cheio de vai e volta, e mesmo assim o modelo entendeu o que ele queria construir

Pelo relato, na voz ele descreveu as regras de exibição: a newsletter não deveria aparecer nas páginas de tag nem na home do blog, mas deveria aparecer nas páginas por data. Também pediu que as newsletters mensais, depois de públicas, entrassem na busca do site, e as do Substack não

Antes mesmo de começar a falar, ele já tinha em mente que a feature ia envolver um model novo, uma migration, views, templates e funções de importação, embora o relato não detalhe se cada uma dessas peças foi narrada passo a passo na conversa

A transcrição completa, com hesitações e tudo, está neste Gist, vale MUITO ler pra sentir o tom

Erro comum deste passo: escopo vago. "Faz uma página de newsletters" deixa o modelo decidir tudo sozinho, e o Simon fez o contrário: disse onde aparece, onde NÃO aparece e o que entra na busca

4. Responda às perguntas de esclarecimento

No relato, o modelo respondia, às vezes fazia perguntas de esclarecimento e depois partia pra alterar o código

A conversa toda durou cerca de 30 minutos, o tempo de fazer o jantar xD

5. Peça para criar um branch e abrir um pull request

Quando terminou de cozinhar e considerou a feature praticamente completa, o Simon pediu ao Codex pra criar um branch e abrir um PR

Erro comum deste passo: pedir o PR com a feature ainda pela metade. Ele só pediu depois de julgar que estava quase tudo pronto

6. Revise o diff no GitHub antes do merge

Ele revisou o código na interface de PR do GitHub

E foi aí que apareceu o problema que a conversa não pegou (já já te conto)…

O que dá para construir por voz: o exemplo da página Newsletters

Esse é o ponto que mais impressiona, porque não foi uma telinha só

O que saiu por voz:

• Um model novo e uma migration no Django, com configuração no Django Admin
• Quatro importadores: itens recentes do Substack via RSS, os demais via API não documentada do Substack, as newsletters mensais do repositório público simonw/monthly-newsletter-archive e a newsletter privada mais recente de um repositório privado
• As páginas /newsletters/ e /newsletters/2026/
• Regras de exibição: aparece nas páginas de arquivo por dia e por mês, mas não nas de tag nem na home
• Integração com a busca do site

Ou seja, o tamanho de tarefa que coube no modo de voz foi uma feature completa de Django, mas BEM definida, daquelas que você já sabe descrever de cabeça

Limites do modo de voz: o que ainda exige teclado e revisão

O próprio relato mostra onde a coisa trava, e é bom saber disso antes de largar o teclado de vez

Credenciais precisam do teclado:

Sintoma: o Astra ofereceu exportar os dados da cópia local pra importar em produção

Causa: segundo o relato, o Simon queria scripts de importação iguais aos que ele já usa, e como parte dos dados estava num repositório privado do GitHub, era preciso criar uma nova chave de API

Solução: como ele mesmo conta, criar essa chave exigiu sentar ao teclado

Credencial não é coisa pra ditar em voz alta numa conversa, né? Deixa essa parte fora da voz desde o começo

A revisão do PR pegou o que a conversa não pegou:

Sintoma: no PR, estava quase tudo como ele precisava, exceto um dos scripts de importação, que chamava o Git via subprocess

Causa: o modelo escolheu implementar esse importador usando Git via subprocess; como esse importador precisava puxar de um repositório Git privado, o Simon achou que a API seria uma opção melhor

Solução: ele voltou a digitar e fez o Codex trocar o subprocess por um importador via API. Também ajustou a exibição nas páginas públicas. Esse trabalho, feito por teclado, levou mais meia hora de prompts digitados antes do merge e do deploy. Ou seja, declarar os padrões do projeto como restrição logo no início da conversa ajuda, mas a revisão humana do PR, e o teclado quando precisar, seguem obrigatórios

E se eu sair de perto do computador?

Pela aba Remote do app mobile do ChatGPT dá pra acessar os chats do Codex do desktop que tenham suporte

Só que esses chats não passam a fazer parte do histórico da web nem do mobile, então não espere encontrar a conversa lá depois

Vale programar por voz no Codex?

Pelo relato do Simon, vale, mas com recorte bem claro

Funciona pra features simples e bem delimitadas, que você já sabe descrever antes de começar a falar

Não é "fala qualquer coisa e sai um sistema pronto", e ainda bem haha

O resultado que dá pra verificar é um PR aberto, revisado, com os ajustes finais feitos por teclado e só então mergeado e deployado, não um merge cego

Quer fazer o teste? Escolhe uma feature pequena do teu projeto, escreve as restrições antes de falar, deixa credenciais pro teclado e revisa o diff linha por linha antes do merge =)

Até o próximo post!