Neste artigo
Se alguma vez olhou para uma folha de cálculo COCOMO II e a viu prever 33 meses de calendário para um projeto que a sua equipa entregou em dois sprints, já conhece o problema: todos os modelos de estimativa hoje em uso foram calibrados para um mundo em que os programadores escrevem cada linha, em que mudar de contexto tem um custo e em que o calendário para às 17h00. Esse mundo já não existe. Desenvolvemos recentemente de raiz uma aplicação com 286 KLOC, 672 ficheiros e vários subsistemas (camada de protocolo, camada de dados, motor de renderização, integração com a plataforma) e chegámos a uma versão alfa pronta para testes em 7 dias. O painel completo de modelos (COCOMO Basic/Intermediate/Post-Architecture, Function Points, referência SLOC, Putnam/SLIM) devolveu uma previsão mediana de 30,3 meses de calendário. O multiplicador de produtividade mediano: 4240×. Até a referência mais conservadora (25 SLOC por dia de programador para sistemas complexos) errou por um fator de 1433×. Os modelos não estão errados. Estão a ser mal aplicados. Segue-se a análise modelo a modelo, a calibração empírica com o mesmo autor e o que a literatura de ensaios controlados aleatorizados de 2024 a 2026 diz realmente sobre os casos em que a IA agêntica comprime os prazos, e aqueles em que não o faz.
O projeto que fez rebentar as estimativas
Na RIADVICE, desenvolvemos recentemente uma aplicação complexa e rica em funcionalidades, do tipo que coordena vários subsistemas numa arquitetura distribuída, como ambiente nativo multiplataforma para dispositivos móveis e computadores a partir de uma única base de código, impulsionada por requisitos de mercado que exigiam uma nova implementação. A base de código mostra a escala:
- 286 662 SLOC (~286 KLOC) distribuídas por 672 ficheiros de código-fonte
- 1 329 399 linhas de churn total: 862 488 inserções e 466 911 eliminações
- 700 commits em 7 dias de desenvolvimento ativo até à primeira versão alfa pronta para testes
- Internacionalização completa em dezenas de idiomas
- Vários subsistemas sem qualquer relação entre si (tratamento de protocolos, gestão de dados, renderização e integração com a plataforma), todos construídos de raiz para o ambiente de destino
Não se tratou de um invólucro nem de uma simples mudança de aspeto. Foi uma implementação nativa construída de raiz para responder a requisitos de mercado que as soluções existentes não conseguiam cumprir. Antes de escrever uma única linha, integrei no projeto uma ferramenta de análise própria que aplica o painel completo de modelos de estimativa de esforço de software de referência no setor à base de código, à medida que esta cresce. O objetivo era honesto: medir a diferença entre o que os modelos clássicos preveem e o que uma entrega assistida por IA realmente produz. Os resultados não são um erro de arredondamento. São uma rutura de categoria.
O que os modelos de estimativa previam e o que realmente aconteceu
A ferramenta aplica todos os grandes modelos de estimativa da literatura de engenharia de software (COCOMO Basic nos modos Organic, Semi-Detached e Embedded, COCOMO Intermediate nos modos Semi-Detached e Embedded, ajustado, COCOMO II Post-Architecture, ajustado, Function Points, a referência de produtividade SLOC e Putnam/SLIM), calibrados para o tipo de projeto com as constantes publicadas na literatura original.
| Modelo de estimativa | Esforço previsto | Calendário previsto | Aceleração face ao real |
|---|---|---|---|
| COCOMO Basic (Organic) | 913 pessoas-mês | 33,3 meses | 2282× |
| COCOMO Basic (Semi-Detached) | 1696 pessoas-mês | 33,7 meses | 4240× |
| COCOMO Basic (Embedded) | 3200 pessoas-mês | 33,1 meses | 8000× |
| COCOMO Intermediate (Semi-Det., ajustado) | 1259 pessoas-mês | 30,4 meses | 3148× |
| COCOMO Intermediate (Embedded, ajustado) | 2376 pessoas-mês | 30,1 meses | 5940× |
| COCOMO II Post-Architecture (ajustado) | 1703 pessoas-mês | 30,3 meses | 4257× |
| Function Points (cálculo aproximado) | 17,9 pessoas-mês | 7,5 meses | 45× |
| Referência de produtividade SLOC (25 SLOC/dia) | 573 pessoas-mês | 573,3 meses | 1433× |
| Putnam/SLIM | ignorado (duração < 30 dias; T 4/3 dispara) | n.a. | n.a. |
O multiplicador de produtividade mediano de todos os modelos é de 4240×. Até o modelo mais conservador prevê um prazo de entrega cerca de 1400 vezes mais longo do que o real. O mais otimista, Function Points, previa ainda assim 7,5 meses de calendário, ou seja, um prazo 45× mais longo do que os 7 dias reais. Segundo os modelos, este projeto deveria ter levado entre 7 meses e 47 anos. Uma versão alfa estava pronta para testes em 7 dias.
Os modelos contradizem-se entre si, por fatores de 50× a 8000×
Estes modelos não estão de acordo entre si. Sobre a mesma base de código, as previsões vão de 17,9 a 3200 pessoas-mês, uma dispersão de 178×. O estudo comparativo SEAA 2013 do COCOMO II, SEER-SEM, SLIM e TruePlanning em 51 projetos reais encontrou um MMRE de 50 a 100%. Uma avaliação de 2023 sobre o conjunto de dados COCOMO da NASA encontrou um MMRE próximo de 1,0 e um PRED(0,25) = 0,0: nem um único projeto estimado dentro da margem de erro de 25%. Os modelos nunca foram concebidos para um projeto assistido por IA. Mas a dimensão da diferença, mesmo tendo em conta a imprecisão dos modelos, mostra que algo estrutural mudou.
O que a investigação diz realmente sobre a IA agêntica e a produtividade dos programadores
O valor de 4240× é extremo, e não o quero sobrevalorizar. A criação de estruturas de raiz infla o churn, e as SLOC são um indicador fraco do valor. Vejamos, por isso, a literatura com revisão por pares. Os assistentes do tipo Copilot trazem ganhos modestos, mas reais. Peng et al. (2023) concluíram que os programadores que usavam um assistente de programação com IA concluíam uma tarefa 55,8% mais depressa (IC 95%: 21-89%). O ensaio controlado aleatorizado da Microsoft, da Accenture e de uma empresa da Fortune 100 (2025), o maior estudo até à data, com n=4867, registou um aumento de 26% nas tarefas concluídas. O ensaio interno da Google (2024) registou uma redução de cerca de 21% no tempo dedicado à tarefa. A experiência de campo do BIS e do Ant Group (2024) mediu um aumento de 55% na produção de código entre os perfis juniores. O resumo honesto: de 1,26× a 1,56× nas tarefas adequadas. Real, mas não transformador. A IA agêntica funciona noutro regime. A análise de 2025 da Cognition sobre o Devin relatou resultados de clientes de 10× em migrações ETL, 14× em migrações de versões Java e 20× em correções de segurança. O Nubank relatou uma melhoria de eficiência de 12× e poupanças de custos de 20× numa refatoração de vários milhões de linhas, anteriormente estimada como um esforço de vários anos para mil engenheiros. O nosso projeto situa-se exatamente neste intervalo: o histograma de commits mostra picos densos às 22h00, às 00h00 e à 01h00, a marca das sessões conduzidas por agentes. As evidências em sentido contrário são reais. O ensaio controlado aleatorizado de 2025 da Metr.org (16 programadores experientes, 246 tarefas em projetos maduros) concluiu que a IA aumentou o tempo de conclusão em 19%: atrasou programadores experientes em bases de código que conheciam. Um estudo de diferenças em diferenças de 2026 sobre 807 repositórios GitHub que adotaram ferramentas de IA (He et al., MSR ’26) encontrou um aumento «transitório» da velocidade e um aumento «persistente» da complexidade do código, que provocou um abrandamento a longo prazo. O título diz tudo: Speed at the Cost of Quality. O consenso: a IA ajuda muito no desenvolvimento de raiz e estruturado, ajuda modestamente nas tarefas de conclusão e pode prejudicar a velocidade em bases de código maduras. A dívida de qualidade é real.
Porque falham os modelos: três mudanças estruturais
Nenhum dos fatores de custo dos modelos clássicos tem uma opção para «o programador dispõe de um agente autónomo que nunca dorme e tem toda a base de código em contexto». Três mudanças fazem colapsar a curva de duração:
- O estrangulamento da escrita desapareceu.
Os modelos partem do princípio de que uma parte significativa do esforço é mecânica: código repetitivo, estruturas de base, refatorações repetitivas, recursos de localização e outros dados estruturados. Neste projeto, grande parte do volume é texto e ligações muito regulares que um agente consegue gerar ou transformar em massa. O próprio código feito à mão (estruturas, construtores, ligação à plataforma) passa a ser gerado em rajadas, e não escrito linha a linha.
- O custo da mudança de contexto está a desaparecer.
Uma pessoa que passa da camada de protocolo para a camada de dados e para o motor de renderização paga de cada vez um custo de carregamento de contexto. Um agente que leu todo o repositório de 672 ficheiros paga-o uma única vez. Esta assimetria acumula-se depressa numa base de código desta dimensão.
- O calendário deixou de ser o estrangulamento.
Os modelos convertem pessoas-mês em meses de calendário através de uma equação de afetação de pessoal que pressupõe um dia de trabalho humano. As sessões dos agentes decorrem durante a noite. O histograma de commits mostra uma produção contínua das 07h00 à 01h00: 18 horas ativas, e não 8.
A calibração empírica com o mesmo autor
Como os modelos paramétricos divergem em ordens de grandeza, fiz também uma calibração empírica entre projetos, comparando o meu próprio churn de código por pessoa-dia antes e depois de adotar uma ferramenta de IA agêntica, em três outros repositórios de produção do mesmo ecossistema:
| Projeto | Churn/dia antes da IA | Churn/dia com IA | Multiplicador |
|---|---|---|---|
| Projeto A (balanceador de carga) | 673 | 2056 | 3,1× |
| Projeto B (serviço de relatórios) | 239 | 2127 | 8,9× |
| Projeto C (serviço de tratamento) | 1322 | 982 | 0,7× |
| Agregado (média / mediana) | n.a. | n.a. | 4,2× / 3,1× |
O mesmo autor, o mesmo domínio, trabalho real de manutenção. O multiplicador empírico é de 3 a 9×, muito mais conservador do que o valor de 4240× do desenvolvimento de raiz, e coerente com o limite superior da investigação publicada sobre IA agêntica. Um dos projetos ficou mesmo mais lento: os ganhos dependem da tarefa e não são universais.
O que isto significa para o planeamento de projetos
Se ainda estima projetos de software com modelos não calibrados e uma referência de 25 SLOC por dia, vai errar por uma a três ordens de grandeza no trabalho assistido por IA. Eis o que fazemos na RIADVICE:
- Calibre com base no seu próprio histórico. Compare a sua própria produção de código por pessoa-dia com e sem IA. É mais barato, mais honesto e dá um intervalo de 3 a 9× que pode defender num plano de projeto.
- Separe o desenvolvimento de raiz da manutenção. O multiplicador da IA agêntica é máximo no desenvolvimento de raiz e estruturado, e mínimo (por vezes negativo) na manutenção de bases de código maduras. Não aplique o mesmo número aos dois casos.
- Preveja um orçamento para a dívida de qualidade. A velocidade da IA traz aumentos persistentes da complexidade. Planeie uma fase de consolidação e meça-a: acompanhe a complexidade ciclomática e execute a deteção de código duplicado em cada versão.
- Estime a curva inteira, não apenas o início. Um ganho de velocidade de 10× que duplica a densidade de defeitos não é um ganho de 10×: é um calendário antecipado à custa de uma fase de estabilização mais longa.
Em resumo
Um projeto que, segundo todos os modelos de estimativa, deveria levar entre 7 meses e 47 anos chegou a uma versão alfa pronta para testes em 7 dias. O multiplicador mediano de 4240× não deve servir de plano de projeto a ninguém. Mas é um sinal claro de que a duração do desenvolvimento de software complexo está a ser comprimida pela mesma força que está a comprimir o esforço. A investigação publicada mostra a IA a trazer desde um ligeiro ganho de 1,26× até um salto de 20×, com um risco real de retorno negativo em bases de código maduras e um custo mensurável em qualidade. Os modelos que nos diziam que este projeto levaria décadas são os mesmos que continuam hoje a correr nas folhas de cálculo de estimativa das empresas. A questão não é saber se a IA agêntica altera a duração dos projetos: a investigação já respondeu. A questão é saber se a sua prática de estimativa acompanhou as evidências. Se os seus números ainda vêm de um modelo de 1981 calibrado em COBOL e assembly, é altura de recalibrar, ou pelo menos de deixar de acreditar no calendário que ele lhe apresenta.
«Continua a haver uma margem de melhoria significativa para dar uma melhor resposta aos desafios de previsão enfrentados na prática.»
Accuracy of Contemporary Parametric Software Estimation Models, SEAA 2013
🏆 Engenharia e competência em nuvem de confiança
RIADVICE: o seu parceiro de confiança em engenharia de software
Concebemos, construímos e implementamos sistemas de software complexos com a disciplina de engenharia e as ferramentas necessárias para entregar na era da IA: dentro do prazo, dentro do orçamento e com qualidade.
Saiba mais sobre os nossos serviços →
📚 Fontes e leituras complementares
Este artigo baseia-se em investigação com revisão por pares, ensaios controlados aleatorizados e relatórios de terreno do setor sobre a produtividade do desenvolvimento de software assistido por IA e a estimativa do esforço de software:
- Estudos de produtividade da IA (ensaios controlados aleatorizados e experiências de campo)
- Peng, S., Kalliamvakou, E., Cihon, P., & Demirer, M. (2023). The Impact of AI on Developer Productivity: Evidence from GitHub Copilot, arXiv:2302.06590: redução de 55,8% no tempo de conclusão das tarefas
- Cui, R., et al. (2025). The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software DevelopersMicrosoft Research: n=4867, +26,08% de tarefas concluídas
- Dam, S., et al. (2024). How much does AI impact development speed? An enterprise-based randomized controlled trial, arXiv:2410.12944: ensaio da Google, n=96, redução de cerca de 21% no tempo dedicado à tarefa
- Becker, B., et al. (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer ProductivityMetr.org: ensaio controlado aleatorizado, n=16, 246 tarefas; a IA aumentou o tempo de conclusão em 19%
- He, H., Miller, C., Agarwal, S., Kästner, C., & Vasilescu, B. (2026). Speed at the Cost of Quality: How Cursor AI Increases Short-Term Velocity and Long-Term Complexity in Open-Source Projects, arXiv:2511.04427: estudo de diferenças em diferenças sobre 807 repositórios GitHub; MSR ’26
- Evolver Business Solutions (2026). For a few tokens more: The productivity effect of AI tools on software development tasksReplicação com resultado de +13% (não significativo)
- Relatórios do setor sobre IA agêntica
- Cognition AI (2025). Devin’s 2025 Performance Review: Learnings From 18 Months of Agents At Work10× em migrações ETL, 14× em migrações Java, 20× em correções de segurança
- Nubank / Cognition. How Nubank refactors millions of lines of code to improve engineering efficiency with Devin12× em horas de engenharia, poupanças de custos de 20× numa refatoração de vários milhões de linhas
- BIS / Ant Group (2024). Experiência de campo; +55% de produção de código, concentrado nos perfis juniores
- Estimativa do esforço de software: fundamentos e precisão
- Boehm, B. W. (1981). Software Engineering Economics. Prentice Hall: o COCOMO original
- Boehm, B. W., Abts, C., & Chulani, S. (2000). Software Cost Estimation with COCOMO II. Prentice Hall: calibrado em 161 projetos
- SEAA 2013. Accuracy of Contemporary Parametric Software Estimation ModelsCOCOMO II, SEER-SEM, SLIM e TruePlanning em 51 projetos; MMRE de 50 a 100%
- Kemerer, C. F. (1993). An empirical validation of software cost estimation models, Communications of the ACM
- Nguyen, V., et al. (2019). Determining relevant training data for effort estimation using window-based COCOMO calibrationCalibração por janelas em 341 + 93 projetos
- Ahmad, M., & Wani, M. A. (2023). Evaluation of COCOMO Model Accuracy in Software Effort EstimationMMRE ~1,0, PRED(0,25) = 0,0
- Putnam, L. H. (1978). A general empirical solution to the macro software sizing and estimation problem. IEEE TSE: o modelo Putnam/SLIM
⚡ RIADVICE.com oferece engenharia de confiança, competência em nuvem e soluções de software de nível empresarial: dentro do prazo, dentro do orçamento e com qualidade.
