Yapay zekâ

Yapay zekâ ile yazılım geliştirme hakkında RAG, MCP ve Skills tartışmaları bize ne söylüyor?

GitHub Blog’daki bir yazı, yapay zekâ ile yazılım geliştirme hakkında yaygın beş varsayımı inceliyor ve üretilen kodun gözden geçirilmesi, bilgi erişimi, MCP ve Skills’in birbiriyle rekabet eden alternatifler değil, farklı roller üstlenen araçlar olduğunu vurguluyor. Sonuç olarak insan muhakemesi ve kodun sürdürülebilirliği belirleyici faktörler olmaya devam ediyor.

2026-09-18
4 dk okuma
1 görüntülenme
فريق تحرير certi.news
Yapay zekâ ile yazılım geliştirme hakkında RAG, MCP ve Skills tartışmaları bize ne söylüyor?

GitHub Blog’da yayımlanan bir yazı, yazılım geliştirmede yapay zekâ kullanımına ilişkin, üretilen kodun okunmasına gerek olmadığı, RAG’in sona erdiği ve Skills’in Model Context Protocol’ü (MCP) ortadan kaldırdığı gibi beş yaygın varsayımı ele alıyor. Yazara göre bu ifadelerin değeri, kısa biçimleriyle doğru olup olmamalarında değil, gerçek işlere uygulandıklarında geçerli oldukları koşulları ve sınırları ayrıştırmakta yatıyor.

Kodun sorumluluğu modele devredilmez

Makalede öne sürülen temel kural, geliştiricinin sonucu açıklayabildiği ve sorumluluğunu üstlenebildiği noktaya kadar kodu gözden geçirmesi gerektiğidir. Bu, her satırın aynı derinlikte incelenmesi gerektiği anlamına gelmez; üretim sistemindeki bir kimlik doğrulama değişikliği, basit bir CSS denemesinden farklı bir incelemeyi hak eder.

İnceleme, temsilci herhangi bir kod yazmadan önce, mevcut uygulamayı anlayarak, bağımlılıkları ve uç durumları belirleyerek ve bir plan oluşturarak başlayabilir. Diğer durumlarda ise üretilen kodun hata işleme, yetkilendirmeler, verilere erişim, performans, erişilebilirlik ve testler açısından doğrudan denetlenmesi gerekir. Makaleye göre yapay zekâ, çabanın yerini değiştirir; ancak çalışmanın kendisini ortadan kaldırmaz.

En önemli beceri sağduyulu değerlendirmedir

Yazı, şirketlerin yapay zekâyı hiç kullanmayan kişileri işe almayacağı fikrini reddediyor; ancak giderek daha fazla çalışma ekibinin adaylara bu araçları nasıl kullandıklarını sorduğunu kabul ediyor. Yaklaşıma göre en güçlü gösterge, araca duyulan heyecanın kendisi değil, geliştiricinin onu ne zaman kullandığını ve ne zaman elle çalıştığını, çıktıları nasıl gözden geçirdiğini ve hız, kalite, güvenlik ve sürdürülebilirlik arasında nasıl denge kurduğunu açıklayabilmesidir.

Yapay zekâdan kaçınmak, ürününü geliştiren veya ona yoğun biçimde dayanan bir şirkette engel hâline gelebilir; ancak ona tamamen güvenmek daha iyi bir çözüm değildir. Gereken, insanı döngünün içinde tutmak ve geliştiricinin neye güvenip neye güvenmediğine dair açık bir açıklamaya sahip olmaktır.

MCP, Skills ve RAG tamamlayıcı rollere sahiptir

Makale bu üç araç arasında bir ayrım yapıyor. MCP, temsilcilerin araçlara ve verilere erişip bunları çağırması için standart bir yöntem sağlarken Skills, ekibin çalışma biçimi, projeyi değiştirme kuralları veya kullanılan teamüller hakkında paketlenmiş bilgi sunar. Skills çoğunlukla Markdown biçiminde yazıldığı için insan tarafından okunabilir olması da faydasının bir parçasıdır.

RAG veya erişimle güçlendirilmiş üretim ise modelin eğitim verileri dışında kalan belgeler, destek kayıtları, ürün ayrıntıları, kurum içi bilgi ve kod tabanının bağlamı gibi ilgili bilgileri sisteme getirir. İyi bir erişim, modelin çalışmaya yanıta daha yakın bir bağlamdan başlamasına yardımcı olur; arama alanını ve eksik yanıt verme olasılığını azaltır.

Bu nedenle yazar, Skills’in MCP’yi öldürdüğünü veya RAG’in öldüğünü düşünmüyor; temsilci bir araca erişmek için MCP’yi kullanabilir, projeye özgü talimatları uygulamak için bir Skill’i izleyebilir ve destekleyici bağlamı getirmek için erişimden yararlanabilir. Bu bileşenler arasındaki anlaşmazlık, tek bir iş akışında nasıl bütünleşebileceklerini göz ardı eder.

Sürdürülebilirlik yeni bir sınavdan geçiyor

Yazı ayrıca, modeli belirli bir kod tabanı üzerinde eğitme ihtiyacının zorunlu olarak kodun kötü olduğu anlamına geldiği fikrini de ele alıyor. Özel eğitim için geçerli nedenler vardır; ancak modelin kod tabanını anlayamaması, yeni bir ekip arkadaşının da karşılaşacağı bir sorunu ortaya çıkarabilir.

Açık yapı, tutarlı adlandırma, okunabilir testler, yararlı soyutlamalar ve güncel belgeler, kodu hem temsilcilerin hem de insanların anlamasını kolaylaştırır. Buradaki editoryal çıkarım, yapay zekâ araçlarının ekipleri yazılım mühendisliği uygulamalarından muaf tutmadığı; aksine sürdürülebilirlik kusurlarını daha görünür hâle getirebileceğidir.

Tartışmadan deneye

Makale, her görüşü karşıt bir görüşle değiştirmek yerine fikirlerin pratikte test edilmesi çağrısıyla sona eriyor. Katkıda bulunanların projeyi iyileştirerek pollen adlı krediler kazanabildiği Pollinations AI projesine ve kuşları dinleyen, ziyaretlerini mikrofon, Raspberry Pi, üç boyutlu yazdırılmış bileşenler ve üretilmiş görseller kullanarak değişen tablolara dönüştüren elektronik mürekkepli bir ekranı belgeleyen Avian Visitors projesine atıfta bulunuyor.

Bu projeler yapay zekâ hakkındaki tüm tartışmaları çözüme kavuşturmuyor; ancak kanıt üretiyor ve ödünleşimleri ortaya çıkarıyor. Metindeki temel sınırlama ise belirli bir iş akışının üstünlüğünü kanıtlayan karşılaştırmalı ölçüm sonuçları değil, genel bir rehber çerçeve ve örnekler sunmasıdır. Bu nedenle önerileri nihai kurallar olarak değil, uygulama için test noktaları olarak ele almak gerekir.

Haber kaynağı
ف
Yazar

فريق تحرير certi.news

Aynı kategoride

Bunlar da ilginizi çekebilir

Tüm haberleri gör