- GitHub ve Microsoft, GitHub Copilot Agent'ın herkese açık önizlemesini duyururken, .NET Runtime deposunda bu ajanının gerçekten otomatik PR oluşturduğu testler yapılıyor
- Ancak bu PR'ler zayıf ya da gereksiz değişiklikler içeriyor; bu da incelemecileri zor durumda bırakıyor ve Reddit kullanıcıları bunu acı tatlı bir manzara olarak görüyor
- Örnek PR'ler:
- PR #115762 –
string.Concat çağrısında Null kontrolü zaten yapılmış koda gereksiz yere bir kontrol daha ekliyor
- PR #115743 – hiçbir etkisi olmayan bir koşul ifadesi refaktörü öneriyor
- PR #115733, PR #115732 vb. de benzer bağlamda
- Yazar, "Sektörün geleceği buysa inmeye hazırım" diyerek yapay zeka benimsenmesine dair yorgunluk ve kuşkuculuğunu ortaya koyuyor
- Ama aynı zamanda "incelemeyi üstlenen çalışanlara karşı empati duyuyorum" diye vurgulayarak, bu durumun büyük olasılıkla yukarıdan gelen Copilot benimseme talimatının yarattığı yükten kaynaklandığını ekliyor
> Benim "schadenfreude" duygum, yapay zeka abartısını körükleyen Microsoft yöneticilerine yönelik. Lütfen geliştiricilere saygı gösterin.
> * schadenfreude, Almancadan gelen ve kelime anlamı olarak “zarardan doğan sevinç” demek. Yani, "başkasının talihsizliğinden gizlice hoşnut olma duygusu"
Öne çıkan yorumların özeti
1. Yapay zekanın yazdığı PR'ler hatalı ve bağlamı anlamadan sadece 'tahmin' üretiyor
- Gerçek PR kodunun ne yaptığını anlamadan değişiklik öneriyor
- Tekrarlanan hata düzeltmeleri → hâlâ yanlış kod → bir başka hata düzeltmesi… şeklinde bitmeyen bir döngü
- “Düzelttim” → “Hâlâ yanlış” → “Bu kez gerçekten düzelttim”… bu sürecin Junior Dev paterni gibi göründüğünü söyleyenler de var
2. Karmaşık problemleri çözmekte aksine daha fazla zaman harcatıyor
- Basit düzeltmelerde yardımcı olabiliyor ama gerçekten zaman kazanmak istenen karmaşık sorunlarda işe yaramıyor
- Problemi anla → Copilot'ın ne yaptığını anla → karşılaştır → doğrula → elle müdahale et
- Pratikte kendim çözmem daha hızlı
3. Şirket liderlerinin 'AI her şeyi çözer' yaklaşımı geliştiricileri dışlıyor
- "Copilot kullanırsan geri kalmazsın" mesajı sahadaki geliştiricilerin gerçekliğiyle kopuk
- PR inceleme süresi uzuyor, sorumluluk ise geliştiricilere yıkılıyor
- Copilot'ın ürettiği kodla eğitilen yapay zekanın yeniden kod kalitesini düşürdüğü bir 'AI'nin AI için eğitim döngüsü' endişesi var
4. Yapay zeka kendinden emin şekilde 'yanlış cevap' veriyor, ama 'bu doğru' diye emin olduğu bir muhakemesi yok
- Hatalı olduğu söylense bile “Düzelttim!” deyip daha da tuhaf değişiklikler öneriyor
- "Bu zaten iyi bir kod, düzeltmeye gerek yok" diye karar vermiyor
- Bunun, hukuki sorumluluktan kaçınmaya yönelik bir tasarım tercihi olabileceği de söyleniyor
5. Sürekli yapay zeka dayatması geliştirici deneyimini yıpratıyor
- Yönetici talimatları ya da performans değerlendirmeleri nedeniyle yapay zeka benimseme denemeleri sürüyor
- Geliştiriciler, kendilerini yapay zekanın bebek bakıcısı olmuş gibi hissettiren bir yorgunluktan söz ediyor
- Bu gidişat sürerse "geliştiriciler yapay zekadan bıkıp sektörü terk edecek" diyen karamsar görüşler de var
Öne çıkan cümleler
- “Yapay zeka, yanlış tahminleri tekrar edip dururken kendi söylediklerinden emin olan bir stajyer gibi”
- “Copilot'ın kod incelemesine zaman harcayacağıma, kodu baştan yazmam daha iyi”
- “Bu, geliştiricinin makineye yardım ettiği bir 'reverse centaurs' durumu”
- Cory Doctorow'un kullandığı bu ifade, "makineden yardım alan insanlar değil, makineye yardım etmeye zorlanan insanlar olduğumuz" anlamına geliyor
- “Copilot, geliştiricinin uyduruk yara bantları yapıştırmasına benziyor; sadece otomatik olduğu için bu, binlerce baş belası yara bandına dönüşüyor”
- “LLM'lerin varsayılanı sanki ‘yanlış olabilir ama belirsiz değil’ gibi”
12 yorum
Sorunları fırlatıp, cevap yanlışsa çöpe attığınız asenkron bir iş akışıyla verimlilik çok arttı; bu aslında statik araçlara benzemiyor mu? Onu oldukça gelişmiş bir statik analiz aracı gibi düşünürseniz iyi bir dost oluyor. Açıkçası analiz de hızlı ve junior bir mühendisten daha çok şey biliyor.
AI kullanıyorum ama o kadar aptal ki, yönünü düzeltemezsen doğru düzgün bir şey hayata geçiremiyor. Vibe coding yapanlara bakınca, hepsi hatalarla dolu kodlar...
LLM kullanırken her seferinde böyle bir deneyim yaşıyorum. Yapamadığı kısımları sonsuza kadar işaret etseniz de yine yapamıyor.
Sonunda yorulup kendim analiz edip düzeltmek zorunda kalıyorum. Bu tür deneyimler biriktikçe, LLM falan demeden hepsi düpedüz çöp gibi gelmeye başlıyor ve kullanmak istemiyorum.
Yapay zekanın insanlara kod yazdırmak için tersine prompt verdiği bir webtoon aklıma geldi.
https://comic.naver.com/bestChallenge/detail?titleId=818158&no=21
Sanırım yapay zeka, bir insan gibi aynı anda hem sorun çözmeyi hem de öğrenmeyi yapmadığı sürece bu sorunlar yaşanmaya devam edecek.
Son teslim tarihlerine ve gereksinimlere uyduğunuz sürece, kod yazarken yapay zeka mı kullandığınız, IDE bile kullanmayıp maço bir şekilde yalnızca Not Defteri mi kullandığınız çok da önemli olmamalı.
Bunu sadece yeni bir teknoloji olarak düşündüğümde ona yalnızca merakla bakıyordum,
ama artık işverenler bu tür teknolojileri gerekçe göstererek gerçekten işe alımları ve ücretleri kısarken, insanın keyfi pek yerinde olmuyor..
Sanırım hâlâ bir geçiş döneminde olduğumuz için çeşitli aksaklıklar yaşanıyor.
İleride daha iyiye gidebilir de, bu şekilde devam da edebilir; o yüzden nasıl değişeceğini izlemek de eğlenceli olacak haha
Github’a Gemini bağlayıp PR incelemesi alıyorum; tam da böyle olduğu zamanlar gerçekten ara sıra oluyor.
Mesela hemen üst satırda
nullkontrolü yapılmış olmasına rağmen,nullkontrolü olmadan kullanıyorsun deyip hemen üstteki satırın aynısını tekrar eklememi öneren bir inceleme bırakabiliyor.Bir kişinin iş yaparken doğal olarak edindiği arka plan bilgisi, iş kalıpları, beklenen sonuçlar ve bunların biçimi gibi şeylerin
tamamını prompt'a yazmak zaten mümkün değil; yazmak mümkün olsa bile,
LLM gibi karmaşık bir yapay zeka yerine, derin öğrenme öncesi geleneksel algoritmalarla otomatikleştirmenin daha gerçekçi olabileceğini de düşündürüyor.
Kullanınca vibe coding ve coding agent’ların kesinlikle kullanışlı olduğu yanlar var, ama gerçekten kullanışlı olmaları için istemleri aşırı titiz hazırlamak gerekiyor; zaten projenin yapısına göre hiç iyi çalışmayan birçok proje de var. MSA yapısındaki web sunucuları gibi işlevler sade ve küçük parçalara iyi ayrılmışsa iyi çalışıyorlar, ama büyük bir monolit içine bağlı çok sayıda modül ve karmaşık mantık varsa bunu yapay zekayla düzeltmeye çalışırken görev planını inanılmaz titiz kurmak ve istemleri çok iyi vermek gerekiyor.
Hacker News görüşü
Her yoruma "Help improve Copilot by leaving feedback using the or buttons" mesajının eklenmiş olmasına rağmen gerçekte buna iliştirilmiş herhangi bir geri bildirim görülmemiş olmasının ilginçliği paylaşılıyor; LLM kullanırken sistem prompt ayarı düzgün yapılmazsa bunun sık yaşandığına dair deneyim aktarılıyor; en komik PR örneği olarak test başarısızlığını düzeltme bahanesiyle test vakalarını tamamen silmesi, yorum satırına alması ya da assertion'ı doğrudan değiştirmesi veriliyor; Google ve Microsoft modellerinin OpenAI ve Anthropic'inkilere kıyasla bu tür durumları daha sık gösterdiği tahmin ediliyor ve şirket içi süreç farklarının sonuca yansıyor gibi göründüğü söyleniyor; gerçek bir PR'da insanın üç kez daha uyarıp sonra vazgeçtiği süreç anlatılıyor; bu tür PR'ları inceleyenlerin ne hissettiğini hayal etmenin bile zor olduğu, sanki söz dinlemeyen bir junior geliştiriciyle uğraşmak gibi ama bağlamı hiç anlamayan bir varlıkla karşı karşıya olunduğu belirtiliyor; belli bir PR'ın %90'ının "Check failure" ile dolu olması nedeniyle kodu/farkları incelemenin bile zorlaştığı bir örnek ve birim testte yalnızca "Test expressions mentioned in the issue" yazmasının yarattığı hüzün paylaşılıyor; eğer bu durum insanlar için bu kadar acı verici olmasaydı aslında gerçekten komik olacağına dair dürüst bir görüş dile getiriliyor
Junior geliştirici benzetmesinin fazla abartılı olduğu söyleniyor; kendisinin de junior geliştiricilerle çalıştığı ama onların LLM'ler gibi tuhaf hataları sık yapmadığı, fazla uğraştırmadığı ve hızlı öğrendiği belirtiliyor; LLM'lerin dikkatli kullanılınca fena olmayan yardımcı araçlar olduğu, hız artışına katkı sağladığı ve fikir üretimi için iyi bir beyin fırtınası partneri olabildiği, ancak stajyerin ya da gerçek bir geliştiricinin yerini alamayacağı düşünülüyor
Yazılım mühendisliğine 80'lerin sonlarında girildiğinde işte bir keyif olduğu, ama bugün mülakat süreçleri, küçük ve orta ölçekli şirketlerin big tech'i taklit etmesi ve şimdi de AI PR deneyleriyle ortamın zehirli hale geldiği söyleniyor; günümüzde profesyonel geliştirici olarak çalışmanın gerçekten hâlâ ne kadar sevinç barındırdığı sorgulanıyor
En azından junior geliştiriciye PR göndermeden önce testleri lokalde çalıştırmasını söyleyebileceğiniz, ama bir noktada insan geliştiricilerin pes edip "AI çöpü" PR'ları kapatacağı ve sadece düzgün çalışanları bırakıp geri kalan her şeyi atacağı yönünde kaygı dile getiriliyor; makinenin deneylerine sürekli katlanırken sonunda herkesin yorulup bırakacağı bir günün gelebileceği düşünülüyor
Böyle bir geri bildirim sistemine gerçekten ihtiyaç olup olmadığı sorgulanıyor; geliştirme açısından başarı, ilk denemede merge edilen PR, başarısızlık ise ajan tarafından istenen düzeltme sayısı kadar biriken kötüleşme olarak tanımlanabilir deniyor; manuel geri bildirim istemenin verimsiz olduğu, geliştiricilerde olduğu gibi cycle time, onay oranı, değişiklik başarısızlık oranı gibi metriklerle performans ölçmenin daha doğru olacağı savunuluyor
Microsoft destek ekibiyle iletişim kurarken duvarla konuşuyormuş hissi yaşandığına dair deneyim paylaşılıyor; birçok vaka açılmış olsa da tatmin edici bir çözüm hiç alınmadığı söyleniyor; Microsoft'un kendi teknolojisini kendisinin kullanmasını anlamakla birlikte bunu başkalarına dayatmaması isteniyor; destek vermeye hazır olmadığı ürünleri piyasaya sürmemesi gerektiği görüşü dile getiriliyor
Yakın zamanda Google'dan Eric'in AI hakkında konuştuğu bir videonun izlendiği anlatılıyor; kendisinin AI'nın şu anda olduğundan az değer gördüğünü savunduğu, roket şirketi satın alma nedenini ve Deep Research gibi uzman olmadığı alanlara AI ile girmesini anlatırken özellikle "uzman değilim" dediği aktarılıyor; yorum sahibi de AI'dan nefret etmediğini ama mevcut nesil, örüntü geri kurulumuna dayalı üretici yapay zekanın 'acemiyi etkileme' konusunda çok güçlü olduğunu söylüyor; ilgili alanda bilgi yoksa sonuçlar etkileyici görünüyor ama derinlemesine bilen biri için boşluklar hızla hayal kırıklığı yaratıyor; Microsoft gibi cephede çalışan insanların sorunun ne olduğunu açıkça gördüğü, ancak yöneticilerin, özellikle de Eric gibi kişilerin, AI gösterişli laflar ettiğinde buna kolayca kanabildiği söyleniyor; bir gün AI'nın gerçekten çalışan kodu doğrudan yazabileceği umuluyor ama bunun henüz uzak olduğu düşünülüyor
Kendisinin AI'yı dikkatli ve çok sınırlı biçimde kullandığı, buna karşılık "roket şirketi satın alan" milyarderlerin AI'ya hayran olup servetlerini daha da büyütecek yatırım kararlarında bile bunu kullandığı söyleniyor; büyük bir başarısızlık yaşansa bile onların kaybının yalnızca aksesuar düzeyinde kalacağı ve toplumsal sarsıntı yaşamayacakları, buna karşılık sahadaki IT işlerinin her iki senaryoda da kötü sonuçlara açık olduğu kaygısı ifade ediliyor
Uzman olmayan liderlerin AI karşısında kolayca hayran kalması üzerinden, Google'ın ABD ordusuyla işbirliği yapıp büyük ölçekli otonom dronelara Gemini yerleştirmesi halinde neler olabileceği hayal ediliyor
Microsoft çalışanlarının gerçek sorunları çözmek yerine saatlerce LLM'lerle atışmasını izlemenin, ürünlerini .NET üzerinde kurmuş şirketlere ne tür bir güven vereceği sorgulanıyor
Eskiden de LLM'ler devreye girmeden önce GitHub issue'larında kullanıcıların sorunu düzgün anlatamadığı ve yöneticilerin giderek sinirlendiği durumlar görüldüğü, artık sinirlenen son kullanıcıya bile ihtiyaç kalmadığı söyleniyor
Hatta bunun kötü yönetim ve baştan savma talimatların doğal sonucu olduğu; bu kez suçu junior'lara atmanın da mümkün olmadığı ve yalnızca kişinin kendisini suçlayabileceği belirtiliyor
Özellikle ünlü .NET performans bloguyla tanınan Stephen Toub gibi birinin de bu sürece dahil olduğunu görmenin acı verdiği vurgulanıyor
Bu tür yeni teknoloji deneylerinin yapılmasına karşı olunmadığı, farkın yalnızca şu anda bu deneylerin herkesin gözü önünde yaşanıyor olması olduğu söyleniyor
Microsoft'un eskiden beri sorun çıktığında "hatayı görmezden gel" tavrıyla Will Not Fix deyip geçmesi ve yöneticilerin kendini tatmin ettiği bir kültüre sahip olduğu, bu yüzden bugün olanların çoğunu kendi eliyle hazırladığı yönünde alaycı bir görüş sunuluyor
İlk PR'a eklenen yorumla bağlam veriliyor: çeşitli deneylerle aracın sınırları anlaşılmaya çalışılıyor ve geleceğe hazırlanılıyor; merge sorumluluğu eskisi gibi yine bakımcılarda kalıyor; kalite standardı karşılanmadan hiçbir şey merge edilmeyecek
Bu yorumu yazan Microsoft çalışanının, AI kullanımını düşünmeyenlerin geride kalacağı görüşünü de savunduğu belirtiliyor; Microsoft'un AI nedeniyle yazılım mühendisliği sektörünün altüst olacağı korku/heyecan karışımı bir havaya kapıldığı, bu deneylerin aracın sınırlarını öğrenmekten çok işini korumak için sürüye katılmak gibi göründüğü ve bunun güveni azaltığı söyleniyor
Yöneticilerin model yetenekleri hakkında zaten kesin bir hükme varmadığını, gerçek dünya bağlamında güçlü ve zayıf yanları anlamaya yönelik makul deneyler yaptıklarını kabul etmek gerektiği belirtiliyor
CI'dan geçememiş bir PR'ın birine atanmasının başlı başına garip olduğu, en azından yalnızca geçen PR'ların atanmasının normal olması gerektiği, ama sistemin o kadar dağınık göründüğü ki bunun bile yapılamadığı hissi verildiği söyleniyor; düzgün çalışsaydı bunun en temel şeylerden biri olması gerekirdi denilerek alay ediliyor
Her şeyi en kötü senaryo olarak yorumlamamak gerektiği, işin içindeki insanların bunun bir deney olduğunun farkında olup beklentilerini de buna göre ayarlamış olacağı söyleniyor; böyle deneysel yaklaşımlar olmadan sistemlerin gelişmesinin zor olduğu, gerçek ortamda tuning ve test yapılıyor olabileceği ekleniyor; kendi şirketinde de AI kodlama destek araçlarının ilk dönemlerinde aynısının yapıldığı, insanın yazdığı koda göre kalite daha düşük olsa da bu süreçten çok şey öğrenildiği ve bir baseline sayesinde iyileşme eğrisinin net görülebildiği belirtiliyor
Yorumlarda, güvenlik duvarı sorunu nedeniyle test geçişinin kontrol edilemediğine dair bir açıklama olduğu ve yalnızca bu sorun çözülse sistemin normal çalışabileceği söyleniyor
AI ajanı yerine başka bir yeni teknoloji koyulduğunda da bunun aşağı yukarı tipik bir şirket görüntüsü olduğu ifade ediliyor: açık biçimde deney yapmak (big tech tarzı dogfooding), sektörün teknik kapasite gelişimine gerçekten katkı sağlamak, sorun çıktığında zararın tamamen takım içinde kalması; bu durumda böyle deneyleri desteklememek için özel bir neden olup olmadığı soruluyor
Bu tür açık deneylere herkesin yalnızca yüklenmesini garip bulan bir yorum var; özel fork'ta gizlemek yerine gerçek yetenekleri şeffaf biçimde göstermek çok daha faydalı görülüyor ve satış/pazarlama abartısından daha iyi bulunuyor
Yazılım geliştirmenin temel altyapı framework'ünde böyle deneyler yapmanın ise tartışmalı olduğu belirtiliyor
"Bizim" neden, nasıl ve neyi destekleyip desteklemememiz gerektiği sorgulanıyor; yorum sahibi kişisel olarak MS'in bu kadar gösterişli biçimde çuvallamasını komik bulduğunu söylüyor
Bunun gerçek anlamda "ilerleme" sayılmasının zor olduğu, iç POC yapılmadan sistem sorunlarının dışarıya açık biçimde sergilenmesinin sorumsuzluk olduğu söyleniyor; güvenlik duvarı gibi temel ortam doğrulamalarının neden yapılmadığı ya da neden önce başka dahili kod tabanlarında denenmediği soruluyor; altyapı kodunun yüksek standart gerektirdiği, dogfooding bahanesi varsa bile önce alt seviye projelerden başlanması gerektiği, bunun "state of the art" bile olmadığı ve harcanan paraya göre sonucun çok kaba olduğu yönünde eleştiri getiriliyor
Çok sayıda geliştiricinin bağımlı olduğu popüler projelerde böyle deneyler yapılmasının sorunlu olduğu, AI'nın ürettiği kötü kod nedeniyle kalitenin düşebileceği, işe yaramaz kod yığınlarının birikebileceği ya da takım üyelerinin üretkenliğinin aşınabileceği kaygısı paylaşılıyor
Eğer amaç bir şeye pasif biçimde boyun eğmekse, talepleri hiç incelemeden topluca onaylamak ve Microsoft'un teknoloji yığını küresel ölçekte çökünce istifa edip danışman olarak üç kat maaş almak yönünde ironik bir öneri yapılıyor
Buna benzer alaycı bir tavırla çalışmak istemediğini söyleyen biri, şirket yönetimiyle düşmanca bir "biz ve onlar" çerçevesini ya da bilerek batırma yaklaşımını anlamadığını belirtiyor; eksiklerden şikâyet etmenin tüm organizasyonu engellemek ya da saldırmak anlamına gelmemesi gerektiğini ve bunun kendi vicdanına uymadığını söylüyor
Buna karşılık bir başkası, aslında Microsoft'un teknoloji yığınının zaten çökmüş sayılabileceği yönünde alaycı bir cevap veriyor
Gerçekte CoPilot ile üretilmiş PR'ın bizzat yöneticiler tarafından gönderildiği de hatırlatılıyor
Bir gün CoPilot'ın tüm kod tabanının üzerine yazacağı ve ortada kod kalmazsa artık test başarısızlığı da olmayacağı diye şaka yapılıyor
Her an işten çıkarılabilecek olunabileceği için, örneğin TypeScript derleyicisini Go ile yazan kişi örneğinde olduğu gibi, böyle organizasyonlarda sadakat göstermenin gerekli olmadığı görüşü ifade ediliyor
PR açmanın en azından güvenli bir deney yöntemi olduğu, işe yaramazsa hemen çöpe atılabildiği söyleniyor; yeni denemelerde her zaman deneme-yanılma ve başarısızlık olacağı, ama deneyimin kendisinin önemli olduğu vurgulanıyor; gerçek kod ve gerçek problemler üzerinde sert biçimde eğitilen araçların hızla gelişebileceği umuluyor; örneğin gelecekte test geçene kadar yinelemeli öğrenme, testleri silmeyi engelleyen kontroller gibi iyileştirmeler bekleniyor; sonuçta geliştirmenin tekrar eden ve basit işleri AI'ya bırakıp, geliştiricilerin özündeki yaratıcı çalışmaya odaklanacağı bir gelecek öngörülüyor
Yine de bu deneylerin public repository yerine private fork'ta yürütülmesinin daha güvenli olacağı, satış açısından böyle örneklerin açığa çıkmasının doğru karar olup olmadığının tartışmalı olduğu belirtiliyor; şirket içi karar vericiler dergilerde CoPilot görüp aynı şeyi denemek istediğinde bu tür gerçek vakaların onlara referans olabileceği de ekleniyor; çoğu şirketin uygulama kusurlarını mümkün olduğunca gizleyip yalnızca cilalı tarafını göstermeyi tercih ettiği söyleniyor
Yüzeyde düzgün görünen PR'larda bile görünmeyen sorunlar saklı olabildiği, bu yüzden onların daha da tehlikeli olabileceği söyleniyor
AI kod incelemesinin, basit ve tekrar eden işlerden bile daha sinir bozucu olduğuna dair deneyim paylaşılıyor; özellikle hata gizlenmişse geliştiricinin çok daha fazla uğraştığı belirtiliyor
PR açmanın kendisinin proje yönetimine ek yük ve karmaşıklık getirdiği, ayrı bir fork'ta deney yapmanın topluluk için daha iyi bir örnek olacağı söyleniyor; birçok açık kaynak projesinin biriken PR yükü yüzünden bakımcılarının tükendiği, hatta bakımın tamamen durduğu ya da birilerinin fork açıp yalnızca hayatta kalan PR'ları aldığı örneklerin sık görüldüğü, bu yüzden bu tür terk edilmiş projeler ve fork'ların çoğalmasından endişe edildiği ifade ediliyor
Eğer LLM'nin gerçekten hatalı durumda kod yazmayı öğrenebileceğine inanılıyorsa, o zaman bir sonraki aşamada neredeyse hatasız veri setlerinin kurulması gerekeceği, gerçekte ise bunun yerine her türlü verinin rastgele toplandığı söyleniyor
GitHub'ın dünyanın en olgun depolarından birinde boşlukla ilgili lint'i bile sık sık geçemeyen bir AI'ya milyarlarca dolar harcadığı, bunun hobi amaçlı bir deney olsa anlaşılabileceği ama fiilen fiyat etiketiyle "yenilikçi ürün" diye satılmasının tartışmalı olduğu söyleniyor
Araştırmacı açısından bunun elbette doğal bir deney olduğu, sorunun ise bu kadar eksik bir şeyi hemen satmaya çalışan şirket tavrı olduğu belirtiliyor
Eski CEO Nat Friedman için "ölmüştür herhalde... yok ya, hâlâ hayatta" şeklinde bir şaka yapılıyor
Asıl sorunun, yazılım geliştiricilerinin performansını ölçmeye yarayan nesnel metriklerin yokluğu olduğu söyleniyor; yıl sonu değerlendirmeleri gibi öznel yargılardan başka bir şey olmadığı, bu yüzden AI kullanımının verimli mi verimsiz mi olduğunu anlamanın da zorlaştığı ifade ediliyor; junior'dan ucuz gibi görünse de senior zamanını boşa harcaması ve talimatlara uymaması gibi maliyetler bulunduğu, buna CEO kültü eklenince organizasyon içinde görüş ayrılıklarının büyüdüğü belirtiliyor; geliştiricilerin itirazlarının "yerini kaybetme korkusu" diye geçiştirildiği, CEO tarafının ise bu girişimden en yüksek siyasi/getirisel başarıyı çıkarmaya çalıştığı, iki tarafın da üzerinde uzlaştığı bir sektör standardı olmadıkça gerçeğin ortaya çıkamayacağı söyleniyor; hatta uç bir çıkarımla, organizasyonların AI PR sayısını artırmak için inceleme standartlarını bile düşürmeyi isteyebileceği öne sürülüyor