ChatGPT'deki fikirden yayına: çok araçlı AI ürün geliştirme akışı
Emanuele Bartolesi, bir ürünü tek bir ajanla değil, görevleri bölüşen bir araç zinciriyle geliştirdiği akışını anlatıyor: ChatGPT'de PRD, Antigravity ile GitHub backlog'u, Copilot CLI ile implementasyon, Claude Code ile review. Yazının asıl değeri, modeller değişse de sabit kalan kısımda: repo içindeki PRD, AGENTS.md talimatları ve dotcraft adını verdiği skill/agent plugin'i.
Kilit noktalar
- PRD'yi docs/PRD.md olarak repo'ya koymak, kararların ChatGPT oturumundan Copilot CLI ve Claude Code'a taşınmasını sağlıyor
- Antigravity + Gemini 3.8 Flash, GitHub CLI ile PRD'den epic ve alt issue üretiyor; issue'lar native parent/sub-issue ilişkisiyle açılıyor
- Copilot CLI'da dotcraft plugin'i her issue için ayrı commit ve tek PR istiyor; epic yalnızca tüm alt issue'lar doğrulanınca kapanıyor
- Model seçimi gerektiğinde elle yapılıyor (UI için GPT-6.1 Sol veya GPT-6 Astra), diğer işlerde varsayılan olarak Copilot Fusion kullanılıyor
- Playwright testleri boş ekrandan kayıt oluşturma, düzenleme ve güncel değerleri görme gibi akışları doğruluyor; CI'da hata anında trace ve screenshot yükleniyor
- YOLO mode onay istemlerini kaldırıyor ama komutları güvenli yapmıyor; sorumluluk yazarda kalıyor
Akış, kod yazdırmadan önce kapsamı netleştirmekle başlıyor: ChatGPT'de gereksinimler tartışılıp repo içine docs/PRD.md olarak konuyor; "kullanıcı verisini dışa aktarabilir" gibi muğlak maddeler hangi veri, hangi format ve arşiv kayıtları dahil mi sorularıyla açılıyor. Antigravity, Gemini 3.8 Flash ile bu belgeyi epic ve alt issue'lara çevirip GitHub CLI üzerinden native parent/sub-issue ilişkileriyle açıyor; yazar backlog'u yine de gözden geçiriyor.
Uygulama tarafında Copilot CLI, dotcraft plugin'i ile çalışıyor: her issue için ayrı commit, sonunda tek PR, Playwright ile otomatikleştirilen tarayıcı kontrolleri ve acceptance criteria'ya göre doğrulama. Ardından Claude Code tüm epic üzerinde review yapıyor, ama son kararı yazarın kendisi veriyor. Amaç, model tercihleri sık değişse de aynı bağlamın korunması; dotcraft içindeki blazor-saas-stack, bunit-testing ve csharp-expert gibi skill ve agent'lar bu ortak zemini sağlıyor.
Gerçek dünyada kullanımı
- Birden fazla ajanı aynı üründe kullanan solo geliştiricilerin, her oturumda aynı mimari kararları yeniden anlatmadan ilerlemesi
- Mevcut bir repo'ya yeni özellik eklerken PRD'den otomatik açılan epic ve issue'larla işi parçalara bölmek
- Blazor veya MudBlazor tabanlı bir SaaS'ta, implementasyon ajanından bağımsız olarak test ve doğrulama beklentilerini sabitlemek
- Değişiklik sonrası aynı tarayıcı akışlarını elle tıklamak yerine Playwright ile PR kontrolüne bağlamak
Neden önemli
Ajanlar ve modeller değiştikçe asıl kayıp, önceki oturumda verilen kararların kaybolması; PRD ve skill dosyalarını repo'da tutmak bu kaybı büyük ölçüde engelliyor. Ancak yazarın da vurguladığı gibi, review bulgu vermemesi doğru ürün davranışını istediğiniz anlamına gelmiyor; son okuma insanda kalıyor.