Yapay zekâ ile kod yazmak

Modeller kod yazmada tam olarak neyde iyidir?

Net bir örüntü var ve onu gördüğünüzde dersin geri kalanı basitleşiyor: modeller, biçimi tekrarlı ve muhakeme içeriği düşük olan işlerde iyidir. İş, projenize özgü kararlara yaklaştıkça kalite düşer ve sessizce düşer, çünkü kod yine de çalışır.

Gerçekten iyi yaptıkları şeyler: benzeri bin kez yazılmış kodu yazmak, bir dosya okumak, bir formu doğrulamak ya da hata yönetimiyle birlikte bir ağ isteği gibi. Bir dilden diğerine çevirmek. Veriyi bir biçimden başka bir biçime dönüştürmek. Kendi yazdığınız bir fonksiyon için test yazmak. Başkasının yazdığı, size yabancı olan kodu açıklamak. Ve neredeyse kimsenin kullanmadığı, en çok geri dönen şey: kendi yazdığınız kodu eleştirmek.

Yetersiz kaldıkları işlerin de ortak bir örüntüsü var: doğru cevabın, konuşmada bulunmayan bir şeye bağlı olduğu her yer. Ölçeğinize ve ekibinize bağlı mimari kararlar. Eski bir projenin yazılı olmayan geleneklerine uyması gereken kod. Bir kütüphanenin en son değişikliklerine bağlı olan her şey. Ve riskler bölümünde geri döneceğimiz güvenlik.

Duruşumuz basit: modeli, kendiniz yapabileceğiniz ama canınızın istemediği işlere koyun; nasıl yapılacağını bilmediğiniz işlere değil. Çünkü ilk durumda çıktıyı yargılayabilirsiniz, ikincisinde yalnızca umut edebilirsiniz.

Bu araçları her gün kullanan geliştiriciler ne diyor?

Tahmin etmek yerine alandaki en büyük kamuya açık ankete bakalım. 2025 Stack Overflow geliştirici anketi, katılımcıların yüzde 84'ünün yapay zekâ araçlarını kullandığını ya da kullanmayı planladığını, profesyonel geliştiricilerin yüzde 51'inin ise bunları her gün kullandığını söylüyor. Yani "kullanmalı mıyız" tartışması bitmiştir.

Ama aynı anket, çok daha az alıntılanan ikinci bir şey daha söylüyor. Kullandıkları araçların karmaşık işleri ne kadar iyi kaldırdığı sorulduğunda yüzde 4,4 çok iyi, yüzde 25,2 iyi ama harika değil dedi. Buna karşılık yüzde 22 kötü, yüzde 17,6 çok zayıf dedi. Yüzde 14,1 ne iyi ne kötü dedi, yüzde 16,8 ise bu araçları karmaşık işler için kullanmadığını ya da bilmediğini söyledi. Başka bir deyişle, bu araçlar her gün elinde olan insanlar karmaşık iş konusunda olumludan çok olumsuz.

Ve bütün dersi özetleyen üçüncü bir sayı: en büyük tekil şikâyet, yüzde 66 ile, "neredeyse doğru ama tam değil çözümler" idi. Neredeyse doğru, mümkün olan en kötü durumdur. Tamamen yanlış kodu derleyici ya da ilk çalıştırma yakalar. Neredeyse doğru kod ikisinden de geçer ve aylar sonra belirli bir durumda kendini gösterir.

Aynı şikâyet listesinin geri kalanı da okumaya değer, çünkü maliyetin biçimini gösteriyor: yüzde 45,2 üretilen kodu ayıklamanın daha çok zaman aldığını, yüzde 20 kendi problem çözme becerisine güveninin azaldığını, yüzde 16,3 ise kodun nasıl ya da neden çalıştığını anlamanın zor olduğunu söyledi. Listenin diğer ucunda yalnızca yüzde 4 hiçbir sorunla karşılaşmadığını söyledi.

Bu sayılar hakkında bir not, çünkü bu aynı zamanda bir dürüstlük dersi: bunlar insanların bildirdiği şeylerdir, kod kalitesinin ölçümü değil. Geliştiricilerin ne yaşadığını söylerler, modellerin nesnel olarak ne kadar iyi olduğunu değil. Bu ders için önemli olan birincisidir.

Hangi araçlar ve İran'dan hangilerine gerçekten erişilir?

Araçlar üç biçimde gelir ve aralarındaki seçim, modelden çok nerede çalıştığınıza bağlıdır.

Editör eklentisi siz yazarken öneri sunar. En bilineni GitHub Copilot'tur. Avantajı hiçbir şeyi kesmemesi; bedeli ise sürekli öneri sunduğu için okumadan kabul etmeye alışmanızdır.

Ayrı bir sohbet, tarayıcıda, Claude ya da Gemini gibi. Yazmaktan çok düşünmek, eleştirmek ve anlamak için daha iyidir, çünkü kodu proje bağlamından ayırır ve bu ayrılık sorunu kendinizin ifade etmesini zorunlu kılar.

Komut satırı ajanı ya da ajanlı editör, Claude Code ya da Cursor gibi, dosyaları kendisi okuyup yazar. En güçlü biçim ve en tehlikelisi: bir araç size her değişikliği göstermeden on dosyayı değiştirdiğinde, gözden geçirme sizinle görünmez bir hata arasında duran tek şey hâline gelir.

Gelelim İran'dan erişime; bu sayfanın okuru için asıl soru budur. Burada nadiren dile getirilen önemli bir fark var: GitHub diğerleri gibi değil. GitHub'ın kendi ticaret denetimleri sayfası, ABD Hazinesi Yabancı Varlıklar Kontrol Ofisi'nden aldığı bir lisansın, İran'da ikamet eden geliştiriciler için bulut hizmetlerini ücretsiz ve ücretli olarak kapsadığını söylüyor. Bu cümleyi aktarıyoruz ve ötesinde bir iddiada bulunmuyoruz; ödemenin İran kartıyla geçip geçmediği ayrı bir meseledir, test etmedik ve satın alma rehberi o katmanı ayrıca ele alıyor.

Diğer tarafta, Anthropic'in desteklenen ülkeler sayfasında İran yok ve Google'ın Gemini web uygulamasına dair kendi sayfası, İran'ın bulunmadığı iki yüz otuzdan fazla ülke ve bölgelik bir liste veriyor. Cursor'ın bulabildiğimiz bir desteklenen ülkeler listesi yok, dolayısıyla onun hakkında bir iddiada bulunmuyoruz; fiyatları kendi sayfasından okunabilir: bir ücretsiz plan ve ayda yirmi dolarlık bir profesyonel plan.

İran'da başka yerlerden daha çok anlam taşıyan dördüncü bir yol var: açık ağırlıklı modeller. Ağırlıkları alıp kendi donanımınızda ya da herhangi bir sağlayıcıda çalıştırabilirsiniz, böylece erişim sorusu biçim değiştirir. Kaliteleri kapalı modellerin gerisindedir ve bu fark sürekli hareket eder; her sayının kaynağıyla birlikte güncel sıralamamız kodlama için en iyi yapay zekâ sayfasındadır ve burada bilerek hiçbir sürüm adı yazmıyoruz, çünkü bir derse yazılan her sayı üç ay içinde bayatlar.

Kaliteyi koruyan iş akışı: önce test, küçük farklar, gerçek gözden geçirme

Modelle daha hızlı çalışan biriyle modelle teknik borç üreten biri arasında üç alışkanlık vardır. Hiçbiri modelle ilgili değildir; üçü de sizindir.

Önce test, sonra kod. Bir uygulama istemeden önce kendinize sorun: bunun çalıştığını nereden bileceğim? O cevabı yazın; artık ne sizin ne de modelin pazarlık edebileceği nesnel bir ölçütünüz var. Sıra burada önemlidir: önce kodu alıp sonra aynı modelden testini yazmasını isterseniz, kodla aynı varsayımları taşıyan bir test alırsınız ve ikisi birlikte yanlış olur. En iyisi, yazımını modele bıraksanız bile, testin neyi kanıtlaması gerektiğini kendinizin söylemesidir.

Küçük farklar. Modelden tek bir işi tek bir değişiklikte yapıp orada durmasını isteyin. Tek bir şeyi değiştiren elli satırlık bir değişiklik gözden geçirilebilir; dört şeyi değiştiren beş yüz satırlık bir değişiklik gözden geçirilmez, onaylanır. Bu ikisi çok farklıdır ve fark tam da hataların girdiği yerdir.

Gerçek gözden geçirme. Gözden geçirmek, her satır için neden orada olduğunu söyleyebilmektir. Anlamadığınız bir satıra rastlarsanız üç seçeneğiniz var: sormak, kendiniz çözmek ya da silmek. Herkesin seçtiği dördüncüsü, gerisi çalıştığı için onu bırakmaktır ve altı ay sonra döneceğiniz satır tam olarak odur.

Neredeyse kimsenin kullanmadığı ucuz bir dördüncü alışkanlık var: modelden kendi kodunu ayrı bir mesajda eleştirmesini isteyin. Konuşma geçmişi olmayan yeni bir mesajda yalnızca kodu yapıştırın ve nesi yanlış diye sorun. Aynı başlık içinde sorarak alamayacağınız cevaplar alırsınız, çünkü o başlığın içinde modelin rolü az önce inşa ettiği şeyi savunmaktır.

Mesaja asla ne girmemeli?

Bu bölüm kısa, çünkü kuralı kısa: mesaja koyduğunuz her şey elinizden çıkar. Servise, plana ve ayarlara göre saklanabilir, bir insan tarafından incelenebilir ve eğitime gidebilir. Bunu öğrenmenin tek doğru yeri her servisin veri kullanımı sayfasıdır, insanların söyledikleri değil.

Dolayısıyla dört şey dışarıda kalır: anahtarlar, parolalar ve jetonlar, yalnızca örnek olsun diye gönderdiğiniz bir parçanın içinde bile; gerçek kullanıcı verisi, özellikle e-posta ve telefon içeren bir günlük; sözleşmenizin izin vermediği bir müşteri kod tabanı; ve gizlilik taahhüdü imzaladığınız her şey.

Pratik yol basit. Anahtarı anlamsız bir dizeyle değiştirin ve bir sohbete gerçek bir anahtar yapıştırdıysanız o anahtar artık geçerli değildir, döndürülmelidir; kesin sızdığı için değil, artık nerede olduğunu bilmediğiniz için. Kullanıcı verisi için aynı biçimde birkaç uydurma satır üretin. Modelin ihtiyacı verinin biçimidir, içeriği değil.

Yeni başlıyorsanız nereden başlamalısınız?

Dürüst bir cevabı hak eden gerçek bir kaygı var: kodu model yazıyorsa ben ne zaman öğreneceğim?

Risk gerçek ve aynı anket bunu gösteriyor: katılımcıların yüzde 20'si kendi problem çözme becerilerine olan güvenlerinin azaldığını söyledi. Mekanizma da açık: öğrenme takılmaktan gelir ve takılmayı ortadan kaldıran bir araç, size öğreten şeyi ortadan kaldırmıştır.

Ama cevap "kullanma" değil, çünkü kullanmayan kişi hem daha yavaştır hem de herkesin bildiğini bilmez. Cevap sıralamadır. Henüz öğrenmediğiniz her şeyi önce kendiniz yazın, kötü ve eksik olsa bile. Sonra modelden onu eleştirmesini isteyin. Bu sıra aynı işi bitirir ve öğrenmeyi korur, çünkü takılmak yerinde kalır, yalnızca süresi kısalır.

Ve bu yelpazede nerede durduğunuzu söyleyen basit bir test: modelin yazdığı kodu kapatın ve aynı şeyi ezberden anlatın. Ne yaptığını ve neden öyle yaptığını söyleyebiliyorsanız iyi. Söyleyemiyorsanız o kod henüz sizin değildir; kiralıktır ve kirasını bozulduğu gün ödersiniz. Bu testi mümkün kılan diğer temeller programlama öğrenme yolunda.