Lore Hafta 3: Bir uygulamayı yeni bir model sağlayıcısına taşımak, kullanım sınırının yeri ve bir platform tarihinin koda etkisi

Lab, haftalık yazı. 26 Ekim Pazartesi ile 1 Kasım Pazar arası, 2026, İstanbul saatiyle.

Bu hafta 66 pull request merge ettik. Geçen hafta bu sayı 43'tü. Tipik bir pull request, açıldıktan yaklaşık 2 saat sonra merge edildi (ortanca 122,6 dakika). Henüz duyurmadığımız yeni bir ürün 23 merge aldı. Onu sınav hazırlık uygulamamız Lexicon (15), AutoReal (13), guno (3) ve lorelabs.co (1) izledi. Kalan 11 merge iç araçlarımıza gitti.

Haftanın en faydalı dersi Lexicon'dan geldi. Lexicon birkaç gün içinde bütün yapay zeka model çağrılarını tek bir modülün arkasında yeni bir sağlayıcıya taşıdı ve sunucunun saydığı günlük bir sınır ekledi. Ayrıca bir platform tarihinin iki uygulamamızın koduna nasıl uzandığını gördük ve kırmızı bir çarpıyı saymadan önce okumayı öğrendik.

Bu hafta üç yeni fikri ve kısa bir notu anlatmak istiyoruz:

1. Bir uygulamayı yeni bir model sağlayıcısına adım adım taşımak. Her çağrıyı tek bir modül üstleniyor ve eski yol en son kalkıyor.

2. Kullanım sınırı nerede durmalı. Sınır sunucuda durmalı, model çağrılmadan önce işlemeli ve sayamadığında kapalı kalmalı.

3. Bir platform tarihi kodu şekillendirir. İki iPhone uygulamamızın build yöntemini gelecek yılın iOS kuralı yüzünden neden değiştirdiğini anlatıyoruz.

4. Kısa not: Kırmızı çarpı her zaman başarısız bir test anlamına gelmez.

Bize yeni katıldıysanız şunu bilmenizi isteriz: CI, kontrol dakikaları ve bir kontrolün bütçe yüzünden neden durabileceği Lore Hafta 2'nin konusuydu. Branch'ler, küçük değişiklikler ve onay gate'leri de Lore Hafta 1'de anlatıldı. Bunları burada tekrar etmiyoruz.

Fikir nedir. Lexicon, TOEFL, IELTS ve GMAT'in sözel bölümlerine hazırlanmanıza yardım eden bir uygulamadır. Uygulamanın arkasında bir sunucu fonksiyonu, bir yapay zeka modelinden alıştırma kelimeleri, paragraflar ve quiz'ler yazmasını ister. Bu hafta bu çağrıları bir model sağlayıcısından diğerine taşıdık.

Neden önemli. Sağlayıcı değiştirmek bir adresi başka bir adresle değiştirmekten ibaret değildir. Her sağlayıcının kendi istek biçimi, kendi limitleri, kendi reddetme şekli ve kendi fiyatı vardır. Model çağrıları birçok dosyaya dağılmışsa taşıma hepsine aynı anda dokunur ve bir hata bütün kullanıcılara aynı anda ulaşır.

Basitçe nasıl işler. Tek bir ana kapısı olan bir bina düşünün. Her teslimat o kapıdan geliyorsa kilidi bir kez değiştirirsiniz. Yazılımda bunun için iki bilinen kalıp var. Microsoft'un mimari rehberinin "anti-corruption layer" dediği adaptör katmanı, uygulamanızla dış bir sistem arasına girer ve ikisi arasında çeviri yapar. Böylece dış sistemin alışkanlıkları sizin tasarımınıza sızmaz. Martin Fowler'ın anlattığı "strangler fig" ise eski bir sistemi yavaş yavaş değiştirir: Yeni yol eskisinin yanında büyür, trafik adım adım taşınır ve eski yol en son kaldırılır. Böylece hem yatırım hem de getiri yavaş yavaş ve görünür biçimde gelir.

Bize ne oldu. İşi adımlara böldük. Önce yazılı bir plan hazırladık. Ardından sunucuda her model çağrısını üstlenen tek bir modül kurduk: Her route bu modülden geçiyor ve yeni sağlayıcıyla yalnızca o konuşuyor. Uygulamanın dışındaki küçük script'ler eski sağlayıcıyı kullanıyor ve aynı planın sonraki bir adımında bilerek taşınacak. Modül neyin cevap sayılacağına da karar veriyor. Bir ret, token limitinde kesilen bir cevap ya da boş bir cevap, boş bir kart olarak değil adı konmuş bir hata olarak dönüyor. Modülün testleri sahte bir istemciyle çalışıyor, böylece ücretli bir çağrı yapmadan istek biçimini ve her hata durumunu kontrol ediyor.

Başkaları ne diyor. Fowler yavaş yolu savunuyor, çünkü bu yolda hem yatırım hem de getiri her adımda görünür kalıyor. Microsoft'un rehberi bedeli de açıkça yazıyor: Katman her çağrıya gecikme ekliyor ve yönetip bakımını yapmanız gereken bir parça daha oluyor.

Biz nerede duruyoruz. Her çağrının tek bir sahibi olması, değişikliği iki pull request'te incelenebilecek kadar küçülttü. Bedeli şu: Script'ler iki sağlayıcı arasında bölünmüş durumda. Yeni sağlayıcının cevaplarının kalitesini aynı prompt'larla eskisiyle henüz karşılaştırmadık. Sıradaki adım bu karşılaştırma olacak.

Fikir nedir. Kullanım sınırı, bir hesabın yapabileceği model çağrısı sayısını kısıtlar. Ücretli model çağrılarının neden bir tavana ihtiyaç duyduğunu 1. haftada anlattık. Bu hafta o tavanın nerede durması gerektiğini konuşuyoruz.

Neden önemli. Telefondaki bir uygulama değiştirilebilir, kopyalanabilir ya da taklit edilebilir. Yalnızca uygulamanın kontrol ettiği bir sınır, bir ricadan öteye geçmez. OWASP'ın Authorization Cheat Sheet'i bunu açıkça söylüyor: Geliştiriciler istemci tarafındaki erişim kontrollerine asla güvenmemeli ve bu kontroller sunucuda yapılmalı. Aynı belge varsayılan olarak reddetmeyi de öneriyor: Emin değilseniz reddedin.

Basitçe nasıl işler. Bir istasyondaki turnike, yolcunun sözüne değil kendi sayacına güvenir. Turnikenin sayacı bozulursa güvenli turnike herkesi geçirmez, kapalı kalır. Mühendisler buna "fail closed" der.

Bize ne oldu. Lexicon'da artık hesap başına günlük 60 model çağrısı sınırı var ve bu sınırı, çağrıları üstlenen aynı modül sunucuda sayıyor. Sınırı aşan bir çağrı, hiçbir model çağrılmadan önce kullanıcıya açık bir mesajla reddediliyor. Örneğin veritabanı cevap vermediği için sistem çağrıyı sayamıyorsa çağrı yine reddediliyor ve farklı bir hata dönüyor. Kullanıcılar kendi sayaçlarını okuyabiliyor ama değiştiremiyor. Testler gün sınırını, sınırdaki reddi ve aynı anda gönderilen bir çağrı yığınını kapsıyor. Saf bir sayaç fazladan çağrıları tam da böyle bir yığında kaçırır. Yerel testlerde kullanılan ücretsiz sahte model bile sınırdan düşüyor, böylece sınır çalıştığı şekilde test ediliyor.

Başkaları ne diyor. OWASP'ın LLM uygulamaları için hazırladığı risk listesi maliyet tarafına "unbounded consumption" diyor ve bu konuyu 1. haftada anlattık. Cheat sheet buna yer kuralını ekliyor: Bir saldırganın içeri girmesi için atlanmış tek bir kontrol yeterli.

Biz nerede duruyoruz. Sınırın yeri rehbere uyuyor. Sayının kendisi ise henüz veriye dayanmıyor: Günde 60'ı biz seçtik ve gerçek kullanıcıların bu sınıra takılıp takılmadığını henüz ölçmedik.

Fikir nedir. Apple, iPhone uygulamalarının build'ini her yıl değişen bir yazılım kitiyle, yani SDK ile alır. Scene tabanlı yaşam döngüsü, bir uygulamanın ekranlarını başlatmanın ve yönetmenin daha yeni bir yoludur. Apple'ın belgelerine göre iOS 27'den itibaren en yeni SDK ile build alınan uygulamalar bu yaşam döngüsünü benimsemek zorunda, aksi halde açılmıyorlar.

Neden önemli. Kural, kodunuzu değiştirmenizi beklemiyor. Onu tetikleyen şey build aldığınız araç oluyor. Sessizce en yeni araçlara geçen bir build makinesi, çalışan bir uygulamayı açılışta kapanan bir uygulamaya çevirebilir.

Basitçe nasıl işler. Yapı yönetmeliğini belli bir tarihte değiştiren bir şehir düşünün. Ayakta duran evler sorun yaşamaz. Yeni yönetmelikle inşa edilen bir evde ise yeni yangın çıkışı olmak zorundadır, yoksa ev açılamaz. Ya çıkışı inşa edersiniz ya da onu inşa edene kadar eski onaylı planları kullanmaya devam edersiniz.

Bize ne oldu. İki iPhone uygulamamız iki farklı yolu seçti. guno, build makinesinin imajını Xcode'un bir önceki sürümüne sabitledi. Durum dosyası nedenini açıklıyor: En yeni imaj iOS 27 SDK'siyle build alacaktı ve scene yaşam döngüsü olmadan uygulama açılışta kapatılacaktı. Lexicon ise öbür yolu seçti, uygulama framework'ünü birkaç sürüm birden yükseltti ve uygulaması artık yeni kuralın istediği parça olan bir scene delegate taşıyor.

Başkaları ne diyor. Apple'ın TN3187 teknik notu geçişin nasıl yapılacağını anlatıyor ve bu tarihin erkenden duyurulduğunu gösteriyor: UIKit, iOS 18.4'ten beri bu konuda bir uyarı yazıyor.

Biz nerede duruyoruz. Sabitlemek şimdilik hızlı ve güvenli, ama üzerinde tarih yazan bir borç. guno'nun durum dosyası çıkış koşulunu da yazıyor: Yeni araçlara yalnızca scene desteğiyle geçilecek. Bu geçiş olduğunda size haber vereceğiz.

Bu hafta 466 kontrol çalışmasının 191'i başarısız oldu. Bu oran yüzde 41 gibi görünüyor. Ama bu 191 hatanın 181'i tek bir adım bile çalıştırmadan, 30 saniyeden kısa sürede bitti: Bunları kodumuz kırmadı, faturalama engeli sırasında reddedildiler. Kırmızı bir çarpıyı saymadan önce ne kadar sürdüğüne ve kaç adım attığına bakın. Bundan sonra retleri ve gerçek hataları ayrı rakamlar olarak raporluyoruz.

Tek bir kapıyı korumak daha kolaydır. Her model çağrısını tek bir modüle taşımak, hem sağlayıcı değişikliğini hem de sınırı küçük ve incelenebilir bir değişikliğe çevirdi.

Bir sınır ancak kullanıcının uzanamadığı yerde gerçektir. Sınırı sunucu sayıyor ve sayamadığında kapalı kalıyor.

Build araçlarınız, kodu değiştirmeden uygulamanızı bozabilir. Sabitlenen bir build imajı zaman kazandırdı, framework yükseltmesi de borcu ödedi.

Gün bitince sayın. 2. hafta sayımımız çok erken saydığımız için 5 merge'ü kaçırdı.

Bu hafta küçük değişiklikler daha uzun bekledi. En yavaş iki pull request yalnızca 2'şer dosyayı değiştirdi ve 16,0 ile 6,4 gün sürdü. Geçen hafta en yavaşlar en büyükler olmuştu.

Durum dosyaları karakterde büyümeye devam ediyor. Üst üste üçüncü hafta, bir ürünün durum dosyası satır sayısını korurken karakterde yüzde 14 büyüdü. Lexicon'unki yüzde 85 büyüdü.

Bizi ne şaşırttı. Henüz duyurmadığımız yeni ürün, 370 dosyada yaklaşık 33.000 satır ekleyen tek bir pull request aldı. Bu değişikliği bir agent rol ekibi tek seferde kurdu. Bu büyüklükte bir değişikliği iyi incelemenin yolunu henüz bilmiyoruz.