O mercado de tecnologia tem o hábito de resolver problemas de eficiência comprando ferramentas. Quando os primeiros assistentes de inteligência artificial para programação surgiram, a reação foi previsível: adquirir licenças e esperar ganhos automáticos de produtividade.
A promessa de acelerar o desenvolvimento parecia atraente, mas a produtividade em engenharia de software nunca foi apenas uma questão de escrever código mais rápido. Entender problemas, definir prioridades e garantir qualidade consome uma parcela significativa do ciclo de desenvolvimento.
Não por acaso um levantamento da McKinsey aponta que 88% das organizações já utilizam IA em pelo menos uma função do negócio, e dois terços a aplicam em mais de uma área. No entanto, apenas 39% atribuem algum impacto no EBITDA ao uso da tecnologia e, entre as empresas que registram ganhos, a maioria reporta contribuição inferior a 5%. Esses dados mostram que a transformação depende de mudanças organizacionais, e não apenas de avanços tecnológicos.
Essa percepção veio da prática. Em 2025, iniciamos a adoção gradual do Copilot e passamos a acompanhar tanto a adesão dos times quanto o impacto no tempo total entre a definição e a entrega de uma demanda.
Os profissionais mais experientes foram os que incorporaram a tecnologia com mais facilidade, mas os ganhos no tempo total de entrega ficaram abaixo das expectativas. A IA acelerava tarefas específicas, sem necessariamente reduzir os intervalos entre definição, desenvolvimento, revisão e validação. A conclusão foi simples: adicionar IA a um fluxo existente não transforma o processo. É como colocar um motor de Ferrari em uma carroça, a potência aumenta, mas a estrutura continua sendo o limitador.
A inteligência artificial melhora partes do processo, mas o impacto real aparece quando a empresa repensa a forma de construir software. Acelerar a escrita de código não é suficiente quando descoberta, priorização e definição de escopo continuam funcionando da mesma maneira. O ganho de velocidade surge quando Produto e Engenharia redesenham juntos o fluxo entre a definição do problema e a validação da entrega.
Esse cenário também muda o papel do engenheiro. À medida que a IA assume parte da execução, o diferencial passa a estar na capacidade de compreender problemas, tomar decisões arquiteturais, fornecer contexto aos agentes e responder pela qualidade do sistema produzido. O conhecimento de engenharia de software não perde relevância, na verdade se torna ainda mais importante. Mesmo quando parte da execução é delegada, a responsabilidade sobre segurança, arquitetura e qualidade continua sendo humana.
Essa transformação exige revisar processos criados para uma realidade em que toda a execução era humana. Estimativas baseadas apenas em horas individuais, por exemplo, tornam-se menos representativas quando parte das atividades pode ser executada em paralelo por agentes.
Mais do que adotar IA, é preciso medir seu impacto. Contar linhas de código geradas ou sugestões aceitas pode criar uma falsa sensação de avanço. O que realmente importa é reduzir o tempo de entrega sem comprometer a estabilidade, a resolução de incidentes ou a qualidade do software.
A maior mudança provocada pela inteligência artificial não será apenas tecnológica. Empresas ainda precisam definir quanta autonomia conceder aos agentes, quais decisões exigem revisão humana e como preparar profissionais para esse novo modelo de trabalho.
A próxima vantagem competitiva não estará apenas em quem usa IA, mas em quem consegue redesenhar seus processos para trabalhar melhor com ela.
