Amazon’da bazı geliştiriciler işlerinin depo işçiliğine benzemeye başladığını söylüyor

• Amazon geliştiricileri, yapay zeka kullanımının ardından iş temposu baskısı ve işlerin basitleşmesi ile karşı karşıya kalıyor
• Yöneticiler, verimlilik artışı gerekçesiyle yapay zeka araçlarının kullanımını güçlü biçimde teşvik ediyor
• Bazıları tekrar eden işlerin azalmasıyla iş kalitesinin iyileştiğini düşünse de, yeni geliştiricilerin büyüme fırsatlarını kaybettiğine dair endişeler de var
• Kodlama, doğrudan yaratım odaklı bir işten inceleme ve doğrulama merkezli bir işe dönüşürken, bazıları bunun artık kendi işi gibi hissettirmediğini söylüyor
• Amazon Employees for Climate Justice gibi şirket içi gruplar, bu sorun da dahil olmak üzere iş stresi ve geleceğe dair kaygıları paylaşıyor

---

At Amazon, Some Coders Say Their Jobs Have Begun to Resemble Warehouse Work

Kodlamada da ‘hız yarışı’ dönemi

• Sanayi Devrimi’nden bu yana tekrar tekrar görülen makineleşmeye bağlı işlerin basitleşmesi olgusu, artık kodlama alanında da yaşanıyor
• Yapay zeka, işleri ortadan kaldırmaktan çok, mevcut görevleri daha basit ve daha hızlı yapılan bir biçime dönüştürüyor
• Microsoft araştırmasına göre, yapay zeka yardımcısı ‘Copilot’ kullanan geliştiricilerin verimliliği %25’ten fazla arttı
• Amazon da bunu benimseyerek yapay zeka ile daha hızlı ve daha verimli çalışma talep ediyor; bunu hissedarlara mektubunda ‘maliyet düşürme ve rekabet gücünü koruma’nın anahtarı olarak vurguluyor
• Örneğin bir geliştirme ekibi, geçen yılın yarısı kadar kişiyle çalışırken aynı miktarda kod üretmesi istenen bir yapıya geçmiş durumda

Şirketler genelindeki eğilim

• Shopify, tüm çalışanlar için yapay zeka kullanımını temel bir gereklilik haline getirdiğini ve bunun performans değerlendirmelerine de yansıtılacağını açıkça belirtiyor
• Google, şirket içi hackathon’larda günlük verimliliği artıran yapay zeka araçları geliştirmeyi tema olarak seçiyor. Şimdiden kodun %30’undan fazlası yapay zeka önerileriyle üretiliyor

Olumlu yönler ve kaygılar

• Bazı yöneticiler, yapay zeka sayesinde sıkıcı ve tekrar eden işlerin azalacağını, böylece daha yaratıcı görevlere odaklanılabileceğini savunuyor
• Amazon, yapay zeka sayesinde 4.500 yıllık geliştirme işinden tasarruf ettiğini söylüyor
• Ancak Harvard’lı iktisatçı Lawrence Katz, başlangıç seviyesindeki geliştiriciler için mesleki gelişim fırsatlarının ortadan kalktığına dikkat çekiyor
• Geçmişte fabrika işçilerinin yaşadığı ‘hız yarışı’na benzer biçimde, geliştiriciler de daha hızlı çalışmaları ve daha fazla iş çıkarmaları için baskı görüyor

Geliştiricilerin hissettiği değişim

• Amazon’un lojistik depolarında olduğu gibi, geliştiriciler de yapay zeka kaynaklı iş otomasyonu ve iş bölümü etkisini hissediyor
• Yapay zeka kullanımı ‘isteğe bağlı’ olsa da, performans hedeflerini tutturmak için fiilen zorunlu hale geliyor
• Geçmişte birkaç hafta süren özellik geliştirme işleri artık birkaç gün içinde tamamlanmak zorunda; bunun için de toplantı süreleri azaltılıyor ve yapay zeka ile yazılmış kod kullanımı artırılıyor
• Yapay zeka tüm programı bile üretebilirken, kodu okuyup gözden geçirme işi artıyor; bu da işin keyfini ve odaklanmayı azaltıyor

Kariyer gelişimi ve odak kaybı

• Yeni geliştiriciler, test otomasyonu nedeniyle kodu derinlemesine anlama fırsatını kaybedebilir
• Yapay zeka, tasarım belgeleri yazımı, kod testi gibi çeşitli işlerde destek sağlıyor, ancak değerlendirme ortamı insan değil araç merkezli bir yapıya dönüşüyor
• Obama kampanyasının eski CTO’su Harper Reed, artık her parçayı derinlemesine anlamanın gerekmediği bir dönemde olduğumuzu ve bunun imalat sektöründeki değişime benzediğini söylüyor
• Buna karşılık Simon Willison, fikirleri hayata geçirme hızını artırdığı için yapay zekayı olumlu değerlendiriyor

Memnuniyetsizlik ve örgütsel tepki

• Yapay zeka kullanımı ve bunun getirdiği iş değişimleri nedeniyle birçok geliştirici, Amazon Employees for Climate Justice grubunda kaygı ve stresi paylaşıyor
• Özellikle işin niteliğinin düşmesi ve kariyer belirsizliği konusunda çok sayıda endişe var; bu durum, geçmişte otomotiv işçilerinin yaşadığı hız yarışı stresine benzetiliyor
• Henüz geliştiriciler arasında bir sendikalaşma hareketi yok, ancak kurum içindeki ortak farkındalık giderek büyüyor

Tarihsel bağlam ve geleceğe bakış

• 1936’daki GM grevinde olduğu gibi, iş temposu ve özerklik meseleleri işçi eylemlerini tetikleyen bir unsur olabilir
• Geçmişte bireyler çalışma yöntemlerini ve hızlarını ayarlayabiliyordu, ancak bugün tüm sürecin izlendiği ve hız odaklı değerlendirildiği bir düzene geçiliyor

[GN⁺]

Hacker News görüşü

• archive.ph/HVZRL bağlantı paylaşımındaki içerik
• Bana göre LLM tabanlı geliştirme, kripto ya da VR gibi abartılmış bir hype. Son dönemde vibe coding ile yazılmış bir kod tabanındaki bug’ları düzeltme deneyimimden sonra, bu yaklaşımın aslında yapısız iş problemlerinin hiçbir yapı kazandırılmadan koda aktarılmış bir karmaşa yığını olduğunu düşündüm. İyileştirme gereken yerler dar yamalarla geçiştirildikçe sonuçta karmaşık ve düzensiz kod üretiliyor. context window sınırına gelindiğinde LLM kendi yazdığı yamaları bile hatırlayamıyor. İngilizce (veya insan dili), benim istediğim kodu tam olarak tarif etmek için muğlak kalıyor; kıdemli geliştiricilerin koda gömdüğü sayısız deneyim ve deneme-yanılmanın toplamını prompt’a dökmek ise aşırı ağır bir iş. “Neden böyle yazıldı” ile “böyle durumlarda bunu yapma, şunu yap” arasında büyük fark var; ikincisi için son derece spesifik ve ucu bucağı olmayan bir liste gerekiyor
  • Bu gözlem, son 30 yılda gördüğüm kod tabanlarının neredeyse tamamının tanımına birebir uyuyor (tam bir istisna dışında)
  • Karşı argüman—AI’ın yapı çıkarması gereken yaklaşık 30 yerde kod kalıplarını bulmama yardımcı olduğu da oldu. Bence vibe coding’in sorunu yaklaşım meselesi. Kendisi kod yazmaktan kaçınan insanlar, uzun vadeli yapı ya da kalite yerine anlık rahatlığa odaklanma eğiliminde; bir tür tembellik yükseltici gibi
  • Gerçekte çok sayıda production kodu, yama üstüne yama yapılarak çalışan kod parçacıklarının toplamı. Trajik olan, CPU’lar o kadar hızlı ki böyle kodlar da pratikte çalışıyor
  • İnsan dilinin net olmadığı eleştirisine katılıyorum. Sonuçta yazılımı doğal dille açık ve net biçimde yönetme girişimleri defalarca tekrarlandı; sonunda hukukta olduğu gibi gri alan yorumları hiç bitmiyor. Gelecekte geliştiriciler programın anlamını derlemeden önce tartışmak zorunda kalacaksa, o gelecek karanlık
  • AI’ın da kripto ya da VR kadar abartılmış bir hype gibi görünmesi doğru. Ama yazılım mühendisliği gibi son derece teknik işlerde bile otomasyon eninde sonunda etkisini gösterecek. Son 10 yılda teknoloji sektöründekiler kendilerini diğer emekçilerin sorunlarından ayrı sandı, ama yeniden yapılanma/işten çıkarma kültürü yüzünden artık ücret baskısı ciddi biçimde hissediliyor. AI her şeyi anında değiştirmese bile, eskiden 5 kişinin yaptığı işi artık 4 kişi AI ile yapınca 1 kişi işten çıkıyor; kalanlar da maaş artışı istemeye cesaret edemiyor. Teknoloji çalışanlarının da sonuçta emekçi olduğunu fark etmesi gerektiği söyleniyor
• Harper Reed’in “kodu derinlemesine anlamaya gerek yok” görüşü hakkında, bu tür sözler bana daha çok “yeter ki derlensin, dağıtıma çıkaralım” tarzı derme çatma bir mantık gibi geliyor. Otomasyon hattında kalite sürekli ölçülse de gerçek makineler açı hatası yapıp alakasız yerlere kaynak atmak gibi halüsinasyonlar üretmiyor; LLM tabanlı yazılımda ise bu tür küçük sapmalar tekrar tekrar yaşanıyor
• LLM tabanlı araçların gerçekten geliştirici üretkenliğini dramatik biçimde artırıp artırmadığı, yoksa organizasyonların sadece daha az sayıda—ve eskisine göre daha az ayrıcalıklı—geliştiriciyle de idare edebildiğini mi fark ettiği belirsiz. Büyük teknoloji şirketleri içinde “çığır açan üretkenlik artışı” örneklerini pek görmedim; şu ana kadar tablo daha çok, yatırımı ancak karşılayacak kadar sınırlı bir verim artışı yönünde
  • Bunun önemli bir kısmı algı meselesi. Eskiden geliştirme zor bir iş olarak görülürdü, ama AI araçlarıyla birlikte kodlamaya giriş bariyerinin düştüğü düşünülüyor. Yazılım geliştirme giderek fabrika işi gibi hissettiriyor ve entelektüel tatmin azalıyor
  • Kod tabanlarının uzun vadeli bakım yapılabilirliği konusunda şüpheler var. Vibe coding, zamanla karmaşıklık, ince bug’lar ve soyutlama sorunlarını biriktirip bakım ve yeni özellik geliştirmeyi daha da zorlaştırıyor olabilir. Kısa vadeli üretkenlik artışına kapılıp uzun vadeli kalite kaybına sürüklenme ihtimali var
  • Organizasyonlar eskiden beri bürokratik süreçlerle “teknikten arınma”, yani daha düşük becerili iş gücünü standardizasyonla ikame etme yoluna gidiyordu. Uzun vadede zehirli olabilecek bir strateji ama tutarlılık sağlandığı sürece “idare eder çözümlerle” yetiniliyor
  • Bu mantığın ikna edici olabilmesi için, Amazon yönetiminin kısa vadeli kârı uzun vadeli kalitenin önüne koyduğunu varsaymak gerekir; ama bundan ne kadar emin olunabilir bilmiyorum
• Yakında emekli olacak biri olarak son değişimler karşısında moralim bozuluyor. 90’larda kariyerime başladığımda uzun süre deney yapmaya ve yaratıcılığa gömülmeye alan vardı. Bugün ise işi küçük parçalara bölmek, durum raporu vermek ve sürekli kendini gerekçelendirmek zorunlu. Gelecekte de ilginç geliştiriciler olacaktır ama böyle fırsatlar azalıyor. Aslında otomasyon yüzünden hayatı zorlaşan diğer mesleklerle aynı yoldan gidiyoruz; bu bakımdan adil bir sonuç
  • Günlük durum raporları, stand-up gibi ritüeller zaman alıyor; ayrıca işimi anlamayan kişilerden bir gün daha kurtulabilmek için verilen biçimsel tepkilere dönüşüp işin değerini düşürüyor
  • Ben de 90’larda işe başlayanlardanım ve JIRA temelli ayrıntılı kontrol hissine katılıyorum. Yine de geçmişin tek başına altın çağ olduğunu düşünmüyorum. Geçmişteki iyi deneyimleri seçerek hatırlatan bir nostalji etkisi de var gibi. Ama bugün de yeterince zorlayıcı ve iyi işler, öğrenilecek şeyler var
  • Mesele mühendislik işlerinin otomasyonu olmaktan çok, fiilen yönetsel pozisyonların AI merkezli gözetimle ikame edilmesi yönünde ilerliyor
• Yazılım geliştirmeyi devrimsel biçimde hızlandırmanın bir yolu da başkalarının açık kaynak kodunu doğrudan kopyalayıp telif/lisans izlerini silerek uygulamak. Doğrudan yakalanmaktan çekiniyorsan bunu taşerona verip aklatabilirsin; bugünlerde AI ile bunu ucuza ve hızlıca yapmak da mümkün. Google eskiden bu tür davranışlarda daha çekingen davranır, yeterince cüretkâr olmazdı. Ama küçük girişimler telif ihlali riskini görmezden gelen AI kullanımıyla hızlı başarı peşinde
  • Bulunduğum sektörde asıl sorun çoğu zaman kod eksikliği değil, “neyin nasıl yapılacağını” tanımlamak. Stackoverflow ya da Github ile çözülemeyen çok sayıda özgün problem var
  • Google da aslında uzun zamandır sitelerin içeriğini tarayıp arama sonuçlarında doğrudan göstererek, trafik göndermeden başkalarının içeriğinden faydalanıyordu. Bu sefer sadece geç kaldı
  • İronik biçimde bazıları, büyük şirketlerin açık kaynak kodunu intihal etmesini neredeyse ister durumda. Çünkü onların kullanıcıya dayattığı soğuk ve verimsiz yöntemlerle yaşamak zorunda kalmaktan daha iyi olduğu düşünülüyor
  • Açık kaynağa kod koymanın sınırları olduğu fikrine katılıyorum. Büyük şirketler, ücretsiz emek elde etmenin bir aracı olarak açık kaynağı teşvik etme eğiliminde. Kısa vadede katkılar azalsa bile uzun vadede bunun sektör için daha sağlıklı olabileceğini düşünüyorum
  • ChatGPT’nin ortaya çıkışı ve Sam Altman’ın liderliğindeki sorumsuzluk eleştiriliyor
• Simon Willison’ın, kod yazmaktan çok kod okumanın daha zor ve daha sıkıcı olduğuna dair sözü ile, AI’ın dokümantasyon yazımı ve test gibi yan işleri ciddi ölçüde üstlendiğini anlatan Amazon geliştiricisi örneği etkileyiciydi. Artık rol, kod yazmaktan çok mevcut kodu inceleme ve bug düzeltmeye doğru kayıyor
  • İlk zamanlarda kod yazmanın ne kadar keyifli olduğu aklıma geliyor. Şimdi bug düzeltmek daha eğlenceli geliyor ve LLM basit tekrar eden kodları üstlenince ben de zorlayıcı meselelere odaklanabiliyorum. LLM sayesinde geliştirmenin eğlenceli tarafının bir kısmı hayatta kaldı
  • Bu yazıdan çıkan genel atmosfer oldukça olumsuz
• Üretkenliği artıran yeni teknolojiler çıktığında şirketler etkisini hızla içselleştirip standartlaştırıyor. Yetişebilmek için sürekli öğrenmek gerekiyor ve bir noktada bu verim artışının faydasını kendin toplayabileceğin bir ortama geçmeyi de düşünmek lazım (örneğin serbest çalışma). Ama tek başına çalışmak, AI konusunda yetkin insanlarla rekabet etmek anlamına geliyor; yani kolay bir çözüm değil
  • Üç gelecek senaryosu öngörülüyor. 1) Kod tabanları giderek kaos ve istikrarsızlık içinde çöker ve sonunda deneyimli geliştiricileri yüksek maliyetle yeniden devreye almak gerekir. 2) AI, idare eder düzeyde kod üretir; kalite ve güvenilirlik düşük kalır ama büyük felaket de yaşanmaz. 3) AI hızla çok daha akıllı hale gelir ve kod tabanı kavramının kendisi ortadan kalkar; yazılım ihtiyaç anında dinamik olarak üretilip evrilir. Mevcut LLM’ler buna daha çok uzak. Şirket yöneticileri 3. senaryoya inanıyor ama bugün için gerçekçi olan 1 ile 2 arası. İyi yönetilirse 2. senaryonun dengeli versiyonuna geçiş mümkün olabilir
  • Üretkenlik artışının daha adil dağıtıldığı modeller de var. Eskiden Avrupa’da olduğu gibi çalışma saatlerinin azaltılması gibi. Bugün ise işçiler bile sürekli meşgul görünmelerini sağlayan, ne olduğu belirsiz angaryalara boğulmuş gibi
  • Aslında fiilen Marksist bir bakış açısı dile getiriyorsun ama ilginç şekilde sonuç kendine yabancılaşmaya çıkıyor. Biraz örgütlenilse iyileşme mümkün ama bu yapılmıyor
  • Sürekli durmadan kendini geliştirmek zorundaymışsın gibi kabullenmek yerine, toplumdaki diğer insanlarla güç birliği yapıp işverenden birlikte talepte bulunmanın yolları da var. Haftada 5 gün çalışma, 8 saatlik iş günü, çocuk işçiliğinin yasaklanması gibi kazanımlar kolektif eylemle elde edildi. Sadece kendi işine odaklanıp başkalarının başarılı olmasını izlemek zorunda değilsin
• Sektörümüzün çocukça bir hale gelişine hep şaşırıyorum. Büyük şirket ve büyük kod tabanı deneyimi olan herkes, yeni kod üretmenin geliştirmenin sadece küçük bir parçası olduğunu bilir
  • Gerçekte yeni kod dışındaki diğer işler, yani yan süreçler de büyük şirketlerde verimsiz. AI bunları da değiştirip bitmek bilmeyen toplantıları ve soyut tartışmaları azaltabilir
  • Şu an heyecan duyanların önemli bir kısmı aslında modern paradigmaların yükü yüzünden kod yazmakta zaten zorlanan insanlar. Copilot gibi LLM araçlarıyla hızla POC üretip production’a taşıyorlar ama kaliteyi, ölçeklenebilirliği vb. derinlemesine düşünmüyorlar. Sonra da bu kişiler, AI benimsenmesinin üretkenlik kazançlarını sorgusuz sualsiz pazarlayıp büyük şirketlerin çıkarıyla uyumlu söylemleri tekrar ediyor. Oysa bunu gerçekten kullanan herkes pratikte eksiklerinin de çok olduğunu biliyor
  • Ben de zamanımın yalnızca yaklaşık %20’sini kod yazarak geçiriyorum; geri kalanı gereksinim toplama, tasarım, test ve takvim yönetimiyle geçiyor. O %20’lik kod işi yarıya inse, kalan zamanda daha fazla test ya da dokümantasyon yapabilirim
• LLM yardımıyla geliştirme verimliliğinin muazzam artacağına dair bir yanılgı var. Aslında kalite kaybı olmadan üretkenlik artışı ancak temel beceriler zaten varsa mümkün. Yani uzmanlar için üretkenlik çarpanı olabilir ama sadece sayıyı artırılmış acemi gruplara LLM verirsen kaliteli yazılım çıkarmak zor
  • Bu argüman sürekli tekrarlanıyor ama asıl mesele “kalite” eşiğinin nerede olduğu. Örneğin genç bir geliştirme çalışma grubunda bir SRE arkadaş haftalık review yaparken LLM’i yoğun kullanıyor; kod kalitesi ve ölçeklenebilirlik de gayet yeterli. Hızları düşük ama ortaya çıkan şey kötü değil
  • “İyi” yazılım gerektiren yerler aslında azınlıkta; Deloitte ve Accenture gibi şirketlerin gelir yapısına bakılırsa çoğu işletme kaliteyi umursamıyor bile. Çoğunluk için “yeterince makul görünen” yazılım fazlasıyla yeterli