AI-yerel bir startup nasıl kurulur

• AI geceleri tekrar eden işleri yürütürken kurucuların ürün geliştirmeye odaklandığı yeni bir operasyon modeli; asıl değişim zaman kullanımında değil, şirketin öğrenme, yineleme ve evrimleşme hızında yatıyor
• AI-native şirketlerde operasyon modelinin kendisi değişir; daha az kişi daha az koordinasyon yapar, ajanlar tekrar eden işleri yürütür ve insanlar yön, zevk, ilişki, doğrulama ve sorumluluğa odaklanır
• Dönüşüm; işlerin haritalanması, bağlam sisteminin kurulması, en basit otomasyonun seçilmesi, tekrar eden işlerin beceri haline getirilmesi, kaliteyi değerlendiren eval'lerin yazılması ve haftalık iyileştirme döngüsünün işletilmesi aşamalarından geçer
• Modeller her ay değiştirilip iyileştirilir ve birbirine benzer hale gelir; bu yüzden şirkete özgü gerçek varlık, bağlam ve eval'ler gibi operasyonel sistemdir
• Herkesin aynı modeli kullandığı bir ortamda gerçek hendek disiplindir; yani her hafta işleri haritalama, bağlam biriktirme, eval yazma ve döngüyü işletme konusundaki tutarlılık

---

İki startup'ın karşılaştırması

• Aynı pazarda, aynı ay kurulan iki şirketi sabah 9'da karşılaştırın
  • İlk şirkette operasyon lideri birikmiş destek biletlerini temizliyor, analist geçen haftanın dashboard'unu yeniden hazırlıyor, kurucu ise kimsenin çözemediği bir müşteri görüşmesi konusu yüzünden standup sırasında meşgul; herkes dünkü sorunları toparlamakla uğraştığı için ürün yerinde sayıyor
  • İkinci şirkette ise tüm bu işleri gece boyunca ajanlar halletmiş durumda: bilet sınıflandırma, dashboard güncelleme, görüşmelerdeki churn risk işaretlerini öne çıkarma tamam; kurucu çoktan sorunu düzeltmeye ve ekiple ürünü geliştirmeye başlamış durumda
• Temel fark öğrenme hızıdır; ikinci şirket her gün daha hızlı öğrenir ve bu kaldıraç haftalar, aylar ve yıllar boyunca bileşik şekilde birikir

1. Aşama - İşleri haritalama (Map The Work)

• Son 2 haftada tekrar eden tüm işleri listeleyin: müşteri görüşmesi notları, lead araştırması, outbound taslakları, destek sınıflandırma, ürün QA, onboarding, release note'lar, yatırımcı güncellemeleri, haftalık metrikler, bug yeniden üretimi, işe alım ön elemesi, fatura incelemesi, rakip takibi vb.
  • Tekrar ediyorsa kodlanmaya adaydır; çoğu kurucunun takviminde bu tür 20 ila 40 madde bulunur
  • Erken aşamadaki ekipler dürüstçe listelediğinde zaten rutine dönüşmüş 10 ila 15 iş bulur

• Otonomi seviyesi sınıflandırması

  • L1 yalnızca insan içindir: stratejik kararlar, nihai işe alım, büyük iade kararları, yasal imzalar, yönetim kurulu iletişimi
  • L2 AI hazırlığı + insan onayıdır: yatırımcı güncellemesi taslakları, sözleşme redline'ları, fiyatlandırma sayfası yeniden yazımı, destek makroları
  • L3 AI yürütmesi + insan gözetimidir: inbound sınıflandırma, toplantı notlarının yönlendirilmesi, lead zenginleştirme, test üretimi
  • L4 net sınırlar içinde otonomdur: rakip takibi, gece raporu üretimi, bilinen tedarikçi faturalarından veri çıkarımı, basit anomali tespiti

• Sıkıcı workflow'lar genelde kazanır

  • Haftalık strateji notu gibi gösterişli işlerden ziyade, her gün tekrarlanan destek etiketleme 10 kat daha sık çalıştırılır; daha fazla zaman geri kazandırır ve temiz doğru cevap verisi sağlar. Sıklık, prestiji yener
  • İlk hedef; sık yapılan, ölçülebilir, geri alınabilir ve gerçek darboğazla bağlantılı işler olmalı

• Otomatikleştirilmemesi gereken işler

  • Nadir yapılan, belirsiz, yüksek güven gerektiren veya istikrarsız işler dışarıda bırakılmalı
  • C.H. Robinson ekibi günde 10 bin e-postayı sınıflandırmayı L4'e itti ancak gözetim imkansız hale gelince L2'ye geri döndü; hacim, yanlış sınıflandırma maliyetini gizledi
  • İyi bir çıktının neye benzediğini açıklayamıyorsanız, bu iş henüz kodlanmaya hazır değildir; tek bir yanlış çıktı müşteri ilişkisine zarar verebiliyorsa yavaş ilerleyin

• Başlangıç kurgusu

  • 1 sayfa ve 3 workflow ile başlayın: kişisel (gelen kutusu sınıflandırma, günlük brief, yatırımcı güncellemesi taslağı), müşteri temaslı (görüşme özeti, bilet sınıflandırma, lead zenginleştirme), iç operasyon (test üretimi, fatura veri çıkarımı, haftalık metrik anlatımı)
  • Aynı anda çok fazla deney yapmak dikkati dağıtır ve en yaygın başarısızlık biçimi olan 20 yarım kalmış pilot üretir

2. Aşama - Bağlam sistemini kurma (Build The Context System)

• Bağlam, AI-native startup'ın operasyonel hafızasıdır; şirketin kendisi hakkında bildiği her şey, ajanların okuyabileceği bir yerde tutulur
  • Modeller değiştirilebilir ama bağlam, şirkete özgü gerçek varlıktır; kurucu ortak gibi çalışan ajanla kafası karışık geçici çalışan gibi çalışan ajanı ayıran şey budur
  • Çıktıyı yeniden yazmaya, gözden geçirmekten daha fazla zaman harcanıyorsa sorun prompt'ta ya da modelde değil, ajanın şirketi yeterince tanımamasındadır

• Haftalık teşhis yöntemi

  • Temsilî bir görevi, yalnızca workspace bağlamına sahip yeni bir ajana verin ve ondan sonraki 3 eylemi isteyin
  • İkiden fazla güçlü öneri geliyorsa bağlam işini yapıyordur; üç genel cevap geliyorsa bağlam zayıftır ve bunu prompt'la kurtarmak mümkün değildir

• Git deposu temeli

  • Tüm ekip üyeleri ve ajanların okuyabildiği paylaşımlı tek bir Git deposu ile başlayın; sürüm kontrolü, diff, hem insanlar hem ajanlar tarafından okunabilirlik ve belirli bir vendor runtime'ına bağlı olmama sağlar
  • 7. gün workspace'i; CLAUDE.md, context/company.md, context/product.md, context/customers.md, context/lessons.md ve aktif işler için GTD.md içeren tek kök yapıdan oluşabilir
  • Elle yazılmış 40 ila 60 satırla sürdürün; kaçınılması gereken şeylerin sıkışık listesiyle dolu, üretilmiş 400 satırlık gevezelikten daha iyidir

• Yetki sınırlarına göre bölme

  • Büyüdükçe paylaşımlı şirket deposu + fonksiyona özel özel depolar (satış, ürün, mühendislik, finans, destek) ya da proje/müşteri bazlı özel depolar + şirket genelinde paylaşılan kök yapı kullanılabilir
  • Enterprise ölçekte; self-hosted Gitea, GitHub Enterprise, GitLab gibi özel Git sunucularıyla dizin/depo bazlı yetkilendirme yapılabilir
  • Block'un iç harness'i Goose, rol bazlı scope'larla aynı artifact akışını okur; scope kaydığı anda kamusal açıklamalarla özel işlem bağlamını karıştırmaya başlar. Sınırlar bu yüzden çok önemlidir

• Sisteme giren 3 veri türü

  • Connector'lar: SaaS, API, MCP sunucuları, e-posta, takvim, CRM, destek, analitik, GitHub, Linear, Stripe, warehouse ve belgelerden dış veri toplar
    • Her connector; tanımlayıcılar, scope izinleri, audit log'lar ve yönetilen kimlik bilgileri gerektirir, aksi halde en büyük güvenlik deliğine dönüşür. Zitadel gibi IAM katmanları kimlik disiplinini üstlenir
    • Anthropic'in MCP code execution işi, tüm araç tanımlarını sunucu klasörü dosya sistemi deseniyle önceden yükleyen yaklaşıma kıyasla bağlam kullanımını yaklaşık 150 bin tokendan yaklaşık 2 bin tokene düşürerek %98,7 tasarruf sağladı
  • Şirketin ürettiği veriler: spec'ler, müşteri özetleri, kararlar, dersler, proje notları, operasyon kuralları; varsayılan biçim Markdown'dır
    • En önemli kural ham (raw) ile damıtılmış (distilled) veriyi ayırmaktır; görüşme kaydı ham veridir, o görüşmeden çıkan kararlar, müşteri itirazları, takip sorumlusu ve yenileme riski ise damıtılmış veridir ve ajanların fiilen sorguladığı şey de budur
    • Karar günlüğü, akıl yürütmenin sonuçla birlikte takip edilebilmesi için satır başına tek kayıt şeklinde append-only tutulmalı
  • Veritabanları ve akışlar: Postgres ürün verisi, warehouse pazarlama verisi, analitik event'leri gibi kaynağın zaten yaşadığı yerler
    • Bunları körü körüne Markdown'a kopyalamayın; DB'yi kaynak olarak bırakın, ajana sınırlı okuma kullanıcısı verin, şemayı ajan için data-models/postgres.md dosyasında belgeleyin ve izin verilen sorgu/yazmaları açıkça belirtin
    • Varsayılan olarak ajanın production verisini silememesini sağlayın; 2025 ortasındaki Replit olayında bir coding ajanı oturum sırasında production DB'yi sildi ve bu, prompt talimatlarının güvenlik sınırı olmadığını hatırlattı

• Gelişmiş sürüm ve kaynak takibi

  • Yapılandırılmış bağlam grafiği: ajanlar sorgulamadan önce ham kaynakları insan, şirket, itiraz, taahhüt, özellik isteği, yenileme riski, takip, tarih, karar ve kaynak bağlantısı gibi varlıklar ve ilişkiler olarak işler
    • Kayıtları sadece saklamak yerine içerik çıkarılır; aynı kişi ya da projeyle ilgili görüşmeler zincirlenir ve "Vandelay Industries'in yenileme riski nedir?" sorusuna tam ifade satırlarını alıntılayarak yanıt vermek mümkün olur
  • Her özet, kaynağına dönülebilir olmalıdır: kayıt, bilet, commit, fatura ya da DB satırı. Kaynak yoksa doğrulanamayan ama makul görünen özetler birikir ve ilk yanlış cevapta tüm ajan sistemine duyulan güven çöker
    • Kaynak olduğunda ajan denetlenebilir hale gelir; ekip üyeleri tek tıklamayla kaynağı kontrol eder ve anlaşmazlıkları saniyeler içinde çözer

3. Aşama - En basit otomasyonu seçme (Choose The Simplest Automation)

• Tüm iş akışlarını ajana dönüştürmeyin; en iyi sistemler scriptler, AI destekli insanlar, deterministik iş akışları ve ajanların karışımıdır
  • Kurucunun görevi, kalite çıtasını aşarken aynı zamanda güvenle çalıştırılabilecek en hafif aracı seçmektir

• Araçlara göre uygulama

  • Script - deterministik adımlar için (rapor dışa aktarma, CSV dönüştürme, test çalıştırma, link kontrolü, JSON doğrulama, haftalık metrik paketini formatlama)
  • AI destekli insan - şirketten çıkmadan önce muhakeme gerektiren çıktılar için (yatırımcı güncellemeleri, kurucu e-postaları, fiyatlandırma metinleri, sözleşme notları)
  • İş akışı - adımlar önceden biliniyorsa (arama toplama→özetleme→itiraz çıkarma→CRM notu yazma→takip oluşturma), sıralama, yeniden deneme ve gözlemlenebilirliği LangGraph, Temporal, Inngest, Prefect gibi motorlar üstlenir
  • Ajan - yol önceden belirlenemiyorsa (prodüksiyon bug araştırması, pazar araştırması, anormal destek vakaları, karışmış müşteri hesapları)
    • Browserbase'in bb ajanı, Slack karşısında çalışan genel amaçlı bir ajan olarak her iş için farklı skill dosyaları ve kapsam izinleri yükler; her görev için ayrı botlar yapmaktan üstündür çünkü botlar zamanla birbirinden sapar

• Harness - 6 adımlı güvenlik katmanı

  • Preflight - ajan token harcamadan önce bağlamı ve izinleri doğrular
  • Plan - işi parçalara ayırır ve önerilen adımları görünür kılar
  • Approve - insan veya bir değerlendirme modeli kapısı, kötü planları çalışmadan önce engeller
  • Execute - işi yürütür
  • Verify - çıktıyı testler, şemalar, rubrikler ve örneklerle doğrular
  • Log - bir sonraki iterasyonda doğru cevap olsun diye olan biteni çalıştırılabilir dosyaya kaydeder

• Guardrail'ler prompt'ta değil, kodda ve konfigürasyonda olmalı

  • "Prodüksiyon verisini silme" şeklindeki bir prompt bir güvenlik sınırı değildir
  • Pazarlık edilemez maddeler - yürütme ve günlük maliyet üst sınırı, yeniden deneme üst sınırı, maksimum araç çağrısı derinliği, ajan başına kapsamlı kimlik bilgileri, onaysız prodüksiyon yazımının yasaklanması, kodun otomatik merge edilmesinin yasaklanması, tüm filoyu durduracak kill switch
  • 2025 boyunca yaşanan özyinelemeli üretim olaylarında (ajanların durmadan alt ajan çağırması) harness yakalayana kadar gerçek maliyet oluştu; üst sınırlar, modelin talimatları yok sayma şansı bulmasından önce, runtime'da konulmalıdır

4. adım - Skill ve eval kodlamak (Encode Skills And Evals)

• Buraya kadarki her şey hazırlıktır; tekrarlayan işleri skill olarak kodlamak ve eval ile puanlamak, şirketi her hafta az da olsa bileşik şekilde büyüten motordur
  • Skill, tekrarlayan işler için yeniden kullanılabilir talimatlar + örneklerdir; işi iki kez elle yaptıktan sonra tekrarlayan kısmı kodlayın
  • Her skill'in net bir biçimi olmalıdır - kapsam, girdiler, yüklenecek bağlam, prosedür, çıktı formatı, örnekler, eskalasyon kuralları, sahip, yürütme günlüğü
  • Ne aldığını, ne döndürdüğünü, ne zaman yardım istemesi gerektiğini ve kimin bakım yaptığını yazmıyorsa o bir skill değil, uzun bir prompt'tur

• Skill şablonu örneği (customer-call-synthesis)

  • Scope: kayıt alındıktan sonraki satış görüşmesi / Inputs: kayıt, hesap geçmişi, ürün bağlamı, açık fırsatlar
  • Load: ICP, fiyatlandırma, ürün yol haritası, itiraz sınıflandırması / Steps: olgu çıkarma→itiraz kümeleme→risk belirleme→takip yazma
  • Output: CRM notu, müşteri özeti, özellik talebi, sonraki aksiyon / Examples: beklenen notların eklendiği 3 önceki görüşme
  • Escalate: hukuki-güvenlik sorunları, churn riski, enterprise fiyatlandırma / Owner: revenue lead / Eval: beklenen çıkarım alanları eklenmiş 30 geçmiş görüşme

• Kurucu dostu skill'lerle başlayın

  • Müşteri görüşmesi sentezi - ham kayıttan itirazlar, özellik talepleri, riskler, taahhütler ve sonraki aksiyonları çıkarma
  • Gelen kutusu sınıflandırması - yatırımcı, müşteri, işe alım ve operasyon mesajlarını ayırma; ilk üç kategori için yanıt taslağı hazırlama
  • Yatırımcı güncellemesi - metriklerden ve kararlardan anlatı yazıp her iki taraftan alıntı ekleme
  • Fiyatlandırma sayfası analizi - canlı sayfayı güncel müşteri itiraz günlüğüyle karşılaştırma
  • Haftalık metrik anlatısı - neyin değiştiğini, neyin bozulduğunu ve neyin incelenmesi gerektiğini açıklama
  • Test üretimi - bir spesifikasyonu testlere ve taslak PR'a dönüştürme

• Eval'in 3 katmanı (bu sırayla birikir)

  • Birincisi, elle etiketlenmiş doğru cevap - insan gerçek örneklerde iyi çıktının ne olduğunu işaretler
  • İkincisi, deterministik kontroller - sıfır maliyetle net hüküm verir (şema geçerliliği, kaynakla eşleşen sayılar, açılan linkler, mevcut alıntılar, geçen testler)
  • Üçüncüsü, LLM değerlendirmesi - yalnızca deterministik kontrollerin erişemediği kısımlar için (yazı kalitesi, duygu, brief'e uygunluk); küçük ve hızlı bir model yeterlidir ama güvenmeden önce insan işaretli örneklerle kalibre edilmelidir

• Vaka çalışması: müşteri görüşmesi sentezi

  • Revenue lead geçmiş 30 görüşmeyi işaretler; önemli olgular, itirazlar, riskler, takipler
  • Deterministik doğrulama; isimler, sözleşme tutarı ve takip tarihinin haftası açısından doğruluğu kontrol eder, özeti görüşme gibi hissettirip hissettirmediğini ise LLM değerlendirir
  • Yaklaşık 50 çalıştırmadan sonra genelde aynı iki şey bozulur; 3+ kişinin olduğu görüşmelerde konuşmacı takibi kaybolur ya da iki ayrı itiraz tek bir itirazda birleştirilir; bunları küme düzeyinde düzeltip tutarlı davranana kadar yeniden yazarlar

• Vaka çalışması: outbound lead sınıflandırması

  • Kurucu, geçmiş 300 lead'i ICP'ye uygun evet/hayır olarak işaretler
  • Mekanik kontroller; gerçekten şirket olup olmadığını, web sitesinin yüklenip yüklenmediğini ve çalışan sayısının girilip girilmediğini doğrular; geri kalanı ICP tanımına karşı LLM değerlendirir
  • Eval hazır olduğunda açık kaynak prompt evrimi döngüleri (GEPA, DSPy), etiketlere karşı sınıflandırma prompt'unu gece boyunca yeniden yazar; kurucu son prompt'u okumaz, önemli olan yalnızca eval hükmüdür

• Eval olgunluğunun 5 aşaması

  • 1. Tek örneği elle inceleme → 2) yazılmış bir rubrikle az sayıda vakayı puanlama → 3) aynı rubriği geçmiş 20-300 vakaya uygulama → 4) ajanın hiç görmediği bir holdout set ile test etme → 5) skill'in etkilemeyi amaçladığı iş metriğini izleme

• Çıkıştan sonra sağlıklı kalmak için: her hafta 6 sayı

  • kabul oranı (acceptance rate), override oranı, çalıştırma başına maliyet, çevrim süresi, inceleme süresi, olay sayısı
  • Kabul oranı kilit metriktir; yaklaşık %70'in altındaysa (küçük düzenlemeler kabul sayılır) otonomi seviyesini artırmaya henüz hazır değilsiniz
  • Kabul oranı düşükken prompt yeniden yazmak neredeyse hiçbir zaman doğru cevap değildir; sorun genelde dört şeyden biridir: runtime'da bağlam eklemek, skill kapsamını daraltmak, dosyaya çalışan örnekler eklemek, üstlenilmemesi gereken vakalar için net eskalasyon kuralları yazmak

5. adım - Ekibi AI-native hale getirin (Make The Team AI-Native)

• Kurucu önce başlamalı; ekibi yeni çalışma biçimine geçirmenin en hızlı yolu bunu şirket bağlamı içinde canlı göstermektir
  • Takvim, gelen kutusu ve Slack'ten gece boyunca çekilen sabah özeti; dünkü görüşmelerin müşteri sentezi; spesifikasyondan ajanın çıkardığı test PR'ı; son metrik paketinden oluşturulan yatırımcı güncellemesi taslağı gösterilir
  • Amaç kalibrasyondur; ajan katmanının neyi yapabildiğini ve neyi yapamadığını bizzat görmek
  • Jack Dorsey, 2025 boyunca her sabah saatlerce bu araçları doğrudan kullandıktan sonra Block'u yeniden yapılandırdı; bu, büyük verimlilik odaklı işten çıkarmalara yol açtı ve kararlar ajanları bizzat kullanmış liderlikten geldi

• İlk günden kurun, onboarding'i çıktıyla bitirin

  • Her ekip üyesi ilk oturumdan, o gün yayına alınabilecek bir çıktı ile çıkar (düzenlenmiş müşteri özeti, destek makrosu, test PR'ı, fiyatlandırma sayfası eleştirisi); gerçek iş üretmeyen eğitim bir hafta sonra unutulur
  • Ramp'in Glass aracı, her onboarding oturumunun yeni kişinin bir skill'ini veya artifact'ini ortak kütüphaneye ekleyerek bitmesi kuralıyla 3 ay içinde günlük kullanıcı sayısını 20'den yaklaşık 700'e çıkardı

• İnsanın rolü büyür

  • İnsanlar sistemi tasarlar, ilişkilere sahip çıkar, çıktıyı değerlendirir ve sorumluluğu üstlenir; ajanlar ise yürütmeyi yapar
  • Yalnızca dar işleri çeviren ekip üyeleri bu modelde görünür hale gelir; muhakemeyi talimatlara, örneklere ve eval'lere dönüştürebilenler ise eskisinden daha değerlidir

• İşe alım da değişir

  • Rol açma eşiği yükselir; eskiden işe alım gerektiren bazı işler artık bir skill olduğundan, yeni roller yalnızca gerçekten insan gerektiren işlere verilir
  • İşe alımda genel bilgi yerine, verilen sürede elle bitirilemeyecek kadar büyük bir proje verin ve ajanları nasıl yönettiklerini gözlemleyin; muhakemeye, zevke ve ajan raydan çıktığında toparlama becerisine bakın
  • Gerçek örnekler: analist için 3 saat içinde kaynak toplama, kanıt çıkarma ve cilalı brief'e kadar uzanan gerçek rapor; mühendis için 1 gün içinde gerçek bir ürün yüzeyini kopyalama veya spesifikasyondan dahili araç üretme (testler dahil); growth adayı için 50-100 şirketlik pazar haritası ve kampanya planı (scraping, kümeleme, yazma, önceliklendirme) — hepsinde kilit nokta, bunların elde verilen sürede elle tamamlanamayacak işler olmasıdır

6. adım - Startup’ı bir geri bildirim döngüsü olarak işletmek (Run As A Feedback Loop)

• AI-native startup’lar operasyon sistemini her hafta iyileştirir; başa dönüp yeniden başlar
  • İncelemenin ele alacakları: agent’ın yaptığı işler, insanın override ettiği noktalar, başarısız olan eval’ler, eksik bağlam, daraltılması gereken beceriler, kapatılacak workflow’lar, özerklik seviyesi artırılacak workflow’lar

• Aynı anda iki döngü çalıştırın

  • İç döngü - mevcut işleri iyileştirme (çalıştırma başına maliyet↓, çevrim süresi↓, olaylar↓, artifact başına inceleme süresi↓)
  • Dış döngü - şunları keşfetme (yeni müşteri segmentleri, ürün fikirleri, fiyat değişiklikleri, iş ortaklıkları, rakip hamleleri, düzenleyici değişiklikler, churn riski); arka plan agent’ları 24 saat aday üretir ve insanlar hangilerinin takip edileceğini seçer

• Yazılım fabrikası (iç döngünün en büyük kısmı)

  • İnsanlar spec ve testleri yazar, agent’lar buna göre uygular; deterministik kontroller kendi kendine çalışır ve merge öncesinde insan incelemesi yapılır
  • Kabul kriterlerinin net ve etki alanının küçük olduğu yerlerden başlayın - test üretimi, dependency upgrade’leri, migration’lar, iç araçlar, entegrasyon scaffold’ları, QA script’leri, güvenlik için otomatik düzeltmeler
  • İki sert kural - hiçbir şey otomatik merge edilmez, hiçbir agent production’a yazmaz
    • Cursor bile büyük ölçekli otonom bulut agent’ları çalıştırırken 2026’nın başına kadar merge için insan inceleme geçidini koruyor; bu geçit geri kalan her şeyin güvenli biçimde ölçeklenmesini sağlıyor

• Pazar öğrenme sistemi (dış döngü)

  • Görüşme kayıtları, itiraz çıkarımı, özellik isteklerini kümelendirme, rakip takibi, kullanım değişimlerini gözlemleme, destek örüntülerini okuma, kaybedilen anlaşmaları inceleme
  • Bulguları hipotezlere dönüştürün, ardından en güçlü olanları test edin - müşteri görüşmeleri, landing page testleri, ürün deneyleri, veriler üzerinde yeni sorgular
  • Agent’lar önerir, insanlar seçer - stratejide hem öneriyi hem kararı agent’lara bırakırsanız sıradan bir uzlaşıya yerleşir ya da yükseltilmesi en kolay metriği yokuş tırmanır gibi optimize ederler

• Şirket genelinde kendini geliştirmenin özü = eval yazabilme becerisi

  • Yüzlerce örneği elle iyi/kötü diye etiketleyin ve eval oluşturup bunu prompt evrimi döngüsüne bağlayın - GEPA ve DSPy gibi framework’ler küçük bir yansıtıcı modelle prompt varyasyonları önerir, eval bunları etiketli sette sıralar, kazananı dağıtıma alır ve tekrar eder
  • Kurucular eval yazar ve başarısızlık kümelerini okur, ancak evrilmiş prompt’ları ne yazar ne de okur
  • Sizi yavaşlatan şey agent yeteneği değil, iyinin ölçütünü kodlayıp kodlayamadığınızdır - kod yazabilmek faydalıdır ama darboğaz değildir; çıktıları güvenilir şekilde iyi/kötü diye işaretleyebilen bir alan uzmanı tüm döngüyü çalıştırabilir
  • eval, yük taşıyan temel artifact’tir ve eval yazımı durduğu anda şirketin bileşik büyümesi de durur

Sonuç

• Gerekli olan şey bir dâhi ya da büyük bir ekip değil; işleri haritalama, bağlam biriktirme, eval yazma ve döngüyü her hafta çalıştırma disiplini - herkesin aynı modeli kullandığı bir dönemde operasyon sistemi gizli silahtır