Van prompt naar productie: de AI-developer workflow

"Bouw een kortingscodefunctie voor me."

Je typt dat in je AI coding agent. Het genereert 400 regels verspreid over zes bestanden. Sommige zien er goed uit. Andere gebruiken patronen van een compleet ander framework. Je besteedt de volgende twee uur aan uitzoeken wat past en wat niet.

Dit is hoe de meeste developers nu met AI werken. En het is de langzame manier.

Er is een gestructureerde workflow die AI transformeert van een code-gokmachine naar een echte engineering partner. Het heeft zes fases, en elke fase telt.

Fase 1: Plan voordat je prompt

De grootste fout die developers maken met AI: meteen naar "bouw dit" springen. Geen context. Geen constraints. Geen definitie van klaar.

Begin in plan mode. Schrijf een feature-prompt die AI alles geeft wat het nodig heeft om goede beslissingen te nemen:

# Feature: Kortingscodes toevoegen aan checkout

## Context
- E-commerce app, Next.js + TypeScript + Prisma
- Bestaand: Cart, Checkout, PaymentService
- Patroon: domain services in /src/domain/, API routes in /src/app/api/

## Requirements
- Gebruikers voeren een kortingscode in bij checkout
- Valideer dat code bestaat, niet verlopen, niet over gebruikslimiet
- Pas percentage- of vast kortingsbedrag toe op ordertotaal
- Sla op welke code gebruikt is bij de order

## Constraints
- Volg bestaand servicepatroon (constructor injection, Result types)
- Kortingslogica leeft in domeinlaag, niet in de API route
- Tests vereist voor validatie-edge cases

Dit kost vijf minuten. Het bespaart uren. De prompt vertelt AI je stack, je patronen, je constraints en wat "klaar" betekent. Zonder dit raadt AI. Met dit volgt AI je architectuur.

Wat maakt een goede feature-prompt

Context: wat er al bestaat, welke stack je gebruikt
Requirements: wat de feature doet, geschreven als gedrag
Constraints: welke patronen te volgen, waar code thuishoort
Grenzen: wat AI moet bouwen vs. wat je zelf afhandelt

Fase 2: Bespreek het plan met AI

Keur niet het eerste plan goed dat AI produceert. Behandel het als een pull request van een junior developer. Lees het kritisch.

Goede vragen om te stellen:

"Wat gebeurt er als twee gebruikers op exact hetzelfde moment dezelfde kortingscode invoeren?"
"Waar leeft de validatie? Laat me de bestandsstructuur zien."
"Welke fouten kan dit gooien en hoe handelt de frontend ze elk af?"

Ga heen en weer tot het plan edge cases, foutafhandeling en je bestaande patronen dekt. Deze discussiefase is waar het echte engineeringwerk gebeurt. AI voert uit. Jij beslist.

Fase 3: Laat AI werken, maar stuur bij

Zodra je het plan goedkeurt, begint AI met bouwen. Jouw rol verschuift van code schrijven naar richting bewaken.

Let op deze signalen terwijl AI werkt:

Goed teken	Waarschuwing
Volgt je bestaande servicepatronen	Verzint een nieuw patroon voor deze ene feature
Importeert uit je bestaande modules	Installeert nieuwe dependencies die je niet besproken hebt
Error types matchen je conventies	Generieke try/catch met string-foutmeldingen
Tests die gedrag verifiëren	Tests die alleen checken of de code draait zonder error

Als AI afdwaalt, corrigeer vroeg. Een redirect van twee zinnen nu voorkomt een rewrite van 200 regels later.

Fase 4: Review voor je commit

AI is klaar met de implementatie. Commit nog niet. Dit is waar de vier-check review plaatsvindt:

> Review de kortingscode-implementatie:
> - Check op beveiligingsissues (code enumeratie, race conditions)
> - Verifieer edge cases in validatielogica
> - Schrijf unit tests voor DiscountService
> - Check dat foutmeldingen geen interne details lekken

Vraag AI om zijn eigen werk te reviewen. Klinkt circulair, maar het vangt echte issues. AI in "bouwmodus" optimaliseert voor het afronden van de feature. AI in "reviewmodus" optimaliseert voor het vinden van problemen. Dit zijn verschillende mindsets, zelfs voor een model.

Review het daarna zelf. Focus op:

Domeinlogica correctheid: werkt de kortingsberekening voor alle gevallen?
Security: kan iemand geldige codes achterhalen via responstijden?
Integratie: past dit schoon in de bestaande checkout-flow?
Testkwaliteit: dekken tests de edge cases of alleen het happy path?

Fase 5: Geautomatiseerde quality gates vangen wat je gemist hebt

Je lokale pre-commit hooks draaien eerst:

# .pre-commit-config.yaml
repos:
  - repo: local
    hooks:
      - id: typecheck
        name: TypeScript type check
        entry: npx tsc --noEmit
        language: system
        pass_filenames: false

      - id: lint
        name: ESLint
        entry: npx eslint --fix
        language: system
        types: [typescript]

      - id: test
        name: Unit tests
        entry: npx vitest run --changed
        language: system
        pass_filenames: false

Typechecking, linting en unit tests draaien voordat code je machine verlaat. Als iets faalt, fix je het voor de commit bestaat.

Daarna draait CI/CD op het pull request:

# .github/workflows/ci.yml
name: CI
on: [pull_request]

jobs:
  quality:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
      - run: npm ci
      - run: npx tsc --noEmit        # Type safety
      - run: npx eslint .             # Code quality
      - run: npx vitest run --coverage # Tests + coverage floor
      - run: npx audit-ci --moderate  # Dependency security

Als CI issues vindt, verwerkt AI de bevindingen en stelt een fixplan voor. Jij reviewt het plan, keurt het goed en AI fixt de issues. Geen handmatig debuggen van CI-failures.

Dit is het kwaliteitsvangnet dat AI-gegenereerde code productie-veilig maakt. Zonder geautomatiseerde gates is elke AI-output een gok. Met gates worden problemen gevangen voordat ze je teamgenoten bereiken.

Fase 6: Peer review en merge

Het pull request is groen. CI slaagt. Nu reviewt een andere developer het.

Dit is niet optioneel. Het vier-ogen-principe bestaat omdat twee mensen meer issues vangen dan een, ongeacht hoe goed de AI is. Je reviewer checkt geen syntax (linters doen dat). Ze checken:

Klopt deze aanpak voor het domein?
Zijn er architectuurimplicaties die ik gemist heb?
Is dit onderhoudbaar over zes maanden?

Als de reviewer opmerkingen heeft, ga je terug naar plan mode. Niet vanaf nul. Je update het bestaande plan, AI maakt de wijzigingen en de cyclus gaat door tot het PR goedgekeurd is.

Dan merge je. CI draait een laatste keer op de gemerged branch. Klaar.

De volledige loop

Hier is de complete workflow, zes fases:

Plan: Schrijf een feature-prompt met context, requirements, constraints
Bespreek: Daag het plan uit, dek edge cases, spreek een aanpak af
Bouw: AI werkt terwijl jij de richting bewaakt en bijstuurt
Review: AI self-reviewt op security, tests, performance. Daarna review jij op domeincorrectheid
Automatiseer: Pre-commit hooks en CI/CD vangen wat mensen missen
Merge: Peer review, opmerkingen verwerken, mergen als goedgekeurd

Elke fase kost minuten, geen uren. De hele loop van feature-prompt tot gemerged PR kan in een enkele gefocuste sessie. Vergelijk dat met de oude manier: dagen implementatie, een dag review, nog een dag fixes.

Waarom dit beter is dan "gewoon prompten"

De ongestructureerde aanpak (typ een prompt, krijg code, plak het erin) voelt sneller. Dat is het niet. Je besteedt de tijd die je "bespaarde" aan het debuggen van integratieproblemen, het fixen van patroonmismatches en het uitleggen aan reviewers waarom de code er anders uitziet dan de rest van de codebase.

De gestructureerde workflow investeert vijf minuten planning vooraf en bespaart uren opruimwerk. Het werkt omdat het AI behandelt als een junior engineer die duidelijke instructies nodig heeft, niet als een magische doos die je gedachten leest.

Dat is het verschil tussen AI gebruiken en werken met AI.

Van prompt naar productie: de workflow die daadwerkelijk shipt