Lore Hafta 1: Bir değişiklik nereye iner, bir kontrol neyi kontrol eder, düğmeye kim basar

Lab, haftalık yazı. 12 Ekim Pazartesi ile 18 Ekim Pazar arası, 2026, İstanbul saatiyle. Sayımları Pazar günü 18 Ekim'de saat 22.15 civarında yaptık, bu yüzden haftanın son bir buçuk saati rakamlara girmedi.

Bu hafta 33 pull request birleştirdik. Pull request, kodda bir değişiklik yapmak için açılan bir öneri: bizde bunu çoğunlukla bir kodlama ajanı açıyor, ana sürüme katılmadan önce de biri gözden geçiriyor. Tipik bir pull request açıldıktan yaklaşık 16 dakika sonra birleşti. Emeğin büyük kısmı, içerik motoru ve ona sohbet arayüzü kurduğumuz AutoReal'a gitti. Geri kalanı, ajanlar bir şey inşa ederken onları güvende tutan kurallara ayrıldı.

Değişen her şeyi uzun uzun sıralamak hem sıkıcı olur hem de pek bir şey öğretmez. Biz bunun yerine haftanın bize net biçimde gösterdiği üç fikri anlatmak istiyoruz:

1. Bir değişiklik nereye iner. Düzeltmelerimizden biri yanlış dala gitti. Bu olay, pull request zincirlerinin hiçbir hata vermeden nasıl bozulabileceğini gösteriyor.

2. Bir kontrol gerçekte neyi kontrol eder. Yeşil tik, ancak baktığı şey kadar değerlidir. Üstüne bir de hızlı gelmezse işe yaramaz.

3. Düğmeye kim basar. Bir ajan para harcayabiliyor ya da yayın yapabiliyorsa, o işin önüne koyduğumuz kapı, bir sayfada yazan kuraldan çok daha fazla iş görür.

Her fikirde aynı sırayı izliyoruz: fikir nedir, neden önemlidir, sade bir dille nasıl işler, başkaları bu konuda ne yazmış ve bizim haftamız bununla nasıl kıyaslanıyor.

Fikir nedir. Çoğu ekibin kodu takip etmek için kullandığı Git'te her değişiklik bir dalda (branch) yaşar. Pull request şunu der: "Bu daldaki değişiklikleri al, şu dala ekle." Eklenecek dala temel dal deniyor. Genellikle temel dal ana daldır, yani yayına giden sürüm. Ama temel dal başka bir özellik dalı da olabilir. O zaman ortada bir zincir, yani istif (stack) vardır: hâlâ incelenmekte olan büyük bir değişikliğin üstüne kurulmuş küçük bir değişiklik.

Neden önemli. Zincir, inceleme beklenirken işin durmamasını sağlar. Ama unutması kolay bir kural da getirir: birleştirme sırası tasarımın bir parçasıdır. Zincirin ortasındaki bir halkayı birleştirirseniz, ana dala değil, altındaki halkaya iner. Hiçbir hata görünmez. Değişiklik, istemediğiniz bir yerde öylece durur.

Sade bir dille nasıl işler. Üst üste dizilmiş tepsiler düşünün. En alttaki tepsi rafa konur, raf ana daldır. Her tepsi altındakinin üstünde durur. Ortadaki bir tepsiyi, altındakileri de kaldırmadan rafa koyamazsınız. GitHub'ın kendi yığınlı pull request belgeleri de aynısını söylüyor: bunlar alttan yukarı doğru birleşir ve yığının ortasındaki bir pull request tek başına birleştirilemez, çünkü altındakiler her zaman onunla birlikte gider. Temel dalı başka bir dal olan sıradan bir pull request'te böyle bir koruma yok. Onu birleştirirseniz değişiklikler temel dalına, yani alttaki dala iner, ana dala değil.

Bizim başımıza ne geldi. İçerik motorumuzun gerçek paylaşım işini taşıyan pull request büyüktü: 62 dosyada yaklaşık 3.650 satır ekliyordu. Üç şey onu engelliyordu: olmaması gereken bir şey dışa aktaran bir dosya, ücretli çağrı yapan ve onay istemeyen bir test betiği ve ana dalla bir çakışma. Düzeltmeleri, temel dalı o büyük pull request'in dalı olan ikinci bir pull request'e koyduk. Cumartesi akşamı ikincisi birleşti. Yani düzeltmeler ana dala değil, büyük dala girdi. Sonra büyük pull request birleştirilmeden kapatıldı. Dalın tamamını yeni bir pull request ile yeniden indirene kadar, yani yaklaşık bir buçuk saat boyunca, bunun hiçbir parçası ana dalda değildi. Üç çakışmayı iki tarafı da koruyarak çözdük. Düzeltmenin metni nereye gittiğini açıkça yazıyordu, yani etiket doğruydu. Eksik olan, zincirin sırasına dair bir plandı.

Başkaları ne diyor. GitHub'ın Merging a pull request sayfası şunu söylüyor: bir pull request birleştikten sonra dalını silerseniz, GitHub silinen dalı temel dal olarak kullanan açık pull request'leri, az önce birleştirdiğiniz pull request'in temel dalına taşır. Tepsi istifinde en alttakinin temel dalı ana daldır, bu yüzden önce onu birleştirip dalını silerseniz bu taşıma bir sonraki pull request'i ana dala getirir. Meta ve Google'da çalışmış mühendisler, istiflemeyi değişiklikleri küçük tutmanın ve inceleme beklerken çalışmaya devam etmenin yolu olarak anlatıyor. Bunun için araç gerektiğini ve sık sık rebase gerektirdiğini de açıkça söylüyorlar. Çok okunan o yazının yazarı, istif aracı yapan bir şirkete küçük bir yatırımı olduğunu belirtiyor. Boyut da burada önemli. Google'ın mühendislik kitabı küçük bir değişikliği yaklaşık 200 satır olarak tarif ediyor. DORA araştırma programı küçük partilerden yana. Programa göre yapay zekâ kodlama asistanlarıyla hızlıca yazılan büyük değişiklikleri incelemek, test etmek ve güvenle birleştirmek zor.

Biz nerede duruyoruz. Biz sıradan dal zincirleri kullandık, yani en az korumalı seçeneği. Hedefi yazdık, bu iyi. Ama birleştirme sırasını yazmadık, üstelik değişiklik Google'ın küçük saydığı boyutun 18 katından fazlaydı. İkisini de ders sayıyoruz: bundan sonra her zincirin ilk satırlarında birleştirme sırası yazacak, büyük işleri de daha erken küçük parçalara böleceğiz.

Fikir nedir. Biri pull request açtığında otomatik kontrollerimiz çalışır. Kodu hatalara karşı okur, testleri koşar ve uygulamayı bir sunucunun yapacağı gibi derler. Buna genellikle sürekli entegrasyon deniyor. Sonuç, yeşil bir tik ya da kırmızı bir çarpı.

Neden önemli. Yeşil tik bir sözdür. Kontrol, yayına giden şeye bakmıyorsa bu söz boştur. Kontrol yavaşsa da kimse onu beklemez ve küçük pull request'ler küçük kalmaz.

Sade bir dille nasıl işler. İki şey doğru olmalı. Kontrol, yayına giden şeye ya da en az onun kadar sıkı bir şeye bakmalı. Ve hızlı olmalı. Martin Fowler hız konusunda, Ekstrem Programlama'nın (XP) on dakikalık derleme ölçüsünün çoğu proje için makul olduğunu yazıyor. DORA programı da aynı şeyi istiyor: her commit bir derleme başlatmalı ve testler birkaç dakika içinde geri bildirim vermeli. DORA ayrıca, sürekli entegrasyon derlemesinin ürettiği paketin geçerli paket olması gerektiğini, sonraki her adımın onu kullanması gerektiğini ekliyor.

Bizim başımıza ne geldi, birinci kısım: yanlış kontrol. Aynı uygulama birden fazla araçla derlenebilir. İçerik motoru pull request'i, yayında çalışan araçla sorunsuz derlendi. Daha katı olan ikinci araçla ise bir rota dosyası olmaması gereken bir şey dışa aktardığı için derlenmedi. Otomatik kontrollerimiz uygulamayı hiç derlemiyordu, bu yüzden hata incelemeye kadar geldi. Önce katı aracı, sonra yayındakini çalıştıran bir derleme adımı ekledik. Aynı değişiklikte, adları yalnızca büyük küçük harf bakımından ayrılan bir dosya çiftinden birini yeniden adlandırdık, çünkü bu çift, varsayılan Mac diskinde tür denetimini bozuyordu.

Bizim başımıza ne geldi, ikinci kısım: yavaş kontrol. Daha önceki bir değişiklik ana kontrol işimizi yaklaşık 2 dakikadan yaklaşık 14 dakikaya çıkarmıştı. Bunu onaran pull request iki gerçek çalışmanın sonucunu veriyor: kontrol çalışmasının tamamı önce 14 dakika 36 saniye sürmüş, sonra 6 dakika 21 saniye. Hızlı çekirdek iş ise 872 saniyeden 111 saniyeye inmiş. Çözüm, yavaş tarayıcı çizim testlerini yanında paralel çalışan ayrı bir işe taşımaktı. Böylece hızlı kontroller hızlı dönüyor. Bunlar o pull request'in kendi rakamları ve her biri tek çalışmadan geliyor. Derleme adımını ekledikten sonra yeniden ölçmedik.

Biz nerede duruyoruz. O çalışma itibarıyla Fowler'ın on dakikasının altındayız. DORA'nın tek geçerli derleme fikrinden ise biraz uzağız, çünkü bizim katı derlememiz yayına giden şey değil, fazladan bir koruma. İkisini de, birleşik çalışmanın süresini ölçene kadar tutuyoruz.

Fikir nedir. Yalnızca metin taslağı yazabilen bir ajan pek zarar veremez. Para harcayabilen, paylaşım yayımlayabilen ya da veri silebilen bir ajan ise başka bir konu. Kapı, bir işlemi, biri onaylayana kadar durduran bir adımdır. Sorular şunlar: kapı nereye konur ve neyi kontrol eder?

Neden önemli. Kötü yazılmış bir cümle düzeltilebilir. Ücretli bir çağrı geri alınamaz, yayımlanmış bir paylaşım da çoktan görülmüştür. Güvenlik dünyası bunu artık adı konmuş bir risk olarak listeliyor. OWASP'ın dil modelli uygulamalar için hazırladığı listede "aşırı yetki" var. Nedenlerinden biri, yüksek etkili işlemleri bağımsız olarak doğrulayıp onaylamayan bir uygulama. Yanındaki madde olan sınırsız tüketim ise maliyet tarafını ele alıyor ve istek sınırları ile kullanıcı kotaları öneriyor.

Sade bir dille nasıl işler. İşlemleri geri alması ne kadar zor olduğuna göre sıralayın. Okumak bedava. Taslak yazmak geri alınabilir. Harcamak ve yayımlamak geri alınamaz. AWS'nin ajan sistemleri rehberi de aynı ayrımı yapıyor ve hoşumuza giden bir uyarı ekliyor: her işlemi incelemeye göndermek gözü kapalı onaylara yol açıyor, hiçbirini göndermemek ise sınırsız özerklik demek. Bu yüzden yalnızca kararın gerçekten önemli olduğu yerde durmak gerek. Rehber, sınıflandırmanın modelin kendi yargısına göre değil, düz kurallara göre yapılması gerektiğini de söylüyor, çünkü güvenilmeyen bir içerik modeli riskli bir işlemi risksiz saymaya ikna edebilir. Anthropic'in ajan rehberi ilgili bir freni anlatıyor: kontrolü elde tutmak için en fazla kaç tur dönülebileceği gibi durma koşulları eklemek yaygın.

Biz ne yaptık. Üç yere kapı koyduk. Birincisi, içerik motorumuz açılmadıkça kapalı ve kendi kotası var. İkincisi, paylaşım planlayıcımızı test eden bir betik eskiden onay sormadan yaklaşık yirmi ücretli çağrı yapıyordu. Şimdi önce bir tahmin yazdırıyor ve açık bir bayrak verilmedikçe çalışmayı reddediyor. Tahmin kaba: gerçek token değil, karakter sayısını üçe bölüyor. Pull request de bunun bir üst sınır olmadığını açıkça yazıyor. Yirmi istek için yaklaşık 0,07 dolar çıkıyor. Bu, kayda geçen ve 0,0707 dolara mal olan tek çalışmayla örtüşüyor. Bir de yaklaşık 1,34 dolarlık kaba bir tavan var. Üçüncüsü, sohbet arayüzümüzde para harcayan ya da yayımlayan her şey, sunucunun doğruladığı bir onay kartı istiyor. Konuşmada yazılan "evet" sayılmıyor, her karta bir kez yanıt veriliyor ve eski kartın süresi doluyor.

Biz nerede duruyoruz. Biçim rehberlerle uyumlu: geri alınabilirliğe göre kademeler, modelin dışında bir kontrol, bir tavan ve bir kota. Kapıyı gerçek müşteri kullanımında henüz görmedik. Bu yüzden dikkatli onaylar mı aldığımızı, yoksa gözü kapalı onaylar mı aldığımızı söyleyemiyoruz.