- Recentemente, uma fala de Andrej Karpathy virou assunto: "Entregue-se ao Vibe, aceite o crescimento exponencial e esqueça até mesmo que o código existe."
- "Vibe Coding" se refere à tendência de delegar a resolução de problemas a ferramentas de IA, sem um plano claro nem escrita direta de código
- Por meio de agentes LLM (grandes modelos de linguagem), tornou-se possível gerar e modificar código com comandos em linguagem natural
- 2022: no ChatGPT, era possível copiar e modificar código
- 2023: no Copilot integrado à IDE, era possível revisar e modificar código
- 2024~2025: tornou-se possível modificar vários arquivos de um projeto e até testar e corrigir por conta própria
Como o "Vibe Coding" funciona
- Tanto usuários técnicos quanto não técnicos podem configurar projetos por meio de agentes baseados em LLM
- É possível criar sites ou apps com comandos simples (ex.: "criar um site de resort de esqui")
- Após a configuração inicial, é possível fazer correções e testes automáticos
-
Exemplos:
- Cursor, GitHub Copilot Agent Mode e outros podem modificar arquivos e executar comandos
- Fazem correções e testes automáticos → podem ocorrer erros por falta de consistência
O problema da autonomia dos agentes
- Agentes podem executar tarefas automaticamente, mas isso não significa autonomia total
- Se executarem sem aprovação do usuário, podem surgir riscos (ex.: execução de comandos em modo YOLO)
- Podem ocorrer problemas de qualidade e precisão do código
-
Principais problemas:
- Falha em reutilizar código existente → recriação repetida dos mesmos componentes
- Tentativa de executar lógica de servidor no lado do cliente
- Erros após corrigir código incorretamente → falha ao consertar
- Falha ao escrever testes unitários ou até destruição do código
Limitações reais
- Modelos como Claude 3.7 Sonnet não conseguem ir além dos limites dos dados de treinamento
- Quando perdem o contexto na base de código, não conseguem fazer mudanças consistentes
- À medida que o código cresce, o desempenho cai e manter o contexto se torna inviável
- Quando a janela de contexto do LLM é ultrapassada, surgem problemas de consistência
-
Casos concretos de problemas:
- Duplicação de interfaces TypeScript
- Execução de lógica de servidor no cliente
- Falha ao corrigir componentes duplicados
- Falha ao escrever testes unitários
- Falha ao corrigir erros após refatoração de código
Tentativas de resolver o problema
- Claude Plays Pokémon: o agente joga interagindo em tempo real
- Falhas ao manter memória e corrigir erros repetitivos
- Falha em construir memória de longo prazo → erros persistentes
-
Possibilidades de melhoria:
- É necessário melhorar o MCP (Model Context Protocol) e o gerenciamento de memória
- Ao modificar código, o LLM precisa refletir corretamente as alterações anteriores
- É necessário preservar memória por domínio e histórico de tarefas
Conclusão
- O "Vibe Coding" pode chegar a 80% na implementação de conceitos funcionais, mas criar um produto confiável e seguro ainda exige o esforço de humanos experientes
- Agentes de IA permitem que pessoas habilidosas criem mais coisas de forma independente, mas não podem substituir quem consegue resolver problemas difíceis que exigem experiência e intuição.
- No nível atual, é difícil que o "Vibe Coding" leve de fato a produtos úteis, e a ajuda de desenvolvedores experientes é indispensável
- "Vibe Coding" é apenas um meio de apoio à escrita de código, não um substituto completo
9 comentários
A parte “nível atual” chama a minha atenção. Será que não estamos olhando para os LLMs com uma noção de tempo humana?
O que sinto ao programar com IA é que, mesmo dando apenas uma parte do código para a IA, para que ela consiga entender o contexto, quando acabo dividindo em unidades no estilo princípio da responsabilidade única + TDD, ela precisa captar bem sem precisar ler o contexto maior, de modo que o contexto local da parte já seja suficiente.
O que eu mais uso IA para hobbies é a criação de jogos web, então concordo. Quando o projeto passa de um certo porte, chega um ponto em que a IA claramente perde muito a capacidade de foco, por assim dizer. Eu uso isso da seguinte forma: junto toda a árvore e o código-fonte do jogo em um único arquivo, incluindo o TOC, e então crio uma nova thread, envio esse arquivo e continuo o trabalho. E, quando faço perguntas, sempre peço a resposta deixando explicitamente claro o nome do projeto atual. Mesmo assim, ainda há partes que me deixam insatisfeito... mas estou muito satisfeito com o fato de conseguir concluir, em relativamente pouco tempo, hobbies que no passado eu nem conseguia começar por estar ocupado demais com a vida real.
Esse padrão de construir algo de forma aproximada primeiro e depois ajustar o restante dos detalhes é realmente muito bom.
Estou fazendo várias tentativas, mas o limite de memória é evidente. No nível de PoC, é bom. Em termos de rapidez para avaliar possibilidade/usabilidade, é bom.
O problema é que isso exige ainda mais profissionais experientes.
Considerando que a maior parte do tempo em programação é gasta com depuração e leitura de código, acho isso um exagero bem grande. As pessoas que criam IA falam todas nesse tom, mas pelo menos olhando a situação atual, não parece ser assim. Se chegarmos a um ponto em que a intervenção humana não seja necessária, será que ainda vai haver necessidade de programar? Não seria melhor simplesmente fornecer a documentação da API e usar um LLM como backend?
Na prática, muitas vezes se usa assim mesmo, definindo o schema para receber os dados.
Concordo. No começo, a velocidade de desenvolvimento parece quase mágica, mas à medida que a escala cresce e o número de arquivos aumenta, se o responsável pela gestão disso (aqui, uma pessoa) não conseguir administrar isso de forma eficaz, o resultado será apenas algo cada vez maior e cheio de erros. Quando chega a um ponto em que já não há mais o que fazer, você só acaba desperdiçando créditos (Windsurf) ou requisições (Cursor). Vai melhorar aos poucos, mas por enquanto não dá para confiar 100% no código gerado por IA.
Opinião do Hacker News
A grande diferença entre "hype de IA vs. realidade" está nos números de produtividade que as pessoas costumam citar. Por exemplo, parceiros da YC citaram uma empresa alegando uma "melhoria de velocidade de 100x" no desempenho de programação. Uma alegação dessas seria óbvia para observadores externos, então não precisaria ser autorrelatada.
No momento, estamos seguindo a febre da terceirização. Apesar de todas as alegações exageradas, a realidade é diferente. É difícil distinguir as discussões sobre agentes de programação com LLM.
É como a comunidade de Go dizer que computadores não podem vencer jogadores humanos de Go. Já existem exemplos de modelos encontrando algoritmos de ordenação com melhor desempenho. Com os incentivos certos e tempo suficiente, os computadores vão nos superar.
Compartilhando um novo problema com LLMs de programação. Desenvolvedores offshore estão totalmente integrados à equipe. Mas o uso de LLMs é tão indiscriminado e espalhado que os pull requests enviados viram um pesadelo.
"Vibe Coding" consegue implementar 80% de um conceito. Mas, para construir algo confiável, seguro e valioso, ainda é preciso um humano experiente.
Recentemente tentei converter código Matlab para Python usando Claude e OpenAI o3-mini, mas o desempenho foi muito ruim. Havia erros em quase todas as linhas importantes. É uma tarefa que precisava de automação, mas falhou.
Fazer "Vibe-TDDing" já é melhor do que não ter testes. Se você entende de programação e de testes, dá para usar LLMs para reduzir efeitos externos negativos.
Depois de compartilhar como construir um SaaS, coisas estranhas começaram a acontecer. O uso da chave de API atingiu o limite máximo, houve tentativas de contornar a assinatura e coisas aleatórias foram criadas no banco de dados. Isso provavelmente é brincadeira.
Ver muitos engenheiros subestimando a capacidade e a produtividade das ferramentas de programação com IA me faz sentir segurança no emprego. Não vou largar o Cursor.