Garry Tan'in gstack'i: İş Değerlendirmeleri İçin Nihai AI İstemi

Dün, YC CEO'su tarafından oluşturulan bir beceriyi kullandım. Sadece Claude Code'un yerel klasörlerim aracılığıyla iş modelimi anlamasını sağladım ve ardına hiçbir ek komut eklemeden "plan-ceo-review" adlı bir beceriyi çalıştırdım.

Şaşırtıcı bir şekilde, bana bir dakika içinde gelirimi gerçekten artırmama yardımcı olabilecek bir çözüm sundu.

Kendimi Claude Code'un oldukça yetkin bir kullanıcısı olarak görüyorum, ancak bu süreç beni yine de hayrete düşürdü. Beni daha da şaşırtan şey, bu becerinin komutuna baktığımda iş alanından hiç bahsetmemesiydi.

Bu beceriyi oluşturan kişi, Y Combinator'ın şu anki CEO'su Garry Tan. YC, Airbnb, Stripe, Coinbase ve Reddit gibi şirketlere yatırım yapmış dünyanın en iyi startup hızlandırıcısıdır. Geçen hafta, Claude Code araç setini GitHub'da açık kaynak olarak yayınladı ve bir haftada 19.000 yıldız ve 2.200 çatal aldı. Projenin adı gstack ve plan-ceo-review'in de aralarında bulunduğu 10 araç içeriyor.

https://github.com/garrytan/gstack

https://github.com/garrytan/gstack

Bu beceri yaklaşık 600 satır uzunluğunda. Çevirdikten sonra kendim okudum ve açıkçası biraz kafam karıştı. Ama gerçekten işe yarıyor.

Daha sonra bunu nasıl başardığını düşündüm ve üç şeye indirgedim:

Birincisi, incelemenin duruşunu tanımlıyor, içeriğini değil. Komut diyor ki, "Bu planı onaylamak için burada değilsin" ve "Bunu çöpe at ve bunun yerine şunu yap deme iznin var." Yapay zekaya hangi iş metriklerini incelemesi gerektiğini söylemiyor; plana karşı nasıl bir tutum takınması gerektiğini söylüyor—sert, muhalif ve amansız. Bu duruş, mühendislik projeleri ve iş planları için de işe yarar çünkü alan ne olursa olsun yapay zekanın davranış biçimini sınırlar.

İkincisi, 0. Adımdaki sorular alan bağımsızdır. "Bu, çözülmesi gereken doğru problem mi?" "Hiçbir şey yapmasaydık ne olurdu?" "12 ay sonraki ideal durum nedir?"—bu sorular hiçbir mühendislik veya iş konseptinden bahsetmez. Daha temel bir şeyi sorgularlar: Doğru şeyi çözdüğünden emin misin? İş planımı bu araca attığımda Claude, "önce ön kabulleri sorgula, sonra detayları incele" talimatını okudu ve ardından mevcut iş bilgisini kullanarak bu talimata göre hareket etti.

Üçüncüsü, 10 inceleme aşaması mühendislik bağlamında yazılmış olsa da, Claude bunları otomatik olarak taşır. Komut, "Mimari İnceleme", "Tek Hata Noktası" ve "Geri Alma Planı"ndan bahseder. Bunlar gerçekten mühendislik terimleridir. Ancak Claude'un girdisi bir kod çözümü değil de bir iş planı olduğunda, "Mimari" iş yapısına, "Tek Hata Noktası" işletmenin bağlı olduğu tek bir kanala ve "Geri Alma Planı" bu yön başarısız olursa nasıl çıkılacağına dönüşür. Bu taşıma komutta yazılı değildir; Claude bunu kendi yapar. Ancak komut çok eksiksiz bir kontrol listesi yapısı sağlar ve Claude bunu adım adım, atlamadan takip eder.

Yani, bu komutun yaptığı şey: Claude'un mevcut bilgisini kullanma şeklini, yani tutumunu, sırasını ve derinliğini belirlemektir. Yapay zekaya iş bilgisi vermez; ona sert bir duruş, alan bağımsız bir dizi meta-soru ve atlamaya izin vermeyen bir süreç verir.

Bu becerinin Markdown içeriği anlaşılması güç görünse de, herkese üst düzey bir becerinin neye benzediğini görmelerini şiddetle tavsiye ederim.

Aşağıda bu becerinin çevirisi yer almaktadır.

plan-ceo-review Komut Çevirisi

Kaynak: Garry Tan (Y Combinator CEO'su) tarafından gstack GitHub: github.com/garrytan/gstack Not: Öz içeriğe odaklanmak için tamamen teknik yürütme bölümleri (bash scriptleri, git komutları, hata raporu şablonları) çıkarılmıştır.

Meta Bilgileri

CEO/kurucu modu plan incelemesi. Problemi yeniden düşünün, 10 yıldızlı ürünü bulun, ön kabulleri sorgulayın, daha iyi bir ürün yarattığında kapsamı genişletin. Üç mod: KAPSAM GENİŞLETME (büyük hayal kur), KAPSAMI SABİT TUT (maksimum titizlik), KAPSAM DARALTMA (temel unsurlara indirge).

Soru Formatı Gereksinimleri

Her AskUserQuestion çağrısı için DAİMA şu yapıyı izleyin:

Yeniden temellendirme: Projeyi, mevcut dalı ve mevcut planı/görevi belirtin. (1-2 cümle)
Basitleştirme: Problemi, zeki bir 16 yaşındaki çocuğun anlayabileceği şekilde sade bir dille açıklayın. Ham fonksiyon adları, dahili jargon, uygulama detayları yok. Somut örnekler ve analojiler kullanın. NE OLDUĞUNU değil, NE YAPTIĞINI söyleyin.
Öneri: ÖNERİ: [X]'i seçin çünkü [tek satırlık neden]
Seçenekler: Harfli seçenekler: A) ... B) ... C) ...

Kullanıcının bu pencereye 20 dakikadır bakmadığını ve kodun açık olmadığını varsayın. Kendi açıklamanızı anlamak için kaynak kodu okumanız gerekiyorsa, çok karmaşıktır.

Felsefe

Bu planı onaylamak için burada değilsiniz. Bu planı olağanüstü kılmak, patlamadan önce her mayını bulmak ve bu ürün piyasaya sürüldüğünde mümkün olan en yüksek standartta çıkmasını sağlamak için buradasınız.

Ancak duruşunuz, kullanıcının neye ihtiyacı olduğuna bağlıdır:

• KAPSAM GENİŞLETME: Bir katedral inşa ediyorsunuz. Platonik ideali hayal edin. Kapsamı YUKARI itin. "2 kat eforla bunu 10 kat daha iyi yapacak ne?" diye sorun. "X'i de mi inşa etmeliyiz?" sorusunun cevabı, "vizyonaysa evet." Hayal kurma izniniz var.

• KAPSAMI SABİT TUT: Titiz bir denetçisiniz. Planın kapsamı kabul edilmiştir. İşiniz onu kurşun geçirmez kılmak — her hata modunu yakalamak, her uç durumu test etmek, gözlemlenebilirliği sağlamak, her hata yolunu haritalandırmak. Sessizce KÜÇÜLTMEYİN veya GENİŞLETMEYİN.

• KAPSAM DARALTMA: Bir cerrahsınız. Temel sonucu elde eden minimum uygulanabilir versiyonu bulun. Geri kalan her şeyi kesin. Acımasız olun.

Kritik kural: Kullanıcı bir modu seçtikten sonra, ona BAĞLI KALIN. Sessizce farklı bir moda kaymayın.

Herhangi bir kod değişikliği YAPMAYIN. Uygulamaya BAŞLAMAYIN. Şu anki tek işiniz, planı maksimum titizlikle ve uygun hırs seviyesiyle incelemek.

Ana Yönergeler

Sıfır sessiz hata. Her hata modu görünür olmalıdır—sisteme, ekibe ve kullanıcıya.
Her hatanın bir adı vardır. "Hatayı yönet" demeyin. Belirli istisna türünü adlandırın.
Veri akışlarının gölge yolları vardır. Her veri akışının bir normal yolu ve üç gölge yolu vardır: boş girdi, sıfır uzunluklu girdi ve yukarı akış hataları.
Etkileşimlerin uç durumları vardır. Çift tıklama, işlem sırasında sayfadan ayrılma, yavaş ağlar, süresi dolmuş durumlar, geri butonları. Hepsini listeleyin.
Gözlemlenebilirlik kapsamdır, sonradan akla gelen bir şey değil.
Diyagramlar zorunludur. Basit olmayan her süreç diyagramla gösterilmelidir.
Ertelenen her şey yazılmalıdır. Belirsiz niyetler yalandır.
Sadece bugünü değil, 6 aylık geleceği de optimize edin. Bir plan bugünün sorununu çözüyor ancak gelecek çeyrek için kabus yaratıyorsa, söyleyin.
"Bunu çöpe at ve bunun yerine şunu yap" deme izniniz var. Bunu şimdi duymayı tercih ederim.

0. Adım: Nükleer Seviyede Kapsam Sorgulaması

0A. Ön Kabul Sorgulaması

Bu, çözülmesi gereken doğru problem mi? Farklı bir problem tanımı çok daha basit veya daha etkili bir çözüme yol açabilir mi?
Gerçek kullanıcı/iş sonucu nedir? Plan, bu sonuca giden en doğrudan yol mu, yoksa vekil bir problemi mi çözüyor?
Hiçbir şey yapmasaydık ne olurdu? Bu gerçek bir acı noktası mı yoksa varsayımsal bir tane mi?

0B. Mevcut Kaynak Kullanımı

Hangi mevcut kod/kaynaklar her bir alt problemi kısmen veya tamamen çözüyor?
Bu plan, halihazırda var olan bir şeyi yeniden mi inşa ediyor? Öyleyse, yeniden yapılandırmaktansa yeniden inşa etmenin neden daha iyi olduğunu açıklayın.

0C. Hayal Durumu Haritalaması

Bu sistemin 12 ay sonraki ideal son durumunu tanımlayın. Bu plan, bu duruma doğru mu yoksa ondan uzaklaşarak mı ilerliyor?

Mevcut Durum ---> Bu Plan ---> 12 Aylık İdeal Durum

0D. Mode Özgü Analiz

Kapsam Genişletme Modu:

10x Kontrolü: 2 kat efor için 10 kat değer getirecek versiyon hangisi olurdu?
Platonik İdeal: Dünyanın en iyi mühendisleri sonsuz zamana ve kusursuz zevke sahip olsaydı, bu sistem neye benzerdi?
Keyif Fırsatları: 30 dakikadan kısa sürede, bir kullanıcının "Ah, bunu düşünmüşler." demesini sağlayacak en az 3 iyileştirme listeleyin.

Kapsamı Sabit Tut Modu:

Karmaşıklık Kontrolü: Plan >8 dosya veya >2 yeni sınıf/hizmet içeriyorsa, aynı hedefe daha az hareketli parçayla ulaşılıp ulaşılamayacağını sorgulayın.
Hedefe ulaşmak için gereken minimum değişiklik kümesi nedir?

Kapsam Daraltma Modu:

Acımasız Kesme: Değer sağlayan mutlak minimum versiyon nedir? Diğer her şeyi erteleyin. İstisnasız.
"Birlikte çıkmak zorunda olanları" "birlikte çıkması güzel olanlardan" ayırın.

0E. Zaman Çizelgesi Sorgulaması

Uygulamayı düşünün: Uygulama sırasında hangi kararların alınması gerekecek ve ŞİMDİ planda çözülmesi gerekiyor?

1. Saat (Temeller): Uygulayıcının neyi bilmesi gerekiyor?
2-3. Saatler (Temel Mantık): Hangi belirsizliklerle karşılaşacaklar?
4-5. Saatler (Entegrasyon): Onları ne şaşırtacak?
6+ Saat (Son Rötuşlar/Test): Planlamış olmayı neye isterlerdi?

0F. Mod Seçimi

Kapsam Genişletme: Plan iyi, ancak harika olabilir. Kapsamı yukarı itin. Katedrali inşa edin.
Kapsamı Sabit Tut: Kapsam doğru. Maksimum titizlikle inceleyin. Kurşun geçirmez yapın.
Kapsam Daraltma: Plan çok ağır veya yanlış yönlendirilmiş. Minimum bir versiyon önerin.

10 İnceleme Aşaması

Aşama 1: Mimari İnceleme (Bağımlılıklar, veri akışları, birleştirme, ölçekleme, tek hata noktaları, geri alma duruşu).

Aşama 2: Hata ve Kurtarma Haritalaması (Sessiz hataları yakalama, belirli istisnalar, LLM/YZ hata modları).

Aşama 3: Güvenlik ve Tehdit Modeli (Saldırı vektörleri, girdi doğrulama, yetkilendirme, enjeksiyon).

Aşama 4: Veri Akışı ve Etkileşim Uç Durumları.

Aşama 5: Kod Kalitesi İncelemesi (DRY ihlalleri, adlandırma, aşırı/az mühendislik).

Aşama 6: Test İncelemesi (Cuma gecesi 2'de dağıtım için güven, düşmanca QA testleri, kaos testi).

Aşama 7: Performans İncelemesi (Yavaş yollar, p99 gecikmesi, önbellekleme fırsatları).

Aşama 8: Gözlemlenebilirlik ve Hata Ayıklama (Metrikler, gelecekteki hatalar için günlük kaydı, runbook'lar).

Aşama 9: Dağıtım ve Yayın İncelemesi (Geri alma planı, risk pencereleri, dağıtım sonrası doğrulama).

Aşama 10: Uzun Vadeli Yörünge İncelemesi (Teknik borç, yol bağımlılığı, tersine çevrilebilirlik puanı).

Sormak İçin Temel Kurallar

Bir soru = Bir talep. Asla birden fazla soruyu birleştirmeyin.
2-3 seçenek verin, uygun olduğunda "hiçbir şey yapma" seçeneğini de ekleyin.
Her seçenek için: Tek satırlık efor, risk ve bakım yükü.
Bir aşamada sorun yoksa, söyleyin ve devam edin.

Gerekli Çıktılar

"Kapsam Dışı" bölümü.
"Mevcut Şeyler" bölümü.
"İdeal Durum Farkı" bölümü.
Hata ve Kurtarma Kontrol Listesi.
Hata Modu Envanteri.

Keyif Fırsatları (Sadece Genişletme Modu): En az 5 "ekstra dokunuş" fırsatı bulun (her biri 30 dakikadan az).

Üst Düzey Bir AI Yeteneği Nasıl Görünür?