Cursor'un 4 Modu: Ask, Agent, Plan ve Debug Nasıl Kullanılır?

Cursor'u ilk kurduğunuzda tek bir chat kutusu görürsünüz. Çoğu kullanıcı hep aynı modu kullanır — genellikle Agent — ve diğerlerinin varlığından habersizce çalışır. Sonuç: yavaş, verimsiz, bazen tehlikeli iş akışları.

Oysa Cursor'da dört farklı mod var ve her biri farklı bir iş için tasarlandı. Doğru modu doğru zamanda seçmek, hem daha az geri dönüş hem de daha az "AI neden bunu yaptı?" anı demek.

Bu yazıda her modu ne için, ne zaman ve nasıl kullanacağınızı, bir yazılım ajansı olarak günlük işimizde gördüğümüz örneklerle açıklıyoruz.

Kısa cevap: Cursor'daki modlar, aynı yapay zeka asistanına ne kadar yetki verdiğinizi belirler:

• Ask: Sadece okur ve cevaplar, kod değiştirmez. Kodu anlamak için.
• Agent: Dosya düzenler, terminal komutu çalıştırır. Bir işi yaptırmak için.
• Plan: Önce soru sorar ve düzenlenebilir bir uygulama planı yazar; siz onaylayınca Agent uygular.
• Debug: Hipotez kurar, koda geçici log ekler, hatayı sizin tekrarlamanızı ister ve çalışma anı verisine göre hedefli düzeltme yapar.

Modlar arasında chat kutusundayken Shift+Tab ile geçilir.

Şubattan bu yana ne değişti? 2 Nisan 2026'da yayınlanan Cursor 3 ile birlikte birden çok ajanı paralel yönettiğiniz Agents Window geldi; klasik editör de kullanılmaya devam ediyor. Debug modu artık sadece hata mesajı yorumlamıyor, kodunuza geçici loglar ekleyip gerçek çalışma verisi topluyor. Proje kuralları için tek dosyalık .cursorrules yerine .cursor/rules klasörü ve AGENTS.md öneriliyor. Aşağıdaki bölümleri bu değişikliklere göre güncelledik.

Modlara Genel Bakış

Agent panelini Ctrl+I (Mac'te Cmd+I) ile açarsınız. Mod seçici chat kutusunun altındaki açılır menüdedir; klavyeden Shift+Tab modlar arasında sırayla geçiş yapar. Cursor, karmaşık bir görev yazdığınızı fark ettiğinde Plan moduna geçmeyi kendisi de önerebilir (Cursor dokümantasyonu).

Temel kural: Anlamak istiyorsanız Ask, yapmak istiyorsanız Agent, planlamak istiyorsanız Plan, düzeltmek istiyorsanız Debug.

Ask Modu: Anlamak İçin Sor

Ask modu, Cursor'un okuma odaklı modudur. Codebase'i analiz eder, sorularınızı yanıtlar ama tek satır bile kod değiştirmez.

Ne Zaman Kullanmalısınız?

• Yeni bir projeye girdiniz ve mimariyi anlamaya çalışıyorsunuz
• Bir fonksiyonun ne yaptığını, neden böyle yazıldığını merak ediyorsunuz
• Bir bug'ın nereden kaynaklandığını araştırıyorsunuz ama henüz değişiklik yapmak istemiyorsunuz
• Kod review öncesi başka birinin yazdığı kodu okuyorsunuz

Pratik Örnekler

# Mimari anlama
"Bu proje nasıl bir authentication akışı kullanıyor? 
Kullanıcı login olduğunda hangi dosyalar devreye giriyor?"

# Bağımlılık analizi
"useCartStore hook'u hangi component'lerde kullanılıyor? 
Bunları değiştirirsem ne etkilenir?"

# Kod anlama
"Bu middleware fonksiyonu tam olarak ne yapıyor? 
Edge cases neler olabilir?"

Bağlamı Doğru Vermek

Eski sürümlerdeki @Codebase etiketine artık ihtiyaç yok: asistan ilgili dosyaları kendi arama araçlarıyla buluyor. Yine de belirli bir dosya ya da klasörü @ ile etiketlemek cevabı hızlandırır ve yanlış yere bakma ihtimalini azaltır:

@src/lib/email Bu projede e-posta gönderme işlemi nerede ve nasıl yapılıyor?

Agent'ı başlatmadan önce bu soruyu sormak, yanlış dosyalarda değişiklik yapma riskini azaltır.

💡 İpucu: Büyük bir feature'a başlamadan önce Ask ile "Bu değişikliği yapmak için hangi dosyalara dokunmam gerekir?" sorusunu sorun. Plan çıkarın, sonra Agent'a geçin.

Agent Modu: Otonom Yapıcı

Agent modu, Cursor'un en güçlü ve en riskli modudur. Bir görev verirsiniz; Agent çok sayıda dosyayı düzenleyebilir, yeni dosyalar oluşturabilir, terminal komutları çalıştırabilir. Terminal komutlarının onay isteyip istemeyeceği ayarlardan belirlenir; otomatik çalıştırmayı açtıysanız neye izin verdiğinizi bilin.

Ne Yapabilir?

• Birden fazla dosyada eş zamanlı değişiklik yapar
• npm install, npx, git gibi terminal komutları çalıştırır
• Yeni dosya ve klasör oluşturur, isim değiştirir, siler
• Hata aldığında kendi kendine tekrar dener
• Test çalıştırır, sonuçları analiz eder, düzeltir

Ne Zaman Kullanmalısınız?

• Yeni bir feature sıfırdan oluşturuyorsunuz
• Büyük bir refactoring yapıyorsunuz (örn. tüm projeyi TypeScript'e geçirmek)
• Tekrarlayan boilerplate kod yazıyorsunuz (form, CRUD, API endpoint)
• Bir kütüphane migration'ı yapıyorsunuz

Pratik Örnekler

"Kullanıcı profil sayfası oluştur. /app/profil/page.tsx altında 
Next.js App Router ile. Supabase'den kullanıcı verilerini çek, 
ad, e-posta ve avatar göster. Mevcut UI bileşenlerini kullan."

"tüm .tsx dosyalarındaki console.log ifadelerini bul ve kaldır. 
Sadece // TODO yorum satırı olan yerlerde bırak."

Agent Modunda Kritik Uyarılar

Agent güçlüdür ama kontrolsüz bırakmayın:

1. Her adımı takip edin. Agent değişiklik yaparken ekranı izleyin. Yanlış bir yöne giderse erken durdurun — Escape tuşu Agent'ı durdurur.

2. Git'te temiz bir state'te başlayın. Agent büyük değişikliklerden önce otomatik checkpoint alır ve sohbet zaman çizelgesinden geri dönebilirsiniz. Yine de checkpoint sadece dosyaları geri alır; çalıştırılmış komutların (ör. veritabanı migration'ı) etkisini geri almaz. Başlamadan önce git commit yapmak hâlâ en sağlam güvence.

3. Küçük, net görevler verin. "Tüm projeyi yeniden yaz" yerine "Sadece checkout flow'unu güncelle" deyin. Ne kadar spesifik olursanız o kadar isabetli sonuç alırsınız.

4. Production'da dikkatli olun. Agent terminal komutları çalıştırabileceğinden, rm -rf, DROP TABLE gibi tehlikeli komutlara dikkat edin. .cursorignore ile hassas dosyaları (ör. .env) asistanın erişiminden çıkarabilirsiniz.

Plan Modu: Önce Planla, Sonra Yap

Plan modu, Agent'ın düşünce sürecini görünür kılar. Kod yazmadan önce kod tabanını araştırır, belirsiz noktalarda size netleştirici sorular sorar ve düzenleyebileceğiniz bir uygulama planı çıkarır. Planlar varsayılan olarak ev dizininize kaydedilir; "Save to workspace" ile projeye taşıyıp ekibinizle paylaşabilirsiniz.

Büyük bir değişikliği körü körüne çalıştırmak yerine şöyle bir akış oluşturur:

Siz → Görev tanımı
       ↓
Plan → Atacağı adımların listesi
       ↓
Siz → Onaylıyorsunuz / düzeltiyorsunuz
       ↓
Agent → Planı uygular

Ne Zaman Kullanmalısınız?

• Büyük ve karmaşık değişiklikler yapmadan önce
• Tam olarak ne yapılacağından emin olmadığınız durumlarda
• Takım çalışmasında başkalarının incelemesi gereken değişiklikler için
• Agent'ın daha önce yanlış anlayıp beklenmedik şeyler yaptığı durumlarda

Pratik Örnek

Görev: "Authentication sistemini NextAuth'tan Supabase Auth'a geçir"

Plan Modunun Ürettiği Çıktı:

Yapılacaklar:
1. next-auth bağımlılığını kaldır, @supabase/ssr ekle
2. /lib/auth.ts dosyasını Supabase client ile yeniden yaz
3. middleware.ts'deki session kontrolünü güncelle
4. /app/api/auth/[...nextauth]/route.ts'i sil
5. /app/api/auth/callback/route.ts oluştur
6. Login/logout component'lerini güncelle
7. .env.local'a SUPABASE_URL ve SUPABASE_ANON_KEY ekle

Bunu görünce fark ettiniz: "Adım 3'te middleware değişiyor, bu production'ı etkiler. Önce staging'de denemeliyim." Plan olmadan bu farkı ancak iş işten geçtikten sonra görebilirdiniz.

💡 İpucu: Plan modunu özellikle database migration'larında ve authentication değişikliklerinde kullanın. Bu iki alan geri alınması en zor değişiklikleri içerir.

Plan'ı Düzenleyebilirsiniz

Plan, chat üzerinden ya da doğrudan markdown dosyası olarak düzenlenebilir. Onaylamadan önce şöyle bir yönlendirme yapabilirsiniz:

"Planın iyi ama Adım 1'i atlayalım, next-auth'u şimdilik bırak.
Sadece Supabase Auth'u paralel olarak ekle. 
Önce sadece yeni kullanıcı kaydı için deneyelim."

Bu şekilde Agent'ı adım adım yönlendirebilir, riski minimize edebilirsiniz.

Agent yanlış bir şey inşa ettiyse planı yamamaya çalışmayın, plana dönün. Cursor'un kendi önerisi de bu: değişiklikleri geri alın, planı daha net hale getirin ve yeniden çalıştırın. Bizim deneyimimizde de yanlış giden bir Agent oturumunu takip mesajlarıyla düzeltmeye çalışmak, temiz bir planla baştan başlamaktan neredeyse her zaman daha uzun sürüyor.

Plan mı, Ask mı?

"cursor plan vs ask" sorusu sık soruluyor, çünkü ikisi de başta kod değiştirmiyor. Fark şurada: Ask bir soruya cevap verir ve orada biter; Plan ise uygulanmak üzere bir yapılacaklar listesi üretir ve onayınızla Agent'a devreder. Kodu anlamak istiyorsanız Ask, bir değişikliği nasıl yapacağınıza karar vermek istiyorsanız Plan.

Debug Modu: Hipotez, Log, Kanıt, Düzeltme

İlk yayında Debug modunu "hata mesajını yorumlayan mod" olarak anlatmıştık. Güncel sürümde çok daha iddialı bir iş yapıyor: tahmin üzerine düzeltme yazmak yerine çalışma anı verisi topluyor. Cursor dokümantasyonuna göre akış şöyle:

1. Keşif ve hipotez: İlgili dosyaları okur, olası kök nedenler için birden fazla hipotez üretir.
2. Enstrümantasyon: Kodunuza, bir Cursor eklentisinde çalışan yerel debug sunucusuna veri gönderen geçici log satırları ekler.
3. Tekrarlama: Hatayı nasıl tekrarlayacağınızı adım adım söyler; siz uygulamada bu adımları yaparsınız.
4. Analiz: Toplanan logları inceleyip gerçek kök nedeni bulur.
5. Hedefli düzeltme: Çoğu zaman birkaç satırlık, doğrudan nedene yönelik bir değişiklik yapar.
6. Temizlik: Düzeltmeyi doğruladıktan sonra eklediği tüm logları kaldırır.

Ne Zaman Kullanmalısınız?

• Hatayı tekrarlayabiliyorsunuz ama koda bakarak nedenini bulamıyorsunuz
• Race condition, zamanlama ve async sıralama sorunları
• Bellek sızıntısı, yavaşlama gibi ancak çalışırken görünen problemler
• "Dün çalışıyordu" türü regresyonlar

Basit bir derleme hatası ya da açık bir TypeScript hatası için Debug moduna gerek yok; hata mesajını Agent'a yapıştırmak çoğu zaman yeterli. Debug modu, Agent'ın tahminle iki üç kez yanlış düzeltme yaptığı durumlarda değer katıyor.

Pratik Kullanım

Ne kadar net bağlam verirseniz enstrümantasyon o kadar isabetli olur:

Sepete ürün eklendiğinde bazen sayaç bir eksik görünüyor.
Tekrarlama: ürün sayfasında "Sepete ekle"ye hızlıca iki kez tıkla.
Beklenen: sayaç 2. Gerçekleşen: çoğu zaman 1.
Hata mesajı yok. Sadece production build'de oluyor.

Debug modu burada muhtemelen state güncellemelerinin sırasını loglayacak, sizden adımları birkaç kez tekrarlamanızı isteyecek ve iki güncellemenin birbirini ezdiği noktayı gösterecektir. Bu tür zamanlamaya bağlı hatalarda adımları birden fazla kez tekrarlamak, ajanın doğru hipotezi seçmesine yardım eder.

💡 İpucu: Beklenen ve gerçekleşen davranışı ayrı ayrı yazın. "Çalışmıyor" yerine "2 bekliyordum, 1 görüyorum" demek, ajanın hangi değeri loglaması gerektiğini doğrudan söyler.

4 Modun Doğru Workflow'u

Gerçek bir feature geliştirme senaryosunda modları şöyle birleştirin:

1. Ask  → "Bu feature için hangi dosyalara dokunmam gerekir?"
            "Mevcut state management nasıl çalışıyor?"

2. Plan → "Kullanıcı bildirim tercihlerini kaydetme özelliği ekle"
            → Agent planı listeler → siz onaylarsınız

3. Agent → Planı uygular, dosyaları düzenler, bağımlılıkları kurar

4. Debug → Nedeni bulunamayan, tekrarlanabilen hataları kanıtla çözer

5. Ask  → "Yaptığım değişiklikler mevcut testleri etkiler mi?"
            "Güvenlik açısından gözden kaçırdığım bir şey var mı?"

Bu döngüyü takip ettiğinizde hem hız kazanırsınız hem de kontrolü elinizde tutarsınız.

Hangi Modu Ne Zaman Seçmeli — Hızlı Karar Rehberi

Soru: Kodun nasıl çalıştığını anlamak mı istiyorum? → Ask

Soru: Büyük bir feature mı yazıyorum, değişiklikler öngörülemeyen yerlere yayılabilir mi? → Plan → Agent

Soru: Küçük, net sınırlı bir değişiklik mi var? → Agent (Plan atla)

Soru: Açık bir hata mesajı mı var (build, TypeScript)? → Agent (mesajı yapıştırın)

Soru: Hata tekrarlanıyor ama nedeni bulunamıyor mu? → Debug

Soru: Bir şeyler yanlış gitti, ne olduğunu bilmiyorum? → Ask ile başla, sonra Debug

Sık Yapılan Hatalar

1. Her şeyi Agent'a vermek

En yaygın hata. "Yap" demek için Agent seçmek yerine önce Ask ile bağlamı netleştirin. Aksi halde Agent doğru görünen ama yanlış olan şeyler yapabilir.

2. Plan modunu atlamak

Karmaşık değişikliklerde Plan modunu atlamak, Agent'ın beklenmedik yerlere dokunmasına yol açar. 2 dakikalık plan incelemesi saatlerce debug çalışmasının önüne geçebilir.

3. Debug yerine Agent'la düzeltmek

Agent'ın aynı hatayı tahminle üç kez "düzelttiğini" görüyorsanız durun. Debug modu tahmin yerine çalışma anı verisiyle ilerlediği için daha hedefli ve cerrahi müdahale yapar.

4. Proje kuralı yazmamak

Cursor'un projenize özel nasıl davranacağını kurallarla tanımlarsınız. Eski tek dosyalık .cursorrules yerine güncel dokümantasyon iki yol öneriyor: .cursor/rules klasöründe sürüm kontrolüne giren .mdc dosyaları ya da kök dizinde düz bir AGENTS.md:

<!-- AGENTS.md -->
- Değişiklik yapmadan önce etkilenecek dosyaların listesini çıkar
- Yeni bileşen yazmadan önce src/components altındakileri yeniden kullanmaya çalış
- Hata düzeltirken kök nedeni açıkla, sadece fix verme
- TypeScript strict mode kullan, any type yazma

Bu dosya olmadan Cursor genel amaçlı davranır. Dosya ile projenize özel kurallarla çalışır; AGENTS.md aynı zamanda başka AI kodlama araçları tarafından da okunduğu için ekipte farklı araç kullananlar varsa ayrıca avantajlı.

Sonuç

Cursor'un 4 modunu birbirini tamamlayan araçlar olarak düşünün:

• Ask = Anlamak
• Plan = Planlamak
• Agent = Yapmak
• Debug = Düzeltmek

Çoğu geliştirici sadece Agent kullanıyor ve "AI neden bunu yanlış yaptı?" diye yakınıyor. Cevap genellikle mod seçiminden geçiyor: önce anlamadan yapmaya çalışmak.

Doğru mod seçimi, AI ile çalışmayı körlükten görerek yürümeye dönüştürür.

Cursor hakkında daha fazla bilgi için teknoloji sayfamızı, diğer vibe coding araçlarını keşfetmek için vibe coding sayfamızı inceleyebilirsiniz.

AI ile hızlı üretilen kodun hangi noktada risk taşımaya başladığını Vibe Coding Nedir? yazımızda ayrıca ele aldık.

Cursor ile başlattığınız projeyi production kalitesine taşımak mı istiyorsunuz? Bizimle iletişime geçin — AI çıktınızı birlikte sağlam bir ürüne dönüştürelim.

Bu yazı 7 Ekim 2026'da güncellendi: Cursor 3 ve Agents Window notu, Shift+Tab ile mod geçişi, yeni Debug modu akışı (hipotez–log–tekrarlama), Plan modu ve Plan/Ask farkı, .cursor/rules ve AGENTS.md ile kısa cevap eklendi; kaldırılan @Codebase ve eski kısayol tablosu düzeltildi.