- Uzun vadeli üretkenliği, yeni kod yazma hızından çok bakım maliyeti belirler
- Örnek modelde 2,5 yıl sonra bakım, toplam zamanın yarısından fazlasını kaplar
- Yapay zeka ajanı hem çıktı miktarını hem de bakım maliyetini artırırsa etkisi hızla ortadan kalkar
- Ajan kullanımı bırakıldığında bile daha önce üretilen kodun ek bakım maliyeti varlığını sürdürür
- Çıktı iki katına çıkıyorsa, kod başına bakım maliyetinin de yarıya inmesi gerekir
Bakım maliyeti üretkenliği belirler
- Kod yazmak için harcanan her zaman, sonrasında hata düzeltme, düzenleme ve bağımlılık yükseltmeleri gibi bakım işlerini sürekli olarak doğurur
- Burada yeni özellikler ya da iyileştirmeler değil, kod var olduğu sürece her yıl tekrar eden bakım işleri ele alınıyor
- Örnek tahminde, her 1 aylık kod yazımı için ilk yıl 10 gün, sonraki her yıl ise 5 gün bakım süresi gerektiği varsayılıyor
- Wisdom of the Crowd yaklaşımıyla yaklaşık 50 geliştiriciye bakım maliyeti sorulursa oldukça isabetli bir yanıt alınabileceği düşünülüyor
- Bu varsayımla oluşturulan elektronik tablo modeli, yeni bir projenin başında zamanın çoğunun özellik geliştirmeye gittiğini, ancak zaman geçtikçe eski kodun bakım payının büyüdüğünü gösteriyor
- Bu tahmine göre 2,5 yıl sonra bakıma harcanan zaman toplamın yarısını aşıyor; 10 yıl sonra ise neredeyse başka iş yapmak zorlaşıyor
- Bakım tahmini yarıya indirilirse %50 noktasına ulaşmadan önce 3 yıl daha kazanılıyor; iki katına çıkarılırsa üretkenlik 1 yıl dolmadan %50'nin altına düşüyor
- Üretken bir ekip istiyorsanız, yeni kod yazma hızından çok bakım maliyetine odaklanmanız gerekir
Model yanlış olabilir ama yön doğru
- Geç aşama girişimlerde, yaklaşık 5-9 yıl sonra ekibin artık işleri düzgün biçimde tamamlayamaması sorunu görüldü; bu da grafiğin gösterdiği örüntüye benziyordu
- Gerçek ekiplerin grafikteki kadar kötü görünmemesinin nedeni bakım maliyetlerinin daha düşük olması ya da sorunun başka yollarla örtülmesi olabilir
- Olası tepkiler arasında tüm hataları düzeltmemek veya tüm bağımlılıkları yükseltmemek, ekip yavaşladığında yeni insanlar eklemek ve eklemeye devam etmek ya da her şeyi bırakıp baştan yazmak var
- Kesin rakamlar tartışılabilir, ancak zamanla üretkenliğin azalması yönündeki büyük eğilim deneyimle uyumlu görünüyor
Yapay zeka kodlama ajanlarının yarattığı çarpan etkisi
- Örnek olarak, en yeni ajan tabanlı kodlama çerçevelerinden Rock Lobster'ın kod çıktısını iki katına çıkardığı varsayılıyor
- Aynı anda kodun biraz daha zor anlaşılır hale geldiği, ekibin pull request yükü altında ezildiği ve onay öncesinde kodun düzgün okunmadığı da varsayılıyor
- Ayda iki aylık kod üretilir ve bu çıktının bakım maliyeti de iki katına çıkarsa, bir sonraki ayın bakım maliyeti 4 katına çıkar
- Bu uç örnekte, Rock Lobster kullanıldıktan yaklaşık 5 ay sonra üretkenlik başlangıç düzeyine geri dönüyor; birkaç ay sonra ise hiç kullanılmamış olmasından daha kötü hale geliyor
- Buradaki amaç, yapay zekanın gerçekten üretkenliği veya bakım maliyetini ikiye katladığını söylemek değil; bakım yapılabilirlik insan yazımı kodla aynı olsa bile üretkenlik kazancının uzun sürmeyeceğini vurgulamak
Ajan bırakıldığında da bakım maliyeti kalır
- Kodlama ajanlarının bir maliyeti vardır ve faydası bu maliyetin altına düştüğünde eski çalışma biçimine dönmek istenebilir
- Ajan kullanımını bıraktığınızda üretkenlik kazancı kaybolur, ancak ajanla üretilen kodun ek bakım maliyeti kod var olduğu sürece kalır
- Bu durumda, ajan hiç kullanılmamış olsaydı elde edilecek seviyeden daha düşük bir üretkenliğe hapsolabilirsiniz
Geçerli olan matematik yalnızca bakım maliyetini düşürmektir
- Toplam üretkenlik hesabının tutması için, LLM'nin kod çıktısını artırma oranının tam tersi kadar bakım maliyetini düşürmesi gerekir
- Çıktı iki katına çıkıyor ve bu çıktının bakım maliyeti de iki katına çıkıyorsa, toplam bakım maliyeti 4 katına çıkar
- Çıktı iki katına çıkıyor ama çıktı başına bakım maliyeti aynı kalıyorsa bile toplam bakım maliyeti yine 2 katına çıkar
- Çıktı iki katına çıkıyorsa bakım maliyeti yarıya inmeli; çıktı üç katına çıkıyorsa bakım maliyeti üçte bire düşmelidir
- Ancak bu koşul sağlanırsa hız kazancı elde edilirken uzun vadeli bağımlılıktan kaçınılabilir
Mevcut kodlama ajanlarına dair kaygılar ve diğer olası kaldıraçlar
- Hacker News gibi kaynaklarda, kodlama ajanlarının bakım maliyetini artırdığına işaret eden çok sayıda sinyal var gibi görünüyor
- Bazıları bunların büyük sistemleri anlamaya yardımcı olduğunu söylese de, gerekli düzeyde büyük bir bakım maliyeti düşüşü görülmüyor; hatta bunun tersine daha yakın olduğu düşünülüyor
- Model gerçeği kusursuz biçimde temsil etmese de, yapay zekanın yeni kod yazma hızına orantılı şekilde bakım maliyetini azaltması gerektiği mesajı geçerliliğini koruyor
- Kodlama hızını artırmaya çalışıyorsanız, bakım maliyetini iyileştirmeye de aynı ölçüde zaman ayırmanız gerekir
- Bu bir yapay zeka karşıtı argüman değil; kodun kendisinin bakım yapılabilirliğini artırmasa bile, bakım işinin kendisini daha üretken hale getiren yapay zeka gibi başka kaldıraçlar da olabilir
- Varsayımları kendi gerçek durumunuza uyarlamak isterseniz, elektronik tabloyu kopyalayıp modeldeki çeşitli değişkenleri ayarlayabilirsiniz
1 yorum
Hacker News görüşleri
Dconf'24 sunumu Software as investment içinde, yazılımın her parçası için birleştirilebilir değer fonksiyonlarına dayanan temel bir çerçeve önerilmiş
Bu çerçevenin kendisinin yapay zeka yüzünden özellikle değişmesi gerekmiyor; ayrı olarak sadece bakımda yapay zekanın ne kadar iyi olduğuna göre maliyet modelini güncellemek yeterli
Yapay zekanın 1,7 kat daha fazla bug ürettiği söyleniyor ama belki daha hızlı da düzeltiyordur, o yüzden emin değilim
Yazılıma yatırım olarak bakınca “teknik borç” yerine “değer” konuşuluyor ve borç da değeri 0'ın altında olan bir varlıktan ibaret oluyor
Yazılım geçmişteki yüksek marjlı dünyadan çıkıyorsa, ekonomik olarak var olmaya değer yazılımın ne olduğunu hassas biçimde tanımlamak gerekiyor
Yazılımda her zaman daha iyi yazılabilecek kısımlar vardır ve borç da budur
İçgörülü bir bakış açısı ve katılıyorum
Ne yazık ki bakım yapılabilirlik genelde “işlevsel olmayan gereksinimler” sepetine atılıyor
Oysa bakım yapılabilirlik gibi işlevsel olmayan gereksinimler, gelecekteki işlevsel gereksinimlerin teslimini koruyan ve mümkün kılan şeyler olarak görülmeli
Bunu sadece yazılımın ne yapması gerektiğine karşılık “nasıl yapması gerektiği” diye çerçevelemek doğru değil
Sürekli özellik ekleme ve iyileştirmenin önemli olduğu projelerde, çok kısa dönemler dışında bakım yapılabilirlik fiilen işlevsel gereksinime yakındır
Ona ayrı bir isim verdiğiniz anda, konuyu iyi anlamayan birine bunu ayrı bir bölmeye koyup önceliğini düşürmek için bahane vermiş olursunuz
Kalite önemlidir ve korunmazsa gelir tablosuna çok hızlı ve sert biçimde yansır
Bu yüzden diğer tüm unsurlar kadar önemlidir
Kevlin Henney'nin kullandığı operasyonel özellikler ve geliştirme özellikleri ifadeleri kullanılabilir
Bakım yapılabilirlik temel bir geliştirme özelliğidir
Ellerinde 1-2 yıllık ürün yol haritası olabilir ama dürüst olmak gerekirse bu yol haritaları çoğu zaman mühendislik planından çok satış amacı taşıyor
Gelir düşmeye başlayınca ürün ve mühendislik yön değiştiriyor ve şirket ne kadar erkense bu o kadar sık oluyor
Startup modundan çıkınca istikrar kazanılması gerekir ama birçok şirket bunu yapmıyor ve kısa vadeli planlama kalıbını sürdürmeye devam ediyor
Sonuç olarak ürün istikrarı düşük öncelikli kalıyor
Nihayetinde birçok şirketin iyi yazılım üretmeye ya kaynağı yetmiyor ya da gerçekten umursamıyor gibi görünüyor
Kendi projemizi geliştirirken gördük ki yapay zeka hızlı ama eklediği bug'ları bulmak tuhaf biçimde zor oluyor
Bunlar bariz bug'lar değil; üç hafta sonra production ortamında bir şey bozuluyor ve izini sürdüğünüzde yapay zekanın ince bir noktayı yanlış anladığı ortaya çıkıyor
Dürüst olmak gerekirse yapay zeka bakım maliyetini azaltmaktan çok maliyetin yerini değiştiriyor
Yazma süresi azalıyor, gözden geçirme süresi artıyor
Yapay zeka kodu yanlış olduğunda bile akıcı ve kendinden emin göründüğü için, insan koduna kıyasla incelenmesi daha zor oluyor
Net kazanç sağlayıp sağlamadığı, ekibin kod yazmaktan çok kod okuma becerisine ne kadar sahip olduğuna tamamen bağlı
Benim deneyimimde yapay zeka bakım maliyetini azaltıyor
Ama bağlam önemli olabilir. Ben onlarca yıllık birden fazla projeyle uğraşıyorum; yeni özellik geliştirme de çok var ama eski kod ve eski projeler bir anda çok daha yönetilebilir ve modernize edilmesi çok daha kolay hale geldi, hatta birçok durumda tamamen kaldırılabildi
Eski kütüphane ve build aracı bağımlılıkları bazı durumlarda güncellendi, bazı durumlarda ise tamamen kaldırıldı; build süreçleri hızlandı ve geliştiriciler için kolaylaştı
Uçtan uca test kurulumu ve otomasyonu da çok daha kolaylaştı, DevOps büyük ölçüde iyileşti ve operasyonel sorunların teşhisi de ciddi biçimde gelişti
Çok fazla log ve bilgi, önemli noktaları yakalamaya yönelik birleşik dashboard'lar ve izleme zaten vardı ama artık production'daki yaklaşık 50 proje üzerinde çok daha fazla analiz yapabiliyorum
Yazının temel iddiası, 1 saatlik “değer katan” özellik geliştirme için kaç saat bakım gerektiğiyle ilgili
Dolayısıyla birincisi yalnızca bakım maliyetine bakmamalı, oranı görmeliyiz; ikincisi de o eski kod zaten baştan yapay zekayla yazılmış değildi
Ama yazarın asıl anlatmak istediği şey, yapay zeka araçlarına erişimi kaybedersen her şeyin çok daha zorlu hale geleceği gibi görünüyor
Ağır iş makineleriyle dağı rahatça taşıyorken tekrar el aletlerine dönmek gibi
Deploy edilen kod satırı arttıkça incident sayısı da arttı ve incident'lar giderek daha ciddi hale geliyor
Elbette çok eski kodu iyileştirdik, daha da fazlasını sildik, kod modernizasyonunu otomatikleştirebiliyoruz, sorun teşhisimiz daha iyi ve hafifletme seçeneklerimiz daha fazla
Ama bunların hiçbiri, kimsenin gerçekten anlamadan production'a çıkan kodun ezici hacmini dengelemeye yetmedi
Ekibimiz yapay zekayı kod eklemek için kullandığı gibi, eskimiş ve terk edilmiş kodu agresif biçimde kaldırmak için de kullanıyor
“Bunu hâlâ kullanan var mı?”, “Bu nasıl çağrılıyor?” gibi sorular, frontend'i, backend'i ve tüm codebase'i ajana verip yazılım projesinin bir haritasını çıkarttırınca cevaplaması kolay hale geliyor
IDE'ler de tek bir dil ve genellikle tek bir proje içinde bunu bir ölçüde yapabiliyor ama RPC veya REST gibi sınırlar fazla olduğunda IDE araçları bozuluyor
Şu soru gerçekten hoşuma gidiyor: Seçme şansın olsa nasıl bir codebase isterdin?
Biraz düşününce muhtemelen aşırı fazla özelliğe sahip bir codebase istemezsin
Şu anda sahip olduğuna epey benzeyen ama anlaşılması daha kolay, gelecekteki iş ihtiyaçlarına göre bakımı ve genişletilmesi daha kolay bir codebase istersin
“Çalışan” bir codebase, yani bakımını yaptığınız bir codebase, gerçek dünyadaki sorunları çözer ve bu sorunları çözmek de her zaman tertemiz olmaktan daha öncelikli olmalıdır
Tertemiz bir codebase çoğu zaman rafa konulup seyredilen bir vitrinlik örnek olur
İki şey eklemek istiyorum
Birincisi, yazılımda sadece teknik bakım yoktur; bir de kullanıcı desteği vardır ve yazılım büyüdükçe bu da artar
İkincisi, bakım maliyetinin doğrusal arttığından emin değilim
Doğrusal artsa bile sonunda tüm zamanınızı bakıma harcadığınız bir noktaya ulaşırsınız
Sadece her parçayı değil, parçaların birbirleriyle nasıl etkileştiğini de sürdürmek gerekiyorsa bu mümkün olabilir
Yapay zekanın gerçekten bakım maliyetini azaltıp azaltmadığına dair gördüğüm en güçlü sinyal, geliştiricinin yapay zeka çıktısını bir taslak olarak mı yoksa nihai çıktı olarak mı gördüğüdür
Mevcut bir codebase üzerinde yapay zeka araçları kullanıldığında, örneğin yabancı bir modülü anlamak, hedefli refactoring üretmek ya da migration script'i yazmak gibi işlerde bakım yükü gerçekten azalıyor
Çünkü yapay zekanın üzerinde çalıştığı kodun mimarisini zaten anlıyorum ve bu sayede çıktıyı hızlıca değerlendirebiliyorum
Sorun, yapay zekanın kimsenin derinlemesine anlamadığı yeni kod üretmesiyle başlıyor
O kodun bakımını, onu ne yazmış ne de tasarlamış olan biri yapmak zorunda kalıyor
Başka birinin yazdığı kodda en azından isimlerden, yapıdan ve commit geçmişinden niyeti çıkarabilirsiniz
Yapay zeka üretimi kodda ise dosya genelinde tutarlı bir niyet taşıyan bir “yazar” olmadığı için bu tür okunabilir niyet çoğu zaman eksik oluyor
Yazının haklı olduğu nokta, yalnızca hızı değil bakım maliyetini de ölçmek gerektiği
Gerçekte günler değil aylar boyunca, yapay zeka destekli kod ile insan tarafından yazılmış kodun anlaşılma süresi ve değişiklik başarısızlık oranı izlenmeli
Code review için de aynı şey geçerli
Yapay zekanın code review'ları daha okunabilir hale getirip getiremeyeceğini merak ediyorum
İnsan code review'larında geliştiriciler, kodu ya da yorumları yeniden akıtmaktan, aracın gizleyemediği girintiyi değiştirmekten, fonksiyon taşımaktan ya da satır silmekten kaynaklanan gereksiz görsel değişikliklerden kaçınmayı hızlıca öğreniyor
Gereksiz refactoring de yapılmamalı
Belki review'ları davranış değişikliği ve görsel değişiklik olarak ikiye ayırmak mümkün olabilir
O zaman review çok daha kolay olur
Review, “hiçbir şey değişmemeli” varsayımıyla başlar ve reviewer pattern matching yapabilir
Aksi halde reviewer her satırı yeniden değerlendirip gerçekten hiçbir şey değişmediğini doğrulamak zorunda kalır ki bunu düzgün yapmak gerçekten zordur
Kullandığım sürüm kontrol sistemlerinin hepsi, her biri bağımsız biçimde review edilen değişiklik kuyruklarına izin veriyordu
Geliştirme sırasında refactoring gerekirse bir commit açıp refactoring yapılır, review'a gönderilir, sonra devam eden iş rebase edilip sürdürülür
“CLEANUP:” ve “REFACTOR_ONLY:” gibi değişiklikleri sürekli akıtırsanız nihai değişiklik devasa bir canavar değişiklik yerine çok daha küçük olur
Reviewer'lar bu emeği takdir edecektir
Böyle bir organizasyonda metrik oyunları da kötüye kullanılmadan yapılabilir
Yazar sanki insanların tüm yapay zeka kodunu ayrıntılı biçimde incelemesi ve yapay zeka yardımı olmadan anlayıp bakımını yapabilmesi gerektiği varsayımından hareket ediyor
Benim deneyimimde insanlar yapay zekayı böyle kullanmıyor
Başta öyle başlıyorlar. Güvenmeden önce ve istedikleri sonucu almak için nasıl prompt yazacaklarını öğrenmeden önce, sıkıcı kısımları otomatikleştirmek için kullanıyorlar ama ilk uygulama ya da kalıpları insan kuruyor, yapay zeka boşlukları dolduruyor
Bu, kod yazma biçiminde büyük bir dönüşümden çok güçlendirilmiş otomatik tamamlama gibi
İnsanlar yapay zekayla daha fazla çalıştıkça, onun gerçekten ürettiği kod konusunda daha az endişeleniyor
Bu iyi demek değil. Bug, performans sorunu ya da güvenlik açığı üretebilir
Ama gerçeklik böyle. Yapay zeka kodu bug mı üretti? Yapay zekaya düzeltmesini söylersin
Yapay zeka kodu şişkin ve okunması zor mu? Umursuyorsan yapay zekaya düzelt dersin. Birçok kişi umursamıyor
İnsan bakım sürecinden tamamen çıkarsa, bakımı yapılabilir kod ihtiyacı da ortadan kalkar
Henüz %100 orada değiliz ama o yöne gidiyoruz
Birçok şirket için zaten yeterince iyi olduğu için riski alıp YOLO gitmek değerli
Ben kişisel olarak yapay zekanın ürettiği kodu okumayacak kadar ona güvenmiyorum ama her satırı da okumuyorum
Test edilen koddan çok testlere dikkatle bakıyor, performans açısından kritik bölümlere daha fazla önem veriyor ve genel yapıyı yönlendiriyorum
Yine de standartları karşılamıyorsa, kendim bakım yapmak yerine yapay zekaya düzeltmesini söylüyorum
Bakım bu kadar ucuzsa, bakım maliyeti de benim için önemli bir başlık olmaktan çıkıyor
Bu yazı, yapay zeka ajanlarının ya da yardımcı araçların sadece başlangıçtaki “yeni bir widget yap” kısmında değil, yazılım geliştirmenin birçok bölümünde yardımcı olması gerektiğini iyi vurguluyor
Yazarın görüşüne göre biri yapay zeka ajanlarını ya da yardımcılarını yalnızca yeni widget üretme aşamasında kullanırsa, yapay zekayla daha fazla kod çıkardığı için bakımını yapmak zorunda kalacağı kod miktarı da ciddi biçimde artar
Kod kalitesi yüksek olsa bile zamanla bakım maliyeti ortaya çıkar
Ancak yazarın anlattığı sorunun tamamı herkesin kaçınılmaz olarak yaşayacağı bir durumdan çok, önemli ölçüde kendi oluşturduğu bir soruna benziyor
Yazarın işaret ettiği startup durumu, yani “ürün-pazar uyumunu görüp müşteri kazanmak için önce ne olursa olsun bunu çalıştır” yaklaşımı, zaten eskiden beri sonradan daha yüksek bakım maliyetiyle geliyordu
Çünkü gerçekten bir iş olup olmadığını görmek ve varsa hızlıca büyütmek için hız uğruna kalitenin bir miktar düşürülmesi belli ölçüde mantıklı
Ayrıca yazarın, yapay zekanın bakım tarafında pratikte nasıl yardımcı olabileceğinden söz etmekten özellikle kaçındığı hissine kapıldım
Yapay zeka, insan yönlendirmesiyle eski bağımlılıkları düzeltmekte ya da can sıkıcı bug'ları çözmekte çok faydalı olabilir
Bunlar yazılım mühendislerine angarya gibi gelebilen ve yapay zeka desteği istenen türden işlerdir