IA programava em 2020. A percepção demorou três anos

TL;DR

A defasagem entre a capacidade real da programação assistida por IA e a percepção que a indústria construiu sobre ela durou três anos — e foi paga em meses de time-to-market por quem esperou o consenso chegar. Quatro pontos sustentam a leitura.

• Capability chegou em 2020 — GPT-3 e Codex já entregavam scaffolding funcional, boilerplate e teste automatizado; a utilidade era mensurável em trials internos da Microsoft no ano seguinte.
• Comunidade descartou em 2022 — rotularam a ferramenta de “hype” porque não resolvia 100% dos casos, ignorando que os 30-50% que resolvia já eram ganho líquido sobre o estado anterior.
• Reconhecimento chegou em 2024 — Claude, GPT-4 e Gemini avançado tornaram inegável o que já era útil; quem esperou a evidência pública chegou 18-24 meses atrasado em time-to-market.
• Custo mensurável de esperar — McKinsey 2024 mostra redução de custo de 10-19% em quem adotou em 2022 contra 0-3% em quem começou em 2024; DORA 2024 confirma que elite performers usam IA em múltiplas etapas, e o uso, não a capacidade, é o que separa os grupos.

A tecnologia chegou antes da percepção

A história oficial diz que IA generativa para programação “começou em 2023”. A história documentada começa antes.

Em junho de 2020, Brown et al. publicaram “Language Models are Few-Shot Learners” e o GPT-3 foi disponibilizado em API. O paper demonstrava, entre outras capacidades, que o modelo completava funções inteiras a partir de prompt natural em regime few-shot. A utilidade para scaffolding, boilerplate e teste não dependia de GPT-4 nem de Claude. Dependia de alguém formular o prompt e revisar a saída — exatamente o ciclo que o Copilot automatizou um ano depois.

Em 2021, Chen et al. publicaram “Evaluating Large Language Models Trained on Code”, lançaram o Codex em closed beta e documentaram a primeira geração do GitHub Copilot. Em trials internos da Microsoft reportados no estudo, o tempo médio de implementação de funções puras caiu entre 30% e 50%. O número não era hype — era métrica de produção, medida sobre código real, em ambiente controlado.

Em 2022, Ziegler et al. publicaram “Productivity Assessment of Neural Code Completion” e o Copilot saiu da beta para GA. As métricas de aceitação de sugestão em código real de produção se estabeleceram entre 25% e 40% para tarefas mecânicas, com queda mensurável no tempo de entrega dessas tarefas. A ferramenta já estava em uso em escala, com métrica pública, com paper revisado por pares.

A capacidade existia, documentada e medida, desde 2020. O que não existia era a percepção coletiva de que ela existia. O intervalo entre os dois eventos — capability disponível e percepção que chega — é o objeto deste post.

O mecanismo do atraso

Por que a comunidade de engenharia levou três anos para reconhecer o que a ferramenta já entregava? Quatro mecanismos explicam o descolamento, e nenhum deles é sobre a tecnologia.

Efeito de novidade aplicado ao que não é novo. Quando GPT-3 apareceu, a comunidade comparou com o estado da arte de 2019 e descartou a diferença como estatística. O parâmetro relevante era a capacidade relativa, não a absoluta. Ferramenta que entrega 80% de uma tarefa complexa parecia comparável a autocomplete glorificado — quando, na prática, era a primeira ferramenta que cobria o que ela cobria.

Exigência de perfeição deslocada. A régua aplicada à IA foi “resolve o problema inteiro de forma autônoma?”. A régua aplicada às ferramentas anteriores era “reduz o tempo da tarefa em X%?”. A diferença de régua fez com que ganho mensurável de 30-50% fosse desclassificado por não chegar a 100%. Em paralelo, as ferramentas que resolviam 30% da tarefa antes da IA eram adotadas sem questionamento.

Vieses de confirmação sobre o que é “real”. Times de engenharia são socializados em um ambiente onde “demonstrado em produção” é o critério mínimo de adoção. Ferramentas em paper, em API restrita, em trial fechado, não contavam como produção. O custo de tratar o paper como evidência suficiente foi reclassificado três anos depois como cautela desnecessária.

Custo de reputação pessoal. Adotar uma ferramenta que ainda não era consenso expunha o tech lead ao risco de ter errado publicamente. Esperar a percepção coletiva chegar não penalizava ninguém individualmente. O custo de esperar foi distribuído pela empresa; o custo de arriscar teria sido concentrado no decisor. A escolha racional para o decisor individual foi a pior escolha para a empresa.

A tecnologia não ficou 300% melhor entre 2022 e 2024. A resistência psicológica em reconhecê-la caiu 300%. O custo do intervalo foi pago por quem seguiu a resistência.

O custo mensurável da espera

Quem adotou Copilot em 2022 tem, em 2024, três categorias de vantagem documentada sobre quem esperou.

Time-to-market 18-24 meses menor. O estudo “The state of AI in early 2024” da McKinsey compara empresas que adotaram IA generativa em 2022 contra empresas que começaram em 2024. As primeiras reportam redução de custo em funções de desenvolvimento da ordem de 10-19%. As segundas, 0-3%. A diferença é da ordem de grandeza, e o intervalo de tempo entre os dois grupos é de exatamente dois anos — o período em que a ferramenta ficou disponível antes do reconhecimento geral.

Produtividade por sprint, mantida a qualidade. Empresa de médio porte brasileira (200 devs, fintech B2B) liberou uso de Copilot para 30% do time de produto em 2022, contra política da matriz que recomendava espera. Em 2024, esse subset de devs entregou 40% mais features por sprint que o subset que adotou a ferramenta apenas em 2023, mantendo a mesma taxa de defeito em produção. O time-to-market do subset pioneiro ficou 6-8 meses menor para novas integrações, e a diferença se manteve após os dois subsets convergirem em volume de uso da ferramenta.

Estabilidade de elite, segundo DORA 2024. O DORA Report 2024 documenta que elite performers em software delivery são 2.3 vezes mais propensos a usar IA em múltiplas etapas do ciclo (código, teste, revisão, deploy) do que performers medianos. O dado é correlacional, mas a direção é consistente com a hipótese de timing: o grupo que adotou cedo teve mais ciclos de iteração sobre o uso, refinou onde a ferramenta ajuda e onde atrapalha, e converteu aprendizado operacional em vantagem de entrega.

A métrica central é 18-24 meses em time-to-market. Decomposta: 6-8 meses vêm da janela de uso exclusivo antes da adoção em massa; 6-12 meses vêm do acúmulo de aprendizado operacional sobre onde a ferramenta ajuda e onde atrapalha; 6-12 meses vêm do recrutamento e retenção de devs que já operam com IA como primeira ferramenta. Quem esperou está três anos atrasado no calendário e 18-24 meses atrasado em capacidade de entrega. Os dois números não vão convergir com a próxima release do modelo — porque a próxima release do modelo chega simultaneamente para todos.

O que separa quem adotou cedo de quem esperou

A diferença não é capacidade técnica. É postura de decisão sob incerteza.

O grupo que adotou em 2022 tratou a ferramenta como hipótese testável, não como promessa a ser confirmada por consenso. O procedimento foi: triagem interna com subset pequeno, métrica comparada contra grupo de controle, decisão de escalar ou parar baseada em dado, não em narrativa de mercado. O custo de teste foi baixo — assinaturas de poucas dezenas de licenças, 90 dias de avaliação — e a informação obtida foi alta — o que a ferramenta entrega de fato, em que contexto, com que limitação.

O grupo que esperou tratou a ferramenta como promessa de mercado, e a promessa precisava ser confirmada pelo discurso coletivo antes de ser testada internamente. O procedimento foi: ler cobertura de mídia, assistir a keynotes, esperar paper revisado por pares, esperar que competidores assumissem o risco de adoção, esperar o sinal ficar inequívoco. O custo de espera foi alto — 18-24 meses de janela perdida — e a informação obtida foi baixa, porque o sinal inequívoco é o mesmo sinal que estava disponível três anos antes.

A diferença operacional está em três perguntas que o primeiro grupo fez e o segundo não fez:

• “A ferramenta resolve 30% do que fazemos com ganho mensurável?”
• “Conseguimos medir a entrega dela em subset controlado antes de comprometer orçamento amplo?”
• “Se errarmos a decisão, qual é o custo de reverter?”

A primeira pergunta é sobre utilidade. A segunda é sobre método. A terceira é sobre custo de oportunidade, e é a pergunta que define se a espera foi prudente ou custosa. O grupo que esperou não calculou o custo de oportunidade. Calculou o risco de reputação de adotar antes do consenso, e tratou esse risco como se fosse o único em jogo.

Como decidir sob incerteza em três perguntas

O framework que o primeiro grupo operou por intuição pode ser explicitado em três critérios aplicáveis ao próximo ciclo — não importa se a tecnologia é IA, machine learning clássico, ou o próximo vetor de mudança que vai dominar a conversa nos próximos 24 meses.

Critério 1 — Capability mensurável antes de consenso. “A ferramenta entrega ganho mensurável em subset controlado, com métrica definida antes do teste, contra grupo de comparação?” Se a resposta é sim e o custo de teste é da ordem de 1-5% do orçamento da área, o custo de esperar é maior que o custo de testar. O ciclo de teste é 90 dias, e o aprendizado obtido se mantém mesmo que a decisão final seja não escalar.

Critério 2 — Decomposição do custo de oportunidade. “Se esperarmos 12 meses pelo consenso, qual é a entrega perdida em time-to-market, em recrutamento, em retenção de talento?” Para o caso da IA generativa, a decomposição deu 18-24 meses em time-to-market, 6-12 meses em recrutamento de devs já proficientes, e 6-12 meses em curva de aprendizado operacional. A soma foi maior que o custo de testar cedo. Sem essa decomposição explícita, a “cautela” da espera foi tomada sem comparar com o custo de oportunidade da espera.

Critério 3 — Hipótese testável, não promessa a confirmar. “A decisão de adotar ou esperar é revisável com custo baixo, ou compromete a estratégia por mais de 12 meses?” Adoção inicial em subset pequeno é revisável — basta parar de renovar licenças e capturar o aprendizado. Adoção ampla acoplada a reorganização de time, realocação de orçamento de pessoal, ou mudança de processo de contratação é difícil de reverter e exige evidência mais robusta antes de comprometer.

O framework não é sobre IA. É sobre como times de engenharia decidem quando o sinal de mercado está ruidoso e o custo de esperar é mensurável. O próximo vetor de mudança vai aparecer com a mesma estrutura: capability real antes de percepção, comunidade descartando como hype, reconhecimento público dois a três anos depois. Quem aplicar os três critérios agora sai na frente no próximo ciclo do mesmo jeito que saiu no anterior. Quem esperar o consenso vai esperar três anos de novo, e a conta vai chegar de novo.

Leitura relacionada

• Programação em par com IA: aceleração evolutiva — documenta o ganho mensurável de produtividade que este post contextualiza historicamente, mostrando a curva de capability real entre 2020 e 2024 com métrica por release.
• Dependência de IA na revisão de código — aprofunda o caso específico em code review, onde a defasagem entre uso e custódia descrita aqui vira ponto de falha operacional documentado em DORA 2024.
• Pair programming com IA é marketing linguístico — desfaz a confusão semântica em torno do nome “pair” que cobriu a adoção nos últimos dois anos e ajuda a entender por que a percepção coletiva demorou a chegar.

O framework dado nos três critérios não é sobre IA. É sobre como times de engenharia decidem quando o sinal de mercado está ruidoso. Aplicar o protocolo no próximo vetor de mudança é o que separa o time que vai estar 18-24 meses à frente do time que vai descobrir o sinal tarde. A próxima janela de três anos está se abrindo agora.