- Yapay zeka kodlama araçlarının kullanımı, "kod borcunu" artıran bir iştir
- Aynı ürün ve gelire sahip iki şirket arasında, 1 milyon satır koda sahip bir şirkete kıyasla 100 bin satır kodla çalışan şirket çok daha hızlı anlaşılır ve değiştirilir
- Yani kod arttıkça borç birikir; yapay zeka ile kod üretimi verimliliği artırsa da aynı zamanda borcu artıran bir eylem olarak yorumlanabilir
- Borcun olumlu/olumsuz iki yönü vardır
- Olumlu: Kısa vadede hızlı büyümeyi mümkün kılar
- Olumsuz: Uzun vadede iyi yönetilemezse projede çöküş riski doğurur
- Yani borç iyi ya da kötü olabilir, faizli ya da faizsiz olabilir, hızlı büyümeyi mümkün kılabildiği gibi projeyi çöküşe de sürükleyebilir
- Önemli olan aracın kullanılıp kullanılmaması değil, sorumlu biçimde yönetilmesidir
- Araçlara kolay erişimi sağlarken, üretilen kodun kalitesi ile uzun vadeli maliyeti de dikkate almak gerekir
5 yorum
Kod çok uzun olsa bile "ne yaptığını" kolayca açıklayabiliyorsanız, bu borç değildir.
Burada söylenmek istenen, yapay zekanın düşünmeden kullanılmasının bunu zorlaştırdığı ve bu yüzden borç yarattığıdır.
https://github.com/kelseyhightower/nocode
Metinde açıkça belirtilmemiş ama, AI ile kod yazıldığında insanın doğrudan yazdığı koda kıyasla daha az aşina olunduğu için bunun bir borç haline geldiği anlamına da gelebilir mi?
Hacker News görüşü
Yüzeysel olarak her şeyi kod satırı sayısıyla (LOC) ölçmek parçalı bir yaklaşım gibi geliyor. Eğer Company A, 1 milyon satır kodu çok daha temiz biçimde düzenleyip belgelendirdiyse, yetersiz yazılmış 100 bin satırlık Company B'den daha iyi bir durumda olduğu söylenebilir. Asıl sorun kod değil, karmaşıklık; satır sayısı da karmaşıklığı ancak kabaca ölçen bir gösterge. Kod bir varlıktır. Yazılım şirketinin çıktısı ve varlığıdır. Elbette varlık arttıkça karmaşıklık da artar ama bu zaten çok doğal. Tıpkı ABD otoyol ağını, bakımı zor ve karmaşık diye bütünüyle olumsuz göremememiz gibi. Yapay zeka meselesini bir kenara koysak bile, yazarın iddiası sonunda "karmaşıklık ne kadar azsa o kadar iyidir" gibi temel ve herkesin bileceği bir sonuca çıkıyor. Bu yüzden bu yazının en önemli noktası, "yapay zeka kodlama araçlarının gereksiz karmaşıklığı bitmiş koda ekleyip eklemediğini mutlaka kontrol et" düzeyine indirgenebilir
Bence burada asıl mesele karmaşıklık bile değil. Zaten ayakta kalmış bir yazılım işimiz olduğunu varsayıp tersinden bakalım: tüm maliyetleri (satın alma, maaş vb.) ilke olarak mümkün olduğunca azaltmak en iyisidir. Karmaşıklığın sadelikten daha kötü olduğu söylenir ama bunun nedeni gerçekten karmaşık olduğunda daha pahalıya mal olmasıdır. Ama nihayetinde önemli olan, kısa vadeli ya da uzun vadeli, sermaye ya da operasyonel fark etmeksizin maliyetin kendisidir. LLM tarafından üretilen kodun maliyeti düşürüp düşürmediği, yoksa artırıp artırmadığı asıl sorudur. Kod boyutu, karmaşıklık ve OP'nin ya da senin değinmediğin sayısız başka değişkenin hepsi önemlidir
Ben fonksiyonlarımın karmaşıklığına cyclomatic complexity ile bakıyorum. Karmaşıklığı SwiftLint ile ölçüp eşik değeri aşınca işaretlenmesini sağlıyorum. Bazen kabaca bölüyorum ama genelde mutlaka daha basit hale getirecek bir yol bulmaya çalışıyorum. Dosyalarım epey uzun ama yorum ile kod oranını yaklaşık 50:50 tutmaya çalışıyorum. LLM'ye karmaşıklığı azaltıp yorumları artırmasını söyleyen bir prompt verirsen bunu gayet iyi yapabilir gibi geliyor
Kod, uçucu kimyasallar gibi hem varlık hem borçtur. Doğru ve hızlı kullanırsan para kazandırabilir ama başıboş bırakırsan ya da dökersen borca dönüşür. Kaynak kod kendi kendine bozulmaz ama organizasyonun hedefleri ve süreçleri değiştikçe 'amaca uygunluk' sürekli değişir
"Neden basit yazılım yapamıyoruz?" konusu ilginç geliyor. Karmaşıklıkla ilgili olarak, "sistemler etkileşime girdiğinde karmaşıklık ortaya çıkar. Karmaşık sistemler irrasyonel noktalara savrulabilir ve beklenmedik yaratıcılık da üretebilir" kısmı etkileyici
Bana göre varlık olan şey kod değil, yazılımın kendisi. Tıpkı bir otoyolda varlığın beton değil tamamlanmış altyapı olması gibi. Betonun kalitesi, varlığın değer kaybını (amortismanını) ve bakım maliyetini etkiler; bu da tekrar varlık değerini etkiler. Buraya risk yönetimi bakış açısı da mutlaka eklenmeli
Kariyerimin başlarında çok kod yazmanın önemli olduğunu düşünürdüm. 20 yıl sonra artık daha çok kod silmekle gurur duyuyorum. Güvenlik mühendisi açısından kod sadece borç değil, aynı zamanda risktir. Özellikle dış kütüphane bağımlılıkları büyük risk oluşturur. Kısa süre önce bir iş arkadaşımla sadece Rust standart kütüphanesini kullanarak 600 satırın altında küçük bir Linux init system yazdık ve şu an çeşitli kuruluşların prod ortamında kullanılıyor. Bağımlılık yok, açılış da 1 saniyenin altında tamamlanıyor. systemd ve milyonlarca satır C kodu olmadan da appliance tarzı Linux sunucuları yapmanın gayet mümkün olduğunu hissettirdi. Kendin yapınca kod miktarı çok daha az oluyor ve tüm sistemi tamamen anlayabiliyorsun
Yapay zekanın ürettiği kod için en kötü senaryonun, şirketten ziyade daha kişisel projelerde daha net görüldüğünü düşünüyorum. Ya çok iyi bildiğim 10.000 satırlık harika kodu kendim yazabilirim ya da birkaç kat daha hızlı biçimde 20.000 satırlık, sorunlu bir kodu kabaca ortaya çıkarabilirim. Ben kendi adıma ikisinin arasında denge bulmaya çalışıyorum. Eğer geliştirmeyi sürekli büyütmek istiyorsam, ilk senaryoda harcadığım zamanın sonunda kayıp olduğunu düşünürüm
Bence her zaman bir orta nokta vardır. Benim durumumda, gerçek kod üretimini yalnızca Bash ya da Python script'leri gibi kendi içinde tamamlanan kodlarda yapay zekaya bıraktım. Bu script'ler sadece komut satırıyla etkileştiği için sınırları netti ve yönetmeleri kolaydı. Böyle kodları bir kez yazdıktan sonra bir daha bakmadım. Ama çekirdek iş alanı kodunu yapay zekayla üretmenin pek anlamı yok, o yüzden yapmıyorum. Nasıl olsa code review gerekiyor ve benim gerçekten ihtiyaç duyduğum şey, kodun bakım yapılabilirliğinin doğrulanabildiği durumlar. Kodu olduğu gibi atabileceğin ya da sadece basitçe gözden geçirmenin yeterli olduğu durumlar değilse, kod üretim araçlarını kullanmaya gerek yok. Eğer yapay zeka ürün sahibi rolünü üstlenip gerçek iş kaybını anlayıp iyileştirme de yapabilirse durum değişir ama o zaman da kullanıcıların ortadan kalkması riskini düşünmek gerekir
Ben de yapay zekaya çok fazla kod emanet ettiğim her seferde, bir noktada kaybedilmiş üretkenliğin bedelini ağır ödedim. Eğer her şey vibe coding ile yapılmış bir uygulamaysa, en gerekli beceri muhtemelen “bu özelliğe gerçekten ihtiyaç var mıydı?” diye karar verebilmek olur. Spagetti kodu debug ederken satır satır ne yaptığını hiç anlayamamak gerçekten çok acı verici olurdu
İlk durumda zaman kaybedildiğini söyledin ama ikinci durumda da (daha kötü kod, daha hızlı süre) sonuçta yine zaman kaybı var. Bence öz mesele orta noktayı bulmak
Kısa, değişken adları kötü seçilmiş ya da fazla zeki davranan kod; uzun ama iyi belgelenmiş ve zengin değişken adlarına sahip koda göre çok daha kötüdür. Borç sonuçta kodu anlama, değiştirme ve genişletme için harcanan zamanla orantılıdır. Kod satır sayısı da borcu kusursuz ölçen bir metrik değildir. Gerçekten tüm koşullar aynıysa, kod miktarını azaltmak okunabilir kodu feda ederek borcu artırabilir. Bu yüzden 'teorinin yokluğu borçtur' iddiası daha doğru gibi geliyor. Hatta kısa kodun kendisi LLM açısından bir borç olabilir. Çünkü LLM kullanımı teori kurmayı en aza indiriyor; bu da özellikle yapay zekanın proje bütünü hakkında kendi başına teori oluşturup bunu mühendise doğru biçimde aktaramadığı bugünkü durumda daha da geçerli
Programlamayı bir teori inşa etme süreci olarak görmeyi seviyorum. Özellikle iş yazılımlarında bu teorinin iş odaklı olması gerekir. Örneğin, "bu kod tabanına geliştirici kolayca alınabilir mi", "iş modeli ne kadar istikrarlı", "her özelliğin iş açısından önemi nedir" gibi bakışların mutlaka dahil edilmesi gerektiğini düşünüyorum
Aklıma bir fikir geldi. Acaba yapay zekaya kod içindeki değişken adlarını / fonksiyon açıklamalarını sormak mümkün mü diye merak ediyorum. Şimdiye kadar yapay zekayı sadece kod üretimi için kullandım
Uzun süre çalıştığım şirketler arasında, kendi kod varlığı olmayan ama ana işi dışarıdaki 3rd party kurumsal servislere dayanan yerler de vardı. Buradaki sorum şu: böyle bir durumda gerçekte ne kadar kodumuz olduğunu nasıl ölçmeliyiz? Örneğin eski bir SaaS sağlayıcısına bağımlıysak, onların kod satırlarını da bizim borcumuz olarak mı görmeliyiz diye düşünüyorum
Bence 3rd party servislere bağımlı olmanın en büyük riski, onların batması ya da satın alma/birleşme sonrası hizmet koşullarının değişmesi. Çoğu zaman da, yalnızca sermayesi büyük startup'ların hizmetinin gerçekten kendi ayakları üzerinde duramadığı durumlarda bunları kullanmak zorunda kalıyoruz
Buna tamamen katılıyorum. Önceki şirketimde bir e-posta pazarlama SaaS'i kullanıyorduk; yazdığımız entegrasyon kodu sadece 500 satırdı ama serviste o kadar çok sorun vardı ki sürekli yangın söndürmek zorunda kaldık. Sonunda sadece ihtiyaç duyduğumuz özellikleri yeniden uygulayıp şirket içine aldık; böylece büyük ölçüde maliyet ve zahmetten kurtulduk, kod satırı sayısı da yaklaşık 3 bin arttı
Pek anlayamadım.
Kodun kesinlikle bir varlık olduğu açık ama donanım gibi o da çeşitli nedenlerle (hatalar, yazılım/donanım sektöründeki değişimler vb.) değer kaybeder. Yazılım kodu arttıkça her yıl amorti edilmesi gereken maliyet de yükselir. Yeterince yönetilmezse (ör. geliştirici sayısına göre fazla kod varsa) ileride sorunları düzeltme maliyeti katlanarak artar. Sanki amortisman kavramına 'faiz' eklenmiş gibi. Bu yüzden 'borç' ifadesinin neden kullanıldığını anlıyorum ama tamamen birebir örtüşen bir kavram değil
Elbette en mükemmel depo bence şu
Eskiden ayda eksi 20 bin satır kod silmekle övünürdüm. Birkaç yıl önce bunu 20 kişilik uzaktan çalışan bir geliştirici ekibiyle yeniden yapmaya çalıştım ama pull request'ler o kadar yağdı ki yetişemedim. Şimdi Claude Code ve GPT ile pair programming yapıyorum, tamamen ikinci durum gibi hissettiriyor. Burada akıllı refactoring fırsatları olduğunu düşünüyorum. Ama muhtemelen daha fazla bağlam gerekiyor. Cursor ve Claude opus 4.1 ile legacy kodda bunu denedim ama 1 milyon token bile yetmedi. Belki kişisel bir LLM ile paylaşılan bir LLM arasında çeviri yapan bir yapı işe yarar diye düşünüyorum; buna benzer deneyimi olan var mı merak ediyorum
Kimse "özellik X'i eksiksiz uygulamak için mutlak olarak gereken en az kod miktarı nedir?" gibi çok önemli bir soruyu pek sormuyor gibi geliyor. Elbette buna tam cevap vermek imkansız ama bu şekilde düşünmek başlı başına verimli bir zihniyet oluşturuyor. Buna karşılık insanlar, pratikte pek önemli olmayan formal verification gibi şeylere çok ilgi duyuyor. Minimum uygulanabilir kod miktarı dikkate alınmadan formal verification yapmak israfçı ve anlamsız hale gelebilir. Ayrıca genelde mühendisin yazdığı kodun iyi olduğu varsayılır ama gerçekte çoğu zaman gereksiz soyutlama ve karmaşıklık ekleyerek işi daha da artırır. Yazılım mühendisliğinin önemli bir kısmı aslında eksi değer üretir. Tabii artı ve eksi yanlar iç içe olduğundan karar vermek daha da zorlaşıyor