İçeriğe geç
Dinamik Çözüm

Ana sayfa / Blog

Claude ile X++ geliştirme: beş ayda öğrendiklerimiz

Dinamik Çözüm ·

Haziran 2026'da ekibimizde basit bir karar aldık: Dynamics 365 Finance & Operations geliştirmelerinde Claude'u gerçek işte kullanacağız. Demo projesinde değil, müşterinin geliştirme ortamında, gerçek taleplerle. Beş ay geçti. Bu yazıda o süreçte gördüklerimizi, mümkün olduğunca abartmadan anlatmaya çalışacağız.

İlk hafta: "Bu X++'ı biliyor mu?"

İlk izlenim karışıktı. Claude genel X++ sözdizimini biliyordu, ama F&O'nun kendine has tarafları söz konusu olunca tökezliyordu. F&O geliştiren herkesin tanıdığı türden hatalar: Chain of Command ile bir metodu genişletirken next çağrısını atlamak, bir form uzantısında olmayan bir veri kaynağına referans vermek gibi. Böyle bir kod ya derlenmez ya da derlenip yanlış çalışır; ikincisi daha tehlikelidir.

Sorunun modelin zekâsında olmadığını kısa sürede anladık. Sorun bağlamdaydı. Claude, Microsoft'un standart kodunu ezbere bilmiyor; bizim müşterimizin yıllar içinde biriktirdiği özel geliştirmeleri hiç bilmiyor. Bir insanı da bu kadar bağlamsız bir projeye sokarsanız benzer hatalar yapar.

Bağlamı biz kurduk

Sonraki haftalarda işin büyük kısmı Claude'a doğru bilgiyi vermekle geçti. Bugün üç katmanla çalışıyoruz:

  • Microsoft'un standart kodu. Application Foundation, Platform ve Common paketlerinin X++ kaynağını parçalara ayırıp yerel bir vektör veritabanına koyduk. Toplam 140 binden fazla parça. Claude bir standart sınıfın nasıl çalıştığını tahmin etmek yerine gidip bakıyor.
  • Müşterinin kendi geliştirmeleri. Müşteriye özel nesnelerin kataloğu ayrı bir koleksiyonda duruyor. Claude ayrıca çalışırken geliştirme ortamındaki kodu doğrudan okuyor.
  • Bizim tecrübemiz. Her geliştiricinin Claude oturumu, öğrendiği dersleri ortak bir depoya yazıyor. Bir sonraki oturum o depoyla başlıyor.

Bu üçüncü katman beklemediğimiz kadar önemli çıktı. Ona birazdan döneceğiz.

En çok vakit kazandıran yer kod değil, okumak

Dışarıdan bakınca yapay zekânın en büyük faydası kod yazmak gibi görünür. Bizim deneyimimizde öyle olmadı. Asıl fark, mevcut sistemi anlamakta ortaya çıktı.

Yıllardır geliştirilen bir F&O ortamında yeni bir talep geldiğinde ilk soru hep aynıdır: "Bu iş zaten bir yerde yapılıyor mu, hangi tablolara dokunuyor, neyi bozarım?" Bunu cevaplamak için eskiden bir geliştirici yarım gün nesne arardı. Şimdi Claude ilgili tabloları, formları ve sınıfları tarayıp bir analiz dokümanı çıkarıyor. Analist o dokümanı okuyup onaylıyor ya da düzeltiyor. Kod ancak bundan sonra yazılıyor.

Bu sırayı bilerek koruyoruz: analiz onaylanmadan kod yazılmıyor. Yapay zekâ çok hızlı kod üretebildiği için, yanlış anlaşılmış bir talebin üzerine güzel ama yanlış bir kod inşa etmek de çok kolay. Onay adımı bunun önündeki en ucuz önlem.

Dersler kaybolunca aynı hata tekrar ediyor

F&O geliştiren herkesin bildiği küçük tuzaklar vardır: senkronizasyondan sonra kaybolan bir alan, belli bir sırada derlenmezse hata veren bir model, SSRS raporunda beklenmedik biçimde davranan bir veri sağlayıcı sınıfı. Bunlar dokümanda yazmaz, kişilerin kafasında durur.

Yapay zekâyla çalışmaya başladığımızda bu sorun büyüdü. Bir geliştiricinin oturumunda Claude bir tuzağa düşüp çıkıyor, ama ertesi gün başka bir geliştiricinin oturumunda aynı tuzağa yeniden düşüyordu. Çünkü oturumlar birbirini bilmiyordu.

Çözüm olarak ortak bir tecrübe deposu kurduk. Her oturumun başında depo çekiliyor, sonunda yeni dersler ekleniyor. Bugün içinde yüzden fazla konu var: X++ tuzakları, derleme ve senkronizasyon sorunları, form ve rapor dersleri, ekip kuralları. Resmî bir onay süreci yok, ama bir kuralımız var: bir ders yazılmadan önce kaynakta doğrulanır, eskiyen ders düzeltilir ya da silinir.

Neyi Claude'a bırakmıyoruz

Beş ayın sonunda sınırlarımız da netleşti:

  • Derleme, veritabanı senkronizasyonu ve test insan eliyle yapılıyor.
  • Kaynak denetimine check-in ve canlıya alma ekibin kararı.
  • Canlı sisteme yazma yetkisi yok. Canlıya yalnızca okumak için, gerektiğinde bakılıyor.

Bunlar teknik zorunluluktan çok güven meselesi. Müşterimizin canlı sistemi bizim sorumluluğumuzda. Bu sorumluluğu bir araca devretmek istemiyoruz.

Bir şeyi ölçmedik

Bu yazıda bilerek bir rakam vermedik: "Yüzde şu kadar hızlandık." Ölçmedik. Hissimiz var, ama hissi rakam gibi sunmak doğru olmaz. Bundan sonraki işlerde ölçmeye başlayacağız; anlamlı bir şey çıkarsa onu da yazacağız.

Şimdilik söyleyebileceğimiz şu: Claude iyi bir başlangıç noktası değil, iyi bir çalışma arkadaşı. Ama ancak doğru bilgiyle beslediğinizde ve kurallarını sizin koyduğunuz bir düzende.

Dynamics projenizi konuşalım.

Claude ile nasıl çalıştığımızı sizin sisteminiz üzerinden anlatalım.

Yöntemimiz