Usa prompts Vibe para crear una app CRUD: genera pantallas, auth, roles y una API respaldada por Postgres. Con conjuntos listos para copiar/pegar y consejos de solución de problemas.

Este conjunto de prompts está diseñado para generar una app CRUD completa y funcional: las pantallas que usa la gente, la API que maneja las peticiones y la base de datos PostgreSQL que almacena los datos. También incluye login y acceso basado en roles, para que distintos usuarios puedan ver y hacer cosas diferentes.
CRUD son solo cuatro acciones cotidianas que tu app necesita:
En el front-end, deberías acabar con un conjunto predecible de pantallas: una página de lista, una página de detalle, un formulario de creación, un formulario de edición, además de una página de login y navegación básica. En el back-end, tendrás endpoints que coinciden con esas pantallas (list, get by id, create, update, delete), respaldados por una tabla Postgres y validaciones simples.
La calidad del prompt importa más que la elección del modelo. El modelo solo puede seguir lo que especifiques. Si tu prompt es vago, obtendrás nombres de campos que no coinciden, rutas faltantes, auth incompleta o una UI que no encaja con la API. Un prompt ajustado actúa como un contrato: UI, API y base de datos acuerdan los mismos nombres y reglas.
Antes de empezar, decide algunos detalles para que la construcción sea consistente:
Si usas Koder.ai, esto puede ser una sola conversación que produce una UI en React, una API en Go y un esquema PostgreSQL que encajen sin pegamentos manuales.
Un buen build CRUD comienza con un pequeño conjunto de decisiones. Escríbelas primero y tus prompts se mantienen claros, tus pantallas se ven bien y tu API coincide con la base de datos.
Empieza con una entidad central. Esto es la “cosa” que tu app gestiona a diario (Item, Customer, Appointment). Añade una segunda entidad solo si realmente es necesaria el primer día (por ejemplo, Item necesita Category). Si empiezas con tres o cuatro, pasarás la mayor parte del tiempo desenredando relaciones en lugar de obtener una app funcional.
Escribe los campos de tu entidad con un tipo y un ejemplo. El ejemplo importa porque guía etiquetas, formato y validación.
A continuación, lista roles y permisos en lenguaje simple. Manténlo específico. Para muchas apps, 2 a 3 roles son suficientes:
Finalmente, crea de 5 a 10 registros de ejemplo. Estos impulsan etiquetas realistas en la UI, opciones de dropdown y valores por defecto sensatos. Ejemplo (inventario): “Hand soap, qty 6, reorder_date 2026-01-20, status low”.
Si construyes en Koder.ai, pega esta hoja en tu primer prompt para que la plataforma pueda mantener la app consistente entre pantallas, auth y la API respaldada por PostgreSQL.
Empieza con un prompt de “reglas del camino”. Mantiene la construcción consistente entre pantallas, API y base de datos, y reduce el ida y vuelta cuando añades funciones después.
Pide un plan corto antes de cualquier código. Quieres que el modelo nombre pantallas y rutas, tablas y endpoints de API. También exige que explique las suposiciones desde el inicio (por ejemplo, qué roles existen) y que mantenga esas suposiciones sin cambios a menos que apruebes una modificación.
Aquí tienes un prompt base para copiar/pegar:
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.
Un ejemplo concreto: si el plan elige role: admin|member, no debería luego inventar manager para resolver un caso borde de la UI. Este prompt obliga a pausar y pedir tu aprobación en lugar de desviarse.
Las buenas pantallas nacen de un mapa de páginas claro primero. Usa los prompts abajo antes de pedir código de base de datos o API. Esto mantiene las rutas y nombres de UI estables después, que es donde muchos builds se descarrilan.
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.
Después de que responda, bloquea los nombres. Si cambias nombres de rutas más tarde, la API y las pruebas se desalinearán.
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.
Si la UI que vuelve es demasiado compleja, pídele que mantenga solo un layout, un estilo de tabla y un patrón de formulario en todas las páginas.
Si quieres resultados predecibles, sé explícito sobre cómo inician sesión los usuarios, cuánto duran las sesiones y qué puede hacer cada rol. Estos prompts asumen un login simple por email + password y un enfoque basado en sesión (fácil de probar en pantallas y APIs).
Pega esto primero para generar login, logout y manejo de sesión:
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.
Ahora agrega roles y reglas de protección. Mantén los permisos pequeños y fáciles de probar:
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.
Comprobaciones manuales rápidas que detectan la mayoría de errores:
Si construyes en Koder.ai, mantén auth y cambios RBAC en un solo snapshot para poder revertir limpiamente si los permisos se enredan.
Un buen prompt de esquema hace dos cosas: fuerza relaciones de tablas claras (para que UI y API sigan consistentes) y evita bases de datos “casi correctas” (sin índices, timestamps o mapeo de roles).
Antes de pegar, decide estos dos toggles (una línea cada uno):
uuid o bigserialyes (usar deleted_at) o no (hard delete)Pega este primer prompt para bloquear el modelo de datos:
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.
Luego pega este prompt para generar migraciones o pasos de setup que coincidan con el proyecto:
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
Si algo queda ambiguo, añade una línea más: “Ask me up to 5 questions if any relationship or field is unclear before writing SQL.”
Si tus outputs de backend siguen llegando a medias, este prompt fuerza lo básico: rutas claras, validación, paginación y checks de roles en cada handler.
Copia/pega esto tal cual, luego reemplaza los placeholders (RESOURCE, FIELDS, ROLES) con los detalles de tu app.
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
Tras la generación, haz una pasada rápida por consistencia: los códigos de estado coinciden con el cuerpo de error, el endpoint de lista devuelve un orden estable y cada handler verifica tanto rol como pertenencia al tenant antes de tocar la BD.
Si usas Koder.ai, además indica que el backend debe seguir en Go y la BD en PostgreSQL para que el código exportado coincida con el stack esperado.
Genera todo (UI, API, base de datos) y luego cambia a modo verificación estricto. El objetivo no es admirar pantallas, sino probar que el ciclo completo funciona: UI - auth - roles - Postgres - API - UI.
Ejecuta la app y carga la pantalla de inicio. Confirma que la navegación funciona y que no ves datos de placeholder. Si la página está en blanco, anota el primer mensaje de error visible (toast UI, consola o log del servidor).
Crea una cuenta de prueba por rol (Admin, Manager, Viewer). Inicia sesión y cierra sesión con cada usuario. Confirma que la app muestra el rol en algún lugar visible (menú de perfil, ajustes o una pequeña insignia).
Elige una pantalla CRUD y realiza un ciclo completo: crea un registro, refresca la página, luego edítalo y elimínalo. La verificación clave es la persistencia: después del refresh, el registro debe reflejar lo que hay en Postgres, no solo en memoria.
Intenta acciones prohibidas a propósito. Inicia sesión con el rol más bajo e intenta acceder a una pantalla solo de admin, invocar una acción restringida (como delete) o editar un registro que no deberías. Quieres resultados claros: o bien UI bloqueada con mensaje, o bien un error 403 sin cambios de datos.
Prueba casos límite: listas vacías, nombres muy largos, campos obligatorios faltantes y formatos inválidos (email, fechas). Confirma que la app muestra validaciones útiles y no se cae.
Si usas Koder.ai, toma un snapshot justo después del primer test CRUD end-to-end exitoso. Te da un punto de rollback seguro antes de empezar a añadir extras.
La mayoría de builds “rotos” no están realmente rotos. Les falta una restricción que mantenga UI, API y BD sincronizados.
Cuando pides pantallas, auth, roles, esquema y todos los casos borde de una vez, la app suele quedar inconsistente (rutas no coinciden, modelos cambian, páginas a medias).
Arreglo: divide por capa y obliga a la herramienta a re-ejecutar lo que va a generar antes de escribir código. En Koder.ai, esto también ayuda a alinear múltiples agentes.
Si solo dices “admin y user”, puede que obtengas una etiqueta de rol en la UI pero ninguna autorización en el servidor.
Arreglo: define permisos como acciones (create, read, update, delete) por recurso y exige aplicación server-side en cada endpoint.
Si describes campos en inglés plano (“price”, “date”, “status”), los formularios pueden renderizar inputs de texto mientras Postgres espera números, fechas o enums.
Arreglo: especifica tipos de campo, nullabilidad, valores por defecto y restricciones, y exige reglas de validación compartidas.
Sin estados de carga y error, una petición fallida parece una página congelada.
Arreglo: pide spinners de carga, estados vacíos y mensajes de error visibles para cada pantalla.
Renombrar “Projects” a “Workspaces” a mitad de camino suele romper rutas, handlers y nombres de tablas.
Arreglo: bloquea un glosario temprano. Cuando cambies nombres, solicita un plan de renombrado (search/replace, migrar) en vez de dejar que el modelo improvise.
Usa este prompt de reparación cuando algo se descarríe:
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.
Si sigues encontrando inconsistencias, probablemente te falta una “fuente única de la verdad”. Añade una frase: “The Postgres schema is the source of truth; UI and API must match it exactly.”
Antes de pulir, haz una pasada rápida para confirmar que la app se comporta como un producto real. Aquí fallan la mayoría de apps CRUD: pequeñas descoordinaciones entre pantallas, reglas y datos.
Una prueba concreta: inicia sesión con el rol con menos permisos e intenta una acción que esperas bloqueada (por ejemplo eliminar). Si tiene éxito, arregla la política en un lugar (la API) primero y luego ajusta la UI para que coincida.
Imagina un pequeño equipo de TI que presta laptops, monitores y adaptadores al personal. Necesitan un lugar para ver qué está disponible, quién tiene qué y cuándo debe devolverse. Es un buen caso de prueba porque fuerza roles, unas pocas pantallas y una base de datos real.
Usa esto como entrada exacta para tu paso de prep (cópialo tal cual y ajusta nombres):
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)
Pega tus prompts en este orden para que la app se mantenga consistente:
Un buen resultado se ve así: staff puede solicitar “MBP-014”, el admin lo aprueba con una fecha de retorno y la lista de inventario lo muestra como no disponible con el nombre del prestatario.
Si el build está cerca pero no correcto, ajusta una cosa a la vez: endurece permisos de roles (viewer nunca debería ver botones de edición), reafirma la regla “solo un préstamo activo por item”, o pide renombrar campos para que etiquetas UI y columnas BD coincidan exactamente.
Cuando lo básico funcione, trata los siguientes cambios como pequeñas releases. Elige una función, define qué significa “hecho” y luego pídela.
Un orden sensato para muchas apps:
Cuando un cambio rompe el build, no intentes arreglar todo a la vez. Hace rollback y reaplica el cambio con un prompt más pequeño y específico. Si usas Koder.ai, los snapshots y rollback son una red de seguridad práctica, sobre todo antes de cambios que toquen el esquema BD, reglas de auth o componentes compartidos.
El modo Planning también ayuda cuando una característica abarca múltiples capas. Pídele que replantee el plan primero (pantallas, endpoints API, cambios en BD, roles), y aprueba ese plan antes de generar código. Esto evita el desajuste común donde la UI espera campos que la API no devuelve, o la API escribe en columnas que no existen.
Si quieres continuar fuera de la plataforma, exporta el código fuente y haz cambios en tu flujo habitual. Conserva el set de prompts junto al repo como “instrucciones de construcción” para recrear la app más tarde o para incorporar a alguien nuevo.
Si construyes en Koder.ai (koder.ai), este set de prompts encaja bien con los defaults React + Go + PostgreSQL de la plataforma y es fácil iterar con seguridad usando snapshots mientras afinás requisitos.
Finalmente, guarda un prompt plantilla reutilizable para tu próximo proyecto. Mantén las partes estables (stack, reglas CRUD, convenciones de auth y roles, patrones PostgreSQL) y cambia solo los sustantivos del dominio. Con el tiempo, tus prompts se convierten en una receta repetible en vez de un experimento puntual.
Comienza con la entidad principal y sus 6–12 campos (nombre, tipo, requerido/opcional, ejemplos). Luego bloquea roles + permisos en lenguaje claro y pide un plan corto antes de escribir código.
Un buen orden por defecto es generar en este orden:
Porque obliga al modelo a tratar la UI, la API y la base de datos como un contrato único. Los prompts vagos suelen causar desvíos:
Un prompt preciso hace que nombres, reglas y validaciones coincidan en todas las capas.
Elige una entidad central que gestionarás todos los días (Customer, Task, Item). Manténlo en una entidad el primer día salvo que una segunda sea realmente necesaria para el flujo.
Un valor práctico por defecto:
Porque los ejemplos guían etiquetas, formato y validación. Si solo dices “date” o “status”, a menudo obtendrás inputs de texto en la UI mientras Postgres espera números, fechas o enums.
Usa este formato consistente para campos:
field_name: type - example (rules)Esto ayuda a que el formulario React, la validación en Go y las restricciones en PostgreSQL estén alineadas.
Usa 2–3 roles como máximo, mapeados a los verbos CRUD list, view, create, update, delete.
Un predeterminado sólido:
Y exige que se aplique en partes: rutas de UI y endpoints de API.
Implementa y prueba ambos:
401 cuando no hay auth, 403 cuando el usuario no tiene permisosUna regla práctica: si la UI bloquea una acción, la API debe rechazarla si se llama directamente.
Usa email + password con persistencia de sesión a través del refresh.
Requisitos mínimos a pedir:
POST /auth/login, POST /auth/logout, GET /auth/meAgrega un usuario admin seed para pruebas locales.
Elige una convención y aplícala en todas partes:
Si renombras algo después, pide un plan de renombrado (search/replace + migraciones) en lugar de permitir improvisaciones del modelo.
Pide que cada endpoint de lista devuelva la misma forma:
page, page_size, más tus filtrostotal, page, page_size, itemsUsa un prompt de auditoría que compare:
Luego aplica un plan de parche mínimo.
Una buena regla: no añadas características mientras arreglas inconsistencias — solo alinea nombres, rutas, validaciones y permisos.
También exige orden estable (por ejemplo created_at luego id) para que la paginación no salte ni duplique elementos.