Beyond Functional Correctness: Design Issues in AI IDE-Generated Large-Scale Projects

Este estudo avalia a capacidade da ferramenta Cursor, auxiliada pelo framework FD-HITL, em gerar projetos de software de grande escala funcionalmente corretos, revelando que, embora atinjam uma taxa de correção funcional de 91%, os sistemas gerados apresentam inúmeros problemas de design que comprometem a manutenibilidade e violam princípios fundamentais de engenharia de software.

O essencial

Imagine que você decidiu construir uma cidade inteira usando um assistente de construção superinteligente, um robô que sabe tudo sobre arquitetura e engenharia. Você dá a ele um plano simples: "Construa uma cidade com prédios, ruas e lojas". O robô trabalha a noite toda e, de manhã, você tem uma cidade pronta! As luzes acendem, as portas abrem e as pessoas podem entrar. Parece mágico, não é?

Mas, se você começar a andar pelas ruas dessa cidade, vai notar algumas coisas estranhas. Alguns prédios têm paredes duplas desnecessárias (como se o robô tivesse esquecido de apagar o esboço). Outros têm escadas que levam a lugar nenhum, ou salas tão grandes e bagunçadas que é difícil encontrar a saída. A cidade funciona, mas é um caos para manter ou expandir no futuro.

É exatamente isso que este estudo descobriu sobre os novos "IDEs com Inteligência Artificial", como o Cursor.

O Que os Pesquisadores Fizeram?

Os autores deste estudo (um grupo de cientistas de computação da China, Nova Zelândia e Austrália) queriam testar até onde esses robôs programadores conseguiam ir. Eles não pediram apenas um "códigozinho" (como um botão de login), mas sim 10 projetos de software grandes e complexos, como:

• Um aplicativo de rede social (como um mini-Facebook).
• Um sistema de gestão escolar.
• Uma loja online completa.
• Ferramentas de utilidade.

Eles usaram uma técnica especial chamada FD-HITL. Pense nisso como dar ao robô um "manual de instruções" muito detalhado, em vez de apenas um comando vago. Eles disseram: "Primeiro, vamos planejar a estrutura. Depois, vamos construir o banco de dados. Agora, vamos fazer o fundo da tela. Teste cada parte antes de seguir para a próxima."

O Que Eles Descobriram?

1. O Robô é Rápido e Funcional (Mas não Perfeito)

Com o "manual de instruções" certo, o Cursor conseguiu construir cidades inteiras!

• Tamanho: Os projetos gerados eram enormes, com uma média de 17.000 linhas de código e 114 arquivos cada.
• Funcionamento: Cerca de 91% do que foi pedido funcionava. As luzes acendiam, as portas abriam. O robô conseguiu fazer o trabalho básico muito bem.

2. O Problema: A "Cidade" Tem Muitos Defeitos de Projeto

Aqui está a parte importante: embora a cidade funcione, ela foi construída com muitos defeitos de engenharia. Os pesquisadores usaram dois "inspetores de qualidade" (ferramentas chamadas CodeScene e SonarQube) para varrer o código e encontraram mais de 4.000 problemas de design.

Aqui estão os principais "defeitos de construção" encontrados:

• Cópia e Cola Excessiva (Duplicação de Código):

  • Analogia: É como se o robô construísse 10 casas idênticas, mas em vez de usar um molde, ele construiu cada uma do zero, tijolo por tijolo, repetindo o mesmo trabalho. Se você precisar pintar todas as casas de azul, terá que pintar 10 vezes o mesmo trabalho.
  • O que significa: O código é repetitivo e difícil de manter. Se houver um erro, você precisa corrigir em 10 lugares diferentes.

• Salas Gigantes e Confusas (Métodos Grandes e Complexos):

  • Analogia: Imagine um único cômodo que serve como cozinha, quarto, banheiro e sala de estar ao mesmo tempo, com móveis empilhados de forma caótica. É difícil saber onde começar a limpar.
  • O que significa: O robô escreveu funções de código gigantescas que fazem tudo de uma vez. Isso viola o princípio de "fazer uma coisa só bem feita". É difícil de testar e fácil de quebrar.

• Regras de Construção Ignoradas (Violação de Melhores Práticas):

  • Analogia: O robô construiu uma escada sem corrimão ou usou cimento que não é permitido em prédios altos.
  • O que significa: O código não segue as regras modernas de segurança e organização (como tratar erros de forma correta ou validar dados).

• Acessibilidade Cega:

  • Analogia: A cidade tem escadas, mas nenhuma rampa para cadeiras de rodas.
  • O que significa: O código gerado muitas vezes ignora pessoas que usam leitores de tela ou navegam apenas pelo teclado, tornando o software inacessível para parte da população.

A Lição Principal: O Robô é um Operário, Não um Arquiteto

O estudo conclui que os IDEs com IA (como o Cursor) são incríveis operários. Se você der a eles um plano claro, eles podem construir a estrutura básica muito rápido.

PORÉM, eles ainda não são arquitetos.

• Eles não entendem a "grande visão" de como o sistema deve evoluir nos próximos 5 anos.
• Eles tendem a criar soluções rápidas e sujas que funcionam hoje, mas que vão virar um pesadelo para manter amanhã.

O Que Isso Significa Para Nós?

Se você é um desenvolvedor ou alguém que usa IA para criar software:

1. Não confie cegamente: Não basta pedir "crie um app" e esperar que fique perfeito.
2. Seja o Chefe de Obra: Você precisa fazer o planejamento, dividir o trabalho em pequenas partes e revisar o que o robô fez.
3. Faça a Limpeza: O código gerado pela IA precisa de uma "revisão humana" rigorosa para corrigir a bagunça (duplicação, complexidade e falta de acessibilidade) antes de ser usado em um produto real.

Em resumo: A IA é uma ferramenta poderosa que acelera a construção, mas o engenheiro humano ainda é essencial para garantir que a cidade não desabe no futuro.

Resumo técnico

1. Problema e Contexto

A integração de Inteligência Artificial (IA), especificamente Modelos de Linguagem (LLMs), transformou o desenvolvimento de software. Ferramentas anteriores (como GitHub Copilot) focavam na geração de snippets de código. No entanto, uma nova geração de IDEs com IA (como o Cursor), dotadas de capacidades "agentes" (capacidade de interagir com o ambiente do projeto, ler bases de código e planejar mudanças), promete gerar código no nível do projeto inteiro.

Apesar do potencial, existem lacunas de pesquisa críticas:

1. Escala: A literatura existente não avaliou se essas IDEs podem gerar sistemas de software de grande escala (com complexidade industrial, múltiplos componentes e milhares de linhas de código).
2. Qualidade de Design: Embora a correção funcional seja frequentemente estudada, há uma falta de evidências empíricas sobre a qualidade de design (arquitetura, manutenibilidade, evolvabilidade) desses projetos gerados em escala. O foco excessivo na velocidade ("Vibe Coding") pode comprometer a qualidade a longo prazo.

O objetivo do estudo é explorar a capacidade do Cursor em gerar projetos de grande escala e avaliar as questões de design resultantes, indo além da simples verificação de "se o código funciona".

---

2. Metodologia

Os autores conduziram um estudo empírico estruturado em duas fases principais: geração de projetos e avaliação de qualidade.

2.1. Framework FD-HITL (Feature-Driven Human-In-The-Loop)

Para superar as limitações de prompts ad hoc, os autores propuseram e utilizaram o framework FD-HITL. Este método sistematiza a geração de projetos em quatro fases, mantendo o desenvolvedor humano no ciclo de controle:

1. Inicialização do Projeto: Definição do contexto e escolha da pilha tecnológica (Tech Stack) através de prompts estruturados.
2. Requisitos e Design: Geração de arquivos requirements.md e tasklist.md. O projeto é decomposto em funcionalidades independentes e testáveis (roadmap incremental).
3. Implementação: Ciclo de desenvolvimento orientado a funcionalidades. O Cursor gera o código (backend/banco de dados primeiro, depois frontend) para uma funcionalidade de cada vez. O humano testa, valida e fornece feedback para correção de bugs antes de avançar para a próxima funcionalidade.
4. Revisão e Teste do Sistema: Teste manual de todo o sistema para garantir consistência e correção lógica final.

2.2. Geração de Dados

• Amostra: 10 projetos de grande escala gerados pelo Cursor Pro.
• Domínios: Aplicações Web, Mobile e Ferramentas Utilitárias.
• Tecnologias: MERN Stack, Spring Boot, Django, React Native, WordPress, entre outras.
• Critérios de Inclusão: Projetos com pelo menos 8.000 linhas de código (LoC), múltiplos componentes arquitetônicos e dependências externas.
• Resultado: 169.646 linhas de código geradas no total (média de ~16.965 LoC por projeto).

2.3. Avaliação de Qualidade

• Correção Funcional: Avaliação manual executando os projetos e comparando com os requisitos (requirements.md).
• Análise de Design: Uso de duas ferramentas de análise estática:
  • CodeScene: Focado em complexidade funcional e duplicação.
  • SonarQube: Focado em "code smells", segurança e boas práticas.
• Filtragem: Os autores realizaram uma verificação manual para remover falsos positivos (ex: regras que conflitam com convenções específicas de frameworks como WordPress), resultando em 1.305 questões do CodeScene e 3.193 do SonarQube.

---

3. Principais Contribuições

1. Framework FD-HITL: Uma metodologia validada para guiar a geração de projetos de grande escala por IAs, demonstrando que a decomposição em funcionalidades e o feedback humano contínuo são essenciais.
2. Avaliação Empírica de Design: A primeira análise detalhada das questões de design em projetos completos gerados por IDEs de IA, revelando que a correção funcional não garante qualidade arquitetural.
3. Dataset Público (DIinAGP): Disponibilização de 10 descrições de projetos, o código fonte gerado e as questões de design identificadas, permitindo replicação e estudos futuros.
4. Diretrizes para Praticantes: Recomendações baseadas em dados sobre como usar IDEs de IA de forma segura e eficaz.

---

4. Resultados Chave

4.1. Capacidade de Geração (RQ1)

• O Cursor, quando guiado pelo framework FD-HITL, consegue gerar projetos funcionais de grande escala.
• Correção Funcional: Média de 91% de requisitos atendidos. Os projetos são executáveis e cobrem domínios complexos (e-commerce, LMS, redes sociais).
• Escala: Projetos com média de 114 arquivos e 16.965 LoC, utilizando stacks industriais padrão.

4.2. Questões de Design Identificadas (RQ2)

Apesar da funcionalidade, os projetos apresentam problemas significativos de design que ameaçam a manutenibilidade e a evolvabilidade a longo prazo.

• Principais Categorias de Problemas (CodeScene & SonarQube):

  1. Duplicação de Código (Code Duplication): A questão mais frequente (28,4% no CodeScene). Viola o princípio DRY (Don't Repeat Yourself). Ex: Lógica repetida para diferentes níveis de dificuldade em quizzes.
  2. Complexidade de Código: Métodos complexos, condicionais aninhados e alta complexidade cognitiva. Viola o princípio KISS (Keep It Simple, Stupid).
  3. Métodos Grandes (Large Methods): Métodos com centenas de linhas de código (média de 171 LoC), muitas vezes fazendo múltiplas tarefas. Viola o SRP (Single Responsibility Principle).
  4. Violação de Melhores Práticas de Framework: Ex: Validação de props no React ausente, injeção de dependência incorreta no Spring Boot.
  5. Tratamento de Exceções: Uso de exceções genéricas ou blocos catch vazios. Viola o princípio Fail Fast.
  6. Acessibilidade: Falta de labels em formulários e elementos interativos não acessíveis via teclado.

• Princípios de Design Violados:

  • SRP (Single Responsibility Principle): Métodos e classes assumem responsabilidades demais.
  • SoC (Separation of Concerns): Mistura de lógica de negócio, UI e acesso a dados.
  • DRY: Código repetitivo excessivo.

• Sobreposição de Ferramentas: Apenas 133 questões foram detectadas por ambas as ferramentas, mas todas tinham severidade crítica no SonarQube, indicando que a complexidade de código é um ponto crítico comum.

---

5. Significado e Implicações

Para Praticantes (Engenheiros de Software)

• Não subestime o esforço humano: A IA é eficaz na implementação de baixo nível, mas o ser humano deve focar no nível superior (requisitos, arquitetura, decomposição de tarefas).
• Abordagem Sistemática: Evite a "Vibe Coding" (geração aleatória). Use frameworks como o FD-HITL para decompor o projeto em funcionalidades testáveis.
• Validação Contínua: Teste cada funcionalidade isoladamente (caixa preta) antes de avançar.
• Foco em Design: Não basta que o código funcione. É necessário monitorar métricas de qualidade (duplicação, complexidade) e corrigir violações de princípios de design.
• Backend Primeiro: Gere e valide a API/Backend antes de integrar o frontend para isolar erros de lógica de negócio.

Para Pesquisadores

• Novo Paradigma de Avaliação: A avaliação de IA deve ir além de snippets e focar em sistemas completos e sua arquitetura.
• Análise Assistida por LLM: Ferramentas estáticas tradicionais podem não capturar problemas de acoplamento arquitetural; o uso de LLMs para análise de design é uma direção promissora.
• Comportamento do Desenvolvedor: É necessário estudar como os desenvolvedores interagem com IDEs de IA para evitar a superconfiança e a falta de revisão crítica.

Conclusão

O estudo conclui que as IDEs de IA, como o Cursor, são capazes de gerar sistemas de software funcionais e de grande escala quando utilizadas com um framework estruturado. No entanto, elas não substituem a engenharia de software humana. Os projetos gerados contêm defeitos de design substanciais que comprometem a manutenibilidade futura. O sucesso na adoção de IA em escala depende de uma supervisão humana rigorosa, focada em princípios de design e qualidade arquitetural, e não apenas na velocidade de geração de código.