Gunakan prompt Vibe untuk aplikasi CRUD agar menghasilkan layar, auth, peran, dan API PostgreSQL yang cocok. Set prompt salin-tempel plus tips pemecahan masalah.
Set prompt ini dirancang untuk menghasilkan aplikasi CRUD lengkap yang bekerja: layar yang dipakai orang, API yang menangani permintaan, dan database PostgreSQL yang menyimpan datanya. Ini juga termasuk login dan akses berbasis peran, sehingga pengguna berbeda bisa melihat dan melakukan hal berbeda.
CRUD hanyalah empat aksi sehari-hari yang dibutuhkan aplikasi Anda:
Di front end, Anda seharusnya mendapat set layar yang dapat diprediksi: halaman daftar, halaman detail, form buat, form edit, plus halaman login dan navigasi dasar. Di back end, Anda akan punya endpoint yang cocok dengan layar tersebut (list, get by id, create, update, delete), didukung oleh tabel Postgres dan validasi sederhana.
Kualitas prompt lebih penting daripada pilihan model. Model hanya bisa mengikuti apa yang Anda spesifikasikan. Jika prompt Anda kabur, Anda akan mendapatkan nama field yang tidak cocok, route yang hilang, auth yang tidak lengkap, atau UI yang tidak selaras dengan API. Prompt yang ketat bertindak seperti kontrak: UI, API, dan database semua setuju pada nama dan aturan yang sama.
Sebelum mulai, tentukan beberapa detail agar build tetap konsisten:
Jika Anda menggunakan Koder.ai, ini bisa menjadi satu percakapan yang menghasilkan UI React, API Go, dan skema PostgreSQL yang cocok bersama tanpa perlu glue manual.
Build CRUD yang baik dimulai dengan serangkaian keputusan kecil. Tulis dulu dan prompt Anda akan lebih jelas, layar terlihat benar, dan API cocok dengan database.
Mulai dengan satu entitas inti. Ini adalah “benda” yang dikelola aplikasi Anda setiap hari (Item, Customer, Appointment). Tambah entitas kedua hanya jika benar-benar diperlukan di hari pertama (mis. Item butuh Category). Jika Anda mulai dengan tiga atau empat, Anda akan menghabiskan sebagian besar waktu merapikan relasi daripada mendapatkan aplikasi yang berfungsi.
Tulis field entitas Anda dengan tipe dan contoh. Contoh itu penting karena memandu label, format, dan validasi.
Selanjutnya, daftarkan peran dan izin dalam bahasa biasa. Jaga agar spesifik. Untuk banyak aplikasi, 2–3 peran sudah cukup:
Terakhir, buat 5–10 record sampel. Ini menghasilkan label UI yang realistis, opsi dropdown, dan default yang masuk akal. Contoh (inventory): “Hand soap, qty 6, reorder_date 2026-01-20, status low”.
Jika Anda membangun di Koder.ai, paste lembar kerja ini ke prompt pertama Anda sehingga platform bisa menjaga konsistensi aplikasi di layar, auth, dan API yang didukung PostgreSQL.
Mulailah dengan satu prompt "aturan jalan". Ini menjaga build konsisten di layar, API, dan database, serta mengurangi bolak-balik saat Anda menambahkan fitur nanti.
Minta rencana singkat sebelum kode apa pun. Anda ingin model menamai layar dan rute, tabel, dan endpoint API. Juga minta model menyatakan asumsi di awal (mis. peran apa yang ada) dan mempertahankan asumsi tersebut kecuali Anda menyetujui perubahan.
Berikut prompt base yang bisa di-copy-paste:
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.
Contoh konkret: jika rencana memilih role: admin|member, itu tidak boleh kemudian mengarang manager untuk menyelesaikan kasus edge UI. Prompt ini memaksa model berhenti dan meminta persetujuan Anda alih-alih mengubah asumsi secara diam-diam.
Layar yang baik berasal dari peta halaman yang jelas terlebih dulu. Gunakan prompt di bawah sebelum meminta kode database atau API. Ini menjaga rute dan nama UI stabil, yang sering menjadi sumber masalah.
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.
Setelah jawabannya kembali, kunci nama-nama tersebut. Jika Anda mengubah nama rute nanti, API dan test akan meleset.
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.
Jika UI terlalu kompleks, minta agar hanya satu layout, satu gaya tabel, dan satu pola form dipakai di seluruh halaman.
Untuk hasil yang dapat diprediksi, jelaskan secara eksplisit bagaimana pengguna login, berapa lama sesi bertahan, dan apa yang boleh dilakukan tiap peran. Prompt ini mengasumsikan login sederhana email + password dan pendekatan berbasis sesi (mudah diuji di seluruh layar dan API).
Tempelkan ini pertama untuk menghasilkan login, logout, dan penanganan sesi:
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.
Sekarang tambahkan peran dan aturan proteksi. Jaga izin kecil dan mudah diuji:
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.
Pemeriksaan manual cepat yang menangkap sebagian besar kesalahan:
Jika Anda membangun di Koder.ai, jaga perubahan auth dan RBAC dalam satu snapshot sehingga Anda bisa rollback dengan bersih jika izin menjadi berantakan.
Prompt skema yang baik melakukan dua hal: memaksa relasi tabel yang jelas (supaya layar dan API tetap konsisten), dan mencegah database yang “hampir benar” (kekurangan index, timestamps, atau pemetaan peran).
Sebelum menempel, tentukan dua toggle ini (satu baris tiap toggle):
uuid or bigserialyes (use deleted_at) or no (hard delete)Tempelkan prompt ini dulu untuk mengunci model data:
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.
Lalu tempelkan prompt ini untuk menghasilkan migration atau langkah setup yang cocok dengan proyek:
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
Jika ada yang ambigu, tambahkan satu baris: “Ask me up to 5 questions if any relationship or field is unclear before writing SQL.”
Jika keluaran backend terus setengah selesai, prompt ini memaksa dasar-dasarnya: rute yang jelas, validasi, paginasi, dan pengecekan peran pada setiap handler.
Salin-tempel ini apa adanya, lalu ganti placeholder (RESOURCE, FIELDS, ROLES) dengan detail aplikasi Anda.
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
Setelah generasi, lakukan satu pengecekan cepat untuk konsistensi: kode status cocok dengan body error, endpoint list mengembalikan ordering stabil, dan tiap handler memeriksa peran serta kepemilikan tenant sebelum menyentuh database.
Jika Anda menggunakan Koder.ai, juga catat bahwa backend harus tetap di Go dan database tetap PostgreSQL agar kode yang diekspor cocok dengan stack yang diharapkan.
Hasilkan semuanya (UI, API, database), lalu beralih ke mode verifikasi ketat. Tujuannya bukan mengagumi layar—melainkan membuktikan loop penuh bekerja: UI - auth - roles - Postgres - API - UI.
Jalankan app dan buka layar home. Konfirmasi navigasi bekerja dan Anda tidak melihat data placeholder. Jika halaman kosong, catat pesan error pertama yang terlihat (toast UI, console, atau log server).
Buat satu akun test per peran (Admin, Manager, Viewer). Login dan logout dengan tiap user. Konfirmasi aplikasi menampilkan peran di tempat yang terlihat (menu profil, settings, atau badge kecil).
Pilih satu layar CRUD dan lakukan siklus penuh: buat record, refresh halaman, lalu edit dan delete. Cek utama adalah persistensi: setelah refresh, record harus mencerminkan apa yang ada di Postgres, bukan hanya di memori.
Coba aksi terlarang dengan sengaja. Login sebagai peran terendah dan coba akses layar admin, panggil aksi terbatas (mis. delete), dan edit record yang seharusnya tidak bisa Anda ubah. Anda ingin hasil yang jelas: UI diblokir dengan pesan, atau error 403 tanpa perubahan data.
Uji kasus tepi dasar: list kosong, nama sangat panjang, field wajib hilang, dan format invalid (email, tanggal). Konfirmasi aplikasi menampilkan validasi yang membantu dan tidak crash.
Jika Anda menggunakan Koder.ai, ambil snapshot segera setelah tes end-to-end CRUD pertama sukses. Ini memberi titik rollback aman sebelum menambah fitur.
Kebanyakan build yang “rusak” sebenarnya bukan rusak. Mereka hanya kekurangan satu constraint yang menjaga UI, API, dan database konsisten.
Saat Anda meminta layar, auth, roles, skema, dan semua edge case sekaligus, aplikasi sering menjadi tidak konsisten (rute tidak cocok, model melenceng, halaman setengah jadi).
Perbaikan: pisahkan berdasarkan lapisan dan paksa tool untuk mengulang apa yang akan dihasilkannya sebelum menulis kode. Di Koder.ai, ini juga membantu menyelaraskan beberapa agen.
Jika Anda hanya menulis “admin dan user”, Anda mungkin mendapat label peran di UI tapi tidak ada otorisasi sisi server.
Perbaikan: definisikan izin sebagai aksi (create, read, update, delete) per resource, dan minta penegakan di server-side pada setiap endpoint.
Jika Anda menggambarkan field secara sederhana (“price”, “date”, “status”), form mungkin merender input teks sementara Postgres mengharapkan angka, tanggal, atau enum.
Perbaikan: spesifikasikan tipe field, nullability, default, dan constraints, serta minta aturan validasi yang dibagi bersama.
Tanpa loading dan error state, permintaan yang gagal terlihat seperti halaman membeku.
Perbaikan: minta spinner loading, empty state, dan pesan error yang terlihat untuk tiap layar.
Mengganti “Projects” menjadi “Workspaces” setengah jalan sering memecah rute, handler, dan nama tabel.
Perbaikan: kunci kamus istilah di awal. Saat mengubah nama, minta rencana rename (search, replace, migrate) daripada membiarkan model mengimprovisasi.
Gunakan prompt perbaikan ini saat sesuatu melenceng:
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.
Jika inkonsistensi terus muncul, Anda mungkin kekurangan pernyataan "single source of truth". Tambahkan satu kalimat: “The Postgres schema is the source of truth; UI and API must match it exactly.”
Sebelum Anda menghabiskan waktu memoles, lakukan pengecekan cepat untuk memastikan aplikasi berperilaku seperti produk nyata. Di sinilah sebagian besar aplikasi CRUD gagal: mismatch kecil antara layar, aturan, dan data.
Tes konkret: login sebagai peran dengan permission terendah dan coba aksi yang Anda harapkan diblokir (mis. delete). Jika berhasil, perbaiki policy di satu tempat (API) terlebih dahulu, lalu sesuaikan UI.
Bayangkan tim IT kecil yang meminjamkan laptop, monitor, dan adaptor ke staf. Mereka butuh satu tempat untuk melihat ketersediaan, siapa memegang apa, dan kapan harus dikembalikan. Ini kasus uji yang baik karena memaksa peran, beberapa layar, dan database nyata.
Gunakan ini sebagai input persiapan Anda (salin apa adanya, lalu sesuaikan nama):
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)
Tempel prompt Anda dalam urutan ini agar aplikasi tetap konsisten:
Hasil yang baik terlihat seperti ini: staff dapat request “MBP-014”, admin bisa menyetujui dengan due date, dan daftar inventori menampilkan item tersebut sebagai tidak tersedia dengan nama peminjam.
Jika build hampir benar tapi tidak pas, ubah satu hal saja: perketat permission (viewer tidak boleh lihat tombol edit), ulangi aturan "hanya satu active loan per item", atau minta rename field sehingga label UI dan kolom DB cocok.
Setelah dasar bekerja, perlakukan perubahan berikutnya seperti rilis kecil. Pilih satu fitur, tentukan apa arti “done”, lalu prompt untuk itu.
Urutan yang masuk akal untuk banyak aplikasi:
Saat perubahan merusak build, jangan mencoba memperbaiki semuanya sekaligus. Roll back, lalu terapkan perubahan dalam prompt yang lebih kecil dan spesifik. Jika Anda menggunakan Koder.ai, snapshot dan rollback adalah jaring pengaman praktis, terutama sebelum perubahan yang mempengaruhi skema DB, aturan auth, atau komponen UI bersama.
Mode Perencanaan juga membantu ketika fitur menyentuh banyak lapisan. Minta model menyatakan rencana dulu (layar, endpoint API, perubahan DB, peran), lalu setujui rencana itu sebelum menghasilkan kode. Ini mencegah mismatch umum di mana UI mengharapkan field yang tidak dikembalikan API, atau API menulis ke kolom yang tidak ada.
Jika Anda ingin melanjutkan di luar platform, ekspor source code dan lanjutkan di alur kerja biasa. Simpan set prompt bersama repo sebagai "instruksi build" sehingga Anda bisa mereplikasi aplikasi nanti atau mempercepat onboarding orang baru.
Jika Anda membangun di Koder.ai (koder.ai), set prompt ini selaras dengan default React + Go + PostgreSQL platform dan mudah diiterasi dengan snapshot sambil menyempurnakan kebutuhan.
Akhirnya, simpan template prompt yang dapat dipakai ulang untuk proyek berikutnya. Pertahankan bagian stabil (stack, aturan CRUD, konvensi auth dan peran, pola Postgres) dan ganti hanya noun domain. Seiring waktu, prompt Anda menjadi resep yang bisa diulang, bukan percobaan satu kali.
Mulailah dengan entitas inti dan 6–12 field (nama, tipe, wajib/opsional, contoh). Kemudian kunci peran + izin dalam bahasa yang jelas, dan minta rencana singkat sebelum kode apa pun.
Default yang baik adalah menghasilkan dalam urutan ini:
Karena itu memaksa model memperlakukan UI, API, dan database sebagai satu kontrak. Prompt yang kabur biasanya menyebabkan drift:
Prompt yang ketat membuat nama, aturan, dan validasi sesuai di semua lapisan.
Pilih entitas inti yang akan Anda kelola setiap hari (Customer, Task, Item). Batasi ke satu entitas di hari pertama kecuali entitas kedua benar-benar diperlukan.
Default praktis:
Karena contoh memandu label, format, dan validasi. Jika Anda hanya menyebut “date” atau “status”, seringkali Anda akan mendapat input teks di UI sementara Postgres mengharapkan date/enum.
Gunakan format baris field yang konsisten:
field_name: type - example (rules)Ini membantu form React, validasi Go, dan constraint PostgreSQL tetap selaras.
Gunakan 2–3 peran maksimum, dipetakan ke kata kerja CRUD list, view, create, update, delete.
Default solid:
Lalu minta penegakan di UI dan API.
Implementasikan dan uji keduanya:
401 ketika tidak terautentikasi, 403 saat terautentikasi tapi tidak berizinAturan praktis: jika UI memblokir aksi, API tetap harus menolaknya jika dipanggil langsung.
Default ke email + password dengan sesi yang bertahan di refresh.
Persyaratan minimum yang diminta:
POST /auth/login, POST /auth/logout, GET /auth/meSeed satu user admin untuk testing lokal.
Pilih satu konvensi dan tegakkan di mana-mana:
Jika Anda mengganti nama nanti, minta rencana rename (search/replace + migrasi) daripada membiarkan model mengimprovisasi.
Minta model mengembalikan bentuk yang sama dari setiap endpoint list:
page, page_size, plus filter Andatotal, page, page_size, itemsJuga minta sorting yang stabil (mis. created_at lalu id) agar paginasi tidak melewatkan atau menduplikasi item.
Gunakan prompt audit yang membandingkan:
Lalu terapkan rencana patch minimal.
Aturan bagus: jangan menambah fitur saat memperbaiki mismatch—hanya selaraskan nama, rute, validasi, dan izin.