Yerel AI Kodlama Ajanları: Akıllı Sistemlerin Aptalca Başarısızlıkları

Bazen bir yapay zeka sisteminin, beceriksizce bir hata yüzünden çökmesini izlemek tarif edilmez bir hayal kırıklığı. Geçenlerde tam da bunu yaşadım—yerel AI kodlama ajanlarıyla uğraşırken. Açık ağırlıklı modellerin yeteneklerinin artması ve gizlilik odaklı geliştirme anlayışının güçlenmesiyle birlikte bu alan hızla büyüyor.

Deney basitti aslında: Tamamen yerel donanımda çalışan bir kodlama ajanı, gerçekten işlevsel bir oyun yapabilir miydi? Yani üç satırlık bir demo değil; gerçek state yönetimi, render mantığı, input işleme ve oynanabilir bir arayüz isteyen bir proje. Cevap, epey kafa yorduktan sonra "evet" oldu—ama bu noktaya ulaşmak, AI araç ekosistemindeki ciddi bir sorun sınıfını gözler önüne serdi.

Sorunsuz Çalışması Gereken Kurulum

Sistem üç temel bileşenden oluşuyordu: OpenAI uyumlu API sunan Ollama, Qwen3.8 27B modeli ve provider-agnostic bir kodlama ajanı CLI'sı. 32GB unified memory üzerinde 17GB'lık 27B model—bu donanım konfigürasyonu hafife alınacak cinsten değil. Model, araç çağrısı yapabiliyor ve mantıklı muhakeme yetenekleri sunuyordu.

İlk sonuçlar umut vericiydi. On beş dakikada ajan, tamamlanmış bir HTML yapısı ve neredeyse 200 satırlık NES temalı CSS üretmişti—greson kabinet stilleri, doğru renk paleti dahil. Daha da etkileyici olanı, ajanın kendi hatasını yakalamasıydı: Bir dosya yazdı, sonra okudu, niyetlettiği şey ile diskteki şey arasında bir uyumsuzluk gördü ve kimse söylemeden düzeltti. Bu gerçek bir ajan davranışıydı ve modelin üstesinden gelebileceğini düşündürdü.

Ta ki ajan oyun mantığı dosyasını yazmaya çalışana kadar—ve her şey durdu.

Çıkmaza Giren Süreç

Ardından gelen sahne, AI araçlarıyla boğuşmuş herkesin tanıyacağı bir döngüydü. Oyun motoru dosyasını yazma girişimleri art arda on üç kez yarıda kesildi. Stream düzgünce öldü—ne hata mesajı, ne açıklama, ne de kullanılabilir bir çıktı.

En sinir bozucu olan şey başarısızlığın kendisi değildi; ajanın muhakeme sürecini izlemekti. Her deneme sıfırdan başladığı için, model aynı tasarım kararlarını baştan türetiyor ve her seferinde farklı scoring tablolarıyla farklı implementasyon yaklaşımlarına varıyordu. Üç deneme, aynı mimari soruya üç farklı cevap demekti. Ajan bir saat düşünüyor ama bunların hiçbirini kullanamıyordu.

Bariz suçlu bellek baskısı gibi görünüyordu. Tarayıcı sekmelerini kapatınca birkaç gigabayt RAM boşaldı ve işler biraz düzeldi—bu da teşhisi doğruluyor gibiydi. Ama yanlış ders çıkarılıyordu.

Logların Gerçeği

Sunucu loglarını tekrar inceleyince bambaşka bir tablo ortaya çıktı. Tek bir out-of-memory hatası bile yoktu. Sistemdeki boş bellek 21 ile 27 gigabayt arasında rahatça seyrediyordu—17 gigabaytlık model ağırlığına karşı. Bellek hiçbir zaman sorun olmamıştı.

Asıl sorun, görünür bir hata üretmeyen bir yapılandırma uyumsuzluğuydu. Ajanın konfigürasyonu 32.768 token'lık bir context window reklam ediyordu. Ama Ollama sunucusu 8.192 token tavanıyla yeniden başlatılmıştı ve bu fark ortaya çıkmamıştı. Ajan, 800 satırlık bir dosyayı tek seferde yazmayı planlayabiliyordu—çünkü 32k yer olduğunu biliyordu. Üretim gerçekte 8k duvarına çarpınca, bağlantı sessizce kesiliyordu. Ajanın reason edebileceği hiçbir hata mesajı yoktu.

Bir yan komplikasyon daha gizleniyordu başlangıç loglarında: Ollama, context shifting açıkken başlatılmıştı—bu özellik yer kalmayınca pencerenin kaymasına, eski tokenların yeni tokenlara yer açmak için feda edilmesine izin verirdi. Ama modelin mimarisi bu özelliği desteklemiyordu, bu yüzden sessizce devre dışı kalmıştı. Yumuşak bir limit olması gerekirken, katı bir duvar olmuştu.

AI Geliştirmenin Talep Ettiği DevOps Disiplini

Bu deneyim, açık ağırlıklı modeller etrafındaki coşkuyla göz ardı edilen kritik bir gerçeği netleştirdi. Modelleri kendi donanımınızda çalıştırdığınızda, sadece kod yazmıyorsunuz—altyapı işletiyorsunuz. Ve altyapı, üretim sistemlerinin talep ettiği aynı tanısal disiplini, yapılandırma yönetimini ve operasyonel parametre takibini gerektiriyor.

Context window'lar unutulup giden soyut model özellikleri değil. Araç zincirinizle beklenmedik şekillerde etkileşen operasyonel parametreler. Ajanın yapılandırılmış context'i sunucunun gerçek tavanıyla uyuşmadığında, uyarı almıyorsunuz—modelin yetersizliği gibi görünen ama aslında operasyonel yanlış yapılandırma olan sessiz arızalarla karşılaşıyorsunuz.

Yerel AI kodlama ajanlarını keşfeden geliştiriciler için pratik öneri açık: Ortamınızı bir üretim deployment'ı kadar titizlikle doğrulayın. Ajanın yapılandırmasının runtime parametreleriyle eşleştiğinden emin olun. Sunucu loglarını okuyun, ajan çıktısına bakmayın. Model mimarinizin hangi özellikleri gerçekten desteklediğini, araçların hangilerini etkinleştirmeye çalıştığını anlayın.

Modeller gelişiyor. Araçlar olgunlaşıyor. Ama "demolarda çalışıyor" ile "günlük kullanımda güvenilir çalışıyor" arasındaki boşluk, hala insan muhakemesi gerektiriyor—ve bu muhakeme, yeni bir altyapı sınıfına uygulanan geleneksel DevOps disiplinine benziyor.

Tetris build'i sonunda başardı. İki günde dört buçuk saat sürdü, üç dosyada temiz kod üretti ve düzgün çalışıyor. Ama dersler başarıdan değil, başarısızlıkların neden gerçekleştiğini anlamaktan geldi—ve bazen en pahalı sorunların zekayla hiçbir ilgisi olmadığını kabul etmekten.