Dilema do desenvolvimento com IA: aceleradores versus vibecoders

A pergunta que carrega uma tese

O autor parte de uma pergunta comum na era da IA: "você ainda lê o código?". Ele observa que o "ainda" pressupõe uma teoria de progresso - a de que ler código é uma prática em extinção, como decorar números de telefone. Para ele, essa certeza é prematura: produzir uma aplicação funcional ficou mais fácil, mas os custos de manutenção ao longo de mudanças de requisitos, desenvolvedores e ferramentas só aparecem depois. As equipes estão fazendo apostas cujas consequências ainda serão sentidas.

Dois modos de programar com IA

O texto distingue dois perfis. Aceleradores usam IA para traduzir seu entendimento em código, mas mantêm o compromisso de compreender a implementação, explicar as escolhas, antecipar consequências de mudanças e sustentar o modelo mental do sistema. Ler o código gerado faz parte desse compromisso. Nesse caminho, a "dívida cognitiva" (conceito citado de Storey, 2026) se acumula quando a leitura da equipe fica atrás da geração.

Vibecoders, por outro lado, delegam a implementação e sua revisão contínua à IA, tratando o modelo como algo equivalente a compiladores e frameworks - algo cujos detalhes técnicos não precisam ser conhecidos. Eles investem em especificar, regerar e avaliar o resultado, e correm o risco de acumular "dívida de intenção": requisitos reescritos ou esquecidos, contexto que deriva entre sessões e dependência da qualidade de modelos controlados por Anthropic ou OpenAI.

A distinção não é sobre quanto código o modelo escreve, mas sobre a relação do desenvolvedor com o resultado. Um acelerador pode gerar quase toda uma feature e ainda entender o que foi construído; um vibecoder pode gastar muito tempo refinando especificações e critérios de aceitação, tratando a implementação como descartável. O autor menciona ainda um terceiro grupo que rejeita IA por motivos legais ou éticos, mas diz não conhecer nenhuma organização comercial que evite IA por razões puramente de engenharia.

Naur e a teoria como produto real

O argumento central do autor se apoia no ensaio de Peter Naur de 1985, "Programming as Theory Building", que voltou à tona com os LLMs. Para Naur, o código não é o verdadeiro produto da programação - o ativo é a teoria, o conhecimento que permite explicar, responder perguntas, projetar o futuro e adaptar o sistema. O código, muitas vezes, é um passivo tratado equivocadamente como ativo, apenas por ser mais visível.

Daí a dúvida do autor sobre a aposta vibecoder: ela assume que a teoria pode ser construída especificando e rodando software, sem lidar com a implementação. Mas, para ele, a implementação é justamente um dos lugares onde a especificação é revisada - o entendimento conceitual nem sempre sobrevive ao primeiro contato com o código. Um conjunto de testes verde só prova que o programa faz o que você disse, não que o que você disse corresponde à realidade.

Escolha e deriva

O autor rejeita a ideia de um espectro entre os dois modos. Pode-se ser acelerador em um módulo e vibecoder em outro, mas não "no meio" de nenhum dos dois. Quem deriva - começa a folhear diffs em vez de lê-los - acaba vibecoder por padrão, mas sem as estruturas de especificação e avaliação que um vibecoder deliberado construiria.

O problema da convivência forçada

A prática claramente prejudicial, segundo o texto, é colocar pessoas de abordagens opostas na mesma equipe sem estabelecer expectativas prévias. O acelerador pode herdar o trabalho de reconstruir um entendimento que o autor nunca pretendia reter; o vibecoder pode ser cobrado a explicar escolhas que tratou como descartáveis. Cortesia vira questão de engenharia: antes de fazer merge, os colegas precisam saber como as mudanças devem ser mantidas.

Limites e ferramentas

O autor admite que os vibecoders podem estar certos e que olhar código pode se tornar obsoleto - ele simplesmente não vê evidência suficiente. Também reconhece que a posição do acelerador é desconfortável: habilidades se deterioram sem uso, e revisar código gerado sem digitá-lo pode não bastar para retomar a escrita manual se necessário. Ele cita o clássico "Ironias of Automation" de Bainbridge (1983): o trabalho de autorrevisar saída delegada é o pior tipo - muito chato e muito responsável, sem oportunidade de manter as qualidades exigidas para essa responsabilidade.

Sobre a dívida de intenção, o autor sugere que agentes podem ajudar ao resumir e rastrear de onde veio cada decisão, e cita ferramentas como Crit, CodeRabbit Change Stack e seu próprio intent-stack. Ele menciona também experimentos de "fábricas de software", como a da StrongDM, que roda sob duas regras: humanos não escrevem e não revisam código - validam o trabalho dos agentes contra cenários mantidos fora do repositório.

Conclusão

Existem dois tipos de progresso na programação assistida por IA: um que ajuda a entender a implementação e outro que busca eliminar essa necessidade. São caminhos distintos, que exigem ferramentas diferentes - e parar de ler código não é, em si, progresso. A frase final inverte a pergunta do título: antes de perguntar se o colega ainda lê código, considere se você ainda espera que ele mantenha o seu.

{"resumo":"## A pergunta que carrega uma tese\n\nO autor parte da pergunta comum na era da IA: "você ainda lê o código?". O "ainda" pressupõe uma teoria de progresso - a de que ler código é uma prática em extinção. Para ele, essa certeza é prematura: produzir uma aplicação funcional ficou mais fácil, mas os custos de manutenção ao longo de mudanças de requisitos, desenvolvedores e ferramentas só aparecem depois. As equipes estão fazendo apostas cujas consequências ainda serão sentidas.\n\n## Dois modos de programar com IA\n\nO texto distingue dois perfis. Aceleradores usam IA para traduzir seu entendimento em código, mas mantêm o compromisso de compreender a implementação, explicar as escolhas e sustentar o modelo mental do sistema - ler o código gerado faz parte disso. Nesse caminho, a "dívida cognitiva" (conceito citado de Storey, 2026) se acumula quando a leitura da equipe fica atrás da geração.\n\nVibecoders delegam a implementação e sua revisão contínua à IA, tratando modelos como equivalentes a compiladores e frameworks, cujos detalhes técnicos não precisam ser conhecidos. Eles investem em especificar, regerar e avaliar o resultado, e correm o risco de acumular "dívida de intenção": requisitos reescritos ou esquecidos, contexto que deriva entre sessões e dependência da qualidade de modelos controlados por Anthropic ou OpenAI.\n\nA distinção não é sobre quanto código o modelo escreve, mas sobre a relação do desenvolvedor com o resultado. Um acelerador pode gerar quase toda uma feature e ainda entender o que foi construído; um vibecoder pode refinar especificações e critérios de aceitação tratando a implementação como descartável. O autor menciona um terceiro grupo que rejeita IA por motivos legais ou éticos, mas diz não conhecer nenhuma organização comercial que evite IA por razões puramente de engenharia.\n\n## Naur e a teoria como produto real\n\nO argumento central se apoia no ensaio de Peter Naur de 1985, "Programming as Theory Building", que voltou à tona com os LLMs. Para Naur, o código não é o verdadeiro produto da programação - o ativo é a teoria, o conhecimento que permite explicar, responder perguntas, projetar o futuro e adaptar o sistema. O código, muitas vezes, é um passivo tratado como ativo apenas por ser visível.\n\nDaí a dúvida do autor sobre a aposta vibecoder: ela assume que a teoria pode ser construída especificando e rodando software, sem lidar com a implementação. Mas, para ele, a implementação é justamente um dos lugares onde a especificação é revisada - o entendimento conceitual nem sempre sobrevive ao contato com o código. Um conjunto de testes verde só prova que o programa faz o que foi dito, não que o que foi dito corresponde à realidade.\n\n## Escolha e deriva\n\nO autor rejeita a ideia de um espectro entre os dois modos. Pode-se ser acelerador em um módulo e vibecoder em outro, mas não "no meio" de nenhum dos dois. Quem deriva - começa a folhear diffs em vez de lê-los - acaba vibecoder por padrão, mas sem as estruturas de especificação e avaliação que um vibecoder deliberado construiria. Ler cada linha do código gerado é, no trabalho comercial dele, uma forma de evitar essa deriva, embora agentes ainda façam escolhas questionáveis, como ignorar o tempo de execução dos testes ou violar regras de hooks do React com contexto poluído.\n\n## O problema da convivência forçada\n\nA prática claramente prejudicial, segundo o texto, é colocar pessoas de abordagens opostas na mesma equipe sem estabelecer expectativas prévias. O acelerador pode herdar o trabalho de reconstruir um entendimento que o autor nunca pretendia reter; o vibecoder pode ser cobrado a explicar escolhas que tratou como descartáveis. Antes de fazer merge, os colegas precisam saber como as mudanças devem ser mantidas: pelo entendimento do desenvolvedor, por especificação e processo rigoroso de geração, ou por combinação explícita das duas formas.\n\n## Limites e ferramentas\n\nO autor admite que os vibecoders podem estar certos e olhar código pode se tornar obsoleto - ele apenas não vê evidência suficiente. Também reconhece que a posição do acelerador é desconfortável: habilidades se deterioram sem uso, e revisar código gerado sem digitá-lo pode não bastar para retomar a escrita manual se necessário. Ele cita o clássico "Ironies of Automation", de Bainbridge (1983): autorrevisar saída delegada é o pior tipo de trabalho - muito chato e muito responsável, sem oportunidade de manter as qualidades exigidas para essa responsabilidade.\n\nSobre a dívida de intenção, agentes podem ajudar ao resumir e rastrear de onde veio cada decisão - um valor como expiryTime = 6h no código não preserva se veio de requisito de negócio, convenção, trade-off ou chute não contestado. O autor cita ferramentas como Crit, CodeRabbit Change Stack e seu próprio intent-stack, além de experimentos de "fábricas de software", como a da StrongDM, que roda sob duas regras: humanos não escrevem e não revisam código - validam o trabalho dos agentes contra cenários mantidos fora do repositório.\n\n## Conclusão\n\nExistem dois tipos de progresso na programação assistida por IA: um que ajuda a entender a implementação e outro que busca eliminar essa necessidade. São caminhos distintos, que exigem ferramentas e abordagens diferentes - e parar de ler código não é, em si, progresso. A frase final inverte a pergunta do título: antes de perguntar se o colega ainda lê código, considere se você ainda espera que ele mantenha o seu.","hook":"Programar com IA se dividiu em duas práticas: quem usa o modelo como acelerador e mantém o compromisso de ler todo o código gerado, e quem delega a implementação e investe em especificações e critérios de aceitação. Um ensaio de 1985 de Peter Naur, redescoberto com os LLMs, sustenta o argumento de que o código nunca foi o verdadeiro produto da programação - a teoria por trás dele é. O autor questiona o que acontece quando os dois estilos se encontram na mesma equipe sem regras combinadas.","entities":["Anthropic","OpenAI","Peter Naur","StrongDM"],"themes":["engenharia-com-ia","trabalho-e-carreiras"],"story_key":"aceleradores-vs-vibecoders","reasoning":{"story_key":"Tese central do artigo: distinção entre aceleradores e vibecoders e o dilema de ler ou não o código gerado.","themes":{"engenharia-com-ia":"O assunto é a prática de programação assistida por IA, fluxo de geração, revisão e fábricas de software.","trabalho-e-carreiras":"Tese de ofício: quais compromissos de entendimento e manutenção o engenheiro assume com IA, deterioração de habilidades e convivência em equipes."},"entities":{"Anthropic":"Citada como controladora dos modelos de que os vibecoders dependem.","OpenAI":"Citada junto a Anthropic como fornecedora dos modelos que sustentam a delegação.","Peter Naur":"Autor do ensaio 'Programming as Theory Building', base conceitual do argumento.","StrongDM":"Sua fábrica de software é o exemplo central de delegação radical."},"excluded":{"Claude Code":"Menção incidental como marco temporal, não sujeito do fato.","Marek Chotoborski":"Autor do texto, excluído por regra.","Storey","Bainbridge","Horthy","Willison":"Autores citados como referências, não sujeitos do fato.","Crit","CodeRabbit":"Ferramentas mencionadas como exemplos, menções secundárias."}}}