Pedi pro Claude uma correção de lint. Voltou com um CI morto há semanas e um CVE patcheado de brinde — os subprodutos abafaram a tarefa.
No repo do how2claude eu ia fazer um lote pequeno de edições, e o passo prévio era passar o rubocop lint. Tirei um screenshot do CI vermelho no GitHub Actions e mandei pro Claude.
A primeira frase dele:
CI tá quebrado. Vou ver por quê.
Achei que ele ia rodar rubocop, olhar os erros e consertar. Não foi.
Alguns minutos depois ele voltou com isto:
CI já tava quebrado fazia tempo (a run anterior, dia 12 de abril, também falhou). Dois tipos de problema:
Coisas que eu acabei de introduzir: 2 RuboCop violations em arquivos de migration
Coisas que já estavam quebradas:
- O CI não tem postgres service configurado, então test/system-test nem inicia (problema de infra, está assim faz 2 semanas)
- 61 RuboCop violations pré-existentes (em arquivos que não toquei)
Vou começar pelas 2 que eu introduzi.
Vale parar um segundo neste parágrafo.
O que pedi pra ele foi "conserta rubocop." Enquanto checava o histórico do CI, fez uma coisa que eu não tinha pedido — separou "por que está quebrado" em duas caixas: o que foi minha culpa agora vs o que o repo já carregava.
Não pedi essa classificação. Ele fez mesmo assim.
Dos dois baldes, o segundo era o ponto:
db:test:prepare batia em connection refused em toda runNas palavras dele:
A run anterior, dia 12 de abril, também falhou.
CI tava no vermelho fazia três semanas. Eu tava pushando todo dia. Cada push mostrava CI vermelho, mas como costumo commitar direto na master e rodar specs no local, treinei meu olho pra tratar aquele vermelho como ruído de fundo.
Aí, no momento em que pedi pro Claude consertar um lint só, ele puxou o histórico e empurrou "isso não começou com a sua mudança" na minha cara.
Ele resolveu tudo numa passada:
✓ 63 RuboCop violations → 0 (autocorrect de whitespace em 17 arquivos)
✓ MCP gem CVE-2026-33946 → bundle update mcp, 0.9.0 → 0.14.0
✓ test/system-test sem postgres service → adicionado postgres:17 service container
✓ Os 241 testes continuam passando no local
✓ bundler-audit: No vulnerabilities found
Olha a segunda linha. Subiu a versão do mcp gem por conta própria porque viu que a nova consertava um CVE. Eu não pedi. Só viu o warning rodando bundler-audit e trouxe junto.
A terceira linha é o que realmente consertou o CI: postgres:17 como service container no workflow, com health check e DATABASE_URL.
Depois ele perguntou sobre granularidade dos commits:
Dois commits ou um?
chore(lint): rubocop autocorrect (whitespace only)fix(ci): add postgres service + bump mcp gem for CVE-2026-33946Ou um:
fix(ci): make CI green again?
Respondi com uma palavra — commit — significando: vai com os dois separados. Ele pushou.
CI rodou de novo. Pedi pra ele monitorar.
4 verdes, system-test ainda vermelho. Olhando.
Depois de algumas sondagens, voltou com:
test/system/nem existe — esse job rodatest:systemsem um único system test. Vamos só apagar o job.
Fiquei alguns segundos olhando aquela linha.
test/system/ é o diretório default do Rails pra system tests. Nunca escrevi um system test nesse projeto, nem uma vez, desde o dia em que dei init. Mas o ci.yml tinha um job system-test que rodava a cada push e falhava sempre, porque bundle exec rails test:system não achava o diretório.
Esse job não quebrou quando o Claude adicionou postgres. Tava quebrado desde o dia 1 do projeto. Eu achava que com postgres iria pra verde — não, postgres não era o problema. O problema era que o job tinha que ser apagado.
O terceiro commit dele:
e1d91d1 chore(ci): drop system-test job
CI verde.
Olhando em retrospecto:
Se eu fizesse sozinho, faria só a 1 — eu vinha vendo CI vermelho fazia três semanas, o olho tava dormente, ia falar "conserta o lint e bora." Eu tinha treinado o cérebro a tratar aquele vermelho como cenário.
Claude não carrega esse hábito. Não tem memória de "isso sempre foi assim" sobre o repo. Cada vez que olha o CI, olha com olhos novos. É justamente isso que vira vantagem — o que pra mim já tinha virado "quebrado por default há tempo," pra ele é visível.
Quando você passa uma tarefa pequena pro Claude, o subproduto mais valioso normalmente não é a tarefa em si — é o check-up incidental. Se ele te disser "enquanto fazia X também notei que Y e Z estão quebrados há um tempo," não trate como ruído. É o diagnóstico.
Algumas coisinhas que adotei:
Faça-o escanear o entorno antes da tarefa pequena. Que olhe o histórico do CI antes de rodar lint. Que veja quando o schema foi tocado pela última vez antes de escrever uma migration. Que dê um grep na cobertura de testes do controller antes de editá-lo. "Uma olhada antes de começar" custa quase nada e solta um "espera, tem coisa aqui" com frequência.
Quando ele diz "dois tipos de problema" ou "duas classes de causa," é organização que você não pediu. Para e leia esse parágrafo até o fim. Não pula.
Não desvie do vermelho de longa data. Eu vinha falando pra mim mesmo "é um known issue, vejo depois" todo push. "Depois" pode ser daqui a três anos. Deixar o Claude limpar de passagem, já que ele está perto, é bem mais realista do que reservar um dia pra "ir consertar o CI."
Os três commits, mais uma vez:
74a3ebf chore(lint): rubocop autocorrect — Layout cops only
76264ee fix(ci): add postgres service + bump mcp gem for CVE-2026-33946
e1d91d1 chore(ci): drop system-test job
O primeiro é o que pedi. O segundo e o terceiro são os que ele trouxe sozinho. Esses dois valem muito mais do que o primeiro.