Daha Temiz Yazılım Mimarisi, Daha Az Yeniden Yazım için Prompt Kalıpları

AI Destekli Çalışmada “Daha Temiz Mimari” Nasıl Görünür?

Bu yazıda "daha temiz mimari" belirli bir çerçeve veya kusursuz bir diyagram anlamına gelmiyor. Sistemi kısa bir açıklamayla tarif edebilmek, değiştirdiğinizde alakasız kısımları kırmamak ve kahramanca test yapmadan davranışı doğrulayabilmek demek.

Pratik bir tanım: açıklık, modülerlik, test edilebilirlik

Açıklık demek sistemin amacı ve şeklinin kısa bir açıklamadan belirgin olması demektir: ne yapar, kim kullanır, hangi veriyi işler ve asla ne yapmamalı. AI destekli çalışmada açıklık ayrıca modelin gereksinimleri sizin onaylayacağınız şekilde tekrar ifade edebilmesi demektir.

Modülerlik demek sorumlulukların temiz sınırlara sahip olmasıdır. Her modülün bir işi, girdileri/çıktıları ve diğer modüllerin iç detayları hakkında asgari bilgi sahibi olması gerekir. AI kod ürettiğinde, modülerlik iş kurallarının controller, UI ve veri erişimi arasında yayılmasını engeller.

Test edilebilirlik demek "çalıştığını kanıtlamak" ucuz hale gelir. İş kuralları tam çalışan bir sistem olmadan test edilebilmeli ve entegrasyon testleri her kod yolunu değil bazı sözleşmeleri hedeflemelidir.

Yeniden yazımlar neden olur (ve AI bunu neden hızlandırabilir)

Yeniden yazımlar genellikle "kötü koda" değil eksik kısıtlara, belirsiz kapsama ve gizli varsayımlara dayanır. Örnekler:

• Bir özellik bir kullanıcı türü için hazırlandı, sonra üç rol olduğu ve farklı izinler gerektiği ortaya çıktı.
• Performans, denetim kayıtları veya veri saklama kuralları geç ortaya çıktı.
• Harici bir API beklenenden farklı davrandı ve her yerde değişiklik yapmak zorunda kaldınız.

AI bu başarısızlık modunu hızlandırabilir çünkü inandırıcı çıktı hızlıca üretebilir; bu da sarsak temellerin üzerine inşa etmeyi kolaylaştırır.

Bu rehberdeki kalıplardan ne bekleyebilirsiniz

İlerideki kalıplar uyarlanabilir şablonlardır, sihirli promptlar değil. Gerçek hedefleri erken doğru konuşmaları zorlamaktır: kısıtları netleştirmek, seçenekleri karşılaştırmak, varsayımları belgelemek ve sözleşmeleri tanımlamak. Bu düşünmeyi atladığınızda model memnuniyetle boşlukları doldurur—ve bedelini sonra ödersiniz.

Bu kalıplar iş akışınıza nerede oturur

Bu kalıpları teslimat döngüsünün tamamında kullanacaksınız:

• Planlama: gereksinimleri ve başarı kriterlerini sıkılaştırma
• Tasarım: sınırları, veri akışlarını ve sözleşmeleri seçme
• Kodlama: uygulama büyüdükçe sorumlulukları ayırma
• İnceleme: riskleri ve uyumsuzlukları yeniden yazıma dönüşmeden yakalama

Eğer chat ile oluşturup yineleyerek bir "vibe-coding" iş akışı kullanıyorsanız, bu kontrol noktaları daha da önemli hale gelir. Örneğin, Koder.ai içinde bir "planlama modu" döngüsü çalıştırarak gereksinimleri ve sözleşmeleri React/Go/PostgreSQL kodu üretmeden önce kilitleyebilir, sonra varsayımlar değiştiğinde deneyleri güvenle yineleyebilmek için snapshot/rollback kullanabilirsiniz—her değişikliği yeniden yazıma dönüştürmeden.

Prompt Kalıplarını Daha Fazla İş Yükü Oluşturmadan Kullanma

Prompt kalıpları karar çalkantısını azalttıklarında en değerli hale gelir. Püf noktası, bunları kısa, tekrar edilebilir kontrol noktaları olarak kullanmaktır—kodlamadan önce, tasarım sırasında ve inceleme esnasında—böylece AI yeniden kullanılabilir artefaktlar üretir, üzerinde ayıklamanız gereken ekstra metin değil.

Ne zaman kullanmalı

Kodlamadan önce: hedefleri, kullanıcıları, kısıtları ve başarı metriklerini onaylamak için bir "hizalama" döngüsü çalıştırın.

Tasarım sırasında: açık takasları zorlayan kalıplar kullanın (alternatifler, riskler, veri sınırları) ve sonra implementasyona geçin.

İnceleme sırasında: kontrol listesi tarzında bir prompt kullanarak boşlukları (köşe durumları, izleme, güvenlik, performans) değişiklikler hala ucuzken yakalayın.

Önce girdileri toplayın (hafif tutun)

Küçük, tutarlı bir giriş paketi ile daha iyi çıktı alırsınız:

• Hedefler: "done" ne demek (gecikme hedefleri, UX sonuçları, maliyet sınırları)
• Kullanıcılar: roller, ana iş akışları ve başlıca acı noktaları
• Kısıtlar: teknoloji yığını, teslim tarihleri, uyumluluk/güvenlik gereksinimleri
• Veri ve entegrasyonlar: kaynaklar, sahiplik, API'ler, üçüncü taraf bağımlılıklar

Bir şeyi bilmiyorsanız, bunu açıkça söyleyin ve modelden varsayımları listelemesini isteyin.

Yeniden kullanılabilir çıktı formatları isteyin

"Tasarımı açıkla" demek yerine, dokümanlara veya ticket'lara yapıştırabileceğiniz artefaktlar isteyin:

• Bir karar günlüğü (seçenekler → artılar/eksiler → seçilen → neden)
• Bileşenlerin sorumlulukları ve sınırlarıyla bir tablo
• Güvenilirlik ve test için bir kontrol listesi
• Daha sonra render edebileceğiniz basit bir diyagram açıklaması (ör. Mermaid metni)

Kabul kriterleri ile küçük döngülerde yineleyin

10–15 dakikalık döngüler yapın: prompt → göz at → sıkıştır. Her seferinde kabul kriterleri dahil edin (tasarımın kabul edilebilmesi için nelerin doğru olması gerektiği) ve modelden bunlara karşı kendi çıktısını kontrol etmesini isteyin. Bu süreç sonsuz yeniden tasarıma dönüşmesini engeller ve sonraki kalıpları hızlıca uygulamayı sağlar.

Kalıp 1: Herhangi Bir Tasarımdan Önce Gereksinimleri Netleştirin

Çoğu "mimari yeniden yazım" kötü diyagramlardan değil, yanlış (veya eksik) problemler için doğru şeyi inşa etmekten kaynaklanır. Bir LLM'i erken kullandığınızda, önce mimari istemeyin. Belirsizliği ortaya çıkarmasını isteyin.

Prompt hamlesi: belirsizliği bir kontrol listesine çevirin

Modeli bir gereksinim görüşmecisi gibi kullanın. Amacınız bileşenleri seçmeden, veritabanı seçmeden veya API'lara karar vermeden önce onaylayabileceğiniz kısa, önceliklendirilen bir spesifikasyon almaktır.

İşte kopyala-yapıştır şablonu:

You are my requirements analyst. Before proposing any architecture, do this:

1) Ask 10–15 clarifying questions about missing requirements and assumptions.
   - Group questions by: users, workflows, data, integrations, security/compliance, scale, operations.

2) Produce a prioritized scope list:
   - Must-have
   - Nice-to-have
   - Explicitly out-of-scope

3) List constraints I must confirm:
   - Performance (latency/throughput targets)
   - Cost limits
   - Security/privacy
   - Compliance (e.g., SOC2, HIPAA, GDPR)
   - Timeline and team size

4) End with: “Restate the final spec in exactly 10 bullets for confirmation.”

Context:
- Product idea:
- Target users:
- Success metrics:
- Existing systems (if any):

(Üstteki kod bloğu aynen korunmalı; içerik değişmedi.)

Çıktıda nereye bakmalı

Soruların karar vermeyi zorlayacak şekilde olması (genel "daha fazla bilgi ver" türü değil) ve must-have listesinin gerçekten zaman çizelgenizde bitirilebilecek öğeler içermesi gerekir.

"10 madde"lik tekrar ifadeyi bir kontrat gibi kullanın: ticket/PRD'ye yapıştırın, paydaşlardan hızlıca evet/hayır alın ve ancak o zaman mimariye geçin. Bu adım en yaygın geç refaktör nedenini önler: gerçekte gerekli olmayan özellikleri inşa etmek.

Kalıp 2: Önce Kullanıcı Yolculukları, Sonra Teknik Seçimler

Tool'larla başlamaya ("Event sourcing kullanalım mı?") başladığınızda genellikle kullanıcı için değil mimari için tasarım yaparsınız. Temiz yapıya daha hızlı ulaşmak için AI'dan önce kullanıcı yolculuklarını düz metinle tarif etmesini isteyin, sonra bu yolculukları bileşenlere, verilere ve API'lara çevirin.

Basit bir yolculuk-öncelikli prompt şablonu

Kopyala-yapıştır başlangıcı olarak kullanın:

• Roller: user / admin / system
• Ana eylemler: her rolün başarmaya çalıştığı şeyler
• Köşe durumları: neler ters gidebilir (geçersiz giriş, izin eksikliği, kısmi tamamlanma)

Sonra isteyin:

1. “Her eylem için adım adım akışı düz metin halinde tanımla.”

2. “Basit bir durum diyagramı veya durum listesi ver (örn. Draft → Submitted → Approved → Archived).”

3. “Mutluluk dışı senaryoları listele: zaman aşımı, yeniden deneme, çoğaltılmış istekler, iptaller ve geçersiz girdiler.”

Yolculukları kararlara dönüştürmek (ileriye atlamadan)

Akışlar netleştikten sonra AI'dan bunları teknik kararlara eşlemesini isteyin:

• Nerede validasyon, nerede iş kuralları gerekli?
• Hangi adımlar idempotency (güvenli yeniden denemeler) gerektirir?
• Hangi veri saklanmalı, hangisi türetilmeli ve hangisinin denetim izi olmalı?

Ancak o zaman akış adımlarına doğrudan bağlı bir mimari taslağı (servisler/modüller, sınırlar ve sorumluluklar) isteyin.

Akışları test edilebilir kabul kriterlerine dönüştürme

AI'dan her yolculuğu şu biçimde kabul kriterlerine dönüştürmesini isteyin:

• Her adım ve hata durumu için “Given/When/Then.”
• Sistem ne döndürmeli veya göstermeli?
• Ne kaydedilmeli ve ne kullanıcıya hata olarak gösterilmeli mi yoksa yeniden denemeyi tetiklemeli?

Bu kalıp, mimarinin teknoloji varsayımlarından değil kullanıcı davranışından büyümesini sağlar ve yeniden yazımları azaltır.

Kalıp 3: Şaşırtıcı Yeniden Yazımları Önlemek için Varsayım Günlüğü

Çoğu mimari yeniden işleme "kötü tasarım" yüzünden değil, yanlış çıkan gizli varsayımlar yüzündendir. Bir LLM'e mimari sorduğunuzda, boşlukları makul tahminlerle doldurur. Varsayım günlüğü bu tahminleri erken görünür kılar, değişiklik ucuzken.

Modelden ne yapmasını isteyin

Hedefiniz sağladığınız gerçekler ile modelin uydurduğu varsayımlar arasında temiz bir ayrım zorlamak.

Bu prompt kalıbını kullanın:

Template prompt “Before proposing any solution: list your assumptions. Mark each as validated (explicitly stated by me) or unknown (you inferred it). For each unknown assumption, propose a fast way to validate it (question to ask, metric to check, or quick experiment). Then design based only on validated assumptions, and call out where unknowns could change the design.”

Yeniden kullanılabilir “varsayım günlüğü” formatı

Kısa tutun ki insanlar gerçekten kullansın:

• Assumption: …
• Status: validated / unknown
• Why it matters: hangi kararı etkilediği
• How to validate: soru, kontol veya spike
• If wrong, likely change: neyi yeniden tasarlarsınız

“Cevabınızı ne değiştirir?” tetikleyicileri

Modelin kritik noktalarını söylettirin:

• “List 5 triggers: what would change your answer? (örneğin kullanıcı hacmi, gecikme hedefleri, uyumluluk ihtiyaçları, veri saklama kuralları).”

Bu kalıp mimariyi koşullu kararlara dönüştürür. Sadece bir diyagram değil—hangi noktaların doğrulanmadan commit edilmemesi gerektiğinin bir haritasını alırsınız.

Kalıp 4: Birini Seçmeden Önce Birkaç Mimarinin Karşılaştırılması

AI araçları tek bir "en iyi" tasarım üretmede iyi ama genellikle bu ilk mantıklı seçenekten ibarettir. Daha temiz bir mimari genellikle erkenden karşılaştırma yapıldığında ortaya çıkar; değişiklikler ucuzken bunu zorlayın.

Temel prompt şablonu

Erken çoklu mimariler ve yapılandırılmış bir takas tablosu isteyen bir prompt kullanın:

Propose 2–3 viable architectures for this project.
Compare them in a table with criteria: complexity, reliability, time-to-ship, scalability, cost.
Then recommend one option for our constraints and explain why it wins.
Finally, list “what we are NOT building” in this iteration to keep scope stable.

Context:
- Users and key journeys:
- Constraints (team size, deadlines, budget, compliance):
- Expected load and growth:
- Current systems we must integrate with:

(Kod bloğu olduğu gibi korunmalı.)

Neden bu yeniden yazımları azaltır

Bir karşılaştırma modelin (ve sizin) gizli varsayımlarını ortaya çıkarmaya zorlar: durum nerede tutuluyor, servisler nasıl iletişim kuruyor, neyin senkron olması gerekiyor ve ne geciktirilebilir. Kriter tablosu tartışmaları "monolith vs microservices" gibi görüşlere değil, aslında önem verdiğiniz şeylere sabitleyerek sonlandırır—hızlı gönderim, operasyonel yükü azaltma veya güvenilirliği artırma gibi.

Bir öneri ve bir sınır talep edin

"Bağlı" demeyi kabul etmeyin. Net bir öneri ve optimize ettiği spesifik kısıtları isteyin.

Ayrıca bu iterasyonda "ne inşa etmiyoruz"u da zorlayın. Örnekler: "Çok bölgeli failover yok", "Plugin sistemi yok", "Gerçek zamanlı bildirimler yok." Bu, mimarinin sessizce genişlemesini engeller ve kapsam daha sonra değiştiğinde sürpriz yeniden yazımları önler.

Kalıp 5: Modüler Sınırlar ve Sorumluluk Promptları

Çoğu yeniden yazım sınırlar belirsiz olduğu için olur: her şey her şeye dokunur ve küçük bir değişiklik tüm kod tabanına yayılır. Bu kalıp, kimse framework veya sınıf diyagramları tartışmadan önce net modül sahipliğini zorlayan promptlar kullanır.

Temel fikir

AI'dan modülleri ve sorumlulukları tanımlamasını isteyin ve her modülde açıkça nelerin olmaması gerektiğini belirtin. Sonra arayüzler (girdiler/çıktılar) ve bağımlılık kuralları isteyin; yapı planı veya implementasyon detayları değil.

Kopyala-yapıştır prompt şablonu

Yeni bir özellik tasarlarken veya karışık bir alanı refactor ederken bunu kullanın:

• Bağlam: <one paragraph about the product/feature>
• Hedef: 4–8 modülle modüler bir mimari önerin.

1. Modülleri listeleyin:

   • Amaç (1 cümle)
   • Sorumluluklar (3–5 madde)
   • Sorumluluk dışı kalanlar ("şu işi YAPMAZ") (2–3 madde)

2. Her modül için sadece arayüzleri tanımlayın:

   • Girdiler (olaylar/istekler/veri)
   • Çıktılar (yanıtlar/olaylar/yan etkiler)
   • Genel API yüzeyi (fonksiyon isimleri veya endpoint'ler uygun; iç sınıflar değil)

3. Bağımlılık kuralları:

   • İzin verilen bağımlılıklar (A → B)
   • Yasak bağımlılıklar (A ↛ C) ve gerekçesi
   • Paylaşılan tiplerin nerede durduğu (ve neyin asla paylaşılmaması gerektiği)

4. Gelecekteki değişiklik testi: Bu muhtemel değişiklikler verildiğinde: <list 3>, hangi tek modülün her değişikliği absorbe etmesi gerektiğini ve nedenini gösterin.

"İyi" çıktı nasıl görünür

Amacınız bir ekip arkadaşınıza bir dakikadan kısa sürede tarif edebileceğiniz modüller almak. Eğer AI "Utils" gibi bir modül öneriyorsa veya iş kurallarını controller'lara koyuyorsa geri itiniz: "Karar verme mantığını domain modülüne taşı ve adaptörleri ince tut."

Bittiğinde, değişikliklerin net bir evi olur ve bağımlılık kuralları istemeden coupling'i engeller, böylece yeni gereksinimler geldiğinde sınırlar dayanır.

Kalıp 6: Veri ve API Sözleşmeleri Önce (Entegrasyon İşlerini Önleyin)

Entegrasyon yeniden işleri genellikle "kötü kod" yüzünden değil, belirsiz sözleşmeler yüzündendir. Veri modeli ve API şekilleri geç kararlaştırılırsa her ekip (veya modül) boşlukları farklı doldurur ve sonraki sprintte uyumsuzlukları uzlaştırmak için zaman harcarsınız.

Sözleşmeleri framework, veritabanı veya mikroservis tartışmadan önce belirleyin. Net bir sözleşme UI, backend ve veri boru hatlarını hizalayan ortak referans olur.

Sözleşme-öncelikli prompt

AI asistanınızla erken bu promptu kullanın:

• Template: "Describe the data model, ownership, and lifecycle for each entity"

Ardından hemen şunu isteyin:

• API sözleşmeleri örneklerle (istekler, yanıtlar, hata şekilleri)
• Versiyonlama ve geriye uyumluluk beklentileri
• Alan başına doğrulama kuralları ve köşe durumları

"İyi" çıktı nasıl görünür

Prose değil, somut artefaktlar isteyin. Örnek:

• Entity: Subscription
  • Owner: Billing service
  • Lifecycle: created on checkout → active → past_due → canceled (soft-delete after 90 days)
  • Source of truth: billing DB; other services cache read-only copies

Ve bir API taslağı:

POST /v1/subscriptions
{
  "customer_id": "cus_123",
  "plan_id": "pro_monthly",
  "start_date": "2026-01-01"
}

201 Created
{
  "id": "sub_456",
  "status": "active",
  "current_period_end": "2026-02-01"
}

422 Unprocessable Entity
{
  "error": {
    "code": "VALIDATION_ERROR",
    "message": "start_date must be today or later",
    "fields": {"start_date": "in_past"}
  }
}

(Kod blokları olduğu gibi korunmalı.)

Versiyonlama ve uyumluluk kuralları

AI'dan şu tür kurallar belirtmesini isteyin: "Yalnızca alan eklemek versiyon artışı gerektirmez; yeniden adlandırma /v2 gerektirir; istemciler bilinmeyen alanları yok saymalıdır." Bu adım sessizce bozucu değişiklikleri ve ardından gelecek yeniden yazımları engeller.

Kalıp 7: Başarısızlık Modları ve Güvenilirlik Kontrol Listesi

Mimari, "happy path" tasarımları gerçek trafik, güvensiz bağımlılıklar ve beklenmeyen kullanıcı davranışı ile karşılaşınca yeniden yazılır. Bu kalıp güvenilirliği tasarım çıktısı olarak açık hale getirir, sonradan panik yapmayı azaltır.

Kopyala-yapıştır prompt şablonu

Seçtiğiniz mimari tanımıyla bunu kullanın:

List failure modes; propose mitigations; define observability signals.

For each failure mode:

• What triggers it?
• User impact (what the user experiences)
• Mitigation (design + operational)
• Retries, idempotency, rate limits, timeouts considerations
• Observability: logs/metrics/traces + alert thresholds

Modelden neleri kapsamasını isteyin (zorunlular)

Başarısız olabilecek arayüzleri isimlendirmekle başlayın: harici API'ler, veritabanı, kuyruklar, auth sağlayıcı ve arka plan işleri. Sonra somut kararlar isteyin:

• Retry: ne zaman yeniden denenecek, kaç kez, backoff stratejisi ve hangi hataların yeniden denenebilir olduğu
• Idempotency: idempotency anahtarları, dedupe pencereleri ve hangi durumların replay için güvenli olduğu
• Rate limits: kullanıcı/IP/servis başına limitler, istemci mesajlaşması ve sunucu tarafı koruması
• Timeouts: her bağımlılık için, toplam istek bütçesi ve iptal yayılımı

Güvenilirlik kontrol listesi çıktısı

Promptu şu satırla bitirin: "2 dakikada gözden geçirebileceğimiz basit bir kontrol listesi döndür." İyi bir kontrol listesi şunları içerir: bağımlılık timeout'ları ayarlı, retry'ler sınırlı, idempotency create/charge işlemleri için uygulanmış, backpressure/rate limiting var, kademeli düşüş (graceful degradation) tanımlı.

Kullanıcı eylemlerine bağlı gözlemlenebilirlik

Sadece sistem içlerine değil kullanıcı anlarına bağlı olaylar isteyin: "user_signed_up", "checkout_submitted", "payment_confirmed", "report_generated". Her biri için isteyin:

• Log alanları (user_id, request_id, idempotency_key)
• Metrikler (başarı oranı, gecikme p95/p99, retry sayısı)
• Trace'ler (bağımlılık çağrılarına göre span'lar)

Bu, güvenilirliği koddan önce doğrulanabilir bir tasarım artefaktı haline getirir.

Kalıp 8: Aşırı Yapı İnşa Etmeyi Önlemek İçin MVP Dilim Planlaması

AI destekli tasarımın yeniden yazım yaratmasının yaygın yolu, çok erken "tam" bir mimari oluşturmayı teşvik etmesidir. Çözüm basit: planı en küçük kullanılabilir dilimle başlatmaya zorlayın—değer sağlayan, tasarımı test eden ve gelecekteki seçenekleri açık tutan bir dilim.

Prompt şablonu

Çözüm gereksinimlerden hızlı genişliyorsa bunu kullanın:

Template: "Propose the smallest usable slice; define success metrics; list follow-ups."

Modelden şu şekilde cevap vermesini isteyin:

• MVP slice: gönderilebilecek gerçek bir şey için neler dahil
• Success metrics: çalıştığını nasıl anlayacağınız (kullanıcıya dönük + teknik)
• Follow-ups: öğrenmeyi engellemeden bekleyebilecek öğeler

Aşamalı yol haritası talep edin (MVP → v1 → v2)

İkinci bir talimat ekleyin: "Fazlı bir yol haritası ver: MVP → v1 → v2 ve her fazın hangi riski azalttığını açıkla." Bu, sonraki fikirleri görünür tutar ama ilk sürüme zorlamaz.

Örnek sonuçlar:

• MVP temel iş akışını ve ince uçtan uca yolu doğrular.
• v1 güvenilirliği sertleştirir, eksik "must-have" kullanılabilirliği ekler.
• v2 kapsamı genişletir (daha fazla entegrasyon, gelişmiş roller, optimizasyonlar).

Kapsam kaymasını önlemek için açık dışlamalar isteyin

Bu kalıbın en güçlü satırı: "MVP için açıkça kapsam dışı olanları listele." Dışlamalar mimari kararı erken karmaşıklığa zorlamaz.

İyi dışlamalar örnekleri:

• "MVP'de çok bölgeli failover yok (olayları kaydederek; v2 için planla)."
• "Henüz plugin sistemi yok (sınırları temiz tut, ama sabit modüllerle ship et)."
• "Sadece bir ödeme sağlayıcı; gerekirse daha sonra soyutla."

Planı ticket'lara çevirin ve bağımlılıkları belirtin

Son olarak: "MVP'yi ticket'lara çevir, her birine kabul kriterleri ve bağımlılıklar ekle." Bu netliği zorlar ve gizli coupling'i ortaya çıkarır.

Tipik ince bölüm bileşenleri:

1. İnce bir uçtan uca "happy path"
2. Minimal veri modeli + API sözleşmesi
3. Temel hata yönetimi ve kayıt
4. Gerekliyse bir entegrasyon noktası ve stub fallback

İsterseniz modelden takımınızın formatında çıktı (ör. Jira-stili alanlar) üretmesini isteyebilirsiniz ve sonraki fazları ayrı backlog olarak tutabilirsiniz.

Kalıp 9: Tasarımı Daha İyi Şekillendiren Test-Önce Promptları

Mimarinin kaymasından kaçınmanın basit yolu, bir bileşen tasarlamadan önce testlerle netlik zorlamaktır. Bir LLM'e önce kabul testleri yazmasını söylediğinizde, davranışları, girdileri, çıktıları ve köşe durumlarını adlandırmak zorunda kalır. Bu eksik gereksinimleri ortaya çıkarır ve implementasyonu temiz modül sınırlarına iter.

Kopyala-yapıştır prompt şablonu

Bir bileşen tasarımı yapmadan önce şu kapı prompt'unu kullanın:

• Template: "Write acceptance tests first; then propose implementation. You must: (1) list assumptions, (2) name unit vs integration tests, (3) define test data and mocks vs real dependencies, (4) include a definition of done."

Modüllerle eşleşen test sınırlarını isteyin

Takip eden isteğiniz: "Testleri modül sorumluluğuna göre grupla (API katmanı, domain mantığı, kalıcılık, harici entegrasyonlar). Her grup için neyin mocklandığını ve neyin gerçek olduğunu belirt."

Bu, LLM'i her şeye dokunan karışık tasarımlardan uzaklaştırır. Eğer entegrasyon testlerinin nerede başlayıp bittiğini açıklayamıyorsa, muhtemelen mimari henüz net değildir.

Kırılgan test takımlarından kaçınma stratejisi

İsteyin: "Test veri planı öner: fixtures vs factories, köşe durumları nasıl üretilecek ve testleri deterministik tutma stratejisi. Hangi bağımlılıkların in-memory fake ile çalıştırılabileceğini ve hangilerinin CI'de gerçek servis gerektirdiğini listele."

Çoğu zaman "basit" görünen bir özellik aslında bir kontrat, seed veri seti veya sabit ID'ler gerektirir—bunu şimdi bulmak yeniden yazımdan daha iyidir.

Gönderim tanımı (tasarımın gönderilmesini sağlamak)

Hafif bir kontrol listesi ile bitirin:

• Testler geçiyor (unit + integration) ve hata durumlarını anlamlı şekilde kapsıyor
• Minimal dokümantasyon: kullanım, yapılandırma ve kısa bir çözüm rehberi
• Ana başarısızlık modları için izleme/alertler
• Yayın planı (feature flag, migration adımları, rollback)

Kalıp 10: Sorunları Erken Yakalamak İçin Tasarım İncelemesi Promptları

Tasarım incelemeleri sadece kod mevcutken olmamalı. AI ile mimari taslağınıza (birkaç paragraf veya sözlü diyagram bile olsa) bir "pre-mortem" incelemesi çalıştırıp, yeniden yazımlara dönüşmeden önce somut zayıflıkları alabilirsiniz.

Temel inceleme şablonu

Keskin bir eleştirmen tutumu ile başlayın ve kesinlik zorlayın:

Prompt: "Act as a reviewer; list risks, inconsistencies, and missing details in this design. Be concrete. If you can't evaluate something, say what information is missing."

Tasarım özetinizi, kısıtları (bütçe, zaman çizelgesi, ekip yetenekleri) ve herhangi bir fonksiyonel olmayan gereksinimi (gecikme, kullanılabilirlik, uyumluluk) yapıştırın.

Geri bildirimi eyleme geçirilebilir bir yapılacak listesine dönüştürün

Geri bildirim belirsiz olduğunda inceleme başarısız olur. Öncelikli düzeltme listesini isteyin:

Prompt: "Give me a prioritized punch list. For each item: severity (Blocker/High/Medium/Low), why it matters, suggested fix, and the smallest validation step."

Bu, tartışma yerine karar-almaya hazır görevler üretir.

Yeniden yazım riskini nicelleştirin

Yarar sağlayan bir zorlayıcı: basit bir puanlama:

Prompt: "Assign a rewrite risk score from 1–10. Explain the top 3 drivers. What would reduce the score by 2 points with minimal effort?"

Amaç hassasiyet değil; en yeniden yazım eğilimli varsayımları ortaya çıkarmaktır.

Bir “diff plan” ile bitirin

Son olarak incelemeyi kapsam genişletmeye dönüştürmemek için:

Prompt: "Provide a diff plan: minimal changes needed to reach the target design. List what stays the same, what changes, and any breaking impacts."

Bu kalıbı her yinelemede tekrarlarsanız, mimariniz küçük, geri alınabilir adımlarla evrilir—büyük problemler ise erken yakalanır.

Kopyala-Yapıştır Prompt Paketi ve Basit Bir İş Akışı

Bu paketi her özellik için tekrarlanabilir hafif bir iş akışı olarak kullanın. Amaç promptları zincirleyip her adımın bir sonraki adımın kullanacağı bir artefakt üretmesini sağlamaktır—kayıp bağlamı ve sürpriz yeniden yazımları azaltır.

6 adımlı iş akışı (bu kalıpları zincirleyin)

1. Gereksinimler (netleştir + kısıtlar)
2. Mimari seçenekler (2–3 yaklaşımı karşılaştır)
3. Sınırlar (modüller + sorumluluklar)
4. Sözleşmeler (veri + API)
5. Testler (test-önce kabul + ana unit testler)
6. İnceleme (başarısızlık modları + tasarım inceleme kontrol listesi)

Pratikte ekipler bu zinciri bir "özellik tarifi" olarak uygular. Eğer Koder.ai ile inşa ediyorsanız, aynı yapı sohbet tabanlı bir build sürecine kolayca uyum sağlar: artefaktları bir yerde saklayın, ilk çalışan dilimi üretin, sonra snapshotlarla deneyler geri alınabilir kalsın. MVP hazır olduğunda kaynak kodu dışa aktarabilir veya deploy/host edebilirsiniz—AI destekli teslimat hızı isterken tek bir ortama kilitlenmemeniz için faydalıdır.

Kopyala-yapıştır prompt paketi (koruyucu kurallarla)

SYSTEM (optional)
You are a software architecture assistant. Be practical and concise. 
Guardrail: When you make a recommendation, cite the specific lines from *my input* you relied on by quoting them verbatim under “Input citations”. Do not cite external sources or general industry claims.
If something is unknown, ask targeted questions.

1) REQUIREMENTS CLARIFIER
Context: <product/system overview>
Feature: <feature name>
My notes: <paste bullets, tickets, constraints>

Task:
- Produce: (a) clarified requirements, (b) non-goals, (c) constraints, (d) open questions.
- Include “Input citations” quoting the exact parts of my notes you used.

2) ARCHITECTURE OPTIONS
Using the clarified requirements above, propose 3 architecture options.
For each: tradeoffs, complexity, risks, and when to choose it.
End with a recommendation + “Input citations”.

3) MODULAR BOUNDARIES
Chosen option: <option name>
Define modules/components and their responsibilities.
- What each module owns (and does NOT own)
- Key interfaces between modules
- “Input citations”

4) DATA & API CONTRACTS
For each interface, define a contract:
- Request/response schema (or events)
- Validation rules
- Versioning strategy
- Error shapes
- “Input citations”

5) TEST-FIRST ACCEPTANCE
Write:
- Acceptance criteria (Given/When/Then)
- 5–10 critical tests (unit/integration)
- What to mock vs not mock
- “Input citations”

6) RELIABILITY + DESIGN REVIEW
Create:
- Failure modes list (timeouts, partial failure, bad data, retries)
- Observability plan (logs/metrics/traces)
- Review checklist tailored to this feature
- “Input citations”

(Kod blokları ve şablonlar olduğu gibi korunmalıdır.)

Eğer daha derin bir eşlik isterseniz, ilgili blog başlığını ve fiyatlandırma sayfasını kendi değerlendirme adımlarınızda inceleyebilirsiniz.","output_format":"json","source_language":"en","target_language":"tr"