Programcılar için Prompt Engineering Playbook
(addyo.substack.com)- Yapay zeka kodlama yardımcıları geliştiricilerin üretkenliğini artırır, ancak ortaya çıkan çıktıların kalitesi büyük ölçüde prompt engineering kalitesine bağlıdır
- Etkili sonuçlar almak için zengin bağlam, somut hedefler, örnekler, rol tanımı, yinelemeli iyileştirme gibi kurallara uyulmalıdır
- Hata ayıklama, refaktöring, yeni özellik geliştirme gibi başlıca geliştirme işleri için prompt tasarım kalıpları ve örnekleri sunulur
- İyi bir prompt, amaç, dil, ortam, hata mesajları, girdi/çıktı örnekleri gibi somut bilgiler içermelidir
- Yeni mühendislerin bile takip edebileceği bir prompt tasarım yöntemi olarak, gerçek yapay zeka yanıt karşılaştırmaları ve yorumlar içerir
Genel Bakış: Başarılı Prompt Engineering'in Önemi
- Son dönemde geliştiriciler, iş akışlarını hızlandırmak için yapay zeka kodlama asistanlarını kullanarak fonksiyon otomatik tamamlama, hata düzeltme ve hatta tüm modül yazımı gibi işleri yapıyor
- Ancak yapay zekanın yanıt kalitesi, belirleyici biçimde prompt kalitesine bağlıdır
- İyi bir prompt, net ve yaratıcı kod çözümleri üretmeye yönlendirirken; belirsiz veya yetersiz promptlar sınırlı ve anlamsız yanıtlara yol açar
- Bu playbook, günlük geliştirme işlerinde uygulanabilecek etkili prompt tasarımı yöntemlerini pratik biçimde düzenler
Etkili Kod Promptlarının Temel İlkeleri
- Zengin bağlam sağlayın: Yapay zeka projenizi veya niyetinizi önceden bilmez; bu yüzden kullanılan dil, framework, kütüphane, hata mesajı ve kodun amacı gibi ilgili tüm bilgileri açıkça belirtin
- Net bir hedef veya soru belirtin: “Kod neden çalışmıyor?” gibi muğlak sorular yerine, istediğiniz sonucu ve mevcut durumu açıkça tarif edin
- Karmaşık işleri bölün: Büyük ölçekli özellik geliştirme gibi işleri tek seferde istemek yerine, küçük adımlara bölerek aşamalı şekilde talep edin
- Girdi/çıktı örnekleri veya beklenen davranışı ekleyin: Gerçek girdi-çıktı ya da davranış örnekleri vermek, yapay zekanın anlayışını ciddi ölçüde artırır ("few-shot prompting")
- Rol (persona) kullanın: “Kıdemli bir React geliştiricisi gibi kodu incele” veya “bir performans uzmanı gibi optimize et” gibi sorumluluk sahibi roller vererek yapay zekanın yanıt seviyesini yükseltin
- Konuşmalı yinelemeli iyileştirme yapın: Yapay zekanın ilk yanıtını temel alarak ek istekler veya düzeltmelerle adım adım istediğiniz sonuca ulaşın
- Kod tutarlılığını koruyun: Yapay zeka kod stili, isimlendirme ve yorumlardan yararlandığı için kodun tutarlılığını ve açıklığını her zaman koruyun
Hata Ayıklama için Prompt Kalıpları
Sistematik hata ayıklama promptu tasarlama yöntemi
- Sorunu ve belirtileri net anlatın: Dil, özelliğin amacı, beklenen davranış, gerçek hata mesajı ve kod parçacığı gibi zengin bilgiler verin
- Adım adım veya satır satır analiz isteyin: Mantık hataları veya ince bug'larda, “değişkenleri satır satır izle” ya da belirli kod bölümlerini açıklatmak kök nedeni buldurabilir
- Minimum yeniden üretilebilir kod kullanın: Karmaşık ve büyük kod yerine, hatanın ortaya çıktığı en küçük kod birimini çıkararak sorunu odaklı biçimde teşhis edin
- Doğrudan sorular ve devam istekleri sorun: “Bug tam olarak nerede oluşuyor?” veya “Düzeltilmiş kodu ver” gibi açık ve yinelenebilir geri bildirimler isteyin
Örnek: Kötü prompt vs. iyileştirilmiş prompt
Sorunlu kod örneği
function mapUsersById(users) {
const userMap = {};
for (let i = 0; i <= users.length; i++) {
const user = users[i];
userMap[user.id] = user;
}
return userMap;
}
const result = mapUsersById([{ id: 1, name: "Alice" }]);
Kötü prompt:
“mapUsersById fonksiyonu neden çalışmıyor olabilir?”
- Yapay zekanın yanıtı: “Dizi boş olabilir ya da user nesnesinde id olmayabilir” gibi belirsiz tahminler sunar
- Bağlam eksikliği ve muğlaklık nedeniyle yalnızca genel tavsiyeler çıkar
İyileştirilmiş prompt:
“mapUsersById fonksiyonu, kullanıcı dizisini id'ye göre map'lemeli; ancak [ {id: 1, name: "Alice"} ] girdisinde TypeError: Cannot read property 'id' of undefined hatası oluşuyor. Kod şu: [kod dahil] Beklenen sonuç { "1": ... }. Bu durumun nedeni ve çözümü nedir?”
- Yapay zekanın yanıtı: Döngü koşulunun (
i <= users.length) sınırı aştığını ve son iterasyondaundefinedoluştuğunu işaret eder,i < users.lengtholarak düzeltilmesini önerir - Somut bağlam, hata mesajı ve beklenen davranış sağlandığında doğru çözüme ulaşılır
Ek hata ayıklama prompt stratejileri
- Olası bug nedenlerinin listesini istemek (“TypeError'ın olası nedenleri neler?” gibi)
- Kodun çalışma mantığını önce kendiniz açıklayıp inceleme istemek (“Açıklamam doğru mu, sorunu bulur musun?”)
- Kenar durum testleri istemek (“Bu fonksiyonun başarısız olabileceği yalnızca 2 girdi öner”)
- Titiz bir kod gözden geçiren rolü vermek (“Bu kodu inceleyip sorunları ve iyileştirmeleri açıkla”)
Refaktöring/Optimizasyon için Prompt Kalıpları
Net iyileştirme hedefleri belirtin
- “Refaktör et” demek muğlaktır; bunun yerine okunabilirlik, performans, bakım kolaylığı, kod tekrarını azaltma gibi somut hedefleri belirtin
- Tüm kodu (veya gerekli bağlamı), ayrıca ortamı, dili ve framework sürümünü yeterince sağlayın
- Yapılan değişiklikler için açıklama da isteyin (“Kodu ve iyileştirme noktalarını birlikte anlat”)
- “Bir TypeScript uzmanı olarak modern pratiklere uygun şekilde” gibi rol tanımı ile beklenen kalite seviyesini yükseltin
Örnek: Refaktöring promptlarının karşılaştırması
Orijinal kod
(Tekrarlanan fetch, verimsiz veri yapıları vb. sorunlar içerir)
async function getCombinedData(apiClient) {
// Fetch list of users
const usersResponse = await apiClient.fetch('/users');
if (!usersResponse.ok) {
throw new Error('Failed to fetch users');
}
// ... (devamı atlandı)
}
Muğlak prompt
“getCombinedData fonksiyonunu refaktör et”
- Yapay zeka, paralel fetch, hata mesajlarını birleştirme vb. değişiklikleri keyfi olarak yapabilir (gereksinim olmadığı için davranış öngörülemez)
Somut hedef belirten prompt
“Kod tekrarını kaldır, performansı iyileştir, iki fetch işlemini paralelleştir, hata mesajlarını ayır, veri birleştirmeyi daha verimli bir yöntemle geliştir. Yorumlar ve iyileştirme noktalarının açıklamasını da ekle.”
- Yapay zekanın yanıtı: Paralel fetch, hata ayrımı, verimli
mapveri yapısı kullanımı gibi hedefleri açıkça yansıtan bir refaktöring ve ayrıntılı açıklama sunar
Ek refaktöring ipuçları
- Aşamalı istekler yapın (“önce okunabilirliği artır → sonra algoritmayı optimize et” gibi)
- Farklı yaklaşımlar isteyin (“Bunu fonksiyonel tarzda da uygula” gibi)
- Kod + açıklama formatını isteyerek öğrenme ve öğretici kullanım sağlayın
- Ortaya çıkan koda test eklenmesini isteyin
Yeni Özellik Geliştirme için Prompt Kalıpları
Adım adım kod üretimini yönlendirin
- Önce yüksek seviyeli bir açıklama verin (hangi özelliği yapmak istediğinizi anlatın), ardından bunu adım adım ayrıntılandırın
- Mevcut benzer kod, proje kalıpları, kullanılan kütüphaneler gibi çalışma ortamı bağlamını aktarın
- Yorumları veya TODO'ları prompt olarak kullanarak IDE içinde doğrudan yapay zekanın kodlama akışını yönlendirin
- Girdi/çıktı örnekleri veya test vakaları vererek sonuç için net beklentiler oluşturun
- İlk sonuç yetersizse, belirli iyileştirme noktalarını veya kod stilini hemen ekleyip yeniden isteyin
Örnek: React ProductList bileşeni oluşturma
“ProductList adlı bir React fonksiyonel bileşeni oluştur. /api/products üzerinden ürün dizisini alıp liste halinde göster ve giriş alanına ürün adı yazıldığında büyük/küçük harf duyarsız filtreleme yap. Yükleme süreci ve hata yönetimi de gerekli.”
- Yapay zekanın yanıtı:
useState,useEffectile veri fetch etme, girdi işleme, filtreleme, hata ve yükleme UI'ı gibi unsurları içerir - Eğer projede custom hook kullanılıyorsa, “
useProducts()hook'unu kullanacak şekilde refaktör et” şeklinde ek yönergeler yinelenebilir
Gerçek işte promptları geliştirme örnekleri
- “Sıralama özelliği ekle: A-Z, Z-A seçenekli bir dropdown olmalı” gibi kademeli özellik genişletmeleri istenebilir
- Uygulama kod akışı aşamalara bölünüp, her aşama için farklı promptlar verilerek kod kalitesi ve tutarlılığı korunabilir
Sonuç
- Yapay zeka kodlama asistanlarının potansiyelinden en üst düzeyde yararlanmak için prompt tasarımı temel bir yetkinliktir
- Başarılı promptlar yazmak için her zaman somut bağlam, amaç, örnekler, yinelemeli geri bildirim ve rol tanımı akılda tutulmalı; böylece etkili sonuçlar elde edilebilir
- Yapay zekayı proje içindeki junior geliştirici veya kod gözden geçiren gibi düşünerek, istenen yönü ayrıntılı biçimde tarif etmek ve kaliteyi aşamalı olarak yükseltmek başarının anahtarıdır
1 yorum
Hacker News görüşleri
Benim deneyimime göre gerçekten yalnızca üç tane prompt engineering tekniği var
In Context Learning (bağlam içinde örnek verme; yani zero-shot’a karşı one-shot veya few-shot yaklaşımı)
Chain of Thought (adım adım düşünmesini isteme)
Structured output (örneğin JSON gibi çıktı biçimini açıkça belirtme)
Buna bu yazıda geçen Role Prompting de eklenebilir gibi
RAG ise modelin verilen bağlamı özetlemesi şeklinde çalıştığı için ayrı bir kategori
Sonuçta geri kalan her şey, isteneni açık ve sade bir dille istemenin özeti
Prompt’ta en önemli unsur bağlam
Örneğin Typescript ile başlayıp sonra veri bilimi sorusu sorarsanız düzgün cevap veremediğini gördüm
Aynı soruyu Python ile sorunca çok daha iyi sonuç veriyor
LLM’ler hâlâ alanlar arası bilgi aktarımında zorlandığı için, amaca uygun bağlam kurmak şart
Kişisel olarak role prompting’in de anlamlı bir yöntem olmadığını düşünüyorum
GPT-3 döneminde belki öyleydi ama çoğu LLM zaten “uzman” rolünü biliyor
“Prompt engineering” işine fazla kapılmanın insanın kendini kandırması olduğunu düşünüyorum
Gereksinimleri net aktarmak, gerekirse örnek eklemek, çıktıyı veya reasoning trace’i kontrol etmek, istenen sonuç çıkmazsa ayarlayıp tekrar denemek yeterli
Birkaç denemeden sonra da cevap gelmiyorsa, AI yerine kendi kafamla reasoning yapmayı seçiyorum
Sorunun, birçok kişinin “her şeyi tek bir prompt’a sığdırmaya çalışması” olduğu görüşüne katılan çok kişi var
Aslında dev bir isteği tek seferde vermek yerine, küçük bağlamlara bölünmüş birden çok prompt kullanıp her birinden net ve yapılandırılmış çıktılar alarak bunları birbirine bağlamak daha iyi olabilir
Her prompt’ta amaca ve örneklere odaklanın, bağlam aşırı yüklemesinden kaçının
Böylece yukarıda anılan üç temel yöntem doğal olarak uygulanmış olur
Makale bağlantısı
Bu arada bizim ekip prompt engineering’den çok fine-tuning’e dayanıyor
few-shot prompt yaklaşımı bizim kullanım senaryomuzda işe yaramadı
Ben de prompt çok uzun veya karmaşık olduğunda modelin bilişsel performansının düştüğünü sık sık hissediyorum
Karmaşık prompt’lar daha fazla kontrol sağlıyormuş hissi verebilir ama pratikte bu her zaman avantaj olmayabilir
Bu yüzden kullanım biçimim doğal olarak çok basit ve minimal prompt’larla yaklaşık sonucu alıp birkaç kez yineleyerek düzeltmeye evrildi
Ben de tamamen aynı şekilde yaklaşmaya başladım
Bu yöntem maliyet açısından da verimli
Agent kullandığımda defalarca $30 harcayıp kod tabanını karıştırdığına ya da tekrar başlangıçtaki koda döndüğüne şahit oldum
Ayrıca AI’ın projeme fazla kod yazmasına izin verirseniz, o kod sonra zihninizde iyi kalmıyor ve bakımı da zorlaşıyor; buna dikkat etmek isterim
Prompt’u uzman terminolojisiyle yazınca performansın daha iyi olduğuna dair kanıtlar da var
İnsanların günlük dille konuştuğu ortamlarda doğruluk genelde düşüyor ama belirli uzmanlık alanlarının kelime dağarcığı daha güvenilir cevaplara yol açıyor
Eğitim verileri de bu dağılımı yansıtıyor
Benim de benzer bir deneyimim var
Ama agent sistem prompt’larına bakınca çoğu zaman inanılmaz uzun ve karmaşık olduklarını görüyorum; bu da bende soru işareti oluşturuyor
Böyle prompt’ların gerçekte nasıl çalıştığını merak ediyorum
Sistem prompt örneği bağlantısı
Bazı işlerde bir iş arkadaşım aşırı uzun bir prompt kullanmıştı
Entegrasyon sırasında CRUD operation ekledim ve deneme olarak bunu “bunu <meslek grubu> açısından analiz et” gibi çok kısa bir ifadeye çevirdim
Sonuçta iki tarafın çıktıları neredeyse aynıydı; hatta uzun prompt bazen bazı cümleleri çıktıya olduğu gibi geri yazıyordu
Sonuçlar kötü değildi ama modelin (gemini 2.5) esasen önemli bilgileri seçip geri kalan gereksiz parçaları da sonuca kattığı hissi oluştu
Yani en azından bu görevde, uzunluğun modelin “düşünme biçimi” üzerinde ilginç bir etkisi olmadı gibi geldi
Ben de aynı sonuca vardım ama AI laboratuvarlarının paylaştığı uzun prompt örneklerini nasıl yorumlamak gerektiğini merak ediyorum
Anthropic sistem prompt örneği
Bence “prompt engineering” diye ayrı bir şey yok
Anlamlı cümle kurmaya ne zamandan beri engineering deniyor, anlamıyorum
Hatta “software engineering”den bile daha ileri bir örnek
Yine de gelecekte bunun bir meslek olarak (prompt engineer) öne çıkması ve özel bir cümle kurma becerisi gibi sunulması üzücü olabilir
Aslında “doğru ve anlamlı cümle” yazmak çok sayıda değişkene bağlı bir mesele
Gerçekte işin içinde test, yönetim, loglama ve versiyon kontrolü de varsa bu artık sezgiden ibaret değil, engineering oluyor
Belirli sıra/stil/sorunu yeniden ifade etme gibi yapılar çok önemli
Çok parametreli model aileleriyle çalışırken, API tabanlı modellerde her sürüm yükseltmesinde mevcut prompt’ların uyumluluğunu kontrol etmek gerekiyor
Bu kontroller ve testler de prompt engineering sürecinin parçası
Hype’a tepki göstermeye fazla odaklanınca özün gözden kaçırıldığı çok oluyor
Mahallemizdeki barista adına coffee engineer yazsa buna daha çok inanırım
Algoritma bağımlılığı yüzünden günümüz tüketicileri artık cümlelerin tamamını okuma yetisini bile kaybetti
“Prompt engineer” iş ilanları için o kadar da endişelenmeye gerek yok bence
AI sloperator’lar işlerini daha havalı göstermek için ellerinden geleni yapıyor
Benim deneyimimde, LLM’nin çözemediği bir problemi ne kadar prompt “engineering” yaparsanız yapın çoğu zaman sonuç değişmiyor
Çözüm daha çok onu alt problemlere bölüp adım adım ilerletmek oluyor
Tersini yaşamış olan varsa örnek duymak isterim
LLM kullanmanın önemli bir kısmı, problemi uygun şekilde nasıl böleceğinizi sezebilmek
Ne zaman, nasıl böleceğinizi; ne zaman doğrudan bırakacağınızı ayırt edebilmek gerekiyor
Yazıda da dendiği gibi bu tür pratik bilgi önemli
İleride kodu daha iyi organize edip daha iyi yorumlayarak LLM’lerle etkileşimi geliştiren yöntemler de artacaktır
LLM’lerin kendisi de bu yönde gelişiyor ve hatta problemi nasıl bölebileceğimizi önerebilecek hale gelebilir
Prompt engineering’in amacı, istenen biçimde daha hızlı ve daha iyi cevap almak
Nihayetinde modelin bunu kendiliğinden yapmasını isteriz ama pratikte sorunun kendisini de optimize etmek gerekiyor
Prompt yazarken, alışkanlık gereği doğal dille komut vermek bana hâlâ tuhaf geliyor
Sanki her şeyi tam argümanlarla ya da bir SQL sorgusu gibi yazmam gerekiyormuş gibi hissediyorum
Sohbet eder gibi, bir araca konuşur gibi komut vermek de ilginç
Yine de doğal dil komutlarını anlayan bir araca dönüşmesi erişilebilirliği dramatik biçimde artırdı
Buna rağmen prompt’ları insana konuşur gibi yazarken kendime biraz gülüyorum
Son zamanlarda çok fazla prompt rehberi var
Ama bence pratikte pek de gerekli değiller
Aracı bizzat kullanıp ona alışınca ve nasıl kullanılacağını öğrenince, hangi prompt’un iyi olduğunu doğal olarak anlıyorsunuz
Bu bana Google’ın yeni yaygınlaştığı ve FOMO’nun zirvede olduğu dönemi hatırlatıyor
İlgili kitapları almazsan ilkel kalırsın deniyordu ama aslında bir günde öğrenilebilecek kadar basit bir alandı; fazla büyütmeye gerek yoktu
Rehberler ve ipucu videoları bazı insanlara gerçekten yardımcı oluyor
Birçok insan kendi başına gelişmeye istekli değil ama bir kez rehber ya da uzman videosu görmek bile seviyelerini yükseltebiliyor
Ben de başkalarının kullanım biçimlerinden ve topluluk deneyimlerinden sürekli ipuçları öğreniyorum
Sadece tek başına pratik yaparak bu tür ipuçlarını edinmenin sınırları var
Eskiden “kullanıcı hikâyesi yazım rehberi” gibi, “As a [role], I want to [task] so I can [objective]” şeklinde bir formül vardı
Usta ya da acemi fark etmeksizin, çoğu insanın gereksinimleri net iletme konusunda yardıma ihtiyacı var
Ne kadar iyi geliştirici olursa olsun, yapılandırılmamış gereksinimlerde hata yapabilir ya da yanlış anlayabilir
Başkalarının bu araçla nasıl verimlilik sağladığını görmek de oldukça faydalı
Benim gözden kaçırdığım fikirleri de fark ediyorum
Her şeyi deneme-yanılmayla tek tek keşfetmektense, birilerinin önceden yaptığı deneyimlerden biraz olsun öğrenmek daha verimli
Şahsen her şeyi kendim denemeye zaman bulamayan biri olarak, bu tür deneyim paylaşımlarını gerçekten değerli buluyorum
Gözden kaçan küçük numaralar da gerçekten var
Mesela prompt’ta “please” gibi nezaket ifadelerini tamamen çıkarsanız da olur
Uzun zaman önce bilgisayar mühendisliği yüksek lisansında aldığım Science of programming dersindeki doğrulama süreçlerini, veri mühendisliği prompt’ları yazarken oldukça iyi uyguladım
Örneğin “input(…) ve varsayımlar(…) verildiğinde, post-condition(…) koşulunu sağlayan spark kodu yaz” diye istemek
Girdi, varsayım ve sonuç koşullarını açıkça belirtince iyi kod çıktısı alınabiliyor
Başvuru kaynakları
Prompt engineering’e fazla anlam yüklemek gereksiz geliyor
Artık çoğu model, kodu ya da hatayı kopyalayıp yapıştırıp düz bir soru sorduğunuzda zaten iyi iş çıkarıyor
Gereksiz yere dolambaçlı yazmaya ihtiyaç duymuyorum
Birkaç gün önce Sergey Brin, AI topluluğunda çok konuşulmayan bir şey diyerek “fiziksel tehditte bulunmanın model performansını artırdığını” söyledi
İlgili haber
YouTube’daki “Programmers are also human” kanalında profesyonel vibe coder’ın LLM komutlarının sonuna hep “.. yoksa hapse girersin” demesi aklıma geldi
Demek Google “Don't Be Evil” ilkesini sessizce bu yüzden bırakmış olabilir
Prompt yazımına “engineering” demek bana hiç ciddi gelmiyor
Geçmişte prompt “engineering” modayken duyduğum komik bir benzetme vardı
Sonuçta bu tartışma, software engineering konuşuldukça tekrar tekrar ortaya çıkıyor
Belki de sorun, insanların hayal gücünün sohbet arayüzünde kedi fotoğrafı isteme seviyesinde kalmasıdır
Oysa gerçekte API’lerde ve otomasyon iş akışlarında kullanılan prompt’lar da var; yani mesele bundan daha geniş
ABD’de “sales engineer” diye bir unvan da var ama benim deneyimime göre bu insanların çoğu sattıkları ürünün nasıl çalıştığını hiç bilmiyor
IT, kelimelerin ve anlamlarının yok olduğu yer
Hatta bazen kelimelerin gerçekten bir anlama sahip olması gerekip gerekmediğini bile sorgulatıyor