Vibe‑Coding‑Prompts für CRUD‑App: Full‑Stack Copy‑Paste‑Set

Was dieses Prompt‑Set baut (einfach erklärt)

Dieses Prompt‑Set ist darauf ausgelegt, eine komplette, funktionierende CRUD‑App zu erzeugen: die Screens, die Benutzer nutzen, die API, die Anfragen bearbeitet, und die PostgreSQL‑Datenbank, die die Daten speichert. Es enthält außerdem Login und rollenbasierte Zugriffssteuerung, sodass verschiedene Nutzer unterschiedliche Dinge sehen und tun können.

CRUD sind die vier alltäglichen Aktionen, die jede App braucht:

• Create: einen neuen Datensatz hinzufügen (z. B. Kunde oder Aufgabe)
• Read: eine Liste anzeigen und einen einzelnen Eintrag öffnen
• Update: einen vorhandenen Eintrag bearbeiten
• Delete: einen Eintrag entfernen (oft mit Bestätigungs‑Schritt)

Im Frontend solltest du am Ende ein vorhersehbares Set an Screens haben: eine Listen‑Seite, eine Detail‑Seite, ein Create‑Formular, ein Edit‑Formular sowie eine Login‑Seite und grundlegende Navigation. Im Backend hast du Endpunkte, die zu diesen Screens passen (list, get by id, create, update, delete), gestützt von einer Postgres‑Tabelle und einfachen Validierungen.

Prompt‑Qualität ist wichtiger als die Modellwahl. Das Modell kann nur dem folgen, was du vorgibst. Wenn dein Prompt vage ist, bekommst du falsche Feldnamen, fehlende Routen, unvollständige Auth oder eine UI, die nicht zur API passt. Ein präziser Prompt wirkt wie ein Vertrag: UI, API und DB stimmen bei Namen und Regeln überein.

Bevor du startest, entscheide ein paar Details, damit der Build konsistent bleibt:

• Deine Hauptentität und 6–12 Felder (Namen, Typen, erforderlich vs optional)
• Rollen (zum Beispiel: admin, manager, viewer) und was jede Rolle darf
• Grundregeln (wer darf bearbeiten, soft delete vs hard delete, Pflichtfelder)
• Die „Happy‑Path“ Screens, die du am ersten Tag brauchst
• Etwaige Einschränkungen (einzigartige Felder, Datumsbereiche, Statuswerte)

Wenn du Koder.ai verwendest, kann das eine Unterhaltung sein, die eine React‑UI, eine Go‑API und ein PostgreSQL‑Schema erzeugt, die ohne manuelles Verknüpfen zusammenpassen.

Vorbereitungs‑Arbeitsblatt: die wenigen Details, die du vor dem Prompten brauchst

Ein guter CRUD‑Build beginnt mit einer kleinen Entscheidungsliste. Schreibe sie zuerst auf, dann bleiben deine Prompts klar, deine Screens sehen richtig aus und deine API passt zur Datenbank.

Fange mit einer Kernentität an. Das ist das „Ding“, das deine App täglich verwaltet (Item, Customer, Appointment). Füge eine zweite Entität nur hinzu, wenn sie am ersten Tag wirklich nötig ist (z. B. Item braucht Category). Wenn du mit drei oder vier beginnst, verbringst du die meiste Zeit damit, Beziehungen zu entwirren, statt eine funktionierende App zu bekommen.

Schreibe die Felder der Entität mit Typ und Beispiel. Das Beispiel ist wichtig, weil es Labels, Formatierung und Validierung lenkt.

• Field: type - example (Anmerkungen)
• name: text - "Paper towels" (erforderlich, 2–80 Zeichen)
• quantity: number - 24 (min 0)
• reorder_date: date - 2026-02-01 (optional)
• status: enum - "in_stock" | "low" | "out" (default in_stock)

Liste als Nächstes Rollen und Berechtigungen in einfacher Sprache. Sei konkret. Für viele Apps reichen 2–3 Rollen:

• Admin: verwaltet Nutzer, volles CRUD für alle Datensätze
• Manager: CRUD für Datensätze, darf keine Nutzer verwalten
• Viewer: nur Lesen

Erstelle schließlich 5–10 Beispieldatensätze. Diese treiben realistische UI‑Labels, Dropdown‑Optionen und sinnvolle Defaults. Beispiel (Inventar): „Hand soap, qty 6, reorder_date 2026-01-20, status low”.

Wenn du in Koder.ai baust, füge dieses Arbeitsblatt in deinen ersten Prompt ein, damit die Plattform die App über Screens, Auth und die PostgreSQL‑API hinweg konsistent halten kann.

Basis‑Prompt: Regeln für den gesamten Build festlegen

Beginne mit einem „Regeln der Straße“-Prompt. Er sorgt dafür, dass UI, API und Datenbank konsistent bleiben, und reduziert Nacharbeit, wenn du später Features hinzufügst.

Forder einen kurzen Plan, bevor Code geschrieben wird. Das Modell soll Screens und Routen, Tabellen und API‑Endpunkte benennen. Fordere außerdem, dass Annahmen vorab genannt werden (z. B. welche Rollen existieren) und diese Annahmen unverändert bleiben, es sei denn, du genehmigst eine Änderung.

Hier ein Copy‑Paste Basis‑Prompt:

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.

Ein konkretes Beispiel: Wenn der Plan role: admin|member auswählt, sollte er später nicht plötzlich manager erfinden, um einen UI‑Edge‑Case zu lösen. Dieser Prompt zwingt das Modell dazu, innezuhalten und deine Zustimmung einzuholen, statt daneben zu driften.

Copy‑Paste Prompts: Screens und Navigation

Gute Screens entstehen aus einer klaren Seitenkarte. Nutze die folgenden Prompts, bevor du Datenbank oder API erzeugst. So bleiben Routen und UI‑Namen stabil — dort entstehen die meisten Probleme.

Prompt 1: Seitenliste und User‑Flows

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.

Nachdem du die Antwort bekommen hast, sperre die Namen. Wenn du Routen später änderst, geraten API und Tests aus der Synchronisation.

Prompt 2: Navigation und Formulare, die sich gut verhalten

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.

Wenn die UI zu komplex zurückkommt, bitte es, nur ein Layout, einen Tabellenstil und ein Formularmuster über alle Seiten hinweg zu verwenden.

Copy‑Paste Prompts: Authentifizierung und Rollen

Wenn du vorhersehbare Ergebnisse willst, sei explizit, wie sich Nutzer einloggen, wie lange Sessions dauern und was jede Rolle darf. Diese Prompts gehen von einfachem E‑Mail+Passwort‑Login und sessionbasierter Handhabung aus (leicht testbar über Screens und APIs).

Füge diesen Prompt zuerst ein, um Login, Logout und Session‑Handling zu generieren:

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.

Füge danach Rollen und Schutzregeln hinzu. Halte Berechtigungen klein und leicht testbar:

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.

Schnelle manuelle Prüfungen, die die meisten Fehler aufspüren:

• Logge dich als jede Rolle ein und bestätige, was sichtbar und was nicht.
• Versuche eine eingeschränkte Aktion (z. B. delete) und bestätige, dass du 403 erhältst.
• Bestätige, dass Logout die Session löscht und die App zur Login‑Seite zurückkehrt.

Wenn du Koder.ai verwendest, halte Auth und RBAC‑Änderungen in einem Snapshot, damit du bei Bedarf sauber zurückrollen kannst.

Copy‑Paste Prompts: PostgreSQL‑Schema und Datenmodell

Ein guter Schema‑Prompt erfüllt zwei Aufgaben: er zwingt zu klaren Tabellenbeziehungen (damit Screens und API konsistent bleiben) und verhindert „fast richtige“ Datenbanken (fehlende Indexe, Timestamps oder Rollen‑Mappings).

Vor dem Einfügen entscheide zwei Optionen (jeweils eine Zeile):

• Primary keys: uuid oder bigserial
• Soft delete: yes (verwende deleted_at) oder no (hard delete)

Füge zuerst diesen Prompt ein, um das Datenmodell zu sperren:

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.

Dann diesen Prompt einfügen, um Migrationen/Setup‑Schritte zu erzeugen:

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

Wenn etwas unklar ist, füge eine Zeile hinzu: „Ask me up to 5 questions if any relationship or field is unclear before writing SQL.”

Copy‑Paste Prompts: Go CRUD API (Postgres‑backed)

Wenn dein Backend immer wieder halb fertig zurückkommt, zwingt dich dieser Prompt zu den Grundlagen: klare Routen, Validierung, Paginierung und Rollenprüfungen in jedem Handler.

Kopiere ihn wie er ist und ersetze Platzhalter (RESOURCE, FIELDS, ROLES) mit deinen Projektdetails.

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

Nach der Generierung mach einen schnellen Konsistenz‑Check: Statuscodes müssen zur Fehlerstruktur passen, die List‑Endpoint gibt stabile Reihenfolge zurück, und jeder Handler prüft sowohl Rolle als auch Tenant‑Eigentum, bevor er die DB manipuliert.

Wenn du Koder.ai benutzt, rufe außerdem hervor, dass Backend in Go und Datenbank in PostgreSQL bleiben müssen, damit der exportierte Code zum erwarteten Stack passt.

Schritt‑für‑Schritt: generieren, ausführen und verifizieren

Erzeuge alles (UI, API, DB) und wechsle dann in den strikten Verifikationsmodus. Ziel ist nicht, Screens zu bewundern, sondern zu beweisen, dass die gesamte Schleife funktioniert: UI → Auth → Rollen → Postgres → API → UI.

Einfache Verifikationsrunde

1. Starte die App und lade die Startseite. Bestätige, dass die Navigation funktioniert und keine Platzhalterdaten sichtbar sind. Wenn die Seite leer ist, notiere die erste sichtbare Fehlermeldung (UI‑Toast, Konsole oder Server‑Log).

2. Erstelle je eine Test‑Account pro Rolle (Admin, Manager, Viewer). Logge dich mit jedem Nutzer ein und aus. Bestätige, dass die Rolle irgendwo sichtbar ist (Profil‑Menü, Einstellungen oder als kleines Badge).

3. Wähle einen CRUD‑Screen und führe einen kompletten Zyklus aus: erstelle einen Datensatz, lade die Seite neu, bearbeite und lösche ihn. Die zentrale Prüfung ist Persistenz: Nach dem Refresh sollte der Datensatz dem Postgres‑Zustand entsprechen, nicht nur dem Speicher der UI.

4. Versuche absichtlich verbotene Aktionen. Logge dich mit der niedrigsten Rolle ein und rufe einen Admin‑Screen auf, führe eine eingeschränkte Aktion (z. B. delete) aus und versuche, einen Datensatz zu bearbeiten, den du nicht dürftest. Ergebnis: UI blockt mit einer Meldung oder die API antwortet mit 403 und ohne Änderung.

5. Prüfe Randfälle: leere Listen, sehr lange Namen, fehlende Pflichtfelder und ungültige Formate (E‑Mail, Daten). Bestätige, dass die App hilfreiche Validierungen zeigt und nicht abstürzt.

Wenn du Koder.ai verwendest, erstelle einen Snapshot direkt nach dem ersten erfolgreichen End‑to‑End CRUD‑Test. Das ist ein sicherer Rollback‑Punkt, bevor du Extras hinzufügst.

Häufige Prompt‑Fehler und wie man sie behebt

Die meisten „kaputten“ Builds sind gar nicht kaputt. Es fehlt nur eine Einschränkung, die UI, API und DB zusammenhält.

1) Du hast zu viel auf einmal verlangt

Wenn du Screens, Auth, Rollen, Schema und jede Randbedingung in einem Prompt verlangst, wird die App oft inkonsistent (Routen passen nicht, Modelle driften, Seiten sind halb fertig).

Fix: Teile nach Schichten auf und zwing das Tool, vor dem Generieren kurz zu wiederholen, was es liefern wird. In Koder.ai hilft das außerdem, mehrere Agents zu synchronisieren.

2) Rollen sind vage, also fehlen Prüfungen

Wenn du nur „admin und user“ sagst, bekommst du vielleicht ein Rollen‑Label in der UI, aber keine serverseitige Autorisierung.

Fix: Definiere Berechtigungen als Aktionen (create, read, update, delete) pro Resource und verlange serverseitige Durchsetzung auf jedem Endpoint.

3) Fehlende Feldtypen führen zu UI/DB‑Drift

Wenn du Felder nur in Worten beschreibst („price“, „date“, „status“), rendert das Formular eventuell Textinputs, während Postgres Zahlen, Datum oder Enums erwartet.

Fix: Gib Feldtypen, Nullbarkeit, Defaults und Constraints an und verlange gemeinsame Validierungsregeln.

4) Keine Lade‑ und Fehlerzustände, also wirkt die UI kaputt

Ohne Lade‑ und Fehlerzustände sieht ein fehlgeschlagener Request wie eine eingefrorene Seite aus.

Fix: Fordere Lade‑Spinner, Empty‑States und sichtbare Fehlermeldungen für jede Seite.

5) Namen ändern sich mitten im Build

„Projects“ zu „Workspaces“ umzubenennen, bricht oft Routen, Handler und Tabellennamen.

Fix: Sperre ein Glossar früh. Wenn du umbenennst, fordere einen Umbenennungsplan (Search/Replace, Migration) statt das Modell improvisieren zu lassen.

Nutze diesen Reparatur‑Prompt, wenn etwas aus dem Ruder läuft:

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.

Wenn Inkonsistenzen immer wieder auftreten, fehlt wahrscheinlich eine „Single source of truth“-Aussage. Füge einen Satz hinzu: „Das Postgres‑Schema ist die Quelle der Wahrheit; UI und API müssen exakt dazu passen."

Schnelle Checkliste, bevor du es als fertig erklärst

Bevor du Zeit ins Polishing steckst, mache eine schnelle Prüfung, ob die App wie ein echtes Produkt funktioniert. Hier scheitern die meisten Full‑Stack CRUD Apps: winzige Abweichungen zwischen Screens, Regeln und Daten.

• Screens entsprechen der Entitätsspezifikation: Jede Seite (list, details, create, edit) verwendet genau die Entitätsnamen und die Feldliste, die du definiert hast.
• Rollen sind eindeutig: Schreibe eine einfache Allow/Deny‑Tabelle pro Rolle und bestätige, dass UI und API dieselben Regeln durchsetzen.
• API‑Antworten sind konsistent: Wähle ein Pattern (Statuscodes, Fehlerform, Pagination) und verifiziere, dass jeder Endpoint sich daran hält.
• DB‑Constraints stimmen mit Formularvalidierung überein: Wenn die DB unique email oder non‑null name verlangt, validiere vor dem Absenden und zeige klare Meldungen, wenn die API ablehnt.
• Create/Edit/Delete übersteht ein Refresh: Erstelle, refresh, bestätige; editiere, refresh, bestätige; lösche, refresh, bestätige.

Ein konkreter Test: Logge dich als niedrigste Rolle ein und probiere eine Aktion, die geblockt sein sollte (z. B. löschen). Wenn sie gelingt, fixiere die Policy zuerst an einer Stelle (API) und passe dann die UI an.

Realistisches Beispiel: ein einfacher Inventory‑Tracker

Stell dir ein kleines IT‑Team vor, das Laptops, Monitore und Adapter an Mitarbeiter verleiht. Sie brauchen einen Ort, um zu sehen, was verfügbar ist, wer was hat und wann es zurückkommen muss. Das ist ein gutes Test‑Szenario, weil es Rollen, einige Screens und eine echte Datenbank erfordert.

Ausgefülltes Vorbereitungs‑Arbeitsblatt

Nutze das als exakte Eingabe für deinen Prep‑Schritt (kopiere es und passe Namen an):

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)

Reihenfolge beim Einfügen der Prompts

Füge Prompts in dieser Reihenfolge ein, damit die App konsistent bleibt:

1. Basis‑Prompt (globale Regeln, Tech‑Stack, Namenskonventionen, Fehlerbehandlung)
2. Screens und Navigation (Inventory, Requests, Loans, Admin Queue)
3. Auth und Rollen (admin, staff, viewer Berechtigungen)
4. PostgreSQL‑Schema und Seed‑Daten (items, loans, requests, users)
5. Go CRUD API (Endpunkte und Validierung, die zu den Regeln passen)

Ein gutes Ergebnis sieht so aus: Ein Mitarbeiter kann „MBP-014“ anfordern, ein Admin genehmigt die Anfrage mit einem Rückgabedatum, und die Inventarliste zeigt das Gerät als nicht verfügbar mit dem Namen des Ausleihenden.

Wenn der Build nah an der Lösung ist, aber nicht richtig, ändere jeweils nur eine Sache: engere Rollenberechtigungen (viewer darf niemals Edit‑Buttons sehen), die Regel „nur ein aktiver Loan pro Item“ präzisieren, oder bitte um Umbenennung von Feldern, sodass UI‑Labels und DB‑Spalten exakt übereinstimmen.

Nächste Schritte: sicher erweitern und das Prompt‑Set wiederverwenden

Wenn die Basics funktionieren, behandle Änderungen wie kleine Releases. Wähle ein Feature, definiere, was „done“ bedeutet, und prompt dafür.

Sinnvolle Reihenfolge für viele Apps:

• Audit Log: protokolliere, wer was wann geändert hat (create, update, delete) und zeige es auf einer Admin‑Seite.
• Datei‑Uploads: hänge Dokumente oder Bilder an einen Datensatz an, speichere Metadaten in Postgres und halte den Zugriff hinter Auth.
• Einfache Benachrichtigungen: zeige In‑App Alerts (z. B. „low stock“ oder „new comment“) mit einer Aktion „als gelesen markieren“.

Wenn eine Änderung den Build bricht, rolle zurück und trage die Änderung erneut in einem kleineren, spezifischeren Prompt ein. Bei Koder.ai sind Snapshots und Rollback ein praktisches Sicherheitsnetz, besonders vor Änderungen an DB‑Schema, Auth‑Regeln oder gemeinsamen UI‑Komponenten.

Der Planning Mode hilft, wenn ein Feature mehrere Schichten berührt. Bitte das Modell zuerst, den Plan (Screens, API‑Endpoints, DB‑Änderungen, Rollen) erneut zu formulieren, und genehmige den Plan, bevor Code erzeugt wird. So vermeidest du das häufige Problem, dass die UI Felder erwartet, die die API nicht liefert, oder die API in Spalten schreibt, die nicht existieren.

Wenn du außerhalb der Plattform weiterarbeiten willst, exportiere den Source‑Code und setze Änderungen in deinem gewohnten Workflow fort. Bewahre das Prompt‑Set neben dem Repo als „Build‑Anleitung“, damit du die App später reproduzieren oder jemanden einarbeiten kannst.

Wenn du auf Koder.ai (Koder.ai) baust, passt dieses Prompt‑Set gut zu den React+Go+PostgreSQL‑Defaults der Plattform, und es ist einfach, mit Snapshots sicher zu iterieren, während du Anforderungen verfeinerst.

Abschließend: Speichere ein wiederverwendbares Template‑Prompt für dein nächstes Projekt. Behalte die stabilen Teile (Stack, CRUD‑Regeln, Auth‑/Rollen‑Konventionen, Postgres‑Muster) und tausche nur die Domain‑Nomen aus. Mit der Zeit werden deine Prompts ein reproduzierbares Rezept statt eines einmaligen Experiments.