Membereskan Jejak Para Pengembang Rockstar AI

• Di masa lalu, masalah codebase sulit dipahami yang ditinggalkan oleh para “pengembang rockstar” kini berkembang menjadi beban pemeliharaan bagi seluruh tim seiring meluasnya kode hasil generasi LLM
• Pengembang rockstar cepat mengadopsi teknologi baru, paradigma baru, dan arsitektur baru, serta menyelesaikan pekerjaan sulit dengan cepat, tetapi kurang peduli menulis kode yang bisa dipahami dan dikerjakan bersama oleh orang lain
• Agen LLM dapat membuat puluhan ribu baris kode dalam waktu singkat tanpa mengingat pekerjaan sebelumnya, dan tidak terlalu memedulikan apakah hasilnya selaras dengan keseluruhan sistem atau menjadi lebih mudah dipahami
• Semakin banyak kode yang dihasilkan, kompleksitas sistem dapat meningkat tajam, dan ini bisa memicu alur kerja yang kembali bergantung pada LLM hanya untuk memahaminya
• Untuk membangun perangkat lunak yang tahan lama, LLM perlu dibatasi pada pembuatan potongan kode kecil, manusia harus memimpin desain, dan arsitektur perlu disederhanakan agar sesuai dengan kompleksitas masalah

---

Struktur yang Ditinggalkan Pengembang Rockstar

• Pengembang rockstar bergabung ke tim lalu mengajukan ide-ide kuat tentang teknologi baru, paradigma baru, dan arsitektur baru
• Mereka menulis ulang sebagian besar arsitektur inti perusahaan, serta memperkenalkan proses build, alat, dan bahasa baru
• Mereka menolak banyak pull request dan menaikkan standar yang dituntut dari rekan tim, sementara orang lain tidak bisa menunjukkan apakah mereka benar-benar memahami kode tersebut
• Pekerjaan paling sulit diberikan kepada pengembang rockstar, dan ia menyelesaikannya lebih cepat daripada siapa pun
• Anggota tim lain bergerak lebih lambat karena harus mempelajari library baru dan menyesuaikan diri dengan cara kerja pengembang rockstar
• Beberapa tahun kemudian, pengembang rockstar pergi dari tim karena menginginkan proyek yang lebih besar dan lebih sulit di perusahaan lain

Menghadapi Dampaknya

• Anggota tim yang tersisa mengambil alih proyek milik pengembang rockstar dan menghadapi situasi yang terasa sangat membingungkan di dalam kode
• Aliran data sulit diikuti, sampai terasa seolah-olah seseorang sedang berusaha menutupi sebuah pembunuhan
• Mereka mulai dari memperbaiki bug sederhana, tetapi hanya untuk menjalankan kode di laptop saja butuh seminggu
• Separuh kode ditulis dalam bahasa yang tidak mereka pahami, dan separuh lainnya menggunakan library yang belum pernah mereka dengar
• Mereka memberi tahu atasan bahwa kode itu perlu ditulis ulang, tetapi usulan itu ditolak hanya karena kode tersebut ditulis oleh pengembang rockstar
• Saat tersesat dalam kode yang berantakan, mereka membayangkan pergi sambil melihat-lihat lowongan kerja

Membersihkan Peninggalan Rockstar

• Banyak tim dan agensi perlu merapikan codebase yang ditinggalkan oleh pengembang rockstar seperti ini
• Proses memahami dan menyelamatkan codebase yang kompleks diibaratkan seperti mengurai rangkaian lampu kusut agar bisa dipakai lagi
• Para pengembang rockstar suka menulis kode, belajar, dan memakai paradigma baru, serta mendorong kemampuan mereka sampai batasnya
• Mereka berusaha menulis kode secerdas mungkin dan fokus bergerak secepat mungkin
• Menulis kode yang bisa dikerjakan bersama orang lain menjadi prioritas paling rendah bagi pengembang rockstar

Munculnya Kecerdasan Buatan

• Dalam beberapa tahun terakhir, banyak tim mengalami situasi seolah-olah kewalahan oleh pasukan pengembang rockstar
• Setiap kali seseorang memulai chat baru, muncul risiko seakan-akan menambahkan satu lagi pengembang rockstar ke tim
• Agen tidak mengingat apa yang dikerjakannya kemarin, tetapi dapat menghasilkan puluhan ribu baris kode dalam hitungan menit
• Agen mengejar penyelesaian pekerjaan dengan kecepatan yang secara manusiawi mustahil
• Mereka tidak peduli apakah kode yang dihasilkan cocok dengan kode lain dalam sistem, atau apakah sistem menjadi lebih mudah dipahami
• AI memiliki kotak peralatan praktik terbaik yang mungkin tidak sesuai dengan konteks
• Bahkan ketika kompleksitas sudah lebih besar daripada manfaatnya, AI tetap bersikeras pada pengamanan berlebihan ala “belt and suspenders”
• Saat diminta melakukan code review, AI menghasilkan daftar panjang perbaikan yang banyak poinnya sulit disetujui
• Makin banyak orang merasa bahwa tanpa memakai LLM, mereka akan tertinggal selamanya
• Penulis menilai bahwa membiarkan LLM menulis semua kode justru pada akhirnya akan membuat kita tertinggal

Membereskan Jejak Ratusan Rockstar AI

• Membersihkan tumpukan kode hasil generasi yang berantakan bahkan tidak semenikmati merapikan kode dari satu pengembang rockstar
• Setidaknya, pengembang rockstar masih memiliki semacam niat desain dan usaha untuk melakukan yang terbaik
• Tumpukan kode berantakan yang dibuat lewat vibe coding bukan hasil karya satu pengembang buatan saja
• Itu menjadi codebase yang dibentuk dari banyak chat dan banyak konteks, masing-masing menghasilkan satu fitur atau satu perbaikan bug
• Ini mirip dengan codebase yang ditulis oleh ratusan pengembang rockstar yang berbeda-beda
• Dalam beberapa kasus, utang teknis menjadi terlalu besar hingga mencapai tingkat yang tidak mungkin dilunasi

Membangun Perangkat Lunak yang Tahan Lama

• Ada berbagai cara menggunakan LLM agar tidak bertindak seperti pengembang rockstar
• Manusia dapat memimpin rekayasa, dan LLM diarahkan untuk hanya menghasilkan potongan kode kecil setiap kali
• Kita harus memastikan perangkat lunak ditulis dengan cara yang mudah dipahami dan dikerjakan oleh semua anggota tim
• Jika LLM tersesat tanpa memahami apa yang dilakukannya dan mengapa, kita perlu memperlambat laju
• Bergerak lebih lambat demi menjamin kualitas perangkat lunak yang dihasilkan itu tidak masalah
• Tidak masalah untuk terus menyederhanakan arsitektur sampai sesuai dengan kompleksitas masalah, sambil mencegah overengineering
• Terkadang, tidak masalah membiarkan LLM tetap berada di kotak peralatan dan menulis kode sendiri secara langsung
• Jiwa craftsmanship akan selalu berada di tangan manusia, dan itu adalah ranah yang tidak bisa dialihdayakan ke mesin

[GN⁺]

Komentar Hacker News

• Kalimat terakhir bahwa keahlian craftsmanship akan selalu tetap berada di tangan manusia dan tidak akan pernah bisa dialihdayakan sepenuhnya ke mesin terasa agak mengkhawatirkan.
  Di industri lain pun craftsmanship tidak mati, tetapi tersingkir oleh alternatif yang jauh lebih murah dan mudah didapat. Sepatu kulit buatan tangan masih bisa dibeli, tetapi hanya sedikit orang yang mau membayar lebih dari $1000, dan lukisan yang dikerjakan berminggu-minggu juga masih bisa dibeli, tetapi kebanyakan orang membeli hiasan dinding dan pernak-pernik di HomeGoods.
  Perbedaan utamanya adalah asumsi bahwa sesuatu itu sekali pakai, dan sayangnya perangkat lunak juga makin diperlakukan seperti produk lain yang “sekali pakai”. Untuk aplikasi hitung mundur yang sederhana, mungkin tidak masalah jika dibuang, tetapi perangkat lunak yang menopang proses kerja jangka panjang tidak boleh diperlakukan seperti itu.
  Jika fokusnya pada craftsmanship dalam perangkat lunak, masalahnya bisa terlihat seperti “sesuatu yang saya butuhkan” versus “sesuatu yang bergaya butik, mahal, dan tidak perlu”. Padahal sebenarnya ini harus dipahami sebagai “sesuatu yang dapat dipelihara dan andal” versus “sesuatu yang boleh dibuang”.
  Terlepas dari apakah tren ini menguntungkan penyedia model besar seperti OpenAI atau Anthropic, itu bukan inti yang ingin disampaikan di sini.

  • Craftsmanship di industri lain tidak sedang mati dengan cara seperti yang dibicarakan dalam perangkat lunak.
    Meja murah yang datang dalam kotak pipih dan saya rakit sendiri dengan obeng juga diproduksi massal di pabrik, tetapi desainnya bisa jadi memuat jauh lebih banyak craftsmanship dari para ahli dibanding barang kustom. Strukturnya adalah biaya desain awal yang tinggi, lalu produksi massal dengan biaya marjinal rendah.
    Perangkat lunak pada dasarnya sudah seperti itu sejak awal. Saat saya mengunduh Firefox, bukan seorang pengrajin yang membuat browser web khusus untuk saya; yang terjadi adalah server CDN di sebuah pusat data menyalin byte dari cache.
    Yang diancam AI adalah penggantian craftsmanship berbasis investasi awal yang dalam industri lain belum pernah tergantikan secara besar-besaran. Yang lebih berhasil digantikan AI justru perangkat lunak “kerajinan tangan” kelas bawah, wilayah yang sampai sekarang praktis tidak ada karena secara ekonomi terlalu tidak layak.
  • Industri fisik dan perangkat lunak sangat berbeda. Sepatu kulit dibuat berkali-kali, sepasang untuk setiap pelanggan, sedangkan kode dibuat sekali lalu semua pelanggan memakai produk yang sama.
    Karena itu ada daya ungkit yang jauh lebih besar untuk investasi kualitas.
    Saya juga sulit setuju bahwa perangkat lunak itu sekali pakai dalam arti yang sama. Jika masalahnya sementara, kodenya bisa dibuang dan dibuat ulang saat masalah lain muncul. Tetapi jika masalahnya berkelanjutan, kodenya akan tetap ada.
  • Dari sudut pandang permesinan, ada sudut pandang yang menarik.
    Sekrup dulunya adalah barang langka yang dibuat khusus, dan membuat satu sekrup yang bagus membutuhkan waktu dan upaya yang luar biasa besar. Bahkan apa yang sekarang kita sebut machine screw hanya bisa dibuat oleh orang yang sangat terampil dengan kerja yang amat berat.
    Namun mesin bisa memindahkan craftsmanship. Jika Anda membuat satu sekrup yang benar-benar bagus, mesin dapat mentransfer kualitas sekrup itu ke banyak sekrup baru.
    Di zaman modern, hampir semua jenis dan kualitas sekrup telah menjadi barang habis pakai yang nyaris setara, dan sekrup yang dulu mungkin harus dipahat berhari-hari atau berminggu-minggu dengan tangan kini dibuat miliaran jumlahnya.
    Saya melihat AI seperti bubut tanpa leadscrew. Pada awalnya kita tetap harus membuat sekrup dengan tangan, lalu setelah itu kita bisa memindahkan kualitas yang mampu kita hasilkan ke sekrup-sekrup baru sebanyak yang kita mau. Jika kita bisa membuat sekrup yang lebih baik, kita bisa memasukkannya ke bubut dan membuat lebih banyak sekrup yang lebih baik. Tetapi pada dasarnya tetap ada batas kualitas sekrup yang bisa saya buat sendiri. Jika yang bisa saya buat hanya sesuatu yang bengkok, bergelombang, dan berantakan, itulah juga yang akan keluar dari mesin.
  • Itu sudut pandang yang sepenuhnya keliru. Yang setara dengan “craftsmanship” dalam perangkat lunak bukanlah pembuatan sepatu, melainkan lebih dekat ke desain sepatu.
    Pengembang perangkat lunak menciptakan kekayaan intelektual yang unik, bukan memproduksi unit perangkat lunak. Ini lebih mirip penulis buku atau musisi.
    Dalam perangkat lunak tidak ada padanan untuk manufaktur per unit. Yang ada hanya menyalin dan memindahkan bit.
    Jadi, “craftsmanship” dalam konteks perangkat lunak berarti seberapa besar perhatian diberikan untuk merancang sesuatu yang bagus. Selama kita belum sampai pada titik di mana kualitas perangkat lunak yang kita pakai tidak lagi penting, ini tidak akan hilang, dan saat ini belum ada tanda-tanda kita bergerak ke arah itu.
  • Analogi sepatu buatan tangan tampaknya tidak pas kecuali yang dimaksud adalah perangkat lunak yang hanya dipakai satu orang.
    Perbandingan yang lebih tepat mungkin adalah insinyur yang membuat dan memelihara peralatan manufaktur di pabrik sepatu. Memang satu tingkat lebih jauh dari konsumen, tetapi craftsmanship jelas tetap ada di sana.

• Saya suka pekerjaan memperbaiki kode AI atau kode hasil outsourcing. Minggu lalu saya tahu ada klien yang mencoba membuat alat internal untuk departemennya dengan vibe coding, dan hasilnya adalah sampah Next.js raksasa yang butuh 10GB memori hanya untuk kompilasi, punya ribuan error lint, dan bahkan log pengembangan yang berisik ikut masuk ke Git.
  Sekarang kami yang harus membereskannya, jadi kejadian seperti ini praktis adalah pekerjaan gratis senilai 10.000 sampai 50.000 euro yang terus berulang. Kalau tahu apa yang dilakukan, ini sangat mudah; kalau tidak, mustahil. Silakan bawa lebih banyak lagi.

  • Dalam arti tertentu, klien itu setidaknya sudah memberi spesifikasi dan mockup UI untuk implementasinya.
  • Saya setuju 1000 kali dengan ini.
    Saya bekerja di bidang respons insiden untuk UKM, dan beberapa tahun terakhir beban kerjanya meningkat sampai sulit ditangani, sementara rekening bank terasa seperti tumpukan emas naga.
    Saya selalu berpendapat bahwa keamanan harus diintegrasikan dan direncanakan sejak awal; saya sama sekali tidak ingin melihat insiden pelanggaran.
    Tapi fakta bahwa orang-orang dengan keahlian yang samar-samar kini bisa memuntahkan aplikasi dalam satu jam benar-benar menjadi durian runtuh bagi orang seperti saya.
  • Agensi yang fokus pada pekerjaan seperti ini akan menghasilkan banyak uang. Saya sendiri sudah menerima beberapa kasus seperti itu, dan selama orang masih berpikir mereka bisa vibe coding sebuah produk, pekerjaan seperti ini akan terus datang. Seperti yang dibilang, ini uang mudah.
  • Banyak orang sedang memasang taruhan besar pada AI. Sebagian memang tampak menjanjikan, tetapi tidak semua taruhan akan berhasil.
    Pola pikir seperti ini bisa dilihat sebagai mesin slot manusia tempat orang terus memasukkan uang.
  • Saya penasaran apakah Anda bisa bercerita lebih jauh tentang bagaimana ini biasanya berkembang, tentu tanpa mengungkap identitas Anda atau klien.
    Saya ingin tahu apakah para klien datang sejak awal untuk meminta bantuan membawa proyek ke lingkungan produksi, atau apakah mereka menjadikan itu pilihan terakhir setelah pendekatan AI mereka gagal total.
    Saya juga ingin tahu apakah ada pola umum bagaimana proyek-proyek seperti ini runtuh, atau apakah kegagalannya biasanya lebih halus.

• Dalam hidup, aku pernah bertemu beberapa orang yang benar-benar layak disebut luar biasa pintar. Tipe orang yang bikin kita berpikir, “Gimana caranya bisa sepintar ini?”
  Ada dua hal yang sering terlihat pada orang yang sangat pintar, dan biasanya keduanya saling eksklusif. Yang pertama, mereka tidak sadar seberapa pintarnya diri mereka. Bagi mereka, hal itu sederhana, atau itu topik yang mereka kuasai, jadi mereka berasumsi siapa pun yang punya gelar ilmu komputer pasti juga tahu, ingat, dan paham. Aku pernah melihat teman-teman yang lancar membahas matematika kriptografi lalu merasa, “Aku memang lulus mata kuliah itu, tapi aku tidak bisa bilang benar-benar memahami topik yang barusan kamu jelaskan”
  Yang kedua, ada orang-orang yang nyaris terus-menerus sadar, sampai terasa menyakitkan, bahwa mereka lebih pintar daripada kebanyakan orang di sekitar mereka. Sebagian jadi bersikap jahat, sebagian lagi hanya lelah dikelilingi orang-orang yang relatif “bodoh”. Aku agak bisa berempati dengan yang kedua ini. Bayangkan hidup dengan segala sesuatu terasa jelas, gamblang, dan mudah diselesaikan, lalu harus melihat umat manusia terus mengulang pilihan-pilihan bodoh padahal jawabannya sudah diketahui sejak lama

  • Ada masalah ketiga juga. Jauh lebih dari setengah orang percaya bahwa merekalah yang termasuk dalam kalimat terakhir itu
  • Aku tidak mengklaim banyak membaca buku atau punya IQ tinggi, tapi untuk hal-hal kecil yang terasa seperti akal sehat, aku merasakan sesuatu yang mirip
    Melihat orang panik ke sana kemari, atau melakukan X padahal jelas hasil buruk -Y akan keluar kalau melakukan X, rasanya bikin gila. Kebanyakan dari kami hanya belajar untuk tidak mengatakannya keras-keras
    Dalam hubungan keluarga dekat, ini terasa sangat tidak sehat. Aku merasa melihat terlalu banyak sampai rasanya bisa membunuh orang dengan omelan
  • Aku pernah tahu dan bertemu orang-orang seperti itu
    Tapi tak satu pun dari mereka adalah developer 10x yang menumpuk kekacauan besar hingga tim dan aku harus membereskannya selama berbulan-bulan
  • Hidup sebagai orang yang berada di titik ekstrem dalam suatu sifat yang mendasar itu sepi
    Sesulit apa pun berusaha, tetap sulit menjalin hubungan dengan kebanyakan orang, dan mereka juga sangat sulit memahami kita. Perbedaan pengalaman hidupnya sangat besar, dan sering kali sulit dijembatani
  • Banyak developer memilih untuk sekadar mengerjakan tugas rutin atau mengikuti cargo cult
    Mungkin tidak semua developer bisa menghasilkan output yang sama, tapi siapa pun bisa menjadi lebih cerdas dengan caranya sendiri jika memutuskan untuk terus berpikir melampaui rata-rata budaya yang ada
    Kebanyakan orang tidak menyadari bahwa mereka bisa melakukan itu

• Dua kalimat ini sangat terasa buatku
  “Mengikuti aliran data terlalu sulit sampai rasanya seperti ada seseorang yang sedang berusaha menutupi pembunuhan”
  “Butuh waktu seminggu hanya untuk menjalankan kode itu di laptop”
  Aku selalu merasa cuma aku yang kesulitan memahami aliran data atau menyiapkan environment development yang layak. Sindrom penipu dan kadang lingkungan beracun yang mendorong “kecepatan” juga tidak membantu
  Senang rasanya tahu ternyata bukan cuma aku

  • Bagian “Butuh waktu seminggu hanya untuk menjalankan kode itu di laptop” benar-benar mengejutkan
    Claude Code di CLI membuat pekerjaan menjalankan aplikasi dan men-debug dependensi acak atau masalah terkait Docker jadi jauh lebih mudah dibanding dulu. Dulu aku harus mempelajari arsitekturnya sambil sekaligus memperbaiki hal-hal yang tidak jalan di mesinku
  • Bukan cuma kamu. Aku juga merasakan hal yang sama, dan pengetahuan seperti itu biasanya cuma ada di kepala orang atau tersimpan di thread Slack yang acak
    Pada kode AI, ini lebih parah lagi. Karena saat itu orang cuma menghasilkan sesuatu yang tampak masuk akal

• Aku agak iri pada orang-orang yang harus membereskan peninggalan orang lain. Setidaknya rasanya seperti memecahkan teka-teki
  Pekerjaanku sekarang benar-benar membosankan. Tugasnya cukup sederhana sampai junior pun bisa melakukannya, tapi entah kenapa tetap butuh developer level menengah. Bukan berarti aku menganggap diriku terlalu bagus untuk pekerjaan ini, atau bahwa developer level menengah tidak seharusnya mengerjakan hal seperti ini. Hanya saja aku tidak bisa memaksa diriku untuk peduli pada kode yang dibuat perusahaan ini. Kodenya tua, berdebu, dan bahkan tidak dipakai oleh orang penting. Pelanggannya memakai alat ini hanya karena dulu pernah membelinya, dan mereka tidak cukup peduli untuk menggantinya karena alat ini memang tidak menarik
  Aku dijanjikan bahwa pekerjaan yang lebih sesuai dengan pengalamanku akan segera datang, tapi rasanya pelanggan seperti itu tidak akan datang ke perusahaan yang mandek seperti ini
  Tidak mengherankan kalau perusahaan ini kehilangan pelanggan dan karyawan. Tapi aku harus membayar cicilan rumah. Hari ini aku diberi tahu bahwa kontrakku mungkin tidak akan diperpanjang, dan rasanya itu sama saja dengan diancam agar menunjukkan lebih banyak rasa memiliki dan mengerjakan lebih banyak hal dengan gaji yang sama
  Sayangnya aku memang harus bertahan sampai menemukan posisi baru yang benar-benar menarik. Aku juga tidak butuh banyak uang dan sama sekali tidak peduli pada hal seperti “pertumbuhan”. Aku cuma butuh cukup untuk bertahan hidup
  Mungkin komentar ini jadi sangat tidak relevan, maaf. Aku tidak punya tempat lain untuk meluapkannya

  • Kamu tidak sendirian. Aku pernah berada di situasi yang persis sama di Microsoft dan akhirnya mengajukan pengunduran diri
    Aku di level L63, tapi pekerjaan yang kulakukan sebenarnya masih bisa dikerjakan oleh L60~L61, dan aku sering merasa seperti berada di salah satu Bullshit Jobs yang dibicarakan David Graeber. Kompensasinya memang besar, tapi setelah saham bonus masukku habis, aku sadar aku cuma bertahan di pekerjaan itu demi stabilitas
    Rasanya seperti menjadi salah satu engineer yang berjemur di teras kantor Hooli sambil menunggu stock vesting. Aku sudah 9 tahun berkarier, dan itu tidak terasa seperti pilihan terbaik untuk karierku saat ini
    Bedanya, aku tidak punya kewajiban finansial besar, jadi keputusannya jauh lebih mudah
  • Awalnya kukira “medior” itu salah ketik aneh dari “senior”, tapi setelah muncul dua kali aku cari tahu. Sepertinya di beberapa wilayah Eropa istilah itu dipakai untuk berarti tingkat menengah
  • Aku sangat relate dengan kalimat, “aku tidak bisa memaksa diriku untuk peduli pada kode yang dibuat perusahaan ini”
    Produk-produk sampah buatan perusahaan sampah hidup dari kemalasan dan ketiadaan selera kebanyakan orang, lalu para marketer memonetisasinya
    Sekarang malah jadi lebih buruk karena seluruh bidang ini sedang mengalami LLM-isasi, diperkuat 100 kali lipat. Ini membuat kode jadi mustahil dipelihara, dan yang lebih parah, membuat kita semua jadi lebih bodoh
    Aku sungguh berharap kita tidak pernah menemukan ini
  • Kalau melihat lebih teliti codebase yang sedang kamu kerjakan sekarang, sepertinya ada cukup banyak kesempatan untuk membereskan sesuatu, entah itu peninggalan orang lain atau buatanmu sendiri
  • Aku agak penasaran dengan bagian “diancam agar menunjukkan lebih banyak rasa memiliki dan mengerjakan lebih banyak hal dengan gaji yang sama”
    Aku penasaran apakah maksudnya sekadar diminta lembur dan mengerjakan tugas-tugas tidak penting, atau benar-benar ada kesempatan untuk ngoding lebih banyak, atau malah ada ekspektasi mendadak untuk membuktikan bahwa kamu lebih bernilai
    Bukan mau meremehkan apa yang kamu alami. Kalau yang dimaksud itu yang terakhir, aku penasaran apakah sebenarnya masih ada sesuatu yang bisa dicoba

• Beberapa bagian awal terasa mengena. Dulu sepertinya aku adalah developer rockstar, lalu aku sadar itu bukan hal yang baik.
  Mungkin aku bisa menyelesaikan pekerjaan 10 kali lebih cepat daripada rekan-rekan kerjaku. Tetapi pada satu titik aku sadar itu bukan karena aku 10 kali lebih produktif daripada orang biasa, melainkan karena cara kerjaku membuat orang-orang biasa di sekitarku hanya menjadi 1/10 seproduktif biasanya.
  Setelah itu aku memperlambat ritmeku, dan itu menjadi perubahan positif bagi hidupku secara keseluruhan. Menjadi pemain tim memang tidak memberi mobilitas naik yang sama di industri gila ini, tetapi dampaknya luar biasa baik untuk kesehatan mental.

  • Aku juga jelas pernah menerapkan gaya rockstar di masa lalu lalu malah mencelakakan diri sendiri.
    Dalam kasusku, biasanya itu berupa abstraksi berlebihan untuk hal-hal yang sebenarnya tidak perlu, atau membuat sesuatu untuk use case yang pada kenyataannya tidak pernah terjadi. Jadi setiap kali pikiranku mulai mengarah ke abstraksi berlebihan, aku berusaha mengingat YAGNI dan KISS.

• Tulisan ini nilainya terlalu rendah.
  Aku juga tidak begitu paham apa yang sebenarnya ingin disampaikan, dan ini cuma terlihat seperti tulisan menepuk punggung sendiri.

  • Kode buruk memang ada. Tetapi tulisan ini tampak mencampuradukkan “kode buruk” dengan “kode yang kompleks, besar, dan butuh waktu untuk dibiasakan”.
    Sebagian besar dari apa yang disebut sebagai sejumlah besar kode buruk yang ditinggalkan oleh “developer rockstar” sebenarnya adalah hasil dari kompleksitas yang perlahan menumpuk seiring waktu karena harus menyesuaikan diri dengan perubahan requirement.
    Selain itu, orang sering mengira mereka sedang “refactor demi keterbacaan”, padahal kenyataannya mereka sering hanya “menulis ulang kode sambil memahaminya dalam proses”.
  • Ringkasnya, ini cuma “saat memakai LLM, pelankan ritme dan pikirkan apa yang sedang kamu lakukan”. Menghemat 5 menit waktuku.
    Aku mengharapkan lebih banyak isi atau contoh nyata. Sekitar 90% tulisan ini dipakai penulis untuk mengeluh dan mendefinisikan masalah, lalu di paragraf kedua dari belakang muncul solusi samar yang terasa asal dilempar. Hampir tidak ada relevansi atau kegunaan nyata.

• Mendorong keras dua production engineer untuk membangun infrastruktur di sekitar dua proyekku yang menghasilkan keuntungan jelas merupakan tindakan yang sangat bodoh.
  Seharusnya aku membuat semuanya seperti spaghetti code ala bos 10x lalu pindah ke Anthropic dan mendapatkan paket kompensasi 9 digit; aku pasti bisa menghasilkan jauh lebih banyak uang. Betapa bodoh dan bodohnya aku.
  Setidaknya itulah kesimpulan yang kudapat dari sini.

• Kode yang ditulis biasanya harus dipelihara oleh seseorang selain penulisnya. Jadi jika kamu menulis kode yang tidak bisa dipahami siapa pun, pada akhirnya itu akan berujung pada gagal dipelihara.
  Yang dioptimalkan bisa berbeda-beda: kode yang mudah dipahami tim, kecepatan, keunggulan teknis, dan sebagainya.
  Tetapi bahkan jika kamu mengoptimalkan keunggulan teknis, kalau tidak ada orang lain di tim yang bisa memahami kode itu, itu tetap gagal.
  Aku pernah melihat kode yang terlalu direkayasa.

[GN⁺]

Pendapat di Lobste.rs

• Tulisan ini nyaris tidak punya saran yang benar-benar berguna

  • Rasanya seperti keluhan pribadi seseorang yang dibungkus dengan dua istilah tren agar terlihat meyakinkan
    Istilah “developer rockstar” memang selalu terasa meragukan, tetapi developer yang benar-benar hebat itu memang ada. Hanya saja, mereka tidak bertindak seperti yang digambarkan di tulisan ini; mereka bekerja semaksimal mungkin dalam lingkungan yang ada, memperbaiki codebase, tidak membawa masuk hal baru yang belum teruji seperti mainan, dan saat pergi justru meninggalkan keadaan yang lebih stabil lewat testing, deployment yang discrpt otomatis, linting, dan sebagainya
    Di sini AI terasa seperti hanya ditambahkan untuk mengatakan bahwa perilaku seperti ini akan menjadi lebih buruk, dan itu mungkin saja, tetapi tampaknya belum cukup terbukti. Selama puluhan tahun bekerja sebagai konsultan, saya sudah sering merapikan codebase yang berantakan; kadang penyebabnya memang orang yang kebablasan, tetapi lebih sering tim yang memang belum tahu cara yang lebih baik. Dalam kedua kasus itu, saya tidak pernah berpikir, “pasti ini ulah developer rockstar/ninja/buzzword”

• Jadi sekarang bukan cuma harus membereskan sampah yang ditumpahkan chatbot ke atas kepala kita, tapi juga harus membereskan orang-orang yang tidak peduli soal itu
  Rasanya jadi hanya menunggu gelembung ini pecah

  • Dari dulu memang selalu begini, hanya saja AI memperbesar masalahnya. Di sisi lain, bisa juga dilihat bahwa pekerjaan beres-beresnya jadi lebih mudah

• Kalau pada 2026 saya bergabung ke sebuah perusahaan dan mendapati mereka masih memakai create-react-app, saya penasaran apa perilaku yang benar-benar dianjurkan. Apa maksudnya saya harus diam saja?

  • Kalau itu proyek baru, cukup katakan bahwa itu sekarang sudah deprecated dan tidak lagi direkomendasikan
    Kalau itu proyek lama, berarti Anda menemukan utang teknis. Semua orang punya. Cara terbaik untuk meyakinkan orang agar memperbaikinya adalah dengan membuat alasan bisnis yang masuk akal. Kalau masih berjalan, apakah itu benar-benar risiko? Dibanding utang teknis lain, prioritasnya di mana? Risiko implisit apa yang ditanggung jika tidak di-upgrade? Seberapa besar usaha yang dibutuhkan untuk upgrade?
    Jika usahanya kecil dan rekan kerja juga menginginkannya, ada juga cara untuk mengerjakannya begitu saja tanpa minta izin. Namun itu paling berhasil ketika ada dukungan dari orang-orang yang terdampak perubahan ini, dan ketika tidak mengganggu hasil kerja Anda sendiri. Mungkin bukan sesuatu yang dilakukan pada minggu pertama masuk kerja
    Biasanya selalu lebih baik bertanya dan memahami mengapa keadaan jadi seperti sekarang, daripada langsung mengatakan “seharusnya begini”. Setiap codebase yang punya sejarah adalah hasil dari ribuan keputusan yang belum Anda ketahui. Anda perlu membekali diri dengan pengetahuan dan empati
  • Saat baru bergabung, saya lebih suka mengamati dulu sebelum menunjukkan semua hal yang menurut saya harus dilakukan secara berbeda. Ada keseimbangan antara mengubah segalanya ketika orang baru masuk ke tim, dan fokus pada hal-hal yang benar-benar berdampak. Tepat setelah bergabung, Anda belum tahu apa yang benar-benar berdampak
  • Tergantung pertarungan mana yang ingin dipilih. Secara pribadi saya rasa itu tidak sepadan, tetapi saya bukan Anda. Kode legacy ada di mana-mana, dan biaya keluar dari framework seperti create-react-app lalu menulis ulang jauh lebih besar daripada biaya bertahan dengan sesuatu yang sudah akrab bagi orang-orang
  • Saya bukan web developer, jadi maksud pertanyaan ini apa? Apakah create-react-app yang dianggap usang, atau React yang dianggap usang?
  • Saya hanya ingin memberi tahu bahwa orang-orang sekarang benar-benar sangat membenci CRA
    Saya sudah membencinya sejak 2020, bahkan saat itu masih terlihat keren

• “Agen tidak mengingat apa pun yang mereka lakukan kemarin” adalah masalah yang bisa dipecahkan. Bisa memakai pendekatan memori dan sebagainya. Belum tentu baik secara umum, tetapi terus membaik
  “Ia tidak peduli apakah kode ini cocok dengan kode lain dalam sistem” berbeda dengan pengalaman saya. Biasanya kode yang dihasilkan LLM cenderung cukup mirip dengan kode sejenis di area terkait. Kode yang dibaca untuk mencari arah sering kali tercermin hampir apa adanya
  “Ia tidak peduli apakah sistem jadi lebih mudah dipahami atau justru lebih buruk” juga bisa diatasi. Suruh LLM menilai hal itu dan turunkan nilainya secara bertahap. Apa yang dianggap lebih mudah dipahami sering kali merupakan sifat sistem yang tidak deterministik, sehingga secara paradoks LLM mungkin justru pendekatan yang lebih mudah diukur daripada alat lain. Di sesi baru, Anda bisa bertanya, “untuk memahami kode yang baru ditambahkan ini, seberapa banyak bagian sistem yang harus dipahami,” lalu mengoptimalkannya dengan memperkecil cakupan itu
  Bagian “AI punya kotak alat praktik terbaik yang mungkin tidak cocok di sini” sering terasa mirip dengan proses melatih developer junior yang datang ke proyek baru dengan idealisme yang sama. Kepada junior, kita menjelaskannya secara lisan dan berharap mereka mengingat serta menerapkannya, tetapi pada AI, kalau didokumentasikan di file AGENTS.md / CLAUDE.md, pengetahuan itu akan tetap ada
  “Kalau diminta code review, ia menghasilkan banyak sekali usulan perbaikan yang tidak saya setujui” untuk Codex sudah diatur agar daftar usulannya tetap kecil, ringkas, dan bernilai tinggi. Model lain mungkin berbeda, tetapi ini pada akhirnya tetap persoalan tingkat instruksi. Hal-hal yang Anda pedulikan sering kali memang layak didokumentasikan, dan dengan AI itu jadi makin perlu

• Saat berurusan dengan rockstar, setengah masalahnya adalah ego, tetapi setidaknya rockstar yang meninggalkan kode buatan manusia masih punya refleksi dan niat yang mendasarinya
  Sebaliknya, “rockstar” yang hanya membungkus AI dengan kulit manusia punya gaya sok yang sama atau bahkan lebih besar, tetapi sering kali bahkan tidak benar-benar memahami setengah dari masalah yang mereka klaim sedang mereka selesaikan

• Jika Anda menerapkan pendekatan functional programming semaksimal mungkin dan membuat komponen yang bebas konteks sehingga bisa dirangkai dengan berbagai cara, Anda bisa mendapat daya ungkit yang sangat besar
  Dengan memisahkan blok-blok penyusun individual yang mengabstraksikan detail implementasi dari tugas-tugas yang bergantung pada konteks tertentu, Anda bisa dengan mudah menyusun ulang blok-blok itu ketika kebutuhan berubah atau ketika memilih pendekatan lain. Selain itu, tiap bagian bisa dipahami secara mandiri tanpa harus mengetahui seluruh konteks susunannya, dan dengan melihat bagaimana bagian-bagian itu saling terpasang, Anda bisa memahami logika tingkat yang lebih tinggi
  Bahasa fungsional memberi dasar yang baik untuk bekerja bersama LLM karena secara alami mendorong penulisan kode dengan cara yang membatasi konteks. Ini membantu mengurangi cakupan yang diperlukan untuk memahami fungsi tertentu dalam program, sehingga bermanfaat baik bagi model maupun pengguna manusia