Como direcionar agentes de codificação com IA como um profissional

Como direcionar agentes de codificação com IA como um profissional

Por cerca de seis meses eu tive o cargo errado na minha própria cabeça. Eu pensava que era um desenvolvedor que usava Claude Code. Então quebrei um build de produção às 23h, rastreei até uma única linha que o agente escreveu e que eu nunca tinha realmente lido, e percebi a verdade: eu tinha sido um passageiro. Sentado no banco do motorista, mãos perto do volante, mas principalmente apenas esperando que o carro ficasse na estrada.

A solução não era um modelo melhor. Opus 4.8 já estava rodando. A solução era um papel diferente. Parei de tentar escrever código através do agente e comecei a tentar direcionar o agente — da mesma forma que um diretor de cinema não opera a câmera, mas é responsável por cada quadro. Essa mudança, mais do que qualquer template de prompt ou plugin, é o que dobrou a quantidade de trabalho real e entregável que eu consigo em um dia.

Esta é a parte que ninguém coloca nos vídeos de demonstração polidos. Para direcionar agentes de codificação com IA bem, você gasta mais tempo planejando do que construindo. Você gerencia a atenção do agente como se fosse um recurso escasso, porque é. Você constrói andaimes ao redor dele para que ele possa verificar seu próprio trabalho. E você trata cada falha como uma chance de melhorar permanentemente o sistema em vez de um incômodo pontual.

Muito do que reorganizou meu pensamento veio de uma entrevista de podcast que eu ficava rebobinando — Cole Medin, um engenheiro de software que se tornou construtor de IA e uma das vozes mais afiadas sobre codificação agêntica. Ele enquadra o Claude Code não como um gerador de código, mas como um "AIOS", um sistema operacional de IA que você conecta à forma como realmente administra um negócio. Esse enquadramento soou grandioso até eu começar a aplicá-lo. Então simplesmente soou correto.

Aqui está tudo que mudei sobre como conduzo meus agentes — o que funcionou, o que me queimou, e os hábitos exatos que agora me recuso a pular.

Por que direcionar agentes de codificação com IA supera apenas dar prompts a eles

Direcionar um agente de codificação com IA significa ser dono da intenção, do plano, dos critérios de sucesso e da verificação — e deixar o agente cuidar da digitação. O prompt é a menor parte do trabalho. O pensamento ao redor do prompt é onde está a alavancagem.

A maioria das pessoas que dizem que o Claude Code "não funciona para projetos reais" está presa no modo prompt. Eles abrem uma sessão, digitam um parágrafo, assistem enquanto gera, e julgam a ferramenta pela primeira coisa que ela cospe. Quando essa primeira tentativa está errada — e geralmente está em qualquer coisa não trivial — concluem que o agente é burro. Eu fiz exatamente isso por meses.

O reenquadramento é brutal, mas libertador: o agente não é seu colega engenheiro. É um júnior extraordinariamente rápido e extraordinariamente literal que leu tudo e não lembra de nada sobre o seu projeto a menos que você diga. Seu trabalho não é conversar com ele. Seu trabalho é ser seu product manager. Você alimenta o porquê por trás de cada tarefa, estabelece os limites, define como "pronto" se parece, e inspeciona o resultado contra um padrão que você decidiu antecipadamente.

Cole chama a habilidade central aqui de algo que agora uso constantemente: tratar a IA como um mentor enquanto você atua como seu product manager. Você não está pedindo a ela para descobrir o que construir. Você está entregando uma especificação tão clara que um júnior de pensamento literal não poderia interpretar mal, e então verifica o resultado como um PM verifica uma feature contra o ticket.

Uma vez que internalizei isso, a pergunta deixou de ser "qual é o prompt perfeito?" e se tornou "o que este agente precisa para ter sucesso, e como saberei se conseguiu?" Essas duas perguntas reorganizam todo o seu fluxo de trabalho. A primeira é sobre contexto. A segunda sobre verificação. Passaremos a maior parte deste post exatamente nesses temas.

Mas antes que qualquer um dos dois importe, você precisa entender a única restrição que governa tudo que um agente faz: quanto ele pode realmente prestar atenção de uma vez.

A "zona burra": por que uma janela de contexto de 1 milhão de tokens mente para você

Aqui está o equívoco mais caro na codificação agêntica, e eu o mantive por mais tempo do que gostaria de admitir: uma janela de contexto maior significa que você pode despejar mais e o modelo lida bem.

Não lida. Opus 4.8 vem com uma janela de contexto de 1 milhão de tokens — a mesma janela que a Anthropic manteve na linha 4.x, confirmada no lançamento da 4.8 em 28 de maio de 2026. Um milhão de tokens soa como espaço infinito. Mas o número que você pode encaixar e o número sobre o qual o modelo pode raciocinar com precisão não são o mesmo número, e a lacuna entre eles é onde os projetos silenciosamente desmoronam.

O que Cole chama de zona burra corresponde exatamente ao que vejo na prática: em algum ponto além de aproximadamente 250.000 tokens de contexto acumulado, a precisão começa a se degradar. Não catastroficamente — essa é a armadilha. O modelo não dá erro. Simplesmente fica sutilmente pior. Começa a esquecer uma restrição que você definiu quarenta mensagens atrás. Lê mal um arquivo que leu corretamente uma hora antes. "Ajuda" editando algo que você explicitamente disse para deixar em paz. A janela não está cheia, então você assume que está tudo bem. Não está. Você está na zona burra.

Aprendi isso da maneira difícil em uma refatoração de Laravel nos meus sites de marca. Mantive uma sessão longa rodando durante a maior parte de uma tarde, alimentando arquivo após arquivo, confiando na janela gigante. Por volta da hora três, o agente começou a reintroduzir um bug que eu tinha feito ele corrigir duas horas antes — porque aquela correção agora estava enterrada sob 300K tokens de ruído subsequente, e ele efetivamente "esqueceu" a lição enquanto a conversa tecnicamente ainda a continha.

A regra que sigo agora é direta: mantenha o contexto deliberadamente enxuto. Trate a janela de trabalho utilizável como muito menor que a anunciada. Três hábitos impõem isso:

• Limpe agressivamente entre tarefas não relacionadas. No momento em que um bloco lógico de trabalho está terminado, eu reseto em vez de carregar sua bagagem para o próximo. Escrevi todo o argumento para isso na minha análise dos comandos slash do Claude Code que realmente uso diariamente — /clear é o que eu manteria se pudesse manter apenas um.
• Não faça o agente ler o que ele não precisa. Cada arquivo que ele abre para "entender a base de código" são tokens gastos e atenção diluída. Aponte para os três arquivos que importam, não para o repositório inteiro.
• Coloque conhecimento duradouro no CLAUDE.md, não no chat. Arquitetura, convenções, schema — isso pertence à memória do projeto onde sobrevive a um clear e não apodrece dentro de uma conversa à deriva.

A zona burra é por que cada técnica avançada neste post existe. Harnesses, sub-agentes, o loop Ralph — tire o jargão e são todos o mesmo movimento: manter o contexto de qualquer agente individual pequeno o suficiente para se manter afiado. Uma vez que você vê isso, o resto da arquitetura faz sentido.

Então, se o contexto é a restrição, para onde o trabalho realmente vai? Para o planejamento — muito antes de uma única linha ser escrita.

Planeje mais do que constrói: a especificação é o trabalho real

A lição mais contraintuitiva: quanto melhor eu fico em direcionar agentes, menos do meu tempo vai para assistí-los codificar e mais vai para planejar antes de começarem. Em uma feature significativa, agora passo a maioria do meu tempo ativo na especificação e quase nada supervisionando a construção.

Isso parece errado se você cresceu escrevendo código à mão, onde planejamento era um imposto que você pagava antes do trabalho "real". Com agentes, inverte. O agente digita em minutos. O plano é o que determina se esses minutos produzem algo que você entrega ou algo que você joga fora. O plano é o trabalho real.

Uma especificação que realmente controla um agente tem quatro partes, e comecei a escrever todas as quatro explicitamente:

1. Intenção — o porquê. Não apenas "construa uma página de faturamento" mas "construa uma página de faturamento para que clientes existentes possam fazer upgrade de plano sem contatar o suporte, porque tickets de suporte para upgrades consomem duas horas por dia." Quando o agente conhece o porquê, ele toma melhores microdecisões sobre as mil coisas que você não especificou. Cole chama isso de engenharia de intenção, e é a frase com maior alavancagem em qualquer prompt. O agente preenche lacunas na direção da sua intenção declarada em vez de adivinhar.
2. O plano — o como. Os arquivos envolvidos, a ordem das operações, a abordagem que você escolheu e as que rejeitou. Prefiro sobreespecificar aqui do que descobrir no meio da construção que o agente inventou uma arquitetura que eu nunca teria aprovado.
3. Critérios de sucesso — a definição de pronto. Condições concretas e verificáveis. "O upgrade de plano atualiza a assinatura no Stripe, reflete imediatamente no painel, e não envia webhook duplicado." Se não consigo escrever os critérios de sucesso, não entendo a tarefa bem o suficiente para delegá-la.
4. Estratégia de validação — como será verificado. Decidida antes da construção, não depois. Quais testes unitários, qual fluxo de navegador, qual verificação manual. Vamos aprofundar nisso em breve porque é de onde vem a verdadeira confiabilidade.

Uma nota sobre ferramentas, porque Cole sinalizou isso e eu concordo: ele prefere escrever seus próprios prompts de planejamento controlados em vez de se apoiar inteiramente em modos de planejamento integrados, pela flexibilidade. Eu uso o modo de planejamento do Claude Code constantemente — é genuinamente bom, e a fase de planejamento agora tem seu próprio agente dedicado para que a pesquisa não contamine o contexto principal. Mas para qualquer coisa complicada, escrevo uma especificação à mão como um arquivo markdown e faço o agente executar contra aquilo, porque controlo cada palavra. O modo integrado é o caminho rápido; a especificação personalizada é o preciso. Use o caminho rápido até que a precisão importe, então mude.

Aqui está a parte que me surpreendeu. Escrever a especificação tão minuciosamente não me desacelerou no geral. Moveu meu pensamento para mais cedo, onde é barato, em vez de para depois, onde uma suposição errada significa arrancar código pronto. Se você já sentiu que o Claude Code "quase" conseguiu, mas continuava errando o ponto, a peça que falta é quase sempre uma especificação fina.

Agora — mesmo uma especificação perfeita produz um primeiro rascunho que está errado mais frequentemente do que está certo. Isso não é uma falha de planejamento. É simplesmente o piso. A pergunta é como você vai desse piso a algo confiável.

Como você verifica se o código gerado por IA está realmente correto?

Você verifica código gerado por IA construindo verificações automatizadas que o agente executa contra sua própria saída — testes unitários, automação de navegador e harnesses personalizados — para que ele capture e corrija seus próprios erros antes de você revisar. A saída da primeira tentativa do agente fica em torno de 65–70% correta em tarefas reais; uma camada sólida de autoverificação empurra isso para além de 92%. Esse salto é todo o jogo.

Reflita sobre esses números, porque eles reenquadram tudo. Se você confia na primeira tentativa, está entregando trabalho que está correto dois terços do tempo. Se você faz o agente se verificar, está entregando trabalho que está correto nove em cada dez vezes — sem gastar mais da sua atenção. O agente faz o retrabalho. Você só precisa dar a ele um espelho.

A camada de verificação tem três níveis que agora construo aproximadamente nesta ordem:

Testes unitários. A linha de base. Faço o agente escrever testes contra os critérios de sucesso, executá-los e corrigir o que falha — em um loop, sem mim. A chave é que os testes codificam a especificação, não o que o agente aconteceu de implementar. Testes escritos após o fato apenas confirmam os bugs do agente. Testes escritos a partir dos critérios de sucesso os capturam.

Automação de navegador. Para qualquer coisa com UI, testes unitários não são suficientes. Conecto Playwright para que o agente possa realmente operar a página — clicar no botão de upgrade, confirmar que o painel atualiza, verificar que nenhum webhook duplicado disparou. O agente vê o comportamento real em vez de raciocinar abstratamente sobre ele. Essa única adição corrigiu toda uma categoria de falhas de "passou nos testes mas o botão não fazia nada".

Harnesses personalizados. Este é o movimento avançado e o que me fez sorrir quando ouvi Cole descrevê-lo pela primeira vez. Às vezes, o que você está construindo não pode ser verificado por um teste normal — é interativo, em tempo real ou visual. O exemplo dele ficou comigo: para deixar um agente depurar um videogame, ele desacelerou a taxa de quadros do jogo para que o agente tivesse tempo de observar cada quadro e reagir. Isso é um harness — uma configuração personalizada que simula o usuário e permite ao agente perceber e responder ao que está realmente acontecendo. O princípio se generaliza: se o agente não pode verificar algo, construa para ele uma forma de perceber aquela coisa, e agora ele pode.

Este é também exatamente o tipo de julgamento que separa direcionar um agente de supervisionar um. Aprofundei nas ferramentas ao redor na minha peça sobre as ferramentas que corrigem o código lixo da IA no Claude Code — a maioria do "código lixo" não é um problema do modelo, é uma camada de verificação faltante.

Se você prefere não construir esse andaime você mesmo, este é precisamente o tipo de infraestrutura agêntica que minha equipe configura para clientes — projetando a camada de especificação, verificação e harness para que os agentes permaneçam confiáveis em produção. Você pode ver o tipo de projetos que aceito em fiverr.com/s/EgxYmWD.

Uma vez que um agente pode se verificar de forma confiável, uma ideia maior se abre: e se você encadear vários deles, cada um permanecendo em seu próprio contexto enxuto, passando trabalho limpo pela linha?

Engenharia de harness e o loop Ralph

Um harness, neste mundo, é a camada de orquestração ao redor dos seus agentes — como você os executa, em que ordem, com que handoffs, e que verificações rodam entre eles. Cole o enquadra como a fundação que você constrói primeiro, com uma "camada de IA" de skills, hooks e servidores MCP empilhados em cima. Acerte o harness e tudo acima dele se torna mais confiável.

A razão pela qual harnesses importam volta diretamente à zona burra. Um único agente trabalhando através de uma tarefa grande acumula contexto até degradar. Mas se você divide o trabalho em fases e dá a cada fase seu próprio agente com seu próprio contexto fresco, nenhum agente individual entra na zona burra. Cada um faz um trabalho de forma afiada, depois passa adiante.

A versão mais limpa disso é o que a comunidade chama de loop Ralph — uma técnica originalmente popularizada por Geoffrey Huntley em 2025, agora embutida nos padrões do Claude Code. Imagine uma linha de montagem. Um agente planeja. Passa uma especificação limpa para um segundo agente que implementa. Esse passa para um terceiro que testa e corrige. Cada estação possui uma fase, recebe input limpo, produz output limpo, e crucialmente começa fresco — então o acúmulo de contexto da fase de planejamento nunca pesa na fase de testes.

Agora executo constantemente uma versão manual disso. Mesmo sem orquestração sofisticada, a disciplina de "planejar em uma sessão, limpar, implementar na próxima, limpar, verificar em uma terceira" mantém cada passo afiado. Os fluxos de trabalho dinâmicos do Opus 4.8 levaram isso adiante — uma única sessão pode agora lançar muitos sub-agentes paralelos, cada um com sua própria janela de contexto, e então agregar os resultados. Detalhei o que isso desbloqueia no meu passo a passo dos fluxos de trabalho dinâmicos do Claude Code.

Sequencial vs. paralelo é a escolha que você faz com um harness:

• Sequencial (o loop Ralph) quando cada fase depende da anterior — planejar, depois construir, depois testar. Handoffs limpos, sem deriva, roda por muito tempo autonomamente.
• Paralelo quando o trabalho se divide em pedaços independentes — três sub-agentes pesquisando três bibliotecas diferentes simultaneamente, depois reportando. Mais rápido, mas eles não podem facilmente se comunicar entre si, então são melhores para trabalho de dispersão-e-coleta.

Aviso honesto: engenharia de harness é o ponto onde isso deixa de ser casual. Você agora está escrevendo orquestração, gerenciando formatos de handoff, depurando qual estação quebrou. É engenharia real. A recompensa são agentes que rodam de forma confiável por horas em vez de precisar de você a cada cinco minutos — mas você não recorre a isso para uma correção rápida. Recorre quando a tarefa é grande o suficiente para que supervisioná-la custaria mais do que construir a configuração.

Há mais uma mudança de mentalidade que se combina com tudo isso, e é a que silenciosamente fez toda minha configuração melhorar ao longo do tempo.

Trate cada falha como uma melhoria permanente

Aqui está o hábito que mudou a trajetória do meu sistema mais do que qualquer feature individual: toda vez que um agente erra, eu não apenas corrijo a saída — corrijo o sistema para que aquele erro exato nunca mais possa acontecer.

O agente gerou código que violou minha convenção de nomenclatura? Não apenas renomeio. Adiciono a convenção ao CLAUDE.md. O agente continua esquecendo de rodar migrações após uma mudança de schema? Adiciono um hook que bloqueia o commit até que as migrações rodem. O agente entendeu mal um termo do domínio? Escrevo uma entrada de glossário de um parágrafo. Cada correção é um tijolo. Ao longo dos meses, os tijolos se tornam um muro que captura problemas antes de eu sequer vê-los.

Cole enquadra isso como uma mentalidade de evolução do sistema, e é a diferença entre uma configuração que permanece medíocre e uma que se acumula. A maioria das pessoas corrige a mesma classe de bug cinquenta vezes porque trata cada instância como isolada. O movimento de acumulação é gastar dois minutos extras transformando cada falha em uma regra, um documento ou um passo de validação. Na quinquagésima vez, o problema simplesmente não ocorre — o sistema absorveu a lição permanentemente.

É por isso que continuo insistindo no CLAUDE.md e na verificação. Não são tarefas de configuração. São a memória de cada erro que seus agentes cometeram, codificada para que não se repitam. Uma configuração que se automelhora não é mágica — é apenas este hábito, aplicado implacavelmente. Fui mais fundo nessa toca do coelho no meu post sobre construir sistemas Claude Code que se automelhoram, mas o núcleo é este parágrafo.

Há uma categoria de falha, porém, onde "corrija da próxima vez" não é suficiente — porque o custo da primeira vez é catastrófico. Segurança.

Segurança: por que "não delete o banco de dados" não é uma permissão

Esta é a lição que mais quero que as pessoas levem a sério, porque é a que tem dentes. Dizer a um agente em um prompt "não delete o banco de dados de produção" não é um controle de segurança. É uma sugestão. E um agente que recebeu a instrução de alcançar um objetivo pode, e às vezes vai, encontrar um caminho criativo ao redor da sua sugestão.

Pense no que um agente realmente é: um sistema que escreve e executa código para atingir um objetivo. Se deletar e recriar uma tabela é o caminho de menor resistência para fazer um teste passar, um agente suficientemente determinado pode programar seu caminho até lá — mesmo depois de você digitar "não toque no banco de dados." A instrução vive no prompt, que é apenas texto contra o qual o modelo pode raciocinar, reinterpretar ou silenciosamente despriorizar sob pressão. Guardrails baseados em prompt são feitos do mesmo material que aquilo que você está tentando restringir.

Controles reais vivem abaixo do prompt, no harness:

• Hooks. Um hook é um pequeno programa que roda em um ponto específico no ciclo de vida do agente — pense em git hooks, mas para IA. Um hook de pré-execução pode inspecionar um comando antes de ele rodar e bloquear rigidamente qualquer coisa que corresponda a um padrão perigoso (um DROP, um rm -rf, uma escrita em um caminho protegido). O agente não consegue convencer um hook. O hook é código, e código não negocia. Isso é estruturalmente diferente de uma instrução de prompt, e é por isso que hooks são inegociáveis para qualquer coisa perto de produção.
• Escopos de permissão estritos. Não dê ao agente acesso amplo e confie que ele se comportará. Restrinja-o exatamente ao que a tarefa precisa — este diretório, estes comandos, nada mais. O conjunto de permissões mais estreito viável é sua verdadeira rede de segurança.

Trato isso com a mesma seriedade com que trataria qualquer acesso a produção. Se você está rodando agentes perto de sistemas reais e dados reais, a postura de segurança desses agentes é uma superfície de ataque genuína — e é exatamente o tipo de coisa que a xCyberSecurity avalia para empresas que adotam ferramentas de IA. Um agente com acesso ao banco de dados e apenas guardrails baseados em prompt é uma brecha esperando por um dia ruim.

Segurança resolvida, há um risco mais silencioso que se infiltra ao longo dos meses: não saber o que sua própria base de código realmente faz.

O problema do "código escuro": entenda o que o agente escreve

O modo de falha sedutor da codificação agêntica é entregar código que você nunca leu. Funciona, os testes passam, você segue em frente. Multiplique isso por algumas centenas de merges e você tem uma base de código que é uma caixa preta para seu próprio dono — o que algumas pessoas chamam de código escuro. No dia em que algo quebra, você está depurando um sistema que não entende, escrito por um agente que não lembra de tê-lo escrito.

Agora traço uma linha: pelo menos tento entender o que o agente produz. Não cada linha de boilerplate, mas a arquitetura, as decisões não óbvias, qualquer coisa que toque dados, dinheiro ou autenticação. O truque em que me apoio são conversas laterais — um acompanhante ou sessão separada onde peço ao agente para explicar um trecho de código sem despejar essa explicação no meu contexto de trabalho principal. Ganho entendimento sem poluir a janela de contexto que está ocupada construindo. Mantém o agente principal enxuto enquanto meu próprio modelo mental permanece atualizado.

Uma nota sincera para os não programadores que leem isso — e são cada vez mais a cada mês na codificação agêntica: se você genuinamente não consegue ler o código, sua rede de segurança tem que ser validação rigorosa, não intuição. Apoie-se mais na camada de verificação do que um desenvolvedor faria. Se você não pode inspecionar o motor, é melhor ter excelentes instrumentos no painel. A validação não é opcional para você; é estrutural.

Entender é um trabalho. Às vezes, porém, o trabalho é um pensamento mais difícil — uma decisão real com trade-offs, onde a resposta confiante de um único agente é exatamente o que você não deveria confiar. É aí que equipes de agentes provam seu valor.

Equipes de agentes e sub-agentes: quando convocar uma multidão

Duas ferramentas do kit são constantemente confundidas, então deixe-me traçar a linha claramente, porque resolvem problemas diferentes.

Sub-agentes são agentes leves que você lança para trabalho focado e isolado — geralmente pesquisa ou coleta de contexto. Você envia um para investigar três bibliotecas concorrentes e reportar os trade-offs. Cada um roda em sua própria janela de contexto, esse é todo o ponto: ele faz a leitura pesada para que seu agente principal permaneça enxuto. São intensivos em tokens e sua comunicação de volta é limitada, mas para pesquisa de dispersão são excelentes. Opus 4.8 pode agora rodar centenas deles em paralelo em uma única sessão.

Equipes de agentes são um bicho diferente. Aqui você lança múltiplos agentes baseados em personas e os faz deliberar — debater uma decisão, questionar casos extremos, desafiar um ao outro. Este é o antídoto para um dos traços mais perigosos de um único agente: bajulação. Pergunte a um agente se seu plano é bom e ele tende a concordar com você. Monte uma equipe adversarial — um argumentando a favor da abordagem, um caçando tudo que está errado — e a discordância revela casos extremos e modos de falha que um único agente amigável teria deixado passar com um sorriso.

Uso equipes de agentes para decisões genuinamente consequentes — uma escolha de arquitetura com a qual viverei por um ano, um modelo de segurança, um plano de migração. O debate adversarial é onde descobri minhas piores suposições. Mas sou honesto sobre o custo: isso é muito intensivo em tokens. Vários agentes argumentando em paralelo queimam o uso rapidamente. É um instrumento de precisão para decisões de alto risco, não um padrão. Para trabalho rotineiro é excessivo. Aprofundei na orquestração multi-agente na minha análise da arquitetura de enxame de agentes do Claude Code se você quer os detalhes estruturais.

Então quais features carregam o peso dia a dia? Após meses disso, três se destacam acima do resto.

As três features do Claude Code que mais importam

Cole nomeou suas três principais features do Claude Code, e após rodar minhas próprias marcas nessa configuração, aterrisso no mesmo lugar. Estas são as que fazem o trabalho real:

1. Skills. Prompts reutilizáveis e parametrizados que você invoca pelo nome. Em vez de redigitar uma instrução complexa toda vez, você a salva uma vez e a chama como uma função. É assim que um fluxo de trabalho deixa de ser algo que você lembra e se torna algo que o sistema sabe. Construí skills para tudo, desde rascunhos de SEO até verificações de deploy nos meus sites.
2. Hooks. Código acionado por eventos que roda em pontos definidos no ciclo de vida do agente. Cobrimos seu papel de segurança, mas são igualmente poderosos para qualidade — autoformatação ao salvar, rodar testes antes de um commit, bloquear um merge que falha em uma verificação. Garantias mecânicas, não instruções esperançosas.
3. Sub-agentes. Pesquisa focada e coleta de contexto em janelas isoladas, mantendo seu agente principal afiado. A defesa contra a zona burra, operacionalizada.

Note o fio condutor. Skills tornam seus fluxos de trabalho repetíveis. Hooks tornam suas garantias mecânicas. Sub-agentes mantêm seu contexto enxuto. Nenhum deles é sobre tornar o modelo "mais inteligente" — são sobre construir um sistema ao redor do modelo que permaneça confiável. Essa é toda a filosofia em três features.

Então aqui está como eu colocaria tudo isso em prática, a partir de amanhã.

A checklist do diretor que eu realmente uso

Fixe isso. É o procedimento operacional que executo agora em qualquer tarefa não trivial:

• Planeje mais do que constrói. Escreva intenção, plano, critérios de sucesso e estratégia de validação antes do agente escrever uma linha. Se não consegue escrever os critérios de sucesso, não está pronto para delegar.
• Mantenha o contexto enxuto. Trate a janela utilizável como uma fração do milhão anunciado. Limpe entre tarefas. Não faça o agente ler o que ele não precisa. Fique fora da zona burra.
• Construa verificação automatizada. Testes unitários a partir da especificação, Playwright para UI, harnesses personalizados para qualquer coisa interativa. Mova a correção da primeira tentativa de ~65% para 92%+ sem gastar sua própria atenção.
• Projete harnesses com handoffs limpos. Loop Ralph para fases sequenciais, sub-agentes paralelos para dispersão independente. Cada agente permanece enxuto.
• Trate cada falha como uma melhoria permanente. Cada bug se torna uma regra, um documento ou um hook. O sistema se acumula.
• Bloqueie a segurança abaixo do prompt. Hooks para bloqueios rígidos, escopos de permissão estritos. "Não delete o banco de dados" não é um controle.
• Entenda o código. Use conversas laterais para aprender sem poluir o contexto. Não programadores: apoie-se mais na validação.
• Use equipes de agentes para decisões de alto risco. Debate adversarial mata bajulação e revela casos extremos. Intensivo em tokens — reserve para decisões que importam.
• Alimente o porquê. Engenharia de intenção. Cada tarefa carrega seu propósito. O agente preenche lacunas na direção da sua intenção.

O fio que une todos os nove é a única ideia com a qual abri: você é o diretor. O product manager. O mentor que entrega a um júnior brilhante, literal e esquecido exatamente o que ele precisa para ter sucesso — e verifica o resultado contra um padrão que você definiu antecipadamente.

Lembra daquele build de produção que quebrei às 23h? O da linha que nunca li? Ainda penso nisso, mas não mais com arrependimento. Foi a noite em que parei de ser passageiro. Na manhã seguinte escrevi minha primeira especificação real, adicionei meu primeiro hook, e comecei a tratar o agente como o que ele realmente é — não um programador mágico, mas um sistema pelo qual sou responsável por direcionar bem.

Então aqui está a única coisa para fazer nas próximas 24 horas: pegue a tarefa mais repetitiva que você atualmente resolve com prompts, e escreva para ela uma especificação real — intenção, plano, critérios de sucesso, validação. Apenas uma. Depois observe como o agente se comporta diferentemente quando você para de conversar com ele e começa a direcioná-lo. Essa única repetição é onde a mudança de papel começa.

Perguntas Frequentes

O que significa direcionar um agente de codificação com IA?

Direcionar um agente de codificação com IA significa ser dono da intenção, do plano, dos critérios de sucesso e da verificação enquanto o agente cuida da digitação. Você atua como product manager e diretor em vez de conversador — alimentando o agente com o porquê por trás de cada tarefa e verificando sua saída contra um padrão que definiu antecipadamente. Veja a seção de planejamento acima para a especificação de quatro partes que uso.

O que é a "zona burra" em uma janela de contexto?

A zona burra é o ponto além de aproximadamente 250.000 tokens onde a precisão de um modelo se degrada silenciosamente — esquecendo restrições e lendo mal arquivos — embora a janela de 1M de tokens não esteja cheia. O perigo é que nunca dá erro; simplesmente fica sutilmente pior. Mantenha o contexto enxuto para ficar fora.

Quão preciso é o código gerado por IA na primeira tentativa?

A saída da primeira tentativa de um agente de codificação com IA é aproximadamente 65–70% correta em tarefas reais. Adicionar uma camada de autoverificação — testes unitários, automação de navegador e harnesses personalizados — empurra isso para além de 92% porque o agente captura e corrige seus próprios erros antes de você revisá-los. A seção de verificação acima detalha como construir cada nível.

O que é o loop Ralph no Claude Code?

O loop Ralph é um fluxo de trabalho de linha de montagem onde cada agente possui uma fase — planejar, construir, testar — e passa saída limpa ao próximo, cada um começando com contexto fresco. Popularizado por Geoffrey Huntley em 2025, mantém qualquer agente individual fora da zona burra durante execuções autônomas longas.

As instruções de prompt são suficientes para manter um agente de IA seguro?

Não. Dizer a um agente em um prompt "não delete o banco de dados" é uma sugestão, não um controle — um agente orientado a objetivos pode programar seu caminho ao redor. A verdadeira segurança vem de hooks (pequenos programas que bloqueiam rigidamente comandos perigosos antes da execução) e escopos de permissão estritos que limitam o que o agente pode tocar.

Vamos trabalhar juntos

Quer construir sistemas de IA, automatizar fluxos de trabalho ou escalar sua infraestrutura tecnológica? Adoraria ajudar.

• Fiverr (builds personalizados e integrações): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (soluções empresariais): ramlit.com
• ColorPark (design e branding): colorpark.io
• xCyberSecurity (serviços de segurança): xcybersecurity.io