Claude Code ajudou a construir em quatro meses um app de produção em Elixir sem nenhuma linha de código escrita à mão

O autor descreveu um experimento de quatro meses: um aplicativo de produção em Elixir/Phoenix foi construído com o Claude Code, sem escrita manual de código. Nesse período, o projeto chegou a 1 702 commits, 3 880 testes e 94,83% de cobertura, e enfrentou dois incidentes sérios em produção no caminho.

Escala do projeto

O projeto passa longe de demo ou projeto pessoal. Trata-se do EasyStocksAI, serviço que avalia mais de 1 000 ações com base em 15 métricas. O aplicativo calcula um score em quatro blocos, gerencia carteiras com histórico de operações, compara resultados com estratégias de benchmark e exibe gráficos interativos. O autor também criou um blog com um parser de Markdown próprio, que transforma tickers e comandos em links e gráficos incorporados. A stack também é de produção: Elixir/Phoenix LiveView, PostgreSQL, Oban, Tailwind e Lightweight Charts.

Pelos números, o projeto está mais próximo de um produto completo do que de um experimento. A base de código soma 422 mil linhas de Elixir, mais de 73 mil linhas de testes, mais de 300 módulos, 34 workers do Oban e 80 migrations de banco. Os dados vêm de cinco APIs ao mesmo tempo, com fallback em cascata: se uma fonte não responde, o sistema passa automaticamente para a seguinte. Tudo rodava em uma infraestrutura modesta: uma VPS na Vultr e PostgreSQL no AWS RDS, com CI/CD montado no GitHub Actions.

Como a qualidade foi mantida

O principal mecanismo de controle foi o arquivo CLAUDE.md, que o Claude Code lê a cada sessão. O autor o descreve como a constituição do projeto: ali ficam os comandos obrigatórios, as proibições e as regras de arquitetura. Sem essas restrições, a IA escreve código que funciona, mas é difícil de gerenciar; com elas, mantém um estilo único e não esquece o processo. Cada novo erro virava uma nova regra, e o documento cresceu junto com o produto.

• Após qualquer alteração, mix format e mix credo --strict são obrigatórios
• Nenhuma linha de código de produção sem um teste falhando
• Para dados financeiros, float é proibido; só Decimal
• Nos workers do Oban, é proibido fazer consultas ao banco dentro de loops
• O banco de dados é a principal fonte da verdade, e não o estado dos processos

Além disso, o autor separou papéis dentro do próprio desenvolvimento com IA. No modo Director, o modelo cuida da arquitetura, dos ADRs e do plano de mudanças; no modo Implementor, escreve o código estritamente conforme esse plano e somente via TDD. O ciclo de trabalho é dividido em três fases distintas: brainstorming, plano detalhado e execução em pequenos passos de 2–5 minutos. Essa abordagem elimina o desvio arquitetural: uma nova sessão da IA lê os ADRs, os planos e os arquivos de memória e retoma o projeto a partir do contexto já registrado, sem começar do zero.

Onde a IA derrubou a produção

A parte mais útil da história está na análise de dois incidentes em produção, mais do que nos números. No primeiro caso, os workers do Oban e as requisições web compartilhavam um único pool de 15 conexões com o PostgreSQL. Quando um backfill de 923 tarefas foi disparado, a interface praticamente caiu. O problema foi resolvido com um ObanRepo dedicado, com pool separado para as operações internas da fila. Depois disso, as regras passaram a exigir um query budget obrigatório para cada worker e limites de concorrência nas filas.

A segunda falha foi ainda mais reveladora. A IA adicionou um ConnectionWatchdog para monitorar a saúde do pool e evitar a repetição do primeiro incidente. Só que o próprio monitoramento causou a queda seguinte: sob carga, consultas com timeout agressivo começaram a matar conexões, e o watchdog derrubou todo o pool do Oban em questão de segundos. No fim, 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»

O autor também integrou ao aplicativo um MCP Debug Server, para que o Claude Code pudesse se conectar à produção como uma ferramenta: ler logs, inspecionar filas do Oban, executar consultas SQL, verificar métricas e reiniciar workers sem SSH e sem depuração manual. Mesmo aqui há limites: o acesso é permitido apenas a uma lista branca de ações, para que a depuração não vire uma brecha de segurança. A conclusão do autor é simples: a IA pode, sim, sustentar uma produção real, desde que tenha regras, memória, postmortems e limites de acesso claros.

O que isso significa

O caso mostra que o desenvolvimento com IA já consegue alcançar o nível de produção, mas não por conta própria. O papel decisivo cabe menos ao modelo e mais à disciplina em torno dele: TDD, decisões de arquitetura, arquivos de memória, postmortems e guardrails rígidos. Se o humano continua como arquiteto e editor do processo, a IA de fato acelera as entregas sem que a qualidade necessariamente caia.