Yüksek Becerili İşlerde Gen AI’ın Etkisi: Yazılım Geliştiricilerle Yapılan Bir Deney

Özet

• Araştırmaya genel bakış
  • Bu çalışma, Microsoft, Accenture ve adı açıklanmayan bir Fortune 100 elektronik üretim şirketinde yürütülen üç rastgele kontrollü deney aracılığıyla üretken yapay zekanın yazılım geliştiricilerin üretkenliği üzerindeki etkisini değerlendirmektedir.
  • Deneyler, her şirketin günlük iş akışının bir parçası olarak yürütüldü ve rastgele seçilen geliştiricilere GitHub Copilot adlı yapay zeka destekli bir kodlama yardımcısı sağlandı.
  • Toplam 4.867 yazılım geliştiricisini kapsayan bu çalışma, yapay zeka araçlarını kullanan geliştiricilerin tamamladığı görev sayısının %26,08 arttığını ortaya koydu (standart hata: %10,3).
  • Özellikle daha az deneyimli geliştiriciler daha yüksek benimseme oranı ve üretkenlik artışı gösterdi.

GN⁺ özeti

• Bu çalışma, üretken yapay zekanın yazılım geliştiricilerin üretkenliğini önemli ölçüde artırabileceğini gösteriyor.
• Özellikle daha az deneyimli geliştiriciler için faydalı olması, yapay zeka araçlarının öğrenme eğrisini yumuşatmaya yardımcı olabileceğine işaret ediyor.
• GitHub Copilot gibi yapay zeka araçları, yazılım geliştirme verimliliğini artırmada önemli bir rol oynayabilir.
• Benzer işlevlere sahip diğer projeler arasında TabNine ve Kite yer alıyor.

[GN⁺]

Hacker News yorumları

• Bazen IT personelinin kalitesinin düşmesinin, şirketlerin personel azaltmak için tek bir kişiye giderek daha fazla rol yüklemesinden kaynaklanıp kaynaklanmadığını merak ediyorum.
  Eskiden geliştirme, operasyon ve güvenlik ayrı ayrı sorumluluklardı; DevOps ortaya çıkınca bazı şirketler bunu ekipleri birleştirmek değil, personelin 2/3’üyle idare edebilmek anlamına geldi diye yorumladı. DevSecOps çıkınca da asıl rollerin yalnızca 1/3’ünün yeterli olduğunu, geliştiricinin operasyonu ve uygulama güvenliğini de üstlenmesi gerektiğini düşündüler.
  shift-left’i ya da birleşik operasyon modelinin kendisini eleştirmiyorum; yöneticiler personeli azaltıp maliyeti düşürürlerse daha fazla bonus alabileceklerini düşündüğünde bu modellerin doğurduğu mantıksal sonuçtan bahsediyorum.
  Şimdi yeni mezun bir geliştirici, akıl almaz derecede karmaşık n adet mikroservis ortamına girip mevcut kod tabanını, 5 parçalı CI/CD pipeline’ını, DBA rolünü de öğrenirken düzenli yayın döngüsünü de tutturmak zorunda kalıyor.
  Yetişebilmek için ChatGPT kullanmaları gerçekten şaşırtıcı mı bilmiyorum; IT şirketleri iyi iş stratejileri yerine “çizgiyi yukarı taşımak” için personel kısmayı bırakmadıkça bu sürecek.

  • Startup’larda bir kişi üç kişinin işini yapabilir ve pratikte de bunu sık sık yapar.
    MBA’lilerin gözden kaçırdığı şeyin aşırı kısıtlama olgusu olduğunu düşünüyorum. “Geliştirici” gibi genel bir rolü “geliştirme, operasyon, güvenlik” diye böldüğünüzde, her rolün nasıl yapılacağına dair bir yığın ayrıntı ortaya çıkar. Sonra bunları tekrar DevSecOps olarak birleştirseniz bile o ayrıntılar yerinde kalır; böylece bir kişi 3 kat verimli çalışmak yerine 3 kat işi üstlenmiş olur.
    Bunu gerçekten geri çevirmek için kısıtları gevşetmek ve o tek kişinin işi nasıl yapacağına kendisinin karar vermesine izin vermek gerekir.
    Buradan çıkan sonuç, organizasyonların küçülemeyeceği, yalnızca büyüyebileceğidir. Çalışan sayısı arttıkça görevler daha uzmanlaşır; o kişileri ortadan kaldırdığınızda o işlevler basitçe yapılmaz hale gelir. Çünkü bu uzmanlaşma düzeyinde kalan çalışanların görev tanımlarını biraz değiştirip yeni sorumlulukları üstlenmesi zordur.
    Sonuçta eski organizasyonu bırakıp yeni ve küçük bir organizasyonla baştan başlamak gerekir; özel sermaye/girişim sermayesi/startup ekosisteminin var olma nedeni de budur. Gall yasası da aynı bağlamdadır: https://en.wikipedia.org/wiki/John_Gall_(author)#Gall's_law
  • IT personelinin kalitesindeki düşüşün, çok para kazanılabildiği için yazılım sektörüne giren kuşakla doğrudan ilgili olduğunu düşünüyorum. Anlaşılır bir şey ama çoğu zaman motivasyon yazılıma duyulan tutkudan çok ödül oluyor; genelde teknik olarak sıradan insanlar oluyorlar ve yine başka sıradan teknik kişileri işe alma eğilimindeler.
    Buna karşılık bugünlerde ortaya çıkan yeni startup’lara baktığımda gerçekten yetenekli insanların giderek arttığını görüyorum. Finansmanın daha sıkı olduğu bir ortamda şirket kurmak için gerçekten çok yetkin insanlara ihtiyaç var; bu insanlar da yine çok iyi kişileri işe alıyor.
    Bugünkü teknoloji sektörü bana, startup’lara ilgi duyan neredeyse herkesin teknik problemleri hacklemeyi sevdiği için bu işe atıldığı 2004-2008 dönemine çok daha fazla benziyor.
    Cursor’ı kullanma deneyimime göre, ortalama bir mühendisin yapabileceği işlerde harika; ama daha ileri düzey işler için berbat ve başkalarının kodunu çok hızlı anlama becerisi de gerekiyor.
    Muhtemelen frontend ya da web uygulama geliştirmeye odaklanmayan ileri düzey teknik mühendislerin, junior web geliştiricileri eskisi kadar çok işe almamasını sağlayacak. Web sayfaları için temel HTML/CSS’i hızla üreten framework ve araçlar ortaya çıkınca webmaster’ların ortadan kaybolmasına benziyor.
  • Bu olgu yalnızca IT çalışanlarının başına gelmiyor, genel olarak yaşanıyor; teknolojinin vaat ettiği üretkenlik artışının gerçekleşmemesinin başlıca nedenlerinden biri olduğunu düşünüyorum.
    Diyelim ki “DevSecOps” çalışanları yapmaları gereken işin 3 katını yapıyor; onların başka neler yaptığına da bakmak gerekir. Seyahat rezervasyonu, masraf beyanı ve raporlama, çalışma saatlerini iş sınıflarına göre bölüp bildirme, izin yönetimi, toplantı yönetimi, kendi hazırladıkları grafiklerle sunum hazırlama, dış tedarikçilerden satın alma hazırlığının %80’i gibi işleri de yapıyor olabilirler.
    Bunlar görev tanımında yoktur, asıl işi engeller ve kişinin temel işini yapma kapasitesini orantısız biçimde aşındırır. Eskiden bu işlerin her biri için, çok daha ucuza ve 10 kat verimle yapabilen uzmanlar vardı.
    Sekreterler, şirket içi grafik departmanı, finans personeli gibi uzmanlar finansal tablolarda görünürdü. Bu rolleri kaldırmak işin ortadan kalktığı anlamına gelmez; yalnızca self servis ofis yazılımlarının “üretkenliği” artırdığı iddiasıyla iş herkese parça parça dağıtılır.
    Sonuçta herkes orantısız biçimde yavaşlar; ama yalnızca sayılara bakanlar, kaldırılan rollerin maaşlarından tasarruf edilen parayı görür. Yavaşlama ise bulanık ve genel bir üretkenlik düşüşü hissi, herkesin yaşadığı gizemli bir maliyet hastalığı gibi ortaya çıkar.
    Bence gizemli bir şey yok: üretkenlik artışı yok, aksine kayıp var. Sadece net ve görünür maliyetleri dağınık ve hesaplanması zor maliyetlere dönüştürdüğü için para tasarrufu yapıldığına inanmak kolaylaşıyor.
  • Şirketler 10x geliştiricilerin var olduğunu fark ediyor, ama onları 1x geliştirici maaşıyla çalıştırabileceklerini sanıyor.
    Atlanan temel yetkinlik, şirketin içinde bulunduğu işi anlama becerisi. Orta karar bir geliştirme becerisi bile iş hedeflerine dair iyi bir anlayışla birleştiğinde, saf geliştiricilerin bir kısmı yapay zeka tarafından ikame edilirken bile geçerliliğini koruyabilir.
  • Bu durmayacak. Gerçek güce sahip tipik üst düzey yöneticiler IT karmaşıklığı hakkında hiçbir şey bilmiyor ve bizi pahalı temizlikçiler gibi görüyor. Bu onların hatası, ama bu hatanın tamamen ortaya çıktığı zamana gelindiğinde çoğu muhtemelen çoktan gitmiş olacak.
    Bankacılık sektöründeki bir şirkette 13 yıl boyunca karmaşıklığın çok arttığını ve saçma bürokrasinin de onunla birlikte büyüdüğünü gördüm. Hâlâ gerekli işi yapabiliyorum ama erişim yetkim yok. Olması da mümkün değil.
    Basit bir iş artık kim olduğu belirsiz Pune ekibiyle 10 aşamalı pazarlık yapmayı gerektiriyor; gerçekten yapmaları gereken bir iş olduğunu kabul edene kadar 10 kez peşlerinden koşup konuyu eskale etmek gerekiyor.
    Süreçler öyle saçma hale geldi ki bir şeye başladığınızda 2 gün mü sürecek, 3 ay mı sürecek bilmiyorsunuz. Her uygulama, yeni bir ağ işi, doğrulanmamış bir Unix güncellemesi ya da kaçınılmaz olarak ortaya çıkacak sayısız şeyden biri yüzünden sürekli bakım yapılmazsa oldukça hızlı bozuluyor.
    Sonunda evrak işleriyle uğraşanlar ve asıl işinde de ortalama düzeyde olan insanlar sürecin içine derinlemesine yerleşip kazandı; iş birimleri düşük kaliteli IT hizmeti alıyor, projeler gecikiyor ve bütçeyi aşıyor. Bu da IT’nin “berbat ama katlanılması gereken bir kötülük” olduğu imajını daha da pekiştiriyor.
    Artık umursamayı bıraktım; işin yaşam için bir araç olması yeterli. Odağım ve başarı duygum o “yaşam” tarafında.

• Neyin ölçüldüğü önemli. Bu çalışma yalnızca Copilot kullanımına bakmış
  Deneyimli bir mühendisim; Copilot benim için yararsız olmakla kalmıyor, engel de oluyor. Zamanımın çoğunu problem alanını anlamaya, bulunduğum ortamın kısıtlarını ve olanaklarını kavramaya ve yazacağım kodu düşünmeye harcıyorum
  Gerçekten kod yazmaya başladığımda ne yazacağımı zaten biliyorum; bu yüzden “yardımcı” Copilot otomatik tamamlaması sadece dikkatimi dağıtıyor. İş akışımı çok daha kötü hale getiriyor
  Buna karşılık, gerçek kodlama öncesi aşamalarda yapay zeka inanılmaz derecede faydalı. Bazen önceden yaptığım düşünme sürecine dayanarak iyi hazırlanmış tek bir prompt ile taslak alabiliyorum; sonrasında da ortaya çıkan küçük beklenmedik sorunlara hızlı yanıtlar almak için bir LLM ile eşleşmek çok yardımcı oluyor
  Bu yüzden, bu raporun aksine, deneyimli bir geliştirici yapay zekayı iyi kullanırsa deneyimsiz bir geliştiriciden daha büyük kazanç elde edebilir diye düşünüyorum

  • Copilot özellikle faydalı değil. En iyi ihtimalle doğru da yanlış da olabilecek küçük kod parçaları üretiyor; daha büyük kod bloklarının en baştan çalıştığı nadir
    Ama Claude Sonnet 3.5’i Cursor veya Continue.dev ile birlikte kullanınca durum dramatik biçimde iyileşiyor. Bağlamı açıkça kontrol edebiliyorsunuz; örneğin 6-7 dosya seçip içeri alabiliyorsunuz ve buna Claude’un üstün yetenekleri de eklenince oyun tamamen değişiyor
    İşe bağlı olarak kolayca 2-5 kat hızlanıyorsunuz. Normalde yarım gün sürebilecek bir işi, testleriyle birlikte üretime hazır 100 satırlık koda bir saat içinde dönüştürebiliyorsunuz
    Bunu 26 yıllık deneyime sahip, 2012’den beri principal/staff/lead rollerinde bulunmuş biri olarak söylüyorum. Ancak senior altı deneyim seviyelerinde aynı iyileşmeyi beklemem. Çünkü aslında ne istediğinizi epey ayrıntılı anlatmanız ve genellikle çalışan ilk çözümü alıp yaklaşık altı kez rafine ederek ideal, iyi ayrıştırılmış bir hale getirmeniz gerekiyor
  • Benim için yapay zeka, dokümantasyon ve arama becerilerini hızlandıran bir araç gibi. Ne yapmak istediğimi tam olarak biliyorum ama sözdizimini veya kullanım şeklini hatırlamadığım çok sayıda küçük iş oluyor
    Örneğin AWS için IaC yazarken bakılması gereken çok şey var. Yapay zekaya sorunca yanıtı ve örnekleri çok hızlı alıyorum. Yeni bir servisin IaC’sini öğreniyorsam AWS dokümantasyonuna bakarım; ama yalnızca hızlı bir yanıt ya da tazeleme gerekiyorsa yapay zeka çok daha hızlı
  • Karşıt bir bakış açısı olarak, Copilot’un ileride yalnızca method signature’a bakarak fonksiyonun tamamını yazabilmesini sağlayan pattern yazımını ödüllendirdiğini hissediyorum
    Fonksiyonel kalıplara ne kadar çok yaslanırsanız, monad’ları tasarlayıp giriş/çıkışı yalnızca sınırlarda yapar ve fluent programming kullanırsanız etkisi çok büyük oluyor
    Not olarak, bu Java’daki deneyimim. Java’yı 3,5 yıldır kullanıyorum ve Java 8+ özelliklerine büyük ölçüde dayanıyorum. Kütüphane kodunda generics’i yoğun kullanırsanız LLM’in tutarlı biçimde doğru seçim yapma alanı artıyor
    Daha hızlı ve kabaca yapılmış tasarımlarda bu kazanımı aynı ölçüde göremiyorsunuz. Haskell, OCaml, F#, Scala gibi gerçek fonksiyonel programlama kullanıcılarının deneyimlerini daha fazla duymak isterim
  • Copilot deneme sürümünü kullandım; ne sonuç vereceğini bekleyip analiz ettikten sonra çoğunu atıp kendi implementasyonumla yeniden yapmaya başladım. Kısa sürede bunun zaman kaybı olduğunu fark ettim
    Birim testlerde, özellikle table-driven test boilerplate’i yazarken işe yarıyordu, ama ücretli aboneliği sürdürmeye değecek kadar değil
  • Benim deneyimim de benzer. İş yerinde erişimim var ama odaklanmak için fazla gürültülü hale geldiğinden son zamanlarda kapattım
    Aşina olmadığım bir dille çalışırken ya da üretilen kodun iyi olup olmadığını kolayca değerlendirebildiğim tekrarlı işlerde çok değerliydi
    Buna karşılık, yapmak istediğim şey çok net olduğunda ve standart implementasyona benzese de biraz daha yeni bir iş olduğunda zayıflıyor. “reduce” veya daha belirsiz prosedürlerde bu sık oluyor
    Platform mühendisiyim; Bash, Python, tarayıcı, saf JS, TS, Node, GitHub Actions, Jenkins Java iş akışları, Docker gibi birçok alan arasında gidip geliyorum. Alan değiştirirken beynimi dinlendirmeye ve ısınmaya yardımcı oluyor

• Araştırmada, az deneyimli geliştiricilerin yapay zekayla katkı yaptıktan sonra daha deneyimli geliştiricilerin uğraşmak zorunda kaldığı teknik borcun dahil edilip edilmediğini merak ediyorum. Çünkü araştırmadaki şirketlerden birinde şahsen buna çok kez maruz kaldım.
  Ayrıca teknolojinin kendisine pek ilgi duymayan ama teslimata çok önem veren geliştiricilerin yapay zekaya daha fazla ilgi gösterdiğini bizzat gördüm. PM’ler böyle insanları sever ama

  • Ben de merak ediyorum. Artık birçok PR’da, bir metodun hiçbir iyi gerekçe olmadan bariz biçimde yapay zeka tarafından tamamen değiştirildiğini incelemek zorunda kaldım. Neden değiştirdiklerini sorduğumda kelimenin tam anlamıyla sessiz kalıyorlar ve soruyu görmezden gelip sadece başta istediğimiz işi açıklamaya çalışıyorlar. PR’ın içinde gerçekte ne olduğunu bilmedikleri açık.
    Bizim istediğimiz yaklaşık 5 satırlık küçük bir değişiklik ve testti. Ama şimdi yalnızca yeni borç değil, neden tamamen değiştirildiğini kimsenin açıklayamadığı kodu, bunun bir kısmı sırf değiştirmek için yapılmış değişikliklerden ibaret olan kodu ve bu kodu yöneten insanların gözünde tamamen yabancı duran kodu da sırtlanıyoruz.
    Bu araçları kullanan ama kıdemli mühendis olmayan kişilerde bunu sürekli görüyorum. Sonunda böyle PR’ları reddedip baştan yapmalarını söylemek zorunda kalıyoruz; başta elde edildiği sanılan zaman kazancı da ortadan kalkıyor.
    Bu, bu araçların işe yaramaz olduğu anlamına gelmiyor; ama insanlar çıktının ne olduğunu anlamadan kullanıyor ve kod tabanı üzerindeki uzun vadeli etkisini de anlamıyor.
  • “Teknolojiyle pek ilgilenmeyen ama teslimatla çok ilgilenen geliştiriciler yapay zekaya daha fazla ilgi gösteriyor” ifadesi, açıklamaya çalıştığım şeyi tam olarak anlatıyor.
    Ruhumun bir parçasını kaybettiğim gün, bir geliştiriciye DB şemasıyla ilgili geri bildirim verebilir miyim diye sorduğum, o da olur dedikten birkaç dakika sonra “Evet, ben X ile pek ilgilenmiyorum” diyerek sözümü kestiği gündü.
    İlgilenmiyor musun? Alan uzmanı olarak neyin nasıl ve neden iyileştirilebileceğini söylüyorum, ama ilgilenmiyor musun?
    Bulut bir hataydı. İnsanlara, istendiği zaman scale up/out yapılabildiği için verimlilik ve optimizasyon peşinde koşmaya gerek olmadığı fikrini aşıladı. Mikro benchmark’lardan bahsetmiyorum; “bu veri yapısı yerine şu veri yapısını kullanmak daha iyi olmaz mı” gibi son derece basit şeylerden söz ediyorum.
  • Kodlama yapay zekası satan bir şirkette çalıştığımı baştan belirteyim.
    Biz de içeride kullanıyoruz ve teknik borcun yeterince ölçülmeyen devasa bir tehdit olduğunu düşünüyorum.
    Aşina olmadığınız API’leri ve kalıpları koda halı bombardımanı gibi uygulamak için çok yararlı; ama dikkatli olmazsanız muazzam kod tekrarına ve baş edilmesi zor boilerplate’e yol açıyor.
    Bunun nedeni iki büyük önyargı. Birincisi, modelin eğitim verisi StackOverflow tarzı örnek verilerden oluşuyor; bağlamı ve kısıtları dikkate almıyor. İkincisi, mevcut kod tabanına bakıp refactoring önermek yerine kopyalama ve tekrarlama eğiliminde.
    İlki, eninde sonunda kendi işinizi yapıp LLM’in ürettiğini inceleyip düzenlerseniz hafifliyor.
    İkincisi ise ancak diff’ler ve commit geçmişi eğitim verisine girerse hafifleyebilir; fakat bu veri kümesini işlemek ve etiketlemek çok daha zor. Bazı değişiklikler refactoring gibi iyi olabilir, bazıları ise sonraki commit’lerde düzeltilen bir bug olabilir; commit mesajları da fiilen yalan olduğundan net bir ayrım yok. Kimse “bug ekleme” diye yazmıyor.
    Üstelik merge, rebase ve squash, geçmişin anlamını değiştiriyor, siliyor ya da gürültü ekliyor; böylece her şeyi daha da muğlaklaştırıyor.
  • Yapay zekayı seven geliştiriciler arasında tanıdıklarımın neredeyse tamamı, yapay zekadan önce de teknik olarak pek saygı duymadığım geliştiricilerdi. İşi bir şekilde bitiriyorlardı ama zanaatkârlık ya da kalite yoktu.
  • Ben de öyle hissettim ama tersini de gördüm. Burada HN’de bile teknolojiye ilgi duyan insanların yapay zeka kullanımına neredeyse tepki gösterdiği durumlar var.
    Ben teknolojiyi seviyorum ve eğlence için de yazılım yazıyorum; ama yapay zekayla birlikte çalışmak nesnel olarak daha eğlenceli. Üretkenliğim çok daha fazla artıyor ve en önemlisi erteleme ortadan kalkıyor.
    Takıldığımda ya da işe başlamak istemediğimde Aider ile konuşmaya başlıyorum; bir bakmışım o gün yapay zeka olmadan yapmayacağım bir işi bitirmişim.
    Bu sayede eskiden aylar ile yıllar süren açık/özel projeleri artık iki haftada bir çıkarıyorum. Hızlı ve deneyimli bir geliştirici ekibinin yanınızda oturmasının maliyeti günde en fazla birkaç dolar.

• Bir sonuca varmadan önce makaleye biraz daha derin bakmak gerekiyor. Araştırmanın kendisi de sonuçları daha iyi özetleyebilirdi gibi görünüyor
  Özet ve sonuç bölümü, sonuç olarak üretkenlikte %26,08 artış diye tek bir oran veriyor; ondalık basamaklar biraz fazla gibi. Biraz daha içine girince junior’lar için %27~39, senior’lar için %8~13 gibi sayılar çıkıyor
  Daha derine bakınca, sadece deneyime göre değil şirketlere göre de sapmanın büyük olduğu görülüyor. Microsoft’ta pull request’ler dışında commit, build, build başarı oranı gibi diğer sonuç metrikleri istatistiksel olarak anlamlı görünmüyor. PR artışı Microsoft’ta anlamlı gibi görünse de Accenture’da öyle değil gibi; üstelik bu bile yalnızca junior’lar için geçerli olabilir
  Özet ve sonuç bölümü elbette özetlemek zorunda, ama değişkenlere göre sonuçlar o kadar farklı ki tek bir genel sayıyı özet olarak vermenin mantıklı olup olmadığını bilmiyorum. Özellikle de istatistiksel anlamlılık çok tutarsız göründüğü için

  • Bu sonucun nasıl çıktığını daha iyi görmek için şöyle bakmak gerekiyor. Microsoft, kendi iç ürün kullanımına dair bir araştırma yaptı ve etkinliği göstermek istiyordu. Sonuçlar beklendiği kadar geniş kapsamlı başarılı olmadı
    Accenture, Microsoft gibi büyük kuruluşlarla iş birliği yapan ve ortak pazarlama yürüten bir şirket. Yaklaşık 300 geliştiricilik havuz, toplam örneklemi neredeyse hiç hareket ettiremiyor; ayrıca yapay zeka iş akışları etrafında pazarlama/danışmanlık birimleri kurduğu için objektif olduğunu varsaymak da zor
    Üçüncü anonim şirket ise aslında rastgele kontrollü bir deney değildi; bu yüzden onun sonuçlarını RCT’lerle nasıl birleştirmek gerektiğini söylemek zor. Ayrıca benzer deneyler yapıp etkinliği öğrenmek isteyen başka büyük teknoloji şirketleri de olmuş olmalı; dolayısıyla sonuçlara dahil edilenlerin dışında başka veriler olduğunu varsayabiliriz
    Daha büyük bir örnek kümesinin içinden neden bu şirketleri seçtiler? Muhtemelen Microsoft ve Accenture’ın benimsemeye yönelik teşviki olduğu, üçüncü şirketin de p-hacking ile seçildiği için
    Özellikle özetteki “her bir deney ayrı ayrı gürültülü olsa da, üç deneyi birleştirince” ifadesi çok kötü bir işaret. Bu, tek tek şirketlere bakıldığında istatistiksel olarak anlamlı bir sonuç olmadığı, ama bu üç grubu birleştirince anlamlı hale geldiğinin fiilen kabulü. Bu bilim değil
  • %26,08 sayısı konusunda, fizik gibi alanlar dışındaki bir araştırmada virgülden sonra ikinci basamağa kadar değer verilince hemen şüpheleniyorum
  • Kişisel olarak farkın bir kısmının, senior geliştiricilerin üretilen koda kod inceleme ve test deneyimlerini uygulamasından kaynaklandığını hissediyorum. Bu yüzden değişiklik istiyor, kötü üretimleri reddediyor, yeni kodun ya da refactoring’in beklendiği gibi çalıştığını test etmek için daha fazla zaman harcıyorlar
    Junior geliştiriciler ise LLM’in doğru yapmasının kolay olduğu işleri yapıyor olabilir ya da ilk taslak LGTM gibi göründüğü için kabul etme hatasına düşüp throughput’u daha yüksek görünebilir
    Üretilmiş kod modellerini kullanmak da beceri gerektiriyor ve bu beceri, işi başkalarına devrederken ve birden fazla yazarın çözümlerini tek, tutarlı bir sisteme entegre ederken gereken beceriyle aynı

• Bu sadece benim sezgim, ama LLM destekli kodlamanın geliştirici olarak büyümeye zararlı olduğunu düşünüyorum. Üretkenliği ancak belli bir seviyeye kadar artırabilir gibi geliyor; bu seviye senior’lar için sıkıcı tekrar olabilir, ama junior’lar için biçimlendirici süreçtir
  Benim deneyimime göre LLM yalnızca basit boilerplate kod için kullanılmıyor; junior geliştiricinin henüz yeterince anlamadığı, oldukça yaygın bir işle karşılaşınca çağrılıyor. Deneme, öğrenme ve anlama sürecinin büyük kısmı LLM ile yer değiştiriyor; gerçek beceri de çalışıyor gibi görünene kadar prompt’u ayarlamak oluyor

  • Bana göre inanılmaz derecede iyi bir öğrenme aracı. Sohbet araçlarını kullanınca daha geniş ve derin öğreniyorum. Bir konuyu keşfetmek ve ek kaynaklar bulmak için harika bir muhatap oluyor
    Dün gece ilk kez Linux RAID kurdum. Çok zor bir iş değil, ama mount, umount, fstab, blkid, mdadm, fdisk, lsblk, mkfs gibi birçok araç gerekiyor ve süreç içinde rehberdeki tam adımlardan farklı ilerleyebiliyor; bu yüzden yalnızca tutorial ya da dokümantasyon bakmak özellikle yardımcı olmuyor
    Her araç ve adım hakkında onlarca soru sordum; eskiden olsa sadece kopyalayıp yapıştırır ve dua ederdim
    İki gün önce de bozuk bir SSD’den tüm verileri kurtarmayı ChatGPT üzerinden öğrenerek başardım. %20 yanlış yapabilecek olsa bile, açık internet ortalamasından çok daha iyi bir “rehber” eşliğinde tamamen yeni bir beceriyle uğraşmak gerçekten güzeldi
    Öğrenmeyi seven biri için, internetteki çöplüğü sonsuza kadar eşelemekle kıyaslandığında yedi fersah çizmesi gibi hissettiriyor. Elbette internetteki diğer her şey gibi yapay zekanın söylediklerinden de şüphe etmek gerekir, ama zahmeti muazzam ölçüde azaltıyor
  • Bu araştırmanın tam da bu kısmı ele almasını gerçekten isterdim. Gerçekte ise yalnızca kısa vadeli üretkenlik artışına bakıyor, uzun vadeli teknik borcu yok sayıyor ve yazılım geliştirici gelişimi üzerindeki etkiyi tamamen görmezden geliyor
    Ben de aynı sezgiye sahibim; hatta buna dayanaklı, güçlü bir görüş demek isterim. Birkaç yıl sonra sektörün bunun bedelini ödeyeceğini düşünüyorum
    “Sezgisi olan junior yazılım geliştirici” arz hattı ciddi biçimde kuruyacak ve yerini “yapay zekaya bağımlı junior yazılım geliştirici” seli alacak. Bu iki kategori arasında derin bir uçurum var
    Doğal olarak bu, sezgisi olan mid-level geliştirici ve sezgisi olan senior geliştirici sayısı üzerinde de zincirleme etki yaratacak
  • Kullanıcıya göre gerçekten çok değiştiğini düşünüyorum. Eskiden StackOverflow kodunu çalışıyor gibi görünene kadar yapıştırıp işi bitirenler, LLM’i de kötüye kullanacak
    Buna karşılık yazdığı kodun tamamını anlamak isteyen biri, LLM’in çıkardığı şeylerde bilmediği kısımları araştırma eğiliminde olacaktır
    En azından ben böyle kullanıyorum. Hipoteze karşı örnek olarak da, LLM bazen bilmediğim fonksiyonları ya da kütüphane bileşenlerini kullandığı için yeni bir dil veya toolkit öğrenirken bana çok zaman kazandırıyor. Benim için öğrenmeyi yavaşlatmaktan çok hızlandırıyor
  • Diğer her şey gibi bu da kötüye kullanılabilir. StackOverflow’dan kopyala-yapıştır yapıp çalışınca işi bitirmek gibi
    Ama zaten başarılı olacak insanlar için, StackOverflow’a soru sorup anında ve azarlanmadan cevap almak gibi; gerçekten büyük bir nimet
    Her zaman doğru olmayacak, ama StackOverflow da öyleydi. Sonuçta her zamanki gibi kişiye bağlı
  • LLM’lerin son 2 yılda gösterdiği ilerlemeye bakınca, gerçekten derine inmek istememeyi seçmek kötü bir bahis mi diye düşünüyorum
    50 yıl önce bir şey yapmak için fiilen zorunlu olan makine dilini bugün geliştiricilerin kaçı kullanabiliyor?
    LLM, bir başka soyutlama koltuk değneği olmaktan çıkıp sağlam bir soyutlama sütununa dönüşüyor olabilir

• Bu araştırmada en ilginç nokta, kariyer seviyesine göre ayırınca, şirketteki çalışma süresi medyanın üzerinde olan geliştiricilerde “üretkenlik” gibi pek de iyi olmayan bir vekil göstergede istatistiksel olarak anlamlı bir artış olmaması. %95 güven aralığı tüm metriklerde negatif tarafa epey derin inebiliyor; sadece biraz pozitif tarafa eğiliyor
  Benim deneyimimle de örtüşüyor. Copilot, bazı sıkıcı işleri azaltıp beyni daha derin sorulara ayırmayı sağlaması açısından iyi; ama junior geliştiricilerin anlattığı gibi dünyayı değiştiren bir şey değil
  Ayrıca sık sık ince biçimde hatalı oluyor; deneyimsiz bir geliştiricinin kaçırabileceği türden. Ürettiği şeylerin çoğunda durup ayar yapmam gerekiyor ve daha az deneyimli bir geliştiricinin bu ayarı nasıl yapacağını bilmemesi çok olası
  Birkaç yıl kullandıktan sonra Copilot’ı ne zaman kullanıp ne zaman kullanmamak gerektiğine dair artık epey iyi bir sezgim oluştu; bu yüzden net etkisinin pozitif olduğunu düşünüyorum, ama bu her zaman böyle değildi
  Ayrıca senior geliştiricilerin “üretkenliğinin” azalmış gibi görünmesinin bir nedeni de şirketteki junior’ların üretkenlik artışı olabilir mi diye merak ediyorum. Junior’lar daha fazla PR açar ve bunlarda daha fazla hata olursa inceleme süresi artar; senior’ın üretkenlik kazanımı da orantılı olarak azalabilir

• %26 üretkenlik artışı benim deneyimimle de genel olarak örtüşüyor. Daha yakından bakılması gereken boyutun, yeni bir teknolojiyle mi yoksa zaten aşina olunan bir teknolojiyle mi çalışıldığı olduğunu düşünüyorum. Yapay zeka, öğrenmeye çalıştığım dil veya framework’lerde çok daha fazla yardımcı oluyor

  • Bunu “doğru düzgün öğrenmeye niyetim olmayan dil/framework’lere” kadar genişletmek isterim
    Bash’te koşul yazmak için tam olarak hangi tırnak büyüsünün gerektiği gibi yardımcı dillerin tuhaflıklarını ve tuzaklarını pek iyi hatırlamıyorum. Bu yüzden geçmişte otomasyon için Bash script’lerini neredeyse hiç kullanmazdım; ancak yeterince sık yaptığım bir iş olduğunda uğraşırdım. jq ile JSON işlemek ya da AWK ile parse etmek de aynıydı
    Artık LLM’ler sayesinde çok daha fazla Bash script’i yazıyorum; o kadar kolaylaştı ki süreç dokümantasyonu için de daha sık kullanıyorum. Eskiden statik, adım adım bir README olan şey artık kullanıcı girdisi alan etkileşimli bir Bash script’iyle birlikte geliyor
  • Copilot sıkıcılığı azaltmada oldukça fena değil. Örneğin docstring’leri genelde iyi yazıyor. Ama yazılım mühendisliğinin gerçek zihinsel emeğini azaltmıyor
  • Öyle de olabilir. Kariyer aşamasına göre insanların ne kadar esnek olduğunun sonucu da olabilir
    Genel olarak senior programcıların yapay zeka araçlarının neden çalışmadığını tartıştığını çok görüyorum. Junior’lar ise önyargısız şekilde kullanıyor
  • Ana ürün geliştirmede pek faydalı olmadı. Python tabanlı olsa da kendi framework’ümüzü kullandığımız için CoPilot’ın başvurabileceği çok az kod var; var olmayan metotlar ve argümanlar önererek işi artırıyor
    Faydalı olduğu dört yer vardı. Birincisi, Qt veya CSS gibi sık kullanmadığım ama bol örnek içeriği olan framework/diller hakkında sorular
    İkincisi, normalde Google Search ya da StackOverflow’da arayacağım çok spesifik sorular. Örneğin “Windows’un CPU ve RAM kullanımını Python ile en verimli şekilde alma yöntemi” gibi bir soruda, doğrudan kopyala-yapıştır kod üretmekten çok kütüphane veya örneklere yönlendiriyor
    Üçüncüsü, zaten nasıl yazılacağını bildiğim ama biraz zaman kazandıran ve yazım hatalarını azaltan boilerplate kod. PyCharm için CoPilot eklentisini kullanırken dosyaya niyetimi yorum olarak yazınca sonraki birkaç satırı tamamlıyor. Yine sonuçlar çok kısa ve spesifik olduğunda en iyi oluyor. Uzadığında CoPilot ile çok fazla yineleme yapmak gerekiyor ve artık değerini yitiriyor
    Dördüncüsü, dokümantasyonda hızlı arama yapmanın bir yolu
    Birim testi yazmakta iyi olduğunu söyleyenler de var ama bende öyle olmadı. En azından benim istediğim türde birim testleri için değildi
    Sayıya dökersem üretkenliği %5–10 artırdığını düşünüyorum. Notepad yerine PyCharm gibi tam teşekküllü bir IDE kullanmaktan ya da CLI’da git komutlarını elle yazmak yerine iyi bir git istemcisi kullanmaktan çok daha küçük bir etki. Yani birçok üretkenlik aracından biri sadece; “devrimsel” demezdim
  • Bende de benzer bir izlenim var
    Devasa bir Ruby on Rails projesinde yaklaşık 10 gün Cursor kullandım; bu stack’i 13 yıldan uzun süredir kullanıyorum
    GitHub Copilot’ın zaten sağladığı üretkenlik artışının ötesine geçemedim. Copilot’ın artışını kabaca %25 civarında tahmin ediyorum
    Ama boş bir klasörde Node.js gibi yeni bir projeye sıfırdan başlarken garip derecede güçlü. Sadece prompt ile, OpenAPI şemasından istekleri işleyen ve OpenAPI şemasını swagger ile sunan bir API’yi yaklaşık 5 dakikada oluşturabiliyor
    Yine de yeni bir projeye sıfırdan başlamak benim için nadir olduğundan, muhtemelen Copilot ve standart VSCode’a geri döneceğim

• İnsanların daha fazla PR açabilmesini sağlıyor. Vay, ne harika. Kimin umurunda
  QA’dan geçen öğe sayısı artıyor mu? Yapay zeka desteğiyle yapılanlarda QA sonrasında bulunan bug sayısı daha mı az? Sonradan genişletmesi veya düzeltmesi kolay mı, yoksa katı ve esnek olmayan bir tasarım mı?
  Geliştiricileri kalitesi bilinmeyen kod maymunlarına dönüştüren bir araç aramıyorum. Geliştiricinin yaptığı işteki bug’ları veya tasarım kusurlarını bulmasına yardımcı olan ya da iyi tasarlanmış testler yazmasını sağlayan araç istiyorum
  Sadece PR saymak hiçbir işe yarar şey söylemez. Aksine, birim zamanda daha fazla kod olunca ortalama kalitenin düştüğüne dair içgüdümü tetikliyor

  • Geliştirici: “Copilot, bu commit’i 5 commit’e böl”
    Copilot: “Tabii, hallediyorum! İşte yeni commit’ler!”
    Senior geliştirici: “Neden? Değişiklik atomik. Yönetim aylık değişiklik sayısı gibi aptal metrikleri tekrar gündeme getirirse, kibarca defolup gitmelerini söylerim”

• Bu muhtemelen GPT-3.5 tabanlı Copilot idi
  Microsoft: Eylül 2022–3 Mayıs 2023
  Accenture: Temmuz 2023–Aralık 2023
  Anonim şirket: Ekim 2023–?
  Copilot Chat’in GPT-4 güncellemesi 30 Kasım 2023’teydi: https://github.blog/changelog/label/copilot/

  • İyi nokta. Cursor gibi şeyler ya da doğrudan Claude kullanılsaydı sonuçların nasıl olacağını çok merak ediyorum. Artık Claude ile basit küçük script’lere başlamanın gerçekten çok kolay olmasına şaşırıyorum

• AI benim için dokümantasyonu yeniden canlandırdı. Yeni framework’lerde dokümantasyon çok yetersiz. Benim için son iyi dokümantasyon DOS kitaplarıydı. Günümüz geliştiricilerinin iyi dokümantasyonun nasıl bir şey olduğuna dair sezgisi bile olmayabilir
  Yine de AI her seferinde farklı öneriler sunabildiği için değerlendirmeyi hâlâ deneyimli bir geliştiricinin yapması gerekiyor. Sonuçta AI, dokümantasyonun ve yazı yazmanın yerini alıyor

  • Bence AI dokümantasyonun değerini daha da artırdı
    Açık bir projeyse dokümantasyon LLM’in eğitim verilerinin bir parçası hâline geldiği için dokümantasyonun kapsamlı ve doğru olması çok daha önemli oldu. Çünkü birçok geliştirici o sistemden yanıt alacak
    Kapalı bir projeyse aynı etkiyi elde etmek için dokümantasyonu fine-tuning veri kümesine veya RAG sistemine koyabilirsiniz
  • Bazen HN’de “iç dokümantasyonu nasıl yönetiyorsunuz” gibi tartışmalar açılıyor; çoğu kişi “dokümantasyon hemen eskir, bu yüzden yazmanın anlamı yok” minvalinde yazıyor. Son birkaç gün içinde bile böyle iki thread vardı
    Bu, neden hiçbir şeyin dokümante edilmediğini açıklayabilir
  • Doğru. AI dokümantasyon yazmaya da yardımcı olabilir ve dokümantasyondan başlarsanız daha da iyi olur. Örneğin önce bir fonksiyonun ne yaptığını açıklayan yorumu yazarsanız, AI fonksiyonu yazmanıza katbekat daha iyi yardımcı olur
    Bu yüzden geliştiricileri kodu daha iyi dokümante etmeye zorlayan bir etkisi de var aslında
  • İyi dokümantasyon yazmayı gerçekten seviyorum. Elbette her zaman buna fırsat olmuyor ama harika olduğunu düşündüğünüz bir dokümantasyon örneği paylaşabilir misiniz?
    Mutlaka modern, canlı bir dokümantasyon olması gerekmez; herhangi bir şey olur. Geçmişte neyin bu kadar harika olup da bizim kaybettiğimizi görmek ve bazı kısımlarını kendi dokümantasyonuma yansıtmak istiyorum