🔁 The continuous cycle

Everything you learned in the first three tracks fits into a five-step cycle that repeats. It doesn’t end: each round produces a smaller configuration than the last, and each new model restarts the cycle. The point of the module isn’t to do the audit once — is setting up the mechanism that gets you to do it again six months from now, without relying on motivation or a crisis.

What to look at: the dotted cyan line is the only edge that closes the loop—without it, you’ve done a cleanup, not installed a cycle. And notice the emphasis on node 4: that’s where most people fail, because returning an instruction after the first failure seems careful, but in practice it’s how the configuration starts to bloat again. The entire discipline of the course lives in this box.

The six-month schedule is the floor, not the ceiling. There are signs that say “audit now, don’t wait for the date” — and almost all of them are easy to observe: a number that crossed a threshold, behavior that became unpredictable, or something someone said to you. The table below connects each trigger to the scope that it asks for: not every signal calls for auditing everything.

Boris keeps coming back to the same topic: working with a model has become empirical, not theoretical. You don’t infer what the model needs from principles — you test, observe where it struggles, and adjust based on what saw. This means letting go of two kinds of baggage: what you learned about how earlier models behaved, and assumptions from computer science theory about what “should” be difficult.

The third requirement is the most uncomfortable: stay willing to retest ideas that failed in the past, because the reason they failed may have disappeared. Boris describes overengineering as a failure mode recurring — and unlearning this habit as a real journey for experienced builders. The more years of engineering experience you have, the stronger the reflex to specify everything, and the more work it takes to undo it.

Boris has said publicly that programming is solved — and added the caveat that tends to disappear from the quote: solved for the kind of programming it does, not for everyone. The caveat matters to you for a practical reason: in areas where the model still struggles, the remedy isn’t to write a longer instruction. It’s to tighten verification.

This section is a bonus: it solves a different problem from the rest of the course. Loops and routines aren't about a large task divided into parts—they're about a a repetitive task run on a schedule. A loop is essentially a cron job running Claude locally. A routine is the same thing in the cloud, so you can close your laptop.

Two properties matter: each run doesn’t share context with the previous one, though it can share memory; and scheduling can be every five minutes, every hour, or daily. Anthropic currently runs 20 to 30 daily routines on its own products—and the detail that changes everything: each one is a single prompt, often one sentence. The model figures out the implementation details on its own.

What to look at: notice the size of the boxes in the middle — it’s the entire prompt for each routine, one sentence. Nobody wrote "use static and dynamic analysis" in the dead code routine; the model chose those methods on its own. And look at the label on the right: the deliverable is a PR, not an applied change. It’s the same discipline as the audit skill — propose and leave the decision to a human.

# --- Opção A: cron job local (roda no seu computador) ---
# abre o editor de agendamentos:
crontab -e

# cola esta linha: dia 1, a cada 6 meses (janeiro e julho), 9h
0 9 1 1,7 * echo "ABLACAO: rodar /audit-ablacao na config global" >> ~/ablacao-lembretes.txt

# --- Opção B: routine (roda na nuvem, notebook fechado) ---
# o prompt inteiro da routine é UMA frase:
"Rode uma auditoria de ablação em ~/.claude/CLAUDE.md e ~/.claude/skills/,
 e me entregue o Top 10 por impacto ÷ risco. Não altere nenhum arquivo."

# --- Opção C: sem nada instalado ---
# evento recorrente semestral no calendário, com este título:
"Ablação: rodar /audit-ablacao + abrir ablacao-diario.md"

Final module and course exercise: write your ablation policy personal in ≤10 lines. It needs four things: when to re-audit, what you never cut, the reintroduction rule, and where the logs and evals live. Less than that isn’t a policy; more than that won’t get read.

And it will where it will be reread — as a separate skill or note, with a date set, not as another paragraph in the CLAUDE.md. If you paste the policy there, you’ve just created zombie line number 1 for the next audit: text about ablation being loaded in 100% of runs, including those that have nothing to do with auditing configuration.

## Política de ablação — <seu nome>

1. Re-auditar: a cada 6 meses (próxima: <DD/MM/AAAA>) e a cada modelo novo.
2. Gatilho extra: CLAUDE.md > 150 linhas, 3+ skills no mesmo gatilho, regra sem dono.
3. Escopo padrão: <global | projeto X | conjunto de skills Y>.
4. Nunca cortar sem teste: identidade, caminhos/fontes de verdade, segurança,
   compliance, contratos de interface, integrações, convenções internas.
5. Reintrodução: só após a MESMA falha repetir 2x em trabalho real,
   e na forma mais curta possível.
6. Aplicar cortes sempre em sessão separada da auditoria, com a config sob git.
7. Diário de falhas: <caminho/ablacao-diario.md>.
8. Evals pessoais: <caminho/evals/> — aposentar as saturadas a cada re-auditoria.
9. Toda remoção aplicada registra: trecho citado + risco + como testar.
10. Toda versão nova precisa ter pelo menos uma verificação objetiva.