Yapay zeka destekli kodlama hakkında yanlış yapılabilecek on iki şey

 (third-bit.com)
9 puan yazan GN⁺ 2 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • Yapay zeka destekli kodlamanın değeri, satır sayısı, ticket sayısı, memnuniyet gibi kolay sayılara indirgenmesi zor bir konu ve değerlendirme biçimine göre sonuçlar çarpıtılabilir
  • Kod satırı sayısı ile commit, Pull Request ve ticket sayıları yalnızca faaliyet hacmini ölçer; hedefe dönüştükleri anda kolayca manipüle edilir ve kaliteyi ayırt edemez
  • Kabul oranı ve benimsenme oranı, yalnızca önerilerin makul göründüğünü ya da aracın dağıtıldığını gösterir; doğruluk, güvenlik ve bakım yapılabilirlik garantisi vermez
  • Oyuncak görevler, kontrol grubu olmayan öncesi-sonrası karşılaştırmaları, gönüllü kullanıcı karşılaştırmaları ve zayıf başlangıç çizgileri, LLM etkisini seçim yanlılığından ayırmayı zorlaştırır
  • Verimlilik değerlendirmesi için review, debugging, güvenlik, teknik borç, ekip darboğazları ve uzun vadeli değişimleri içeren sistem düzeyi metrikler gerekir

Ne değerlendiriliyor ve hangi varsayımlarla?

  • Yapay zeka destekli kodlama araçlarının abonelik maliyetine değip değmediğini kanıtlamaya çalışırken üretilen kod satırı sayısı, tamamlanan ticket sayısı ve geliştirici memnuniyeti anketleri farklı şekillerde yanlış sonuçlara götürebilir
  • Temel mesele, LLM destekli kodlamanın değerinin kendisi değil; bu etkinin ne kadar kolay yanlış değerlendirilebildiğidir
  • Aynı eleştiriler, az bir uyarlamayla çevik geliştirme, test güdümlü geliştirme ve diğer yazılım geliştirme pratikleri hakkındaki iddialara da uygulanabilir
  • Buradan çıkan sonuç, yazılım mühendisliğinin insan bilimlerindeki araştırma yöntemlerini gerektiği gibi benimsemiş olması halinde bu tür olgu araştırmalarında çok daha ileride olacağıdır

Yanlış verimlilik metrikleri

  • Üretilen kod satırlarını saymak

    • Kod satırı sayısı, doğrudan ölçülmesi zor olan verimliliğin yerine uzun süredir kullanılan bir vekil metriktir
    • LLM’ler daha fazla kod üretebilir, ancak daha iyi sonuçları garanti etmez
    • LLM kullanımından sonra geliştirici başına kod satırı sayısı %40 artan bir ekip, verimliliği değil laf kalabalığını ölçüyor olabilir
    • İç içe geçmiş mantıkla dolu 2000 satırı temiz 200 satırla değiştiren bir iyileştirme, kod satırı metriğinde kayıp gibi görünebilir
    • Daha fazla kod, okunacak, bakımı yapılacak ve debug edilecek yükü artırır; yapay zekanın bıraktığı gelecekteki yük, satır sayısı hesabında görünmez

  • Commit, Pull Request ve ticket saymak

    • McKinsey 2023’te, bireysel geliştirici verimliliğini commit, Pull Request ve code review gibi faaliyet sayılarıyla ölçmeyi önerdi
    • Goodhart yasasında olduğu gibi, bir ölçüm hedefe dönüştüğünde artık iyi bir ölçüm olmaktan çıkar
    • Commit sayısı izlenirse geliştiriciler daha küçük ve daha fazla commit üretir; ticket sayısı izlenirse ticket’lar bölünür
    • Sayılar iyileşse bile alttaki gerçek iş iyileşmeyebilir
    • Faaliyet çıktı değildir; çıktı da doğrudan değer anlamına gelmez

  • Öneri kabul oranını kalite sinyali saymak

    • LLM kodlama asistanlarının yüksek öneri kabul oranı, aracın faydalı olduğuna dair kanıt olarak sıkça sunulur
    • Kabul oranı, yalnızca üretilen kodun geliştiricinin Tab tuşuna basacak kadar makul görünüp görünmediğini ölçer; doğruluğu, güvenliği ya da bakım yapılabilirliği ölçmez
    • Zaman baskısı altındaki geliştiriciler daha fazla öneri kabul eder ve bunların arasında güvensiz öneriler de bulunur
    • 400 geliştiriciyi kapsayan bir kurumsal araştırma, ortalama %33 kabul oranı ve yüksek geliştirici memnuniyeti buldu; ancak kabul edilen kodun doğruluğu ya da güvenliği izlenmedi
    • Makul görünen şeyi ödüllendiren bir metrik, gerçekten iyi olanı ödüllendiren bir metrik değildir

  • Benimsenme oranını başarı metriği saymak

    • “Tüm mühendislik organizasyonunda AI araçlarında %90 benimsenme oranına ulaştık” ifadesi, satın alma ve dağıtım başarısıdır; verimlilik başarısı değildir
    • Benimsenme oranı yalnızca aracın kurulup açıldığını ölçer; önerilerin yararlı olup olmadığını, geliştiricilerin bunları eleştirel süzgeçten geçirmeden kabul edip etmediğini veya kabul edilen önerilerin doğru olup olmadığını söylemez
    • Yüksek benimsenme oranı düşük öneri kalitesiyle birleştiğinde geliştiriciler avantaj elde etmek yerine aracı yönetmeye zaman harcayabilir
    • IBM’in kurumsal AI kodlama asistanı çalışmasında araç çoğu zaman net verimlilik artışı sağladı, ancak bu kazanım tüm kullanıcılar arasında eşit dağılmadı
    • Benimsenme oranı, faydadan daha kolay ölçülür ve tam da bu yüzden raporlanması daha kolaydır

Deney tasarımındaki hatalar

  • Yapay görevlerde süre tutmak

    • Sık alıntılanan GitHub Copilot araştırmasında kullanıcılar, kullanmayanlara göre görevi %55 daha hızlı tamamladı
    • Görev, JavaScript ile sıfırdan bir HTTP sunucusu yazmaktı; süre sınırı 90 dakikaydı ve geliştiricilerin o gün başka yükümlülükleri yoktu
    • Gerçek yazılım geliştirme, kişinin yazmadığı büyük bir kod tabanında gezinmeyi, belirsiz ticket gereksinimlerini anlamayı, ekip arkadaşlarıyla koordinasyonu ve toplantıları içerir
    • Greenfield oyuncak görevlerindeki hız, bu gerçek işlerin hızını öngörmez
    • Deneyimli açık kaynak geliştiricileriyle yapılan randomize kontrollü bir çalışmada, katılımcıların beklentisinin tersine, AI araçlarına erişim verilen grupta görev tamamlama süresi %19 arttı

  • Kontrol grubu olmayan öncesi-sonrası karşılaştırmaları

    • Ocakta LLM kullanmaya başladıysanız ve haziranda Pull Request’ler daha hızlı deploy edilmeye başladıysa, araç etkili olmuş gibi görünebilir
    • Ama aynı dönemde 12 mühendis işe aldıysanız, CI pipeline’ını refactor ettiyseniz ve bulut sağlayıcınızı değiştirdiyseniz, nedeni ayırmak mümkün değildir
    • Aracı kullanmayan bir grup yoksa, LLM’nin etkisini aynı anda yaşanan diğer değişimlerin etkisinden ayırmak zordur
    • İç geçerlilik, araç olmasaydı ne olacağını gösterebilen güvenilir bir karşı-olgusal çerçeve gerektirir

  • Kullananlarla kullanmayanları karşılaştırmak

    • LLM kullanmayı seçen geliştiricilerle seçmeyenleri karşılaştırdığınızda, iki koşulu değil iki farklı grubu karşılaştırmış olursunuz
    • Erken benimseyenler, geç benimseyenlere ya da hiç benimsemeyenlere göre denemeye daha istekli, yeni araçlara daha alışkın ve zaten daha yüksek performanslı olabilir
    • Seçim yanlılığı nedeniyle gözlenen fark, aracın özelliğinden değil kişilerin özelliğinden kaynaklanıyor olabilir
    • Bu yaklaşım uygulama maliyeti en düşük yöntem olduğu için, sektördeki AI verimlilik raporlarında yaygın bir tasarım kusuru haline gelir
    • Büyük bir teknoloji organizasyonunda Copilot kullanımını iki yıl boyunca izleyen boylamsal bir çalışmada, kullanıcıların araç kullanılmadan önce de kullanmayanlardan sürekli daha aktif olduğu görüldü

  • AI’ı “hiçbir şey olmamasıyla” karşılaştırmak

    • AI destekli geliştiricileri hiçbir araç kullanmayan bir kontrol grubuyla karşılaştırmak, gerçek işte var olmayan bir başlangıç çizgisi seçmek demektir
    • LLM asistanı olmayan geliştiriciler de dokümantasyon, ekip arkadaşları ve problemi kendi başına düşünmek için ayırdığı zamanı kullanır
    • Asıl önemli soru, LLM aracının geliştiricinin zaten sahip olduğu alternatiflerden daha iyi olup olmadığıdır; bu tür karşılaştırmalar ise nadiren yapılır
    • Zayıf bir başlangıç çizgisi seçildiğinde her araç iyi görünür, ama bu onun gerçekten faydalı olduğu anlamına gelmez

Ölçüm kapsamındaki eksikler

  • Yalnızca kolay yarıyı ölçmek

    • LLM’ler kod üretimini hızlandırır ve bu kısmı ölçmek kolaydır
    • Daha zor olan diğer yarı ise LLM üretimi kodu inceleme süresi, kendinden emin ama yanlış öneriler yüzünden kaybedilen debugging süresi, makul görünüp güvensiz olan kodun yarattığı güvenlik açıkları ve çevredeki tasarımı görmezden gelen doğaçlama çözümlerin yarattığı teknik borçtur
    • GitHub Copilot kod çalışmasında, üretilen kodun önemli bir bölümünde güvenlik açıkları vardı ve zaman baskısı altındaki geliştiriciler güvensiz önerileri daha yüksek oranda kabul etti
    • 2025’te beş büyük LLM’nin değerlendirildiği bir çalışmada, hiçbir model endüstriyel güvenlik standartlarını karşılayan web uygulaması kodu üretemedi
    • Yapay zeka tarafından yazılan 300 binden fazla commit’in geniş ölçekli analizinde, %15’ten fazlasının en az bir kalite sorunu getirdiği ve bunların yaklaşık dörtte birinin kod tabanında uzun vadeli kaldığı görüldü
    • Sadece artan girdiyi ölçüp eşzamanlı artan maliyeti görmezden geliyorsanız, yaptığınız şey ölçüm değil pazarlamadır

  • Bireyi değil sistemi ölçmek gerekir

    • Bireysel kodlama hızı, ölçülmesi en kolay şey olduğu için sık ölçülür
    • AI araçları geliştiricilerin kodu %30 daha hızlı yazmasını sağlasa bile, ekibin ticket’tan production’a lead time’ı değişmiyorsa darboğaz kod yazımı değildi
    • Üretilen kod arttığında review edilmesi gereken kod da artar; AI yalnızca kod miktarını artırıp review kapasitesini artırmıyorsa cycle time kötüleşebilir
    • Profesyonel geliştiriciler üzerinde yapılan ampirik bir araştırmada, AI araçları daha az deneyimli katkıcıların çıktısını artırdı; ancak senior geliştiricilerin verimliliği, AI üretimi kodun yarattığı code review yükünün %6,5 artmasıyla %19 düştü
    • Hattın yalnızca tek bir aşamasını optimize edip geri kalanını yok saymak, verimlilik araştırması gibi görünen bir sistem düşüncesi başarısızlığıdır

Zaman içindeki etkiyi çarpıtmak

  • Geliştiricilere verimliliklerinin artıp artmadığını sormak

    • “Geliştiricilerin %87’si AI aracıyla kendini daha verimli hissediyor” türü anket sonuçları, aracın işe yaradığının kanıtı olarak sıkça gösterilir
    • Öz-bildirim, üç nedenle sistematik yanlış anlamalara yol açabilir
    • Hawthorne etkisi nedeniyle insanlar gözlemlendiklerini ve değerlendirildiklerini bildiklerinde farklı çalışır
    • Yeni araçlar, yeni oldukları için daha hızlı hissettiren bir yenilik etkisi yaratır; bu his genellikle birkaç hafta içinde kaybolur
    • Sosyal beğenirlik yanlılığı nedeniyle yanıt verenler, özellikle de aracı yönetim seçtiyse, anketin duymak istediğine inandıkları cevapları verme eğilimindedir

  • Yalnızca yenilik etkisi dönemini ölçmek

    • Dört haftalık bir çalışma verimlilik artışı bulduysa, bulduğu şey yalnızca dört haftalık bir verimlilik artışıdır
    • Geliştiriciler başlangıç döneminde yeni araca daha fazla odaklandığı için, gözlenen performans uzun vadeli başlangıç düzeyine göre olduğundan yüksek görünebilir
    • Asıl önemli etkiler haftalar içinde değil aylar içinde ortaya çıkar
    • AI’a devredilen işlerdeki beceri körelmesi, yanlış önerilerden biriken teknik borç ve ekip işbirliği biçimindeki değişimler uzun vadeli gözlem gerektirir
    • Kısa vadeli kazancı tespit edecek şekilde tasarlanmış çalışmalar, araştırma bittikten sonra ne olduğunu söylemez
    • Cursor kullanan 807 açık kaynak deposunun analizinde, kullanım sonrası geliştirme hızının büyük ama geçici biçimde arttığı; kod karmaşıklığı ve statik analiz uyarılarının ise belirgin ve kalıcı şekilde arttığı görüldü

Daha iyi yorumlama için sonuç

  • Verimlilik ölçümü, tek bir sayıya ya da kolay vekil metriklere indirgenmesi zor bir konudur
  • LLM destekli kodlamanın etkisini değerlendirmek için yalnızca kod yazma hızına değil; review, debugging, güvenlik, bakım yapılabilirlik, teknik borç, ekip darboğazları ve uzun vadeli değişimlere de bakmak gerekir
  • Kontrol grubu, gerçekçi başlangıç çizgileri, seçim yanlılığını denetleme, uzun vadeli gözlem ve sistem düzeyi metrikler olmadan, AI araçlarının etkisini diğer değişimlerin etkisinden ayırmak zordur
  • Ölçmesi kolay olan değerler raporlanması kolay olduğu için öne çıkar, ancak kolay değerler önemli olanların yerine geçmez
  • Yazılım geliştirme pratiklerini değerlendirmek için insan bilimlerindeki araştırma yöntemlerini daha ciddiye almak gerekir

Alıntılanan başlıca kaynaklar

İlgili okumalar

1 yorum

 
GN⁺ 2 시간 전
Lobste.rs görüşleri

  • Yazar, Software Carpentry'nin kurucularından biri; yani LLM'ler ortaya çıkmadan çok önce de yazılım üretkenliğini ölçmenin daha iyi yollarını düşünen biri
    Alıntılanan METR araştırması, yaygın olarak dile getirilen nedenden daha ilginç. Birçok kişi için manşet, “AI insanları daha yavaş hale getirdi” olmuştu ve buna 2025 tarzı LLM'lerin hâlâ gelişmekte olduğu söylenerek itiraz edilebilir
    Ama daha ilginç olan sonuç, katılımcıların sonradan kendi tahmin ettikleri değerlerin gerçek sonuçlarla yön olarak bile uyuşmamasıydı. Burada, çoğu şirketin görmezden geldiği ve her türlü ölçümü temelden zorlaştıran bir unsur var gibi görünüyor
    İnsanları daha üretken hale getirdiğine dair belirsiz hisse bile güvenilemez. İnsanlar bunu kendileri bilmiyor
    Ardından gelen devam araştırması, seçilim yanlılığı yüzünden fiilen başarısız oldu

    The primary reason is that we have observed a significant increase in developers choosing not to participate in the study because they do not wish to work without AI
    Geliştiricilerin AI olmadan çalışmayı reddetmesi, araçların iyi çalıştığı anlamına gelebilir; ama aynı zamanda araçlara giderek bağımlı hale geldikleri ve daha zor işleri yapabilme yeteneklerinin tamamen köreldiği anlamına da gelebilir

    • Benim hipotezim, insanların aslında yapmak istemedikleri kısımlarda LLM'lere daha fazla yaslandığı ve istemedikleri işleri yaparken zamanın her zaman çok daha yavaş geçtiğini hissettikleri yönünde

  • “Yeni araçlar, yeni oldukları için daha hızlı hissettirir ve bu his genelde birkaç hafta içinde kaybolur” sözü bana ters geliyor
    Yeni araçlar bana her zaman yavaşlatıcı gelir, çünkü onlara alışık değilim. Elbette daha hızlı olma potansiyelini görürüm, ama henüz onları etkili kullanamıyorumdur

    • Bununla ilişkili bir başka etki daha var. Özellikle yeni araçları gönüllü olarak deneyen insanlar hevesli oldukları için, eksiklerini telafi etmek adına mesai dışında da daha fazla çalışıyor
      Bir süre etkileyici görünüyor, ama sonunda normal çalışma düzenine dönülünce doğal olarak ortadan kalkıyor

  • Ölçmek zordur. Bir bakıma, AI destekli kodlamayı ölçmeye çalışmak başlı başına bir hata olabilir
    Bazı işleri daha hızlı yaptığı açık ve onları hızlandıracak şekilde kullanmanın yolları da neredeyse kesinlikle vardır
    Daha önemli soru, bu yolların neler olduğu ve bu süreçte neyin kaybedildiğidir

    • Üretkenlik ile iş yapma hızındaki artış aynı şey değildir. Bir iş daha hızlı yapılabiliyor olsa bile, o iş darboğaz değilse ya da hız artışının bir maliyeti varsa üretkenlik üzerinde olumlu bir etkisi olmayabilir
      Orijinal yazı da bunu “kolay olan yarıyı ölçmek” olarak ele alıyor

  • “Gelecek hafta bir yönetici, şirketin abone olduğu AI kodlama aracının ücretine değdiğini göstermeni isterse, üretilen kod satırı sayısını mı ölçersin, kapanan ticket sayısını mı?” sorusuna gelince, Claude zaten faturalama kayıtlarında kod satırı sayısını, kabul oranını ve token kullanımını ölçüyor
    Kapanan ticket sayısı takımın hızıyla ilgili olurdu; AI çıktısı bunun yalnızca bir unsuru ve sprint hızını zaten Jira ölçüyor
    Her hâlükârda bu soru, yöneticinin hangi çıktıyı görmek istediğini düşündüğüne bağlı olarak kolayca manipüle edilebilir ve büyük ihtimalle bu zaten oluyordur

  • Bana kalırsa yazar çok önemli bir soruyu atlamış: “AI kullanımı ne tür zararlar doğuruyor?”
    Bence bu soru diğerlerinden daha temel, çünkü zararı ölçmek çok daha kolay. Bir Git forge kurup crawler'ların kan kokusu almış köpekbalıkları gibi üşüşmesini izlemek yeterli
    Scraper'ların bütün interneti DDoS etmesi ölçülebilir bir sorun ve kendi sistemini barındıran herkes için doğrudan hissedilen bir gerçek
    Doğru düzgün ölçmekte bile zorlandığımız, AI'ın sözde faydaları, crawler'ların yol açtığı bu çok gerçek zararı göze almaya değiyor mu?
    Crawler çalıştırmanın ve bu istekleri işlemenin enerji maliyetini, eğitim maliyetini, çıkarım maliyetini ve giderek büyüyen veri merkezlerine olan ihtiyacı da eklersek ne olacak?
    Bence çok daha önemli soru, AI'ın bu sözde faydalarının tüm bunları feda etmeye değip değmediğidir

    • Bu tür “X hakkında konuşmalıyız” tartışmalarında beni hep zorlayan şey, ekolojik zararı ele alan yazılarda bunun tam tersinin savunulduğunu görmüş olmam
      “Bunlar enerji harcamıyor olsaydı bile yine de kötü kod üretiyor olurdu, o yüzden asıl bundan bahsetmek daha önemli” ya da “neden kodlamadan bahsediyoruz, asıl zarar gözetim için kullanılması” gibi argümanlarla konu sürekli başka yere kayıyor