Je collega's gaan bouwen. Ben je er klaar voor?

Je hoeft geen developer te zijn om software te maken. Niet meer.

Je kent het gevoel. Je wacht zes weken op een rapport dat IT "op de backlog" heeft gezet. Je kopieert data van het ene spreadsheet naar het andere omdat er geen koppeling is. Je hebt een idee voor een dashboard, maar "dat is een dev-vraag" en die hebben het druk.

Ondertussen hoor je dat AI alles verandert. Maar je weet niet waar je moet beginnen.

Dit artikel is voor jou. Niet voor de developers. Voor de marketeer die sneller wil. De finance lead die handwerk zat is. De HR-manager die processen wil stroomlijnen. De ops manager die overal duct tape ziet.

Je kunt nu zelf bouwen. Dit is wat je moet weten.

Wat er veranderd is

Begin 2025 introduceerde AI-onderzoeker Andrej Karpathy de term "vibe coding": software maken door te beschrijven wat je wilt, in gewone taal. Geen programmeertaal. Geen terminal. Gewoon een gesprek.

Een jaar later is dit geen experiment meer. Zo wordt software nu gebouwd.

Tools als Claude, Cowork en Cursor laten je zeggen: "Ik wil een dashboard dat onze marketing-spend per kanaal laat zien, met data uit dit spreadsheet." En dan krijg je een werkend dashboard.

Peter Steinberger, een ervaren developer, beschrijft de shift:

Most software does not require hard thinking. Most apps shove data from one form to another.

Dat is precies het werk waar jij op wacht. Data van A naar B. Rapporten genereren. Formulieren verwerken. Alerts sturen.

De implicatie: het bouwen van dit soort tools is geen schaarse skill meer. De bottleneck verschuift van kunnen coderen naar weten wat je wilt.

Wat je nu zelf kunt maken

Twee voorbeelden:

Marketing: Een marketing manager bouwde in een middag een dashboard dat automatisch campaign performance vergelijkt met de week ervoor. Elke maandag om 8:00 krijgt ze een email met de campagnes die actie nodig hebben. Wat vroeger twee uur handwerk kostte, kost nu nul.

Finance: Een finance lead maakte een reconciliatie-tool die banktransacties matcht met openstaande facturen. Het script dat zij in een gesprek met Claude bouwde, verving een wekelijks proces van vier uur kopiëren en vergelijken.

Andere voorbeelden: HR-managers die onboarding checklists genereren per rol. Ops leads die inventory alerts bouwen. Customer success teams die churn risk scores berekenen op basis van gebruiksdata.

Dit bouwen marketeers, finance leads en ops managers nu zelf. Zonder programmeerervaring.

De vraag is niet wat je kunt bouwen. De vraag is hoe je begint.

De nieuwe skill: specificeren

Je hoeft niet te leren coderen. Je moet leren specificeren. En dat doe je niet in één keer. Je bouwt het op in gesprek met AI.

Stap 1: Begin met een chat

Open Claude, ChatGPT of een andere AI. Leg uit wat je probleem is. Niet wat je wilt bouwen — wat je probleem is.

Ik ben marketing manager. Elke week vergelijk ik handmatig onze campagne-performance in Google Ads met de week ervoor. Dat kost me 2 uur en ik maak fouten. Ik wil dit slimmer doen.

Dat is genoeg om te starten.

Stap 2: Laat AI meedenken

Vraag om invalshoeken:

Welke manieren zijn er om dit aan te pakken? Wat zijn mijn opties? Waar moet ik over nadenken?

AI komt met vragen die je zelf niet had bedacht:

• Wil je een alert alleen bij grote afwijkingen, of altijd een rapport?
• Moet het automatisch draaien of start je het handmatig?
• Wie moet dit nog meer zien?
• Wat doe je met campagnes die net zijn gestart?

Dit gesprek scherpt je denken.

Stap 3: Werk van groot naar klein

Je bouwt niet in één keer. Je werkt in lagen.

PRD → Epics → Tasks

Een PRD (Product Requirements Document) beschrijft het wat en waarom. Wat is het doel? Voor wie? Wat is wel en niet in scope?

Epics zijn de grote brokken werk — een term uit software development voor "te groot om in één keer te doen". Als je PRD zegt "automatische campaign alerts", dan zijn je epics misschien: "data ophalen", "vergelijking maken", "alert versturen".

Tasks zijn de concrete stappen binnen een epic. Klein genoeg om in één sessie af te ronden.

PRD: Campaign Performance Alert
├── Epic 1: Data ophalen uit Google Ads
│   ├── Task: API-toegang configureren
│   ├── Task: Campagne-data ophalen (afgelopen 14 dagen)
│   └── Task: Data opslaan in werkbaar format
├── Epic 2: Performance vergelijken
│   ├── Task: CPL berekenen per campagne per week
│   ├── Task: Week-over-week verschil berekenen
│   └── Task: Campagnes markeren met >20% stijging
└── Epic 3: Alert versturen
    ├── Task: Email-template maken
    ├── Task: Automatische trigger op maandagochtend
    └── Task: Testen met echte data

Je hoeft dit niet zelf te bedenken. Vraag AI:

Breek dit op in epics en tasks. Wat moet er gebeuren, in welke volgorde?

Stap 4: Schrijf een PRD

Voor grotere projecten: vraag AI om je PRD te helpen schrijven.

Help me een PRD schrijven voor deze tool. Beschrijf het doel, de gebruiker, de must-haves, de nice-to-haves, en wat expliciet buiten scope is.

Een PRD dwingt je om scherpe keuzes te maken:

• Wat is het doel? (niet: "campagne-inzicht", wel: "binnen 5 minuten weten welke campagnes actie nodig hebben")
• Wie is de gebruiker? (alleen jij, of ook je team?)
• Wat is v1? (minimaal werkend, niet perfect)
• Wat is expliciet niet v1? (voorkomt scope creep)

Voorbeeld PRD:

# PRD: Campaign Performance Alert

## Doel
Elke maandagochtend binnen 5 minuten weten welke 
Google Ads campagnes actie nodig hebben.

## Gebruiker
Marketing manager (ikzelf), later mogelijk hele marketing team.

## Must-haves (v1)
- Vergelijk cost-per-lead afgelopen 7 dagen vs. 7 dagen daarvoor
- Markeer campagnes met >20% stijging in CPL
- Output: simpele tabel in email, gesorteerd op grootste stijging eerst
- Draait automatisch elke maandag 8:00

## Nice-to-haves (v2)
- Slack notificatie naast email
- Drempelwaarde aanpasbaar
- Historische trend (4 weken)

## Buiten scope
- Automatisch campagnes pauzeren
- Koppeling met andere platformen (Meta, LinkedIn)
- Dashboard met grafieken

Stap 5: Bewaar alles in Markdown

Gebruik Markdown-bestanden voor je stappenplannen en PRD's. Geen losse chatberichten die je kwijtraakt — werkdocumenten die je kunt bewaren, delen en bijwerken. AI kan direct met Markdown werken, dus je kunt zeggen: "Update de PRD met wat we net besproken hebben."

---

Dit is specificeren. Niet in één keer de perfecte opdracht typen — maar in gesprek met AI je denken aanscherpen, opbreken in behapbare stukken, en documenteren wat je bouwt.

Waar je tegenaan gaat lopen

Eerlijk zijn: het is niet alleen maar makkelijk.

Het begin is hobbelig. Je eerste pogingen zullen mislukken. De AI begrijpt je niet. Het resultaat is niet wat je bedoelde. Dit is normaal. Itereren hoort erbij.

Je weet niet wat je niet weet. Je bouwt iets dat werkt — maar is het veilig? Mag dit met deze data? Wat als het breekt? Je mist de context die developers jarenlang hebben opgebouwd.

Gevoelige data vergeeft geen fouten. Klantgegevens, financiële data, HR-informatie — hier gelden regels. Een zelfgebouwd script dat per ongeluk data lekt is geen hypothetisch risico.

Onderhoud is niemands favoriet. Je bouwt iets, het werkt, je vergeet het. Tot het breekt. Of tot jij van baan verandert en niemand weet dat het bestaat.

Het escaleert snel. Wat begint als "even een scriptje" wordt stilletjes kritieke infrastructuur. Zonder dat iemand het doorheeft.

Wanneer je hulp nodig hebt

Dit is de spanning: je wilt niet terug naar zes weken wachten op IT. Maar je wilt ook niet in je eentje iets bouwen dat later ontploft.

De oplossing is niet een approval-proces. Het is weten wat je niet kunt zien.

Wat je niet ziet

Als niet-developer zie je het stukje dat je bouwt. Een developer ziet het systeem.

Jij ziet: "Mijn script werkt."

Zij zien: "Waar gaat die data naartoe? Wat gebeurt er als het faalt? Wat als er 10.000 records zijn in plaats van 100? Wie heeft er nog meer toegang? Wat breekt er als het CRM update?"

Dit is geen kritiek op jouw skills. Dit is patroonherkenning die je opbouwt door jarenlang systemen te bouwen en te zien falen.

Hoe het misgaat

Concrete scenario's:

Je bouwt een script dat klantdata verwerkt. Werkt prima. Maar de data gaat naar een externe API — en dat is een GDPR-overtreding. Jij wist niet dat die API buiten de EU draait.

Je maakt een automatisering die perfect werkt. Met 100 records. Bij 10.000 records crasht het hele systeem. Of het kost €200 aan API-calls per maand.

Je koppelt aan het CRM. Werkt. Tot je team geblokkeerd wordt omdat je de rate limit hebt overschreden. Of tot de wijzigingen van een collega jouw output breken.

Je maakt een "tijdelijk" dashboard. Zes maanden later draaien er drie processen op die niemand kent. Jij bent met vakantie. Het breekt. Niemand weet hoe het werkt.

Dit zijn geen hypothetische risico's. Dit gebeurt. Elke developer heeft deze verhalen.

Hoe de interactie eruitziet

Niet een ticket. Niet een formeel review-proces. Niet weken wachten op goedkeuring.

Wel: een gesprek van vijftien minuten. Je deelt je PRD. Je vraagt: "Wat zie ik over het hoofd?"

De developer stelt vragen:

• Waar komt die data vandaan? Waar gaat het naartoe?
• Wat gebeurt er als het faalt? Wie merkt dat?
• Hoe groot kan dit worden?
• Wie heeft er toegang nodig? Wie mag er juist geen toegang hebben?
• Is dit wegwerp of moet het blijven werken?

De output is niet "goedgekeurd" of "afgekeurd". De output is: een lijstje dingen om over na te denken. Of: "dit ziet er goed uit, ga ervoor."

Jij blijft eigenaar

Dit is het verschil met de oude wereld. Vroeger gaf je een opdracht aan IT en wachtte je tot zij iets opleverden. Zij waren eigenaar.

Nu bouw jij. De developer is consultant, niet bouwer. Ze helpen je blinde vlekken zien. Jij beslist wat je ermee doet.

Dat betekent ook: jij bent verantwoordelijk. Als het breekt, is het jouw probleem. Dat is de trade-off voor niet meer hoeven wachten.

De vragen die je jezelf kunt stellen

Je hoeft niet altijd een developer te vragen. Je kunt beginnen met dezelfde vragen die zij zouden stellen:

• Wat is het ergste dat kan gebeuren als dit faalt?
• Wie wordt geraakt als het misgaat?
• Bevat dit persoons- of bedrijfsgevoelige data?
• Is dit een eenmalige actie of moet het blijven draaien?
• Zijn er anderen die hiervan afhankelijk worden?
• Wat gebeurt er als ik volgende maand van baan verander?

Als je op meerdere van deze vragen geen goed antwoord hebt — vraag een developer om mee te kijken.

Hoe je begint

Begin klein en persoonlijk. Niet het grote project dat je team nodig heeft. Iets dat alleen jouw werk makkelijker maakt. Een rapport dat je elke week handmatig maakt. Een data-check die je steeds opnieuw doet.

Gebruik een tool met guardrails. Cowork (Anthropic), Claude, of vergelijkbare tools zijn ontworpen met niet-developers in gedachten. Veiliger dan een blanco code-editor.

Test met echte data. Niet met voorbeelddata. Met jouw data. Kijk of het resultaat klopt.

Vraag feedback voordat je uitbreidt. Werkt het? Check met een developer of tech-savvy collega voordat je het deelt of afhankelijkheden creëert.

De nieuwe realiteit

Drie dingen om te onthouden:

Specificeren is de nieuwe skill. Niet coderen. Helder maken wat je wilt, in lagen: PRD → Epics → Tasks. AI doet de rest.

Je blinde vlekken zijn reëel. Je ziet niet wat een developer ziet. Vraag om een vijftien-minuten check voordat je iets bouwt dat gevoelige data raakt of waar anderen van afhankelijk worden.

Jij bent eigenaar. Geen IT-tickets meer. Geen zes weken wachten. Maar ook: als het breekt, is het jouw probleem.

De tools zijn er. De drempel is weg.

Wat zou jij bouwen als je niet hoefde te wachten?