Prompt yazma bir numaradan mühendislik yetkinliğine dönüşüyor. Web, backend ve mobil uygulamalar için pratik kalıplar, araçlar, test ve ekip iş akışlarını öğrenin.
Mühendislikte prompting, “bir yapay-zeka ile sohbet etmek” değildir. Bir asistanı belirli, denetlenebilir bir sonuca yönlendiren inceleme yapılabilir girdiler sağlamaktır—tıpkı bir ticket, spes veya test planı yazmak gibi.
İyi bir prompt genellikle küçük bir paket içerir:
Gerçek projelerde “bir giriş sayfası yap” diye sormazsınız. Bunun yerine “tasarım tokenlarımıza uyan, e-posta formatını doğrulayan, hataları satır içi gösteren ve doğrulama ile submit durumları için birim testleri olan bir giriş formu” gibi spesifikasyon verirsiniz. Prompt, başka birinin inceleyebileceği, düzenleyebileceği ve tekrar kullanabileceği somut bir artefakte dönüşür—çoğu zaman kodla birlikte repoya check-in edilir.
Bu yazı tekrarlanabilir uygulamalara odaklanır: prompt kalıpları, iş akışları, prompt testi ve ekip inceleme alışkanlıkları.
Abartı ve “sihirli sonuçlar”tan kaçınır. Yapay zeka yardımı faydalıdır, ama yalnızca prompt beklentileri açıkça belirttiğinde—ve mühendislerin çıktıyı insan yazılı kodu doğruladıkları şekilde doğruladığında işe yarar.
Prompting, fikirden incelemeye hazır bir şeye ne kadar hızlı geçilebileceğini değiştirdiği için “iyi olur” dan günlük bir mühendislik yetkinliğine dönüşüyor.
AI destekli araçlar UI varyantları taslaklayabilir, API şekilleri önerebilir, test vakaları üretebilir veya logları saniyeler içinde özetleyebilir. Hız gerçek—ama yalnızca promptlarınız çıktıları gerçekten değerlendirebileceğiniz şekilde spesifikse. Bulanık niyeti net talimatlara dönüştürebilen mühendisler saat başına daha kullanılabilir iterasyon alır ve bu sprintler boyunca katlanarak büyür.
Daha fazla iş doğal dile kayıyor: mimari notlar, kabul kriterleri, migration planları, release checklist’leri ve incident özetleri. Bunlar geleneksel spes gibi olmasa da hâlâ "spes"tir. Prompting, bu spesleri belirsizliği azaltacak ve test edilebilir hale getirecek şekilde yazma becerisidir: kısıtlamalar, kenar durumlar, başarı kriterleri ve açık varsayımlar.
İyi bir prompt genellikle küçük bir tasarım brifi gibi okunur:
AI özellikleri IDE’lere, pull requestlere, CI kontrollerine ve dokümantasyon pipeline’larına entegre oldukça, prompting ara sıra yapılan bir sohbet olmaktan çıkar ve günlük mühendislik akışının bir parçası olur. Kodu isteyip sonra testleri isteyecek, sonra risk incelemesi isteyeceksiniz—her adım tutarlı, yeniden kullanılabilir prompt yapısından faydalanır.
Tasarım, ürün, QA ve mühendislik giderek ortak AI araçları üzerinden işbirliği yapıyor. Net bir prompt bir boundary object olur: herkes onu okuyabilir, eleştirebilir ve “bitti”nin ne anlama geldiği konusunda hizalanabilir. Bu paylaşılan netlik yeniden çalışmayı azaltır ve incelemeleri daha hızlı ve sakin hale getirir.
“Bir giriş sayfası yap” gibi belirsiz bir istek modelin ne demek istediğinizi tahmin etmesine zorlar. Test edilebilir bir prompt daha çok mini-spes gibi okunur: girdileri, beklenen çıktıları, kenar durumları ve doğrulama yöntemlerini belirtir.
Sistem ne alıyor ve ne üretmesi gerektiğini yazmakla başlayın.
Örneğin, “formu çalıştır” yerine: “E-posta geçersizse satır içi hata göster ve gönderme devredışı olsun; API 409 dönerse ‘Hesap zaten var’ göster ve girilen değerleri koru.” gibi açık davranış belirleyin.
Kısıtlamalar çıktıyı gerçekliğinizle hizalamanın yoludur.
Şunları dahil edin:
Sadece kod istemek yerine modelden kararları ve alternatifleri açıklamasını isteyin. Bu incelemeyi kolaylaştırır ve gizli varsayımları ortaya çıkarır.
Örnek: “İki yaklaşım öner, sürdürülebilirlik ve performans açısından artı/eksi karşılaştırmasını yap ve önerilen seçeneği uygula.”
Örnekler belirsizliği azaltır; karşı-örnekler yanlış yorumlamayı engeller.
Zayıf prompt: “Kullanıcı güncelleme uç noktası oluştur.”
Daha güçlü prompt: “PATCH /users/{id} tasarla. JSON kabul et { displayName?: string, phone?: string }. Bilinmeyen alanları reddet (400). Kullanıcı bulunmazsa 404. Phone alanını E.164 olarak doğrula. Güncellenmiş kullanıcı JSON’u döndür. Geçersiz telefon, boş payload ve yetkisiz erişim için testler ekle. E-posta değişikliğine izin verme.”
Kural: prompttan birkaç test vakası yazamıyorsanız, henüz yeterince spesifik değildir.
Web promptlama, modeli genç bir ekip arkadaşı gibi ele aldığınızda en iyi sonucu verir: bağlam, kısıtlamalar ve “bitti” tanımı gerekir. UI işi için bu, tasarım kurallarını, durumları, erişilebilirliği ve bileşenin nasıl doğrulanacağını belirtmeyi gerektirir.
“Giriş formu oluştur” demek yerine design system’i ve kenar durumları belirtin:
Örnek prompt: “Button/Input bileşenlerimizi kullanarak bir React LoginForm üret. Submit sırasında loading durumu, satır içi doğrulama ve erişilebilir hata mesajları ekle. Tüm durumlar için Storybook hikâyeleri sağla.”
Refactor’lar, koruyucularla daha sorunsuz gider:
“Bu bileşeni UserCardHeader ve UserCardActions olarak ayır. Mevcut props API’sini sabit tut, CSS sınıf isimlerini koru ve görsel çıktıyı değiştirme. Yeniden adlandırma gerekiyorsa bir migration notu ver.”
Bu, kırılmaları azaltır ve isimlendirme/stil tutarlılığını korur.
Sadece markup değil, mikro-metni ve durum metnini de açıkça isteyin:
“Boş durum, ağ hatası ve yetki reddi için mikro-metni öner. Ton nötr ve kısa olsun. Kopyayı ve nerede göründüğünü döndür.”
Frontend hataları için promptlar kanıt paketlemeli:
“Bu yeniden üretme adımları, console logları ve stack trace verildiğinde, olası nedenleri öner, sonra düzeltmeleri güvene göre sırala. Tarayıcıda ve birim testte nasıl doğrulanacağını ekle.”
Kısıtlamalar ve doğrulama içeren promptlar daha tutarlı, erişilebilir ve incelenebilir UI çıktıları sağlar.
Backend işi kenar durumlarla doludur: kısmi hatalar, belirsiz veriler, retry’ler ve performans sürprizleri. İyi promptlar, sohbet içinde kolayca geçilebilecek ama üretimde başa çıkması zor kararları sabitlemenize yardımcı olur.
“API oluştur” demek yerine modelden gözden geçirilebilir bir kontrat üretmesini isteyin.
İsteyin:
Örnek prompt:
Design a REST API for managing subscriptions.
Return:
1) Endpoints with method + path
2) JSON schemas for request/response
3) Status codes per endpoint (include 400/401/403/404/409/422/429)
4) Pagination and filtering rules
5) Idempotency approach for create/cancel
Assume multi-tenant, and include tenant scoping in every query.
(Bu kod bloğunu çevirtmeyin; içerik değişmeden kalmalıdır.)
Prompt, tutarlı bir doğrulama ve kararlı bir “hata şekli” istemelidir ki istemciler problemleri öngörülebilir şekilde ele alabilsin.
Kullanışlı kısıtlamalar:
Model çoğunlukla doğru ama yavaş kod üretir; performans tercihlerini açıkça isteyin. Trafik, gecikme hedefleri ve veri boyutunu belirleyin, sonra ödünleri isteyin.
İyi eklemeler:
Gözlemlenebilirliği özelliğin bir parçası olarak ele alın. Ölçülecekleri ve harekete geçirecekleri sorularla promptlayın.
Modelden şunu istemesini isteyin:
Mobil uygulamalar sadece “kötü kod” yüzünden başarısız olmaz. Gerçek cihazlar karmaşıktır: ağ kopar, batarya düşer, arka plan kısıtları var ve küçük UI hataları erişilebilirlik sorunlarına dönüşür. Mobil geliştirme için iyi promptlar, modelden özellik değil, kısıtlar için tasarlamasını ister.
“Offline modu ekle” demek yerine ödünleri açıkça belirten bir plan isteyin:
Bu promptlar modeli mutlu yolun ötesine düşünmeye zorlar ve gözden geçirilebilir kararlar üretir.
Mobil hatalar genellikle kullanıcı geri, cihaz döndürme veya derin linkten geri dönme gibi durumlarla ortaya çıkar.
Aşağıdakileri tanımlayan promptlar kullanın:
“Ekranlar ve olaylar şunlar (login → onboarding → home → details). Bir durum modeli ve navigasyon kuralları öner. Process death sonrası durumun nasıl geri yükleneceğini ve çift tıklama/ hızlı geri gezinme durumlarını nasıl ele alacağını belirt.”
Basitleştirilmiş bir akış diyagramı veya rota listesi yapıştırırsanız model geçişler ve test edilmesi gereken hata modlarının bir kontrol listesini üretebilir.
Genel UI tavsiyesi yerine platform-spesifik inceleme isteyin:
“Bu ekranı iOS Human Interface Guidelines / Material Design ve mobil erişilebilirlik açısından incele. Dokunma hedefi boyutları, kontrast, dinamik yazı ölçeklendirme, ekran okuyucu etiketleri, klavye navigasyonu ve haptics kullanımı gibi somut sorunları listele.”
Çökme raporları, stack trace ile bağlam eşleştirildiğinde eyleme dönüştürülebilir:
“Bu stack trace ve cihaz bilgisi (OS sürümü, model, uygulama sürümü, bellek baskısı, yeniden üretme adımları) verildiğinde en olası kök nedenleri, eklenmesi gereken log/metricleri ve güvenli bir düzeltme ile rollout planı öner.”
Bu yapı “Ne oldu?”yu “Sonraki ne yapmalıyız?”a çevirir—mobilde promptlamanın en çok işe yaradığı yer budur.
İyi promptlar tekrar kullanılabilirdir. En iyileri küçük bir spesifikasyon gibi okunur: net niyet, eylem için yeterli bağlam ve kontrol edilebilir çıktı. Bu kalıplar UI iyileştirmede, API şekillendirmede veya mobil çökme ayıklamada işe yarar.
Güvenilir bir yapı:
Bu, web (a11y + tarayıcı desteği), backend (tutarlılık + hata kontratları) ve mobil (pil + cihaz kısıtları) arasında belirsizliği azaltır.
Direkt çıktı, zaten ne istediğinizi bildiğinizde kullanışlıdır: “TypeScript tipi + örnek payload üret.” Daha hızlıdır ve uzun açıklamalardan kaçınır.
Kararların önemli olduğu durumlarda ödünler ve kısa gerekçeler isteyin: pagination stratejisi seçimi, cache sınırları, veya flakey testlerin teşhisi gibi. Pratik orta yol: “Kısa varsayımlar ve artı/eksi açıkla, sonra nihai cevabı ver.”
Promptları mini kontratlar gibi ele alın ve yapılandırılmış çıktı talep edin:
{
"changes": [{"file": "", "summary": "", "patch": ""}],
"assumptions": [],
"risks": [],
"tests": []
}
Bu, sonuçları incelenebilir, diff-dostu ve şema kontrolleriyle doğrulanabilir kılar.
Koruyucuları ekleyin:
Ekip AI’yı düzenli kullanırsa, promptlar “sohbet mesajı” olmaktan çıkar ve mühendislik varlıkları gibi davranır. Promptların kalitesini artırmanın en hızlı yolu onlara kodla aynı muameleyi yapmaktır: net niyet, tutarlı yapı ve değişim izleme.
Sahiplik atayın ve promptları versiyon kontrolünde tutun. Bir prompt değiştiğinde şunu cevaplayabilmelisiniz: neden, ne iyileşti ve ne bozuldu. Hafif bir yaklaşım olarak her repoda bir /prompts klasörü, her iş akışı için bir dosya (ör. pr-review.md, api-design.md) bulundurun. Prompt değişikliklerini pull request’te inceleyin, tıpkı diğer katkılar gibi.
Chat tabanlı bir platform kullanıyorsanız bile (ör. Koder.ai), üretim kodu üreten girdiler şablon olarak versiyonlanmalı veya en azından tekrar kullanılabilir hale getirilmelidir ki ekip sprintler boyunca aynı sonuçları elde edebilsin.
Çoğu ekip aynı AI destekli görevleri tekrarlar: PR incelemeleri, incident özetleri, veri migration’ları, release notları. Bağlamı (context, constraints, definition of done) ve çıktıyı (format, checklist, kabul kriterleri) standardize eden prompt şablonları oluşturun. Bu mühendisler arasındaki varyansı azaltır ve doğrulamayı kolaylaştırır.
İyi bir şablon genellikle içerir:
İnsanların onaylaması gereken yerleri belgeleyin—özellikle güvenlikle ilgili alanlar, uyumluluk değişiklikleri, prod veritabanı düzenlemeleri ve auth/ödeme ile ilgili her şey. Bu kuralları promptun yanına (veya /docs/ai-usage.md gibi bir yere) koyun ki kimse belleğe dayanıp hareket etmesin.
Araçlar destekliyorsa, “güvenli iterasyon” mekaniklerini iş akışına gömün. Örneğin Koder.ai gibi platformlar snapshot ve rollback özellikleri sunarak üretilen değişikliklerle deney yapmayı, diff’leri incelemeyi ve hızlıca geri almayı kolaylaştırır.
Promptlar birinci sınıf varlık haline geldiğinde, tekrarlanabilirlik, denetlenebilirlik ve daha güvenli AI destekli teslimat elde edilir—ekibi yavaşlatmadan.
Promptları diğer mühendislik varlıkları gibi ele alın: eğer onları değerlendiremiyorsanız, iyileştiremezsiniz. “Gibi görünüyor” demek kırılgandır—özellikle aynı prompt bir ekip tarafından tekrar kullanılacaksa, CI’de çalıştırılacaksa veya yeni kod tabanlarına uygulanacaksa.
Promptlar için küçük bir “bilinen girdi → beklenen çıktı” paketi oluşturun. Önemli olan çıktının doğrulanabilir olmasıdır:
Örnek: bir prompt API hata kontratı üretiyorsa aynı alanları, adlandırmayı ve status kodlarını üretmelidir.
Prompt güncellendiğinde, yeni çıktıyı önceki çıktı ile karşılaştırın ve sorun: ne değişti ve neden? Diff’ler regresyonları görünür kılar (eksik alanlar, farklı ton, sıra değişiklikleri) ve inceleyicilerin stili tartışmak yerine davranışa odaklanmasını sağlar.
Promptlar kodla aynı disiplinle test edilebilir:
Eğer bir platform iş akışı üzerinden tam uygulamalar üretirseniz (web, backend, mobil), bu kontroller daha da önemli olur çünkü büyük değişiklik setleri hızlıca üretilebilir. Hız, inceleme verimini artırmalı, titizliği azaltmamalıdır.
Son olarak, promptların gerçekten teslimatı iyileştirip iyileştirmediğini takip edin:
Bir prompt dakika kazandırıyor ama yeniden işi artırıyorsa, “iyi” değil—sadece hızlı demektir.
LLM kullanmak “varsayılan olarak güvenli” kavramını değiştirir. Model hangi detayların gizli olduğunu bilemez ve makul görünen kod güvenlik açıkları içerebilir. AI yardımı, CI, bağımlılık taraması veya kod incelemesi gibi diğer araçlar kadar muhafaza edilmelidir.
Yapıştırdığınız her şeyin bir sohbete kaydedilebileceğini, loglanabileceğini veya incelenebileceğini varsayın. API anahtarları, erişim tokenları, özel sertifikalar, müşteri verileri veya iç URL’leri asla paylaşmayın. Bunun yerine placeholder ve küçük, sentetik örnekler kullanın.
Debug için paylaşmanız gerekirse:
Ekip için bir redaksiyon iş akışı (şablonlar ve kontrol listeleri) oluşturun ki insanlar baskı altında kendi kurallarını icat etmesin.
AI tarafından üretilen kod enjekte riskleri, güvensiz defaultlar, yetkilendirme eksiklikleri, tehlikeli bağımlılık seçimleri ve zayıf kriptografi gibi klasik sorunlar getirebilir.
Pratik bir prompt alışkanlığı modelden kendi çıktısını eleştirmesini istemektir:
Kimlik doğrulama, kriptografi, izin kontrolleri ve erişim yönetimi gibi alanlar için “güvenlik inceleme promptları”nı kabul kriterinin bir parçası yapın. Bunları insan incelemesi ve otomatik kontrollerle (SAST, dependency scanning) eşleştirin. İç standartlarınız varsa, promptta onlara referans verin (ör. “/docs/security/auth içindeki auth yönergelerini uygula”).
Amaç AI’yı yasaklamak değil—güvenli davranışı en kolay hareket haline getirmektir.
Prompting, kişisel bir numara değil ekip becerisi olarak ölçeklendiğinde en iyi sonuç verir. Amaç “daha iyi promptlar” değil—daha az yanlış anlama, daha hızlı inceleme ve AI destekli işlerden daha öngörülebilir sonuçlar almaktır.
Prompt yazmadan önce, ortak bir “bitti” tanımında uzlaşın. “Daha iyi yap”ı denetlenebilir beklentilere çevirin: kabul kriterleri, kodlama standartları, isimlendirme, erişilebilirlik gereksinimleri, performans bütçeleri ve loglama/gözlemlenebilirlik ihtiyaçları.
Pratik bir yol promptlara küçük bir “çıktı kontratı” eklemektir:
Ekipler bunu tutarlı şekilde yaptığında, prompt kalitesi kod gibi incelenebilir hale gelir.
Eşli prompting, eşli programlamaya benzer: biri promptu yazar, diğeri onu inceleyip varsayımları sınar. İnceleyicinin soruları şunlar olabilir:
Bu belirsizliği erken yakalar ve modelin yanlış bir şeyi kendinden emin biçimde yapmasını engeller.
Kod tabanınızdan örneklerle hafif bir prompt playbook’u oluşturun: “API endpoint şablonu”, “frontend bileşen refactor şablonu”, “mobil performans kısıtı şablonu” vb. Bunu mühendislerin zaten çalıştığı yerde (wiki veya repo) saklayın ve PR şablonlarına linkleyin.
Eğer organizasyon tek bir platform kullanıyorsa (ürün + tasarım + mühendislik için), bu şablonları orada da tutun. Örneğin, Koder.ai ekipleri genellikle promptları planlama modu (önce kapsam ve kabul kriterlerinde anlaşma) etrafında standartlaştırır, ardından implementasyon adımları ve testler üretilir.
Bir bug veya incident belirsiz bir prompttan kaynaklanmışsa, sadece kodu düzeltmeyin—prompt şablonunu güncelleyin. Zamanla en iyi promptlar kurumsal hafıza haline gelir, tekrarlayan hataları ve oryantasyon süresini azaltır.
AI promptlamayı benimsetmek geniş çaplı bir “AI inisiyatifi” değil, küçük ve ölçülebilir bir mühendislik değişikliği olarak en iyi çalışır. Dar başlayın, etkiyi ölçün, sonra genişletin.
Her ekip için 3–5 sık tekrarlanan, düşük riskli ve kolay değerlendirilebilir kullanım seçin. Örnekler:
“İyi”nin nasıl göründüğünü yazın (tasarruf edilen süre, daha az hata, daha net dokümantasyon) ki ekip ortak hedefe sahip olsun.
5–10 odaklı prompt şablonu oluşturun ve haftalık iterasyon ile geliştirin. Her şablon kısa ve yapılandırılmış olsun: bağlam, kısıtlamalar, beklenen çıktı ve kısa bir “bitti” tanımı. Şablonları mühendislerin zaten çalıştığı yerde saklayın (repo klasörü, dahili wiki veya ticket sistemi).
Platform yaklaşımını değerlendiriyorsanız, platformun yaşam döngüsünü destekleyip desteklemediğine bakın: uygulama oluşturma, test çalıştırma, deploy etme ve kaynak dışa aktarma. Örneğin, Koder.ai chat ile web, backend ve Flutter uygulamaları oluşturup kaynak kodu dışa aktarma ve dağıtım/host destekleri sunar—promptların sadece snippet değil, tekrarlanabilir build’lere dönüşmesini istediğinizde bu faydalıdır.
Yönetişimi basit tutun ki teslimatı yavaşlatmasın:
Ekiplerin her biri 30 dakikalık oturumlarda bir promptun nasıl somut fayda sağladığını gösteren demolar yapsın. Birkaç metriği takip edin (çevrim süresi azalması, daha az inceleme yorumu, test kapsamı artışı) ve işe yaramayan şablonları emekliye ayırın.
Daha fazla desen ve örnek için /blog. Eğer ekipleri ölçeklendirmek için araç ya da iş akışı değerlendiriyorsanız, /pricing sayfalarını inceleyin.
Bu, bir asistana belirli ve kontrol edilebilir bir sonuç elde etmesi için verilen inceleme yapılabilir girdiler yazmaktır—bir ticket, spesifikasyon veya test planı gibi. Önemli nokta, çıktının yalnızca “güzel görünüyor” demek yerine açık kısıtlamalara ve kabul kriterlerine göre değerlendirilebilmesidir.
Pratik bir prompt genellikle şunları içerir:
Eğer prompttan birkaç test vakası yazamıyorsanız, muhtemelen hâlâ çok belirsizdir.
Bulanık promptlar modelin ürün kurallarınızı, tasarım sisteminizi ve hata semantiğinizi tahmin etmesine zorlar. İstekleri gereksinimlere dönüştürün:
Örnek: bir durumunda ne olacağını, hangi alanların değişmez olduğunu ve her hata için hangi UI metninin gösterileceğini belirtin.
Kısıtlamalar “güzel ama yanlış” çıktıları engeller. Şunları ekleyin:
Kısıtlamalar yoksa model boşlukları kendi varsayımlarıyla dolduracaktır ve bu sisteminizle uyuşmayabilir.
Önceden tasarım ve kalite gereksinimlerini belirtin:
Böylece tasarım sisteminizden sapma azalır ve “tamamlandı” tanımı netleşir, incelemeler hızlanır.
Bir inceleme yapılabilir kontrat istemek için baskı yapın, sadece kod istemeyin:
Geçersiz payloadlar, auth hataları ve boş güncellemeler gibi kenar durumları kapsayan testler isteyin.
Gerçek cihaz kısıtlamalarını ve hata modlarını dahil edin:
Mobil promptları akışları ve kurtarma yollarını tanımlamalı; sadece mutlu yolu değil.
Direkt çıktı, neye ihtiyacınız olduğunu biliyorsanız hızlıdır (ör. “TypeScript tipi + örnek payload üret”). Kararların önemli olduğu durumlarda trade-off’ları isteyin (pagination, caching sınırları, flaky test tespiti).
Pratik bir orta yol: kısa bir varsayımlar ve artı/eksi listesi isteyin, ardından nihai çıktıyı (kod/kontrat/testler) verin.
Yapılanı yapısal ve lintlenebilir çıktı isteyerek sözleşmeye benzetin. Örneğin:
changes, assumptions, risks, tests içeren JSONYapılandırılmış çıktı belirsizliği azaltır, regresyonları görünür kılar ve CI’de şema doğrulaması sağlar.
Sızıntıyı ve riskli çıktıları azaltan prompt ve iş akışları kullanın:
409AI çıktısını diğer kodlar gibi değerlendirin: incelemeye ve doğrulamaya tabi olmadan güvenilmez.