Her görev canlı bir sohbet gerektirmez. Sürüm notu hazırlama, değişiklik özeti çıkarma veya belirli bir hata kaydını sınıflandırma gibi işler düzenli bir süreçte çalıştırılabilir. Codex'in non-interactive kullanımı bu tür betik ve CI akışlarını destekler. Resmî belgelerde giriş noktası codex exec olarak açıklanır. Ancak iyi otomasyon, komutu bir iş akışına eklemekten daha fazlasını gerektirir.
Önce sabit girdiyi tanımlayın
Bir CI işinin hangi değişikliği değerlendirdiği kesin olmalıdır. “Son kodu incele” talebi yerine karşılaştırılacak temel sürüm ile değişiklik kimliğini kaydedin. Aynı iş tekrar çalıştırıldığında farklı bir dalın güncel halini okursa sonuçları karşılaştırmak güçleşir. Girdinin kaydı, otomasyonun araştırılabilir geçmişini oluşturur.
Örnek görev: “Bu çalışma kopyasındaki değişiklikleri verilen temel sürümle karşılaştır. Yalnızca kullanıcıya görünen davranışları özetle. Çıktıyı özellikler, düzeltmeler ve belirsiz maddeler bölümlerinde hazırla. Depoda veya dış sistemlerde değişiklik yapma.” İlk otomasyon için salt okuma niteliğinde bir iş seçmek, sonucu değerlendirmeyi ve hatayı geri almayı kolaylaştırır.
Gerekli bağımlılıkları da çalışmadan önce hazırlayın. Kod analizi sırasında eksik bir paket nedeniyle kurulum yapmak zorunda kalınması, ağ ve kimlik bilgisi ihtiyaçlarını değiştirebilir. Kurulum adımıyla inceleme adımını ayırmak, hangi sürecin hangi kaynağa eriştiğini daha açık hale getirir. Aynı ayrım süre ölçümünü de kolaylaştırır.
İzinleri sürecin başında belirleyin
CI ortamında karşılık verecek bir insan bulunmayabilir. Bu nedenle çalışma alanı, ağ ihtiyaçları ve hata halinde durma davranışı önceden tasarlanmalıdır. Belirsiz bir erişim ihtiyacını sessizce daha geniş yetkiyle çözmek yerine işin gerekli kaynağı açık biçimde bildirmesi daha yararlıdır. İnceleme görevi için depo yazma yetkisi gerekmeyebilir.
Kimlik bilgilerini çıktı dosyasına veya normal iş günlüğüne koymayın. Özellikle deponun kendi betikleri çalışıyorsa hangi süreçlerin ortam değişkenlerini okuyabildiğini düşünün. Resmî GitHub Actions örneğindeki gibi kod incelemesi, yama üretimi ve dış sistemde yazma adımlarını ayrı yetkilerle tasarlamak, sorumlulukları daraltabilir. Her projede aynı şablonu kopyalamak yerine kendi akışınızı değerlendirin.
Çıktıyı tüketen tarafı unutmayın
İnsan için yazılmış açıklama ile sonraki programın beklediği veri farklıdır. Bir sürüm notu Markdown olabilir; hata sınıflandırması ise sabit alanları olan JSON gerektirebilir. Çıktı dosyasının konumunu ve boş sonuç davranışını baştan kararlaştırın. Otomasyon bir şey bulamadığında “başarısız” mı sayılacak, yoksa boş bir liste mi üretecek?
Günlükler ile teslim dosyasını ayırın. Uzun araç çıktısını doğrudan müşteri sürüm notuna taşımak okunabilirliği bozar. Bir makine çıktısının içine açıklama paragrafı karışması da sonraki ayrıştırıcıyı durdurabilir. Sonraki adım, beklediği dosyanın gerçekten oluştuğunu ve kabul ettiği biçimde olduğunu kontrol etmelidir.
Aynı işi ikinci kez çalıştırın
İyi bir ilk deneme yeterli değildir. Aynı sabit girdiyi ikinci kez çalıştırıp temel alanların ve kapsamın korunduğunu görün. Metnin birebir aynı olması her işte gerekmez; fakat eklenen hayalî özellikler veya kaybolan önemli maddeler değerlendirilmelidir. Dış sisteme yazan işlerde tekrarın aynı kaydı çoğaltmaması ayrıca önemlidir.
Otomasyonun teslimi; görev metni, gereken ortam, üretilen çıktı ve bilinen sınırları kapsamalıdır. Bu küçük sözleşme, gece çalışan bir sürecin sabah anlaşılabilir olmasını sağlar. Amaç yalnızca insan etkileşimini azaltmak değil, işi tekrar yürütülebilir ve sonucu değerlendirilebilir hale getirmektir.
Resmî kaynak: OpenAI Docs — Non-interactive mode.
