[GN] Não desenvolvedor + Claude em produção por 238 dias — o que funcionou e o que não funcionou?

(chajooin.com)

7 pontos por workdriver 2026-04-12 | 5 comentários | Compartilhar no WhatsApp

Sou o operador que criou o chajooin.com. Ensino médio completo, 8 anos com caminhões de carga (2017~). Sem saber escrever uma única linha de código, fiz meu primeiro commit com o Claude em 16 de agosto de 2025. Já se passaram 238 dias, e hoje este serviço coleta dados automaticamente todos os dias e publica relatórios.

Este texto não é sobre “eu criei”, e sim um registro de “eu criei e estou operando”. Há muitos relatos de protótipos feitos com vibe coding, mas experiências de continuar operando em produção ainda são raras, então resolvi escrever. Não é um caso de sucesso, e sim um registro honesto do que funcionou e do que não funcionou.

Contexto

Domínio: comparação de preços de caminhões de carga (mercado de 17 trilhões de won, sem registro oficial de preços reais de transação)
Tentativa anterior: em 2024, terceirização turnkey por 30 milhões de won → desisti porque o controle das mudanças ficava com a empresa terceirizada
Virada: 2 meses estudando IA em julho de 2025 → primeiro commit em 16 de agosto

Stack

Frontend    Vite + React + TypeScript + Tailwind  
Backend     Node.js + Express + Prisma  
DB          PostgreSQL (Railway managed)  
Coleta      Playwright (headless) + 46 parsers por fonte  
ML          LightGBM (Python, 75 features)  
Deploy      Railway (Docker)  
Automação   Node scheduler + alertas no Telegram  
Colaboração com IA  Claude (desenvolvimento principal) + GPT-4o (roteiros curtos/prompts)  
Autenticação Naver/Kakao OAuth

Não fui eu que “escolhi” essa stack. Perguntei à IA “o que eu preciso usar para fazer isso?” e apenas segui a resposta. Depois percebi que era uma combinação razoável. Esse é o valor prático de agentes de IA — eles assumem a carga cognitiva da escolha.

Números (2025-08-16 ~ 2026-04-12)

Item	Valor
Total de commits	3.493
Dias com commit	189 dias
Número de arquivos de código	cerca de 1.500 (base js/ts/py)
Rollbacks	mais de 20
Falhas de deploy	39 vezes (2 dias no setup inicial da Railway)
Máximo de repetições do mesmo bug	7 vezes (unidade de preço)
Anúncios ativos	cerca de 48.000 veículos
Parsers de fontes externas	46
CLAUDE.md	187 linhas, 24 regras absolutas
Arquivos de memória	129

Parte 1. Construção — 3 coisas que fizeram funcionar

1.1 CLAUDE.md — controlar a IA com regras

Se o mesmo bug acontece duas vezes, dizer “tome cuidado” não significa nada. Eu escrevo regras concretas em um arquivo e faço a IA ler isso no início de toda sessão.

"parser=fonte → normalização=÷10.000 → DB=dez mil won. Proibido ×10.000 no valor do DB"  
"Se a extração do ano no parser falhar, proibido preencher com getFullYear()"  
"Proibido adicionar kakaotalk ao UA rewrite do vercel.json"  
"Valor de setInterval exige clamp com Math.min(value, 2^31-1)"

Hoje são 24 regras. Todas surgiram depois de incidentes reais.

1.2 Separação de papéis — planejamento/julgamento é humano, implementação é da IA

Mesmo sem conseguir ler código, eu consigo julgar o resultado. Se um Porter de 2 toneladas aparece por 5 milhões de won, eu consigo dizer “isso está errado”; se wingbody e cargo aparecem com o mesmo preço, consigo dizer “separe isso”. A sensibilidade de domínio faz o papel de teste.

1.3 Arquivos de memória — manter contexto entre sessões

Acumulo decisões/falhas/políticas em 129 arquivos de memória. Quando uma nova sessão começa, a IA lê as memórias relevantes e mantém decisões passadas. É uma estrutura que compensa a limitação da janela de contexto da IA com o sistema de arquivos.

Parte 2. Operação — problemas diferentes de simplesmente construir

2.1 Coisas que estão rodando automaticamente

Ingestão de anúncios: o scheduler coleta dados de fontes externas → passa por quality gate → reflete no DB
Relatórios de preços de mercado: geração automática diária → publicação automática em blog/café
Geração de roteiros curtos: por faixa de tonelagem, o GPT-4o gera roteiro/prompt para Sora (a composição do vídeo é uma etapa separada)
Retreinamento de ML: 1 vez por semana, o motor de preços é retreinado com novos dados
Monitoramento: alertas no Telegram quando há anomalias no pipeline

O desenvolvedor sou só eu.

2.2 Custos

Infraestrutura: Railway (PostgreSQL + Node + Playwright)
API de IA: assinatura do Claude (para desenvolvimento) + API do GPT-4o (para geração de shorts, com estimativa de cerca de US$ 1/mês com base em api_usage_log)
Domínio/OAuth: Naver/Kakao

2.3 Registro de resposta a incidentes

1.138 casos de contaminação de dados (02/03): bug de fallback do ano descoberto → patch no DB + pipeline de reprocessamento + regra adicionada
Alertas no Slack sem funcionar por 6 meses (descoberto em 18/03): problema de variável de ambiente/caminho → reestruturação consolidando tudo em um único fluxo no Telegram
Overflow de 32 bits no setInterval (10/04): login travado → hotfix + regra de clamp adicionada
Tela em branco no KakaoTalk (31/01): o UA rewrite de SEO também estava pegando o navegador embutido do KakaoTalk → correção na lista de UAs

2.4 Trecho das regras de operação

O CLAUDE.md também inclui regras do ponto de vista operacional.

"Depois do deploy, reportar com 3 números: estado do servidor (health 200),  
 quantidade de crawls de hoje (dentro de ±20% de ontem), número de anúncios ativos (sem variação brusca)"  
  
"Se houver modificação em 4 arquivos ou mais, conexão com scheduler, alteração no schema do DB,  
 ou nova alteração em uma área que já teve revert antes → relatório prévio obrigatório"  
  
"Mudanças temporárias (fallback/TODO/hardcoding) devem ser registradas no controle:  
 o que precisa ser revertido e até quando, e o que quebra se isso não for revertido"

A IA lê essas regras sempre, e quando uma dessas situações aparece, ela primeiro reporta antes de trabalhar.

Parte 3. O que não funcionou

3.1 O mesmo bug repetido 7 vezes — não enxerga o caminho inteiro dos dados

O motivo de o bug de unidade de preço ter acontecido 7 vezes: se você corrige só um ponto nas 6 etapas coleta → parser → normalização → DB → API → UI, ele volta a aparecer por outro caminho. A capacidade de “ver o todo” é o que mais falta na combinação não desenvolvedor + IA. A IA corrige apenas onde foi mandada, e a pessoa nem sabe que existem outros caminhos.

3.2 1.138 casos de contaminação de dados — os padrões “gentis” da IA

Quando o parser falhava ao extrair o ano, entrou código que retornava getFullYear(). Do ponto de vista da IA, provavelmente foi o julgamento de que “o ano atual é melhor do que null”. Resultado: um Porter 2003 foi gravado no DB como modelo 2026. Se você não escrever explicitamente para a IA “se não souber, use null”, ela vai preencher com alguma coisa.

3.3 Alertas no Slack sem funcionar por 6 meses — o sistema de monitoramento não era monitorado

O envio de alertas terminava em falha, e a própria falha não ficava registrada em log, então isso ficou silencioso por 6 meses. Nesse período houve alguns problemas no pipeline, mas eu achei que “não havia problema”. Em sistemas feitos com IA, o estado mais perigoso é quando “parece que está tudo funcionando”. Hoje simplifiquei tudo para um fluxo único no Telegram.

3.4 Overflow de 32 bits no setInterval — armadilha da linguagem

Se você não souber que setInterval aceita apenas int32, não vai saber que, ao colocar 30 dias em milissegundos, ele executa imediatamente. Resultado: login travado. A IA não avisa espontaneamente sobre edge cases como esse. A regra de clamp só surgiu depois que deu problema.

3.5 Overfitting no ML — MAPE de treino 8,56% vs produção 42%

Com LightGBM e 75 features, alcancei um MAPE de treino de 8,56% e pensei “pronto, funcionou”. Em produção: 42%. Motivo: limitações estruturais dos dados de preço pedido (ausência de preço real de transação, contratos subdeclarados, margem de revendedor). Um especialista de domínio saberia disso desde o começo, mas eu fiquei preso à ideia de que “se o resultado do treino é bom, então está bom”.

Reflexões finais

Olhando para trás nesses 238 dias:

A IA acelera muito a velocidade de implementação. Mesmo quem não sabe código consegue criar um serviço funcional.
Mas a qualidade operacional não vem automaticamente junto. Incidentes acontecem sem exceção, e a IA não avisa por conta própria.
O trabalho do não desenvolvedor deixa de ser escrever código e passa a ser desenhar regras, monitoramento e validação. Julgar resultados e prevenir recorrência vira o trabalho principal.

É uma produção operada sozinho, então a amostra é n=1. Não vou generalizar. Tenho curiosidade sobre a experiência de outras pessoas nas mesmas condições.

Links

Serviço: https://chajooin.com (comparação e análise de preços de caminhões de carga)

Feedback é bem-vindo. Principalmente, tenho curiosidade sobre como vocês monitoram sozinhos o estado em que “parece que está tudo funcionando”.

5 comentários

savvykang 2026-04-13

Acho que o problema de um estado que parece estar funcionando bem pode ser mitigado até certo ponto com treinamentos periódicos de recuperação de falhas e definindo quais características dos dados são consideradas normais.

workdriver 2026-04-13

Sim, obrigado pela boa observação.
É verdade que, à medida que o sistema cresce, fica difícil gerenciá-lo.