Codex Pro Daha Çok Kod mu, Daha Çok Bitmiş İş mi?

Codex kullanım sınırına daha az takılmak, görevleri daha uzun süre çalıştırmak veya birkaç işi aynı dönemde ilerletmek cazip görünebilir. Fakat küçük bir ekip ya da tek başına çalışan bir geliştirici için asıl soru şudur: Daha yüksek kapasiteli bir plan, gerçekten daha fazla işi bitirmemi sağlıyor mu?

Bu soruyu yalnızca üretilen kod miktarına bakarak cevaplayamayız. Ajan bir öğleden sonra beş değişiklik hazırlayabilir; ancak bunların üçü inceleme bekliyor, biri testleri bozuyor, diğeri de kullanıcının istediği davranışı karşılamıyorsa ortada beş bitmiş iş yoktur. Yalnızca büyümüş bir kontrol kuyruğu vardır.

Bu yazıda ayrıntılı maliyet formüllerine girmeden, başlangıç seviyesinde uygulanabilecek bir karar yöntemi kuracağız. Önce “bitmiş iş”in ne olduğunu açıklayacak, ardından mevcut plan ile Pro koşulunu bir haftalık küçük bir pilotta karşılaştıracağız. Pilotun sonunda elinizde yalnızca “daha hızlı hissettirdi” gibi bir izlenim değil; kalma, geçme veya yalnızca yoğun dönemlerde ek kapasite kullanma kararını destekleyen somut gözlemler olacak.

Daha fazla kapasite, tek başına sonuç değildir

Daha yüksek kullanım hakkı, ajana daha fazla görev verebilmenizi sağlayabilir. Daha uzun çalışma oturumları ve kullanım sınırına daha seyrek rastlamak da günlük akışı rahatlatabilir. Bunlar gerçek avantajlardır; fakat hiçbiri tek başına doğru, güvenli ve yayımlanabilir bir ürün değişikliği garanti etmez.

Bunu bir atölye üzerinden düşünelim. Atölyeye ikinci bir matkap almak, delik açma kapasitesini artırır. Fakat ölçüler yanlışsa daha hızlı çalışmak yalnızca yanlış yerde daha çok delik açılmasına yol açar. Parçaları ölçen, yapılan işi kontrol eden ve ürünü teslim eden kişi aynı kişiyse üretimdeki artış son aşamada yığılma da yaratabilir.

Kodlama ajanlarında dört ayrı kavramı birbirinden ayırmak gerekir:

• Kapasite: Ajanın belirli bir dönemde ne kadar çalışma yürütebildiğini gösterir.
• Doğruluk: Yapılan değişikliğin istenen davranışı karşılayıp karşılamadığını gösterir.
• Doğrulama: Değişikliğin yalnızca doğru görünmediğini, gerçekten çalıştığını kanıtlar.
• Teslim: Değişikliğin incelenmiş, kabul edilmiş ve güvenle birleştirilebilir duruma gelmesidir.

Plan kararında bizi asıl ilgilendiren teslimdir. Daha çok ajan çalışması, ancak doğrulanmış ve kabul edilmiş işlerin sayısını artırıyorsa değerlidir.

Daha yüksek planın değeri, ajanın ne kadar meşgul olduğuyla değil, sizin güvenle kabul edebildiğiniz işlerin artmasıyla ortaya çıkar.

Plan değiştirmeden önce darboğazınızı bulun

Bir iş akışı yavaşladığında en görünür engeli gerçek neden sanmak kolaydır. Kullanım sınırına rastlamak can sıkıcıdır; fakat her gecikmenin nedeni bu sınır değildir. Bazen ajan çalışmayı bitirir, siz çıktıyı iki gün boyunca inceleyemezsiniz. Bazen görev o kadar belirsiz yazılmıştır ki ilk sonuçtan sonra uzun bir düzeltme konuşması gerekir. Bazen de testler eksik olduğu için değişikliğin güvenli olup olmadığını anlamak, kodu üretmekten daha uzun sürer.

Plan sayfasını açmadan önce son iki haftada geciken üç işi inceleyin. Her biri için gecikmenin baskın nedenini tek cümleyle kaydedin. Örneğin:

• “Ajan kullanım sınırı nedeniyle tanımlanmış göreve devam edemedi.”
• “İstenen davranışı başlangıçta yeterince açık tarif etmedik.”
• “Kod hazırdı ama insan incelemesine zaman ayıramadık.”
• “Otomatik test olmadığı için sonucu elle kontrol etmek uzadı.”
• “Aynı anda fazla iş açtığımız için hangi değişikliğin hazır olduğunu kaybettik.”

İlk neden tekrar tekrar karşınıza çıkıyorsa daha yüksek kapasite anlamlı bir adaydır. Diğer nedenler baskınsa önce çalışma sistemini düzeltmek daha yararlı olabilir. Daha yüksek limit, belirsiz bir görevi kendiliğinden netleştirmez; eksik doğrulama düzenini tamamlamaz ve insanın inceleme zamanını artırmaz.

“Bitmiş iş” için dört soruluk kabul kapısı

İki planı karşılaştırabilmek için ikisinde de aynı bitiş çizgisini kullanmalıyız. “Ajan görevi tamamlandı olarak işaretledi” yeterli bir ölçü değildir. Başlangıç için şu dört soruluk kabul kapısı yeterlidir:

1. İstenen kullanıcı davranışı gerçekleşiyor mu?
2. İlgili testler geçiyor mu?
3. Mevcut çalışan davranışların bozulmadığı doğrulandı mı?
4. Bir insan değişikliği inceleyip birleştirilebilir buldu mu?

Bir işin teslim edilmiş sayılması için dört sorunun tamamına “evet” yanıtı verilmelidir. Böylece testleri geçen fakat yanlış ihtiyacı çözen, doğru görünen fakat eski bir özelliği bozan veya henüz insan tarafından incelenmeyen değişiklikleri başarı hanesine yazmamış olursunuz.

Doldurulmuş örnek: kupon alanı

“Sepete kupon alanı ekle” talebi ilk bakışta açık görünür. Oysa geçersiz kodun ne yapacağı, indirimin nerede doğrulanacağı veya aynı kodun iki kez uygulanıp uygulanamayacağı belirtilmemiştir. Başlamadan önce küçük bir başarı sözleşmesi yazalım:

Bu tablo teknik bir bürokrasi değildir. Ajanın ne yapacağını ve sizin neyi kontrol edeceğinizi aynı yerde buluşturur. Pilot boyunca bütün görevlerde aynı açıklık düzeyini kullanmak, iki koşulu daha adil karşılaştırmanızı sağlar.

Bir haftalık pilot: Üç eşleştirilmiş görev çifti

Tek bir kolay görevle karar vermek yanıltıcıdır. Küçük bir metin değişikliğinde iki plan arasında fark görülmeyebilir; olağanüstü zor bir görev ise gündelik kullanımınızı temsil etmeyebilir. Aynı görevi iki kez yaptırmak da sorunludur: İkinci denemede ilk çözümden kalan bilgi, dosya değişiklikleri veya sizin kazandığınız deneyim sonucu etkileyebilir.

Başlangıç seviyesinde daha temiz bir yöntem için toplam altı gerçek görev seçin. Bu görevleri zorluk ve doğrulama ihtiyacı bakımından üç çift hâlinde eşleştirin. Her çiftin bir görevini mevcut plana, diğerini Pro koşuluna verin. Böylece her koşulda üç ayrı görev, pilotun tamamında ise altı görev bulunur.

Örnek bir abonelik uygulamasında eşleştirme şöyle kurulabilir:

Eşleştirme “iki görev de küçük görünüyor” demekten biraz daha dikkatli yapılmalıdır. Aynı görev ailesinde olmalarına, benzer sayıda sistemi etkilemelerine ve benzer doğrulama adımları istemelerine bakın. Örneğin basit bir düğme metni değişikliği ile ödeme toplamını etkileyen bir sunucu değişikliğini aynı çifte koymayın.

Görevlerin tamamen aynı zorlukta olduğunu kanıtlamak mümkün değildir. Bu pilot bilimsel bir laboratuvar deneyi değil, kendi çalışma düzeniniz için karar desteğidir. Amacımız görev farkını ortadan kaldırmak değil, farkın sonucu kolayca ele geçirmesini önleyecek kadar dengeli bir karşılaştırma kurmaktır.

Hafta boyunca ne yapacağız?

• Pazartesi: Altı görevi üç çift hâlinde eşleştirin. Altı görevin de başarı sözleşmesini, testini, görsel ya da işlevsel kontrolünü ve insan onayı koşulunu yazın.
• Salı ve çarşamba: Her çiftin bir görevini mevcut planda, diğerini Pro koşulunda çalıştırın. Sonuçta her koşula üç görev atanmış olsun. Aynı proje talimatlarını, benzer çalışma saatlerini ve aynı açıklık düzeyini kullanın.
• Perşembe: Yeni görev açmayın. Altı görev için testleri, gerçek kullanıcı akışlarını ve kod incelemelerini tamamlayın.
• Cuma: Her koşuldaki üç görevden kaçının dört soruluk kabul kapısından geçtiğini ve kalanların neden tamamlanmadığını kaydedin.

Pilotta iki koşula da adil davranın. Bir tarafta ayrıntılı görev sözleşmesi, diğer tarafta tek cümlelik istek kullanmayın. Bir planın çıktısını dikkatle inceleyip diğerini aceleyle onaylamayın. Mümkünse hangi çiftte hangi görevin hangi koşula verileceğini çalışmaya başlamadan önce belirleyin; sonuçları gördükten sonra görev dağılımını değiştirmeyin.

Karmaşık hesaplar yerine dört basit gözlem

Yararlı bir karar için ayrıntılı bir finans tablosu kurmanız gerekmez. Pilot sırasında dört şeyi kaydetmeniz yeterlidir.

1. Kaç iş gerçekten bitti?

Kod üretilen görevleri değil, kabul kapısının tamamından geçen görevleri sayın. Bir koşula verilen üç görevden ikisi testleri geçtiği hâlde bunlardan biri insan incelemesi bekliyorsa bitmiş iş sayısı iki değil, yalnızca birdir.

2. Ne kadar insan ilgisi gerekti?

Dakika dakika kusursuz zaman takibi yapmanız şart değildir. Her görevi “az”, “orta” veya “çok” insan ilgisi gerektirdi diye işaretleyebilirsiniz:

• Az: Görev başta açıklandı, sonuç bir kez incelendi ve kabul edildi.
• Orta: Birkaç açıklama veya küçük düzeltme gerekti.
• Çok: Çıktı önemli ölçüde yeniden yazıldı, uzun süre hata arandı ya da görev baştan kurulmak zorunda kaldı.

Bu sınıflandırma kesin bir para hesabı vermez. Fakat planın sizi gerçekten rahatlattığını mı, yoksa daha fazla denetim işi mi doğurduğunu gösterir.

3. Kaç düzeltme turu gerekti?

Ajanın ilk “hazır” mesajından sonra kaç kez yeniden çalışması gerektiğini not edin. Bunun yanında düzeltmenin önemini de yazın. Bir boşluk ayarını değiştirmek ile yanlış ödeme toplamını veya eksik yetki kontrolünü düzeltmek aynı ağırlıkta değildir. Güvenlik, ödeme, yetkilendirme ya da veri kaybı riski doğuran tek bir hata, birkaç küçük görsel düzeltmeden daha güçlü bir karar sinyali olabilir.

4. Kapasite gerçek engeli kaldırdı mı?

Daha yüksek plan sayesinde daha önce sınır nedeniyle duran, iyi tanımlanmış bir görev tamamlandı mı? Yoksa boşalan kapasite yalnızca inceleyemediğiniz yeni işler açmak için mi kullanıldı? Pro koşulunda çok sayıda dal açıp yalnızca birkaçını kontrol edebiliyorsanız sorun artık kullanım sınırı değil, inceleme kuyruğudur.

Doldurulmuş pilot sonucunu birlikte okuyalım

Deniz, tek başına küçük bir abonelik ürünü geliştiriyor. Bazı yoğun günlerde kullanım sınırına yaklaşıyor ve Pro’nun işini gerçekten rahatlatıp rahatlatmayacağını anlamak istiyor. Üç eşleştirilmiş görev çiftinden oluşan, toplam altı görevli pilotun sonunda şu tabloyu çıkarıyor:

Bu örnekte Pro lehine bir işaret vardır: Her iki koşula da üç görev atanmasına rağmen Pro tarafındaki üç görevin tamamı kabul kapısından geçmiş, mevcut planda ise iki görev tamamlanmıştır. Üstelik insan ilgisi artmamış ve hafta sonunda bekleyen iş kalmamıştır.

Yine de bir haftalık sonuç kesin hüküm değildir. Görevlerden biri tahmin edilenden kolay çıkmış olabilir; proje o hafta olağan dışı derecede sakin ilerlemiş olabilir. Deniz bu nedenle aynı kabul kapısını sonraki gerçek işlerinde kullanmayı sürdürür ve ilk sonucun tekrarlanıp tekrarlanmadığına bakar.

Tersi bir sonuç da mümkündür. Pro daha çok değişiklik üretirken kabul edilen iş sayısı aynı kalabilir; hatta inceleme kuyruğu büyüyebilir. Bu durumda daha yüksek kapasite teslimi artırmamış, yalnızca devam eden iş miktarını çoğaltmıştır. İlk müdahale yeni plan almak değil, aynı anda açılan görevleri azaltmak ve doğrulama sürecini iyileştirmek olmalıdır.

Üç seçenek için kolay karar kuralı

Pro’ya geçmeyi düşünün, eğer…

• Kullanım sınırı iyi tanımlanmış gerçek işleri düzenli olarak durduruyorsa,
• Eşleştirilmiş pilotta kabul edilen iş sayısı Pro koşulunda artıyorsa,
• Bu artış daha fazla insan denetimi veya daha ciddi hata üretmiyorsa,
• Ek kapasiteyi yalnızca yeni görev açmak için değil, işleri kabul kapısından geçirmek için kullanabiliyorsanız.

Mevcut planda kalın, eğer…

• Kullanım sınırına nadiren ulaşıyorsanız,
• Asıl sorun belirsiz görevler, eksik testler veya inceleme kuyruğuysa,
• Pro daha çok çıktı üretse de kabul edilen iş sayısını artırmıyorsa,
• Üretilen değişiklikleri kontrol etmeye zaten yetişemiyorsanız.

Yalnızca yoğun dönemlerde ek kapasiteyi değerlendirin, eğer…

• İhtiyaç lansman, bakım veya kısa bir teslim dönemi sırasında yükseliyorsa,
• Normal haftalarda mevcut plan yeterli geliyorsa,
• Satın alma anında planınız için sunulan güncel seçenek geçici ihtiyacınıza uyuyorsa.

Plan fiyatları, kapsanan kullanım ve ek kapasite seçenekleri zaman içinde değişebilir. Bu nedenle kararı verdiğiniz gün resmî fiyatlandırma ve kullanım sınırı sayfalarını kontrol edin. Buradaki yöntem belirli bir fiyatı kalıcı kabul etmez; o gün sunulan seçenekleri kendi teslim düzeninize göre değerlendirmenizi sağlar.

Daha yüksek kapasiteye geçmeden önce sistemi hazırlayın

Pro’ya geçseniz de mevcut planda kalsanız da şu dört alışkanlık çalışma düzeninizi güçlendirir:

1. Görevi başarı davranışıyla yazın. “Kupon ekle” yerine geçerli, geçersiz ve tekrar kullanılan kodun ne yapacağını belirtin.
2. Her göreve aynı kabul kapısını koyun. İstenen davranış, geçen testler, bozulmayan eski işlevler ve insan incelemesi doğrulanmadan “bitti” demeyin.
3. Aynı anda yürüyen işi sınırlayın. İki değişiklik inceleme bekliyorsa üçüncüyü başlatmadan önce kuyruğu temizlemeyi düşünün.
4. Ajan raporunu tek başına kanıt saymayın. Değişen dosyaları, test sonuçlarını ve gerçek kullanıcı akışını kontrol edin.

Bu sistem yoksa daha yüksek kapasite zayıf yönleri büyütebilir. Sistem varsa plan farkını daha temiz görürsünüz; çünkü hangi işin tamamlandığı ve hangisinin yalnızca üretildiği bellidir.

Yarın atılacak ilk adım

Önce son iki haftada geciken üç işi açın ve her birinin neden geciktiğini tek cümleyle yazın. Kullanım sınırı gerçekten baskın neden çıkarsa gelecek hafta için üç karşılaştırılabilir görev çifti, yani toplam altı küçük ya da orta büyüklükte görev seçin. Her görevin başarılı durumunu, hata durumunu, testini ve insan onayı koşulunu baştan belirleyin.

Cuma günü kaç satır kod yazıldığına veya ajanın ne kadar süre meşgul göründüğüne bakmayın. Her koşula verilen üç görevden kaçının kabul kapısından geçtiğine, bu görevlerin sizden ne kadar ilgi istediğine ve geride nasıl bir inceleme kuyruğu bıraktığına bakın.

Planın karşılığını daha çok kodda ararsanız ölçmek kolay, yanılmak da kolay olur. Karşılığı daha çok doğrulanmış işte aradığınızda ise plan seçimi bir güç gösterisi olmaktan çıkar; çalışma biçiminize uygun, gözlemlenebilir bir ürün kararına dönüşür.

Kaynaklar

• Pricing | ChatGPT Learn
• Using Codex with your ChatGPT plan | OpenAI Help Center
• Code review | ChatGPT Learn
• Custom instructions with AGENTS.md | ChatGPT Learn