stamatios
← Voltar ao feed
Qualidade do código agêntico depende das restrições impostas aos agentes
Dev & Engenharia · Agentes

Qualidade do código agêntico depende das restrições impostas aos agentes

resumo de ~3 min

A qualidade do código agêntico depende das restrições impostas aos agentes

Addy Osmani argumenta que, com agentes de IA gerando código em volumes massivos, o modelo tradicional de code review humano não escala mais. A qualidade do software passa a depender das restrições (constraints) que definimos ao redor dos agentes - testes, gates de qualidade, métricas e verificações automatizadas que determinam se uma proposta de código é segura, correta e útil o suficiente para chegar à produção.

O que são essas restrições

As constraints assumem diversas formas: testes unitários, testes de propriedade, testes de aceitação, mutation testing, métricas de complexidade ciclomática, regras de arquitetura via linters, scans de segurança e políticas de deploy. Cada uma tem uma responsabilidade distinta. A ideia é que, antes de uma mudança proposta por um agente atravessar a fronteira para produção, ela passe por verificações suficientes para garantir que é segura e está dentro do escopo.

Autonomia e confiança

Osmani aponta dois problemas centrais. O primeiro é a autonomia: agentes podem falhar quando há informação ausente ou ambiguidade na tarefa, assim como humanos falham em ambientes frágeis, builds não determinísticos e testes fracos. A solução é construir ambientes que deem feedback confiável ao agente e permitam falhas com baixo dano.

O segundo é a confiança: não se pode delegar intenção a um agente sem verificar a correção do resultado. A confiança precisa ser conquistada progressivamente.

Back-pressure ao longo do pipeline

O conceito de "back-pressure" é central: restrições devem existir ao longo de todo o loop, não apenas como uma revisão final no CI. Compiladores rejeitando código inválido, testes falhando cedo, políticas de segurança bloqueando más práticas - tudo isso cria pressão de volta que impede trabalho ruim de avançar.

Quando o volume de mudanças supera a capacidade de verificação, há três opções: escalar o sistema de verificação, reduzir a taxa de geração de mudanças pelos agentes, ou baixar a barra de qualidade. Idealmente, deve-se estar preparado para todas.

Onde apertar e onde afrouxar

Osmani defende decisões deliberadas sobre onde aplicar restrições fortes e onde relaxá-las. Restrições fortes onde importam mais (segurança, correção crítica) permitem maximizar throughput sem sacrificar qualidade. Em outras áreas, pode-se dar mais liberdade aos agentes. A atenção humana, sendo escassa, deve ser direcionada para os problemas mais subjetivos - taste, intenção e arquitetura - enquanto as guardrails automatizadas cuidam do resto.

O papel humano

O code review humano do futuro será diferente. Humanos devem ser acionados apenas quando os guardrails automatizados falham. A qualidade não é uma métrica única, mas uma coleção de sinais de importância variável: correção, manutenibilidade, performance, segurança, eficiência e compreensibilidade.