Döngüdeki insan yoruldu

 (pydantic.dev)
2 puan yazan GN⁺ 3 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • LLM programlama, üretkenliği artırırken geliştiricinin niyeti ve kaliteyi sürekli kontrol altında tutmasını gerektiren denetim yorgunluğunu büyüterek tatmin duygusunu ve sürdürülebilirliği sarsıyor
  • Modeller, inandırıcı kodu hızla üretebiliyor; ancak karmaşık değişikliklerde tutarlı niyeti kaçırabildiğinden, insan artan çıktıyı inceleyip düzelten kalite kapısı hâline geliyor
  • Başlatılabilecek işlerin sayısı hızla artsa da dikkatle tamamlanabilecek iş miktarı insan beynine ve dikkatine bağlı; kodlamanın küçük ödülleri azalırken incelemenin bilişsel yükü artıyor
  • Derinlemesine anlaşılan alanlarda LLM etkili biçimde yönlendirilebilir; ancak uzmanlığın sığ olduğu alanlarda doğruluktan çok inandırıcılığa kaydığı için zevk ve mimari yargı daha önemli hâle geliyor
  • Yazılım mühendisliği yok olmaktan çok küçülüp yeniden şekilleniyor; kıt kaynak kod yazmanın kendisi değil, insan dikkati, mühendislik yargısı ve sisteme dair tutarlı bir vizyonu koruma becerisi

Yararlı ama istikrarsız LLM programlama

  • LLM programlama pratikte yararlı olduğu kadar istikrarsız; bu istikrarsızlık görmezden gelinirse geliştiriciler tükenmişliğe sürüklenebilir
  • Pydantic ekibi de veri doğrulama, AI ajanları oluşturma ve prodüksiyon gözlemlenebilirlik araçları geliştirirken aynı karmaşayı yaşıyor
  • Esas mesele yapay zekanın programcıların yerini alıp almadığı değil; mevcut geliştirme deneyiminin nasıl değiştiği ve bunun neyle iyileştirilebileceği

Elle üretmenin verdiği his

  • Programlama, yalnızca mantıkla bir şeyler inşa etme ve derin soyutlama katmanlarıyla doğrudan çalışma üzerinden bir yaratma hissi sunageldi
  • Resmî bilgisayar bilimi eğitimi yerine deneme yanılmayla yazılım mühendisliği öğrenme deneyiminde mimari ve kod kalitesi ilkeleri, ders kitabı kurallarından çok birikmiş yaralara benzer
  • 2010'ların low-code/no-code araçları ve Dreamweaver gibi ürünler de kodsuz bir şeyler yapma vaadiyle ortaya çıktı; ancak içeride spaghetti code üreterek beklentileri tam olarak karşılayamadı
  • Bugünün yapay zeka araçları, geçmişten farklı olarak vaat ile gerçeklik arasındaki farkı anlamlı ölçüde daralttı; tam da bu yüzden daha tedirgin edici geliyor

“Kod kendi kendini yazıyor” deneyimi gerçekte nasıl

  • Kod bir ölçüde kendi kendini yazıyor; fakat onu inceleyen, yönlendiren ve rotasını düzelten insanın deneyimi tersine daha kötüleşebilir
  • Pydantic AI bakımcısı Douwe, başkalarının yapay zekasının gece boyunca açtığı yaklaşık 30 PR'ı her sabah inceleyip her biri hakkında anında karar vermek zorunda kaldı
    • İncelemeyi de yapay zekaya bırakma isteği güçlü; ama böyle yapılınca insanın ne yaptığı sorusu geriye kalıyor
  • LLM'in uygulayacağı planı neredeyse iki gün boyunca yazıp tekrar tekrar netleştirseniz bile model React hook'larını Storybook story dosyasına taşıyabilir ya da yanlış planı okuyup var olmayan bileşenler oluşturabilir
  • Bu tür başarısızlıklar basit bir yetenek eksikliğinden çok tutarlılık eksikliğine yakındır
    • Model, inandırıcı kod üretecek kadar zekidir; ama karmaşık bir değişikliğin tamamında tek bir niyeti koruyamayabilir
  • İnsan, zihninde niyeti korurken çok sayıda “çoğunlukla doğru” çıktıyı sürekli yargılamak zorunda kalır; bu süreçte yeni bir denetim yorgunluğu türü ortaya çıkar
  • Açık kaynakta gerçek insanlarla özellik geliştirmenin ve karşı tarafın yetkinliğinin artmasına yardım etmenin verdiği ödül de azalır
    • İş yapay zekanın kara kutusuna girdiğinde diğer tarafta öğrenen biri olmadığından işbirliğinin tatmini kaybolur

İş yoğunluğunu artıran tuzak

  • Simon Willison tarafından aktarılan Berkeley Haas araştırması, yapay zeka kullanımının iş yükünü azaltmaktan çok iş yoğunluğunu artırdığını öne sürüyor
    • Günün sonunda bir prompt daha girme ya da bir özelliği daha bitirme baskısı sürüyor
    • Planın neredeyse tamamlandığı hissi yüzünden gece 2'ye yakın saatlere kadar prompt girilen durumlar da yaşanıyor
  • Pydantic'ten Marcelo, Claude Code oturumu durursa 5 oturum açmak gerektiği yönünde şaka yapıyor
    • Bunun anlamı, diğer oturumlara geri bildirim vermekle meşgulseniz bir oturumun durduğunu fark bile etmeyebilirsiniz
  • Paralel çalışma, başlatılabilecek iş sayısını büyük ölçüde artırır; ancak dikkatle bitirilebilecek iş sayısı değişmez
    • Tamamlama, paralelleştirilemeyen bir kaynağa, yani insan beynine ihtiyaç duyar

İnsan ödül fonksiyonunun bozulması

  • Makine öğrenmesindeki ödül fonksiyonunun bir ajan için iyi sonucu tanımlaması gibi, elle kodlamada da problem çözme, karmaşık mantığı anlama, derlemenin başarılı olması ve kontrol hissi gibi küçük ödüller vardı
  • LLM destekli programlama, bu dopamin ödüllerini yaratan işleri otomatikleştirip yerini inceleme ve denetimin bilişsel yüküyle dolduruyor
    • Tatmin edici kısımlar azalıyor
    • Yıpratıcı kısımlar artıyor
    • Boşluğu dolduracak yeni bir ödül henüz yok
  • Üretkenliğin artarken tatminin azalması kişisel bir kusur değil, geri bildirim döngüsünün bozulmasıdır ve ayrı bir mühendislik problemi olarak ele alınmalıdır

Yalıtılmışlık ve değişken ödül

  • LLM programlama, insan ile makinenin prompt, düzeltme ve incelemeyi tekrarladığı son derece yalnız bir etkinliğe dönüşebilir
  • Bir iş arkadaşına soru sormak ya da problemi birlikte sözlü olarak çözümleyip çözümün küçük sevincini paylaşmak gibi anların yerini bir başka prompt alır
  • Mevcut işbirliği kültürü zayıf olan ekiplerde insanlar arası iletişim daha da daralır ve başkalarının da zorlandığını görmek güçleşir
  • Sonucun bazen harika, bazen çöp olması ama bunun önceden bilinememesi, Skinner Kutusu gibi değişken ödül yapısı yaratır
  • Gerektiğinde doğrudan kod yazmak mümkündür; ancak LLM destekli çalışma ile elle çalışma arasında düşünme biçimi ciddi ölçüde farklı olduğundan geçiş rahatsız edicidir
    • Bu iki yöntem arasında gidip gelmeye kendine izin verebilmek olgunluk ve özgüven gerektirir

Responsive tasarıma geçişle benzerlik

  • 2009 civarında web, sabit genişlikli piksel tabanlı yerleşimlerden akışkan responsive tasarıma geçtiğinde tasarımcılar da kontrol kaybı yaşadı
  • Kimliğini ve uzmanlığını hassas yerleşimler ile kusursuz gridler üzerine kuran kişiler için tasarımın rastgele ekran genişliklerine ve cihazlara göre akması fikri köklü bir değişimdi
  • Geçişe uyum sağlayan tasarımcılar mevcut becerilerini terk etmek yerine yeniden yapılandırdı
    • Oran duygusu ve hiyerarşi anlayışı önemini korudu
    • Piksel düzeyinde kontrole duyulan takıntı daha az önemli hâle geldi
    • Sistemler, uyarlanabilirlik ve belirsizlik için tasarım yapmak daha önemli hâle geldi
  • Bugünkü yapay zeka dönüşümü responsive tasarımdan çok daha hızlı ve çıkar dengeleri de farklı
    • Responsive tasarımdaki değişim yıllara yayılmıştı; bugünkü değişim ise aylar ölçeğinde ilerliyor
    • O dönemde de ajanslar müşterilerini, tasarımcılar işlerini kaybetti; ama bu, bugünkü gibi varoluşsal bir kaygıyla birlikte gelmiyordu
  • Yine de becerilerin yok olmaktan çok evrilmesi ve temel yetkinliklerin daha önemli hâle gelmesi örüntüsü LLM tabanlı kodlama için de geçerli
  • Tüm kodu doğrudan yazmamak mühendisin değerini azaltmaz; ancak çok daha fazla çıktının kalite kapısı hâline geldiği için iyi sonucu ayırt etme becerisine daha çok ihtiyaç vardır

Ayakta kalan uzmanlık ve yeni çalışma biçimleri

  • Herkesin inandırıcı arayüzler ve derlenen kod üretebildiği bir ortamda zevk ve nüans, olgun mimari yargı ve gerçek uzmanlığa dayanan ana akım dışı kararlar fark yaratır
  • Kodları, kararları ve trade-off'ları ne kadar derin anlarsanız LLM'i o kadar başarılı biçimde yönlendirebilirsiniz
  • Uzmanlığın sığlaştığı alanlara gidildikçe çıktılar prodüksiyona hazır seviyeden uzaklaşır ve gerçekten doğru olmaktan çok etkileyici biçimde inandırıcı bir hâle yaklaşır
    • Model, bilmediğini bilmeden boşlukları özgüvenle doldurur; bu insanlarda da görülen bir başarısızlık biçimidir
  • Karmaşık planlarda pre-mortem kullanılabilir
    • Yeni bir LLM oturumundan planın feci biçimde başarısız olduğunu varsaymasını ve nedenleri teşhis etmesini isteyin
    • Ayrıntılara iki gün boyunca bakan kişinin kaçırdığı spesifikasyon boşluklarını bulmaya yardımcı olur
  • Pydantic'teki bir mühendis, geçmiş kod inceleme yorumlarındaki binlerce kuralı çıkarıp AGENTS.md dosyası için başlangıç yönergelerine dönüştüren bir araç geliştirdi
    • Bu, yıllar içinde örtük olarak birikmiş mühendislik yargısını LLM'in izleyebileceği talimatlara dönüştüren bir uzmanlık damıtımıdır
  • Değişime uyum sağlayan kişiler, pratikte edinilmiş güçlü yargı ölçütlerine sahiptir ve hâlâ geçerli ilkeler ile geçmiş bant genişliği kısıtlarından doğan alışkanlıkları birbirinden ayırır
  • Bu kişiler standartlarını terk etmeden iş akışlarını değiştirmeye isteklidir

Döngü içinde ortaya çıkan kıt kaynak

  • Bugünkü yapay zeka dalgası yazılım mühendisliği mesleğini bitirmeyecek; ancak sektörde ciddi bir küçülme ve köklü bir yeniden yapılanma getirebilir
  • Elenme, yetkinlik körelmesi ve yeterince hızlı hareket edilmezse geride kalma korkusu meşrudur
    • Son kaygı kimi zaman abartılır; ama tamamen temelsiz değildir
  • Gerçek darboğaz kod değil; insan dikkati, mühendislik yargısı ve sisteme dair tutarlı bir vizyonu koruma becerisiydi
  • Kod yazmak zor kısım gibi göründüğü için bu darboğaz eskiden pek görünmüyordu; yazma süreci otomatikleştikçe insan kapasitesinin asıl kıt kaynak olduğu netleşiyor
  • Geliştiriciler daha üretken ama daha az mutlu ve istikrarsız olabilir; araçları geliştiren ekipler de aynı sorunları yaşayıp ödül fonksiyonunu gerçek zamanlı olarak ayarlıyor
  • Kod ve geliştirme biçimi değişiyor; ancak insan hâlâ döngünün içinde ve şu anki temel durum insan katılımcının yorgunluğu

İlgili okumalar

1 yorum

 
GN⁺ 3 시간 전
Hacker News görüşleri

  • Elle kod yazarken iş zorlaştıkça problem çözme, mantığı anlama, derlemenin başarıyla geçmesi ve kontrol hissi gibi küçük ödüller büyüyordu. Buna karşılık ajan kodlama, özellik ölçeğinden bağımsız olarak sürekli benzer bir gözetim gerektiriyor; bu da ilk başta üretkenlik dalgasına binmiş gibi heyecan verse de tatmin edici kısımlar azalıyor, incelemenin bilişsel yükü artıyor ve insanı çabucak yoruyor

    • İşimi kaybetmekten çok yakında işin kendisinden nefret eder miyim diye korkuyorum. LLM’ye talimat vermenin çok zaman kazandırmadığı işleri kendim yapıyor, çıktı yapısını da insanların anlamasını kolaylaştıracak şekilde yeniden düzenleyerek kontrol hissini koruyorum
    • Benim motivasyonum, kodun nasıl üretildiğinden çok ortaya çıkan ürünü daha fazla insanın faydalı bulup kullanması. Önce kullanıcıyı düşünüp gerekirse kestirme yollar seçtim; bakımı yapılabilir kod ile çıkış hızının dengesini LLM kullansam da kurabiliyorum
    • Geliştirme, bilgi temelli bir meslekten ücreti düşük bir fabrika işçiliğine dönüşebilir. LLM’yi yönlendirmek için gereken bilgi ve deneyim, doğrudan yazmaya kıyasla çok daha az; LinkedIn’de neredeyse hiç deneyimi olmayan ya da junior seviyesindeki insanlar bile AI engineer olarak işe alınıyor
    • Yapay zekanın çıktısını kendi kendine test ettiği bir döngü kurarken dopamin hissediyorum. Codex’in belirli bir dizüstü bilgisayarda ve Linux çekirdeğinde hazırda bekletmeyi çalıştırması için ağ-USB-C klavye dongle’ı, Fingerbot ve web kamerasını bile bağlayıp uzaktan kontrol ettirdiğim Rube Goldberg tarzı otomasyonlar daha da tatmin ediciydi
    • Kişisel projelerde özellikleri daha kolay üretirken sonuçlar daha rafine ve tutarlı olduğu için tatminim aksine artıyor. Bir projeye bir ay boyunca odaklanırsam oldukça iyi sonuç alıyorum; yeniden yazım ve yapı düzenlemesi ucuzladığı için tasarım alanını gerçekten daha geniş biçimde keşfedebiliyorum. Yine de çoğu zaman tıkandığım oluyor; bunun yarısı benim yeterli bağlam vermemem, yarısı da modelin doğasından gelen sınırlar

  • Claude’u işte ve kişisel projelerde keyifle kullanıyorum; kilit nokta ajanın cazibesine kapılmayıp onu bir kod üreticisi gibi ele almak. Tek bir oturum açıp planı iyice netleştirdikten sonra adım adım yürütmesini izliyor, her adım bittiğinde gözden geçirip yön veriyorum; böylece sonda da kodun durumunu iyi kavrıyorum
    Buna yakın bir one-shot kullanım istiyorsanız plan aşamasında yalnızca mimariyi değil, ana kararları belirleyecek gerçek kodu da somutlaştırmanız gerekiyor. Refactoring maliyeti hiç olmadığı kadar düşük; anlaması zor kısımları hemen LLM ile düzeltin ama aynı anda bir LLM’ye yalnızca tek bir iş verin ve sürece sürekli dahil olun

    • Claude ile birkaç ay çalıştıktan sonra başlangıçta ayrıntıları yeterince konuşup gerekirse iskeleti bile hazırladıktan sonra yürütmeye geçiren akışı öğrendim; bunu https://github.com/ctomkow/claude/blob/main/README.md içinde toparladım. Sürekli ertelediğim legacy kodu yeni mimariye başarıyla refactor ediyorum
      Claude’a tam yetki verince kaçınılmaz olarak ortaya çıkan karmaşa ve engeller insanı tüketiyor. İstediğimde kendim kodlayıp yorulduğumda Claude’a devredince kod tabanı üzerinde kontrol hissini de koruyabiliyorum
    • Editörden tamamen ayrı bir sohbete yalnızca gerekli kod parçalarını yapıştırıp kısıtları ve fikirleri tartışıyorum; sonuçtan memnun kalırsam editöre taşıyıp isimleri ve implementasyonu daha da rafine ediyorum. Net ya da keyifli işleri kendim yapıyorum; mimari kararlara da dahil olmam gerekiyor ki projeyle bağımı koruyayım ve onu derinlemesine anlayabileyim
    • Vibe coding, birden fazla ajan döngüsü kullansa bile çıktıyı yakından gördüğünüz yardımcı araç yaklaşımına göre daha kolay tükenmişlik yaratıyor
    • Kademeli çalışsanız bile başka biri incelerken tüm sonuca ilk kez bakıyormuş gibi tek seferde bakmak zorunda kaldığından inceleme yükü azalmıyor
    • İş akışında en fazla iki şey arasında gidip gelebiliyorum; bundan fazlasında bağlam değişimi yüzünden zihnim tamamen tükeniyor

  • Ekip arkadaşlarımın ya da bana bağlı çalışanların kodunu incelerken, geri bildirimin teknik doğruluğunun yanı sıra ego, mimari bakış farkı, nazik bir ton, ek iş yükü ve ekip dinamikleri gibi şeyleri de hesaba katmak zorunda olduğum için zihinsel enerjimin çoğu buna gidiyor. Buna karşılık LLM’de duygusal etkiyi düşünmek gerekmiyor; bu yüzden inceleme ve yön düzeltme çok daha kolay

    • Ekip arkadaşımın benim geri bildirimimi tekrar AI’a vereceğini biliyorsam, insandan çok AI’a hitap eder gibi yazar ve düzeltme listesini çok daha kısa ve doğrudan iletirim
    • Teknik lider olarak her PR’da “bu kadarı yeterli” itirazıyla karşılaştım; LLM’ye ise itiraz olmadan bunu doğru şekilde yeniden yap diyebilmek rahatlatıcı

  • İş yerinde artık human in the loop yerine Human on the hook demeye başladık. İyi giderse takdir alamayan, ama bir şey ters giderse sorumlu kişi olan; yani yalnızca sorun çıktığında insanın önemli hale geldiği yapıyı daha doğru anlatıyor

  • Kod yazma işi benim için hiçbir zaman asıl zor kısım olmadı. Hızlı yazma, Vim’in kipli düzenlemesi, Unix komutları, script’ler ve kısayollar, Git, IDE refactoring’i, Java; ne yapmak istediğimi bildiğimde düşünce hızında çalışıyordum
    Durduğum anlar yazma ya da sözdizimi yüzünden değil, kodun biçimini ve doğru değişikliği düşündüğüm anlardı; zorlaştığında daha iyi soyutlamalar, IDE araçları ya da sed dahil Unix pipeline’ları kurardım. Bu yüzden darboğaz kod yazımı değil, düşünme ve yargıydı
    AI coding’in büyük bir sıçrama gibi görünmesinin nedeni, iyi araçlarla hiç tanışmamış ya da onları ustalıkla kullanamamış geliştiricilerin beklenenden fazla olması olabilir. Şimdi 20’lerimde olsaydım bu tür teknikleri öğrenmeye daha az zaman harcardım; ama yazılım mühendisliğinin bana gerçekten çekici geldiği an, hiçbir şeyin sihir olmadığını anladığım zamandı

    • “AI, iyi yapamadığı şeyleri iyi yapıyormuş gibi görünür” sözü çok yerinde. Programlamada acemiyseniz AI çıktısı hızlı ve harika görünebilir; ama deneyimli bir geliştirici için talimat verme, bekleme, ikna etme, düzeltme ve refactor etmenin toplamı, işi doğrudan yapmaktan daha hızlı olmayabilir
      Ben resimde kötü olduğum için AI görselleri bana etkileyici geliyor; AI ile programlama da aynı ilkeyle değerlendiriliyor olabilir

  • Birçok kişinin hissettiği yorgunluk, daha yüksek hız ile daha büyük karmaşanın birleşip yarattığı kontrol kaybından geliyor. LLM, dahi ile bebek arasında bir yerde; arka koltukta oturup onu izlemek hem heyecan verici hem korkutucu
    Bir süre çok hızlı gittikten sonra yürümenin de kötü olmadığını, hatta istediğiniz varış noktasına ulaşma ihtimalini artırdığını fark edeceğiz gibi görünüyor

  • LLM ile kod yazmak, slot makinesinin kolunu çekip bu kez olacak diye umut ederek ritüeli tekrar etmek gibi hissettiriyor. Normal programlamadaki hataların tutarlı nedenleri vardır ve sistem, o nedenleri anlayıp mümkünse kalıcı olarak ortadan kaldıracak şekilde tasarlanmıştır. Deneyimli geliştiriciler rastgele denemeler yapıp başarıya ulaştıklarında bunu nedenini bilmedikleri bir şey diye geçiştirmez
    Sistemin ne olduğu konusunda bile uzlaşamayan çok sayıda paydaşla uğraşmaktan zaten yorulduysanız, insan dikkatinin ve mühendislik muhakemesinin en başından beri asıl darboğaz olduğunu muhtemelen çoktan biliyordunuz

    • İlk kez kod öğrenip bir web uygulaması yaparken, “Acaba bunu denesem olur mu?” diye körlemesine tahmin edip uygulayarak gece geç saatlere kadar bilgisayar başında kalırdım. Yeteneğim arttıkça ve tipli diller, derleyiciler, LSP kullandıkça neyin çalışacağını anlamaya başladım ve bağımlılık yapan tahmin oyunu yerine tatmin edici bir akış durumuna girebildim
      Claude ile kod yazmak, o tahmin aşamasına geri dönmek gibi geliyor; bu yüzden istemiyorum. Yine de karmaşık API'ler ve çeşitli bileşenleri birbirine bağlayan DevOps türü işler gibi, zaten kör tahminin çok olduğu alanlarda LLM sohbeti en faydalı oluyor
    • Artık paydaşlar uzlaşmak yerine LLM ile yarım pişmiş planlar ve çeyreklik hedefler üretiyor, tasarım, hikâyeler, teknik ayrıntılar, uygulama ve kod incelemeyi de tamamen LLM'ye bırakıyor. Sürecin tamamında eleştirel düşünme ve doğrulama ortadan kalkıyor ve geriye amacı bile belirsiz tasarım belgeleri ile kod yığınları kalıyor; bunları takip etmek bile zor
      Planlar her an değişebiliyor ve her şeyin dürtüsel biçimde baştan yazılma ihtimali de daha yüksek

  • Yazının ana fikrine katılıyorum ama yer yer Claude'a özgü üslup hissediliyor; birinin AI ile yazdığı bir metni okumak daha da yorucu

    • Doğrudan AI yazmış olmaktan ziyade, kurumsal üsluba uyarlayan düzenleme ve incelemeden geçmiş olması daha olası. LLM'nin kendisi de zaten böyle bir üslupla eğitildi
    • Büyük kısmını AI yazmış olsa da tipik AI metinlerine göre insan müdahalesi çok daha fazla; bu yüzden her zamanki kadar rahatsız etmiyor
    • “It’s not” tekrarları ve tire kullanımı gibi üslup izlerine bakınca bunun AI yazımı olduğu sonucuna varıyorum
    • Kendisi yazma zahmetine girmediyse, ben de okuma zahmetine girmek istemem

  • 2021 tarihli The Animal is Tired yazısını hatırlattı: https://www.robinhobb.com/blog/archives/2021-05

    • Orijinal site IP engellediği için, daha az kısıtlayıcı aynadan https://archive.is/RWxXP okunabiliyor. Kendi gerileyişini hissetmek en büyük kederlerden biri olabilir ve herkesin başına gelir
      Bedeninize daha çok özen gösterseniz bile sonunda aynı yere varırken değerli anıları kaçırmış olabilirsiniz. Bedeninize iyi bakın, ama ona bir sonraki savaşta gerekebilir diye sona kadar kullanılamayan oyun iksiri gibi davranmayın. Bedenimizin her parçası ya daha büyük bir amaç uğruna bir kez feda edilebilir ya da hiç feda edilmez
      Bunları düşünmek bile beni ağlatacak kadar, hâlâ duygusal bir krizin içindeyim

  • Yapay zeka kullanımının iş yoğunluğunu artırdığını söyleyen Berkeley Haas araştırma tanıtımı dikkat çekici, ancak HBR yazısı https://hbr.org/2026/02/ai-doesnt-reduce-work-it-intensifies... ve tanıtım materyali https://newsroom.haas.berkeley.edu/ai-promised-to-free-up-wo... yayımlandıktan sonra 5 aydan fazla geçmiş olmasına rağmen ortada gerçek makale ya da ön baskı yok
    Şu anda bilinen tek şey, tek bir sektördeki tek bir şirkette yapılmış yaklaşık 40 nitel görüşme olduğu; bu yüzden araştırma yöntemini görmeden sonuçların güvenilirliğini değerlendirmek zor