Até onde dá para desenvolver com vibe coding?
(github.com/delos-cresco)Este é um retrospecto focado mais nos aspectos técnicos e de implementação do que no produto em si.
São opiniões totalmente pessoais.
Por favor, levem em conta que este foi um projeto desenvolvido enquanto eu aprendia, durante o último ano da faculdade!
Por que comecei este projeto
- Desenvolver um produto com a mentalidade de criar uma startup, sob a ótica de PM/PO
- Avaliar se era realmente possível desenvolver um MVP full stack com Claude Code
- Resolver o problema de descobrir ativos para investimento em ações
- Adotar ativamente produtos comerciais e extrair insights do processo
Linha do tempo do projeto e informações adicionais
- Planejamento + desenvolvimento: 1 mês
- Deploy: 1 semana
- Operação: 2 meses
- Investimento
- Claude Code: 100 USD
- Conta de desenvolvedor Apple: 100 USD
- AWS: cerca de 220 USD
- Managed DB: cerca de 300 USD
- Free tier: Datadog, Langfuse, Posthog
- Anúncios: 40 mil won
- Total: cerca de 1 milhão de won (do meu bolso..)
Processo de desenvolvimento
Frontend
- Definição de design tokens
- Implementação de 3 páginas principais no Figma
- Aplicação dos design tokens no Expo e implementação usando Figma MCP
- Tentei usar Expo MCP, mas como não era estável, fui depurando diretamente ao observar os resultados
- Geração de novas páginas sem wireframe no Figma com prompts como “use design tokens e aproveite o conceito visual de outras páginas…”
Backend
- Solicitei o desenvolvimento da API com base nos requisitos
- Também pedi que os endpoints necessários fossem criados com base nos requisitos do frontend
- Por usar uma stack genérica com Django, foi possível desenvolver com Claude Code sem gargalos na implementação em si
AI
- Defini a arquitetura de múltiplos agentes e pedi a implementação com base nela
- Para acompanhar as especificações mais recentes de LangChain e LLMOps, anexei links da web para referência
- Os prompts do serviço de LLM foram gerados pelo próprio LLM e utilizados depois
Observability
- Estrutura inicial baseada em ClickStack e posterior migração para Datadog
- Aplicação de logging e analytics após o desenvolvimento de todo o sistema
Infra
- No começo tentei usar Pulumi, mas como o Claude Code não lidava bem com isso, acabei escrevendo arquivos de deploy com scripts baseados em AWS CLI
- Por questões de custo, não implementei CI/CD nem Dev Server
Lista de tecnologias adotadas
- Serviço: assinatura/pagamento, login social, modo escuro
- Dados: coleta de dados via API, CDC, ETL
- AI: múltiplos agentes, Text-to-SQL, Agentic RAG, streaming com SSE, gerenciamento de sessão, Retry, Rate Limit
- LLMOps: teste A/B, Cloud Based Prompt Management (OTA Update), Synthetic Dataset, Evaluation
Insights
Implementação
- Com o plano de 100 USD do Claude Code por cerca de 1 mês, consegui criar sozinho um produto desse porte
- Implementei a UI apenas definindo o padrão de design tokens; se eu também tivesse implementado um design system e incorporado isso ao Claude.md, provavelmente daria para desenvolver um frontend mais rápido e mais estável
- A importância do design system. Ele aumenta muito a produtividade no frontend. Em vez de criar no Figma, implementar primeiro e ajustar depois é mais rápido. Na prática, existem páginas implementadas que nem estão no Figma.
- Definição de casos excepcionais. Isso é ainda mais importante em apps mobile e sistemas de AI. É preciso planejar e implementar casos que fogem do happy path, como gerenciamento de timeout do sistema inteiro, políticas de background, recuperação de streaming e erros simples. Há casos em que o Claude Code implementa o tratamento de erros por conta própria, mas não resolve isso de forma elegante e integrada entre frontend e backend. Por isso, é preciso pedir explicitamente ao Claude Code que trate esses pontos.
- Refatoração em larga escala é proibida. No início, coloquei todo o código React e CSS em um único arquivo no frontend, e depois tentei refatorar para separar isso. No fim, fracassei. A separação aconteceu, mas a UI ficou diferente da original, e tive que seguir um processo de separação gradual. Parece importante pensar na arquitetura do código desde o começo e, ao usar componentes, incluir essas diretrizes no prompt para que isso seja bem aproveitado.
- Uso de Claude.md. Depois de desenvolver uma funcionalidade, eu pedia ao Claude Code que adicionasse ao Claude.md os pontos que valia a pena guardar com base naquele conteúdo. Como o arquivo foi crescendo, depois passei a pedir que mantivesse só o que era realmente necessário e removesse o resto. Usei README e claude.md de forma adequada para ajustar o contexto do LLM. (na época em que ainda não existiam skills)
- Não usei subagentes. Como ele já construía bem sem isso, acabei não usando. Simplesmente usava o modo Plan até o planejamento de desenvolvimento ficar suficientemente concreto e, quando bastava, deixava o Agent desenvolver de forma autônoma.
- É melhor definir e informar pacotes e tecnologias com antecedência. É preciso trabalhar especificando com precisão no Claude.md, no README ou em alguma spec, para evitar código duplicado ou situações em que outra stack seja usada. (Skills?)
Sistema de AI
- ReAct é lento. A UX fica péssima. Mesmo estruturando a execução paralela de múltiplos agentes, ainda assim ficou lento demais.
- UX. Para lidar com respostas lentas, introduzi uma UX que mostra as etapas dos múltiplos agentes, streaming, animações e renderização dinâmica de Markdown. Mas se a resposta leva 1 minuto, qual é o sentido disso?... (app B2C)
- Gerenciamento de prompts e schemas de ferramentas na nuvem. O bom é que dá para aplicar em ambiente online. Agora considero isso indispensável, e eu amo o Langfuse.
- Em Text-to-SQL, é preciso colocar o schema no prompt. Isso consome contexto demais. Acho que dá para resolver com fine-tuning ou RAG.
- Avaliação e iteração. Montei um Synthetic Dataset por persona de usuário e avaliei com LLM-as-a-Judge. Queria automatizar isso, mas de novo, para fazer tudo sozinho, faltam recursos de desenvolvimento.
- Métricas e rubricas de avaliação: é mais complicado do que parece. Acho que métricas genéricas são coisas como DAU e MAU. Mas com esse tipo de métrica não dá para extrair insights. É preciso definir métricas caso a caso para distinguir exemplos de baixa qualidade, resolvê-los e iterar em cima disso. No fim, é necessário um sistema que ajude a criar boas métricas customizadas. (e em multi-turn?..)
- Os tiers da OpenAI são mais apertados do que eu imaginava. Em tiers baixos, não dá para usar bons modelos em produção.
Infraestrutura
- AWS é caro, Managed DB é caro. É bom, mas me arrependo
- Clickhouse é muito caro, mas é bom. Como usei managed, foi conveniente. Principalmente por já incluir CDC de uma vez. (de que adianta ser rápido se o LLM é lento)
- Qdrant e Redis Cloud também não são ruins. Levam pouco tempo para implantar e o custo também é baixo.
- Datadog. É muito bom. Só que deve ficar caro, então usei apenas o free tier. Principalmente a função que separa e avisa sobre erros ocorridos é excelente. Usei o agente no ECS como sidecar.
Serviço
- Pagamento e assinatura. Pensei em usar Toss Pay, mas não usei. Primeiro porque exige taxa anual, e também porque não há documentação para React Native, então o SDK deixa a desejar. Foi uma grande decepção. No fim, escolhi Nice Payments. Não há taxa anual e existe servidor de desenvolvimento, então foi possível desenvolver sem grandes problemas.
- Pagamento Apple. Usei Nice Payments, mas há um problema. As políticas de pagamento da Apple são complicadas. Durante o desenvolvimento para iOS, houve questões ligadas às políticas da Apple e foi necessário resolver isso com vários documentos e soluções de UI. Acho que, no fim, usar simplesmente o sistema interno de pagamento da própria Apple seria mais tranquilo.
- Pagamento e assinatura (cobrança automática) são coisas diferentes. Para implementar cobrança automática, é necessária uma infraestrutura de agendamento, e também é preciso se preocupar com a segurança para armazenar card keys. No fim, consegui implementar, mas foi mais complicado do que eu esperava. Isso me fez querer experimentar Stripe.
- Notificações push. Dá para montar isso com facilidade no Expo. No fim das contas, é preciso ter um backoffice para disparar mensagens, mas considero isso uma funcionalidade essencial.
Reflexões
- A importância de padrões de design de software e arquitetura deve aumentar.
- Espero que cresça o interesse das pessoas em usar agentes de código para criar resultados que vão além de toy projects.
- Vamos evitar overengineering. Mas, para conseguir emprego, não precisa conhecer também coisas overengineered? Da próxima vez talvez seja melhor resolver tudo com
docker-composeem uma única instância… (com Supabase?) - A era do empreendedorismo solo está quase chegando. Mas acho que ganhar dinheiro e construir algo são coisas separadas.
- Fazer tudo sozinho não é divertido
- O Linear também é uma boa alternativa ao Jira. Como foi minha primeira vez usando, ainda não sei bem como visualizar agrupando conforme a hierarquia dos tickets.
Resultado
- O projeto foi encerrado porque eu não consegui arcar com os custos do servidor.
- Saldo -100
Referência
Há conteúdo adicional a partir da página 4.
8 comentários
Saldo -100
kkk
Obrigado por compartilhar um conteúdo tão bom.
Deve ser uma experiência que vale mais de um milhão de won. Pelo que me lembro, eu também não tinha muita experiência com projetos no quarto ano da faculdade. É realmente impressionante ver que conseguiu implementar isso tudo usando IA.
É muito divertido ver esse compartilhamento de experiências. Li com muito interesse. E acabei descobrindo que você é até mesmo um veterano da minha alma mater, nossa. Hoje em dia, os alunos do quarto ano também encaram desafios assim? Sério, é incrível.
Provavelmente foi algo superengenheirado para fins de aprendizado, mas o custo é lamentável demais.
Muito caprichado.
Hoje em dia, a qualidade dos portfólios dos universitários é impressionante. Quando me formei, há 20 anos, acho que me graduei sem realmente saber quase nada, então isso é admirável.
A IA elevou muito o nível médio de todo mundo.
Agora parece até que o certo é simplesmente contratar um dev gente boa mesmo kkk