Bir ERP Projesini AI ile Nasıl Yönetiyorum: Çok Ajanlı Yazılım Geliştirme Metodolojisi

Giriş

Yirmi yılı aşan saha deneyimimde bir yazılım projesinin nasıl yavaşladığını, pahalıya patladığını, özel istekler karşısında esnekliğini yitirdiğini defalarca gördüm. Geleneksel model oldukça netti: uzun analiz, kalabalık geliştirme ekipleri, tek kişiye bağlı know‑how, aylarca süren iterasyonlar. Bir özellik ekletmek için bazen haftalarca beklemek gerekiyordu; çünkü kodu yazan kişi başka bir projede, test eden başka birinde, onay veren üçüncü kişi izindeydi.

Son bir yılda bu tabloyu baştan aşağı değiştiren yeni bir gerçek var: yapay zeka artık yalnızca “yardımcı araç” değil, aktif olarak kod üreten, bağımsız denetim yapan, mimari öneri veren bir katman haline geldi. Ama burada kritik bir soru var: AI’a kod yazdırmak yeterli mi, yoksa AI’ı yönetmek ayrı bir disiplin mi? Cevabımı bu yazıda paylaşacağım, çünkü bir ERP projesinin kendisini artık tek başıma değil, koordine ettiğim bir AI ekibiyle birlikte yönetiyorum.

AI Araçlarını Kullanmak mı, Yönetmek mi?

Aradaki fark, bir rolün “kullanıcı” olmakla “orkestra şefi” olmak arasındaki fark kadar büyük. ChatGPT’ye soru sorup çıkan cevabı kopyalamak bir AI kullanım biçimidir — evet değerlidir, ama bir projeyi baştan sona yürütmek için yeterli değildir. Çünkü tek bir AI modelinin neyi iyi, neyi kötü yaptığını, hangi aşamada yanıldığını, hangi görevi hangi modele vermeniz gerektiğini bilmeden sonuca ulaşamazsınız.

Ben AI’ı bir pipeline (iş hattı) gibi düşünüyorum: belirli bir sıra, içinde farklı uzmanlık alanlarına sahip ajanlar, her ajanın üretimini bir sonrakinin girdisine dönüştüren bir koordinasyon katmanı. Bu katmanın adı “insan mimar” — yani ben. Araç kullanmakla araçları koordine etmek arasındaki bu ayrım, bir projenin iki haftada mı yoksa sekiz ayda mı biteceğini belirleyen asıl kaynak.

Bir müşteri “AI ile kod yazdırıyormuşsunuz” dediğinde düzelttiğim nokta her seferinde aynı: hayır, birden fazla AI’ı aynı anda koordine ediyorum ve hiçbirinin çıktısını denetlemeden kabul etmiyorum. Bu kritik bir ayrım, çünkü projelerin kalite güvencesi bu koordinasyonun hangi özenle kurulduğuna bağlı.

Çok Ajanlı Pipeline: Nasıl Çalışıyor?

Bir ERP özelleştirme projesinde benim yürüttüğüm pipeline kabaca beş rolden oluşuyor; her birini farklı bir AI ya da insan üstleniyor.

Büyük bağlamlı dil modeli — projenin tüm kod tabanını, veritabanı şemasını, mevcut entegrasyonları bir bütün olarak okuyor. Yüz binlerce satırlık kodu aynı anda “görebilen” bu katman olmadan bir sistemin mevcut durumunu çıkarmak imkânsız. Bunu topoloji raporu çıkarmak, bağımlılıkları haritalamak, tekrar eden desenleri bulmak için kullanıyorum.

Mimari danışman AI — üst düzey kararları aldığım katman. Bir fonksiyonu nereye yazmalı, hangi ortak servisten yararlanmalı, hangi tasarım deseni geçerli olmalı, teknik standart nasıl belirlenmeli? Bu sorular benim için en önemli. Aynı zamanda bir sonraki ajana verilecek talimatları — yani prompt‘ları — bu katmanda tasarlıyorum.

Geliştirme AI — asıl kod yazımını yapan ajan. Mimari danışmanın ürettiği spesifikasyonlara göre dosyalar oluşturuyor, mevcut kodu değiştiriyor, iterasyon yapıyor. Burada insan müdahalesi en az; ama üretilen her şey bir sonraki aşamaya geçmeden denetleniyor.

Denetim AI — pipeline’ın kalite sigortası. Üretilen kodu bağımsız bir gözle okuyor, güvenlik zafiyetleri arıyor, iş mantığı hatalarını kontrol ediyor, iş kurallarının ihlal edildiği yerleri raporluyor. Kodu yazan ajan aynı kodu denetleyemez — denetim her zaman ikinci bir gözle yapılır.

İnsan mimar (ben) — pipeline’ın kendisini yöneten katman. Hangi görevi hangi AI’a vereceğime, hangi çıktının kabul edilebilir olduğuna, hangi kararın canlı ortama (prod) çıkarılacağına ben karar veriyorum. Müşteriye karşı sorumluluk tamamen bende, çünkü araçların hiçbiri iş bağlamını benim kadar bilmiyor.

İnsan Mimarın Rolü Neden Kritik?

AI, kod yazmak konusunda şaşırtıcı derecede iyi. Ama şu beş şeyi hâlâ yapamıyor:

İş gereksinimini anlamak. Bir müşterinin “depoyu sıkıştırmak istiyoruz” dediğinde gerçekte neyi kastettiğini anlamak için yüzlerce benzer projenin bağlamına sahip olmak gerekiyor. AI bu bağlamı kendi başına inşa edemez; ben yıllar içinde inşa ettim ve bu bilgiyi pipeline’a taşıyan ben oluyorum.

Mimari tradeoff kararı vermek. Her teknik tercihin bir bedeli var: hız karşısında esneklik, standart karşısında özelleştirme, kısa vade karşısında uzun vade. Bu dengeleri müşterinin öncelikleriyle eşleştirmek bir mimar kararıdır, bir model tahmini değil.

Canlı ortama geçiş onayı vermek. Üretim ortamına geçiş her zaman bir sorumluluk taşır. Bir şey ters giderse hesap vermek gereken kişi bir AI değil, benim. Bu yüzden onay her zaman insanda kalıyor.

Müşteriye karşı sorumluluk almak. İş ilişkisi güven üzerine kuruludur. Müşteri bir AI’ın çıktısına değil, benim onayladığım bir çözüme güveniyor.

Araçlar arasında doğru görevi dağıtmak. Hangi AI hangi görevde iyi, hangi aşamada hangi modelin yanıldığı, hangi kombinasyonun en verimli sonucu verdiği — bu bilgi uzun süre pipeline’ı yürüten birinde birikiyor ve pipeline yöneticisinin asıl uzmanlık alanı haline geliyor.

Kalite Güvencesi: Her Satır Denetleniyor

Geleneksel yazılım projelerinde code review — yani yazılan kodun başka bir geliştirici tarafından okunup kontrol edilmesi — çoğu zaman isteğe bağlı kalır. Ekip küçükse, takvim sıkışsa, öncelikler değişse bu adım atlanır. Oysa benim metodolojimde bu seçenek yok: her fonksiyon, her değişiklik, her yeni dosya bağımsız bir AI denetiminden geçiyor. Üstelik bu denetim raporu satır referanslarıyla geliyor, yani hangi satırda ne tür bir sorun görüldüğü net bir şekilde belgeleniyor.

Bu, hatanın canlı sisteme ulaşmasını engelliyor. Bir güvenlik zafiyeti, yanlış iş kuralı ya da gereksiz kod tekrarı sistemi terk etmeden yakalanıyor. Bu benim için bir bonus değil, metodolojinin temel taşı — çünkü bir ERP sistemi kritik iş süreçlerini yürütüyor ve bu sistemlerde en küçük hata bile üretimi durdurabilir.

Hangi Projelere Uygun?

Bu çok ajanlı pipeline yaklaşımı bazı senaryolarda açık farkla öne çıkıyor:

• ERP üzerine özel modül geliştirme — hazır bir platformu iş ihtiyaçlarınıza göre genişletmek istediğinizde, klasik ekiplerin aylar sürdürdüğü işler hafta bazına iniyor.
• Depo, üretim ve kalite ekranları — operasyonel süreçlere özel ara yüzler, hızlı iterasyon isteyen alanlar için biçilmiş kaftan.
• Mevcut sisteme entegrasyon — iki farklı sistemin konuşmasını sağlamak için köprü kod yazmak AI destekli pipeline’ın en güçlü olduğu yerlerden biri.
• Air‑gap / kapalı ağ ortamları — internet erişimi olmayan, özel güvenlik gerektiren ortamlarda bile pipeline’ın belirli parçaları çevrimdışı çalışabiliyor.
• Savunma sanayi dahil kritik sektörler — en yüksek denetim disiplinini gerektiren alanlar; paradoksal olarak burada çok ajanlı AI en fazla değer üretiyor çünkü her çıktı zaten bağımsız denetime tabi.

Sonuç ve Çağrı

Bu metodoloji yazılım geliştirmeyi demokratikleştiriyor. Eskiden bir KOBİ’nin kurumsal kalitede özel bir yazılım için on kişilik ekip kurması, altı ay beklemesi ve büyük bir bütçe ayırması gerekiyordu. Şimdi birkaç hafta içinde aynı kaliteyi üretmek mümkün. Ama lütfen yanlış anlaşılmasın: bu “AI’a bırak, kendini yazar” demek değil. Doğru mimarinin koordinasyonunu, doğru kararların alınmasını, doğru denetim disiplininin kurulmasını gerektiren bir yaklaşım.

Bir ERP projeniz varsa ve bu yöntemle çözülebilecek gibi görünüyorsa, benimle bir keşif görüşmesi yapalım. Sistemi, ihtiyacı, beklentileri konuşalım — gerçekten uygunsa beraber yol haritası çıkaralım.