Mise En Place Para Codar Com Agente: A Preparação Deliberada Que Ninguém Faz Antes De Delegar

Faz duas semanas que escrevi sobre um número que não conseguia tirar da cabeça: mais de 8 mil de quase 10 mil startups que geraram código de produção com IA generativa precisaram de algum tipo de reconstrução. Fechei aquele post com uma constatação incômoda — o custo do vibe coding não aparece na hora em que o código é gerado, aparece meses depois, quando alguém descobre que o trabalho real é reconstruir um entendimento que nunca existiu de forma completa em nenhuma cabeça humana. Publiquei, movi para a próxima pauta, e o assunto devia ter ficado ali.

Não ficou. Fiquei pensando, nos dias seguintes, numa lacuna que deixei aberta de propósito: identifiquei o mecanismo do problema, mas não ofereci nada parecido com um caminho prático para evitá-lo. É fácil, e um pouco barato, apontar que delegar sem contexto suficiente é arriscado. É mais difícil dizer o que fazer diferente na segunda-feira de manhã, quando o agente está esperando um prompt e o prazo não espera.

Foi por isso que um paper publicado no arXiv em maio de 2026 me chamou atenção numa leitura de fim de semana. Andrew Zigler propõe uma metodologia chamada "mise en place" para codar com agente — nome emprestado da cozinha profissional, onde cada ingrediente é separado e organizado antes de a panela ir ao fogo. A tese é simples de enunciar e mais difícil de praticar: gerar código raramente é o gargalo num fluxo com agente; alinhamento é. Um agente que recebe contexto raso produz código que diverge da intenção, das convenções do time ou da semântica do domínio, e o ciclo de depuração que vem depois consome mais tempo do que a preparação teria custado.

Não apliquei essa metodologia eu mesmo, e não vou fingir que apliquei — não tenho esse relato de primeira mão para contar. Este post cobre o que o paper de Zigler descreve, como as três fases da metodologia funcionam, o conceito de "context fluency" que ele propõe como habilidade nova de desenvolvedor, os números do estudo de caso que sustenta o trabalho, um cenário hipotético de como isso desceria para o dia a dia de um time fora de hackathon, e os limites que o próprio autor admite que a pesquisa tem.

---

O Problema Que Ficou Em Aberto No Post Sobre Vibe Coding

Vale recapitular rápido, sem repetir o post inteiro. O padrão dominante em programação assistida por IA prioriza velocidade de implementação sobre preparação deliberada — descreve-se uma tarefa em poucas frases, o agente gera uma solução completa, e ela sobe para produção se passar no teste que já existia. O problema não é a velocidade em si; é que esse padrão cria uma falha sistemática de alinhamento. Agente sem contexto suficiente sobre convenções do time, decisões arquiteturais anteriores ou regra de negócio implícita produz código que funciona no caminho feliz e falha silenciosamente no resto, exigindo depuração e refatoração extensivas quando alguém finalmente esbarra no problema.

No post anterior, tratei esse mecanismo como dívida de compreensão — o código funciona, passa no teste que existe, mas ninguém consegue explicar por que foi estruturado daquele jeito. Já toquei nesse território, com outro ângulo, ao escrever sobre context engineering como a habilidade mais importante para quem trabalha com agentes de coding: a ideia de que o gargalo real de um fluxo agêntico não é a capacidade do modelo, é a qualidade do contexto construído para ele operar.

O paper de Zigler não contesta esse diagnóstico — parte dele. A diferença é que, em vez de ficar na crítica ao vibe coding, o autor propõe uma metodologia com fases nomeadas, artefatos concretos e um estudo de caso mensurável. É esse deslocamento, do diagnóstico para o protocolo, que fez o paper valer um post à parte.

---

Mise En Place: Preparar Antes De Delegar, Não Torcer Depois

A metáfora culinária é literal, não decorativa. Mise en place é o termo que cozinheiros profissionais usam para separar, medir e organizar cada ingrediente antes de cozinhar — para que o momento de execução seja isso mesmo, execução, e não improviso sob pressão. Zigler transpõe essa lógica para o momento anterior à delegação de uma tarefa a um agente: preparar o contexto deliberadamente antes de escrever o prompt que dispara a implementação, em vez de descrever a tarefa em poucas linhas e torcer para o agente preencher as lacunas com uma suposição razoável.

O argumento estrutural é que geração de código deixou de ser o gargalo em fluxos com agente. Modelos atuais produzem código sintaticamente correto, que compila e passa em teste superficial, numa velocidade que nenhum time humano alcança escrevendo linha por linha. O gargalo migrou para garantir que o gerado está alinhado com a intenção real de quem pediu, com as convenções da base existente e com o conhecimento tácito que normalmente vive só na cabeça de quem trabalha ali há tempo suficiente. Mise en place — MEP, na sigla do paper — é uma metodologia de context engineering desenhada para fechar essa lacuna antes que ela vire código em produção.

Isso não é reinventar processo do zero. O próprio paper reconhece que MEP é síntese de práticas já conhecidas — arquivo de instrução no estilo CLAUDE.md ou AGENTS.md, diálogo de especificação antes de implementar, decomposição de tarefa em unidades menores — organizadas numa sequência deliberada, com nome e protocolo repetível. A contribuição não é a novidade de cada peça isolada; é amarrar as três num fluxo único, aplicado no início do projeto, em vez de deixá-las como hábito solto que cada desenvolvedor pratica de um jeito diferente.

---

As Três Fases Da Metodologia MEP

O paper estrutura a metodologia em três fases sequenciais, cada uma produzindo um artefato escrito que a fase seguinte consome como insumo:

• Fundamentação contextual (contextual grounding). Conhecimento de domínio e conhecimento tácito — aquilo que normalmente só existe na cabeça de quem já trabalha no projeto — são externalizados em documentos estruturados que o agente lê antes de qualquer tarefa. O objetivo não é documentar tudo sobre o sistema; é converter julgamento de especialista em algo que um agente consiga consultar e usar.
• Especificação colaborativa (collaborative specification). Um diálogo entre humano e agente produz artefatos de design detalhados, cobrindo telas, interações, fluxos de dado e critérios de qualidade — e, de forma explícita, o porquê de cada decisão, não só o comportamento esperado. A pessoa descreve a intenção, o agente propõe detalhes, a pessoa aceita, rejeita ou ajusta.
• Decomposição de tarefas (task decomposition). As especificações viram registros de tarefa estruturados, cientes de dependência entre si — unidades de trabalho pequenas o suficiente para serem implementadas em paralelo, com critério de aceite explícito, formando uma fila que múltiplos agentes conseguem consumir sem pisar um no outro.

A ordem não é arbitrária. Fundamentação sem especificação produz documentação de domínio que ninguém traduziu em decisão de design. Especificação sem decomposição produz um documento de intenção rico que ainda exige que alguém decida como fatiar o trabalho na hora de implementar — reintroduzindo exatamente o tipo de suposição não verificada que a metodologia tenta eliminar. Um detalhe técnico da terceira fase: o paper usa registros em JSONL versionados no repositório, e não uma lista em Markdown, citando pesquisa da própria Anthropic sobre harnesses para agentes de execução longa, que mostrou modelos modificando Markdown de forma inadequada com mais frequência do que JSON estruturado. Um registro com campos fixos de prioridade, dependência e critério de aceite dá menos espaço para o agente reinterpretar a tarefa no meio da execução.

---

Context Fluency: A Habilidade Que Ninguém Tinha Nomeado

A parte do paper mais interessante de discutir com quem lidera time não é a metodologia em si — é o conceito que Zigler cunha para a habilidade por trás dela: "context fluency", fluência de contexto. A definição é direta: a capacidade de criar contexto rico e estruturado sobre o qual um agente consegue agir. Não é habilidade de escrever prompt mais longo; é a capacidade de decidir o que externalizar, em que granularidade e formato, para que um agente sem memória de longo prazo do projeto consiga operar como se tivesse.

O paper descreve essa fluência com componentes específicos. Decomposição é fatiar um problema em tarefas paralelizáveis sem criar dependência escondida entre elas. Especificação é capturar o quê e, igualmente importante, o porquê — não só o comportamento esperado de uma função, mas a razão pela qual esse comportamento é o certo naquele contexto, informação que normalmente evapora quando fica só na cabeça de quem decidiu. Definição de restrições é declarar explicitamente o que está fora de escopo, o que o agente deveria tratar como fronteira fixa em vez de sugestão a otimizar.

Tratar isso como habilidade — algo que se pratica e melhora, não traço de sorte de ter documentação boa à mão — muda como um tech lead deveria pensar sobre desenvolvimento de time num mundo com agente de coding. Otimizar para "prompt melhor" é otimizar a coisa errada. A habilidade que separa quem tira valor real de um agente de quem produz o tipo de código que alimenta a estatística do post anterior é estruturar contexto antes de pedir a tarefa — habilidade de engenharia, não de comunicação genérica com IA.

Isso conversa com algo que já toquei ao escrever sobre spec-driven development como complemento de harness engineering: a especificação não é burocracia que atrasa o trabalho real, é o artefato que carrega a informação de que o agente precisa para não reinventar uma decisão já tomada. Context fluency é, na descrição de Zigler, a habilidade humana que produz esse artefato de forma consistente — em vez de depender de lembrar a restrição certa no prompt certo, na hora certa.

---

O Estudo De Caso Do Hackathon: Duas Horas Para Sessenta E Quatro Tarefas

O paper ancora a metodologia num único estudo de caso: sua aplicação durante um hackathon competitivo. Cerca de duas horas de preparação — passando pelas três fases — permitiram a implementação paralela e rápida de uma plataforma educacional full-stack por agentes de IA concorrentes, dentro da janela apertada que todo hackathon impõe. Sessenta e quatro registros de tarefa cobriram a plataforma inteira, e quatro subagentes paralelos pegaram essas tarefas em ordem de dependência, cada um numa área da plataforma, sem precisar coordenar diretamente com os outros três.

Vale detalhar o que a fundamentação contextual produziu, porque dá ideia concreta do que "externalizar conhecimento tácito" significa na prática. Segundo o resumo do workflow publicado no AgentPatterns.ai, que descreve o paper com mais granularidade operacional, essa fase gerou dez documentos de planejamento somando 9.386 palavras — notas de exploração de API, análise competitiva e, mais chamativo, uma extensa dissertação sobre filosofia de design pedagógico, extraída da própria experiência do autor como educador. É exatamente o tipo de conhecimento tácito que nenhum agente teria como inferir sozinho do treinamento.

O resultado, ainda segundo esse resumo secundário, foi uma plataforma conectando professores organizando ambientes de pesquisa a partir do acervo de um jornal, para alunos usando um tutor de IA baseado no método socrático. Em cerca de cinco horas de implementação depois das duas de preparação, o resultado somou 8.496 linhas de código em 43 arquivos TypeScript e TSX. Cada subagente carregava as instruções e a especificação, consultava o sistema de tarefas por itens prontos na sua área e implementava contra o critério de aceite — mecanismo que importa porque agentes em paralelo não compartilham memória de sessão entre si; sem a especificação e o grafo de tarefas escritos, cada um teria de re-derivar decisões de design sozinho, com risco real de convergir em soluções inconsistentes entre módulos que precisavam interoperar.

Vale frisar o que esse número não prova, porque a tentação de tratar "64 tarefas, 2 horas de prep, hackathon vencido" como fórmula replicável é real. É um único estudo de caso, sem grupo de controle e sem instrumentação do que outras equipes fizeram de diferente. O que ele demonstra é que a metodologia é executável dentro de uma janela real e apertada, e produziu um resultado funcional — não que qualquer time que replicar os mesmos passos vai obter o mesmo ganho relativo.

---

Como Isso Desceria Para O Dia A Dia De Um Time — Fora De Hackathon

Hackathon é ambiente artificial: prazo fixo, equipe pequena, escopo que todo mundo aceita cortar sem briga política. Vale pensar num cenário hipotético de como MEP se aplicaria fora desse contexto, num time de produto em ritmo normal de sprint — deixando claro que é exercício de imaginação, não relato de aplicação real.

Imagine um time de plataforma construindo um módulo de faturamento com regras de cobrança específicas do setor — regras que existem em parte na cabeça do gerente de produto, em parte espalhadas em tickets antigos, em parte em lugar nenhum documentado. No modelo de vibe coding, alguém escreveria um prompt de poucas frases descrevendo a feature, o agente geraria uma implementação plausível, e as exceções de regra de negócio apareceriam meses depois, como bug reportado por cliente que caiu num caso de borda que ninguém tinha mencionado.

Aplicando a lógica de MEP, a primeira fase seria sentar com quem entende as regras — o gerente de produto e alguém do suporte que já resolveu disputa de fatura — e produzir um documento curto cobrindo exceções conhecidas e o vocabulário de negócio que o time usa. A segunda fase seria um ciclo de especificação em que o tech lead descreve a intenção de cada fluxo, o agente propõe telas e estrutura de dado a partir da fundamentação, e alguém valida ou corrige cada proposta. A terceira quebraria a especificação em tarefas menores — cálculo de valor prorrateado, geração de fatura, reembolso parcial, notificação de cliente —, com dependência explícita, permitindo que pessoas ou agentes sob supervisão trabalhassem em paralelo sem pisar na mesma lógica.

O ganho, nesse cenário, não seria necessariamente velocidade bruta — é possível que o tempo até a primeira versão funcional seja parecido ou até maior do que pedir a feature direto. O ganho estaria em quantas exceções apareceriam já na primeira versão em vez de meses depois como incidente, e em quanto do conhecimento que hoje só existe na cabeça do gerente de produto sobrevive documentado. É o mesmo custo assimétrico: pagar um pouco mais de alinhamento na frente para evitar correção bem mais cara depois, quando o erro já afetou cliente real.

---

Os Limites Que O Próprio Paper Assume

Aqui vale a mesma honestidade do post sobre vibe coding: não vou tratar MEP como solução validada só porque tem paper e nome bonito. O próprio Zigler é explícito sobre as limitações da evidência, e valem o mesmo peso dado aos números.

A mais óbvia: a evidência é um único hackathon, sem grupo de controle e sem instrumentação do desempenho de outras equipes. O autor classifica o próprio trabalho como exploratório e pede validação empírica adicional antes de qualquer generalização mais forte — ressalva que, na prática, costuma desaparecer quando a ideia vira slide de conferência.

A segunda é o que o próprio autor chama de confundimento de expertise do operador: não dá para separar a contribuição da metodologia da experiência prévia de quem a aplicou. Zigler já tinha prática relevante em desenvolvimento e, no caso do hackathon, conhecimento pedagógico de sobra para produzir aquele documento de filosofia de ensino. Um praticante menos experiente, seguindo o mesmo protocolo, pode não produzir contexto igualmente rico — a metodologia dá a estrutura, não substitui o julgamento de quem sabe o que vale externalizar.

A terceira, e a que mais importa para decidir quando aplicar isso no seu time, é que duas horas de preparação — ou qualquer proporção equivalente — não é realista para toda tarefa. Faz sentido para trabalho em paralelo entre agentes sem memória compartilhada, domínio pouco familiar onde o agente não tem convenção a inferir do treinamento, ou implementação cara de reverter. Não faz sentido para ciclo de feedback curto, onde testar e corrigir é mais rápido que planejar, nem para trabalho exploratório, onde ninguém ainda sabe a forma certa do problema — especificação escrita cedo demais tende a engessar estrutura prematura em vez de proteger contra erro.

Isso conecta de volta com o argumento que abriu este post: MEP não descarta o diagnóstico do vibe coding, é resposta parcial a um subconjunto real do problema — agente trabalhando com contexto insuficiente em cenário onde esse contexto faria diferença mensurável. Não é bala de prata para o universo de 8 mil startups que precisaram reconstruir código; é uma ferramenta a mais, com condição de uso descrita com honestidade suficiente para saber quando se aplica e quando é processo demais para um problema que um ciclo rápido de teste resolveria mais barato.

---

Conclusão

Volto à pergunta que fiquei devendo no post de 1º de setembro: o que fazer diferente, além de reconhecer que o problema existe. A resposta que este paper oferece não é definitiva nem universal — é metodologia com evidência limitada a um único estudo de caso, aplicada por alguém com experiência suficiente para tirar dela um resultado que outra pessoa, seguindo o mesmo protocolo, pode não replicar da mesma forma. Mas é, pelo menos, uma resposta com fases nomeadas, artefato concreto em cada uma e número real de tarefas e horas de preparação para ancorar a conversa, em vez de ficar só no princípio geral de "dê mais contexto ao agente".

O que fica mais claro depois de olhar as duas peças lado a lado — a crise de dívida técnica do vibe coding e a proposta de preparação deliberada do MEP — é que o problema nunca foi a capacidade do agente de gerar código. Sempre foi a disciplina de quem constrói o contexto em que esse código é gerado. Isso desloca a conversa de "qual ferramenta resolve isso" para "que hábito de preparação o time mantém quando o prazo aperta e a tentação de pular direto para o prompt fica mais forte" — pergunta de cultura de engenharia, não de escolha de fornecedor.

Não tenho certeza de que "context fluency" vai se consolidar como termo comum entre quem trabalha com agente, nem que mise en place vai sobreviver como nome depois que a novidade do paper passar. O que me parece razoavelmente seguro de levar daqui é mais modesto: preparar contexto antes de delegar tem custo real e mensurável, tem condição específica em que compensa, e ignorá-lo por completo — que é o que o vibe coding, na prática, tem feito — é aceitar pagar depois, com juro, um preço que parte dele daria para negociar antes.

Fontes:

• arXiv — Mise en Place for Agentic Coding: Deliberate Preparation as Context Engineering Methodology (Zigler, 2026)
• AgentPatterns.ai — Mise en Place for Agentic Coding
• Anthropic — Harness design for long-running application development
• Taskade — Context Engineering: What It Is + How to Do It