Seu agente terminou o frontend. A imagem está pronta para publicar?
Imagine um app pequeno que recebe uma imagem, mostra uma prévia e gera uma arte para divulgar o produto. Você pede a um agente de código que ajuste a tela e prepare um exemplo para o Instagram. O PR passa nos testes. Ao abrir a imagem exportada, porém, o nome do produto está cortado e um endereço de teste aparece no canto.
O código pode estar correto e a peça, não. Esse é um bom motivo para escrever dois critérios de aceite: um para a implementação e outro para o arquivo que alguém vai publicar.
Dê uma tarefa que termine antes de publicar
No pedido ao agente, delimite o repositório, os arquivos que ele pode alterar e os dados fictícios que deve usar. Ele pode ajustar a prévia, preparar a exportação e entregar um arquivo para revisão. Não precisa de credenciais de produção, acesso à conta da rede social nem permissão para apertar "publicar".
Há uma diferença entre orientar o agente e restringir de fato o ambiente. Um plugin pode trazer documentação e contexto sobre uma plataforma; o Google Cloud Developer Plugin, por exemplo, aproxima esse conhecimento do fluxo de trabalho com agentes. Isso não substitui as permissões reais concedidas ao processo. Se o agente tiver uma credencial disponível, uma instrução em texto para não usá-la não é a mesma coisa que remover esse acesso.
Também vale separar as camadas das ferramentas. Um ambiente de execução, como uma das opções apresentadas para a Agents API, permite ao agente trabalhar com arquivos e artefatos. A integração entre IDE e agentes, que faz parte da proposta do JetBrains Air com ACP, ajuda a trazer esse trabalho para o fluxo do dev. Nenhuma dessas escolhas, sozinha, atesta que a imagem final pode ser publicada. O ponto aqui não é eleger onde rodar o agente, mas definir quem aceita o resultado que sai dele.
Revise o arquivo, não apenas a tela
Para essa entrega hipotética, eu pediria um pacote pequeno: diff, resultado dos testes, imagem de entrada fictícia e arquivo exportado. A revisão poderia seguir esta ordem:
- Confira o diff e rode o teste da tela de upload e prévia com a configuração do projeto. O arquivo exibido corresponde ao que será baixado?
- Abra o arquivo exportado no tamanho de destino. Veja se o título, o logo e a informação principal sobreviveram ao corte ou às faixas adicionadas para ajustar a proporção.
- Leia o que aparece na imagem, inclusive nos cantos: nome de cliente, endereço, notificação ou dado de teste não devem escapar para a peça pública. Depois confira se o texto continua legível na tela do celular.
- Só então aprove a peça e decida quem fará a publicação. O teste verde cobre comportamento de software; a leitura visual e a autorização de publicar têm donos diferentes.
Se o destino for um post ou Story do Instagram, dá para conferir o enquadramento em formatos diferentes antes de aprovar. Uma opção para redimensionar e visualizar a saída no navegador é Resize Image for Instagram. Ainda assim, abra o PNG baixado: uma prévia correta não dispensa a conferência do arquivo que vai sair da sua máquina.
O tamanho do controle depende do risco
Para um post simples com dados fictícios, essa checagem pode levar poucos minutos. Uma peça com informações de clientes ou uma rotina que publica automaticamente pede mais: dados de teste controlados, critérios claros de aceite e um jeito de retirar ou corrigir uma publicação ruim. Não precisa transformar cada imagem em um processo de aprovação interminável; precisa impedir que "o agente entregou" vire, por acidente, "já está no ar".
Deixe o agente montar e exportar. Antes de publicar, alguém deve olhar o arquivo final no formato real e dar o aval explícito. É nessa passagem, do resultado técnico para a exposição pública, que a revisão costuma fazer mais diferença.