LLM Çağında Mühendislik

• Reindeer’de geçen bir buçuk yılın, LLM çağında ürün ve geliştirme organizasyonunun nasıl kurulması gerektiğine dair değerlendirmelerini özetleyen bir yazı; tüm içgörüler, insan bağlamının (human context) en kıt kaynak olduğu kabulünden yola çıkıyor
• İçerik üretim hacmi patlayıcı biçimde arttı ama insanların tüketim hızı aynı kaldı; bu fark yeni darboğazı oluşturuyor — slop’un slop’u beslediği (slop feeds slop) kısır döngü kesilmeli
• Modelleme ve API tasarımı gibi yapısal kararlar hâlâ insanların alanı; LLM’in ürettiği çıktılara "hayır" diyebilecek birine ihtiyaç var
• Yalnızca kod incelemesiyle LLM’i yenmek mümkün değil; bu yüzden linter’lar, LLM yargıçları (LLM judges) ve küçük PR’lar gibi otomatik ve disiplin temelli savunma katmanları kurulmalı
• Geliştiricinin temel yetkinliği derin teknik bilgi değil, context switching ve kendi context window boyutu; uyum sağlayan geliştirici aşırı üretken olurken, uyum sağlayamayan geliştirici ekip için net negatif (net negative) hale geliyor

---

İnsan bağlamı kıt bir kaynak

• Sektörde 25 yıldır değişmeyen gerçek şu: en pahalı kaynak insan bağlamı; insanlar da LLM’ler gibi sınırlı bir context window ve attention mask’e sahip
• Bugün değişen şey, her yandan LLM slop’unun akması; yeni darboğaz, üretim hızı ile insanların tüketim hızının oranı
• Sorun şu: slop, slop’u besliyor
  • LLM’in şişirdiği kod yorumları, gereksiz derecede uzun PR açıklamaları, sonuç yerine geçmişi anlatan dokümanlar
  • Sonraki LLM bunları okuyup bağlamı gürültüyle dolu halde aynı şekilde devam ediyor
• Organizasyon içindeki metin içerikleri sıkıştırılmış olmalı ve yalnızca koddan ve davranışından açıkça anlaşılmayan şeyleri içermeli

İnsanların yerini alamayacağı alanlar

• Modelleme insan işidir
  • CUJ’yi (Critical User Journey) API akışına çevirmek, bileşenlerin ne olduğunu ve her birinin ilgi alanı ile sınırlarının nerede olduğunu belirlemek
  • LLM kodu hızla ürettiği için kötü modelleme de hızla yayılır ve sonradan düzeltilemeyen eğri bağımlılıklar yaratır
  • Uygulama maliyeti düştükçe, nihai değerde yapıya dair insan kararlarının payı büyür
  • Modelleme, organizasyonun gerçek hakikatidir ve erişilebilir tek bir yerde canlı olarak bulunmalıdır
• API tanımı katı insan disiplini gerektirir
  • LLM belirli görevler için kullanışlı alanlar eklemeye eğilimlidir; bu alanların her biri API’yi kalıcı olarak kirletir
  • API bir kamusal sözleşmedir (public contract), karalama defteri değil — "hayır" diyecek bir insana ihtiyaç vardır

Slop’a karşı ölçekli savunma

• İnsan kod incelemesiyle LLM’i yenmek mümkün değil; ölçeklenmez ve sonunda herkesin gözünü kapatıp onay verdiği bir duruma varır
• Reindeer, otomatik zorlayıcı katmanlara yönelmiş
  • Linter’lar: servisler arası yasak bağımlılıklar, mimari sınırlar gibi mutlak mantık kuralları
  • LLM yargıçları (LLM judges): kodlaştırılması zor ama modelin denetleyebildiği şeyler; örneğin örtük sözleşmeler
• Ancak API’ye dokunulduğunda veya modelleme değiştiğinde gerçek insan incelemesi zorunlu
• Günlük seviyedeki kural şu: "birbirinize slop fırlatmayın"
  • Küçük PR’lar, gerekirse stacked PR’lar
  • 2.000 satırlık bir slop PR atma isteğine ve inceleyicinin gözünü kapatıp onaylama ihtimaline karşı koymak gerekir
  • PR, dikkatin (attention) temel birimidir — insanın context window’unu aşarsa onay alır ama okunmaz

Padded rooms — LLM’in serbest bırakılacağı alanlar

• Bu yapı kurulduğunda, LLM’in özgürce çalışabileceği alanlar olan "padded rooms" (tampon odalar) tespit edilebilir
  • Modellemeyi etkilemeyen ve uzun vadeli bağımlılığı olmayan alanlar
  • Slop oluşsa bile kolayca değiştirilebilir ve tüm kod tabanına yayılmaz
  • Şirket kodunun büyük kısmı böyle olabilir ama yük taşıyan (load bearing) kısım değildir
• Müşteri özelleştirmesinin cevabı da burada yatar
  • Özelleştirme yüzde 100 padded rooms içinde yaşamalıdır
  • Çekirdeğe sızdığı anda çekirdek parçalanır ve her yeni müşteri için risk doğar
  • Padded rooms, mimaride bedel ödemeden müşteriye hızlıca "evet" denmesini sağlayan altyapıdır

Teknik borcun ekonomik tersine dönüşü

• Yük taşıyan alanlarla padded alanların ayrılması, teknik borçla ilişkiyi de değiştirir
• Geçmişte: geliştirme sırasında modelleme sorunu fark edilirse gelecekteki kendine bırakılırdı; yeniden yazma maliyeti yüksek olduğu için büyük işlerin içinde borç yutulurdu
• Bugün: yeniden yazma maliyeti neredeyse 0’a yaklaşıyor
  • Asıl yatırım yazma işine değil, modellemeye yapılıyordu
  • Atmak, modellemeyi düzeltmek ve yeniden yazmak ucuz
  • Ertelemek ise çok pahalı — yanlış kodun içinden geçen her LLM onu benimser, slop slop’u besler; anında düzeltilmeyen bir modelleme hatası kısa sürede kat kat daha karmaşık bir borca dönüşür

Bu çağın PM’i

• PM rolü değişiyor — CUJ’nin API ve bileşenlere çevrilirken bozulmamasını sağlamak için modellemeden sorumlu kişiyle yakın çalışmalı
• PM ile modelleyici senkronize değilse
  • teknik olarak çalışan ama CUJ’yi karşılamayan bir ürün ya da
  • temiz bir CUJ’ye sahip ama makul biçimde üretilemeyen bir sonuç ortaya çıkar
• Reindeer’de PM, ayrı bir repoda doğrudan MVP inşa ediyor
  • Bu kodun asla production’a temas etmeyeceği varsayımıyla
  • LLM ile birlikte hızlı hareket edip müşteriye gösterilebilecek özgürlüğü kazanıyor
  • Başarılı olan ya da müşteriyle buluşması gereken şeyler resmî modelleme ve geliştirme sürecinden geçiyor
  • Çekirdeğe yatırım yapmadan önce hızlı demo kurup müşteri doğrulaması yapılabiliyor — fikir test etme hızı ile ürüne girecek şeyler üzerindeki cerrahi titizlik arasında denge

Döngüden çıkmayı sağlayan altyapı

• Bir ajanın elinden tutarak ilerletmek ile birden fazla görevi paralel çalıştırıp uyumaya gitmek arasındaki fark, iyi bir ödül fonksiyonudur (reward function)
  • Olmazsa LLM geri dönemeyeceği bir yolculuğa çıkar
  • Varsa ne zaman yakında ne zaman uzakta olduğunu kendi başına anlayabilir
• Geliştirmede iyi ödül fonksiyonu, iyi testler olarak karşılık bulur
  • Platform için E2E testleri dahil
  • LLM’i hiçbir şeyi test etmeyen mock’a dayalı kötü alışkanlıklardan uzaklaştırmak
  • LLM tabanlı çıktılar için Evals
  • Temiz bağlama sahip LLM yargıçları, otomatik inceleme döngüsünü çalıştırır — böylece yargıç, kodu yazan ajanın düştüğü aynı halüsinasyona düşmez
• Organizasyon düzeyinde bu altyapının paylaşılıyor olması gerekir
  • Reindeer’de kategorilere ayrılmış merkezi bir skill marketplace reposu var ve tüm iç becerileri içeriyor
  • Claude Code, Codex tüm harness’lerde otomatik destekleniyor; ayrıca kendisi kadar derin şekilde unhinged olanlar için pi.dev desteği de var
  • Yeni geliştirici anında organizasyonun tüm becerilerini alıyor (onboarding ve kurulum yapan beceriler dahil)

Geleceğin geliştiricisi

• Bu çağdaki geliştiricinin belirleyici yetkinliği, derin bilgi değil context switching ve kendi context window/attention mask boyutu
  • Büyük bir bağlamı koruyup odağını kaybetmeden görevler arasında geçebilen ve birden fazla ajanı paralel yönetebilen kişi kazanır
  • Sivri teknik derinlik, bunu LLM tamamladığı için daha az önemli hale gelir
• Ek bir yetkinlik de modelleme becerisi, sistem mimarisi hakkında iyi anlayış ve tasarım aşamasında neye dikkat edilmesi gerektiğine dair sezgidir
• Yeni dünyanın geliştiricileri ikiye ayırmasının nedeni
  • Uyum sağlayan kişi aşırı üretken (super-productive) olur
  • Uyum sağlayamayan kişi nötr değil, ekip için net negatif (net negative) olur
  • LLM bir çarpandır (multiplier) — kullanmayı bilen için üretkenlik, bilmeyen için yüksek hızlı hasar
  • Ödül açısından bakıldığında ikinci tip geliştiricinin maaşı 0 olur — iş bulamaz
• Çok daha az insanla çok daha fazla iş yapılabilir ama büyümek çok zordur; son derece seçici olmak gerekir

Token maliyeti hakkında

• Tekrarlanan soru: token maliyeti 5–10 kat artarsa ne olur
• Zaman geçtikçe bu endişe gerçekçi görünmüyor
  • AI tarafında hızlandırılmış bir Moore yasası var; dolar başına kalite artmaya devam ediyor
  • Yeterince fazla açık model bulunduğu için kartel oluşması mümkün değil
• Token’ların ucuz olmasının nedeni şu: Claudex bir anda mantıksız biçimde pahalı hale gelirse herkes herhangi bir neocloud üzerindeki Qwen’e geçer