Apêndice: A borda serrilhada

A L02 do Módulo 1 te deu a régua de revisão por modo. Esta lição mostra onde no seu código a régua precisa subir, e por que isso não é uniforme.

A capacidade do modelo não é uma linha reta

É um padrão que aparece cedo quando você trabalha com o Claude: ele escreve uma migration impecável (uma migration é uma mudança na estrutura do banco de dados, tipo adicionar uma coluna), refatora um módulo inteiro sem quebrar nada, e três minutos depois erra uma conta de centavos que um estagiário pegaria. Não é falta de atenção sua nem do modelo. É a forma da capacidade dele.

Andrej Karpathy chama isso de jagged intelligenceA capacidade do modelo é irregular — excelente num ponto, ruim no ponto vizinho. Ele escreve uma migration impecável e três minutos depois erra uma conta de centavos. Não é falta de atenção; é a forma da capacidade dele. — inteligência serrilhada. A capacidade do modelo sobe e desce de forma irregular entre tarefas vizinhas, em vez de ser uniformemente alta ou baixa. Ele descreve a sensação de trabalhar com o modelo assim (paráfrase atribuída, citação conferida contra a fonte):

Para você que constrói, isso tem uma consequência prática direta: não dá pra revisar tudo com a mesma régua. Revisar cada linha com lupa é lento e te faz desistir da velocidade que o agente oferece. Aceitar tudo de leve cobra o preço no lugar errado. Foi assim que o Karpathy deixou passar um bug no pagamento do MenuGen, o app de cardápio que ele construiu vibe coding e a L02 do Módulo 1 destrincha. A saída está em saber onde o serrilhado tem pico e onde tem vale, e pôr o checkpoint humanoO ponto onde você para e confere antes de seguir. A regra é posicional: ponha o checkpoint na borda serrilhada — revise duro onde o modelo é fraco (zona de perigo), deixe correr onde é forte (zona forte). no vale.

A fraqueza mora nos últimos 20%

Há um padrão em onde o modelo erra. O começo de uma tarefa sai com folga: montar a estrutura, escrever o caminho feliz, gerar o boilerplate. O que escorrega são os últimos 20%: o caso de borda, a recuperação de falha, o que acontece sob escala, a integração nova que ele nunca viu de verdade, qualquer coisa irreversível.

No MenuGen, Karpathy descreve isso direto: ele se sentia "80% done" (80% pronto) quando estava "closer to 20%" (mais perto de 20%). Os 80% fáceis criam a ilusão de que acabou. Os 20% que faltam são onde está o risco, e são justamente os que o modelo é pior em fechar sozinho.

Repara que esses 20% não estão espalhados ao acaso. Eles se concentram em tipos específicos de tarefa. É isso que dá pra mapear.

O mapa do serrilhado pro builder brasileiro

Pega o seu produto (seja um SaaS em Next.js e Postgres, um pipeline de dados em Python, um scraper que alimenta um painel público, um bot, o que for) e separe o que você pede pro Claude em duas zonas. As categorias abaixo usam exemplos de SaaS porque são os mais comuns, mas a divisão vale pra qualquer stack: o que muda é o conteúdo de cada zona, não a ideia de ter duas.

ZONA FORTE  (deixa correr)

- criar/listar/editar/apagar um
registro simples (o CRUD básico)
- código repetitivo seguindo um
padrão que já existe no projeto
- refatorar COM teste verde cobrindo
o comportamento
- caminhos batidos: validar um
formulário, uma consulta simples
ao banco, uma tela de UI
- gerar teste pra código que você
já entende

régua: roda, olha o teste, segue

ZONA DE PERIGO  (revisa duro)

- login, sessão, quem-pode-o-quê
- dinheiro / centavos: cálculo,
cobrança, desconto, imposto
- dado público / sensível: cruzamento
que pode imputar fato errado a uma
pessoa; fonte oficial que mudou
- migration que mexe em dado já salvo
- dois processos escrevendo na mesma
linha ao mesmo tempo; repetir uma
ação sem duplicar efeito
- apagar dado / qualquer coisa que não
dá pra desfazer
- pagamento e dado pessoal (CPF, LGPD)
- lógica fiscal: NFS-e, tributo,
retenção

régua: lê o diff, exige o teste da
borda (Step 2), confere o dado
contra a fonte

O critério que separa as duas zonas, e que vale a pena guardar:

A linha que separa as zonas não é "difícil vs fácil". É quão caro é o erro e quão verificável é o acerto.

Criar um registro simples é zona forte porque o caminho é batido e o erro é barato de pegar (a tela quebra na sua cara). Lógica fiscal é zona de perigoTarefa onde o modelo erra feio e você revisa de perto: login/permissão, dinheiro/centavos, migration com dado salvo, dado público/sensível, deleção, pagamento, LGPD, lógica fiscal. O critério: quão caro é o erro e quão difícil é verificar o acerto. porque o caminho é específico do Brasil, o modelo viu pouco disso no treino, e o erro pode aparecer semanas depois: na declaração de um cliente, num dado que um cidadão lê como verdade, num número que vai pro ar com o seu nome junto.

A regra: o checkpoint humano vai na borda

O gesto que faz você ir rápido sem se queimar é posicional: ponha a sua revisão exatamente onde o serrilhado tem vale, e deixe o modelo correr onde tem pico. A questão não é revisar tudo nem confiar em tudo. É revisar no lugar certo.

O writeup fecha nesse ponto, resumindo o conselho assim: construir checkpoints ao redor do serrilhado, em vez de confiar nos outputs de forma uniforme. Seu trabalho é pegar os momentos de criança antes que eles se acumulem.

Essa régua é a mesma da L02, agora com endereço no código. Na L02 a régua subia conforme o que a tarefa toca (descartável, usuário, dinheiro, dado). Aqui você vê por que: dinheiro e dado caem no vale do serrilhado, porque o modelo é pior justamente onde o erro é mais caro. A régua alta da L02 e o vale do serrilhado são o mesmo lugar visto de dois ângulos.

E conecta direto com a disciplina que você começou na L02 deste módulo (schema e migration), onde você lê o SQL bruto antes de aprovar a migration. Naquela lição a tabela ainda nasce vazia; quando a migration passar a mexer em dado já salvo, é a mesma régua aplicada com mais risco. Esta lição dá o princípio geral por trás dela.

Mapeie o serrilhado antes de precisar dele

Reserve uns 15 minutos pra isso. Listar as zonas é rápido, mas pensar num checkpoint concreto pra cada uma pede um pouco de atenção. É tempo bem gasto: te poupa de descobrir o vale do jeito caro, depois que o erro já foi pro ar.

Cria o arquivo docs/borda-serrilhada.md com duas seções:

## Zonas fortes (deixo correr, régua baixa)
- criar/listar/editar/apagar registro simples, código repetitivo seguindo padrão existente, refatorar com teste verde, caminhos batidos do meu stack

## Zonas de perigo (reviso duro, checkpoint obrigatório)
Lista cada uma com o checkpoint concreto:
- login / sessão / permissão → [meu checkpoint]
- dinheiro/centavos → assertion + teste com número esperado
- mudança no banco que mexe em dado já salvo → leio a mudança antes de aplicar + confirmo backup
- apagar dado / irreversível → [meu checkpoint]
- dado público ou importado → confiro amostra contra a fonte oficial, anoto data/versão do dataset
- [zona específica do meu domínio: NFS-e / regra de edital / cruzamento de dado público] → [meu checkpoint]

Deixa os campos [meu checkpoint] pra eu preencher. Mostra o diff antes de criar.

Takeaways

• A capacidade do modelo é serrilhada: nível de doutorado num canto, erro de criança no canto vizinho. Não é falta de atenção, é a forma dele.
• A fraqueza se concentra nos últimos 20%: borda, recuperação de falha, escala, integração nova, qualquer coisa irreversível.
• Zona forte (deixa correr): registro simples, código repetitivo, refatorar com teste, caminhos batidos. Zona de perigo (revisa duro): login/permissão, dinheiro, migration com dado, dado público/sensível, deleção, pagamento, LGPD, fiscal/NFS-e.
• A regra é posicional: checkpoint humano na borda. Revise onde o modelo é fraco, deixe correr onde é forte. É assim que você vai rápido sem se queimar.

Você terminou quando

Você consegue, diante de uma tarefa nova, dizer se ela cai em zona forte ou zona de perigo e qual checkpoint ela pede — e tem docs/borda-serrilhada.md commitado com as zonas de perigo do seu domínio e o checkpoint concreto de cada uma.