AI ile ABAP Kod Üretimi Nasıl Çalışır?

"AI ABAP yazar" cümlesi kulağa basit gelir, ama bir ABAP geliştiricisi için asıl soru şu: üretilen kod SAP'de gerçekten çalışır mı, yoksa genel amaçlı bir dil modelinin tahmin ettiği sözde-ABAP mı? Bu yazıda mdp/aigui'nin kod üretimi akışını adım adım açıyoruz — istek yazmaktan SAP'a aktivasyona kadar. Amaç pazarlama cümlesi kurmak değil; her adımda neyin otomatik yapıldığını, neyin sizin onayınıza bağlı kaldığını netleştirmek.

1. Doğal dil isteminden başlar

ABAP kod üretimi mdp/aigui'de doğal dille yazılmış tek bir istekle başlar: "Satış siparişlerini satış organizasyonu bazında toplayan bir ALV raporu yaz" gibi. Bir istem şablonu ezberlemeniz veya özel bir sözdizimi öğrenmeniz gerekmez — ihtiyacı bir meslektaşınıza anlatır gibi yazarsınız.

Kritik nokta, bu isteğin boşlukta işlenmemesi. mdp/aigui doğrudan SAP sisteminize bağlıdır: bağlantı, ADT (ABAP Development Tools) REST API üzerinden kurulur. SAP NetWeaver 7.40 ve üzeri sürümlerde bu servisler varsayılan olarak etkindir, yani sunucu tarafında ekstra kurulum gerekmez. İstek işlenirken gerçek sisteminizdeki tablo ve alan bilgileriyle zenginleştirilir — bir sonraki bölümün konusu tam olarak bu.

İstemin kalitesi çıktının kalitesini etkiler: tablo adını, filtre koşullarını ve beklenen çıktı formatını (ALV, liste, dosya) belirtmek işi hızlandırır. Ama eksik bıraktığınız yerde süreç durmaz; Agentic ABAP IDE yaklaşımının özü, aracın gereken bilgiyi sistemden kendisinin toplamasıdır.

2. Kod, uydurma değil gerçek sistem bilgisiyle üretilir

mdp/aigui, kodu üretmeden önce ilgili SAP nesnelerini genel bir eğitim setinden değil, o an bağlı olduğunuz sistemden okur. AI'ın "VBAK tablosunda hangi alanlar var" sorusuna verdiği yanıt, sizin sisteminizin veri sözlüğünden gelir. Genel amaçlı bir sohbet botu ile SAP AI aracı arasındaki asıl fark budur.

Bunun neden önemli olduğunu her ABAP geliştiricisi bilir: iki SAP sistemi birbirinin aynısı değildir. Z-tablolar, append yapıları, müşteriye özel alanlar ve data elementleri hiçbir dil modelinin eğitim verisinde yer almaz. Yalnızca kendi belleğine dayanan bir model, standart tablolarda bile sürüme göre değişen alanları yanlış hatırlayabilir.

Bu yüzden üretim öncesinde tablo alanları, data elementleri ve mevcut fonksiyon modülü imzaları ADT üzerinden canlı sistemden çekilir. Sonuç: hayali alan adlarıyla derlenemeyen kod üretme riski büyük ölçüde azalır. "Azalır" diyoruz, "sıfırlanır" değil — kalan riskin nasıl yakalandığını doğrulama döngüsü bölümünde anlatıyoruz.

3. Rapor, sınıf, fonksiyon modülü, Interface, CDS View

mdp/aigui beş ana nesne tipinde kod üretir: çalıştırılabilir rapor/program, ABAP sınıfı, fonksiyon modülü, arayüz (Interface) ve CDS View. Her nesne tipi kendi kalıplarıyla ele alınır — tek boyutlu bir şablonun beş nesneye kopyalanması değil:

• Rapor / program: selection-screen tanımı, veri seçimi ve ALV çıktısı dahil, çalıştırılabilir bütün olarak üretilir.
• ABAP sınıfı: metod imzaları, görünürlük ve hata yönetimi nesne yönelimli kalıplarla kurgulanır.
• Fonksiyon modülü: IMPORTING/EXPORTING/CHANGING/TABLES arayüzü ihtiyaca göre tanımlanır.
• Interface: sözleşmeyi tanımlayan metod ve tip bildirimleri üretilir.
• CDS View: modern S/4HANA geliştirmenin temel yapı taşı olarak desteklenir.

Kod nesnelerinin ötesinde, SE11 veri sözlüğü nesneleri (tablo, yapı, data elementi, domain) de uygulama içinden oluşturulup aktive edilebilir. Birden fazla nesnenin birlikte gerektiği senaryolarda ise "Planla ve Uygula" modu devreye girer: AI gereken tüm nesneleri bağımlılık sırasına göre (paket → domain → data elementi → tablo → fonksiyon modülü → sınıf → program) planlar, siz planı inceleyip onayladıkça adım adım uygular.

4. Satır bazlı diff — neden "kopyala-yapıştır" değil

Üretilen kod editörünüze otomatik yazılmaz; her değişiklik önce satır bazlı bir diff görünümünde önünüze gelir. AI'ın hangi satırı eklediği, hangisini değiştirdiği işaretli kalır — siz onaylamadan editördeki kod değişmez, reddederseniz her şey olduğu gibi kalır.

Bu yaklaşımın asıl değeri mevcut bir programı düzenlerken ortaya çıkar. Yıllardır canlıda çalışan bir Z-raporuna küçük bir koşul eklemek istediğinizde, "tüm kodu yeniden üret ve üzerine yaz" yaklaşımı kabul edilemez bir risktir: AI'ın dokunmaması gereken bir bölümü sessizce değiştirmediğinden emin olamazsınız. Satır bazlı diff bu belirsizliği ortadan kaldırır — neyin değiştiği tartışmaya yer bırakmadan görünürdür.

Aslında bu, ekiplerin insan geliştiriciler için zaten uyguladığı disiplinin AI'a taşınmasıdır: hiçbir kod incelenmeden ana koda girmez. AI'ın ürettiği kodun bundan muaf tutulması için hiçbir neden yok.

5. SAP'a gönderme ve aktivasyon sizin onayınızla

Kod SAP sistemine yalnızca siz onayladığınızda gönderilir; yazma ve aktivasyon adımları hiçbir koşulda otomatik çalışmaz. Diff onayından sonra kod tek tıkla SAP'a yazılır ve aktive edilir — pratik olarak Eclipse ADT'deki kaydet + aktive et akışının AI destekli hali.

Aktarım süreci de SAP standartlarının dışına çıkmaz: Transport (CTS) entegrasyonu sayesinde değişiklik için transport talebini uygulama içinden arayabilir veya oluşturabilirsiniz. Aktivasyon öncesinde syntax kontrol çalıştırmak da (IDE'deki F8 akışı) yine sizin elinizde.

Bu ilke mdp/aigui'nin genelinde geçerlidir: AI hiçbir zaman sizin bilginiz veya onayınız olmadan SAP sisteminize yazmaz. Aynı kural veri tarafında da işler — doğal dil sorgularında her SQL kullanıcı onayına sunulur ve AI otomatik veri silmez.

6. AI halüsinasyon üretirse ne olur? Doğrulama döngüsü

Sözde-ABAP'ın son hakemi dil modeli değil, SAP sisteminizin kendisidir: üretilen kod aktive edilmeden önce SAP'ın kendi syntax denetiminden geçer. Model ne kadar güçlü olursa olsun — Claude gibi modeller de dahil — hiçbir dil modeli %100 hatasız değildir; bu yüzden akış tek bir doğrulama noktasına değil, üst üste üç katmana dayanır:

• Üretim öncesi: tablo, alan ve fonksiyon modülü bilgileri canlı sistemden okunur — halüsinasyonun en yaygın kaynağı (uydurma alan adları) baştan daraltılır.
• Üretim sonrası: satır bazlı diff ile geliştirici her değişikliği görür ve onaylar — alan adı doğru ama iş mantığı yanlışsa bunu en iyi siz yakalarsınız.
• Aktivasyon öncesi: SAP syntax denetimi son sözü söyler. Derlenemeyen kod aktive edilmez; hata mesajı görünür ve düzeltme yine aynı diff-onay akışı içinde yapılır.

IDE tarafında ATC statik analiz ve birim test desteği de bu zincirin devamıdır: syntax'ı geçen kodun kalite ve davranış kontrolü için aynı ortamda araç hazırdır. Kısacası soru "AI hata yapar mı?" değil — yapar. Soru, hatanın canlı sisteme ulaşmadan hangi katmanda yakalandığıdır.

7. Güvenlik modeli: kod ve anahtarlar nereye gider?

AI'ın kod üretebilmesi için ilgili bağlam (istek ve gerekli sistem bilgisi) seçtiğiniz model sağlayıcısına gönderilir — ama bu trafik doğrudan sizin cihazınızdan sağlayıcıya akar. mdp/aigui sunucuları aracı konumda değildir; kodunuz ve verileriniz bizim altyapımızdan geçmez.

API anahtarları için de aynı model geçerlidir: anahtarlarınız yalnızca cihazınızda şifreli olarak saklanır ve hiçbir zaman mdp/aigui sunucularına iletilmez. SAP bağlantı bilgileriniz (host, kullanıcı adı, şifre) de aynı şekilde yalnızca cihazda şifreli tutulur. SAP bağlantısının kendisi internet bile gerektirmez — SAP sunucunuza ağ erişimi yeterlidir; internet yalnızca AI özellikleri için gereklidir.

Kurumsal dağıtımlarda ek seçenekler vardır: yönetilen AI erişimi ile şirket yöneticisi API erişimini merkezi olarak yapılandırır, kullanıcılar kendi anahtarlarını hiç girmeden şirketin belirlediği bütçe ve politikalar dahilinde çalışır. Trafiğin şirket ağından çıkmaması gereken senaryolar için Microsoft Azure AI Foundry (VNet, private access) desteklenir.

Sonuç

AI ile ABAP kod üretimi, "bir istem yaz, ne çıkarsa çıksın" değil; gerçek sistem bilgisiyle beslenen, satır satır incelenebilen ve yalnızca onayınızla SAP'a ulaşan bir süreç olduğunda gerçekten işe yarar hale geliyor. Eclipse ADT veya SE38'de saatler süren bir rapor yazımı, bu akışla dakikalar içinde — ve hâlâ sizin kontrolünüzde — tamamlanabiliyor.

Eclipse ADT veya SE38'e karşı bir konum da değil bu: mdp/aigui zaten aynı ADT altyapısını kullanır ve SAP'ın standart transport, aktivasyon ve syntax denetim mekanizmalarının içinde kalır. Değişen tek şey, kodun ilk halini kimin yazdığı. Değişmeyen şey ise son kararın — ve sorumluluğun — her adımda geliştiricide olması.