Dışarıdan bakınca bir AI kurulumu bir model ve bir eklentiden ibaret görünüyor. Yöneticilere de genellikle böyle anlatılıyor. Benim kurduğum her ortamda ise dört ayrı katman çıktı. En önemlisi her seferinde en sona kaldı: İlk üçü olmadan hiçbir şey çalışmıyor, ama dördüncüsü olmadan ajanın neye dokunduğunu kimse bilmiyor.
Birinci bölümde sistemi üç parça olarak anlattım: geçit, kural kitabı, bağımsız kontrol. O üç parça bu dört katmanın üstüne oturuyor. Bağımsız kontrol de doğrudan dördüncü katmandan besleniyor.
Bu bölümde her katmanda hangi seçenekler olduğunu, neyi seçtiğimi ve neyi bilerek seçmediğimi anlatacağım. Sonda da sıfırdan başlayan bir ekip için kurulum önerim var.
Birinci katman: model
En görünür katman bu ve ironik biçimde en az kritik olanı. “Model nerede, hangi model, hangi donanımda?” sorusunun üç cevabı var:
- Bulutta sınır modeller. Kalite en yüksek, ama kod dışarı çıkıyor.
- Satıcının modeli sizin veri merkezinizde. 2026’da yeni açılan ama henüz dar bir kapı. OpenAI, Mayıs’ta Codex’i kurum içine taşımak için Dell ile ortaklık duyurdu, ayrıntılar netleşmedi; Anthropic’in kamuya açık bir kurum içi ürünü yok. Kalite yüksek, kontrol kısmi, maliyet yüksek.
- Açık ağırlıklı modeller kendi donanımınızda. Kontrol tam, ama kalite bir iki nesil geride ve operasyon yükü tamamen sizde.
Kod kısıtınız kesinse açık modelle başlıyorsunuz; başka yolu yok. Ama tek modelle değil. İş türüne göre birkaç model gerekiyor: kod tamamlama için küçük ve hızlı bir model, muhakeme için büyük bir model, bağlam araması için ayrı bir embedding modeli.
Bunu baştan planlamak zor, çünkü ihtiyaç kullanımdan çıkıyor. Genelde tek modelle başlanıyor. Bir ay sonra küçük işlerde gecikme, büyük işlerde kalite şikâyeti geliyor ve çeşitlendirme o şikâyetlerden doğuyor.
Bilerek seçmediğim şey kendi modelimi ince ayarlamak oldu. “Bankanın kodunu öğrensin” fikri her toplantıda gündeme geliyor ve kulağa çok iyi geliyor. Pratikte ise veri hazırlığı, sürüm takibi ve bakım küçük bir ekibin taşıyamayacağı bir yük. Üstelik kurum bilgisini modele bir kere öğretmek yerine her istekte ona taşımak, yani üçüncü katmanı kurmak, hem daha ucuz hem her zaman güncel.
İkinci katman: geliştirici arayüzü
Geliştiricinin modelle konuştuğu yer: IDE eklentisi, terminal ajanı ya da web arayüzü. Bu katmanın asıl işi kullanıcı deneyimi değil, neyin modele gittiğini belirlemek. Üç seçenek var:
- Hazır ticari eklentiler. Bağlam toplama mantığı satıcıya ait, sizin kontrolünüz sınırlı.
- Açık kaynak eklentiler. Yerel modele bağlanıyor, daha fazla kontrol veriyor, ama kalitesi değişken.
- Kendi eklentiniz. Kontrol tamamen sizde, geliştirme maliyeti de.
Ben .NET ağırlıklı, onlarca solution’dan oluşan bir bankacılık tabanında kendi Visual Studio eklentimi yazmak zorunda kaldım. Hazır olanlar ya yerel modele bağlanmıyordu ya da bağlam toplarken repo’nun yarısını modele gönderiyordu. Kendi eklentimde hangi dosyanın bağlama gireceğini, hangi dizinin hiç okunmayacağını ve her isteğin nasıl loglanacağını ben belirledim. Bu, sonradan geçidi kurarken de işimi kolaylaştırdı.
Bu katmanda 2026’da öğrenilen bir şey daha var: Ajanın okuduğu yapılandırma dosyaları artık bir saldırı yüzeyi. CLAUDE.md, .claude/settings.json, hook tanımları, .mcp.json. Birinci bölümde saydığım CVE’lerin çoğu bu dosyalar üzerinden geldi: proje açılır açılmaz çalışan hook’lar, trust diyaloğu çıkmadan geçerli olan izin ayarları. LayerX de Nisan 2026’da, bir repo’daki CLAUDE.md’ye sessizce eklenen talimatın projeyi klonlayan herkese fark edilmeden geçtiğini gösterdi.
Mesele yalnızca yapılandırma dosyaları da değil. Ajanın okuduğu her metin, bir README, bir issue açıklaması, bir bağımlılığın dokümanı, talimat taşıyabilir. Birinci bölümdeki sandbox aşımlarının tetikleyicisi de buydu.
Dolayısıyla bu katmanın sorusu artık yalnızca “bağlama ne giriyor?” değil, “ajan hangi dosyadan talimat alıyor?” Cevap net: Bu dosyalar kod gibi review edilir, admin’e aittir ve ajan onları değiştiremez.
Seçmediğim şey ise her geliştiriciye kendi aracını seçme serbestisi vermek. Esnek görünüyor ama yönetilmiyor: Beş eklenti, beş bağlam politikası ve beş log formatı demek. Araç çeşitliliği olabilir, beşinci bölümde nasıl olacağını anlatacağım, ama her aracın geçitten geçmesi şartıyla.
Üçüncü katman: bağlam
Model kurumunuzu tanımıyor. İş kurallarını, isimlendirmeleri, “burada bunu neden böyle yapıyoruz”u bilmiyor. Bağlam katmanı bu bilgiyi her istekte modele taşıyor. Yaygın adı RAG: Dokümanlar parçalanıyor, embedding modeliyle indeksleniyor, istek gelince ilgili parçalar bulunup prompt’a ekleniyor.
Bende işe yarayan üç kaynak oldu: teknik analiz dokümanları, koddaki açıklamalar ve regülasyon özetleri. Bir yere kadar işe yarıyor. Model bankanın bir ürününü nasıl adlandırdığını öğreniyor, ama bir metodu değiştirince hangi gün sonu işinin bozulacağını öğrenemiyor. Çünkü RAG metin buluyor, yapıyı anlamıyor. Dördüncü katmanı zorunlu kılan sınır bu.
Seçmediğim şey her şeyi indekslemek oldu: mail arşivi, toplantı notları, eski dokümanlar. Gürültü arttıkça modelin “ilgili” diye bulduğu parçalar yanıltmaya başlıyor. Az ama güncel kaynak, çok ama bayat kaynaktan her zaman iyi.
Bir de bakım meselesi var. Dokümanlar değişiyor; indeks güncellenmezse model eski bilgiyle özgüvenle cevap veriyor. Sahibi olmayan bir RAG altı ay içinde zarar vermeye başlıyor. Bunun bende nasıl olduğunu yedinci bölümde anlatacağım.
Bu katmana yatırımın modele yatırımdan daha etkili olduğunu sektör verisi de söylüyor. Stack Overflow’un Ekim 2026’da yayımlanan anketinde geliştiriciler en güvenilir bağlam kaynağı olarak %85 ile proje hedeflerini ve gereksinimleri gösterdi. Faros’un 22 bin geliştiricilik telemetri raporu da kalitenin sonradan değil, kodun yazıldığı aşamada ele alınması gerektiğini savunuyor. Yani modeli değiştirmeden verimi en çok artıran şey, modele ne verdiğiniz.
Dördüncü katman: sistem anlama
Çoğu kurulumda bu katman yok ve çoğu başarısızlığın sebebi de bu. Bankacılık ya da sigorta yazılımı gibi onlarca solution’dan oluşan sistemlerde bir değişiklik, üç solution ötedeki gün sonu sürecini kırabiliyor. Bu yapıyı anlamadan ajanı koda dokundurmak kumar.
Sistem anlama katmanı, kodun kendisinden çıkarılmış bir graf: Hangi sınıf hangi servisi çağırıyor, hangi tablo hangi toplu işte okunuyor, bir metot değişince hangi uç noktalar etkileniyor.
Graf modele bağlam olarak da veriliyor, ama asıl değeri başka yerde: Etki analizi modelin tahminine değil, grafa dayanıyor. Birinci bölümde “bağımsız kontrol” dediğim şey burası.
Seçmediğim şey, bunu modelin kendi kendine yapmasını beklemek. “Bütün repo’yu ver, o anlar” deniyor. Ama çok solution’lı bir sistemde kod ne pencereye sığıyor, ne de sığsa sonuç güvenilir oluyor. Grafın nasıl kurulduğunu üçüncü bölümde anlatacağım.
Hangisi olmadan başlanır
Dört katmanı birden kurmak altı aylık iş, o yüzden sıra önemli.
- Birinci ve ikinci katman olmadan başlanmıyor. Bir yerel model ve kontrol edebildiğiniz bir arayüz, açık kaynak bir eklentiyle ilk haftada çalışır.
- Üçüncü katmanı ikinci aya bırakın. İlk ay kullanıcıların ne sorduğunu izleyip indeksi o sorulara göre kurmak, “her şeyi indeksle” diye başlamaktan çok daha iyi sonuç veriyor.
- Dördüncü katman çok solution’lı sistemde şart, tek repo’da lüks. Tek bir monorepo’nuz varsa modelin bağlam penceresi bir süre idare eder. Ama on solution’ınız ve gün sonu süreçleriniz varsa, graf olmadan ajanı üretim koduna dokundurmayın.
Dördü de çalışırken fark ettiğim bir şey oldu: Her katmandan iz çıkıyordu, ama izler ayrı yerlerde duruyordu. Hangi kullanıcının hangi modele ne gönderdiğini tek bir yerden göremiyordum. Altıncı bölümdeki geçidin hikâyesi tam olarak oradan başlıyor.
Başlangıç için bir kurulum
Aşağıdaki öneriler yaklaşık 50 geliştiricili, orta ölçekli bir .NET ekibi düşünülerek yazıldı. Donanım ve modeller birkaç ayda bir değişiyor; rakamlardan çok arkalarındaki mantığa bakınız.
Donanım. Bu alan her çeyrek değişiyor, o yüzden kart modeli saymak yerine nasıl düşündüğümü anlatayım. İlk karar bir mi, iki mi GPU. Ekip için veri merkezi sınıfında iki kart öneririm: biri büyük muhakeme modeline, diğeri kod tamamlamaya ve embedding’e. Böylece biri uzun bir analizle meşgulken diğerinde satır tamamlama yavaşlamıyor. Tek kartla başlayacaksanız muhakeme modelini orta boyda tutun; büyük modeller ağırlıklarıyla belleğin önemli bir kısmını kaplıyor ve uzun bağlamlı isteklere az yer kalıyor. Kaç kişiyi taşıyacağınızı da model boyutundan çok, aynı anda kaç uzun isteğin açık olduğu belirliyor. Tüketici kartları prototip için iyi, ekip için yetmiyor.
Model sunumu. Ollama ile başlamak kolay; birkaç kişiyle denemek için ideal. Kullanıcı sayısı artıp istekler üst üste binmeye başladığında vLLM gibi eşzamanlılık için tasarlanmış bir sunucuya geçmek gerekiyor. Model seçerken aklınızda tutmanız gereken şey iş türü. Satır tamamlama küçük ve hızlı bir model ister, çünkü geliştirici birkaç saniyeden fazla beklemez. Analiz ve doküman işleri büyük bir model ve uzun bağlam ister, ama orada gecikme o kadar önemli değil; bir analiz dokümanı için bir dakika beklemek kimseyi rahatsız etmiyor. Embedding için küçük ve çok dilli bir model yeter; Türkçe dokümanınız varsa çok dilli olması şart. Bugün hangi modelin en iyisi olduğu ise birkaç ayda bir değişiyor. O yüzden mimariyi, modeli değiştirmek bir ayar değişikliği olacak şekilde kurun.
Geliştirici arayüzü. İlk gün için açık kaynak bir IDE eklentisi yeterli. Önemli olan onu yerel sunucunuza bağlamak ve neyi okuyacağını daraltmak. Bağlamı başta yalnızca açık dosya ve geliştiricinin seçtiği dizinle sınırlamanızı öneririm. Kulağa kısıtlayıcı geliyor, ama hangi dosyanın modele gittiğini kesin olarak bilmenin en kolay yolu bu; sonradan genişletmek, sonradan daraltmaktan her zaman kolay. Ekip olgunlaştıkça iki yol açılıyor: ya kendi eklentinizi yazarsınız ya da hazır bir aracı yönetimli ayarlarıyla kullanırsınız. Hangisini seçerseniz seçin, araç geçidin arkasında durmalı.
Bağlam katmanı. Vektör veritabanı için yeni bir şey kurmanız gerekmeyebilir: Zaten PostgreSQL kullanıyorsanız pgvector işinizi görür, yoksa Qdrant iyi bir başlangıç. Asıl karar araçta değil, indekse ne koyduğunuzda. İlk indekse sadece teknik analiz dokümanlarını ve kod açıklamalarını koymanız yeterli. Neyin eksik olduğunu kullanıcıların sorduğu sorular size zaten söyleyecek. Bir de indeksi haftada bir yenileyin ve ona bir sahip verin; sahibi olmayan bir indeksin nasıl çürüdüğünü yedinci bölümde anlatacağım.
Sistem anlama. Grafı çıkarırken derleyicinin kendisinden yararlanın: .NET’te Roslyn, Java’da benzer analizörler. Böylece metin eşleştirmesiyle değil, kodun gerçekte neyi çağırdığıyla çalışırsınız. Başlangıçta grafı saklamak için ayrı bir veritabanına da gerek yok; küçük bir sistemde ilişkisel bir tablodaki kenar listesi yetiyor. Solution ve bağlantı sayısı büyüdükçe Neo4j sorguları kolaylaştırıyor. Grafı bir MCP sunucusu olarak açın ki hangi araç kullanılırsa kullanılsın aynı soruya aynı cevabı versin. O soruların neler olduğunu üçüncü bölümde anlatacağım.
Baştan konması gereken tek şey: log. Her isteğin logu: kullanıcı, model, bağlama giren dosyalar, token sayısı, süre. Geçit sonra gelir, ama log birinci günden olmalı. Yoksa yedinci bölümde anlatacağım “önce verisi yok” sorununu siz de yaşarsınız. Bir uyarı: Bu log’un kendisi de kod ve müşteri verisi içerir. Erişimini en az ajanın eriştiği veri kadar sıkı tutun.
Sıradaki bölüm araçlar: Regüle bir kurumun sorularıyla araç karşılaştırması ve hiçbir aracın yapmadığı iş, kod grafı.
Kaynaklar: Check Point Research ve Dark Reading (CVE-2025-59536, CVE-2026-21852, Şubat 2026); stack.watch (CVE-2026-33068); DevOps.com (LayerX, CLAUDE.md, 9 Nisan 2026); BleepingComputer (Pillar Security, 20 Temmuz 2026); OpenAI (Dell ortaklığı, 18 Mayıs 2026); Stack Overflow Developer Survey 2026 (6 Ekim 2026); Faros AI, AI Engineering Report Q2 2026 (22.000 geliştirici, 4.000 ekip).