IDE'nin ölümü mü?

• Geliştiricinin çalışma odağı, IDE içinde satır satır kod düzenlemeden ajan orkestrasyonu ve denetim arayüzlerine kayıyor; Cursor Glass, Claude Code Web, GitHub Copilot Agent gibi çeşitli araçlar bu geçişi hızlandırıyor
• Yeni geliştirme döngüsü "niyet belirtimi → delege etme → gözlemleme → diff inceleme → merge" biçiminde; çalışma biriminin merkezi artık dosya değil ajan
• Paralel ajan çalıştırmak için iş izolasyonu (git worktree), görev durum yönetimi, arka planda asenkron yürütme ve attention routing gibi kalıplar araçlar genelinde ortaklaşıyor
• Ajanın %90 doğru olup ince noktalarda hata yaptığı durumlarda ortaya çıkan inceleme yorgunluğu ile güvenlik ve yönetişim ek yükü yeni maliyetler olarak öne çıkıyor
• IDE ortadan kaybolmuyor; bunun yerine merkezsizleşiyor (de-centered). Ayrıntılı inceleme, debugging ve yüksek zorluklu işler için hâlâ kritik, ancak programlamanın başladığı tek yer artık o değil

---

Dosya düzenlemeden iş akışı yönlendirmeye

• Geleneksel IDE'ler dosya aç → düzenle → build et → debug et → tekrarla şeklindeki sıkı iç döngü için optimize edilmişti; ancak ajanlar bu döngünün büyük kısmını otonom biçimde yürütebildiği için artık üretkenliğin baskın birimi değiller
• Yeni döngü "niyet belirtimi → delege etme → gözlemleme → diff inceleme → merge" biçiminde. Bunu "sohbet penceresi eklenmiş otomatik tamamlama"dan ayıran şey, araç kullanımındaki otonomi ile bu otonomiyi kontrol edilebilir kılan arayüzün birleşimi
• Claude Code Web (veya Desktop) ile Codex, açıkça tanımlanmış işleri izole bulut ortamlarında çalışan ajanlara devrediyor; ilerleme tarayıcı üzerinden izlenebiliyor — terminal ya da yerel kurulum gerekmiyor
• GitHub Copilot Agent, çoklu dosya değişikliklerini bağımsız olarak planlayıp uyguluyor; branch oluşturma, test çalıştırma ve PR gönderimine kadar ilerliyor. Geliştiricinin ana rolü sonuçları incelemek ve yinelemek
• Conductor, birden fazla Claude Code ajanını izole çalışma alanlarında eşzamanlı çalıştırırken canlı ilerleme takibi sunan bir masaüstü uygulaması
• Google Jules, arka planda asenkron görev işleme sunuyor — görevi atıyorsunuz, tamamlanınca sonucu inceliyorsunuz
• Bu araçların paylaştığı zihinsel model şu: çalışma birimi dosya değil, ajandır — optimize edilmesi gereken arayüz daha hızlı yazmak değil, ajanları yönlendirmek, izlemek ve incelemektir

Şekillenen orkestrasyon katmanı

• İş izolasyonu (Work Isolation) temel primitive hâline geliyor: Paralel ajanların birbiriyle çakışmaması gerektiğinden, neredeyse tüm büyük araçlar git worktree (veya benzer yaklaşım) kullanıyor — Conductor her ajan oturumunu izole bir çalışma alanına eşliyor; Vibe Kanban da kanban tabanlı ajan iş akışında aynı yaklaşımı uyguluyor
• Planlama ve görev durumu en üst seviye UI hâline geliyor: Vibe Kanban gibi araçlar "sekmeler ve dosyalar"ı "görevler ve durumlar" ile değiştiriyor — görev kartları (landing page, backend service, e-posta entegrasyonu vb.) oluşturup bunları belirli ajanlara ve modellere atıyor, tüm yapıyı hafif bir proje panosu gibi yönetiyorsunuz; yalnız burada "takım" otonom çalışan ajanlardan oluşuyor
• Arka plan ajanları ve asenkron öncelikli tasarım: Cursor, Copilot, Antigravity gibi araçlar, çalışırken kullanıcı katılımı gerektirmeyen arka plan ajanlarını destekliyor — niyeti tanımlayıp başından ayrılıyor, tamamlandığında incelemeye dönüyorsunuz. Jules da aynı şekilde çalışıyor; temel varsayım, kullanıcının attention'ının bir progress bar izlemeye harcanamayacak kadar değerli olduğu
• Paralel ajanlar için attention yönetimi: Çok sayıda ajan aynı anda çalışırken asıl darboğaz, hangi ajana hemen müdahale edilmesi gerektiğini anlamak oluyor — Conductor oturumlar arasında canlı ilerlemeyi gösteriyor, cmux ise terminal panellerine bildirim halkaları ve okunmamış rozetleri ekliyor — "ajan attention istiyor" durumu, geliştirme ortamında birinci sınıf olay (first-class event) olarak öne çıkıyor
• Yazılım yaşam döngüsüne gömülü ajanlar: GitHub Copilot coding agent asenkron çalışıyor, güvenliği kontrol katmanı üzerinden sağlıyor ve GitHub Actions tabanlı ilerliyor — yalnız kodun nasıl yazıldığına değil, kodun gerçekte nasıl dağıtıldığına da bağlanıyor (issue → PR → CI → merge)
• Bu araçlar IDE'nin işe yaramaz olduğunu iddia etmiyor; hatta birçoğu IDE ile birlikte çalışabiliyor. Ancak tekrarlanan kalıplar — paralel çalışma alanları, diff öncelikli inceleme, görev durumu, arka plan yürütme ve yaşam döngüsü entegrasyonu — tam da "IDE'nin ölümü" denirken kastedilen ağırlık merkezi kaymasını gösteriyor

Geliştiriciler neden hâlâ IDE'ye dönüyor?

• "IDE öldü" iddiasına karşı en güçlü itiraz şu: IDE, hassas gezinme, yerel akıl yürütme, etkileşimli debugging ve doğrudan manipülasyon yoluyla sistemi anlama gibi zor problemleri tek bir yüksek sadakatli geri bildirim döngüsünde topluyor
• En iddialı orkestrasyon araçları bile manuel düzenleme için kaçış yolu bırakıyor — thread içinde diff inceleme, değişiklikleri yorumlayıp ardından editörde manuel ayar yapma iş akışı bilinçli bir tasarım tercihi
• Ajan araçlarının sınırlarını gösterdiği alanlar da var: Büyük repository'lerde çoklu dosya refactoring hâlâ yazılım mühendisliği ajanları için en zor meydan okumalardan biri — çünkü burada, ajanların yalnızca bağlamdan bütünüyle yeniden kuramayacağı bir sistem zihinsel modeline ihtiyaç duyuluyor
• Geliştiricileri IDE düzeyinde incelemeye geri bağlayan başarısızlık modu şu: Ajan %90 doğru ama ince şekilde hatalı olduğunda — sorunu bulmanın maliyeti, kodu doğrudan yazmanın maliyetini sık sık aşıyor; yüksek riskli değişikliklerde IDE, hassas inceleme için hâlâ en iyi araç

Yeni maliyet: inceleme yorgunluğu ve yönetişim ek yükü

• Geliştirme süreci "çok sayıda ajanın paralel çalıştırılması"na dönüştüğünde, iş akışı metin düzenlemeden çok dağıtık sistem yönetimi sorunlarını devralıyor — observability, yetkiler, izolasyon, yönetişim
• Ajan iş akışları emeğin yönünü tersine çeviriyor: Kod yazmak yerine inceleme merkeze oturuyor ve günün sonunda 12 paralel ajandan gelen 12 diff ile karşılaşmak şeklindeki inceleme yorgunluğu gerçek bir sorun hâline geliyor — en dikkatli araçların attention routing, yapılandırılmış planlar ve inceleme öncelikli kapılara odaklanmasının nedeni bu
• Ajanlar web'de gezinme, veritabanı sorgulama, dosya sistemine yazma, deployment tetikleme gibi daha fazla araca eriştikçe güvenlik yüzeyi genişliyor — ajanın ne yapabildiği kadar, yapmasına neyin izin verildiği de önem kazanıyor
• Observability ve kontrol açısından, IDE ile entegre ajan modları şimdiden açık araç logları ve onay kapıları yönünde evriliyor — ajan asenkron çalışıp CI pipeline'ına dokunduğu anda yönetişim artık tercih değil, zorunluluk oluyor

Ne hayatta kalacak: IDE, control plane, yoksa ikisi birden mi

• "IDE'nin ölümü", ağırlık merkezinin yönü açısından doğru; ama kelimesi kelimesine bir öngörü olarak yanlış
• Bu iddianın en güçlü versiyonu şu: IDE, ana çalışma alanı olmaktan çıkıp birçok alt araçtan biri hâline geliyor — hassas inceleme, debugging ve son düzenleme için kullanılıyor; planlama, orkestrasyon, inceleme ve ajan yönetimi ise dashboard'lara, issue tracker'lara, observability terminallerine ve bulut control plane'lerine kayıyor
• "Daha büyük IDE" çerçevesi de aynı ölçüde geçerli: Yeni "IDE", çoklu ajan orkestrasyonu, izole çalışma alanları, izinler ve audit log'ları, diff öncelikli inceleme, güvenilir araç bağlantısı ve attention routing sunan sistem olabilir — dosya editörü hâlâ vardır, ama artık ana giriş kapısı (front door) değildir
• IDE ölmüyor; merkezsizleşiyor (de-centered) — iş, orkestrasyon yüzeylerine kayıyor ve insanlar niyet tanımlamaya, paralel ajan runtime'larına görev devretmeye, denetim, inceleme ve yönetişime daha fazla zaman ayırıyor
• IDE, doğruluk, anlama ve ajanların hâlâ zorlandığı yüksek zorluklu problemler için hâlâ kritik; ancak artık programlamanın gerçekleştiği tek yer değil ve giderek daha fazla geliştirici için ilk gidilen yer de olmaktan çıkıyor