- İnsanların kod okuyup yazmadığı ışıksız (lights-off) yazılım fabrikası, üretim hızını artırsa da uzun vadeli bakım yapılabilirliği değerlendirecek insanı da devreden çıkardığı için karmaşık production kod tabanlarında çalışmakta zorlanır
- Kodlama modellerinin pekiştirmeli öğrenimi, test geçmek gibi hızlı ve net ödülleri optimize eder; aylar sonra ortaya çıkan kötü tasarım maliyetine ise ceza veremez
- SWE-bench ailesi hata düzeltmeyi ve mevcut testleri korumayı değerlendirir, ancak rastgele try/catch, type cast ve shotgun surgery gibi kod kalitesini yavaş yavaş bozan değişiklikleri ayıklayamaz
- Şu anda insanlar code review üstlenmeli ve ürün gereksinimleri, sistem mimarisi, program tasarımı, dikey dilimler uygulamadan önce incelenmelidir; ancak bu sayede yeniden çalışma ve büyük ölçekli AI üretimli kod incelemeleri azaltılabilir
- Modelin kısıtlarını kabul edersek, zorlama 10–100 kat otomasyon yerine insan seviyesine yakın kaliteyi koruyarak 2–3 kat daha hızlı geliştirme yapılabilir; temel kararlar ve kod okuma ise hâlâ dış kaynak kullanımıyla devredilemez
Döngü merkezli yazılım fabrikasının vaadi ve gerçeği
- AI ile kodlamanın production ortamına alınması yarışında, daha fazla harness ve agent loop eklemenin yeterli olduğu düşüncesi yayılıyor
- StrongDM'nin ışıksız yazılım fabrikası, insanların kod okuyup yazmadığı bir yaklaşımı öne çıkarıyor
- OpenAI'ın Symphony'si de harness engineering tabanlı bir yazılım fabrikası örneği
- Bu yaklaşım, darboğazın insan olduğu, modellerin yeterince iyi olduğu ve kod üretim maliyetinin fiilen düşük olduğu için daha çok şey yayınlamanın yeterli olduğu varsayımına dayanıyor
- Hedef, 10–100 kat hız, yüksek kalite ve insan code review sürecini aynı anda ortadan kaldırmak
- Daha fazla linter kurup PR review botlarına agresif inceleme yaptırarak yazılımın kendi kendine güvenli hale gelebileceği düşünülüyor
- Gerçek sahada ise kodlama agent'larının hataları yüzünden kesintiler yaşandığı ve kod tabanlarının hızla bozulduğu örnekler görülüyor
- Faros AI raporu, AI kodlama araçlarının benimsenmesinden sonra şu değişimleri gözlemliyor
- Review yorumlarının sayısı ve uzunluğu arttı, ancak review yapılmadan merge edilen PR'ler de çoğaldı
- Incident sayısı ve geliştirici başına düşen bug sayısı arttı
- Ancak bu doğrulanmış bir nedensellik değil, daha çok korelasyon sinyali
- StrongDM'nin sonuçlarını gösteren kesin veriler bulmak zor; şubattan hazirana kadar paylaşılan güncellemeler de seyrek
Karmaşık kod tabanları vibe coding'den farklı bir problem
- Az kişinin kullandığı yan projeler ile 10 yıllık kurumsal sistemleri sürdüren ekiplerin paylaştığı kısıtlar neredeyse yok
- Tartışılan konu vibe coding'in kendisi değil, karmaşık kod tabanlarının zor problemleri ve production bakım süreçleri
- Geçmişte brownfield, eski Java sistemleri gibi şeyleri ifade ediyordu; ancak agent'ların ürettiği kod tabanları da yüksek geliştirme hızı nedeniyle yaklaşık 3–6 ay sonra değiştirmesi zor hale gelebilir
- Sonuç kötü olduğunda bunun token veya teknoloji eksikliğinden kaynaklandığı söylenir; ama asıl sorun harness'ten çok modelin eğitilme biçimindedir
Yazılım fabrikasının evrimi
-
1968'den AI öncesine kadar
- “Yazılım fabrikası” terimi, “software engineering” ifadesinin ortaya çıktığı 1968 NATO konferansına kadar uzanır
- 2022 civarındaki tipik bir fabrika şu döngüye sahipti
- İnsanlar ne yapılacağına karar verir ve bunu Linear veya Jira gibi takip araçlarına kaydeder
- Sorumlu kişi implementasyon ve test yapar
- Otomatik kontroller ve insan code review sürecinden geçer; sorun varsa tekrar implementasyon aşamasına dönülür
- Production dağıtımından sonra izleme yapılır, incident'lar ve kullanıcı geri bildirimleri tekrar takip aracına eklenir
- Implementasyon ve review ayrı ayrı saatler veya günler alabildiği için ekipler planlama, mimari önerileri ve sprint planlarını öne koyarak önce uzlaşma yaratır
- Implementasyon öncesi uzlaşma yeniden çalışmayı azaltır ve kararlaştırılan yöne yakın, olgun PR'ler tüm satırlar okunsa bile hızlı incelenebilir
-
Agent tabanlı fabrika
- Ramp, Stripe, WorkOS ve Brex gibi şirketler, agent fabrikalarının kodun yaklaşık %75'ini ürettiğini söylüyor
- Mevcut fabrikada insanların implementasyon yaptığı adım agent'larla değiştirilip orkestrasyon, harness, sandbox, model ve bilgisayar kullanımı bir araya getiriliyor
- Implementasyon süresi saatler-günlerden dakikalar-saatlere iniyor, ancak insanların kod okuması ve test etmesi aynı kaldığı için review darboğaz haline geliyor
- Bu darboğazı azaltmak için çeşitli döngüler ekleniyor
- Stil, bug ve güvenliği denetleyen agent code review
- Tarayıcı ve bilgisayar kullanımıyla dış davranışı doğrulayan regression testleri
- Incident'ları otomatik olarak PR'lere bağlayıp sorumlu kişiye düzeltme adayı sunan akış
- Kullanıcı geri bildirimini doğrudan iş kuyruğuna bağlayan akış
- Sonuçta operasyonel sorun, iş kuyruğuna ne kadar çok iş sokulabildiği ve sonuçların ne kadar hızlı incelenip test edilebildiğine indirgeniyor
-
Işıksız fabrika
- Dan Shapiro tarafından adlandırılan ışıksız fabrika, insanların tüm değişiklikleri okuduğu aşamayı kaldırıyor
- Code review yerine şu alanlara yatırım yapılıyor
- Agent'ın kendi testleri
- Sandbox ve orkestrasyon
- Otomatik review ve izleme
- Kademeli yayın ve kullanıcı geri bildirim sinyallerinin toplanması
- İnsan yargısı çıkarıldığında geriye agent'a ne kadar çok iş verilebildiği kalıyor; ancak bu yaklaşım karmaşık production kod tabanlarında çalışmıyor
Doğrudan uygulanan ışıksız yaklaşımın başarısızlığı
- 2025 Temmuz'dan itibaren, sadece spesifikasyon ve ticket okuyup küçük-orta ölçekli işleri arka plan agent'larına bırakan tam ışıksız yaklaşım uygulandı
- Birkaç ay sonra, gelişmiş prompt ve workflow'larla da çözülemeyen karmaşık problemler ortaya çıktı
- Gerekli bağlam toplanıp modele verildi
- Agent, problemi yaklaşık 10 farklı şekilde yeniden üretmeye çalıştı
- Sonunda insanın, 3 aydır okunmamış kod tabanına girip doğrudan kök nedeni bulması gerekti
- Bu sırada site kesintiye uğradı, kullanıcılar rahatsız oldu ve insanlar birikmiş düşük kaliteli kodu okumak zorunda kaldı
- İlk başarısızlıkta hız uğruna risk almaya değeceği düşünüldü, ancak yaklaşık üçüncü problem kasımda yaşandığında baştan yeniden yazmak daha kolaydı
- Kurucu ortaklardan biri, VS Code'da 2 hafta boyunca kalıpları bizzat yeniden uyguladı
Modellerin kod tabanı kalitesini düşürmesinin nedeni
- Güncel modeller, önemli insan yönlendirmesi olmadan kod tabanı kalitesini uzun vadede koruyup iyileştiremiyor
- Buradaki bakım yapılabilirlik, bir yeri değiştirince başka yerlerin bozulduğu ve aynı değişikliğin birçok konuma uygulanması gereken shotgun surgery durumundan kaçınabilme yeteneği
- Modeller tek seferlik problem çözme veya yeni bir pazarlama sitesi üretmede çok ilerledi; ancak zaman içinde kod kalitesini iyileştirme yeteneklerinin belirgin biçimde geliştiğini söylemek zor
- Bakım yapılabilirliği ölçecek iyi benchmark'lar olmadığı için bu farkı kanıtlamak ya da çürütmek de zor
- GPT-5.5 xhigh gibi bir model harika refactor yapabilse bile, insanın kod tabanını anlaması ve gerekli işi somut olarak tarif etmesi gerekiyorsa ışıksız fabrikanın sorunu çözülmüş olmaz
Claude Code ve harness içi pekiştirmeli öğrenim
- Claude Code'dan önce de aider, cline, codebuff gibi CLI agent'ları okuma, yazma, düzenleme, arama, shell araçları ve context engineering sağlıyordu
- Önceki agent'larda aynı düzenlemeyi tekrar tekrar başarısız deneme gibi araç kullanımında kararlılık sorunları olabiliyordu
- SWE-Agent makalesi, ReadFile çıktısına satır numarası eklemek veya Edit'i bul/değiştir yerine satır aralığı düzenlemesine çevirmek gibi küçük araç tasarımı farklarının bile performansı etkilediğini analiz ediyor
- Claude Code'un hızla büyümesinin temel nedenlerinden biri olarak Anthropic'in modeli gerçek üründe kullanılacak harness içinde pekiştirmeli öğrenimle eğitmesi gösteriliyor
- Model ağırlıkları, agent loop içinde doğru araç kümesini çağıracak şekilde ayarlanıyor
- Dış geliştiriciler araç tanımlarını ve değerlendirmeleri model tercihlerine uydururken, model sahibi modelin kendisini araca uyacak şekilde değiştirebiliyor
- Hem harness'e hem model ağırlıklarına sahip ekipler, yalnızca harness yapıp ağırlıkları ayarlayamayan ekiplere göre avantajlı
Kodlama agent'larının pekiştirmeli öğreniminde ödül sınırları
- Kodlama modellerinin pekiştirmeli öğrenimi genel olarak şu süreci milyonlarca kez tekrarlar
- Test düzeltme gibi bir problemi çözmeye yönelik agent çalıştırma izi üretilir
- Bir doğrulayıcı, çalıştırma izini değerlendirir
- İyi çalıştırma izlerinin olasılığını artırıp kötülerin olasılığını azaltacak şekilde model ağırlıkları güncellenir
- Sorun, değerlendirme puanının aşırı tek boyutlu olabilmesidir
-
SWE-bench Multilingual örneği
- SWE-bench Multilingual, Redis, jq, Django gibi açık kaynak depolardan alınmış yaklaşık 15 dakikalık işleri kullanır
- Ödül 0 veya 1'dir ve iki koşulu kontrol eder
FAIL_TO_PASS: İstenen sorun çözüldü müPASS_TO_PASS: Mevcut davranış bozulmadı mı
fastlane__fastlane-19304görevi, isteğe bağlıinclude,excludeparametreleri olmadığında nil üzerinde.empty?çağrıldığı için oluşan bir bug'dır- Gerçek insan düzeltmesi, nil'i boş diziye varsayılanlayan iki satırlık bir değişiklikti
- Model, düzeltmeden hemen önceki temel commit ile bug raporunu alır; doğru patch'i ve puanlama için kullanılan test patch'ini görmez
- Değerlendirme şu sırayla yapılır
- Modelin ürettiği patch korunur
- Modelin test dosyalarında yaptığı değişiklikler kaldırılır
- Benchmark'ın gizli test patch'i uygulanır
- Mevcut testler ile yeni testler birlikte çalıştırılır
- Test değişikliklerinin atılma nedeni, modelin başarısız testleri yorum satırına alarak veya anlamsız mock'lar ekleyerek geçirmeye çalışabilmesidir
- Benchmark ile pekiştirmeli öğrenim doğrulayıcıları aynı şey değildir ve ayrı tutulmalıdır; ancak ikisi de kodlama çalıştırma izlerinin kalitesini yargılamadaki yapısal sınırları gösterir
-
Tasarım bozulmasına ceza yok
- Testler geçtiği sürece çözüme nasıl ulaşıldığı ve yapısal kalite puana yansımaz
- Her yeri try/catch ile sarmak veya type system'ın avantajlarını bozan gevşek type cast'ler yapmak da doğru cevap sayılabilir
- Bakım yapılabilirliğin bozulması, mevcut testler ve yeni testler geçtiği sürece ceza almaz
Test geçmekten daha zor olan kalite doğrulaması
- Testler saniyeler içinde net başarı/başarısızlık sunar; bu yüzden pekiştirmeli öğrenim milyonlarca kez tekrarlanabilir
- Kötü mimarinin maliyeti ise haftalar, aylar veya yıllar sonra; küçük bir değişikliği birçok yere uygulamak gerektiğinde ortaya çıkar
- Mevcut benchmark'lar bu uzun vadeli tasarım maliyetini değerlendiremez
- Pekiştirmeli öğrenim ile benchmark aynı şey olmasa da, bakım yapılabilirlik pekiştirmeli öğrenimde çözülmüş olsaydı bunun benchmark tasarımında da görülmesi beklenirdi
- Bu yüzden mevcut benchmark puanlarındaki artış, modelin artık kod tabanını kirletmediğinin kanıtı sayılamaz
Bakım yapılabilirliği değerlendirmeye yönelik yeni denemeler
- Model kalitesinin sınırları iyileşiyor, ancak teknik disiplinin önüne beklenti ve pazarlama geçmiş durumda
- Bakım yapılabilirliğe daha yakın değerlendirme girişimleri arasında şunlar var
- SWE-Marathon: Excel'in tüm işlevlerini kopyalamak gibi yaklaşık 400 saatlik görevler ve tek bir başarı/başarısızlık yerine bileşik ödül kanalları kullanır
- DeepSWE: Gerçekte henüz uygulanmamış büyük açık kaynak görevlerini kullanarak eğitim verisi kirlenmesini azaltır, ancak kalite sorununu tek başına çözemez
- Frontier Code: Birden fazla PR'ye yayılan işleri değerlendirir ve patch öncesi kodda da başarısız olmayan testler yazılırsa ceza verir
- Testlerin geçerliliğini belirlemek için mutation testing benzeri deterministik bir kontrol uygular
- Diff'i kod kalite kurallarına göre inceleyen bir yargıç modeli de çalıştırır
- Yargıç model kaliteyi güvenilir biçimde ayırt edebiliyorsa, en baştan iyi kod üretmek de mümkün olmalıydı gibi bir sınıır vardır
- Pekiştirmeli öğrenim hızlı ve güvenilir bir oracle gerektirir; ancak bakım yapılabilirlik için böyle bir oracle yoktur
- Review agent'ları ve ek token'lar bariz hataları yakalayarak taban kaliteyi yükseltebilir; ancak pekiştirmeli öğrenimin modele öğrettiği seviyenin ötesinde tavan kaliteyi artırmaz
- SWE-Marathon, DeepSWE ve Frontier Code başarı/başarısızlık kararının ötesine geçip bakım yapılabilirliği ölçmeye çalışan ilk girişimlerdir; ancak henüz tüm kod tabanını emanet edecek seviyede değiller
İnsanı yeniden döngüye sokan 4 adım
- Şu anda güvenilir kalite değerlendiricisi insan olduğu için code review geri getirilmeli
- Uzun review'ler ve yeniden çalışma ihtimalini azaltmak için AI öncesinden beri kullanılan ön planlama uygulanmalı
- AI'ın kaldıraç etkisi; ürün gereksinimleri, sistem mimarisi, program tasarımı ve dikey dilimler olmak üzere dört aşamada kullanılmalı
-
1. Ürün incelemesi
- Kısa cümleleri veya uzun ses notlarını yarı yapılandırılmış belgelere dönüştürerek neyin neden yapıldığını sabitleyin
- Önce kullanıcının diliyle çözülecek problemi tanımlayın ve yayına çıktıktan sonra başarıyı ölçmek için kriter belirleyin
- Workflow tamamlama süresinin kısalması
- Onboarding kilometre taşlarına daha erken ulaşılması
- Hata oranı veya gecikme süresinde iyileşme
- Belirli destek ticket'larının azalması
- Teknik ayrıntılardan çok kullanıcı deneyimine odaklanın; teknik kararlar ürün kararlarını bloke ediyorsa mevcut belgeyi kaydedip mimari incelemeye veya fizibilite prototipine geçin
- Ekran davranışını uzun açıklamalardan ziyade kaba HTML taslaklarıyla doğrulamak uzlaşma için daha etkilidir
- Metin düzeltmeleri, tek seferlik script'ler ve yeniden üretim yöntemi net bug'lar için bu süreç uygulanmaz; bunlar doğrudan agent'a verilir
- Agent'ın niyeti yanlış anlaması halinde maliyeti yüksek değişiklikler ürün incelemesinin konusu olmalıdır
- PR incelemesini yapacak kişinin ürün ve teknik spesifikasyonu da önceden görmesi gerekir; bunun için eşzamansız belge yorumları veya GitHub, Notion gibi araçlar kullanılabilir
-
2. Sistem mimarisi
- Servisler, endpoint'ler, schema'lar, kuyruklar ve depolar arasındaki iletişim biçiminde uzlaşılır, ancak program içi implementasyon ayrıntısına inilmez
- İnsanlar ile agent'lar arasındaki iletişim bant genişliğini artırmak için şu gösterimler kullanılır
- UI, API, servis ve depo arasındaki sequence diagram
- İstek/yanıtı gösteren API sözleşmeleri
- Yeni tabloları ve sorgu biçimlerini gösteren veri modelleri
- Mermaid yararlıdır, ancak aşırı kullanımı gerçek uzlaşma sağlandığına dair yanlış bir güven duygusu verebilir
- Mimari inceleme, modelin kötü alışkanlıklarını erken durdurmada etkilidir; ancak tek başına yüksek kaliteli kodu garanti etmez
-
3. Program tasarımı
- Implementasyondan önce, mimarinin bir seviye altındaki kodun biçimi belirlenir
- Type'lar
- Method signature'ları
- Program yerleşimi
- Call stack
- Karmaşık Mermaid yerine hafif pseudo-code görselleştirmeleri daha okunaktır
- Orkestrasyon veya kontrol akışı değişikliklerinde call stack ağacı kullanılır; değişen kısım önemliyse diff sözdizimi uygulanır
- Dosya ağacı diff'i ile yeni ve değişen dosyaların yeri ile rolü doğrulanır
- Temel fonksiyonların type ve method signature'larını önceden belirlemek, agent'ın iç tasarımda yanlış seçim yapma olasılığını azaltır
- Taslağı model hazırlayıp insan ayarlayabilir; bu, code review sırasında örtük olarak verilecek kararları daha ucuz bir ana çekmektir
- Implementasyondan önce, mimarinin bir seviye altındaki kodun biçimi belirlenir
-
4. Dikey dilimler
- Modeller; veritabanı migration'ı → servis katmanı → API → frontend sırasıyla ilerleyen yatay planı tercih eder
- Yatay plan, iş sırasında gerçek çözümü tarayıcıda veya curl ile dokunup doğrulamayı zorlaştırır
- AI öncesi geliştiriciler, 500 veya 2.000 satırı tek seferde yazmak yerine ortadan dışa doğru ilerleyip sürekli doğrulama yapıyordu
- API sözleşmesi ve mock data oluşturulup curl ile kontrol edilir
- Frontend mock data'yı kullanır ve tarayıcıda iyileştirilir
- API servis katmanına bağlanır
- Veritabanı migration'ı ve depo bağlantısı eklenir
- İş mantığı eklenir
- Hata işleme eklenir
- Dikey dilimler veya tracer bullets, her adımda gerçek çalışan davranışın test edilip iyileştirilmesini sağlar
- Kalitenin özellikle önemli olduğu alanlarda, her adımda 100–200 satır inceleyip yönü yeniden ayarlamak; 2.000+ satırı geç fark edip düzeltmekten daha ucuzdur
- En yeni modeller bile insan yönlendirmesi olmadan böyle bir plan kurmakta zorlanır; ayrıca kod tabanı ve görevler arasında genelleme yapmakta da yetersiz kaldıkları için insanın döngüde kalması gerekir
İş boyutuna göre uygulama biçimi
- 30 dakikalık ön planlama, implementasyon sonrası saatler sürecek review'leri azaltabilir
- İnsan seviyesine yakın kaliteyi korumak için ürün tasarımı, sistem mimarisi, program tasarımı ve dikey dilimlerde insan katılımı gerekir
- Her işe tam süreç uygulanmaz
- Yaklaşık %40 tek seferde üretilir veya 1–2 hafif geri bildirim turuyla tamamlanır
- Orta büyüklükte işlerde ürün ve sistem tasarımı tek bir plan belgesinde birleştirilir, implementasyon aşamaları bölünmez
- Büyük işlerde dört adımın tamamı uygulanır; ancak büyük refactor'larda ürün incelemesi uygun değilse o adım atlanır
- Genellikle modele aynı anda 1–3 dilim verilir ve ilerlemekte olan kod gözden geçirilir
- Erken aşamada iç yapı veya işlevi düzeltmek, toplu üretimden sonra neyin yanlış gittiğini aramaktan daha kolaydır
Darboğaz PR sayısı değil, PR kalitesidir
- Darboğaz, çok fazla PR olması değil çok fazla kötü PR olmasıdır
- Kararlaştırılmış tasarıma ve takım alışkanlıklarına uyan temiz PR'ler, tüm dosyalar okunsa bile hızlı incelenebilir
- PR'lerin sadece %20'sinin yeniden çalışma gerektirmesi bile hem gönderici hem inceleyen için bilişsel ve duygusal yük yaratır
- AI'ın tek seferde ürettiği PR'lerde yeniden çalışma oranı çoğu zaman %50'ye yaklaşır
- Gönderici AI olsa bile birinin işi başlatması, sonucu düzeltmesi veya sorumluluğu üstlenmesi gerektiği için yeniden çalışma maliyeti ortadan kalkmaz
Kısıtları kabul eden geliştirme hızı
- Mevcut temel kısıt, modellerin iyi yaptığı ve yapamadığı işlerin net olması ve bir süre daha insanların kod okumak zorunda kalacak olmasıdır
- Kod kalitesinin önemsiz olduğunu varsayıp 10–100 kat hıza koşmak yerine, sistem bu kısıtlar içinde optimize edilirse güvenli biçimde 2–3 kat hız elde edilebilir
- Pratik ilkeler dört maddede özetlenebilir
- Modellerle yeterince çalışıp kısıtlar konusunda sezgi geliştirin
- Geliştirme sistemini bu kısıtlar içinde optimize edin
- Kaldıraç etkisi yüksek noktaları bulun
- Gerçek kodu okuyun
- Harness ve loop'lar bariz hataları azaltan araçlardır; ancak bakım yapılabilirlik değerlendirmesinin ve tasarım düşüncesinin yerini tutamaz
1 yorum
Hacker News yorumları
Buna niyet-uygulama-kalite sorunu deniyor
Yazılım fabrikası tek satırlık bir gereksinimle uygulama, özellik, hata düzeltmesi, tasarım değişikliği ve refactoring bile gerçekleştirebilir; ancak o gereksinimin arkasındaki insan niyetini ve ürünün gelişim yönünü doğru biçimde üretebilip üretemeyeceği ayrı bir mesele
Uygulama yöntemleri kombinatoryal olarak patlar; sistemle tutarlı, ölçeklenebilir, anlaşılması kolay ve milyonlarca kullanıcıyı güvenle destekleyen “doğru” yöntem kişiye ve probleme göre özneldir. Testler ve çalışma kanıtları bazı kaliteyi artırabilse de bu tür öznel kaliteyi doğrulayıp düzeltecek bir geri bildirim döngüsü yok
Koda hiç bakmadan yalnızca gereksinimin başarılı olup olmadığını geri bildirim olarak alan bir denge de mümkün olabilir; ancak bunun dışındaki yazılımlarda niyet ve öznel kalite sorunu henüz çözülmüş değil
Yazıda iyi noktalar var, ancak Temmuz 2025’teki insansız işletim deneyini mevcut ajanların sınırı olarak genellemek zor
Modellerin faydası 2025 sonbaharı ya da 2026 ilkbaharı civarında büyük bir sıçrama yaptı; ben de ancak bundan sonra ajanlara bütün bir özelliği devredebildim. Yazı model iyileşmelerinden söz edip fiilen yok sayıyor; bu benim deneyimimle örtüşmüyor
Opus 4.6 sonrası modeller 700 bin-900 bin token’da bile zekâ düşüşünü hissetmek zor olacak kadar kararlıydı; maliyet verimliliği çok düşük ama çalışıyor
Mevcut modellerin kapasitesini iyi bildiği için, şu anda insansız yazılım fabrikasının mümkün olduğuna karar verseydi yeniden deniyor olurdu
Güncel frontier modellerin de bağlamdan kopmayı veya shotgun surgery’yi daha iyi ele almadığını düşünüyorum. Buna karşı çıkılacaksa basitçe yok saymak yerine somut kanıt ve farklı kullanım deneyimleri sunulmalı
4.5 daha hızlıydı; basit prompt’ları ve örtük niyetleri iyi okuyarak yeni kullanıcıları hızla çekmekte avantajlıydı
Kendi yazılım fabrikamı 8 ay boyunca kurup işlettim; otomatik iş toplama ve PR gönderimi henüz yok, ancak gereksinimleri belirledikten sonra çoğunlukla dağıtıma kadar kendi ilerliyor. Sistem değerlendirmesinden sonra son 4 ayda kod incelemeyi bıraktım
Tek satırlık prompt yerine bir mülakat süreciyle önce açık soruları ve belirsizlikleri gideriyor; güvenlik önlemi olarak plan incelemesi, tarayıcı tabanlı kalite güvencesi, adversarial inceleme, birim testleri, linter, tip denetleyici, commit sonrası hook’lar ve biçimsel yöntem izleme kullanıyorum
Tekrarlayan hatalar ortaya çıktığında koda bakmadan da kirlenen alanları tespit edebiliyorum. Gereksinimler artıp durum değişkenleri üst üste bindiğinde bunları tek bir sum type’a refactor ediyor; karmaşıksa Quint ile biçimsel model ve izleme oluşturup birim testi olarak çalıştırıyorum
Kod tabanı bir yıldan eski frontend ve backend’den oluşuyor. Ajan mevcut kalıpları aynen kopyaladığı için net ilkeler önemli; yeni sistem sınırlarını ayırırken Sonnet düzeyi modeller sık sık yanlış karar veriyor, Opus daha iyiydi
Kalite düşüşünü genellikle tespit edebildim; kodu açıp sorunu bulduktan sonra ajanla toparlayamadığım olmadı. Ortalama bir mühendisin kod tabanındaki kirlenmeyi geri döndüremediği bir durum da görmedim
Kod tabanının nasıl çalıştığını anlamanız gerekir ya da anlamanız gerekmez; ikisinden biri
Claude sizin yerinize kod yazabilir ama sizin yerinize anlayamaz; bu süreç hâlâ insan hızında ilerler. Her şeyi anlamanız gerekmeyen durumlar vardır, ancak daha ince bir ayrım gerekir; Claude kusursuz kod yazsa bile bu gerçek değişmez
LLM’lerden önce de büyük kod tabanlarının tamamını bilen kimse yoktu; ama insanlar en azından kendi oluşturdukları PR’ı ve sorumlu oldukları alanı genel olarak anlıyordu
Kendi deneyimime çok benzediği için içim rahatladı. Son dönemde sıkça sözü edilen zevk ve muhakeme aklıma geliyor
Mimari kalitesi, moda gibi nesnel bir doğru cevabı olmayabilecek bir şey; mantığı ve rasyonelliği makineye devrettikten sonra insanların estetik çalışması gerekebilir
Uygulama sürecinin sağladığı molalar olmadan, neredeyse eşdeğer seçenekler arasında sürekli ödünleşimleri değerlendirmek zorunda kalmak yorucu; Fable ya da GPT-5.6 düzeyi modellerde bile kod incelemesi hâlâ gerekli. Küçük kusurları akılda tutup benzer sorunlar yeterince birikince hepsini birden düzeltiyorum
Ajanlar konusunda da az sayıda çok iyi insanla yakın çalışmak mı, yoksa büyük ölçekli alt ajanlar çalıştırıp iyiyi kötüyü otomatik ayıklamak mı gerektiğine karar vermek gerekiyor. Benim tercihim az sayıda, yüksek düzeyde uyumlanmış ekip, ama doğru cevap olup olmadığını zaman gösterecek
Zevk denen şey, yazılım yaparken bizzat patlattığınız tüm anti-pattern’lerden ve mayınlardan gelen zahmetle kazanılmış sezgidir
https://www.youtube.com/watch?v=eIoohUmYpGI
Bu kişi geçmişte de temelsiz şeyler uydurup yayarak zarar verdiğini kabul etmişti; bu fikrin iyi olduğuna dair de hiçbir kanıt yok. Ona yeniden güvenmek için bir gerekçe gerekiyor
Şu anda en göze çarpan sorun PR inceleme kullanıcı deneyimi
GitHub’ın PR ekranından hep nefret ettiğim için branch’i indirip farkları
$EDITORile kontrol ederdim; artık bunun bu kadar zahmetli olması için bir sebep yok. Kod inceleme şirketi bile olmayan Linear, küçük bir modelle değişen dosyaları konuya göre gruplayıp açıklama ve önem sırası ekleyerek GitHub’dan daha iyi bir temel özellik sunuyorİnceleyen ve talep eden kişi için ek iş çıkmadan bilişsel yük ciddi biçimde azalıyor; görselleştirme gibi devam özellikleri de gayet mümkün. Bu yaklaşımın yanlış olup olmadığını ya da yaygın kullanılan bir alternatif bulunup bulunmadığını merak ediyorum
https://linear.app/docs/diffs#guides
Güçlü rollback süreçleri de varsa PR kapısı, yararlı sorunları yakalayamayan gereksiz bir adıma dönüşür ve ekip üyeleri doğrudan merge edebilir
Gerçekten çalışan yazılımı incelemek gerekiyor; değişikliği anında demo edebilen bir sisteme ihtiyaç var. Kodun ve spesifikasyonların ağırlığı azalacak, gelecekte yazılım üretimi GitHub’dan çok Replit’e benzeyecek
Tree-sitter tabanlı bir yaklaşım olan https://github.com/0x007BA7/codebook ile deneme yaptım ve hoşuma gitti. Henüz üretim ortamında kullanılacak düzeyde değil ama benzer bir yaklaşımı ürünleştirme imkânı var
Yazılım fabrikasına karşı ikircikli hissediyorum
Çekirdek ürün, ölçeği büyük olduğu için her değişiklikte insan girdisi gerektiriyor; ama hafif refactoring, test yazma ve UI değişikliklerini otomatikleştirme iyi çalışıyor. Buna karşılık küçük deneylerde, ortaya çıkan kod çok özel olmasa da ileride genişleme potansiyeli görüldü; baştan ajanların yazacağı varsayımıyla yeni stratejiler ve mimariler tasarlanabileceğini düşünüyorum
Yöne hiç müdahale etmediğim açık deneyleri https://relentless.works/ adresinde belgeledim. İşlem yapan ajanı da müdahalesiz izliyorum; yaklaşık %3 zararda ama tüm parayı kaybetmedi ve yakın zamanda yeni pozisyon da açtı
Yazılım fabrikası mümkün görünüyor, ancak yeni kavramlar, düşünme biçiminde değişim ve AI’ı bekleyecek sabır gerekiyor
Yazılım yapmanın ne olduğu konusunda daha en başta temel bir sorun var
GitHub ticket’larını AI ajanına atayıp sadece dinlenirseniz, soyutlama ve dolaylı katmanlar sürekli birikmeye çok yatkın. Kod yazarken “burada Redis kullansak?”, “API zaten gereken veriyi veriyor?”, “son 1 yıldır aktif olmayan müşterileri rapordan çıkaralım” gibi bakış açıları ortaya çıkar ve bir noktada bunları insanın değerlendirmesi gerekir
https://gwern.net/doc/cs/algorithm/1985-naur.pdf
Claude Code’un plan modu,
mattpocock/skills,obra/superpowers, araştırma-planlama-uygulama akışları buna örnekModelin belleği, insanın uyurken ağırlıklarına işlemesi gibi bütünleşmiyor; daha çok dünü hatırlamayan birine not vermeye benziyor. Entropisi yüksek bir sistemin zamanla projeye entropi eklemesi şaşırtıcı değil
Vibe coding projeleri bu tür israfla dolu, ama prompt’u yazan kişi bunu fark etmeyebilir. Aracın her gün zaman kazandırması güzel, fakat aşırı implementasyon ciddi bir sorun
İnsansız yazılım fabrikalarını tartışırken üretkenliği PR veya commit sayısıyla ölçmek komik. O yönden bakılırsa kod birimine şimdiden
bos(bunch of shit) denmesi gerekirhttps://en.wikipedia.org/wiki/The_Goal_(novel)
Aşırı uçtaki startup’larda olduğu gibi sermayeden tasarruf etmek yerine hayatınızdan yıllar koyduğunuz bir takasa daha yakındır