Autor do Habr parodia Oneguin: quem responde pelos erros do agente é o humano

Quatro versos de paródia da «Carta de Tatiana a Oneguin» e uma declaração sobre o método. É assim que começa o artigo autoral do Habr «Poesia do desenvolvimento com agentes, ou como escrever código agora». O autor se recusa a oferecer mais um conjunto de receitas e propõe subir um nível de abstração: entender a problemática, os valores e os sentidos, deixando os detalhes para depois. O anúncio disponível contém apenas a introdução, por isso analisamos o enquadramento declarado, não a argumentação.

O que exatamente foi declarado

No poema, a engenheira Tatiana escreve ao vibe coder Eugênio. O agente, diz ela, pode escrever tudo. Mas, queira ou não, quem terá de responder pelos erros é o próprio Eugênio. A piada funciona porque descreve uma assimetria real. Gerar código ficou quase de graça, mas a responsabilidade por ele continua a mesma e segue recaindo sobre o humano.

Parâmetros do material:

• Formato: artigo autoral, seção AI do Habr
• Data de publicação: 10 de outubro de 2026
• Imagem central: a engenheira Tatiana e o vibe coder Eugênio
• Tese principal: a responsabilidade pelo resultado não passa ao agente
• Método: primeiro a problemática, os valores e os sentidos; depois os detalhes
• O que não há no anúncio: ferramentas, medições, práticas concretas

Por que a tese toca num ponto sensível

O termo «vibe coding» foi proposto por Andrej Karpathy no início de 2025. Ele descrevia um estilo em que o desenvolvedor aceita as mudanças do agente sem ler o que mudou. Para um protótipo ou um projeto de domingo, tudo bem. Em produção, essa abordagem significa que o código entra no sistema sem que ninguém o entenda.

O agente escreve mais rápido do que um humano lê. Por isso, o gargalo sai da escrita e vai para a revisão. Essa é uma lógica comum no setor, não uma conclusão do autor do artigo, mas a piada de Tatiana e Eugênio a resume bem: quem aceitou o diff é quem responde por ele no incidente.

Pontos fortes e fracos do enquadramento escolhido

Subir o nível de abstração é uma jogada sensata. Receitas para agentes envelhecem em meses: mudam os modelos, as interfaces e os limites de contexto. Perguntas como quem é o dono do resultado, o que conta como código pronto e que risco é aceitável duram bem mais.

Há também um risco. Um texto sobre sentidos vira facilmente um ensaio do qual não se tira nenhuma ação. Só a versão completa permite julgar se o autor evitou essa armadilha. O anúncio não traz exemplos nem comparações entre abordagens.

O que uma equipe pode fazer com isso

Não são conselhos do autor, e sim conclusões nossas a partir da tese declarada. Dá para aplicá-las já:

• Atribua um responsável a cada mudança feita por um agente. Uma pessoa concreta, não «a equipe».
• Adote a regra: não faço merge do que não consigo explicar com minhas próprias palavras.
• Escreva testes e critérios de aceitação antes de acionar o agente. Assim, a verificação se apoia numa especificação, e não na sensação de que o código parece plausível.
• Guarde a tarefa e os prompts principais junto ao commit. Seis meses depois, isso ajuda a entender por que o código ficou do jeito que ficou.
• Separe os modos de trabalho. Protótipo pode ser feito «no vibe»; código de produção precisa de revisão.

Vale ler o texto completo no Habr para ver no que o autor transforma os valores e os sentidos. Se houver práticas concretas por trás deles, o resultado será um material útil. Se não houver, restará uma paródia bonita com uma observação correta.