Por que o inglês não pode estar errado

Em janeiro de 2023, Andrej Karpathy postou uma frase que foi citada até a exaustão: "A linguagem de programação mais quente do momento é o inglês."

Era uma boa frase porque era majoritariamente verdadeira, e era majoritariamente verdadeira de um jeito que levou dois anos para se tornar desconfortável. Em fevereiro de 2025, o próprio Karpathy nomeou a consequência. Ele chamou isso de vibe coding: "Há um novo tipo de programação que chamo de 'vibe coding', em que você se entrega totalmente às vibrações, abraça os exponenciais e esquece que o código sequer existe." O detalhe operacional era a parte que valia a pena ler duas vezes: "Eu sempre clico em 'Aceitar tudo', não leio mais os diffs."

O Merriam-Webster incorporou o termo em março de 2025 como gíria e expressão em alta. O Collins English Dictionary o nomeou Palavra do Ano de 2025.

Pare para pensar nisso. Um dicionário, uma instituição cuja função inteira é fixar significados com firmeza suficiente para que um uso possa ser verificado contra eles, deu sua maior honraria anual a uma prática definida pelo não verificar o resultado. Isso não é uma piada interna de tecnologia que escapou do contexto. É uma admissão em nível cultural sobre para onde o trabalho se deslocou.

A pergunta interessante não é se o vibe coding é bom ou ruim. É o que os dois anos entre essas duas citações revelam sobre o inglês. O inglês foi promovido a linguagem de instrução, e a primeira coisa que fez no cargo foi parar de verificar seu próprio trabalho. Isso não é uma falha de disciplina das pessoas que o usam. É uma propriedade da própria linguagem.

O defeito é a virtude

O inglês não pode estar errado.

Não "raramente está errado." Não pode. Não existe operação que você possa rodar sobre uma frase em inglês que retorne falso. Você pode discordar de uma frase, interpretá-la mal, achá-la inútil, ou descobrir depois que o mundo não correspondeu a ela. Mas a frase em si nunca falha. Ela sempre é interpretável. Não tem mecanismo para se rejeitar.

Considere três instruções, cada uma soando completa.

"Deixa mais rápido." Rápido em que sentido? Latência (o tempo que uma requisição leva)? Throughput (o número de requisições atendidas por segundo)? Velocidade percebida (o tempo até algo aparecer, que é uma coisa diferente de novo)? Custo por unidade de trabalho? Não são nuances de uma ideia. Elas competem entre si. Otimizar para throughput rotineiramente piora a latência. Uma resposta a "deixa mais rápido" pode ser um sucesso técnico e um fracasso completo da instrução.

"Repita requisições que falharam." Isso soa como uma regra. É uma pergunta vestida de regra. O que é uma requisição que falhou? Uma requisição que foi rejeitada, ou uma requisição cuja resposta nunca voltou? São eventos diferentes com a mesma aparência de fora. Se a requisição original teve sucesso e apenas a confirmação se perdeu, a repetição faz o trabalho uma segunda vez. Cobra o cartão duas vezes. Envia o pedido duas vezes. A frase é silenciosa sobre a única coisa que importa, e é silenciosa soando definitiva.

"Só administradores podem excluir contas." Quem conta como administrador, o cargo, ou qualquer um que atualmente possa assumir o cargo? A autoridade se delega, e se sim, o delegado é administrador para os fins dessa frase? O que acontece com uma sessão já aberta quando as permissões de alguém são revogadas em pleno funcionamento? Cada uma dessas é uma decisão que a frase parece ter tomado e não tomou.

Nenhuma dessas é uma frase descuidada. São frases comuns. A linguagem natural é construída para funcionar assim. Ambiguidade é compressão, quem fala omite o que quem ouve consegue reconstruir, e a reconstrução costuma estar certa. O contexto faz o resto do trabalho. A contradição é tolerada porque um ouvinte competente a repara silenciosamente e segue em frente, e ambas as partes vivenciam isso como compreensão, não como adivinhação.

Essas são propriedades extraordinárias na conversa. São defeitos na instrução. O trabalho de uma instrução é eliminar futuros. Uma frase que permite quatro resultados incompatíveis não instruiu nada. Ela apontou para uma região e deixou o leitor escolher um ponto dentro dela.

Isso não se limita a software. "A demanda estará forte no próximo trimestre" é uma previsão que não pode estar errada, porque "forte" não tem limiar, o que é exatamente o que a faz sobreviver ao trimestre que descreve. "Aprove descontos caso a caso" é uma política que não pode ser violada. "Vamos priorizar o trabalho de maior impacto" é um plano compatível com qualquer alocação possível de esforço. Todas essas frases passam na reunião. Nenhuma delas pode falhar, e é isso que as torna inúteis como restrições e populares como linguagem.

O que um sistema formal realmente compra

Um sistema formal começa exatamente onde essa tolerância termina.

Uma função está com o tipo correto ou não está. Uma transação satisfaz suas restrições ou o banco de dados recusa a escrita. Um esquema valida o registro ou o rejeita. Um plano de produção é viável dentro da capacidade ou não é viável, e o solver vai te dizer qual dos dois. Um teste passa ou falha.

A história convencional sobre sistemas formais é que eles são precisos. É verdade, e não é o ponto. Precisão é o mecanismo. O produto é a recusa.

Essa é a propriedade que o inglês não tem e não pode receber. Um sistema de tipos não é valioso porque descreve sua intenção com elegância. É valioso porque existem programas que ele não vai aceitar. Tire a capacidade de rejeitar e você não enfraqueceu o sistema, você o apagou. Um sistema de tipos que aceita tudo é um comentário. Uma restrição de capacidade que nunca se ativa é uma nota de rodapé. Um teste que não pode falhar é decoração.

A economia se inverteu, e ninguém se mexeu

Durante a maior parte da história do trabalho de conhecimento, o artefato era a parte cara. Escrever o código, construir o modelo, redigir o documento, produzir o plano, era aí que as horas iam. Verificar era comparativamente barato, e majoritariamente implícito: produzir a coisa te obrigava a pensá-la até o fim. A lentidão era um trabalho de verificação feito nas entrelinhas. Você não conseguia escrever o parágrafo sem ter decidido o que queria dizer.

Esse vínculo acabou. A geração agora é quase gratuita, e o artefato chega em segundos.

A verificação não ficou mais barata. É a única parte do processo cujo custo permaneceu igual, então, à medida que tudo ao redor despencava de preço, sua fatia do total foi para quase tudo. O que é escasso não é mais a capacidade de produzir o artefato. É a existência de algo disposto e capaz de dizer não a ele.

E aqui as duas propriedades colidem. Uma instrução que não pode estar errada não pode ser verificada. Uma instrução que não pode ser verificada não pode ser confiável em volume.

Volume é a palavra que faz o trabalho. Um rascunho gerado está tudo bem; uma pessoa o lê, e o julgamento dela é a verificação. Mil rascunhos gerados não podem ser lidos, e a verificação humana silenciosamente para de acontecer, não por decisão, mas por aritmética. Esse é o conteúdo honesto de "não leio mais os diffs." Não é preguiça. É o que acontece com qualquer etapa manual de verificação quando a coisa sendo verificada começa a chegar mais rápido do que uma pessoa consegue absorver. A verificação não é anulada. É ultrapassada.

A complicação, dita com honestidade

A leitura óbvia de tudo isso é "seja preciso, sempre, desde o início." Essa leitura está errada, e está errada de um jeito caro.

A ambiguidade é genuinamente útil no início. Intenção vaga é como o trabalho começa. "Tem algo errado com como os clientes renovam" não é uma especificação e não poderia ser uma, ninguém sabe o suficiente ainda para escrevê-la. A vagueza dessa frase é o que permite que quatro pessoas com expertises diferentes fiquem diante dela e cada uma enxergue um problema tratável diferente. A precisão prematura mata isso. Uma especificação escrita antes de alguém entender a coisa não captura o problema; ela o encerra. Formalizar cedo demais converte uma pergunta aberta em uma resposta errada com boa postura.

Então a afirmação não é que a formalidade deva vir primeiro. É que a coisa vaga precisa, eventualmente, pousar em algum lugar capaz de rejeitá-la. Exploração é uma fase, não um destino. A frase pode continuar mole enquanto ainda está encontrando sua forma, e então ela precisa encontrar algo com poder de recusá-la, um esquema, um tipo, uma restrição, uma checagem de viabilidade, um teste, um número com um limiar atrelado.

O modo de falha deste momento em particular é que as pessoas pulam esse pouso, porque o resultado já parece pronto. Fluência costumava ser uma evidência fraca de cuidado. Custava algo produzir um artefato limpo, confiante e bem estruturado, e esse custo era majoritariamente pensamento. Agora não custa nada. Os sinais de superfície que um leitor passou décadas aprendendo a ler como competência foram completamente desacoplados da competência, e o reconhecimento de padrões humano ainda não alcançou isso.

Para onde foi a alavancagem

Se a geração é gratuita e a recusa é escassa, então a alavancagem fica com quem quer que segure as restrições.

Não com o prompt. O prompt é inglês; ele vai aceitar qualquer coisa. Não com o modelo, cuja fluência é precisamente a razão pela qual seu resultado escapa da verificação. A alavancagem está no esquema que rejeita o registro malformado, no tipo que não vai compilar, na restrição que o solver não consegue satisfazer e diz isso, no teste que falha, no limiar de aceitação definido antes do resultado chegar, e não depois.

Esse trabalho não é glamoroso e é para onde o valor se moveu. Qualquer um agora pode produzir um plano. A habilidade escassa é declarar de antemão o que o tornaria inviável. Qualquer um pode produzir uma previsão. A habilidade escassa é nomear o número que a torna errada, antes que seja conveniente sabê-lo. Qualquer um pode gerar o código. A habilidade escassa é construir a coisa que não vai aceitá-lo.

A frase de Karpathy em 2023 estava certa. O inglês é a linguagem de programação mais quente do momento, e 2025 canonizou o que isso custa. O inglês vai aceitar qualquer coisa que você disser a ele. O modelo também. Em algum ponto adiante na cadeia, algo precisa ser capaz de dizer não, e se nada na cadeia conseguir, então nada foi verificado. Foi apenas produzido.

---

Sources

• Karpathy, A. (2023). "The hottest new programming language is English." X/Twitter, 24 January 2023.
• Karpathy, A. (2025). Post coining "vibe coding." X/Twitter, February 2025.
• Merriam-Webster. (2025). "Vibe coding," Slang & Trending listing. March 2025. merriam-webster.com
• Collins English Dictionary. (2025). Word of the Year 2025: "vibe coding." Announced 6 November 2025. collinsdictionary.com
• BBC News. (2025). "Vibe coding" named word of the year by Collins Dictionary. 6 November 2025. bbc.com
• The Independent. (2025). What does vibe coding mean? The AI term crowned Collins word of the year. 6 November 2025. independent.co.uk