Mijn AI-lab in april 2026: Copilot CLI, lokale LLMs en een platform dat zichzelf runt

April 2026 was een drukke maand in mijn AI-lab. Ik wil graag eerlijk delen wat ik de laatste weken heb gedaan, wat verrassend goed werkte en waar ik tegenaan liep. Geen gepolijste tutorial — gewoon een oprecht verslag van mijn laatste AI-avonturen. Van GitHub Copilot CLI die mijn terminal overneemt, over Ollama-agents die lokaal codebasissen analyseren, tot een AI Control Platform dat zichzelf bewaakt. Buckle up.

🤖 GitHub Copilot CLI: AI in je terminal

De grootste verrassing van deze maand was GitHub Copilot CLI. Ik kende Copilot al van in de IDE, maar de CLI-variant is een ander beest. Je opent een terminal, typt wat je wilt bereiken in natuurlijke taal, en Copilot gaat aan de slag — hij leest bestanden, voert commando's uit, debugt fouten en legt elke stap uit. Het voelt alsof je een junior developer naast je hebt zitten die nooit moe wordt en altijd de juiste PowerShell-syntax kent.

Concreet gebruik ik het voor het opstarten van het VorstersNV-project. Vandaag vroeg ik simpelweg: "kan je dit project lokaal nu draaien?" — en Copilot CLI analyseerde de volledige repo, controleerde welke tools beschikbaar waren (Python 3.12 ✅, Node.js 22 ✅, Ollama ✅, Docker ❌), ontdekte dat Docker Desktop niet geïnstalleerd was, vond de juiste poorten, en startte FastAPI én Next.js op zonder dat ik één commando zelf hoefde in te typen. Dat is de toekomst van developer tooling.

🧠 Ollama lokaal: de realiteit van CPU-inference

Ik draai Ollama lokaal op mijn laptop — een Intel i7-1165G7 zonder dedicated GPU. De eerlijkheid gebiedt me te zeggen: dat is traag. Mistral 7B doet er ~290 seconden over per chunk bij een codebase-analyse. Dat is geen typo — bijna vijf minuten per stuk code. Toch gebruik ik het, want de voordelen zijn reëel: geen cloud kosten, geen data-privacy zorgen, en volledige controle over welk model ik gebruik.

# Codebase analyseren met lokale AI (stap voor stap)
# 1. Eerst dry-run: alleen bestanden scannen, geen AI
python scripts/analyse_project.py \
  --pad C:\pad\naar\klant-project \
  --dry-run

# 2. Volledige analyse (mistral:7B op CPU — pak een koffie)
python scripts/analyse_project.py \
  --pad C:\pad\naar\klant-project

# 3. Via gaming desktop server (veel sneller)
# In .env:
# OLLAMA_BASE_URL=http://192.168.1.XXX:11434
# OLLAMA_DEFAULT_MODEL=mistral:7b

🏗️ Het AI Control Platform: van idee naar productie

Het grote project van de laatste maanden is het AI Control Platform dat ik heb gebouwd als onderdeel van VorstersNV. Het is ontstaan uit een concrete nood: ik had meer dan 20 Ollama-agents die allemaal los van elkaar draaiden, zonder centraal beheer, zonder audit trail, zonder manier om te weten welke agent goed presteerde en welke niet. De oplossing: één centrale Control Plane die alles orkestreert.

• 🎛️ Control Plane: één REST-endpoint (POST /api/ai/run) dat alle AI-aanroepen routeert op basis van 8 dimensies (capability, risk, environment, budget, latency, model, policy, rollout)
• 📋 Policy Engine: governance-regels als YAML — welke agent mag welke tool gebruiken, wanneer is human-in-the-loop verplicht, welk model wordt ingezet per risiconiveau
• 📓 Decision Journal: elke AI-beslissing wordt gelogd met trace_id, input, output, rationale en verdict — volledig auditeerbaar
• 📊 Quality Monitor: real-time alerts wanneer een agent degradeert (CRITICAL/DEGRADED/SLOW status)
• 🧪 A/B Tester met AutoPromoter: winnende prompt-versies worden automatisch gepromoot, verliezende teruggedraaid
• 🔗 Event Bridge: Mollie-webhooks en order-events triggeren automatisch de juiste AI skill chain

Het meest waardevolle was niet de technologie zelf, maar de governance die eromheen zit. Een AI-agent zonder audit trail is een tijdbom — je weet pas dat er iets mis is als het al fout gegaan is.

🔬 Wat ik leerde over AI-agent architectuur

Na maanden bouwen heb ik een paar harde lessen geleerd die ik nergens anders las. Ten eerste: agents zijn zo goed als hun context. Een agent die alleen de user input krijgt, presteert significant slechter dan een agent die ook de relevante business-context meekrijgt — klanthistorie, ordergegevens, productcategorie. De prompt engineering is slechts 30% van het werk; de andere 70% is het ophalen en structureren van de juiste context vóór de agent aanroep.

Ten tweede: monitor alles, vertrouw niets. De Quality Monitor in het platform alarmeert me wanneer een agent structureel slechter presteert. Dat klinkt voor de hand liggend, maar zonder automatische monitoring merk je het pas na tientallen slechte antwoorden aan klanten. De Decision Journal heeft me al drie keer gered: één keer een policy-bug gevonden, één keer een model dat stilletjes andere outputs gaf na een Ollama update, en één keer een agent die op basis van verouderde productdata adviseerde.

# Voorbeeld policy in het AI Control Platform
# policies/order_verwerking.yml
policy_id: order-fraud-check
version: "1.2"
applies_to:
  - capability: fraud_detection
  - risk_level: [medium, high, critical]

rules:
  - id: hitl-high-risk
    condition: risk_score >= 75
    action: require_human_approval
    notify: ["fraud-team@vorsternv.be"]

  - id: block-critical
    condition: risk_score >= 95
    action: block_order
    log_to_decision_journal: true

  - id: model-selection
    condition: risk_score >= 50
    preferred_model: mistral:7b  # meer nauwkeurig, trager
    fallback_model: llama3.2:3b  # sneller, minder nauwkeurig

📁 Consultancy tooling: code analyseren voor klanten

De nieuwste richting voor VorstersNV is IT/AI-consultancy voor Belgische KMOs. Concreet betekent dat: ik neem een bestaande codebase van een klant, scan die met lokale AI-agents, en lever een rapport met technische bevindingen, risico's en aanbevelingen. Geen cloud, geen data die de organisatie verlaat, geen licentiekosten per token. Alles draait lokaal op mijn laptop of op een kleine server bij de klant.

De tooling hiervoor is bijna klaar: scripts/analyse_project.py scant de bestanden, code_analyse_agent beoordeelt elk bestand op architectuur en risico's, klant_rapport_agent schrijft de samenvatting in klantgerichte taal, en bedrijfsproces_agent mapt het AS-IS proces. De output gaat naar documentatie/analyse/ als Markdown-rapport dat ik kan bezorgen of in een Confluence-pagina zetten.

🗺️ Wat staat er nog op de planning

• Gaming desktop server configureren als Ollama inference node — OLLAMA_BASE_URL switchen en klaar
• Docker Desktop installeren zodat de volledige stack (PostgreSQL + Redis) via één docker compose up draait
• Eerste echte klantopdracht: codebase analyse van een bestaand Java ERP-systeem
• A/B tester koppelen aan de Quality Monitor zodat slechte prompts automatisch worden teruggedraaid
• MCP server voor de consulting module — Confluence integratie voor automatisch rapport genereren

Het tempo ligt hoog, maar dat is precies de charme van een persoonlijk platform: je kiest zelf wat je bouwt, hoe snel en waarvoor. AI maakt dat solo-development tegenwoordig dichter bij team-development komt — niet qua sociale dynamiek, maar qua snelheid en kwaliteit van wat je kunt afleveren. Als je vragen hebt over het platform, de consultancy aanpak of de Ollama setup — reach out. Ik deel graag wat werkt.

AI maakt solo-development sneller, maar maakt het niet makkelijker. De moeilijkste beslissingen — architectuur, prioriteiten, wat je weggooit — die blijf je zelf maken. En dat is precies hoe het hoort.