Yazılım Süreçlerini Agent'larla Yarı Otonom Hale Getirmek — Deneyimlerim ve Kurduğum Sistem

Son dönemde geliştirme süreçlerimde yapay zeka ajanlarını yoğun şekilde kullanırken dikkatimi çeken bir problem vardı: tekrar eden ama detaylı anlatım gerektiren işler.

Bu görevleri her yaptırmak istediğimde yeni bir sohbet açıyor, uzun uzun bağlam veriyor ve aynı açıklamaları tekrar ediyordum. İş yaptırmak birkaç saniye sürerken, anlatmak dakikalar alıyordu.

Bu darboğaz beni agent skill mimarisi kurmaya itti.

Problemin Kaynağı: Prompt Tekrarı ve Bilgi Dağınıklığı

Agent'lar varsayılan olarak proje bağlamını bilmez. Onlara:

• proje mimarisini
• kodlama standartlarını
• commit kurallarını
• test stratejilerini
• naming convention'ları

her seferinde anlatmanız gerekir.

Başta çözüm olarak proje içine agent klasörleri koydum (.claude, .cursor vb.). Ancak bu yaklaşımın üç büyük problemi vardı:

• Her projede ayrı skill tanımlamak gerekiyordu
• Yeni geliştirici gelince dosyaları aktarmak gerekiyordu
• Skill'ler farklı projelerde farklı versiyonlara ayrılıyordu

Bu sürdürülebilir değildi.

Çözüm: Agent Skills'i MCP Tool'a Dönüştürmek

Bu problemi çözmek için agent-skills-mcp adını verdiğim bir yapı kurdum.

Buradaki fikir şuydu:

Skill'leri artık agent'ın lokal klasöründe tutmak yerine, MCP tool olarak sunmaya başladım. Bu tool'lar kod yazan fonksiyonlar değil, guide sağlayan fonksiyonlar.

Böylece:

• Agent yalnızca bir kez tanımlanıyor
• Tüm developer'lar aynı skill setini kullanıyor
• Skill güncellenince herkes otomatik güncel versiyona geçiyor

İkinci Problem: Projeler Arası Körlük

Agent'ların doğası gereği erişemedikleri bir şey daha vardı: diğer projeler.

Örneğin:

• UI geliştirirken başka projeden component almak
• Backend geliştirirken başka servisin API yapısını incelemek
• Ortak kütüphane kodunu referans almak

Agent bunları göremediği için her seferinde açıklamak gerekiyordu.

Çözüm: Filesystem MCP ile Kurumsal Kod Hafızası

Bu sorunu çözmek için tüm şirket projelerini tek root klasör altında topladım ve agent'lara filesystem MCP bağladım.

Ancak kritik nokta şu:

Bu sayede agent:

• bağımlı projeleri görebiliyor
• diğer servislerin kodunu okuyabiliyor
• gerektiğinde başka projeye kod yazabiliyor

Yani artık agent sadece bir repo bilen değil, organizasyon kod haritasını bilen bir varlık haline geliyor.

Üçüncü Aşama: Süreçleri IDE'den Çıkmadan Yönetmek

Bir sonraki adımda sistemin yalnızca kod yazan değil, iş yapan hale gelmesini istedim. Bunun için agent'ları şu sistemlere bağladım:

• Jira
• Slack
• Jenkins

Artık workflow şu şekilde işliyor:

• Jira'da görev oluşturuyorum
• Görev açıklamasına teknik detay + prompt ekliyorum
• Agent'a görevi veriyorum

1Jira'daki DEV-1234 görevini yap

Agent:

• görevi okuyor
• kodu yazıyor
• testleri çalıştırıyor

Sonra ben diyorum:

1Commit et, pushla ve test ortamına deploy al

Deploy başladıktan sonra:

• Slack'ten PO'ya haber ver

Bütün süreç IDE'den çıkmadan tamamlanıyor.

Ortaya Çıkan Sistem: Yarı Otonom Geliştirme

Kurulan mimariyle birlikte şunlar gerçekleşti:

• Tekrar eden prompt yazma ihtiyacı ortadan kalktı
• Kurumsal standartlar otomatik uygulandı
• Projeler arası bilgi bariyeri kalktı
• Operasyonel süreçler agent'a devredildi

Sonuç olarak yazılım süreci şu evrimi geçirdi:

• manuel
• destekli
• yarı otonom

En Kritik Kazanım

En büyük fark hız değil.

Artık kod:

• kişiye göre değil
• o anki moda göre değil
• deneyime göre değil
• tek bir merkezî akla göre yazılıyor

Bu da şunu sağlıyor:

Sonuç

Agent'ları yalnızca kod yazdıran araçlar olarak görmek büyük bir potansiyeli kaçırmak demek. Asıl sıçrama, onları organizasyonel hafızaya ve süreç motoruna dönüştürdüğünüzde başlıyor.

Bugün geldiğim noktada şunu net söyleyebilirim:

Ve bu daha başlangıç.