Quando uma aplicação apoia pedidos, propostas ou acompanhamento de clientes, duas alterações incompatíveis podem interromper trabalho da equipa. A decisão de usar vários agentes deve considerar essa dependência. Dividir tarefas só ajuda se houver responsabilidade pela integração e verificação do comportamento que o negócio precisa de preservar.
Começa por separar o trabalho e a autoridade
Um agente pode procurar falhas enquanto outro prepara uma correção, mas encontrar um problema não lhe dá automaticamente autorização para o resolver. Escreve essa distinção antes de começar. O revisor deve saber que entrega um relatório; o construtor deve saber que avalia os achados e implementa as alterações aceites.
Tenho usado esta separação no trabalho com aplicações: peço a uma IA que construa e a outra que analise. Depois levo o relatório a quem está responsável pela construção. Isso permite aproveitar uma segunda leitura sem criar dois intervenientes a reescrever a mesma decisão por caminhos diferentes.
O relatório também não é uma ordem para aceitar tudo. Um achado pode partir de uma interpretação errada do comportamento esperado, ignorar uma restrição do projeto ou sugerir trabalho que não faz parte do pedido. Quem integra precisa de confrontar a sugestão com os requisitos antes de mexer no código.
Imagina uma aplicação de inscrições num evento. Um agente altera a validação do formulário enquanto o outro decide simplificar os campos obrigatórios. Os dois podem considerar o próprio trabalho correto, mas estão a responder a regras diferentes sobre o que constitui uma inscrição válida e quem pode completá-la.
É por isso que planear a aplicação antes de programar também inclui decidir quem tem autoridade sobre as regras partilhadas. A pessoa que coordena precisa de conseguir responder a uma pergunta concreta: se os agentes discordarem sobre o comportamento, qual é a decisão do projeto que prevalece?
Para preparar o próximo passo, consulta Desenvolver aplicações com IA.
Limita as zonas de edição com exemplos concretos
Dizer que cada agente tem uma tarefa diferente pode ser insuficiente quando essas tarefas dependem dos mesmos ficheiros. Identifica as áreas onde cada um pode escrever e os componentes partilhados que exigem coordenação. Se uma alteração atravessar esse limite, o agente deve parar nessa dependência e explicar o que precisa.
Na aplicação do evento, um agente pode preparar os textos de confirmação e outro analisar a acessibilidade do formulário. Essa divisão é relativamente clara enquanto o segundo entrega apenas sugestões. Torna-se menos clara se ambos começarem a alterar a estrutura que gera a confirmação depois da inscrição.
Uma instrução útil descreve tanto a responsabilidade como o resultado esperado: rever o percurso de inscrição, listar problemas reproduzíveis e entregar recomendações sem editar. Para quem constrói, a instrução pode delimitar o formulário e exigir um aviso antes de mudar a regra partilhada de lotação do evento.
Evita assumir que nomes de pastas resolvem todas as dependências. Uma mudança num campo pode afetar uma exportação, uma mensagem e uma consulta noutra área. Mesmo com ficheiros separados, continua a existir a possibilidade de os agentes introduzirem comportamentos incompatíveis, sem qualquer conflito visível na edição.
O objetivo destes limites é tornar os cruzamentos explícitos. Quando uma tarefa precisa de atravessar várias áreas, pode ser mais claro entregá-la por inteiro a um responsável e reservar a segunda leitura para o final. A quantidade de agentes deve acompanhar a divisão real do trabalho.
Pede achados que possam ser confirmados
Um relatório de revisão deve mostrar onde está o problema, como o reproduzir e que consequência tem para o utilizador. Expressões como melhorar a qualidade ou tornar o código mais robusto não chegam. Quem vai corrigir precisa de distinguir uma falha demonstrada, uma hipótese e uma preferência do revisor.
No exemplo das inscrições, um achado útil diria que um participante consegue submeter duas vezes o mesmo pedido numa determinada sequência. Deve explicar os passos observados e o comportamento esperado. Sugerir simplesmente uma nova organização do formulário não permite perceber se existe uma falha ou apenas outra opção de desenho.
Pede também que o revisor identifique a versão que analisou. Se a construção continuar entretanto, parte das conclusões pode deixar de se aplicar. Antes de implementar, confirma que o problema ainda existe e que a solução proposta não interfere com uma alteração entretanto concluída no mesmo percurso.
O construtor deve responder aos achados com decisões compreensíveis: corrigido e verificado, adiado por um motivo concreto ou não confirmado com a evidência disponível. Esta resposta evita que um relatório extenso fique a circular como se todos os pontos fossem problemas ativos e igualmente urgentes para o projeto.
Integra as alterações numa sequência conhecida
A integração precisa de um responsável e de uma ordem, mesmo quando partes do trabalho foram feitas em paralelo. Antes de juntar alterações, verifica se partem da mesma decisão e se continuam compatíveis. Depois testa o percurso completo, porque duas partes corretas isoladamente podem falhar quando passam a funcionar juntas.
Se o formulário passar a pedir uma escolha adicional, a confirmação precisa de a apresentar corretamente e a gestão do evento precisa de a receber. Não basta confirmar que cada ecrã abre. A validação acompanha a inscrição desde a introdução dos dados até ao resultado usado pela equipa.
Esta disciplina aproxima-se de testar uma automação antes de a entregar: reproduzir o caso normal e as exceções relevantes, observar o resultado e guardar o que foi efetivamente verificado. Um agente dizer que terminou não substitui essa observação, sobretudo quando outro alterou uma dependência.
Se surgir uma contradição, suspende a edição da parte afetada enquanto esclareces a regra. Pedir simultaneamente a ambos que resolvam o conflito pode produzir uma nova ronda de alterações incompatíveis. Define a decisão, escolhe quem a aplica e entrega depois a versão resultante para revisão.
Muda de responsável com uma passagem de contexto
Podes trocar o agente responsável pela construção, desde que a mudança inclua uma passagem de contexto explícita. Entrega o estado atual, as decisões aceites, os pontos pendentes e as verificações feitas. O novo responsável precisa de continuar um projeto existente, com razões que podem não estar visíveis nos ficheiros alterados.
Não entregues apenas a última mensagem da conversa anterior. Uma solução aparentemente estranha pode preservar uma restrição importante, e uma melhoria sugerida pode já ter sido rejeitada por uma razão válida. Regista essas decisões junto do projeto, de forma suficientemente curta para serem consultadas durante o trabalho.
Tal como ao definir quem aprova cada parte de um projeto de automação, importa separar execução, revisão e decisão final. Duas análises podem enriquecer a decisão, mas não dispensam alguém de assumir a compatibilidade do conjunto e aceitar o comportamento que vai ser entregue.
Antes de iniciar a próxima alteração, confirma que existe um responsável identificável por cada área, que o revisor sabe o que pode fazer e que a integração tem uma sequência. Se estas respostas continuarem vagas, resolve primeiro a coordenação. Acrescentar mais capacidade de execução a essa indefinição tende a multiplicar o trabalho por conciliar.