Chat ile oluşturulan uygulamalar için ajan rolleri: planlayıcıdan inceleyiciye iş akışı

Sohetle oluşturulan uygulamalarda güvenilirlik neden bozulur

Sohbet hızla ilerlemenizi sağlar, ama bir ürünün tamamını kafasında tutmakta zayıftır. Çoğu başarısızlık “kötü kod” değildir. Daha çok sizin kastettiğiniz, asistanın varsaydığı ve gerçekte yayımlanan arasındaki boşluklardır.

İlk çatlak eksik gereksinimlerdir. “Basit bir kayıt akışı” istersiniz, ama kimse parola sıfırlama, e-posta zaten kullanılıyorsa ne olacağı veya kullanıcı adımı yarım bıraktığında ne olacağı gibi kenar durumlarını yazmaz. Asistan boşlukları doldurur ve bu tahminler ürününüz olur.

İkinci çatlak tutarsız kararlar. Bir mesaj veri modelini seçer, sonraki kısım kısayol ekler, üçüncü ise isimlendirmeyi veya doğrulama kurallarını değiştirir. Her seçim tek başına makul olabilir. Birlikte ele alındığında, bir sonraki özellik eklendiğinde kırılan kırılgan bir uygulama ortaya çıkar.

Üçüncü çatlak kanıt eksikliğidir. Temel testler ve net kabul kontrolleri yoksa, sorunları ancak etkileşimde keşfedersiniz. O zaman “benim ekranımda çalışıyor” geçersiz hale gelir ve geç saatlere, acil düzeltmelere ve rastgele regresyonlara yol açar.

Basit bir çözüm, yeniden kullanılabilir kişilikler kullanmaktır: işi somutlaştıran bir Planner (Planlayıcı), yapıyı belirleyen bir Architect (Mimar), küçük adımlarla inşa eden bir Implementer (Uygulayıcı), kırmaya çalışan bir Tester (Testçi) ve ağrının %90'ına neden olan son %10'u yakalayan bir Reviewer (İnceleyen). Bu ağır bir süreç değil. Kararları tutarlı tutmanın tekrar edilebilir bir yolu.

Bu yaklaşım solo kurucular, küçük ekipler ve Koder.ai gibi sohbet araçlarını kullanan teknik olmayan üreticiler için işe yarar. Hala hızlı hareket edebilirsiniz, ama şansa bağlı kalmazsınız.

Bu roller mucizevi şekilde kaliteyi garanti etmez. Yine de net girdilere (başarı ne demek, kısıtlar, öncelikler) ihtiyacınız var ve çıktıları okumanız gerekir. Rolleri koruyucu kenarlıklar olarak düşünün: önlenebilir hataları azaltırlar, ama sürücü sizsiniz.

Temel fikir: sorumlulukları ayırın, sonra temiz devredin

Bir sohbetin her şeyi aynı anda yapmaya çalıştığında güvenilirlik düşer: ne yapılacağına karar vermek, tasarlamak, kodlamak, test etmek ve değerlendirmek. Bu işleri karıştırmak kenar durumlarını kaçırmayı, gereksinimleri inşa sırasında değiştirmeyi veya hataları daha fazla karışıklık ekleyerek “düzeltmeyi” kolaylaştırır.

Bunu önlemenin pratik yolu, rolleri tutarlı ve dar tutmaktır. Her rol tek bir işi üstlenir ve o işin dışına “yardım etmeye” izin verilmez. Bu, kararların izlenebilir kalmasını sağlar ve hataları bulmayı kolaylaştırır.

Neredeyse her özellik için şu sıralamayı kullanın:

• Planner: hedefi, kullanıcıları, kabul kontrollerini ve kapsam dışını tanımlasın
• Architect: hedefi destekleyebilecek en basit tasarımı öneri
• Implementer: planlanmış olanı, küçük adımlarda inşa etsin
• Tester: kırmaya çalışsın ve hataları net raporlasın
• Reviewer: son kilometre detaylarını (isimlendirme, temel güvenlik, UX boşlukları, riskli kısayollar) kontrol etsin

Temiz devir teslimler roller kadar önemlidir. Her devretme, ne karar verildiğini, ne varsayım yapıldığını ve “tamam” ne anlama geldiğini içermelidir. Koder.ai kullanıyorsanız, her rolü ayrı bir sohbet adımı veya anlık görüntü olarak ele alın ki bir karar yanlış çıktığında geri dönebilesiniz.

Bilerek geri dönün, kazara değil. Testler başarısız olursa, küçük bir hata raporu ile Implementer'a geri dönün. Tasarım yeni bir gereksinimi destekleyemiyorsa Architect'e dönün. Gereksinim belirsizse veya sürekli değişiyorsa, duraklayın ve Planner'a geri dönün.

Aynı rolleri ve sıralamayı özellikler boyunca koruyun. Birkaç uygulamadan sonra kas hafızası gelişir: erken daha iyi sorular sorarsınız ve işin geçte yeniden yapılmasını önlersiniz.

Persona 1: Planner (kimse inşa etmeden önce işi netleştir)

Planner’ın işi, bulanık bir fikri inşa edilebilir ve doğrulanabilir bir şeye çevirmektir. Bu “doküman yazmak” değildir. İlk ekran veya API uç noktası olmadan önce “tamam” ne demek anlaşmaktır.

İyi bir Planner çıktısı küçük ve test edilebilir kalır: net bir problem açıklaması, birkaç kullanıcı hikayesi, basit kabul kriterleri ve kısa bir kenar durumları listesi. Ayrıca henüz ne yapmadığınızı belirtir, böylece Implementer istemeden daha büyük bir özellik geliştirmez.

Planner komut şablonu (küçük, öncelikli plan)

Bir özellik fikriniz olduğunda ve diğer rollerin takip edebileceği sıkı bir plan istediğinizde bunu kullanın.

You are the Planner. Turn the feature idea below into a buildable plan.

Feature idea:
<PASTE IDEA>

Context:
- App type:
- Target users:
- Current behavior (if any):
- Constraints (time, data, compliance, devices):

Output (keep it short):
1) Problem statement (1-2 sentences)
2) Assumptions (3-6 bullets)
3) Questions to confirm (max 6, prioritized)
4) User stories (2-5)
5) Acceptance criteria (5-10, testable, specific)
6) Edge cases & failure modes (3-8)
7) Out of scope (3-6 bullets)
8) Small milestone plan (2-4 steps, highest value first)

Planner'dan Architect'e devretme (yapılandırılmış ve kısa)

Bu mesajı olduğu gibi (doldurulmuş halde) gönderin ki gereksiz tekrarlar olmasın.

PLANNER HANDOFF
Feature: <name>
Problem: <1-2 sentences>
Users: <who>
Must-haves (AC): <5-10 acceptance criteria>
Key edge cases: <3-6>
Out of scope: <3-6>
Open questions (need Architect input): <1-4>
Constraints: <tech, data, privacy, deadlines>
Success signal: <how we’ll know it worked>

Planner olarak yapacağınız tek şey kabul kriterlerini ölçülebilir yapmak olmalı. Örneğin: “Kullanıcı parola sıfırlayabilir ve 60 saniye içinde e-posta alır” cümlesi, “Parola sıfırlama çalışır” demekten çok daha iyidir.

Persona 2: Architect (uygulamanın gerçekten destekleyebileceği bir şekli seç)

Architect iyi bir planı inşa edilebilir bir şekle çevirir. İş, gösterişli desenler icat etmek değildir. Gerçek kullanıcılar tıkladığında, veri büyüdüğünde ve hatalar olduğunda hâlâ işe yarayacak en basit yapıyı seçmektir.

Burada güvenilirlik gerçek olmaya başlar: net sınırlar, net veriler ve net hata yolları.

Pratik bir Architect çıktısı genellikle şunları kapsar:

• Ekranlar (React veya Flutter) veya API uç noktaları (Go)
• Küçük bir veri modeli (PostgreSQL tabloları ve ana alanlar)
• Bir veya iki temel akış (mutlu yol artı nelerin yanlış gidebileceği)
• Şu an önemli olan işlevsel olmayan temel ihtiyaçlar (auth, gizlilik, performans, logging)
• Tradeoff'lar (şimdi neyi inşa etmediğiniz)

Somut tutun. “Bildirim sistemi” demek yerine “POST /api/alerts, table alerts(user_id, type, status), başlıkta okunmamış sayısını göster” gibi söyleyin. “Güvenli” demek yerine “JWT oturumu, admin uç noktalarında rol kontrolleri, PII alanlarını koru” gibi belirtin.

Komut şablonu: Architect devretme (tradeoff’ları zorlar)

Planner işi Architect’e verdiğinde veya karışık hissettiren bir özelliği resetlemek istediğinizde bunu kullanın.

You are the Architect.
Goal: design the simplest buildable structure for this feature.
Context:
- App type: [web/mobile/both]
- Stack: React UI, Go API, PostgreSQL DB (Flutter screens if mobile)
- Existing constraints: [auth method, existing tables, deadlines]

Input (from Planner):
- User story:
- Acceptance criteria:
- Out of scope:

Deliverables (keep it short and specific):
1) UI map: list screens/components with 1-line purpose each.
2) API map: list endpoints with method, path, request/response fields.
3) Data model: tables + key columns + relationships.
4) Key flows: happy path + 2 failure cases and how UI should respond.
5) Non-functional needs: security, performance, audit/logging (only what matters now).
6) Tradeoffs: 3 decisions you made (and what you avoided) to prevent over-design.

Rules:
- Prefer the smallest option that meets acceptance criteria.
- If something is unclear, ask up to 3 questions, otherwise make a reasonable assumption and write it down.

Koder.ai içinde inşa ediyorsanız, bu tür bir devretme Implementer için uygulamayı daha hızlı yapar çünkü Implementer şekli tahmin etmek yerine net bir haritayı takip edebilir.

Persona 3: Implementer (küçük adımlarda inşa et, kapsamı sıkı tut)

Implementer, net bir planı çalışır koda dönüştürür; planı değiştirmeden. Burada güvenilirliğin çoğu kazanılır veya kaybedilir. Amaç basittir: kararlaştırılanı, geri alınabilir küçük adımlarda inşa etmek.

Her değişikliği geri alınabilirmiş gibi ele alın. İnce dilimler halinde çalışın ve kabul kriterleri karşılandığında durun. Bir şey belirsizse sorun. Tahmin etmek, küçük özelliklerin sürpriz yeniden yazımlara dönüşmesinin yoludur.

İyi bir Implementer kısa bir kanıt izi bırakır: yapı sırası, ne değişti, ne değişmedi (gizli kapsam sürprizlerini önlemek için) ve nasıl doğrulanacağı.

Implementer'a işi devrettiğinizde yapıştırabileceğiniz bir komut şablonu şöyle:

You are the Implementer.

Context:
- Feature: <name>
- Current behavior: <what happens today>
- Desired behavior: <what should happen>
- Acceptance criteria: <bullets>
- Constraints: <tech choices, performance, security, no schema change, etc.>

Before writing code:
1) Ask up to 5 questions if anything is unclear.
2) Propose a step-by-step build plan (max 6 steps). Each step must be reversible.
3) For each step, list the exact files/modules you expect to touch.

Then implement:
- Execute steps one by one.
- After each step, summarize what changed and how to verify.
- Do not add extras. If you notice a better idea, stop and ask first.

Örnek: Planner “Parola sıfırlama e-posta akışı ekle” istediyse, Implementer aynı zamanda giriş ekranını yeniden tasarlamamalıdır. E-posta isteği uç noktasını, sonra token işlemini, sonra UI'ı, her adımda kısa bir doğrulama notu ile inşa edin. Araç anlık görüntü ve geri alma destekliyorsa (Koder.ai yapıyor), küçük adımlar çok daha güvenli olur.

Persona 4: Tester (çalıştığını kanıtla ve nasıl başarısız olduğunu göster)

Tester’ın işi, kullanıcılar yapmadan önce özelliği kırmaktır. Mutlu yola güvenmezler. Belirsiz durumlara, eksik doğrulamaya ve çıkış anında ortaya çıkan kenar durumlarına bakarlar.

İyi bir Tester çıktısı başkası tarafından kullanılabilir olmalıdır: kabul kriterlerine bağlı bir test matrisi, kısa bir manuel senaryo ve beklenen vs gerçek adımlarla hata raporları.

Ne test edilmeli (UI, API ve veri)

Hacim yerine kapsama odaklanın. Hataların en pahalı olduğu yerlere bakın: doğrulama, izinler ve hata durumları.

• UI: boş durumlar, hata mesajları, yükleniyor durumları, devre dışı bırakılmış butonlar, sadece klavye akışı
• API: eksik alanlar, yanlış tipler, auth hataları, oran/zaman aşımı davranışı
• Veri doğrulama: tekrarlar, maksimum uzunluklar, geçersiz formatlar, sadece UI değil sunucu tarafı kontrolleri
• İzinler: normal bir kullanıcının yapabilecekleri vs bir admin
• Regresyon: bir veya iki “mevcut davranışı kırdık mı?” kontrolü

Örnek: “Fatura oluştur” eklediyseniz, negatif miktar, 10.000 karakterlik not, eksik müşteri ve çift tıklama ile çift gönderim deneyin.

Komut şablonu: kabul kriterlerinden test matrisi üret

Implementer’dan Tester’a devrederken bunu kullanın. Kabul kriterlerini ve ilgili UI/API notlarını yapıştırın.

ROLE: Tester
GOAL: Produce a test matrix tied to acceptance criteria, including negative tests.
CONTEXT:
- Feature: <name>
- Acceptance criteria:
  1) <AC1>
  2) <AC2>
- Surfaces: UI screens: <list>; API endpoints: <list>; DB changes: <notes>
OUTPUT FORMAT:
1) Test matrix table with columns: AC, Test case, Steps, Expected result, Notes
2) Negative tests (at least 5) that try to break validation and permissions
3) Manual test script (10 minutes max) for a non-technical person
4) Bug ticket template entries for any failures you predict (Title, Steps, Expected, Actual, Severity)
CONSTRAINTS:
- Keep steps precise and reproducible.
- Include at least one test for loading/error states.

Persona 5: Reviewer (ağrının %90'ına neden olan son %10'u yakala)

Reviewer son kalite kontrolüdür. Her şeyi yeniden yazmak için değil, ancak sonra uzun süren hatalara dönüşecek küçük sorunları tespit etmek içindir: kafa karıştırıcı isimlendirmeler, eksik kenar durumları, zayıf hata mesajları ve sonraki değişikliği zorlaştıran riskli kısayollar.

İyi bir review şu çıktıların net olmasını sağlar: ne kontrol edildi, ne değişmeli, ne kabul edilebilir bir risk, ve hangi karar alındı (böylece gelecek hafta tekrar tartışılmaz).

Reviewer neler arar

Geçici ve tekrar edilebilir bir geçiş yapın. Güvenilirliği en çok bozan şeylere odaklanın:

• Tutarlılık: isimlendirme, desenler, klasör yapısı ve UI davranışı uygulamayla uyumlu mu
• Güvenlik temelleri: girdi doğrulama, auth kontrolleri, loglarda hassas veri yok
• Hatalar: kullanıcıya gösterilen mesajlar açık; sunucu hataları eyleme geçirilebilir; sessiz başarısızlık yok
• Sürdürülebilirlik: küçük fonksiyonlar, açık niyet, sebepsiz tekrar yok
• Gelecek değişiklikler: ileride ne zor olacak ve bu maliyeti şimdi nasıl azaltırız

Yapılandırılmış inceleme komutu (onay veya değişiklik iste)

Implementer özelliğin bittiğini söylediğinde bu devretmeyi kullanın:

You are the Reviewer. Do a final review for correctness, clarity, and maintainability.

Context
- Feature goal:
- User flows:
- Key files changed:
- Data model/migrations:

Review checklist
1) Correctness: does it meet the goal and handle edge cases?
2) Security basics: auth, validation, safe logging.
3) Errors: clear messages, consistent status codes.
4) Consistency: naming, patterns, UI text.
5) Maintainability: complexity, duplication, TODOs.

Output format
- Findings (bulleted): include file/function references and severity (high/medium/low)
- Requested changes (must-fix before merge)
- Risk notes (acceptable with reason)
- Decision log updates (what we decided and why)

Finish with exactly one:
APPROVE
CHANGES REQUESTED

Reviewer değişiklik istediyse, bunlar küçük ve spesifik olmalı. Amaç üretimde sürprizleri azaltmak, ikinci bir geliştirme döngüsü yapmak değil.

Yeniden çalışma önleyen devretme şablonları

Çoğu yeniden çalışma, bir sonraki kişinin belirsiz hedefle, eksik girdilerle veya gizli kısıtlarla başlamasından kaynaklanır. Basit bir devretme şablonu, her transferi öngörülebilir kılar.

Her seferinde, küçük görevler için bile ortak bir başlık kullanın:

• Context + Goal: ne inşa ediyorsunuz ve neden, bir paragrafta.
• Inputs: ekranlar, API notları, veri alanları, örnek kayıtlar, ilgili kod alanları.
• Constraints: teknoloji tercihleri, teslim tarihleri, performans, güvenlik, korunması gereken davranışlar.
• Definition of Done: ölçülebilir kontroller (ne geçmeli, ne var olmalı).
• Assumptions / Open questions / Decisions made: neyi varsaydınız, ne bilinmiyor, neyi kilitlediniz.

İşte bir örnek devretme (Architect -> Implementer):

ROLE HANDOFF: Architect -> Implementer
Context: Add “Invite team member” to the admin area.
Goal: Admin can send an invite email; invited user can accept and set a password.
Inputs: Existing Users table; auth uses JWT; email provider already configured.
Constraints: Go backend + PostgreSQL; React UI; audit log required; no breaking auth changes.
Definition of Done:
- UI: invite modal + success state
- API: POST /invites, POST /invites/accept
- DB: invites table with expiry; audit event on create/accept
- Tests: happy path + expired invite + reused token
Assumptions: Email templates can reuse “reset password” styling.
Open questions: Should invites be single-use per email?
Decisions made: 72h expiry; tokens stored hashed.

Bunu kalıcı hale getirmek istiyorsanız, şablonlarınızı herkesin kopyalayabileceği bir yerde saklayın. Koder.ai kullanıyorsanız, bu komutları Planning Mode'da saklayabilir ve uygulamadan önce bir anlık görüntü alarak kapsam kayarsa geri dönüşü kolaylaştırabilirsiniz.

Her özellik için izleyebileceğiniz adım adım iş akışı

Her özelliği küçük bir sürüm gibi ele aldığınızda güvenilirlik artar; roller arasında temiz devretmelerle. Bir seferde bir kullanıcı hikayesiyle başlayın, fikir yığınıyla değil. Bunu düz bir dille yazın, sonra birinin tahmin etmesine gerek kalmadan kontrol edilebilecek kabul kriterleri ekleyin.

O hikayeyi destekleyecek minimum şekli tasarlayın. Amaç mükemmel bir sistem değil. Bir sonraki özellik eklenince çökmeyecek basit bir plan.

Pratik bir akış şöyle görünür:

1. Planner: Kullanıcı hikayesini, kenar durumlarını ve kabul kriterlerini doğrular (başarı, başarısızlık ve “kullanıcı X yaparsa ne olur”).
2. Architect: En küçük veri modeli ve API yüzeyini önerir (tablolar/alanlar, uç noktalar, auth kuralları) ve neyin yapılmayacağını kısa notla belirtir.
3. Implementer: Kabul kriterlerini karşılayan uçtan uca ince bir dilimi inşa eder (UI -> API -> DB), UI sade olsa bile.
4. Tester: Tekrarlanabilir bir test senaryosu çalıştırır, yeniden üretilebilir adımlarla hataları kaydeder ve belirsiz davranışları not eder.
5. Reviewer: Güvenlik temelleri ve ürün düzeltmeleri için son geçişi yapar, sonra kararları kaydeder.

Her adımın çıktısını küçük ve açık tutun. Genellikle rol başına bir devretme mesajı yeterlidir: girdiler, alınan kararlar ve bir sonraki kişiden ne beklendiği.

Son olarak bir paragraf değişiklik notu yazın: ne eklendi, ne kaldırıldı ve bir sonraki sürümde neye dikkat edilecek. Bu “hafıza” aynı tartışmaların ve hataların geri gelmesini önler.

Gerçekçi bir örnek: fikirden incelenmiş sürüme bir özellik

Özellik: kullanıcıların kişi ekleyebileceği, etiket (ör. “Lead” veya “Vendor”) ekleyebildiği ve isim veya etikete göre arama yapabildiği basit bir CRM ekranı. Kısıt: 90 dakikanız var ve mevcut contacts tablosunu yeniden kullanmalısınız (kırıcı migration yok). Mobil için tek sayfalık bir “Kişi Ekle” ekranı yeterli.

Persona zincirini kullanarak devretme şu şekilde görünür. Her rol, bir sonraki kişinin güvenebileceği küçük bir eser üretir.

Planner output (definition + acceptance)
- Goal: Add contacts with tags and fast search.
- Must: Create, edit, list contacts; add/remove tags.
- Search: matches name OR any tag; results update in under 300ms.
- Constraint: keep existing contacts table; tags can be new table.
- Done when: 5 test cases pass; mobile screen has no scroll on common devices.

Architect output (shape + data)
- Tables: contacts (existing), tags (id, name), contact_tags (contact_id, tag_id).
- API: POST /contacts, PATCH /contacts/:id, GET /contacts?query=.
- Search: SQL ILIKE on contact name + join on tags.
- UI: Contact list with search bar; contact form with tag picker.
- Risk: duplicate tags (“lead” vs “Lead”) - enforce lowercase unique.

Implementer output (small steps)
- Step 1: Add tags + join table migrations.
- Step 2: Update backend handlers and query.
- Step 3: Build React UI list + form; wire to API.
- Step 4: Add basic validation (name required, tag length).
- Step 5: Add loading/error states; keep UI responsive.

Tester output (proof + failure)
- Case: search “lea” returns contacts tagged “lead”. FAIL: returns none.
- Case: adding tag “Lead” then “lead” should not create two tags. PASS.
- Case: empty name rejected. PASS.
- Bug note: backend search only checks contact name, not tags.

Loop-back (Planner update)
- Update acceptance: search must match tags via join; include a test for it.
- Add edge case: searching by tag should return even if name doesn’t match.

Reviewer output (last 10%)
- Check: query uses indexes; add index on tags.name and contact_tags.tag_id.
- Check: error messages are clear; avoid raw SQL errors.
- Check: mobile form spacing and tap targets.
- Confirm: snapshots/rollback point created before release.

O tek başarısız test temiz bir geri dönüşü zorlar: plan netleşir, Implementer bir sorguyu değiştirir ve Reviewer performans ve cilayı kontrol edip yayımlamadan önce onay verir.

Yaygın tuzaklar (ve basit düzeltmeler)

Sohbetle oluşturulan yazılıma güveni kaybetmenin en hızlı yolu, herkesin her şeyi yapmasına izin vermektir. Net roller ve temiz devretmeler işleri öngörülebilir tutar, hızlı ilerlerken bile.

• Persona'lar birbirine karışıyor (gereksinimler stabil olmadan inşa başlıyor). Düzeltme: Planner çıktısını kilitleyin, kod değişikliğine başlamadan önce. Şablon ayarı: “Implementer: Planner'ın Kapsam, Varsayımlar ve Kabul Kriterleri mevcut olana kadar kod yazma. Eksikse, en fazla 3 soru sor.”
• Done Tanımı yok, iş asla bitmiyor. Düzeltme: her devretme bir Done satırı içermeli. Örnek: “Done demek: kabul kriterleri karşılandı, yeni TODO yok ve değişiklikler 5 maddeyle belgelendi.”
• Tester sadece mutlu yolu kontrol ediyor. Düzeltme: her seferinde bir geçersiz girdi vakası ve bir kenar durumu şart koşun. Şablon: “Tester: (1) mutlu yol, (2) bir geçersiz girdi, (3) bir kenar durumu sun. Çalıştıramıyorsanız, adımları ve beklenen çıktıyı net yazın.”
• Reviewer stil tartışıyor, ürün riskine odaklanmıyor. Düzeltme: Reviewer'ı önce riske odaklanmaya zorlayın. Şablon: “Reviewer: en büyük 3 riski (güvenlik, veri kaybı, bozuk UX, performans) listele. Stil sadece okunabilirliği engelliyorsa veya hata oluşturuyorsa bahset.”
• Devretmeler bağlamı kaçırıyor, sonraki rol tahmin ediyor. Düzeltme: her seferinde kısa bir Handoff Bloğu zorunlu kılın: “Goal, What changed, How to verify, Known gaps.” 8 satırın altında tutun.

Küçük bir alışkanlık yardımcı olur: Implementer işi bitirdiğinde kabul kriterlerini yapıştırıp madde madde tik atın.

Sohbetle oluşturulan güvenilir sürümler için hızlı kontrol listesi

Bunu inşa etmeden önce, merge öncesi ve yayımladıktan sonra çalıştırın.

İnşa öncesi (kimse kod yazmadan önce)

• Hedefi bir cümlede yazın ve 2-3 kabul kontrolü listeleyin (“tamam” ne demek).
• Nelerin kapsam dışında olduğunu belirtin (Implementer tahmin etmesin).
• Tam olarak hangi veri alanları ve kurallar (tipler, zorunlu/opsiyonel, varsayılanlar) olduğunu yazın.
• Ana hata durumlarını not edin (kötü girdi, eksik izin, boş durumlar, zaman aşımı).
• Hızlıca nasıl doğrulayacağınızı kararlaştırın (bir ekran, bir API yanıtı, bir log satırı).

Küçük örnek: “E-posta ile davet ekle.” Alanları (email, role), e-posta geçersizse ne olacağı ve yeniden davete izin verilip verilmediğini belirtin.

Merge öncesi ve yayımlama sonrası (değişiklik korkusunu azalt)

• Merge öncesi: testlerin çalıştığını doğrulayın (veya kısa bir manuel senaryo çalıştırıldığını) ve neyin kontrol edildiğini kaydedin.
• Merge öncesi: 2-3 kenar durumunu açıkça test edin, “çalışmalı” demeyin.
• Merge öncesi: bir geri alma planı ve hangi değişiklikte geri alma tetikleneceğini not edin.
• Yayımlama sonrası: ilk saat/gün için 1-2 sinyali izleyin (hatalar, yavaş sayfalar, başarısız işler).
• Yayımlama sonrası: kullanıcı geri bildirimlerini yakalayın ve destek ekibinin karışmaması için bilinen sınırlamaları yazın.

Platform destekliyorsa (Koder.ai yapıyor), riskli düzenlemelerden önce anlık görüntü alın. Geri dönebileceğinizi bilmek, küçük ve güvenli değişiklikler yayımlamayı kolaylaştırır.

Sonraki adımlar: bunu varsayılan iş akışınız yapın

Bir küçük özellik seçin ve tam persona zincirini bir kez çalıştırın. Gerçek ama sınırlı bir şey seçin: “parola sıfırlama ekle”, “sadece admin sayfası oluştur”, veya “faturaları CSV'ye dışa aktar”. Amaç Planner'dan Reviewer'a temiz devretmeler zorladığınızda neyin değiştiğini görmektir.

Koder.ai (koder.ai) kullanıyorsanız, Planning Mode kapsamı ve kabul kontrollerini inşa etmeden önce kilitlemek için pratik bir yerdir. Sonra anlık görüntüler ve geri alma, bir karar yanlış çıktığında tüm projeyi tartışmaya dönüştürmeden güvenli bir kaçış sağlar.

Workflow'u tekrar edilebilir kılmak için persona komutlarınızı ekipte şablon olarak saklayın. Kısa tutun, çıktı formatlarını tutarlı hale getirin ve her özellikte aynı açıklamaları tekrar etmekten daha az zaman harcayın.