- 2025'in başındaki AI araçlarının açık kaynak geliştiricilerinin gerçek üretkenliği üzerindeki etkisine dair rastgele kontrollü bir deney yürütüldü
- Araştırma sonucunda, AI araçları kullanıldığında görev tamamlama süresinin ortalama %19 daha uzun sürdüğü görüldü
- Geliştiriciler AI'ın kendilerini %24 daha hızlı yapmasını bekliyordu, ancak gerçek algının aksine yavaşlama ortaya çıktı
- Benchmark'larda ve günlük deneyimde görülen AI yetenekleri ile gerçek etki arasındaki fark oldukça belirgin
- Çalışma, AI'ın üretkenlik etkisini doğru anlamanın ve çeşitli değerlendirme yöntemlerinin önemini vurguluyor
Genel Bakış
- Bu çalışma, 2025'in başındaki (Early-2025) AI araçlarının deneyimli açık kaynak geliştiricilerinin üretkenliği üzerindeki etkisini doğrulamak için rastgele kontrollü deney (RCT) yürüttü
- Beklentilerin aksine, AI araçları kullanıldığında geliştiricilerin işleri tamamlamasının %19 daha uzun sürdüğü doğrulandı
- Bu sonuç, AI araştırma otomasyonunun yazılım geliştirme üzerindeki gerçek etkisini ölçmeye yönelik bir örnek olarak yorumlanıyor
- Bu metodolojiye dayanarak, AI Ar-Ge hızlanmasının gerçek etkisini sürekli tahmin etmeyi planladıklarını belirtiyorlar
Araştırmanın motivasyonu
- Mevcut kodlama/ajan benchmark'ları, gerçek iş koşullarını yeterince yansıtamama sınırlamasına sahip
- Kendi kendine testler, bağlamdan yoksun tek seferlik görevler ve otomatik puanlama yapısı nedeniyle AI yeteneğini abartabilir
- Tersine, insanın uyarlanabilir müdahalesi olmadığında gerçek AI model performansının olduğundan düşük değerlendirilmesi de mümkün
- Bu sınırlamaları tamamlamak için, gerçek açık kaynak geliştirici üretkenliği üzerindeki etki deneysel olarak ölçülerek AI'ın gerçek dünyadaki etkisi değerlendirildi
Deney yöntemi
- 16 deneyimli açık kaynak geliştiricisi işe alındı ve her biri, yıllardır katkı verdiği büyük depolardaki (ortalama 22 bin+ yıldız, 1 milyon+ satır kod) gerçek 246 issue'yu seçti
- Her issue için, AI kullanımına izin verilen veya yasaklanan gruplara rastgele atama yapıldı
- AI'a izin verildiğinde geliştiriciler Cursor Pro ve Claude 3.5/3.7 Sonnet gibi güncel modelleri serbestçe kullandı; yasaklandığında ise üretken AI yardımı olmadan çalıştı
- Katılımcılar her issue'nun çözüm sürecini (ortalama 2 saat) kaydetti ve harcadıkları süreyi kendileri raporladı
- Deneye katılanlara saat başına 150 dolar ödeme yapıldı
Temel bulgular
- AI araçları kullanıldığında, issue çözüm süresi ortalama %19 uzadı
- Geliştiriciler AI'ın üretkenliği gerçekte %24 artırmasını bekliyordu ve deneyden sonra da hâlâ %20'lik bir hız artışı hissettiklerini söyledi
- Böylece algı ile gerçek performans arasında büyük bir fark ortaya çıktı
- Bazı yanlış anlamaları önlemek için çalışma, aşağıdakiler hakkında kanıt sunmuyor:
- AI'ın tüm geliştiricileri veya yazılım geliştirmenin tamamını yavaşlattığı yönünde bir genelleme
- AI'ın diğer alanlar ya da kurulumlardaki etkisini tanımlama
- Aynı sonucun yakın gelecekte de süreceğini kesin olarak söyleme
- Mevcut LLM ve prompt tekniklerinin optimize edilemeyeceğini iddia etme
Etki faktörlerinin analizi
- Gecikmeyi açıklayabilecek 20 faktör analiz edildi ve bunların 5'inin gerçekten etkili olduğu değerlendirildi
- Deney koşulları, model, issue zorluğu, PR kalitesi gibi başlıca değişkenlerin sonuç üzerinde anlamlı etkisi olmadığı doğrulandı
- Yavaşlama olgusu, farklı veri alt kümeleri ve tahmin yöntemlerinde de tutarlı biçimde gözlendi
- Ayrıntılı analizler makalenin tam metninde görülebilir
Sonuçların yorumu ve tartışma
Kanıtlar arasındaki çatışma ve nedenleri
- AI benchmark skorları / vaka raporları / gerçek deneyler arasındaki sonuç farkı belirgin
- Benchmark'lar, AI yeteneğini otomatik puanlanabilen dar problemler üzerinden ölçüyor
- SWE-Bench: test tabanlı açık kaynak PR'ları, RE-Bench: algoritmik olarak değerlendirilebilen problemler
- Gerçek RCT'de ise 20 dakika ile 4 saat süren karmaşık ve gerçekçi görevlerde insanlar aksine daha yavaş kaldı
- Buna karşılık, sektörde veya toplulukta AI'ın uzun süreli işlerde oldukça faydalı olduğuna dair nitel raporlar da çok sayıda bulunuyor
Yorum çerçevesi
- Her yaklaşımın “gerçek yeteneği” farklı biçimde ölçme özelliği var
- Vaka bazlı yaklaşım:
- RCT'nin düşük değerlendirme sorunu: yalnızca bizim deney düzenimize özgü bir özellik olabilir
- Benchmark/vaka tarafında aşırı değerlendirme ihtimali: gerçek çözüm süreciyle uyumsuzluk, öz bildirim temellerinin zayıf güvenilirliği
- Üç yaklaşımın da gerçek dünyanın yalnızca bazı alt problemlerine iyi uyuyor olması mümkün
- Farklı kaynaklar ile gerçek yetenek düzeyi arasındaki uçurum, ölçüm hatası/yanlılık (kırmızı) ve ölçüm kapsamı farkı (mavi) olarak yorumlanabilir
Deneyin ek çıkarımları
- RCT sonuçları, AI çıktısının yüzlerce veya binlerce kez örneklendiği ortamlar için geçerli olmayabilir
- Cursor gibi AI araçlarının onlarca ila yüzlerce saat kullanımdan sonra verim artışı sağlaması mümkün olabilir
- Yüksek kaliteli kodun ve örtük gereksinimlerin (dokümantasyon, test, biçimlendirme vb.) fazla olduğu ortamlarda AI yeteneği sınırlı kalabilir
- Benchmark'lar problem kapsamı bakımından dar olduğu için gerçek iş zorluğunu uygun şekilde yansıtamayabilir
- Nitel hislere dayalı raporlar, aşırı değerlendirme ve öz yanılsama etkisi nedeniyle güvenilirliğini yitirebilir
- Hiçbir tekil değerlendirme yöntemi kusursuz olmadığından, bunların birbirini tamamlayacak şekilde kullanılması gerektiği vurgulanıyor
Gelecek görünümü
- Bu metodoloji sürekli geliştirilerek AI araçlarının geliştirici üretkenliğini gerçekte ne kadar değiştirdiği nicel olarak izlenecek
- Eğer AI araçları sahadaki geliştiricilerin verimini ciddi ölçüde artırırsa, AI Ar-Ge genelinde ani hızlanma / gözetim başarısızlığı / güç yoğunlaşması riskleri de birlikte ortaya çıkabilir
- Gerçek ortamlara uygun değerlendirme çerçevelerinin geliştirilmesi, gelecekte AI ilerlemesi ve sektör geneli açısından çok önemli
2 yorum
Saatte 150 dolar mı? Değişken kontrolünden itibaren olay kopuyor zaten hahahaha
Hacker News görüşleri
Simon Willison'ın yorumu:
Tam makalede, özette yer almayan pek çok ayrıntı var makale bağlantısı
Bana göre, LLM tabanlı yapay zeka araçlarından gerçek bir verimlilik artışı elde etmek için insanların düşündüğünden çok daha dik bir öğrenme eğrisi var
Bu çalışmaya, çeşitli yapay zeka araçlarını kullanma deneyimi olan 16 kişi katıldı; bunların %56'sı Cursor'ı ilk kez kullanıyordu ve çalışma ağırlıklı olarak Cursor üzerineydi
Her katılımcı toplamda yaklaşık 15 issue üzerinde çalıştı ve her issue için yapay zeka kullanımına izin verilip verilmeyeceği rastgele belirlendi
Yani bir geliştirici, yapay zekanın serbest olduğu görevlerle yasak olduğu görevleri karışık şekilde yaptı
Katılımcıların yalnızca dörtte birinde performans artışı görülürken, dörtte üçünde performans düştü
Yapay zekayı en yoğun kullananlar, Cursor'ı 50 saatten fazla kullanmış kişilerdi
Araştırmacılar da Cursor deneyimi yeterli olan geliştiricilerde performans artışı olduğunu kabul ediyor
Sezgim şu yönde: Bu makale, yapay zekayla birlikte geliştirmede öğrenme eğrisinin yüksek olması nedeniyle, mevcut iş akışına doğrudan karıştırıldığında pratikte performansı düşürdüğünü gösteriyor
LLM'ler hakkında verilen yaygın tepki “sen doğru kullanamadığın için böyle” oluyor ama bu bana fazla kullanıcıyı suçlayan bir bahane gibi geliyor
Çoğu teknoloji ürününde, kullanıcı değer görmüyorsa bunun ürün tasarımındaki bir sorun olduğunu düşünürüm; neden aynı mantık yapay zeka için geçerli olmasın diye merak ediyorum
Simon'a teşekkürler; makaleyi dikkatle okumuş olman da harika - OSS projelerinin bir hayranı olarak birkaç önemli noktayı vurgulamak istiyorum
1) Önceki araştırmaların bazılarında araç deneyimi az olsa bile performans artışı görülüyordu; yani bu sonucun tamamı yalnızca “dik öğrenme eğrisi” teorisiyle açıklanamaz
2) Çalışma öncesinde katılımcıların %90'ından fazlasının LLM prompt yazma deneyimi vardı ve asıl temel becerinin bu olduğu düşünülüyordu. VSCode kullanmaya alışkınsan Cursor'ı da rahat kullanırsın görüşü yaygındı
3) Herkes yapay zekaya alışkınsa, yapay zeka olmadan daha kötü performans göstermeleri de mümkündür (en azından ben buna katılıyorum); böyle olursa yapay zeka sanki daha iyiymiş gibi görünen bir yanılsama tersine baskılanmış olur
4) Deneyim bilgileri önceden tahmin uzmanlarıyla paylaşıldı; buna rağmen tahminciler verimlilik artışı beklentisini fazla yüksek tuttu
5) Yüzlerce saatlik kullanımla oluşan bir long-tail beceri gerçekten var olabilir; bu çalışma bunun hakkında net bir şey söyleyemiyor
Makale şaşırtıcı bir sonuç verdiği için okuyanların tek bir etken seçip “sebep bu!” demesi kolay oluyor
Oysa gerçekte nedenler birleşik olabilir (en az 5, en fazla 9 etken dışlanamıyor; bkz. sayfa 11, tablo)
Gerçekten önemli bir çıkarım da şu: Geliştiricilerin öznel memnuniyet beyanları ile gerçek sonuçlar arasında büyük bir boşluk vardı ve bu, kullanılan araç türünden bağımsızdı
Verimlilik ölçümünde sahadaki gerçek verilere mutlaka ihtiyaç var (özellikle makaledeki C.2.7, “ortalamanın altında AI araç kullanımı” bölümüne bakın)
Bunu, katılımcıların %75'inin LLM deneyimi olmasına rağmen yapay zeka kullanınca işlerinin daha da yavaşladığı şeklinde yorumlayabiliriz; bir yorum LLM öğrenme eğrisinin çok dik olduğu, diğeri ise mevcut LLM'lerin gerçek programlama yardımı verimliliğinin abartıldığı yönünde. İnsanlar performans tahmininde tutarlı biçimde yanılıyor
LLM'leri iyi kullanmayı öğrenseniz bile, kendi yazdığınız koda dair kavrayışınız azalabilir
Geliştirici zamanla koda daha hâkim olurken, LLM giderek daha kötü hale gelebilir
LLM ile hızlıca kod üretilebilir ama yeterince dikkat edilmezse kodla ilgili ustalık birikmez
Başta geliştirme akıcı ve hızlı görünür ama arka planda anlayış eksik kalır; LLM de ilk başta işe yarar görünse de giderek iyileşmez ve bir noktada hem LLM'nin hem de kullanıcının baş edemeyeceği bir kod karmaşası oluşur
Ayartıya kapılmadan, LLM'nin daha temiz kod üretmesini ısrarla yönetmek ve kişinin kendi kodunu mutlaka çalışması gerektiğini düşünüyorum; bizzat anlamaya çalışma çabası şart
AI araçlarıyla verimliliği artanlar da var artmayanlar da
Benim tahminim, uzun metinleri ya da kodu hızlı okuyabilenlerin ciddi avantaj elde ettiği yönünde
İşe yaramayan önerileri hızla ayıklamak ve iyi cevabı bulana kadar yinelemek çok önemli
Hızlı tarama becerisi kıdemle ilişkili ama şaşırtıcı biçimde bazı yeni başlayanlarda da çok güçlü olabiliyor
Arama becerisi yüksek olanlar LLM kullanımında da avantajlı olabilir; biraz iyi Google araması yapabilmeye benziyor
80/20 kuralını yeniden hatırlatıyor - işin %80'ini sürenin %20'sinde çözüyor, kalan %20 içinse zamanın %80'i harcanıyor
Sürekli “neredeyse bitti” hissi verdiği için batık maliyet yanılgısına düşmek kolay oluyor
Son dönemde denediğim yöntem, AI'ı “çözücü” değil “sürtünmeyi azaltıcı” olarak kullanmak oldu
Programlamayı kendim yapıp sadece ufak tefek unuttuğum sözdizimi gibi şeyleri AI'a sorarak hız kazanıyorum
Doğrudan tüm kodu öneren çıktılara neredeyse hiç bakmıyorum; her zaman kodu kendim düşünerek yazıyorum, böylece anlayış ve beceri kaybını önlüyorum
Eskiden bu, işin %80'i için %80 emek, kalan %20 için de yine %80 emek gerektiren ters-Pareto gibiydi
AI'ı sadece “küçük engelleri” kaldırmak için kullanma fikrine katılıyorum
Dün de Java stream API ile List işlerken ConcurrentOperationsException yüzünden uğraştım
Metodu kendim yazarken çözemedim; AI'a “thread-safe liste dönüştürme metodu” verince, ilgili API'de bunun için zaten yerleşik bir yöntem olduğunu söyledi
Böyle ufak tefek sorunlarda AI harika - karmaşık ama sınırları net olduğunda
Özellikle Stack Overflow'u daha güçlü kullanmak gibi durumlarda faydalı; ne yapmak istediğimi kabaca biliyorum ama bunu mevcut ortamıma uygun şekilde tam nasıl yapacağımı bilmiyorsam, ayrıca debugging ve rubber ducking için de yardımcı oluyor
“Son %20 için zamanın %80'ini harcamak” AI öncesinde de benim deneyimimdi; yalnızca başlangıç süresini kısaltması bile değerli. Konuya hâkim birinden duyduğum en iyi AI değerlendirmesi şuydu: “Becerilerimin %90'ı değersizleşti, kalan %10 ise bin kat daha önemli hale geldi.” Abartılı ama özü hoşuma gidiyor
“Sürekli neredeyse bitti” yanılsaması yüzünden aslında zaman kaybı doğuyor. AI, bir şeyi faydalıymış gibi göstermekte çok iyi; bunun gerçekten verimlilik artışı olup olmadığını anlamak için güçlü eleştirel düşünme gerekiyor
Özellikle mevcut bir kod tabanına özellik eklerken çok yararlı; örneğin “mevcut arama parametrelerine ek olarak foo da eklensin” ya da “x ile ilgili kod kaldırılacak” gibi işlerde iyi çalışıyor
HN kullanıcılarına, makalenin yazarlarından biriyim - uzun yıllardır HN kullanıcısıyım ve bugün yorumlardaki soru/geri bildirimlere elimden geldiğince yanıt veriyorum. Zamanınız yoksa makalenin tamamı yerine tanıtım blog yazısını ya da x.com'daki duyuru zincirini öneririm
Makalenin metodolojisi ve yazarın iletişim biçimi çok profesyonel ve etkileyici; gerçekten iyi bir çalışma
Bu çalışmanın, clickbait'e kaçmadan sonuçları dürüstçe sunması ve aynı zamanda okunaklı biçimde düzenlenmiş olması onu gördüğüm en iyi araştırmalardan biri yapıyor
AI ile çözülen ticket'ların gerçekten AI'a uygun türden işler olup olmadığını düşündünüz mü? “Bu ticket'ı AI ile çöz” yaklaşımı gerçekçi olsa da verimsiz olabilir. AI uygun kullanıldığında gerçekten çok katkı sağlayabiliyor ama bazen ters de tepebiliyor. Katılımcılar yeterince AI deneyimine sahipse bu ayrımı yapmış olabilirlerdi ama makaleyi okurken bunun ne kadar net olduğu belli gelmedi
Mümkünse anonimleştirilmiş ham veri setini yayımlamayı ya da en azından geliştirici bazında işlerin mutlak sürelerini makaleye eklemeyi düşünür müsünüz? Cursor deneyimi yüksek katılımcıların gerçekten diğerlerinden hızlı olup olmadığını, yoksa aslında yavaş kişiler olup AI ile daha büyük sıçrama mı yaptıklarını merak ediyorum. Hawthorne effect'i de dikkate alan böylesine iyi bir deneysel değerlendirme görmek sevindirici
(Makaleyi okumadım, sadece gönderiyi gördüm) Öznel yorgunluğun, AI'ın daha hızlı olduğu yönündeki yanlış algıyı açıklayan bir değişken olarak ölçülüp ölçülmediğini merak ediyorum. Geliştiricilikten yöneticiliğe geçtikten sonra beynim yorgunken AI bana daha rahat geliyor
Bu çalışmanın sonucu, özellikle de “geliştiriciler AI'ın hızlarını %24 artırmasını bekliyordu ama aslında yavaşladıkları halde deneyimden sonra bile %20 hızlandıklarına inandılar” kısmı çok ilginç. Gerçek ile algı arasındaki bu kadar dramatik farkın nedeni ne olabilir? Acaba beyin ‘zihinsel çabayı’ zaman deneyimiyle karıştırıyor olabilir mi diye düşünüyorum
Bunun için elimde kanıt yok ama ürkütücü bir düşünce var: Kod yazarken AI ile etkileşim kurmak, sosyal medyadaki dopamin döngüsüne benzer bir şekilde beyni uyarıyor olabilir mi (elbette aynı ölçüde olmasa da)? AI tekrar tekrar cevap sunarken beyin olumlu geri bildirim alıyormuş gibi hissediyor olabilir; bu da geliştiricilerin AI'ı gerçekte olduğundan daha olumlu değerlendirmesine yol açıyor olabilir. Eğer bu bir tür bağımlılık etkisi yaratıyorsa, insanlar verimlilik etkisini sistematik biçimde abartıyor olabilir mi?
Bu olgu, piyasadaki pek çok kişinin AI araçlarının gerçekte olduğundan daha güçlü olduğuna inanmasını sağlayan devasa bir kampanyanın sonucu da olabilir. Ekonomi uzmanları ve ML uzmanları grubunun kendisi AI şirketlerinin çıkar çevreleriyle örtüşüyor; yöneticiler de bunu doğrudan kabul edip büyük kazanımlar vaat ediyor. Bu da genel beklenti tabanını yukarı taşıyor ve deneyimli geliştiricileri bile etkiliyor olabilir. Bunu ampirik olarak kanıtlamak zor ama AI verimliliğine dair kolektif yanılgının neden bu kadar yaygınlaştığını açıklayabilir
HN yorumlarındaki birçok AI meraklısının da bu etki altında olup olmadığını merak ediyorum. Kişi kendi performansını gerçekten ölçmedikçe, AI'ın üretkenliğini gerçekten artırıp artırmadığından emin olmak zor
Bazen tam tersini de yaşıyorum. Bugün Claude code ile örnek bir demo uygulama üretmeyi denedim; izlerken havalı ve bilim kurgu gibi hissettirdi, eğlenceliydi ama 15 dakika sonra zihnim uyuştu ve sıkılmaya başladım
“Geliştiriciler AI'ın %24 daha hızlı olmasını bekledi, gerçekte yavaşladıkları halde %20 daha hızlı olduklarına inandılar” ifadesine bakınca burada iki sorun görüyorum
Birincisi, aynı kişinin aynı bağlamda AI ile ve AI olmadan ne kadar sürdüğünü düzgün şekilde karşılaştırmak çok zor
İkincisi, PR açılma/merge edilme süresi gibi yüzeysel göstergelerle AI verimliliğini ölçmek kolay; ama gerçekte AI kullanıldığında refactoring, test, issue çözümü gibi sonradan yapılan işlere daha fazla zaman ayrılabiliyor
Sadece “PR daha hızlı açıldı” diye AI'ın hızlı olduğu sanılabiliyor, fakat sonradan ortaya çıkan ek işler gözden kaçabiliyor
Belirli bir teknoloji ya da pratiğin üretkenlik üzerindeki etkisini ölçmek gerçekten çok zor. Sadece öznel anlatılara dayanıp sonuç çıkarmak bence tehlikeli; çünkü herkes kolayca kendi kendini kandırabilir. Araştırma da zaten kendi sınırlamalarını kabul ediyor, bu yüzden üretkenlik tartışmalarında geniş bir hata payını akılda tutmak gerek. AI, hayatımda gördüğüm en tuhaf teknolojilerden biri; parçalı örneklerden ya da şüpheli benchmark'lardan nedensellik çıkarmaya çalışmak neredeyse fal bakmak gibi
Makalede, AI'a izin verilen ve verilmeyen durumlar arasında PR kalitesinde bir düşüş gözlemlenmedi. Katılımcıların çoğu depo standartlarına alışkındı ve “öylesine gönderip PR açayım” tarzında çalışan insanlar değildi. Çalışmadaki PR'lerin ara inceleme süresi medyan olarak yaklaşık 1 dakikaydı. Dediğiniz gibi zaman kullanım biçimi tamamen değişiyor. Makalenin 10. sayfasında AI kullanılan ve kullanılmayan durumlarda zaman dağılımı yer alıyor; AI ile kod yazma süresi azalırken AI ile etkileşim süresi artıyor
“Aynı kişinin aynı bağlamda AI ile ve AI olmadan çalıştığında süre farkını tam olarak bilemeyiz” eleştirisine karşılık, deney tasarımı bunu random assignment ile çözüyor; AI grubu ile AI olmayan grubun etkileri ayrıştırılıyor. Kişi, durum, ortam gibi farklar rastgele atama ile dengeleniyor. Örneklem ve etki büyüklüğü yeterliyse istatistiksel olarak anlamlı farklar çıkarılabilir
Figure 21'e bakınca, ilk uygulamanın kendisi de (PR'a kadar geçen süre) artmış; PR incelemesinden sonraki ek süre daha da artsa da toplam etki çok büyük görünmüyor. Figure 18'de görüldüğü gibi gerçek kodlama süresi azalmış ama prompt yazma, çıktı bekleme ve sonuçları gözden geçirme gibi işler bu kazancı sıfırlamış. 5 dakikanın altındaki basit işlerde LLM kullanmamak daha iyi bile olabilir
Her iş akışında PR içeriğinin nasıl değiştiğini karşılaştırmak isterdim. Copilot, benim elle yazacağımdan daha fazla kod öneriyor ve çoğu zaman gereksiz kontroller, tekrarlar ya da anlamsız soyutlamalar nedeniyle kod miktarı şişiyor. Benim kişisel hipotezim şu: LLM'nin çok fazla kod üretmesini görünce, insanların bir problemi çözmenin ne kadar süreceğine dair sezgisi bozuluyor olabilir
LLM'leri büyük bir kod tabanında kullanırken asıl zor olan şey, yapılması gereken işi doğru tarif etmek. Kod içindeki sayısız etkileşim nedeniyle sorunu anlatmak bazen elle çözmekten daha uzun sürebiliyor; buna karşılık yeni projelerde boilerplate kod üretirken LLM'lerle çok daha iyi anlaşılıyor
Katılımcı geliştiricileri toplamak için 300 x 246 = yaklaşık 73K harcanmış ama makale ne bir dergide yayımlanmış ne de hakem değerlendirmesinden geçmiş. Dışarıdan düzenli ve AI üretimi gibi görünmese de, bu kadar finansmanın nasıl sağlandığını merak ediyorum
En büyük mali destek The Audacious Project'ten geldi; bu resmî duyuruda görülebilir. Ayrıca web sitesindeki dipnotta, 2025 Nisan'ına kadar AI şirketlerinden değerlendirme karşılığı ödeme alınmadığı belirtiliyor
Şirketler bu tür ‘whitepaper’ları sık sık yayımlıyor. Teknik rapor, politika önerisi ve tanıtım materyalinin birleşimi gibi oluyorlar
Bence sadece dergi yayını ya da hakem incelemesine bakmak çok anlamlı değil. Bilimde önemli olan kimin yayımladığı değil, yeniden üretilebilirlik ve tekrar eden sonuçlardır. Psikolojideki yeniden üretim krizi örneğinde olduğu gibi, bir dergide yayımlanmış olmak tek başına güvenilirlik garantisi değildir
Çoğu ülkede araştırmalar için kamu destekleri vardır; ABD eskiden daha fazla destek veriyordu ama son dönemde ciddi biçimde kesildi
Vakfın tanıtım sayfasına bakılırsa AI şirketleri ve devlet dahil olmak üzere çeşitli yerlerden fon alıyor gibi görünüyor
Hobi amaçlı OSS projelerinde AI daha çok engel oluyor. Kod üretimi/scaffolding asıl kaygı değil; kod inceleme ve topluluk yönetimi daha önemli. AI araçlarının yapabilecekleri oldukça sınırlı. Buna rağmen birisi açık PR'ıma AI kod inceleme aracı bağlamış ve 30 satırlık bir PR için emojili, düzenli madde işaretli iki sayfalık özetler üretmiş. Bu gereksiz gürültü yaratıyor; şimdi de o yorumları silmek ya da gizlemek için gerçekten daha fazla bakım zamanı harcıyorum
Öğrenme eğrisini aştıktan sonra hızlanıyor olabilirsiniz (ya da birinin dediği gibi “artık AI olmadan çalışmayı unutana kadar”), ama gerçekten ölçülmesi gereken şey şu... gece 3'te PagerDuty alarmı çaldığında o kodu debug etmek ne kadar sürüyor? Bir de o kodun uzun vadeli kalitesi nasıl? Ben yıllardır business logic'i ortak klasörlere taşımak, çağrı zincirini yukarı çekip API'yi aşağıda sadeleştirmek, logic/API/display ayrımı, encapsulation ve dependency injection ile bağlılığı azaltmak gibi yapısal iyileştirmeler yapıyorum. AI ile yazılan kod uzun vadede gerçekten daha kaliteli, taşınabilir ve genişletilebilir mi? Yoksa düşük kaliteli kod giderek birikip birbirine dolanan bir çöplüğe mi dönüşecek ve sonunda zamanımızın yarısını bug düzeltmeye mi harcayacağız?