Por Kwame Boateng

A programação assistida por IA é frequentemente descrita como uma versão mais rápida da programação em dupla. Essa comparação agora é limitada demais. Quando um agente consegue inspecionar um repositório, alterar vários arquivos, executar ferramentas, gerar uma pré-visualização e abrir uma pull request, o problema central da colaboração já não é simplesmente “Ele consegue escrever código?”. É “As pessoas conseguem ver, revisar, aprovar e, mais tarde, reconstruir o que aconteceu?”

É por isso que a mudança de design mais importante nas equipes de software assistidas por agentes pode ser a transição de prompts privados para espaços de trabalho visíveis. O Slack Code, por exemplo, é descrito como combinando canais de projeto com agentes de programação, auditoria de diferenças de código, pré-visualizações HTML ao vivo, fluxos de feedback e aprovação, arquivamento automático e registros de auditoria. O aplicativo Copilot do GitHub também adicionou um painel “Meu trabalho” para organizar issues e pull requests entre projetos. Esses recursos apontam para um princípio prático: o trabalho de um agente deve parecer menos uma resposta opaca e mais um conjunto de alterações passando por um processo de produção controlado.

O chat não é o registro do trabalho

Uma conversa com um agente pode ser útil para explorar uma ideia, mas é um sistema de registro fraco. Detalhes importantes podem ficar enterrados em uma thread longa: quais arquivos foram alterados, quais comandos foram executados, quais suposições o agente fez, o que um revisor rejeitou e se o resultado final difere da primeira proposta.

Um espaço de trabalho durável torna esses detalhes inspecionáveis. Ele deve conectar a solicitação a um repositório ou projeto específico, preservar o plano do agente, mostrar ações de ferramentas e alterações em arquivos, vincular testes e pré-visualizações e registrar quem aprovou o resultado. A interface exata pode variar — um rastreador de issues, uma pull request, um canal de colaboração ou um console de agente —, mas as informações devem sobreviver ao fim da sessão.

Isso é importante por razões comuns de engenharia, não apenas por conformidade. Se um bug aparecer duas semanas depois, uma equipe precisará de mais do que o diff final. Talvez precise saber qual era o requisito original, qual foi o plano gerado, quais evidências de teste existiam, quais foram os comentários do revisor e se um humano aceitou explicitamente uma compensação arriscada. Um registro durável encurta essa investigação.

Cinco camadas de trabalho visível

As equipes que adotam agentes de programação podem tratar cada alteração como um pequeno processo inspecionável. Cinco camadas são especialmente úteis:

  1. Intenção: a issue, os critérios de aceitação, as restrições e o escopo solicitado.
  2. Plano: a abordagem proposta pelo agente antes de editar os arquivos. Para uma tarefa não trivial, este é um ponto de verificação de aprovação, não uma decoração.
  3. Diff: as adições, exclusões, alterações de dependências, edições de configuração e ativos gerados exatos.
  4. Evidências: resultados de testes, saída do lint, verificações de segurança, capturas de tela e uma pré-visualização ao vivo ou implantável, quando relevante.
  5. Registro de decisão: comentários do revisor, alterações solicitadas, aprovação, rejeição, reversão ou trabalho de acompanhamento.

A questão não é obrigar toda alteração a passar por um comitê pesado. Um erro de digitação e uma alteração no fluxo de pagamento não devem ter controles idênticos. A questão é tornar o nível de análise proporcional ao impacto potencial.

As aprovações devem estar vinculadas a ações

“Humano no circuito” é vago demais para ser um controle útil. Uma pessoa pode aprovar um plano sem ver o diff resultante ou aprovar uma alteração de código sem perceber que o agente também modificou um arquivo de implantação. Fluxos de trabalho melhores especificam o que a aprovação permite.

Por exemplo, uma equipe pode permitir que um agente leia um repositório e execute testes locais automaticamente, exigir aprovação antes de escrever fora de uma branch designada e exigir uma aprovação separada antes de fazer merge ou implantar. Um agente poderia propor uma migração de banco de dados, mas ser proibido de executá-la em produção. A abordagem proposta pelos EAU para classificar quais tarefas os agentes podem concluir e quais podem apenas recomendar reflete esse padrão mais amplo: a autonomia deve ser atribuída por tarefa, não presumida globalmente.

As aprovações também precisam de escopo e validade. Uma aprovação para “atualizar o texto da landing page” não deve autorizar silenciosamente um novo pacote de analytics. Um plano aprovado ontem não deve abranger automaticamente um diff materialmente alterado hoje. A interface deve tornar esses limites visíveis.

As pré-visualizações transformam a revisão em inspeção

A revisão de código costuma ser mais fácil quando as pessoas podem inspecionar o resultado em vez de inferi-lo a partir dos arquivos-fonte. Uma pré-visualização HTML ao vivo pode revelar espaçamento quebrado, estados ausentes, controles inacessíveis ou uma alteração não intencional na navegação que um revisor talvez não perceba em um diff textual.

As pré-visualizações não são prova de correção. Elas devem ficar ao lado dos testes e da revisão do código-fonte, não substituí-los. Mas criam um objeto comum para discussão: um revisor pode apontar para uma tela, um estado ou uma interação específica e deixar feedback associado à alteração proposta.

Isso é particularmente valioso quando não especialistas participam da revisão. Um gerente de produto talvez não consiga avaliar uma alteração de framework, mas pode ser a pessoa certa para confirmar que o fluxo corresponde ao requisito. Um designer pode validar uma regressão visual. Um especialista em segurança pode se concentrar em permissões e tratamento de dados. O espaço de trabalho assistido por agentes pode encaminhar cada pergunta à pessoa mais bem posicionada para respondê-la.

Os diffs precisam de contexto, não apenas de cor

Um diff familiar em vermelho e verde continua sendo essencial, mas as alterações geradas por agentes podem ser amplas o suficiente para sobrecarregar um revisor. As equipes devem pedir aos agentes que mantenham commits ou grupos de alterações restritos, expliquem por que cada arquivo substancial foi alterado e identifiquem separadamente arquivos gerados ou de fornecedores.

Entre os prompts úteis para revisão estão:

  • Que comportamento visível para o usuário mudou?
  • Quais arquivos foram alterados apenas para dar suporte à implementação?
  • Que suposições o agente fez sobre o comportamento existente?
  • Quais testes foram adicionados, modificados ou não executados?
  • Essa mudança pode afetar permissões, retenção de dados, faturamento ou APIs externas?

Essas perguntas transformam a revisão de um pedido vago para “dê uma olhada nisto” em uma análise repetível. Elas também ajudam a expor um modo comum de falha: um recurso plausível acompanhado de uma atualização incompleta dos testes ou de uma alteração acidental de configuração.

Arquive o raciocínio que importa

Preservar cada token de cada conversa com um modelo não é automaticamente útil. Históricos longos podem ser caros para armazenar e difíceis de pesquisar, enquanto pesquisas sobre compactação de contexto alertam que resumos podem perder informações importantes. Uma trilha de auditoria prática deve, portanto, preservar artefatos relevantes para as decisões, em vez de salvar tudo indiscriminadamente.

No mínimo, retenha a solicitação, o plano aprovado, o diff final, os resultados das ferramentas e dos testes, a referência da prévia ou da implantação, as decisões dos revisores e qualquer exceção concedida. Se um agente usou fontes externas ou recuperou documentos internos, registre as referências às fontes relevantes e o momento em que elas influenciaram a mudança. Para trabalhos de alto risco, pode ser justificável reter a interação e o registro de execução completos.

Torne os registros evidentes quanto a adulterações quando os riscos exigirem isso e defina regras de retenção antes de uma crise. Uma trilha de auditoria que desaparece quando um canal é arquivado — ou que não consegue distinguir um resultado alterado do original — não dará suporte a uma investigação séria.

O que isso muda para as carreiras em software

A habilidade que está surgindo não é apenas escrever prompts melhores. É projetar um trabalho que outra pessoa possa inspecionar e em que possa confiar. Os desenvolvedores precisarão se sentir à vontade para especificar critérios de aceitação, decompor tarefas, revisar diffs em escala, criar testes significativos e decidir onde um agente deve parar e perguntar.

Profissionais de produto e design terão um papel maior na revisão de prévias e no esclarecimento da intenção. Engenheiros de QA podem ajudar a definir etapas de aprovação e casos de falha. Gestores de engenharia precisarão medir a produtividade sem recompensar a assunção de riscos invisíveis. Redatores técnicos e especialistas de operações podem contribuir tornando decisões, exceções e runbooks duradouros.

Um exercício útil é pegar um recurso rotineiro e mapear sua cadeia de evidências: solicitação, plano, branch, diff, testes, prévia, aprovação, lançamento e rollback. Em seguida, pergunte onde um futuro colega seria obrigado a adivinhar. Cada suposição é candidata a um workspace melhor, uma permissão mais clara ou um registro mais duradouro.

Uma regra operacional simples

Deixe os agentes avançarem rapidamente dentro de uma faixa visível e reversível. Dê a eles um workspace definido, restrinja ações sensíveis, exija aprovação em limites importantes, anexe evidências à mudança e preserve a decisão final. O objetivo não é desacelerar a automação até que ela se pareça com a codificação manual. É tornar a velocidade compatível com a responsabilização.

No desenvolvimento assistido por agentes, o melhor colaborador não é o sistema que produz mais código isoladamente. É o sistema cujo trabalho pode ser entendido, questionado, aprovado, desfeito e usado para aprender.