--- title: "Agentes de IA aceleram a avaliação de projetos no ecossistema de código aberto" author: "Gabriela P. Torres" date: "2026-10-07 07:15:00-03" category: "Inteligência Artificial & Dados" url: "http://desbugados.scale.press/portal/desbugados/post/2026/10/07/agentes-de-ia-aceleram-a-avaliacao-de-projetos-no-ecossistema-de-codigo-aberto/md" --- ## Resumo - A CNCF usa agentes de IA para acelerar a due diligence de projetos antes da graduação. - A Akka testou entrega orientada por especificações em 65 projetos de código aberto. - Em 57 dos 65 projetos avaliados pela Akka, houve melhorias de código ou desempenho. - Claude e Akka Specify foram usados para gerar especificações e implementar partes dos projetos. - Especificações estruturadas ajudaram na primeira implementação, mas decisões entre componentes continuaram difíceis. - Configurações de maior esforço aumentaram o consumo de tokens sem garantir mais eficiência. - AIDLC e dados da Agoda reforçam a necessidade de rastreabilidade, verificação e revisão humana. --- Em outubro de 2026, dois testes colocaram a inteligência artificial em pontos menos chamativos, porém mais decisivos, do desenvolvimento de software: a **CNCF** passou a usar agentes para acelerar a avaliação de projetos antes da graduação, enquanto a **Akka** testou um fluxo de entrega orientado por especificações em 65 projetos de código aberto. A pergunta que separa avanço real de anúncio bem embalado é simples: a IA está apenas escrevendo mais código ou está ajudando a reduzir os gargalos que aparecem antes e depois da programação? Os dados disponíveis apontam para a segunda hipótese, mas também mostram que especificações melhores não eliminam decisões difíceis entre componentes nem transformam automaticamente mais tokens em mais eficiência. ## A avaliação de projetos também entrou na fila da automação A **CNCF** está graduando projetos em ritmo mais rápido com o apoio de agentes de IA em tarefas de due diligence, expressão usada para descrever a verificação realizada antes de uma decisão formal. Na prática, esses agentes ajudam a examinar informações e requisitos de projetos submetidos à fundação, reduzindo o trabalho manual necessário para organizar essa análise. A mudança importa porque a graduação depende de uma avaliação consistente, e não apenas da capacidade de produzir código rapidamente. Segundo **Jonathan Bryce**, diretor executivo da CNCF, a fundação acelerou esse processo usando agentes, o que desloca a IA do papel de assistente de programação para uma função ligada à análise de conformidade e maturidade dos projetos. Essa aplicação se conecta ao papel que o código aberto desempenha na infraestrutura usada por sistemas de inteligência artificial. A lógica apresentada por Bryce é que empresas conseguem adaptar seus ambientes às próprias demandas sem depender de um único fornecedor, enquanto projetos como **Kubernetes** servem de base para operar cargas de trabalho em escala. Se a infraestrutura pode ser modificada conforme a necessidade, então a avaliação dos projetos que sustentam essa infraestrutura também precisa acompanhar o volume de mudanças. A [análise sobre a atuação da CNCF](https://thenewstack.io/open-source-ai-kubernetes) mostra que a automação da due diligence não aparece isolada: ela faz parte de uma discussão maior sobre como administrar software aberto quando a demanda por sistemas de IA cresce. O próximo teste de padronização já tem local e prazo previstos. A **KubeCon** de Salt Lake City, planejada para novembro de 2026, deverá discutir a padronização de agentes e a infraestrutura necessária para operações de inteligência artificial em larga escala. O ponto não é presumir que agentes diferentes trabalharão de maneira uniforme apenas porque executam tarefas parecidas. Sem padrões para descrever tarefas, acessar ambientes e registrar decisões, cada projeto tende a criar sua própria camada de integração, repetindo trabalho e dificultando a comparação dos resultados. A discussão da CNCF, portanto, leva a uma pergunta prática: como acelerar a avaliação sem tornar menos clara a responsabilidade por cada decisão? ## O experimento da Akka troca o improviso por especificações A **Akka** conduziu um experimento com 65 projetos de código aberto para testar um modelo de desenvolvimento orientado por especificações. Nesse método, a equipe descreve com clareza o que o software deve fazer, quais condições precisa respeitar e como seu comportamento será verificado antes de pedir à IA que implemente a solução. O resultado informado foi mensurável: **57 dos 65 projetos** apresentaram melhorias de código ou de desempenho. Isso não significa que todos os projetos tenham sido resolvidos de forma automática, mas indica que a qualidade da instrução e do contexto fornecido ao modelo interfere diretamente na primeira tentativa de implementação. No fluxo testado, **Claude** foi usado com o **Akka Specify** para gerar especificações e implementar partes dos projetos. A ferramenta não recebeu apenas um pedido genérico para escrever código; o experimento examinou como a estrutura da especificação, o contexto disponível e a forma de orientar a tarefa afetavam o resultado. Essa diferença é importante para quem avalia promessas de desenvolvimento automático: se a solicitação continua vaga, o modelo precisa preencher lacunas por conta própria; se a especificação delimita o comportamento esperado, a primeira versão tende a partir de uma base mais verificável. A [descrição do teste da Akka](https://www.infoq.com/news/2026/10/ai-spec-driven-delivery) trata essa preparação como parte do processo de entrega, não como burocracia anterior ao trabalho real. A comparação entre **Sonnet** e **Opus** acrescentou uma ressalva que costuma desaparecer em apresentações comerciais: aumentar a configuração de esforço elevou o consumo de tokens sem necessariamente melhorar a eficiência. Tokens são unidades de texto que o modelo processa para interpretar instruções, consultar contexto e produzir uma resposta. Mais unidades podem significar mais custo e mais tempo de processamento, mas não garantem uma decisão melhor. O experimento também separou duas questões que frequentemente são misturadas: especificações estruturadas ajudaram na implementação de primeira passagem, porém continuaram existindo dificuldades para decidir como diferentes componentes deveriam se relacionar, justamente a parte em que o contexto técnico e o julgamento humano pesam mais. ## O ponto comum está nos gargalos, não na promessa de autonomia Os dois casos apontam para a mesma mudança de foco: a IA começa a ser avaliada pela capacidade de organizar e verificar trabalho, e não apenas pela quantidade de linhas que consegue gerar. Na CNCF, o agente atua na análise que antecede a graduação de projetos. No teste da Akka, a especificação funciona como uma moldura para limitar interpretações antes da implementação. Se o problema é falta de informação estruturada, então melhorar o contexto tende a ajudar; se o problema é uma decisão arquitetural entre componentes, então a geração automática não resolve a questão sozinha. O resultado é menos cinematográfico do que a promessa de um programador autônomo, mas muito mais útil para medir onde a tecnologia realmente entrega valor. Essa leitura também aparece na abordagem **AI-Driven Development Life Cycle**, ou AIDLC, da Kloia. O método propõe uma base de conhecimento estruturada e especificações claras para reduzir a dificuldade que as IAs têm ao interpretar ambientes específicos. Em um caso envolvendo uma **instituição financeira**, a técnica reduziu em 90% os custos de modernização e encurtou ciclos de descoberta de meses para semanas. O dado não autoriza concluir que qualquer projeto terá o mesmo resultado, porque a fonte apresenta um caso específico, mas mostra qual é a lógica operacional: antes de pedir velocidade ao modelo, a organização precisa fornecer informações organizadas sobre o sistema que será alterado. A mesma cautela aparece nos dados da **Agoda**, segundo os quais ferramentas de IA elevaram a produtividade individual, enquanto o ganho de velocidade no nível do projeto foi modesto. A diferença sugere que escrever trechos de código mais depressa não elimina as etapas de especificação e verificação, que continuam exigindo julgamento humano. Em termos práticos, uma pessoa pode produzir uma alteração em menos tempo e ainda assim consumir o ganho obtido ao revisar integrações, testar comportamentos ou corrigir uma interpretação errada do requisito. A conta, portanto, precisa considerar o ciclo completo: entender o problema, definir o resultado, implementar, verificar e decidir se a mudança pode seguir adiante. ## Como separar eficiência mensurável de marketing Para avaliar uma solução desse tipo, o primeiro passo é observar quais informações ela recebe antes de gerar qualquer resultado. O experimento da Akka examinou a estrutura das especificações, o contexto, a seleção de modelos e o desempenho em tempo de execução, quatro dimensões que permitem sair da pergunta genérica sobre qual IA é melhor. Se uma ferramenta melhora apenas a primeira implementação, então esse ganho precisa ser comparado ao trabalho de revisão posterior. Se a configuração de maior esforço aumenta o consumo de tokens sem elevar a eficiência, então aumentar indiscriminadamente o orçamento de processamento não é uma estratégia de otimização. A métrica deve acompanhar o custo e a qualidade do resultado até a execução. Na avaliação de projetos, o critério é parecido, mas o risco muda de lugar. Um agente pode acelerar a due diligence ao reunir informações e apontar itens para análise, porém a velocidade do levantamento não equivale à aprovação automática. A abordagem AIDLC mantém auditoria automática, rastreabilidade e revisão humana para decisões críticas, uma combinação que ajuda a identificar quem decidiu, com base em quais informações e em que momento. Para comunidades de código aberto, esse registro é especialmente útil porque transforma a contribuição assistida por IA em algo que pode ser conferido depois, em vez de esconder a origem das alterações atrás de uma resposta aparentemente pronta. ## O próximo passo é padronizar o trabalho e preservar a revisão Os próximos movimentos combinam escala e controle. A **CNCF** levará à KubeCon de Salt Lake City a discussão sobre padronização de agentes e infraestrutura para operações de IA em larga escala, enquanto os resultados da Akka oferecem uma lista concreta de variáveis para comparação: qualidade da especificação, quantidade de contexto, modelo escolhido, consumo de tokens e desempenho em execução. O setor terá uma base melhor para comparar ferramentas quando esses elementos forem registrados de maneira consistente, porque será possível distinguir uma melhoria na primeira passagem de uma redução real no trabalho total do projeto. Para quem desenvolve ou mantém software aberto, a caixa de ferramentas é objetiva: descreva o comportamento esperado antes da implementação, registre o contexto fornecido ao modelo, meça o custo das configurações de esforço e trate decisões entre componentes como pontos de revisão. A IA já demonstrou utilidade na avaliação de projetos e na produção orientada por especificações, mas os próprios testes indicam que a confiança depende de rastreabilidade e julgamento humano. A próxima etapa, portanto, não é entregar o controle integral ao agente; é padronizar o que ele analisa, verificar o que ele produz e manter uma pessoa responsável pela decisão final.