Vibe-coding prompts voor CRUD-app: volledige copy-paste set

Wat deze promptset bouwt (platte taal)

Deze promptset is ontworpen om een complete, werkende CRUD-app te genereren: de schermen die mensen gebruiken, de API die verzoeken afhandelt en de PostgreSQL-database die de data opslaat. Het bevat ook login en rolgebaseerde toegang, zodat verschillende gebruikers verschillende dingen kunnen zien en doen.

CRUD zijn gewoon vier alledaagse acties die je app nodig heeft:

• Create: een nieuw record toevoegen (zoals een klant of taak)
• Read: een lijst bekijken en één item openen
• Update: een bestaand item bewerken
• Delete: een item verwijderen (vaak met een bevestiging)

Aan de front-end zou je moeten eindigen met een voorspelbare set schermen: een lijstpagina, een detailpagina, een create-formulier, een edit-formulier, plus een loginpagina en basisnavigatie. Aan de back-end krijg je endpoints die bij die schermen passen (list, get by id, create, update, delete), ondersteund door een Postgres-tabel en eenvoudige validaties.

De kwaliteit van de prompt doet er meer toe dan de modelkeuze. Het model volgt alleen wat je specificeert. Als je prompt vaag is, krijg je mismatches in veldnamen, ontbrekende routes, onvolledige auth of een UI die niet overeenkomt met de API. Een strakke prompt werkt als een contract: UI, API en database gebruiken dezelfde namen en regels.

Voordat je begint, bepaal een paar details zodat de build consistent blijft:

• Je hoofdentiteit en 6 tot 12 velden (namen, types, verplicht vs optioneel)
• Rollen (bijvoorbeeld: admin, manager, viewer) en wat elke rol kan doen
• Basisregels (wie kan bewerken, soft delete vs hard delete, verplichte velden)
• De “happy path”-schermen die je op dag één nodig hebt
• Eventuele constraints (unieke velden, datumbereiken, statuswaarden)

Als je Koder.ai gebruikt, kan dit één gesprek zijn dat een React-UI, een Go-API en een PostgreSQL-schema produceert die zonder handmatige lijm op elkaar aansluiten.

Voorbereidende worksheet: de paar details die je nodig hebt voordat je prompt

Een goede CRUD-build begint met een kleine set beslissingen. Schrijf ze eerst op en je prompts blijven helder, je schermen zien er goed uit en je API komt overeen met de database.

Begin met één kernentiteit. Dit is het “ding” dat je app elke dag beheert (Item, Customer, Appointment). Voeg een tweede entiteit alleen toe als het echt nodig is op dag één (bijvoorbeeld: Item heeft Category nodig). Als je begint met drie of vier, besteed je het grootste deel van je tijd aan het ontwarren van relaties in plaats van aan een werkende app.

Schrijf je entiteitsvelden met een type en een voorbeeld. Het voorbeeld is belangrijk omdat het labels, opmaak en validatie stuurt.

• Field: type - example (notities)
• name: text - "Paper towels" (verplicht, 2-80 tekens)
• quantity: number - 24 (min 0)
• reorder_date: date - 2026-02-01 (optioneel)
• status: enum - "in_stock" | "low" | "out" (default in_stock)

Maak vervolgens rollen en permissies in gewone taal. Houd het specifiek. Voor veel apps zijn 2 tot 3 rollen genoeg:

• Admin: beheert gebruikers, volledige CRUD op alle records
• Manager: CRUD op records, mag geen gebruikers beheren
• Viewer: alleen-lezen

Maak tenslotte 5 tot 10 voorbeeldrecords. Die sturen realistische UI-labels, dropdown-opties en verstandige defaults. Voorbeeld (voorraad): “Hand soap, qty 6, reorder_date 2026-01-20, status low”.

Als je in Koder.ai bouwt, plak deze worksheet in je eerste prompt zodat het platform de app consistent kan houden over schermen, auth en de PostgreSQL-backed API.

Basisprompt: stel de regels voor de hele build in

Begin met één “regels van de weg”-prompt. Die houdt de build consistent over schermen, API en database, en vermindert heen-en-weer wanneer je later features toevoegt.

Vraag om een kort plan voordat er code wordt geschreven. Je wilt dat het model schermen en routes, tabellen en API-endpoints benoemt. Eis ook dat het aannames vooraf vermeldt (zoals welke rollen bestaan) en die aannames niet verandert tenzij jij een wijziging goedkeurt.

Hier is een copy-paste basisprompt:

You are building a complete full-stack CRUD app.

Tech targets (do not change):
- Frontend: React web app
- Backend: Go REST API
- Database: PostgreSQL

Before writing any code, produce a short plan (max 25 lines) that includes:
1) Screens + key UI components
2) Routes/navigation
3) Roles and permissions
4) PostgreSQL tables (with columns and relationships)
5) API endpoints (method + path) for auth and CRUD

Assumptions:
- If any detail is missing, make a reasonable default and list it under “Assumptions”.
- Keep assumptions consistent across UI, API, and DB. If you must change an assumption, stop and ask.

Rules:
- Use simple, boring CRUD first. No “nice to have” features unless asked.
- Include input validation, basic error messages, and loading states.
- Use clear names that match across layers (same field names in UI, API, and DB).

Non-goals (do NOT implement):
- Payments, subscriptions, invoices
- Complex workflows/approvals
- Multi-tenant org hierarchy
- Real-time chat/notifications

Now ask me 5 clarifying questions max. If I answer “default”, proceed with your assumptions.

Een concreet voorbeeld: als het plan role: admin|member kiest, zou het later niet manager moeten verzinnen om een UI-edgecase op te lossen. Deze prompt dwingt het model te stoppen en jouw goedkeuring te vragen in plaats van te driften.

Copy-paste prompts: schermen en navigatie

Goede schermen ontstaan uit een duidelijke paginakaart. Gebruik de prompts hieronder voordat je database of API-code vraagt. Dat houdt routes en UI-namen stabiel later, waar veel builds fout gaan.

Prompt 1: paginalijst en gebruikersflows

You are building a full-stack CRUD app UI. Start by proposing a complete page list and user flows.

App concept (1 sentence): <PASTE YOUR APP CONCEPT>
Entities (list): <ENTITY_1>, <ENTITY_2>
Roles: <ROLE_1>, <ROLE_2> (include an Admin role)

Deliverables:
1) A table of pages with: Route, Page name, Who can access, Primary actions, Empty state behavior.
2) Key user flows (bullets): sign up, sign in, create record, edit, delete, search/filter, admin manages users.
3) Route naming rules: kebab-case paths, consistent singular/plural, no duplicates.
4) Component naming rules: PascalCase, one top-level page component per route.
Ask me 5 questions max only if needed.

Nadat het antwoord terugkomt, vergrendel je de namen. Als je routenames later verandert, raken API en tests uit elkaar.

Prompt 2: navigatie en formulieren die goed werken

Using the approved page list and route names, generate:

A) Navigation
- A simple top nav for desktop and a compact mobile menu.
- Show which items appear for each role.
- Add a clear "You do not have access" page and redirect rules.

B) Page skeletons
For each page, create a minimal UI with:
- A visible page title and short helper text.
- Loading state, empty state, error state.
- A primary button for the main action.

C) Accessible forms
For all create/edit forms:
- Labels tied to inputs, required markers, inline validation errors.
- Disable submit while saving, show a spinner, prevent double submits.
- Toast or inline success message after save.

D) Consistent action names
Use these verbs exactly: list, view, create, update, delete.
Use these UI actions: onCreate, onUpdate, onDelete, onSearch.

Als de UI te complex terugkomt, vraag dan om slechts één layout, één tabelstijl en één formpatroon over alle pagina's.

Copy-paste prompts: authenticatie en rollen

Als je voorspelbare resultaten wilt, wees expliciet over hoe gebruikers inloggen, hoe lang sessies duren en wat elke rol kan. Deze prompts veronderstellen een eenvoudige email + wachtwoord login en een sessiegebaseerde aanpak (makkelijk te testen over schermen en API's).

Plak dit eerst om login, logout en sessiebehandeling te genereren:

Implement authentication for this app.

Requirements:
- Add UI screens: Login, Logout action, and a simple “My account” page that shows the logged-in user email and role.
- Use email + password login.
- Session handling: keep the user logged in across refresh; include a clear “Log out” button.
- API endpoints: POST /auth/login, POST /auth/logout, GET /auth/me.
- Show friendly error messages for wrong password, unknown email, and locked/disabled accounts.

Security (keep it simple):
- Password rules: minimum 12 characters; must include at least 1 letter and 1 number.
- Store passwords securely (hash + salt). Never store plain text.
- Basic protections: rate-limit login attempts per email/IP and return generic error text that doesn’t reveal which part was wrong.

Deliverables:
- Working UI flows + backend endpoints.
- Seed one default admin user for local testing and tell me the credentials.
- Add clear comments explaining where to change password rules and session duration.

Voeg nu rollen en beschermingsregels toe. Houd permissies klein en makkelijk te testen:

Add role-based access control (RBAC) with these roles: admin, manager, viewer.

Rules:
- admin: can create, edit, delete, and manage users/roles.
- manager: can create and edit records, cannot delete, cannot manage users.
- viewer: read-only.

Enforcement:
- Protect both routes (screens) and API endpoints. Do not rely on the UI alone.
- If a user lacks permission, show a “Not allowed” page in the UI and return HTTP 403 from the API.

Deliverables:
- A simple “Users” admin screen to list users and change roles.
- A clear table (in text) mapping each route + API endpoint to required role.
- Add automated checks or middleware so every protected endpoint enforces the rules.

Snelle handmatige checks die de meeste fouten vangen:

• Log in als elke rol en bevestig wat je wel en niet kunt zien.
• Probeer een beperkte actie alsnog (zoals delete) en bevestig dat je 403 krijgt.
• Bevestig dat logout de sessie wist en de app terugkeert naar het Login-scherm.

Als je in Koder.ai bouwt, houd auth en RBAC-wijzigingen in één snapshot zodat je veilig kunt terugrollen als permissies in de knoop raken.

Copy-paste prompts: PostgreSQL-schema en datamodel

Een goede schema-prompt doet twee dingen: hij dwingt duidelijke tabelrelaties af (zodat schermen en API consistent blijven) en voorkomt “bijna correcte” databases (ontbrekende indexen, timestamps of role-mapping).

Voordat je plakt, beslis over twee toggles (één regel elk):

• Primary keys: uuid of bigserial
• Soft delete: yes (use deleted_at) of no (hard delete)

Plak deze eerste prompt om het datamodel vast te zetten:

You are building the PostgreSQL data model for a full-stack CRUD app.

Domain: <DESCRIBE YOUR APP IN 1 SENTENCE>
Core entities: <LIST 3-6 ENTITIES>

Rules:
- Use PostgreSQL.
- Choose primary key type: <uuid|bigserial>.
- Timestamps: every table must have created_at and updated_at.
- Soft delete: <yes|no>. If yes, add deleted_at and default queries should ignore deleted rows.
- Define users, roles, and permissions storage:
  - users table (email unique, password_hash, status)
  - roles table (name unique)
  - user_roles join table (user_id, role_id) with unique(user_id, role_id)
- For each core entity: define columns, types, required vs optional, and relationships.
- Call out any many-to-many relationships and introduce join tables.
- Propose indexes for common lookups (foreign keys, email, name/search fields).

Output:
1) A short ERD description in plain English.
2) The final table list with columns and constraints.
3) The index list with rationale.

Plak daarna deze prompt om migraties of setup stappen te genereren die bij het project passen:

Now generate the actual database setup for this project.

Requirements:
- Provide SQL migrations (up and down) for all tables, constraints, and indexes.
- Ensure foreign keys and on-delete behavior are explicit.
- Include extensions you rely on (for example uuid generation), but only if needed.
- Add a seed migration for: one admin user, one admin role, and the user_roles link.

Output:
- migrations/ file names in order
- contents of each up/down migration
- brief notes on how to apply migrations in the project

Als iets onduidelijk is, voeg één regel toe: “Ask me up to 5 questions if any relationship or field is unclear before writing SQL.”

Copy-paste prompts: Go CRUD API (Postgres-backed)

Als je backend-outputs steeds half-af terugkomen, dwingt deze prompt de basics af: duidelijke routes, validatie, paginatie en rolchecks in elke handler.

Copy-paste dit exact en vervang daarna de placeholders (RESOURCE, FIELDS, ROLES) met je appdetails.

You are building the backend API in Go for a Postgres-backed CRUD resource.

Resource
- RESOURCE name (singular/plural): <Item/items>
- Table: <items>
- Primary key: <id UUID>
- Fields (name, type, required?, rules):
  - <name TEXT required, 2..80 chars>
  - <qty INT required, min 0>
  - <status TEXT optional, one of: active, archived>
- Ownership: <tenant_id UUID required> and <created_by UUID required>

Auth and roles
- Roles: <admin, manager, viewer>
- Authorization rules:
  - Every endpoint must check role and tenant_id.
  - admin: full access
  - manager: create, read, update, list; cannot delete
  - viewer: read and list only

API requirements
1) Implement REST endpoints:
- POST /api/items
- GET /api/items/{id}
- PUT /api/items/{id}
- DELETE /api/items/{id}
- GET /api/items

2) Define request/response JSON shapes for each endpoint, including examples.

3) Validation
- Return 400 with field-level errors (clear messages) when invalid.
- Return 401 if no auth, 403 if role not allowed, 404 if not found in tenant.

4) List endpoint
- Support filtering by: <status>
- Support sorting by: <created_at,name> with order asc/desc
- Support pagination: page, page_size; return total, page, page_size, items.

5) Data access
- Use database/sql (or pgx) with parameterized queries only.
- Include migrations SQL for the table and indexes (tenant_id + created_at).

Deliverables
- Go code: routes, handlers, DTOs, validation helpers, repository layer
- SQL: migration(s)
- Notes: any assumptions

Controleer na generatie één keer op consistentie: statuscodes passen bij het error body, de list-endpoint geeft stabiele ordering en elke handler controleert zowel rol als tenant-eigendom voordat de database wordt aangeraakt.

Als je Koder.ai gebruikt, roep dan ook dat de backend in Go moet blijven en de database PostgreSQL zodat geëxporteerde code bij de verwachte stack past.

Stapsgewijs: genereer, run en verifieer

Genereer alles (UI, API, database), zet dan om naar strikte verify-modus. Het doel is niet om schermen te bewonderen maar te bewijzen dat de volledige lus werkt: UI - auth - rollen - Postgres - API - UI.

Een simpele verificatierun

1. Start de app en laad het home-scherm. Bevestig dat navigatie werkt en je geen placeholderdata ziet. Als de pagina leeg is, noteer de eerste zichtbare foutmelding (UI-toast, console of serverlog).

2. Maak één testaccount per rol (Admin, Manager, Viewer). Log in en uit met elke gebruiker. Bevestig dat de app de rol ergens zichtbaar toont (profielmenu, instellingen of een klein badgeje).

3. Kies één CRUD-scherm en doorloop een volledige cyclus: maak een record, refresh de pagina, bewerk en verwijder het. De belangrijke check is persistentie: na refresh moet het record reflecteren wat in Postgres staat, niet alleen in geheugen.

4. Probeer opzettelijk verboden acties. Log in als de laagste rol en probeer een admin-only scherm te openen, voer een gerestricteerde actie uit (zoals delete) en bewerk een record dat je niet zou mogen. Je wilt duidelijke resultaten: ofwel een geblokkeerde UI met een bericht, ofwel een 403-achtige fout zonder dat de data verandert.

5. Test randgevallen: lege lijsten, zeer lange namen, ontbrekende verplichte velden en ongeldige formats (email, datums). Bevestig dat de app behulpzame validatie toont en niet crasht.

Als je in Koder.ai werkt, maak een snapshot nadat de eerste end-to-end CRUD-test succesvol is. Dat geeft een veilig rollback-punt voordat je extras toevoegt.

Veelvoorkomende prompt-fouten en hoe ze te verhelpen

De meeste “gebroken” builds zijn niet echt kapot. Ze missen één constraint die UI, API en database samenhoudt.

1) Je vroeg te veel in één keer

Als je schermen, auth, rollen, schema en alle randgevallen in één keer vraagt, wordt de app vaak inconsistent (routes passen niet, modellen drijven weg, half-af schermen).

Fix: splits per laag en forceer het hulpmiddel om te herhalen wat het zal genereren voordat het code schrijft. In Koder.ai helpt dit ook om meerdere agents op één lijn te houden.

2) Rollen zijn vaag, dus checks ontbreken

Als je alleen zegt “admin en user”, krijg je mogelijk een rollabel in de UI maar geen echte server-side autorisatie.

Fix: definieer permissies als acties (create, read, update, delete) per resource en eis server-side afdwinging op elk endpoint.

3) Ontbrekende veldtypes veroorzaken UI en DB-drift

Als je velden in gewone taal beschrijft (“price”, “date”, “status”), renderen formulieren soms als tekstinputs terwijl Postgres nummers, datums of enums verwacht.

Fix: specificeer veldtypes, nullability, defaults en constraints, en eis gedeelde validatieregels.

4) Geen loading- en error-states, dus de UI lijkt kapot

Zonder loading- en error-states ziet een mislukte request eruit als een bevroren pagina.

Fix: eis loading spinners, empty states en zichtbare foutmeldingen voor elk scherm.

5) Namen veranderen halverwege de build

Het hernoemen van “Projects” naar “Workspaces” halverwege breekt vaak routes, handlers en tabelnamen.

Fix: lock een glossary vroeg. Wanneer je namen wijzigt, vraag dan om een rename-plan (search, replace, migrate) in plaats van het model te laten improviseren.

Gebruik deze reparatieprompt wanneer iets uit de rails loopt:

Audit the current app and list mismatches between: (1) routes, (2) API endpoints, (3) database tables/columns, (4) UI form fields.
Then propose a minimal patch plan.
Rules: do not invent new names, do not add new features, keep existing behavior, and update tests if present.
Output: a checklist of changes, then apply them.

Als je steeds inconsistencies blijft zien, mis je waarschijnlijk een “single source of truth”-statement. Voeg één zin toe: “The Postgres schema is the source of truth; UI and API must match it exactly.”

Snelle checklist voordat je het afvinkt

Voer een snelle controle uit zodat de app zich gedraagt als een echt product. Hier falen de meeste full-stack CRUD-apps: kleine mismatches tussen schermen, regels en data.

• Schermen matchen de entiteit-spec: elk scherm (list, details, create, edit) gebruikt exact dezelfde entiteitsnamen en velden die je hebt gedefinieerd.
• Rollen zijn eenduidig: schrijf een simpele allow/deny-tabel per rol en bevestig dat UI en API dezelfde regels afdwingen.
• API-responses zijn consistent: kies één patroon (statuscodes, foutvorm, paginatievorm) en verifieer dat elk endpoint het volgt.
• Database-constraints matchen formulier-validatie: als de DB unieke email of non-null name vereist, valideer dat vóór submit en toon een duidelijke boodschap wanneer de API het afwijst.
• Create/edit/delete overleeft een refresh: maak een record, refresh en bevestig dat het er nog is; bewerk, refresh en bevestig; verwijder, refresh en bevestig.

Een concrete test: log in als de laagste permissierol en probeer een actie die je verwacht te blokkeren (zoals delete). Als het lukt, repareer eerst het beleid op één plek (de API), en pas daarna de UI aan zodat die overeenkomt.

Realistisch voorbeeld: een eenvoudige inventory-tracker

Stel je een klein IT-team voor dat laptops, monitors en adapters uitleent aan personeel. Ze hebben één plek nodig om te zien wat beschikbaar is, wie wat heeft en wanneer het terug moet. Dit is een goede testcase omdat het rollen, een paar schermen en een echte database afdwingt.

Ingevulde prep-worksheet

Gebruik dit exact als input voor je prep-stap (kopieer zoals het is en pas namen aan):

App name: IT Equipment Loans
Goal: Track inventory and loans. Staff can request items. Admin approves and records check-out and return.
Roles:
- admin: manage inventory, approve/deny requests, edit any loan, see all
- staff: browse inventory, create a request, see own requests/loans
- viewer: read-only access to inventory and aggregate loan status
Core screens:
- Login
- Inventory list + item detail
- Request item (staff)
- Admin requests queue
- Loans list (filter: active/overdue)
Data rules:
- An item can have 0 or 1 active loan at a time
- Due date required for approved loans
- Overdue if due_date < today and not returned
Sample data:
- Items: MacBook Pro 14 (MBP-014), Dell 27 Monitor (MON-227), USB-C Dock (DOC-031)
- Users: alice(admin), ben(staff), carla(viewer)

Plakvolgorde

Plak je prompts in deze volgorde zodat de app consistent blijft:

1. Basisprompt (globale regels, stack, naamgeving, foutafhandeling)
2. Schermen en navigatie (Inventory, Requests, Loans, Admin queue)
3. Authenticatie en rollen (admin, staff, viewer permissies)
4. PostgreSQL-schema en seed-data (items, loans, requests, users)
5. Go CRUD API (endpoints en validatie die bij de regels passen)

Een goed resultaat ziet er zo uit: staff kan “MBP-014” aanvragen, de admin keurt het goed met een due date, en de inventory-lijst laat het als niet beschikbaar zien met de naam van de lener.

Als de build dichtbij is maar niet goed, pas één ding tegelijk aan: verscherp rolpermissies (viewer mag nooit edit-knoppen zien), herhaal de regel “maar één actieve lening per item”, of vraag om veldnamen te hernoemen zodat UI-labels en databasekolommen exact overeenkomen.

Volgende stappen: veilig uitbreiden en hergebruiken van de promptset

Als de basis werkt, behandel volgende veranderingen als kleine releases. Kies één feature, definieer wat “done” betekent en prompt daar specifiek voor.

Een verstandige volgorde voor veel apps:

• Audit log: leg vast wie wat en wanneer heeft veranderd (create, update, delete), en toon het op een admin-only scherm.
• Bestandsuploads: koppel een document of afbeelding aan een record, sla metadata in Postgres op en hou toegang achter auth.
• Eenvoudige notificaties: toon in-app alerts (bijv. “low stock” of “new comment”), met een “mark as read”-actie.

Wanneer een wijziging de build breekt, probeer niet alles in één keer te repareren. Roll back, en breng de wijziging daarna opnieuw aan met een kleinere, specifiekere prompt. Als je Koder.ai gebruikt, zijn snapshots en rollback een praktisch vangnet, vooral voor wijzigingen die DB-schema, auth-regels of gedeelde UI-componenten raken.

Planning Mode helpt ook wanneer een feature meerdere lagen beslaat. Laat het eerst het plan herhalen (schermen, API-endpoints, database-wijzigingen, rollen), en keur dat plan dan goed voordat je code genereert. Dat voorkomt de mismatch waarbij de UI velden verwacht die de API niet terugstuurt, of de API schrijft naar kolommen die niet bestaan.

Als je buiten het platform verder wilt gaan, exporteer dan de broncode en werk verder in je gebruikelijke workflow. Bewaar de promptset naast de repo als “build instructions” zodat je de app later kunt reproduceren of iemand nieuw kunt onboarden.

Als je op Koder.ai bouwt (koder.ai), sluit deze promptset goed aan op de React + Go + PostgreSQL-standaarden van het platform, en is het eenvoudig om veilig te itereren met snapshots terwijl je requirements verfijnt.

Tot slot: sla een herbruikbare template-prompt op voor je volgende project. Houd stabiele onderdelen (stack, CRUD-regels, auth- en rollenconventies, Postgres-patronen) en wissel alleen de domein-nouns. Na verloop van tijd worden je prompts een herhaalbaar recept in plaats van een eenmalige proef.