Yapay zekâyla kodlayın — ama sorumlu biçimde

Bu modülün en önemli mesajı baştan net olsun: YZ güçlü bir araçtır, ama bir araçtır — onu bir "her şeyi bilen otorite" değil, "hızlı ama bazen yanılan bir stajyer" gibi düşün. Çok iş çıkarabilir, ama her çıktısını sen kontrol etmelisin. Bu seride öğrendiğin tüm temeller (HTML/CSS/JS, algoritma, veritabanı, güvenlik, yayınlama) burada paha biçilmez hâle gelir: YZ'nin önerisini ancak konuyu anlıyorsan değerlendirebilirsin. Konuyu bilmeyen biri için YZ tehlikelidir (yanlışı fark edemez); konuyu bilen biri için ise muazzam bir hızlandırıcıdır. Bu yüzden YZ, öğrenmenin yerini almaz — onu güçlendirir. Modül boyunca tekrar tekrar göreceğin ilke şudur: YZ önerir, insan karar verir. Her bölümdeki "önce doğrula" kartı bu yüzden var.

Bu basitleştirilmiş bakış, YZ'nin hem gücünü hem zayıflığını açıklar. Gücü: o kadar çok kod görmüştür ki, yaygın kalıpları (bir döngü nasıl yazılır, bir API nasıl çağrılır) şaşırtıcı isabetle üretir. Zayıflığı: "anlamadığı" için, akla yatkın ama yanlış şeyler de üretebilir — çünkü amacı "doğru olmak" değil, "olası/akıcı görünmek"tir. İşte halüsinasyonun (sonraki bölümlerde) kök sebebi budur: var olmayan bir fonksiyon, yanlış bir parametre veya hatalı bir mantık, tıpkı gerçeği gibi özgüvenle sunulabilir. Bu yüzden YZ'nin "kendinden emin" görünmesi, doğru olduğu anlamına gelmez. Ayrıca YZ'nin bilgisi eğitildiği ana kadarıdır; çok yeni kütüphaneleri veya değişiklikleri bilmeyebilir. Bunu anlamak, sana en önemli alışkanlığı kazandırır: özgüvenli bir çıktı bile doğrulanmalıdır.

Üç türün ortak ilkesi aynı: ne kadar otonom, o kadar dikkat. Tamamlama araçları küçük öneriler sunar (bir satır, bir fonksiyon) — sen yazarken görür ve kabul/ret edersin, kontrol nispeten kolaydır. Sohbet asistanları daha büyük parçalar üretir ve diyalog kurarsın; çıktıyı bütün olarak değerlendirmen gerekir. Ajanlar en güçlü ama en riskli türdür: bir hedef verirsin, onlar birçok adımı (dosya değiştirme, komut çalıştırma, hatta yayınlama) kendi başlarına yapabilir. Ajanlar zaman kazandırır ama denetimsiz bırakılırsa ciddi zarar verebilir (yanlış dosyayı silmek, hatalı kodu uygulamak). Bu yüzden ajanlarla çalışırken onay kapıları koymak ve ne yaptıklarını adım adım izlemek şarttır. Hangi türü kullanırsan kullan, "önce doğrula" ilkesi değişmez — yalnızca doğrulamanın kapsamı, aracın otonomisiyle birlikte büyür.

İyi istemin sırrı, YZ'ye net bir hedef ve yeterli bağlam vermektir. Dört parçayı düşün: Görev (tam olarak ne yapılsın — tek ve net bir iş), Bağlam (hangi dil/çerçeve, ilgili kod, ne amaçla), Kısıt (uyulması gereken kurallar: stil, sürüm, güvenlik, "şunu yapma"), ve varsa Örnek (beklenen girdi/çıktı). Belirsiz bir istem ("bir şeyler yap"), YZ'yi tahmin etmeye zorlar ve genelde işine yaramayan bir sonuç çıkar. Pratik ipuçları: küçük ve net iste (devasa tek bir istem yerine adım adım), kısıtları açıkça söyle (özellikle "şunu yapma"ları), ve sonuç istediğin gibi değilse düzeltici geri bildirimle tekrar dene ("bu iyi ama şu kısmı şöyle değiştir"). İyi istem yazmak, YZ'yle çalışmanın en pratik becerisidir — ve Seviye 4'te buna "istem mühendisliği" olarak daha derin bakacağız. Ama unutma: en iyi istem bile doğrulamayı ortadan kaldırmaz; sadece daha iyi bir başlangıç noktası verir.

YZ'nin en sık hayal kırıklığı yaratan davranışı, aslında yetersiz bağlamdan kaynaklanır: "neden çalışmıyor?" diye sorarsan, kodu görmeyen YZ tahmin etmek zorunda kalır ve genelde işe yaramaz. Ona ilgili kodu, tam hata mesajını ve ne yapmaya çalıştığını verirsen, çok daha isabetli yardım alırsın. Ancak bağlam verirken kritik bir denge vardır: faydalı bağlam ver, ama hassas bilgi verme. Sırları (parolalar, API anahtarları), kişisel verileri (KVKK kapsamındakiler) veya şirketin gizli kodunu bir YZ aracına yapıştırmak ciddi bir güvenlik/gizlilik riskidir (Seviye 3'te derinleşeceğiz) — çünkü o veri nereye gittiğini ve nasıl kullanıldığını bilmediğin bir sisteme aktarılır. Bu yüzden bağlamı temizle: gerçek anahtarları örnek değerlerle değiştir, kişisel verileri çıkar, yalnızca sorunu anlatmaya yetecek kadarını ver. "İlgili ama güvenli bağlam" altın kuraldır.

"Çalışıyor gibi görünüyor" ile "doğru ve güvenli" arasında büyük fark vardır. YZ'nin ürettiği kod akıcı ve ikna edici görünebilir ama gizli hatalar, güvenlik açıkları veya senin durumuna uymayan varsayımlar içerebilir. Bu yüzden altın kural: anlamadığın kodu projene koyma. Üretilen kodu okurken kendine sor: Bu satır tam olarak ne yapıyor? Neden böyle yazılmış? Bir güvenlik riski var mı (Seviye 3)? Gereksiz/şişkin mi? Benim durumuma uygun mu? Eğer bir kısmı anlamıyorsan, YZ'ye açıklatabilirsin ("bu satır ne yapıyor?") — bu hem güvenliği artırır hem öğretir. Anlamadan kabul etmenin iki büyük zararı vardır: (1) gizli hatalar/açıklar projene sızar, (2) sen öğrenmezsin ve bağımlı hâle gelirsin (Seviye 3'teki "aşırı bağımlılık"). Üretilen kodu okumak, YZ'yi bir "kara kutu" olmaktan çıkarıp gerçek bir öğrenme ve hızlanma aracına dönüştürür. Sen kodun sahibisin; ne koyduğunu bilmelisin.

Halüsinasyon, YZ'nin "anlamadan tahmin etme" doğasının (Bölüm 2) doğrudan sonucudur: akla yatkın görünen ama gerçek olmayan bir şey üretir — var olmayan bir kütüphane fonksiyonu, yanlış bir API kullanımı, uydurma bir istatistik veya hatalı bir mantık. En sinsi yanı, bunu tıpkı doğruymuş gibi, özgüvenle sunmasıdır. Çözüm tek kelimedir: doğrulama. Pratik doğrulama yolları: kodu çalıştır ve test et (en kesin yol — gerçekten çalışıyor mu?), resmî dokümana bak (bu fonksiyon/parametre gerçekten var mı?), kendi bilginle kontrol et (mantık doğru mu?), ve kritik gerçekleri ikinci bir kaynaktan teyit et. Asla "YZ söyledi, doğrudur" deme — özellikle kesin bir gerçek, bir komut, bir güvenlik kararı veya bir kütüphane kullanımı söz konusuysa. Diyagramdaki döngü bu modülün özüdür: İstem → YZ üretir → İNSAN doğrular → kabul/düzelt. Doğrulama bir engel değil, YZ'yi güvenle hızlı kılan şeydir. Doğrulanmamış YZ çıktısı, kontrol edilmemiş bir varsayımdır.

"İnsan döngüde" (human-in-the-loop) ilkesi, sorumlu YZ kullanımının temelidir: YZ önerir, ama her kritik kararı bir insan onaylar. Bu yalnızca teknik değil, etik ve yasal bir gerçektir: bir kod hata yaparsa, bir güvenlik açığı kullanıcıları zarara uğratırsa veya bir karar birini mağdur ederse, sorumluluk "YZ söyledi" diyerek kaçılabilecek bir şey değildir — sorumluluk, o çıktıyı kabul eden insandadır. Bu yüzden YZ'yi, sorumluluğu devredebileceğin bir merci değil, hızlandıran bir asistan olarak gör. Otonomi arttıkça (özellikle ajanlarda) insan denetimi azalmaz, daha kritik hâle gelir: ne kadar çok şeyi YZ'ye bırakıyorsan, kontrol kapıların o kadar net olmalı. Bu ilke, bu modülün geri kalanının çerçevesidir — günlük kullanımda (Seviye 2), güvenlik ve gizlilikte (Seviye 3), ve olgun çalışmada (Seviye 4) hep aynı merkez döner: YZ önerir, insan karar verir ve sorumluluğu taşır. Bu, YZ'yi güçsüzleştirmez; onu güvenle güçlü kılar.

Kod yazımında YZ, en çok zaman kazandıran ama en kolay kötüye kullanılan alandır. İyi kullanım: tekrarlayan kalıpları (bir döngü iskeleti, bir veri dönüşümü), bildiğin ama yazması sıkıcı şeyleri ve hızlı taslakları YZ'ye yazdırıp kontrol ederek hızlanmak. Kötü kullanım: anlamadığın karmaşık kodu körü körüne kabul edip projeye gömmek. Pratik denge: YZ'yi küçük, doğrulanabilir parçalar için kullan (büyük, anlaşılmaz bir blok yerine). Gelen her parçayı, kendin yazmış gibi sahiplen — çünkü artık senin sorumluluğunda. Özellikle kenar durumları (boş girdi, hata, sınır değerler) ve güvenliği (girdi doğrulama — Seviye 3) kontrol et; YZ bunları sıklıkla atlar veya basitleştirir. Unutma: YZ ile hızlı kod yazmak, hızlı doğru kod yazmak değildir — ikisini buluşturan şey senin doğrulamandır.

Öğrenme, YZ'nin en parlak olduğu alandır çünkü burada çıktıyı doğrudan üretime koymazsın — anlamak için kullanırsın, dolayısıyla risk düşüktür ve fayda yüksektir. YZ'ye anlamadığın bir kodu açıklattırabilir ("bu satır ne yapıyor?"), bir kavramı farklı düzeylerde sorabilir ("bunu daha basit anlat"), veya bir hatanın kök sebebini öğrenebilirsin. Bu, sabırlı, yargılamayan ve 7/24 erişilebilir bir öğretmen gibidir. Ama kritik bir incelik var: YZ öğretirken de halüsinasyon yapabilir — yanlış bir açıklama, uydurma bir "kural" veya eski bir bilgi verebilir. Bu yüzden öğrendiğin kritik şeyleri (özellikle bir gerçeği, bir güvenlik kuralını, bir API davranışını) resmî kaynaktan teyit et. En sağlıklı kullanım: YZ'yi "hızlı kavrama" için kullan, sonra önemli noktaları güvenilir dokümanla pekiştir. Bu, hem hızlı öğrenmeni hem yanlış öğrenmemeni sağlar. YZ öğrenmeni hızlandırır; ama neyi öğrendiğinin doğruluğundan yine sen sorumlusun.

YZ hata ayıklamada gerçekten yardımcıdır çünkü çok sayıda benzer hata görmüştür ve hızlıca olası sebepler önerebilir — bu, "nereye bakacağını bilememe" tıkanıklığını aşmana yardım eder. İyi kullanım için: tam hata mesajını ver (özetleme — tam metin altın değerindedir), ilgili kodu ekle ve ne beklediğini söyle. Ama iki tuzağa dikkat et: (1) Körü körüne yama: YZ'nin önerdiği çözüm hatayı "susturabilir" ama gerçek sebebi çözmeyebilir (hatta yeni hata ekleyebilir) — bu yüzden sebebi anla, sadece belirtiyi değil. (2) Doğrulamadan uygulama: önerilen çözümü test et; gerçekten çalıştığını ve başka bir şeyi bozmadığını gör. En değerli sonuç, hatanın çözülmesi kadar neden çözüldüğünü anlamandır — bu seni bir sonraki hatada daha güçlü kılar. YZ'yi bir "düşünme ortağı" gibi kullan (hipotez üreten), kararı sen ver. Ayrıca: hata ayıklarken paylaştığın koda da dikkat — sır veya kişisel veri içeriyorsa temizle (Seviye 3).

YZ'yi bir kod inceleme yardımcısı olarak kullanmak değerlidir: yazdığın koda "bunu nasıl iyileştirebilirim?", "bir güvenlik riski var mı?", "daha okunur olabilir mi?" diye sorabilirsin. İnsan inceleme (Modül 14'teki PR) yerine geçmez ama onu tamamlar — özellikle tek başına çalışıyorsan değerli bir "ikinci göz" sağlar. Ancak YZ'nin her önerisi iyi değildir: bazı önerileri gereksiz karmaşıklık ekler, bazıları senin bağlamına uymaz, bazıları "moda" ama faydasızdır. Bu yüzden önerileri değerlendirerek al: her birini "bu gerçekten daha mı iyi yapıyor, neden?" diye sorgula, mantıklı olanı seç, uygulamadan önce test et. Özellikle güvenlik iyileştirmeleri için YZ faydalı bir kontrol listesi sunabilir (Seviye 3) ama yine doğrula. İyi bir refactoring (yeniden düzenleme) kuralı: davranışı değiştirmeden iyileştir ve her adımdan sonra test et — YZ ile çalışırken bu daha da kritik, çünkü YZ bazen "iyileştirirken" davranışı sessizce değiştirebilir.

Test yazımı, YZ'nin gerçekten yardımcı olduğu bir alandır çünkü test kodu genelde tekrarlayan ve şablon ağırlıklıdır — YZ hızlıca bir iskelet üretebilir, sen de zihinsel enerjini "neyi test etmeliyim?" sorusuna ayırabilirsin. Ama kritik bir tuzak var: YZ genelde "mutlu yolu" (her şeyin yolunda gittiği durumu) test eder ve asıl önemli olan kenar durumları (boş girdi, sıfır, negatif, çok büyük değer, geçersiz tür, hata koşulları) sıklıkla atlar — oysa hatalar tam da buralarda saklanır. Bu yüzden YZ'nin ürettiği testleri bir başlangıç olarak al, sonra kapsamı sen tamamla: "hangi durumda bu kod bozulabilir?" diye düşünüp eksik testleri ekle. Ayrıca dikkat: bir testin var olması, doğru şeyi test ettiği anlamına gelmez — YZ bazen yanlış bir beklentiyi test eden, yani hatayı "onaylayan" testler yazabilir. Bu yüzden her testin doğru davranışı kontrol ettiğini sen doğrula. Test, kodun güvencesidir; o güvencenin kendisi de güvenilir olmalı.

Dokümantasyon ve yorum yazımı, YZ'nin güzel bir yardımcı olduğu ama dikkat gerektiren bir alandır. İyi tarafı: YZ, bir fonksiyona bakıp ne yaptığını özetleyen bir açıklama, parametre listesi veya kullanım örneği taslağı üretebilir — bu, "boş sayfa" zorluğunu aşar. Dikkat edilecek: YZ kodun ne yaptığını tahmin eder; eğer kodu yanlış yorumladıysa, doküman da yanlış olur — ve yanlış doküman, hiç dokümandan kötüdür (insanları yanlış yönlendirir). Bu yüzden ürettiği açıklamanın kodu gerçekten doğru anlattığını kontrol et. İki tuzak daha: (1) "Neyi" anlatan gereksiz yorumlar — YZ bazen kodun aynısını tekrarlayan yorumlar üretir ("i'yi bir artır" gibi); iyi yorum "ne" değil "neden"i açıklar. (2) Bayatlama — doküman kodla birlikte güncellenmeli; YZ ile hızlı üretmek, güncel tutma sorumluluğunu kaldırmaz. En iyi kullanım: YZ'yi ilk taslak için kullan, sonra doğruluk, sadelik ve "neden"e odaklanarak insan eliyle rafine et. Doküman senin adına konuşur; doğru ve net olduğundan emin ol.

Bu, bu serinin güvenlik bilincinin (Modül 7-12-14) YZ tarafıdır ve kritiktir: YZ'nin ürettiği kod "çalışıyor" diye güvenli sanma. YZ, güvenliği özel olarak istemediğin sürece çoğu zaman düşünmez ve eğitim verisindeki — bir kısmı güvensiz — kalıpları üretir. Sık riskler: girdi doğrulama eksikliği (kullanıcı girdisini doğrudan kullanmak → SQL enjeksiyonu, XSS; Modül 7-8'deki parametreli sorgu/temizleme ilkelerini YZ atlayabilir), savunmasız bağımlılıklar (YZ eski veya açığı olan bir paket önerebilir — bilgisi güncel olmayabilir), sır gömme (örnek diye koda gerçekçi anahtarlar yazma) ve aşırı yetki. Korunma: üretilen kodu güvenlik gözüyle de incele, YZ'den açıkça güvenlik iste ("girdiyi doğrula", "parametreli sorgu kullan"), bağımlılıkları tara (Modül 14) ve kritik güvenlik kodunu mutlaka insan ve araçlarla denetle. YZ güvenlik için faydalı bir yardımcı olabilir (açık aramak, öneri sunmak) ama güvenliğin sorumlusu değildir — o sensin. Güvenlik, "çalışıyor mu?"dan ayrı ve daha derin bir sorudur.

Bu, sorumlu YZ kullanımının en kritik kurallarından biridir ve doğrudan Modül 7-12-14'teki güvenlik/gizlilik ilkelerinin ve KVKK'nın uzantısıdır. Temel gerçek: bir YZ aracına yazdığın her şey, senin kontrolünden çıkıp üçüncü bir tarafın sistemine gider; orada nasıl saklandığını, kimin gördüğünü veya gelecekte nasıl kullanılacağını tam bilemezsin. Bu yüzden şunları asla yapıştırma: sırlar (parolalar, API anahtarları, tokenlar), kişisel veriler (gerçek isimler, TCKN, e-posta, telefon, adres, sağlık/finans verisi — KVKK kapsamı), ve gizli şirket kodu/verisi (ticari sırlar, müşteri verisi). Bunun yerine: kodu/sorunu temizleyerek paylaş — gerçek anahtarları ORNEK_ANAHTAR ile, kişisel verileri temsilî değerlerle değiştir, yalnızca sorunu anlatmaya yetecek kadarını ver. Kurumsal ortamlarda genelde YZ kullanım politikaları vardır (hangi aracın kullanılabileceği, neyin paylaşılabileceği — Seviye 4); bunlara uy. KVKK açısından: kişisel veriyi izinsiz bir YZ'ye aktarmak bir veri ihlali olabilir ve yasal sorumluluk doğurur. Kural basit: emin değilsen, paylaşma.

Bu, henüz net kurallara tam oturmamış, gelişen bir alandır; bu yüzden amaç kesin hukuki cevaplar vermek değil, farkında olmanı sağlamaktır (ben bir hukukçu değilim; ciddi durumlarda hukuki danışmanlık alınmalı). Temel gerçek: YZ, milyonlarca satır kamuya açık kod üzerinde eğitilmiştir ve farklı lisanslara (kimi serbest, kimi kısıtlı) sahip bu kodlardan öğrendiği örüntüleri üretir. Çoğu zaman ürettiği kısa/yaygın parçalar bir sorun teşkil etmez, ama uzun veya özgün bir bloğu neredeyse birebir üretmesi teorik olarak mümkündür ve bu, bir başkasının lisanslı kodunu farkında olmadan kullanmana yol açabilir. Pratik yaklaşım: kısa, yaygın kalıplar için genelde endişelenme; büyük, özgün veya kritik bir blok için, tanıdık/şüpheli geliyorsa kaynağını araştır. Kurumsal ortamda mutlaka şirketinin YZ ve lisans politikasına uy (bazı kurumlar üretilen kodun kullanımına kurallar koyar). Ayrıca: ürettiğin işte YZ'nin payını şeffafça belirtmek (ekip/proje kurallarına göre) iyi bir uygulamadır. Özetle: lisans belirsizliğinin farkında ol, şüphedeysen araştır veya danış.

YZ'yi olgunca kullanmak, sınırlarını bilmekle başlar. (1) Önyargı: YZ, eğitildiği verideki — yani insanların ürettiği metin ve koddaki — önyargıları yansıtabilir. Bu kodda "yaygın ama kötü" alışkanlıkları üretmek olarak görünebileceği gibi, daha geniş bağlamlarda (örneğin insanları sınıflandıran bir sistem yazarken) ayrımcı sonuçlar üretmeye de yol açabilir — bu yüzden insanları etkileyen kararlar üreten kodda özellikle dikkatli ol. (2) Eski bilgi: YZ'nin bilgisi eğitildiği ana kadarıdır; çok yeni kütüphaneleri, sürümleri veya değişiklikleri bilmeyebilir, hatta kaldırılmış/değişmiş bir şeyi hâlâ "doğru" sanabilir. (3) Sınırlı bağlam: YZ senin projenin tamamını, ekip kararlarını, iş kurallarını görmez — yalnızca verdiğin kadarını bilir. (4) Genelleme: "ortalama" bir çözüm üretir; senin özel, kenar veya alışılmadık durumuna uymayabilir. Bu sınırların hiçbiri YZ'yi işe yaramaz kılmaz — ama nerede temkinli olacağını söyler: yeni teknolojiler, insanları etkileyen kararlar, özel/karmaşık bağlamlar ve "herkese uyan" görünen çözümler için fazladan doğrula. Sınırlarını bilmek, aracı daha iyi kullanmaktır.

Bu, özellikle öğrenme aşamasındakiler için kritik bir dengedir. YZ o kadar yardımcıdır ki, düşünmeyi ona devretme tuzağına düşmek kolaydır: her sorunu sormak, her kodu anlamadan kabul etmek, hiç zorlanmamak. Sorun şu: zorlanmak, öğrenmenin nasıl gerçekleştiğidir — bir problemi kendin çözmeye çalışmak (başarısız olsan bile), beyninde YZ'nin asla kuramayacağı bağlantılar kurar. Her şeyi YZ'ye yaptıran biri, kısa vadede hızlı görünür ama uzun vadede: (1) temel becerileri gelişmez, (2) YZ'nin yanlışını fark edemez (çünkü kendisi bilmez), (3) YZ olmadan çaresiz kalır. Sağlıklı denge: önce kendin dene/düşün, sonra YZ'ye danış; üretileni anlayarak kullan; ara sıra YZ olmadan çalışıp becerini koru; YZ'yi "benim yerime yapan" değil "bana öğreten ve hızlandıran" olarak kullan. Özellikle öğrenirken, bazı şeyleri zahmetli de olsa kendin yapmak bir yatırımdır. YZ en çok, güçlü bir temeli olan kişinin elinde değer kazanır — çünkü o kişi onu yönlendirebilir, değerlendirebilir ve yanılgılarını yakalayabilir. Amacın YZ'siz çaresiz kalmak değil, YZ'yle daha güçlü olmak.

Doğrulama "her şeyi her zaman aynı şekilde kontrol et" demek değildir; çıktının türüne göre doğru aracı seçmektir. Kod için en kesin doğrulama çalıştırıp test etmektir — gerçekten işliyor mu, kenar durumlarda ne yapıyor, başka bir şeyi bozuyor mu? Bir gerçek veya iddia için (bir fonksiyonun varlığı, bir API'nin davranışı, bir "en iyi uygulama") resmî dokümana bak ve mümkünse ikinci bir bağımsız kaynaktan teyit et. Bir karar veya tasarım önerisi için kendi muhakemeni, deneyimini ve gerekirse bir uzmanın görüşünü kullan — çünkü "en iyi" çözüm bağlama bağlıdır ve YZ senin tüm bağlamını bilmez. Doğrulamanın derinliği riske göre ölçeklenir: kritik bir güvenlik kodu, bir ödeme mantığı veya insanları etkileyen bir karar için doğrulama çok daha titiz olmalı; deneme amaçlı küçük bir script için daha hafif olabilir. Altın kural değişmez: doğrulanmamış YZ çıktısı, bir varsayımdır — onu bir gerçek gibi kullanmadan önce kanıtla. Bu refleks, seni "YZ'ye kanan" biri olmaktan "YZ'yi ustaca kullanan" biri olmaya taşır.

İstem mühendisliği "sihirli kelimeler" bulmak değil, YZ'ye iyi düşünme malzemesi vermektir. En etkili teknikler: (1) Net ve tek görev — bir istemde tek bir iş iste; "şunu yap, ayrıca bunu, bir de onu" demek karışık sonuç verir. (2) Bağlam ve örnek ver — ilgili kodu, hedefi ve mümkünse beklenen girdi/çıktı örneğini göstermek (buna "örnekle yönlendirme" denir) isabeti çok artırır. (3) Adımlara böl — karmaşık bir görevi tek seferde istemek yerine parçalara ayır; YZ'ye "önce şunu planla, sonra uygula" demek ("adım adım düşün") daha tutarlı sonuç verir. (4) Rol/çerçeve ver — "deneyimli bir güvenlik gözüyle incele" gibi bir çerçeve, çıktının odağını ayarlar. (5) İteratif düzelt — ilk sonuç nadiren mükemmeldir; "bu iyi ama şu kısmı şöyle yap" diyerek rafine et. (6) Kısıtları açıkça söyle — "şunu kullanma", "şu sürüme uygun olsun", "güvenli olsun". Bu teknikler sonucu iyileştirir ama bir şeyi değiştirmez: çıktıyı yine doğrularsın. İyi istem, doğru cevabı garanti etmez — sadece olasılığını yükseltir ve gidip gelmeyi azaltır. İstem mühendisliği, YZ'yi daha verimli bir ortak yapar; doğrulama ise onu güvenli yapar.

Ajanlar, YZ'nin en güçlü ve en riskli biçimidir. Güçlüdür çünkü bir hedefi (örneğin "şu özelliği ekle ve test et") çok adımda kendi başına yürütebilir — planlar, dosya değiştirir, komut çalıştırır. Risklidir çünkü otonomi, hata yapma kapasitesini de büyütür: yanlış bir adım artık tek bir öneri değil, gerçekleştirilen bir eylemdir (yanlış dosyayı silmek, hatalı kodu uygulamak, istenmeyen bir komut çalıştırmak). Bu yüzden ajanlarla çalışırken denetim azalmaz, en kritik hâle gelir. Güvenli kullanım: onay kapıları koy (özellikle dosya silen, komut çalıştıran, yayınlayan adımları ajan yapmadan önce sen onayla); kapsamı sınırla (ajanın erişimini ve yetkisini gerektiği kadar tut — en az yetki ilkesi); her adımı izle (ne yaptığını adım adım takip et, "kara kutu" gibi bırakma); ve güvenli bir ortamda dene (geri alınabilir, izole bir alanda — üretimde değil). Ajanlar muazzam zaman kazandırabilir ama "ayarla ve unut" zihniyetiyle değil. Otonomi arttıkça insan sorumluluğu kaybolmaz; yalnızca denetimin şekli değişir — tek tek satırları değil, eylemleri ve onları onaylamayı denetlersin. En güçlü araç, en dikkatli eli gerektirir.

Bir ekipte veya kurumda YZ kullanımı, bireysel kullanımdan daha fazla yapı gerektirir çünkü riskler de paylaşılır (birinin sır sızdırması tüm kurumu etkiler). İyi bir YZ politikası şunları netleştirir: Hangi araçlar onaylı? (her YZ aracı aynı gizlilik/güvenlik garantisini vermez; kurum belirli araçları onaylayabilir, özellikle veri işleme konusunda). Ne paylaşılabilir, ne paylaşılamaz? (Seviye 3'teki sır/KVKK kuralları kurumsal düzeyde tanımlanır — müşteri verisi, gizli kod asla; genel sorular serbest olabilir). Çıktılar nasıl denetlenir? (YZ ile üretilen kod da insan incelemesinden — Modül 14'teki PR'dan — geçmeli; "YZ yazdı" denetimi atlamaz). Sorumluluk kimde? (çıktıyı kullanan kişi sorumludur, net olmalı). Eğitim: ekip, sorumlu kullanım (doğrulama, gizlilik, sınırlar) konusunda bilgilendirilmeli — bu modülün öğrettikleri gibi. İyi politika YZ'yi yasaklamaz (faydası büyük) ama çerçeveler: faydayı serbest bırakırken riski yönetir. Eğer bir kurumda çalışıyorsan, mevcut YZ politikasını öğren ve uy; yoksa, ekibinle birlikte basit bir tane oluşturmak değerli bir adımdır. Ortak kurallar, herkesin YZ'den güvenle yararlanmasını sağlar.

Olgun bir YZ kullanıcısı, "YZ'yi her yere koymak" ile "YZ'yi hiç kullanmamak" arasında akıllı bir denge kurar — işin türüne göre. YZ'nin iyi uyduğu işler: taslak/iskelet üretmek, tekrarlayan/şablon kod, açıklama ve öğrenme, hata ayıklama için fikir üretme, dokümantasyon taslağı — yani insanın yönlendirip doğrulayabileceği, hata maliyeti düşük, hızlandırılabilir işler. Dikkatli kullanılacak işler: üretim kodu, testler, güvenlik kodu — YZ yardımcı olur ama her çıktı titizlikle doğrulanmalı. İnsana bırakılması gereken işler: mimari ve tasarım kararları (geniş bağlam ve deneyim ister), etik veya insanları etkileyen kararlar (sorumluluk insanda olmalı), kritik güvenlik/sorumluluk noktaları ve gizli/hassas verinin işlendiği yerler. İyi iş akışı şu soruyu sorar: "Bu adımda YZ hızlandırır mı, yoksa risk mi ekler? Hatası ne kadar pahalı? Doğrulayabilir miyim?" Cevaba göre YZ'yi devreye al veya alma. Amaç, YZ'yi doğru yerlerde kullanıp gücünden yararlanmak, yanlış yerlerde kullanmaktan kaçınıp riski önlemek. Bu denge, bu modülün tüm öğrettiklerini pratik bir iş akışına dönüştürür.

YZ ile geliştirmenin etik boyutu, bu modülün ilkelerini daha geniş bir sorumluluğa bağlar. Doğruluk: doğrulamadan YZ çıktısını yaymak (yanlış kod, yanlış bilgi), başkalarını yanlış yönlendirebilir — doğrulama bir etik sorumluluktur, sadece teknik bir adım değil. Gizlilik: insanların verisini (KVKK) YZ'ye sorumsuzca vermek, onların mahremiyetini ihlal eder; veriyi korumak başkalarına karşı bir borçtur. Adalet: YZ'nin önyargılarını (Seviye 3) fark etmeden, insanları etkileyen sistemlerde kullanmak ayrımcılık üretebilir — özellikle insanları sınıflandıran/değerlendiren kodda adaleti gözet. Şeffaflık: uygun olduğunda YZ'nin katkısını açıkça belirtmek (ekip/proje kurallarına göre) dürüstlüktür. Sorumluluk: en temel ilke — ürettiğin her şeyin sorumluluğu sende, "YZ yaptı" bir mazeret değil. Bunların hepsi, "iyi geliştirici" olmanın YZ çağındaki anlamını oluşturur: hızlı ama dikkatli, güçlü ama sorumlu. YZ muazzam bir araçtır; onu insanlara fayda sağlayacak, zarar vermeyecek biçimde kullanmak senin elinde. Teknik beceriyle etik sorumluluğu birleştiren geliştirici, bu çağın en değerli geliştiricisidir.

Bu ilkeler, modülün tamamının özüdür; her YZ kullanımında bir pusula olarak başvur. Bu modülle birlikte, çağımızın en güçlü geliştirme araçlarından birini sorumlu biçimde kullanmayı öğrendin: YZ'nin ne olduğunu ve nasıl çalıştığını (Seviye 1), günlük işte nasıl kullanılacağını (Seviye 2), güvenli ve sorumlu kullanımı (Seviye 3) ve olgun çalışmayı (Seviye 4). Bütünsel kavrayış tek bir cümlede: YZ önerir, insan doğrular ve karar verir. YZ, bu seride öğrendiğin tüm temellerin (HTML/CSS/JS'ten algoritma, veritabanı, güvenlik ve yayınlamaya) üstüne oturan bir hızlandırıcıdır — ama bu temeller olmadan onu güvenle yönlendiremez veya yanılgılarını yakalayamazsın. İşte bu yüzden YZ, öğrenmenin yerini almaz; güçlü bir temeli olan kişinin elinde en değerli hâline gelir. En önemli mesaj baştan beri aynıydı ve şimdi senin alışkanlığın olmalı: her özgüvenli çıktıyı doğrula, her hassas veriyi koru, her kararı ve sorumluluğu sahiplen. Bu refleksleri taşıyan biri için YZ, korkulacak bir tehdit değil, ustaca kullanılacak muazzam bir güçtür. Serinin son modülünde (Bitirme & Portfolyo), tüm bu öğrendiklerini birleştirip kendi projeni inşa edecek ve geliştirici yolculuğunu taçlandıracaksın.