Da escrita de código à engenharia do ambiente

O avanço acelerado da inteligência artificial↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI → no desenvolvimento de software está nos levando a uma mudança importante: uma parcela crescente do código das aplicações passa a ser produzida, modificada e testada por agentes baseados em modelos de linguagem.

A produtividade é impressionante. Mas ela também revela um novo gargalo. A velocidade de geração de código pode crescer muito mais rapidamente do que a capacidade de preservar a qualidade estrutural do sistema ao longo do tempo.

Ferramentas como Claude Code, Codex, Gemini CLI e outras representam um salto importante em relação aos primeiros copilotos. Embora tenham arquiteturas, mecanismos de contexto, ferramentas e graus de autonomia diferentes, esses agentes já conseguem, em determinados cenários, navegar por grandes repositórios, consultar documentação, utilizar ferramentas externas, executar testes, modificar múltiplos arquivos, propor refatorações e manter um plano de execução durante uma tarefa.

Em muitos casos, conseguem produzir alterações consistentes que atravessam diversos componentes de uma aplicação. Mas essa capacidade possui limites.

O contexto operacional utilizado por um agente durante uma tarefa não equivale, por padrão, a um modelo arquitetural persistente, completo e continuamente atualizado do sistema.

Um agente pode inspecionar centenas de arquivos, compreender dependências relevantes para uma tarefa e construir uma representação bastante útil do problema que está resolvendo. Isso não significa, porém, que mantenha uma compreensão global e permanente de todas as decisões arquiteturais, dependências históricas, restrições organizacionais e consequências acumuladas da evolução do software.

Existe ainda outra questão. Muitos fluxos de utilização desses agentes são orientados principalmente pelo sucesso da tarefa solicitada: implementar uma funcionalidade, corrigir um defeito, refatorar determinado componente ou fazer os testes passarem.

Isso é diferente de otimizar continuamente propriedades globais do sistema, como modularidade, baixo acoplamento, consistência arquitetural, evolutividade, segurança, observabilidade↳Observabilidade11 conteúdosObservabilidade para APIs: os desafios e benefícios dessa abordagemDev (Back & Front) · jan 2025Falhas em Observabilidade afetam os Apps e a Segurança das OrganizaçõesDev (Back & Front) · nov 2023ADK Java 1.0: O Google quer que você pare de gambiarra Python no seu backendMarketing Tech · abr 2026Ver tudo em DevSecOps → e conformidade.

Na prática, isso cria um risco conhecido na engenharia de software, mas que pode ser ampliado pela escala da automação. O agente pode tomar excelentes decisões locais sem necessariamente preservar a qualidade global do sistema.

Uma alteração individualmente correta pode introduzir uma nova dependência. Outra pode duplicar uma abstração já existente. Uma terceira pode resolver um problema local criando acoplamento desnecessário com outro componente.

Nenhuma dessas mudanças precisa ser, isoladamente, um erro evidente. Mas centenas ou milhares delas, acumuladas ao longo do tempo, podem produzir erosão arquitetural, padrões divergentes, abstrações redundantes, complexidade acidental e dívida técnica.

O problema, portanto, não é necessariamente que a IA escreva código ruim. Pode ser que ela escreva código suficientemente bom em escala tão grande que os problemas sistêmicos se acumulem mais rapidamente do que conseguimos percebê-los.

É nesse contexto que vem ganhando espaço o termo Harness Engineering. É importante fazer uma ressalva: não existe ainda uma definição única e universalmente consolidada de Harness Engineering. O termo descreve uma abordagem emergente para projetar o ambiente no qual agentes de IA desenvolvem software.

E muitas das práticas envolvidas não são novas. Testes automatizados↳Testes automatizados4 conteúdosComo migrei meus testes automatizados de Java para Ruby… Será que fiz bem?Dev (Back & Front) · jun 2019TDD em Nodejs: conhecendo o JestDev (Back & Front) · mar 2019Arquitetura Hexagonal na prática com exemplos em PythonDev (Back & Front) · mai 2025Ver tudo em Dev (Back & Front) →, integração contínua, observabilidade, revisão de código, políticas de segurança, controle de acesso, sandboxing, CI/CD e mecanismos de aprovação fazem parte da engenharia de software há décadas.

A novidade está em organizar essas práticas explicitamente para governar agentes probabilísticos capazes de tomar e executar sequências de decisões durante o desenvolvimento.

O foco deixa de ser apenas escrever código. Passa também a ser projetar o ambiente no qual o código será produzido.

Em vez de depender exclusivamente da revisão humana depois que o código foi gerado, o engenheiro pode definir restrições arquiteturais, mecanismos automáticos de validação, políticas de acesso, fluxos de aprovação, guardrails e avaliações contínuas capazes de orientar e limitar o comportamento dos agentes.

Podemos organizar essa abordagem em três pilares

1. Invariantes e pensamento sistêmico. Princípios arquiteturais, padrões de projeto, políticas de segurança, requisitos regulatórios e convenções importantes do domínio não deveriam existir apenas como documentação que alguém precisa lembrar. Sempre que possível, devem ser transformados em propriedades verificáveis automaticamente. Uma regra arquitetural pode virar uma verificação no pipeline. Uma dependência proibida pode gerar uma falha automática. Uma política de segurança pode ser transformada em teste. Um requisito estrutural pode ser monitorado continuamente. O objetivo é reduzir a dependência da memória humana e impedir que uma alteração incompatível seja incorporada simplesmente porque o código aparentemente funciona. E isso vale independentemente de o código ter sido escrito por um humano ou por uma IA.

2. Dados, avaliação e ciclos de feedback. Logs de execução, resultados de testes, revisões de código, métricas de qualidade, falhas recorrentes, incidentes de produção e resultados das avaliações dos agentes podem alimentar continuamente a evolução dos contextos, instruções, ferramentas e políticas utilizadas pelos sistemas. Aqui é importante diferenciar mecanismos que muitas vezes são colocados sob o mesmo rótulo. Mutation testing, por exemplo, procura avaliar a eficácia dos testes ao introduzir alterações deliberadas no código e verificar se a suíte consegue detectá-las. Agent evals, por outro lado, procuram medir o comportamento e a capacidade do agente diante de tarefas e cenários definidos. Conjuntos de regressão podem verificar se uma alteração no agente, no modelo ou no ambiente deteriorou capacidades que anteriormente funcionavam. São mecanismos diferentes, mas complementares. A ideia central é transformar o desenvolvimento com agentes em um ciclo contínuo de: execução → observação → avaliação → aprendizado → melhoria. O agente deixa de ser apenas um gerador de código e passa a operar dentro de um sistema de feedback.

3. Autonomia proporcional ao risco. Nem toda alteração possui o mesmo impacto. Uma mudança localizada, de baixo risco e completamente coberta por testes pode receber um nível elevado de automação. Já alterações envolvendo arquitetura, segurança, dados sensíveis, requisitos regulatórios ou componentes críticos podem exigir revisão humana, aprovação adicional ou execução em ambientes especialmente controlados. A autonomia, portanto, não precisa ser uma escolha binária entre “humano” e “agente”. Ela pode ser graduada conforme o risco da operação. Quanto maior o potencial de impacto, maior deve ser a quantidade de evidências, controles e aprovações exigidos antes que uma mudança seja incorporada. Isso também muda a discussão sobre confiança. Não precisamos perguntar simplesmente: “Confiamos na IA?”, mas sim “em quais condições podemos permitir que a IA aja autonomamente?”.

Mas isso não transforma agentes probabilísticos em sistemas determinísticos. Esse ponto merece atenção. Guardrails, testes, avaliações, políticas e mecanismos de aprovação podem reduzir significativamente determinados riscos, mas não garantem que todas as decisões futuras de um agente serão corretas ou previsíveis.

Da mesma maneira que testes de software aumentam a confiabilidade sem provar a ausência de todos os defeitos, mecanismos de governança aumentam a previsibilidade e a controlabilidade sem transformar um modelo probabilístico em um sistema determinístico.

Essa distinção é importante porque existe uma tentação de acreditar que, adicionando controles suficientes, eliminaremos completamente a incerteza. Não eliminaremos. O objetivo é confinar a incerteza dentro de limites aceitáveis.

E o que acontece com a engenharia de software tradicional? Ela não desaparece. Ela se reorganiza.

Também não devemos criar uma falsa dicotomia entre “software determinístico” e “IA probabilística”. Sistemas tradicionais possuem complexidade, concorrência, falhas e comportamentos difíceis de prever. Da mesma forma, sistemas modernos podem combinar componentes determinísticos e probabilísticos em uma mesma arquitetura.

O ponto é que algumas partes do sistema continuarão podendo ser especificadas, implementadas e verificadas por mecanismos determinísticos, enquanto outras incorporarão componentes probabilísticos.

Projetar arquiteturas, definir modelos de domínio, construir protocolos de comunicação, desenvolver algoritmos críticos, implementar componentes de infraestrutura, bancos de dados↳Banco de dados134 conteúdosSQL ou NoSQL: eis a questão!!Data · mar 2020Banco de dados: como organizar e dar segurança para milhões de dados de loteriasData · mai 20215 serviços gratuitos na cloud para bancos de dados PostgresData · fev 2025Ver tudo em Data →, compiladores, bibliotecas, mecanismos criptográficos, sistemas embarcados, sistemas de tempo real e software sujeito a certificações rigorosas continuará exigindo conhecimento profundo de engenharia.

E existe uma razão simples. Quanto mais código a IA produz, mais importante se torna alguém capaz de avaliar aquilo que foi produzido.

A profissão tende, portanto, a incorporar competências complementares. De um lado, continuará existindo a engenharia dedicada à arquitetura, infraestrutura, componentes determinísticos e problemas de elevada complexidade técnica.

De outro, ganhará importância a capacidade de orquestrar agentes, definir restrições, construir mecanismos de avaliação, projetar ambientes de execução e governar componentes probabilísticos.

Essas competências não competem. Elas se reforçam.

Quanto maior a autonomia concedida aos agentes, maior tende a ser a necessidade de uma engenharia sólida capaz de definir limites, preservar propriedades arquiteturais, controlar complexidade e avaliar continuamente as decisões produzidas.

Um primeiro passo pragmático para essa transição é identificar algumas regras arquiteturais fundamentais do repositório e transformá-las em verificações automáticas executadas continuamente.

Em paralelo, o histórico de alterações, revisões, resultados de testes, avaliações dos agentes e incidentes pode ser utilizado para identificar padrões de falha e aprimorar progressivamente os contextos, ferramentas, avaliações e guardrails.

O objetivo deixa de ser simplesmente produzir software mais rapidamente. Passa a ser construir um ambiente no qual sistemas probabilísticos possam gerar código em velocidade crescente sem comprometer qualidade, segurança, consistência arquitetural, conformidade e governança.

Durante décadas, o principal instrumento de abstração do engenheiro foi o código. Agora surge uma camada adicional. O engenheiro precisa projetar não apenas o software, mas também o ambiente no qual agentes irão produzir, modificar, testar e evoluir esse software.

À medida que a geração de código se torna cada vez mais barata, a capacidade de controlar sua geração pode se tornar o verdadeiro diferencial. O código continuará sendo um ativo fundamental, especialmente em sistemas complexos e críticos.

Mas saber escrever código pode deixar de ser suficiente. Será necessário saber definir o que o código deve preservar, como essas propriedades serão verificadas, quais decisões podem ser delegadas, quais exigem supervisão e o que acontece quando o agente estiver errado.

No fundo queremos saber como  construir um ambiente no qual uma IA possa escrever muito código sem destruir aquilo que levou anos para construir.