CRUD uygulaması için Vibe coding prompt’ları: tam yığın kopyala-yapıştır set

Bu prompt setinin inşa ettiği şey (düz İngilizce)

Bu prompt seti, eksiksiz çalışan bir CRUD uygulaması üretmek için tasarlandı: kullanıcıların kullandığı ekranlar, istekleri işleyen API ve verileri saklayan PostgreSQL veritabanı. Ayrıca giriş ve rol tabanlı erişim de içerir; böylece farklı kullanıcılar farklı şeyleri görüp yapabilir.

CRUD, uygulamanızın ihtiyaç duyduğu dört temel eylemdir:

• Create: yeni bir kayıt eklemek (örneğin bir müşteri veya görev)
• Read: bir listeyi görüntülemek ve tek bir öğeyi açmak
• Update: var olan bir öğeyi düzenlemek
• Delete: bir öğeyi silmek (genellikle onay adımı ile)

Ön uçta, sona doğru tahmin edilebilir bir ekran seti elde etmelisiniz: bir liste sayfası, bir detay sayfası, bir oluşturma formu, bir düzenleme formu, ayrıca bir giriş sayfası ve temel gezinme. Arka uçta ise bu ekranlarla eşleşen endpoint’ler (liste, id ile get, oluştur, güncelle, sil) olacak; bunların arkasında bir Postgres tablosu ve basit doğrulamalar bulunacak.

Prompt kalitesi, model seçiminden daha önemlidir. Model sadece belirttiğiniz kuralları izleyebilir. Eğer prompt belirsizse, alan adları uyuşmaz, route’lar eksik kalır, auth tamamlanmamış olur veya UI API ile uyumsuz olur. Sıkı bir prompt bir sözleşme gibidir: UI, API ve veritabanı aynı adlar ve kurallar üzerinde anlaşır.

Başlamadan önce, derlemenin tutarlı kalması için birkaç detayı belirleyin:

• Ana varlığınız ve 6 ila 12 alan (isimler, tipler, gerekli mi isteğe bağlı mı)
• Roller (örnek: admin, manager, viewer) ve her rolün neler yapabildiği
• Temel kurallar (kim düzenleyebilir, soft delete mi hard delete mi, gerekli alanlar)
• Birinci günde gerekli "mutlu yol" (happy path) ekranları
• Herhangi bir kısıtlama (unique alanlar, tarih aralıkları, durum değerleri)

Eğer Koder.ai kullanıyorsanız, bu tek bir konuşma olabilir ve React UI, Go API ve PostgreSQL şeması birbirine manuel yapıştırma gerektirmeden eşleşir.

Hazırlık çalışma sayfası: Prompt öncesi gereken birkaç detay

İyi bir CRUD yapısı, küçük bir karar setiyle başlar. Bunları önce yazın; prompt’larınız net kalsın, ekranlar doğru görünsün ve API veritabanıyla uyuşsun.

Bir ana varlıkla başlayın. Bu, uygulamanızın her gün yönettiği “şey”dir (Item, Customer, Appointment). İkinci bir varlığı yalnızca ilk gün gerçekten gerekiyorsa ekleyin (örneğin Item’in Category’ye ihtiyacı varsa). Üç veya dört ile başlarsanız, çalışan bir uygulama elde etmek yerine ilişkileri çözmekle zaman harcarsınız.

Varlık alanlarınızı tip ve örnekle yazın. Örnek önemlidir çünkü etiketleri, formatlamayı ve doğrulamayı yönlendirir.

• Field: type - example (notlar)
• name: text - "Paper towels" (gerekli, 2-80 karakter)
• quantity: number - 24 (min 0)
• reorder_date: date - 2026-02-01 (isteğe bağlı)
• status: enum - "in_stock" | "low" | "out" (varsayılan in_stock)

Sonra roller ve izinleri düz metin halinde listeleyin. Spesifik tutun. Birçok uygulama için 2–3 rol yeterlidir:

• Admin: kullanıcıları yönetir, tüm kayıtlar üzerinde tam CRUD
• Manager: kayıtlar üzerinde CRUD, kullanıcı yönetemez
• Viewer: sadece görüntüleme

Son olarak 5–10 örnek kayıt oluşturun. Bunlar gerçekçi UI etiketlerini, açılır seçenekleri ve makul varsayılanları sağlar. Örnek (envanter): “Hand soap, qty 6, reorder_date 2026-01-20, status low”.

Eğer Koder.ai’de inşa ediyorsanız, bu çalışma sayfasını ilk prompt’unuza yapıştırın ki platform ekranlar, auth ve PostgreSQL destekli API arasında uygulamayı tutarlı tutabilsin.

Temel prompt: tüm yapının kurallarını belirleyin

Tüm yapıyı tutarlı kılmak için bir “yol kuralları” prompt’u ile başlayın. Bu, ekranlar, API ve veritabanı arasında tutarlılık sağlar ve daha sonra özellik eklerken gereksiz geri dönüşleri azaltır.

Herhangi bir kod yazmadan önce kısa bir plan isteyin. Modelden ekranları ve route’ları, tabloları ve API endpoint’lerini adlandırmasını isteyin. Ayrıca varsayımları (örneğin hangi rollerin olduğu) baştan belirtmesini ve bu varsayımları sizin onayınız olmadan değiştirmemesini talep edin.

Aşağıda kopyala-yapıştır için temel prompt var:

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.

Bir örnek: eğer plan role: admin|member seçerse, sonrasında manager gibi yeni bir rol icat etmemelidir. Bu prompt, değişiklik gerektirdiğinde modelin durup onay istemesini sağlar.

Kopyala-yapıştır promptlar: ekranlar ve gezinme

İyi ekranlar önce net bir sayfa haritasından çıkar. Aşağıdaki promptları veritabanı veya API kodunu istemeden önce kullanın. Bu, route’ları ve UI adlarını daha sonra sabit tutar; çoğu yapı buradan sapar.

Prompt 1: sayfa listesi ve kullanıcı akışları

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.

Cevap geldikten sonra isimleri kilitleyin. Sonradan route isimlerini değiştirirseniz API ve testler sapar.

Prompt 2: gezinme ve iyi davranan formlar

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.

UI çok karmaşık gelirse, tek bir layout, tek bir tablo stili ve tüm sayfalarda tek bir form deseninde kalmasını isteyin.

Kopyala-yapıştır promptlar: kimlik doğrulama ve roller

Tahmin edilebilir sonuçlar istiyorsanız, kullanıcıların nasıl giriş yaptığı, oturumların ne kadar sürdüğü ve her rolün ne yapabildiği konusunda açık olun. Bu promptlar basit e-posta + parola girişi ve oturum tabanlı bir yaklaşıma dayanır (ekranlar ve API'ler arasındaki testleri kolaylaştırır).

İlk olarak oturum açma, çıkış ve oturum yönetimini oluşturmak için şunu yapıştırı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.

Sonra roller ve koruma kurallarını ekleyin. İzinleri küçük ve test etmesi kolay tutun:

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.

Hızlı manuel kontroller:

• Her rol için giriş yapın ve nelerin görünüp görünmediğini doğrulayın.
• Kısıtlı bir eylemi (örneğin delete) yine de deneyin ve 403 aldığınızı doğrulayın.
• Çıkışın oturumu temizlediğini ve uygulamanın Login ekranına döndüğünü doğrulayın.

Eğer Koder.ai kullanıyorsanız, auth ve RBAC değişikliklerini tek bir snapshot’ta tutun ki izinler karışırsa geri alabilin.

Kopyala-yapıştır promptlar: PostgreSQL şeması ve veri modeli

İyi bir şema prompt’u iki işi yapar: tablolardaki ilişkileri netleştirir (böylece ekranlar ve API tutarlı kalır) ve "neredeyse doğru" veritabanlarını (eksik indexler, zaman damgaları veya rol eşlemesi) engeller.

Önce şu iki ayarı belirleyin (her biri tek satır):

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

Bu prompt’u yapıştırın ve veri modelini kilitleyin:

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.

Sonra projeyle eşleşen migration veya kurulum adımlarını üretmek için şunu yapıştırın:

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

Eğer bir belirsizlik varsa, bir satır daha ekleyin: “Ask me up to 5 questions if any relationship or field is unclear before writing SQL.”

Kopyala-yapıştır promptlar: Go CRUD API (Postgres destekli)

Eğer backend çıktılarınız hep yarım kalıyorsa, bu prompt temel gereksinimleri zorunlu kılar: net route’lar, doğrulama, sayfalama ve her handler’da rol kontrolleri.

Aşağıyı olduğu gibi kopyalayın, sonra placeholder’ları (RESOURCE, FIELDS, ROLES) uygulama detaylarınızla değiştirin.

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

Oluşturduktan sonra bir geçiş yapın: durum kodları hata gövdesiyle eşleşiyor mu, liste endpoint’i stabil sıralama döndürüyor mu ve her handler hem rolü hem tenant sahipliğini kontrol ediyor mu.

Koder.ai kullanıyorsanız, backend’in Go’da ve veritabanının PostgreSQL’de kalması gerektiğini ayrıca belirtin ki dışa aktarılan kod beklentiyle uyuşsun.

Adım adım: oluştur, çalıştır ve doğrula

Her şeyi (UI, API, veritabanı) oluşturun, sonra sıkı doğrulama moduna geçin. Amaç, tam döngünün çalıştığını kanıtlamaktır: UI - auth - roller - Postgres - API - UI.

Basit bir doğrulama çalıştırma

1. Uygulamayı çalıştırın ve ana ekranı yükleyin. Gezinmenin çalıştığını ve placeholder veri görmediğinizi doğrulayın. Eğer sayfa boşsa, ilk görünen hata mesajını not edin (UI toast, konsol veya sunucu logu).

2. Her rol için bir test hesabı oluşturun (Admin, Manager, Viewer). Her kullanıcıyla giriş yapın ve çıkış yapın. Uygulamanın rolu görünür bir yerde gösterdiğini doğrulayın (profil menüsü, ayarlar veya küçük bir rozet).

3. Bir CRUD ekranı seçin ve tam bir döngü yapın: bir kayıt oluşturun, sayfayı yenileyin, sonra düzenleyin ve silin. Ana kontrol, kalıcılıktır: yeniledikten sonra kayıt Postgres’tekiyle aynı olmalı, sadece bellektekiyle değil.

4. Kasıtlı olarak yasaklanmış eylemleri deneyin. En düşük rol ile admin-only bir ekrana erişmeye çalışın, kısıtlı bir eylem çağırın (örneğin delete) ve düzenleyemeyeceğiniz bir kaydı düzenlemeyi deneyin. Net sonuçlar isteyin: ya engellenmiş bir UI mesajı, ya da veri değişikliği olmadan 403 tipi bir hata.

5. Temel uç durumları test edin: boş listeler, çok uzun isimler, eksik gerekli alanlar ve geçersiz formatlar (email, tarihler). Uygulamanın yardımcı doğrulama gösterdiğini ve çökmediğini doğrulayın.

Eğer Koder.ai kullanıyorsanız, ilk başarılı uçtan uca CRUD testinden hemen sonra bir snapshot alın. Bu, DB şeması, auth kuralları veya paylaşılan UI bileşenlerine dokunan değişikliklerden önce güvenli bir geri alma noktası sağlar.

Yaygın prompt hataları ve nasıl düzeltileceği

Çoğu “bozuk” build aslında tamamen bozuk değildir. UI, API ve veri arasında tutarlılığı sağlayan bir kısıt eksiktir.

1) Çok fazla şeyi aynı anda istediniz

Ekranları, auth’u, rolleri, şemayı ve tüm uç durumları tek seferde istediğinizde, uygulama genellikle tutarsız olur (route’lar eşleşmez, modeller sapar, sayfalar yarım kalır).

Düzeltme: katmanlara göre ayırın ve araçtan kod yazmadan önce ne üreteceğini tekrar etmesini isteyin. Koder.ai’de bu ayrıca birden fazla ajanı hizalamaya yardımcı olur.

2) Roller belirsiz, bu yüzden kontroller eksik kalıyor

Eğer sadece “admin ve user” derseniz, UI’da bir rol etiketi görürsünüz ama sunucu tarafında yetkilendirme olmayabilir.

Düzeltme: izinleri kaynak başına eylem olarak tanımlayın (create, read, update, delete) ve her endpoint’te sunucu tarafı uygulamasını zorunlu kılın.

3) Alan tipleri eksik, UI ve DB sapıyor

Alanları sadece düz metinle tanımlarsanız (“price”, “date”, “status”), formlar metin alanı olarak gelirken Postgres sayı, tarih veya enum bekleyebilir.

Düzeltme: alan tiplerini, null olabilirliklerini, varsayılanları ve kısıtları belirtin ve ortak doğrulama kuralları isteyin.

4) Yükleniyor ve hata durumları yok, UI bozuk görünüyor

Yükleniyor ve hata durumları olmadan, başarısız istek donmuş sayfa gibi görünür.

Düzeltme: her ekran için yükleme spinnner’ı, boş durum ve görünen hata mesajı talep edin.

5) İsimler inşa sırasında değişiyor

“Projects”i ortada “Workspaces” olarak yeniden adlandırmak route’ları, handler’ları ve tablo isimlerini kırar.

Düzeltme: erken bir sözlük (glossary) kilitleyin. Yeniden adlandırırsanız, bir yeniden adlandırma planı isteyin (ara/değiştir + migrate) ve modelin doğaçlama yapmasına izin vermeyin.

Bir şeyler yanlış giderse bu onarım prompt’unu kullanın:

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.

Eğer tutarsızlıklar devam ediyorsa, büyük ihtimalle bir “tek gerçek kaynağı” (single source of truth) beyanı eksiktir. Bir satır ekleyin: “The Postgres schema is the source of truth; UI and API must match it exactly.”

Bitirmeden önce hızlı kontrol listesi

Parlatmaya vakit harcamadan önce hızlı bir geçişle uygulamanın gerçek bir ürün gibi davrandığını doğrulayın. Çoğu full-stack CRUD uygulaması burada küçük eşleşmezlikler yüzünden başarısız olur.

• Ekranlar varlık spesifikasyonuyla eşleşiyor: her ekran (liste, detay, oluştur, düzenle) tanımladığınız varlık isimlerini ve alan listesini kullanıyor.
• Roller net: her rol için basit bir izin tablosu yazın ve UI ile API’nin aynı kuralları uyguladığını doğrulayın.
• API cevapları tutarlı: bir kalıp seçin (status kodları, hata şekli, sayfalama şekli) ve her endpoint’in bunu takip ettiğini doğrulayın.
• Veritabanı kısıtları form doğrulamasıyla eşleşiyor: DB unique email veya non-null name istiyorsa, submit öncesi doğrulayın ve API reddettiğinde net bir mesaj gösterin.
• Oluştur/düzenle/sil yenileme sonrası kalıcı: bir kayıt oluşturun, yenileyin, hâlâ orada olduğunu doğrulayın; düzenleyin, yenileyin; silin, yenileyin ve silindiğini doğrulayın.

Somut bir test: en düşük izinli rolde giriş yapın ve engellenmesini beklediğiniz bir eylemi (örneğin silme) deneyin. Eğer başarılı olursa, önce API’de politikayı düzeltin, sonra UI’yi buna göre ayarlayın.

Gerçekçi örnek: basit bir envanter takipçisi

Küçük bir BT ekibi düşünün: personele dizüstü, monitör ve adaptör ödünç veriyorlar. Ne var ne yok, kimde ne var ve ne zaman geri gelecek görmek istiyorlar. Bu iyi bir test vakasıdır çünkü roller, birkaç ekran ve gerçek bir veritabanı gerektirir.

Doldurulmuş hazırlık çalışma sayfası

Hazırlık adımınız için bunu aynen kullanın (kopyala-yapıştır, sonra adları düzenleyin):

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)

Yapıştırma sırası

Prompt’larınızı bu sırayla yapıştırın ki uygulama tutarlı kalsın:

1. Base prompt (global rules, tech stack, naming, error handling)
2. Screens and navigation (Inventory, Requests, Loans, Admin queue)
3. Authentication and roles (admin, staff, viewer permissions)
4. PostgreSQL schema and seed data (items, loans, requests, users)
5. Go CRUD API (endpoints and validation that match the rules)

İyi bir sonuç şöyle görünür: staff “MBP-014” için istek yapar, admin onaylar ve bir due date kaydeder; envanter listesi öğeyi ödünçte olarak ve ödünç alan ismiyle gösterir.

Eğer build yakın ama tam değilse, her seferinde tek bir şeyi düzeltin: rol izinlerini sıkılaştırın (viewer hiçbir zaman düzenleme düğmesi görmemeli), “bir öğede yalnızca bir aktif ödünç” kuralını tekrar belirtin veya UI etiketleri ile veritabanı sütunlarının eşleşmesi için alan adlarını yeniden adlandırın.

Güvenli genişletme ve prompt setini yeniden kullanma

Temeller çalıştıktan sonra, sonraki değişiklikleri küçük sürümler gibi ele alın. Bir kerelik genişletmeler yerine, bir özellik seçin, “done” ne demek belirleyin ve sonra o özelliği prompt’layın.

Birçok uygulama için mantıklı bir sıra:

• Audit log: kim neyi ne zaman değiştirdiğini kaydedin (create, update, delete) ve admin-only bir ekran gösterin.
• Dosya yüklemeleri: bir kayda belge veya resim iliştirin, meta veriyi Postgres’te saklayın ve erişimi auth arkasında tutun.
• Basit bildirimler: uygulama içi uyarılar gösterin (örneğin “low stock” veya “new comment”), ve "mark as read" eylemi ekleyin.

Bir değişiklik build’i bozduğunda, her şeyi aynı anda düzeltmeye çalışmayın. Geri alın, sonra daha küçük, daha spesifik bir prompt ile yeniden uygulayın. Koder.ai kullanıyorsanız, snapshot’lar ve rollback özellikle DB şeması, auth kuralları veya paylaşılan bileşenleri etkileyen değişikliklerden önce pratik bir güvenlik ağı sağlar.

Planning Mode, çok katmanlı bir özellik geldiğinde de yardımcı olur. Önce planı (ekranlar, API endpoint’leri, veritabanı değişiklikleri, roller) tekrar etmesini isteyin, sonra kod üretmesine onay verin. Bu, UI’nin beklediği alanları API’nin dönmediği veya API’nin yazdığı sütunların veritabanında olmadığı yaygın uyuşmazlığı önler.

Platform dışında devam etmek isterseniz, kaynak kodu aktarın ve normal iş akışınızda değişiklik yapın. Prompt setini repo yanında "build talimatı" olarak saklayın ki projeyi tekrar oluşturabilesiniz veya yeni birini hızlıca devreye alabilin.

Eğer Koder.ai (koder.ai) üzerinde inşa ediyorsanız, bu prompt seti platformun React + Go + PostgreSQL varsayılanlarıyla iyi uyuşur ve özellikleri rafine ederken snapshot’lar sayesinde güvenli yinelemeler yapabilirsiniz.

Son olarak, bir sonraki proje için yeniden kullanılabilir bir şablon prompt kaydedin. Sabit parçaları (stack, CRUD kuralları, auth ve roller konvansiyonları, Postgres desenleri) tutun ve yalnızca domain isimlerini değiştirin. Zamanla prompt’larınız bir kerelik deneme olmaktan çıkar ve tekrarlanabilir bir tarif haline gelir.