A IA tornou o código barato. O software continua caro.

Durante décadas, desenvolver software significava lidar com uma limitação bastante concreta: a velocidade humana de implementação.

Um desenvolvedor precisava analisar um problema, compreender os requisitos, projetar uma solução, escrever o código, criar testes, corrigir erros, documentar o sistema e, depois, mantê-lo.

O código era um dos principais gargalos do processo.

Hoje, esse cenário mudou.

Com a evolução dos modelos de Inteligência Artificial generativa e dos agentes capazes de interagir com ambientes de desenvolvimento, uma parte significativa da implementação pode ser automatizada.

DTOs podem ser gerados.

Entidades podem ser criadas.

APIs podem ser implementadas.

Testes podem ser produzidos.

Documentação pode ser escrita.

Refatorações podem ser sugeridas.

Até mesmo estruturas arquiteturais podem ser propostas.

O que antes levava horas pode, em determinados contextos, ser produzido em minutos.

Isso é uma transformação enorme.

Mas existe um problema.

Estamos confundindo a redução do custo de geração de código com a redução do custo de construção de software.

E são coisas completamente diferentes.

---

Código não é software

Essa distinção parece óbvia, mas está sendo cada vez mais ignorada.

Código é uma parte do software.

Software é um sistema muito maior.

Quando uma empresa contrata o desenvolvimento de uma solução, ela não está comprando milhares de linhas de C#, Java, Python ou TypeScript.

Ela está tentando resolver um problema.

E resolver esse problema envolve muito mais do que escrever código.

É necessário compreender:

• O problema de negócio;
• Os requisitos;
• As regras de negócio;
• A arquitetura;
• O modelo de dados;
• As integrações;
• A segurança;
• A escalabilidade;
• A observabilidade;
• Os testes;
• A operação;
• A manutenção;
• A evolução do sistema.

A IA pode ajudar em praticamente todos esses pontos.

Mas existe uma diferença fundamental entre ajudar e assumir responsabilidade.

Uma IA pode gerar uma arquitetura.

Mas quem decide se aquela arquitetura é adequada ao contexto?

Uma IA pode criar uma API.

Mas quem garante que o contrato atende às necessidades reais do negócio?

Uma IA pode gerar testes.

Mas quem sabe se os cenários testados representam os riscos mais importantes do sistema?

Uma IA pode sugerir uma solução tecnicamente elegante.

Mas quem avalia se a empresa possui orçamento, equipe e maturidade para operar aquela solução?

Essas perguntas continuam existindo.

E elas são perguntas de Engenharia de Software.

---

A grande mudança não aconteceu no software. Aconteceu no custo do código.

Durante muito tempo, o código era um recurso relativamente escasso.

Se uma empresa precisava de uma nova funcionalidade, precisava de profissionais para implementá-la.

Se precisava de dez funcionalidades, precisava de mais tempo.

Se precisava acelerar, contratava mais desenvolvedores.

A Inteligência Artificial alterou essa equação.

Agora existe uma capacidade muito maior de produzir código.

O problema é que isso cria uma consequência inesperada.

Quando produzir código fica barato, produzir código deixa de ser o principal gargalo.

O gargalo começa a migrar para outras etapas.

Entender corretamente o problema.

Definir requisitos.

Tomar decisões arquiteturais.

Identificar riscos.

Estabelecer restrições.

Construir contexto.

Validar hipóteses.

Supervisionar agentes.

Auditar resultados.

Garantir qualidade.

E decidir o que não deve ser construído.

Essa última talvez seja uma das competências mais importantes da nova realidade.

Porque a IA não possui dificuldade para produzir uma solução.

Ela possui dificuldade para saber, por conta própria, se aquela solução deveria existir.

---

O perigo da produtividade artificial

Imagine uma equipe tradicional.

Cinco desenvolvedores conseguem implementar determinada quantidade de funcionalidades em um mês.

Agora imagine que esses mesmos profissionais passem a utilizar agentes de IA.

A capacidade de implementação aumenta.

Talvez significativamente.

A equipe consegue produzir mais código.

Mais funcionalidades.

Mais endpoints.

Mais testes.

Mais componentes.

Mais documentação.

Tudo parece melhor.

Mas existe uma pergunta que precisa ser feita:

A equipe aumentou sua capacidade de construir software ou apenas aumentou sua capacidade de produzir código?

Essa diferença é crítica.

Porque, se a capacidade de implementação cresce mais rapidamente do que a capacidade de análise, arquitetura e validação, o sistema começa a acumular problemas em velocidade maior.

É possível produzir rapidamente:

• Código duplicado;
• Arquiteturas inconsistentes;
• Dependências desnecessárias;
• APIs mal projetadas;
• Falhas de segurança;
• Testes que validam comportamentos incorretos;
• Abstrações excessivas;
• Complexidade desnecessária;
• Débito técnico.

A IA pode acelerar a produção de tudo isso.

E essa é uma das grandes ironias da nova era.

A mesma tecnologia que pode aumentar drasticamente a produtividade de uma equipe também pode aumentar drasticamente a velocidade com que ela produz problemas.

---

O novo gargalo é a capacidade de decisão

Durante muito tempo, o fluxo de desenvolvimento podia ser representado de maneira relativamente simples:

Pensar → Projetar → Codificar → Testar → Entregar

A IA começa a alterar esse modelo.

A implementação deixa de ser exclusivamente manual.

Uma parte significativa dela pode ser delegada.

O fluxo passa a se aproximar de algo como:

Entender o problema
↓
Modelar a solução
↓
Definir a arquitetura
↓
Construir o contexto
↓
Delegar a implementação
↓
Auditar o resultado
↓
Validar a qualidade
↓
Entregar

A mudança parece sutil.

Mas não é.

Ela representa uma mudança profunda no papel do profissional.

O desenvolvedor deixa de ser apenas aquele que escreve código.

Ele passa a ser também aquele que define o que deve ser construído, estabelece as restrições, orienta a execução e verifica se o resultado está correto.

Isso exige um nível maior de abstração.

E, principalmente, exige conhecimento.

---

A IA aumenta o valor do conhecimento técnico

Existe uma interpretação equivocada de que, se a IA consegue gerar código, estudar programação deixou de ser importante.

Na prática, o raciocínio é inverso.

Quanto maior a capacidade de geração automática, maior a necessidade de profissionais capazes de avaliar o que foi gerado.

Imagine um agente produzindo milhares de linhas de código.

Quem vai verificar?

Imagine uma IA propondo uma arquitetura distribuída.

Quem vai questionar?

Imagine um agente afirmando que uma determinada implementação é segura.

Quem vai auditar?

Imagine uma suíte de testes com 95% de cobertura.

Quem vai verificar se os 5% restantes não representam justamente os cenários críticos?

O problema não é mais apenas:

"Você consegue escrever esse código?"

O problema passa a ser:

"Você consegue identificar se esse código deveria existir?"

E depois:

"Você consegue provar que ele está correto?"

Essa mudança é significativa.

Porque conhecer profundamente Engenharia de Software deixa de ser apenas uma forma de produzir software.

Passa a ser uma forma de avaliar e controlar software produzido por humanos e máquinas.

---

A crise dos operadores de IA

Existe um novo perfil profissional surgindo.

É o profissional que sabe conversar com ferramentas de Inteligência Artificial.

Ele conhece prompts.

Conhece algumas ferramentas.

Sabe pedir código.

Sabe pedir refatorações.

Sabe gerar testes.

Sabe criar documentação.

Mas, quando recebe o resultado, simplesmente aceita.

Esse profissional pode parecer extremamente produtivo.

Mas existe um problema:

ele não possui capacidade suficiente para validar aquilo que a própria IA produziu.

Isso cria uma situação perigosa.

O profissional passa a depender da ferramenta para produzir e também para avaliar.

A IA gera.

A IA explica.

A IA testa.

A IA diz que está correto.

E o profissional aprova.

Nesse cenário, o ser humano deixa de exercer engenharia.

Ele apenas opera ferramentas.

É o que podemos chamar de crise dos operadores de IA.

O risco não é a existência de profissionais utilizando Inteligência Artificial.

O risco é a existência de profissionais que sabem utilizar IA, mas não sabem engenharia.

---

O novo profissional não é um "prompt engineer"

Acredito que estamos entrando em uma fase em que o mercado começará a separar duas competências.

A primeira é:

Saber utilizar ferramentas de IA.

A segunda é:

Saber fazer Engenharia de Software utilizando IA.

A primeira pode ser aprendida relativamente rápido.

A segunda exige fundamentos.

Exige experiência.

Exige capacidade analítica.

Exige conhecimento de arquitetura.

Exige entendimento de requisitos.

Exige conhecimento de segurança.

Exige capacidade de modelagem.

Exige compreensão de sistemas distribuídos.

Exige domínio de testes.

Exige capacidade de avaliar trade-offs.

Exige responsabilidade técnica.

Por isso, o profissional que tende a ganhar relevância não será necessariamente aquele que produz mais código.

Será aquele capaz de tomar melhores decisões sobre o código que precisa ser produzido.

O profissional do futuro próximo será menos um "escritor de código" e mais um:

Analista.

Arquiteto.

Orquestrador.

Supervisor.

Auditor.

Tomador de decisão.

E, principalmente, um Engenheiro de Software Assistido por Inteligência Artificial.

---

A nova equação da Engenharia de Software

Existe uma relação que considero importante compreender:

Maior capacidade de geração automática
↓
Maior velocidade de implementação
↓
Maior volume potencial de mudanças
↓
Maior potencial de erro em escala
↓
Maior necessidade de engenharia disciplinada

A Inteligência Artificial não eliminou a Engenharia de Software.

Ela tornou a ausência dela mais perigosa.

Antes, um desenvolvedor poderia levar uma semana para implementar uma solução ruim.

Agora, um agente pode produzir uma solução ruim em poucos minutos.

O problema é que a velocidade da geração aumentou.

A velocidade da validação humana não aumentou na mesma proporção.

Esse é um dos grandes desafios que a indústria de software precisará enfrentar.

---

A pergunta que precisamos começar a fazer

Talvez a pergunta mais importante para os próximos anos não seja:

"Qual ferramenta de IA você utiliza?"

Talvez seja:

"Qual é o seu processo para garantir que o software produzido por IA está correto?"

Essa pergunta muda completamente a discussão.

Porque desloca o foco da ferramenta para a engenharia.

Do prompt para o contexto.

Da geração para a validação.

Da velocidade para a qualidade.

Da implementação para a decisão.

E essa mudança de perspectiva é fundamental.

A Inteligência Artificial está tornando a implementação de software cada vez mais acessível.

Mas construir sistemas realmente bons continua exigindo algo muito mais difícil de automatizar:

compreender problemas complexos, tomar decisões corretas e assumir responsabilidade pelos resultados.

A IA pode escrever o código.

Mas alguém ainda precisa decidir qual código deve ser escrito.

E, principalmente, alguém precisa ser capaz de dizer:

"Esse código está errado."

---

O início de uma nova Engenharia de Software

A discussão sobre IA no desenvolvimento de software não deveria começar pela ferramenta.

Deveria começar pelo processo.

Como definimos problemas?

Como construímos contexto?

Como delegamos tarefas para agentes?

Como estabelecemos restrições?

Como supervisionamos a execução?

Como auditamos resultados?

Como validamos arquitetura?

Como garantimos segurança?

Como controlamos qualidade?

Como evitamos que a velocidade de geração de código se transforme em velocidade de geração de débito técnico?

Essas são algumas das questões que estão no centro daquilo que chamo de Engenharia de Software Assistida por Inteligência Artificial.

A IA não representa o fim da Engenharia de Software.

Ela representa o início de uma nova fase.

Uma fase em que a capacidade de implementar deixa de ser o único — ou talvez nem mesmo o principal — diferencial profissional.

A próxima geração de engenheiros de software precisará aprender a trabalhar com agentes inteligentes.

Mas, antes disso, precisará aprender a pensar como engenheiro.

---

Este artigo faz parte de uma série sobre Engenharia de Software Assistida por Inteligência Artificial

Nos próximos artigos, vou explorar temas como:

• Como delegar tarefas de desenvolvimento para agentes de IA;
• Por que Context Engineering será uma competência fundamental;
• Como auditar código produzido por Inteligência Artificial;
• Como avaliar arquiteturas propostas por agentes;
• O risco do débito intelectual causado pela dependência excessiva de IA;
• Como estruturar um processo de desenvolvimento baseado em agentes;
• O novo papel do desenvolvedor na Engenharia de Software assistida por IA.

Se você quer aprofundar essa transformação e entender como a Inteligência Artificial está mudando não apenas a programação, mas a própria disciplina de Engenharia de Software, conheça o livro Engenharia de Software Assistida por Inteligência Artificial.

A IA já mudou a forma como produzimos código. A próxima mudança será na forma como pensamos, projetamos e supervisionamos software.