Quando os humanos ainda precisavam sentar-se diante do teclado e orientar agentes inteligentes linha por linha, a capacidade central era escrever prompts. Hoje, os agentes já podem receber um objetivo e operar autonomamente; a nova capacidade central é a engenharia de ciclos.

Autor do artigo: CyrilXBT

Artigo compilado, fonte: ME News

Em junho de 2026, dentro de uma semana, três pessoas chegaram independentemente à mesma conclusão.

O desenvolvedor do OpenClaw, Peter Steinberger, declarou publicamente que as pessoas devem parar de escrever prompts diretamente para agentes de programação e, em vez disso, projetar sistemas cíclicos que possam automaticamente emitir instruções aos agentes.

Quase ao mesmo tempo, Boris Cherny, responsável pelo Anthropic Claude Code, também afirmou que já não insere prompts diretamente no Claude. Agora, ele executa um conjunto de ciclos que chamam automaticamente o Claude e determinam a próxima ação a ser tomada, e seu verdadeiro trabalho consiste em escrever e projetar esses ciclos.

Poucos dias depois, o engenheiro do Google Addy Osmani fez um resumo sistemático dessa prática e deu um nome:

Loop Engineering, engenharia cíclica.

Eles não criaram esse modo de trabalho do nada, mas sim deram nome a uma mudança que já estava ocorrendo silenciosamente.

Antes disso, as ferramentas subjacentes já haviam ultrapassado um ponto crítico: agentes de programação começaram a ser capazes de concluir tarefas reais sem supervisão; o custo de agendamento automático tornou-se suficientemente baixo para que executar repetidamente uma tarefa em horários programados não parecesse um desperdício; o custo de uma única execução do agente também caiu para um novo nível — em vez de gastar muito tempo pensando cuidadosamente uma vez, é possível deixar o agente tentar cinco vezes, o que pode acabar sendo até mais barato.

É exatamente por isso que este roadmap existe.

Quando os humanos ainda precisavam sentar-se diante do teclado e orientar agentes inteligentes linha por linha, a capacidade central era escrever prompts. Hoje, os agentes já podem receber um objetivo e operar autonomamente; a nova capacidade central é a engenharia de ciclos.

Abaixo está um caminho completo de 20 etapas de um operador de prompts para um designer de sistemas. É necessário avançar na ordem, pois, nesse caminho, a sequência entre as etapas muitas vezes é mais importante do que qualquer etapa individual.

A engenharia de ciclo não é uma única habilidade que se "domina" ou "não domina", mas sim uma pilha de competências empilhadas. Cada camada depende da solidez da base abaixo dela.

Por exemplo, construir o gatilho de agendamento automático na etapa 14 antes de estabelecer as condições reais de parada na etapa 10 resultará apenas em um sistema que automaticamente desperdiça dinheiro sem supervisão. Antes, ele pelo menos só desperdiçava recursos enquanto você estava olhando para a tela; agora, ele pode continuar queimando dinheiro sozinho.

Da mesma forma, se você implementar a camada de memória persistente da etapa 11 antes de estabelecer os mecanismos de verificação confiáveis das etapas 6 e 7, poderá gravar cuidadosamente as lições aprendidas de um “revisor” excessivamente permissivo que constantemente permite resultados incorretos.

Isso não apenas não ajudará o sistema a progredir, mas também fará com que experiências erradas se acumulem, transformando a camada de memória de “temporariamente inútil” em “ativamente prejudicial”.

Portanto, pular certos passos não é apenas deixar de implementar uma funcionalidade. O problema mais grave é que você estará construindo capacidades avançadas e aparentemente empolgantes sobre uma base que não consegue sustentá-las, e muitas vezes só perceberá os problemas quando o sistema já estiver em escala e causando consequências reais.

O primeiro passo real não envolve nenhuma tecnologia.

Você deve reconhecer que, no fluxo de trabalho atual, os fatores que limitam a eficiência muitas vezes já não são a capacidade do modelo, mas sim você ainda permanecendo no ciclo.

Sempre que você se senta à frente do computador esperando a resposta do modelo, lê os resultados e digita o próximo comando, você se torna o elo mais lento de todo o sistema.

O modelo pode executar, validar e tentar novamente, e essas operações são muito mais rápidas do que um humano supervisionar passo a passo a conclusão da tarefa.

Este passo não possui uma palavra-chave correspondente; é uma decisão cognitiva.

Antes de você realmente aceitar isso, todos os passos subsequentes parecerão apenas trabalho extra desnecessário, em vez de seu verdadeiro propósito — remover o maior gargalo de eficiência do sistema.

Quando o modelo apresenta problemas na saída, a reação mais natural das pessoas é geralmente adicionar uma nova regra ao prompt original.

Meses depois, essa abordagem criará um muro alto de regras: denso em conteúdo, contraditório entre si e tão extenso que o modelo não consegue processar simultaneamente todas as exigências na memória de trabalho.

Finalmente, os modelos frequentemente conseguem fazer correspondência de padrões apenas com base no conteúdo mais recente ou mais evidente, ignorando inconscientemente outras regras.

A engenharia de ciclo revolucionou esse pensamento.

Quando um problema surgir, você não adiciona apenas uma nova exigência ao prompt, mas sim acrescenta um novo componente ao sistema, por exemplo:

• Adicione um passo de verificação independente;
• Adicionar um arquivo de memória;
• Adicione um gatilho agendado;
• Adicione uma etapa de avaliação estruturada.

As as capacidades dos sistemas externos aumentam, os prompts devem se tornar cada vez mais curtos, e não mais longos.

Independentemente de a tarefa específica pertencer a qual domínio, cada execução no loop pode ser decomposta em cinco ações básicas:

Identificação, transferência, verificação, persistência, agendamento.

Descoberta

Descubra exatamente qual é a tarefa que precisa ser concluída.

Transferência

Assign the task to the model, agent, or tool responsible for execution.

Verificação

Verifique se os resultados estão corretos com base em padrões reais.

Persistência

Registre o que ocorreu nesta execução e o que foi aprendido, para evitar perder essa experiência na próxima execução.

Agendamento

Decida quando este processo será executado novamente.

O fluxo de trabalho atual da maioria das pessoas inclui apenas claramente as duas primeiras ações: identificar a tarefa e transferir a tarefa, geralmente realizadas manualmente na janela de bate-papo.

Os outros três movimentos ou não existem, ou estão escondidos dentro do próprio cérebro humano.

O núcleo da engenharia de ciclo é tornar explícitos todos esses cinco passos e, sempre que possível, automatizá-los.

Antes de começar a construir o sistema, escolha uma tarefa que você já está executando repetidamente e que possa descrever claramente os padrões de qualidade.

Não escolha a questão mais difícil nem tarefas inovadoras sem precedentes.

A primeira tarefa candidata deve atender a três condições:

1. Você precisa executá-lo repetidamente;
2. Possui padrões claros que podem ser escritos;
3. Ele tem um "estado concluído" facilmente identificável.

Em outras palavras, um colega que visualizar os resultados deve ser capaz de determinar rapidamente se a tarefa foi concluída corretamente.

Esta limitação é mais importante do que parece à primeira vista.

Se uma tarefa não tiver um critério claro de conclusão, não é possível construir um verdadeiro processo de verificação. E um ciclo sem um mecanismo de verificação confiável não é um verdadeiro ciclo, apenas um palpite sem supervisão.

Este é o passo que a maioria das pessoas mais facilmente pula, mas que é crucial para determinar se o sistema funcionará corretamente posteriormente.

Antes de escrever quaisquer instruções para o agente, escreva primeiro, em linguagem clara e natural: como deveria ser o resultado correto.

Você precisa de critérios específicos e verificáveis, não de julgamentos de qualidade vagos como “parece bom” ou “parece profissional”.

Você pode usar o seguinte modelo:

Nome da tarefa: [Nome da tarefa]

Definição Concluída (Definition of Done, DoD):

• [Padrão específico e verificável 1]
• [Padrão específico e verificável 2]
• [Padrão específico e verificável 3]

Mesmo que a saída final pareça completa e cuidadosamente revisada, a tarefa não poderá ser considerada concluída se faltar qualquer um dos itens acima.

Se você não conseguir preencher este modelo para a tarefa selecionada atualmente, volte ao passo 4 e escolha uma tarefa mais adequada para construir o ciclo.

Esta é a decisão arquitetônica mais importante em todos os sistemas cíclicos.

The role responsible for generating results must be separated from the role responsible for reviewing results.

A razão é que, quando o modelo revisa imediatamente sua própria saída após gerar o conteúdo, tende a defender a resposta recém-gerada em vez de examinar criticamente os problemas nela contidos.

Em um ciclo razoável, devem existir pelo menos dois papéis independentes:

Construtor

Os construtores têm algum espaço criativo para gerar a versão inicial do resultado.

Avaliador (Judge)

O avaliador recebe a saída do construtor e a definição de conclusão estabelecida na Etapa 5, e avalia se o resultado atende a esses critérios.

Idealmente, os avaliadores também devem ter acesso a evidências independentes que os construtores não conseguem acessar, como:

• Conjunto de testes;
• Dados originais;
• Dados em tempo real;
• Banco de dados de referência;
• Original task brief.

Assim, a avaliação do revisor poderá ser baseada em evidências reais, e não em uma nova opinião subjetiva gerada com o mesmo raciocínio do construtor.

Se o avaliador puder ver apenas a saída do construtor, ele poderá julgar apenas se o resultado "parece coerente".

Ele não consegue determinar se o resultado está realmente correto.

Portanto, o revisor deve possuir uma base objetiva verificável, ou seja, Ground Truth. Conforme o contexto específico, pode ser entendido como “fato de referência”, “dados reais” ou “base autorizada”.

Para diferentes tarefas, os critérios objetivos também variam.

Tarefa de programação

The objective basis is the test suite and the output results after the code runs in practice.

Tarefa de produção de conteúdo

A base objetiva são os materiais e resumos originais. Os revisores devem comparar lado a lado os materiais originais com o rascunho gerado.

Tarefa de pesquisa

The objective basis is the original files, papers, datasets, or authoritative sources explicitly required for use in the task.

Se você não conseguir especificar claramente o que o revisor deve verificar, então seu ciclo ainda não possui um mecanismo de verificação real, independentemente de quão confiante pareça a linguagem do revisor.

A saída do construtor e as conclusões do revisor devem seguir uma estrutura claramente definida, e não apenas linguagem natural fluente.

Caso contrário, o gerente da próxima etapa não terá informações estáveis e confiáveis para tomar decisões e encaminhar.

Os construtores podem adotar o seguinte formato de saída:

Saída do construtor:

• Conteúdo final entregue;
• Grau de confiança nos resultados;
• Uncertainties known.

O avaliador pode adotar o seguinte formato de saída:

Conclusão da avaliação:

• PASS: aprovado;
• FAIL: falha;
• PRECISA DE REVISÃO:
• Problemas específicos identificados;
• Os critérios objetivos ou evidências originais baseados nesta inspeção.

Antes de acessar o agendamento automático e a retenção automática, execute manualmente uma vez o fluxo completo “Criador—Revisor”.

Leia atentamente o julgamento fornecido pelo revisor e pergunte a si mesmo:

• Você concorda com sua conclusão?
• Ele já deixou passar um resultado que você sabia estar errado?
• Did it incorrectly negate a result that was originally qualified?

Se o avaliador aprovou um resultado que você sabe estar errado ou rejeitou um resultado que na verdade não tem problemas, corrija primeiro as bases objetivas ou os padrões completos, antes de continuar construindo o sistema.

Automatizar um passo de verificação incorreto apenas faz com que o sistema produza resultados errados mais rapidamente.

Para tornar os cinco passos acima mais específicos, podemos observar uma tarefa comum: transformar uma matéria-prima em um artigo completo.

Passo 5: Definir a conclusão

O critério de conclusão desta tarefa pode ser:

• Cada fato no rascunho pode ser rastreado até um conteúdo explícito na fonte original;
• O rascunho atende a todos os requisitos específicos do boletim, incluindo extensão, tom e estrutura;
• O ponto central do texto original foi mantido claramente, sem ser diluído por conteúdo preenchimento sem sentido.

Passo 6: O construtor gera o rascunho

O construtor recebe os materiais brutos e o brief de conteúdo para gerar uma versão rascunho.

Ao mesmo tempo, também é necessário listar claramente as incertezas existentes durante o processo de escrita, por exemplo:

• Se um determinado número realmente aparece nas fontes originais;
• A conclusão é explicitamente declarada no texto original ou inferida pelo modelo?
• Whether a fact lacks sufficient sources.

Passo 7: O revisor verifica em relação ao texto original

The reviewer receives both the draft and the original materials, not just the draft.

Ele precisa verificar separadamente os três critérios definidos e fornecer uma conclusão individual de aprovado ou reprovado para cada critério, em vez de comprimir todos os dimensionais em uma única pontuação composta vaga.

Combinar três padrões diferentes em uma única avaliação geral oculta qual dimensão específica está com problemas. Esta é a causa mais comum pela qual muitos ciclos que originalmente funcionavam perdem seu valor de feedback.

Passo 8: Entrega estruturada

A conclusão do avaliador deve ser um objeto estruturado, não um parágrafo com linguagem reservada.

Ele precisa gerar três resultados claros de aprovação ou reprovação, fornecendo razões específicas para cada falha.

Passo 9: Verificação manual do mecanismo de revisão

Executar manualmente um fluxo completo antes da execução automática do sistema pode ajudá-lo a identificar se os avaliadores estão sendo muito brandos ou muito rigorosos.

Revisores muito brandos podem, por causa da fluidez do artigo, ignorar os dados fictícios contidos nele.

Um revisor excessivamente rígido pode rejeitar indevidamente um artigo adequado por causa de uma preferência pessoal de estilo nunca mencionada no briefing.

Esses dois problemas são muito comuns na primeira configuração.

Descobri-las após o sistema ter sido executado 50 vezes sem supervisão é muito mais caro do que resolver os problemas durante o primeiro teste manual.

Fase 3: Completar os componentes ausentes no ciclo Passo 10: Estabelecer o gerenciador e as condições reais de parada

O gerente é responsável por ler as decisões dos revisores e determinar a próxima ação.

As condições de parada também devem existir no gerenciador e devem ser escritas como lógica rígida e explícita, e não como instruções flexíveis que o modelo pode contornar por meio de autointerpretação.

Por exemplo:

Condição de parada:

• Número máximo de modificações: 3;
• Quando a terceira revisão ainda falhar, envie o histórico completo para processamento humano e não inicie uma quarta modificação;
• Padrão de qualidade: Cada item definido deve exibir PASS;
• Limite de orçamento: Se o custo da tarefa exceder X ou o tempo de execução exceder Y, a tarefa deve ser interrompida imediatamente, independentemente do estado atual.

Um loop sem uma condição de parada real não é um sistema, mas uma dívida que aguarda a exposição de riscos.

Por que instruções subjetivas, como “parar quando o resultado for bom o suficiente”, não são confiáveis?

Porque é apenas uma sugestão.

Quando o modelo já foi modificado várias vezes consecutivas sem aprovação, para fornecer um final aparentemente satisfatório à tarefa, ele provavelmente convence a si mesmo de que “esta versão já está suficientemente próxima do padrão”, reduzindo assim automaticamente seus critérios de julgamento.

Em contraste, o número de iterações verificadas mecanicamente pelo código ou regras explícitas que o gerente não pode contornar por raciocínio não apresentam esse problema.

Se um ciclo começar do zero cada vez que for iniciado, ele não lembrará o que aprendeu na execução anterior.

Portanto, é necessário adicionar uma camada de persistência simples.

Você pode criar um arquivo para cada nova experiência real e resumir em uma frase no topo do arquivo:

• O que aprendeu;
• O que foi corrigido;
• Why is this experience important?

O princípio fundamental é: registrar apenas novos conhecimentos que ainda não foram salvos em outro lugar.

Memórias repetidas não são conhecimento, mas ruído.

Para que o mecanismo de persistência permaneça eficaz a longo prazo, é necessário manter moderação durante a gravação.

É comum ter a impulsão de registrar todos os detalhes da execução, mas isso apenas replica o problema do “prompt inchado” mencionado na Etapa 2, apenas que desta vez, o objeto inchado é a pasta de memória.

As experiências verdadeiramente dignas de registro são aquelas que, se esquecidas, exigem muito tempo para serem descobertas novamente, e não simples registros de operações normais que ocorreram conforme o esperado.

Apenas aumentar o mecanismo de persistência acabará gerando problemas semelhantes aos de prompts extremamente longos.

Ao longo do tempo, o sistema acumula dezenas de arquivos, muitos dos quais contêm apenas ligeiras variações na mesma pergunta.

Portanto, os arquivos de memória devem ser organizados em intervalos fixos. Executar isso semanalmente geralmente é uma frequência razoável.

O processo de organização inclui:

• Revisar memórias existentes;
• Fundir conteúdo duplicado;
• Comprimir várias experiências semelhantes em um princípio mais claro;
• Remove content that has been proven incorrect or outdated.

O objetivo não é acumular cada vez mais arquivos, mas obter um número menor de conhecimentos com maior densidade de informação.

Muitas pessoas pularão completamente este passo, pois ele não traz novas habilidades visíveis imediatamente, mas apenas previne problemas futuros.

Precisamente por falta de feedback imediato, deve ser claramente incluído no agendamento, em vez de ser deixado para quando alguém perceber que a pasta de memória já se tornou difícil de gerenciar.

Na prática, essa tarefa de “arrumar depois, quando tiver tempo” geralmente nunca acontece, até que o desempenho do sistema já comece a decair devido a uma grande quantidade de memórias conflitantes, desatualizadas e parcialmente relacionadas disputando a janela de contexto.

Ao iniciar cada nova tarefa, faça o ciclo primeiro escanear um resumo de uma frase no arquivo de memória para determinar quais experiências são realmente relevantes para a tarefa atual e carregue apenas esses conteúdos relacionados.

Ao mesmo tempo, deve-se exigir claramente ao sistema que, se não houver nenhum conteúdo na memória atual aplicável à tarefa atual, informe diretamente que não há experiência aplicável.

Não force experiências passadas a serem aplicadas a um novo problema completamente diferente apenas porque um sistema de memória já existe.

Em seguida, é necessário decidir quando este ciclo será executado automaticamente sem intervenção humana.

As formas de gatilho podem incluir:

• Tarefa agendada Cron;
• Monitor de alterações de arquivo;
• Gatilho de ciclo baseado em calendário;
• Triggered when an external event or state changes.

Este passo transformará um sistema que só pode ser iniciado manualmente por você em um sistema que continua funcionando enquanto você dorme.

Ironicamente, este é geralmente o passo mais fácil de toda a lista, mas também o que muitas pessoas ainda não implementam, mesmo após concluírem os outros componentes.

Antes de usar o ciclo para qualquer tarefa importante, é necessário testar ativamente quatro modos de falha.

Teste 1: Tarefa impossível

Give the system a truly unsolvable task version to confirm that the manager can exit according to the stop conditions, rather than entering an infinite loop.

Se um ciclo for testado apenas em tarefas que conseguem ser concluídas com sucesso, nunca provou ter a capacidade de falhar com elegância.

Teste 2: Resultado que parece razoável, mas está incorreto

Forneça aos revisores uma saída que você sabe com certeza conter erros sutis.

Este resultado deve ser lido de forma muito fluida, mas contém um erro factual ou lógico que você intencionalmente inseriu.

Observe se o revisor consegue identificar problemas, em vez de aprovar apenas porque o conteúdo parece razoável.

Teste 3: Construtores e revisores compartilham cegueiras do modelo

Se o construtor e o avaliador usarem o mesmo modelo subjacente, é possível intencionalmente inserir um erro típico que esse modelo comete frequentemente, para observar se o avaliador o ignorará.

Se o avaliador e o construtor tiverem as mesmas cegueiras, a separação de papéis projetada na Etapa 6 perde seu sentido.

Teste 4: Calcular o custo de operação no pior cenário

Calculate the cost of this loop under the worst-case scenario, using the most expensive model invocation, the maximum number of modifications, and the longest possible output within reasonable limits.

E então pergunte-se honestamente:

Se esse número aparecesse na sua fatura real, você se sentiria desconfortável?

Concluir estes quatro testes antes de processar tarefas importantes no ciclo de confiança permite identificar antecipadamente a maioria dos problemas potenciais.

Caso contrário, esses problemas provavelmente aparecerão pela primeira vez diante dos clientes e gestores, ou diretamente na sua fatura, e não em um teste sob seu controle.

Quando o ciclo puder operar de forma estável, não permita que todos os personagens usem o mesmo modelo que você mais gosta.

Os diferentes papéis no ciclo têm requisitos distintos para as capacidades do modelo.

Buildadores

Os construtores geralmente devem usar o modelo mais poderoso.

Porque ele realiza o principal trabalho de raciocínio complexo e geração de conteúdo. Se um modelo com capacidade insuficiente for usado aqui, a qualidade do resultado da primeira versão diminuirá, podendo exigir mais rodadas de revisão posteriormente.

Finalmente, o custo de corrigir uma versão inicial de baixa qualidade pode ser maior do que o custo de usar um modelo mais potente desde o início.

Revisor

O revisor é responsável por realizar verificações com base em critérios claros, geralmente não exigindo grande capacidade criativa.

Quando os critérios forem suficientemente específicos, um modelo menor, mais barato e mais rápido também pode realizar tarefas de revisão de forma confiável.

Um pequeno modelo, se operar com base em uma lista de verificação extremamente clara, pode alcançar estabilidade próxima à de um grande modelo, mas com custos e latência significativamente menores.

Gerente

O gerente apenas roteia conforme regras já definidas, raramente precisando usar o modelo mais caro.

Sua tarefa é executar lógicas já definidas, e não realizar raciocínio aberto.

Além disso, independentemente do desempenho dos construtores e revisores, o gerenciador é executado pelo menos uma vez em cada iteração, portanto, seu custo por chamada individual merece atenção especial.

A configuração em camadas adequada geralmente é:

• O modelo forte é responsável pela construção;
• Modelos baratos e estáveis são responsáveis por revisões regulares;
• Modelos ou programas de regras de baixo custo são responsáveis pelo roteamento e gerenciamento.

A otimização de custos verdadeiramente significativa no sistema de ciclo geralmente vem desse tipo de correspondência de papéis de modelo.

Muitas pessoas acreditam que controlar custos significa reduzir o número de ciclos ou iterações. Na verdade, um método mais eficaz é alinhar o custo do modelo com a dificuldade real de cada papel no ciclo.

Após o primeiro ciclo ser bem-sucedido, é fácil tentar imediatamente construir vários ciclos simultaneamente, processando cinco tarefas diferentes em paralelo.

Mesmo que a arquitetura atual já suporte essa expansão, deve-se conter esse impulso.

Você deve primeiro deixar o primeiro ciclo funcionar de forma estável por tempo suficiente, até que realmente não precise mais verificar cada saída dele de perto.

Não se trata de uma demonstração que aconteceu de funcionar perfeitamente enquanto todos estavam assistindo atentamente, mas sim de uma que continua a passar em inspeções manuais após um período de operação real.

Apenas após atingir esse estado, deve-se começar a construir o segundo ciclo.

O segundo ciclo deve lidar com uma tarefa claramente diferente da primeira.

Isso é necessário para verificar se a arquitetura subjacente possui verdadeira generalidade, e não apenas otimizações cada vez mais refinadas para a mesma tarefa.

Após executar vários ciclos simultaneamente, é necessário criar uma visão de monitoramento unificada para rastrear centralmente os custos e os gatilhos de condições de parada de todos os ciclos, em vez de verificar cada ciclo separadamente.

Visto isoladamente, um orçamento de tarefas cíclicas pode ser totalmente razoável.

Mas se as dez rotinas operarem todas dentro de seus orçamentos individuais, seu custo total ainda pode atingir um nível surpreendente.

Como os dados individuais de cada ciclo parecem normais, esse risco geralmente só é detectado quando a fatura consolidada é gerada.

Além das tarefas concluídas com sucesso, é necessário registrar explicitamente cada disparo de condição de parada.

Se um ciclo frequentemente atingir o número máximo de modificações, enquanto outros ciclos raramente apresentam essa situação, o sinal transmitido pode não ser “esta tarefa é particularmente difícil”, mas sim:

• Os critérios de avaliação estão definidos incorretamente;
• Os revisores são muito rigorosos, fazendo com que nenhum resultado seja aprovado;
• O sistema verificou os critérios objetivos incorretos;
• Concluir a definição em si apresenta problemas.

Se forem rastreados apenas os resultados bem-sucedidos e cada atualização manual for considerada um evento isolado e independente, esse padrão no nível de design não será detectado.

O critério mais evidente para determinar se a mudança de mentalidade foi realmente concluída é que os indicadores aos quais você presta atenção no dia a dia mudaram.

O operador de prompts se preocupa com:

• Quantas instruções válidas foram escritas hoje?
• Qual prompt funciona melhor;
• Como escrever prompts de forma mais refinada.

Os designers do sistema estão preocupados com:

• Quantos ciclos estão atualmente em execução;
• Qual é a confiabilidade de cada ciclo?
• Quanto tempo o sistema liberou para si mesmo;
• Quais trabalhos já não precisam de supervisão humana.

Se você ainda mede sua produtividade pela quantidade de prompts inseridos, então a mudança de mentalidade exigida no Passo 1 ainda não foi realmente concluída.

O último passo já não se trata mais completamente do seu próprio sistema.

It is used to verify whether you truly understand this method.

Você precisa tentar explicar a outra pessoa cinco ações básicas sem depender de termos complexos:

Identificação, transferência, verificação, persistência, agendamento.

Se você conseguir levar outra pessoa a construir seu primeiro ciclo apenas com esses cinco passos e os anteriores, significa que você já realizou a verdadeira transformação descrita neste roteiro.

Você não é mais a pessoa que fica dentro do loop, inserindo continuamente o próximo comando.

Você se tornou a pessoa que está fora do ciclo, projetando o sistema e observando-o funcionar por conta própria.

Quatro custos que se acumulam silenciosamente após pular etapas

No final do artigo, é necessário fornecer um aviso.

Pular etapas neste roadmap geralmente não causa falhas imediatas no sistema.

Seu fracasso geralmente é silencioso e até difícil de perceber por muito tempo, até que os problemas já tenham se acumulado até um grau considerável.

Quando você pula os passos 6 e 7, sem estabelecer revisores verdadeiramente independentes e sem fornecer base objetiva confiável, a validação da dívida começa a se acumular.

O ciclo ainda parece estar funcionando normalmente, pois os resultados gerados "parecem razoáveis".

Só quando um erro se acumular ao longo de dezenas de execuções e for finalmente descoberto, você perceberá que o sistema nunca realmente avaliou se os resultados estavam corretos desde o início.

A degradação da compreensão pode ocorrer quando você pular o passo 20.

Você ainda está executando o ciclo que construiu anteriormente, mas já não consegue explicar claramente por que cada componente existe nem diagnosticar eficazmente falhas no sistema.

A razão é que você nunca realmente internalizou a lógica por trás dessa arquitetura.

Cede-se ao compromisso cognitivo se a etapa 1 nunca for realmente concluída.

Mesmo após o sistema de verificação ter comprovado sua confiabilidade ao longo do tempo, você ainda revisa manualmente cada saída por hábito.

Esse comportamento parece cauteloso, mas na verdade anula todo o sentido de construir o sistema.

Se pular a etapa 10 e não definir uma condição de parada real para o loop, pode ocorrer consumo descontrolado de tokens e custos de chamada.

Você geralmente não percebe o problema assim que o sistema começa a sair do controle, mas sim só quando a fatura final aparece, percebendo que o ciclo já realizou muitas chamadas inválidas.

Todos os custos acima podem ser evitados.

A maneira de evitá-las é sempre a mesma disciplina:

Construa na ordem, não pule etapas que pareçam menos impressionantes.

O que realmente funciona, muitas vezes, são justamente as partes mais chatas:

• Definição clara e concluída;
• Condições de parada confiáveis;
• Evidências objetivas verificáveis;
• Mecanismo de avaliação independente.

Em contraste, as partes que soam mais atraentes — prompts inteligentes, diagramas de arquitetura de sistema complexos — são muito menos importantes do que as pessoas imaginam.

O que realmente determina a qualidade do sistema é se o sistema que você construiu sabe:

• Quando você está certo?
• Quando você está errado;
• Quando deve parar.

Essa é a única diferença entre o operador de prompts e o projetista do sistema.

A diferença não está em quem é mais inteligente nem em quem consegue escrever prompts mais elaborados.

A verdadeira diferença é se você tem disciplina suficiente para construir cuidadosamente as partes chatas, que são fáceis de pular, mas que realmente determinam a confiabilidade do sistema.