A IA barateou o código. E pode estar encarecendo o software…

Nas empresas que venho acompanhando, percebo uma mudança importante no desenvolvimento de software.

A IA↳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 → pode reduzir significativamente o esforço necessário para produzir determinados tipos de código. Isso cria a impressão tentadora de que escrever código deixou de ser um problema relevante.

Ganhou força uma narrativa que poderíamos resumir como specs to code: descreva em linguagem natural o que deseja, deixe um modelo gerar a implementação e, se algo estiver errado, ajuste a especificação e tente novamente. Essa visão, porém, já começa a parecer simplista. As ferramentas mais avançadas já não são apenas geradores de código. Agentes de desenvolvimento conseguem inspecionar repositórios, localizar arquivos relevantes, elaborar planos, editar múltiplos componentes, executar comandos, escrever e executar testes, investigar erros e iterar sobre os resultados. Essa evolução já está mudando o próprio fluxo de desenvolvimento. Mas isso não elimina o problema fundamental. Muda o perfil do problema.

O fluxo tradicional podia ser simplificado como: especificação → código. Com agentes, ele se aproxima mais de: intenção → contexto → plano → implementação → execução → teste → observação → correção → revisão.

E é justamente aí que observo um paradoxo. Quanto mais fácil fica produzir código, mais importante se torna a engenharia de software.

Código barato não significa software barato. A IA pode reduzir o tempo e o custo de produzir código. Mas software nunca foi apenas código. Envolve requisitos, arquitetura, dados, interfaces, segurança, testes, 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 →, integração, operação e manutenção.

Quando aumentamos em muito a nossa capacidade de produzir código, também aumentamos nossa capacidade de produzir código desnecessário, duplicado, excessivamente acoplado ou baseado em premissas erradas.

Podemos, portanto, produzir muito mais código e, simultaneamente, muito mais complexidade.

É o que eu chamo de erosão arquitetural, quando mudanças sucessivas tendem a aumentar a complexidade acidental, criar dependências desnecessárias e enfraquecer fronteiras que antes eram claras. E já posso constatar que quanto mais barato fica gerar código, mais importante se torna decidir qual código deveria existir.

Estudos recentes sobre software empresarial começam a apontar exatamente nessa direção: a IA pode acelerar a entrega, mas também acelerar dívida técnica, custos e exposição a riscos quando a qualidade arquitetural e os mecanismos de controle são frágeis.

O primeiro trabalho é construir contexto. Um dos riscos do desenvolvimento assistido por IA é imaginar que, porque o modelo produz uma resposta convincente, ele compreendeu integralmente o problema. Uma abordagem mais robusta é permitir que o agente explore o contexto, identifique ambiguidades, levante exceções, mapeie dependências e proponha um plano antes de modificar o sistema. Não significa fazer a IA perguntar indefinidamente.

Significa construir um contexto suficientemente explícito para que humanos e agentes trabalhem sobre as mesmas premissas. Nesse cenário, especificações deixam de ser apenas descrições do que construir. Passam a registrar também contexto, restrições, invariantes e critérios de aceitação.

Outro ponto importante é que contexto de domínio vale ainda mais. Uma IA pode produzir código sintaticamente correto e, ainda assim, semanticamente errado.

É por isso que práticas de modelagem de domínio e uma linguagem comum entre negócio e tecnologia continuam relevantes, especialmente em sistemas complexos.

Termos como cliente, contrato, pedido, reserva ou limite de crédito precisam ter significados precisos dentro daquele sistema.

Uma linguagem compartilhada reduz ambiguidades entre negócio, desenvolvedores e agentes. No desenvolvimento agentic, contexto passa a ser parte da própria infraestrutura de engenharia.

Observo também que ciclos curtos são essenciais. Agentes conseguem produzir grandes quantidades de código rapidamente. Isso é uma vantagem, mas também um risco.

Quanto maior a distância entre implementação e validação, mais difícil fica identificar onde uma decisão equivocada entrou no sistema. TDD↳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) → pode ajudar, mas não é uma solução universal. Testes são guardrails, não substitutos para arquitetura, segurança ou julgamento de negócio.

E não basta saber se o código funciona. Precisamos determinar se ele funciona de acordo com o que o sistema deveria fazer. Um agente pode produzir código e testes perfeitamente coerentes com uma interpretação errada do requisito.  Por isso, ciclos curtos são tão importantes: especificar → testar → implementar → executar → observar → corrigir → revisar. A velocidade da geração precisa ser acompanhada pela velocidade e pela qualidade da validação.

É essencial reconhecer que arquitetura e segurança são decisivas. Bases de código excessivamente fragmentadas, com interfaces numerosas e responsabilidades mal definidas, são difíceis de compreender e modificar, tanto para humanos quanto para agentes. Módulos com responsabilidades claras e interfaces estáveis continuam importantes porque escondem complexidade e reduzem o espaço de decisão.

Mas surge uma nova camada de risco. Um agente que apenas sugere código é uma coisa. Um agente que pode executar comandos, acessar repositórios, modificar arquivos, consultar sistemas ou utilizar credenciais é outra completamente diferente.

Nesse momento, não estamos mais falando apenas de geração de código. Estamos falando de software com capacidade de ação.

Isso exige identidade, princípio do menor privilégio, isolamento, registro das ações, limites operacionais, revisão e capacidade de interromper ou reverter operações. NIST e outras iniciativas recentes de segurança de agentes vêm justamente tratando dessa necessidade de estabelecer controles para sistemas capazes de agir autonomamente sobre ambientes digitais. Quanto maior a autonomia, maior precisa ser a capacidade de controle.

Tudo isso nos leva a considerar o novo papel do engenheiro de software. A maior mudança não é a narrativa da substituição do programador pela IA. É a mudança na distribuição do trabalho de engenharia.

Durante décadas, grande parte do esforço esteve em transformar uma decisão humana em código. Agora, a IA consegue executar uma parcela crescente dessa transformação. Com isso, ganham importância relativa aspectos como formular corretamente o problema, compreender o domínio, definir arquitetura e fronteiras, explicitar restrições e invariantes, estabelecer critérios de aceitação, validar resultados, avaliar trade-offs, controlar segurança e permissões, revisar o que foi produzido, e preservar a evolução arquitetural do sistema.

A programação não vai desaparecer. Entendo que digitar código tende a representar uma parcela menor do trabalho de engenharia, enquanto compreensão, decisão, validação e responsabilidade ganham peso. E o que considero mais interessante é que quanto mais competente fica a IA para escrever código, menos podemos nos dar ao luxo de tratar engenharia de software como simplesmente escrever código.

A IA pode tornar o código muito mais barato. Mas transformar código em software confiável, seguro, sustentável e alinhado ao negócio continua sendo um problema de engenharia.