🏎️ Fundamentos do Harness

Tudo que envolve o modelo: prompts, skills, ambiente e codebase.

É onde está a alavanca que você de fato controla.

Motor = modelo; carro = harness; controle quase total.

O motor é uma parte; o chassi e a aerodinâmica fazem o carro vencer.

Reposiciona seu foco do brinquedo brilhante para o sistema.

Sistema > peça; mentalidade chassi.

Prompts, ambiente e codebase estão 100% nas suas mãos.

Muda onde vale investir tempo: no que você muda hoje.

Três alavancas; melhoria independente do modelo.

A obsessão pelo modelo novo e o vibe coder que troca toda semana.

Evita ficar preso a um modelo e nunca aprender fundamentos.

Pensar pelo harness, não pelo modelo.

Pocock pesa modelo e harness em partes iguais.

Metade do resultado está sob seu controle direto.

Balanço 50/50; harness barateia o modelo.

Traduzir “melhorar a IA” em “melhorar o harness”.

Maior retorno por hora investida.

Checklist: prompt, skills, ambiente, codebase.

Ideia de ML (Rich Sutton): compute bruto vence otimizações feitas à mão.

Explica por que apostar contra o avanço dos modelos costuma perder.

Compute cresce rápido; métodos gerais > truques manuais.

A ideia de só esperar o modelo melhorar — “esperar o motor ficar melhor”.

É o erro espelhado: terceirizar todo o progresso ao laboratório.

Esperar parado ≠ estratégia.

Mesmo com o Bitter Lesson, ainda há muito a ganhar otimizando o harness hoje.

O limite da lição: ela não diz para você não fazer nada.

Compute sobe; harness ainda multiplica resultado agora.

“Esperar parado pela AGI sem fazer nada foi uma ideia muito burra.”

Ação compõe: cada melhoria de harness rende juros enquanto o modelo evolui.

Agir agora > esperar; melhorias compõem.

Meio-termo: melhorar o setup todo dia E usar o melhor modelo.

Evita os dois extremos: superotimizar o harness ou só esperar o motor.

“Faço o melhor com o que tenho agora.”

Investir no harness agora; usar o melhor modelo; não apostar tudo na espera.

Transforma a teoria em rotina semanal.

Rotina: 1 melhoria de harness por semana + melhor modelo.

Manter o workspace/harness o mais independente de modelo possível.

O que é agnóstico sobrevive à próxima troca de modelo.

Agnosticismo = robustez a mudanças.

“Se eu superotimizo em torno de um modelo, perco o foco nos fundamentos.”

Acoplar-se a um modelo cria dívida quando ele muda.

Superotimização = dívida futura.

Focar no que funciona há 30-40 anos; tende a seguir funcionando.

Fundamentos antigos são a aposta mais segura no longo prazo.

Boas práticas atemporais > novidade brilhante.

Pular de ferramenta em ferramenta sem aprender princípio nenhum.

É o oposto do agnosticismo: muita novidade, zero base.

Trocar tudo ≠ evoluir.

Aplicar bons fundamentos para sobreviver a trocas de modelo.

Um setup blindado custa menos a cada virada de modelo.

Padrões portáveis; baixo acoplamento.

Como auditar se você está preso a um modelo.

Torna o agnosticismo verificável, não vago.

Lista de checagem objetiva.

A experiência que o agente tem trabalhando no seu codebase.

Boa AX deixa o agente mais eficaz e mais barato.

AX = ambiente do agente.

DX e AX têm enorme sobreposição; bom DX já melhora AX.

Você não precisa escolher: melhorar um melhora o outro.

Bom sênior que faz bom DX já entrega AX.

O que ajuda o agente a explorar sem bater cabeça.

Guard rails reduzem tentativa-e-erro e custo.

Limites claros + caminhos óbvios.

“Documentação suficiente para apontar a IA aos lugares certos.”

Doc demais vira ruído; doc certa acelera o agente.

Doc enxuta e direcional.

Melhorar o codebase é melhorar o ambiente em que o modelo roda.

É a alavanca de AX mais esquecida — e das mais potentes.

Codebase = ambiente; ambiente = AX.

Sinais de um codebase com boa AX.

O que você mede, você melhora.

Sinais observáveis de AX.

“Como otimizar gasto de tokens? Tenha um codebase mais fácil de mudar.”

A arquitetura é a alavanca de custo mais subestimada.

Fácil de mudar = barato de operar.

Guard rails melhores → o modelo gasta menos tokens batendo cabeça.

Cada cabeçada evitada é token economizado.

Guard rails = menos tentativa-e-erro.

Codebase melhor → modelo mais barato/simples faz o mesmo trabalho.

É como pagar menos por API sem perder resultado.

Bom harness rebaixa o modelo necessário.

“Algemar o modelo desde o dia 1” obriga a usar um modelo caro.

O custo aparece como dependência de modelo caro.

Codebase ruim = imposto permanente.

Refatorar para deixar fácil de mudar é otimização de custo.

Cada refatoração reduz o token gasto nas próximas mudanças.

Refatorar = baixar o custo marginal.

Como pensar custo por mudança.

Dá um número para guiar refatorações.

Tokens/mudança como bússola.

Toda skill vaza sua descrição no context window.

O contexto é finito; cada vazamento ocupa espaço.

Descrição da skill = custo de contexto.

100 skills = 100 descrições vazando no contexto.

A “lista de habilidades” não sai de graça.

Mais skills = mais vazamento.

`disable model invocation: true` → skill só invocada por você, sem vazar descrição.

Permite ter a skill sem pagar o custo de contexto dela.

Procedure só-do-usuário; descrição oculta.

“Todo mundo entope o context window com coisa demais, instrução demais.”

Excesso de instrução piora o desempenho, não melhora.

Menos é mais no contexto.

Voltar ao blank slate e observar o agente puro.

Só assim você vê o que realmente precisa adicionar de volta.

Deletar tudo → observar → recamadar.

Cortar o que não agrega; manter conhecimento no humano.

Contexto limpo melhora desempenho e custo.

Higiene contínua de contexto.