Leer bewezen prompting‑patronen die AI naar duidelijkere requirements, modulaire ontwerpen en testbare code sturen—waardoor refactors en herschrijfcycli afnemen.
“Schonere architectuur” in dit artikel betekent niet een specifiek framework of een perfect diagram. Het betekent dat je het systeem eenvoudig kunt uitleggen, dat je het kunt wijzigen zonder ongerelateerde delen te breken, en dat je gedrag kunt verifiëren zonder heroïsche testinspanningen.
Duidelijkheid betekent dat het doel en de vorm van het systeem duidelijk zijn uit een korte omschrijving: wat het doet, wie het gebruikt, welke data het verwerkt en wat het nooit mag doen. Bij AI‑ondersteund werk betekent duidelijkheid ook dat het model requirements op een manier kan herformuleren die jij zou goedkeuren.
Modulariteit betekent dat verantwoordelijkheden duidelijke grenzen hebben. Elke module heeft een taak, inputs/outputs en minimale kennis van interne details van andere modules. Wanneer AI code genereert, voorkomt modulariteit dat businessregels over controllers, UI en data‑toegang worden verspreid.
Testbaarheid betekent dat de architectuur het “aantonen dat het werkt” goedkoop maakt. Businessregels kunnen getest worden zonder een volledig draaiend systeem en integratietests richten zich op een paar contracten in plaats van elk code‑pad.
Herschrijvingen worden meestal niet veroorzaakt door “slechte code” maar door ontbrekende constraints, vage scope en verborgen aannames. Voorbeelden:
AI kan dit faalpatroon versnellen doordat het snel overtuigende output levert, waardoor je makkelijk bouwt op wankele fundamenten.
De patronen hieronder zijn templates om aan te passen, geen magische prompts. Hun echte doel is om vroeg de juiste gesprekken af te dwingen: constraints verduidelijken, opties vergelijken, aannames documenteren en contracten definiëren. Als je dat denkwerk overslaat, vult het model de lege plekken en betaal je daar later voor.
Je gebruikt ze tijdens de hele leveringscyclus:
Als je een vibe‑coding workflow gebruikt (waar het systeem via chat wordt gegenereerd en geïtereerd), zijn deze checkpoints nog belangrijker. Bijvoorbeeld, in Koder.ai kun je een "planning mode" loop draaien om requirements en contracten vast te leggen voordat je React/Go/PostgreSQL code genereert, en vervolgens snapshots/rollback gebruiken om veilig te itereren wanneer aannames veranderen—zonder dat elke wijziging in een herschrijving uitmondt.
Prompting‑patronen zijn het meest waardevol wanneer ze de besluitvorming verminderen. Het geheim is ze als korte, herhaalbare checkpoints te gebruiken—voordat je code schrijft, tijdens ontwerp en tijdens review—zodat de AI artefacten produceert die je opnieuw kunt gebruiken, niet extra tekst waar je doorheen moet ploegen.
Voor het coderen: draai één "alignment"‑loop om doelen, gebruikers, constraints en succescriteria te bevestigen.
Tijdens ontwerp: gebruik patronen die expliciete afwegingen afdwingen (bijv. alternatieven, risico's, databoundaries) voordat je begint met implementeren.
Tijdens review: gebruik een checklist‑achtige prompt om hiaten te vinden (randgevallen, monitoring, security, performance) terwijl veranderingen nog goedkoop zijn.
Je krijgt beter output met een klein, consistent input‑pakket:
Als je iets niet weet, zeg het expliciet en vraag de AI om aannames te benoemen.
In plaats van “leg het ontwerp uit,” vraag artefacten die je in docs of tickets kunt plakken:
Doe 10–15 minuten loops: prompt → skim → aanscherpen. Neem altijd acceptatiecriteria op (wat waar moet zijn om het ontwerp acceptabel te maken) en vraag de AI om zichzelf daartegen te controleren. Dat voorkomt eindeloze redesign en maakt de patronen in de volgende secties snel toepasbaar.
De meeste “architectuurherschrijvingen” worden niet veroorzaakt door slechte diagrammen maar door het bouwen van het juiste ding voor het verkeerde (of onvolledige) probleem. Als je vroeg een LLM gebruikt, vraag dan niet meteen om architectuur. Laat het ambiguïteit blootleggen.
Gebruik het model als requirements‑interviewer. Je doel is een korte, geprioriteerde spec die je kunt bevestigen voordat iemand componenten ontwerpt, databases kiest of APIs vastlegt.
Hier is een copy‑paste template die je hergebruiken kunt:
You are my requirements analyst. Before proposing any architecture, do this:
1) Ask 10–15 clarifying questions about missing requirements and assumptions.
- Group questions by: users, workflows, data, integrations, security/compliance, scale, operations.
2) Produce a prioritized scope list:
- Must-have
- Nice-to-have
- Explicitly out-of-scope
3) List constraints I must confirm:
- Performance (latency/throughput targets)
- Cost limits
- Security/privacy
- Compliance (e.g., SOC2, HIPAA, GDPR)
- Timeline and team size
4) End with: “Restate the final spec in exactly 10 bullets for confirmation.”
Context:
- Product idea:
- Target users:
- Success metrics:
- Existing systems (if any):
Je wilt vragen die beslissingen afdwingen (geen generieke “vertel meer”), plus een must‑have lijst die binnen je tijdlijn afgevinkt kan worden.
Behandel de “10 bullets” herformulering als een contract: plak het in je ticket/PRD, vraag stakeholders om een snelle ja/nee en ga pas daarna door naar architectuur. Deze ene stap voorkomt de meest voorkomende oorzaak van late refactors: bouwen aan features die nooit echt vereist waren.
Als je begint met tools (“Moeten we event sourcing gebruiken?”) ontwerp je vaak voor de architectuur in plaats van voor de gebruiker. Een snellere weg naar schone structuur is de AI eerst user journeys in eenvoudige taal te laten beschrijven en pas daarna die journeys te vertalen naar componenten, data en APIs.
Gebruik dit als copy‑paste startpunt:
Vraag dan:
“Beschrijf de stap‑voor‑stap flow voor elke actie in eenvoudige taal.”
“Geef een eenvoudige statusdiagram‑beschrijving of statuslijst (bijv. Draft → Submitted → Approved → Archived).”
“Noem non‑happy‑path scenario's: timeouts, retries, dubbele requests, annuleringen en ongeldige inputs.”
Als de flows duidelijk zijn, kun je de AI vragen ze te mappen naar technische keuzes:
Pas daarna vraag je om een architectuurschets (services/modules, grenzen en verantwoordelijkheden) die direct gekoppeld is aan de flowstappen.
Laat de AI elke journey omzetten in acceptatiecriteria die je echt kunt testen:
Dit patroon vermindert herschrijvingen omdat de architectuur uit gebruikersgedrag groeit—niet uit aannames over technologie.
De meeste architectuurherschrijvingen worden niet veroorzaakt door “slecht ontwerp” maar door verborgen aannames die onjuist blijken. Als je een LLM om architectuur vraagt, vult het vaak gaten met plausibele gissingen. Een assumptielog maakt die gissingen vroeg zichtbaar, wanneer veranderingen goedkoop zijn.
Je doel is een duidelijke scheiding tussen feiten die je gaf en aannames die het maakte.
Gebruik dit promptpatroon:
Template prompt “Before proposing any solution: list your assumptions. Mark each as validated (explicitly stated by me) or unknown (you inferred it). For each unknown assumption, propose a fast way to validate it (question to ask, metric to check, or quick experiment). Then design based only on validated assumptions, and call out where unknowns could change the design.”
Houd het kort zodat mensen het echt gebruiken:
Voeg één regel toe die het model dwingt zijn kantelpunten te noemen:
Dit patroon verandert architectuur in een set conditionele beslissingen. Je krijgt niet alleen een diagram—je krijgt een kaart van wat bevestigd moet worden voordat je je commit.
AI‑tools zijn goed in het produceren van één “beste” ontwerp—maar dat is vaak slechts de eerste plausibele optie. Schonere architectuur verschijnt vaak als je vroeg een vergelijking afdwingt, terwijl veranderingen nog goedkoop zijn.
Gebruik een prompt die meerdere architecturen vereist en een gestructureerde tradeoff‑tabel:
Propose 2–3 viable architectures for this project.
Compare them in a table with criteria: complexity, reliability, time-to-ship, scalability, cost.
Then recommend one option for our constraints and explain why it wins.
Finally, list “what we are NOT building” in this iteration to keep scope stable.
Context:
- Users and key journeys:
- Constraints (team size, deadlines, budget, compliance):
- Expected load and growth:
- Current systems we must integrate with:
Een vergelijking dwingt het model (en jou) om verborgen aannames naar boven te halen: waar state leeft, hoe services communiceren, wat synchroon moet zijn en wat kan worden vertraagd.
De criteriatabel is belangrijk omdat die discussies als “microservices vs monolith” ontwijkt en de beslissing ankert aan wat jullie echt belangrijk vinden—snel leveren, minder operationele overhead of betere betrouwbaarheid.
Accepteer geen “het hangt ervan af.” Vraag om een duidelijke aanbeveling en specifieke constraints waarop die optimaliseert.
Eis ook “wat we in deze iteratie NIET bouwen.” Voorbeelden: “Geen multi‑region failover”, “Geen plugin‑systeem”, “Geen realtime notificaties.” Dit voorkomt dat de architectuur stiekem uitbreidt om features te ondersteunen waar je nog niet voor hebt gekozen—en voorkomt verrassende herschrijvingen als de scope later verandert.
De meeste herschrijvingen gebeuren omdat grenzen vaag zijn: alles raakt alles, en een kleine wijziging verspreidt zich door de codebase. Dit patroon gebruikt prompts die vóór elke framework‑ of class‑discussie heldere module‑eigenaarship afdwingen.
Vraag de AI modules en verantwoordelijkheden te definiëren, plus wat uitdrukkelijk niet in elke module hoort. Vraag vervolgens interfaces (inputs/outputs) en dependency‑regels, geen bouwplan of implementatiedetails.
Gebruik dit wanneer je een nieuwe feature schetst of een rommelig gebied refactort:
Noem modules met:
Definieer voor elke module alleen interfaces:
Dependency‑regels:
Future change test: Gegeven deze waarschijnlijke wijzigingen: <lijst 3>, laat zien welke enkele module elke wijziging moet opvangen en waarom.
Doel is modules die je in onder een minuut aan een collega kunt uitleggen. Als het model een “Utils”‑module voorstelt of businessregels in controllers schuift, duw terug: “Verplaats beslissingen naar een domeinmodule en houd adapters dun.”
Als je klaar bent, heb je grenzen die toekomstige vereisten overleven—omdat wijzigingen een duidelijke plek hebben en dependency‑regels accidentele koppeling voorkomen.
Integratie‑herwerk wordt vaak niet veroorzaakt door “slechte code” maar door onduidelijke contracten. Als datamodel en API‑shapes laat worden besloten, vult elk team (of elke module) de lege plekken op zijn eigen manier en besteed je de volgende sprint aan het reconciliëren van mismatchende aannames.
Begin door contracten te vragen voordat je praat over frameworks, databases of microservices. Een duidelijk contract wordt de gedeelde referentie die UI, backend en datapunten op één lijn houdt.
Gebruik deze vroege prompt met je AI‑assistent:
Volg dat direct met:
Je wilt concrete artefacten, geen prose. Bijvoorbeeld:
Subscription
En een API‑schets:
POST /v1/subscriptions
{
"customer_id": "cus_123",
"plan_id": "pro_monthly",
"start_date": "2026-01-01"
}
201 Created
{
"id": "sub_456",
"status": "active",
"current_period_end": "2026-02-01"
}
422 Unprocessable Entity
{
"error": {
"code": "VALIDATION_ERROR",
"message": "start_date must be today or later",
"fields": {"start_date": "in_past"}
}
}
Laat de AI regels noemen zoals: “Additieve velden zijn toegestaan zonder versie‑bump; hernoemingen vereisen /v2; clients moeten onbekende velden negeren.” Deze ene stap voorkomt stille breaking changes—en de herschrijvingen die daarop volgen.
Architecturen worden herschreven wanneer “happy path” ontwerpen echte traffic, flauwe afhankelijkheden en onverwacht gebruikersgedrag ontmoeten. Dit patroon maakt betrouwbaarheid een expliciet ontwerpresultaat, niet iets voor na de lancering.
Gebruik dit met je gekozen architectuurbeschrijving:
List failure modes; propose mitigations; define observability signals.
For each failure mode:
- What triggers it?
- User impact (what the user experiences)
- Mitigation (design + operational)
- Retries, idempotency, rate limits, timeouts considerations
- Observability: logs/metrics/traces + alert thresholds
Noem interfaces die kunnen falen: externe APIs, database, queues, auth provider en achtergrondjobs. Vereis concrete beslissingen:
Eindig de prompt met: “Return a simple checklist we can review in 2 minutes.” Een goede checklist bevat items zoals: dependency timeouts ingesteld, retries begrensd, idempotentie geïmplementeerd voor create/charge acties, backpressure/rate limiting aanwezig, graceful degradation pad gedefinieerd.
Vraag events rond gebruikersmomenten (niet alleen systeemintern): “user_signed_up”, “checkout_submitted”, “payment_confirmed”, “report_generated”. Voor elk, vraag om:
Dit maakt betrouwbaarheid tot een ontwerpartefact dat je kunt valideren voordat er code bestaat.
Een veelvoorkomende manier waarop AI‑ondersteund ontwerp herschrijvingen creëert, is door te vroeg een “complete” architectuur te stimuleren. De oplossing is eenvoudig: forceer dat het plan begint met de kleinste bruikbare slice—één die waarde levert, het ontwerp test en toekomstige opties openhoudt.
Gebruik dit wanneer het oplossingidee sneller uitbreidt dan de requirements:
Template: “Propose the smallest usable slice; define success metrics; list follow‑ups.”
Vraag het model te antwoorden met:
Voeg een tweede instructie toe: “Give a phased roadmap: MVP → v1 → v2, and explain what risk each phase reduces.” Dit houdt latere ideeën zichtbaar zonder ze in de eerste release te dwingen.
Voorbeelden van gewenste uitkomsten:
De krachtigste regel in dit patroon is: “List what is explicitly out of scope for MVP.” Uitsluitingen beschermen architectuurbeslissingen tegen voortijdige complexiteit.
Goede uitsluitingen zien eruit als:
Tot slot: “Convert the MVP into tickets, each with acceptance criteria and dependencies.” Dit dwingt duidelijkheid af en onthult verborgen koppelingen.
Een degelijke ticketopdeling bevat doorgaans:
Als je wilt, laat het model outputten in het format van je team (bijv. Jira‑velden) en bewaar latere fases als aparte backlog.
Een eenvoudige manier om te voorkomen dat architectuur wegzakt, is duidelijkheid forceren via tests voordat je om een ontwerp vraagt. Als je een LLM vraagt te beginnen met acceptatietests, moet het gedrag, inputs, outputs en randgevallen benoemen. Dat legt ontbrekende requirements bloot en stuurt implementatie naar schone modulegrenzen.
Gebruik dit als een “poort”‑prompt telkens wanneer je een component gaat ontwerpen:
Volg aan met: “Group the tests by module responsibility (API layer, domain logic, persistence, external integrations). For each group, specify what is mocked and what is real.”
Dit duwt het LLM weg van verwarde ontwerpen waarin alles alles raakt. Als het niet kan uitleggen waar integratietests beginnen, is de architectuur waarschijnlijk nog niet duidelijk.
Vraag: “Propose a test data plan: fixtures vs factories, how to generate edge cases, and how to keep tests deterministic. List which dependencies can use in‑memory fakes and which require a real service in CI.”
Je ontdekt vaak dat een “simpele” feature eigenlijk een contract, een seed‑dataset of stabiele IDs nodig heeft—beter om dat nu te vinden dan tijdens een herschrijving.
Sluit af met een lichte checklist:
Design reviews mogen niet alleen plaatsvinden nadat code al bestaat. Met AI kun je een “pre‑mortem review” op je architectuurschets uitvoeren (zelfs als het maar enkele alinea's en een diagram‑in‑woorden is) en een concrete lijst met zwaktes krijgen voordat ze herschrijvingen worden.
Begin met een strenge reviewer‑houding en forceer specificiteit:
Prompt: “Act as a reviewer; list risks, inconsistencies, and missing details in this design. Be concrete. If you can’t evaluate something, say what information is missing.”
Plak je design‑samenvatting, constraints (budget, tijdlijn, teamvaardigheden) en non‑functionele vereisten (latency, beschikbaarheid, compliance).
Reviews falen wanneer feedback vaag is. Vraag om een gerangschikte set fixes:
Prompt: “Give me a prioritized punch list. For each item: severity (Blocker/High/Medium/Low), why it matters, suggested fix, and the smallest validation step.”
Dit levert beslisklare taken op in plaats van een debat.
Een nuttige dwingende maat is een eenvoudige score:
Prompt: “Assign a rewrite risk score from 1–10. Explain the top 3 drivers. What would reduce the score by 2 points with minimal effort?”
Je jaagt geen precisie na; je brengt vooral de meest rewrite‑gevoelige aannames naar boven.
Voorkom dat de review scope opgeblazen wordt:
Prompt: “Provide a diff plan: minimal changes needed to reach the target design. List what stays the same, what changes, and any breaking impacts.”
Als je dit patroon bij elke iteratie herhaalt, evolueert je architectuur via kleine, omkeerbare stappen—terwijl grote problemen vroeg worden opgevangen.
Gebruik dit pakket als een lichtgewicht workflow die je bij elke feature herhaalt. Het idee is om prompts te koppelen zodat elke stap een artefact produceert dat de volgende stap kan hergebruiken—waardoor “verloren context” en verrassende herschrijvingen afnemen.
In de praktijk implementeren teams deze keten vaak als een herhaalbaar “feature‑recept”. Als je met Koder.ai bouwt, map je dezelfde structuur makkelijk naar een chat‑gedreven bouwproces: bewaar de artefacten op één plek, genereer de eerste werkende slice en iterateer met snapshots zodat experimenten omkeerbaar blijven. Als de MVP klaar is, kun je broncode exporteren of deployen/hosten met een custom domain—handig als je de snelheid van AI‑ondersteunde levering wilt zonder jezelf aan één omgeving vast te binden.
SYSTEM (optional)
You are a software architecture assistant. Be practical and concise.
Guardrail: When you make a recommendation, cite the specific lines from *my input* you relied on by quoting them verbatim under “Input citations”. Do not cite external sources or general industry claims.
If something is unknown, ask targeted questions.
1) REQUIREMENTS CLARIFIER
Context: <product/system overview>
Feature: <feature name>
My notes: <paste bullets, tickets, constraints>
Task:
- Produce: (a) clarified requirements, (b) non-goals, (c) constraints, (d) open questions.
- Include “Input citations” quoting the exact parts of my notes you used.
2) ARCHITECTURE OPTIONS
Using the clarified requirements above, propose 3 architecture options.
For each: tradeoffs, complexity, risks, and when to choose it.
End with a recommendation + “Input citations”.
3) MODULAR BOUNDARIES
Chosen option: <option name>
Define modules/components and their responsibilities.
- What each module owns (and does NOT own)
- Key interfaces between modules
- “Input citations”
4) DATA & API CONTRACTS
For each interface, define a contract:
- Request/response schema (or events)
- Validation rules
- Versioning strategy
- Error shapes
- “Input citations”
5) TEST-FIRST ACCEPTANCE
Write:
- Acceptance criteria (Given/When/Then)
- 5–10 critical tests (unit/integration)
- What to mock vs not mock
- “Input citations”
6) RELIABILITY + DESIGN REVIEW
Create:
- Failure modes list (timeouts, partial failure, bad data, retries)
- Observability plan (logs/metrics/traces)
- Review checklist tailored to this feature
- “Input citations”
Als je een diepere companion wilt, zie /blog/prompting-for-code-reviews. Als je tooling of team‑rollout evalueert, is /pricing een praktisch volgende stap.
"Schonere architectuur" betekent hier dat je kunt:
Bij AI‑ondersteund werk betekent het ook dat het model requirements op zo'n manier kan herformuleren dat jij ze zou goedkeuren.
AI kan overtuigende code en ontwerpen snel produceren, waardoor het makkelijk is om voort te bouwen op ontbrekende constraints en verborgen aannames. Die snelheid kan triggers voor herschrijvingen versterken, zoals:
De oplossing is niet "minder AI" maar prompts die constraints, contracten en aannames vroegtijdig naar boven halen.
Gebruik de patronen als korte checkpoints die herbruikbare artefacten opleveren (niet extra verhalende tekst):
Houd iteraties bij : prompt → snel scannen → aanscherpen → zelfcontrole tegen acceptatiecriteria.
Breng een klein, consistent bundel mee:
Als iets onbekend is, zeg dat expliciet en vraag het model om expliciet aannames te benoemen in plaats van stilletjes te gokken.
Vraag artefacten die je direct in docs, tickets en PR's kunt plakken:
Dit houdt AI‑output actiegericht en vermindert herwerk door “verloren context.”
Gebruik het model als requirements‑interviewer. Laat het:
Begin met rollen en acties, en vraag vervolgens om:
Pas daarna pas flows toe op beslissingen zoals waar validatie eindigt en businessregels beginnen, waar idempotentie nodig is, en wat opgeslagen vs afgeleid moet worden. Zet flows om in testbare Given/When/Then acceptatiecriteria.
Omdat LLM's gaten vaak opvullen met plausibele aannames, forceer je scheiding tussen:
Vraag om een assumptielog die elk item markeert als gevalideerd of onbekend, plus:
Forceer het model om 2–3 haalbare architecturen voor te stellen en vergelijk ze in een tabel (complexiteit, betrouwbaarheid, time‑to‑ship, schaalbaarheid, kosten). Vraag daarna om:
Dit voorkomt dat de eerste plausibele optie de default wordt en vermindert verborgen scopegroei (een veelvoorkomende oorzaak van herschrijvingen).
Een contract‑eerst aanpak vermindert integratie‑herwerk door data‑shapes en compatibiliteitsregels expliciet te maken. Vraag om:
/v2; clients negeren onbekende velden)Als UI, backend en integraties hetzelfde contract‑artefact delen, besteed je minder tijd aan het reconciliëren van mismatchende aannames later.
Behandel die 10 bullets als het contract dat je met stakeholders valideert voordat je aan het ontwerp begint.
Voeg ook “wat zou je antwoord veranderen?” triggers toe (bijv. volume, latency, compliance, retentie) zodat het ontwerp conditioneel wordt en minder gevoelig voor herschrijvingen.