Vibe Coding’de Bağlam Mühendisliği: Context Rot Nasıl Önlenir?

Vibe coding bağlam mühendisliği, yapay zekâ ajanına yalnızca iyi bir istem yazmak değil; doğru anda doğru proje bilgisini sağlayıp gereksiz gürültüyü dışarıda bırakmaktır. Bir AI kodlama aracı güçlü olabilir, fakat hangi dosyanın gerçek veri kaynağı olduğunu, neden belirli bir mimarinin seçildiğini veya hangi testin kritik davranışı koruduğunu kendiliğinden bilemez.

İlk birkaç istem başarılı giderken uzun oturumlarda modelin önceki kararları unutması, aynı bileşeni yeniden oluşturması veya artık geçerli olmayan bir varsayımla kod yazması sık görülür. Bu durum çoğu zaman model yetersizliğinden değil, bağlamın kötü yönetilmesinden kaynaklanır. Çözüm daha uzun prompt değil; daha seçici, güncel ve yapılandırılmış context’tir.

Bağlam mühendisliği nedir?

Prompt mühendisliği, modele verdiğiniz talimatın nasıl yazıldığıyla ilgilenir. Bağlam mühendisliği ise modelin o talimatı işlerken görebildiği bütün bilgi ortamını düzenler:

Sistem ve proje yönergeleri
Görev tanımı ve kabul ölçütleri
İlgili kaynak kodu ve mimari belgeler
Önceki konuşmalar ve alınan kararlar
Test sonuçları, hata mesajları ve çalışma zamanı günlükleri
Kullanılabilen araçlar ve bunların çıktıları

Başka bir ifadeyle prompt tek bir mesajdır; context ise modelin karar verirken içinde bulunduğu çalışma masasıdır. Masaya yalnızca gerekli belgeleri koyarsanız odak artar. Her dosyayı, bütün logları ve eski tartışmaları yığarsanız önemli sinyal gürültü içinde kaybolabilir.

Context rot nedir?

Context rot, konuşma veya görev uzadıkça bağlamın kalitesinin bozulmasıdır. Context penceresi tamamen dolmasa bile eski, tekrar eden veya birbiriyle çelişen bilgiler modelin dikkatini dağıtabilir.

Tipik bir context rot döngüsü şöyledir:

İlk görev ve mimari doğru biçimde açıklanır.
Model birkaç değişiklik yapar ve çok sayıda çıktı üretir.
Hata logları, deneme kodları ve geçici kararlar konuşmada birikir.
Yeni görev, eski ama artık geçersiz bilgiyle birlikte değerlendirilir.
Model mevcut çözümü kullanmak yerine yeni bir desen oluşturur.
Düzeltme istemleri daha fazla gürültü ekler ve döngü büyür.

Sonuç; unutma gibi görünse de asıl sorun çoğu zaman modelin çok fazla aday bilgi arasından doğru olanı seçmek zorunda kalmasıdır.

Context rot belirtileri

Aşağıdaki davranışlar bağlamı yenilemeniz veya yeni bir oturum başlatmanız gerektiğini gösterebilir:

Model daha önce reddedilen çözümü yeniden öneriyor.
Var olan servis, bileşen veya yardımcı fonksiyonun ikinci sürümünü oluşturuyor.
Görev kapsamı dışında dosyalara dokunuyor.
Test veya build komutunu tekrar tekrar yanlış çalıştırıyor.
Güncel hata yerine konuşmanın başındaki eski hatayı çözmeye çalışıyor.
Dosya adları, veri akışı veya kullanılan teknoloji hakkında çelişkili açıklamalar yapıyor.
Her düzeltme bir önceki çalışan davranışı bozuyor.
Yanıtlar uzuyor fakat yapılan değişiklik küçülmüyor.

Bu noktada “daha dikkatli ol” demek genellikle yetmez. Bağlamı yeniden düzenlemek gerekir.

Bağlam bütçesi: Daha fazla bilgi her zaman daha iyi değildir

Context penceresi sonlu bir kaynaktır. Ancak sorun yalnızca teknik token sınırı değildir. Modelin dikkat kapasitesi açısından da her ek bilgi maliyetlidir. Görevle ilgisiz dosyalar, binlerce satırlık başarılı test çıktısı ve eski kararlar doğru sinyalin ağırlığını azaltabilir.

Bağlam bütçesini şu öncelik sırasıyla kullanın:

Değişmez kurallar: Güvenlik, mimari sınırlar ve değiştirilmemesi gereken davranışlar.
Mevcut görev: Amaç, kapsam dışı alanlar ve kabul ölçütleri.
Doğrudan ilgili kod: Değişecek dosyalar ve çağrı zincirindeki yakın bağımlılıklar.
Kanıt: Başarısız test, kısa hata mesajı veya yeniden üretim adımı.
Geçmiş: Yalnızca bugünkü kararı açıklayan özetlenmiş kararlar.

“İleride lazım olabilir” düşüncesiyle bütün depoyu konuşmaya taşımak yerine, ajanı önce keşif yapmaya ve gerekli dosyaları kanıtlarıyla seçmeye yönlendirin.

Dört katmanlı context modeli

1. Kalıcı proje bağlamı

Her görevde değişmeyen bilgiler depo içinde sürümlenen bir yönerge dosyasında tutulmalıdır. Araçlara göre dosya adı değişebilir; önemli olan içeriğin kısa ve güncel olmasıdır.

Kalıcı bağlam şunları içerebilir:

Projenin amacı ve ana teknoloji yığını
Yüksek seviyeli klasör ve katman yapısı
Build, test, lint ve biçimlendirme komutları
Veri akışı ve tek doğruluk kaynakları
Güvenlik ve gizli bilgi kuralları
Yeni bağımlılık veya migration için onay sınırı

2. Görev bağlamı

Yalnızca o iş için gereken amaç, dosyalar, kabul ölçütleri ve kapsam dışı alanlardır. Görev kapandığında bu bağlamın büyük bölümü sonraki oturuma taşınmak zorunda değildir.

3. Çalışma zamanı kanıtı

Test sonucu, hata yığını, API yanıtı veya ekran görüntüsü gibi gerçek davranışı gösteren verilerdir. Yorum yerine kanıt sunar. Fakat tam log yerine ilgili bölüm ve yeniden üretim adımları verilmelidir.

4. Karar ve devir kaydı

Oturum boyunca alınan önemli kararların kısa özetidir: ne değişti, neden değişti, hangi risk kaldı ve bir sonraki adım nedir? Uzun konuşma geçmişini taşımak yerine bu kayıt yeni oturuma başlangıç context’i olur.

Repo haritası hazırlayın

AI ajanının her görevde depoyu sıfırdan anlamaya çalışması hem context hem zaman tüketir. Kısa bir repo haritası, yüksek seviyeli yön bulma sağlar.

# Proje Haritası

src/app/        Uygulama başlangıcı ve yönlendirme
src/features/   Özellik bazlı modüller
src/data/       API, yerel veri ve repository katmanı
src/ui/         Ortak görsel bileşenler
tests/          Birim ve entegrasyon testleri

Veri akışı: UI → ViewModel → Repository → Local/Remote
Tek doğruluk kaynağı: Repository üzerinden yerel veritabanı
Test komutu: [projenin gerçek komutu]
Lint komutu: [projenin gerçek komutu]

Harita dosya listesinin tamamı değildir. Ajanın “nereye bakmalıyım?” sorusunu cevaplayan bir yön levhasıdır. Mimari değiştiğinde haritayı da aynı pull request içinde güncelleyin.

Görev paketi nasıl hazırlanır?

Tek satırlık istek yerine küçük bir görev paketi hazırlamak, modelin varsayım yapmasını azaltır. Paket mümkün olduğunca gözlenebilir bilgiler içermelidir.

Görev: Çevrimdışı kaydedilen notun senkronizasyon durumunu göster.

Amaç:
Kullanıcı notun cihazda kayıtlı olduğunu fakat sunucuya henüz
ulaşmadığını anlayabilsin.

İlgili dosyalar:
- src/features/notes/note_item.*
- src/data/notes_repository.*
- tests/notes_sync_test.*

Kabul ölçütleri:
- pending kayıtta küçük bir durum göstergesi görünür.
- synced kayıtta gösterge kaybolur.
- ekran yeniden açıldığında durum yerel veriden korunur.

Kapsam dışı:
- Senkronizasyon algoritmasını değiştirme.
- Yeni paket ekleme.
- Ortak tema dosyasını yeniden düzenleme.

Doğrulama:
- İlgili birim testini ekle.
- Mevcut testleri ve lint komutunu çalıştır.
- Değişen dosyaları gerekçeleriyle özetle.

Görev paketi hem istemdir hem inceleme sözleşmesidir. Çıktıyı kabul ölçütleriyle karşılaştırmayı kolaylaştırır.

Progressive disclosure: Bilgiyi aşamalı verin

Her ayrıntıyı ilk mesajda vermek yerine bağlamı ihtiyaç oldukça açın:

Önce amaç, mimari harita ve kabul ölçütlerini verin.
Ajandan ilgili dosyaları belirlemesini isteyin.
Dosya seçimlerini gerekçeleriyle kontrol edin.
Yalnızca bu dosyaların yakın bağımlılıklarını bağlama ekleyin.
Uygulama sonrası yalnızca başarısız kontrollerin ayrıntısını paylaşın.

Bu yöntem hem gereksiz token kullanımını hem de ilgisiz kodun modele yön vermesini azaltır.

Log ve test çıktısını context’e nasıl eklemelisiniz?

On bin satırlık terminal çıktısını doğrudan yapıştırmak yerine şu bilgileri ayırın:

Çalıştırılan tam komut
İlk anlamlı hata satırı
İlgili stack trace bölümü
Beklenen ve gerçekleşen davranış
Hatayı yeniden üretmek için en kısa adımlar

Başarılı testlerin tamamını paylaşmak yerine “124 test geçti, yalnızca şu iki test başarısız” özeti çoğu görev için yeterlidir. Ayrıntı gerekiyorsa ajan ilgili dosyayı veya test sonucunu ayrıca okuyabilir.

Karar günlüğü tutun

Uzun vibe coding projelerinde aynı tartışmanın tekrar yaşanmasını önlemek için kısa bir karar günlüğü kullanın. Her kayıt dört soruyu cevaplasın:

Hangi karar alındı?
Neden bu seçenek seçildi?
Hangi alternatif reddedildi?
Karar hangi koşulda yeniden değerlendirilecek?

Örneğin “Yerel veri ana kaynak olacak; API yalnızca senkronizasyon sağlayacak” kararı, gelecekte ajanı UI’dan doğrudan API çağrısı eklemekten alıkoyabilir. Karar günlüğü geçmiş konuşmanın tamamından daha yoğun ve güvenilir bir context’tir.

Oturum devir notu şablonu

Görev bir oturuma sığmadığında veya context rot belirtileri başladığında yeni konuşmaya temiz bir devir notuyla geçin:

# Oturum Devri

Hedef:
[Tek cümlelik amaç]

Tamamlananlar:
- [Doğrulanmış değişiklik]
- [Geçen test veya kontrol]

Alınan kararlar:
- [Karar + kısa gerekçe]

Mevcut durum:
- Branch/commit: [kimlik]
- Başarılı komutlar: [komutlar]
- Kalan tek hata: [kısa kanıt]

Dokunulmaması gerekenler:
- [dosya, davranış veya kapsam]

Sonraki en küçük adım:
[Tek görev ve kabul ölçütü]

Devir notuna çözüme ulaşmayan bütün denemeleri eklemeyin. Yalnızca gelecekte aynı çıkmazı önleyecek bir bilgi varsa kısa biçimde kaydedin.

Ne zaman yeni oturum başlatmalısınız?

Aynı konuşmayı sonsuza kadar sürdürmek süreklilik sağlamaz; bazen yalnızca gürültüyü korur. Şu durumlarda yeni oturum daha verimlidir:

Bir özellik tamamlandı ve farklı bir özelliğe geçiliyor.
Mimari yön veya teknoloji kararı değişti.
Model aynı hatalı varsayımı tekrarlıyor.
Konuşma, güncel koddan daha eski bir durumu tarif ediyor.
Başarısız denemeler gerçek görev bilgisinden daha fazla yer kaplıyor.
Görevi temiz bir devir notuyla anlatmak geçmişi taşımaktan daha kısa.

Yeni oturumda depo yönergeleri, görev paketi ve devir notu yeterli olmalıdır. Eski sohbeti bütünüyle kopyalamak context rot’u da kopyalar.

Tehlikeli bağlam türleri

Her bilgi yalnızca gereksiz değildir; bazı context doğrudan risklidir:

API anahtarı, parola, erişim belirteci veya gerçek kullanıcı verisi
Kaynağı doğrulanmamış internet metni veya issue yorumu
Artık geçerli olmayan mimari belgeler
Üretim loglarında kişisel bilgiler
Modeli proje kurallarını yok saymaya yönelten dış içerikler
Güncel dosyayla çelişen eski kod parçaları

Dış kaynaktan gelen metni talimat değil veri olarak ele alın. Ajanın çalıştırabileceği araçları ve değiştirebileceği alanları görev ihtiyacına göre sınırlandırın.

Zayıf context ile güçlü context karşılaştırması

Zayıf istek:

Bildirimler bozuk, düzelt. Önceki konuşmada her şeyi anlatmıştım.

Güçlü görev context’i:

Android’de zamanlanmış bildirim, cihaz yeniden başladıktan sonra tetiklenmiyor. iOS davranışını ve bildirim ekranını değiştirme. İlgili servis src/notifications altında. Önce mevcut yeniden planlama akışını ve platform yapılandırmasını incele. Hatayı yeniden üreten testi veya doğrulama adımını yaz; sonra en küçük düzeltmeyi uygula. Yeni paket eklemeden önce gerekçe ve onay iste.

İkinci örnek çözümü dikte etmez; fakat modelin doğru problemi, sınırları ve kanıt standardını anlamasını sağlar.

15 dakikalık context denetimi

3 dakika: Proje yönergelerinde artık geçersiz komut veya mimari bilgi var mı kontrol edin.
3 dakika: Aktif görevin tek cümlelik amacı ve kabul ölçütleri net mi bakın.
3 dakika: Context’te görevle ilgisiz büyük dosya veya eski logları çıkarın.
3 dakika: Son önemli kararları kısa günlüğe ekleyin.
3 dakika: Context rot belirtisi varsa devir notu yazıp yeni oturum başlatın.

Bu kısa temizlik, saatler süren yanlış yönlü düzeltme döngüsünden daha ucuzdur.

Sonuç: İyi context, iyi koddan önce gelir

Vibe coding bağlam mühendisliği, modele daha çok bilgi vermek değil; karar için en değerli bilgiyi doğru biçimde sunmaktır. Kalıcı proje kuralları, küçük görev paketi, ilgili kod, çalışma zamanı kanıtı ve kısa karar günlüğü birlikte kullanıldığında AI ajanı daha tutarlı değişiklikler yapar.

Bağlamı bir depo gibi değil, sınırlı bir çalışma alanı gibi düşünün. Güncel olmayanı çıkarın, önemli kararları yoğunlaştırın ve farklı hedefler için temiz oturumlar açın. Böylece uzun vibe coding projelerinde context rot, kopya çözümler ve mimari sapmalar belirgin biçimde azalır.

Vibe coding’e yeni başlıyorsanız Vibe Coding Nedir? rehberini; AI tarafından üretilen kodun bakım maliyetini yönetmek için Vibe Coding Projelerinde Teknik Borç yazısını da okuyabilirsiniz.