Construí um produto do zero com vibe-coding e essas são minhas impressões

O problema que me fez codar nas horas vagas

Há mais de dez anos iniciei um processo sério de transformação corporal. Com treino de musculação, dieta e mountain bike, cheguei a perder cerca de 30kg em um único ano. Depois de um bom período de dedicação, fui deixando tudo de lado. Os anos de pandemia bagunçaram tanto minha rotina quanto as prioridades e, como aconteceu com muita gente, voltei a ganhar bastante peso.

Recentemente decidi voltar a treinar com mais seriedade e retornar ao que era antes. E com isso voltou também uma vontade antiga: ter um aplicativo que fosse exatamente o que eu precisava. Não menos, não mais. Testei alguns apps de mercado e nenhum se encaixou direito. Alguns focam demais em dieta (alô MyFitnessPal!), outros mais em treino. Entretanto, como são focados para uma audiência ampla, logicamente, deixam a desejar para as minhas necessidades.

Decidi então construir minha própria solução. Assim surgiu a proposta do IronHUD. Como a janela de tempo disponível eram as horas vagas, resolvi usar vibe-coding como método principal. O que começou como projeto pessoal depretensioso do ponto de vista de análise, virou, sem querer, um experimento bastante revelador.

O projeto, a stack e a rotina

O IronHUD é um app para organização de treinos de musculação, gestão de cargas e séries e acompanhamento de dieta. A stack: Python com FastAPI no backend, HTMx no front, CSS via Tailwind e JS via AlpineJS. Pensei na stack que eu usaria caso fosse programar diretamente e esse foi o único critério.

A rotina foi de implementação nas horas que me sobravam no dia — menos de 2 horas por dia, durante o mês de maio, sem dedicação diária. Editei o código manualmente o mínimo possível. Usei diferentes formas de prompt para testar os limites das ferramentas: user stories abertas, sequência de perguntas e respostas para refinamento, implementação de funções específicas, features completas com pouca definição técnica e solicitações de refatoração. A variedade foi intencional para entender como a IA se saia em cada questionamento. E também, claro, porque eu não sabia o que funcionava melhor.

Desde o início pensei em estabelecer guardrails: testes unitários e de integração com cobertura de 90%, gerados pela própria IA, além de algumas especificidades de qualidade de código. As ferramentas usadas foram o Gemini Pro e o Claude Code Pro.

Claude vs. Gemini

Não há uma análise super criteriosa aqui, mas a minha experiência com os dois foi suficientemente diferente para valer o registro.

Qualidade do código. O código gerado pelo Claude era mais eficiente e atendia aos requisitos de forma mais direta. Não tenho dados concretos, mas a sensação é de que o Claude produzia códigos mais robustos. O Gemini tendia a gerar soluções mais prolixas para os mesmos problemas.

Modo de planejamento. O modo de planejamento do Claude fazia perguntas mais relevantes antes de partir para a implementação — as decisões consideravam mais fatores. Isso, ao meu ver, contribuiu para que o resultado gerado fosse mais próximo do que eu esperava.

Decisões de front-end. O Claude priorizava o resultado da interface em vez de simplesmente produzir HTML/CSS/JS minimamente funcional. Código que funciona não é sempre código que resulta em uma boa experiência de uso — e o Claude parecia saber disso.

Reset de cota. Se não me engano, o tempo de reset do Claude é de 4 horas contra 24 horas do Gemini. No fluxo de trabalho em horas vagas, essa diferença é fundamental. No meu caso, aos finais de semana, significava retomar o projeto no mesmo dia ou só no seguinte. Um ponto a salientar, entretanto, é que a janela de contexto do Gemini é expressivamente maior. Mas na minha experiência isso não se demonstrou como uma vantagem.

O que funcionou bem

A velocidade em projetos greenfield é real. Sair do zero para um produto com funcionalidades em poucas horas é uma das vantagens concretas da abordagem. Código boilerplate — configurações, endpoints padronizados, schemas — é produzido em um piscar de olhos. Rápido e sem atrito.

Um ponto que me surpreendeu, mas que talvez não seja novidade: a IA funciona bem para introduzir conceitos e tecnologias que o desenvolvedor ainda não domina. No meu caso, vários recursos do HTMx e do AlpineJS. Em vez de me pegar lendo documentação antes de escrever a primeira linha, conseguia facilmente partir de um código funcionando e aprender enquanto desenvolve. Para quem quer entrar em uma stack nova sem partir do zero, tem valor real.

Quando o projeto cresce

A maior parte das questões que o vibe-coding atualmente levanta não aparece nos primeiros dias ou em algumas linhas de código de refatoração ou correção. Aparece quando o projeto cresce e as sessões de interação ficam mais longas.

Código que cresce sem parar

A tendência das ferramentas é gerar mais e mais código, não menos. Mesmo quando instruída explicitamente a usar bibliotecas padrão, ou criar abstrações para tarefas triviais, a preferência é escrever código novo. Essa tendência piora conforme o contexto da sessão cresce — e o contexto cresce rápido.

O resultado é um volume de código que dificulta progressivamente manter a diligência sobre qualidade, efitividade e eficiência. Mesmo com bastante tempo de experiência na stack utilizada, em determinado momento eu já não tinha controle técnico real sobre os detalhes da implementação. O código existia, funcionava — mas eu não conseguia afirmar com confiança que era bom.

Já explorei em outro artigo como a quantidade de código não equivale à qualidade do software. O vibe-coding torna esse problema mais evidente na prática.

AI não compreende as camadas de abstração?

Foi muito comum ver lógica de negócio sendo implementada nos templates HTML em vez da camada de serviço. Mesmo com instruções explícitas, de varias formas, para respeitar a arquitetura em camadas da aplicação, as violações persistiam — especialmente quando o contexto da sessão se expandia.

O problema é que o código funciona mesmo assim. Os testes passam. A arquitetura vai se deteriorando silenciosamente. Em uma aplicação mais séria do mundo real, esse custo só aparece meses depois. Pessoalmente, esse é um ponto crítico demais para ser negligenciado em produção. E, como falei antes, a quantidade de código gerado dificulta o apropriado controle do que é produzido.

Estou pensando em alguma solução de pipeline onde a AI se auto-regularia para esse controle arquitetural sistêmico. Mas ao mesmo tempo imagino o custo que isso geraria. Não sei se pega.

Cobertura de testes ≠ qualidade de testes

Um dos pontos de "auto-regulação" é estruturar as alterações para serem validadas com testes automatizados, lints e demais validadores. E fazer com que as verificações por si só também evoluam com o tempo. Por exemplo, os testes automatizados. A realidade aponta um ponto incoveniente.

Os 90% de cobertura gerados pela IA soam bem. A qualidade desses testes é outra conversa. O número de cobertura é fácil de atingir sem que os testes de fato protejam o projeto contra regressões relevantes — e o vibe-coding incentiva exatamente isso.

A transferência de overhead

O vibe-coding não reduz o nível de atenção necessário do desenvolvedor — muda o que precisa de atenção. Além do código em si, o desenvolvedor passa a gerenciar o modelo utilizado, o tamanho do contexto da sessão, o nível de esforço de processamento e a eficiência de consumo de tokens. Além de precisar revisar criteriosamente muito mais código. É um overhead que pesa mais do que parece. Quando escrevemos nossos próprios códigos, todo processamento mental da escrita do código, nosso pipeline mental, acontece quase sem percebemos.

Uma analogia que me vem a mente é: ter que revisar código de AI é como se tivéssemos a todo momento ter que trazer dados do sistema de armazenamento permanente (HD, SSD) para nossa memória para então processá-los nos nossos registradores cerebrais. Sabemos como isso é custoso computacionalmente. O mesmo acontece individualmente com os profissionais de desenvolvimento.

Os guardrails são necessários mas insuficientes. O código gerado ignora restrições com facilidade quando o contexto cresce. A diligência, e o overhead, precisa ser constante.

Facilidade para se gastar ineficientemente

Quanto maior o projeto, mais fácil fica consumir tokens de forma ineficiente. Não que a tecnologia seja necessariamente cara — a questão é que a tendência é gastar progressivamente mais para obter o mesmo resultado conforme o contexto acumula. No contexto corporativo, percebo várias negligências sobre isso. Em uma expectativa de que o resultado futuro irá pagar esse custo atual. Preciso dizer, desconfio muito dessa premissa.

No contexto individual, o uso amplo e irrestrito rapidamente se torna impraticável. No contexto corporativo não tenho métricas próprias, mas com times de senioridade variada, é razoável supor que uma parcela considerável do custo não se converte em retorno real de qualidade ou produtividade.

A questão de código boilerplate facilmente gerado

IA gera boilerplate bem. Mas não precisamos de IA para isso. É usar um caminhão que gasta energia demais para mover uma pena do ponto A ao ponto B. Mas o mais importante é: quantos dos projetos do dia a dia são realmente greenfield? A maioria tem anos de código acumulado, decisões já tomadas e débito técnico consolidado.

Se um projeto existente exige muito boilerplate, isso é sinal de déficit arquitetural — de abstrações mal implementadas. O debate sobre produtividade com LLMs de código raramente toca nesse ponto. A IA resolve o sintoma. O problema continua lá.

A lição que fica agora

O IronHUD existe, funciona e está em uso (pelo menos por mim). O experimento valeu. Tenho um app que atende minhas necessidades.

O vibe-coding permite construir coisas reais — mas fora do playground de desenvolvimento, os custos são concretos: código que cresce sem critério, arquitetura que se deteriora, testes que cobrem mas não protegem, e um overhead de gestão que antes não existia.

O desenvolvedor que usa essas ferramentas precisa de muito mais repertório, não menos. Quem não tem esse repertório vai ter dificuldade para perceber quando o código gerado está errado, quando a arquitetura está sendo comprometida ou quando o consumo está saindo do controle.

Se repetisse o experimento, faria com mais cerimônia técnica: sessões menores, contextos mais controlados, revisões arquiteturais mais frequentes. Valeu a pena — e eu repetiria. Mas com outros cuidados.