Por que escrevo meus prompts em inglês
Uma análise subjetiva e objetiva sobre o uso do português na programação agêntica
Desde que comecei a falar publicamente de inteligência artificial e programação agêntica, nenhuma crítica tem sido mais recorrente do que o fato de que escrevo meus prompts em inglês. Ora, por que eu faço isso se sou brasileiro? Afinal, se a IA ficou tão inteligente – dizem meus críticos – você não vai me dizer que ela não entende português, certo?
A esses questionamentos irônicos eu nunca tive muito a oferecer além de um subjetivo “eu prefiro assim”. Evidente que não é apenas um capricho; mas existe algo ali difícil de quantificar. Tentei, algumas vezes, apelar à argumentação, mas sem nunca ser convincente o suficiente. Pois bem, isso mudou. No artigo de hoje pretendo oferecer – além dos argumentos subjetivos, que também são importantes – uma razão objetiva do por que interagir com a IA em inglês é melhor que em português.
Note que esse conjunto de razões não visa convencê-lo a adotar o meu jeito. Existem razões legítimas para se preferir falar em português – por exemplo se você não fala inglês. Mas espero com esse texto ter algo concreto para compartilhar sempre que for abordado com aquele comentário condescendente: “muito legal o que você fala Rafael, mas hoje em dia escrever prompts em inglês é besteira...”
Os argumentos subjetivos
Quando digo que um argumento é “subjetivo”, não quero dizer que ele é necessariamente fraco, apenas que é compreensível alguém discordar de mim, ou que existem exceções. Ainda assim, rogo-lhes não descartá-los somente por não serem “científicos”.1
Comecemos pelo argumento de que um bom código é idiomático. Essa é a razão pela qual eu sempre escrevi todos os meus códigos em inglês, e também por que considero o inglês a melhor linguagem para se começar a programar. Quando lemos um código (algo que fazemos bem pouco hoje, é verdade), a fluidez é importante. Variáveis e funções cujos nomes deixam explícito o que fazem, tornam a leitura agradável e de fácil compreensão. Obviamente, como as linguagens de programação são em inglês, seguir esse padrão ajudará nessa fluidez e diminuirá a carga cognitiva.
Mas mesmo se não lermos o código, alguém irá – no caso, o agente. Sendo assim, o código passa a se incorporar ao seu harness, que também foi desenvolvido em inglês. Os melhores harnesses, como o Codex e o Claude Code, são inclusive alimento para o pós-treinamento dos modelos flagship da OpenAI e da Anthropic, o que intuitivamente nos faz crer que comunicar na mesma linguagem trará um ganho. É o mesmo raciocínio de achar que um modelo treinado majoritariamente em Python entenderá a intenção melhor nessa linguagem do que se fosse em Rust, por exemplo, ainda que você passe um manual de conversão de uma linguagem à outra.
E por fim mas não menos importante, se o inglês é a lingua franca da programação, qualquer um que decida participar seriamente da comunidade se beneficiaria (e muito) de aprender esse idioma. Além de desbloquear um sem-número de recursos, blogs, e vídeos, teria maior acesso à comunidade internacional, às discussões das ferramentas que são utilizadas no dia a dia, e de quebra estaria muito melhor posicionado para pleitear uma vaga numa empresa estrangeira, cujo work life balance costuma ser superior às contrapartes brasileiras (além do óbvio benefício financeiro).
Mas tudo isso pode ser refutado ou ignorado dependendo do seu caso. No entanto, há uma verdade inconteste: falar em português com seu agente gasta muito mais tokens, e eu posso provar.2
A economia dos tokens
Já falei exaustivamente sobre a matemática dos tokens e a economia da IA. De maneira resumida, o principal custo de se utilizar um agente de IA está na parte da inferência, onde uma máquina física precisa receber o seu input (prompt + contexto) e produzir um output. Essa discrepância é fácil de perceber: basta abrir o OpenRouter para notar que os output tokens do Opus são 5x mais caros que os input tokens. Já no GPT 5.5, esse número é 6x maior.
Por isso é louvável os esforços de se economizar output tokens. Skills como caveman e proxies como RTK prometem justamente isso. Em testes que realizei, pedir para o agente se comunicar como um homem das cavernas, cortando o não-essencial, chegou a reduzir o custo de uma sessão no Claude Code em até 50%. Esse assunto é tão dramático que meu review do caveman se tornou rapidamente um dos meus vídeos mais assistidos no YouTube.
Portanto, é claro que economizar tokens faz parte de um uso “responsável” da IA, principalmente quando assinaturas como ChatGPT Pro e Claude Max entregam muito mais em token do que se fossem consumidas via API (ainda assim, cuidado com o mito de que a IA só funciona porque é subsidiada). Ser um bom “gestor de agentes” também é saber trabalhar com recursos escassos, como output tokens.
E, pelo mesmo princípio que uma linguagem sintética como o chinês simplificado atinge o máximo grau de compressão no caveman, o português pode aumentar o número de output tokens em até 69%.
Estudo sobre o consumo de tokens em português
Para provar a tese de que o consumo de tokens em português é maior que o em inglês, eu desenhei um teste onde um agente de IA recebe um prompt, tanto em português quanto em inglês, e mede o número de output tokens gerados. Aqui as coisas complicam, pois o resultado depende brutalmente de variáveis como modelo, harness, thinking level e tipo de tarefa.
Para tentar fazer uma análise um pouco mais justa, comparei a mediana de output tokens em 8 tarefas diferentes, sendo 5 restritas (constrained) e 3 abertas (open-ended). Tarefas restritas são aquelas cujo output é controlado (como contar o número de r em strawberry), e abertas são as que dão mais liberadade ao modelo (”explique o que é uma linked list“, ou “me diga como funcionam as filas nesse app”). Cada tarefa foi executada 5 vezes para cada combinação de idioma (inglês ou português), modelo, harness e thinking level.
Os harnesses escolhidos foram o Codex (pela praticidade de se executar os testes utilizando o codex exec dentro da própria assinatura do plano Pro), e o Cursor SDK (pela possibilidade de se alternar diversos modelos e por também poder usar com a assinatura do Cursor). Foram testados os modelos GPT 5.5 (tanto no harness do Codex quanto via Cursor SDK), Sonnet 4.6 e Composer 2 (esse último não possui thinking level).
Em todos os casos notou-se um aumento de output tokens nos prompts em português. De forma moderada, a latência também foi maior. No entanto, não observou-se uma perda na qualidade, em que pese a subjetividade de se analisar respostas open-ended.
Um detalhe importante: existem várias formas de se medir a diferença de tokens. Para o estudo, elegi duas métricas principais: blended median output delta e typical task delta. O primeiro mede a diferença de tokens produzidos em português vs inglês (BTBR tokens) considerando a mediana de tokens em cada tarefa. Por exemplo, se na tarefa 1 a mediana de tokens gerados em inglês foi 1000 e em português foi 1500, então o delta foi de 50% (lembre-se que cada tarefa foi executada 5 vezes para cada idioma, daí o uso da mediana). Já o typical task compara a mediana do delta entre os diversos tipos de tarefa. Então se para a tarefa 1 o delta em português foi +50%, na tarefa 2 foi -20% e na tarefa 3 foi +20%, o typical task delta foi de +20%.
A primeira métrica tende a ser mais representativa de um dia normal de um programador, já que o que importa é a quantidade de tokens gastos ao longo de todas as tarefas, que variam de complexidade. Já a segunda métrica pretende normalizar por tarefa, esclarecendo qual seria a diferença do consumo típico considerando diversos tipos de prompts.
Se considerarmos o consumo total – independente das tarefas – observamos alguns fenômenos interessantes. O consumo de output tokens cresce linearmente com o thinking level no harness do Codex, chegando a +40% no xhigh (minha combinação favorita). O comportamento foi inverso no Sonnet dentro do Cursor SDK, que apresentou a maior discrepância de todas no Composer 2, seu modelo proprietário (+69%).
Se considerarmos a tarefa típica, o consumo em português é maior em todos os casos. Embora os números sejam menores, eles se compõe com o tempo: toda tarefa tem um consumo esperado adicional de tokens que flutua entre +10-30%. Curiosamente um thinking level maior tende a reduzir o consumo extra. Essa discrepância frente à métrica anterior indica que o uso do xhigh em português tende a afetar desproporcionalmente o número total de output tokens em tarefas open-ended.
Para uma análise mais aprofundada de cada tarefa e da diferença em output e em latência por harness, modelo e thinking level, considere ler o estudo publicado no GitHub.
Por que isso acontece?
Cabe buscar entender as razões por trás desse fenômeno. Embora seja difícil precisar com certeza, além do óbvio fato de que os modelos são treinados num corpo maior de documentos em inglês, a principal razão é a tokenização.
Tokenizar é o processo de transformar o input em tokens (as “sílabas” que a IA “entende”). Existem diversos algoritmos de tokenização, e em todos os meus testes, independente do algoritmo, produziu-se mais tokens nos prompts em português.
É importante que se diga que o algoritmo utilizado por cada modelo varia e pode ser proprietário, de modo que não é possível cravar nada. Direcionalmente, no entanto, fica claro que a token inflation é real.
Recomendações práticas
Se é verdade que enviar prompts em português consome mais output tokens, que são entre 5-6x mais caros que input tokens, que lições podemos tirar desse estudo?
Em primeiro lugar, o argumento de que a IA entende português tanto quanto inglês é razoável: não houve nenhuma degradação de qualidade nos testes. Portanto, se a sua preocupação é comunicar-se com precisão, fique tranquilo.
Se a sua preocupação é com a latência, ou o tempo de resposta, a diferença é pouco notável. Ainda assim, ela fica na casa dos 5-15% e pode impactar num cenário de uso programático, como uma API, por exemplo.
Por fim, é inegável que há um aumento de tokens ao se comunicar em português, embora o quanto varie largamente com o harness, modelo, thinking level e tipo de tarefa. No geral, o Codex apresentou uma certa estabilidade, principalmente quando o reasoning é menor. À medida que se aumenta o reasoning, o impacto é desproporcional nas tarefas que são mais verborrágicas por natureza. Para aqueles que programam no Cursor, o uso do Composer 2, embora um dos melhores custo-benefício da assinatura, apresentou a maior diferença de consumo.
Meu objetivo nesse artigo não é convencê-lo a escrever em inglês – escreva na forma que lhe for mais conveniente. No entanto, pode-se fazer o argumento objetivo que será observado um consumo 10-35% maior de output tokens numa tarefa típica, ou até 69% maior se considerarmos um uso contínuo (onde tarefas mais open-ended distorcem o montante).
De minha parte, continuo acreditando que os argumentos subjetivos são ainda mais importantes. É escusado não se saber inglês e programar, mas deliberadamente omitir-se de aprender me parece um erro estratégico de carreira. Espero que o argumento dos tokens, somados aos limites inconstantes e nebulosos dos provedores de IA, seja o impulso que faltava para que você torne-se partícipe da lingua franca.
É bom que se diga que já condensei esses argumentos no terrível formato hot-take que infelizmente se popularizou no Twitter.