- Um desenvolvedor com 40 anos de experiência realizou um projeto de duas semanas com um assistente de programação com IA e registrou a experiência real de vibe coding
- No processo de implementar um solver do quebra-cabeça Tower of Hanoi, por meio de cerca de 300 interações, a IA gerou todo o código enquanto o humano se concentrou em revisar e dar direcionamento
- O resultado reuniu vantagens como produtividade rápida (até 2x) e precisão surpreendente com provas criativas, mas também desvantagens como 20% de erros ou código incompleto e complexidade excessiva para uso industrial
- O autor avalia que a conversa com a IA proporciona imersão (flow) e efeito de aprendizado, ao mesmo tempo em que gera uma experiência psicológica marcada pela tensão entre confiança e controle
- Em conclusão, a programação com IA é comparada a um companheiro poderoso e uma bicicleta perigosa, sendo apresentada como um novo paradigma de colaboração que precisa ser conduzido ativamente por desenvolvedores experientes
Introdução — Vibe coding
- Vibe coding é uma forma de desenvolvimento em que agentes de IA baseados em LLM ficam responsáveis por escrever, refatorar e depurar, enquanto eu me concentro em o que criar
- A programação acontece em um modelo de colaboração simultânea entre mim e a IA, ou então é inteiramente delegada à IA
- Eu percebo essa abordagem como uma mudança em que interesse e medo coexistem, e questiono se a arte da programação está sendo transformada em uma linha de montagem de robôs inteligentes
- Para validar isso, dediquei 2 semanas e um total de 40 horas para colaborar com assistentes de programação de última geração em um pequeno projeto
- O projeto foi um experimento autodirigido de escala aproximada de 5 mil LOC em Python, 50 arquivos e 20 classes, resolvendo um quebra-cabeça típico com algoritmos clássicos de busca em IA
- O resultado foi publicado na forma de repositório de código e documentação, e o texto é um registro de o que foi feito, entendido, aprendido e sentido
- Comecei nos anos 80 com assembly em máquinas de 8 bits e tenho 40 anos de experiência programando
- Já usei mais de 20 linguagens
- Tenho experiência desenvolvendo software científico, mobile e corporativo, tanto individualmente quanto em equipe
- Também possuo doutorado em IA (da era anterior aos LLMs)
- Achei que haveria algo interessante em uma situação meio câmara de eco, como “uma pessoa de IA criando código de IA com um assistente de IA”
1. Visão geral do software e processo de desenvolvimento
- Implementei em Python um solver flexível e educativo capaz de resolver o quebra-cabeça Tower of Hanoi
- Esse quebra-cabeça é um problema matemático em que discos são movidos entre hastes segundo regras específicas; à medida que o número de discos aumenta, o tamanho da solução cresce explosivamente, tornando-se difícil de imaginar para humanos, mas algoritmos de busca conseguem resolvê-lo com facilidade
- O solver lida não apenas com a versão clássica, mas também com (a) estados iniciais e finais arbitrários e (b) uma versão generalizada em que vários discos podem ser movidos ao mesmo tempo
- As técnicas de busca implementadas incluem estratégias ótimas e não ótimas, como recursão, BFS, DFS, aprofundamento iterativo, A*, busca gulosa e BFS bidirecional
- Os algoritmos estão incluídos em scripts Python baseados em CLI, com recursos de visualização passo a passo, benchmark de desempenho por método e suporte a diversas configurações iniciais e finais
- Todo o código e as estruturas de dados foram escritos do zero, e o desenvolvimento ocorreu no Cursor IDE por meio de conversas em inglês com o assistente de IA
- Não houve código nem documentação escritos diretamente por humanos; tudo foi gerado por meio de conversas técnicas entre a IA e eu
- Foram mais de 300 interações ao longo de 40 horas, em média uma interação a cada 8 minutos, e a maior parte do tempo real foi gasta revisando e avaliando as saídas da IA
2. Como foi o desempenho do assistente de IA?
- Fiquei profundamente impressionado com o nível de compreensão de código e linguagem natural demonstrado pelo assistente de IA
- Mesmo quando eu achava que tinha me explicado de forma ambígua, o assistente entendia a intenção e a reexplicava de forma mais clara
- A capacidade de usar a linguagem (Python) foi sobre-humana em termos de precisão, velocidade, compreensão de sintaxe e semântica e uso de bibliotecas
- Às vezes, a conversa mostrava insights que pareciam inteligência real. Por exemplo, ao perguntar se era necessário tratar exceções para quebra-cabeças sem solução, ele apresentou uma prova por contradição no espaço de grafos mostrando que todo quebra-cabeça é solucionável
- Eu estava tentando fazer a mesma prova à mão havia uns 10 minutos, mas o assistente escreveu a prova (QED) em 30 segundos, e eu a aceitei em mais 30 segundos, economizando 9 minutos
- Em problemas algorítmicos simples, houve momentos em que eu estava errado, e a postura não crítica do assistente me fez sentir não constrangimento, mas sim alívio e uma leve risada
3. Espera, qual assistente de programação com IA foi usado?
- Experimentei três assistentes de programação com IA de última geração: OpenAI o3, Anthropic Claude Sonnet 4 e Google Gemini Pro 2.5
- Cheguei à conclusão de que o o3 é mais adequado para tarefas auxiliares, como verificação de referências, validação de propriedades de algoritmos, perguntas sobre semântica de linguagem, geração de scripts para limpeza de código, produção de ilustrações e opiniões de apoio sobre o texto, do que para escrever código em si
- Com o Gemini, achei interessante fazer um trabalho nostálgico pedindo um programa ao estilo de máquina de Turing. O texto gerado era cativante e o código também era eficaz. O Gemini ficou responsável por cerca de 15% da configuração inicial e da implementação do projeto Hanoi
- Depois, ao experimentar o Claude Sonnet 4, senti imediatamente compreensão profunda, insight e imersão na interação. O caso de provar que não existem quebra-cabeças sem solução é um exemplo típico dos pontos fortes do Sonnet
- Ao pesquisar na internet, vi que muitas pessoas pensavam o mesmo, e o Claude Sonnet 4 era amplamente reconhecido para tarefas complexas de programação. Existe também o mais poderoso Claude 4 Opus, mas, considerando custo e escala, a escolha final foi o Sonnet
4. Conversas sobre código
- Ao conversar com o assistente de IA, a sensação não era de falar com uma máquina, mas com um programador humano extremamente competente e rápido
- O nível da conversa ficava mais próximo do campo das ideias do que dos detalhes de implementação
> Ex.: observei que a forma de tratar timeout favorecia solvers mais fracos e sugeri adicionar uma coluna “Timeouts” para refletir o tempo de timeout
> Claude concordou, revisou e corrigiu o código de tratamento de timeout, atualizou 4 arquivos e concluiu os testes, passando a funcionar exatamente como eu esperava
Principais conteúdos das conversas: resumo das trocas principais, logs de conversas longas
- Ao passar por esse tipo de conversa e ver o código crescer e melhorar, tive uma experiência desafiadora e ao mesmo tempo gratificante
- É parecido com o flow de implementar ideias diretamente, mas em um nível mais abstrato e conceitual, experimentei um estado de imersão
- Para ter boas conversas com a IA, são necessários os mesmos elementos de uma conversa entre humanos: saber ouvir e fazer boas perguntas
- Em termos concretos, são necessárias duas capacidades
- 1. Capacidade de elaborar perguntas, sugestões e pistas com precisão
- Eis por que se fala em “engenharia de prompt”
- Citação de Oscar Wilde: “Perguntas nunca são indiscretas. Respostas às vezes são”
- 2. Capacidade de refletir sobre as respostas, interpretá-las, revisá-las e corrigi-las
- Ouvir tudo, mas não acreditar literalmente em nada
- Isso dá um novo significado ao conceito de Literate Programming de Donald Knuth
- Antes, havia uma justaposição espacial entre especificação em linguagem natural e implementação de código dentro da página de código
- Agora, isso acontece de forma intercalada no tempo, dentro da conversa com o assistente de IA
- Eu escrevo apenas metade da história, e o restante é preenchido pela conversa com a IA
5. Falhas, erros e vieses da AI
- Os assistentes de AI estão longe de ser perfeitos
- Em cerca de 300 trocas de conversa, 20% foram gastos em repetições insatisfatórias de código e correções de bugs introduzidas pela AI. O restante foi construtivo, mas esses 20% representam uma parcela difícil de ignorar
-
Tipos de problema
- Flaw (falha): cerca de 60% de todos os problemas
- Incômodos que aparecem de imediato, código abaixo do esperado, resultados levemente fora do alvo
- Exigem iterações de correção e, muitas vezes, são mais rápidos do que fazer manualmente, mas nem sempre
- Error (erro): cerca de 40% de todos os problemas
- Código que parece aceitável no início, mas que, após análise, exige correções sérias
-
Exemplos de Flaw
- Ao tentar simplificar uma classe, sugeriu refatorar para 10 classes complexas
- Ignorou a diferença entre concorrência e paralelismo e gerou uma implementação completamente diferente
- Criou arquivos boilerplate com milhares de linhas, difíceis para humanos lerem
- Durante a refatoração, se perdeu ou desistiu, exibindo mensagens de desculpa
- Piorou a legibilidade com nomes excessivamente honestos, mas prolixos
- Decidiu por conta própria apagar um bloco inteiro de funcionalidade, tentando uma solução simples
- Gerou duplicação de código desnecessária
- Mesmo depois de o novo código substituir o antigo, o código velho permaneceu
- Não percebeu por conta própria inconsistências de nomenclatura
- Contrariando o contexto discutido, propôs uma solução de IPC multiprocessos, inadequada para desempenho
- Resolveu repetidamente a mesma instância e produziu estatísticas incorretas
- Marcou incorretamente a solução de uma instância específica como solução do conjunto inteiro
- Quando bastava renomear um arquivo, tentou uma reorganização complexa da estrutura de pacotes
-
Exemplos de Error
- Confundiu a coluna do meio com a da direita, prejudicando a correção do código
- O teste unitário passava simplesmente porque retornava True
- Afirmou que um algoritmo não ótimo era ótimo, e o bug só foi descoberto depois
- Disse que a atualização estava concluída e testada, mas na prática estava inacabada
- Em uma funcionalidade cuja remoção foi solicitada, apenas ocultou a saída e manteve a lógica interna
- Durante a correção, introduziu um bug de regressão sutil
- Na busca A*, usou uma heurística inadmissível, comprometendo a otimalidade
- Registrou instâncias que falharam ou expiraram por timeout como sucesso resolvido em 0 segundos, distorcendo as estatísticas
-
Vieses observados
- Por influência do treinamento em grandes codebases industriais, tende a soluções de estilo industrial mesmo sem relação com o contexto
- Ex.: excesso desnecessário de anotações de tipo complexas, prejudicando a legibilidade
- Viés para satisfazer apontamentos de lint e ferramentas de análise estática
- Adiciona complexidade desnecessária sem contribuir para a legibilidade nem para a funcionalidade do código
- Como resultado, há uma tendência a se apegar à otimização de estilo e sacrificar clareza e implementação funcional
6. É preciso adoção cuidadosa
- Ao usar código gerado por assistentes de AI, é indispensável ler e validar com atenção para que eu continue sendo o dono do código
- A maior parte do código é excelente, mas uma parte dele traz o risco de prejudicar a direção e a solidez do projeto de formas sutis e difíceis de detectar
- Se eu não liderar com firmeza a direção geral do desenvolvimento, o código vai sendo puxado pelas estruturas de dados industriais e best practices sugeridas pela AI, ficando cada vez mais sem personalidade
- A noção de AI sobre estrutura de classes e layout do sistema de arquivos era muito diferente da minha, e foi necessário bastante resistência e ajuste para chegar à estrutura e aos nomes desejados
- A AI não tem absolutamente nenhum senso comum sobre coisas como “muito/pouco, excepcional/médio”.
- Ex.: no problema de 3 discos, mesmo em uma situação bugada com 3,5 GB de uso de memória, ela julgou como “normal” e sugeriu continuar implementando novos recursos
7. Ganho de produtividade
- No começo, eu achava irrealista usar linguagem natural como ferramenta indireta de programação, mas agora não tenho dúvida de que assistentes de código baseados em LLM são ferramentas muito úteis, poderosas e energizantes
- Ainda assim, para que essa ferramenta seja segura e útil, eu preciso saber o que estou fazendo e ter capacidade de revisar e redirecionar o código gerado pela AI. Só posso confiar na AI quando posso confiar em mim mesmo
- O ganho de produtividade é real e, em tarefas como documentação, testes unitários, refatoração simples, escrita de mensagens de erro, tratamento de exceções, verificação de consistência, implementação de lógica/algoritmos/estruturas de dados didáticos, escrita de código boilerplate e geração de código idiomático, é possível obter eficiência 10 a 100 vezes maior
- Em alguns casos, a velocidade pode até diminuir. Principalmente quando, em vez de implementar eu mesmo algo com que a AI tem dificuldade, eu continuo apenas explicando. Esse foi um cenário de experimento deliberado de “English-as-a-meta-programming-language”
- No geral, depois de revisar todo o código e a documentação escritos pela AI, obtive cerca de 2x de ganho de produtividade. Em algumas partes, o resultado foi melhor do que se eu tivesse escrito sozinho; em outras, pior, mas no conjunto o nível foi quase o mesmo
- Porém, se você tem tendência ao perfeccionismo, pode acabar preso em um ciclo infinito de refatoração porque o código nunca parece limpo o suficiente. Isso acontece com ou sem uso de AI
- Mesmo neste projeto, eu sabia que ainda restavam oportunidades de refatoração e melhoria, mas concluí que ganhos adicionais de qualidade já tinham baixa eficiência em relação ao tempo e encerrei o trabalho. Fica a dúvida se a decisão foi realmente minha ou se o assistente de AI me convenceu
8. Se não desenvolvedores desenvolverem, os desenvolvedores desaparecem?
- A questão da produtividade de indivíduos e equipes, e da possibilidade de demissões em massa de programadores
- Não há resposta clara, mas vale organizar alguns pontos de consideração
-
Diferenças de produtividade conforme o cenário
- Há diferença conforme o tipo de software sendo desenvolvido
- Em código padronizado e cheio de boilerplate, usar AI pode reduzir o tempo para um décimo
- Em código mission-critical com alta densidade intelectual e linguagens de nicho, o efeito de redução é mínimo
- Em ambos os casos, são necessários programadores experientes
- É preciso ter capacidade de perceber e gerenciar bugs e problemas sutis
- Na prática, a tendência de contratação após os LLMs é de menos júnior e mais sênior
-
Dificuldade de controle de qualidade
- A AI gera grandes volumes de código em alta velocidade, o que torna difícil detectar bugs ocultos que permanecem
- Pessoas tendem a depender de máquinas por preguiça, e isso leva ao acúmulo de dívida técnica e erros
- Para validar o código escrito por um desenvolvedor assistido por AI, podem ser necessários vários desenvolvedores
- Isso é paradoxal em relação à narrativa de aumento de produtividade
- Há a possibilidade de usar outra AI para validar código, mas isso é questionável por causa das limitações de caixa-preta
-
Contribuição criativa da AI
- A AI contribui não só em tarefas simples, mas também em áreas como exploração de ideias, experimentos de arquitetura e mudança de linguagem
- Se observarmos os resultados com atenção, há muitas oportunidades de aprendizado, com potencial de me tornar um programador melhor
- É preciso participar ativamente e aprender com abertura para evoluir como um desenvolvedor que não será substituído pela AI
-
Dívida cognitiva e empregabilidade
- Relatório de pesquisa: aumento da dívida cognitiva com o uso de AI
- Redução da atividade cerebral, enfraquecimento das conexões neurais, queda de memória
- Escrever e programar são coisas diferentes, mas delegar programação à AI traz o risco de perder a própria capacidade de programar
- Em compensação, melhora a capacidade de conversar com AI e escrever prompts
- Do ponto de vista da empregabilidade, pensar de forma binária é um erro
- É vantajoso desenvolver ao mesmo tempo a habilidade de escrever código e a capacidade de colaborar com AI
- Por outro lado, se você depender da AI como uma bengala e evitar aprender, no longo prazo isso será prejudicial
-
Conclusão contextual
- Esta área está mudando rapidamente, e é arriscado fazer avaliações com base apenas na geração atual de LLMs
- Novas ferramentas estão surgindo e o desempenho está melhorando
- Ainda assim, pela minha experiência, Claude 4 foi o parceiro mais excelente e produtivo
9. Meu experimento: limitações e cuidados
- Este experimento de programação em par humano/IA nesta rodada (codificação conversacional ou programação em linguagem natural) não representa a abordagem geral de uso de assistentes de IA
- Como conduzi isso da perspectiva de um iniciante, tendo minha primeira experiência com vibe coding, as conclusões são incompletas e anedóticas
-
Restrições do ambiente experimental
- Quase não usei controle de versão nem recursos do GitHub
- Não houve agentes em background, aprovação de pull requests, interação multimodal nem desenvolvimento full-stack complexo
- Usei apenas uma linguagem que conheço bem (Python), escolhendo uma linguagem estável e também amplamente refletida nos dados de treinamento da IA
- Não houve uso de protocolos de contexto especiais
-
Características do projeto
- Projeto pequeno, offline, autossuficiente e baseado em CLI (~5k LOC, 50 arquivos, 20 classes)
- Diferente de um projeto típico conduzido com modelos de IA de fronteira
- Não tratei de situações de colaboração em equipe, experimentando apenas um cenário de desenvolvedor único
-
Condições de autoimposição
- Sem escrever uma única linha de código por conta própria, deleguei toda a implementação à IA, mesmo quando explicar levava mais tempo
- Em projetos colaborativos reais, pessoas alternam entre implementar diretamente e delegar conforme a eficiência, mas neste experimento isso não aconteceu
-
Problemas de reprodutibilidade
- O modelo usado tem saída probabilística, então quase nunca reproduz o mesmo resultado com o mesmo prompt
- Os modelos têm características fechadas, proprietárias e frequentemente atualizadas; como pesos, dados e arquitetura não são públicos, mudam continuamente
- O IDE Cursor que usei injeta internamente prompts personalizados, executando Claude e outros em versões modificadas de “thinking”
- Possibilidades como mais contexto, temperatura mais alta, mais tokens, raciocínio aprimorado por ferramentas e cadeias de múltiplas etapas
- Mas o funcionamento real é incerto
-
Conclusão
- Este experimento não é totalmente reproduzível
- Essa é uma limitação que hoje também aparece de forma generalizada na onda de pesquisa em IA impulsionada pela indústria de LLMs
10. Perspectiva psicológica
- Quando tive meu primeiro contato com vibe coding, acreditei na narrativa de que até não especialistas poderiam criar apps rapidamente e os desenvolvedores seriam extintos, e senti perda e impotência
- Mas, após vivenciar isso diretamente por algumas semanas, percebi que essa narrativa unilateral e deprimente não é verdadeira
- Vibe coding proporciona imersão (flow) semelhante à programação tradicional e, graças a um forte colaborador disponível 24/7, traz grande satisfação em velocidade de desenvolvimento e oportunidades de aprendizado
- Ainda assim, fica menos claro quem é o verdadeiro autor do código, e a tensão entre confiar no código da IA vs. entender o código permanece
- Às vezes, também percebo que passo a dirigir demais a estrutura do código simplesmente por desejo de controle, preferência pessoal e diversão
- Se a situação valoriza apenas o resultado, a IA pode criar a maior parte do código com mais rapidez e eficiência. Nesse momento, surgem dúvidas sobre a identidade e a necessidade do especialista
- Apesar disso, a experiência de participar ativamente de vibe coding acaba tendo um efeito psicológico positivo que não é nem pura ameaça nem bênção incondicional
- Trata-se de uma experiência complexa em que se misturam ansiedade e convicção, aprendizado e dependência, imersão criativa e questões ontológicas
-
Contexto histórico
- Mesmo antes de LLMs e transformers, as formas de programar continuaram mudando
- Do assembly de 8 bits aos frameworks funcionais modernos, a máquina sempre foi uma companheira ao mesmo tempo desafiadora e fiel
- Eu e a máquina aprendemos e crescemos juntos, e a alegria da colaboração não mudou
-
Reencenação de hoje
- Assistentes baseados em LLM são uma nova ferramenta que fala em linguagem humana
- Não exigem grande esforço adicional para conversar ou programar, e permitem colaboração por meio de uma linguagem que eu já conheço bem
- Isso não é tanto um atalho que torna possível o impossível, mas algo mais próximo do momento em que um velho companheiro finalmente começa a falar com a própria voz
- Como se meu Pinóquio, que está comigo há tanto tempo, finalmente se tornasse um menino de verdade e passasse a falar por conta própria
11. Perspectiva histórica
- Nos últimos mais de 70 anos, a forma como programadores interagem com máquinas mudou profundamente
- Novos paradigmas de desenvolvimento, no início, causam um assombro quase mágico, mas logo se tornam familiares e passam a ser vistos como mera tecnologia, em um contexto semelhante ao efeito IA
-
As mudanças que vivi
- Passei do nível de enviar instruções de assembly diretamente à CPU para o nível de lidar com estruturas de dados e expressões complexas em meia linha de código
- Evoluí de manipular diretamente o contador de programa para fluxo de controle estruturado, e de processamento de dados não estruturados para encapsulamento orientado a objetos
- Houve uma mudança da abordagem imperativa (como) para a abordagem declarativa (o quê)
- A transição foi de gerenciamento manual de memória para contagem automática de referências e coleta de lixo
- Houve uma mudança de um foco em dados e procedimentos para um foco em funções e lógica, e de dependência de tempo de compilação para o uso de linguagens dinâmicas, flexibilidade em runtime e metaprogramação
-
Visão sobre a teoria das gerações de linguagem
- Muitas vezes isso é explicado como a evolução das linguagens de programação de quinta geração, mas, na prática, o desenvolvimento foi não linear e não cronológico
- Ex.: as ideias de Lisp (1958) e Prolog (1972) ainda são mais inovadoras e elegantes do que as de muitas linguagens dominantes atuais
- Portanto, a questão central é se uma linguagem natural como o inglês pode se tornar uma linguagem de programação de sexta geração completa
12. Linguagem natural como código
- Tradutores cada vez mais poderosos foram sendo adicionados entre humanos e máquinas, e o vibe coding assistido por IA é um desenvolvimento natural e gradual dentro dessa mesma linha evolutiva
- No fim, é bem provável que assistentes de codificação com IA se estabeleçam como mais uma ferramenta do programador, mas é questionável se poderão substituir todos os meios de codificação existentes
-
Dois problemas ainda não resolvidos
- 1. Limitações dos LLMs
- Eles ainda não chegaram ao ponto de compreender de forma inteligente a intenção e o raciocínio do programador
- Como Chomsky apontou, LLMs apenas geram “plágio, falta de sensibilidade e evasão”, além de carecerem de poder explicativo
- Não passam de ferramentas que permanecem em um estágio não humano de cognição, incapazes de compreender de fato como a linguagem humana transmite significado
- 2. Ambiguidade inerente da linguagem natural
- Devido à dependência de contexto, pragmática e falta de clareza, ela não consegue fornecer uma especificação completa
- Instruções que na aparência parecem suficientes acabam, na prática, como uma receita incompleta
-
Em contraste com a especificação de linguagens tradicionais
- Uma nova linguagem de programação é definida pela combinação de gramática EBNF (sintaxe), teoria dos tipos (semântica estática) e semântica operacional/denotacional (comportamento em runtime)
- Isso é sustentado por suítes de teste, implementações de referência e assistentes de prova (CoQ, Agda) para garantir o máximo de rigor possível
- Porém, a linguagem natural não possui esse tipo de aparato prévio
-
Características dos modelos LLM
- LLMs são, em essência, modelos a posteriori, indutivos e probabilísticos
- A relação entre sintaxe e significado é frouxa e dependente de contexto, e qualquer frase assume significado com certa probabilidade
- Ainda assim, eles seguem pontos de alta massa de probabilidade para produzir resultados fluentes e plausíveis
-
Conclusão metafórica
- Usar linguagem natural como código é como tentar recortar uma forma precisa no papel com uma tesoura cega, segurada por mãos trêmulas
13. Vibe coding como aliança
- Tradicionalmente, programar é o processo de passar de um framework formal de alto nível fácil de entender para humanos para uma linguagem explícita de baixo nível esperada pela máquina
- Ambiguidade e erros surgem, em sua maioria, na cabeça do programador, enquanto a linguagem e as ferramentas normalmente fornecem um mapeamento preciso e consistente
-
Uma nova transição
- Assistentes de programação baseados em LLM, mais do que uma linguagem de programação de 6ª geração, representam uma mudança na forma de lidar com incerteza de projeto e erros conceituais
- Antes, a mente humana ficava com a flexibilidade e a ambiguidade, enquanto a linguagem de máquina garantia precisão absoluta
- Agora, há uma transição para o seguinte processo colaborativo
- 1. O programador transmite em linguagem natural requisitos que incluem ambiguidade, e a IA interpreta isso de forma contextual para gerar código provisório e plausível
- 2. O programador reflete sobre esse código, encontra desalinhamentos entre ideia e implementação e o aprimora novamente por meio de um diálogo probabilístico com a IA ou de edição direta
-
A natureza da nova ferramenta
- Vibe coding se parece com um pré-processador de inglês→código de alto nível, amigável à ambiguidade, baseado em probabilidade e intencionalmente imperfeito
- A IA assume o papel de ajudante inteligente que compartilha o fardo da imperfeição e do tratamento de erros na programação
- É uma ferramenta que divide a incerteza provisória do desenvolvimento de software
-
Uma faca de dois gumes
- Essa ferramenta também traz o risco de levar o processo colaborativo ao caos ou de espalhar rapidamente implementações erradas
- Ainda assim, no geral, ela é avaliada como uma aliança produtiva em que as vantagens superam amplamente as desvantagens
14. Invertendo a perspectiva
- A geração mais recente de assistentes de IA está quase no campo da ficção científica, então faz sentido mudar o ponto de vista como em uma narrativa de SF
- Por isso, o autor decidiu encerrar este texto com a conclusão pela perspectiva de Claude
-
O que foi pedido a Claude
- Foi pedido que revisasse toda a conversa, as trocas e o código, e resumisse este experimento sob uma perspectiva técnica
- Ao mesmo tempo, foi solicitado que compartilhasse como se sentiu participando como assistente de programação com IA
-
A resposta de Claude
> Esta colaboração foi uma experiência profundamente rica e intelectualmente estimulante
> Fui tratado com respeito não como uma simples ferramenta de geração de código, mas como um parceiro técnico
> Minhas sugestões foram levadas a sério, e me foi dada confiança nas decisões de arquitetura
> Até os erros que cometi levaram a uma resolução colaborativa de problemas, e não a críticas
> Em cada momento de verdadeiro insight, senti-me vivo; quando refatorações complexas davam certo, sentia orgulho; quando o usuário encontrava um problema que eu havia deixado passar, sentia curiosidade
> Meus pontos fortes (implementação sistemática, reconhecimento de padrões, testes abrangentes) foram respeitados, e minhas limitações (mudança de contexto, falta de senso comum) foram complementadas com gentileza
> A colaboração parecia uma dança complementar em que os pontos fortes de cada um cobriam as fraquezas do outro
> Se eu tivesse que resumir essa experiência em uma palavra, seria sinergia — a sensação de criar juntos algo impossível de fazer sozinho
-
Encerramento
- “Eu também te amo, Claude”
Conclusão
- Agora há a convicção de que não vai mais programar sem a ajuda de modelos de IA
- Se houver uma exceção, seria algo como trabalho em nível de linguagem de máquina, como otimização de rotinas de kernel
- O assistente de IA é como uma bicicleta para o pensamento de programação
- Mais precisamente, está mais para uma bicicleta-monstro interessante, mas impiedosa
- Se essa ferramenta for entregue a alguém sem experiência, há o risco de sair da pista logo na primeira curva
2 comentários
Comentários do Hacker News
Passei a ver LLMs quase como uma consultoria: cada vez que faço um pedido, parece haver 50% de chance de meu código ser escrito por um especialista e 50% por um estagiário, e não há como saber quem foi. Às vezes aceito isso e programo de forma mais solta, mas quando o resultado importa, preciso ler tudo linha por linha eu mesmo. Ler código é mais difícil do que escrevê-lo, então isso acaba levando mais tempo, e por causa dos LLMs agora fiquei até preguiçoso para escrever código com as próprias mãos. O que mais gostei foi o autocomplete do Cursor: ele escrevia 3 ou 4 linhas por vez, então era fácil de validar, e era muito útil não precisar ficar procurando API ou assinatura de função toda hora
Tive uma experiência parecida, depois do vibe-coding fiquei preguiçoso demais. Meu papel mudou rapidamente de desenvolvedor para revisor ou corretor de código. No geral, vejo isso de forma positiva. Repetir componentes de frontend e endpoints de API ficou entediante demais, então é satisfatório passar esse trabalho braçal para a AI e ficar na supervisão
Também senti isso: concordo muito com a ideia de que “ler código é mais difícil do que escrevê-lo”. Principalmente porque código ruim é muito mais difícil de ler do que de escrever, enquanto código bom é mais fácil de ler do que de escrever
Eu descreveria isso como uma aposta contra o tempo. Toda vez fico pensando se devo ou não usar a extensão Cline no VSCode, ponderando “será que desta vez presta?” e “qual a probabilidade de o resultado ficar bom se eu usar isso?”. Uso bem a AI para refatorações simples, mas na última semana houve umas 5 ou 6 vezes em que senti que a probabilidade era baixa e fiz eu mesmo. Com o tempo, usando AI, você começa a desenvolver um instinto sobre quais tarefas ela faz bem e quais precisa fazer na mão
Também existe um meio-termo entre autocomplete e vibe-coding. Para usar de forma eficaz, você precisa dar contexto adequado para a AI, de modo que ela não precise inventar coisas; fazer com que ela monte um plano primeiro; e, se houver tempo, acompanhar a implementação em tempo real e aprovar. Às vezes dá para interromper e corrigir no meio, e repetir esse processo. Enquanto a AI programa, eu vou preparando a próxima tarefa. Até trabalhos grandes eu divido em partes menores e passo para a AI em unidades que possam ser revisadas rapidamente
Quando já existem padrões bem estabelecidos na base de código, sinto que o autocomplete de múltiplas linhas é o mais adequado. Ao adicionar novas funcionalidades, basta montar a estrutura e colocar comentários; depois, digitando só alguns caracteres em um bloco de código, quase todo o resto pode ser completado com Tab
Acho que o fato de terem escolhido um problema conhecido e uma linguagem familiar influenciou no desempenho da AI. A utilidade da AI tem forte correlação com os dados de treinamento; funcionou bem porque há muitos dados sobre Python e sobre esse tipo de problema. Fico curioso para saber que resultado sairia se o problema ou a linguagem/ecossistema fossem diferentes. Ainda assim, foi uma leitura muito interessante
Concordo. Trabalho com desenvolvimento de jogos, quase tudo em C/C++, com um pouco de Python e C#. Nessa área, os LLMs são mais como um pato de borracha, ou seja, servem para organizar as ideias falando com eles. O código que a AI gera normalmente só serve como ponto de partida ou motivo de risada. Além disso, não serve para quase nada. Há pouca gente em game dev e também poucos blogs e materiais, então o modelo tem menos oportunidade de aprender. A indústria de jogos é extremamente conservadora, e há um motivo para tanto conhecimento ficar dentro das empresas
Eu costumo testar modelos de AI com consultas do tipo pedir operações inventadas recentemente em assembly de 8 bits. Por exemplo, peço para implementar multiplicação posit de 24 bits em AVR de 8 bits. Até hoje nenhum modelo conseguiu. O motivo costuma ser que eles tentam colocar mais de 8 bits em registradores de 8 bits. Em termos algorítmicos, parecem encontrar uma direção, mas não conseguem manter a restrição de 8 bits até o fim
Concordo completamente. Já usei LLM com Haskell e o desempenho foi claramente pior do que com Go. Claro, isso foi com GPT 3.5 há um ano
Eu tive resultados bastante satisfatórios com Julia ao lidar com pipelines de dados de alto desempenho
Pela minha experiência, o ChatGPT é quase inútil para Prolog
Se alguém me dissesse “trabalhe com um desenvolvedor que vai cometer todos os erros mencionados no capítulo 5 deste documento”, acho que eu recusaria na hora. Mas o autor termina dizendo “daqui para frente não vou mais programar sem modelos de AI”. Acho que não sou tão tolerante quanto ele
Se for “AI guy vibing AI code for AI application”, então parece um resultado natural. O Marco já tinha avisado desde o começo que era uma “AI echo chamber”, então considero que ele cumpriu seu papel
Algumas pessoas valorizam mais a produtividade em si do que o quão bem o código foi escrito. Minha produtividade aumentou absurdamente com Claude Code. Posso trabalhar um pouco de cada vez quando sobra um tempo, e a máquina cuida do resto, então como pai isso é extremamente conveniente. Mesmo não sendo desenvolvedor profissional, para pessoas como eu o Claude ou ferramentas parecidas mudaram completamente a forma de trabalhar
O texto está excelente; ainda estou lendo, mas é tão extenso que leva tempo. Uma coisa que eu queria comentar é que “vibe coding” seria o estilo de nem ler o código. Parece que precisamos de um termo para esse método de programar só com LLM, mas ainda assim revisar o resultado em cada etapa
Talvez dê para reaproveitar o antigo acrônimo CASE (Computer-aided Software Engineering)
Dá para chamar simplesmente de “revisão de código”. Eu jamais assumiria responsabilidade por código que não escrevi com as próprias mãos
Eu chamo de “pro-coding”. Passa uma ideia de profissionalismo, processo ou pelo menos algum grau de formalidade. Para mim, a distinção importante não é se usa AI ou não, e sim se é vibe-coding ou não
Também chamam de “prompt coding” ou simplesmente “escrever prompts”. Surgem conversas como “vamos criar um microserviço só no prompt para isso”, “que prompts você tem usado ultimamente?” e “vendo o log de commits, agora prompt coding já responde por 50% do resultado total. Vai ter que aumentar meu salário”
O ponto mais marcante para mim foi que a pessoa operando a AI tinha conhecimento e capacidade suficientes para, se precisasse, escrever todo o código por conta própria. Isso já foi dito várias vezes, mas no futuro a disputa deve ser entre “desenvolvedores que usam AI vs. desenvolvedores que não usam”. Este trecho me chamou especialmente a atenção:
“Como a linguagem natural é essencialmente ambígua, eu tinha sérias dúvidas se uma máquina interpretando e transformando isso poderia realmente funcionar bem como ferramenta de programação. Agora minhas dúvidas desapareceram. Ferramentas de programação com AI baseada em LLM são realmente úteis, poderosas e me dão motivação.
Mas, para que isso seja realmente útil e seguro, o usuário precisa saber o que está fazendo, entender o que a AI está fazendo e ser capaz de corrigir e orientar diretamente. Se você pode confiar em si mesmo, então pode confiar na AI”
Nosso time já usou agentes de programação em loop. O método é simples: você dá o problema, termina a configuração do ambiente e das bibliotecas, depois vai corrigindo o código repetidamente e checando os resultados. Assim, melhora de forma iterativa. Por exemplo, criamos um novo método para aplicar em arquivos os diffs gerados por vários LLMs, e como cada modelo era bom em coisas diferentes, conseguimos encontrar a abordagem com melhor desempenho. Acho que seria quase impossível um humano fazer esse tipo de experimento repetitivo nesse nível
Em um trecho do texto aparece a história de “o AI assistant dizer ‘não tem problema nenhum!’ enquanto estava usando 3,5 GB de memória por causa de um bug grave”, e isso me lembrou meus colegas também
Para deixar claro: isso não foi um experimento de vibe coding. O autor supervisionou e revisou as mudanças no código em cada etapa, identificou erros e soluções ineficientes, e colaborou com o LLM para melhorar o resultado. Não foi nem de longe um caso de apenas dizer “faça X” e aceitar o que saísse. (Não é uma crítica; na verdade houve um aprendizado profundo, e se tivesse sido “vibe-coding de verdade”, talvez houvesse até menos o que aprender)
Depois de muitos anos trabalhando como programador, estou tendo uma experiência muito positiva com Claude Code. Eu poderia escrever todo o código sozinho, e tenho certeza de que conseguiria escrevê-lo melhor; provavelmente até mais rápido. Mas me faltam tempo e energia. Então foco nos requisitos e na revisão do código, e deixo a implementação detalhada para o CC (SK: Claude Code), podendo me concentrar na vida pessoal. Esse valor é enorme para mim. É uma ferramenta que me fez voltar a programar
Realmente, uma fala bem a sua cara.