🤖 AI

Specification Portability Across LLM Development Agents: Cross-Agent Compatibility in Specification-Driven Software Migration

Este artigo demonstra que as especificações geradas por um agente de IA para migração de Oracle para PostgreSQL frequentemente falham ao serem portadas efetivamente para outros agentes, revelando uma degradação significativa dependente do agente na qualidade da implementação e destacando a necessidade de estratégias explícitas, como a ingestão com aumento de recuperação, para garantir a compatibilidade entre agentes em fluxos de trabalho de engenharia de software.

Autores originais: Oleg Grynets, Oleksii Ilchuk, Dariia Zatulna, Vasyl Lyashkevych

Publicado 2026-08-24

📖 5 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Oleg Grynets, Oleksii Ilchuk, Dariia Zatulna, Vasyl Lyashkevych

Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

No mundo moderno da criação de software, um novo tipo de trabalhador juntou-se à equipe: o modelo de linguagem de grande escala. Estes são programas de computador poderosos treinados em vastas quantidades de texto e código, capazes de ler uma descrição de uma tarefa e escrever as instruções que o computador precisa para executá-la. À medida que estas ferramentas se tornam mais comuns, os desenvolvedores estão a passar de simplesmente pedir que escrevam código para lhes fornecerem plantas detalhadas, conhecidas como especificações. Estas especificações atuam como guias operacionais, dizendo ao modelo exatamente o que construir, como deve comportar-se e quais as regras que deve seguir. Esta abordagem, chamada desenvolvimento orientado por especificação, promete tornar a criação de software mais fiável e estruturada. No entanto, uma questão crítica surgiu à medida que as equipas começam a utilizar múltiplos modelos diferentes para construir um único sistema: se um modelo escreve uma planta perfeita, será um modelo diferente capaz de ler essa planta e construir a mesma coisa? A suposição tem sido a de que um bom plano é um bom plano, independentemente de quem o lê, mas a realidade de como estas máquinas interpretam a informação é muito mais complexa.

Investigadores da EPAM Systems decidiram testar esta suposição tratando a migração de software como um experimento controlado. Escolheram uma tarefa específica e difícil: mover o código de uma base de dados de um sistema, Oracle, para outro, PostgreSQL. Estes dois sistemas falam linguagens semelhantes, mas possuem dialetos diferentes, exigindo uma tradução precisa de lógica, tipos de dados e funções. A equipa estabeleceu primeiro uma linha de base, fazendo com que um único modelo gerasse uma especificação e, em seguida, utilizasse essa mesma especificação para escrever o novo código. Isto funcionou razoavelmente bem; de mais de mil ficheiros fonte, o sistema regenerou com sucesso mais de 600, e quase 400 desses novos scripts funcionaram corretamente no ambiente de destino. Isto provou que o método de utilizar uma especificação de etapa intermédia era viável. Mas o verdadeiro teste veio quando introduziram um segundo modelo, diferente, na mistura.

Os investigadores criaram um cenário onde um modelo, como o Amazon Kiro, escreveria uma especificação e, em seguida, um modelo completamente diferente, como o Google Gemini ou o GitHub Copiloto, receberia esse documento para gerar o código. Eles queriam ver se o segundo modelo conseguiria compreender o plano do primeiro sem perder qualidade. Os resultados foram impressionantes e surpreendentes. O tamanho da especificação revelou-se irrelevante para o resultado. Um modelo produziu um documento massivo e detalhado com quase 1.600 linhas de texto, enquanto outro produziu uma versão concisa com apenas cerca de 200 linhas. No entanto, a extensão do documento não previu o quão bem o código funcionaria. De facto, a descoberta mais significativa foi que a origem da especificação importava imenso. Quando o Google Gemini recebeu uma especificação escrita pelo Amazon Kiro, a qualidade do código resultante colapsou. Os novos scripts falharam ao executar, continham erros de sintaxe e não se pareciam em nada com o alvo pretendido. Este fracasso não foi uma falha isolada; os investigadores repetiram o experimento e observaram o mesmo declínio dramático de desempenho, confirmando que os dois modelos simplesmente não conseguiam concordar sobre como interpretar o mesmo conjunto de instruções.

Esta incompatibilidade não era, contudo, universal, o que adicionou uma camada de nuance à descoberta. Embora o Gemini tenha tido dificuldades profundas com as especificações do Kiro, o GitHub Copiloto lidou muito melhor com os mesmos documentos estrangeiros, por vezes desempenhando tão bem com eles como o fazia com os seus próprios. Isto sugeriu que o problema não era que os planos estrangeiros fossem inerentemente maus, mas sim que diferentes modelos têm diferentes formas de ler e compreender o texto. Para abordar isto, a equipa testou várias formas de ajudar os modelos a colmatar a lacuna. Tentaram reescrever as especificações estrangeiras num novo formato que o modelo recetor pudesse preferir e tentaram comprimir o texto para o tornar mais curto. A reescrita ajudou o Gemini significativamente, elevando o seu desempenho de volta a um nível utilizável, mas a compressão do texto não ofereceu qualquer benefício real. A estratégia mais promissora envolveu uma técnica chamada geração aumentada por recuperação (RAG). Em vez de alimentar o modelo com toda a especificação de uma só vez, os investigadores deram ao modelo uma ferramenta para pesquisar através do documento e extrair apenas as partes específicas de que necessitava para a tarefa atual. Esta abordagem não venceu em todos os critérios, mas foi o único método que proporcionou um equilíbrio consistentemente forte de desempenho tanto para os modelos que estavam com dificuldades como para os que eram bem-sucedidos.

O estudo conclui que, num mundo onde o software é construído por uma equipa de diferentes agentes de inteligência artificial, uma especificação não pode ser tratada como um documento neutro e universal. Um plano escrito por um agente não é automaticamente um conjunto de instruções válido para outro. A eficácia do código depende fortemente da relação específica entre o modelo que escreveu o plano e o modelo que está a construir o software. Se uma equipa substituir um agente por outro, não pode simplesmente assumir que as plantas existentes funcionarão; podem ser necessários adaptar a linguagem do plano ou mudar a forma como o novo agente acede à informação. A investigação sugere que o futuro da engenharia de software multi-agente exigirá um novo foco em como as especificações são estruturadas e entregues, garantindo que o conhecimento contido num plano possa ser efetivamente compreendido pela máquina encarregue de o construir.

Resumo Técnico: Portabilidade de Especificação entre Agentes de Desenvolvimento de LLM

1. Declaração do Problema

O artigo aborda uma lacuna crítica de interoperabilidade em fluxos de trabalho emergentes de engenharia de software multi-agente (SDE). À medida que os Grandes Modelos de Linguagem (LLMs) transitam de assistentes baseados em prompts para agentes autônomos que geram código a partir de especificações, surge uma nova questão: uma especificação criada por um ambiente de agente LLM é confiavelmente consumível por outro?

A pesquisa atual foca no desempenho de agente único, recuperação de contexto ou esclarecimento de requisitos. No entanto, permanece empiricamente incerto se uma especificação gerada pelo Agente A (ex: Amazon Kiro) retém sua eficácia operacional quando consumida pelo Agente B (ex: Google Gemini) para produzir o código alvo. Os autores hipotetizam que as especificações não são artefatos "neutros de agente"; sua eficácia pode degradar significamente dependendo da origem da especificação e da estratégia de ingestão utilizada pelo agente de implementação.

2. Metodologia

O estudo emprega um design experimental controlado de dois estágios usando a migração de banco de dados Oracle-para-PostgreSQL como a tarefa de transformação. Este domínio foi escolhido porque requer a preservação de semânticas complexas de aplicação enquanto traduz construtos específicos de dialeto (lógica procedural, triggers, tipos de dados).

Estágio 1: Pipeline de Migração Baseado em Especificação

Tarefa: Um pipeline baseado primeiro em especificação foi avaliado em 1.006 arquivos fonte PL/SQL.
Processo: O código fonte foi decomposto em objetos de banco de dados. Um agente gerou uma especificação textual intermediária, que foi então usada para derivar a implementação em PostgreSQL.
Resultado: 623 arquivos foram regenerados com sucesso, e 380 deles executaram com sucesso no PostgreSQL 16. Isso estabeleceu a viabilidade da abordagem, mas ainda não testou a transferência entre agentes.

Estágio 2: Experimentos de Compatibilidade Cross-Agente

Dataset: 1.802 scripts Oracle com implementações PostgreSQL correspondentes.
Agentes Avaliados: Amazon Kiro, Google Gemini (via Antigravity), GitHub Copilot (via Spec Kit), Claude Code e Cursor.
Condições Experimentais:
1. Baseline Nativo: Cada agente gerou sua própria especificação e implementação.
2. Transferência Cross-Agente: Especificações geradas por um agente foram fornecidas a outro (ex: especificação do Kiro $\to$ implementação do Gemini).
3. Estratégias de Adaptação: Para mitigar a potencial degradação, três estratégias foram testadas em especificações estrangeiras:
  - Reescrita (Rewriting): O agente de implementação reescreve a especificação estrangeira para o seu formato preferido antes de codificar.
  - Compressão (Compression): Resumir a especificação estrangeira para reduzir o comprimento.
  - Geração Aumentada por Recuperação (RAG): O agente acessa a especificação estrangeira via ferramentas de recuperação em vez de ingerir o texto completo diretamente.

Métricas de Avaliação

O estudo utilizou um conjunto de métricas multidimensionais para distinguir qualidade lexical, sintática, estrutural e operacional:

F1 de Token: Similaridade ao nível de token.
Correspondência Exata (Exact Match): Porcentagem de saídas idênticas ao alvo.
Validade de Sintaxe SQL: Validade do SQL gerado (usando sqlglot).
Correspondência Exata de AST & Similaridade Média: Similaridade estrutural de Árvores de Sintaxe Abstrata (AST).
Executabilidade Imediata: Porcentagem de scripts executando sem modificação manual (notada como um limite inferior devido às restrições do ambiente de teste).

3. Resultados Principais

A. O Tamanho da Especificação Não é um Preditor de Qualidade

Ao contrário da suposição de que especificações mais detalhadas geram melhor código, o estudo não encontrou correlação entre o comprimento da especificação e a qualidade da implementação.

O Kiro gerou as maiores especificações (~1.597 linhas).
O Gemini gerou especificações significativamente menores (~193 linhas).
Apesar da diferença de tamanho, as especificações maiores do Kiro não produziram universalmente um código superior em todos os agentes ou métricas.

B. Degradação Assimétrica e Dependente de Agente

A transferência cross-agente produziu resultados altamente variáveis, confirmando que a portabilidade da especificação é direcional ( $C_{i \to j} \neq C_{j \to i}$ ).

Caso de Falha Crítica: Quando o Gemini consumiu diretamente uma especificação de origem Kiro, o desempenho colapsou.
- O F1 de Token caiu para 0.035 (vs. 0.73 nativo).
- A Validade de Sintaxe SQL caiu para 2.33% (vs. 45.54% nativo).
- A Similaridade Média de AST caiu para 0.015.
- Este padrão de falha foi replicado em uma segunda execução independente, descartando o não-determinismo aleatório.
Estabilidade em Outros Pares: Outras combinações (ex: Copilot consumindo especificações do Kiro) permaneceram relativamente estáveis ou mostraram melhorias mistas, indicando que a degradação não é uma lei universal, mas específica para pares de agente-especificação.

C. Eficácia das Estratégias de Adaptação

Reescrita (Rewriting): Melhorou substancialmente o desempenho do Gemini ao consumir especificações do Kiro, sugerindo que o formato de representação (não apenas o conteúdo) é uma fonte primária de incompatibilidade. Esta estratégia foi menos eficaz para o Copilot.
Compressão (Compression): Não proporcionou um benefício universal; a simples redução de comprimento não resolveu a incompatibilidade.
Ingestão Aumentada por Recuperação (RAG): Embora o RAG não tenha dominado todas as métricas, foi a única estratégia que apareceu nas fronteiras de Pareto tanto para o Gemini quanto para o Copilot ao lidar com especificações estrangeiras. Isso identifica o RAG como a estratégia de trade-off mais robusta entre as alternativas testadas.

4. Principais Contribuições

Evidência Empírica de Não-Portabilidade: O artigo fornece a primeira evidência empírica controlada de que especificações geradas em um ambiente de LLM não são automaticamente eficazes em outro, desafiando a suposição de artefatos intermediários neutros de agente.
Framework de Avaliação Multidimensional: O estudo introduz um conjunto de avaliação abrangente (F1 de Token, similaridade de AST, executabilidade) especificamente para transferência de especificação cross-agente, indo além de simples benchmarks de geração de código.
Análise de Estratégia de Adaptação: Avalia sistematicamente reescrita, compressão e RAG, identificando que a adaptação de representação (reescrita) e o acesso seletivo (RAG) são mais eficazes do que a simples redução de conteúdo.
Proposta de Modelo Formal: Os autores propõem um modelo onde a qualidade do código $Q_{code}$ é uma função da origem da especificação ( $A_g$ ), do agente de implementação ( $A_i$ ), da estratégia de ingestão ( $I_s$ ) e do contexto ( $C$ ), distinguindo entre preservação de conhecimento e preservação de interpretação operacional.

5. Significância e Alegações

O artigo alega modestamente que suas descobertas são empíricas e específicas ao contexto, restritas aos agentes, datasets e métricas avaliados. Não alega que especificações estrangeiras são universalmente inferiores, mas sim que sua eficácia é dependente do agente.

Significância Primária:

Implicações de Fluxo de Trabalho: Em fluxos de trabalho de SDE multi-agente heterogêneos, as especificações não devem ser tratadas como artefatos estáticos e intercambiáveis. Transferir uma especificação entre agentes pode exigir adaptação explícita (ex: reescrita ou RAG) para evitar a degradação da implementação.
Orientação de Design: Os resultados motivam o desenvolvimento de representações de especificação estruturadas (separando conhecimento, representação, dependências e granularidade) e visões de especificação específicas para cada agente.
Direção Futura: O estudo sugere que o acesso baseado em recuperação às especificações é uma estratégia robusta para pares de agentes desconhecidos, mas que mais pesquisas são necessárias sobre recuperação consciente de dependências e modelos de especificação estruturados para resolver totalmente o problema da portabilidade.

Os autores concluem que a "portabilidade de especificação" é um problema aberto que requer consideração explícita de como a informação é estruturada, transferida e interpretada através de diferentes ambientes de desenvolvimento de LLM.