27 Eki 2025·7 dk
AI destekli geliştirme için Joel Spolsky'nin yazılım doğruları
Joel Spolsky’nin yazılım doğruları, AI hızlı kod yazsa bile geçerliliğini koruyor. Testler, işe alım ve sadelik üzerine pratik rehber.
Joel Spolsky’nin yazılım doğruları, AI hızlı kod yazsa bile geçerliliğini koruyor. Testler, işe alım ve sadelik üzerine pratik rehber.
AI dakika içinde çalışıyor görünen kod üretebilir. Bu proje hızını değiştirir ama yazılımın neden başarılı olduğunu değiştirmez. Joel Spolsky’nin “yazılım doğruları” aslında yazma hızıyla ilgili değildi. Karar verebilme, geri bildirim döngüleri ve kendi yarattığınız karmaşıklıktan kaçınma hakkındaydı.
Değişen nokta kod yaratmanın maliyeti. Üç yaklaşım, beş varyasyon veya tam bir yeniden yazım isteyip anında bir şeyler alabilirsiniz. Değişmeyen ise doğru yaklaşımı seçmenin, onu kontrol etmenin ve aylarca yaşamanın maliyeti. Yazmayı kısa süreye indirirken zaman genellikle ne demek istediğinize karar verme, uç durumları doğrulama ve bugünün hızlı kazanımının yarının bakım vergisine dönüşmemesini sağlamaya kayar.
Doğruluk, güvenlik ve sürdürülebilirlik hâlâ gerçek zaman alır çünkü bunlar kanıta dayanır, güvene değil. Bir giriş akışı derlendiğinde bitmiş sayılmaz. Kötü girdileri güvenilir şekilde reddettiğinde, tuhaf durumları yönettiğinde ve veri sızdırmadığında biter. AI emin konuşabilir ama bir kritik detayı — örneğin bir endpoint'te izin kontrolü veya bir ödeme güncellemesinde yarış durumu — kaçırabilir.
AI en iyi, onu hızlı bir taslak makinesi olarak kullandığınızda güçlüdür. Boilerplate, tekrarlayan kalıplar, hızlı refaktörler ve yan yana karşılaştırabileceğiniz seçenekleri keşfetmede parlıyor. Doğru kullanıldığında “boş sayfa” aşamasını sıkıştırır.
AI en çok zarar verdiğinde ise ona belirsiz hedefler verip çıktısını olduğu gibi kabul ettiğiniz zamandır. Aynı hata kalıpları tekrar tekrar ortaya çıkar: gizli varsayımlar (açıklanmamış iş kuralları), test edilmemiş yollar (hata işleme, yeniden denemeler, boş durumlar), emin ama yanlış sonuçlar (geçerli görünen ama ince şekilde hatalı kod) ve sonradan açıklaması zor “zekice” çözümler.
Kod ucuzsa, yeni kıt kaynak güvendir. Bu doğrular o güveni korur: kullanıcılarla, ekip arkadaşlarınızla ve gelecekteki kendinizle.
AI bir özelliği dakikalar içinde üretebiliyorsa, testleri yavaş kısım olarak görüp kurtulmak cazip olur. Spolsky’nin noktası hâlâ geçerli: yavaş kısım gerçeğin bulunduğu yerdir. Kod üretmek kolaydır. Doğru davranış değildir.
Faydalı bir değişim, testleri çalıştırılabilir gereksinimler olarak ele almaktır. Beklenen davranışı kontrol edilebilir şekilde tanımlayamıyorsanız, düşünmeyi bitirmemişsiniz demektir. AI destekli çalışmada bu daha da önem kazanır; çünkü model güvenle ama biraz yanlış bir şey üretebilir.
Testlere, bozulduğunda en çok zarar verecek şeylerle başlayın. Çoğu ürün için bunlar temel akışlardır (kayıt, ödeme, kaydetme, dışa aktarma), yetkiler (kim görüntüleyebilir, düzenleyebilir, silebilir) ve veri bütünlüğü (çoğaltma yok, doğru toplamlar, güvenli migrationlar). Sonra geç saat olaylarına neden olan kenarları kapsayın: boş girdiler, uzun metin, zaman dilimleri, yeniden denemeler ve ödemeler, e-postalar, dosya yüklemeleri gibi flaky dış sınırlar.
AI test vakaları önermede iyidir ama gerçekte kullanıcılara ne vaat ettiğinizi bilemez. Onu beyin fırtınası ortağı gibi kullanın: eksik uç durumları, kötüye kullanım senaryolarını ve izin kombinasyonlarını isteyin. Sonra insan işi yapın: kapsamı gerçek kurallarınıza eşleştirin ve sadece “uygulamayı test eden” testleri değil, davranışı test edenleri bırakın.
Hataları eyleme dönüştürülebilir yapın. Başarısız bir test sizi hazine avına göndermemeli; neyin bozulduğunu söylemeli. Testleri küçük tutun, cümle gibi isimlendirin ve hata mesajlarını özgül yapın.
AI yardımıyla basit bir “takım notları” uygulaması yaptığınızı varsayın. CRUD ekranları hızlıca gelir. Doğruluk riski UI’da değildir. Erişim kontrolü ve veri kurallarıdır: bir kullanıcı başka bir takımın notlarını görmemeli, düzenlemeler daha yeni değişiklikleri ezmemeli ve bir not silindiğinde bağlı eklentiler yetim kalmamalı. Bu kuralları kilitleyen testler darboğaz gibi hissettirecektir ama aynı zamanda güvenlik ağıdır.
Testlerin darboğaz olması netlik zorlar. Bu netlik, hızlı kodun hızlı hatalara dönüşmesini engeller.
Kalıcı doğrulardan biri, basit kodun zekice olandan kazandığıdır. AI, parlatılmış ve hızlı geldiği için gösterişli soyutlamaları kabul etmeyi cazip kılar. Maliyet daha sonra ortaya çıkar: hataların gizlenebileceği daha fazla yer, daha çok dosya taraması ve “bunun ne yaptığı?” anları.
Kod ucuz olduğunda ödediğiniz şey karmaşıklıktır. Küçük, sıkıcı bir tasarım daha kolay test edilir, değiştirilir ve açıklanır. Bu, ilk taslak bir modelden geldiğinde daha da önemlidir çünkü model emin konuşurken ince şekilde yanlış olabilir.
Pratik bir kural: fonksiyonları, bileşenleri ve modülleri bir ekip arkadaşınızın dakikalar içinde gözden geçirebileceği büyüklükte tutun, saatler değil. Bir React bileşeni birden fazla custom hook, yerel durum makinesi ve genel bir “akıllı render” katmanı gerektiriyorsa durup gerçek bir problemi mi çözdüğünüz yoksa AI'nin sunduğu mimariyi mi kabul ettiğiniz sorusunu sorun.
Birkaç “sadelik testi” geri itmenize yardımcı olur:
Promtlar burada önemlidir. “En iyi mimariyi” sorduğunuzda genellikle aşırı inşa edilmiş bir şey alırsınız. Daha az hareketli parça yönünde iten kısıtlamalar isteyin. Örneğin: en az dosya ile en basit yaklaşımı kullan; üçten fazla yerde duplikasyon kaldırmıyorsa yeni soyutlamalardan kaçın; genel yardımcılar yerine açık kodu tercih et.
Somut örnek: AI'ye bir yönetici sayfasına rol tabanlı erişim eklemesini istersiniz. Zekice versiyon izin çerçevesi, dekoratörler ve bir konfig DSL getirir. Basit versiyon bir yerde kullanıcı rolünü kontrol eder, rotaları bir yerde sınırlar ve reddedilen erişimi kaydeder. Basit versiyon gözden geçirmek, test etmek ve yanlış yorumlamak daha zordur.
Sohbet tabanlı bir araçta (ör. Koder.ai) çalışıyorsanız, sadelik aynı zamanda anlık kayıtları ve geri almayı daha değerli kılar. Küçük, açık değişiklikleri karşılaştırmak, saklamak veya geri almak daha kolaydır.
Kod üretmek kolay olduğunda kıt yetenek neyin var olması gerektiğini seçmek ve bunun doğru olduğundan emin olmak olur. Eski “harika programcılar işe al” tavsiyesi hâlâ geçerli, ama iş kayar. Artık daha hızlı yazan birini değil, yargılayan, rafine eden ve ürünü savunan birini işe alıyorsunuz.
AI destekli geliştirmede en değerli kişiler genelde dört özelliğe sahiptir: yargı (ne önemlidir), zevk (iyi olanın neye benzediği), hata ayıklama becerisi (gerçek nedeni bulma) ve iletişim (takasları net yapmak). AI yazmış bir özelliği “çoğunlukla çalışıyor” halinden güvenilir bir şeye dönüştürebilirler.
Mükemmel bir çözüm talep etmek yerine adaylara bazı gerçekçi problemlere sahip bir AI üretilmiş pull request (veya yapıştırılmış diff) verin: belirsiz isimlendirme, gizli bir uç durum, eksik test ve küçük bir güvenlik hatası.
Onlardan kısaca kodun ne yapmaya çalıştığını düz bir dille açıklamalarını, en yüksek riskli parçaları bulmalarını, düzeltme önerileri sunmalarını ve yakalanacak regresyonlar için testler eklemelerini (veya taslaklamalarını) isteyin. Güçlü bir sinyal için, bir sonraki AI denemesi için talimatları nasıl değiştirirler diye de sorun.
Bu, onların gerçek koşullar altında nasıl düşündüğünü gösterir: kusurlu kod, sınırlı zaman ve öncelik seçme ihtiyacı.
AI genellikle emin konuşur. İyi işe alınanlar geri tepkiye açıktır. Karmaşıklık ekleyen bir özelliğe hayır diyebilirler, güvenliği zayıflatan bir değişikliğe hayır diyebilirler ve kanıt olmadan gönderme yapmaktan kaçınırlar.
Somut bir gösterge, “Bunu merge eder miydin?” sorusuna nasıl yanıt verdikleridir. Güçlü adaylar his yerine bir karar ve kısa bir gereken değişiklik listesi verir.
Örnek: “hızlı” bir erişim kontrol güncellemesi istersiniz ve AI handler'lara kontrol eklemeyi önerir. Güçlü bir aday o yaklaşımı reddeder, net bir yetkilendirme katmanı önerir ve admin ve non-admin yolları için testler ister.
Son olarak, ekipte AI çıktısını aynı şekilde düzenleyecek ortak standartlar oluşturun. Basit tutun: bir tamamlanma tanımı, tutarlı inceleme beklentileri ve bir test tabanı.
AI dakika içinde çok sayıda kod üretebildiğinde düşünmeyi atlamak ve sadece yinelemeye gitmek caziptir. Demo için işe yarar. Doğruluk, öngörülebilir davranış ve daha az sürpriz gerektiğinde bozulur.
İyi bir prompt genellikle kısa bir spes içinde gizlidir. Kod istemeden önce muğlak hedefi birkaç kabul kriterine ve açık hedef dışı duruma dönüştürün. Bu, AI'nin (ve ekibin) sessizce kapsamı genişletmesini engeller.
Spes küçük ama spesifik olsun. Roman yazmıyorsunuz. Sınırları belirliyorsunuz:
Üretimden önce “bitti”yi tanımlayın, sonra değil. “Bitti” sadece “derleniyor” veya “UI doğru görünüyor” olmamalı. Test beklentilerini, geriye uyumluluğu ve yayın sonrası izlenecekleri içermeli.
Örnek: “parola sıfırlama ekle” istiyorsunuz. Daha net bir spes şunu söyleyebilir: kullanıcı e-posta ile sıfırlama isteği yapar; linkler 15 dakika sonra geçersiz olur; e-posta var mı yok mu aynı mesaj gösterilir; IP başına oran sınırlaması; tokenlar düz metinde saklanmaz ama sıfırlama denemeleri kaydedilir. Hedef dışı: giriş sayfasının yeniden tasarımı yok. Artık promptunuz gardrail içerir ve incelemeler basitleşir.
Kararların hafif bir değişiklik günlüğünü tutun. Her karar için bir paragraf yeterlidir. Neden bu yaklaşımı seçtiğinizi ve alternatifleri neden reddettiğinizi not edin. Birisi iki hafta sonra “neden böyle?” diye sorduğunda cevap hazır olur.
AI ile en büyük değişim kod üretmenin kolaylaşmasıdır. Zor olan ne yapılması gerektiğine karar vermek ve bunun gerçekten yapıldığını kanıtlamaktır.
Önce hedefi ve kısıtları düz dilde yazın. Asla olmaması gerekeni, hangi şeylerin yavaş olabileceğini ve kapsam dışını dahil edin. İyi bir kısıtlama test edilebilir olmalı: “Hiçbir kullanıcı başka bir kullanıcının verisini görmemeli” veya “Toplamlar finans dışa aktarımıyla kuruşa kadar uyuşmalı” gibi.
Koddaki üretim öncesi basit bir tasarım ve takasları isteyin. AI'den ne depolayacağı, neyi doğrulayacağı ve neyi loglayacağı konusunda gerekçesini görebileceğiniz bir formda gösterimini isteyin. Zekice bir şey önerirse geri itip kısıtları karşılayan en basit versiyonu isteyin.
Tekrarlanabilir döngü şöyle görünür:
Küçük bir senaryo: sipariş ekranına “iade durumu” ekliyorsunuz. AI UI'yi hızlıca üretebilir ama doğruluk uç durumlarda yaşar. Kısmi iade ne olur? Ödeme sağlayıcısı webhook'u tekrar gönderirse? Bu durumları önce yazın, sonra bir dilim (veritabanı sütunu + doğrulama) uygulayın ve testlerle doğrulayın.
Koder.ai gibi araç kullanıyorsanız, planlama modu, anlık kayıtlar ve geri alma bu döngüye doğal olarak uyar: önce planlayın, dilimler halinde üretin ve her anlamlı değişiklik için güvenli bir geri alma noktasını yakalayın.
Kod üretimi hızlı olunca kodu iş ürünü gibi görme eğilimi artar. İş ürünü davranıştır: uygulama doğru şeyi yapar, işler ters gittiğinde bile.
AI sıkça emin konuşur, ama tahmin ediyor olabilir. Hata, sıkıcı kısmı atlamaktır: testleri çalıştırmak, uç durumları kontrol etmek ve gerçek girdileri doğrulamak.
Basit bir alışkanlık yardımcı olur: bir değişikliği kabul etmeden önce “Bunu nasıl biliyoruz doğru olduğuna?” diye sorun. Cevap “doğru görünüyor” ise kumar oynuyorsunuz demektir.
AI ekstra eklemeyi sever: cache, yeniden denemeler, daha fazla ayar, ek endpointler, daha güzel bir UI. Bazıları faydalıdır ama risk arttırır. Birçok hata kimsenin istemediği “iyi olur” özelliklerden gelir.
Sert bir sınır koyun: çözmeyi hedeflediğiniz problemi çözün, sonra durun. Değerli bir öneri varsa onu ayrı bir görev olarak yakalayın ve kendi testleriyle ele alın.
Büyük AI üretilmiş commit bir düzineden fazla ilgisiz kararı gizleyebilir. İnceleme rubber-stamp olur çünkü kimse hepsini aklında tutamaz.
Sohbet çıktısını bir taslak gibi ele alın. Okuyup çalıştırabileceğiniz ve geri alabileceğiniz küçük değişikliklere bölün. Anlık kayıtlar ve geri alma yalnızca mantıklı noktalarda alındığında işe yarar.
Birkaç basit kısıtlama çoğu acıyı önler: değişiklik başına bir özellik, değişiklik başına bir migration, aynı değişiklikte güncellenmiş testler ve “nasıl doğrulanır” notu.
AI eğitim verilerinden kalıplar tekrarlayabilir veya anlamadığınız bağımlılıklar önerebilir. Lisans tamamsa bile daha büyük risk güvenliktir: sabit kodlanmış sırlar, zayıf token işleme veya güvensiz dosya/sorgu işlemleri.
Bir parçanın ne yaptığını açıklayamıyorsanız, onu gönderme. Daha basit bir versiyon isteyin veya kendiniz yeniden yazın.
“Benim makinemde çalıştı” hatalarının çoğu aslında veri ve ölçek hatalarıdır. AI şema değişiklikleri oluşturabilir ama var olan satırlar, büyük tablolar veya kesinti düşünmeyebilir.
Gerçekçi örnek: model bir PostgreSQL tablosuna yeni NOT NULL sütunu ekleyip bunu yavaş bir döngüyle doldurmayı önerir. Üretimde bu tabloyu kilitleyebilir ve uygulamayı bozabilir. Her zaman milyonlarca satır, yavaş ağ veya yarım kalmış deploy durumunda ne olacağını düşünün.
Küçük bir dahili istek takipçisi hayal edin: insanlar istek gönderir, yöneticiler onaylar veya reddeder ve finans ödemeyi işaretler. Basit gibi görünür ve AI yardımıyla ekranlar ve endpoint'ler hızlıca üretebilirsiniz. Sizi yavaşlatan kısım yine aynı eski gerçek: kurallar, yazma hızı değil.
Önce doğru olması gereken asgari öğeleri yazın. Düz bir dille açıklayamıyorsanız, test edemezsiniz.
Sıkı bir ilk sürüm tanımı genelde şöyle görünür: alanlar (başlık, istekçi, departman, tutar, sebep, durum, zaman damgaları); roller (istekçi, onaylayıcı, finans, admin); durumlar (taslak, gönderildi, onaylandı, reddedildi, ödendi). Sonra önemli geçişleri belirtin: yalnızca bir onaylayıcı gönderilenı onaylıya veya reddede bilir; sadece finans onaylıyı ödemeye taşıyabilir.
AI'yi kontrollü sırayla kullanın ki hataları erken yakalayın:
submit, approve, reject, pay)—generic update rotası değil.En yüksek değere sahip testler “sayfa yükleniyor mu” değil, izin kontrolleri ve durum geçişleridir. Örneğin bir istekçinin kendi isteğini onaylayamayacağını, bir onaylayıcının şeyi ödemeye işaret edemeyeceğini, reddedilmiş isteklerin ödenemeyeceğini ve (kuralınız buysa) gönderimden sonra tutarların düzenlenemeyeceğini kanıtlayın.
En uzun süren kısım uç durumları netleştirmektir. Bir onaylayıcı reddettikten sonra fikrini değiştirebilir mi? İki onaylayıcı aynı anda onay tuşuna basarsa ne olur? Finans kısmi ödeme yapmalı mı? AI sizin seçtiğiniz herhangi bir cevap için kod üretebilir ama doğru cevabı sizin seçmeniz gerekir. Doğruluk bu kararları almak ve sonra kodu bunlara uymaya zorlamakla gelir.
AI çok hızlı kod üretebilir ama son mil hâlâ insan işi: bunun ne demek olduğunu kanıtlamak ve demeyeceği zaman güvenli şekilde başarısız olmak.
Başlamadan önce en küçük “bitti” tanımını seçin. Küçük bir özellik için bu bir mutlu yol, iki hata yolu ve kısa bir okunabilirlik incelemesi olabilir. Ödemeler veya yetkilendirme için çıtayı yükseltin.
AI yönetici ekranına “toplu davet et” ekledi. Mutlu yol çalışıyor ama gerçek risk uç durumlar: tekrar eden e-postalar, kısmi başarısızlıklar ve oran sınırlamaları. Sağlam bir gönderim kararı, kopyalar için bir otomatik test, kısmi hata mesajı için bir manuel kontrol ve bir geri alma planı olabilir.
Kod ucuz olduğunda risk karar kalitesine kayar: neyi istediğiniz, neyi kabul ettiğiniz ve neyi gönderdiğiniz. Bu doğruları AI destekli çalışmada ödemeye başlamak için en hızlı yol, “neredeyse doğru” değişikliklerin kaymasını engelleyen gardrailler eklemektir.
Bir sonraki özellik için tek sayfalık bir spesle başlayın. Basit tutun: kim için, ne yapmalı, ne yapmamalı ve günlük dilde yazılmış birkaç kabul testi. Bu kabul testleri AI cazip kestirme öneri sunduğunda çapa görevi görür.
Az işlem yüküyle ölçeklenen gardrail seti:
Artık promptlar sürecinizin bir parçası. Hangi kütüphanelere izin verildiği, hataların nasıl ele alındığı, “bitti”nin ne anlama geldiği ve hangi testlerin geçmesi gerektiği konusunda ekipçe bir ev stili üzerinde anlaşın. Bir prompt başka bir ekip üyesi tarafından yeniden kullanılamıyorsa muhtemelen çok muğlaktır.
Koder.ai gibi sohbet-öncelikli bir web, backend ve mobil uygulama inşa yolunu tercih ediyorsanız, planlama modu, anlık kayıtlar ve kaynak kodu dışa aktarma bu gardrailleri destekleyebilir. Araç taslakları hızlandırabilir, ama doğrulukta insan disiplini hâlâ yöneticidir.
AI çıktısını bitmiş bir özellik gibi değil, hızlı bir taslak gibi değerlendirin. Önce 3–5 geç/kal kabul testi yazın, sonra bir küçük dilim (bir endpoint, bir ekran, bir migration) üretin ve ilerlemeden önce testlerle ve hata durumlarını deneyerek doğrulayın.
Çünkü testler kodun gerçekte ne yaptığını ortaya çıkarır. AI mantıklı gözüken ama bir ana kuralı (yetkilendirme, yeniden denemeler, uç durumlar) kaçıran kod üretebilir. Testler beklentilerinizi çalıştırılabilir, tekrarlanabilir ve güvenilir hale getirir.
İlk önce en çok zarar verecek şeyleri test edin:
“Yüksek zarar” davranışları kilitlenene kadar kapsamı artırın.
En basit yaklaşıma, açık kısıtlamalara ve sonra gereksinimleri yerine getiren somut sonuçlara odaklanın. Yeni bir soyutlama eklemeyin ya da mevcut yapıyı karmaşıklaştırmayın; bir kural olarak: bir soyutlamayı ancak üçten fazla yerde tekrar eden duplikasyonu gideriyorsa ekleyin ya da doğrulamayı kolaylaştırıyorsa tutun.
Kısa bir spes yazın: girdiler, çıktılar, hatalar, kısıtlamalar ve hedef dışı durumlar. Somut örnekler (örnek istek/yanıtlar, uç durumlar) ekleyin. Ardından “bitti”yi tanımlayın: gereken testler, geriye uyumluluk beklentileri ve hızlı bir doğrulama notu.
Parçalayın:
Böylece inceleme gerçek olur, otomatik onay değil.
Güvene değil, kanıta güvenin: test çalıştırın, bozuk girdileri deneyin ve izin sınırlarını doğrulayın. AI tuzaklarına dikkat edin: eksik auth kontrolleri, güvenli olmayan sorgu oluşturma, zayıf token işleme ve sessiz hata yutma gibi.
Genellikle submit, approve, reject, pay gibi açık geçiş endpointlerini tercih edin; generic “update anything” rotalarından kaçının. Ardından hangi role hangi geçişlerin açık olduğunu zorlayan testler yazın.
Adaya gerçekçi bir AI üretilmiş diff verin: belirsiz isimlendirme, eksik test, bir uç durum ve küçük bir güvenlik hatası gibi. Kodun amacını basitçe açıklamasını, en yüksek riskli parçaları bulmasını, düzeltme önermesini ve ekleyeceği testleri taslaklamasını isteyin.
Planlayın, küçük dilimler halinde üretin, riskli değişikliklerde anlık kayıt alın ve doğrulama başarısızsa geri alın. Sohbet tabanlı araçlarda planlama modu, anlık kayıtlar ve geri alma özellikleri bu döngüyle iyi eşleşir.