A Harness publicou um guia de engenharia em duas partes sobre as práticas que adotou após seis meses redesenhando seu SDLC em torno de agentes de IA. O objetivo é controle operacional. Harness vende infraestrutura CI/CD; seus clientes a medem pela confiabilidade, não pela velocidade de iteração.
Os quatro pilares mapeiam onde sistemas agenticos falham na prática. Pilar um: desenvolvimento baseado em especificações. Todas as especificações de produto, tecnologia, UI e testes vivem em repositórios versionados (Harness usa seu próprio Code Repository). Agentes de IA precisam de contexto estruturado e co-localizado. Páginas do Confluence não funcionam. Resultado: equipes prototipam mockups de UI em 30 minutos em vez de semanas porque as especificações são legíveis por máquina e sempre atuais.
Pilar dois quantifica onde agentes pertencem. Harness mediu 15–20% do trabalho de engenharia como totalmente autônomo—ticket Jira para pull request—enquanto 80% permanece auxiliado por IA, com desenvolvedores usando agentes como ferramentas em vez de delegar fluxos de trabalho inteiros. Quatro em cinco tarefas ainda requerem supervisão humana no loop. A arquitetura combina microsserviços tradicionais com endpoints de agentes expostos via Model Context Protocol. Cada agente tem permissões limitadas e uma única responsabilidade: um agente de revisão de código não pode implementar mudanças, um agente de testes não pode tocar produção, um agente de especificação não tem autoridade sobre arquitetura. Agentes especializados superam os omniscientes sobrecarregados em custo e confiabilidade.
Os testes revelam a maior lacuna. O guia especifica seis camadas: verificação de front-end (Vitest, Playwright), testes de produto e API (unitário, integração, funcional), testes de eficácia de agentes contra baselines, verificação de dados para detectar fontes de alucinação, monitoramento contínuo de eficácia em produção e loops de feedback agenticos. Camada cinco—monitoramento contínuo de eficácia—é a mais negligenciada e mais dolorosa. Mude um prompt do sistema, atualize uma base de conhecimento ou troque uma versão de modelo: a qualidade da saída do agente se degrada silenciosamente sem um harness de monitoramento observando.
Harness adotou Avaliações de Prontidão Operacional do playbook de hiperscalers. ORRs executam imediatamente após revisão de design, não desenvolvimento, e produzem uma lista de verificação com evidência documentada. O guia enquadra essa evidência—resultados de testes de carga, resultados de game day, aprovações de auditoria de segurança—como um template que as equipes devem seguir, não figuras da Harness. Camadas de severidade são impostas: itens altos bloqueiam o lançamento, itens médios requerem resolução em 90 dias, itens baixos vão para backlog. Após o lançamento, as equipes de serviço se reúnem semanalmente para revisar a saúde de data-plane e control-plane, métricas de clientes e RCAs.
Forrester descobriu que melhorias de IA focadas apenas em código de 30–40% frequentemente se traduzem em menos de 10% de ganho de produtividade de equipe inteira quando planejamento, testes e pipelines de release permanecem manuais. Gargalos se deslocam em vez de desaparecer.
Arquitetos expandindo autonomia de agentes devem instrumentar monitoramento de eficácia no primeiro dia, impor escopo de agentes na camada de permissões não na camada de prompt, e tratar ORRs como uma função forçante para surfaçar preocupações operacionais antes do código ser entregue.