Van Cloud naar Lokaal - Een Council of LLMs voor Development

January 26, 2025 · 50 min read

Software Developer

De afgelopen maanden heb ik intensief gewerkt met cloud-based AI development tools zoals Cursor met Claude. En eerlijk? Ik ben er super blij mee. De kwaliteit, snelheid en integratie zijn fantastisch. Maar er zit een addertje onder het gras: vendor lock-in, privacy concerns bij gevoelige projecten, en vooral - de kosten lopen snel op. Bij intensief gebruik betaal je al gauw €100-200/maand voor API calls, en bij heavy development kan dat oplopen tot €1000-2000/maand.¹

Tijd voor een experiment: een volledig lokale AI development omgeving, waarin niet één maar een heel team van gespecialiseerde LLMs samenwerkt aan software development. Het concept van een 'Council of LLMs' - meerdere AI-agents die samenwerken - is niet nieuw. Platforms zoals AutoGPT, BabyAGI, en MetaGPT hebben dit al verkend,² en Microsoft Research werkt aan AutoGen voor multi-agent systemen.³ Maar kan dit concept ook lokaal werken? En nog belangrijker: kan een Council of LLMs een menselijk development team vervangen?

Dat is de uitdaging die dit blog probeert te beantwoorden.

✅ UPDATE: Het Werkt Echt!

4 januari 2026 - Na het schrijven van dit blog heb ik het concept daadwerkelijk getest. En het werkt. Echt.

De Test

Ik heb de Council een simpele opdracht gegeven: "Bouw een REST API voor een contactformulier met validatie." Geen code, geen voorbeelden, alleen deze requirements.

Wat er gebeurde (in 15 seconden):

Geert (Product Owner) brak het op in 2 user stories met acceptance criteria
Saskia (Scrum Master) maakte een sprint plan met 3 taken en dependencies
Johnie (Backend Developer) schreef werkende Flask API code (23 regels)
Boris (Security Expert) deed een security review en vond 2 echte problemen
Linda (Test Engineer) genereerde een pytest test suite (103 regels)

Het model: qwen2.5-coder:1.5b (slechts 986MB!)
De output: Werkende, executable code die je direct kunt draaien
De tijd: 15 seconden totaal
De kosten: €0 (100% lokaal)

Kwaliteit Check

Johnie's gegenereerde code:

from flask import Flask, request, jsonify
from pydantic import BaseModel, ValidationError

app = Flask(__name__)

class ContactForm(BaseModel):
    name: str
    email: str
    subject: str
    message: str

@app.route('/submit-contact', methods=['POST'])
def submit_contact():
    try:
        form_data = ContactForm.parse_obj(request.json)
        submission_id = "12345"
        return jsonify({'submission_id': submission_id}), 201
    except ValidationError as e:
        return jsonify({'error': str(e)}), 400

Dit is geen fake demo. Deze code is echt gegenereerd door een LLM agent. Je kunt het zelf draaien:

# Installeer dependencies
pip install flask pydantic

# Run de API
flask run

# Test het
curl -X POST http://localhost:5000/submit-contact \
  -H "Content-Type: application/json" \
  -d '{"name":"Test","email":"test@test.com","subject":"Hi","message":"Test message"}'

# Response:
# {"submission_id":"12345"}

Boris's security review was spot-on:

❌ Email field heeft geen format validation
❌ Message field heeft geen length limit
✅ Aanbeveling: Voeg regex validation toe + max length

Linda's tests dekten happy path, edge cases (empty data, invalid email), en error handling.

Wat Dit Betekent

Is het perfect? Nee. De code mist logging, docstrings, en de tests hebben enkele bugs.
Is het nuttig? Absoluut. Dit is een solide eerste draft die in 15 seconden werd gegenereerd.
Zou ik een junior developer vervangen? Voor simpele CRUD APIs? Misschien wel.
Zou ik een senior developer vervangen? Nog niet. Maar we zijn dichter dan ik dacht.

De volledige test output staat in council-real-output/ in de repo. Alles is echt. Niets is gesimuleerd.

Lees verder voor hoe je dit zelf opzet →

Waarom Lokaal? We Hebben Toch Cloud?

Laat ik voorop stellen: cloud-based AI tools zijn geweldig. Cursor met Claude Sonnet heeft me enorm geholpen, en ik blijf het gebruiken voor veel projecten. Maar er zijn goede redenen om ook lokaal te experimenteren:

De Cloud Voordelen (Die We Behouden Willen)

Kwaliteit: Claude Sonnet 3.5/4 is extreem goed in code generatie
Snelheid: No setup, gewoon werken
Updates: Altijd de nieuwste modellen zonder gedoe
Integratie: Perfect geïntegreerd in de IDE

Maar Ook Nadelen

Privacy: Bij gevoelige overheidsprojecten of bedrijfscode is "naar de cloud" niet altijd mogelijk⁴
Vendor Lock-in: Afhankelijk van één provider (Anthropic/OpenAI)
Kosten: Bij intensief gebruik lopen de API calls op
Controle: Geen invloed op model gedrag of specialisatie
Offline: Geen internet = geen AI

De Lokale Propositie

Wat als we het beste van beide werelden kunnen combineren? Cloud waar het kan, lokaal waar het moet. En wat als we lokaal niet één LLM gebruiken, maar een heel team van gespecialiseerde modellen die samenwerken?

De Tooling: Open Source Stack

Dit experiment is volledig gebouwd op open source tooling. Hier zijn de belangrijkste componenten:

Stack overzicht:

n8n: Workflow orchestration - het zenuwstelsel van ons systeem
Ollama: Local LLM runtime - draait de modellen
DeepSeek Coder / Qwen / Llama: De LLM modellen zelf
OpenCode: Open source AI coding agent (terminal, IDE, desktop)⁵
PostgreSQL + pgvector: Vector database voor code embeddings en context⁶
Git: Version control en samenwerking
Playwright/Puppeteer: Browser automation voor testing

Het Concept: Council of LLMs

Hier is mijn experiment: in plaats van één generalist LLM, creëer ik een council - een groep gespecialiseerde AI agents die elk een rol hebben in het development proces, vergelijkbaar met een echt dev team.

De Team Structuur

Execution Layer: De Developers (4 LLMs)

2x Frontend LLMs - elk met een net iets ander karakter:

Anita (Frontend Alpha): Focus op UI/UX, toegankelijkheid, gebruikerservaring
- Context: React best practices, design systems, WCAG richtlijnen
- Karakter: Perfectionistisch op detail, denkt vanuit de gebruiker
Henk (Frontend Beta): Focus op performance, state management, architectuur
- Context: Performance patterns, bundle optimization, advanced React
- Karakter: Technisch, optimalisatie-gedreven

2x Backend LLMs - ook met specialisaties:

Johnie (Backend Alpha): Focus op API design, database modeling, business logic
- Context: REST/GraphQL patterns, database normalisatie, domain modeling
- Karakter: Architecturaal, denkt in systemen
Ingrid (Backend Beta): Focus op security, performance, infrastructure
- Context: Security patterns, caching strategies, scalability
- Karakter: Paranoia (op een goede manier), performance-minded

Management Layer: De Coordinators (3 LLMs)

Thierry (Lead Tech): De technische vraagbaak en architect

Beantwoordt technische vragen van Anita, Henk, Johnie en Ingrid
Maakt architecturale beslissingen
Lost technische blokkades op
Context: Breed, alle tech stacks en patterns

Geert (Product Owner): De strategische richting

Bepaalt feature prioriteit
Schrijft user stories en acceptance criteria
Bewaakt de product visie
Context: Product management, user needs, business value

Saskia (Scrum Master): De dirigent van het orkest

Stuurt de sprint aan
Verdeelt werk over Anita, Henk, Johnie en Ingrid
Bewaakt Definition of Done
Zorgt voor samenwerking
Context: Agile methodologie, team management

Quality Layer: De Gatekeepers (2 LLMs)

Boris (Security Review): De paranoia-agent

Reviewed alle code op security issues
Checkt OWASP Top 10, injection attacks, auth flows
Moet elke PR goedkeuren
Context: Security best practices, CVE databases, threat modeling

Linda (Test & QA): De quality guardian

Schrijft en runt tests
Doet visuele browser testing
Moet elke PR goedkeuren
Context: Testing strategies, E2E testing, visual regression
Special ability: Heeft toegang tot een browser om functionaliteit daadwerkelijk te testen

Hoe Ze Samenwerken: Sprint-Based Development

Het idee is om te werken in sprints - afgebakende werkpakketten met een duidelijk doel:

Sprint flow in detail:

1. Sprint Planning
   └─> Geert (Product Owner): Definieert features en acceptance criteria
   └─> Saskia (Scrum Master): Breekt af in taken, wijst toe aan developers

2. Development
   └─> Anita, Henk, Johnie, Ingrid: Werken parallel aan toegewezen taken
   └─> Thierry (Lead Tech): Ondersteunt bij blokkades
   └─> Code wordt gecommit als feature branches

3. Code Review
   └─> Partner Review: Anita reviews Henk en vice versa, Johnie reviews Ingrid
   └─> Boris (Security): Checkt alle PRs op security
   └─> Linda (Test): Schrijft tests, test in browser
   └─> Alle drie moeten goedkeuren voor merge

4. Sprint Review
   └─> Saskia: Evalueert wat af is
   └─> Geert: Accepteert of wijst af
   └─> Team: Retrospective input voor volgende sprint

5. Deploy
   └─> Als Definition of Done is bereikt: merge en deploy

Definition of Done

Elke story is pas "done" als:

Checklist detail:

✅ Code is geschreven en werkt
✅ Partner developer heeft gereviewd en goedgekeurd (Anita ↔ Henk, Johnie ↔ Ingrid)
✅ Boris (Security) heeft gereviewd en goedgekeurd
✅ Linda (Test) heeft tests geschreven en in browser getest
✅ Code voldoet aan style guide en lint regels
✅ Acceptance criteria zijn gehaald
✅ Geert (Product Owner) heeft geaccepteerd

De Tech Stack: Open Source All The Way

Voor dit experiment kies ik bewust voor open source tooling, passend bij mijn overtuiging dat open source cruciaal is voor digital soevereiniteit⁷:

OpenCode: De AI Coding Agent

OpenCode.ai - De open source AI coding agent voor dit experiment:⁵

45.000+ GitHub stars - bewezen en vertrouwd door 650.000+ developers
Multi-provider support: 75+ LLM providers via Models.dev, inclusief lokale modellen
Cross-platform: Terminal, IDE extensie, en desktop app (Windows, Mac, Linux)
LSP enabled: Automatisch de juiste Language Server Protocols voor LLMs
Multi-session: Meerdere agents parallel op hetzelfde project
Privacy-first: Geen code of context data opslag
Claude Pro support: Log in met je eigen Anthropic account
Open source: Volledig transparant en community-driven (https://opencode.ai)

Voor ons Council is OpenCode perfect omdat het:

Native lokale model support heeft via Ollama
Multi-agent workflows ondersteunt (meerdere sessies parallel)
LSP integration heeft (agents begrijpen code context beter)
Cross-platform werkt (Windows, Mac, Linux zonder gedoe)

n8n: De Orchestrator

n8n is een open source workflow automation tool die perfect is voor het orkestreren van onze LLM council⁸:

Visual workflow builder: Ontwerp de sprint flow visueel
LLM integrations: Native support voor lokale LLMs (Ollama, LM Studio)
Git integration: Commit, branch, PR automation
Browser automation: Voor de Test LLM om visueel te testen
State management: Houdt sprint state bij (taken, status, reviews)
Scheduling: Automatische sprint cycles

Voorbeeld n8n Workflow: PR Review Flow

Workflow uitleg:

[New PR Created]
    ├─> [Trigger] Git webhook
    ├─> [Notify] Security LLM: "Review PR #123"
    │   ├─> [Security LLM analyseert code]
    │   └─> [Output] Security review comment
    ├─> [Notify] Test LLM: "Test PR #123"
    │   ├─> [Test LLM schrijft tests]
    │   ├─> [Test LLM runt browser tests]
    │   └─> [Output] Test results + screenshots
    ├─> [Notify] Partner LLM: "Review PR #123"
    │   ├─> [Partner LLM code review]
    │   └─> [Output] Code review comments
    ├─> [Check] Alle 3 approved?
    │   ├─> [Yes] → Merge PR + Deploy
    │   └─> [No] → Notify developer LLM voor fixes

Lokale LLM Models

Voor de verschillende rollen gebruik ik verschillende open source modellen via Ollama:

Dev LLMs: DeepSeek Coder v2 (33B) - excellent voor code generation⁹
Review LLMs: Qwen2.5-Coder (32B) - goed in code analysis
Management LLMs: Llama 3.1 (70B) - sterke reasoning voor planning
Specialisten: Mix van bovenstaande, plus fine-tuned varianten

Hardware: Dit vereist serieuze GPU kracht. Ik werk met een RTX 4090 (24GB VRAM), wat 33B modellen goed aankan. Voor 70B modellen is quantization nodig (Q4/Q5).

Codebase Structuur: LLM-Safe By Design

Een cruciaal onderdeel is hoe we de codebase structureren zodat LLMs effectief en veilig kunnen werken. Hier komt "LLM-safe" architectuur om de hoek.

Principe 1: Modulaire Grenzen

Elke agent heeft een duidelijk afgebakend domein waar het aan werkt:

project/
├── frontend/
│   ├── components/     ← Anita's domein
│   ├── pages/          ← Anita's domein
│   ├── state/          ← Henk's domein
│   └── utils/          ← Henk's domein
├── backend/
│   ├── api/            ← Johnie's domein
│   ├── database/       ← Johnie's domein
│   ├── auth/           ← Ingrid's domein
│   └── infrastructure/ ← Ingrid's domein
└── tests/
    └── e2e/            ← Linda's domein

Waarom?

Voorkomt merge conflicts tussen de agents
Maakt ownership duidelijk
Limiteert blast radius van fouten

Principe 2: Context Boundaries

Elke agent krijgt alleen de context die het nodig heeft:

anita: # Frontend UI/UX
  read_access:
    - frontend/components/**
    - frontend/pages/**
    - shared/types/**
  write_access:
    - frontend/components/**
    - frontend/pages/**

johnie: # Backend API/Business
  read_access:
    - backend/api/**
    - backend/database/**
    - shared/types/**
  write_access:
    - backend/api/**
    - backend/database/**

Waarom?

Voorkomt dat agents buiten hun expertise werken
Reduceert token gebruik (kleinere context)
Verbetert focus en kwaliteit

Principe 3: Schema-Driven Development

Gebruik strikte schemas als contract tussen LLMs:

// shared/types/user.schema.ts
export const UserSchema = z.object({
  id: z.string().uuid(),
  email: z.string().email(),
  role: z.enum(['admin', 'user', 'guest']),
});

export type User = z.infer<typeof UserSchema>;

Frontend LLM weet: "Dit is wat backend stuurt"
Backend LLM weet: "Dit moet ik sturen"
Beide valideren runtime tegen het schema.

Waarom?

Geen miscommunicatie tussen agents
Runtime validatie voorkomt bugs
Duidelijk contract = minder reviews nodig

Principe 4: Automated Guardrails

Implementeer automatische checks die voorkomen dat agents onveilige code schrijven:

// .llm-rules.json
{
  "forbidden_patterns": [
    "eval\\(",           // No eval()
    "dangerouslySet",    // No dangerouslySetInnerHTML
    "SELECT \\* FROM",   // No SELECT * queries
    "\\.env",            // No direct .env access
  ],
  "required_patterns": {
    "api/**/*.ts": [
      "input\\.validate", // All API routes must validate input
      "requireAuth"       // All routes must have auth
    ],
    "database/**/*.ts": [
      "prepared"          // All queries must be prepared statements
    ]
  }
}

Deze rules worden gecheckt:

Pre-commit: Git hook checkt of code voldoet
In n8n: Voor een agent code kan committen
In Security Review: Boris gebruikt deze rules

Waarom?

Voorkomt common vulnerabilities
Dwingt best practices af
Maakt security review efficiënter

Principe 5: Explicit Dependencies

Maak dependencies explicieit en locked:

// package.json
{
  "dependencies": {
    "react": "18.2.0", // Exact version, no ^
    "express": "4.18.2"
  },
  "llm-rules": {
    "allowed_dependencies": ["react", "express", "zod"],
    "forbidden_dependencies": ["eval-*", "*-unsafe", "shell-*"]
  }
}

LLMs mogen niet zomaar dependencies toevoegen - dat moet via Geert (Product Owner) als bewuste keuze.

Waarom?

Voorkomt supply chain attacks
Voorkomt dependency hell
Keeps bundle size in check

Security: De Paranoia Layer

Boris (Security Review) is cruciaal - hij is de laatste verdedigingslinie tegen vulnerabilities. Hoe zorg ik dat Boris effectief is?

Boris' Context & Prompting

Boris krijgt specialized context:

You are a security expert reviewing code for vulnerabilities.
Focus on:
- OWASP Top 10 vulnerabilities
- Input validation and sanitization
- Authentication and authorization flows
- SQL injection, XSS, CSRF
- Secrets management
- Dependency vulnerabilities

For EACH PR, you MUST:
1. Check against forbidden patterns in .llm-rules.json
2. Verify input validation on all API endpoints
3. Check for hardcoded secrets or credentials
4. Verify authentication on protected routes
5. Check SQL queries are parameterized
6. Verify CORS configuration
7. Check dependency versions against CVE databases

Output format:
- [APPROVED] if no issues found
- [REJECTED] with detailed list of issues to fix

Automated Security Scanning Integration

Boris gebruikt ook geautomatiseerde tools:

Tool integratie:

n8n workflow:
[PR Created]
  ├─> Run: npm audit (dependency check)
  ├─> Run: eslint-plugin-security (static analysis)
  ├─> Run: git-secrets (secrets scanning)
  ├─> Aggregate results
  └─> Feed to Boris for analysis + human-readable report

Boris interpreteert de tool output en geeft context-aware feedback.

Advanced Security: Beyond Static Analysis

Maar we stoppen niet bij static analysis. Security is een layered approach, en Boris krijgt toegang tot geavanceerde security tooling die in de CI/CD pipeline draait:

1. Container Security Scanning

Elke Docker image die we bouwen moet door container scanning:

Waarom dit cruciaal is:

Base images (zoals node:18) kunnen kwetsbaarheden bevatten
Dependencies in layers kunnen outdated zijn
Supply chain attacks via compromised images⁹
Compliance: we willen weten wat er in onze containers zit

Boris' container review:

Voor elke image:
1. Scan met Trivy[^23], Snyk[^18], Grype
2. Aggregeer CVEs en severity scores
3. Check tegen acceptabel risico-niveau
4. Bij critical/high: block deploy + suggest fixes
   - Update base image
   - Patch vulnerable dependencies
   - Replace compromised packages
5. Bij medium/low: log en monitor
6. Generate SBOM (Software Bill of Materials)[^22]

2. Penetration Testing Automation

We integreren automated pentesting in de CI/CD:

# n8n workflow: Weekly Pentest
schedule: '0 2 * * 0' # Zondag 2:00 AM

steps:
  - name: OWASP ZAP Active Scan
    target: staging.app.local
    scan_types:
      - SQL injection
      - XSS (reflected & stored)
      - CSRF
      - Authentication bypass
      - API security

  - name: Nuclei Template Scan
    templates:
      - cves/
      - exposures/
      - vulnerabilities/
      - misconfigurations/

  - name: Custom Fuzzing
    tool: ffuf
    wordlists:
      - api-endpoints
      - parameters
      - payloads

  - name: Boris Analysis
    input: aggregated_scan_results
    output:
      - vulnerability_report
      - risk_assessment
      - remediation_plan

OWASP ZAP: Automated web app security scanner⁹ Nuclei: Fast vulnerability scanner met 1000+ templates¹⁰ ffuf: Web fuzzer voor endpoint discovery en parameter testing

3. AI-Powered Security: De Toekomst

Hier wordt het interessant - AI-enhanced security die verder gaat dan traditionele tools:

A. LLM-Based Code Review (Boris' Superpower)

Boris gebruikt zijn LLM capabilities voor:

# Boris' security prompting
context = """
You are reviewing this code for security issues.
Focus on:
- Logic flaws (business logic vulnerabilities)
- Race conditions in async code
- Subtle injection vulnerabilities
- Authorization bypass opportunities
- Cryptographic misuse
- Time-of-check to time-of-use (TOCTOU) bugs
"""

# Boris analyzes CONTEXT + CODE + PATTERNS
# Output: natuurlijke taal uitleg van subtiele bugs

Waarom LLMs hier beter zijn:

Traditionele tools missen logic flaws (business logic bugs)
LLMs kunnen context begrijpen: "deze check kan bypassed worden als..."
LLMs vinden novel attack vectors die niet in CVE databases staan
LLMs kunnen impact uitleggen in natuurlijke taal

Voorbeeld: Boris vindt een subtle bug

// Code in PR
if (user.role === 'admin' || user.permissions.includes('delete')) {
  await deleteResource(resourceId);
}

// Boris' analyse:
"⚠️ Authorization Logic Flaw gevonden:
De check gebruikt OR in plaats van AND. Een user met alleen
'delete' permission (zonder admin role) kan nu resources deleten,
ook al was de intentie dat dit alleen admins mogen.

Impact: Privilege escalation - regular users met 'delete' permission
kunnen admin-only resources verwijderen.

Fix: Verander naar AND of voeg separate check toe voor admin-only resources."

B. AI-Powered Fuzzing

We gebruiken ML-guided fuzzing voor intelligentere pentesting:⁸

Tool: AFL++ met MOpt scheduler (ML mutation)
Doel: Find edge cases en crashes

Traditionele fuzzing: random mutations
AI fuzzing: ML leert welke mutations
           interessante code paths triggeren

Result: 5-10x snellere bug discovery[^18]

C. Threat Modeling met LLMs

Boris kan automated threat modeling:¹⁰

Input: System architecture diagram + code
Boris' prompt:
"Generate a threat model using STRIDE methodology:[^23]
- Spoofing opportunities
- Tampering vectors
- Repudiation risks
- Information disclosure
- Denial of service
- Elevation of privilege

For each threat, provide:
- Attack scenario
- Likelihood & impact
- Mitigation strategy"

Output: Comprehensive threat model per feature

D. Runtime Application Self-Protection (RASP)

We integreren een AI-powered RASP layer:

// In runtime: real-time monitoring
const rasp = require('rasp-shield');

app.use(
  rasp.middleware({
    ai_model: 'security/anomaly-detection',

    detect: [
      'sql-injection-attempts',
      'unusual-request-patterns',
      'rate-limit-violations',
      'jwt-tampering',
      'suspicious-payload-structure',
    ],

    actions: {
      block: true,
      alert_boris: true, // Real-time alert naar Boris
      log_forensics: true,
    },
  })
);

Hoe RASP werkt:

App draait met RASP layer
RASP monitort alle requests real-time
AI model detecteert anomalieën (afwijkend gedrag)
Bij verdacht gedrag: block + alert Boris
Boris analyseert: false positive of echte attack?
Bij echte attack: emergency patch workflow

E. Automated Patch Suggestions

Boris kan automated security patches voorstellen:

Workflow:
1. CVE wordt ontdekt in dependency
2. Boris analyseert:
   - Welke code gebruikt deze dependency?
   - Wat is de impact op onze app?
   - Welke versie fixed de CVE?
3. Boris genereert:
   - Update PR voor package.json
   - Tests om te checken dat update niet breekt
   - Rollback plan als het misgaat
4. Boris assignt aan Johnie/Ingrid voor review
5. Bij approval: automated merge + deploy

F. Security Log Analysis met AI

Boris analyseert security logs met LLM:

Input: 10.000 log regels per dag
Boris' AI analysis:
- Pattern recognition: welke logs horen bij elkaar?
- Anomaly detection: wat is afwijkend?
- Threat correlation: is dit deel van een attack chain?
- Natural language alerting: "Mogelijk brute force attack
  op /api/login - 500 failed attempts van IP 1.2.3.4
  in laatste 5 minuten"

Output: Actionable security alerts (geen noise)

4. Security in CI/CD Pipeline

Volledige security gate:

# .github/workflows/security.yml
name: Security Pipeline

on: [push, pull_request]

jobs:
  security-scan:
    runs-on: ubuntu-latest
    steps:
      # Static Analysis
      - name: SAST (Static Application Security Testing)
        run: semgrep --config=auto

      # Dependency Scanning
      - name: Dependency Check
        run: |
          npm audit --audit-level=high
          snyk test

      # Secret Scanning
      - name: Secret Detection
        run: gitleaks detect --verbose

      # Container Scanning
      - name: Build & Scan Docker Image
        run: |
          docker build -t app:${{ github.sha }} .
          trivy image app:${{ github.sha }}

      # IaC Security (Infrastructure as Code)
      - name: Terraform Security
        run: tfsec .

      # Boris Review
      - name: AI Security Analysis
        run: |
          n8n execute security-review-workflow \
            --pr=${{ github.event.number }} \
            --commit=${{ github.sha }}

      # Security Gate
      - name: Check Security Status
        run: |
          if [[ "$BORIS_APPROVAL" != "true" ]]; then
            echo "❌ Boris blocked this PR due to security concerns"
            exit 1
          fi

Security metrics we tracken:

MTTR (Mean Time To Remediate): Hoe snel fixen we CVEs?
Vulnerability Density: CVEs per 1000 lines of code
Security Test Coverage: % code gecheckt door security tests
False Positive Rate: Boris' accuracy (< 5% target)
Zero-Day Response Time: Hoe snel reageren we op nieuwe CVEs?

Waarom Deze Security Aanpak Werkt

Layered Defense (Defense in Depth):

Preventie: Boris blokkeert onveilige code voor merge
Detection: Container scanning + RASP detecteert runtime issues
Response: Automated patching + pentesting vindt nieuwe vectors
Recovery: SBOM + forensics voor incident response

AI als Force Multiplier:

Boris vindt bugs die tools missen (logic flaws)
ML-fuzzing vindt edge cases 10x sneller
Automated threat modeling schaalt met team growth
Log analysis reduceert alert fatigue (alleen actionable alerts)

Continuous Improvement:

Boris leert van elke CVE: "deze pattern is vulnerable"
Team leert van Boris' reviews: "zo denk je als attacker"
Security metrics tonen improvement over tijd

Dit is niet alleen security - dit is security at scale, waarbij AI ons helpt om sneller, slimmer, en proactief te zijn tegen threats.

Testing: De Visual QA Layer

Linda (Test & QA) heeft een special ability: browser toegang voor visuele testing.

Linda's Workflow

Workflow detail:

1. Receive: PR with new feature
2. Analyze: Code changes + feature description
3. Generate:
   - Unit tests (Jest/Vitest)
   - Integration tests (API testing)
   - E2E test specs (Playwright)
4. Execute: Run tests
5. Visual Testing:
   - Launch browser (via n8n browser automation)
   - Navigate feature flow
   - Take screenshots at key points
   - Compare against expected states
   - Check accessibility (WCAG)
6. Report:
   - Test coverage metrics
   - Passing/failing tests
   - Screenshots + visual regression diffs
   - Accessibility violations

n8n Browser Automation

n8n heeft ingebouwde browser automation (gebaseerd op Puppeteer):

[Test LLM]
  └─> [n8n: Launch Browser Node]
      └─> Navigate to localhost:3000/feature
      └─> Fill form fields
      └─> Click submit button
      └─> Wait for response
      └─> Screenshot result
      └─> Check for error messages
      └─> Validate DOM elements
      └─> Return results to Test LLM

Linda kan zelf test scripts schrijven in Playwright syntax, die n8n uitvoert.

WCAG en Digitale Toegankelijkheid: Linda's Specialiteit

Een cruciaal onderdeel van kwaliteit is toegankelijkheid. Linda heeft hiervoor een dedicated workflow met externe tooling:

Automated Accessibility Testing Stack:

Tooling uitleg:

axe-core: Automated WCAG 2.1 Level AA testing - checkt 57+ accessibility rules¹⁰
Lighthouse CI: Google's accessibility auditing tool - geeft een score 0-100
Pa11y: Command-line tool die WCAG A, AA, AAA standaarden checkt
WAVE API: WebAIM's tool die visuele feedback geeft op a11y issues

Linda's toegankelijkheidsworkflow:

1. PR wordt aangemaakt
2. Linda runt parallel alle 4 a11y tools
3. Results worden geaggregeerd:
   - Violations per WCAG criterium[^22]
   - Severity (critical, serious, moderate, minor)
   - Specifieke elementen met problemen
4. Linda analyseert en genereert een rapport met:
   - WCAG compliance status (A, AA, of AAA)
   - Concrete remediation steps per violation
   - Code voorbeelden voor fixes
   - Screenshots met problemen gemarkeerd
5. Bij blocking issues: PR wordt geblokkeerd met remediation guide
6. Bij compliance: PR krijgt accessibility approval ✓

Target compliance: WCAG 2.1 Level AA als minimum, met streven naar AAA waar mogelijk.⁹

Waarom dit werkt:

Geautomatiseerd: Elke PR wordt gecheckt, geen handmatig werk
Vroeg in proces: A11y issues worden gevonden voor merge, niet na deploy
Educatief: Linda geeft concrete fix-voorbeelden, team leert
Compliant: Voldoet aan Nederlandse toegankelijkheidseisen (Digitoegankelijk.nl)⁸

Challenges & Realiteit Check

Laten we eerlijk zijn - dit is een experiment, en er zijn challenges:

Council of LLMs vs. Menselijk Dev Team

Voor we in de challenges duiken, laten we eerst eerlijk zijn: hoe verhoudt dit Council zich tot een echt menselijk development team? Want dat is de relevante vergelijking.

De Menselijke Benchmark

Een typisch menselijk development team voor een middelgroot project:

Team samenstelling (8 personen):
├─ 2x Frontend Developer (€60-80k/jaar elk)
├─ 2x Backend Developer (€60-80k/jaar elk)
├─ 1x DevOps/Infrastructure (€70-90k/jaar)
├─ 1x QA/Tester (€50-65k/jaar)
├─ 1x Product Owner (€70-85k/jaar)
├─ 1x Scrum Master (€65-80k/jaar)

Kosten: €535-660k/jaar (excl. overhead, tooling, kantoor)
Capaciteit: ~40 uur/week per persoon = 320 uur/week totaal

De Council Benchmark

Team samenstelling (9 LLMs):
├─ 4x Development LLMs (Anita, Henk, Johnie, Ingrid)
├─ 2x Quality LLMs (Boris, Linda)
├─ 3x Management LLMs (Geert, Saskia, Thierry)

Kosten:
├─ Hardware: RTX 4090 €2000 (eenmalig)
├─ Elektriciteit: ~€30/maand = €360/jaar
├─ Setup & onderhoud: ~40 uur/jaar × €100 = €4000/jaar

Totaal Year 1: €6360 | Year 2+: €4360/jaar
Capaciteit: 24/7 beschikbaar = 168 uur/week × 9 agents = 1512 uur/week

Vergelijking: Wat Zijn De Verschillen?

Voordelen van het Council (vs. Mensen)

1. Kosten: 99% goedkoper

Council: €4-6k/jaar vs. Team: €535-660k/jaar
Break-even na 3 maanden
Geen recruitment kosten, geen onboarding, geen benefits

2. Beschikbaarheid: 5x meer capaciteit

Council werkt 24/7, geen vakanties, geen ziekte
1512 uur/week vs. 320 uur/week
Geen context switching tussen projecten

3. Consistentie: Geen "bad days"

LLMs hebben geen slechte dagen, frustraties, of burn-out
Constante code kwaliteit (binnen model capabilities)
Geen interpersoonlijke conflicten

4. Schaalbaarheid: Instant scaling

Voeg een agent toe = 5 minuten
Menselijk team uitbreiden = 3-6 maanden recruitment + onboarding
Geen teamdynamiek issues bij groei

5. Documentatie: Perfect memory

Agents documenteren automatisch alles
Geen kennis die "in iemands hoofd zit"
Complete audit trail van alle beslissingen

6. Specialisatie: Hyper-focused

Elk agent focust 100% op hun domein
Geen "jack of all trades, master of none"
Deep expertise per domein

Nadelen van het Council (vs. Mensen)

1. Creativiteit: LLMs zijn niet innovatief⁸

Mensen bedenken nieuwe architecturen, patterns, oplossingen
LLMs reproduceren bestaande kennis
Breakthrough innovations komen van mensen, niet van LLMs

2. Begrip: Oppervlakkige context

Mensen begrijpen de waarom achter requirements
LLMs volgen instructies, maar missen business context
Subtiele user needs worden door mensen beter begrepen

3. Communicatie: Geert is geen echte PO

Stakeholder management vereist empathie, onderhandeling
LLMs kunnen niet effectief vergaderen met klanten
Politieke navigatie binnen organisaties is menselijk werk

4. Judgment calls: Geen "gut feeling"

Ervaren developers voelen aan wat "not quite right" is
LLMs hebben geen intuïtie, alleen patronen
Edge cases vereisen menselijke judgment

5. Kwaliteit: Inferieur aan senior developers

DeepSeek Coder (33B) < Claude Sonnet < Senior Developer
Code quality: 70-80% van menselijke output⁹
Subtiele bugs blijven vaak door de mazen

6. Debugging: Beperkte problem-solving

"Waarom werkt dit niet?" - mensen debuggen beter
LLMs kunnen vastlopen op complexe issues
Root cause analysis is moeilijk voor LLMs

7. Setup complexiteit: Niet plug-and-play

Menselijk team: onboarden = 2 weken, productief
Council setup: weken aan configuratie, debugging, tuning
Maintenance overhead blijft hoog

8. Context limitations: Beperkt geheugen

Mensen onthouden hele project geschiedenis
LLMs: beperkte context window (128k tokens ≈ 100 files)
Vector DB helpt, maar is geen perfect oplossing

De Realistische Sweet Spot: Hybrid Teams

Hier is de waarheid: het is geen óf/óf, maar én/én.⁹

Optimale setup:

Menselijk Team (klein, senior):
├─ 1x Lead Developer (architectuur, moeilijke problemen)
├─ 1x Product Owner (stakeholder management, strategy)
└─ 1x DevOps Engineer (infrastructure, security review)

Council of LLMs (grunt work):
├─ Anita, Henk, Johnie, Ingrid (feature development)
├─ Boris, Linda (automated testing & security)
└─ Saskia, Thierry (documentatie, code review)

Samenwerking:
- Mensen sturen de Council: requirements, architectuur beslissingen
- Council doet het zware tilwerk: code schrijven, tests, reviews
- Mensen reviewen Council output: finale quality gate
- Council amplifieert menselijke productiviteit 5-10x

Kosten hybrid model:

3 menselijke seniors: €210-270k/jaar
Council: €4-6k/jaar
Totaal: €214-276k/jaar (60% besparing vs. volledig menselijk team)
Output: Vergelijkbaar met 6-8 persoons team

Waar Werkt Het Council Het Beste?

✅ Ideaal voor:

Maintenance work: Bug fixes, small features, refactoring
Testing & QA: Automated test generation en execution
Documentation: Code comments, API docs, README updates
Security scanning: Continuous security reviews
Code reviews: First-pass reviews voor obvious issues
Prototyping: Snel MVPs bouwen voor validatie

❌ Minder geschikt voor:

Greenfield projects: Nieuwe architectuur vereist menselijke creativiteit
Complex problem-solving: Novel bugs, performance issues
Stakeholder management: Klanten willen met mensen praten
Critical systems: Waar fouten levensgevaarlijk zijn (medical, aviation)
Highly regulated: Compliance, legal vereist menselijke accountability

De Eerlijke Conclusie

Het Council of LLMs is niet een vervanging voor menselijke developers. Het is een force multiplier.

Denk aan het als:

Menselijke developers = Architects & Engineers
Council = Construction crew

De architect ontwerpt het gebouw, de engineer lost de moeilijke problemen op, maar de crew doet het daadwerkelijke bouwen. En die crew werkt 24/7, kost bijna niets, en maakt weinig fouten bij repetitief werk.

Voor mijn experiment: Ik test dit op niet-kritische projecten (personal projects, prototypes). Voor production work blijf ik een hybrid model gebruiken: Cursor/Claude voor complex werk, Council voor grunt work.

De toekomst? Modellen worden beter. Over 2-3 jaar kunnen lokale 100B+ modellen misschien wel senior developer niveau halen.¹⁰ Maar voorlopig: Council = junior developers met superkrachten, niet senior developers.

Technical Challenges

Challenge 1: Context Management

Probleem: LLMs hebben beperkte context windows. Hoe houden de agents overzicht over een groeiende codebase?

Oplossing:

Vector database (PostgreSQL + pgvector) met code embeddings⁶
Agents querien alleen relevante context voor hun taak
Semantic search: "find authentication code" → retrieves auth modules

Challenge 2: Performance - Lokaal is Langzamer

Probleem: Lokale LLMs zijn significant langzamer dan cloud APIs.

Reality check:

Claude Sonnet 3.5 (Cloud):
- Response tijd: 2-5 seconden
- Tokens/seconde: ~100-150 tokens/sec
- Parallel requests: onbeperkt

DeepSeek Coder (Lokaal RTX 4090):
- Response tijd: 15-45 seconden
- Tokens/seconde: ~20-30 tokens/sec
- Parallel: max 2-3 agents tegelijk (VRAM limiet)

Concrete impact:

Een feature die Claude in 5 minuten schrijft, duurt lokaal 20-30 minuten
Code review die 10 seconden duurt in cloud = 1-2 minuten lokaal
Sprint van 8 uur (menselijk) = 24-48 uur voor Council (lokaal)

Maar hier is het slimme deel:

Dit maakt juist niet uit wanneer je de Council als autonoom team laat draaien:

De 24/7 Strategie:

Vrijdagavond 18:00:
└─> Geert (PO) krijgt backlog met 10 user stories
└─> Saskia (SM) plant sprint en verdeelt werk
└─> Anita, Henk, Johnie, Ingrid starten development

PC draait 24/7 door het weekend:
├─> Vrijdagnacht: Development (8 uur)
├─> Zaterdagochtend: Code reviews + fixes (6 uur)
├─> Zaterdagmiddag: Boris security scans (4 uur)
├─> Zaterdagavond: Linda test automation (6 uur)
└─> Zondagochtend: Integratie + deploy (4 uur)

Maandagochtend 09:00:
└─> 10 features klaar, getest, gedeployed
└─> Menselijke review: 2 uur voor final check
└─> Sprint retrospective met metrics

Waarom dit werkt:

Geen wachttijd: Agents hebben geen meetings, pauzes, of context switching
Nachtelijke productiviteit: Terwijl jij slaapt, werkt de Council door
Weekends zijn productief: 48 uur extra dev tijd per week
Compound effect: Langzaam × 24/7 = Meer output dan snel × 40 uur/week

Rekensom:

Menselijk team (8 personen):
- 40 uur/week × 8 = 320 productive uur/week
- Alleen tijdens kantooruren
- Met meetings, pauzes, context switches

Council (9 agents, 3x langzamer):
- 168 uur/week × 9 agents = 1512 beschikbare uur
- Effectief door slowdown: 1512 / 3 = 504 productive uur/week
- Zonder meetings, pauzes, of context switches
- 24/7 beschikbaar

Result: 504 > 320 → Council wint op volume

Trade-off:

✗ Niet geschikt voor: Urgent hotfixes, real-time collaboration
✓ Perfect voor: Planned work, sprints, background maintenance
✓ Ideaal scenario: Vrijdag requirements, maandag results

De persoonlijke use case:

Voor mijn experimenten betekent dit:

Vrijdag: Ik schrijf user stories (1 uur werk)
Weekend: Council werkt 48 uur autonoom
Maandag: Ik review output (2 uur), merge wat goed is
Resultaat: 3 uur werk van mij = 40+ uur dev output

Performance vs. Convenience:

Lokaal is langzamer per taak, maar bij 24/7 autonomous operation is het sneller per week dan een menselijk team dat 40 uur werkt. Het is de shift van "fast per task" naar "high throughput per sprint".

Challenge 3: Agent Coordination Overhead

Probleem: 9 agents coördineren is complex. Wat als ze het niet eens zijn?

Oplossing:

Saskia (Scrum Master) heeft final say bij deadlocks
Voting system: Bij conflicts stemmen relevante agents
Escalation: Bij blijvend conflict → human intervention

Challenge 4: Cost vs. Cloud

Probleem: Een RTX 4090 kost €2000+, elektriciteit loopt op.

Maar wacht - dit is te simpel. Een enkele RTX 4090 kan niet meerdere 33B+ modellen tegelijk draaien voor ons Council. Laten we realistisch zijn over wat je écht nodig hebt.

De Hardware Investering: Wat Kost Een Echte Council Machine?

Om 9 agents tegelijk te laten draaien met acceptabele snelheid, heb je serieuze hardware nodig. Hier zijn drie realistische configuraties:

Configuratie 1: Budget - Single GPU (Beperkt Council)

Wat kan het:

1-2 agents tegelijk (33B modellen)
Veel task switching, langzaam
Goed voor experimenten, niet voor productie

Hardware:

Component	Specificatie	Prijs
GPU	RTX 4090 24GB VRAM	€2.000
CPU	AMD Ryzen 9 7950X	€550
RAM	64GB DDR5 6000MHz	€250
Moederbord	X670E chipset	€350
Voeding	1000W 80+ Gold	€180
Koeling	AIO watercooling	€150
Opslag	2TB NVMe Gen4	€150
Behuizing	ATX case	€120
TOTAAL		€3.750

Elektriciteit: ~500W gemiddeld × 24/7 × €0.40/kWh = €175/maand

Year 1 kosten: €3.750 + (€175 × 12) = €5.850
Year 2+ kosten: €2.100/jaar

Configuratie 2: Production - Dual GPU (Echt Council)

Wat kan het:

4-5 agents parallel (2x 33B + 1x 70B)
Redelijke snelheid voor development
Goed voor serious experimenten

Hardware:

Component	Specificatie	Prijs
GPU 1	RTX 4090 24GB VRAM	€2.000
GPU 2	RTX 4090 24GB VRAM	€2.000
CPU	AMD Threadripper PRO 5965WX	€2.500
RAM	128GB DDR4 ECC	€500
Moederbord	TRX40 met 4x PCIe x16	€700
Voeding	1600W 80+ Platinum	€350
Koeling	Custom watercooling	€400
Opslag	4TB NVMe Gen4	€280
Behuizing	Full Tower	€200
TOTAAL		€8.930

Elektriciteit: ~900W gemiddeld × 24/7 × €0.40/kWh = €260/maand

Year 1 kosten: €8.930 + (€260 × 12) = €12.050
Year 2+ kosten: €3.120/jaar

Configuratie 3: Enterprise - Quad GPU (Full Council)

Wat kan het:

Alle 9 agents parallel
Production-ready snelheid
Multi-model serving

Hardware:

Component	Specificatie	Prijs
GPU 1-4	4× RTX 4090 24GB VRAM	€8.000
CPU	AMD EPYC 7543P 32-core	€3.200
RAM	256GB DDR4 ECC	€900
Moederbord	Server board 7x PCIe x16	€1.200
Voeding	2× 1600W 80+ Titanium	€800
Koeling	Server watercooling	€600
Opslag	8TB NVMe RAID	€600
Behuizing	4U Server rack	€400
TOTAAL		€15.700

Elektriciteit: ~1600W gemiddeld × 24/7 × €0.40/kWh = €460/maand

Year 1 kosten: €15.700 + (€460 × 12) = €21.220
Year 2+ kosten: €5.520/jaar

RAM & GPU Prijzen: De Realiteit van 2025

De prijzen zijn aan het zakken, maar high-end AI hardware blijft duur:

GPU Trends (2024-2025):

RTX 4090 24GB: €2.200 (2024) → €2.000 (2025) → ~€1.700 (2026 verwacht)
RTX 5090 32GB: Verwacht Q2 2025 voor ~€2.500
Gebruikt RTX 3090 24GB: €800-1.000 (goede budget optie!)

RAM Trends:

DDR5 prijzen dalen: €5/GB (2023) → €3.90/GB (2025) → ~€3/GB (2026)
DDR4 ECC (voor servers): €3.90/GB stabiel
Voor AI workloads: veel RAM helpt, maar VRAM is kritischer

Waarom GPUs zo duur zijn:

AI boom = hoge vraag
TSMC production constraints
Crypto mining (nog steeds)
Maar: Prijzen zakken ~15-20% per jaar sinds 2023

VRAM Requirements: Hoeveel Heb Je Nodig?

Voor verschillende model groottes:

Model Size | VRAM Needed (FP16) | VRAM Needed (Q4 quantized)
-----------|-------------------|---------------------------
7B         | 14GB              | 4GB
13B        | 26GB              | 8GB
33B        | 66GB              | 20GB
70B        | 140GB             | 40GB

Voor ons Council:
- 4× 33B dev models: 4 × 20GB = 80GB (met quantization)
- 2× 32B review models: 2 × 19GB = 38GB
- 3× 70B management: 3 × 40GB = 120GB (kan met model offloading)

Minimum: 96GB VRAM (4× RTX 4090)
Comfortable: 128GB+ VRAM

Praktische oplossing:

Model offloading: Laad modellen in RAM als ze niet actief zijn
Quantization: Q4 models zijn 70% kleiner met 5% quality loss
Sequential loading: Niet alle 9 agents tegelijk, maar in batches

De Echte Kostenberekening: Council vs. Team

Laten we nu de realistische vergelijking maken:

Cloud (Heavy Usage)

Cursor Pro: €20/maand
Claude API (1M tokens/dag): €50-200/dag
→ Maand: €20 + (€125 × 30) = €3.770/maand
→ Jaar: €45.240/jaar

Break-even: €45.240 / €12.050 (dual GPU) = 3.8 maanden

Conclusie Cloud: Bij intensief gebruik (council-level) is cloud veel duurder dan lokaal.

Lokale Setup (Dual GPU - Realistisch)

Year 1: €12.050 (hardware + elektriciteit)
Year 2: €3.120 (alleen elektriciteit)
Year 3: €3.120
Year 4: €3.120
Year 5: €3.120

5-year total: €24.530
→ Gemiddeld: €4.906/jaar
→ Per maand: €409

vs. Cloud 5-year: €226.200
Saving: €201.670 (82% goedkoper)

Maar: Dit gaat ervan uit dat je de hardware 5 jaar gebruikt. GPU's verouderen snel (2-3 jaar cycle).

Alternative: Gebruikt Hardware

Slimme opties om kosten te drukken:

Budget Council Setup:

Component	Specificatie	Prijs
GPU 1-2	2× RTX 3090 24GB (gebruikt)	€1.800
CPU	AMD Ryzen 9 5950X (gebruikt)	€350
RAM	128GB DDR4 (gebruikt server RAM)	€250
Rest	Nieuw	€1.000
TOTAAL		€3.400

Met deze setup:

2-3 agents parallel
Acceptabele snelheid
Year 1: €5.500 all-in
Break-even vs. cloud: 1.5 maanden!

Realiteit:

Voor experimenten: Single RTX 4090 (€3.750) is genoeg
Voor serious development: Dual GPU setup (€8.930) is minimum
Voor production Council: Quad GPU (€15.700) of cloud hybrid

De sweet spot: Dual RTX 3090 gebruikt (€3.400) → affordable én capable

Realiteit:

Dit is een experiment en learning exercise
Voor productie blijf ik cloud (Cursor/Claude) gebruiken waar het kan
Lokaal is voor gevoelige projecten of offline scenarios
Hybrid approach: cloud voor prototyping, lokaal voor production

Challenge 5: Model Quality

Probleem: Zijn lokale modellen (33B) even goed als Claude Sonnet (175B+)?

Eerlijk antwoord: Nee. Claude is superieur in reasoning en code quality.

Maar:

DeepSeek Coder v2 is verrassend goed voor specifieke taken
Door specialisatie (elke agent focust op klein domein) compenseert dit
Door peer review (agents checken elkaar) vang je fouten
Voor veel taken is "goed genoeg" voldoende

Challenge 6: Setup Complexiteit

Probleem: Dit is niet plug-and-play. Setup is complex.

Realiteit:

Dit is voor gevorderde users die willen experimenteren
Niet bedoeld als vervanging voor Cursor (nog niet)
De journey is het doel - leren hoe agents samenwerken

De Roadmap: Iteratief Bouwen

Ik bouw dit stap voor stap:

Fase 1: Foundation (Januari 2025) ✅

Hardware: RTX 4090 geïnstalleerd
Ollama setup met DeepSeek Coder
n8n geïnstalleerd en geconfigureerd
OpenCode getest met lokale LLMs

Fase 2: Single LLM Development (Februari 2025)

Eén development agent werkend krijgen met n8n (laten we beginnen met Johnie)
Git workflow automation (commit, branch, PR)
Basic code generation + review cycle
Definition of Done implementeren

Fase 3: Council Setup (Maart 2025)

Alle 4 development agents actief (Anita, Henk, Johnie, Ingrid)
Boris (Security) integratie
Linda (Test) met browser automation
Sprint workflow in n8n

Fase 4: Management Layer (April 2025)

Saskia (Scrum Master) voor coördinatie
Geert (Product Owner) voor backlog
Thierry (Lead Tech) voor architectuur
Volledige sprint cycle

Fine-tuning modellen op onze codebase
Performance optimalisatie
Context management met vector DB
Hybrid cloud/local workflows

Praktische Setup: Stap-voor-Stap Implementatie

Nu de theorie duidelijk is, tijd voor de praktijk. Ik heb deze setup zelf uitgevoerd en getest. Hieronder vind je de exacte stappen die nodig zijn om een volledig werkend Council of LLMs op te zetten.

Wat gaan we bouwen:

✅ Complete Docker environment met alle services
✅ PostgreSQL database met vector search capabilities
✅ Ollama runtime met 3 LLM modellen
✅ n8n voor workflow orchestration
✅ OpenCode IDE configuratie
✅ Verificatie dat alles werkt

Totale tijd: ~2-3 uur (vooral model downloads)
Moeilijkheidsgraad: Intermediate
Vereiste kennis: Basic terminal, Docker basics

Je hebt twee opties: Docker (aanbevolen, getest, werkt overal) of Native installatie (advanced, platform-specific).

🚀 Optie 1: Docker Setup (Aanbevolen & Getest)

Deze methode heb ik volledig uitgevoerd en getest. Het werkt op Windows, Mac, en Linux.

Download de complete setup van GitHub: Council-LLM Docker Setup

Of maak een docker-compose.yml:

version: '3.8'

services:
  # PostgreSQL met pgvector voor code embeddings
  postgres:
    image: pgvector/pgvector:pg16
    container_name: council-postgres
    environment:
      POSTGRES_DB: council
      POSTGRES_USER: council
      POSTGRES_PASSWORD: change-me-in-production
    volumes:
      - postgres-data:/var/lib/postgresql/data
    ports:
      - '5432:5432'
    healthcheck:
      test: ['CMD-SHELL', 'pg_isready -U council']
      interval: 10s
      timeout: 5s
      retries: 5

  # Ollama - LLM runtime
  ollama:
    image: ollama/ollama:latest
    container_name: council-ollama
    volumes:
      - ollama-models:/root/.ollama
    ports:
      - '11434:11434'
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]
    environment:
      - OLLAMA_KEEP_ALIVE=24h
      - OLLAMA_NUM_PARALLEL=4

  # n8n - Workflow orchestration
  n8n:
    image: n8nio/n8n:latest
    container_name: council-n8n
    ports:
      - '5678:5678'
    environment:
      - N8N_BASIC_AUTH_ACTIVE=true
      - N8N_BASIC_AUTH_USER=admin
      - N8N_BASIC_AUTH_PASSWORD=change-me
      - N8N_HOST=localhost
      - N8N_PORT=5678
      - N8N_PROTOCOL=http
      - POSTGRES_HOST=postgres
      - POSTGRES_PORT=5432
      - POSTGRES_DB=council
      - POSTGRES_USER=council
      - POSTGRES_PASSWORD=change-me-in-production
    volumes:
      - n8n-data:/home/node/.n8n
    depends_on:
      postgres:
        condition: service_healthy
      ollama:
        condition: service_started

volumes:
  postgres-data:
  ollama-models:
  n8n-data:

Setup Instructies (Windows, Mac, Linux)

Vereisten:

Docker Desktop geïnstalleerd
NVIDIA GPU (voor GPU acceleratie)
- Windows: NVIDIA Container Toolkit via WSL2
- Linux: NVIDIA Container Toolkit
- Mac: Helaas geen NVIDIA support, gebruik CPU (langzaam)

Step 1: Start de Stack

# Clone of maak een project folder
mkdir council-llm && cd council-llm

# Sla bovenstaande docker-compose.yml op

# Start alle services
docker-compose up -d

# Check of alles draait
docker-compose ps

Step 2: Download LLM Models

# DeepSeek Coder voor development agents
docker exec council-ollama ollama pull deepseek-coder:33b

# Qwen voor review agents
docker exec council-ollama ollama pull qwen2.5-coder:32b

# Llama voor management agents
docker exec council-ollama ollama pull llama3.1:70b

# Check gedownloade models
docker exec council-ollama ollama list

Step 3: Test de Setup

# Test Ollama API
curl http://localhost:11434/api/generate -d '{
  "model": "deepseek-coder:33b",
  "prompt": "Write a Python hello world"
}'

# Open n8n
# Browser: http://localhost:5678
# Login: admin / change-me

# Check PostgreSQL
docker exec council-postgres psql -U council -d council -c "SELECT version();"

Step 4: Install Continue (IDE)

Step 4: Install OpenCode (IDE/Terminal/Desktop)

Windows/Mac/Linux - Via installer:

# Via curl (Linux/Mac)
curl -fsSL https://opencode.ai/install | bash

# Via npm
npm install -g opencode

# Via brew (Mac)
brew install opencode

# Windows: Download desktop app
# https://opencode.ai/download

Configure OpenCode met Ollama:

# Start OpenCode
opencode

# In OpenCode, configure model:
# Settings → Models → Add Provider
# Provider: Ollama
# Base URL: http://localhost:11434
# Model: deepseek-coder:33b

Test OpenCode:

# Terminal mode
opencode --model ollama/deepseek-coder:33b "Write a Python hello world"

# IDE mode (VS Code/Cursor extension)
# Install via: code --install-extension Anomaly.opencode

# Desktop app
# Launch OpenCode.app

Optie 2: Native Installatie (Advanced)

Als je liever alles lokaal install (zonder Docker):

Windows Setup:

# 1. Install Ollama
# Download: https://ollama.ai/download
# Run installer, restart terminal

# Verify
ollama --version

# 2. Install PostgreSQL
# Download: https://www.postgresql.org/download/windows/
# Install with pgAdmin

# Add pgvector extension
# In pgAdmin SQL editor:
CREATE EXTENSION vector;

# 3. Install n8n
# Requires Node.js 18+
npm install -g n8n

# Start n8n
n8n start

# 4. Pull models
ollama pull deepseek-coder:33b
ollama pull qwen2.5-coder:32b
ollama pull llama3.1:70b

Linux Setup:

# 1. Install Ollama
curl -fsSL https://ollama.ai/install.sh | sh

# 2. Install PostgreSQL + pgvector
sudo apt update
sudo apt install postgresql postgresql-contrib
sudo -u postgres psql -c "CREATE EXTENSION vector;"

# 3. Install n8n
npm install -g n8n

# 4. Pull models
ollama pull deepseek-coder:33b
ollama pull qwen2.5-coder:32b
ollama pull llama3.1:70b

Mac Setup:

# 1. Install Ollama
brew install ollama

# 2. Install PostgreSQL + pgvector
brew install postgresql@16
brew install pgvector

# 3. Install n8n
npm install -g n8n

# 4. Pull models
ollama pull deepseek-coder:33b
ollama pull qwen2.5-coder:32b
ollama pull llama3.1:70b

Windows Specifieke Notes

GPU Acceleratie op Windows:

Als je een NVIDIA GPU hebt op Windows:

Installeer WSL2 (Windows Subsystem for Linux)

wsl --install

Installeer NVIDIA CUDA drivers voor WSL2
- Download: https://developer.nvidia.com/cuda-downloads
Docker Desktop moet WSL2 backend gebruiken
- Settings → General → Use WSL 2 based engine
Verify GPU in Docker:

docker run --rm --gpus all nvidia/cuda:12.0-base nvidia-smi

Zonder GPU (CPU Only):

Als je geen NVIDIA GPU hebt (Intel/AMD graphics):

Models draaien op CPU (10-20x langzamer)
Gebruik kleinere models: 7B ipv 33B
Of gebruik quantized models (Q4)
Overweeg cloud hybrid approach

Resource Requirements

Minimum (voor experimenten):

CPU: 8 cores
RAM: 32GB
GPU: RTX 3060 12GB (of CPU only met 64GB RAM)
Disk: 100GB SSD
Internet: Voor model downloads (20-50GB)

Recommended (voor Council):

CPU: 16 cores
RAM: 64GB
GPU: RTX 4090 24GB
Disk: 250GB NVMe
Internet: Fiber (voor snelle updates)

Troubleshooting

Problem: Ollama out of memory

# Reduce parallel requests
export OLLAMA_NUM_PARALLEL=2

# Use smaller models
ollama pull deepseek-coder:6.7b

Problem: n8n can't connect to Ollama

# Check if Ollama is running
curl http://localhost:11434

# Check Docker network
docker network inspect council-llm_default

Problem: PostgreSQL permission denied

# Fix volume permissions
docker-compose down
docker volume rm council-llm_postgres-data
docker-compose up -d

Problem: VS Code Continue can't find models

# Verify Ollama API
curl http://localhost:11434/api/tags

# Check Continue config path:
# Windows: %USERPROFILE%\.continue\config.json
# Mac/Linux: ~/.continue/config.json

Next Steps

Als je setup draait:

Setup n8n workflows voor de Council agents
Configure Continue voor je dev agents
Test single agent voor je dual/quad agent workflows gaat bouwen
Build incrementeel: Start met 1 agent, voeg er geleidelijk bij toe
Monitor resources: Check GPU/RAM usage met nvidia-smi en htop

Volgende blog: Ik zal een detailed guide schrijven over hoe je de eerste n8n workflows bouwt voor agent coördinatie. Stay tuned!

📊 Echte Test Resultaten

Wil je zien wat de Council echt heeft gegenereerd? Check de volledige output in de repository:

👉 Council Real Output - Bekijk de Echte Resultaten

Hierin vind je:

✅ 1-geert-user-stories.json - User stories gegenereerd door Geert (PO)
✅ 2-saskia-sprint-plan.json - Sprint plan van Saskia (SM)
✅ 3-TASK1.1.1-johnie-code.py - WERKENDE Flask API gegenereerd door Johnie
✅ 4-TASK1.2.1-boris-review.md - Security review door Boris
✅ 5-TASK1.3.1-linda-tests.py - Test suite van Linda (103 regels pytest)
✅ README.md - Gedetailleerde analyse van de test

Model gebruikt: qwen2.5-coder:1.5b (986MB)
Totale tijd: 15 seconden
Code kwaliteit: 6/10 (werkend, maar basis)
Kosten: €0 (100% lokaal)

Deze output is NIET gesimuleerd. Dit is wat er uit komt als je 5 LLM agents een project geeft. Je kunt het zelf draaien:

# Clone de repo
git clone https://github.com/rubenvdlinde/rubenlinde.git
cd rubenlinde

# Installeer Ollama en download model
ollama pull qwen2.5-coder:1.5b

# Start Docker containers
docker compose up -d

# Run de Council
python3 council_orchestrator.py

Waarom Dit Experiment?

Ten slotte, waarom doe ik dit? Een paar redenen:

1. Digital Soevereiniteit

Als ik pleit voor digital soevereiniteit bij overheden⁷, moet ik ook zelf experimenteren met alternatieven voor cloud-afhankelijkheid.

2. Leren Hoe LLMs Samenwerken

De toekomst van AI development is waarschijnlijk niet één super-intelligent model, maar teams van gespecialiseerde modellen die samenwerken.³ Dit is een kans om die dynamiek te begrijpen.

3. Open Source Bijdragen

Door te bouwen met open source (OpenCode, n8n, Ollama), kan ik:

Bugs vinden en fixen
Features bijdragen
De community helpen

4. Privacy-Sensitive Projecten

Voor overheidsprojecten waar code niet naar de cloud mag, biedt dit een realistisch alternatief.

5. Het Is Gewoon Vet

Eerlijk? Het is gewoon een gaaf experiment. Een council of AI agents die in sprints werken? That's science fiction made real.

Volg De Reis

Ik ga dit experiment open delen via deze blog. Verwacht updates over:

Setup guides en tutorials
Successen en (vooral) failures
Code voorbeelden en n8n workflows
Performance benchmarks lokaal vs. cloud
Lessons learned

Wil je meevolgen? Subscribe via RSS of volg me op social media (links in footer).

En als je zelf experimenteert met lokale LLMs of multi-agent systems - laat het me weten! Ik ben enorm geïnteresseerd in hoe anderen dit aanpakken.

Dit is het begin van een reis. Een reis naar meer controle, meer privacy, en meer begrip van hoe AI systems kunnen samenwerken. En wie weet - misschien wordt dit ooit een realistisch alternatief voor cloud-based development. Maar eerst: experimenteren, leren, en veel fouten maken.

Let's build a Council of LLMs. 🚀

Anthropic - Claude API Pricing - Bij intensief gebruik (1M tokens/dag) kan dit €50-200/dag kosten ↩
AutoGPT & BabyAGI - Autonomous AI agents - Eerste experimenten met multi-agent AI systems ↩
Microsoft Research - AutoGen: Enabling next-generation LLM applications ↩ ↩²
NCSC - Cloud Security Guidelines for Government ↩
OpenCode.ai - Open source AI coding agent - 45K+ GitHub stars, 650K+ monthly developers ↩ ↩²
PostgreSQL pgvector - Open-source vector similarity search ↩ ↩²
iBestuur - Versterk de digitale soevereiniteit ↩ ↩²
n8n.io - Open source workflow automation ↩ ↩² ↩³ ↩⁴
DeepSeek AI - DeepSeek Coder: Open source code generation models ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶
Zie mijn eerdere blog: Volwassenheid van Open Source ↩ ↩² ↩³ ↩⁴

✅ UPDATE: Het Werkt Echt!​

De Test​

Kwaliteit Check​

Wat Dit Betekent​

Waarom Lokaal? We Hebben Toch Cloud?​

De Cloud Voordelen (Die We Behouden Willen)​

Maar Ook Nadelen​

De Lokale Propositie​

De Tooling: Open Source Stack​

Het Concept: Council of LLMs​

De Team Structuur​

Execution Layer: De Developers (4 LLMs)​

Management Layer: De Coordinators (3 LLMs)​

Quality Layer: De Gatekeepers (2 LLMs)​

Hoe Ze Samenwerken: Sprint-Based Development​

Definition of Done​

De Tech Stack: Open Source All The Way​

OpenCode: De AI Coding Agent​

n8n: De Orchestrator​

Voorbeeld n8n Workflow: PR Review Flow​

Lokale LLM Models​

Codebase Structuur: LLM-Safe By Design​

Principe 1: Modulaire Grenzen​

Principe 2: Context Boundaries​

Principe 3: Schema-Driven Development​

Principe 4: Automated Guardrails​

Principe 5: Explicit Dependencies​

Security: De Paranoia Layer​

Boris' Context & Prompting​

Automated Security Scanning Integration​

Advanced Security: Beyond Static Analysis​

1. Container Security Scanning​

2. Penetration Testing Automation​

3. AI-Powered Security: De Toekomst​

4. Security in CI/CD Pipeline​

Waarom Deze Security Aanpak Werkt​

Testing: De Visual QA Layer​

Linda's Workflow​

n8n Browser Automation​

WCAG en Digitale Toegankelijkheid: Linda's Specialiteit​

Challenges & Realiteit Check​

Council of LLMs vs. Menselijk Dev Team​

De Menselijke Benchmark​

De Council Benchmark​

Vergelijking: Wat Zijn De Verschillen?​

Voordelen van het Council (vs. Mensen)​

Nadelen van het Council (vs. Mensen)​

De Realistische Sweet Spot: Hybrid Teams​

Waar Werkt Het Council Het Beste?​

De Eerlijke Conclusie​

Technical Challenges​

Challenge 1: Context Management​

Challenge 2: Performance - Lokaal is Langzamer​

Challenge 3: Agent Coordination Overhead​

Challenge 4: Cost vs. Cloud​

De Hardware Investering: Wat Kost Een Echte Council Machine?​

Configuratie 1: Budget - Single GPU (Beperkt Council)​

Configuratie 2: Production - Dual GPU (Echt Council)​

Configuratie 3: Enterprise - Quad GPU (Full Council)​

RAM & GPU Prijzen: De Realiteit van 2025​

VRAM Requirements: Hoeveel Heb Je Nodig?​

De Echte Kostenberekening: Council vs. Team​

Cloud (Heavy Usage)​

Lokale Setup (Dual GPU - Realistisch)​

Alternative: Gebruikt Hardware​

Challenge 5: Model Quality​

Challenge 6: Setup Complexiteit​

De Roadmap: Iteratief Bouwen​

Fase 1: Foundation (Januari 2025) ✅​

Fase 2: Single LLM Development (Februari 2025)​

Fase 3: Council Setup (Maart 2025)​

Fase 4: Management Layer (April 2025)​

Fase 5: Refinement (Mei 2025+)​

Praktische Setup: Stap-voor-Stap Implementatie​

🚀 Optie 1: Docker Setup (Aanbevolen & Getest)​

Setup Instructies (Windows, Mac, Linux)​

Optie 2: Native Installatie (Advanced)​

Windows Specifieke Notes​

Resource Requirements​

Troubleshooting​

✅ UPDATE: Het Werkt Echt!

De Test

Kwaliteit Check

Wat Dit Betekent

Waarom Lokaal? We Hebben Toch Cloud?

De Cloud Voordelen (Die We Behouden Willen)

Maar Ook Nadelen

De Lokale Propositie

De Tooling: Open Source Stack

Het Concept: Council of LLMs

De Team Structuur

Execution Layer: De Developers (4 LLMs)

Management Layer: De Coordinators (3 LLMs)

Quality Layer: De Gatekeepers (2 LLMs)

Hoe Ze Samenwerken: Sprint-Based Development

Definition of Done

De Tech Stack: Open Source All The Way

OpenCode: De AI Coding Agent

n8n: De Orchestrator

Voorbeeld n8n Workflow: PR Review Flow

Lokale LLM Models

Codebase Structuur: LLM-Safe By Design

Principe 1: Modulaire Grenzen

Principe 2: Context Boundaries

Principe 3: Schema-Driven Development

Principe 4: Automated Guardrails

Principe 5: Explicit Dependencies

Security: De Paranoia Layer

Boris' Context & Prompting

Automated Security Scanning Integration

Advanced Security: Beyond Static Analysis

1. Container Security Scanning

2. Penetration Testing Automation

3. AI-Powered Security: De Toekomst

4. Security in CI/CD Pipeline

Waarom Deze Security Aanpak Werkt

Testing: De Visual QA Layer

Linda's Workflow

n8n Browser Automation

WCAG en Digitale Toegankelijkheid: Linda's Specialiteit

Challenges & Realiteit Check

Council of LLMs vs. Menselijk Dev Team

De Menselijke Benchmark

De Council Benchmark

Vergelijking: Wat Zijn De Verschillen?

Voordelen van het Council (vs. Mensen)

Nadelen van het Council (vs. Mensen)

De Realistische Sweet Spot: Hybrid Teams

Waar Werkt Het Council Het Beste?

De Eerlijke Conclusie

Technical Challenges

Challenge 1: Context Management

Challenge 2: Performance - Lokaal is Langzamer

Challenge 3: Agent Coordination Overhead

Challenge 4: Cost vs. Cloud

De Hardware Investering: Wat Kost Een Echte Council Machine?

Configuratie 1: Budget - Single GPU (Beperkt Council)

Configuratie 2: Production - Dual GPU (Echt Council)

Configuratie 3: Enterprise - Quad GPU (Full Council)

RAM & GPU Prijzen: De Realiteit van 2025

VRAM Requirements: Hoeveel Heb Je Nodig?

De Echte Kostenberekening: Council vs. Team

Cloud (Heavy Usage)

Lokale Setup (Dual GPU - Realistisch)

Alternative: Gebruikt Hardware

Challenge 5: Model Quality

Challenge 6: Setup Complexiteit

De Roadmap: Iteratief Bouwen

Fase 1: Foundation (Januari 2025) ✅

Fase 2: Single LLM Development (Februari 2025)

Fase 3: Council Setup (Maart 2025)

Fase 4: Management Layer (April 2025)

Fase 5: Refinement (Mei 2025+)

Praktische Setup: Stap-voor-Stap Implementatie

🚀 Optie 1: Docker Setup (Aanbevolen & Getest)

Setup Instructies (Windows, Mac, Linux)

Optie 2: Native Installatie (Advanced)

Windows Specifieke Notes

Resource Requirements

Troubleshooting