AI'ın Hazırladığı SAP Geliştirme Planını Onaylamadan Önce: 7 Kontrol

Agentic bir ABAP aracının en değerli çıktısı ürettiği kod değil, ürettiği plandır. Bir ihtiyacı tarif ettiğinizde araç gereken SAP nesnelerini — paket, domain, data elementi, tablo, fonksiyon modülü ya da sınıf, program — bağımlılık sırasına dizip önünüze koyar. Bu noktada henüz sisteme tek bir nesne yazılmamıştır. Yani bir hatayı düzeltmenin en ucuz olduğu an, tam olarak bu andır.

Sorun şu ki plan ekranı, onaylanmaya "hazır görünen" bir ekrandır. Nesne adları düzgün, sıra mantıklı, açıklamalar akıcıdır; göz hızla aşağı kayar ve onay butonuna basılır. Bu yazı, mdp/aigui'nin "Planla ve Uygula" modunda ya da herhangi bir agentic SAP aracında AI'ın çıkardığı bir planı onaylamadan önce bakılması gereken yedi noktayı ele alıyor. Hiçbiri yeni bir disiplin değil; hepsi kıdemli bir geliştiricinin bir teknik tasarımı gözden geçirirken zaten sorduğu sorular.

1. Plan, sistemde zaten olanı yeniden mi yaratıyor?

İlk soru planın içeriğiyle değil, planın neyi atladığıyla ilgilidir. İyi bir agentic akış, plan çıkarmadan önce ADT üzerinden sistemi okur: mevcut paketleri, tabloları, fonksiyon modüllerini. Bu keşif adımının sonucu planda görünmelidir — "bu tablo zaten var, yeni tablo yerine buna alan eklenebilir" ya da "bu hesaplamayı yapan bir fonksiyon modülü mevcut" gibi.

Planda her şey sıfırdan oluşturuluyorsa durup sorun: gerçekten hiçbiri yok mu? Özellikle yıllar içinde büyümüş sistemlerde aynı işi yapan iki Z-tablo ya da birbirinin kopyası iki fonksiyon modülü, çoğu zaman tam da böyle doğar — kimse önce aramadığı için. Aynı soru standart SAP nesneleri için de geçerli: malzeme, müşteri ya da şirket kodu alanı için yeni bir data elementi öneren bir plan, standart olanı kullanmayı neden tercih etmediğini açıklayabilmelidir.

2. İsimlendirme ve namespace

AI'ın önerdiği nesne adları sözdizimsel olarak geçerli olabilir ama kurumunuzun standardına uymayabilir. Hangi önekin (Z, Y ya da kayıtlı bir müşteri namespace'i) kullanıldığı, modül kısaltmasının ada nasıl gömüldüğü, tablo ile data elementinin adlarının birbirini nasıl izlediği — bunların hiçbiri dil modelinin bilebileceği şeyler değildir, ta ki sistemdeki mevcut nesnelerden çıkarılana ya da size sorulana kadar.

Bu kontrol kozmetik değildir. Yanlış adla oluşturulup transport'a girmiş bir nesneyi sonradan yeniden adlandırmak SAP'ta neredeyse her zaman "yenisini oluştur, kullanımları taşı, eskisini sil" demektir. Uzunluk sınırlarına da dikkat edin: tablo adları kısa bir sınıra tabidir ve uzun, açıklayıcı bir ad önerisi aktivasyonda değil, oluşturma anında takılır. Plan ekranında bir adı düzeltmek ise birkaç saniyelik iştir.

3. Paket ve transport hedefi

Planın en tepesinde duran paket kararı, altındaki her nesnenin kaderini belirler. Nesneler yerel bir pakete mi ($TMP) gidiyor, yoksa transport edilebilir gerçek bir pakete mi? Doğru yazılım bileşenine ve transport katmanına bağlı mı? Prototip için yerel paket makul olabilir; ama test sistemine taşınacak bir geliştirmeyi yerel pakette başlatmak, sonradan paket değiştirme ve transport'a ekleme işi yaratır.

Transport tarafında da aynı netlik gerekir: zincirdeki tüm nesneler aynı talebe mi gidecek, yoksa sözlük nesneleri ile kod ayrı taleplerde mi taşınacak? Bu kararı uygulama başlamadan vermek gerekir. mdp/aigui'de transport talebi uygulama içinden aranabilir veya oluşturulabilir; ama hangi talebin doğru olduğu, kurumunuzun değişiklik yönetimi sürecine bağlı bir karardır ve onu ancak siz verebilirsiniz.

4. Sözlük nesnelerinin gerçekten gerekli olup olmadığı

AI'ın hazırladığı planlar sözlük tarafında genellikle cömerttir: her yeni alan için yeni bir domain ve yeni bir data elementi. Bu bazen doğrudur — alanın kendine özgü bir değer aralığı ya da sabit değer listesi varsa ayrı bir domain anlamlıdır. Ama çoğu zaman yeni bir alan, mevcut bir domaine dayanan yeni bir data elementi ile, hatta doğrudan mevcut bir data elementiyle karşılanabilir.

Bakılacak şey nesne sayısı değil, her nesnenin bir gerekçesi olup olmadığıdır. Yeni bir data elementi öneriliyorsa alan etiketleri raporlarda ve ekranlarda nasıl görünecek? Yeni bir domain öneriliyorsa sabit değerler doğru mu, yoksa bunlar aslında bir kontrol tablosunda mı yaşamalı? Gereksiz her sözlük nesnesi, ileride bakımı yapılacak, çevirisi yapılacak ve transport edilecek bir nesne daha demektir.

5. Tablonun teknik kararları

Planda yeni bir tablo varsa, yalnızca alan listesine değil, alan listesinin söylemediklerine de bakın. Anahtar alanlar doğru mu — bir kaydı gerçekten benzersiz kılan kombinasyon bu mu? Tablo istemciye (client) bağımlı olmalı mı, yani ilk anahtar alanı istemci alanı mı? Teslimat sınıfı tablonun bir uygulama verisi tablosu mu yoksa bir özelleştirme tablosu mu olduğunu doğru yansıtıyor mu?

Bu kararlar tablonun ilk aktivasyonundan sonra değiştirilebilir, ama içine veri girdikten sonra her değişiklik bir dönüştürme işine dönüşür. Anahtar yapısını sonradan değiştirmek, özellikle canlı sistemde, kimsenin istemediği bir iştir. Plan bu bilgileri açıkça göstermiyorsa onaydan önce sorun ya da tabloyu uygulama sonrası veri sözlüğünde açıp teknik ayarlarını aktivasyondan önce kendiniz kontrol edin.

6. İş mantığının nereye konduğu

Zincirin ortasındaki iş mantığı katmanı, planın en az dikkat çeken ama uzun vadede en çok etki eden kararıdır. Hesaplama bir fonksiyon modülüne mi, bir sınıfa mı konuyor? Yoksa doğrudan programın içine mi gömülüyor? Programın içine gömülen mantık bugün hızlıdır ama yarın aynı hesaplamaya bir arayüzden, bir arka plan işinden ya da başka bir rapordan ihtiyaç duyulduğunda kopyalanır.

Ekibinizin yaklaşımı ne ise — yeni geliştirmeleri sınıf tabanlı yazmak, RFC ile çağrılacak işlevleri fonksiyon modülünde tutmak — planın buna uyup uymadığına bakın. Burada "doğru" cevap tek değildir; ama planın yaptığı tercihin sizin tercihiniz olması gerekir, aracın varsayılanı değil.

7. Kapsamın sınırı: fazla ve eksik adımlar

Son kontrol planın kenarlarıyla ilgilidir. Fazla adım: tarif ettiğiniz ihtiyacın dışına taşan bir nesne var mı — istenmemiş bir bakım ekranı, gereksiz bir yardımcı sınıf? Eksik adım: plan, ihtiyacın gerçekten tamamlanması için gereken bir şeyi atlıyor mu?

Eksik adımlar daha sinsidir, çünkü plan ekranında görünmezler. Yetki kontrolü bunun en tipik örneğidir: bir raporun hangi kullanıcıların hangi verilerini görebileceği, çoğu zaman tarif edilen ihtiyaçta hiç geçmez ve dolayısıyla plana da girmez. Benzer şekilde bir işlem kodu, bir arka plan iş tanımı ya da bir bakım görünümü gerekip gerekmediği de çoğunlukla sizin bilginize kalmıştır — ve bunların bir kısmı hâlâ SAP GUI üzerinden yapılan işlerdir. Planı onaylamadan önce "bu nesneler oluştuğunda iş gerçekten bitmiş olacak mı?" sorusunu sormak, eksik halkayı uygulama bittikten sonra değil, şimdi bulmanızı sağlar.

Onay bir imza değil, bir düzenleme anıdır

Bu yedi kontrolün ortak noktası, hepsinin plan ekranında ucuz, uygulamadan sonra pahalı olmasıdır. mdp/aigui'de plan doğrudan uygulanmaz; önce inceleme fazında size gelir ve düzenlenebilir — bir nesnenin adını değiştirebilir, gereksiz bir adımı çıkarabilir ya da eksik olanı ekleyebilirsiniz. Onayladıktan sonra da uygulama tek seferde değil, adım adım ilerler: kod içeren adımlar satır bazlı diff olarak önünüze gelir ve SAP'a yalnızca sizin onayınızla yazılır. Syntax kontrolü ve aktivasyon SAP'ın kendi mekanizmalarıyla çalışır; derlenemeyen kod aktive edilmez.

Ama adım adım onay, plan aşamasındaki bir yanlışı telafi etmez — yalnızca onu daha geç fark etmenizi sağlar. Yanlış pakete giden bir tabloyu üçüncü adımda fark etmek, sekizinci adımda fark etmekten iyidir; plan ekranında fark etmek ise ikisinden de iyidir.

Sonuç

Agentic bir aracın planını gözden geçirmek, bir meslektaşın teknik tasarımını gözden geçirmekten farklı değildir — ve aynı ciddiyeti hak eder. Yedi soruyu kısaca özetlersek: zaten var mı, adı doğru mu, nereye ve hangi transport'la gidiyor, bu sözlük nesnesi gerçekten gerekli mi, tablonun anahtarı ve sınıfı doğru mu, mantık doğru yerde mi, iş bittiğinde gerçekten bitmiş olacak mı.

AI planın ilk taslağını saniyeler içinde çıkarır ve bağımlılık sırasını takip etme yükünü sizden alır. Bu, geliştiricinin zamanını azaltmaz; onu doğru yere taşır. Plan ekranında harcanan beş dakika, agentic bir geliştirmede harcanabilecek en verimli beş dakikadır.