Pausa Tática: Um Agente, Dois Papéis, Uma Janela

Como o mesmo agente executa um processo real, para quando um de nós encontra um problema, me ajuda a mudar o sistema e volta ao trabalho sem sair da conversa.

O que você vai encontrar neste artigo

A noite em que um sistema de logística finalmente mostrou uma incompatibilidade entre a base e a análise, depois de mais ou menos uma semana de tentativas.
Por que tanto a pessoa quanto o agente precisam conseguir pedir uma pausa tática.
Como o mesmo agente muda de executor para assistente técnico e depois volta a executar, tudo na mesma janela.
O que pesquisas sobre iniciativa mista, programação ao vivo e geração interativa de código dizem sobre esse jeito de trabalhar.
Um prompt prático para definir condições de parada, autoridade e a comparação antes e depois.

Artigo completo

Por quase uma semana a gente não conseguia entender por que um sistema de despacho, coleta automática e análise de pedidos de transporte dava o resultado errado.

Os dados e os campos estavam na base, e cada parte parecia normal quando a gente olhava separadamente. Mesmo assim, a base e a análise não batiam, e o erro passou por uma sequência de versões, mais ou menos da 0.5 até a 0.8.

Numa noite eu abri o projeto no Codex e parei de olhar para ele como um monte de arquivos.

Eu estava vendo o produto rodar. Na mesma janela apareciam os campos da base, o código, os logs, o resultado da análise. O agente fazia o trabalho de verdade: puxava os pedidos, conectava registros, calculava valores, separava um tipo de carga de outro. E ali em cima do processo rodando estava o mesmo agente, disponível para conversar comigo sobre o que ele próprio estava fazendo.

Aí ficou interessante.

Às vezes eu via o erro primeiro. Dizia: para, a base e a análise não estão batendo aqui, olha estes campos.

Mas o caminho que mais me surpreendeu funcionava ao contrário. Eu tinha colocado condições de parada no prompt. Se sumisse um campo obrigatório, se o esquema não batesse, se um cálculo saísse da faixa esperada, o agente não podia simplesmente seguir em frente e produzir mais uma resposta confiante. Tinha que parar.

E parou.

Na prática, ele me disse: olha, achei um erro. Este campo existe na base, mas a análise não está usando direito. Vamos corrigir.

Eu olhei a mudança que ele propôs e respondi: não, a ligação em si está errada. Vamos reconstruir esta parte de outro jeito.

A gente mudou a lógica, rodou o mesmo caso outra vez e viu o resultado mudar. A versão 0.9 funcionou.

Foi o momento em que fiquei ali pensando: uau.

Eu sei o que estou olhando. Não tem um engenheiro pequeno escondido dentro do modelo que de repente ficou preocupado com a minha base de dados. Não tem consciência ali. É geração, probabilidade, contexto, ferramentas e instruções. Tudo bem.

Mas sentado na frente daquela tela, aquilo parecia trabalho em parceria. Qualquer um dos dois podia perceber o problema. Qualquer um podia pedir a pausa. Depois a gente olhava para o mesmo estado do sistema, mudava junto e colocava o mesmo agente para trabalhar outra vez.

É uma experiência bem diferente de pedir para um chatbot escrever código.

Qualquer um dos dois pode pedir a pausa

A comparação que funciona na minha cabeça vem dos jogos de estratégia.

A situação está andando. As unidades se movem, os recursos vão embora, alguma coisa já está dando errado do outro lado do mapa. Você aperta a pausa tática. Nada some. Todas as posições ficam na tela, mas agora dá para olhar com calma, mudar a decisão e continuar do mesmo ponto.

Com o agente foi quase igual.

O sistema roda. Aparece uma diferença. Se eu vejo primeiro, digo para. Se o agente encontra uma das condições que coloquei no prompt, ele para sozinho e devolve a iniciativa para mim. A gente olha as evidências, muda o código, o prompt, o contrato de dados ou a arquitetura, depois roda o mesmo caso de novo.

O ciclo é simples:

execução → uma das partes encontra uma diferença → pausa tática → mudança em conjunto → nova execução

As condições de parada dão ao agente uma forma clara de me devolver o problema. Podemos entender o que precisa mudar antes que o erro se espalhe para a próxima operação.

O mesmo agente muda de papel

No modo de execução, o agente faz parte do produto. Ele processa pedidos, lê a base, aplica regras e entrega um resultado operacional.

Durante a pausa, o mesmo agente vira meu assistente técnico. Lê os logs, compara os campos, segue a ligação, propõe uma correção, muda a instrução ou me ajuda a repensar a arquitetura. Eu posso aceitar, recusar ou dizer que o problema está uma camada mais fundo.

Depois ele volta para execução.

Esse detalhe importa. Eu não copio o erro do produto para um ticket separado, reconstruo tudo para outro desenvolvedor, abro outro chat e tento explicar o que aconteceu cinco minutos atrás. O histórico de trabalho já está ali. O agente que acabou de executar o processo tem no contexto o código, a saída do terminal, as minhas decisões e o resultado errado.

Tecnicamente, o modelo não reescreve os próprios pesos. Ele muda o sistema de trabalho ao redor: código, prompts, configuração, testes, esquemas, consultas e ligações entre componentes. Do meu lado, a colaboração continua: o mesmo agente, o mesmo projeto, o caso que já estamos olhando.

Uma janela muda a conversa

O que tornou aquela noite útil foi ter tão pouco a reconstruir. O produto, o código, os campos e os logs estavam na nossa frente. Quando questionei a ligação, podíamos examiná-la no mesmo contexto de trabalho.

A documentação da OpenAI descreve as partes desse ambiente: um terminal integrado para executar comandos e examinar a saída, e um navegador integrado para olhar juntos o site ou aplicativo local. O fluxo de telemetria no macOS percorre uma sequência próxima: adicionar eventos de diagnóstico, executar o aplicativo, observar uma pessoa usando a função, ler os logs e propor uma correção. É parecido com o que me ajudou. A próxima mudança começa em alguma coisa que conseguimos ver acontecendo.

Há uma ligação com pesquisas mais antigas. Em Supporting exploratory data analysis with live programming, 15 profissionais de dados trabalharam com alterações que atualizavam os resultados automaticamente. A maioria preferiu essa resposta imediata, e as sessões registradas tiveram menos erros do que os históricos usados na comparação. Eles também sentiram falta de um histórico visível. No meu trabalho, as duas coisas importam: consigo ver o resultado atual e voltar à conversa que explica por que o mudamos.

A pausa dá a cada um a sua vez

Os pesquisadores chamam a ideia mais ampla de interação de iniciativa mista. O artigo de Eric Horvitz na CHI de 1999 descreve a combinação de controle humano direto e raciocínio automatizado: a pessoa pode orientar e corrigir o sistema, enquanto ele assume parte do trabalho e apresenta um próximo passo útil.

Para mim, o detalhe útil é a iniciativa poder mudar de lado. Eu posso interromper porque o resultado visível parece errado. O agente pode parar porque encontrou uma das condições que defini. Nenhum dos dois precisa esperar o processo inteiro produzir outro resultado ruim.

As Guidelines for Human-AI Interaction, de 2019, incluem correção eficiente, controles gerais claros e consequências visíveis das ações do usuário. O trabalho envolveu avaliação de 20 produtos com IA e um estudo com 49 profissionais de design. No nosso caso, essas ideias têm uma forma concreta: parar, decidir o que mudar, executar outra vez e ver a consequência.

O Grounded Copilot, premiado como Distinguished Paper na OOPSLA de 2023, observou 20 participantes em quatro linguagens de programação e descreveu aceleração e exploração. Às vezes o programador sabe o próximo passo e quer ajuda para executá-lo; às vezes precisa de ajuda para examinar as opções. Nossa pausa passa entre essas situações. O agente executa, investigamos juntos e depois ele retoma o processo alterado.

O artigo da CHI de 2025 Need Help? Designing Proactive AI Assistants for Programming também trata o contexto de programação como um espaço compartilhado para sugestões mais relevantes. Isso ajuda a explicar por que a mesma conversa importava para mim. Podíamos apontar para o campo e seu uso na análise, sem reconstruir o problema a partir de uma descrição.

O que uma nova execução pode mostrar

A primeira proposta do agente foi útil, mesmo que eu a tenha recusado. Ela mostrou onde olhar. Eu achava que a própria ligação precisava mudar, e a nova execução permitiu testar essa decisão.

Há evidências sobre o valor desse tipo de correção. Em LLM-Based Test-Driven Interactive Code Generation, 15 programadores usaram testes para esclarecer a intenção. Eles tiveram uma probabilidade significativamente maior de avaliar o código gerado corretamente e relataram menor carga cognitiva durante a tarefa. Uma avaliação separada e de maior escala usou feedback idealizado: a precisão média pass@1 melhorou 45,97 pontos percentuais em até cinco interações, com quatro modelos e dois conjuntos de dados em Python. Esse número pertence à avaliação idealizada; eu não o usaria para prever o ganho no meu projeto.

O Let's Fix this Together: Conversational Debugging with GitHub Copilot estudou 16 profissionais da indústria. O sistema reunia contexto antes de responder e apoiava a troca de turnos. Comparado com a experiência anterior de depuração assistida por IA no Visual Studio, o estudo relatou melhora de 2,5 vezes na localização do erro e de 3,5 vezes na correção.

São sistemas específicos e tarefas controladas; a versão 0.9 é um caso pessoal. O que os aproxima, para mim, é a possibilidade de examinar uma proposta, corrigi-la e ver o efeito da correção. Quero essa possibilidade dentro do próprio modo de trabalho do agente.

O prompt precisa de dois modos e uma parada de verdade

Hoje eu acho que o agente deve receber dois modos claros antes de começar.

No modo de execução, ele cumpre a função combinada. Na pausa tática, ele interrompe o processo, preserva o estado atual, mostra as evidências e espera uma decisão quando a mudança afeta arquitetura ou regra de negócio.

A transição pode começar dos dois lados. Eu posso pedir a pausa quando o resultado visível está errado. O agente pode pedir quando encontra uma condição definida.

Na prática, a instrução fica assim:

Trabalhe no modo de execução. Se eu disser "pausa", ou se você detectar incompatibilidade de esquema, campo obrigatório ausente, teste com falha ou resultado fora da faixa definida, pare e entre na pausa tática. Diga diretamente que encontrou um erro. Mostre os fatos observados, indique a causa provável e proponha opções. Não mude a arquitetura nem as regras de negócio sem a minha decisão. Depois da mudança aprovada, rode o mesmo caso com a mesma entrada e mostre o resultado antes e depois.

A parada precisa ser de verdade. Um agente que avisa sobre o erro e continua processando não parou. Só colocou um aviso em cima de um resultado ruim.

Pausar esse agente não congela serviços externos nem o trabalho de outras pessoas no sistema. Guarde uma cópia da entrada para a comparação e confira o estado externo atual antes de retomar o trabalho real.

Rodar outra vez também importa. Se a entrada muda, a base muda e o código muda ao mesmo tempo, você não sabe o que resolveu o problema. Use o mesmo caso. Guarde as evidências. Compare antes e depois.

O que eu chamo de parceria

Existe um objeto compartilhado na nossa frente. O agente consegue agir sobre ele. Eu consigo inspecionar o que ele fez. Qualquer um dos lados pode iniciar a parada. Durante a pausa, o agente contribui com análise técnica e eu mantenho a autoridade sobre arquitetura, sentido de negócio e a decisão de continuar. Depois ele age outra vez e os dois veem a consequência.

O que me agradou foi conseguir acompanhar o problema enquanto ele mudava. Podíamos discutir a ligação, tentar outra versão e ver o que acontecia no produto em execução.

Naquela noite a gente apertou continuar. A versão 0.9 usou o campo direito e a análise finalmente bateu com a base.

Eu sabia exatamente o que estava vendo.

Mesmo assim, falei uau.

Aplicação prática

Dê ao agente um modo de execução e um modo de pausa tática antes de iniciar.
Permita que qualquer lado peça a pausa. A pessoa pode reagir ao resultado visível, e o agente pode reagir às condições definidas no prompt.
Defina condições observáveis: incompatibilidade de esquema, campo ausente, teste com falha, quantidade inesperada de registros ou resultado fora de uma faixa conhecida.
Durante a pausa, permita análise e propostas. Mudanças de arquitetura e regra de negócio continuam sob autoridade humana.
Rode o mesmo caso com a mesma entrada e mostre o resultado antes e depois.
Preserve a conversa, os logs e o histórico de mudanças. É o estado compartilhado que faz o ciclo funcionar.

Em poucas palavras

O mesmo agente consegue executar um processo real, parar, ajudar a mudar o sistema e voltar à execução dentro da mesma conversa.
A pausa tática pode começar pela pessoa ou pelo agente, dentro das condições definidas no prompt.
A sensação de parceria vem do contexto compartilhado, da troca de turnos, das evidências visíveis e da capacidade de agir sobre o mesmo objeto.
A nova execução torna visível o efeito da mudança feita em conjunto no produto em funcionamento.

Fontes

Eric Horvitz. Principles of Mixed-Initiative User Interfaces. CHI, 1999.
Saleema Amershi et al. Guidelines for Human-AI Interaction. CHI, 2019.
Shraddha Barke, Michael James, Nadia Polikarpova. Grounded Copilot: How Programmers Interact with Code-Generating Models. OOPSLA, 2023.
Sarah Fakhoury et al. LLM-Based Test-Driven Interactive Code Generation: User Study and Empirical Evaluation. IEEE Transactions on Software Engineering, 2024.
Yasharth Bajpai et al. Let's Fix this Together: Conversational Debugging with GitHub Copilot. IEEE VL/HCC, 2024.
Valerie Chen et al. Need Help? Designing Proactive AI Assistants for Programming. CHI, 2025.
Robert DeLine e Danyel Fisher. Supporting exploratory data analysis with live programming. IEEE VL/HCC, 2015.
OpenAI. Integrated terminal.
OpenAI. Built-in Browser.
OpenAI. Add macOS telemetry and inspect live app logs.