A produtividade subiu. E a arquitetura, acompanhou?
Deriva arquitetural:
quando a IA acelera o código
e desorganiza o sistema
Produzir código mais rapidamente não significa desenvolver software melhor. Sem governança arquitetural, ganhos locais de produtividade podem aumentar inconsistências, perda de contexto e custo de evolução.
Uma cadeia de decisão mais curta
Uma nova camada passa a influenciar a arquitetura
No fluxo assistido por IA, a qualidade do resultado passa a depender também do contexto oferecido, do modelo escolhido e dos limites definidos pela empresa.
A IA pode melhorar a produtividade de uma atividade e piorar a capacidade de evoluir o sistema.
A deriva arquitetural raramente começa com uma grande decisão errada. Ela aparece no acúmulo de pequenas alterações, cada uma plausível isoladamente, mas incoerentes quando observadas em conjunto.
Quando cada alteração funciona, mas o sistema deixa de funcionar da mesma forma
A inteligência artificial está tornando a produção de software mais rápida. Funções podem ser geradas em segundos. Testes podem ser sugeridos automaticamente. Agentes já conseguem alterar dezenas de arquivos, executar comandos, corrigir erros e propor refatorações.
Mas existe uma diferença entre produzir código mais rapidamente e desenvolver software melhor.
Quando essa diferença não é compreendida, a organização pode aumentar a produtividade de uma atividade específica e, ao mesmo tempo, reduzir a capacidade de manter e evoluir o sistema como um todo.
Um dos sinais desse problema é a deriva arquitetural: a arquitetura real do software começa a se afastar, gradualmente, da arquitetura que a empresa havia definido.
Imagine uma empresa com princípios técnicos claros:
- regras de negócio devem permanecer em uma camada específica;
- integrações devem ocorrer por APIs;
- erros devem ser tratados de maneira centralizada;
- todos os serviços devem seguir o mesmo padrão de autenticação;
- determinadas dependências não podem ser acessadas diretamente.
Cada modelo recebe contextos, instruções e restrições diferentes. As entregas podem passar nos testes e funcionar isoladamente. Mesmo assim, o sistema começa a perder uma lógica estrutural comum.
A arquitetura passa a refletir as preferências dos modelos utilizados, as decisões locais de cada desenvolvedor e o contexto disponível em cada interação. Deixa de representar, de forma consistente, os princípios arquiteturais definidos pela organização.
A armadilha da produtividade local
É simples observar que determinado código foi produzido mais rapidamente. É muito mais difícil calcular revisão, correção, testes, reconstrução de contexto, retrabalho e manutenção futura.
Ganhos individuais não significam automaticamente melhor entrega.
O relatório identificou benefícios da IA sobre produtividade individual, fluidez do trabalho e satisfação, mas também impactos negativos sobre estabilidade e throughput da entrega de software.
Consultar fonte ↗A IA funciona principalmente como amplificador.
Ela amplia tanto pontos fortes quanto fragilidades existentes. Os retornos dependem também da qualidade do sistema organizacional, dos processos e das práticas de engenharia sobre os quais a IA é aplicada.
Consultar fonte ↗Percepção de produtividade pode divergir da produtividade medida.
Em um estudo específico com desenvolvedores experientes em projetos open source conhecidos havia anos, os participantes estimaram ganhos, mas levaram mais tempo para concluir as atividades com ferramentas de IA. O resultado não deve ser generalizado para todos os contextos.
Consultar fonte ↗DÍVIDA DE
COMPREENSÃO
Deriva arquitetural é um problema de governança
Arquitetura de software sempre exigiu governança. Com a IA, porém, a governança precisa controlar não apenas pessoas, ferramentas e processos, mas também modelos e agentes capazes de alterar o sistema.
Desenvolvedor → código → sistemaDesenvolvedor → contexto + instrução + modelo → código → sistemaEssa nova camada influencia diretamente a qualidade e a consistência do resultado. Ela precisa ser governada.
Isso envolve decidir:
- quais modelos podem ser utilizados;
- quais repositórios e arquivos podem ser acessados;
- quais dados podem ser enviados a provedores externos;
- quais ações os agentes podem executar;
- quais decisões exigem aprovação humana;
- quais informações devem ser registradas;
- quais testes e controles são obrigatórios;
- quem responde pela alteração aprovada.
O NIST AI Risk Management Framework propõe que riscos de IA sejam tratados ao longo do desenho, desenvolvimento, uso e avaliação dos sistemas, não apenas na contratação ou seleção dos modelos.
Da mesma forma, o Secure Software Development Framework do NIST recomenda que práticas de segurança sejam incorporadas a todo o ciclo de desenvolvimento. Código produzido com IA não deveria receber um caminho abreviado de validação.
Cinco controles para reduzir a deriva arquitetural
Em vez de adicionar mais uma camada de burocracia, a empresa precisa tornar arquitetura, contexto, permissões, evidências e métricas parte do próprio fluxo de engenharia.
Transformar a arquitetura em uma fonte de contexto
Princípios arquiteturais, padrões aprovados, restrições, dependências e decisões relevantes precisam estar disponíveis em formatos utilizáveis por equipes e agentes. ADRs, arquiteturas de referência, mapas de dependência e padrões de desenvolvimento passam a compor o contexto operacional da IA.
Versionar o contexto, não apenas o código
Instruções, regras de negócio, políticas, versões de modelos, fontes consultadas e configurações relevantes precisam ser tratadas como ativos versionados. Context Engineering deixa de ser apenas escrever instruções melhores e passa a significar fornecer conhecimento correto, autorizado, atualizado e rastreável.
Aplicar o princípio do menor privilégio aos agentes
Um agente não deveria receber acesso irrestrito a todo o ambiente apenas porque precisa alterar um componente.
- repositórios e módulos permitidos;
- comandos disponíveis;
- ambientes e dados acessíveis;
- ações que exigem aprovação humana.
Registrar evidências nas alterações
Pull Requests podem registrar ferramenta, modelo e versão, escopo, fontes de contexto, testes, verificações de segurança, responsável pela revisão e exceções arquiteturais aprovadas. O objetivo é preservar auditoria, investigação e aprendizado.
Medir o sistema, não o volume de código
Linhas produzidas, prompts enviados, tokens consumidos e sugestões aceitas medem atividade. Não medem necessariamente valor. A avaliação precisa considerar tempo de entrega, frequência de implantação, recuperação, retrabalho, defeitos, violações arquiteturais, revisão, manutenção e custo total de propriedade.
Sua engenharia está preparada para agentes?
Antes de ampliar o uso de agentes de desenvolvimento, CIOs, CTOs e líderes de engenharia deveriam conseguir responder às perguntas abaixo.
Se a IA participa da arquitetura, a governança não pode ficar fora do desenvolvimento.
Na SuperClient, entendemos que a governança da IA aplicada à engenharia precisa ir além da escolha do modelo. Quando agentes e assistentes passam a influenciar o software, a empresa precisa enxergar ferramentas, acessos, contexto, decisões e evidências que participam do desenvolvimento.
O objetivo não é impedir que desenvolvedores utilizem IA. É permitir que utilizem IA sem transferir para o futuro um custo que a empresa ainda não consegue enxergar.
Velocidade sem coerência não é escala.
A IA não elimina a complexidade da engenharia de software. Ela muda o lugar em que essa complexidade precisa ser administrada.
Fontes
- Cezar Taurion - A dívida técnica invisível da IA: o problema que ninguém está discutindo
- DORA - Accelerate State of DevOps Report 2024
- DORA - State of AI-assisted Software Development 2025
- METR - Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity
- NIST - AI Risk Management Framework
- NIST - Secure Software Development Framework, SP 800-218