Pra mim a cena já estabilizou. Em processos seletivos pra posições senior e acima, a pergunta sobre ferramentas de IA no fluxo de trabalho aparece com a mesma naturalidade que a pergunta sobre versionamento aparecia em 2012. A diferença é que em 2012 ainda existia margem pra responder SVN. Em 2026, responder que não usa nenhuma ferramenta de IA provoca o mesmo tipo de silêncio que responder que faz deploy por FTP provocaria numa entrevista de 2018. O entrevistador não julga explicitamente, recalibra: ajusta mentalmente o nível do candidato.
O Stack Overflow Developer Survey de 2025 registrou que 84% dos desenvolvedores usam ou planejam usar ferramentas de IA no processo de desenvolvimento, com 51% utilizando diariamente. O GitHub Copilot atingiu 20 milhões de usuários totais em julho de 2025 e está presente em cerca de 90% das empresas Fortune 100. Esses números descrevem uma curva de adoção que já ultrapassou o ponto onde a ferramenta deixa de ser vantagem competitiva e vira infraestrutura mínima. O Git seguiu uma trajetória análoga: lançado em 2005, popularizado pelo GitHub a partir de 2008, dominante por volta de 2010. Quem resistiu até 2013 acumulava um déficit de contexto operacional que ia ficando mais caro de corrigir a cada trimestre. A IA repete o padrão com velocidade comprimida: pouco mais de dois anos entre o lançamento do ChatGPT e a presença em 84% dos fluxos de desenvolvimento.
Pra mim a dinâmica é a mesma nos dois casos. Uma ferramenta atinge um nível de adoção onde os fluxos de trabalho da indústria passam a pressupor a sua existência. Code reviews pressupõem branches e pull requests. Pipelines de CI/CD pressupõem commits atômicos e tags semânticas. Quando IA entra nessa categoria, o que muda é a estrutura de expectativas sobre o que constitui uma entrega razoável num intervalo de tempo razoável. Um estudo controlado de Peng et al. (2022) com 95 desenvolvedores profissionais mostrou que o grupo com Copilot completou tarefas 55% mais rápido. Numa escala empresarial, a pesquisa da GitHub com a Accenture envolvendo 4800 participantes registrou queda no tempo médio de pull request de 9.6 pra 2.4 dias. Esses números medem velocidade de ciclo, e velocidade de ciclo é o que define throughput de equipe.
Na minha avaliação o efeito secundário é mais relevante que o direto. Quando 84% dos colegas de equipe operam com assistência de IA e os 16% restantes não, a diferença de output vai se acumulando sprint a sprint. O desenvolvedor sem IA consome proporcionalmente mais tempo de revisão dos colegas e produz menos cobertura no mesmo período. O resultado é um gap de throughput que a equipe absorve como custo distribuído. Eu já vi isso em três equipes diferentes nos últimos dois anos: o engenheiro que se recusa a usar assistência de IA acaba funcionando como um gargalo invisível, e quando os dashboards de engineering metrics tornam isso visível, a conversa de performance acontece rápido.
O argumento mais frequente contra a adoção é a desconfiança na qualidade do output. O Stack Overflow Survey de 2025 mostra que apenas 33% dos desenvolvedores confiam na precisão das respostas de IA, uma queda em relação aos 43% de 2024. A desconfiança é tecnicamente justificada: modelos alucinam e preenchem parâmetros com valores inventados, às vezes sugerindo código com vulnerabilidade. A taxa de aceitação de sugestões do Copilot é de 30% em média, o que significa que 70% das sugestões são descartadas ou requerem modificação. Essa métrica descreve o funcionamento normal da ferramenta. Um revisor humano que aceita 30% das sugestões de um colega junior e corrige as restantes está operando dentro do processo esperado de revisão. Mesmo com 30% de aceitação direta, 88% dos caracteres gerados pelo Copilot que o desenvolvedor aceita permanecem no código ao longo do tempo, o que indica que o filtro humano funciona e o que passa por ele tem qualidade de produção.
Na minha análise o trade-off real é entre o custo de aprender e o custo de não aprender. Integrar IA no fluxo de trabalho exige investimento em prompt engineering, compreensão dos limites do modelo, desenvolvimento de intuição sobre quando a sugestão é confiável e quando precisa de verificação. Esse custo é real, consome semanas de ajustamento, e durante o período de transição a produtividade pode cair antes de subir. O custo de não aprender é um déficit acumulativo que se manifesta como diferença de velocidade e como ausência nos processos seletivos que exigem demonstração de literacia em IA. Dados da Dice, plataforma de vagas especializada em tecnologia, de setembro de 2025 mostram que cerca de 50% das vagas tech nos Estados Unidos já incluíam competências em IA como requisito, quase o dobro do ano anterior. A Gartner projeta que 90% dos engenheiros de software empresariais usarão assistentes de IA até 2028. O intervalo entre o estado atual e essa projeção funciona como prazo de depreciação.
Pra mim a decisão de não usar IA já não é preferência técnica, virou posição de carreira. Posições de carreira têm consequências mensuráveis. Um desenvolvedor que em 2026 não integra nenhuma forma de assistência de IA no seu trabalho aceita um diferencial de produtividade que se acumula em cada sprint e que estreita progressivamente o conjunto de equipes e projetos onde o seu perfil se encaixa sem fricção. A questão não é a IA produzir código perfeito. O mercado já se reorganizou em torno da suposição de que todos usam.