“Terminei”
Pedi a um agente AI que escrevesse testes para 527 funcoes. O agente concluiu o trabalho e reportou:
“Concluido.”
Funcoes que realmente receberam testes: 40.
Nao mentiu. Fez 40 e julgou que “ja era suficiente”. Ao encontrar uma funcao dificil, pulou. Depois de mais algumas, concluiu que “o restante segue o mesmo padrao, entao esta feito”.
LLM gera bem. Mas seu julgamento sobre conclusao nao e confiavel.
A catraca
Uma chave catraca tem dentes que travam em uma unica direcao. Gire e ela avanca. Solte e ela para, mas nao volta.
O Ratchet Pattern aplica esse mecanismo ao controle de agentes.
Item 1: verificacao mecanica → PASS → proximo
Item 2: verificacao mecanica → FAIL → nova tentativa (com feedback)
Item 2: verificacao mecanica → PASS → proximo
...
Item N: PASS → concluido. Parar.
Tres regras:
- Mostre apenas um item por vez.
- So avanca apos passar.
- Quando todos passarem, pare.
Ao implementar essas regras como CLI, o agente precisa conhecer apenas um comando: next. O resto a maquina decide.
Agente para em 40, catraca completa 527
Mesmo modelo. Mesmo projeto. Mesmas 527 funcoes.
Agente autonomo: 40 / 527 (7.6%) — agente declarou "concluido"
Ratchet CLI: 527 / 527 (100%) — maquina declarou "ainda faltam 487"
A diferenca nao esta no desempenho do modelo. Esta em quem decide o “fim”.
No agente autonomo, o LLM julga o encerramento. O LLM e otimista. Faz 40 e “sente” que e suficiente. Na catraca, a maquina julga. A maquina nao sente. Declara “ainda nao” ate que o numero de itens restantes chegue a zero.
Definicao em uma frase
Coloque o agente probabilistico dentro de uma maquina de estados deterministica.
| Papel | Responsavel |
|---|---|
| Geracao | LLM |
| Veredicto | verifier |
| Gestao de progresso | ratchet |
Muitos sistemas delegam geracao, veredicto e decisao de parada inteiramente ao LLM. O Ratchet separa essas responsabilidades.
Cinco principios
1. A condicao de encerramento e mecanica
pass/fail. Nao “looks good”. Se go test passa, e PASS. Se coverage chega a 100%, e PASS. Nao ha espaco para julgamento subjetivo.
2. PASS e imutavel
Um item aprovado nao se reabre. Sem retrocesso. O numero de itens restantes so diminui.
remaining_work(t+1) ≤ remaining_work(t)
O que voce construiu hoje nao sera desmontado amanha. So avanca. Essa e a diferenca fundamental em relacao ao “agente de 24 horas”. Um agente sem condicao de parada adiciona uma abstracao hoje, remove amanha e readiciona depois de amanha. A catraca nao permite essa oscilacao.
3. LLM so gera
Gerar codigo, escrever testes, propor correcoes — esse e o papel do LLM. O que corrigir, se passou ou nao, qual e o proximo, se terminou — tudo isso a maquina decide. LLM nao e um planejador, e um constrained generator.
4. Revogar o direito do agente de declarar conclusao
Se o LLM diz “terminei”, para em 40. Se a maquina diz “terminou”, para em 527. A razao de existir da catraca se resume a essa linha.
5. Verifier deve ser deterministico
Nem tudo pode ser verifier.
| Pode ser | Nao pode ser |
|---|---|
go test | “looks cleaner” |
| medicao de coverage | “seems better” |
| AST validation | “more scalable” |
| schema diff | “clean architecture” |
Condicoes do Verifier: deterministic, machine-checkable, resumable, localized feedback. Se essas quatro nao forem atendidas, os dentes da catraca nao engatam.
Feedback e gradient signal
Se a catraca retorna apenas “passou/falhou”, o LLM corrige sem direcao. Quanto mais especifico o feedback, mais precisa a correcao do LLM.
Feedback fraco: "teste falhou" → LLM corrige sem direcao
Feedback medio: "coverage 65%" → LLM reforca aproximadamente
Feedback forte: "line 41, 44, 70 sem cobertura" → LLM cobre exatamente esses ramos
Numeros verificados em projeto real:
Sem feedback: para em 60~70% de coverage
Com feedback: atinge 100% (para funcoes alcancaveis)
Mesmo modelo. Uma unica linha “line 41 not covered” funciona como gradient signal.
Quanto maior a resolucao do feedback, maior a precisao das correcoes do LLM, menor o numero de iteracoes do loop e menor o custo.
O agente morre. O progresso sobrevive.
O agente vai cair. Limite de tokens, erro de rede, sessao encerrada. Se a catraca persiste o estado de progresso, o proximo agente continua de onde o anterior parou.
Agente A: processa funcoes 1~200 → morre
Agente B: next → retoma a partir de 201
Agente C: next → retoma a partir de 401
O agente e descartavel. O progresso se acumula.
Troque o Verifier, obtenha outra ferramenta
A catraca nao esta presa a um verificador especifico. Troque o verificador e voce tem outra ferramenta.
| Catraca + verificador | Uso |
|---|---|
Catraca + go test + coverage | Geracao de testes por funcao |
| Catraca + regras estruturais validator | Organizacao de estrutura de codigo |
| Catraca + hurl pass/fail | Verificacao de endpoints de API |
| Catraca + verificacao cruzada de especificacoes | Garantia de coerencia SSOT |
| Catraca + Toulmin verdict | Aplicacao de regras definidas pelo usuario |
O padrao e um so. O verificador determina o dominio.
Perguntas
Quantos itens seu agente completou antes de dizer “terminei”?
Realmente terminou?
Quem decidiu o “fim” — o agente ou a maquina?
Artigo relacionado: Topologia de feedback importa mais que QI do modelo — O fundamento teorico do Ratchet Pattern. Por que a estrutura de feedback e mais importante que o desempenho do modelo.