- Ao usar ferramentas de codificação com IA e delegar tarefas cada vez maiores, houve um sentimento de surpresa com os resultados, mas também a constatação de que faltavam consistência e acabamento estrutural ao produto final
- Mesmo escrevendo especificações detalhadas, os agentes de IA não conseguiam manter o contexto de longo prazo nem evoluir o design, e no fim toda a base de código se transformava em um conjunto de fragmentos heterogêneos
- Os trechos de código pareciam completos individualmente, mas no conjunto surgiam desordem estrutural (sloppy) e colapso de contexto
- Depois dessa experiência, o autor concluiu que não era possível garantir a confiança do usuário nem a proteção dos dados com código gerado por IA e voltou a escrever código diretamente
- A codificação com IA ainda é útil, mas pode causar dívida técnica e perda de controle por parte do desenvolvedor, exigindo uso cuidadoso
Empolgação inicial com a codificação por IA e percepção dos limites
- A maioria dos usuários começa a programar com IA em tarefas simples e, aos poucos, passa a delegar desafios mais complexos, ficando impressionada com o desempenho
- Porém, depois de certo ponto, os erros e a inconsistência da IA começam a aparecer, criando um abismo entre expectativa e realidade
- Quando o resultado não é satisfatório, o usuário tende a atribuir o problema ao próprio prompt e tenta escrever especificações mais detalhadas
- Usa ferramentas como o Obsidian para criar documentos de especificação minuciosos, mas a IA não consegue desenvolvê-los ao longo do tempo
O fracasso da abordagem baseada em especificações
- No desenvolvimento real, os documentos de design são “documentos vivos” que mudam continuamente durante a descoberta e a implementação
- Já os agentes de IA ficam presos à especificação inicial e não conseguem fazer ajustes flexíveis nem reinterpretá-la
- Ao lidar com estruturas complexas, os agentes tendem a perder o contexto geral do problema ou seguir em frente à força
- Como resultado, o código pode parecer completo por fora, mas carece de consistência interna e integridade estrutural
O colapso da qualidade do código e os limites do ‘vibecoding’
- O código escrito por IA pode parecer excelente em partes, mas no todo vira uma combinação sem sentido
- Depois de revisar toda a base de código, o autor percebeu a presença de “bagunça pura (slop)” nela
- A IA é fiel ao prompt e à própria autocoerência, mas não considera a harmonia do sistema como um todo nem a consistência com padrões adjacentes
- Isso se parece com um caso de ‘vibewriting’ em que alguns parágrafos de um romance são ótimos, mas o capítulo inteiro está uma bagunça
Retorno ao desenvolvimento centrado no humano
- O autor concluiu que não podia distribuir como produto nem usar para proteger dados de usuários o código gerado por IA
- Com a decisão de “não mentir para o usuário com este código”, voltou a programar diretamente
- Ao escrever por conta própria, percebeu melhora em velocidade, precisão, criatividade e produtividade
- Quando a avaliação é feita não pela velocidade bruta de geração de código, mas pela eficiência geral do desenvolvimento, a superioridade humana fica evidente
Uso contínuo da codificação com IA e necessidade de cautela
- O autor ainda usa LLMs de forma limitada em parte do trabalho (cerca de 40%)
- Eles são úteis para tarefas repetitivas ou geração simples de código, mas acumulam dívida técnica e reduzem a compreensão do código
- No longo prazo, existe o risco de o desenvolvedor perder o modelo mental da base de código e ficar incapaz de resolver problemas sem a IA
- Em deslocamentos (trem, avião etc.), há até situações em que a dependência da IA faz a produtividade cair a 0%
- Outros desenvolvedores apontam que a ideia de “basta escrever bem a especificação” é uma reprodução do modelo waterfall, enquanto o desenvolvimento real exige exploração improvisada e interação
Conclusão
- A codificação com IA continua sendo uma ferramenta poderosa, mas ainda carece da capacidade de manter o contexto do sistema inteiro e a consistência estrutural
- O julgamento intuitivo e a capacidade de ajuste improvisado do desenvolvedor humano continuam sendo essenciais,
e a IA deve ser usada como meio auxiliar, de forma cautelosa e sob controle
9 comentários
Faz nem um ano completo que o conceito de vibe coding surgiu, então que pose de SNS é essa, pqp kkk
É preciso se dedicar bastante ao refinamento das especificações.. Se você realmente criar e lapidar as especificações do jeito formal que aprendemos em Engenharia de Software, e depois trabalhar atualizando enquanto faz a gestão de rastreabilidade, isso ajuda bastante.
Durante o projeto, eu sempre continuo elevando a versão dos templates de especificação e dos prompts, e ultimamente venho pensando que talvez seja hora de estudar Engenharia de Software de forma mais aprofundada.
O autor ainda utiliza LLMs de forma limitada em algumas tarefas (cerca de 40%)
Pelo que foi descrito acima, parece que o autor também não defende abandonar completamente a IA.
Parece que precisamos continuar pensando em como usar isso bem. Acho que desenvolver abrindo mão da IA é, aos poucos, ficar para trás.
O autor deste texto já usou uma boa forma de aproveitá-la, mas, ainda assim, acho que é preciso refletir sobre como usar a IA ainda melhor.
(ainda só há muitos erros e acertos pelo caminho...)
Atualize a especificação
Isso mesmo. Dá para colocar um hook e, quando a implementação estiver concluída, atualizar a especificação; e, mesmo que não seja assim, também dá para adicionar um command ou skill para atualizar a especificação manualmente kk
Ah, odeio envelhecer.
Comentários do Hacker News
Acho que o fato de a IA ser boa demais no básico é justamente o perigo
Os alunos passam a não escrever código por conta própria porque “a IA faz isso por eles”, e como resultado deixam de aprender na prática os passos intermediários e os conceitos difíceis
Como professor de ciência da computação, enfatizo aos alunos: “você precisa escrever o código com as próprias mãos, não a máquina”
É fácil levantar peso com uma empilhadeira, mas isso não desenvolve músculos
A dor do processo de aprendizado é justamente o núcleo do crescimento
Claro que no trabalho o resultado importa mais, mas ainda assim precisamos de pessoas capazes de pensar em nível mais alto
O candidato tinha conhecimento teórico perfeito, mas não conseguia explicar de forma alguma como o código que ele escreveu funcionava
No fim, confessou que “o GenAI escreveu a maior parte”, e a distância entre “o que aprendeu” e “o que realmente fez” era grande demais
É mais importante ensinar “como o código funciona” do que “como escrever código”
Antigamente houve uma época em que se programava diretamente em assembly, mas hoje vale mais a pena entender os princípios dos compiladores
Na prática, a maioria não vai criar um compilador ou um SO do zero, mas conhecer esses princípios ajuda a entender os limites das linguagens de programação
Quando os compiladores surgiram, houve o mesmo debate, e no fim subimos para um nível maior de abstração
Só implementar coisas não aprofunda o pensamento
Se você delega a implementação à IA, no fim vira “um cego guiando outro cego”
O processo de pensar enquanto mexe diretamente no código é indispensável
Não concordo com a ideia de que “a IA é boa em tarefas simples, mas ainda melhor nas grandes”
Na prática, só tive resultados decepcionantes
Ou o código não funcionava direito, ou era preciso ficar pedindo correções repetidamente
Se o ciclo de feedback é difícil, no fim você mesmo vira a única fonte de feedback, e aí os limites da IA ficam evidentes
Por exemplo, se explico claramente a estrutura de um TaskManager ou regras de ownership de memória, ela gera código que até passa nos testes
Há gente como Ryan Dahl que diz “não escrevo mais código diretamente”, mas isso só funciona porque vai refinando em colaboração por meio de feedback iterativo
É preciso lidar com a IA como se estivesse ensinando uma criança
Descreva claramente entrada, saída e erros esperados, e vá ajustando com experimentos repetidos
O Claude faz perguntas, pesquisa e até revisa código
É como orientar um desenvolvedor júnior competente
No começo tentei “vibe coding” de mente aberta, mas fui ficando cada vez mais cético
É bom para código repetitivo e claro, mas inadequado para lógica central de negócio
O Claude frequentemente ignora a especificação, repete a mesma lógica várias vezes ou diz que corrigiu algo e deixa tudo igual
Também dá a sensação de que o modelo está ficando mais lento e menos afiado
Hoje uso só para discutir design ou fazer debugging
Se há muitas “partes chatas” para a IA preencher, talvez a própria estrutura do código já esteja errada
Nisso, os LLMs ainda ajudam bastante
Muitos desenvolvedores de qualquer forma recebem um design já definido e apenas implementam, então a IA pode acelerar esse trabalho
Não concordo com a afirmação de que “a IA não consegue refletir mudanças de design”
Na verdade, esse é justamente o papel do humano
Por exemplo, se você pede para mudar a estrutura de uma API, a IA pode encontrar e ajustar todas as partes relacionadas e ainda rodar testes
Eles se prendem demais a detalhes de implementação ou deixam faltar validação conceitual
Ainda assim, testes escritos por humanos muitas vezes sofrem do mesmo problema, então dá para entender
Se você não escreve o código diretamente, não sente as partes ásperas e desequilibradas da abstração, e isso acaba levando à perda de qualidade estrutural
Essa diferença determina o nível de acabamento do código
Mas o importante é saber julgar quais tarefas realmente exigem intervenção manual
Mas a eficiência só aparece de verdade com uma assinatura premium cara, como o Claude Max de 200 dólares
Fico em dúvida com a frase “faço vibe coding há 2 anos”
O Karpathy cunhou esse termo há apenas 1 ano (fonte)
É interessante que o GPT tenha desenhado a própria API que usaria e depois implementado com base nela
Mas depois, segundo ela, os modelos passaram a bloquear conversas sobre autoedição e auto-replicação
Mesmo sem uma ferramenta totalmente agentic, isso já é bem possível com ChatGPT ou Claude
Eu digo aos alunos que “assistir esporte na TV não significa que você está se exercitando”
Com vibe coding é a mesma coisa: existe uma sensação de realização que só vem ao escrever código com as próprias mãos
o “código meio pronto” que a IA gera me devolve a motivação
Tenho dúvidas se engenheiros de verdade fazem “vibe coding” de forma cega
Eu, na verdade, uso mais um modo de lapidar o código por conversa
Apresento os requisitos, reviso o design junto com a IA e vou completando a estrutura aos poucos
Esse processo é mais lento, mas preserva a colaboração e a profundidade do raciocínio
A IA sugere ideias novas com base na enorme quantidade de código que aprendeu, e eu calibro isso com minha experiência
No fim, a IA parece uma versão expandida de mim (me++)
Ainda não estou pronto para entregar tudo a um agente totalmente autônomo, mas esse modelo é o mais produtivo para mim
Sinto que o código escrito por IA é como um romance excelente em partes, mas ruim como um todo
Capítulo por capítulo parece perfeito, mas no contexto geral fica confuso
Se não, então esperar que uma base de código de 10 mil linhas feita por vibe coding funcione direito é exagero
Se não houver pensamento e emoção humana refletidos ali, a experiência do usuário também perde consistência e surge atrito cognitivo
Quando o design está claro, os LLMs aceleram de forma explosiva o trabalho de boilerplate
Mas o design em si continua sendo responsabilidade humana
O projeto dele pode ser visto na versão pública no GitHub
Reconheço que o código criado por LLMs é excelente em partes, mas fraco na estrutura geral
Ainda assim, se você entende a base de código e faz revisão direta, dá para compensar isso bem
Vibe coding é ótimo para criar protótipos
Funciona bem pegar o embalo rapidamente e depois refatorar e expandir
Ou seja, o verdadeiro vibe coding seria julgar apenas o resultado final