Di Amazon, Sebagian Pengembang Mengatakan Pekerjaan Mereka Mulai Menyerupai Kerja Gudang

• Para pengembang Amazon mengalami tekanan untuk bekerja lebih cepat dan penyederhanaan tugas setelah adopsi AI
• Para manajer sangat mendorong penggunaan alat AI dengan alasan peningkatan produktivitas
• Sebagian melihat berkurangnya pekerjaan berulang sebagai peningkatan kualitas kerja, tetapi ada kekhawatiran pengembang junior kehilangan peluang untuk berkembang
• Saat coding bergeser dari penciptaan langsung menjadi pekerjaan yang berpusat pada peninjauan dan verifikasi, sebagian orang merasa pekerjaan itu bukan lagi miliknya
• Kelompok internal seperti Amazon Employees for Climate Justice turut membagikan kecemasan tentang stres kerja dan prospek masa depan, termasuk isu ini

---

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

Bahkan coding pun memasuki era ‘kejar-kejaran kecepatan’

• Fenomena penyederhanaan pekerjaan akibat mekanisasi yang berulang kali muncul sejak Revolusi Industri kini juga terjadi di bidang coding
• AI bukan menghilangkan pekerjaan, melainkan mengubah pekerjaan yang ada menjadi bentuk yang lebih sederhana dan lebih cepat dikerjakan
• Menurut riset Microsoft, produktivitas pengembang yang menggunakan asisten AI ‘Copilot’ meningkat lebih dari 25%
• Amazon menerima hal ini dan menuntut pekerjaan yang lebih cepat dan efisien dengan AI, serta menekankannya dalam surat kepada pemegang saham sebagai kunci penghematan biaya dan menjaga daya saing
• Sebagai contoh, satu tim pengembang beroperasi dengan ukuran setengah dari tahun lalu tetapi tetap diminta menghasilkan jumlah kode yang sama

Arus di seluruh perusahaan

• Shopify menyatakan bahwa penggunaan AI adalah persyaratan dasar bagi semua karyawan, dan juga tercermin dalam evaluasi kinerja
• Google menjadikan pengembangan alat AI untuk meningkatkan produktivitas sehari-hari sebagai tema hackathon internal. Saat ini lebih dari 30% kode sudah dihasilkan melalui saran AI

Sisi positif dan kekhawatiran

• Sejumlah manajer berpendapat bahwa dengan adopsi AI, pekerjaan membosankan dan berulang berkurang sehingga orang bisa fokus pada tugas yang lebih kreatif
• Amazon menyebut AI telah menghemat pekerjaan pengembangan setara 4.500 tahun
• Namun, ekonom Harvard Lawrence Katz menyoroti bahwa bagi pengembang pemula, peluang pertumbuhan dalam pekerjaan justru bisa hilang
• Mirip dengan ‘kejar-kejaran kecepatan’ yang dulu dialami pekerja pabrik, para pengembang kini juga ditekan untuk bekerja lebih cepat dan menangani volume yang lebih besar

Perubahan yang dirasakan pengembang

• Seperti di gudang logistik Amazon, para pengembang juga merasakan otomatisasi pekerjaan dan pembagian kerja akibat AI
• Penggunaan AI memang ‘pilihan’, tetapi dalam praktiknya menjadi nyaris wajib untuk memenuhi target kinerja
• Pengembangan fitur yang dulu memakan waktu beberapa minggu kini harus selesai dalam hitungan hari, dan untuk itu waktu rapat dikurangi serta penggunaan kode AI diperluas
• AI bahkan dapat menghasilkan seluruh program, tetapi pekerjaan membaca dan meninjau kode meningkat, sementara kesenangan dan tingkat keterlibatan menurun

Pertumbuhan karier dan penurunan keterlibatan

• Pengembang junior dapat kehilangan kesempatan untuk memahami kode secara mendalam akibat otomatisasi pengujian
• AI mendukung berbagai pekerjaan seperti penulisan dokumen perencanaan dan pengujian kode, tetapi lingkungan evaluasi kini bergeser menjadi berpusat pada alat, bukan manusia
• Harper Reed, mantan CTO kampanye Obama, menilai ini sebagai era di mana tidak perlu lagi memahami setiap bagian secara mendalam, dan menjelaskan bahwa ini adalah perubahan yang mirip dengan manufaktur
• Sebaliknya, Simon Willison menilai AI secara positif karena mempercepat realisasi ide

Keluhan dan respons organisasional

• Karena penggunaan AI dan perubahan pekerjaan yang menyertainya, banyak pengembang membagikan kecemasan dan stres di kelompok Amazon Employees for Climate Justice
• Kekhawatiran terbesar terutama terkait penurunan kualitas pekerjaan dan ketidakpastian karier, yang mirip dengan stres akibat kejar-kejaran kecepatan yang dulu dirasakan pekerja otomotif
• Belum ada gerakan pembentukan serikat pengembang, tetapi kesadaran bersama di dalam organisasi terus meluas

Konteks historis dan prospek masa depan

• Seperti pada pemogokan GM tahun 1936, persoalan kecepatan kerja dan otonomi dapat menjadi pemicu tindakan kolektif pekerja
• Di masa lalu, individu masih bisa mengatur cara dan kecepatan kerja mereka, tetapi sekarang sistem telah berubah menjadi proses yang dipantau dari ujung ke ujung dan dinilai berdasarkan kecepatan

[GN⁺]

Komentar Hacker News

• Membagikan tautan archive.ph/HVZRL
• Bagi saya, pengembangan berbasis LLM terasa seperti hype yang dibesar-besarkan, mirip kripto atau VR. Setelah baru-baru ini harus memperbaiki bug di codebase yang ditulis dengan vibe coding, saya merasa pendekatan ini hanyalah segumpal kekacauan di mana masalah bisnis yang tidak tertata dipindahkan ke dalam kode tanpa struktur. Bagian yang perlu diperbaiki ditambal dengan patch sempit, sehingga hasil akhirnya adalah kode yang kompleks dan tidak terorganisir. Saat terbentur batas context window, LLM bahkan tidak bisa mengingat patch buatannya sendiri. Bahasa Inggris (atau bahasa manusia) terlalu ambigu untuk menjelaskan dengan tepat kode yang saya inginkan, dan menuangkan seluruh kumpulan pengalaman serta trial-and-error yang telah ditanamkan developer senior ke dalam prompt adalah pekerjaan yang sangat berat. Ada perbedaan besar antara menjelaskan "mengapa ditulis seperti ini" dan membutuhkan daftar yang sangat spesifik dan nyaris tak ada habisnya seperti "dalam situasi seperti ini jangan lakukan ini, lakukan itu"
  • Ini sangat cocok dengan deskripsi hampir semua codebase (kecuali satu) yang saya lihat selama 30 tahun terakhir
  • Sanggahan—AI juga pernah membantu saya menemukan pola kode di sekitar 30 tempat yang perlu dianalisis untuk mengekstrak struktur. Menurut saya, masalah vibe coding adalah soal sikap. Orang yang ingin menghindari coding sendiri cenderung hanya fokus pada kenyamanan saat ini, bukan struktur atau kualitas jangka panjang; semacam penguat kemalasan
  • Kenyataannya, banyak kode produksi hanyalah kumpulan potongan snippet yang terus ditambal agar tetap berjalan. Secara realistis, CPU sekarang terlalu cepat sehingga kode seperti ini pun tetap bisa jalan, dan itu cukup menyedihkan
  • Saya setuju bahwa bahasa manusia tidak jelas. Upaya untuk mengendalikan software secara jelas lewat bahasa alami sudah berulang kali dicoba, dan seperti hukum, wilayah abu-abu dalam penafsiran tidak pernah hilang. Jika di masa depan para developer harus berdebat soal makna program sebelum kompilasi, masa depan itu suram
  • Memang benar AI terlihat sama overhyped-nya dengan kripto atau VR. Namun, bahkan pekerjaan yang sangat teknis seperti software engineer pada akhirnya akan terdampak otomatisasi. Selama 10 tahun terakhir, orang-orang di industri teknologi keliru mengira mereka tidak terkait dengan masalah para pekerja lain, tetapi budaya layoff kini mulai benar-benar menekan upah. Walau AI tidak langsung menggantikan semuanya, jika pekerjaan 5 orang menjadi bisa ditangani 4 orang dengan bantuan AI, maka 1 orang dipangkas, dan yang tersisa pun tak berani menuntut kenaikan gaji. Argumennya: pekerja teknologi juga pada akhirnya adalah buruh
• Tentang pendapat Harper Reed bahwa "tidak perlu memahami kode secara mendalam", pernyataan seperti ini justru terdengar seperti logika tambal sulam ala "asal bisa dikompilasi, ayo deploy". Di lini otomatisasi, kualitas diukur terus-menerus, tetapi mesin nyata tidak berhalusinasi soal sudut atau melakukan pengelasan yang ngawur; software berbasis LLM justru mengulang kesalahan kecil semacam ini
• Saya bertanya-tanya apakah tool berbasis LLM benar-benar secara dramatis meningkatkan produktivitas developer, atau hanya membuat organisasi sadar bahwa mereka bisa berjalan dengan jumlah developer yang lebih sedikit—dan kurang memiliki privilese dibanding sebelumnya. Saya juga belum banyak melihat contoh "lonjakan produktivitas inovatif" di perusahaan teknologi besar; sejauh ini yang ada hanya sedikit peningkatan produktivitas, sekadar cukup untuk menutupi investasi
  • Sebagian besar adalah soal persepsi. Dulu pengembangan software dianggap sulit, tetapi sejak muncul tool AI, orang melihat hambatan masuk ke coding jadi lebih rendah. Pengembangan software pun semakin terasa seperti kerja pabrik, dan kepuasan intelektualnya berkurang
  • Ada keraguan soal maintainability jangka panjang codebase. Vibe coding secara bertahap menumpuk kompleksitas, bug halus, dan masalah abstraksi, yang pada akhirnya membuat maintenance dan pengembangan fitur baru jadi lebih sulit. Ada risiko terjebak pada kenaikan produktivitas jangka pendek sambil menurunkan kualitas jangka panjang
  • Organisasi sejak lama memakai proses birokratis untuk "menyingkirkan teknologi", yaitu mengganti tenaga terampil dengan standarisasi dan tenaga yang lebih rendah keterampilannya. Ini bisa menjadi strategi beracun dalam jangka panjang, tetapi selama konsisten, mereka puas dengan "solusi biasa-biasa saja yang cukup bisa dipakai"
  • Agar logika ini meyakinkan, kita harus mengasumsikan bahwa manajemen Amazon lebih mementingkan keuntungan jangka pendek daripada kualitas jangka panjang, tetapi saya tidak yakin soal itu
• Dari sudut pandang orang yang akan segera pensiun, perubahan belakangan ini terasa mengecewakan. Saat memulai karier di tahun 90-an, masih ada ruang untuk tenggelam lama dalam eksperimen dan kreativitas. Sekarang unit kerja kecil, laporan status, dan justifikasi terus-menerus menjadi keharusan. Ke depan tetap akan ada developer yang menarik, tetapi peluang seperti itu makin berkurang. Sebenarnya ini hanyalah jalan yang sama seperti profesi lain yang hidupnya dipersulit otomatisasi, jadi hasilnya terasa adil
  • Laporan status harian seperti stand-up itu memakan waktu, dan pada akhirnya hanya respons formal agar saya bisa bebas satu hari lagi dari orang-orang yang tidak memahami pekerjaan saya; hal semacam ini menurunkan nilai kerja itu sendiri
  • Saya juga masuk industri sejak tahun 90-an dan paham soal kontrol detail berbasis JIRA. Tapi saya juga tidak menganggap masa lalu otomatis merupakan zaman keemasan. Mungkin ada efek nostalgia yang membuat kita hanya mengingat pengalaman bagus. Meski begitu, sekarang pun masih ada pekerjaan yang cukup menantang dan banyak hal untuk dipelajari
  • Daripada otomasi pekerjaan engineer, arahnya justru menggantikan pekerjaan manajerial dengan pengawasan berbasis AI
• Untuk secara drastis mempercepat pengembangan software, ada juga cara memakai langsung kode open source milik orang lain lalu menghapus jejak hak cipta/lisensinya. Kalau khawatir ketahuan, bisa pakai vendor outsourcing untuk "mencuci" kode itu, atau sekarang malah bisa dicuci cepat dan murah dengan AI. Dulu Google menahan diri melakukan hal semacam ini dan kurang berani. Tetapi startup kecil mengejar keberhasilan cepat dengan memakai AI sambil mengabaikan risiko pelanggaran hak cipta
  • Di industri saya, masalah yang lebih besar justru bukan ketiadaan kode, melainkan mendefinisikan "apa yang harus dibuat dan bagaimana cara membuatnya". Banyak masalah unik yang tidak bisa diselesaikan dengan Stackoverflow atau GitHub
  • Sebenarnya Google sejak dulu juga mengambil konten situs lalu menampilkannya langsung di hasil pencarian, memanfaatkan konten orang lain tanpa memberi trafik. Kali ini mereka hanya terlambat
  • Ironisnya, ada juga yang berpendapat bahwa mereka justru berharap perusahaan besar menyalin kode open source. Sebab lebih baik itu daripada dipaksa memakai cara yang dingin dan tidak efisien yang mereka buat sendiri
  • Saya setuju soal keterbatasan mengunggah kode ke open source. Perusahaan besar cenderung mendorong open source sebagai sarana mendapatkan tenaga kerja gratis. Meski kontribusi bisa berkurang dalam jangka pendek, saya pikir industri justru akan lebih sehat dalam jangka panjang
  • Kritik terhadap kemunculan ChatGPT dan sikap tidak bertanggung jawab dalam kepemimpinan Sam Altman
• Pernyataan Simon Willison bahwa membaca kode lebih sulit dan kurang menyenangkan daripada menulisnya, serta contoh developer Amazon yang mengatakan AI banyak membantu tugas-tugas pendukung seperti dokumentasi dan testing, terasa menarik. Kini peran developer bergeser dari coding menjadi lebih berfokus pada review kode yang sudah ada dan perbaikan bug
  • Saya teringat masa lalu saat menulis kode itu menyenangkan. Sekarang memperbaiki bug justru lebih menarik, dan LLM mengambil alih coding repetitif yang sederhana sehingga saya bisa fokus pada tantangan. Berkat LLM, sebagian kesenangan dalam pengembangan masih tersisa
  • Suasana yang terasa dari tulisan ini cukup negatif
• Saat muncul teknologi baru yang meningkatkan produktivitas, perusahaan akan cepat mengambil manfaatnya lalu menstandarkannya. Untuk terus mengejar, kita harus terus belajar, dan pada titik tertentu perlu mempertimbangkan pindah ke lingkungan di mana kita sendiri yang mengambil manfaat pertumbuhan itu, misalnya bekerja mandiri. Tetapi bekerja sendiri berarti harus bersaing dengan orang-orang yang mahir memakai AI, jadi tidak ada solusi mudah
  • Ada tiga skenario masa depan. 1) Codebase makin runtuh ke dalam kekacauan dan ketidakstabilan, lalu pada akhirnya developer berpengalaman harus dimasukkan kembali dengan biaya mahal. 2) AI menghasilkan kode yang cukup bisa dipakai, dengan kualitas dan keandalan rendah tetapi tanpa bencana besar. 3) AI tiba-tiba menjadi sangat pintar hingga konsep codebase itu sendiri hilang, dan software dibuat serta berevolusi secara dinamis saat dibutuhkan. LLM saat ini masih sangat jauh dari itu. Para eksekutif perusahaan percaya pada skenario 3, tetapi untuk saat ini yang realistis adalah 1 atau 2. Jika dikelola dengan baik, peralihan ke pandangan seimbang ala skenario 2 juga mungkin
  • Ada juga model di mana peningkatan produktivitas dibagi lebih adil, seperti pengurangan jam kerja ala Eropa dulu. Sekarang bahkan para pekerja pun tampak sibuk dengan pekerjaan aneh yang tak jelas hanya demi terlihat sibuk
  • Kamu pada dasarnya sedang menyampaikan sudut pandang Marxis, dan lucunya kesimpulannya justru berujung pada alienasi diri. Padahal dengan sedikit kerja sama, perbaikan itu mungkin saja terjadi
  • Jangan terima begitu saja bahwa kita harus terus hidup dalam mode pengembangan diri tanpa henti; ada juga cara untuk bergabung dengan anggota masyarakat lain dan bersama-sama menuntut pada pemberi kerja. Pekan kerja 5 hari, kerja 8 jam, dan pelarangan pekerja anak semua didapat lewat aksi kolektif. Tidak perlu hanya fokus bekerja keras sendiri dan melihat orang lain sukses
• Saya selalu terkejut melihat betapa kekanak-kanakannya industri kita berubah. Siapa pun yang pernah bekerja di perusahaan besar dengan codebase besar tahu bahwa pembuatan kode baru hanyalah bagian kecil dari pengembangan
  • Sebenarnya pekerjaan di luar penulisan kode baru—yaitu bagian-bagian tambahan lainnya—juga tidak efisien di perusahaan besar. AI mungkin juga bisa mengubah ini dan mengurangi rapat tanpa henti atau diskusi abstrak
  • Banyak orang yang sekarang begitu bersemangat sebenarnya adalah mereka yang kesulitan menulis kode karena terikat paradigma terbaru. Dengan tool LLM seperti Copilot, mereka cepat membuat POC lalu mendorongnya ke produksi tanpa benar-benar memikirkan kualitas, skalabilitas, dan semacamnya secara mendalam. Lalu mereka tanpa syarat mengiklankan kisah produktivitas dari adopsi AI, hanya mengulang argumen yang sejalan dengan keuntungan perusahaan besar. Padahal orang yang benar-benar memakainya dalam praktik tahu bahwa masih banyak kekurangannya
  • Saya sendiri hanya menghabiskan sekitar 20% waktu untuk coding, sisanya untuk menggali requirement, desain, testing, dan pengelolaan jadwal. Kalau 20% pekerjaan coding itu bisa dipangkas setengah, mungkin waktu yang tersisa bisa saya pakai untuk lebih banyak testing atau dokumentasi
• Ada ilusi bahwa bantuan LLM akan sangat meningkatkan efisiensi pengembangan. Faktanya, peningkatan produktivitas tanpa kehilangan kualitas hanya mungkin jika kemampuan dasar sudah ada. Artinya, bagi orang terampil ini adalah pengganda produktivitas, tetapi jika LLM diberikan ke pasukan pemula dalam jumlah besar, sulit menghasilkan software berkualitas
  • Klaim seperti ini sering diulang, tetapi yang penting adalah di mana batas minimum "kualitas" itu. Dalam praktiknya, tim studi developer muda yang saya kenal aktif memakai LLM sambil direview mingguan oleh teman SRE, dan kualitas maupun skalabilitas kodenya cukup baik. Memang lebih lambat, tetapi hasil akhirnya tidak buruk
  • Tempat yang benar-benar membutuhkan software "bagus" itu hanya sebagian kecil; kalau melihat model pendapatan perusahaan seperti Deloitte atau Accenture, kebanyakan perusahaan bahkan tidak terlalu peduli pada kualitas. Bagi mayoritas, software yang "terlihat meyakinkan" saja sudah cukup