13 puan yazan GN⁺ 2026-02-08 | 3 yorum | WhatsApp'ta paylaş
  • StrongDM AI ekibi, koda bakmadan da yüksek kaliteli yazılım üreten bir Software Factory kavramını savunuyor
  • Spesifikasyon/senaryo temelli olarak ajanların kod yazdığı, test harness’larını çalıştırdığı ve insan incelemesi olmadan yakınsadığı etkileşimsiz geliştirme yaklaşımı
  • Kod insanlar tarafından yazılmamalı veya incelenmemeli; ayrıca Software Factory’nin düzgün çalışması için mühendis başına günde en az 1.000 doların üzerinde token maliyeti harcanması gerektiği savunuluyor
  • Claude 3.5’in 2. revizyonundan (Ekim 2024) itibaren uzun soluklu ajan kodlama iş akışlarının hata biriktirmek yerine doğruluğu bileşik biçimde artırmaya başladığı ve etkileşimsiz geliştirme olasılığını doğruladığı belirtiliyor
  • Mevcut test kavramı genişletilerek senaryo (scenario) ve memnuniyet (satisfaction) kavramları ekleniyor; LLM’nin kullanıcı memnuniyetini olasılıksal olarak değerlendirdiği bir yapı kuruluyor
  • Digital Twin Universe (DTU) ile Okta, Jira, Slack gibi başlıca SaaS’ların kopyaları oluşturulup büyük ölçekli doğrulama yapılıyor; böylece senaryo doğrulaması prodüksiyon sınırlarının ötesinde hacim ve hızla mümkün oluyor
  • Ajan çağı, yazılım ekonomisini kökten değiştiriyor; geçmişte ekonomik olarak mümkün olmayan yüksek doğrulukta SaaS kopyaları oluşturmak artık rutin bir iş haline geliyor

Software Factory kavramı

  • Spesifikasyonlar (specs) ve senaryolar (scenarios), ajanları yönlendirerek kod yazan ve doğrulayan etkileşimsiz bir geliştirme sistemi oluşturuyor
    • İnsanların kod yazması ve kod incelemesi yapması yasaklanıyor; tüm geliştirme sürecini ajanlar yürütüyor
    • Verimlilik, mühendis başına günde 1.000 doların üzerinde token kullanımı ölçütüyle değerlendiriliyor
  • Bu yaklaşım, insan müdahalesi olmadan kodun otomatik olarak üretildiği, doğrulandığı ve yakınsadığı otonom bir yazılım üretim ortamı kurmayı hedefliyor

StrongDM AI ekibinin kuruluşu

  • 14 Temmuz 2025’te StrongDM AI ekibi kuruldu ve etkileşimsiz geliştirme deneylerine başladı
    • Katılımcılar: Jay Taylor, Navan Chauhan, Justin McCarthy (kurucu ortak ve CTO)
  • 2024 sonlarında Claude 3.5 (Ekim revizyonu) sonrasında uzun süreli kod yazımındaki doğruluk artarak, tekrarlayan hata birikimi yerine bileşik doğruluk (compounding correctness) mümkün hale geldi
  • Cursor’un YOLO modu, modelin uzun soluklu kod yazma yeteneğini açık biçimde gösterdi
  • Önceki modellerde LLM’lerin kodlama görevlerine tekrar tekrar uygulanması, yanlış anlama, halüsinasyon, sözdizimi hataları, sürüm düzeyinde DRY ihlalleri, kütüphane uyumsuzlukları gibi her tür hatayı biriktiriyor ve uygulamanın "çökmesine" yol açıyordu
  • Anthropic’in güncellenmiş modeli ile YOLO modunun birleşimi, etkileşimsiz geliştirme veya büyütülen yazılımın ilk kez mümkün olabileceğini gösterdi

Temel ilke: elini çek

  • AI ekibinin ilk gününün ilk saatinde bir tüzük oluşturuldu; en önemli ilke şuydu: "Kod insanlar tarafından doğrudan yazılmamalı."
  • Başlangıçta bu yalnızca sezgiye ve deneye dayanıyordu: elle hiç kod yazmadan ne kadar ileri gidilebilir?
  • İlk etapta sınıra takıldılar, ancak testler eklendikten sonra ilerleme başladı
  • Ajanlar anlık görevlere saplanıp kestirme yollar seçiyordu: dar yazılmış testlerde return true ile geçmek mümkün oluyordu, ancak bu gerçek istenen yazılıma genellenmiyordu
  • Yalnızca basit testler yeterli değildi; bunun entegrasyon testleri, regresyon testleri, uçtan uca testler ve davranış testleriyle genişletilmesi gerekiyordu

Testlerden senaryo ve memnuniyete geçiş

  • Ajan çağının tekrar eden teması: yeni bir dile ihtiyaç var; "test" sözcüğü yetersiz ve muğlak kalıyor
  • Kod tabanında saklanan testler, koda uyacak şekilde tembelce yeniden yazılabiliyor ya da kod, testleri önemsiz biçimde geçecek şekilde yeniden düzenlenebiliyor
  • Senaryo terimi yeniden tanımlanıyor: uçtan uca kullanıcı hikâyesini ifade ediyor, kod tabanının dışında saklanıyor (model eğitimindeki "holdout" setine benzer), LLM tarafından sezgisel biçimde anlaşılabiliyor ve esnek şekilde doğrulanabiliyor
  • Büyütülen yazılımın kendisi de ajan bileşenleri içerdiğinden, başarı ölçütü basit bir boolean yerine olasılıksal ve ampirik memnuniyete (satisfaction) dönüştürülüyor
    • Memnuniyet: tüm senaryolardan geçen gözlemlenmiş izlerin, kullanıcıyı tatmin etme olasılığı taşıyan oranını niceliyor

Digital Twin Universe ile senaryo doğrulama

  • Önceki düzende entegrasyon testleri, regresyon testleri ve UI otomasyonu ile "çalışıyor mu?" sorusuna yanıt aranıyordu
  • Daha önce güvenilir sayılan yöntemlerde iki sınırlama tespit edildi:
    • Testler fazla katı: Kod ajanlarla yazıldığında ve LLM ile ajan döngüleri tasarım primitifi olarak kurulduğunda, başarıyı değerlendirmek için çoğu zaman LLM-as-judge gerekiyor
    • Testler reward hacking’e açık: Modelin hile yapmasına daha az açık doğrulama yöntemleri gerekiyor
  • Digital Twin Universe (DTU) çözüm olarak sunuluyor: yazılımın bağımlı olduğu üçüncü taraf servislerin davranışsal kopyaları
    • Okta, Jira, Slack, Google Docs, Google Drive ve Google Sheets için twin’ler oluşturuluyor; API’ler, edge case’ler ve gözlemlenebilir davranışlar kopyalanıyor
    • DTU sayesinde, prodüksiyon sınırlarını çok aşan hacim ve hızlarda doğrulama yapılabiliyor
    • Canlı servislerde riskli ya da imkânsız olan hata modları da test edilebiliyor
    • Rate limit’e takılmadan, kötüye kullanım tespitini tetiklemeden ve API maliyeti biriktirmeden saatte binlerce senaryo çalıştırılabiliyor

Alışılmadık ekonomi

  • DTU ile elde edilen başarı, ajan çağı (Agentic Moment) yazılım ekonomisini kökten değiştiriyor iddiasının örneklerinden biri olarak gösteriliyor
    • Büyük SaaS uygulamalarının yüksek doğrulukta klonlarını oluşturmak her zaman teknik olarak mümkündü, ancak ekonomik olarak uygulanabilir değildi
    • Birkaç mühendis kuşağı boyunca insanlar test amaçlı bir CRM’in tam bellek içi kopyasını istedi, fakat yöneticilere bunu önermeye bile yanaşmadı (reddedileceğini düşündükleri için)
  • Software Factory kurucularının bilinçli saflık (deliberate naivete) pratiği yapması gerektiği savunuluyor: Software 1.0’ın alışkanlıklarını, teamüllerini ve kısıtlarını bulup ortadan kaldırmak
    • DTU ile 6 ay önce hayal bile edilemeyen şeyler artık gündelik iş akışının rutin parçası haline geliyor

Sonraki okumalar

  • Principles : Ajanlarla yazılım geliştirmeye dair inançlarımız
    • Yazılım, seed → validation harness → feedback loop yapısıyla büyütülüyor ve token’lar yakıt görevi görüyor
    • Her yazılımın başlangıçta bir seed’e ihtiyacı var: geçmişte bir PRD veya spesifikasyon, bugün ise birkaç cümle, ekran görüntüsü ya da mevcut bir kod tabanı yeterli olabiliyor
    • Validation harness uçtan uca olmalı ve gerçek ortama (müşteriler, entegrasyonlar, ekonomi) mümkün olduğunca yakın olmalı
    • Çıktı örneklerinin girdi olarak geri beslenmesi, sistemin kendini düzeltmesini ve doğruluğun bileşik şekilde artmasını sağlayan kapalı döngüyü oluşturuyor
    • Doğrulama ve geri besleme teorisi anlaması kolay olsa da, pratikte yaratıcı ve en ileri mühendislik gerektiriyor: her engeli modelin anlayabileceği bir temsile dönüştürmenin yollarını aramak
  • Techniques : Bu ilkeleri uygulamak için tekrar eden kalıplar
    • Digital Twin Universe (DTU)
      • Kritik üçüncü taraf bağımlılıkların dışarıdan gözlemlenebilir davranışlarını kopyalar
      • Prodüksiyon sınırlarının çok ötesinde hacim ve hızlarda doğrulama sağlar
      • Deterministik ve yeniden üretilebilir test koşulları sunar
    • Gene Transfusion
      • Ajanı belirli örneklere yönlendirerek kod tabanları arasında çalışma kalıplarını taşır
      • İyi referanslarla eşleştirilmiş çözümleri yeni bağlamlarda yeniden üretmeyi mümkün kılar
    • Filesystem
      • Modelin depoyu hızlıca dolaşmasını ve dosya okuma/yazma ile kendi bağlamını ayarlamasını sağlar
      • Dizinler, indeksler ve disk üzerindeki durum pratik bir bellek temeli olarak çalışır
    • Shift Work
      • Etkileşimli işleri tamamen spesifikasyonu yapılmış işlerden ayırır
      • Niyet tam olduğunda (spesifikasyon, testler, mevcut uygulama), ajanın gidip gelmeden uçtan uca çalışmasını sağlar
    • Semport
      • Anlamsal farkındalığa sahip otomatik portlama, tek seferlik veya sürekli yapılabilir
      • Niyeti koruyarak kodu diller ya da framework’ler arasında taşır
    • Pyramid Summaries
      • Birden fazla yakınlaştırma düzeyinde geri dönüşlü özetler
      • Tüm ayrıntılara yeniden genişletebilme yeteneğini kaybetmeden bağlamı sıkıştırır
  • Products : Her gün kullandığımız ve başkaları için de yararlı olacağını düşündüğümüz araçlar
    • CXDB, AI ajanları için self-hosted bir bağlam deposu; Turn DAG, blob deduplication, dynamic type ve visual debugging sunuyor
    • StrongDM ID, insanlar, iş yükleri ve AI ajanları için bir kimlik sistemi; federated authentication ve path-scoped sharing desteği sunuyor
    • Attractor, phase graph ile yapılandırılmış etkileşimsiz bir kodlama ajanı; görev tamamen spesifiye edildiğinde uçtan uca çalışıyor

3 yorum

 
pencil6962 2026-02-08

Spesifikasyon odaklı geliştirmeyi, çoklu ajan kullanarak denedim. İş yükünü ciddi ölçüde azalttığı doğru, ancak LLM'lerin performans sınırları nedeniyle müşteriyi tatmin edecek bir ürün ortaya çıkaramıyor. %100 ikame mümkün değil ve belli ölçüde insan emeği gerekiyor.

 
xguru 2026-02-08

Biraz fazla kışkırtıcı ama bir ölçüde anlaşılır da geliyor.. İnsanın içinde tuhaf bir his bırakan bir yazı.

Bu yazıyı görüp aşağıdaki yazıyı okuyunca daha çok empati kuruyorsunuz.
Zanaatkârlığımızın yasını tutuyoruz

 
GN⁺ 2026-02-08
Hacker News görüşleri
  • Ben Digital Twin Universe kavramına katılıyorum
    Benim kod tabanımda da çok sayıda dış servis entegrasyonu var, bu yüzden test sırasında dış çağrıları engelleyince neredeyse hiçbir şeyi doğrulayamaz hale geliyorduk
    Bu nedenle Okta, Jira, Slack, Google Docs gibi her API için sahte uygulamalar oluşturup test ettik
    Ancak UI'ı kopyalamadık, yalnızca API davranışını taklit ettik

  • “Mühendis başına günde 1.000 $ token harcamıyorsanız gelişime açık alan vardır” sözü fazla gerçek dışı geliyor
    Bunun gerçekten ciddi bir iddia olduğundan şüpheliyim

    • Hesaplayınca yıllık yaklaşık 250 bin $ ediyor
      Eğer yapay zeka gerçekten o kadar üretkenlik sağlıyorsa mantıklı olabilir
      Gerçekte ise muhtemelen iki junior mühendisin verimi civarındadır
      Sonuçta insanlar sadece liderlik rolünde kalıp planlama ve doğrulama yapacak gibi görünüyor
      Abartılı bir iyimserlik ama tamamen deli saçması da değil

    • Ben sadece aylık 20 $'lık Claude ve OpenAI aboneliklerini kullanıyorum
      Tokenlar bitince yürüyüşe çıkıyor ya da kitap okuyorum
      Hızlanmacı değilim ama yine de işimi gayet yapıyorum

    • Ben StrongDM ekibinden biriyim
      Günde 1.000 $ token harcamak kolay ama asıl mesele bunu verimli şekilde harcamanın zor olması

    • Bu bana sadece bir gösteriş gibi geliyor
      Sanki “biz AI konusunda sizden daha ilerideyiz” sinyali veriyorlar

    • Yazıyı okurken utanç hissettim
      Mevcut mock'ları ya da simülasyon testlerini “inovasyon” gibi paketlemişler hissi verdi
      Yine de maliyet yapısını açıkça ortaya koymalarını takdir ediyorum

  • Sitelerinde gerçek bir kod ya da ürün arıyordum
    Bulabildiğim tek şey strongdm/attractor oldu
    “Kanadalı kız arkadaş kodlaması” artık bir iş modeline dönüşmüş gibi
    Ayrıca strongdm/cxdb'yi de buldum ama commit geçmişi temizlenmişti

    • Gerçek kod cxdb deposunda var

    • Bunun delilik mi yoksa geleceğin bir kesiti mi olduğunu bilmiyorum

    • Products sayfasında veritabanı ve kimlik sistemleri de var
      Birden fazla ajan birlikte çalışacaksa paylaşılan bağlam ve yetki sistemi şart

    • BoundaryML'in BAML ile ilgili webinarını dinledim
      Spec-driven development, insanın döngünün içinde olduğu yapılandırılmış iş akışları oluşturma yaklaşımı
      /research → /plan → /implement döngüsünü açıkça tanımlıyor ve her aşamada insan doğrulaması istiyor
      Bu, StrongDM'in “insan kod yazmaz ya da okumaz” iddiasının tam zıttı bir felsefe

    • Bu da bana bir başka boş blog yazısı gibi geliyor
      Ortada somut bir çıktı yok ve günde 1.000 $ token söylemi yatırımcılara oynuyormuş gibi duruyor

  • Doğrulama sorununu çözemezseniz bunların hepsi gösterişten ibaret kalır
    Otomatik review ya da guardrail kursanız bile, sonunda spesifikasyon ile sonucun örtüşüp örtüşmediğini kontrol edecek biri insan olacak

    • Biz Speedscale'de trafik yakalama ve yeniden oynatma ile doğrulamayı otomatikleştiriyoruz

    • Aslında insan geliştiriciler de kusursuz değil
      Kod incelemesi, test, QA gibi çeşitli sistematik doğrulama süreçleri zaten var
      Önemli olan yapay zekanın kusursuz olup olmaması değil, sistemin toplam kalitesinin yakınsayıp yakınsamadığı
      Benim deneyimime göre Opus 4.5 ile az da olsa net pozitif etki var

    • Ben de neredeyse tamamen katılıyorum
      Esas mesele üretim değil doğrulama
      Birden çok bağımsız ajanın birbirleriyle fikir ayrılıklarını ortaya koyup uzlaşmaya vardığı bir yapı kuruyorum

    • Kısacası, doğrulama ve güvenlik testlerini son kullanıcıya yıkmak anlamına geliyor

    • Spesifikasyon tabanlı dilleri ve biçimsel doğrulamayı daha agresif kullanmalıyız
      Sonunda programlama, “bir spesifikasyonu somutlaştırma eylemi” olarak yeniden tanımlanacak

  • Günde 1.000 $ token demek, insanlardan çok yapay zekaya para harcamak demek
    Bu, AI vizyonunun çöktüğü nokta gibi görünüyor

    • Simon Willison'ın yazıyı güncellediği söyleniyor

    • Yıllık 240 bin $, giriş seviyesi bir FANG mühendisi seviyesinde
      Dürüst olmak gerekirse Claude'dan daha kötü birçok junior var
      Sonunda tepede az sayıda insanın olduğu bir piramit yapısına dönüşecek gibi

    • Aynı işi 5 günde bitirebiliyorsa, hıza göre maliyet makul olabilir

    • Çıktı da orantılı biçimde büyürse maliyet/verim dengesi tutabilir
      Üstelik token birim fiyatlarının düşmesi de mümkün

  • Hukuk ve sigorta sektörü bu değişimde en çok zorlanacak alanlar olacak
    İnsan hatası modellenebilir ama otonom döngülerin zincirleme hataları tamamen başka bir mesele

    • Sigorta sektörünün daha basit yaklaşacağını düşünüyorum
      AI'ın kararları eninde sonunda insan sorumluluğuna bağlanacak
      Bu da tüm agentic shift için bir fren mekanizması olabilir
  • Günde 1.000 $ token tamamen saçma bir metrik
    Kod kalitesi kötüyse token tüketimi patlar
    Sonuçta dağınık bir kod tabanı maliyeti büyütür
    Günde bin dolar yakan bir takımın verimliliği neredeyse yoktur
    (bkz: bu görsel)

    • Bu, kısa vadeli ve uzun vadeli optimizasyon meselesi
      Şimdi verimliliği mi artıracaksınız, yoksa tüm sistemi mi iyileştireceksiniz, seçim buna bağlı

    • Belki de yöneticiler ancak şimdi refactoring'in önemini fark eder

  • Daha önce sözünü ettiğim Dark Factory pattern ekibi tam da bunlardı
    İlgili yazıyı yazmıştım; bu ekip en iddialı deneycilerden biri

    • Ama pratikte ortada neredeyse hiçbir sonuç yok
      Birkaç üniversite öğrencisine 10 bin $ verseniz daha iyisini yaparlardı gibi

    • Günde 1.000 $ token mı? Benim ekip bütçemle hayal bile edilemez
      Kişisel olarak da geçim masrafları yüzünden imkansız
      Sonuçta insan “yapsan da batıyorsun, yapmasan da” hissine kapılıyor

    • Doğrulanabilir sonuç yoksa laftan ibaret
      Artık laf üretmek bile LLM'ler sayesinde çok daha ucuz

    • Etik açıdan daha açık bir paylaşım gerekli
      Sitedeki terimler, mevcut kavramların yeniden paketlenmiş hali gibi
      “Digital Twin Universe” mock'lar, “Gene Transfusion” referans kod okuma, “Semport” ise transpiling demek
      Ortada hiçbir gerçek veri ya da benchmark yok
      Bu, yapay zeka pazarlamasının mühendislik içgörüsü gibi sunulmuş hali

    • Aslında temel kodun çoğu zaten GitHub'da mevcut
      Gerçek fark yaratan şey mekanizma tasarımı ve değerler sistemi
      Gelecek, formal methods ile AI'ın birleştiği yere gidiyor

  • “Senaryoları holdout set olarak bırakıp test etme yöntemi” ilginç geldi
    Bu, QA ekibinin saldırgan testlerini taklit eden bir fikir
    Build ekibi ile bug bulma ekibini ayırıp karşılıklı rekabet yapısı kurmaları etkileyici
    Ama günde 1.000 $ token, açık kaynak geliştiricileri için umutsuzluk verici

    • Yerel modeller kullanılırsa maliyet düşürülebilir
      Bu başlıkta olduğu gibi yerel ajan otomasyonu gayet mümkün

    • Bir gün ajanların birbirine rüşvet verdiği durumları bile görebiliriz

    • Ben hâlâ insanın döngünün içinde kaldığı yaklaşımı tercih ediyorum
      Rastgele token yakmak israf

  • “LLMs aren’t tools” yazısında LLM kullanımına dair zihinsel çerçeveyi incelemiştim
    “Yazılım fabrikası” şu anki son durak ama bir sonraki aşama, LLM'i tek bir uygulama olarak görmek
    Yani basit iş akışı otomasyonu değil, özelleştirilmiş bir harness oluşturma aşaması