“Se você não souber assembly, nunca vai ser um bom programador.”
Talvez você nunca tenha ouvido essa frase exatamente assim, mas ela representa uma discussão antiga. Lá atrás, quando linguagens de alto nível começaram a ganhar espaço, muita gente via isso com desconfiança. Parecia que quem parasse de escrever código “perto do metal” estava abrindo mão de controle e, de quebra, deixando de ser um “verdadeiro” programador.
Hoje, a conversa mudou de figurino, mas o roteiro é parecido:
“Se você usar Copilot, ChatGPT, Cursor, Claude Code ou qualquer outro agente de código, você não vai aprender de verdade.”
A tese deste texto é simples: IA generativa não é só autocomplete turbinado. LLMs e agentes de código estão virando uma nova camada de abstração na engenharia de software, do mesmo jeito que linguagens de alto nível, frameworks e cloud foram, cada um no seu tempo, novas camadas.
E, como toda abstração, IA resolve problemas antigos e cria novas dívidas.
Este artigo é um convite para olhar para IA com esse óculos de engenharia: não como ameaça, nem como milagre, mas como mais uma camada que muda onde está o trabalho difícil.
Não vamos discutir se “IA vai substituir devs”, nem comparar ferramentas, nem ensinar prompt engineering. A conversa aqui é sobre responsabilidade técnica nessa nova camada de abstração — o que você faz com o código que a IA gera, e que tipo de dívida isso pode criar no seu sistema.
Ao longo do texto, vou fazer um paralelo com a história de outras abstrações em software e, no fim, mostrar por que o problema não é a IA escrever código, mas o time aceitar esse código sem entender, testar e validar.
Se quiser ver o texto original desta ideia em outro formato, ele também foi publicado como artigo na plataforma Arandu da DWCorp em “Da linguagem de programação aos agentes de IA: toda abstração cria uma nova dívida”.
TL;DR
- IA (LLMs e agentes de código) é uma nova abstração de programação, não só uma feature da IDE.
- Toda abstração traz ganhos de produtividade e novas dívidas (confiança, validação, segurança, autoria, manutenção).
- O risco não está em usar IA, mas em aceitar código gerado sem entendimento, teste e revisão.
- IA não transforma automaticamente ninguém em sênior; ela amplifica práticas que já existiam no time.
- Usar IA com responsabilidade é tratá-la como um par júnior muito rápido: útil, mas que precisa de supervisão.
1. IA não é só autocomplete, é uma nova abstração de programação
Quando você abre sua IDE hoje, é bem provável que tenha alguma IA ali do seu lado:
- Copilot sugerindo blocos inteiros de código;
- ChatGPT ou Claude Code explicando uma função estranha;
- Cursor reescrevendo um módulo completo;
- Agentes de código tentando mexer em vários arquivos ao mesmo tempo.
É tentador olhar para isso apenas como “digitar mais rápido”. Mas, na prática, algo mais profundo está acontecendo.
Assim como:
- linguagens de alto nível abstraíram o hardware;
- frameworks abstraíram detalhes de infraestrutura e de protocolos;
- cloud abstraiu rack, datacenter, cabo e switch;
LLMs e agentes de código começam a abstrair partes da própria programação: você para de dizer como escrever cada linha e começa a dizer o que você quer que exista no código.
Isso não é só um “autocomplete inteligente”. É mais próximo de dizer:
“Tenho esse requisito em linguagem natural. Constrói algo que pareça resolver isso.”
E, toda vez que a gente sobe um nível de abstração, a história se repete:
- ganho: fica mais rápido construir;
- custo: aparecem novas dívidas que não existiam antes.
O resto deste texto é justamente para explorar como essa nova camada de IA muda o trabalho de engenharia — e que tipo de dívida técnica ela pode criar se a gente usar sem critério.
2. Linha do tempo das abstrações: toda solução trouxe nova dívida
Antes de falar de IA, vale olhar a fila de abstrações que já passou pela engenharia de software. A lógica é sempre parecida: a gente sobe um nível, ganha potência, mas também cria novas formas de errar.
2.1. Das linguagens de baixo nível às linguagens de alto nível
Saímos de um mundo em que muita coisa era escrita em assembly ou C próximo do sistema operacional e fomos para Java, C#, Python, Ruby, Go, Kotlin e por aí vai.
Ganhos claros:
- desenvolvimento muito mais rápido;
- portabilidade entre plataformas;
- código mais legível e expressivo;
- bibliotecas reutilizáveis para praticamente tudo.
Mas isso cobrou um preço.
Novas dívidas:
- nem sempre sabemos o que o compilador ou o runtime está fazendo por trás (otimizações, alocação, coleta de lixo);
- bugs aparecem só em produção porque dependem de detalhes sutis de memória, concorrência ou ordem de execução;
- muita gente passou a acreditar na armadilha cultural:
- “se compila, então está certo”.
Esse tipo de pensamento é um clássico exemplo de dívida de confiança criada por abstração: você confia demais no intermediário e para de validar o resultado.
2.2. Frameworks e ORMs: eliminando repetição, criando acoplamento
Depois vieram frameworks e ORMs. Spring, Rails, Django, ASP.NET, Hibernate, Entity Framework, etc.
Ganhos:
- muita produtividade: CRUDs, roteamento, validação, injeção de dependência, tudo “de graça”;
- menos boilerplate, mais foco em regra de negócio;
- convenções que alinham o time com menos conversa.
Mas, de novo, a conta chega.
Novas dívidas:
- queries ruins escondidas atrás de uma API bonita;
- dificuldade de otimizar sem entender o SQL gerado;
- acoplamento forte ao framework (“se quiser trocar, praticamente reescreve o sistema”);
- “mágicas” que funcionam até a hora em que param — e ninguém sabe bem por quê.
Aqui o trade-off típico é:
Velocidade de entrega agora vs. controle fino de performance e flexibilidade amanhã.
2.3. Cloud e DevOps: infra como serviço, complexidade como contrato
Depois, a infraestrutura saiu do rack embaixo da mesa e foi parar na AWS, Azure, GCP e companhia.
Ganhos:
- escalar sem comprar servidor físico;
- automação de deploy, pipelines, observabilidade;
- times focando mais em produto e menos em firmware de RAID.
E as novas dívidas?
- custos surpreendentes porque alguém deixou um cluster de teste gigante ligado;
- lock-in em serviços específicos do provedor;
- topologias de rede e segurança distribuída difíceis de entender;
- incidentes que envolvem meio sistema interno, meio serviço gerenciado.
De novo, abstração aumenta o poder, mas também esconde complexidade atrás de contratos.
2.4. IA entra na fila: mais uma camada em cima de tudo isso
É nesse contexto que entra a IA generativa como nova abstração de programação:
- não é uma ruptura total com o passado;
- é a continuidade dessa tendência de subir o nível de “linguagem” com que conversamos com o computador.
Agora, em vez de escrever código diretamente, você passa parte da responsabilidade de “traduzir” sua intenção para um agente de IA.
O trade-off muda um pouco:
- menos esforço em escrever cada linha;
- bem mais esforço em verificar o que foi escrito.
3. O que muda com IA como abstração de programação?
3.1. A diferença entre “digitar menos” e “pensar diferente”
Quando a IA gera blocos inteiros de código, arquitetura inicial, testes e até documentação, o gargalo do trabalho muda:
- antes: “como vou implementar isso?”;
- agora: “como vou ter certeza de que isso que foi implementado é correto, seguro e sustentável?”.
IA não é um autocomplete que sugere o próximo token. Ela vira algo muito mais próximo de:
- “monta esse módulo de autenticação”;
- “refatora esse serviço em microserviços”;
- “cria testes para essa classe”.
Isso exige um tipo diferente de raciocínio do desenvolvedor. Você não está mais só construindo; está especificando, auditando e corrigindo um sistema que está tentando construir para você.
3.2. Especificar melhor, revisar melhor
Imagine a cena:
“Implemente autenticação com JWT neste projeto Spring Boot.”
A IA gera algo que, num primeiro olhar, parece excelente:
- código bem formatado;
- endpoints organizados;
- exemplos de payload.
Mas esse código:
- segue as políticas de segurança da sua empresa?
- está alinhado com a forma como o resto do sistema trata autenticação?
- respeita requisitos não funcionais (compliance, logging, auditoria, observabilidade)?
Se a resposta for “não sei”, temos um problema.
O papel do dev muda de:
- “vou implementar tudo na mão” para
- “vou especificar bem o que eu quero, checando depois se o que veio bate com o contexto real do sistema”.
Uma boa metáfora é:
Trate a IA como um estagiário muito rápido e muito confiante.
Ele acerta muita coisa, mas sempre precisa de revisão.
3.3. IA como compilador esteroidal
Outra analogia útil: IA como um “compilador esteroidal”.
- O compilador traduz uma linguagem de alto nível (Java, C#, etc.) em algo executável.
- A IA traduz requisitos em linguagem natural em código na linguagem de programação.
Em ambos os casos:
- você sobe um nível de abstração;
- delega uma parte da tradução para uma ferramenta.
Quanto mais você delega, mais precisa ser a sua capacidade de:
- ler o resultado;
- identificar inconsistências;
- testar hipóteses rapidamente.
Se você não entende bem o que o compilador pode fazer (otimizações, reordenação de instruções, etc.), você erra ao projetar o código. Se você não entende bem o que a IA costuma fazer (alucinações, padrões genéricos, suposições), você erra ao aceitar o código.
4. As novas dívidas criadas pela IA (sem drama, mas com realismo)
Toda abstração cria novos tipos de dívida. Com IA não é diferente. A questão não é “ter ou não ter dívida”, mas que tipo de dívida você está assumindo sem perceber.
4.1. Dívida de confiança: parece certo vs. é certo
Ferramentas de IA têm uma característica perigosa: elas são muito convincentes.
O código:
- compila;
- passa no happy path;
- parece bem escrito.
Isso ativa um viés perigoso:
“Se parece bom, deve estar certo.”
Mas, por baixo, podem existir:
- uso de APIs inexistentes ou obsoletas;
- erros sutis de lógica em bordas de domínio;
- problemas de concorrência, performance ou segurança.
Exemplo simples: IA gera um método de paginação em uma API:
- funciona para o caso comum;
- mas ignora ordenação estável, limites de paginação, paginação baseada em cursor para grandes volumes, etc.
Em sistemas de verdade, esse tipo de detalhe representa dívida de corretude: o código está “quase certo” — e esse “quase” é o que te morde em produção.
4.2. Dívida de validação: testes viram etapa opcional?
Se o time já tinha cultura fraca de testes, IA pode piorar o cenário:
- antes: pouco código, poucos testes;
- agora: muito código, mesmos poucos testes (ou nenhum).
Existe ainda a armadilha de:
“Pede pra IA gerar os testes e pronto.”
Sem cuidado, isso vira:
- testes gerados que só cobrem o caminho feliz;
- casos de borda ignorados;
- testes que basicamente verificam se o código faz o que o próprio código faz (sem falar do domínio).
Boas práticas mínimas:
- rodar os testes do projeto depois de incorporar código gerado;
- validar manualmente casos de borda e cenários negativos;
- revisar testes sugeridos pela IA para ver se eles realmente testam o que importa.
Se testes virarem “coisa que a IA escreve sozinha e ninguém lê”, você está criando dívida de validação.
4.3. Dívida de segurança: copiar sem contexto é convite a vulnerabilidade
Muita resposta de IA sobre segurança é baseada em:
- exemplos genéricos;
- padrões potencialmente desatualizados;
- suposições simplistas sobre o ambiente.
Riscos comuns:
- sanitização de entrada incompleta;
- configurações de autenticação “de tutorial” indo para produção;
- dados sensíveis aparecendo em logs ou mensagens de erro;
- uso de bibliotecas com versões vulneráveis.
IA pode ajudar a lembrar boas práticas, mas não substitui threat modeling, revisão de segurança e políticas da organização.
Quando você copia uma solução “de caixinha” sem adaptar ao contexto, está criando dívida de segurança que pode ficar invisível por muito tempo.
4.4. Dívida de autoria: quem entende esse código daqui a 6 meses?
Outro tipo de dívida pouco falado é a dívida de autoria.
Cenário típico:
- grande trecho de código foi gerado por IA;
- foi aceito na pressa;
- ninguém do time entende profundamente por que aquela abordagem foi escolhida.
Seis meses depois:
- aparece um bug crítico naquele módulo;
- o time evita mexer porque “aquele código é estranho”;
- refactor demora mais porque ninguém se sente dono daquilo.
Para evitar isso, é importante:
- documentar decisões técnicas, mesmo quando a IA ajudou;
- registrar o racional por trás de escolhas não óbvias;
- manter alguém responsável por entender aquele pedaço (não precisa ser o autor original do prompt, mas alguém precisa assumir).
Se tudo é “código de ninguém”, a manutenção vira um campo minado.
4.5. Dívida de manutenção: escalar código ruim fica mais barato
Sem IA, um dev descuidado consegue produzir uma certa quantidade de código ruim por semana.
Com IA, esse mesmo dev consegue produzir muito mais código ruim no mesmo tempo.
Isso é o que torna IA um grande amplificador de cultura:
- se o time já aceitava código sem teste, sem revisão, sem design;
- a IA só acelera o acúmulo de endpoints duplicados, regras de negócio espalhadas, contratos quebrados.
É comum ver sprints “milagrosas”:
- muita entrega aparente;
- velocity explodindo;
- backlog esvaziando.
Depois de algumas semanas, começa a conta:
- bugs regressivos;
- features novas demorando mais porque ninguém entende o estado atual;
- medo de refatorar.
Esse é o trade-off clássico em nova escala:
velocidade de curto prazo vs. custo de manutenção em todos os ciclos futuros.
5. IA não cria o bom ou o mau engenheiro — ela amplifica o que já existe
5.1. O desenvolvedor criterioso vs. o desenvolvedor no piloto automático
Pega o mesmo cenário e dois desenvolvedores diferentes usando a mesma IA.
Dev A (criterioso):
- usa IA para gerar testes, checar entendimento, comparar abordagens;
- questiona as respostas, adapta ao contexto do sistema;
- reescreve o que for necessário para ficar coerente com a arquitetura.
Dev B (piloto automático):
- copia a primeira resposta que parecer “pronta”;
- não roda testes ou confia demais nos que a IA sugeriu;
- não revisa, não refatora.
Ferramenta é a mesma. O resultado:
- no caso do Dev A, produtividade sobe e a qualidade se mantém (ou melhora);
- no caso do Dev B, produtividade aparente sobe, mas a dívida técnica cresce rápido e silenciosa.
IA não transforma ninguém em sênior. Ela aumenta a distância entre quem tem boas práticas e quem não tem.
5.2. A ilusão de senioridade instantânea
Outra armadilha é acreditar que IA “dá poderes de sênior” para qualquer um:
- um júnior com IA consegue gerar código que “parece” sofisticado;
- pode até passar numa code review superficial, se o revisor também estiver no piloto automático.
Mas o que diferencia um desenvolvedor mais experiente?
- entender trade-offs de arquitetura;
- ler logs, métricas e stack traces;
- projetar boas interfaces entre módulos;
- lidar com falhas em produção;
- negociar escopo, simplificar problema.
Nada disso vem “de brinde” com IA.
Na prática, senioridade continua ligada a julgamento, não à quantidade de código que você consegue colocar no repositório.
5.3. Onde a engenharia de software continua insubstituível
Existem coisas que IA hoje (e por bastante tempo) não faz bem sozinha:
- entender restrições reais de negócio;
- conhecer legado organizacional, política interna, prioridades conflitantes;
- negociar com stakeholders, cortar escopo, simplificar problemas complexos;
- assumir responsabilidade quando algo dá errado em produção.
Por outro lado, IA é excelente para:
- sugerir alternativas técnicas que você talvez não lembrasse de cabeça;
- automatizar partes repetitivas;
- explicar código legado;
- auxiliar em refactors (com supervisão humana).
O trade-off que cada time precisa decidir é:
Vamos usar o tempo liberado pela IA para fazer mais engenharia de verdade
ou para encher o backlog com mais features irrelevantes?
6. Como usar IA como abstração com responsabilidade técnica
Não é um guia de prompt engineering, mas algumas posturas ajudam muito no dia a dia.
6.1. Tratar a IA como um par júnior muito rápido
Heurística prática:
Não aceite da IA o que você não aceitaria de um estagiário.
Isso inclui:
- código sem teste para partes críticas;
- ausência total de logging ou métricas em pontos sensíveis;
- desrespeito a padrões de arquitetura do projeto;
- uso de bibliotecas ou padrões que o time não adotaria normalmente.
Se você não deixaria um júnior “mergear direto na main” sem revisão, não faça isso com a IA.
6.2. Validar sempre: testes, observabilidade e revisão continuam essenciais
Alguns princípios que valem ainda mais agora:
- nenhuma mudança relevante sem testes rodando;
- revisão humana em código gerado, sempre que possível;
- checagem mínima de segurança para qualquer coisa exposta externamente;
- cuidado especial com código que mexe com dados sensíveis.
A tentação de “se compila e o happy path funciona, está pronto” fica maior com IA, mas é justamente o momento em que você mais precisa de:
- testes automatizados decentes;
- observabilidade (logs, métricas, traces);
- review criterioso.
6.3. Explicar o sistema para a IA… e para você mesmo
Um efeito colateral interessante de usar IA é que bons prompts exigem clareza de pensamento.
Para que a IA ajude de verdade, você precisa explicar:
- contexto do sistema;
- restrições;
- exemplos;
- casos de borda.
Muitas vezes, ao escrever esse contexto, você percebe:
- requisitos mal definidos;
- fluxo de domínio confuso;
- inconsistências entre módulos.
Exemplo:
Ao descrever detalhadamente o fluxo de criação de pedido para pedir uma sugestão de refactor, você percebe que três serviços diferentes mexem no mesmo estado, cada um de um jeito.
Só esse exercício já é um ganho de engenharia, mesmo antes de aceitar qualquer linha de código gerada.
6.4. Cultura de time: acordos claros sobre uso de IA
Cada time precisa responder algumas perguntas:
- Em quais partes do sistema podemos usar IA com mais liberdade?
- Em quais partes o uso é restrito (por segurança, compliance, criticidade)?
- Como vamos documentar trechos gerados por IA, se for relevante?
- Qual é o nosso processo mínimo de revisão e teste para aceitar código sugerido por IA?
Restringir demais pode engessar. Liberar geral sem critérios aumenta a chance de dívida escondida.
O importante é que o uso de IA não seja uma decisão individual isolada, mas parte de acordos de time, assim como code review, padrões de commit, guidelines de arquitetura etc.
6.5. Atualizar habilidades fundamentais, não abandoná-las
IA não é desculpa para abandonar fundamentos. Na verdade, ela torna alguns ainda mais importantes:
- leitura cuidadosa de código (você vai ler mais do que escreve);
- design de sistemas e modelos de domínio (para orientar a IA e validar o que ela produz);
- testes automatizados (TDD, coverage, property-based, etc.);
- noções sólidas de segurança e performance.
Você pode usar IA para:
- pedir explicações de conceitos;
- gerar exemplos didáticos;
- comparar abordagens;
mas ainda precisa investir em entender de verdade.
7. Conclusão: o código pode ser gerado — a responsabilidade, não
Se a gente olhar para a história da engenharia de software, IA entra como mais uma camada na pilha de abstrações:
- linguagens de alto nível abstraíram máquina;
- frameworks e ORMs abstraíram detalhes repetitivos de aplicação;
- cloud abstraiu infraestrutura física;
- agora, IA começa a abstrair pedaços da própria programação.
Em todos esses casos:
- ganhamos produtividade;
- criamos novas dívidas.
Com IA, as dívidas aparecem em:
- confiança (“parece certo vs. é certo”);
- validação (testes que viram opcional);
- segurança (padrões genéricos usados sem contexto);
- autoria (código sem dono);
- manutenção (escala de código ruim).
O problema central não é a IA escrever código.
O problema é o time aceitar esse código sem entender, sem testar, sem validar.
Usar IA com responsabilidade é:
- revisar o código como se você fosse o dono (porque você é);
- questionar respostas, especialmente as muito confiantes;
- fortalecer suas bases técnicas para conseguir avaliar melhor o que está sendo sugerido;
- ajustar práticas de revisão, testes e documentação para essa nova realidade.
A IA pode escrever o código mais rápido.
Mas a dívida que ela cria ou evita ainda depende de quem assina o commit.
Se você quiser continuar essa conversa, trocar experiências e ver como outras pessoas estão lidando com esse tema na prática, vale acompanhar a comunidade Software Craftsmanship Brasília em Participe da comunidade SCCB e também conferir os próximos eventos e encontros técnicos.
Próximos Passos
Algumas ideias práticas para você levar para o seu dia a dia:
- Observe seu próprio uso de IA por uma semana
- Anote em que tipos de tarefa você usa mais: gerar código, explicar, refatorar, testar.
-
Reflita onde você está usando com critério e onde está só “aceitando porque parece bom”.
-
Combine um experimento em equipe
- Escolham uma parte do sistema para usar IA de forma deliberada, com critérios claros de revisão e teste.
-
Depois de uma ou duas sprints, discutam o que melhorou e o que piorou.
-
Fortaleça um fundamento técnico
- Escolha um tema (testes, design de domínio, segurança básica) e use a IA como apoio para estudar — mas não aceite tudo sem checar.
-
Tente explicar de volta o que aprendeu, em texto ou para outra pessoa.
-
Reveja pelo menos um trecho gerado por IA em um sistema real
- Pegue um pedaço de código que você sabe que nasceu com IA.
-
Releia, refatore, escreva testes melhores e documente as decisões técnicas.
-
Discuta o papel da IA no fluxo do seu time
- Tragam a pauta para uma retrospectiva ou tech talk interna.
- Falem abertamente sobre medos, expectativas e práticas recomendadas para uso de IA como nova abstração de programação.
