AIREITERTersine mühendislik sürecinin ilk yarısında kodu mekanik olarak ayırır, algoritma ailesini tespit eder ve diferansiyel testlerle doğrularsınız. Sonunda vardığınız nokta şudur: “Bu kodun ne hesapladığını anlıyorum.” Ancak bu bilgi tek başına üretime çıkmaz. Mantık hâlâ özgün çalışma zamanına bağlıdır; onu CI içinde çalışacak saf bir fonksiyona mı, yoksa sürekli bakım gerektiren harici bir sürece mi dönüştüreceğinize karar vermeniz gerekir. Burada yapılan yanlış seçim, başlangıçta kazandığınız zamanı operasyon tarafında faiziyle geri ödettirir.
Dört aşamalı genel bakış bu adımı tek cümlede özetliyordu: “4. aşamada taşıma katmanına göre kademeli olarak geri düş.” Bu yazıda o kısmı açıyoruz. Ana fikir net: Her alt katmana iniş, bağımlılık yüzeyini, hata türlerini ve dağıtım maliyetini bir büyüklük mertebesi artırır. Bu yüzden varsayılan yaklaşım, mümkün olduğunca üst katmana çıkmak için mücadele etmektir.
Üretime taşımanın üç yolu
Mantığı üretime almanın yukarıdan aşağıya yalnızca üç biçimi vardır. Bu sıralama, “hangisi önce çalıştıysa onu kullanalım” diye anlık karar verilecek bir konu değil; ekip standartlarında açıkça yer almalıdır:
Native rewrite. Mantığı hedef dilinizde, özgün çalışma zamanından tamamen kopuk ve yalnızca standart kütüphaneye bağlı şekilde yeniden yazarsınız. Bunun ön koşulu, algoritma ailesinin doğru belirlenmiş olmasıdır. Fingerprinting aşaması geçildiğinde kodun %90’ı kamuya açık uygulamadan gelir; kalan sapma noktaları ayrı ele alınır ve sonuç saf bir fonksiyon olarak teslim edilir.
Minimal parçayı çalıştıran yerel JS motoru. Bazı mantıkları kısa vadede tamamen arındırmak pahalı olabilir. Bu durumda özgün JS’in küçük bir bölümünü korur, tüm sayfayı değil yalnızca gerekli birkaç düzine satırı yerel Node/V8 üzerinde çalıştırırsınız.
Pasif browser bridge. Bazı durumlarda gerekli durum bilgisi sadece gerçek, oturum açılmış bir sayfanın çalışma zamanında bulunur. Örneğin çalışma zamanında üretilen bir imza veya oturuma bağlı dinamik bir tanımlayıcı, statik yeniden kurulumla üretilemeyebilir; şimdilik yalnızca tarayıcı içinden okunabilir. Bu geçici bir çözümdür: arayüz notlarında açıkça işaretlenmeli ve asla varsayılan yöntem olarak yaygınlaştırılmamalıdır.
Katmanlar arasındaki maliyet farkı
Sıralamanın sabit olmasının sebebi maliyetlerin doğrusal artmamasıdır. Her katman, bir öncekine göre yaklaşık bir büyüklük mertebesi daha pahalıdır.
Katman | Bağımlılık yüzeyi | Hata türü | CI’da çalışır mı? |
|---|---|---|---|
Native rewrite | Standart kütüphane, sıfır harici süreç | Çıktı uyuşmazlığı; tek bir | Evet — saf fonksiyondur |
Yerel JS motoru | Ek bir Node çalışma zamanı; V8 context thread-safe değildir, eşzamanlılık için kilit gerekir | Motor sürümü veya parçanın ihtiyaç duyduğu global değişkenin eksik olması | Zor da olsa — motoru kurmanız gerekir |
Pasif browser bridge | Gerçek bir Chrome + eklenti + insan tarafından sürdürülen oturum + yerel loopback kanalı | Sayfa açık değil, oturum sona ermiş, yapı değişmiş veya sekme kapatılmış | Hayır — canlı bir kullanıcı gerekir |
İlk katmandaki hata birim testinde yakalanır; üçüncü katmandaki hata ise “kullanıcı bugün o sekmeyi kapattı”dır. Saf fonksiyon olabilecek bir şeyi üçüncü katmana taşımak, her çağrıyı bir insana bağlar. Referans olarak: Algoritma ailesi tespit edildikten sonra, obfuscate edilmiş bir imza SDK’sı yalnızca yerleşik crypto bağımlılığıyla 600 satırın altında bağımsız bir uygulamaya dönüşebilir ve ilk katmanda çalışabilir. Browser bridge üzerinden gitmesi gerektiğini düşündüğünüz şey, çoğu zaman henüz tam olarak tanımlamadığınız bir algoritmadır.
Pasif bridge için sınır: tek snapshot, asla aktif davranış yok
Pasif bridge’in kontrolden çıkmasının tek yolu vardır: “yardım etmeye” başlaması. Otomatik yenileme, otomatik giriş, sayfanın yüklenmesini otomatik bekleme gibi her “otomatik” davranış, onu ileticiden crawler’a biraz daha yaklaştırır. Bu nedenle sınır son derece dar çizilmelidir. Aşağıdaki kurallar zor yoldan öğrenildi:
Tek seferlik snapshot alın; sayfayı hiçbir şekilde değiştirmeyin. Halihazırda açık olan bir sayfanın cookie’lerini, oturum durumunu ve çalışma zamanını ayrı ayrı yalnızca bir kez sorgulayın. Yeni sekme açmayın, yenilemeyin, gezinmeyin, odağı değiştirmeyin, polling ile beklemeyin. Sayfa yoksa yoktur; kullanıcı adına sayfayı açmayın.
Eksik olan her şey için anında açık hata dönün. Eşleşen sekme yoksa tab_unavailable; sayfa açık ama oturum kapalıysa not_logged_in; oturum açık ancak runtime hazır değilse runtime_unavailable dönmelidir. Bu üç hata kodunun her biri tek bir gerçek duruma ve tek bir sonraki adıma karşılık gelir: sayfayı beklemek, giriş yapmak veya hedef değiştirmek. Çağıranın tahmin etmeye çalışacağı tek bir “başarısız oldu” hatası vermeyin.
Hassas durum bilgisi tarayıcıdan çıkmamalı. Eklenti cookies / webRequest izni istemez. Sadece açık olan ve eşleşen sekmeyi sorgular, isteği bu sayfanın context’i içinde tamamlar ve yanıtı döndürmeden önce alanları temizler. Cookie’ler ve sayfa imza durumu tek bir aşamada bile Chrome dışına çıkmaz; kanal varsayılan olarak yerel loopback adresine bağlanır. Bridge kimlik bilgilerini değil, sonuçları taşır.
Neden birkaç platform için 15 ayrı scope gerekiyor?
Pasif bridge’in ilettiği şey whitelist’e alınmış isteklerdir; path, parametreler ve referer, adapter tarafından sınırlandırılır. Buradaki en ters köşe nokta scope granülerliğidir: Toplam 15 scope yalnızca birkaç platformu kapsar, çünkü scope’lar “platforma” göre değil, “sayfa context’ine” göre ayrılır. Aynı TikTok içinde Creative Center, Top Ads, Creator platformu, influencer kütüphanesi ve Ads Manager birbirinden bağımsız beş scope’tur. Bunların beşi de ayrı oturum durumlarına ve ayrı sayfa runtime’larına sahiptir; reklam yönetim paneline giriş yapmış olmak, Creator platformunun runtime’ına erişim sağlamaz. Platform başına tek dilim keserseniz, “A alt sitesinde giriş var ama B alt sitesine hizmet veremiyor” hatasında yeniden başa dönersiniz. Xiaohongshu’nun ana sitesi, uygulama eşdeğeri path’leri ve creator marketplace’i de benzer şekilde üç ayrı scope oluşturur.
Zamanlama granülerliği de buna göre belirlenir: kilit yalnızca platform ailesi düzeyinde uygulanır. Aynı ailedeki istekler, örneğin Douyin ailesindekiler, aynı gerçek sekmeyi kullandıkları için seri çalışır. Tek bir sayfa context’ine eşzamanlı istek göndermek, isteklerin birbirini ezmesine yol açar. Farklı aileler, örneğin Douyin ve Xiaohongshu ise bağımsız iki sekme olduğundan paralel çalışabilir. Aile içinde ayrıca minimum istek aralığı koyun. Kilidi fazla geniş tutarsanız paralel yapılabilecek işleri gereksiz yere serileştirirsiniz; fazla dar tutarsanız aynı sekmeyi paylaşan istekler çakışır. Platform ailesi, “aynı sayfa runtime’ını paylaşma” durumunun doğal sınırıdır.
Giriş gerektiğinde tek izin verilen insan müdahalesi
Pasif bridge sayfayı işletmez, ancak oturumların süresi dolar. Çözüm, insan müdahalesini açık ve tek seferlik bir adıma indirmektir: Etkileşimli bir komut handoff sürecini başlatır; program işletim sistemi aracılığıyla ilgili iş sayfasını açar, sizin elle giriş yapmanızı ve sayfanın hazır olmasını bekler, ardından özgün isteği yeniden oynatır. Eklenti bu süreçte hiçbir düğmeye tıklamaz, form doldurmaz, cookie dışa aktarması yapmaz. Girişi gerçek tarayıcıda siz yaparsınız; program işiniz bittiğinde yalnızca isteği kaldığı yerden sürdürür.
Buradaki kritik kural şudur: Bu süreç örtük biçimde asla tetiklenmemelidir. Etkileşimsiz bir komut, örneğin CI veya zamanlanmış görev, tarayıcı açmaz. Temiz şekilde oturum hatası döner ve kararı üst katmana bırakır. Handoff mekanizması yanlış pozitiflere karşı da koruma sağlamalıdır: Başarılı girişten sonra runtime için en fazla kısa bir ek bekleme süresi tanınır; uygulamada bu süre 20 saniyedir. Ardından mutlaka bir sonuç elde edilmelidir. İş sayfası hedef arayüz context’ini taşımayan bir hesap sayfasına yönlendirilmişse, “hâlâ yükleniyor” sanıp boşuna beklemek yerine mevcut aşamayı hemen sonlandırın. Degradasyona izin veren bir akış, tüm süreci başarısız kılmak yerine bu aşamayı unavailable olarak kaydeder ve devam eder.
Aşama durumları: tamamlandı, bilinçli olarak atlandı, oturum gerekiyor
Yukarıdaki her şeyin ortak zemini şudur: Hiçbir aşama yalnızca “başarılı” veya “başarısız” sonucu döndürmemelidir. Bir orkestrasyon pipeline’ında her aşamanın sonucu altı biçimden birini alır: completed (tamamlandı), empty (çalıştı ancak veri yok), ready (hazırlandı, gönderim bekliyor), skipped (kural gereği bilinçli olarak atlandı), unavailable (şu anda kullanılamıyor; çoğunlukla oturum gerektiği anlamına gelir), blocked (bir ön koşul karşılanmıyor).
“Bilinçli olarak atlandı”, “oturum gerekiyor” ve “gerçekten boş” birbirinden tamamen farklı sinyallerdir. Tek ve opak bir sonuç döndürürseniz boşluğun “boş olması gerekiyordu” anlamına mı geldiğini, yoksa “oturum öldü ve kimse fark etmedi” anlamına mı geldiğini ayırt edemezsiniz. Bu durumda pipeline işletilemez. Aşama durumunu sonlu bir enum olarak modellediğinizde orkestrasyon katmanı — bir script ya da model — degradasyon, yeniden kimlik doğrulama veya iptal kararını bu veriye göre verebilir. Bu, pasif bridge’in üç hata kodu ilkesinin akış seviyesine taşınmış hâlidir.
Bir yeteneğin hangi katmana yerleşeceğine modelle karar vermek
Modelin devreye girdiği yer yalnızca burasıdır ve rolü sınırlıdır: Arındırma işini sizin yerinize yapmaz; neyin ne kadar arındırılabileceğine karar vermenize yardım eder. Bu bir imza kırma görevi değil, mimari değerlendirmedir. Temel soru şudur: Bağımlı olduğu durum statik olarak yeniden kurulabilir mi, yoksa yalnızca runtime’da mı erişilebilir? Sonrasında arındırma maliyetini, bu mantığın ne sıklıkla değiştiğiyle karşılaştırırsınız. Farklı adımlarda modelden farklı yetenekler beklersiniz:
Adım | Gerekli yetenek | Tercih | model id |
|---|---|---|---|
Bağımlılık yüzeyini görmek için tüm modülü okumak | Uzun context, çağrı grafiğini tek seferde okuyabilme | Kimi K3 |
|
Katmanı iki yönden tartışmak, “önce çalışsın yeter” yaklaşımına itiraz etmek | Güçlü muhakeme; arındırmaya ek bir gün ayırmanın gerekçesini kurabilme | Claude Opus 5 |
|
Onlarca ila yüzlerce yetenek için toplu ilk geçiş sınıflandırması | Düşük maliyet, yüksek eşzamanlılık | Claude Sonnet 5 |
|
Degradasyon sonrasında neden analizi | Orta seviye muhakeme; hata loguna dayanarak açıklama yapabilme | GPT-5.6 Sol |
|
En kritik olan ikinci satırdır. Katman seçerken en kolay yapılan hata, modele “önce çalışsın yeter” tonuyla yaklaşıp ondan “browser bridge en kolayı” cevabını almaktır. Model bu noktada uzun vadeli maliyet hesabı yapmıyor, sizi yansıtıyordur. Güçlü muhakeme katmanı ise karşı çıkar: “Bu parça standart bir hash ve tek bir sabit sapmadan oluşuyor; bir gün ayırıp saf fonksiyon olarak taşımaya değer, bridge’e koyulmamalı.” Sözüme güvenmeyin, kendiniz deneyin: Üç mantık parçası seçin; kontrol için, en az birinin doğru yerleşimini zaten biliyor olun. Aynı “yerleşim öner + gerekçelendir + bridge’e erken gitmeye itiraz et” istemini claude-opus-5 ve gpt-5.6-sol modellerine verin. Tek bir şeye bakın: Sizi bir üst katmana taşımak için itiraz ediyor mu, yoksa tembelce üçüncü katmanı mı varsayıyor?
Asıl sorun model değiştirme maliyeti
Üç farklı sağlayıcıdan dört katman demek; üç SDK, üç kimlik doğrulama şeması ve üç hata formatı demektir. Adımlar arasında model değiştirmek için istemcinizi yeniden yazmak çoğu zaman değmez. Bu nedenle insanlar genellikle her işte tek model kullanır; en çok muhakeme gerektiren yerleşim değerlendirmesinde ise yalnızca kendilerini yansıtan bir modelle kalırlar.
AIReiter bu katmanı sadeleştirir: Tek anahtar, OpenAI uyumlu tek arayüz ve arkasında dört katmanın tamamı. Model değiştirmek, istek gövdesindeki model alanını değiştirmekten ibarettir.
# Yerleşim tartışması: muhakeme katmanı
curl https://aireiter.com/api/v1/chat/completions \
-H "Authorization: Bearer $AIREITER_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "claude-opus-5",
"messages": [{"role": "user", "content": "<yerleşim istemi + tersine çıkarılan mantık parçası + bağımlılık listesi>"}]
}'
# Toplu ilk geçiş sınıflandırması: tek alanı değiştirin
# "model": "claude-sonnet-5"
# Degradasyon neden analizi:
# "model": "gpt-5.6-sol"
Halihazırda OpenAI SDK kullanıyorsanız base_url değerini https://aireiter.com/api/v1 olarak ayarlayın. Anthropic SDK kullanıyorsanız aynı anahtarla POST /api/v1/messages çağrısını yapın. Fiyat tarafında Claude modelleri liste fiyatına göre %30 indirimli, GPT modelleri ise yarı fiyatına çalışır. Bu iş akışının maliyeti iki noktada yoğunlaşır: Onlarca ila yüzlerce yeteneğin toplu ilk geçiş sınıflandırması — Sonnet, yüksek çağrı hacmi — ve tüm modülü okuyarak bağımlılık yüzeyini çıkaran uzun context’li tekil giriş — Kimi, çağrı başına çok token. Toplu sınıflandırma Claude modeliyle yapıldığı için indirim en yoğun adıma doğrudan yansır; muhakeme katmanındaki yerleşim tartışması da %30 indirimli bir Claude modelidir. Kimi K3’ün uzun context katmanı da aynı anahtarla kullanılabilir.
Kayıt olmadan deneyin — Önce birkaç mantık parçasını elle girin; iki modelin sizi tekrar edip etmediğini veya “bu browser bridge’e mi gitmeli?” sorusunda size karşı çıkıp çıkmadığını görün.
Sonuç
Tersine mühendislikle çıkarılan mantığı üretime almak teknik bir problemden çok maliyet problemidir. Üç katmanlı sıralama — native rewrite > yerel JS motoru > pasif browser bridge — tersine çevrilemez. Çünkü her aşağı iniş, saf bir fonksiyonun yerini harici bağımlılıkları, insan müdahalesi ve canlı bir sekmesi olan bir sürece bırakır. Pasif bridge yasak bir alan değildir; fakat sınırları sıkı çizilmiş geçici bir bileşendir: Tek snapshot alır, asla aktif davranmaz, sayfa yoksa anında açık hata döner, hassas durum bilgisini tarayıcı dışına çıkarmaz, giriş yalnızca açık handoff ile yapılır ve aşama durumu her zaman okunabilir kalır. Bu kuralları korursanız güvenilir bir ara çözüm elde edersiniz; içlerinden birini bile bırakırsanız kimsenin bakımına cesaret edemediği bir kara kutuya dönüşür. Model, yeteneğin hangi katmana yerleşeceğini değerlendirmenize ve “önce çalışsın yeter” ataletiyle mücadele etmenize yardımcı olur. Ancak her yeniden yazımın doğruluğuna karar veren şey model değil, diferansiyel testtir.