Büyük Kod Projelerini Parçalayın: AI Ajanlar Nasıl Bağlam Kaybetmeden Ölçeklenebilir

Hepimiz yaşadık bunu. AI ajanına authentication sisteminizi refactor etmesini istiyorsun, yirmi dakika sonra üçüncü dosya ile beşinci context penceresi yenilemesi arasında orijinal gereksinimleri kaybettiğini fark ediyorsun. Model eksik bilgilerle bulmacayı çözmeye çalışıyor, varsayımlar sızmaya başlıyor ve birdenbire kontrol dışına çıkan bir ajana bebek bakıyor gibi davranmak zorunda kalıyorsun.

Daha iyi bir yol var—ve bunu yapmak için her şeyi manuel olarak belirtmen veya sürekli müdahale etmen gerekmiyor.

Herkesin Sessiz Kaldığı Context Penceresi Sorunu

Kirli sır şu: AI ajanlar dar ve iyi tanımlanmış görevlerde harika. Onlara dar bir sorun ver—bu fonksiyonu refactor et, bu sorguyu optimize et, bu testleri ekle—ve çöverler. Ama tüm kod tabanında devasa bir refactoring düzenlenmesini istersen? Onlardan context penceresindeki her şeyi dengede tutmasını ve aynı anda sonrasında ne geleceğini düşünmesini istiyorsun.

200K token context penceresi ile bile, savaş çoktan kaybedilmiş gibi hissediliyor. Ajan tarih, kararlar, mimari notlar ve kod parçacıkları biriktirir ta ki bilişsel yük sorunun kendisi haline gelene kadar. Sanki birinden yaşadığı her sohbeti çalışma belleğinde tutarken kod yazmasını istiyorsun.

Koordinatör Deseni Devreye Giriyor

Ya bir ajan her şeyi yapmaya çalışmak yerine sahip olsaydın:

• Bir koordinatör ajan - büyük resmi anlayan ve ana planı oluşturan
• Birden fazla uzmanlaşmış işçi ajan - her biri izole bir parçayı yöneten
• Harici bir gözden geçiren - kritik anlarda kontrol sağlayan

Bu yeni bir fikir değil—dağıtılmış görev yönetimi çoktan var. Ama bunu modern LLM yetenekleriyle birleştirmek? İşte burada ilginç şeyler başlıyor.

Koordinatörün işi şaşırtıcı derecede hafif. Şu şeyleri yapması gerek:

1. Büyük görevi açık aşamalar ve bağımlılıklarla bölmek
2. Hangi aşamaların tamamlandığını, hangilerinin bloklendiğini takip etmek
3. Yüksek seviyeli planı bellekte tutmak (uygulama ayrıntılarını değil)
4. Ön koşulları tamamlandıkça yeni işçi aşamalarını başlatmak

Her işçi ajan kendi ortamında çalışır—ayrı bir git worktree'de, diğer her şeyden izole. Spesifik bir prompt alırlar: "Bu modülü dependency injection kullanacak şekilde refactor et. İşte mevcut kod, işte hedef mimari, harekete geç."

Context şişmesi yok. İlgisiz kodda dolanıp durma yok. Henüz görmediği iş mantığı hakkında varsayımlar yok.

İşbirlikçi Gözden Geçirmenin Gücü

İşin şık tarafı şu: uygulama başlamadan önce ve bittikten sonra, bağımsız bir gözden geçiren (farklı bir model çalıştıran ya da temiz bağlamla aynısı) planı sorgulayıp sonuçları doğruluyor.

Koordinatör bir aşama dağılımı önerir—belki "authentication'ı authorizationdan ayır," sonra "role mantığını çıkar," sonra "permission caching ekle." Gözden geçiren diyebilir ki, "Bekle, üçüncü aşama ikincisinin tamamlanmasına bağlı, ama veritabanı migrasyonunu düşündün mü?"

Bu dışarıdan bakış açısı korkuluk görevi yapıyor. Kusursuz kod garantilemeyecek, ama sorunları birden fazla işçiye yayılmadan önce yakalar. Sanki teknik bir lider yapı planını inşaat başlamadan önce gözden geçiriyor.

Uygulama sonrasında gözden geçiren, gerçek diff'i plana karşı kontrol eder. Aşama söylediklerini başardı mı? Beklenmedik yan etkiler var mı? Kod kalitesi standartlarına uyuyor mu?

Bunu Ne Zaman Kullanman Gerekir (ve Ne Zaman Gerekmiyor)

Bu yaklaşım büyük refactoring çalışmaları için gerçekten güçlü. İşte neden:

• Net başarı kriterleri: Kod davranış olarak öncekiyle aynı ama temizse refactoring başarılı oldu.
• Minimum yeni varsayımlar: Özellik geliştirmesinin aksine, refactoring iş mantığı icat etmek gerektirmiyor.
• Birden fazla bakış açısı sağlamlığı iyileştirir: Farklı ajanlar (ya da farklı modeller) aynı aşamaya yaklaşım önerise, sonuç daha düşünceli olur.

Ama bir forma üç alan ekliyorsan? Bu aşırı. Bunu normalde bir hafta alacak 50-dosya refactoring için sakla.

Bu Senin Geliştirme Akışın İçin Ne Anlama Geliyor

Gerçek kazanç şu: AI'a yönelik işleri devrederken gerçekten micromanagement olmadan çalışmasına güvenebilirsin. Koordinatör-işçi deseni daha önce sürekli gözetim gerektiren projelere ölçeklenebilir.

NameOcean ve ötesindeki yazılımcılar için—ister bulut altyapı kodunu yönetiyorsun, ister deployment otomasyonu inşa ediyorsun, ister eski sistemleri refactor ediyorsun—bu desen kapılar açıyor:

• Altyapı refactoring: Monolitik Terraform'dan modüler, bileşen tabanlı infrastructure-as-code'a geç
• Eski sistem modernizasyonu: Kod tabanını eski desenlerden güncel en iyi uygulamalara yavaş yavaş geçir
• API yeniden yapılandırması: Sıkı bağlı endpoint mantığını uygun servis sınırlarına böl

Temel anlayış, spesifik araçlar ya da akış değil—şu: ayrıştırma ve izolasyon context çöküşünü önler. AI ajanlarını ya da insan geliştirici ekibini koordine ediyorsun, bu ilke her zaman geçerli.

Pratik Gerçeklik

Bunu çalıştırmak için egzotik araçlar gerekmez. Gerekli olan:

1. İzole çalışma ortamları oluşturma yöntemi (git worktrees ideal)
2. Koordinatör mekanizması (bir ajan, bir script, ya da organize edilmiş promptlar)
3. İş akışına entegre inceleme adımı
4. Alakasız iş mantığı hakkında bağlam gerektirmeyen net görev tanımları

NameOcean'da Vibe Hosting'in AI destekli geliştirme yeteneklerini sürekli geliştirirken, tam da bu tür orkestrasyonun AI'ı production-grade işlere ölçeklendirmesini sağlayan desendir. Context sınırlamalarıyla savaş vermek yerine, onlarla beraber çalışıyorsun.

Bir sonraki sefer büyük kod tabanı revizyonuna baksan, her şeyi aynı anda prompt etme isteğine direniş göster. Parçala. Koordine et. Gözden geçir. AI işçilerinin gerçekten iyi oldukları şeye—net, kapsamlı, iyi tanımlanmış değişikliklere—odaklanmalarına izin ver.

Senin context pencereniz (ve sağlık durumun) minnettardır.