Claude Code ajudou a criar uma aplicação Elixir para produção sem código escrito manualmente em quatro meses

O autor descreveu um experimento de quatro meses: uma aplicação Elixir/Phoenix em produção foi construída através do Claude Code sem escrita manual de código. Durante esse tempo, o projeto alcançou 1.702 commits, 3.880 testes e 94,83% de cobertura, mas enfrentou dois incidentes sérios em produção no caminho.

Escala do Projeto

Não se tratava de um demo ou projeto pessoal, mas de um serviço EasyStocksAI para avaliação de mais de 1.000 ações em 15 métricas. A aplicação calcula scores em quatro blocos, mantém portfólios com histórico de transações, compara resultados com estratégias de benchmark e exibe gráficos interativos. O autor também construiu um blog com um parser Markdown customizado que consegue transformar tickers e comandos em links e gráficos embutidos.

O stack também é completamente production-ready: Elixir/Phoenix LiveView, PostgreSQL, Oban, Tailwind e Lightweight Charts.

Pelos números, o projeto se mostrou mais próximo a um produto completo do que a um experimento. A base de código contém 422 mil linhas de código Elixir, mais de 73 mil linhas de testes, mais de 300 módulos, 34 workers Oban e 80 migrações de banco de dados. Os dados são puxados de cinco APIs simultaneamente com fallback em cascata: se uma fonte não responde, o sistema automaticamente muda para a próxima. Tudo rodava em infraestrutura modesta: um VPS na Vultr e PostgreSQL em AWS RDS, enquanto CI/CD foi construído através de GitHub Actions.

Como a Qualidade Foi Mantida

O mecanismo de controle principal foi um arquivo CLAUDE.md que Claude Code lê em cada sessão. O autor o descreve como a constituição do projeto: contém comandos obrigatórios, proibições e regras arquiteturais. Sem tais restrições, AI escreve código funcional mas mal gerenciável; com elas, mantém estilo consistente e não esquece o processo. Cada novo erro virou uma nova regra, então o documento cresceu junto com o produto.

• Após qualquer mudança, mix format e mix credo --strict são obrigatórios
• Nem uma linha de código de produção sem um teste falhando
• Para dados financeiros, float é proibido; apenas Decimal é permitido
• Workers Oban não podem fazer requisições ao banco de dados dentro de loops
• O banco de dados é considerado a fonte de verdade, não o estado dos processos

Além disso, o autor separou papéis dentro do próprio desenvolvimento de AI. Em modo Director, o modelo cuida de arquitetura, ADRs e planos de mudança; em modo Implementor, escreve código estritamente conforme o plano e apenas através de TDD. O ciclo de trabalho é dividido em três fases distintas: brainstorming, planejamento detalhado e execução em pequenos passos de 2–5 minutos. Essa abordagem elimina deriva arquitetural: cada nova sessão de AI lê os ADRs, planos e arquivos de memória e continua o projeto a partir do contexto estabelecido, não do zero.

Onde AI Quebrou Produção

A parte mais valiosa da história não são os números, mas a análise de dois incidentes em produção.

No primeiro caso, workers Oban e requisições web compartilhavam um único pool de 15 conexões com PostgreSQL. Quando um backfill de 923 tarefas foi lançado, a interface efetivamente caiu. O problema foi resolvido com um ObanRepo dedicado com um pool separado para operações internas da fila. Após isso, orçamentos de query obrigatórios para cada worker e limites de concorrência de fila foram adicionados às regras.

A segunda falha foi ainda mais instrutiva. AI adicionou um ConnectionWatchdog para monitorar a saúde do pool e evitar repetir o primeiro incidente. Mas o monitoramento em si se tornou a causa da próxima falha: sob carga, requisições com timeouts agressivos começaram a matar conexões, e o watchdog derrubou todo o pool Oban em segundos. No final, o componente foi simplesmente removido, e a lição foi registrada na memória do projeto.

"Nunca use pooled connections com timeouts agressivos para monitoramento"

Separadamente, o autor construiu um MCP Debug Server na aplicação para que Claude Code pudesse se conectar à produção como uma ferramenta: ler logs, verificar filas Oban, executar queries SQL, verificar métricas e reiniciar workers sem SSH e debugging manual. Mas mesmo aqui há limites: o acesso é restrito a uma whitelist de ações para que a depuração não se torne um buraco de segurança.

A conclusão principal do autor é simples: AI pode perfeitamente bem manter produção real, dados regras, memória, postmortems e limites de acesso claros.

O Que Isso Significa

Esta história mostra que desenvolvimento com AI já pode alcançar nível de produção, mas não por si só. O papel-chave não é desempenhado pelo modelo, mas pela disciplina ao seu redor: TDD, decisões arquiteturais, arquivos de memória, postmortems e guardrails rígidos. Se um humano permanece como o arquiteto e editor do processo, AI verdadeiramente acelera a entrega sem necessariamente sacrificar qualidade.