Compound Engineering: Yapay zeka yerel mühendislik felsefesi

• Tüm mühendislik iş birimlerinin sonraki işleri daha kolay hale getirdiği bileşik getirili yazılım geliştirme metodolojisi olarak, yapay zeka ajanlarıyla iş birliğini sistematikleştiren 4 aşamalı döngü (planlama→uygulama→inceleme→bileşikleştirme) etrafında kuruludur
• Tekrarlayan döngü içinde mühendisin zamanının %80’i planlama ve incelemeye, %20’si uygulama ve bileşikleştirmeye ayrılmalıdır
• 26 uzman ajan, 23 iş akışı komutu ve 13 beceri içeren eklenti biçiminde dağıtılır; Claude Code, OpenCode ve Codex’e kurulabilir
• Mevcut yazılım geliştirmenin 8 yaygın kanısını (kod elde yazılmalıdır, her satır manuel incelenmelidir vb.) terk edilmesi gereken inançlar olarak sunar ve sisteme tercihleri kodlayan yeni ilkelerin benimsenmesi gerektiğini savunur
• Geliştiricilerin yapay zeka benimseme düzeyini 0. seviye (manuel geliştirme) ile 5. seviye (paralel bulut yürütme) arasında sınıflandırır; her seviye için seviye atlama yöntemleri ile ekip iş birliği, tasarım, araştırma ve pazarlamaya kadar genişleyen kapsamlı bir çerçeve sunar

---

Temel felsefe

• Her mühendislik iş biriminin sonraki işleri daha kolay hale getirmesi gerektiği ana ilkedir
• Geleneksel kod tabanlarında her yeni özellik eklemesiyle karmaşıklık artar; bu da 10 yıl sonra sistemle mücadele etmeye daha fazla zaman harcanmasına yol açar
• Compound Engineering’de ise özellikler sisteme yeni yetenekler öğretir, hata düzeltmeleri gelecekteki hata kategorilerinin tamamını ortadan kaldırır ve örüntüler araçlara dönüştürülerek kod tabanı zaman geçtikçe anlaması, değiştirmesi ve güvenmesi daha kolay hale gelir

Ana döngü: Plan → Work → Review → Compound

• Every ekibi, 5 ürünü (Cora, Monologue, Sparkle, Spiral, Every.to) çoğunlukla tek kişilik mühendislik ekipleriyle yürütüyor; bunu mümkün kılan şey de bu 4 aşamalı döngü
• İlk 3 aşama (planlama, uygulama, inceleme) genel kabul görmüş olsa da, bileşik getirinin biriktiği asıl ayırt edici aşama 4. adım olan Compound
• İster 5 dakikalık bir hata düzeltmesi ister birkaç günlük bir özellik geliştirmesi olsun, aynı döngü kullanılır; yalnızca her aşamaya ayrılan süre ayarlanır

• 1. aşama: Plan (Planlama)

  • Gereksinimleri anlama: Ne yapılacağını, neden yapılacağını ve hangi kısıtların bulunduğunu belirleme
  • Kod tabanını araştırma: Benzer işlevlerin nasıl çalıştığını ve mevcut örüntüleri analiz etme
  • Dış araştırma: Framework belgelerini ve sektördeki en iyi uygulamaları inceleme
  • Çözüm tasarımı: Yaklaşımı ve değiştirilecek dosyaları belirleme
  • Plan doğrulama: Planın bütünlüğünü ve tutarlılığını kontrol etme

• 2. aşama: Work (Uygulama)

  • Yalıtılmış ortam kurma: Çalışmayı Git worktree (deponun yalıtılmış kopyası) veya branch ile ayırma
  • Planı uygulama: Ajanın adım adım geliştirmeyi yapması
  • Doğrulama çalıştırma: Her değişiklikten sonra test, linting (otomatik kod denetimi) ve type check yürütme
  • İlerlemeyi takip etme ve sorun çıktığında planı güncelleme
  • Plana güveniliyorsa, kodu satır satır gözetlemeye gerek yoktur

• 3. aşama: Review (İnceleme)

  • Birden fazla ajanın paralel biçimde kod incelemesi yapması
  • Bulguların önceliğe göre P1 (zorunlu düzeltme), P2 (önerilen düzeltme), P3 (iyileştirme) şeklinde sınıflandırılması
  • Ajanın inceleme geri bildirimine göre sorunları düzeltmesi ve sonuçları doğrulaması
  • Örüntü kaydı: Neyin yanlış gittiğini belgelendirerek tekrarını önleme

• 4. aşama: Compound (Bileşikleştirme) — en önemli aşama

  • Geleneksel geliştirme 3. aşamada biter, ancak Compound aşamasında sistem iyileştirmeleri birikmeye başlar
  • İlk 3 aşama özellik üretirken, 4. aşama özellikleri daha iyi üreten sistemi üretir
  • Yapılan işler:
    • Nelerin işe yarayıp yaramadığını ve hangi içgörülerin yeniden kullanılabileceğini yakalama
    • YAML frontmatter ile metadata, tag ve kategoriler ekleyerek aranabilir hale getirme
    • Yeni örüntüleri CLAUDE.md dosyasına ekleme ve gerekirse yeni ajan oluşturma
    • "Sistem bir dahaki sefere bu sorunu otomatik olarak yakalayabilir mi?" sorusunu doğrulama

Eklenti yapısı

• 26 uzman ajan: İnceleme (14 adet), araştırma, tasarım, iş akışı, dokümantasyon vb.; her biri belirli görevlere odaklı
• 23 iş akışı komutu: Ana döngü + yardımcı araçlar
• 13 beceri: Ajan-yerel mimari, stil kılavuzu vb. ile alan uzmanlığı sağlar
• Claude Code, OpenCode (deneysel) ve Codex’e (deneysel) sıfır yapılandırmayla kurulabilir

• Dosya yapısı

  • CLAUDE.md: Ajanın her oturum başında okuduğu en önemli dosya; tercihleri, örüntüleri ve proje bağlamını saklar
  • docs/solutions/: Çözülen sorunların aranabilir belgeler olarak birikmesiyle kurumsal bilgi (institutional knowledge) oluşturur
  • docs/brainstorms/: brainstorm komutu çıktılarının saklandığı yer
  • docs/plans/: plan komutu çıktılarının saklandığı yer
  • todos/: İş öğelerini öncelik ve duruma göre takip eder

Temel komutlar

• /workflows:brainstorm

  • Ne yapılacağının net olmadığı durumlarda kullanılan komut
  • Hafif bir repo araştırmasının ardından amaç, kullanıcı, kısıtlar ve edge case’leri tek tek sorarak netleştirir
  • Yapay zeka yaklaşım önerir; sonuçlar docs/brainstorms/ içine kaydedilir ve /workflows:plan aşamasına devredilir

• /workflows:plan

  • İstenen şeyi açıklarsanız bir uygulama planı döndürür
  • Paralel çalışan 3 araştırma ajanı devreye girer: repo-research-analyst (kod tabanı örüntüleri), framework-docs-researcher (belgeler), best-practices-researcher (sektör standartları)
  • spec-flow-analyzer ajanı kullanıcı akışını ve edge case’leri analiz eder
  • ultrathink modu etkinleştirildiğinde /deepen-plan otomatik çalışır ve 40’tan fazla paralel araştırma ajanı devreye alınır

• /workflows:work

  • Ajanın gerçek kodu yazdığı aşama
  • 4 fazdan oluşur: quick start (Git worktree oluşturma ve branch ayarlama) → execute (ilerleme takibiyle görev bazlı uygulama) → quality check (isteğe bağlı olarak 5’ten fazla inceleyici ajan çalıştırma) → ship it (linting çalıştırma, PR oluşturma)

• /workflows:review

  • PR, 14’ten fazla uzman ajan tarafından paralel ve eşzamanlı biçimde incelenir
  • Güvenlik (security-sentinel), performans (performance-oracle), mimari (architecture-strategist), veri bütünlüğü (data-integrity-guardian), kod kalitesi (code-simplicity-reviewer), framework’e özel inceleyiciler (DHH-rails, Kieran-rails/python/typescript), dağıtım doğrulaması, frontend race condition ve ajan-yerel inceleyici gibi bileşenleri içerir
  • Çıktı, P1 (kritik), P2 (önemli), P3 (küçük) olarak sınıflandırılmış tek bir öncelik listesi olur
  • /resolve_pr_parallel komutuyla bulgular otomatik düzeltilir (öncelik P1’dedir, her düzeltme yalıtılmış yürütülür)
  • /triage komutuyla bulgular tek tek onaylanabilir, atlanabilir veya özelleştirilerek filtrelenebilir

• /workflows:compound

  • Çözülen sorunları gelecekte başvurmak üzere belgelendirir
  • Paralel çalışan 6 alt ajan devreye girer: context analyzer, solution extractor, related docs finder, prevention strategist, category classifier, documentation writer
  • YAML frontmatter içeren aranabilir Markdown üretir

• /lfg

  • Bir özelliği tarif ettiğinizde ajan planlama, uygulama ve inceleme dahil her şeyi yaparak merge edilebilir bir PR sunar
  • plan → deepen-plan → work → review → resolve findings → browser tests → feature video → compound şeklindeki tam hattı zincirler
  • Plan onaylandığında durakladıktan sonra otonom biçimde çalışır ve tüm aşamalarda 50’den fazla ajanı devreye alır

Vazgeçilmesi gereken 8 inanç

• "Kod elle yazılmalıdır"

  • Asıl gereksinim, bakımı yapılabilir ve doğru problemi çözen iyi kod yazmaktır; kimin yazdığı önemli değildir

• "Her satır manuel olarak gözden geçirilmelidir"

  • Manuel satır satır inceleme, kalite güvencesinin yalnızca bir yoludur; aynı sorunları yakalayan otomatik sistemler de geçerlidir
  • Sonuca güvenemiyorsanız bunu elle yaparak telafi etmeye çalışmamalı, sistemi düzeltmelisiniz

• "Çözüm mühendisten gelmelidir"

  • Yapay zeka yaklaşım araştırması, ödünleşim analizi ve seçenek önerileri yapabildiği için, mühendisin rolü beğeni (taste) eklemek olur — bu kod tabanı, bu ekip ve bu bağlam için hangi çözümün uygun olduğuna karar vermek

• "Kod ana çıktıdır"

  • Kod üreten sistem, tek tek kod parçalarından daha değerlidir
  • Tek bir mükemmel uygulamadan çok, istikrarlı şekilde iyi uygulamalar üreten süreç önemlidir

• "Kod yazmak temel iştir"

  • Geliştiricinin işi değer sunmaktır (ship value) ve kod bunun sadece girdilerinden biridir
  • Planlama, inceleme ve sistemi eğitme de işin parçasıdır

• "İlk deneme iyi olmalıdır"

  • İlk denemede hata oranı %95, ikincide bile %50'dir
  • Bu bir başarısızlık değil süreçtir; üçüncü denemenin ilkinden daha hızlı tamamlanması için hızlı iterasyona odaklanmak gerekir

• "Kod kendini ifade etme biçimidir"

  • Kod ekibe, ürüne ve kullanıcılara aittir; kodu kişisel ifade olarak görmezseniz geri bildirim kabul etmek, refactor yapmak ve kalite tartışmaları kolaylaşır

• "Ne kadar çok yazarsam o kadar çok öğrenirim"

  • Bugün kas hafızasından çok kavrayış önemlidir
  • 10 yapay zeka implementasyonunu gözden geçiren geliştirici, 2 tanesini kendisi yazan geliştiriciden daha fazla örüntü anlar

Geçiş sürecindeki psikolojik zorluklar

• Yazma azalınca daha az çalışıyormuş gibi hissetmek: Oysa ajana talimat vermek, implementasyondan daha fazla düşünme gerektirebilir
• Otonom yürütmeden duyulan kaygı: Bu, kontrolü bırakmak değil; kısıtları, kuralları ve inceleme süreçlerini kontrol olarak sisteme kodlamak demektir
• "Bunu gerçekten ben mi yaptım?" sorusu: Planlama, inceleme ve kalite çıtasını sağlama zaten işin kendisidir; yapay zeka sadece yazım kısmını üstlenir

Benimsenmesi gereken inançlar

• Beğeniyi sistemden çıkarmak

  • İsimlendirme kuralları, hata işleme kalıpları, test yaklaşımı gibi geliştirici tercihleri genellikle belgelenmez, kıdemli mühendislerin zihninde bulunur
  • Bu tercihleri CLAUDE.md veya AGENTS.md içine yazmak ve inceleme, test, dağıtım için uzman ajanlar ile beceriler oluşturmak gerekir; böylece yapay zeka, onaylanabilecek kodu doğrudan üretebilir

• 50/50 kuralı

  • Mühendislik zamanının %50'si özellik geliştirmeye, %50'si sistemi iyileştirmeye ayrılmalıdır
  • Geleneksel olarak dağılım %90 özellik / %10 diğer işlerdir; oysa inceleme ajanı üretmek, örüntüleri belgelemek, test üreticileri kurmak gibi yatırımlar gelecekteki özellikleri daha kolay hale getirir
  • İnceleme ajanına yapılan 1 saatlik yatırım, 1 yıl boyunca 10 saat inceleme süresi kazandırabilir

• Sürece güvenmek ve güvenlik ağları kurmak

  • Yapay zeka destekli çalışma ölçeklenecekse insanların her satırı incelemesi mümkün olmayacağından, test, otomatik inceleme ve izleme gibi guardrail'ler kurmak kritik hale gelir
  • Çıktıya güvenmiyorsanız manuel incelemeye dönmek yerine, o aşamayı güvenilir kılacak sistemi eklemelisiniz

• Ortamı ajana yerel olacak şekilde kurmak

  • Geliştiricinin görebildiği veya yapabildiği her şeyi ajan da yapabilmelidir: test çalıştırma, production log'larını görme, ekran görüntüsüyle debug etme, PR oluşturma vb.
  • Ajana izin verilmeyen her iş, sizin tarafınızdan manuel yapılmak zorunda kalır

• Paralelleştirmeden yararlanmak

  • Geçmişte darboğaz insan dikkatiydi (aynı anda tek görev), artık yeni darboğaz compute'tur (aynı anda çalışabilecek ajan sayısı)
  • Birden çok ajanı, birden çok özelliği aynı anda çalıştırın; inceleme, test ve dokümantasyonu paralel yürütün

• Plan yeni koddur

  • Plan dokümanı artık en önemli çıktıdır
  • Önce kod yazıp sonra belgelemek yerine, önce plan yazarsanız ajan bunu kod üretme, test etme ve doğrulama için tek doğru kaynak olarak kullanabilir
  • Fikirleri kağıt üzerinde düzeltmek, kod içinde düzeltmekten daha ucuzdur

• Temel ilkelerin özeti

  • Her iş birimi, sonraki işi kolaylaştırmalıdır
  • Beğeni, incelemede değil sistemin içine gömülü olmalıdır
  • İşi kendiniz yapmak yerine sistemi eğitmelisiniz
  • İnceleme süreci değil güvenlik ağları kurmalısınız
  • Ortamı ajana yerel olacak şekilde yapılandırmalısınız
  • Bileşik etki mantığını her yerde uygulamalısınız
  • Delege etmenin rahatsızlığını kabul edin ve mükemmel ama ölçeklenemez sonuçlar yerine kusurlu ama ölçeklenebilir sonuçları seçin
  • Daha az kod yazın ve daha fazla değer sunun
  • Bu ilkeler, mühendisliğin ötesinde tasarım, araştırma, yazı gibi beğeni ve bağlamın kodlanmasının fayda sağladığı tüm alanlara genişletilebilir

Geliştirici gelişim aşamaları (5 basamaklı merdiven)

• Stage 0: Manuel geliştirme

  • Yapay zeka olmadan kodu satır satır yazmak, dokümanlar ve Stack Overflow ile araştırma yapmak, print ifadeleriyle debug etmek
  • On yıllardır iyi yazılım üretildi, ancak 2025'te bu yeterince hızlı değil

• Stage 1: Sohbet tabanlı asistanlık

  • ChatGPT, Claude, Cursor vb. araçlara soru sorup kod snippet'leri almak, işe yarayanları kopyalayıp yapıştırmak
  • Yapay zeka araştırmayı ve boilerplate üretimini hızlandırır ama her satırı bizzat gözden geçirerek tam kontrolü korursunuz

• Stage 2: Ajanik araçlar + satır satır inceleme

  • Claude Code, Cursor Composer, Copilot Chat gibi ajanik araçlar dosyaları okuyup kod tabanında doğrudan değişiklik yapar
  • Ajanın önerdiği her şeyi onaylayan ya da reddeden kapı bekçisi rolündesinizdir
  • Geliştiricilerin çoğu bu aşamada takılı kalır ve yapay zekaya delege etmenin avantajlarından yararlanamaz

• Stage 3: Önce plan, PR düzeyinde inceleme

  • Her şeyin değiştiği aşama budur: gereksinimler, yaklaşım ve edge case'leri içeren ayrıntılı plan yapay zeka ile birlikte hazırlanır
  • Plan yapıldıktan sonra yapay zeka gözetimsiz şekilde implementasyon yapar, çıktı ise PR olarak incelenir
  • Compound Engineering burada başlar — her döngüdeki planlama, implementasyon ve inceleme, sistemi eğiterek bir sonraki döngüyü daha hızlı ve kolay hale getirir

• Stage 4: Fikir → PR (tek makine)

  • Siz fikri verirsiniz; ajan kod tabanı araştırmasını, planlamayı, implementasyonu, testi, öz incelemeyi, sorun çözmeyi ve PR oluşturmayı tamamını üstlenir
  • Katılımınız fikir verme, PR inceleme ve merge etme olmak üzere 3 adıma iner
  • Ancak hâlâ tek bir bilgisayarda aynı anda yalnızca bir iş çalıştırılır

• Stage 5: Paralel bulut yürütmesi (çoklu cihaz)

  • Çalıştırmayı buluta taşıyarak paralel yürütme sağlanır
  • 3 özellik için 3 ajan aynı anda çalıştırılır, PR'ler hazır olduğunda gözden geçirilir
  • Ajanlar geri bildirimi izleyip proaktif biçimde düzeltme önermeye kadar ilerleyebilir
  • Artık bireysel katkı sağlayan değil, ajan filosunu yöneten kişi olursunuz

Seviye atlama rehberi

• 0 → 1: İş birliğine başla

  • Bir araç seç (Cursor with Opus 4.5 veya Claude Code gibi) ve her gün kullan
  • Kod yazmadan önce AI'dan mevcut kodu açıklamasını isteyerek anlayışını doğrula
  • Testler, yapılandırma dosyaları, tekrar eden fonksiyonlar gibi boilerplate işlerden başlayarak devret
  • Öğrenmek için tüm satırları gözden geçir
  • Bileşik getiri işi: İyi çalışan prompt'ları sürekli kaydet

• 1 → 2: Ajan erişimine izin ver

  • Agentic moda geç ve ajana dosya sistemine erişim izni ver
  • "Bu fonksiyona test ekle" gibi tek dosyalı, tek amaçlı dar değişikliklerle başla
  • Her aksiyonu onaylayıp reddederek güven sezgisi oluştur
  • Diff'i inceleyerek değişen kısımlara odaklan
  • Bileşik getiri işi: CLAUDE.md dosyası oluştur, ajan hata yaptığında not ekle

• 2 → 3: Plana güven (kritik dönüşüm)

  • Gereksinimleri, yaklaşımı ve edge case'leri açık bir plan olarak yaz
  • AI'ın kod tabanını okuyup kalıpları bulmasına ve yaklaşım önermesine izin ver
  • Plan yazıldıktan sonra uygulamayı ajana bırak ve tamamlanana kadar başından ayrıl
  • Tek tek adımlar ya da kod satırları yerine PR seviyesinde inceleme yap
  • Bileşik getiri işi: Her uygulamadan sonra planın kaçırdıklarını belgele

• 3 → 4: Talimat değil sonuç ver

  • "Yeni yorumlara e-posta bildirimi ekle" gibi sonucu (outcome) ver, nasıl uygulanacağına ajan karar versin
  • Ajan kod tabanını bildiği ve araştırma yaptığı için plan da ajanın sorumluluğudur
  • Uygulamadan önce yaklaşımı inceleyerek yanlış yönü erken engelle
  • Bileşik getiri işi: İyi çalışan sonuç odaklı talimatlardan bir kütüphane oluştur

• 4 → 5: Her şeyi paralelleştir

  • Çalıştırmayı buluta taşıyarak yerel makine darboğazını ortadan kaldır
  • 3 özelliği aynı anda 3 ajana ata
  • Fikirleri, hataları ve iyileştirmeleri bir kuyruk halinde düzenle; ajan bunları sırayla işlesin
  • Ajanın kullanıcı geri bildirimlerini izlemesini ve özellikleri kendiliğinden önermesini etkinleştir
  • Bileşik getiri işi: Paralel yürütülebilen işleri ve doğası gereği seri olan işleri ayırt edip belgele

AI çıktısını onaylamadan önce 3 soru

• "Buradaki en zor karar neydi?" — AI'ın zorlayıcı kısımları ve karar noktalarını ortaya koymasını sağlar
• "Hangi alternatifleri reddettin ve neden?" — Değerlendirilen seçenekleri görerek yanlış seçimleri yakalamayı sağlar
• "En az emin olduğun kısım hangisi?" — LLM'in kendi zayıf yönlerini kabul etmesini sağlar, ancak bunu doğrudan sormak gerekir

Ajan yerel mimarisi

• Asıl mesele, ajana geliştiriciyle aynı yetkinlikleri vermektir
• Ajan testleri çalıştıramıyorsa bunları sizin çalıştırmanız gerekir; log'ları göremiyorsa sizin hata ayıklamanız gerekir; bu yüzden izin verilmeyen her yetenek manuel işe dönüşür

• Ajan yerel kontrol listesi

  • Geliştirme ortamı: yerel uygulamayı çalıştırma, test paketini çalıştırma, linter ve type checker çalıştırma, DB migration, geliştirme verisini seed etme
  • Git işlemleri: branch oluşturma, commit, remote'a push, PR oluşturma, PR yorumlarını okuma
  • Hata ayıklama: yerel/production log'larını görüntüleme (salt okunur), UI ekran görüntüleri, ağ isteklerini inceleme, hata izleme araçlarına (Sentry vb.) erişim

• Ajan yereli aşamalı olarak benimseme

  • Level 1 (temel geliştirme): dosya erişimi, test çalıştırma, Git commit — temel Compound Engineering mümkün
  • Level 2 (tam yerel): tarayıcı, yerel log'lar, PR oluşturma erişimi — Stage 3~4 mümkün
  • Level 3 (production görünürlüğü): production log'ları (salt okunur), hata izleme, izleme dashboard'ları — ajan proaktif hata ayıklama yapabilir
  • Level 4 (tam entegrasyon): ticket sistemi, dağıtım yetenekleri, harici servis entegrasyonları — Stage 5 mümkün

• Ajan yerel zihniyeti

  • Özellik geliştirirken: "Ajan bununla nasıl etkileşime girecek?"
  • Hata ayıklarken: "Ajanın neyi görebilmesi gerekiyor?"
  • Dokümantasyon yazarken: "Ajan bunu anlayabilecek mi?"

Skip Permissions

• Claude Code'un --dangerously-skip-permissions bayrağı, her aksiyonda sorulan izin isteklerini devre dışı bırakır
• Adının bilerek korkutucu seçilmesinin nedeni, kullanmadan önce dikkatle düşünmeye yöneltmektir

• Ne zaman kullanılmalı

  • Kullanım önerilir: iyi bir plan ve inceleme sistemi varsa, sandbox ortamında çalışılıyorsa, hıza ihtiyaç varsa
  • Kaçınılmalı: öğrenme aşamasındayken (izin istekleri anlamaya yardımcı olur), production kodunda çalışırken, rollback mekanizması yoksa

• İzin atlandığında güvenlik mekanizmaları

  • Git güvenlik ağıdır: ajanın yaptığı işler Git'e kaydedilir ve git reset --hard HEAD~1 ile geri alınabilir
  • Testler hataları yakalar: merge öncesinde test çalıştır
  • Merge öncesi inceleme: uygulama sırasında izinler atlanabilir ama son inceleme mutlaka yapılmalıdır
  • Worktree ile riski izole et: riskli işleri izole bir dizinde dene

• Verimlilik hesabı

  • İzinler atlanmadığında yaklaşık her 30 saniyede bir prompt çıkar; her seferinde "y" girmek odak kaybına yol açar
  • İzinler atlandığında flow durumunu korumak mümkün olur; bu da ara sıra rollback yapma riskinden çok daha büyük bir zaman tasarrufuyla 5~10 kat daha hızlı iterasyon sağlar

Tasarım iş akışı

• Baby App yaklaşımı

  • Test, mimari ve breaking değişiklik kaygısı olmadan özgürce iterasyon yapılabilen tek kullanımlık bir proje (baby app) oluştur
  • Tasarım tatmin edici olduğunda renkleri, aralıkları, tipografiyi ve bileşen kalıplarını çıkarıp asıl projeye aktar

• UX keşif döngüsü

  • Birden fazla sürüm üret, click-through yap ve kullanıcılara işlevsel prototipler paylaşarak geri bildirim topla
  • Figma mockup'larının aksine gerçekten tıklanabilir
  • Prototipler öğrenme içindir; sonrasında uygun bir planla sıfırdan yeniden inşa edilir

• Tasarımcıyla iş birliği: Compound akışı

  • Geleneksel akış: tasarımcı mockup'ı → geliştiricinin yorumu → tekrar tekrar düzeltme
  • Compound akışı: tasarımcı Figma mockup'ı → Figma linkini /plan'e ver → AI uygular → figma-design-sync ajanı uygulamanın mockup ile uyuşup uyuşmadığını kontrol eder → tasarımcı ekran görüntüsü yerine canlı sürümü inceler

• Tasarım zevkini kodlamak

  • Tasarımcıyla birkaç özelliği birlikte geliştirirken keşfedilen kalıpları (tercih edilen renkler, form düzenleri vb.) skill dosyasına kaydet
  • AI, tasarımcı olmadan da tasarımcının zevkine uygun tasarımlar üretebilir

• Tasarım ajanları

  • design-iterator: mevcut tasarım ekran görüntüsünü analiz eder, iyileştirmeleri tekrarlayarak kademeli olarak rafine eder
  • figma-design-sync: tasarımı Figma'dan alır, uygulamayla karşılaştırır ve farkları otomatik olarak düzeltir
  • design-implementation-reviewer: uygulamanın Figma özelliklerine uyup uymadığını denetler ve görsel hataları kullanıcıya ulaşmadan yakalar

Vibe coding

• Kodun kendisini değil, yalnızca sonucu isteyen kişiler için bir yaklaşım: ürün yöneticileri, tasarımcılar, kişisel projeler vb.
• Merdiveni atlayıp doğrudan Stage 4'e geç: ne istediğini açıkla → ajan planı, kodu, testleri, incelemeyi ve PR'ı tamamen üstlensin
• Uygun olduğu durumlar: kişisel projeler, prototipler, deneyler, "Bu mümkün mü?" araştırması, iç araçlar, UX keşfi
• Uygun olmadığı durumlar: kullanıcıları olan production sistemler, başkalarının bakımını üstleneceği kodlar, güvenliğe duyarlı uygulamalar, performansın kritik olduğu sistemler

• Vibe coding paradoksu

  • Vibe coding, ironik biçimde planlama becerisini geliştirebilir
  • Ne yapılacağını bilmediğinde bir prototip üret, kullanıcı geri bildirimi topla, ardından her şeyi silip uygun bir planla yeniden başla
  • En iyi dağılım: vibe coding ile keşfet, spek ile inşa et — nihai uygulamada her zaman spek kazanır

Ekip iş birliği

• Yeni takım dinamikleri

  • Geleneksel: kişi A kod yazar → kişi B inceler → PR yorumları tartışılır → onaydan sonra merge edilir
  • Compound: kişi A plan oluşturur → AI uygular → AI ajanı inceleme yapar → kişi B AI incelemesini inceler → insan onayından sonra merge edilir

• Takım standartları

  • Plan onayı: sessizlik onay anlamına gelmez, bu yüzden uygulamadan önce açık onay gerekir
  • PR sahipliği: kodu kimin yazdığından bağımsız olarak işi başlatan kişi PR'ın sahibidir; plan kalitesi, inceleme, düzeltmeler ve merge sonrası etkilerden sorumludur
  • İnsan incelemesinin odağı: AI inceleme ajanı PR'ı zaten analiz ettiğinden, insan incelemesi sözdizimi hataları, güvenlik, performans veya stil yerine niyet (intent) odaklı olmalıdır — "Üzerinde anlaştığımız şeyle uyumlu mu?", "Yaklaşım makul mü?", "İş mantığıyla ilgili bir sorun var mı?"

• İletişim kalıpları

  • Varsayılan olarak asenkron: plan oluşturmak, incelemek ve onaylamak için toplantı gerekmez, "Plan dokümanını oluşturdum, bugün içinde yorum rica ederim"
  • Açık handoff: durum, tamamlanan işler, kalan işler, bağlam ve nasıl devam edileceği dahil edilir

• Ölçekleme kalıpları

  • Net sahiplik + asenkron güncellemeler: her ana özellik için bir sahip planlama, izleme, inceleme, merge ve takım güncellemelerinden sorumludur
  • Feature flag + küçük PR'lar: herkes ne kadar hızlı dağıtım yaparsa merge çatışmaları da o kadar artar; küçük parçalar halinde dağıtım yapın, ana dala sık merge edin ve çatışmaları hemen çözün
  • Compound dokümantasyonu = kurumsal olmayan örtük bilgi (tribal knowledge): "Sarah'ya sor, auth konusunu iyi bilir" demek yerine, Sarah /compound çalıştırıp çözümü dokümante ederse herkes arayıp bulabilir

Kullanıcı araştırması

• Araştırma-geliştirme açığı

  • Geleneksel: araştırmacı görüşme yapar → rapor yazar → Google Drive'a bırakılır → geliştirici rapora bakmaz → özellik kullanıcı ihtiyaçlarını yansıtmaz
  • Compound: araştırma yapılandırılmış içgörüler üretir → içgörüler plan bağlamı olarak kullanılır → AI planlama yaparken içgörülere başvurur → kullanım verileri içgörüleri doğrular → içgörüler bileşik şekilde birikir

• Araştırmanın yapılandırılması

  • Ham görüşme notlarını AI'ın kullanabilmesi için yapılandırılmış Markdown'a dönüştürün: katılımcı bilgileri, temel içgörüler, alıntılar, çıkarımlar ve güven düzeyi (n/5 katılımcı) dahil

• Persona dokümanları

  • Hedefler, şikayetler ve alıntılar içeren persona dokümanları oluşturun ki AI bunlara başvurabilsin

• Araştırma temelli planlama

  • /workflows:plan çalıştırılırken araştırma bağlamını ekleyin (görüşme sonuçları, persona kalıpları, mevcut pain point'ler); böylece araştırma içgörüleri doğrudan özelliğe bağlanır

Veri kalıplarını çıkarma

• Kullanıcıların ürünü nasıl kullandığı, ne inşa edilmesi gerektiğine dair ipuçları verir

• Dikkat edilmesi gereken kalıp türleri

  • Aşırı kullanım kalıpları: beklenenden çok daha fazla kullanılan özellikler, aynı sayfaya tekrar tekrar dönüş
  • Zorluk kalıpları: basit bir sayfada yüksek kalma süresi, aynı aksiyonun tekrar tekrar denenmesi, hata→yeniden deneme→hata döngüsü
  • Geçici çözüm kalıpları: veriyi bir yerden dışa aktarıp başka yere yeniden içe aktarmak, ekranlar arasında kopyala-yapıştır yapmak, karşılaştırma için aynı anda birden fazla sekmeyi açık tutmak
  • Terk etme kalıpları: akıştan çıkma, başlanmış ama tamamlanmamış özellikler

• Kalıptan özelliğe

  • Kullanıcılar tablolar arasında haftada 50 kez kopyala-yapıştır yapıyor → "B tablosuna senkronize et" düğmesi olarak ürünleştirin
  • Kullanıcılar "template" proje oluşturup kopyalıyor → birinci sınıf template desteği olarak ürünleştirin

Metin yazımı

• Plana metinleri dahil etme

  • Çoğu takım metinleri, özellik oluşturulduktan sonra doldurulan ikincil bir iş olarak görür; oysa metin de kullanıcı deneyiminin bir parçasıdır
  • Plan aşamasından itibaren e-posta başlıkları, başarı mesajları, hata mesajları gibi kullanıcıya görünen metinleri dahil ederseniz, AI uygulama yaparken metinler zaten hazır olur

• Ses tonunu kodlamak

  • İlkeleri (insan gibi konuşmak, hata mesajlarının yardımcı olması, kısa cümleler, net kelimeler) ve kaçınılması gereken kelimeleri (Invalid → didn't work, Error → ne olduğunu açıklayın gibi) bir skill dosyası olarak yazın

• Metin incelemesi

  • /workflows:review sürecine metin incelemesini ekleyin: netlik, yardımcı olma, ton, tutarlılık olmak üzere 4 ölçüte göre değerlendiren bir copy-reviewer ajanı

Ürün pazarlaması

• Compound akışı

  • Mühendis, ürünün değer önerisini içeren bir plan oluşturur → AI özelliği uygular → AI plandan release notes üretir → release notes'tan sosyal medya gönderisi üretir → Playwright ile ekran görüntüleri otomatik yakalanır → mühendis inceleyip her şeyi birlikte yayınlar
  • Her şey tek bir yerde aktığı için handoff gerekmez, boşluk oluşmaz

• Release notes üretimi

  • AI planı, kod değişikliklerini ve testleri birlikte gördüğü için tam olarak neyin geliştirildiğini anlayabilir
  • Önce kullanıcı faydası, 1 somut örnek dahil, breaking change'den bahsedin, 200 kelimeyi aşmayın

• Changelog üretimi

  • /changelog komutuyla main'e yapılan son merge'leri kontrol edin, her planı/PR'ı okuyup çekici bir changelog oluşturun

• Otomatik ekran görüntüleri

  • Playwright kullanarak pazarlama için ekran görüntülerini otomatik yakalayın; mühendislik ekibinden ekran görüntüsü istemeye gerek kalmaz ve eski ekran görüntüsü sorunu ortadan kalkar