Neden “iyi prompt” yazılım geliştirmede fark yaratır?

Son güncelleme: 2026-03

Not: Araç davranışları ve en iyi uygulamalar, kullandığınız ürünün/modelin sürümüne ve IDE entegrasyonuna göre değişebilir. Bu nedenle aynı şablonu ekip standartlarınıza göre uyarlayıp test ederek ilerleyin.

ChatGPT ve IDE içi asistanlar (ör. Copilot Chat) yazılım geliştirmede hız kazandırabilir; ancak çıktıların doğruluğu garanti değildir. Bu yüzden amaç, “tek seferde mükemmel kod” beklemek yerine, modeli doğru bağlam + net talimat + doğrulama adımları ile bir üretkenlik aracına dönüştürmektir.

OpenAI’nin prompt rehberinde öne çıkan pratiklerden bazıları: talimatı net şekilde başa koymak, bağlamı belirgin ayraçlarla (ör. üç tırnak veya ###) ayırmak ve istenen çıktı formatını açıkça söylemektir. Kaynak: OpenAI Prompt Engineering Best Practices.

Not: Bu içerik eğitim amaçlıdır; güvenlik, lisans/telif ve üretim ortamı riskleri için ek inceleme süreçleri gerekir. Şüpheli durumlarda ekibinizin güvenlik/uyum politikalarını izleyin.

Çekirdek prompt yapısı: 5 parçalı şablon

Aşağıdaki şablonu çoğu “kod yazdır / düzelt / test üret” isteğinde temel alın:

  • Rol: “Kıdemli backend geliştirici gibi davran”
  • Hedef: “X fonksiyonunu yaz / Y hatasını çöz”
  • Bağlam: Dil, framework, mevcut kod, kısıtlar, örnek girdi/çıktı
  • İstenen çıktı formatı: Dosya listesi, adım adım plan, testler, yalnızca diff vb.
  • Doğrulama: Kenar durumları, test senaryoları, performans/güvenlik kontrolleri

Copilot dokümantasyonu, özellikle IDE bağlamının (açık dosyalar, seçili kod, repo yapısı) yanıtları etkileyebileceğini vurgular; pratikte daha hedefli sonuç için bağlamı daraltmak (ör. yalnızca ilgili dosyaları/fragmentleri paylaşmak) işe yarayabilir. Kaynak: GitHub Copilot Chat Prompt Engineering.

Hızlı kontrol: Belirsizliği azaltan minimum bilgiler

  • Dil ve sürüm (örn. “Python 3.12”)
  • Çalışma bağlamı (CLI, web, serverless, mobil)
  • Kısıtlar (bağımlılık ekleme, performans, uyumluluk)
  • Hata mesajı/stack trace ve “beklenen vs gerçekleşen”
  • Örnek veri ve kabul kriteri

Kod tamamlama promptları (pratik şablonlar)

Kod tamamlama için amaç, modelin “ne üretmesi gerektiğini” kesinleştirmek ve varsayımları azaltmaktır. OpenAI rehberinde; örnek/format vererek ve gerekirse “leading words” (örn. import, def, SELECT) ile çıktıyı yönlendirmenin faydalı olabileceği anlatılır. Kaynak: OpenAI Prompt Best Practices.

Şablon 1: Tek fonksiyon (net I/O sözleşmesiyle)

Ne için?Prompt şablonu
Yeni fonksiyon yazdırma

Talimat: Aşağıdaki gereksinimlere göre bir fonksiyon yaz. Önce kısa bir plan çıkar, sonra kodu ver.

Bağlam: ### Dil: Python Fonksiyon adı: normalize_phone Girdi: string (telefon) Çıktı: E.164 formatına yakınlaştırılmış string veya None Kurallar: boş/None ise None; sadece rakamları al; ülke kodu yoksa varsayılan +1; 10 haneliyse +1 ekle. Örnekler: “(415) 555-2671” → “+14155552671”; “+1 415 555 2671” → “+14155552671” ###

Çıktı formatı: Yalnızca tek bir Python fonksiyonu döndür, ek açıklama ekleme.

Şablon 2: Mevcut koda “tamamlama + gerekçeli seçenekler”

Bu yaklaşım, modelin tek bir çözüm yerine 2–3 alternatif üretmesini sağlar; siz de ekip standartlarına uygun olanı seçersiniz.

Ne için?Prompt şablonu
Mevcut kodu tamamlama

Talimat: Aşağıdaki dosyada TODO kısmını tamamla. Sonra 2 alternatif yaklaşım öner ve artı/eksi yaz.

Bağlam (dosya): ### <buraya ilgili sınıf/fonksiyon ve TODO satırları> ###

Kısıtlar: Yeni bağımlılık ekleme. Mevcut public API değişmesin. Zaman karmaşıklığını belirt.

Çıktı formatı: 1) Patch (yalnızca değişen satırlar) 2) Alternatifler listesi

Şablon 3: SQL sorgusu (indeks ve açıklama isteyerek)

SQL’de doğruluk kadar performans da önemli olduğu için, sorgu ile birlikte olası indeks önerisi isteyebilirsiniz.

Ne için?Prompt şablonu
SQL üretimi

Talimat: Aşağıdaki şemaya göre bir SQL sorgusu yaz ve olası indeks önerilerini ekle.

Bağlam: ### DB: PostgreSQL Tablolar: - users(id, email, created_at) - orders(id, user_id, total, created_at) İstek: Son 30 günde toplam harcaması 500$ üstü olan kullanıcıları listele. ###

Çıktı formatı: 1) SQL 2) 2-3 cümle açıklama 3) indeks önerileri

Unit test üretimi: “test-first prompt” ile doğrulamayı öne al

OpenAI ve GitHub Copilot rehberleri, karmaşık işleri küçük parçalara bölmeyi ve çıktıyı doğrulamak için test/örneklerle ilerlemeyi önerir. Bu pratik, birçok ekipte “önce test(ler), sonra implementasyon” akışıyla uygulanır. Kaynaklar: GitHub Copilot Prompting, OpenAI Prompt Best Practices.

Şablon: Önce test, sonra implementasyon

AdımPrompt
1) Test üret

Talimat: Aşağıdaki fonksiyon sözleşmesine göre unit testleri yaz. Kenar durumlarını özellikle kapsa.

Bağlam: ### Dil: JavaScript (Node) Test framework: Jest Fonksiyon: isValidPassword(pw) Kurallar: min 12 karakter; en az 1 büyük, 1 küçük, 1 sayı; boşluk içeremez. ###

Çıktı formatı: Yalnızca test dosyası içeriği.
2) Implementasyonu yaz

Talimat: Şimdi aynı sözleşmeye göre fonksiyonu yaz. Aşağıdaki testleri geçmeli.

Bağlam: ### <bir önceki adımda üretilen testlerden ilgili kısımlar> ###

Çıktı formatı: Yalnızca fonksiyon kodu.

Test üretirken ekleyebileceğiniz kalite istekleri

  • Negatif testler: “Beklenmeyen input’larda hata mı dönsün, false mu?”
  • Örnek tablosu: “En az 10 örnek girdi/çıktı”
  • Kapsam yaklaşımı: “Temel dallanmaları ve kenar durumlarını kapsa”
  • Deterministiklik: Rastgelelik varsa seed veya sabitleme isteyin

Refactor şablonları: okunabilirlik, güvenlik ve bakım maliyeti

Refactor promptlarında en kritik nokta, davranışı koruma (behavior-preserving) beklentisini açık yazmaktır. Ayrıca “diff” formatı istemek, kod incelemesini kolaylaştırır.

Şablon: Davranışı koruyan refactor + gerekçe

Ne için?Prompt şablonu
Fonksiyon sadeleştirme

Talimat: Aşağıdaki kodu davranışı değiştirmeden refactor et. Daha okunabilir hale getir, isimlendirmeyi düzelt, gereksiz tekrarları kaldır.

Bağlam: ### <fonksiyon/sınıf kodu> ###

Kısıtlar: Public API aynı kalsın. Yeni paket ekleme. Yan etkileri koru.

Çıktı formatı: 1) Diff 2) Değişikliklerin kısa gerekçesi 3) Riskli gördüğün noktalar

Şablon: Performans odaklı refactor (ölçüm önerisiyle)

Modelin performans önerileri ortama göre değişebilir. Bu nedenle “ölçüm planı” istemek genellikle daha güvenlidir.

  • “En büyük darboğaz nerede olabilir? 3 hipotez yaz.”
  • “Her hipotez için ölçüm/benchmark öner (metrik + yöntem).”
  • “Sonra en az riskli optimizasyonu öner ve diff ver.”

Debug promptları: hatayı yeniden üret, izole et, kanıtla

Hata ayıklamada iyi sonuç için etkili yaklaşım: minimum yeniden üretilebilir örnek (MRE) sağlamak, beklenen/gerçekleşen davranışı net yazmak ve modelden “tek bir cevap” yerine bir soruşturma planı istemektir.

Şablon 1: Stack trace ile kök neden analizi

Ne için?Prompt şablonu
Hata mesajı üzerinden teşhis

Talimat: Aşağıdaki hata için olası kök nedenleri sırala, her biri için doğrulama adımı öner, sonra en olası olanı seçip düzeltme patch’i öner.

Bağlam: ### Ortam: Python + FastAPI Beklenen: /users/{id} endpoint’i 200 dönmeli Gerçekleşen: 500 Stack trace: <stack trace buraya> İlgili kod: <endpoint ve çağırdığı fonksiyonlar> ###

Çıktı formatı: 1) Hipotez listesi 2) Doğrulama adımları 3) Önerilen düzeltme (diff)

Şablon 2: Regresyon hatası (önce “ne değişti?”)

  • “Son çalışan commit ile bozuk commit arasındaki farkı özetle.”
  • “Bu farklardan hangileri hataya neden olabilir? 3 aday.”
  • “En hızlı izolasyon adımı nedir? (ör. feature flag, bisect yaklaşımı, log ekleme)”

Not: Burada modelin repo geçmişine erişimi sınırlıysa, ilgili diff’i prompt içine eklemek gerekir.

Code Interpreter (python tool) ile iteratif debug ne zaman işe yarar?

Eğer elinizde tekrar çalıştırılabilir bir örnek (ör. bir veri dosyası, bir fonksiyon, bir test) varsa, modeli kodu çalıştırıp hata üretmeye zorlamak güçlü bir doğrulama yöntemi olabilir. OpenAI geliştirici dokümanları, Python aracının bir sandbox/konteyner içinde çalıştığını ve oturum bazlı, geçici bir çalışma alanı mantığı olduğunu açıklar. Kaynak: OpenAI Code Interpreter (python tool) docs.

Pratik ipucu: “Bu hata şu input’ta çıkıyor” diyorsanız, modelden şu sırayla yardım isteyin:

  1. Hatanın tekrar üretildiğini kanıtlayan küçük bir test yazması
  2. Hata çıktısını yorumlaması
  3. En küçük düzeltmeyi yapması
  4. Testi tekrar çalıştırıp geçtiğini göstermesi

Daha tutarlı sonuçlar için bağlam stratejileri

Resmi rehberler, çıktıyı daha tutarlı hale getirmek için açık format, örnekler ve bağlamın doğru seçiminin önemini vurgular. Kaynak: OpenAI Prompt Best Practices.

  • Yeniden deneme (yeniden örnekleme): Özellikle test/bugfix gibi işlerde aynı isteği küçük varyasyonlarla tekrar denemek ve en iyi sonucu seçmek pratikte işe yarayabilir.
  • Bağlamı parçalara bölme: Uzun dosyalar yerine ilgili fonksiyon ve arayüzleri seçip verin.
  • Çıktı sözleşmesi: “Yalnızca diff”, “yalnızca dosya içeriği”, “önce plan sonra kod” gibi format kısıtları ekleyin.
  • IDE bağlamı: Dokümantasyon, IDE bağlamının yanıtları etkileyebileceğini vurgular; pratikte daha hedefli sonuç için ilgili kod parçalarına odaklanmak faydalı olabilir. Kaynak: GitHub Docs.

Kalite ve risk yönetimi: test, inceleme, güvenlik ve lisans

Kod üreten modeller bazı görevlerde çok başarılı olsa da fonksiyonel doğruluk her zaman güvenilir değildir. Kod üzerine eğitilmiş büyük dil modellerini değerlendiren Codex çalışması, performansın probleme ve değerlendirme yöntemine göre değişebildiğini; pratikte test ve incelemenin önemini gösterir. Kaynak: Evaluating Large Language Models Trained on Code (arXiv:2107.03374).

Üretim öncesi pratik doğrulama akışı

  • Otomatik test: Unit/integration testlerini çalıştırın; yeni eklenen davranış için test ekleyin.
  • Statik analiz: Lint, type-check, temel güvenlik taramaları (ekibinizin kullandığı araçlar).
  • Kod incelemesi: En az bir insan reviewer; özellikle kimlik doğrulama, yetkilendirme, kripto, dosya sistemi ve komut çalıştırma gibi alanlarda.
  • Lisans/telif hassasiyeti: Model çıktısı istemeden lisanslı kod parçalarına benzeyebilir. Şüpheli durumda benzerlik kontrolü ve lisans incelemesi yapın.
  • Gizli bilgi koruması: Prompt’a API anahtarı, müşteri verisi veya gizli repo içeriği koymayın (kurumsal politikanıza göre hareket edin).

Prompt-injection ve “araç kullanımı”na dair not

Modeli dış araçlarla (dosya okuma/yazma, kod çalıştırma) kullandığınız senaryolarda, girdilerin talimat gibi davranıp davranmadığını kontrol edin. Kullanıcıdan gelen içerikleri “veri” olarak sınırlamak, talimatları ayrı tutmak ve çıktı formatını sabitlemek riski azaltabilir.

Tek sayfalık kontrol listesi (kopyala-kullan)

Prompt yazmadan önce

  • Hedefi 1 cümleyle tanımla (ne üretilecek/ne düzeltilecek?)
  • Bağlamı daralt (yalnızca ilgili kod + hata)
  • Kısıtları yaz (dil/framework, bağımlılık, performans, API stabilitesi)
  • Kabul kriteri ekle (örnek girdi/çıktı veya test)

Modelden çıktı isterken

  • Çıktı formatı iste (diff, dosya içeriği, adım listesi)
  • 2-3 hipotez/alternatif iste (özellikle debug/refactor’da)
  • Riskli noktaları “kırmızı bayrak” olarak belirtmesini iste

Çıktıyı uyguladıktan sonra

  • Testleri çalıştır (ve yoksa ekle)
  • Code review yap
  • Güvenlik/lisans kontrollerini uygula (kurumsal süreçlere göre)
  • Değişikliği küçük parçalara bölerek merge et

Kaynaklar

Kapanış: hedef “otomatik yazılım” değil, daha iyi bir iş akışı

Yazılım geliştirmede prompt şablonları doğru kurgulandığında kod tamamlama, unit test üretimi, refactor ve debug süreçlerinde belirgin hız kazandırabilir. En iyi sonuçlar genelde şu formülle gelir: net talimat + iyi bağlam + test/inceleme ile doğrulama. Bu yaklaşımı bir kez oturttuğunuzda, aynı şablonları ekibinize göre standardize ederek tekrar tekrar kullanabilirsiniz.