Antes de tudo, eu realmente não acho que a engenharia de software vá desaparecer tão cedo. Se é que vai desaparecer. Ela vai evoluir. Para quem tem já compreendeu o cenário atual, ela já evoluiu. Outros vão demorar para perceber isso, mas eventualmente perceberão.
A primeira coisa que mudou foi a revisão de código. Ela praticamente deixará de existir, com exceção de alguns casos de alto risco em que seja necessária uma comprovação de correção, como sistemas bancários, contratos, aviões, pontes, arranha-céus, saúde, missões para outros planetas e assim por diante.
Isso significa que, se você trabalha principalmente escrevendo código de forma operacional, sem se envolver profundamente com arquitetura, design ou decisões técnicas mais complexas, provavelmente será cada vez menos solicitado a escrever código manualmente. E isso não é necessariamente algo negativo. Muitas dessas tarefas de programação podem ser executadas pela IA de forma mais rápida e consistente, permitindo que o profissional concentre seu tempo em atividades de maior valor, como definir soluções, validar resultados, compreender requisitos e resolver problemas.
Mas isso não significa que esse programador terá menos trabalho. Muito pelo contrário. Seu gerente vai esperar mais código de você, e não menos. Você realmente acha que seu gerente, o vice-presidente acima dele ou algum executivo do C-level vai começar a fazer vibe coding pessoalmente? Isso não escala. Não existem executivos suficientes para isso e eles custam caro demais.
Os 10% restantes dos engenheiros de software, aqueles que já trabalham com sistemas de alto risco, usarão IA para escrever dois tipos de código:
1. Transformações pontuais de dados, convertendo um formato em outro formato cujo resultado possa ser verificado. Nesse caso, eles validarão o resultado, não o código.
2. Código pequeno o suficiente para caber em uma tela e ser lido de forma compreensível. Esse código será efetivamente revisado, corrigido manualmente ou iterado com IA até que o engenheiro esteja satisfeito com aquilo que está lendo.
Os arquitetos desses sistemas de alto risco continuarão projetando os grafos de dependência entre os módulos dos projetos. Eles indicarão quais módulos poderão ser entregues aos programadores menos qualificados e quais deverão ficar sob responsabilidade dos engenheiros de software.
Os arquitetos de qualquer projeto de software de alto risco ainda precisarão compreender fundamentos de Ciência da Computação, Cloud Computing, bancos de dados, protocolos da Internet, segurança, manutenção, CPUs, paralelismo, complexidade de algoritmos, Machine Learning e muitos outros temas.
Os profissionais de UX continuarão sendo responsáveis pelas decisões relacionadas à experiência do usuário e precisarão conhecer ergonomia, psicologia do usuário, desenho de experimentos e outras disciplinas relacionadas.
Portanto, estamos diante de uma evolução e não de uma ruptura.
É exatamente por isso que continuo escrevendo artigos sobre fundamentos.
Entender como as coisas realmente funcionam tornou-se ainda mais importante, porque a era da especialização excessivamente estreita na indústria de software está ficando para trás.
Com as ferramentas atuais de IA, uma única pessoa consegue construir em semanas aquilo que antes exigiria equipes inteiras e meses de trabalho. Como consequência, as expectativas das empresas também tendem a aumentar. Cada vez mais, o profissional será chamado não apenas para escrever código, mas para compreender o problema, definir a arquitetura, escolher as tecnologias, integrar diferentes componentes, validar resultados e entregar uma solução funcional de ponta a ponta.
A expectativa será cada vez mais próxima de algo como: “Preciso dessa solução funcionando. Avalie o que é necessário, construa, valide e me avise quando estiver pronta.” Esse é o Futuro da Engenharia de Software.
David Matos
A tese é sólida: a estratificação por risco/consequência como critério para decidir onde a revisão humana permanece obrigatória é exatamente a lógica que você já está desenvolvendo com o “gap de confiança” — a ideia de que a mitigação não deve ser uniforme, mas proporcional ao custo de um erro não detectado. Estás, sem nomear assim, descrevendo camadas de verificação escalonadas: verificação de resultado (transformações de dados, onde o output é auditável) vs. verificação de processo (código pequeno o suficiente para ser lido e compreendido). Isso é quase um framework de verificação formal aplicado informalmente. Pode valer a pena você formalizar essa distinção no seu trabalho — “verificabilidade do output” como eixo, não só “criticidade do domínio”.
Onde eu questionaria: a frase “a revisão de código praticamente deixará de existir” comprime várias funções distintas da revisão em uma só — correção. Mas revisão de código historicamente também serve para:
transferência de conhecimento tácito entre membros da equipe (não é sobre achar bug, é sobre difundir contexto); consistência arquitetural ao longo do tempo (evitar deriva silenciosa entre módulos escritos por pessoas/IAs diferentes); auditoria e rastreabilidade organizacional, que existe independente de “correção técnica” (quem aprovou o quê, por quê).
Se essas funções desaparecem junto com a revisão-para-correção, a consequência não é neutra — é uma perda de conhecimento organizacional distribuído, não só uma otimização de processo.
Segundo ponto fraco: a dicotomia “10% em sistemas de alto risco vs. 90% que só valida resultado” pressupõe que “risco” é uma propriedade fixa e óbvia do sistema. Na prática, incidentes graves costumam nascer justamente em código “sem importância” — scripts internos, ferramentas auxiliares, integrações esquecidas — que ninguém classificou como alto risco a priori. Definir o que é alto risco é, em si, um trabalho de arquitetura que exige a expertise que o texto supõe estar sendo dispensada nos outros 90%.
Pergunta que fica em aberto: se a intensidade da camada de verificação deveria escalar com “verificabilidade do output” em vez de com uma classificação binária de risco do sistema, isso muda como você desenharia os checkpoints humano-no-loop dos seus agentes — não fixos por módulo, mas dinâmicos por tipo de saída que cada agente produz. Saudações.