Stop met het voeden van je AI-aanbieder met voorgekauwde scripts en maak subagenten, vaardigheden en commando’s

Van afhankelijkheid van prompts naar intelligente agent-systemen

De meeste mensen gebruiken AI nog steeds als een autocue.

Ze typen een prompt. Ze wachten. Ze krijgen een antwoord. Ze kopiëren en plakken het ergens. Dan doen ze het opnieuw. En opnieuw. Elke interactie begint vanaf nul. Elk gesprek vergeet wat eraan voorafging.

Dit is geen samenwerking. Het is dicteren met extra stappen.

In 2026, als je je AI-provider nog steeds als autocue gebruikt, mis je de hele verschuiving die zich onder je afspeelt.

Het autocue-probleem

Als je AI als een autocue gebruikt, behandel je een potentieel autonoom systeem als een eenmalige tekstgenerator. Het patroon ziet er zo uit:

1. Je schrijft een gedetailleerde prompt
2. Je wacht op het antwoord
3. Je beoordeelt de output handmatig
4. Je scherpt bij en geeft een nieuwe prompt
5. Je raakt alle context kwijt zodra je de chat sluit

Dit model heeft drie fatale gebreken:

Geen blijvende kennis. Elk gesprek is een leeg blad. Je legt steeds opnieuw dezelfde context uit. Je AI kent je codebase, je voorkeuren, je beperkingen of je geschiedenis niet.

Geen delegatie. Jij blijft de bottleneck. Elke beslissing, elke validatie, elke volgende stap vereist jouw input. De AI wacht totdat jij zegt wat de volgende stap is.

Geen specialisatie. Je gebruikt één generieke interface voor alles: programmeren, documentatie, design, testen, deployment. Eén promptstijl. Eén contextvenster. Eén gesprek dat het werk van velen moet doen.

Het autocue-model behandelt AI als een hulpmiddel. Maar hulpmiddelen schalen autonomie niet op. Agents wel.

Wat er verandert als je in agents gaat denken

In Claude Code bestaat de agent-architectuur uit drie bouwstenen:

• Subagents: Gespecialiseerde Claude-instanties met geïsoleerde contextvensters (~/.claude/agents/)
• Skills: Automatisch getriggerde kennismodules met SKILL.md-bestanden (~/.claude/skills/)
• Commands: Door de gebruiker getriggerde /slash-commando’s voor expliciete acties (~/.claude/commands/)

Het belangrijkste verschil met traditioneel prompten:

• Skills worden automatisch door Claude getriggerd op basis van context
• Commands vereisen dat je expliciet /command typt
• Subagents draaien in een aparte context met hun eigen tools

Bekijk het verschil:

Autocue-aanpak:

“Schrijf een card-component met een afbeelding, titel, bodytekst en een primaire knop volgens onze design system‑patronen en toegankelijkheidsstandaarden...”

Claude Code-aanpak:

/generate card --variant=default --with-image=true --with-button=true

De eerste is een verzoek. De tweede roept een skill aan die al weet wat een card is, wat je design system vereist, welke toegankelijkheidsstandaarden gelden en hoe het zijn eigen output moet valideren.

De architectuur: Subagents, Skills & Commands

Dit is de structuur die het autocue-model vervangt:

Level 1: Subagents

Subagents zijn op zichzelf staande markdown-bestanden in ~/.claude/agents/ die werk parallel uitvoeren. Ze hebben hun eigen contextvensters en kunnen skills aanroepen.

~/.claude/agents/
├── header-builder.md
├── footer-builder.md
└── dashboard-builder.md

Elk subagent-bestand heeft YAML-frontmatter:

• name: Duidelijke identificatie
• description: Wat het doet en wanneer het moet worden aangeroepen
• tools: Toegestane mogelijkheden (Read, Write, Bash, Grep, Glob)

Voorbeeldsubagent (header-builder.md):

---
name: header-builder
description: Build complete header components with navigation
tools: Read, Write, Bash, Glob, Grep
---  You are a header component specialist...

Level 2: Skills

Skills zijn automatisch getriggerde kennismodules. Wanneer je Claude iets vraagt dat overeenkomt met het doel van een skill, past Claude die skill automatisch toe.

~/.claude/skills/
├── card/
│   ├── SKILL.md
│   ├── workflows/
│   │   ├── generate.md
│   │   ├── validate.md
│   │   └── improve.md
│   ├── references/
│   │   └── schema.yml
│   └── scripts/
│       └── validate.py

Dit volgt de Atomic Design‑methodologie: atoms, molecules, organisms. Elke skill is expert in precies één ding. Wanneer je een card nodig hebt, wordt de card‑skill automatisch getriggerd.

Elke skill weet:

• Het schema van de component (props, slots, varianten)
• De conventies van jouw design system
• Frameworkspecifieke patronen
• WCAG-toegankelijkheidseisen
• Gerelateerde skills waarnaar hij kan verwijzen

Level 3: Commands

Commands zijn door de gebruiker getriggerde snelkoppelingen. Je typt /command om ze aan te roepen. Ze leven in skill‑workflows of globaal:

~/.claude/skills/card/workflows/
├── generate.md    # /generate card
├── validate.md    # /validate card
├── improve.md     # /improve card
├── document.md    # /document card
├── test.md        # /test card
└── a11y.md        # /a11y card

Commands kunnen subagents inschakelen voor de planning, waarna de hoofd‑Claude de uitvoering afhandelt. Dit levert gestructureerde workflows op met volledige tooltoegang.

Compleet voorbeeld: Card‑skill

Ik laat je precies zien hoe dit werkt met een echte skill:

De skill-structuur

~/.claude/skills/card/
├── SKILL.md           # Core prompt and instructions
├── workflows/         # Slash commands
│   ├── generate.md
│   ├── validate.md
│   ├── improve.md
│   ├── document.md
│   ├── test.md
│   └── a11y.md
├── references/        # Documentation loaded into context
│   └── schema.yml
└── scripts/           # Executable Python/Bash scripts
    └── validate.py

Het SKILL.md‑bestand

---
name: card
description: Generate and validate card components 
  for any design system with accessibility checks
---  # Card Skill  When user requests card components, this skill 
auto-triggers based on context.
 ## Schema  props:
  title: string
  body: string
  image: { src, alt, width }
  variant: default | horizontal | overlay
 slots:
  header: Custom header content
  footer: Buttons, links
 ## Related Skills  This skill can reference:
- image
- heading
- button
- link
- text

Slash-commando’s gebruiken

Genereer een nieuwe card:

/generate card \   --variant="default" \   --title="Welcome" \   --with-image=true \   --with-button=true

Valideer een bestaande card:

/validate card \   --file="components/card.jsx"

Controleer toegankelijkheidsconformiteit:

/a11y card --level="AA"

Verbeter UX voor een specifieke context:

/improve card \   --context="e-commerce product listing" \   --focus="conversion"

Wat er onder de motorkap gebeurt

Wanneer je /generate card aanroept, doet Claude het volgende:

1. Activeert de card‑skill: SKILL.md wordt in de context geladen
2. Leest het schema: Valideert je parameters tegen de toegestane props
3. Raadt andere skills aan: image-, heading- en button‑skills leveren hun expertise
4. Voert de workflow uit: workflows/generate.md wordt uitgevoerd
5. Valideert zichzelf: Voert de validate‑workflow uit op zijn eigen output
6. Geeft het resultaat terug: Levert de component plus eventuele waarschuwingen

De card‑skill genereert niet alleen markup. Hij orkestreert een systeem van specialisten, die elk hun domeinexpertise inbrengen.

Waarom dit ertoe doet: van bouwer naar systeemdenker

Het autocue‑model houdt jou aan de knoppen. Het skill‑model maakt jou de architect.

Toen ik overstapte van prompts schrijven naar skills ontwerpen, veranderden er een paar dingen:

Ik stopte met context herhalen. Elke skill kent zijn domein al. Ik hoef niet elke keer uit te leggen wat een card is als ik er een nodig heb.

Ik begon in compositie te denken. Een pagina is geen enkele prompt, het is een coördinatie van organisms, die op hun beurt weer coördinaties zijn van molecules, die coördinaties zijn van atoms. Elke laag heeft zijn eigen skill.

Ik delegeerde validatie. In plaats van elke output handmatig te beoordelen, controleert het /validate-commando de structuur, het /a11y-commando controleert WCAG‑conformiteit, en het /test-commando draait geautomatiseerde checks. Ik beoordeel uitzonderingen, niet elk resultaat.

Ik bouwde institutionele kennis op. Als ik de SKILL.md van een skill verbeter, blijft die verbetering bestaan. Het systeem wordt in de loop van de tijd slimmer, niet alleen tijdens één gesprek.

Dit is het verschil tussen AI gebruiken en met AI bouwen.

Het design ís de code

In mijn werk met design systems ben ik tot een principe gekomen: Het design ís de code.

Wanneer designtokens, component‑schema’s en agentconfiguraties op elkaar zijn afgestemd, is er geen vertaallaag tussen wat ontwerpers specificeren en wat developers bouwen. De specificatie is de implementatie.

Zo maken agents dit concreet:

# The schema IS the source of truth schema:   props:     variant:       type: string
      enum: [primary, secondary, success, danger, warning, info]       default: primary
    size:       type: string
      enum: [sm, md, lg]       default: md
 tokens:   colors:     - --btn-bg
    - --btn-color
    - --btn-border-color

Dit schema is niet slechts documentatie. Het is de bron van de waarheid. De agent genereert er componenten uit. De validator controleert ertegen. De designtokens verwijzen ernaar. Eén bestand, veel toepassingen.

Wanneer een ontwerper de tokenwaarden in Figma bijwerkt, wordt de agentconfiguratie bijgewerkt. Wanneer de agentconfiguratie wordt bijgewerkt, worden de gegenereerde componenten bijgewerkt. Het design is de code omdat ze allebei uit hetzelfde schema zijn afgeleid.

Hoe je begint met bouwen met Claude Code

Als je klaar bent om voorbij het autocue‑model te gaan, is hier een praktisch pad:

Stap 1: Bepaal je domeinen

Welke delen van je werk zijn repetitief, regelgebonden en contextafhankelijk? Dat zijn skill‑kandidaten:

• Codegeneratie
• Documentatie
• Testen
• Review en validatie
• Beheer van design systems
• Deployment en DevOps

Stap 2: Maak je eerste skill

Begin met een eenvoudige SKILL.md:

---
name: my-component
description: Generate and validate my-component
---  # My Component Skill  When user asks about my-component, apply these rules...

Stap 3: Voeg workflows (commands) toe

Maak de zes kerncommando’s in workflows/:

Elk commando is een markdown‑bestand met instructies.

Stap 4: Stel skill‑referenties in

Skills kunnen naar andere skills verwijzen:

## Related Skills  This skill uses:
- image (for card images)
- button (for CTAs)
- heading (for titles)

Breng deze afhankelijkheden in kaart. De hiërarchie moet overeenkomen met de natuurlijke structuur van je domein.

Stap 5: Maak subagents voor complexe taken

Wanneer je geïsoleerde context of parallelle uitvoering nodig hebt, maak je een subagent‑bestand in ~/.claude/agents/:

---
name: header-builder
description: Build complete header components with navigation, logo, and search
tools: Read, Write, Bash, Glob, Grep
---  You are a header component specialist. When building headers:
1. Check existing header patterns in the codebase
2. Use the nav, button, logo skills for sub-components
3. Ensure responsive design and accessibility

Je skill‑bibliotheek opbouwen

Structureer je skills volgens Atomic Design:

Elke skill:

• Heeft zijn eigen SKILL.md-configuratie
• Heeft workflows/ met slash‑commando’s
• Heeft references/ met documentatie
• Heeft scripts/ voor automatisering
• Weet welke andere skills hij gebruikt

Dit creëert een consistent, schaalbaar systeem waarin Claude automatisch de juiste skill triggert op basis van context.

De toekomst is agentic

Brad Frost, bedenker van Atomic Design, spreekt al langer over deze verschuiving: design systems moeten machine‑leesbare infrastructuur worden, omdat AI‑agents nu UI’s assembleren met dezelfde componenten als menselijke teams.

Dit is geen voorspelling voor 2030. Het gebeurt nu.

Als je design system niet door een agent geparsed kan worden, raakt het verouderd. Als je ontwikkelworkflow bij elke stap een mens nodig heeft om een prompt te schrijven, schaalt het niet. Als je AI‑interacties elke keer vanaf nul beginnen, verspil je opgebouwde kennis.

Het autocue‑model was prima toen AI nog een curiositeit was. Het is niet meer voldoende nu AI infrastructuur is.

Stop met prompten. Begin met ontwerpen.

Bouw agents. Geef ze skills. Laat ze coördineren.

De toekomst is voor degenen die systemen ontwerpen, niet voor degenen die scripts schrijven.

Agentische design systems bouwen voor de toekomst van webdevelopment.

Verder lezen

• The Design Is the Code Mijn verkenning van denken in cellulaire automata binnen design systems
• Atomic Design by Brad Frost De methodologie achter component‑hiërarchieën
• Designing Systems That Build Themselves Van bouwer naar systeemdenker