AI kod yazarken iş kararını kim veriyor?

Bir siparişin adresini değiştiren kod hazır, testler geçiyor. Operasyon sorumlusu ise ekranda adres değişikliğinin hâlâ açık olduğu sipariş için “Depoda bunu toplamaya başladılar” diyor.

Bu varsayımsal sistemde uygulama, depodan gelen bildirimle siparişin durumunu “hazırlanıyor” olarak değiştiriyor. Geliştirici adres değişikliğini bu duruma bağlamış. Operasyon sorumlusu fiziksel hazırlığın başladığı anı esas alıyor. Bildirim geç geldiğinde depo çalışmaya başlamış olsa da müşteri yeni adres girebiliyor.

AI'ın yazdığı kod, kendisine verilen talimatı uyguluyor. Ancak geliştiriciyle operasyonun “hazırlık başladı” derken aynı şeyi kastetmediği şimdi anlaşılıyor. Ekip, hazır sandığı özelliğin nasıl çalışacağına yeniden karar vermek zorunda.

AI ile daha fazla kod üretmek, tek başına daha fazla yazılım teslim etmek değildir. Ekip teslimatı, ortak iş niyetinin kabul ölçütlerine dönüşmesini ve kodun güncel karara dayanmasını gerektirir. Açık kalan tercihi kimin yapacağı da bunun parçasıdır.

Daha erken kilitlemek müşteriden ne götürüyor?

Operasyonun kaygısı anlaşılır: Depo eski adresle çalışmaya başladıktan sonra müşterinin adres değiştirmesi, gönderiyi düzeltme işi çıkarabilir. Ürün ekibi ise müşteriye hazırlık başlayana kadar değişiklik yapma imkânı vermek istiyor.

Geliştirici, geciken bildirimi beklemek yerine adresi sipariş depoya gönderilirken kilitlemeyi önerebilir. Bu sistemde sipariş depoya aktarıldıktan sonra toplama sırasını bekliyor. Öneri uygulanırsa müşteri, henüz kimse ürünlere dokunmamışken de adres değiştiremeyecek.

Teknik düzeltme, müşteriye tanınan süreyi burada kısaltıyor. Bir durum kontrolünü değiştirmek kolay olabilir. Fakat bu tercihin bedelini müşteri yaşar, gelen itirazlarla ürün ve operasyon ilgilenir. Bu yüzden kodu inceleyen kişi bulguyu “kontrolü düzelt” diye kapatamaz. Hangi davranışın değişeceğini ilgili sorumlulara göstermesi gerekir.

Ekip, müşteriye verilen süreyi korumak için depo ile uygulama arasındaki işleyişi değiştirebilir. Ya da daha erken kilitlemeyi kabul edebilir. Teknik ekip seçeneklerin uygulanabilirliğini açıklar. Ürün ve operasyon arasındaki tercihi yapmaya yetkili sorumlu da hangi sonucun kabul edileceğini kararlaştırır.

İlk sürüm için erken kilitlemenin seçildiğini varsayalım. Kabul ölçütü artık “hazırlık başlayana kadar” gibi iki türlü yorumlanan bir ifade taşımaz. Sipariş depoya gönderildikten sonra adres değişikliği reddedilecek, müşteriye de işlemin kapanmış olduğu gösterilecek. Testler bu davranışı sınar. Ekip, canlıda müşteri ekranıyla depo işlemi uyuşmazsa kimin ilgileneceğini de belirler.

Sonraki geliştirici bu tercihi nereden öğrenecek?

Yalnızca kodu gören bir geliştirici, toplama başlamadığı hâlde adresin kilitlenmesini gereksiz bulabilir. Geciken bildirim yüzünden alınan kararı bilmiyorsa, iyileştirme yaparken aynı sorunu geri getirebilir. AI'a verilen yeni talimatta gerekçe eksikse aynı risk orada da oluşur.

Kararın gerekçesi, geçerli olduğu sipariş akışı ve değiştirmek için başvurulacak sorumlu bu yüzden bulunabilmeli. Bilgi mevcut iş kaydındaysa ayrı bir belgeye kopyalamak gerekmez. Kod ve test o kayda bağlanabilir. Depo işleyişi değişip erken kilitleme gereksizleştiğinde ekip, kararın hâlâ geçerli olup olmadığını yeniden değerlendirir.

Wei Zhang ve Jessie Jie Xia'nın Structured-Prompt-Driven Development yazısı da promptları kodla birlikte sürümlenen ve gözden geçirilen geliştirme girdileri olarak ele alıyor. Thoughtworks'ün iç IT ekiplerinden gelen bu uygulayıcı önerisi, küçük bir faturalama sistemi örneğiyle anlatılıyor. Yazı, yöntemin hız, kalite, güvenilirlik, maliyet veya ROI etkisine dair bağımsız karşılaştırmalı kanıt sunmuyor.

SPDD'nin bu örneğe katkısı, kararlaştırılmış iş niyetini sonraki kod üretiminde kullanılabilir tutma fikri. Bunun için kaydın güncel olması gerekir. İşletme farklı davranış seçtiğinde talimat, kabul ölçütü, test ve kod da bu seçimi izlemeli. Eski kararı Git'te saklamak, yeni geliştirmede hangisinin kullanılacağını kendiliğinden açıklamaz.

Kayıt, aynı tartışmayı yeniden yaşamayı azaltıyor mu?

Ek kayıt ve onayların ekip için bir karşılığı olmalı. Sonraki değişiklikte eski kuralın nedenini bulmak kolaylaştı mı? Yanlış anlaşılma yüzünden yapılan düzeltme işi azaldı mı? İncelemede kodla uğraşmaktan çok karar verecek kişiyi beklemeye mi zaman gidiyor?

Bunlar kazanım iddiası değil, düzeni sınamak için bakılabilecek noktalar. Kayıtları hazırlama ve güncelleme emeği de hesaba katılmalı. Benzer işlerde canlı hataları ve geri alma ihtiyacı izlenebilir. Ekip veya iş türü değişmişse farkı yalnızca yeni kayıt düzenine bağlamak güçleşir.

Açılıştaki sipariş için ekip artık adresin neden kapandığını, müşteriye tanınan sürenin neden kısaldığını ve bu tercihin ne zaman yeniden ele alınacağını açıklayabiliyor. Özelliği devralan kişi de hangi davranışı koruyacağını biliyor. Teslimat açısından ilerleme, çalışan kodun yanında bu ortak anlayışın da oluşmasıdır.