OpenAI’ın dahili mühendislik süreçlerine ait bir diyagram bu hafta X'te yarı-viral oldu. Diyagramda, "yazılım geliştiricisi sonucu tanımlar"dan başlayarak üretim grafiklerini izleyen ve kendi olay raporlarını oluşturan bir ajana kadar on kutucuk gösteriliyordu. Kaynak, Gergely Orosz'un The Pragmatic Engineer adlı bültenindeki “OpenAI’ın ajan temelli yazılım fabrikası” başlıklı bir yazıdan alınmıştır ve diyagramın kendisi X'te hızla yayıldı.
Tepkilerin çoğu önemli bir detayı atladı: o on kutucuktan birkaçı, bugün yükleyebileceğiniz Codex ürünü değil, OpenAI’ın dahili mühendislik kurulumunu tanımlıyor. İkisini karıştırmak, bu diyagram etrafındaki söylemde en yaygın hatadır. Bu makale kutucuk kutucuk ilerleyecek ve dış ekiplerin gerçekten kopyalayabileceği tek aşamada duracak: CI.
On aşama, sırasıyla
Diyagram soldan sağa doğru bir döngü olarak okunur: bir insan bir hedef belirler, bir ajan kod yazar, otomatik kapılar kodu kontrol eder ve ajan, bu kapılardan geçene kadar yinelemeye devam eder. İşte her aşama için dahili-karşı-piyasaya sürülen ayrımının işaretlendiği tam sıralama.
| # | Aşama | Ne olur | Yalnızca dahili mi yoksa Codex'te piyasaya sürüldü mü |
|---|---|---|---|
| 1 | Yazılım geliştiricisi | Bir mühendis veya PM sonucu tanımlar | İnsan adımı, yazılım değil |
| 2 | Codex kod yazar/düzenler | Kaynak, belgeler, GitHub, Slack, Notion, dahili beceriler ve Databricks ile Datadog gibi veri sistemlerinden bağlam çeker | Piyasaya sürülen Codex kod yazar; dahili bağlam grafiği (Slack, Notion, dahili veri) yalnızca dahili kullanım içindir |
| 3 | CI: derleme + test | Ajan ölçeğindeki yüke göre yeniden inşa edilen bir pipeline, artı bir “Perf Harness” | Piyasaya sürüldü (kendi CI'ınız); OpenAI'ın özel ölçeklendirme çalışması dahili kullanım içindir |
| 4 | Ajan temelli kod incelemesi | Veri, altyapı, bulut ve güvenlik uzmanı ajanlarından paralel inceleme, artı risk sınıflandırması | Yalnızca dahili |
| 5 | Düşük riskli karar | Düşük riskli değişiklikler ilerler; yüksek riskli değişiklikler ek bir insan mühendisi incelemesi alır | Yalnızca dahili |
| 6 | Ajan temelli dağıtım | Bir ajan, özellik bayrağı dağıtımı dahil olmak üzere değişikliği üretime “göz kulak olur” ve kendi panolarını oluşturur | Yalnızca dahili |
| 7 | Üretim izleme | Ajan, OpenAI'ın dahili gözlemlenebilirlik yığınındaki grafikleri, sinyalleri ve uyarıları izler | Yalnızca dahili |
| 8 | Kesinti algılandı -> Sevbot | Olayı araştırır, hafifletmeler önerir, soruları yanıtlar | Yalnızca dahili |
| 9 | Perf Fabrikası | Tekrarlayan uyarıları filtreler, gecikme regresyonlarını bulur, düzeltmeler önerir | Yalnızca dahili |
| 10 | Geri döngü | Ajan, CI ve incelemeler geçene kadar sorunları düzeltir, ardından geliştirici önerilen düzeltmeleri alır | Dahili döngüyü tanımlar |
Tam olarak bir aşama, CI adımı, artı 2. aşamanın bir kısmı, dışarıdaki bir ekibin "bizde de var" diyebileceği bir şeydir. Ajan temelli incelemeden Sevbot'a kadar her şey OpenAI'ın dahili yapısıdır.
Yalnızca dahili olan bu sütun aynı zamanda bir kaynak bulma sorunudur. OpenAI'ın güvenlik duvarının arkasında tuttuğu parçalar, orkestrasyon, inceleme kapısı, insan onayı, çoğu ekibin hiçbir şeyi olmayan tam da o katmandır. Sharkly, bunu inşa etmek için sağlayıcıdan bağımsız bir yerdir: bir geliştirici sonucu bir Görev olarak tanımlar, bir Ajana atar ve Ajan, sahip olduğunuz herhangi bir Çalışma Zamanını (Claude Code veya Codex) kullanarak bir Bilgisayarda çalışır. 'Yayımlanmaya Hazır' durumu, bir şeyin 'Tamamlandı'ya ulaşmadan önce bir insanın geçirmesi gereken bir durumdur, böylece onay işi hattın değil, kişinin işi olarak kalır. Sharkly, Codex'i değiştirmez veya kendi başına kod yazmaz; zaten ödediğiniz Çalışma Zamanını çalıştırır ve çevredeki döngüye yaşayacak bir yer sağlar.
Aşama 1-2: bir insan hala hedefi belirliyor, Codex hala kodu yazıyor
Bir yazılım geliştiricisi, yani bir mühendis veya ürün yöneticisi, istedikleri sonucu tanımlar. Codex daha sonra o hedefe ulaşana ve sonucun çalıştığını doğrulayana kadar bir dizi kod değişikliği yapar. Bu doğrulama döngüsü, Codex'in bugün piyasaya sürülen kısmıdır: masaüstü uygulaması (Mac için Şubat 2026, Windows için Mart), Temmuz 2026'dan itibaren ChatGPT Work entegrasyonu, rol tabanlı eklentiler ve beceriler ve uzun süreli çalışan görevler için /goal komutu. Bu komutun mekaniklerini öğrenmek isterseniz, otonom ajan çalıştırmaları için /goal komutunu ayrı olarak ele aldık.
Piyasaya sürülmeyen şey, Codex'i dahili olarak besleyen bağlam grafiğidir: Slack konularından Databricks panolarına kadar hemen hemen her OpenAI sistemi. Orosz'un makalesi bunu doğrudan belirtiyor: OpenAI'ın dahili Codex'i "harici muadilinden çok daha gelişmiş çünkü hemen hemen her OpenAI sistemine bağlı." Dahili ve harici Codex arasındaki bu fark, makalenin asıl tezidir.
Aşama 3: Döngünün gerçekten uygulandığı yer CI'dır
Bu, üzerinde yavaşlamaya değer bir aşamadır, çünkü tüm süreçteki tek kutucuktur ve sadece OpenAI değil, herhangi bir ekip buna zaten sahiptir. Makale, OpenAI'daki CI'ın yaklaşık altı ay içinde yükte yaklaşık 10 kat artış için yeniden inşa edildiğini belirtiyor, çünkü ajanlar artık boru hattından insanlardan çok daha fazla değişiklik geçiriyor. Bir “Performans Test Takımı” (Perf Harness), incelemeye ulaşmadan önce performans gerilemelerini yakalamak için bununla birlikte çalışır.
İşte gözden kaçan kısım: "CI ve incelemeler geçene kadar sorunları çözen" bir ajan, yalnızca CI'ın gerçekten neyi kontrol ettiği kadar güvenilirdir. Test paketiniz birim mantığını kapsıyor ancak API sözleşmesini kapsamıyorsa, bir ajan hala bozan bir değişikliği piyasaya süren yeşil bir yapıya döngü yapabilir. Durum kodları, şema şekli, yetkilendirme davranışı ve yük altında yanıt süresi bütçeleri, çoğu ekibin birim testlerine göre daha az yatırım yaptığı kontrol sınıfıdır. Burası Apidog'un uyduğu yerdir: CI adımınızda Apidog CLI aracılığıyla Apidog'un test senaryolarını çalıştırmak, bir ajana "kod derlendi"den daha zor bir kapı sağlar. Bunu Codex içindeki Apidog CLI makalemizde yazdık. Apidog'un bu süreçteki tek rolü budur. Ajan değildir ve dağıtım, inceleme veya olay yanıtıyla ilgilenmez.
Aşama 4-5: uzman inceleme ajanları ve risk kararı
CI geçtikten sonra, OpenAI'ın dahili kurulumu değişikliği veri, altyapı, bulut ve güvenlik uzmanı ajanlarından paralel incelemeye yönlendirir. Orosz bunu "her ilgili altyapı ekibinden bir insan alan uzmanının her değişikliği incelemesine eşdeğer" olarak tanımlıyor, ki bu çoğu insan ekibinin her çekme isteği için personel sağlayabileceğinden daha ağır bir inceleme eşiğidir. Codex'in piyasaya sürülen kod inceleme özelliği, bu dahili uzman ajanlardan farklı, daha hafif bir şeydir; kendi yığınınız için genel amaçlı bir ajan temelli inceleyicinin neler yapabileceğine karar veriyorsanız, yapay zeka kod inceleme araçları derlememiz iyi bir başlangıç noktasıdır ve OpenAI'ın ajan temelli inceleme ve risk kapısı tasarımı hakkındaki eşlik eden makalemiz bu kutucuğu daha derinlemesine inceler (kardeş, bağlantı vermeden önce canlı olduğunu onayla).
Risk sınıflandırması daha sonra ne olacağına karar verir. Kod tabanının düşük riskli alanları, bir ajanın kendi PR'larını otomatik olarak onaylamasına izin verebilir, bu tür değişiklikler için insan onayını tamamen devreden çıkarabilir. Daha yüksek riskli değişiklikler daha fazla yapay zeka inceleme geçişi, zorunlu bir insan incelemesi veya her ikisini birden alır. OpenAI, neyin düşük riskli sayılacağına dair kesin kuralı yayınlamadı ve biz burada bunu tahmin etmeyeceğiz. OpenAI'ın özel kurulumunun ötesine genelleşen bir fikir: herkese açık bir API sözleşmesindeki bozan bir değişiklik, fark ne kadar küçük görünürse görünsün, asla düşük riskli olarak sınıflandırılmamalıdır. OpenAPI tanımınızı ve testlerinizi aynı yerde tutan, spesifikasyon öncelikli araçlar, şema farkı bir satır sayısı farkından çok daha temiz bir risk sinyali olduğu için bu ayrımı otomatik olarak uygulamayı kolaylaştırır.
Aşama 6-8: ilk önce bir insan çağrılmadan dağıtım, izleme ve yanıt verme
Bir değişiklik incelemeden geçerse, dahili bir ajan, özellik bayrağı dağıtımı dahil olmak üzere onu üretime "göz kulak olur" ve o spesifik değişiklik için kendi izleme panolarını oluşturur. Canlıya geçtiğinde, aynı ajan (veya ilgili bir ajan) OpenAI'ın dahili gözlemlenebilirlik yığınındaki grafikleri ve uyarıları izler. Bir sorun çıktığında, Sevbot devreye girer: olayı araştırır, hafifletmeler önerir ve Slack'te geliştirici sorularını yanıtlar. Sevbot'un ne yapmadığı konusunda kesin olmakta fayda var. Önerir; uygulamaz. Bir insan hala hafifletmeyi yetkilendirir ve hala nöbetçi konumdadır. Makalede açıkça belirtildiği gibi, "nöbet görevi geçmişte kalmış bir şey değildir." Satın alabileceğiniz Codex ürününde 6'dan 8'e kadar olan aşamaların hiçbiri mevcut değildir.
Aşama 9-10: performans gerilemeleri ve geri döngü
Perf Fabrikası, olay yolunun yanında yer alır. Uyarıları ve panoları eler, yinelenen sinyalleri filtreler, gerçek gecikme regresyonlarını kökünden bulur ve düzeltmeler önerir, bu düzeltmeler daha sonra orijinal geliştiriciye geri döner. Sevbot ile birlikte, bu OpenAI'ın uyarı yorgunluğuna cevabıdır: her pingi önceliklendiren bir nöbetçi mühendis yerine, bir ajan önce ön filtreleme ve ön teşhis yapar. Döngü 10. aşama ile kapanır: ajan, CI ve her inceleme katmanı geçene kadar revizyonlara devam eder.
Dahili/harici ayrımının ekibiniz için neden önemli olduğu
Ekibinizin bu çeyrekte "OpenAI tarzı" ajan temelli mühendisliği benimseyip benimseyemeyeceğini değerlendiriyorsanız, dürüst cevap şudur: 1'den 3'e kadar olan aşamaları bugün benimseyebilirsiniz ve 4'ten 9'a kadar olan aşamalar satın alınabilir bir özellik değil, bir yönü tanımlar. Bu, OpenAI'ya bir eleştiri değildir; bu ölçekteki dahili araçların geliştirilmesi yıllar sürer. Orchflows adlı açık kaynaklı bir proje, bu döngüyü Claude Code ve Codex için bir /software-factory komutuyla yaklaştırmaya yönelik halka açık bir girişimdir; README'si amacını açıkça belirtir ve bir kütüphane yerine sadece iki beceriye ihtiyacınız olduğunu savunur. Bu, erken aşamada olan, OpenAI ile bağlantısı olmayan bir projedir, bu yüzden onu yerleştirilebilir bir fabrika yerine bir referans uygulaması olarak değerlendirin.
OpenAI'ın kendi içinde benimseme, özel dahili tesisat gerektirmeyen kısımlarda hızla ilerlemiştir: mühendislik dışı ekiplerde Codex kullanımı dört ayda, Şubat'tan Mayıs 2026'ya kadar yaklaşık %0'dan %90'a çıkmıştır. Bu, yalnızca süreç diyagramından daha keskin bir sinyaldir, çünkü kolay kısmın (belirtilen bir hedefe yönelik kod yazan bir ajan) OpenAI'da zaten normal olduğunu, zor kısmın ise (ajan temelli dağıtım, inceleme ve her dahili sisteme entegre edilmiş olay yanıtı) hala özel olarak geliştirildiğini gösterir.
İnsan kalanlar
Makale, nelerin değişmediği konusunda dikkatli. Geliştiriciler hala sonuçları tanımlar. İnsanlar hala yüksek riskli değişiklikleri onaylar ve olay hafifletmelerini yetkilendirir. Sevbot'un yaptıklarını hala biri sonradan inceler ve nöbet rotasyonları hala mevcuttur. Makalenin sonunda yer alan cümle, değişimi herhangi bir istatistikten daha iyi yakalar: “Muhakeme, önceliklendirme ve beğeni daha önemli hale geliyor.” İki uyarı da bunu sağlam tutar: mobil uygulama mağazası incelemesi, hiçbir ajanın atlatamayacağı manuel bir darboğaz olmaya devam ediyor ve altyapı ölçeklendirmesi çözülmüş bir sorun değil, aylık bir mücadele.
Bir satıcının 4'ten 9'a kadar olan aşamaları piyasaya sürmesini beklemek yerine, 1'den 3'e kadar olan aşamaların kendi versiyonunuzu inşa ediyorsanız, sürecinizde zaten var olan kapıyla başlayın: CI. Codex etrafında daha hafif bir yazılım fabrikası inşa etme konusundaki eşlik eden makalemiz bu yapıyı anlatır (kardeş, bağlantı vermeden önce canlı olduğunu onayla) ve Sevbot/Perf Fabrikası tasarımı, OpenAI'ın performans fabrikası ve Sevbot hakkındaki yazımızda (kardeş, bağlantı vermeden önce canlı olduğunu onayla) kendi başına ele alınır. Testler geçene kadar döngüye giren bir ajan, yalnızca karşı test ettiği testler gerçekten bir şeyleri doğruluyorsa iyi bir fikirdir. Apidog, API sözleşme testlerini spesifikasyonun yanında tutar, böylece bu kapı, sadece insanlar değil, ajanlar da değişiklikleri zorlamaya başladığında dürüst kalır.