AI voor Project Scaffolding: Boilerplate Genereren Zonder Hersendood te Worden

Elk nieuw project begint met hetzelfde ritueel. Mappenstructuur aanmaken, config files kopiëren van een vorig project, dependencies installeren, linting opzetten, CI pipeline configureren. Het kost makkelijk een halve dag voordat er ook maar één regel businesslogica geschreven wordt.

AI-tools beloven daar verandering in te brengen. Niet door magische code te produceren, maar door het saaie werk over te nemen. De vraag is: werkt dat ook echt?

Het Boilerplate Probleem

Bij een gemiddeld .NET project ziet de opstart er ongeveer zo uit:

• Solution file met meerdere projecten
• Dependency injection setup
• Logging configuratie (Serilog, OpenTelemetry)
• Dockerfile en docker-compose
• GitHub Actions workflow
• Health checks, middleware, error handling
• Entity Framework setup met migrations

Dat zijn tientallen bestanden die grotendeels hetzelfde patroon volgen. Kopiëren uit een template werkt, maar templates raken snel verouderd. En elke keer handmatig aanpassen kost ook weer tijd.

Wat AI-tools Hier Kunnen

De huidige generatie code-assistenten — Copilot, Cursor, Claude — kan behoorlijk wat van deze setup automatiseren. Niet door een magische "generate project" knop, maar via gerichte prompts.

Een prompt als "Genereer een ASP.NET 8 Web API project met Serilog, health checks, en Entity Framework met PostgreSQL" levert in de meeste gevallen een werkende basisstructuur op. Inclusief Program.cs, appsettings, en de benodigde NuGet packages.

// Typisch AI-gegenereerde Program.cs - werkt, maar heeft fine-tuning nodig
var builder = WebApplication.CreateBuilder(args);

builder.Host.UseSerilog((context, config) =>
    config.ReadFrom.Configuration(context.Configuration));

builder.Services.AddDbContext<AppDbContext>(options =>
    options.UseNpgsql(builder.Configuration
        .GetConnectionString("DefaultConnection")));

builder.Services.AddHealthChecks()
    .AddNpgSql(builder.Configuration
        .GetConnectionString("DefaultConnection")!);

var app = builder.Build();

app.UseSerilogRequestLogging();
app.MapHealthChecks("/health");
app.MapControllers();

app.Run();

Dat is bruikbaar. Niet perfect — de error handling ontbreekt, er zit geen middleware pipeline in, en de connection string handling is naïef — maar als startpunt scheelt het een kwartier tot twintig minuten.

Waar Het Goed Werkt

Sommige types boilerplate zijn bijna perfect te genereren:

Docker configuratie. Een Dockerfile voor een .NET API is zo standaard dat AI-tools die foutloos produceren. Multi-stage builds, juiste base images, correct geplaatste COPY en RUN statements. Hier valt weinig op af te dingen.

CI/CD pipelines. GitHub Actions workflows voor build-test-deploy zijn repetitief genoeg dat de gegenereerde output direct bruikbaar is. Zeker voor standaard flows: build, run tests, push Docker image, deploy naar staging.

CRUD endpoints. Het klassieke controller-service-repository patroon voor een simpele entity? Dat genereert AI sneller dan het handmatig typen ervan duurt. Inclusief DTO mapping en basis validatie.

Waar Het Misgaat

Het wordt lastiger bij configuratie die projectspecifiek is.

Omgevingsvariabelen en secrets. AI kent de standaard patronen, maar niet welke secrets er nodig zijn voor een specifiek project. De gegenereerde code gebruikt hardcoded strings of generieke placeholder namen die niet matchen met de daadwerkelijke infrastructuur.

Authenticatie en autorisatie. Hier gaat het regelmatig fout. De gegenereerde JWT configuratie werkt technisch, maar mist vaak belangrijke details: token rotation, refresh token flows, proper claim mapping. Niet het soort code dat zonder review naar productie mag.

Project-specifieke conventies. Elk team heeft eigen patronen. Naamconventies, mappenstructuur, hoe errors gelogd worden. AI baseert zich op de meest voorkomende patronen uit de trainingsdata, niet op wat binnen een specifiek team gebruikelijk is.

Praktische Aanpak

De meest effectieve manier om AI voor scaffolding in te zetten:

Stap	Wat	AI Bruikbaarheid
1	Basisstructuur genereren	⭐⭐⭐⭐⭐
2	Config files aanpassen aan project	⭐⭐⭐
3	Authenticatie/autorisatie setup	⭐⭐
4	Team-specifieke conventies toepassen	⭐

De truc zit in stap 1 volledig aan AI overlaten en bij stap 2-4 steeds meer handmatig bijsturen. Probeer niet alles in één prompt te proppen. Genereer de basis, review, en bouw daar iteratief op verder.

Context Meegeven Maakt Het Verschil

Een kale prompt levert generieke code op. Maar geef de AI een bestaande Program.cs of docker-compose.yml als referentie, en de output volgt ineens wél de projectconventies. Tools als Cursor en Continue doen dit automatisch door de codebase te indexeren. Het verschil in kwaliteit is enorm.

Hetzelfde geldt voor .editorconfig, Directory.Build.props, en andere projectbrede configuratie. Hoe meer context, hoe beter de scaffolding matcht met wat er al staat.

Tijdsbesparing

Op basis van een paar maanden dagelijks gebruik: de opstart van een nieuw project of microservice duurt nu gemiddeld 30-45 minuten in plaats van 3-4 uur. Het meeste van die tijd gaat naar review en aanpassingen, niet naar typen.

Dat is geen revolutie. Maar voor teams die regelmatig nieuwe services opzetten — microservices architecturen, event-driven systemen — telt het op. Tien nieuwe services per kwartaal, elk drie uur bespaard: dat is een complete werkweek terug.

Conclusie (Zonder De Hype)

AI-scaffolding is geen vervanging voor een goed template repository of een Yeoman generator. Het is een aanvulling. Voor standaard patronen werkt het uitstekend. Voor projectspecifieke zaken blijft menselijke kennis nodig.

De grootste winst zit niet in de initiële generatie, maar in het iteratief verfijnen. Genereer de basis, pas aan, gebruik die aangepaste versie als context voor de volgende component. Zo bouw je snel op zonder de kwaliteit in te leveren die bij productie-code hoort.