O inglês é agora a minha principal linguagem de programação

No ano passado, comecei a registar para onde vai de facto o meu tempo de desenvolvimento. A resposta foi desconfortável: escrevo mais inglês do que código. Não se trata de documentação, mas de especificações, critérios de aceitação, enquadramentos de contexto para modelos de IA, prompts de verificação, notas de iteração. A proporção ronda os 80/20 a favor da prosa.

Esta mudança não aconteceu de um dia para o outro, nem é exclusiva minha. Andrej Karpathy deu-lhe nome em 2023. Jensen Huang repetiu uma versão da ideia em todas as suas grandes intervenções desde então. Simon Willison tem-na documentado em fluxos de trabalho reais há dois anos. Mas no início de 2026, com Claude Code, Cursor, Aider e Kiro em uso em pipelines de produção em milhares de equipas, já não é uma previsão provocadora — é um facto observável para qualquer pessoa atenta.

Eis como a transição aconteceu na prática. Comecei pelo que a comunidade chama vibe coding — uma descrição generosa para “diga ao modelo o que quer e veja o que sai”. Funcionava razoavelmente bem para protótipos. Desmoronava-se no momento em que eu precisava de manutenibilidade. Surgiam regressões em sítios em que eu não tinha tocado. A deriva de contexto transformava uma base de código limpa numa manta de retalhos. Não era o modelo que falhava; era eu. Dava instruções ambíguas e esperava resultados precisos.

A soluçã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 se gerar qualquer código. Requisitos concretos. Casos-limite explicitamente identificados. Critérios de aceitação que servem de prompts de teste. Quando tornei o meu inglês mais preciso, a qualidade do código disparou. O consumo de tokens caiu porque o modelo deixou de alucinar intenções. A especificação tornou-se a fonte de verdade, e eu tornei-me o seu autor.

O inglês não substituiu o Python nem o TypeScript. Tornou-se a interface para eles. O modelo mental que funciona: está a escrever a entrada de um compilador — só que o compilador é um grande modelo de linguagem, e as suas mensagens de erro chegam sob a forma de funções alucinadas e de âmbito à deriva. A precisão da especificação reduz o ruído nas etapas seguintes. Não é uma metáfora. É um fluxo de trabalho em produção.

A implicação desconfortável é geográfica e linguística. Os falantes nativos de inglês — e, mais concretamente, as pessoas que escrevem em inglês com clareza estrutural — têm uma vantagem mensurável. Não porque os modelos sejam enviesados, mas porque a ambiguidade na entrada produz ambiguidade na saída. Um programador que escreve especificações na sua terceira língua, e luta pela precisão palavra a palavra, gasta mais iterações na mesma tarefa. As ferramentas democratizam o acesso à criação de software; a exigência linguística recria discretamente uma barreira diferente.

Há uma segunda tensão que merece ser identificada. As competências que faziam de alguém um bom programador em 2019 — fluência sintática, memorização de APIs, depuração de baixo nível — não são as que tornam alguém eficaz neste modelo. O novo perfil assemelha-se mais a uma combinação de redator técnico e arquiteto de sistemas: alguém capaz de decompor um problema, especificar as suas restrições e verificar criticamente o resultado. A maioria dos processos de recrutamento ainda não avalia isto.

A minha leitura: os engenheiros que vão prosperar nos próximos cinco anos não serão os que programam mais depressa. Serão os que especificam com mais clareza. A capacidade de redigir uma descrição rigorosa e inequívoca de um sistema — as suas entradas, saídas, modos de falha e restrições — é hoje uma competência técnica central. Tratá-la como uma competência comportamental é o caminho para que as equipas acabem com código gerado por IA que ninguém compreende totalmente e que ninguém quer manter.

Que parte do seu dia de trabalho é hoje dedicada ao inglês?