AI destekli geliştirme için Joel Spolsky'nin yazılım doğruları

AI hızlı kod yazsa bile bu doğrular neden hâlâ önemli

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.

Testler hâlâ darboğazdır ve bu iyi bir şeydir

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.

Kısa bir örnek

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.

AI döngüdeyken sadelik zekâdan üstündür

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:

• Yeni bir ekip arkadaşı ana akışı bir oturumda anlayabilir mi?
• Bu soyutlamayı silip yerini düz kodla almak açıklığı kaybettirir mi?
• Bir hatayı düzeltmek için bir açık yer mi var yoksa beş mi?
• Her parçanın bir cümlede ifade edilebilecek bir işi var mı?

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.

İşe alım: daktilo değil editör ve karar verici gerekir

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.

Daha iyi bir mülakat: AI değişikliğini iyileştirin

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ı.

Süper güç: “hayır” diyebilme

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ı.

Spesifikasyonlar ve planlama: daha net promptlar daha net düşünceden başlar

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:

• Girdiler: neler geliyor (alanlar, formatlar, uç durumlar)
• Çıktılar: ne çıkmalı (örnekler dahil)
• Hatalar: neler yanlış gidebilir ve nasıl yanıt verilmeli
• Kısıtlamalar: performans, gizlilik, bağımlılıklar veya “değişmemeli” alanlar
• Hedef dışı: bu değişiklikte ne yapmıyorsunuz

Ü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.

Tekrarlanabilir bir AI destekli iş akışı

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:

1. Kısa bir problem tanımı ve 3–5 açık geç/kal kabul testi yazın.
2. Minimal bir plan isteyin: veri modeli, ana fonksiyonlar ve nelerin yanlış gidebileceği.
3. Bir seferde tek bir küçük değişiklik üretin (bir endpoint, bir UI ekranı, bir migration), tam uygulama dökümü değil.
4. Editör gibi inceleyin: diff'leri okuyun, testleri çalıştırın, hata durumlarını deneyin, sonra düzeltmeler isteyin.
5. Güvenli yayın: flag veya sınırlı rollout kullanın, logları ve metrikleri izleyin ve geri almaya hazır olun.

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.

AI ile kodlamanın çok kolay hissettirdiği zamanlarda yapılan yaygın hatalar

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.

1) Emin görünen çıktıya kanmak

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.

2) Aracın kapsamı büyütmesine izin vermek

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.

3) İncelemesi imkansız büyük değişiklikleri merge etmek

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.

4) Belirsiz lisanslama veya güvenlik riski taşıyan kodu kopyalamak

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.

5) Migrationları, limitleri ve hata modlarını unutmak

“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.

Örnek: doğruluğun hızdan daha önemli olduğu basit bir uygulama

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:

1. Önce veritabanı şemasını ve durum enum'unu tanımlayın.
2. Geçişler etrafında endpoint'ler oluşturun (submit, approve, reject, pay)—generic update rotası değil.
3. API izin verdiği şekilde UI'yi en son üretin.

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 tarafından üretilen değişiklikleri göndermeden önce hızlı kontrol listesi

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.

Beş kontrol

• Her gereksinim doğrulanabilir. Her gereksinim için ya bir testiniz ya da bir cümleyle yazılmış açık bir manuel kontrolünüz olmalı. Nasıl doğrulayacağınızı açıklayamıyorsanız, büyük olasılıkla ne yaptığınızı anlamıyorsunuz.
• Hata durumları ele alınmış ve açıklanmış olmalı. En üst hata durumlarını deneyin (hatlı girdi, eksik izin, ağ hatası, boş veri). Uygulama yararlı bir mesaj göstermeli ve hassas ayrıntı sızdırmamalı.
• Tasarım sade kaldı. AI ekstra yardımcılar, soyutlamalar veya zekice desenler eklediyse sorun: elinizle yazsaydınız bunları tutar mıydınız? Fazla katmanları silin, aksi takdirde ancak karşılığını veriyorsa tutun.
• Yeni bir gözden geçiren takip edebilmeli. İnceleyen sohbet oturumunu izlemediğini varsayın. Kod bir hikâye gibi okunmalı: açık isimler, kısa fonksiyonlar ve neden değişiklik yapıldığını belirten kısa bir not.
• Güvenli şekilde geri dönebilmelisiniz. “Normale dön”ün ne olduğunu bilin. Bilinen iyi bir sürüm yakalayın ve üretim farklı davranırsa hızlıca geri alabileceğinizi doğrulayın.

Kısa örnek

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.

Sonraki adımlar: gardrail ekleyin, sonra süreci ölçekleyin

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:

• İnceleme için değişiklikleri dakikalar içinde okunabilecek kadar küçük tutun.
• Her davranış değişikliği için test (veya en azından test notları) zorunlu kılın.
• Standart bir prompt şablonu kullanın: kısıtlamalar, kodlama stili ve test beklentileri.
• Her deploy için güvenilir bir geri alma yolu tutun.
• Bilinmeyenleri açık TODO olarak takip edin, gizli varsayımlar olarak değil.

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.