Dirigir agentes não substitui julgamento técnico: transforme revisão em evidência

O GitHub apresenta três competências para desenvolvimento apoiado por IA: dirigir agentes, avaliar criticamente suas saídas e exercer julgamento técnico.[19] O artigo não afirma que escrever código deixou de importar; desloca parte da atenção para definir o problema, revisar resultados e decidir o que pode ser entregue.[19] A conclusão prática não é contratar mais opiniões automáticas, mas tornar a revisão verificável.

O que muda para quem desenvolve

A publicação propõe usar outro modelo para criticar o primeiro e cita Rubber Duck, agente do Copilot que revisa planos, código e testes com um segundo modelo.[19] No exemplo de SQL para obter o pedido mais recente de cada cliente, a crítica identifica timestamps duplicados, falta de orientação sobre índices e possível lentidão em tabelas grandes.[19]

Minha leitura é que a segunda opinião vale quando produz perguntas melhores e casos executáveis. Uma revisão eloquente ainda precisa ser convertida em evidência: qual entrada quebra a solução, qual saída é esperada e como confirmar a correção?

A divisão entre agentes de implementação, documentação e testes aparece como possibilidade no artigo, com o desenvolvedor responsável pela integração e pelo resultado.[19] Portanto, não recomendo avaliar produtividade por quantidade de agentes ou linhas geradas. O critério deveria ser entrega correta com esforço de revisão conhecido.

Como aplicar

Proponho um exercício com dados sintéticos para a consulta do pedido mais recente. Inclua cliente sem pedidos, cliente com um pedido e cliente com dois pedidos no mesmo timestamp. Antes de pedir código, defina a regra de desempate. Sem essa decisão, duas saídas diferentes podem parecer corretas para revisores diferentes.

Peça a um agente a implementação e a outro uma crítica baseada nesses critérios. Transforme cada preocupação aceita num teste ou numa verificação de plano de execução no banco escolhido. Não acrescente índices apenas porque uma resposta os sugeriu; confira o padrão de acesso e o custo de manutenção.

Na revisão final, confronte implementação, testes e documentação. Verifique se descrevem a mesma regra e se os testes realmente falham diante de uma versão incorreta. Para autenticação, use o mesmo método com autorização, identidade ausente e caminhos de falha, sempre em ambiente descartável.

Cuidados e limites

O texto do GitHub apresenta uma tese de desenvolvimento profissional e exemplos de fluxo, não um benchmark que comprove ganho universal.[19] Uma segunda opinião não substitui execução de testes ou decisão humana sobre requisitos.

Além disso, dirigir agentes exige capacidade de reconhecer quando a especificação está incompleta. A economia de implementação pode ser anulada por revisão sem foco e integração mal definida. Recomendo medir retrabalho, defeitos encontrados e tempo até o aceite. O julgamento técnico aparece quando alguém decide a regra, exige evidência e assume a responsabilidade pelo que entrou em produção.

Fonte

[19] Fonte: GitHub Blog