The End of “Boilerplate”: AI Generating Projects, Not Just Code

How much time does your team spend configuring a new project? Creating Controllers, registering the DbContext, defining the csproj… all before writing the first line of business logic?

Tools like GitHub Co-pilot have changed how we write code, but they are assistants. The next leap is generative automation: using AI to create the entire structure of a project.

The problem? Pure AI is “creative chaos.” It can “hallucinate” and deliver inconsistent results, breaking the architectural standards we fight so hard to establish.

What if we could combine AI’s power with our engineering discipline?

This is where Spec Driven Design (SDD) comes in. It’s not about the AI guessing what we want; it’s about giving it an exact instruction manual, based on our own templates.

In this article, we’ll explore how to use GitHub to orchestrate this automation, uniting Templates (Governance) and an AI Agent (Velocity) to end boilerplate once and for all.

What is SDD (in an AI Context)?

Forget BDD or TDD for a moment. In the context of automation, Spec Driven Design is the practice of using a formal specification file (like a spec.yaml or spec.md) as the single source of truth for an application’s structure.

The key insight is this: this file isn’t written for developers. It’s written for an AI Agent.

This agent reads the specification and makes code-generation decisions. It doesn’t invent; it follows the manual. If the spec says “create a ‘Product’ entity with a ‘Price’ field,” the agent knows exactly which template to use and where to inject that code.

The GitHub Architecture (The “How-To”)

To make this work, we don’t need complex tools. We need three simple components hosted on GitHub:

1. The Template Repository (The “Mold”)

This is the heart of your architectural governance. It’s a repository (e.g., /template-dotnet-api) that contains your “ideal” architecture for a Web API.

It uses simple placeholders, like __EntityName__, __DbContextName__, or __ProjectName__.

• Value for the CTO: Ensures that every new project started in the company follows the same architecture, uses the same logging libraries, and the same security patterns.
• Value for the Tech Lead: Standardizes the team’s way of working, making onboarding and maintenance easier.

2. The Project Repository (The “Destination”)

This is simply the new, empty repository (e.g., /my-new-project-catalog) where the generated code will live. It’s where the automation “contract” will be placed.

3. The Specification File (The “Contract”)

Inside /my-new-project-catalog, we create the key file: spec.yaml (or spec.md). This file is the human interface to the AI agent.

A simple example:

# spec.yaml
projectName: "ProductCatalog"
dbProvider: "PostgreSQL"
entities:
  - name: "Product"
    properties:
      - name: "Name"
        type: "string"
      - name: "Price"
        type: "decimal"
      - name: "InStock"
        type: "bool"
  - name: "Supplier"
    properties:
      - name: "CompanyName"
        type: "string"

This specification is declarative, human-readable, and, most importantly, easily parsed by a script.

The AI Agent in Action (The “Orchestrator”) With the components in place, here is how the automation workflow runs:

Trigger: A developer (or even a Product Manager) commits a new version of spec.yaml to the main branch.

Action: A GitHub Action (or a webhook to an external service) is triggered by this commit.

Execution: The AI Agent (which could be a C# or Python script running in that action) gets to work:

It parses the spec.yaml.

It clones the /template-dotnet-api to a temporary directory.

It performs the “magic”:

Replaces ProjectName with “ProductCatalog”.

For each entity in the list (Product, Supplier):

Generates the Product.cs class file with its properties.

Adds the DbSet to the DbContext file.

Generates a basic ProductController.cs (CRUD).

Registers IProductRepository in the Dependency Injection container.

Result: The agent commits the generated code to the repository and opens a Pull Request (e.g., “🤖 Code generated based on spec v1.1”).

From here, the human team takes over. Developers review the PR, merge it, and start working directly on complex business logic, not on boilerplate setup.

Benefits (The “Why” for Business & Tech) This approach changes the game on two fronts:

For CTOs and Directors:

Velocity: Prototyping new ideas drops from days to minutes.

Governance: Guarantees 100% of projects comply with the defined architecture, reducing technical debt from Day Zero.

Scalability: Allows new squads to become productive instantly, with no setup learning curve.

For Tech Leads and Architects:

End of Boilerplate: Frees up senior talent from repetitive, low-value tasks.

Focus on the Challenge: The team spends its time on what truly matters—complex business rules and product differentiators.

Simplified Maintenance: If the “ideal” architecture changes (e.g., adopting a new logging standard), you just update the template. The agent applies the change to all new projects.

Conclusion Spec Driven Design, when combined with GitHub Templates and AI Agents, isn’t about replacing developers. It’s about augmenting them.

We are treating AI not as a magical black box, but as a high-speed executor. The governance and intelligence (the architecture) remain human-driven (in the templates); the AI just handles the manual labor (the code generation).

Connect with me on LinkedIn to discuss how to implement Spec Driven Design in your architecture and take your software engineering to the next level.