O Fim do “Boilerplate”: IA Gerando Projetos, Não Apenas Código

Quanto tempo seu time gasta configurando um novo projeto? Criando Controllers, registrando o DbContext, definindo csproj… antes mesmo de escrever a primeira linha de regra de negócio?

Ferramentas como o GitHub Co-pilot mudaram como escrevemos código, mas elas são assistentes. O próximo salto é a automação generativa: usar IA para criar a estrutura inteira de um projeto.

O problema? A IA pura é um “caos criativo”. Ela pode “alucinar” e entregar resultados inconsistentes, quebrando os padrões de arquitetura que lutamos tanto para estabelecer.

E se pudéssemos combinar o poder da IA com a nossa disciplina de engenharia?

É aqui que entra o Spec Driven Design (SDD). Não é sobre a IA adivinhar o que queremos; é sobre darmos a ela um manual de instruções exato, baseado nos nossos próprios templates.

Neste artigo, vamos explorar como usar o GitHub para orquestrar essa automação, unindo Templates (Governança) e um Agente de IA (Velocidade) para acabar com o boilerplate de uma vez por todas.

O que é Spec Driven Design (SDD) no Contexto de IA?

Esqueça BDD ou TDD por um momento. No contexto da automação, Spec Driven Design é a prática de usar um arquivo de especificação formal (como um spec.yaml ou spec.md) como a única fonte da verdade para a estrutura de uma aplicação.

O “pulo do gato” é: esse arquivo não é escrito para desenvolvedores. Ele é escrito para um Agente de IA.

Esse agente lê a especificação e toma decisões de geração de código. Ele não inventa; ele segue o manual. Se a especificação diz “crie uma entidade ‘Produto’ com um campo ‘Preco’”, o agente sabe exatamente qual template usar e onde injetar esse código.

A Arquitetura da Solução no GitHub (O “Como”)

Para fazer isso funcionar, não precisamos de ferramentas complexas. Precisamos de três componentes simples hospedados no GitHub:

1. O Repositório de Templates (O “Molde”)

Este é o coração da sua governança arquitetural. É um repositório (ex: /template-dotnet-api) que contém sua arquitetura “ideal” de uma Web API, por exemplo.

Ele usa placeholders simples, como __EntityName__, __DbContextName__ ou __ProjectName__.

  • Valor para o CTO: Garante que todo novo projeto iniciado na empresa segue a mesma arquitetura, usa as mesmas bibliotecas de log e os mesmos padrões de segurança.
  • Valor para o Tech Lead: Padroniza a forma de trabalho do time, facilitando o onboarding e a manutenção.

2. O Repositório do Projeto (O “Destino”)

Este é simplesmente o novo repositório vazio (ex: /meu-novo-projeto-catalogo) onde o código gerado irá residir. É aqui que o “contrato” da automação será colocado.

3. O Arquivo de Especificação (O “Contrato”)

Dentro do /meu-novo-projeto-catalogo, criamos o arquivo-chave: spec.yaml (ou spec.md). Este arquivo é a interface humana com o agente de IA.

Um exemplo simples:

# spec.yaml
projectName: "CatalogoDeProdutos"
dbProvider: "PostgreSQL"
entities:
  - name: "Produto"
    properties:
      - name: "Nome"
        type: "string"
      - name: "Preco"
        type: "decimal"
      - name: "EmEstoque"
        type: "bool"
  - name: "Fornecedor"
    properties:
      - name: "NomeFantasia"
        type: "string"

Esta especificação é declarativa, legível e, o mais importante, fácil de ser parseada por um script.

O Agente de IA em Ação (O “Orquestrador”) Com os componentes no lugar, veja como o fluxo de automação funciona:

Gatilho (Trigger): Um desenvolvedor (ou até um Gerente de Produto) commita uma nova versão do spec.yaml na branch main.

Ação (Action): Um GitHub Action (ou um webhook para um serviço externo) é disparado por esse commit.

Execução (Execution): O Agente de IA (que pode ser um script C# ou Python rodando nessa action) entra em cena:

Lê o spec.yaml.

Clona o /template-dotnet-api para um diretório temporário.

Executa a “mágica”:

Substitui ProjectName por “CatalogoDeProdutos”.

Para cada entidade na lista (Produto, Fornecedor):

Gera o arquivo da classe Produto.cs com suas propriedades.

Adiciona o DbSet ao arquivo do DbContext.

Gera um ProdutoController.cs básico (CRUD).

Registra IProdutoRepository na Injeção de Dependência.

Resultado (Result): O agente commita o código gerado no repositório e abre um Pull Request (ex: “🤖 Código gerado baseado na spec v1.1”).

A partir daqui, a equipe humana assume. Os desenvolvedores revisam o PR, mesclam e começam a trabalhar diretamente nas regras de negócio complexas, não em configurar o boilerplate.

Benefícios (O “Porquê” para Negócios e Tech) Essa abordagem muda o jogo em duas frentes:

Para CTOs e Diretores:

Velocidade: A prototipação de novas ideias cai de dias para minutos.

Governança: Garante que 100% dos projetos estão em conformidade com a arquitetura definida, reduzindo o débito técnico desde o Dia Zero.

Escalabilidade: Permite que novas equipes (squads) se tornem produtivas instantaneamente, sem curva de aprendizado de setup.

Para Tech Leads e Arquitetos:

Fim do Boilerplate: Libera a equipe sênior de tarefas repetitivas e de baixo valor.

Foco no Desafio: A equipe gasta seu tempo no que realmente importa — as regras de negócio complexas e os diferenciais do produto.

Manutenção Simplificada: Se a arquitetura “ideal” mudar (ex: adotar um novo padrão de log), basta atualizar o template. O agente aplica a mudança em todos os novos projetos.

Conclusão O Spec Driven Design, quando combinado com Templates no GitHub e Agentes de IA, não é sobre substituir desenvolvedores. É sobre aumentar sua capacidade.

Estamos tratando a IA não como uma caixa preta mágica, mas como um executor de alta velocidade. A governança e a inteligência (a arquitetura) ainda são humanas (nos templates); a IA apenas cuida do trabalho braçal (a geração de código).

Conecte-se comigo no LinkedIn para discutir como implementar o Spec Driven Design na sua arquitetura e levar sua engenharia de software para o próximo nível.