PLAID e o dia que Claude Code multiplicou os PRs por 4x — o que a equipe fez para não desabar

“O time adotou Claude Code e o número de PRs quadruplicou.” Toda vez que vejo essa frase circulando em post do LinkedIn, minha primeira reação não é ficar impressionado. É perguntar quem passou a revisar 4x mais PR.

A PLAID, empresa listada em bolsa que faz o KARTE, publicou o número inteiro no blog de engenharia: o time Journey, com cerca de 5 pessoas, saiu de ~150 PRs/mês em setembro de 2025 para ~600 PRs/mês em fevereiro de 2026. Quatro vezes mais PRs em ~6 meses. O post não é uma peça de marketing, é um relatório operacional com os arquivos de configuração que sustentaram esse volume (tech.plaid.co.jp/claude-code-scalable-team-operation, 2026-02-18).

O que me chamou atenção nesse caso vai além do próprio “4x”: é a matemática do gargalo humano que a versão ingênua desse número prevê e que, na prática, não aconteceu com 5 engenheiros. Este post é sobre o que eles publicaram para segurar o volume, e o que eu tirei disso para o meu próprio setup, com atribuição correta de quem fez o quê.

Antes e depois na PLAID: quem carrega os 600 PRs/mês quando o time tem ~5 pessoas

O que quebra primeiro quando a IA acelera o time

Antes de olhar o que a PLAID fez, vale ser honesto sobre o que rachou no meu próprio setup quando eu tentei encostar num regime parecido, em escala menor.

O primeiro a ceder não é a geração de código. É a review. Você aumenta o volume de PR aberto, mas a atenção humana de revisar continua a mesma. Aparecem quatro sintomas, nessa ordem:

Regras informais viram debate por PR. “Isso aqui devia ter teste, né?” — comentário manual, toda semana, para pessoas diferentes.
Format/typecheck falham dentro da PR aberta, ocupando espaço mental na review.
Commits diretos em main acontecem “só uma vez” e viram cicatriz.
Consultas de banco em código de produção começam a aparecer em lugares onde não deviam, porque a IA foi ágil demais.

Meu instinto inicial foi trabalhar mais na review. Ler mais rápido, comentar melhor. Isso escalou até o ponto em que passei a evitar abrir os PRs porque sabia que ia demorar. Foi aí que percebi que precisava de camadas antes da minha caixa de entrada.

O que a PLAID publicou, camada por camada

O post da PLAID descreve a configuração do .claude/ do repositório e o que cada peça faz. Vou listar só o que está no post deles, com o nome que eles usam.

Camada 1: bloqueio mecânico (Permission + Hooks)

O settings.json do .claude/ marca read como allow, git push:* como ask (pede confirmação toda vez) e rm -rf como deny. Isso é permission puro, e evita que o agente execute ação irreversível sem que uma pessoa dê um OK explícito antes.

Em cima disso, eles usam Hooks:

PreToolUse bloqueia commit direto em branch protegida e roda secretlint para pegar segredo vazando.
PostToolUse roda formatter (Prettier/gofmt) e typecheck automaticamente após edição.
SessionStart reporta quais CLI ficaram instalados.

O que isso resolve: uma classe inteira de “erros que não deveriam entrar em review” nunca chega no PR. O typecheck já rodou. O rm -rf nunca foi executado. O segredo foi barrado.

Camada 2: workflow padronizado (Skills + Subagents)

Skills que o post cita explicitamente:

/create-pr --wait — cria PR, observa o CI, se falhar tenta corrigir sozinho e responde a comentários de review.
/verify — roda verificação apropriada ao tipo de mudança.
/interviewing-issues — entrevista de 4 etapas para clarificar spec de issue.
/orchestrating-tdd — orquestra Red → Green → Refactor.

Subagents (agentes com escopo limitado):

db-reader — todas as queries de banco passam por ele, com Hooks restringindo o subagente a leitura. Uma classe inteira de bug (write acidental) fica isolada.
code-simplifier — reduz código depois da implementação.

Aqui a lógica muda. Em vez de escrever regra em texto (“por favor, use pnpm —filter em vez de cd”), você transforma a regra em código executável. O AGENTS.md da PLAID de fato contém regras como "pnpm --filter を使用（cd しない）" e "TDD で実装", mas o que faz elas funcionarem é o par com Skills e Hooks — não é o texto sozinho. Já falei do problema de regra que fica só no texto no post AGENTS.md como política única — 47 PRs depois, sistema virou juiz único.

Camada 3: review automatizado (GitHub Actions + claude-code-action)

Quando um PR abre, o GitHub Actions dispara a claude-code-action oficial da Anthropic, que roda uma Skill de review lendo o AGENTS.md do repositório. A primeira leitura do PR é da IA, não do humano. Comentários mecânicos (tipo de retorno inconsistente, teste faltando, formatter escapou) aparecem antes de qualquer humano abrir o diff.

O post não afirma que esse review substitui o humano. Ele diz o oposto: decisão de design continua com humano. O que muda é que o humano recebe um PR já triado.

Camada 4: decisão humana (o que sobra)

Depois das três camadas anteriores, o humano abre o PR para decidir três tipos de coisa:

Direção arquitetural (a abstração escolhida foi a certa?)
Alinhamento com decisões antigas do time
Autorização para fazer o que a IA não tem permissão de fazer sozinha

Nesse regime, review humana não é sobre “achar bug de formatação”. É sobre design. E design escala melhor que caça de bug, porque o custo por decisão é diferente.

E o Git como fonte da verdade

Detalhe pequeno mas importante do post: git é o System of Record. Notion e Slack são usados, mas informação “de verdade” mora no repositório. Isso não é bonito de escrever em um post, mas é o que dá lastro à camada de automação. Um Skill não pode ler Slack. Uma Action não pode citar Notion no comentário do PR. Se a regra vive só no chat, ela deixa de existir na hora que a automação assume.

Onde o meu texto termina e o texto do livro começa (aviso importante)

Estou publicando este post junto com o meu livro de Claude Code em PT-BR, então preciso separar duas coisas para não confundir:

O que a PLAID publicou (acima): os 4 mecanismos, os nomes dos Skills, o db-reader subagent, o par de números (150 → 600 PRs/mês), os exemplos “pnpm —filter” e “TDD”.
O que o livro discute em cima do caso PLAID: um CLAUDE.md de exemplo mais opinativo (uma feature por PR, alvo abaixo de 300 linhas alteradas, título em conventional commits, corpo sempre com Why). Essas regras não estão no post da PLAID. Elas são uma sugestão do livro, inspirada no espírito do que a PLAID mostrou — “regra escrita no CLAUDE.md é regra que o time inteiro segue” — mas não devem ser atribuídas à PLAID.

Fiz questão de deixar isso explícito porque eu já vi (e cometi) o erro de misturar “o que o caso ensina” com “o que o caso diz”. O post da PLAID diz o suficiente sozinho, e o livro amplia o modelo. Cada um no seu lugar.

O que copiar, o que não copiar

Copiei três coisas do setup deles para o meu próprio repositório e todas caíram bem:

git push:* como ask no permission — barato, elimina o “ah, eu não queria ter empurrado isso agora”.
PostToolUse com formatter e typecheck — a IA já sabe quando o próprio código dela quebrou, antes de eu ver.
Um subagent de leitura só para uma classe de operação sensível — no meu caso não é banco, é chamada a API externa paga. Mesma ideia: isolar uma classe de bug em um agente cujo escopo é físico, não textual.

O que não copiei (e você provavelmente não deve copiar cegamente):

O regime de 600 PRs/mês em 5 pessoas. Isso é um perfil de time muito específico: 120 PRs por pessoa por mês, ~6 por dia útil. Só faz sentido se cada PR for pequeno de propósito. Copiar o volume sem copiar o resto da cultura de PR pequeno vai colocar 600 monstros dentro do repositório.
A claude-code-action como primeira review em projeto solo. Se você é o único humano, IA revisando IA sem terceiro par de olhos vira eco. Meu setup solo mantém o humano como primeiro revisor da parte crítica.

O que sobra depois de tudo

Falar “4x mais PRs” como se fosse vitória por si só me parece leitura curta do caso. O que aconteceu ali foi um deslocamento de custo: você tira custo da tela do editor e coloca custo em outro lugar. A pergunta que importa depois de “quanto mais PR meu time produz com Claude Code” é “para onde foi o custo que a IA tirou do teclado”. Se ele foi para um sistema automatizado que segura formatação, teste, permission e primeira leitura, dá para escalar. Se foi para a caixa de entrada do único humano, você aumentou seu problema de review em vez de resolver.

O que a PLAID fez de bem publicado, no meu entendimento, foi resistir à tentação de vender “IA acelerou 4x” como manchete e mostrar, ao lado, a infraestrutura que impediu o 4x de virar backlog. Essa é a parte importante — e é a parte que a maioria dos posts de LinkedIn não conta.

Notes

O post da PLAID vai mais fundo em cada peça (o .claude/settings.json deles, o texto real do AGENTS.md, o design da db-reader). Vale ler direto: tech.plaid.co.jp/claude-code-scalable-team-operation.

Do lado do livro, o capítulo sobre CLAUDE.md como constituição do time monta em cima do modelo — com um exemplo de CLAUDE.md mais opinativo, além dos padrões de Git worktree, 2-Claude Review e critérios de review escritos — em Practical Claude Code (PT-BR) (Kindle, também no Kindle Unlimited).

ken imoto · WebRTC & Voice AI engineer · kenimoto.dev · TabNews