Kod yazımında kullanılan yapay zeka kodlama ajanları, bakım maliyetlerini mutlaka azaltmalı
(jamesshore.com)- AI kodlama ajanları kod yazma hızını artırsa bile bakım maliyetlerini aynı oranda azaltamazsa, geçici üretkenlik artışının ardından tersine kalıcı bir üretkenlik düşüşüne yol açar
- Yazılan her kod, sonrasında hata düzeltme, temizlik, bağımlılık yükseltmeleri gibi sürekli bakım gerektirir ve zaman geçtikçe bakım toplam çalışma süresinin büyük kısmını kaplar
- Kod çıktısı 2 katına çıkarken bakım maliyeti de 2 katına çıkarsa, gerçek bakım maliyeti 4 kat artar ve birkaç ay içinde üretkenlik avantajı ortadan kalkar
- AI kaldırılsa bile, daha önce üretilmiş kodun bakım yükü kalır; bu da AI hiç kullanılmamış duruma göre daha düşük üretkenliğe saplanmaya neden olur
- Üretkenliği 2 kat artırmak için bakım maliyetini tam olarak yarıya indiren bir AI gerekir; kodlama hızını artırmaya verilen çabayla bakım maliyetini azaltmaya da eşit düzeyde çaba harcanmalıdır
Bakım maliyeti üretkenliği belirler
- Kod yazmaya harcanan her zaman, sonrasında hata düzeltme, temizlik ve bağımlılık yükseltmeleri gibi bakım sürelerini sürekli olarak üretir
- Konu, yeni özellikler ya da iyileştirme çalışmaları değil; kod var olduğu sürece her yıl tekrarlanan bakımdır
- Örnek tahmin, yazılan her 1 aylık kod için ilk yıl 10 gün, sonrasındaki her yıl 5 gün bakım gerektiği varsayımına dayanır
- Wisdom of the Crowd yöntemiyle yaklaşık 50 geliştiriciye bakım maliyetini sorarsanız oldukça doğru bir yanıt alınabileceği düşünülüyor
- Bu varsayımla oluşturulan elektronik tablo modeline göre, yeni bir projenin başlarında zamanın çoğu özellik geliştirmeye giderken zamanla geçmişte yazılmış kodun bakım payı büyür
- Bu tahminde 2 buçuk yıl sonra bakıma harcanan süre toplamın yarısını aşar ve 10 yıl sonra neredeyse başka iş yapmak zorlaşır
- Bakım tahminini yarıya indirirseniz %50 noktasına kadar 3 yıl daha kazanabilirsiniz; iki katına çıkarırsanız üretkenlik 1 yıl dolmadan %50'nin altına düşer
- Ü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şamadaki startup'larda 5-9 yıl civarında, ekibin artık işleri düzgün biçimde tamamlayamadığı bir sorun görülüyordu; 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ı da olabilir, sorunun başka yollarla örtülmesi de
- Olası tepkiler; her hatayı düzeltmemek ya da her bağımlılığı yükseltmemek, ekip yavaşladıkça yeni insanlar eklemek ve eklemeye devam etmek, ya da her şeyi bırakıp baştan yazmaktır
- Kesin rakamlar tartışılabilir, ancak zaman geçtikçe üretkenliğin düştüğü genel eğilim deneyimle uyumlu görünüyor
AI kodlama ajanlarının yarattığı çarpan etkisi
- Örnek olarak, en yeni ajan tabanlı kodlama framework'ü Rock Lobster kod çıktısını iki katına çıkarıyor varsayılıyor
- Aynı anda kodun biraz daha zor anlaşılır hale geldiği, ekibin pull request'ler altında ezildiği ve onaydan önce kodu gerçekten okumadığı da varsayılıyor
- Ayda 2 aylık kod üretilir ve bu çıktının bakım maliyeti de 2 katına çıkarsa, sonraki ayın bakım maliyeti 4 katına çıkar
- Bu uç örnekte Rock Lobster kullanıldıktan yaklaşık 5 ay sonra üretkenlik yeniden başlangıç seviyesine döner ve birkaç ay sonra hiç kullanılmamış olmasından bile kötü hale gelir
- Bunun anlamı AI'ın gerçekten üretkenliği ya da bakım maliyetini iki katına çıkardığı değildir; asıl vurgu, bakım yapılabilirliği insanların yazdığı kodla aynı olsa bile üretkenlik kazancının uzun sürmeyeceğidir
Ajanlar durdurulsa da bakım maliyeti kalır
- Kodlama ajanlarının bir maliyeti vardır ve sağladıkları fayda bu maliyetten küçük kalırsa eski yönteme dönmek istenebilir
- Ajan kullanımını durdurunca üretkenlik kazancı kaybolur, ancak ajanla üretilen kodun ek bakım maliyeti, o kod var olduğu sürece kalmaya devam eder
- Bu durumda, ajan hiç kullanılmamış olsaydı elde edilecek üretkenliğin bile altına kilitlenilebilir
İşleyen matematik yalnızca bakım maliyetinin düşmesidir
- Genel üretkenlik hesabının tutması için, LLM'nin kod çıktısını artırdığı oranın tam tersine denk gelecek ölçüde 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 da kaçınılabilir
Bugünün kodlama ajanlarına dair kaygılar ve olası başka kaldıraçlar
- Hacker News gibi kaynaklarda, kodlama ajanlarının bakım maliyetini artırdığına dair çok sayıda işaret olduğu görülüyor
- Bazıları büyük sistemleri anlamaya yardımcı olduğunu söylüyor, ancak gerekli ölçekte büyük bir bakım maliyeti düşüşü görünmüyor; hatta bunun tersine daha yakın olduğu düşünülüyor
- Model gerçekliği kusursuz biçimde temsil etmese de, AI'ı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ırmayı hedefleseniz bile, bakım maliyetini iyileştirmeye de aynı ölçüde zaman ayırmanız gerekir
- Bu, anti-AI bir argüman değil; kodun kendisinin bakım yapılabilirliğini artırmasa bile, bakım işinin kendisini daha üretken hale getiren AI gibi başka kaldıraçlar da olabilir
- Varsayımları gerçek durumunuza göre değiştirmek isterseniz elektronik tabloyu kopyalayıp modelin çeşitli değişkenlerini ayarlayabilirsiniz
2 yorum
Yapay zekaya güvensizliğin ortaya çıkmasının en temel nedeni,
şu anda çoğu uzmanın (sözde) kendilerinin başkalarının sözünü ettiği yapay zeka dezavantajlarını yaşamadığını ve herhangi bir trade-off da olmadığını yüksek sesle savunup adeta pazarlamacı gibi davranmasıdır.
Zaten dolandırıcıların sayısı arttığı için bütüne karşı bir güvensizlik birikmiş durumda.
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