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

> AI'ın yazdığı kod, henüz verilmemiş bir iş kararını içerebilir. Kabul ölçütleri, review ve güncel karar kayıtları bu belirsizliği nasıl görünür kılar?

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.

![Kod önerisi, kabul ölçütleri ve operasyonel kayıtlar bir iş kararının sahipliğinde birleşiyor](/images/inline-ai-code-team-delivery/ai-code-team-delivery.webp)

## 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.

![Operasyon, müşteri ve ürün sorumlusu adres değişikliği kuralının sonuçlarını tartarak kod güncellemesinden önce seçim yapıyor](/images/inline-ai-code-team-delivery/customer-time-needs-business-decision.webp)

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](https://martinfowler.com/articles/structured-prompt-driven/) 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.

---

Language: Turkish
License: CC BY 4.0
License URL: https://creativecommons.org/licenses/by/4.0/
Scope: Evren Bal-authored text, unless this article expressly states otherwise.
Excluded: Third-party material, quoted excerpts, logos, and separately marked images retain their own rights.
Attribution: Credit Evren Bal, link to the canonical source and license, and indicate changes.
Source: https://evrenbal.com/tr/ai-ile-kod-uretimini-ekip-teslimatina-donusturmek