O Maintainer do Redux Documentou o Workflow de Agentes Mais Honesto de 2026

Em 7 de maio de 2026, Mark Erikson publicou a Parte 2 da sua série sobre workflow de IA. Erikson mantém o Redux. O trabalho do dia a dia dele é na Replay. É a pessoa que responde quando uma engenheira frontend sênior abre um bug de gerenciamento de estado às três da manhã, e ela respondeu a tantos desses bugs por tantos anos que tem opiniões que valem a leitura.

A manchete do texto não é o stack de ferramentas. A manchete é o que ele se recusou a fazer e o que ele admitiu, em público, que ainda não sabe resolver.

O stack em si é interessante. OpenCode com a interface CodeNomad. Claude Opus 4.5 e 4.6 via API. MCPs próprios chamados grepika, tilth e cachebro. Um script Bun próprio, o devplans.ts, que cuida das passagens entre sessões. Boa parte disso é substituível. Ferramenta troca a cada seis semanas. Disciplina não.

A disciplina parece uma lista de coisas que muita gente fingiu já ter superado. Erikson não superou. Ele roda uma sessão orquestradora pai que dispara sessões filhas interativas de subtarefa, e se limita a um único fluxo de trabalho concorrente. Palavras dele: “Estou escolhendo intencionalmente limitar o workflow ao que eu consigo gerenciar dentro da minha própria cabeça.” Recusa os modos de permissão YOLO. Usa filtragem de comandos por regex em vez de segurança baseada em chamada de agente. Faz commit no Git à mão.

Se você leu isso e sentiu vontade de discutir com ele, as próximas duas seções são para você.

O que Erikson Recusou, e por que Cai Diferente em 2026

Três recusas se destacam. Cada uma delas pressiona algo que algum fornecedor ou pensador influente vem vendendo nos últimos doze meses.

A primeira recusa é o modo de permissão YOLO. A maioria dos runners de agente vem com uma chave de “vai” que desliga o prompt em cada chamada de ferramenta. Erikson não vira essa chave. O argumento a favor de virá-la é vazão. O argumento contra, que Erikson faz simplesmente por não usar, é que uma rodada de agente sem prompt é uma rodada que você não consegue reconstruir. Trocou um loop mais lento por um loop mais rápido sem registro de quais decisões o modelo tomou em seu nome. Quando alguma coisa quebra, você não sabe por onde começar a ler.

A segunda recusa é segurança baseada em chamada de agente. Várias arquiteturas de segurança recentes roteiam toda chamada de ferramenta por um agente guardião que decide se ela é permitida. O pitch é que um LLM entende intenção e consegue bloquear chamadas perigosas que uma regex não bloqueia. Erikson escolheu a regex. A regex tem a propriedade de ser determinística, auditável e não pode ser alucinada por cima. Dois engenheiros lendo a mesma regex enxergam o mesmo conjunto de comandos permitidos. Dois engenheiros lendo o log recente de um agente guardião não enxergam.

A terceira recusa é subtarefas concorrentes. A fronteira dos workflows agênticos é muitos sub-agentes em paralelo, hierarquias, enxames. Erikson roda um por vez. O motivo não é que a tecnologia não consegue mais. O motivo é que ele não consegue modelar mentalmente mais de um em voo, e se recusa a operar um sistema cujo estado ele não consegue manter na cabeça. Aplique esse teste aos agentes em produção da sua casa. Quantos deles produzem saída que qualquer engenheiro do seu time consegue reconstruir depois? Se a resposta for “nenhum”, isso é um achado, não uma conquista.

Nenhuma dessas três posições é radical isoladamente. O que chama atenção é que um maintainer do calibre do Erikson publique as três juntas e não fique constrangido em dizer “eu me limito”. A mensagem implícita é que as pessoas embarcando nos stacks de agente mais barulhentos, mais rápidos e mais paralelos podem estar embarcando porque ainda não tiveram de conviver com as consequências.

Os Dois Problemas Abertos que Ele Foi Honesto a Respeito

A contribuição mais importante do post não são as recusas. São as duas superfícies que Erikson nomeou abertamente como não resolvidas.

A primeira é memória e contexto de longo prazo. Erikson é explícito. Quando ele precisa reconstruir o que ele e o agente decidiram duas sessões atrás, ele escava sessões anteriores à mão. Não existe memória de longo prazo funcionando. A sessão é a memória. Continuidade entre sessões é um problema de arqueologia manual, e o paliativo é o script devplans.ts dele, que costura na mão as passagens entre sessões.

A segunda é revisão de código e verificação de intenção. O enquadramento exato dele: “revisão de código e garantir a intenção ainda são difíceis.” Essa é a parte que lideranças de engenharia têm mais chance de ler errado. Ele não está dizendo que agentes não conseguem escrever código. Está dizendo que ninguém, inclusive ele, tem um jeito confiável de confirmar que o código que o agente produziu reflete a intenção que o humano tinha no início. A superfície de verificação ainda é humana.

As duas são superfícies que fornecedores correm para preencher. A corrida é real, e alguém eventualmente vai entregar algo útil em cada pista. Hoje, em maio de 2026, o praticante mais respeitado publicando sobre o tema diz que nenhuma das duas pistas está fechada. Sua premissa operacional deve casar com a dele.

Existe uma conexão entre as três recusas e os dois problemas abertos que vale nomear. As recusas existem porque os problemas abertos existem. Se memória de longo prazo funcionasse, o caso para rodadas YOLO sem estado seria muito mais forte, porque daria para reconstruir o que aconteceu. Se revisão confiável de código por IA existisse, o caso para subtarefas paralelas de alta vazão seria muito mais forte, porque cada saída seria verificável de forma independente. A disciplina que ele pratica não é arbitrária. É exatamente a disciplina que um praticante sênior adota quando as duas primitivas estruturais ainda estão faltando.

Por que Isso Importa para o Seu Stack

Já escrevemos antes sobre por que o harness é a sua memória e por que subtração vence adição em design de harness. O post do Erikson é a validação de campo dessas posições, escrita por alguém que não está construindo um serviço da Victorino.

Leia o post dele contra a sua configuração de agente em produção. Três perguntas valem ser feitas.

Os seus agentes rodam com modelos de permissão que um revisor externo conseguiria reconstruir? Se o seu time usa modos YOLO em produção, vocês aceitaram implicitamente que não conseguirão explicar decisões individuais depois. Erikson escolheu não fazer essa troca. A pergunta é se o seu time fez a escolha de propósito ou por omissão.

A sua camada de segurança é determinística ou baseada em modelo? Um agente guardião é um complemento útil para um filtro determinístico. É uma substituição perigosa. A regex é chata, e é exatamente esse o ponto. Chato é auditável.

Vocês têm uma regra escrita de quantas subtarefas concorrentes cada operador gerencia? Se não têm, têm uma na prática e não estão medindo. O número não precisa ser um. Erikson escolheu um para si. Um time operando em escala vai escolher mais. Mas o número precisa ser uma decisão, não uma propriedade emergente do que a ferramenta vier configurada de fábrica.

Onde a Fronteira de Fato Está

O post puxa uma linha mais nítida do que a maioria das lideranças se dispõe a puxar em público entre resolvido e não resolvido. A parte resolvida é engenharia mão na massa com um agente que obedece a um filtro determinístico, faz commit quando um humano manda fazer commit e trabalha em uma coisa de cada vez. Essa parte funciona hoje e funciona bem. A parte não resolvida é continuidade entre sessões e verificação de intenção.

Os pitches de fornecedor em volta de produtos de memória e revisão de código por IA não estão errados em existir. Apontam para superfícies reais. Mas apontam para superfícies que o melhor maintainer praticante do setor diz que ainda não estão fechadas. Se você está orçando investimento em agentes para os próximos dois trimestres, pese o orçamento na direção das partes que Erikson confirma estarem resolvidas, e trate as partes de memória e revisão como apostas de pesquisa, não como primitivas de produção.

Faça Isso Agora

Abra o documento de operação de um agente em produção do seu time. Encontre três coisas.

Encontre o modelo de permissão. Anote se os seus operadores rodam com aprovação por prompt, filtros determinísticos ou modo YOLO. Se for YOLO, agende uma revisão com o engenheiro responsável esta semana. A pergunta não é se você confia no agente. A pergunta é se você consegue reconstruir as decisões dele caso um cliente pergunte.

Encontre o limite de concorrência. Anote o número máximo de subtarefas concorrentes que um único operador roda. Se o número não está escrito, escreva hoje. Escolha um número que você consiga defender. Erikson escolheu um. Seu time pode escolher três. O número em si importa menos do que o fato de alguém ser dono dele.

Encontre a história da memória. Anote como um operador reconstrói o que foi decidido três sessões atrás. Se a resposta for “ele faz grep em logs antigos”, vocês estão rodando o mesmo paliativo que o Erikson, e isso é aceitável. Se a resposta for “nosso produto de memória cuida disso”, verifique essa afirmação contra um caso real antes de apostar um release nela.

A régua que Erikson colocou nesse post não é uma régua alta. É uma régua honesta. Acompanhe.

Fontes

Mark Erikson / blog.isquaredsoftware.com. “My Thoughts on AI, Part 2: Agent Setup, Workflow, and Tools.” Maio de 2026.

A Victorino ajuda lideranças de engenharia a codificar a disciplina de agentes que os maintainers de ponta praticam, com guardas explícitas para as lacunas que os fornecedores ainda não fecharam: contato@victorino.com.br | www.victorino.com.br