Codex, CI ve Apidog API Testleri ile Kendi Yazılım Fabrikanızı Nasıl Kurarsınız

Gergely Orosz'un OpenAI'ın dahili yazılım fabrikasına ilişkin diyagramı bu hafta gündemdeydi: bir geliştirici bir sonuç bildiriyor, Codex kodu yazıyor, bir uzman inceleme aracıları filosu risk hakkında tartışıyor ve bir ajan, kendi inşa ettiği kontrol panellerini izlerken dağıtımı takip ediyor. Bu aynı zamanda, OpenAI'ın kendi mühendisleri için en önemli olan kısımlarda, yükleyemeyeceğiniz dahili bir araç setinin açıklamasıdır.

Perf Factory, Sevbot ve kendi kendini inşa eden kontrol panelleriyle ajan bazlı dağıtım, OpenAI'ın kendi gözlemlenebilirlik yığınında çalışır ve satın alabileceğiniz Codex ürününün bir parçası değildir. Bu hafta inşa edebileceğiniz şey, hala gerçek iş yapan daha küçük bir döngüdür: bir geliştirici sonucu bir sorun olarak tanımlar, Codex dal üzerinde çalışır, CI değişikliğin gerçekten beklendiği gibi davrandığını kontrol eder, bir veya iki inceleme ajanı buna bakar ve riskli herhangi bir şey bir bayrak arkasına gönderilmeden önce bir insan tarafından onaylanır. Tüm mesele, orijinal diyagramın göz ardı ettiği tek bir ayrıntıya dayanır: “CI geçti” ifadesi, ancak CI doğru şeyleri kontrol ediyorsa bir anlam ifade eder. Bir API için bu, yalnızca API'yi çağıran kodu değil, API'yi test etmek anlamına gelir.

Diyagramın doğru anlattığı şeyler (ve kopyalayamayacaklarınız)

Pragmatic Engineer makalesinin herkese açık kısmı, Codex'in “hedefine ulaşana kadar bir dizi kod değişikliği yaptığı ve ardından yazılımın olması gerektiği gibi çalıştığını doğruladığı” temel bir döngüyü açıklıyor. Düşük riskli alanlar otomatik onaylanabilir; daha yüksek riskli değişiklikler daha fazla yapay zeka incelemesi veya zorunlu bir insan onayı alır. Risk düzeyine göre önerme, doğrulama, inceleme şeklindeki bu yapı taşınabilirdir. Ekipler bunu yıllardır çekme isteği botları ve CI geçitleri ile yaklaşık olarak uyguluyor; ajanlar ise döngüyü daha hızlı ve daha az denetimli hale getiriyor.

Taşınamayan şey ise etrafındaki dahili mekanizmalardır. Perf Factory, gecikme regresyonlarını bulmak ve düzeltmeler önermek için uyarıları ve kontrol panellerini tarar. Sevbot, olayları araştırır ve Slack'teki soruları yanıtlar, ancak kendisi iyileştirme eylemlerini yürütmez. Ajan tabanlı dağıtım, bir değişikliği üretime izler ve OpenAI'ın dahili telemetri yığınını kullanarak kendi izlemesini oluşturur. Bu üçünden hiçbiri harici Codex ürününde gönderilmez. Gönderilenler ise masaüstü uygulaması, uzun süreli görevler için /goal komutu ve kendi yapılandırdığınız rol eklentileri ve becerileridir. OpenAI'ın Codex ürün sayfası, gerçekten neyin mevcut olduğunu kapsar.

Bu hafta çalıştırabileceğiniz beş adımlı döngü

Ölçeklendirilmiş bir versiyonu şöyle görünüyor:

1. Bir geliştirici sonucu bir sorun olarak kaydeder. Bir görev listesi değil, nihai durumun bir açıklamasıdır: “siparişler, toplamı azaltan isteğe bağlı bir indirim kodu taşıyabilir.” Aynı GitHub sorununu Sharkly'deki bir Ajana vermek, gönderilen entegrasyondur: sorun bir Görev haline gelir ve çalışma, ayrı bir uzlaştırma bileti yerine bir PR olarak geri döner. Şu anda 10 kişiye kadar olan kuruluşlar için ücretsizdir.
2. Codex, /goal ile dal üzerinde çalışır. /goal komutunun otonom Codex ve Claude Kod çalıştırmalarını nasıl yönlendirdiği konusunda belirtildiği gibi, ajana bir hedef verirsiniz ve hedefe ulaşılana kadar kendi kendine tekrar etmesine izin verirsiniz.
3. CI, derleme, birim testleri ve API test senaryolarını çalıştırır. Bu, çoğu ekibin atladığı veya yarım bıraktığı adımdır.
4. Bir veya iki inceleme ajanı farkı kontrol eder ve bir insan düşük riskin üzerindeki her şeyi inceler. Yapay zeka kod inceleme araçları, bir insan PR'ı açmadan önce birçok şeyi yakalayabilir. Sharkly'de, "Yayınlamaya Hazır" durumu işi yapar: bir insan, herhangi bir şey "Bitti" durumuna ulaşmadan önce görevi o durumdan çıkarmalıdır ve ayrı bir inceleme Ajanı, kodu yazan ajanla aynı Ekipte yer alabilir.
5. Bir özellik bayrağının arkasına dağıtım yapın, böylece kötü bir birleştirme bir olay değil, bir geçiş anahtarı olur.

Adım 3, döngünün ya çalıştığı ya da size yalan söylediği yerdir.

CI neden sadece kodu değil, API'yi de test etmeli?

Codex'in kendi inceleme özelliği, Codex kod incelemesinin nasıl çalıştığı konusunda belirtildiği gibi, farkı okur ve bariz sorunları işaretler. Hizmetinizi çalıştırmaz ve ne döndürdüğünü kontrol etmez. Birim testleri, ajan onları yazdıysa veya koruduysa, çoğunlukla kodun amaçladığı şeyi yaptığını doğrular; bu, API'nin sözleşmenin vaat ettiklerini yaptığını doğrulamakla aynı değildir. Bir işleyiciyi düzenleyen bir ajan, sessizce her bir müşterinin bağlı olduğu yanıtı bozarken her birim testini geçebilir.

Diyelim ki bir sipariş API'si çalıştırıyorsunuz. POST /api/orders bir sipariş oluşturur ve kaydını döndürür; GET /api/orders/{id} kimliğine göre birini getirir. Her ikisi için de bir OpenAPI belirtimi tutuyorsunuz ve buna karşı Apidog test senaryoları oluşturdunuz: bir sipariş oluşturun, geri alın ve bir birim testinin genellikle yapmayacağı dört şeyi kontrol edin:

• Durum kodları. POST /api/orders, 200 veya doğrulama kenar durumunda sessiz bir 500 yerine 201 döndürür.
• OpenAPI belirtimine karşı yanıt şeması. total_amount alanı bir sayı olarak kalır, status tanımladığınız numaralandırma değerlerinden biri olarak kalır ve istemcilerin bağlı olduğu hiçbir alan sessizce kaybolmaz veya yeniden adlandırılmaz.
• Kimlik doğrulama hataları. Geçerli bir jeton olmadan yapılan bir istek, boş gövdeli bir 200 yerine 401 döndürür; bu şaşırtıcı derecede yaygın bir gerilemedir.
• Bir gecikme eşiği. Senaryo, yanıtın belirlenen bir sınırın altında geldiğini iddia eder, böylece işleyicinin içine gruplandırılmamış bir veritabanı çağrısı ekleyen bir değişiklik, müşteri fark etmeden önce yakalanır.

Bunlar, her birim testi hala geçerken bir işleyici düzeyinde yeniden düzenlemenin sessizce bozabileceği kontrollerdir, çünkü birim testleri genellikle API senaryosunun fiilen uyguladığı sınırı taklit eder.

Bunu işlem hattına bağlamak

Codex'te Apidog CLI'yı nasıl kullanacağınızı takip ettiyseniz, bu senaryoların CLI sürümünü zaten yerel olarak çalıştırıyorsunuz demektir. Aynı komut CI'da da çalışır. Derleme yapan, birim testlerini çalıştıran ve ardından Apidog senaryosunu çalıştıran bir GitHub Actions işi şöyle görünür:

name: CI

on:
  pull_request:
  push:
    branches: [main]

jobs:
  build-test-verify:
    runs-on: ubuntu-latest
    steps:
      - name: Check out repository
        uses: actions/checkout@v4

      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: Install dependencies
        run: npm ci

      - name: Build and run unit tests
        run: npm run build && npm test

      - name: Install Apidog CLI
        run: npm install -g apidog-cli

      - name: Run orders API test scenario
        env:
          APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}
        run: |
          apidog run \
            --access-token $APIDOG_ACCESS_TOKEN \
            -t 88214 \
            -e 3301 \
            -r cli,junit

      - name: Upload Apidog reports
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: apidog-reports
          path: apidog-reports/

-t ve -e değerleri, sizin uydurduğunuz yer tutucular değil, Apidog'dan alınan gerçek senaryo ve ortam kimliklerinizdir. apidog run komut referansı her bayrağı kapsar ve Apidog CLI test raporları, işin yüklediği JUnit çıktısını açıklar. apidog run, başarısız bir iddiada sıfır olmayan bir çıkış yapar, bu nedenle GitHub Actions, işi başarısız bir birim testi için olduğu gibi başarısız olarak işaretler.

Aracının istemi nasıl görünür?

/goal'in amacı, sonucu ve çıkış koşulunu sizin tanımlamanız ve Codex'in her adımı sizin onayınız olmadan yinelemesidir. İndirim kodu örneği için makul bir istem şöyledir:

/goal POST /api/orders'a isteğe bağlı bir `discount_code` alanı ekle. Bunu
promosyon hizmetine karşı doğrula ve indirimi yanıttaki `total_amount`'a uygula.
Mevcut hiçbir yanıt alanını yeniden adlandırma veya kaldırma.
Bitirmeden önce `npm test` ve `apidog run --access-token $APIDOG_ACCESS_TOKEN -t 88214 -e 3301
-r cli` komutlarını çalıştır. İkisi de 0 çıkış vermelidir. Apidog çalıştırması başarısız olursa,
başarısız olan iddiayı oku ve işleyiciyi düzelt, testi değil.

O son satır önemlidir. Bir kontrolü yeşile çevirme baskısı altındaki bir ajan bazen hatayı düzeltmek yerine iddiayı düzenler. Döngünün hangi tarafını düzelteceğini açıkça söylemek, test senaryosunu gerçeğin kaynağı olarak tutar, etrafından dolaşılması gereken bir engel olarak değil.

Aracı sözleşmeyi ihlal ettiğinde

Codex indirim alanını ekler ve bu süreçte total_amount'ı totalAmount olarak yeniden adlandırır, çünkü bu, yakında okuduğu bir dosyadaki kuraldır. Birim testleri hala geçer; indirim matematiğini kontrol ederler, alan adını değil. Derleme başarılı olur. Ardından Apidog senaryosu CI'da çalışır, yanıtı OpenAPI belirtimine karşı doğrular ve başarısız olur: belirtim total_amount derken, yanıt artık totalAmount içerir ve şema iddia hemen bunu yakalar.

CI, sıfır olmayan bir çıkış bildirir ve JUnit çıktısındaki başarısız şema iddiayı işaret eder. Codex hatayı okur, yeniden adlandırmanın neden olduğunu görür ve indirim mantığını koruyarak geri alır. Senaryo geçer, derleme yeşile döner ve çekme isteği, "geçti" kelimesinin arkasında gerçek bir garanti ile incelemeye taşınır. API düzeyinde kontrol olmasaydı, bu yeniden adlandırma gönderilir ve total_amount'ı ayrıştıran her istemci bir sonraki sürümde bozulurdu.

Belirtimde temellendirebileceğiniz risk katmanlandırması

Düşük riskli sayılan şeyin belirsiz bir hissine sahip olmak yerine, risk sınıflandırmanızı OpenAPI farkına bağlayın. Varsayılan değere sahip isteğe bağlı bir alan ekleyen bir değişiklik, testler geçtikten sonra otomatik birleştirme için bir adaydır. Bir alanı kaldıran, yeniden adlandıran veya bir durum kodunu değiştiren bir değişiklik, farkın geri kalanı neye benzerse benzesin asla düşük riskli değildir. Bu tek kural, uzman bir inceleme ajanının zaten işaretleyeceği çoğu şeyi yakalar. Kuralın işaretlediği her şeyi, birleştirmeden önce bir insan inceleyiciye veya bir yapay zeka kod inceleme aracından ikinci bir geçişe yönlendirin.

Bir bayrağın arkasına gönderin, boşluğa değil

Bir değişiklik CI ve incelemeyi geçtikten sonra, doğrudan her kullanıcıya göndermek yerine bir özellik bayrağının arkasına dağıtın. Bu, OpenAI'ın ajan tabanlı dağıtım adımının ucuz bir alternatifidir: dağıtımı denetleyen veya kendi kontrol panellerini oluşturan hiçbir ajan yoktur. %5 trafikle başlayan bir bayrak ve bunu %100'e çevirmeden önce hata oranlarını kontrol eden bir kişi, dahili araçların hiçbiri olmadan güvenliğin çoğunu size sağlar. Bir sorun varsa, baskı altında bir birleştirmeyi geri almak yerine bayrağı kapatırsınız.

Zaten var olan bir iskele

Tüm beş adımı sıfırdan bağlamak zorunda değilsiniz. orchflows, Orosz'un gönderisine verilen yanıtlarda ortaya çıkan açık kaynaklı bir projedir: Claude Code ve Codex için, az sayıda yeniden kullanılabilir beceri etrafında inşa edilmiş, MIT lisanslı bir /software-factory komutudur. Bu, yukarıdaki CI ve inceleme adımlarının yerine geçmez, sadece bir başlangıç iskelesidir; hala kendi test senaryolarınızı ve risk kurallarınızı ona işaret edersiniz.

Neyi inşa etmeyi atlamalı

Perf Factory, Sevbot veya kendi kendine inşa edilmiş kontrol panelleriyle ajan tabanlı dağıtımı yeniden oluşturmaya çalışmayın. Bunlar, çoğu ekibin çalıştırmadığı telemetriye bağlı dahili OpenAI sistemleridir. OpenAI'daki insanlar hala sonuçları tanımlar, yüksek riskli değişiklikleri onaylar, olay azaltmalarını yetkilendirir ve nöbet tutar; OpenAI'ın dediği gibi, “nöbet görevi geçmişte kalmış bir şey değildir.” Döngünün sadece iyi mühendislik disiplini olan kısımlarını kopyalayın: birleştirmeden önce doğrulayın, riski gerçekten neyin değiştiğine göre katmanlandırın ve açıkça güvenli olmayan her şeyde bir insanı bulundurun.

Döngüyü çalıştırın

CI adımıyla başlayın; bu, diğer her adımı güvenilir kılar. Apidog'da durum kodlarını, şemayı, kimlik doğrulamayı ve bir gecikme bütçesini kapsayan sipariş API test senaryonuzu oluşturun. Bunu CLI ile işlem hattınıza bağlayın, /goal'i gerçek bir soruna yöneltin ve Codex'in ajanın sözüne güvenmek yerine API davranışını gerçekten iddia eden bir kontrole karşı yinelemesine izin verin. İlk senaryoyu oluşturmak için Apidog'u indirin, ardından döngü kendini kanıtladığında inceleyici ve bayrak adımlarını ekleyin.