Kazanimlar:
- Satır içi tamamlama ile sohbet modunu doğru görev tipine eşleyebilme
- Girdi/çıktı sözleşmesi, kenar durum ve stil kısıtı içeren güçlü üretim promptları yazabilme
- Üretilen kodu ve önerilen her yeni bağımlılığı birleştirmeden önce doğrulayabilme
Bir yazılımcının AI ile ilk temas noktası genellikle otomatik tamamlama (autocomplete — siz yazarken bir sonraki satırı öneren özellik) veya bir sohbet penceresine "şu fonksiyonu yaz" demektir. İkisi de aynı motoru kullanır ama farklı disiplinler ister. Bu ünitede kod üretimini rastgele "yaz bakalım"dan çıkarıp, çıktısı öngörülebilir ve doğrulanabilir bir mühendislik adımına dönüştürüyoruz.
Amaç, AI'yı daktilonuzu hızlandıran bir araç olmaktan çıkarıp, sizin belirlediğiniz kısıtlar içinde çalışan bir çırağa dönüştürmektir. İyi yönlendirilen bir çırak zaman kazandırır; yönlendirilmeyen bir çırak, sonradan temizlemeniz gereken bir dağınıklık üretir.
İki Kullanım Modu: Satır İçi Tamamlama ve Sohbet
Satır içi tamamlama editörünüzde siz yazarken devreye girer; bir fonksiyon imzası veya bir yorum satırı yazdığınızda gerisini önerir. Hız için idealdir ama bağlamı dardır: yalnızca yakın çevredeki kodu görür. Bu yüzden en iyi sonucu, niyetinizi bir yorumla açıkça yazdığınızda verir. Örneğin // kullanıcı e-postasını doğrula, geçersizse ValidationError fırlat yorumu, altına gelen öneriyi belirgin biçimde iyileştirir.
Sohbet modu ise daha büyük ve yapılandırılmış görevler içindir: "Bu sınıfa sayfalama ekle", "Şu servisin bir arayüzünü çıkar". Burada rol, bağlam ve format verme lüksünüz vardır. Genel kural şudur: küçük ve akış içindeki işler için tamamlama, düşünmeyi ve yapı kurmayı gerektiren işler için sohbet.
İpucu: Tamamlama önerisini körü körüne "Tab" ile kabul etmeyin. Önerilen satırı bir saniye okuyun; yanlış değişken adı ya da ters çevrilmiş bir koşul, en sık buradan sızar.
Niyeti Koda Çevirmenin Adımları
- Sözleşmeyi (contract) tanımlayın. Fonksiyonun girdisi, çıktısı ve hata davranışı nedir? "E-posta al, geçerliyse normalize et, geçersizse hata fırlat" gibi.
- Kısıtları söyleyin. Dış bağımlılık kullanılmasın mı? Belirli bir stil kılavuzu mu? Performans sınırı mı var?
- Örnek verin. Bir girdi–çıktı çifti ("ali@x.com → geçerli, ali@ → hata"), modelin niyeti kavramasını tahminden kesinliğe taşır.
- Küçük parça isteyin. Tek fonksiyon, tek sorumluluk. Sonra bir sonrakine geçin.
- Üretilen kodu okuyun ve çalıştırın. Derleme + hızlı bir manuel deneme, en ucuz güvence adımıdır.
Üç Mini Vaka
Vaka 1 — Yorum odaklı üretim isabeti artırıyor. Bir geliştirici, bir tarih ayrıştırma fonksiyonunu önce boş bir gövdeyle isteyince 3 turda doğru sonuca ulaştı. İkinci denemede işlevi 4 satırlık bir yorumla (kabul edilen formatlar, saat dilimi kuralı, hata durumu) tanımlayıp isteyince ilk turda çalışan kod geldi. Aynı model, aynı gün; fark yalnızca niyetin netliğiydi.
Vaka 2 — Sürüm belirtmemek pahalıya patlıyor. Bir ekip, Node.js için üretilen kodda fs.promises yerine eski geri çağırma (callback) tabanlı API'nin gelmesiyle uğraştı. Prompt'a "Node 20, ESM, async/await kullan" satırı eklenince üretim ilk seferde projeye uydu; düzeltme için harcanan ortalama 12 dakika sıfırlandı.
Vaka 3 — Kalıplaşmış kodda gerçek kazanç. Bir mikroservise 6 yeni DTO (Data Transfer Object — katmanlar arası veri taşıyan basit veri sınıfı) ve bunların doğrulama kuralları gerekiyordu. Elle yaklaşık 90 dakikalık iş, AI ile üretilip gözden geçirilince 35 dakikaya indi; kod tekrarı yüksek ve örüntüsü belirgin olduğundan AI burada en verimli olduğu alanda çalıştı.
Dört Kopyalanabilir Şablon
Sözleşme temelli fonksiyon üretimi:
Rol: Titiz bir {{dil}} geliştiricisisin.Fonksiyon sözleşmesi:- İsim: {{ad}}- Girdi: {{tipler ve anlamları}}- Çıktı: {{tip ve anlamı}}- Hata durumu: {{ne zaman ne fırlatılır/döner}}Kısıtlar: {{dış bağımlılık yok / stil / performans}}Örnekler:- {{girdi_1}} -> {{çıktı_1}}- {{girdi_2}} -> {{hata_2}}Önce imza + kısa plan, sonra kod ver. Test yazma, sadece fonksiyon.
Var olan stile uydurmak için (kod tabanına uyum):
Aşağıda projemizden örnek bir fonksiyon var; adlandırma, hata yönetimi veyorum stilini buradan öğren. AYNI stille {{yeni_görev}} için bir fonksiyon yaz.Örnek:{{mevcut_kod}}
İskeletten doldurmaya (stub → implementation):
Aşağıdaki fonksiyon iskeletini, yorumlardaki TODO'lara göre doldur.İmzayı ve dönüş tipini DEĞİŞTİRME. Var olmayan yardımcı fonksiyon uydurma;gerekiyorsa bana "şu yardımcı gerekli" diye bildir.{{iskelet_kod}}
Alternatif uygulama karşılaştırması:
{{görev}} için 2 farklı uygulama ver:(a) okunabilirliği önceleyen, (b) performansı önceleyen.Her birinin altına 1 cümle "ne zaman tercih edilir" not düş.
Zayıf prompt / Güçlü prompt
Zayıf: "Bana bir e-posta doğrulama fonksiyonu yaz."
Güçlü: "TypeScript 5, sadece standart kütüphane. isValidEmail(input: string): boolean yaz. Boşlukları kırp, büyük/küçük harfe duyarsız olsun, a@b.co geçerli, a@, @b.co, boş string geçersiz. Regex kullanacaksan aşırı karmaşık olmasın; 2 satır açıklama ekle."
Güçlü sürüm; dili, sürümü, imzayı, kenar durumları ve bir stil kısıtını verir. Böylece üretilen kod hem çalışır hem de sizin projenize oturur.
Yaklaşım
Ne zaman kullan
Dikkat
Satır içi tamamlama
Akış içinde küçük ekler
Öneriyi okumadan kabul etme
Sohbette sözleşme temelli üretim
Yeni fonksiyon/sınıf
Örnek ve kenar durum ver
Stil örneğiyle üretim
Var olan koda ekleme
Örnek kodu güncel seç
İskelet doldurma
İmza sabit, gövde boş
İmzayı değiştirtme
Kod Tekrarı ve Bağımlılık Tuzağı
AI, işini kolaylaştırmak için sık sık yeni bir kütüphane önerir. Bazen bu isabetlidir, bazen projenize gereksiz bir bağımlılık ekler ya da var olmayan bir paketi (halüsinasyon) önerir. Kural: her yeni bağımlılığı siz onaylayın. Paketin gerçekten var olduğunu, bakımlı olduğunu ve lisansının uygun olduğunu doğrulamadan projeye eklemeyin. Çoğu zaman zaten projede bulunan bir yardımcı, yeni bir paketten daha iyidir.
Dikkat: AI'nın önerdiği import satırlarını gözden geçirin. Var olmayan bir paket adı ("typo-squatting" adı verilen sahte paketlere de benzeyebilir) hem derlemeyi bozar hem de güvenlik riski taşır.
Sık yapılan hatalar
- İmzayı modele belirletmek. Girdi/çıktı tiplerini siz sabitlemezseniz, her üretimde farklı bir imza gelir ve entegrasyon zorlaşır.
- Kenar durumları söylememek. Boş girdi, null, negatif sayı, çok büyük değer — bunları belirtmezseniz model "mutlu yol"u yazar, kenarları atlar.
- Öneriyi test etmeden birleştirmek. Çalışıyor görünen kod, çalıştığı anlamına gelmez.
- Gereksiz bağımlılık kabul etmek. Tek satırlık iş için koca bir kütüphane eklemek teknik borç üretir.
- Stil tutarsızlığı. Projenin geri kalanından farklı adlandırma ve hata yönetimi, kod tabanını yamalı hale getirir.
Özetle
Kod üretimi, niyeti net bir sözleşmeye çevirdiğinizde güçlüdür. Satır içi tamamlamayı küçük ve akış içi işler için, sohbeti yapı kuran işler için kullanın. Girdi/çıktı tiplerini, kenar durumları, sürümü ve stili siz belirleyin; modele örnek verin; her yeni bağımlılığı doğrulayın; ve üretilen her parçayı çalıştırıp okuyun. AI en çok kalıplaşmış, tekrarlı kodda kazandırır — onu tam da orada, sizin belirlediğiniz sınırlar içinde çalıştırın.
Uygulama görevi
Projenizden yazmanız gereken gerçek bir küçük fonksiyon seçin. Önce onu "sözleşme temelli fonksiyon üretimi" şablonuyla, girdi/çıktı tiplerini, iki kenar durumu ve bir stil kısıtını vererek AI'ya yazdırın. Üretilen kodu derleyip iki farklı girdiyle deneyin. Sonra aynı fonksiyonu, bu kez hiç bağlam vermeden "bana şunu yaz" diye tekrar isteyin ve iki çıktıyı satır satır karşılaştırın: hangi kenar durumlar atlandı, kaç düzeltme gerekti?
Kontrol listesi
- [ ] Satır içi tamamlama ile sohbet modunu hangi işte kullanacağımı biliyorum.
- [ ] Fonksiyon üretiminde girdi/çıktı sözleşmesini ve kenar durumları ben belirliyorum.
- [ ] Prompt'a dil ve sürüm bilgisini eklemeyi alışkanlık hâline getirdim.
- [ ] Üretilen her parçayı birleştirmeden önce derleyip deniyorum.
- [ ] AI'nın önerdiği her yeni bağımlılığı var olduğunu ve gerekliliğini doğrulayarak onaylıyorum.
- [ ] Üretilen kodun projenin stiline uyduğunu kontrol ediyorum.