Krisis Identitas Programmer

• Identitas programmer belakangan ini sedang terancam oleh kemunculan AI dan alat LLM
• Budaya pemrograman berawal dari etika hacker MIT pada 1950-an, yang memandang aktivitas menulis kode itu sendiri sebagai sebuah craft yang mendalam, dengan logika presisi dan keterlibatan penuh dalam pemecahan masalah sebagai nilai utamanya
• Namun kini industri AI dan alat LLM berusaha mengubah developer menjadi sekadar penulis spesifikasi atau operator, memaksa pendekatan "vibe-coding" di mana alih-alih menulis kode langsung, mereka hanya memberi instruksi dalam bahasa alami
• Kode yang dihasilkan LLM nondeterministik dan tidak akurat, serta menghilangkan pemahaman mendalam dan keterlibatan penuh yang diperoleh developer saat membaca dan menulis kode sendiri, sehingga memutus hubungan dengan codebase
• Perusahaan, dengan dalih meningkatkan produktivitas, memaksakan penggunaan alat, dan menggantikan budaya kolaborasi serta mentoring dalam tim dengan interaksi bersama AI, sehingga melemahkan koneksi antarmanusia di antara para developer
• Nilai esensial yang memandang pemrograman bukan sekadar hasil akhir, melainkan proses berpikir dan memahami, sedang hilang, dan developer perlu melawan perubahan ini demi menjaga keterampilan, kesenangan, dan identitas profesional mereka

---

Hakikat dan tradisi programmer

• Menulis kode bukan sekadar pekerjaan, melainkan identitas developer itu sendiri, dan editor adalah bengkel sekaligus ruang sakral tempat keterampilan diasah dan kondisi flow dicapai

  • Dengan alat seperti Vim, developer bekerja tanpa hambatan antara pikiran dan kode, menciptakan dunia tak berwujud yang berdampak pada dunia nyata
  • Proses memecahkan puzzle itu sendiri lebih penting daripada gambar yang sudah selesai, dan dalam aliran keterampilan dari jari ke buffer, waktu seakan menghilang

• Pada akhir 1950-an di MIT, lahir budaya pemrograman baru, ketika para hacker yang eksperimental dan anti-establishment menggunakan Flexowriter dan komputer TX-0 sambil mengejar program yang sempurna

  • Mereka menjadikan konsep "The Right Thing" sebagai pusat, dengan tujuan menulis kode yang elegan dan ringkas
  • Anggota Tech Model Railroad Club tenggelam dalam bahasa mesin, mempelajari sihir digital, dan membangun budaya berbagi pengetahuan yang mereka temukan dengan mahasiswa lain

• Keterampilan coding ditempa di dalam kawah komputasi Building 26, dan budaya yang dibentuk sekitar 70 tahun lalu itu terus berlanjut hingga kini, masih hidup dalam benak developer dan mesin mereka

  • Warisan para hacker awal tetap menjadi keterampilan yang dalam dan nyaris bersifat fisik, dan di atas fondasi itulah industri yang penuh gairah dibangun
  • Developer masih termotivasi oleh rasa takjub, pencapaian, dan keanggunan dalam memecahkan puzzle yang sama

• Namun nilai-nilai inti yang membentuk identitas programmer ini kini terancam, dan masa depan pemrograman yang dulu tampak terang dan jelas kini tertutup oleh kegelapan, penipuan, dan ketidakpastian yang mengkhawatirkan

Pemaksaan identitas baru oleh industri AI

• Industri AI bernilai miliaran dolar, komunitas Hacker News, dan para pendukung LLM di LinkedIn mengklaim bahwa masa depan pengembangan software hampir tidak lagi menyerupai pemrograman, dan "vibe-coding" yang setahun lalu tampak seperti meme kini menjadi arus utama

  • Developer diminta menulis spesifikasi dalam Markdown alih-alih kode, sementara keterlibatan mendalam dan kedalaman keterampilan yang lahir dari menjelajahi setiap sudut codebase, memecahkan puzzle, dan menemukan rahasia-rahasianya pun menghilang
  • Sebagai gantinya, developer diminta menerima perhatian yang terpecah dan context switching sementara agent berpikir untuk mereka, kreativitas pemecahan masalah diserahkan pada mesin, dan developer berubah menjadi sekadar operator

• Sebagian developer menyambut perubahan ini dan identitas baru bernama "Specification Engineering", merasa antusias menjadi operator yang, seperti Steve Jobs, "memimpin orkestra"

  • Sulit dipahami mengapa mereka memilih menjadi programmer jika tampaknya memang tidak tertarik pada coding; barangkali mereka mencampuradukkan Woz dengan Jobs
  • Prompt, Context, dan Specification "Engineering" tampaknya tidak akan membawa karier yang cerah dan makmur bagi programmer

• Ini berarti penurunan nilai keterampilan, kemahiran, dan kerja, karena kemampuan berpikir abstrak khas developer dipindahkan ke ranah yang tak lagi membutuhkannya, masuk ke wilayah yang sudah ditempati product manager dan desainer

Perubahan dinamika kekuasaan di perusahaan

• Ketika identitas baru ini dipaksakan di perusahaan, dinamika kekuasaan berubah, dan dalam upaya obsesif untuk meningkatkan produktivitas di tempat yang keliru, developer makin dipaksa menggunakan LLM dengan cara-cara yang sangat spesifik

  • Jika tidak patuh, mereka akan tersingkir, dan harus memilih antara memakai produk yang mengumumkan ketidakbergunaan dirinya sendiri atau mengundurkan diri
  • Dulu, hampir tidak pernah manajemen memberi instruksi sedetail ini tentang alat yang harus dipakai developer

• Seperti koki atau tukang kayu, developer selalu sangat bangga dalam mengkurasi dan mengasah alat mereka sendiri, mempersonalisasi alat agar sesuai dengan cara berpikir mereka lewat pengaturan editor yang teliti, penyesuaian dotfile, dan konfigurasi environment pengembangan

  • Mereka telah mendedikasikan diri untuk mempersonalisasi toolset sebagai bagian dari keterampilan mereka, sehingga ketika hal itu diperintahkan oleh manajemen yang nyaris tak terhubung dengan pekerjaan sehari-hari, rasanya seperti pelanggaran
  • Bagi programmer yang selama puluhan tahun menikmati posisi istimewa di perusahaan, narasi ini memberi manajemen cara baru untuk kembali memiringkan keseimbangan demi keuntungan mereka sendiri

Perbedaan mendasar antara LLM dan bahasa pemrograman

• Ada yang membandingkan dampak LLM dengan peralihan dari bahasa tingkat rendah ke bahasa tingkat tinggi (dari Assembly ke Fortran), tetapi analogi ini keliru dalam banyak hal

  • Fortran berakar pada pemrograman dan tidak berupaya menghapus keterampilan, melainkan membangunnya; ia memperluas pemrograman tanpa menghilangkan presisi dan daya ekspresinya
  • Fortran juga secara konsisten berhasil menghasilkan keluaran yang benar untuk input yang diberikan, sedangkan di dunia LLM tak satu pun dari hal itu berlaku

• Komputer dan pemrograman memang bisa sangat membuat frustrasi, tetapi setidaknya kita selalu bisa mempercayai presisi; melalui pemrograman, komputer melakukan persis seperti yang diperintahkan

  • Justru karena ketergantungan dan kepercayaan pada presisi komputer inilah, kita mudah percaya saat chatbot menggaslight kita seolah-olah tugas yang diminta sudah benar-benar dikerjakan

• LLM dan cara kerjanya secara mendasar tidak akurat, baik karena sifat model bahasa besar itu sendiri maupun karena instruksi dalam bahasa alami memang membuka ruang tafsir

  • Menarik bahwa programmer yang biasanya membenci nondeterminisme justru memilih pendekatan ini, padahal mereka umumnya menyukai prediktabilitas, komposabilitas, idempotensi, dan integration test yang stabil
  • Kode LLM justru mewakili kebalikannya: kekacauan yang tidak konsisten

• Dalam "On the foolishness of natural language programming", Dijkstra menekankan bahwa asumsi bahwa bahasa alami akan menyederhanakan pekerjaan perlu dipertanyakan, dan bahwa keunggulan teks formal adalah ia hanya perlu memenuhi beberapa aturan sederhana agar sah

Hilangnya pemahaman mendalam dan keterlibatan penuh

• Memang ada upaya membedakan pengembangan berbantuan AI dari vibe-coding dengan menambahkan rigor dan birokrasi, tetapi itu mengabaikan hakikat dasarnya

  • Kode yang dihasilkan LLM cenderung tidak dibaca seteliti ketika kita menulisnya sendiri atau meninjaunya dalam sebuah PR, dan ada sesuatu yang secara inheren membuat coding dengan LLM terasa menumpulkan pandangan
  • Orang jadi hanya sekilas membaca, merasa kewalahan dan bosan, lalu begitu CI lolos dan program berhasil dikompilasi, jebakan berbahaya pun diterima begitu saja
  • Mereka tidak memeriksa apakah test benar-benar dikonfigurasi untuk berjalan, apakah library yang diimpor sebenarnya tidak ada, atau apakah seluruh library justru diimplementasikan ulang sendiri

• Review atau ringkasan buku tidak bisa menggantikan pengalaman membaca langsung; dibutuhkan proses menyerap setiap kalimat dengan saksama selama ratusan halaman sambil merenungkan gagasannya

  • Demikian pula, sekadar menelusuri ringkasan atas pekerjaan yang diselesaikan AI merampas kesempatan membangun pemahaman mendalam tentang domain, masalah, dan solusi yang mungkin, serta memutus hubungan dengan codebase
  • Menyelam ke jurang ketidaktahuan untuk menyingkap topik dan implikasinya, lalu belajar dan memahaminya, adalah sesuatu yang memuaskan dan esensial bagi software yang baik
  • Kepemilikan, agensi, dan pekerjaan yang dalam serta memuaskan digantikan oleh perhatian yang terpecah di antara tab-tab agent

• Joan Didion pernah berkata, "Saya menulis untuk mengetahui apa yang saya pikirkan, apa yang saya lihat, apa yang saya lihat itu, dan apa artinya," dan Peter Naur mengeksplorasi gagasan yang sama dalam "Programming as Theory Building"

  • "Theory" menurut Naur mewujudkan pemahaman atas codebase, termasuk cara kerjanya, formalismenya, dan representasinya terhadap dunia nyata
  • Konteks dan insight seperti itu hanya bisa diperoleh lewat keterlibatan penuh, dan Naur menggambarkan "Theory" sebagai hasil utama pemrograman sekaligus produk sesungguhnya, lebih penting daripada softwarenya sendiri
  • Hanya dengan "Theory" yang berkembang baik, perluasan dan perbaikan bug dapat diterapkan secara efektif pada codebase

• Desain yang baik lahir dari keterlibatan penuh, muncul lewat bolak-balik bekerja di text buffer dan sering kali juga saat sedang jauh dari keyboard

  • Karena seluruh codebase tak mungkin ditampung sepenuhnya dalam pikiran, kita harus menyelam ke modul, kelas, dan fungsi untuk mempertajam model mental yang masih kabur
  • Kita perlu membaca dan menulis kode untuk memperluas kognisi, memulihkan keakraban, dan memahami domain masalah

• Setelah sebagian konteks terbentuk dan melalui banyak percobaan yang gagal, barulah solusi bisa ditemukan, dan kita perlu merasakan disonansi dari desain yang buruk

  • Hanya ketika menulis kode yang menjijikkan dan berulang-ulanglah kita sadar bahwa ada cara yang lebih baik, lebih ringkas, lebih elegan, lebih komposabel, dan lebih dapat digunakan kembali
  • Itu membuat kita berhenti untuk memikirkan masalah secara mendalam, mundur selangkah, dan memulai kembali dari awal
  • Sebaliknya, pekerjaan dengan agent AI nyaris tanpa friksi, sehingga solusi alternatif cenderung dihindari, dan kita bahkan tak tahu apakah yang diterima itu sempurna, biasa-biasa saja, buruk, atau bahkan berbahaya

Runtuhnya kolaborasi tim dan koneksi antarmanusia

• Utang kognitif dari coding yang berpusat pada LLM melampaui sekadar hilangnya keterampilan; para "slop-jockey" dengan rentang perhatian pendek melemparkan hasil kerja mereka ke pull request dan dokumen desain, menghambat kolaborasi dan mengganggu tim

  • Rekan yang melakukan code review mulai kehilangan kewarasan saat menyadari dengan ngeri bahwa mereka bukan lagi lapisan kontrol kualitas terakhir, melainkan lapisan pertama
  • Mereka harus menunjukkan fungsi yang baru ditambahkan tetapi tidak pernah dipanggil, penambahan library halusinatif, atau error runtime maupun compile yang jelas
  • Penulis yang jelas hanya sekilas melihat kodenya sendiri tidak memikul tanggung jawab, lalu berkata, "Claude yang menulis begitu. AI bodoh, haha"

• Manajer yang terlalu ikut campur dan eksekutif yang ingin menghemat uang mendorong tim untuk mengurangi interaksi antarmanusia (mudah-mudahan tanpa sepenuhnya sadar)

  • Dalam keadaan terisolasi dan tercerabut dari koneksi, orang kini diberi kuasa dan didorong untuk membangun tembok di sekeliling pengalaman kerja mereka
  • Saat membutuhkan pair programmer, berdiskusi sambil saling melempar solusi, membuat prototipe, menggambar arsitektur, atau meminta jawaban dari ahli tentang bagian codebase yang sulit dipahami, mereka bergantung pada LLM alih-alih manusia
  • Tak lagi memerlukan onboarding buddy, mentor, atau rekan kerja; sebagai gantinya, mereka bisa berbicara dengan mesin
  • Menghindari kontak manusia dengan LLM menjadi terlalu mudah, sehingga hal ini bisa berubah menjadi standar

Membela identitas programmer

• Mengejutkan melihat betapa patuhnya kita pada narasi hype AI, betapa aktifnya kita ikut serta dalam penghapusan keterampilan yang direncanakan, dan betapa sukarelanya kita menyerahkan sarana berpikir kita sendiri

  • Kita seharusnya termasuk orang-orang beruntung yang bisa mencari nafkah dari hobi, tetapi bahkan jika kita membangun proses yang ketat dan teliti untuk menghadapi slop, kita tetap telah mengalihdayakan bagian pekerjaan yang menyenangkan dan menggantinya dengan kerja mengarahkan yang melelahkan

• LLM tampak seperti solusi melempar bom nuklir dari orbit ke kompleksitas software, meraih sesuatu yang jauh lebih rumit dan kabur untuk mengobati gejala alih-alih menyelesaikan masalah yang sebenarnya

  • Mengganti sed dengan Claude, atau meminta jawaban tentang library atau framework yang tak kunjung jelas bahkan setelah berjam-jam menelusuri dokumentasinya, itu tidak masalah
  • Namun saya tidak ingin sekadar menjadi operator atau reviewer kode, mengambil kursi belakang dari pekerjaan yang menyenangkan dan menarik

• Saya lebih menyukai alat yang membantu tugas-tugas berulang, membantu memahami codebase, dan membantu menulis program yang benar, tetapi merasa muak pada produk yang dirancang untuk berpikir menggantikan saya

  • Saya menolak produk yang menghapus agensi saya dalam memahami software yang saya hasilkan dan memutus hubungan saya dengan rekan kerja
  • Bahkan jika LLM memenuhi hype, kita tetap akan kehilangan semua ini beserta keterampilan kita
  • Manusia lebih penting daripada mesin dan perusahaan yang mendukungnya, sementara mereka meraup keuntungan ketika kita yang lain mengejar American Dream baru yang mereka jual
  • Sebagai gantinya, kita menyerahkan kemampuan berpikir kritis, kesenangan, keterampilan, privasi, dan mungkin juga bumi

[command2alt]

Secara umum saya setuju
Terutama soal context switching? Meminta prompt lalu menunggu, dan selama waktu tunggu itu fokus jadi buyar sehingga produktivitas menurun. Mungkin ini bisa teratasi jika kecepatan llm meningkat dan respons datang seketika

[serithemage]

Tulisan itu sendiri terasa sangat seperti sudah menetapkan kesimpulannya terlebih dahulu lalu menulis sesuai arah tersebut. Masalah hilangnya ownership dari pengembang, terlepas dari LLM, terbaca sebagai pembahasan tentang "era semangat keartisan vs era industrialisasi".

[GN⁺]

Pendapat Hacker News

• Hal yang paling berkesan bagi saya adalah melihat para peninjau kode makin kehilangan kewarasan saat menyadari bahwa mereka kini bukan lagi tahap akhir pengendalian mutu, melainkan garis pertahanan pertama. Permintaan review masuk, tetapi sekarang mereka harus satu per satu menangkap fungsi baru yang tidak pernah dipanggil, library yang tiba-tiba ditambahkan, error runtime atau kompilasi yang jelas, dan sebagainya. Penulis kode pun menghindari tanggung jawab dengan berkata seperti, “Itu ditulis Claude, AI-nya yang salah, haha.” Sejak adopsi LLM, Hukum Brandolini (energi untuk membantah omong kosong jauh lebih besar daripada energi untuk membuatnya) terasa makin nyata. Ketika developer yang kurang berpengalaman atau kurang terampil bisa memuntahkan ribuan baris kode dalam beberapa menit, tanggung jawab untuk benar-benar menjamin kesehatan sistem akhirnya dialihkan ke para reviewer kode. Jika melihat added/removed LoC delta pada PR, PR yang ditulis LLM hampir selalu hanya terus menambah, sementara engineer senior yang berpengalaman sering kali menghapus kode lama sebanyak mereka menambah kode baru

  • Menurut saya ini bukan masalah teknis, melainkan masalah manusia. Sekali kejadian seperti ini terjadi, harus diberi peringatan keras, dan jika terulang dua kali, harus ditolak dan dieskalasikan ke manajer. Siapa pun yang menulis PR, pada akhirnya dia tetap menaruh namanya pada hasil itu, jadi kalau kodenya berantakan, tanggung jawabnya juga harus ditanggung olehnya

  • Saya sekarang sudah tidak lagi melakukan code review di tim besar, tetapi kalau saya ada di situasi seperti itu, penghindaran tanggung jawab seperti ini mungkin bisa saya toleransi sekali. Kalau berulang, saya akan berusaha mengeluarkan orang itu. Kalau tidak memungkinkan, saya sendiri yang akan keluar. Sekacau itu lingkungannya

  • Saya rasa ini juga terkait dengan perasaan saya belakangan bahwa produktivitas saya menurun. Ada tekanan untuk menghasilkan lebih banyak kode lebih cepat, dan kalau memakai hal seperti agent, saya jadi tidak benar-benar memahami keseluruhan konteks kode yang saya hasilkan. Saya hanya bisa menjamin kualitas dalam batas yang masih bisa saya review teliti baris demi baris, dan di situlah batasannya. Karena itu belakangan saya memakai AI lebih lambat dan lebih konservatif, serta menambah porsi menulis kode dengan tangan sendiri. Untuk hal seperti menerapkan definisi tipe atau spesifikasi yang jelas secara berulang ke banyak properti, AI lumayan membantu, tetapi bahkan dalam situasi seperti itu pun hasilnya tidak selalu meyakinkan

  • Semakin senior seorang engineer, semakin sering dia memangkas kode lama sebanyak dia menambahkan kode baru. Tulisan Negative 2,000 Lines Of Code juga layak dibaca

  • Menurut saya, begitu LLM ikut campur, cara kita melihat kepada siapa tanggung jawab dialihkan menjadi masalah sosial yang lebih luas. Orang-orang mengklaim hasil bagus sebagai prestasi mereka sendiri, tetapi kalau jelek, dengan mudah menyalahkan AI. Saya rasa budaya ini akan banyak berubah begitu ada beberapa gugatan hukum yang tepat sasaran

• Sudah lama saya merasa orang-orang yang masuk ke industri ini memandang kode bukan sebagai kerajinan yang ditekuni, melainkan sebagai cara mudah menghasilkan uang. Sejak saya membaca tulisan tentang developer infrastruktur open source yang sulit menyambung hidup, lalu melihat developer yang coding di kafe, bootcamp dan gerakan “cukup belajar coding”, para penggiling Leetcode, sampai developer di San Francisco yang tinggal di mobil karena harga rumah mahal, sekarang isu terbarunya adalah orang mengotomatisasi dirinya sendiri dengan AI lalu kehilangan pekerjaan. Masalahnya adalah persepsi bahwa developer bukan profesional sungguhan. Standarnya longgar, tidak ada kode etik, tidak ada skillset yang konsisten, juga tidak ada representasi yang jelas. Bahkan para pelaku industrinya sendiri kurang punya daya tawar sampai terkesan memusuhi kepentingan mereka sendiri. Pengacara punya asosiasi pengacara, dokter punya organisasi profesi, tetapi developer hanya punya kecemasan eksistensial. Sekarang malah ada atasan yang mengancam dengan gaya, “Saya akan otomatisasi pekerjaanmu pakai AI.” Profesi lain tidak seantagonistis ini terhadap kepentingannya sendiri, jadi saya sendiri heran kenapa hanya industri ini yang begini

  • Saya rasa “coder” dan software engineer itu berbeda. Hanya karena seseorang lulus bootcamp dan bisa menulis program sederhana dengan Python bukan berarti dia software engineer. Saat saya bilang saya punya gelar, saya dibilang elitis, dan saya juga sering dengar bahwa yang diajarkan di ilmu komputer itu tidak berguna untuk kerja nyata. Padahal jelas ada juga orang yang tanpa gelar tetap tumbuh menjadi engineer hebat secara otodidak. Meski begitu, saya setuju bahwa kita tetap butuh standar dalam bentuk tertentu. Kalau ada lulusan bootcamp yang bergabung ke startup unicorn buzzword terbaru, ya selamat saja untuk dia, tetapi untuk sistem sensitif seperti Therac-25 (kasus kecelakaan), saya rasa lebih baik yang menangani adalah orang-orang dengan pelatihan formal

  • Atasan bilang, “Kalau kamu tidak mengotomatisasi, pekerjaanmu akan hilang”? Ya memang itulah pekerjaan kita. Mengotomatisasi tenaga kerja adalah inti dari pekerjaan kita, dan kita adalah profesi yang paling punya peluang dan pemahaman untuk mengotomatisasi tempat kerja kita sendiri

  • Saya pikir profesi guru juga mirip dengan developer. Ada guru hebat, ada guru buruk, dan banyak juga yang di tengah-tengah. Hanya karena tahu sebuah mata pelajaran bukan berarti pandai mengajarkannya. Mungkin developer bisa dilihat sebagai guru bagi mesin. Ada yang mengajarnya huruf demi huruf, pikiran demi pikiran, sampai karakter kartun merch, dan ada juga yang mengajarnya lewat nuansa umum secara keseluruhan

• Kalau LLM disisihkan sejenak, kadang saya memang menulis kode yang begitu rapi sampai saya sendiri bangga. Dari struktur sampai setiap barisnya, tidak ada keputusan yang tanpa alasan; pada saat itu saya adalah ahli atas kode tersebut dan benar-benar menguasainya. Tetapi sebagian besar kode tidak saya tulis sesempurna itu. Kebanyakan ditulis dengan pola pikir “yang penting tugasnya selesai”, dengan membiarkan standar pribadi saya sedikit turun. Meski begitu, sesekali ketika saya benar-benar tenggelam dan menuntaskan kode dengan baik, rasanya sangat memuaskan dan menjadi pengalaman terbaik saya dalam menulis kode. Kalau dipikir bersama LLM, justru sekarang menulis kode berkualitas tinggi menjadi lebih mudah sekaligus lebih sulit. Secara psikologis, kalau saya bisa masuk ke mode fokus mendalam, saya bisa memanfaatkan LLM dengan baik untuk menghasilkan hasil yang lebih cepat dan dengan standar lebih tinggi. Saya bisa menulis jauh lebih baik daripada kode buatan LLM, tetapi dengan bantuan LLM saya juga bisa menulis kode yang lebih unggul. Masalahnya, mempertahankan kondisi fokus ini makin sulit. Saya jadi cenderung sekadar melihat sekilas kode yang dibuat LLM, tampilannya bagus dan tampaknya berjalan benar, lalu saya biarkan lewat. Namun kode yang saya loloskan dengan asal begitu perlahan-lahan jadi makin berantakan, dan kalau terus dibiarkan dalam kondisi tumpul seperti itu, saat kita sadar semuanya sudah terlambat. Akhirnya kita sendiri gagal menjadi ahli atas kode tersebut, dan yang menumpuk hanyalah kode serampangan

  • Dalam dua bulan terakhir saya lebih banyak memakai AI dan melalui proses seperti ini:
    1. Awalnya saya hanya memakai AI untuk tugas kecil, lalu terkesan karena hasilnya sangat bagus
    2. Pelan-pelan saya memberinya tugas yang lebih besar sambil mencari cara memakainya dengan efisien
    3. Sampai akhirnya AI nyaris bekerja seperti agent, mengerjakan hampir semuanya sendiri, dan saya tinggal mereview kodenya di akhir
    4. Lalu saya sadar bahwa “pada akhirnya saya tetap harus memeriksa sendiri seluruh kode itu dengan teliti, dan ternyata AI bukan jalan pintas persis seperti yang saya harapkan” (misalnya, mustahil hanya melempar gambaran besar lalu mendapatkan kode akhir yang meyakinkan)
    5. Jadi sekarang saya kembali hanya menyuruh AI mengerjakan tugas-tugas kecil AI terasa berguna untuk riset, prototipe, POC, atau kode sekali pakai seperti “berjalan sih, tapi jelas tak akan pernah layak untuk produksi.” Untuk desain dasar atau struktur fundamental, saya pegang sendiri; untuk tugas kecil seperti implementasi fungsi atau mengisi detail logika, AI cukup membantu

• Esai ini sangat sesuai dengan pikiran saya, jadi saya membacanya dengan senang. Di kantor saya juga sempat mencoba memakai AI, tetapi dalam kebanyakan kasus hasilnya kurang bagus sehingga akhirnya hampir semuanya saya tulis ulang sendiri. Saya makin yakin bahwa menyerahkan waktu berpikir atau pemecahan masalah yang seharusnya saya lakukan kepada AI adalah pilihan terburuk bagi karier saya. AI hanyalah generator teks kualitas menengah

  • Hal yang paling membuat saya menyesal adalah bahwa sebenarnya saya bisa sangat jago dalam coding berbasis LLM. Rekan-rekan saya tenggelam dalam dunia baru ini, terus memproduksi kode AI slop dan pekerjaannya pun makan waktu sangat lama. Sementara itu saya punya naluri arsitektur software dan lebih piawai dalam “cara memberi instruksi ke AI”, misalnya meminta corner case yang penting kepada LLM. Selain itu saya juga bagus dalam mengelola konteks, dan berkat karakteristik perkembangan neurologis saya, saya sudah lama berlatih berkomunikasi dengan entitas yang cara kerjanya berbeda dari saya, sehingga saya bisa berempati secara lebih mekanis dengan LLM. Rekan-rekan saya justru lebih frustrasi karena LLM tidak bisa membaca pikiran mereka. Tapi LLM terus membaik, jadi keunggulan saya ini tidak akan abadi. Semakin banyak AI slop yang menumpuk, semakin banyak pula LLM yang harus dipakai untuk mengurusi semuanya, sehingga menjadi lingkaran setan. Pada akhirnya mungkin tak ada seorang pun yang benar-benar paham kode apa yang sedang dilihat, dan saya hanya akan berdoa pada dewa mesin

• Menanggapi pertanyaan, “Kenapa sih orang-orang itu memilih jadi programmer kalau tampaknya mereka bahkan tidak peduli pada kode itu sendiri?”, saya ingin menekankan bahwa tujuannya adalah pemecahan masalah. Coding adalah sarana, bukan tujuan itu sendiri. “Mengutak-atik pengaturan editor, dotfile, dan lingkungan pengembangan” mungkin memang menyenangkan, tetapi bagi saya itu adalah kompleksitas yang tidak perlu dan dengan senang hati akan saya delegasikan

  • Menyiapkan editor, dotfile, dan lingkungan pengembangan sendiri pada akhirnya membangun keakraban dengan lingkungan kerja saya, meningkatkan kemampuan saya dalam menggunakan alat, dan menciptakan lingkungan yang lebih produktif. Saat build script perlu disentuh dan Anda jadi “orang yang dipanggil”, itu terjadi justru karena ada pengelolaan semacam ini. Terlalu banyak orang yang setelah sepuluh atau dua puluh tahun memakai Git masih tidak paham merge conflict atau penggunaan dasarnya, sehingga semua pekerjaan menyebalkan akhirnya menumpuk pada orang yang benar-benar menguasai alatnya

  • Klaim seperti “ini tidak bernilai” kalau didorong sampai ujung logikanya bisa berakhir pada “memangnya keberadaan itu sendiri bernilai apa?”

  • Hampir semua pekerjaan di dunia bertujuan memecahkan masalah, tetapi saya penasaran kenapa, dari sekian banyak profesi, mereka memilih software

  • Saya 100% setuju dengan pernyataan “tujuannya adalah memecahkan masalah, dan coding hanyalah sarana.” Orang-orang yang sedih jika AI mengambil alih coding adalah tipe “seniman kode” yang lebih terikat pada ‘bentuk’ dari apa yang mereka buat. Saya sendiri lebih fokus pada masalahnya, jadi saya tidak sedih sama sekali jika AI mengambil alih bagian coding

  • Pernyataan “coding bukan tujuan, melainkan sarana” maupun “mengutak-atik editor itu menyenangkan tapi tidak bernilai” semuanya sangat subjektif. Ada orang yang akan tetap menyukai coding murni karena coding itu sendiri, meskipun tidak ada masalah yang perlu dipecahkan, dan kalau pun dunia sama sekali tidak punya masalah, masih banyak orang yang akan tetap menikmati coding

• Saya sangat tertarik membaca tulisan ini. Hampir persis sama dengan perasaan saya tentang pemrograman dengan LLM. Saya dulu memang orang yang coding karena suka coding, dan saya juga menikmati itu sebagai pekerjaan. Tapi belakangan saya sedih karena di pekerjaan saya tidak lagi bisa menyalurkan hobi yang saya sukai. Pekerjaannya sudah berubah total menjadi hal yang berbeda

• Saya sudah agak berumur. Sekitar tahun 1995, saya memrogram dalam lingkungan yang benar-benar berbeda dari sekarang. Waktu itu engineer tahu siapa target pelanggannya, tahu tech stack, tahu tren industri, dan benar-benar memegang kendali. Kode miliknya adalah taman bermainnya sendiri; dia bisa mengubah total sesuka hati, bahkan gaya indentasi atau tanda kurung pun dia tentukan sendiri (kalau rusak ya dia sendiri yang memperbaiki). Tidak ada yang namanya unit test (paling cuma pengecekan parameter saat itu), dan hampir tidak ada code review formal; yang ada hanya ngobrol santai dengan rekan kerja di kantor sambil corat-coret whiteboard. Kalau ada bug, ya langsung diperbaiki. Pada akhirnya manajemen yang menang, dan saya rasa era “cowboy coding” seperti itu sulit kembali lagi. Kita boleh saja merindukan Apple tahun 90-an, tetapi kita tidak bisa kembali ke masa itu. Waktu itu benar-benar menyenangkan

  • Saya juga mulai di masa yang mirip, tetapi karena ISO 9001 kami melakukan code review rutin. Hasilnya dicetak, lalu tiga orang berkumpul di satu ruangan untuk memeriksa semua baris dan menandatanganinya. Ini diterapkan pada RTOS kontrol industri. Manajemen proyek pun dilakukan dengan mencetak bagan Gantt sepanjang 40 kaki dan menempelkannya di dinding. Benar-benar era waterfall

  • Saya mulai pada akhir 2000-an, dan waktu itu jalur karier serta batas antarspesialisasi jauh lebih jelas. Administrator sistem dan developer benar-benar terpisah, tetapi sekarang saya malah diharapkan menangani juga peran operator sistem, sehingga cakupan pekerjaan saya justru melebar. Saya mengembangkan skill sistem hanya sebagai hobi, dan ketika benar-benar harus menangani pekerjaan itu, dokumentasi vendor maupun pelatihannya sering begitu buruk sehingga saya ingin pura-pura tidak melihatnya

  • Industri secara keseluruhan mungkin tidak akan kembali ke bentuk cowboy coding, tetapi saya rasa di beberapa lingkungan gaya seperti ini masih tetap ada. Di WhatsApp antara 2011–2019, lingkungannya cukup bebas. Tiap lingkungan berbeda, tetapi mana yang cocok bergantung pada biaya mencegah error di muka dibanding biaya memperbaikinya setelah produksi. Secara pribadi saya lebih menyukai pendekatan yang menurunkan biaya perbaikan error. Tentu saja saya tetap berusaha menghindari kesalahan yang memalukan, dan saya tetap melakukan testing untuk hal-hal yang memang perlu

  • Sekarang rasanya semuanya jadi buruk karena terlalu banyak orang bermental bisnis, vibe coder, dan script kiddie yang masuk

  • Masalah cowboy coding adalah satu anggota yang tidak bisa diandalkan bisa merusak seluruh tim. Semakin besar organisasinya, semakin tak terhindarkan jumlah anggota bermasalah juga bertambah, dan untuk mencegah ledakan masalah dibutuhkan mekanisme yang makin besar. Dalam tim kecil yang sangat selektif dan berbasis kepercayaan, cowboy coding adalah efisiensi terbaik, tetapi karena sulit menilai kemampuan kandidat saat perekrutan, pendekatan ini sama sekali tidak cocok untuk organisasi besar. Ke depan, mungkin cara seperti ini hanya bisa bertahan di perusahaan kecil atau tim kecil di dalam perusahaan besar

• Saya sulit setuju dengan pernyataan penulis bahwa "<i>LLM adalah solusi seperti senjata nuklir terakhir yang diarahkan ke kompleksitas perangkat lunak. Alih-alih menyelesaikan masalah sebenarnya, ia berusaha meredakan gejalanya dengan membawa kompleksitas yang lebih besar lagi</i>." Tujuan inti adopsi AI adalah memusatkan “talenta terampil mahal yang kreatif” ke segelintir perusahaan yang merancang AI, lalu di semua perusahaan lain memecat pekerja kreatif dan hanya menyisakan tenaga kerja yang lebih sederhana. Dengan kata lain, tujuannya adalah menyederhanakan kompleksitas semua bisnis melalui AI. Kalau memakai contoh "The Wizard of Oz", orang-orang tidak mau melihat apa yang ada di balik tirai; mereka hanya ingin pekerjaan mereka menjadi lebih mudah. Risiko jangka panjang diabaikan karena semua orang hanya mengejar keuntungan jangka pendek

  • Contoh sentralisasi seperti ini sudah terjadi di banyak industri. Misalnya di industri perbankan, dulu banker lokal membuat keputusan dengan mempertimbangkan kekhasan wilayahnya, tetapi kemudian seluruh HQ memusatkan semua keputusan. Para banker lokal terdorong ke dunia “di bawah API”, sementara elite HQ mengambil seluruh kekayaan. Konsep seperti “Legibility” dan “Seeing Like a State” layak dijadikan rujukan

• Saya sangat suka tulisan ini. Saya juga setuju dengan sebagian pendapat bahwa menyelesaikan masalah lebih penting daripada kode. Tetapi menurut saya, kalau kita mulai menyerahkan bahkan masalah yang menuntut pemikiran mendalam kepada AI, kemampuan untuk melakukan pemecahan masalah yang mendalam itu sendiri bisa menurun seiring waktu. Sekadar memberi instruksi “tolong buatkan sesuatu” menurut saya bukan pemecahan masalah yang sesungguhnya

  • Saya pikir kita bisa menikmati keduanya: pemecahan masalah dan craftsmanship. Secara logis, pemecahan masalah memang nilai yang lebih besar, tetapi bagi sebagian orang, kesenangan “menulis, menyentuh, dan membuatnya sendiri” memang lebih besar, sehingga wajar kalau mereka merasa kehilangan ketika kesenangan itu menghilang. Seperti dalam tulisan ini, orang-orang yang mendefinisikan dirinya sebagai “programmer” biasanya benar-benar menikmati pemecahan masalah, membuat sesuatu, mengerjakannya sendiri, dan tinkering