letramento
ai-first.

por que agora.

Entender por que esta transição é diferente de outras ondas de tecnologia, e por que a vantagem não está no modelo de IA que você usa — está no modelo operacional que você constrói em volta dele.

A capacidade dos modelos cresceu muito mais rápido do que a capacidade das organizações de usá-los. Esse descompasso — a janela capacidade × uso — é o "por que agora". A ferramenta já está disponível e barata; o que falta é a forma de trabalhar que extrai valor dela. A maioria dos times trata IA como ferramenta isolada de produtividade (um copiloto que escreve mais rápido) e fica presa no purgatório dos pilotos: muitos experimentos, pouco resultado que se sustenta.

Quem ganha não é quem tem o modelo melhor — modelos viraram commodity — é quem reorganiza o modelo operacional em volta deles. Essa é a tese da Rabbity e o pano de fundo dos dois workshops. A diferença prática é enorme: tratar como ferramenta = cada pessoa usa um chat para acelerar a própria tarefa, e nada fica registrado; tratar como modelo operacional = o time desenha como a inteligência entra em cada etapa, o que fica externalizado para a IA operar, e onde o humano decide.

A evidência é farta: índices econômicos mostram curvas reais de adoção; relatórios de mercado apontam recomposição de tarefas (não só "demissões por IA"); casos como Coinbase, Uber e JPMorgan mostram empresas redesenhando engenharia e produto em torno de agentes. O fio comum: o impacto da IA nas tarefas é maior do que nas vagas — muda primeiro como o trabalho é feito. Guarde a frase-âncora: o modelo operacional é a vantagem.

inteligência × julgamento.

Internalizar o eixo-mãe da metodologia: separar o que a IA faz bem (inteligência) do que precisa continuar no humano (julgamento) — e usar isso para decidir o que delegar.

É o primeiro dos 6 fundamentos canônicos e a lente que organiza todo o resto. Inteligência é coletar, sintetizar, gerar e verificar — processamento que a IA faz em escala. Julgamento é dar direção, arbitrar, tomar a decisão que carrega responsabilidade — o que permanece no humano. A regra prática: delegue a inteligência, retenha o julgamento.

Não é uma fronteira fixa, é um critério que você aplica tarefa a tarefa. Pesquisar 40 fontes e resumir padrões? Inteligência — delega. Decidir qual aposta vale o risco? Julgamento — retém. Gerar 30 variações de copy? Inteligência. Escolher qual vai ao ar e responde pela marca? Julgamento. O erro comum é colapsar os dois: ou desconfiam de tudo, ou delegam até o que carrega responsabilidade.

Esse eixo desemboca em outro fundamento — delegar / supervisionar / fazer, a régua de granularidade — e, no tempo, move-se de copilot (IA assiste, humano dirige) para autopilot (IA executa, humano vira advisor). Quando você propuser automatizar algo, a primeira pergunta vai ser: "isso é inteligência ou julgamento?".

o harness.

Entender o conceito central: agente = modelo + harness. Nomear as três peças (memory, skills, protocols) e ter uma lente rápida para diagnosticar por que um agente falhou.

Harness é tudo num agente exceto o modelo: o contexto que recebe, as ferramentas que usa, a memória que consulta, os gates onde a decisão volta ao humano. O modelo é o motor; o harness é o resto do que faz aquilo virar trabalho útil e confiável. Como modelos viraram commodity, o harness é onde mora a vantagem.

Ele se organiza em três pilares:

• memory — o que o time/agente sabe e consulta no tempo (decisões, evidências, estado). Resolve continuidade.
• skills — como o trabalho é feito, codificado em arquivos que o agente lê ao executar. Resolve variância.
• protocols — como o agente se conecta a ferramentas e a outros agentes (ex.: MCP). Resolve coordenação.

Para diagnosticar, use as 4 alavancas — quando um agente falha, uma delas quebrou: context (faltou/sobrou informação), tools (ferramenta errada ou mal usada), loop (o ciclo de execução falhou) e governance (faltou gate, permissão ou política). Num nível mais fino há 6 dimensões operacionais: loop · sandbox · gates · observabilidade · permissões · orçamento de contexto. E uma distinção útil: guides (controles preventivos, feedforward — um spec, um design system) vs. sensores (controles corretivos, feedback — holdout, validação funcional).

externalização.

Entender a ideia que dá base ao harness: por que tirar a carga cognitiva da cabeça (ou do contexto efêmero do modelo) e colocá-la em estruturas externas, persistentes e inspecionáveis é o que torna a IA confiável.

Externalização é mover carga cognitiva para fora — para estruturas externas, persistentes, que dá para inspecionar. A raiz é antiga (Donald Norman, cognição distribuída: já externalizamos memória em listas e agendas). O paper de Zhou et al. (2026) unifica isso para agentes: memory, skills, protocols e harness são, todos, formas de externalização — e é isso que tira o agente da fragilidade.

Três trocas explicam por que funciona:

• recall → reconhecimento — em vez de "lembrar" tudo no contexto (limitado e efêmero), o agente reconhece o que está escrito num arquivo que consulta.
• geração → composição — em vez de gerar do zero, ele compõe a partir de skills já codificadas. Mais consistente.
• ad-hoc → contrato — em vez de improvisar cada interação, ela vira contrato estável (um protocol, um spec). Mais robusto.

A tradução prática: tudo que importa precisa virar artefato legível — por gente e por agente. Uma decisão na cabeça de alguém não é externalizada; escrita num arquivo que o agente consulta, sim. Por isso insistimos tanto em escrever: specs, memória do squad, design system como contrato. Não é burocracia — é o que torna a inteligência reutilizável e auditável.

executor + advisor.

Entender o padrão que organiza a relação humano-agente quando a IA opera em escala: a IA executa, o humano é advisor nos pontos de ambiguidade — e por que separar quem faz de quem julga melhora a qualidade.

Terceiro fundamento canônico. Quando a IA passa de copilot para autopilot, o papel do humano muda: você deixa de operar cada passo e vira advisor — entra nos pontos de ambiguidade, arbitra, aprova. O agente é o executor; você é o conselheiro que decide quando o caminho não é óbvio. É o inteligência × julgamento virando arranjo concreto.

A parte contraintuitiva e mais importante: separar quem gera de quem avalia melhora o resultado. Em vez de um agente que faz e se autovalida (e tende a acreditar na própria resposta), monte um arranjo onde um gera e outro, independente, critica de forma adversarial — tentando refutar, não confirmar. A Anthropic descreve isso como planner / generator / evaluator, e os ganhos de acurácia são expressivos quando o avaliador é independente e cético.

Na prática: um agente redige o PRD, outro o estressa contra os 4 riscos; um gera variações de copy, outro testa contra cenários de persona escondidos. O humano-advisor fica no topo — não revisando cada token, mas decidindo onde gerar e avaliar discordam, ou onde a decisão carrega responsabilidade. Sinal de alerta: "o mesmo agente faz e revisa".

o ecossistema claude.

Conhecer o vocabulário das ferramentas reais que usamos para montar harness — sem precisar operá-las ainda. Saber o que cada peça faz e em qual pilar (memory / skills / protocols) ela cai.

Técnico ou não, você vai ouvir esses nomes o tempo todo. Mapeando no harness:

• Claude Code — o agente que roda no seu ambiente e executa tarefas reais (lê, escreve, roda comandos, chama ferramentas). O executor mais usado.
• Projects — contexto e instruções fixos de um projeto. É memory no nível do projeto.
• Skills — métodos de trabalho codificados em arquivos (SKILL.md) que o agente lê ao executar. É skills, literalmente.
• Subagents — agentes auxiliares despachados para tarefas paralelas/especializadas. É como você monta executor + advisor.
• MCP (Model Context Protocol) — o protocolo-padrão que liga o agente a fontes e ferramentas (Notion, Drive, Figma, bancos) com permissão. É protocols.
• Dynamic workflows — para tarefas grandes, o agente desenha a própria máquina de execução (decompõe, paraleliza, sintetiza).
• Managed Agents / Outcomes — a fronteira mais nova: agentes geridos e orientados a resultado. Conecta com o loop (módulo 09).

A mensagem não é "decore features" — é: cada peça é uma forma concreta de externalizar memory, skills ou protocols.

spec executável (sdd).

Entender a primitiva que aparece nos dois workshops: a especificação executável. Por que ela substitui o brief em prosa e quais são suas três partes.

SDD — spec-driven development é o segundo fundamento canônico e a peça que mais se repete. Em vez de descrever o trabalho em prosa solta (um brief ambíguo que cada um interpreta de um jeito), você escreve uma especificação executável — uma descrição que um agente consegue operar e contra a qual dá para medir o resultado. Três partes:

• input estruturado — o que entra, organizado (não "faça um banner bonito", mas contexto, restrições e material explícitos).
• output mensurável — como você sabe que ficou bom: o critério objetivo, não um "ficou legal".
• gate humano — quem aprova, quando e com que critério. Onde o julgamento volta para a pessoa.

Isso é externalização aplicada ao "como fazer": o spec transforma intenção implícita em contrato explícito (a troca ad-hoc → contrato). É a camada feedforward (um guide) que orienta o agente antes de agir. E um detalhe que muda a postura: na maioria das vezes você não escreve o spec do zero — você converte algo que já existe (um PRD, um brief de campanha) em forma executável. No produto vira prd executável; no marketing, brief de campanha executável. Quando o spec vira um documento vivo que um agente mantém atualizado, ele vira um live artifact.

os dois ciclos.

Ver a espinha dos dois workshops lado a lado: o ciclo de produto (ClickBus) e o ciclo de campanha (Roca). Perceber que são a mesma lógica em domínios diferentes — e que o harness atravessa as duas.

Os dois têm a mesma arquitetura: um ciclo em 4 etapas, lido pelo frame do harness, com o spec executável costurando cada etapa. Muda o domínio.

Ciclo de produto (ClickBus):

• opportunity discovery — captar sinais; o brief como spec; a OST (opportunity solution tree, de Teresa Torres) como âncora que os agentes alimentam.
• assessment → definição executável — passar pelos 4 riscos de Cagan (valor · usabilidade · viabilidade · negócio), virar 1-pager e prd executável; gate de kill-or-sharpen.
• test development — prototipar e validar antes de engenharia; cenários como holdout; design system como contrato; gates.
• launch & measure — live artifact, análise recorrente, proveniência do dado, fechamento do loop de outcomes.

Ciclo de campanha (Roca):

• sinais e oportunidade — leitura de mercado/audiência alimentando o quê fazer.
• definição executável — o brief de campanha executável (o SDD reembalado para marketing).
• validação pré-disparo — testar a peça antes de veicular; recepção de persona como holdout (validar copy contra cenários de persona escondidos do gerador).
• veiculação e mensuração — colocar no ar, medir, fechar o loop.

O paralelo é proposital: quem entende um ciclo entende o outro. As âncoras de domínio mudam, mas a estrutura — 4 etapas, spec em cada uma, gates humanos, loop que retroalimenta — é idêntica. Em ambos, o artefato coletivo é um mural (etapas nas colunas, camadas do harness nas linhas) que vira o plano de harness. E ambos terminam numa régua de maturidade: adoção → closed-loop → intelligence layer.

loop, valor e riscos.

Fechar o tronco com três ideias de horizonte: para onde o harness evolui (loop), onde o valor é capturado (a pilha), e o que pode dar muito errado (os riscos).

Loop engineering. Se o harness é o agente montado, o loop é o harness rodando numa cadência, sem alguém dando prompt a cada execução. A frase de Peter Steinberger: "você não deveria mais estar promptando agentes; deveria estar desenhando loops que promptam seus agentes." É um andar acima do harness. Não é automação burra: o loop tem memória, gates e sensores — observa o próprio resultado e ajusta. Quando ele fecha de verdade (a entrega retroalimenta a inteligência que gera a próxima), chamamos de closed-loop.

Pilha de captura de valor. Onde está a margem numa operação ai-first? Quatro camadas empilhadas: (1) modelos — commodity; (2) conexão de dados — padronizando (MCP); (3) harness e orquestração — vantagem técnica; (4) modelo operacional — onde o valor é de fato capturado. A margem migra de baixo para cima: a defensibilidade está em cima. Isso fecha o arco do módulo 01.

Riscos. Poder de agir traz risco de errar em escala:

• trifeta letal — dados sensíveis + comunicação externa irrestrita + execução não verificada. As três juntas = porta aberta para exfiltração. Mitigação: quebrar a tríade (sandbox, gates, permissões).
• memory poisoning — se entra lixo na memória externalizada, o agente opera sobre base contaminada.
• slop — volume gerado sem curadoria; parece produtivo, degrada qualidade. Antídoto: executor + advisor (curar é o gargalo, não gerar).

Há ainda comprehension debt — quando a IA gera mais do que o time consegue entender e manter. Esses riscos não são argumento contra a IA — são exatamente o que o harness (gates, sensores, governança) existe para administrar.