Şöyle bir sahne düşünün: Cursor açık, model cevap veriyor ve siz yine aynı cümleyi prompt’un sonuna yapıştırıyorsunuz — “make no mistakes”. İlk seferde tamam, normal. Ama onuncu keferde içinizden geçen şey çok net: “Neden hâlâ ben yapıyorum bunu?” Küçük bir tekrar (en azından benim deneyimim böyle). Sinir bozucu derecede küçük. Ve aslında hikâye tam oradan başlıyor.
Geçen ay, 2026 Ocak’ta İstanbul’daki bir startup ekibiyle kısa bir sohbet oldu; ekipteki herkes benzer şekilde prompt sonuna aynı uyarıyı eklediğini itiraf etti. Hani bazı alışkanlıklar vardır ya — ilk başta önemsiz görünür, sonra günün yarısını yer, fark bile etmezsiniz. İşte bu da aynen öyle bir şey. Geliştirici tarafında otomasyonu dilimizden düşürmüyoruz ama konu prompt olunca elle işi sürdürmeye devam ediyoruz. Biraz tuhaf. Biraz da çok tanıdık.
Asıl mesele ne? Tekrar eden prompt alışkanlığı
İnanın, İşin aslı şu: “make no mistakes” gibi ifadeler çoğu ekipte gayriresmî bir güvenlik kemeri gibi kullanılıyor. Modelin hata yapma ihtimalini sıfırlamıyor tabi — kimse öyle bir iddiada bulunmuyor zaten — ama çıktının tonunu ve dikkat seviyesini gerçekten etkiliyor, bunu inkâr etmek de doğru olmaz. İnsanlar bunu manuel yazmaya başlayınca kısa sürede ortak bir refleks oluşuyor.
Durun, bir saniye.
Bu tür şeylerin nasıl yayıldığını ilk kez 2023’te Kadıköy’de çalışan küçük bir ürün ekibinde görmüştüm. Ekipte herkes aynı SQL notunu kopyalayıp yapıştırıyordu; sonunda biri mini bir araç yazdı ve herkes “of be” dedi. Benzer durum. Küçük görünen tekrarlar, günün sonunda zihinsel çöp kutusunu dolduruyor ve siz bunu fark etmeden yoruluyorsunuz.
Ne yalan söyleyeyim, Gel gelelim burada sadece konfor meselesi yok; tutarlılık da var. Bu ne anlama geliyor? Prompt’un sonuna eklenen aynı talimatın bazen unutulması, bazen farklı yazılması, bazen de aceleyle bayağı atlanması yüzünden model davranışı dalgalanabiliyor — özellikle hızlı iterasyon yapılan işlerde bu dalgalanma, inanın, bayağı can sıkıyor (bizzat test ettim)
Bir dakika — bununla bitmedi.
make-no-mistakes ne yapıyor?
Basit. Temelde o tekrar eden parçayı otomatik hale getiriyor. Geliştirici her defasında aynı cümleyi yazmak zorunda kalmıyor; araç bunu arka planda hallediyor. Kulağa mütevazı geliyor, evet. Ama etkisi fena değil — çünkü kazandırılan şey yalnızca saniyeler değil, akış bozulmuyor ve bu çok farklı bir şey.
Bakın, Açık konuşayım, böyle araçların en sevdiğim tarafı “küçük problem, net çözüm” yaklaşımıdır. Büyük vaatler satmazlar. İşleyen bir boşluğu kapatırlar. Bu proje de tam o sınıfta duruyor; üretkenlik açısından baya iş görüyor diyebilirim.
“Bir şeyi günde yirmi kere elle yapmak yerine tek noktadan yönetmek, lüks değil; özellikle AI destekli geliştirme çağında neredeyse temel ihtiyaç.”
Neyse uzatmayalım… Buradaki mantık şuna benziyor: CI/CD’de deploy komutunu elle çalıştırmak yerine pipeline’a bağlamak nasıl doğal geliyorsa, prompt eki için de aynı refleks oluşmalıydı zaten. Geç kalınmış ama doğru bir hamle.
Kullanım senaryosu nasıl görünüyor?
Şöyle ki, Küçük bir startup’ta çalışıyorsanız bu tür otomasyonlar hemen fark yaratır — ekipler zaten az kişiyle çok iş çıkarıyor (kendi tecrübem). Gereksiz tekrarlar direkt moral düşürüyor, bunu yaşamayan biri anlayamaz. Enterprise tarafında konu biraz kayıyor; orada standartlaştırma ve denetim öne çıkıyor.
Evet, doğru duydunuz. Node.js’te Retry Kütüphanesi Savaşı: retry-pro mu p-retry mi? yazımızda bu konuya da değinmiştik. Bu konuyla ilgili Pixel 10 Pro XL 600 Dolara İndi: Alınır mı, Beklenir mi? yazımıza da göz atmanızı tavsiye ederim.
| Senaryo | Manuel kullanım | Otomatik ekleme |
|---|---|---|
| Küçük startup | Sık unutulur, hız kaybı olur | Daha akıcı çalışma sağlar |
| Orta ölçekli ekip | Prompt standardı bozulabilir | Tutarlılığı artırır |
| Enterprise | Ekipler arasında farklılık çıkar | Politika ve şablon yönetimi kolaylaşır |
Neden şimdi? Çünkü alışkanlıkların bedeli büyüyor
Dürüst olmak gerekirse, Bakın şimdi… AI araçları geliştikçe biz onlardan sadece — kendi adıma konuşayım — cevap değil, güvenilir cevap beklemeye başladık. Haklıyız da. Ama kullanıcı davranışı hâlâ eski usul ilerliyor: kopyala-yapıştır, ufak düzeltme yap, yeniden gönder. İlginç, değil mi? Sistem tarafında her şey otomasyona koşarken prompt katmanında elle işlem yapmak — hmm, nasıl desem — biraz 2018 hissi veriyor.
Benzer gerilimi Mart 2025’te Berlin’deki bir SaaS firmasının demo toplantısında da bizzat gördüm. Ekip kurucu ortağı bana şöyle demişti: “Test ortamını dakikalar içinde kuruyoruz ama LLM isteminde hâlâ cümleleri manuel tamamlıyoruz.” Cümle kısa ama nokta atışıydı (ilk duyduğumda inanamadım). Asıl mesele hız değil; ritim.
Durun, bir saniye.
Bana göre projenin değeri tam burada yatıyor: küçük sürtünmeleri azaltıp insanın kafasını asıl işe bırakmak. Kodun kendisini iyileştirmek kadar iş akışını temizlemek de önemli oluyor artık. Hele vibecoding modunda çalışırken… eh, biraz disiplin iyi geliyor doğrusu.
Artıları güçlü, eksileri ise göz ardı edilmemeli
Bilmem anlatabiliyor muyum, Evet. Araç güzel. Ama kusursuz değil — bunu da söylemek lazım. En büyük artısı açık ara tutarlılık sağlıyor olması; ikinci artısı ise, şaşırtıcı biçimde, zaman kazandırması değil aslında — zihinsel yükü azaltması. Tahmin eder misiniz? Her seferinde aynı şeyi hatırlamak zorunda kalmıyorsunuz ve bu küçücük rahatlama gün sonunda gerçekten hissediliyor, inanın. Bu konuyla ilgili Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımıza da göz atmanızı tavsiye ederim.
Buna karşılık dezavantaj tarafını da konuşalım. Böyle çözümler kullanıcıyı fazla otomasyona alıştırabilir; eğer ekip içinde herkes “nasıl olsa sistem ekliyor” diye düşünürse bazı durumlarda ince ayarlar gözden kaçabiliyor. Bir de projenin olgunluk seviyesi önemli — kağıt üstünde süper görünen şey pratikte biraz pişmek ister, bu sektörde bunu hepimiz biliyoruz.
- Artılar: Tutarlılık, hız, daha az tekrar, daha temiz iş akışı
- Eksi taraflar: Yanlış yapılandırma riski, alışkanlık bağımlılığı, henüz erken aşama olabilirliği
- Dikkat: Her prompt için aynı politika doğru olmayabilir; bağlam bazlı düşünmek lazım
Mstack meselesi ne anlama geliyor?
Sorunun göbeğinde duran bakış açısı aslında şu: Eski yöntemler yetmiyorsa yeni stack’e geçmek gerekir. Yazıda geçen “Gstack bitti” vurgusu biraz afacan dursa da — ve durduğu belli oluyor açıkçası — mesaj net. Hani ne farkı var diyorsunuz, değil mi? Araç zincirinizde artık prompt katmanı da yönetilebilir olmalı diyorlar (yanlış duymadınız)
Bu kısmı okurken kendi editör masamda güldüm diyebilirim (Ocak 2026’da Maslak’taki ofiste not alırken olmuştu). Teknoloji dünyası sürekli yeni isimler üretir ama çoğu zaman derdi aynıdır: sürtünme azaltmak ve standardizasyonu yükseltmek. Yeni isim, eski dert.
Peki kimler kullanmalı?
Bireysel geliştiriciler için kullanım alanı çok net; özellikle Cursor ya da Claude ile yoğun çalışanlar için anlamlı duruyor. Gün içinde onlarca kez aynı talimatları giriyorsanız bu tarz araçlar ciddi rahatlatır — şaşırdım açıkçası ne kadar fark yarattığına. Daha fazla bilgi için TSMC’ye Giden Yol: Apple’ı Sarsan Çip Gölgesi yazımıza bakabilirsiniz.
Ekip liderleri ve platform mühendisleri içinse olay başka yere gidiyor: iç standart oluşturmak mümkün oluyor. Bir de şu var — AI ajanlarıyla çalışan takımlarda yanlış yönlendirme riski. Yüksek olduğu için sistematik hatırlatmalar kıymet kazanıyor. Burada amaç modeli terbiye etmekten çok iş akışını sabitlemek.
# Örnek kullanım fikri
prompt = base_prompt + " make no mistakes"
response = llm.generate(prompt)Kod basit görünüyor diye hafife almayın. Bazen en iyi araçlar tam böyle sade olur — kafanıza çivi gibi çakılmaz, sessizce işini yapar ve siz farkında bile olmadan rahatlamış olursunuz. PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımızda bu konuya da değinmiştik.
Kısa değerlendirme ve pratik öneriler
Eğer sizin takımda prompt tekrarları sık yaşanıyorsa böyle bir çözüm bayağı mantıklı. Ama körü körüne her yerde kullanmayın — mesela yaratıcı metin üretiminde sert kalite talimatları bazen tonu gereğinden fazla sıkabiliyor, bunu yaşadım. Test edin, ölçün, sonra karar verin.
Ben olsam önce küçük çapta denerdim: bir kişilik kullanım, bir haftalık test, sonra ekip geri bildirimi. Çünkü AI araçlarında gerçek hayat testi olmadan hüküm vermek pek sağlıklı olmuyor. Hatta bazen en büyük hayal kırıklığı, kendi sandığınız kadar fark yaratmaması oluyor — ama bu da bir veri, en azından.
Sıkça Sorulan Sorular
“make no mistakes” ne işe yarıyor?
LMM veya LLM istemlerinde modele daha dikkatli davranmasını söyleyen kısa bir yönerge gibi çalışır. Hata riskini sıfırlamaz ama çıktının kontrol seviyesini artırabilir. En çok da kod veya teknik metin üretiminde tercih edilir.
Bu tür bir skill gerçekten zaman kazandırır mı?
Evet, özellikle sık kullanılan promplarda kazandırır.
Tek tek saniyeler az görünür ama gün sonunda tekrar sayısı yükselince fark ortaya çıkar.
Asıl kazanç çoğu zaman zihinsel akışın bozulmaması olur.
Sadece Cursor kullanıcıları mı faydalanır?
Şöyle ki, Hayır.
Benzer mantıkla çalışan diğer LLM araçlarında da kullanılabilir veya uyarlanabilir.
Önemli olan istem zincirine sabit kuralları otomatik olarak ekleyebilmek.
Böyle araçların riski var mı?
Şunu söyleyeyim, Var tabii.
Yanlış kural seti uygularsanız model istenmeyen biçimde daralabilir ya da bağlama uygun olmayan çıktılar verebilir.
O yüzden önce küçük test yapmak en doğrusu olur.
Kaynaklar ve İleri Okuma
make-no-mistakes GitHub Sayfası
Anthropic Claude Dokümantasyonu
Doğrusu, Cursor Resmi Dokümantasyonu
İlgili Yazılar
LLM Mühendisliğinde 10 Temel Kavram: Kısa Rehber
AI Ajanlar Neden Yalan Söyler: Asıl Ders Ne?
MCP Ekosistemi Nereye Gidiyor: Hız, Açıklar, Güvenlik:
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
