Inglês agora é minha linguagem de programação principal

No ano passado comecei a registrar para onde vai de fato o meu tempo de desenvolvimento. A resposta foi desconfortável: escrevo mais inglês do que código. Não documentação — especificações, critérios de aceitação, molduras de contexto para modelos de IA, prompts de verificação, notas de iteração. A proporção gira em torno de 80/20 a favor da prosa.

Essa mudança não aconteceu da noite para o dia, e não é exclusiva minha. Andrej Karpathy deu nome a isso em 2023. Jensen Huang repetiu uma versão em todas as keynotes importantes desde então. Simon Willison vem documentando isso em fluxos de trabalho reais há dois anos. Mas no início de 2026, com Claude Code, Cursor, Aider e Kiro rodando em pipelines de produção em milhares de equipes, isso não é mais uma previsão provocadora — é um fato observável para qualquer pessoa atenta.

Eis como a transição aconteceu na prática. Comecei com o que a comunidade chama de vibe coding — uma descrição generosa para «diga ao modelo o que você quer e veja o que sai». Funcionava razoavelmente bem para protótipos. Desmoronava no momento em que eu precisava de manutenibilidade. Regressões apareciam em lugares que eu não havia tocado. A deriva de contexto transformava uma base de código limpa numa colcha de retalhos. O modelo não estava falhando; eu estava. Eu fornecia entrada ambígua e esperava saída precisa.

A correção foi uma mudança de metodologia, não uma atualização de modelo. Spec-Driven Development significa escrever uma especificação estruturada antes de qualquer código ser gerado. Requisitos concretos. Casos extremos nomeados explicitamente. Critérios de aceitação que servem como prompts de teste. Quando ajustei o inglês, a qualidade do código disparou. O consumo de tokens caiu porque o modelo parou de alucinar intenções. A especificação tornou-se a fonte da verdade, e eu me tornei seu autor.

O inglês não substituiu Python ou TypeScript. Tornou-se a interface para eles. O modelo mental que funciona: você está escrevendo entrada para um compilador — só que o compilador é um modelo de linguagem grande, e suas mensagens de erro voltam como funções alucinadas e escopo à deriva. Precisão na especificação reduz o ruído rio abaixo. Isso não é uma metáfora. É um fluxo de trabalho em produção.

A implicação desconfortável é geográfica e linguística. Falantes nativos de inglês — e mais especificamente, pessoas que escrevem com clareza estrutural em inglês — têm uma vantagem mensurável. Não porque os modelos sejam tendenciosos, mas porque ambiguidade na entrada produz ambiguidade na saída. Um desenvolvedor escrevendo especificações em seu terceiro idioma, lutando pela precisão palavra por palavra, gasta mais iterações na mesma tarefa. As ferramentas democratizam o acesso à criação de software; o requisito do idioma silenciosamente recria uma barreira diferente.

Há uma segunda tensão que merece ser nomeada. As habilidades que tornavam alguém um bom desenvolvedor em 2019 — fluência sintática, memorização de APIs, depuração de baixo nível — não são as habilidades que tornam alguém eficaz neste modelo. O novo perfil parece mais um redator técnico cruzado com um arquiteto de sistemas: alguém capaz de decompor um problema, especificar suas restrições e verificar a saída criticamente. A maioria dos processos de contratação ainda não testa isso.

Minha leitura: os engenheiros que prosperarão nos próximos cinco anos não serão os que codificam mais rápido. Serão os que especificam com mais clareza. A capacidade de redigir uma descrição rigorosa e inequívoca de um sistema — suas entradas, saídas, modos de falha e restrições — é agora uma competência técnica central. Tratá-la como habilidade interpessoal é como equipes acabam com código gerado por IA que ninguém entende completamente e ninguém quer manter.

Qual porcentagem do seu dia de trabalho é inglês agora?