A Akka conduziu um experimento em larga escala para examinar como fluxos de trabalho orientados por especificações afetam a portabilidade de software assistida por IA. O estudo envolveu 65 projetos open source e mediu tempo, consumo de tokens, tamanho de código, paridade de testes e desempenho.
Metodologia e Escopo
O experimento foi dividido em duas fases. Na primeira, a Akka analisou todos os 65 projetos, gerando especificações e implementando até 10% da superfície de cada um. Com base nos resultados e características do sistema, selecionou 10 projetos para implementação completa.
A primeira fase consumiu 99,3 horas e 9,41 bilhões de tokens, resultando em melhorias de linhas de código ou desempenho em 57 dos 65 portes.
O Fluxo de Trabalho
O harness de entrega funcionava em ciclos que incluíam:
- Descoberta: análise de código, modelos, esquemas e comportamento em tempo de execução
- Especificação: estruturação de requisitos com claims, evidências e comportamentos tipados
- Portabilidade: implementação assistida por IA usando Claude com Akka Specify
- Testes e revisão: validação automática do código gerado
- Benchmarking: comparação de testes, tamanho de código e latência
Achados sobre Especificações
Especificações estruturadas com claims, evidências e comportamentos tipados melhoraram a taxa de sucesso na primeira tentativa. No entanto, gaps permaneceram em torno de decisões entre componentes, levando a pesquisa a identificar áreas de melhoria:
- Enumeração de interfaces
- Ingestão de testes existentes
- Rastreamento de proveniência
- Testes diferenciais
- Testes adversariais
Desempenho dos Modelos
Os resultados mostraram diferenças significativas entre modelos:
- Claude Sonnet: média de 61 minutos por porto
- Claude Opus: 120 minutos por porto, mas consumindo cerca de 40% menos tokens
Confusamente, aumentar os níveis de esforço elevou o consumo de tokens sem melhorar consistentemente a eficiência.
Engenheiros que acompanharam a pesquisa levantaram pontos interessantes. Um comentário sugeriu que o comportamento do modelo menor corresponde ao trabalho de modernização observado na prática: "o modelo pequeno segue a especificação enquanto um modelo maior pode improvisar". Outra questão levantada foi se as reduções em linhas de código vieram principalmente da remoção de código morto ou de diferenças na linguagem alvo.
Um terceiro ponto destacou: "O modelo mais barato produzindo a portabilidade mais ajustada é o achado que vale a pena perseguir".
