- Dalam pengembangan perangkat lunak, bottleneck bukanlah penulisan kode melainkan berbagai proses yang berpusat pada manusia seperti code review, transfer pengetahuan, pengujian, debugging, kolaborasi/komunikasi
- Berkat LLM, pembuatan kode itu sendiri menjadi sangat mudah, tetapi biaya dan beban untuk memahami, memverifikasi, dan membangun kepercayaan justru makin besar
- Pembuatan kode yang cepat memberi beban lebih besar kepada reviewer, integrator, dan penanggung jawab pemeliharaan, sehingga kecepatan tim secara keseluruhan tidak benar-benar meningkat
- Memahami kode adalah bagian yang paling sulit, dan meskipun LLM dapat menghasilkan kode, kualitas tidak bisa dijamin tanpa kepercayaan tim dan konteks yang dibagikan
- LLM sangat kuat untuk prototyping dan otomatisasi, tetapi tidak dapat menggantikan dasar-dasar pengembangan perangkat lunak seperti desain yang cermat, review, dan berbagi konteks
Titik bottleneck yang sebenarnya dalam penulisan kode
- Selama bertahun-tahun, aktivitas menulis kode itu sendiri bukanlah bottleneck dalam rekayasa perangkat lunak
- Bottleneck yang sebenarnya muncul pada code review, mentoring dan transfer pengetahuan melalui pair programming, pengujian, debugging, serta biaya kolaborasi dan komunikasi
- Pengelolaan tiket, rapat perencanaan, agile meeting, dan prosedur yang kompleks makin memperlambat laju
- Proses-proses untuk menjamin kualitas ini pada kenyataannya menuntut jauh lebih banyak waktu dan pemikiran dibanding penulisan kode itu sendiri
- Namun berkat LLM, biaya menghasilkan kode yang berjalan mendekati 0
- Tetapi biaya untuk memahami, menguji, dan membangun kepercayaan terhadap kode justru menjadi lebih tinggi
- Kecepatan implementasi awal memang meningkat, tetapi lebih banyak kode menjadi objek review/integrasi/pemeliharaan, sehingga beban pun bertambah
LLM mengubah hakikat pekerjaan – bukan menghapusnya
- Alat LLM seperti Claude meningkatkan kecepatan implementasi awal, tetapi pada akhirnya lebih banyak kode masuk ke sistem dalam waktu yang lebih singkat sehingga memberi beban lebih besar pada pihak yang menangani review dan pemeliharaan
- Beban ini makin berat terutama dalam situasi berikut
- Tidak pasti apakah penulis benar-benar memahami kode yang dia ajukan
- Kode yang dihasilkan menggunakan pola yang tidak familiar atau melanggar konvensi yang ada
- Kondisi batas dan efek samping yang tidak disengaja tidak terlihat dengan jelas
- Akibatnya, meski produksi kode menjadi mudah, tingkat kesulitan verifikasi justru meningkat dan pada akhirnya tidak menaikkan kecepatan tim secara keseluruhan
- Dulu ada candaan di kalangan developer tentang “copy-paste engineering”, tetapi dengan LLM fenomena ini menjadi jauh lebih diperbesar
Memahami kode adalah kesulitan yang sebenarnya
> “Biaya terbesar dari kode bukanlah menulisnya, melainkan memahaminya”
- Berkat LLM, produksi kode itu sendiri memang menjadi lebih cepat, tetapi menalar cara kerjanya, menemukan bug yang halus, atau menjamin pemeliharaan jangka panjang sama sekali tidak menjadi lebih mudah
- Ini menjadi lebih sulit terutama ketika reviewer tidak bisa membedakan kode hasil generasi dan kode yang ditulis langsung, atau ketika sulit memahami alasan di balik solusi yang dipilih
Tim tetap bergantung pada kepercayaan dan konteks bersama
- Pengembangan perangkat lunak pada dasarnya mengandaikan kolaborasi, dan sepenuhnya bergantung pada pemahaman bersama, alignment, serta mentoring
- Ketika kode dihasilkan lebih cepat daripada kecepatan diskusi dan review, tim bisa keliru mengira kualitasnya sudah tervalidasi, padahal sebenarnya belum benar-benar memastikannya
- Akibatnya, beban psikologis bagi reviewer dan mentor membesar, dan kecepatan tim secara keseluruhan bisa melambat dengan cara yang baru
LLM kuat, tetapi tidak menyelesaikan inti masalah
- LLM sangat berharga untuk prototyping cepat, scaffold, dan otomatisasi, tetapi tidak menghilangkan kebutuhan akan pemikiran yang jelas, review yang cermat, dan desain yang mendalam
- Biaya menulis kode itu sendiri memang turun, tetapi biaya agar tim memahami kode bersama-sama dan memberi makna padanya tidak berubah
- Bottleneck yang sebenarnya tetap ada pada "pemahaman dan kolaborasi"
7 komentar
Saya persis adalah developer yang kekurangan keterampilan seperti yang diperkenalkan dalam tulisan ini dan sangat bergantung pada LLM.
Karena pengetahuan teknis saya kurang, tanpa AI saya sulit bekerja sesuai WBS..
Setidaknya, apa yang sebaiknya saya lakukan untuk mengurangi waktu review dari para developer senior..?
Kalau sekalian pengetahuan saya juga bisa bertambah, itu akan bagus..
Untuk mengurangi waktu review, Anda sendiri harus bisa menentukan dan menjelaskan dari latar belakang apa kode yang Anda tulis muncul, serta mengapa Anda memilih itu di antara berbagai metode implementasi. Untuk bisa begitu, Anda perlu terus melakukan poin 3. pada akhir pekan atau waktu luang, dan akan bagus jika Anda melihat-lihat secara acak library terkenal atau kode yang diunggah orang lain di GitHub sambil menganalisis hal-hal seperti struktur kode dan gaya implementasinya.
Terima kasih atas kata-katanya yang baik!!
Namun melihat mereka tetap mengurangi tenaga kerja, rasanya suram.. Bagaimana 4 orang bisa menangani 12 proyek.. Ditambah satu orang juga harus mengurus manajemen..
T_T Sepertinya Anda benar-benar sedang melalui masa yang berat.
Opini Hacker News
Sebagai mentor berpengalaman, ada pengalaman membimbing para intern yang ambisius tetapi masih mentah, dan melihat mereka menumpahkan kode setara satu minggu, bahkan dua minggu, hanya dalam sehari. Namun pekerjaanku justru menjadi lebih sulit daripada sebelumnya. Saat melakukan code review, para intern kurang memikirkan secara mendalam kode yang mereka tulis sehingga feedback dariku tidak tersampaikan dengan baik. Bug sederhana atau masalah sepele hampir hilang, tetapi masalah yang tersisa menjadi jauh lebih halus dan kompleks, serta jauh lebih sulit dijelaskan. Selain itu, muncul jenis bug baru yang belum pernah kulihat sebelumnya. Kode yang tampak normal di permukaan ternyata sama sekali tidak bekerja, dan sering kali terlihat seperti sudah matang padahal bagian dasarnya sudah rusak. Junior yang bekerja bersama LLM cenderung bukan menghasilkan kode sederhana yang layak didiskusikan, melainkan langsung menghasilkan kode kompleks yang tampak selesai sekaligus menimbulkan masalah kolaborasi dan maintenance dari berbagai sisi. Akibatnya, cara tradisional “perbaikan bertahap” untuk memoles satu PR sampai kualitas akhir terasa tidak lagi berjalan dengan baik. Saat diberi feedback, mereka kadang bukan memperbaiki PR yang ada, tetapi malah mengajukan pendekatan yang benar-benar baru—sering kali menimbulkan masalah baru lagi. Karena itu, senior justru menghabiskan waktu jauh lebih lama pada satu PR ini dibanding junior. Dari sisi junior, mungkin mereka merasa sangat produktif, tetapi makin sering feedback dari reviewer senior tidak lagi sehangat atau semendorong dulu. Pada akhirnya, hal yang lumayan efektif hanyalah mewajibkan banyak test case, tetapi bahkan tes ini pun mentok karena masalah yang mirip
Melihat kode seperti ini yang 'terlihat matang tetapi sama sekali tidak bekerja', aku teringat proyek pengembangan software luar negeri senilai 250 ribu dolar yang pernah kualami dulu. Dari specification saja semuanya tampak benar, tetapi dalam praktiknya sistem itu sama sekali tidak konsisten. Karena terlalu terpaku pada penafsiran specification dan melewatkan hal-hal yang seharusnya jelas secara common sense, akhirnya seluruh proyek langsung dibuang. Sangat mengesankan bahwa sekarang hal-hal seperti ini diotomatisasi dan digratiskan berkat LLM
Aku sepenuhnya setuju dengan masalah ini. Dari pengalaman pribadiku juga, saat memakai LLM memang bisa membuat ribuan baris kode dengan sangat cepat, tetapi pekerjaan yang benar-benar sulit adalah code review, perbaikan bug, pemeriksaan celah keamanan, refactoring, penghapusan kode yang tidak perlu, dan sebagainya. Pada akhirnya, sering kali menulis kode sendiri justru lebih produktif. Penggunaan paling realistis untuk LLM adalah auto-complete atau menghasilkan potongan sederhana saja. Jika junior memakai LLM sebagai perantara lalu aku masih harus meneruskan lagi, rasanya efisiensinya malah turun. Orang-orang yang saat ini merasa lebih produktif dengan LLM mungkin sebenarnya merasa begitu karena mereka melewatkan pekerjaan penting semacam ini atau memang sama sekali tidak memedulikannya. Pada kenyataannya, hanya segelintir orang yang benar-benar peduli pada kualitas produk yang harus menanggung beban menghadapi volume kode yang sangat besar. Mereka kadang disalahpahami sebagai orang yang terlalu cerewet, padahal sebenarnya merekalah tokoh utama yang berusaha memberikan produk terbaik kepada pengguna. Tidak ada solusi yang jelas, malah tampaknya situasinya akan makin memburuk. Developer yang dilatih hanya dengan LLM akan terus masuk ke industri, dan perusahaan pembuat alat akan terus melakukan marketing berlebihan. Pada akhirnya, beban menjaga kualitas hanya akan terus meningkat
Aku juga mengalami fenomena 'effort inversion' di mana senior harus mencurahkan lebih banyak usaha pada satu PR daripada junior. Dalam kasusku, para penulis PR memakai AI untuk menulis posting blog atau siaran pers, dan ketika aku sebagai subject-matter expert menerima hasilnya, waktu kerjaku justru membengkak 3 sampai 4 kali lipat karena harus membereskan segala halusinasi dan kesalahan AI. Pekerjaan mereka seharusnya mendukungku, tetapi sekarang aku yang harus membantu mereka. Bahkan halusinasi AI pun berbeda-beda setiap kali, jadi setiap saat jadi penderitaan baru. Aku sudah menyampaikan fenomena ini ke eksekutif juga, dan kalau terus begini rasanya separuh staf PR akan hilang tahun depan. Kalau perannya cuma menyalin email ke ChatGPT lalu mengirimkannya kembali kepadaku, aku bisa melakukannya sendiri
Aku penasaran apakah bisa dijelaskan lebih rinci soal bagian “feedback yang kuberikan saat review tidak tersampaikan dengan baik”. Aku sedang mengalami masalah serupa, jadi kalau ada solusi atau insight, tolong dibagikan
Menambahkan pikiranku sendiri, generasi sebelumnya secara alami membangun pemahaman mendalam tentang struktur dan desain software melalui refactoring atau unit test. Tetapi jika ke depan LLM sampai menghasilkan unit test juga, developer bisa kehilangan kesempatan untuk refleksi diri dan belajar seperti “apa yang sebenarnya kubutuhkan?”, “apa cara untuk membuat ini lebih sederhana?”. Menurutku, perbedaan antara 'developer', 'engineer', dan 'architect' ada di titik ini. LLM atau 'vibe coding' sama sekali tidak akan membentuk mindset seperti itu. Dalam bahasa seperti Go yang beban sintaksnya ringan, kesalahan desain seperti ini lebih mudah terlihat saat review. Struktur unit test di Go berguna untuk mendiagnosis kompleksitas kode. Pada akhirnya kita butuh metode test/review yang lebih baik. Fuzz testing, unit test, dan integration test saja tidak cukup. Menurutku kita perlu automated testing framework yang bisa memeriksa secara logis apakah cabang-cabang dalam kode benar-benar terpanggil dan apakah kondisi kepuasannya terpenuhi
Berkat LLM, biaya awal adopsi software baru nyaris mendekati 0, tetapi biaya untuk memahami, menguji, dan mempercayai kode itu secara mendalam terasa lebih tinggi daripada sebelumnya. Namun dari pengalamanku, aku tidak merasa kode buatan LLM jauh lebih buruk dibanding begitu banyak legacy code yang dibuat orang yang sudah pergi dan bahkan tidak bisa lagi ditanyai, atau kode yang berserakan di internet. Bahkan LLM tidak malas menulis test code seperti manusia, juga tidak lelah lalu asal lewat. Filosofiku berangkat dari asumsi bahwa ‘semua kode adalah utang potensial’. Jadi aku tidak terlalu khawatir soal tingkat kepercayaan pada kode. Aku benar-benar pernah membangun codebase besar dengan AI dan membuatnya berjalan dengan baik—tetapi itu hanya mungkin jika domain-nya bisa diverifikasi, serta ada banyak testing dan iterasi. Kesimpulannya, dengan hasil LLM produksi kode memang menjadi lebih cepat, tetapi rangsangan intelektual dari kegiatan coding itu sendiri terasa berkurang, sampai-sampai otakku juga terasa ikut menjadi malas. Sebaliknya, kita sedang memasuki era ketika kerja otak di tahap depan seperti mendefinisikan requirement dan desain menjadi jauh lebih penting
Bahkan tanpa LLM pun, industri sebenarnya sudah berada dalam kondisi di mana yang kurang bukan "kekurangan kode", melainkan kecepatan pengembangan dibatasi oleh permintaan pasar dan keterbatasan modal. Tooling sudah menjadi sangat bagus sehingga coding itu sendiri bukan lagi inti persoalan. Lingkungannya sudah sangat berbeda dari masa awal. Aku teringat kisah Bill Gates saat remaja, ketika sekadar ‘bisa ngoding’ itu sendiri adalah sumber daya langka. Ada cerita bahwa sebuah perusahaan yang sedang terburu-buru mempekerjakan Gates yang saat itu berusia 16 tahun bersama Paul Allen, dan mereka takjub hanya karena keduanya bisa menulis kode dengan cepat. Sekarang pertanyaan yang lebih penting adalah "apa yang dibangun, dan apakah ada bisnis yang benar-benar layak di situ?"
Video terkait
Aku setuju dengan klaim bahwa coding bukan bottleneck karena permintaan pasar. Sebelum booming AI, Marc Andreessen juga pernah berkata, "modal berlimpah, tetapi ide bagus untuk diinvestasikan kurang." Aku tidak merasa pernyataan itu sepenuhnya mencerminkan kenyataan, tetapi setidaknya dari sisi data ucapannya tampak punya kredibilitas
Seperti kisah lama Bill Gates, kemampuan menulis kode berkualitas tinggi dan memahaminya secara mendalam tetap merupakan sumber daya langka. Hanya saja bedanya sekarang, industrinya tidak lagi berada dalam suasana yang benar-benar menghargai kemampuan itu
Dari sudut pandang analisis dampak AI, kita cenderung terlalu percaya pada efisiensi. Namun ekonomi dunia nyata punya struktur bottleneck yang jauh lebih kompleks daripada itu. Walaupun produksi kode meningkat 100 kali, belum jelas apakah itu benar-benar berguna
Belakangan kalau melihat pengalaman orang-orang, rasanya terlalu suram. Jika seorang junior menyerahkan gumpalan kode raksasa yang tidak bekerja, tidak dites/diverifikasi sendiri, tidak dirapikan secara ringkas, dan tanpa dokumen, komentar, atau penjelasan, itu sendiri sudah bisa digambarkan sebagai "LLM versi yang dipasang pada manusia". Pada akhirnya yang penting adalah berpikir kritis dan rasa tanggung jawab atas hasil. Bahkan, aku merasa LLM justru lebih mungkin merespons feedback dengan setia dibanding software engineer junior yang sudah ada
Aku juga dulu mengira menulis kode adalah bottleneck, tetapi dalam 10 tahun aku menyadari bahwa yang benar-benar sulit adalah menyelaraskan teknologi dengan bisnis. Bahkan di lingkungan seperti B2B atau SaaS yang dipenuhi tumpukan kode kompleks dan berbeda-beda untuk tiap pelanggan, jika teknologinya benar-benar selaras dengan bisnis maka semuanya berjalan lancar. Sekarang teknologi sudah cukup maju, jadi yang benar-benar penting adalah 'ego' developer dan sikap untuk fokus pada nilai pelanggan. Kita harus memikirkan apa yang sebenarnya diinginkan pelanggan, apakah mereka akan membayar untuk itu, bahkan apakah antarmuka web benar-benar diperlukan. “Fitur mainan kucing” yang dibuat developer demi kepuasan diri adalah penyebab nyata meningkatnya biaya cloud. Yang lebih menyedihkan lagi, melempar insentif agresif, stock option, atau gaji tinggi pun tidak menyelesaikan masalah mendasar ini. Harus ada seseorang—setidaknya satu orang—yang punya rasa misi untuk membuat software dengan baik, mau berbicara langsung dengan pelanggan, dan bertekad melakukannya dengan benar
Momen ketika LLM benar-benar membantu di organisasi justru adalah proyek pribadiku atau side project. Saat membuat aplikasi untuk menyelesaikan masalah kecil, karena waktunya terbatas, penulisan kode benar-benar menjadi bottleneck besar. Untuk proyek seperti ini, tingkat pemakaian LLM adalah 100%
Aku juga setuju seratus persen. Jika menginvestasikan 1~2 jam sehari ke Claude code, pada saat akhir pekan hampir selesai akan ada satu hasil yang bisa dipakai sungguhan. Dengan investasi waktu yang singkat, validasi ide atau eksperimen menjadi mudah. Menurutku alat LLM seperti ini benar-benar menghasilkan nilai besar bahkan di organisasi profesional. Berbagai alat manajemen atau sistem otomatisasi yang biasanya tak sempat dibuat karena kekurangan waktu juga bisa diprototipekan dengan cepat. Jika rekan kerja membutuhkan query DB atau otomatisasi sederhana, cukup tanya Claude, review hasilnya, lalu tinggal copy-paste. Mendukung agar bahkan non-engineer pun bisa menangani sendiri pekerjaan repetitif di domain mereka juga merupakan tujuan proyekku mcp-front[0]
GitHub mcp-front
Sejujurnya, pada tahap karierku sekarang sulit untuk mencurahkan waktu berminggu-minggu, dan karena pengalaman panjang aku selalu mempertimbangkan non-functional requirements dan perspektif jangka panjang. Bahkan jika melewatkan hal seperti testing pun, tetap saja akan ada banyak hal yang terus kupikirkan
Ini mengingatkanku pada kutipan terkenal Robert C. Martin bahwa "waktu membaca kode lebih dari 10 kali waktu menulisnya"
Kutipan terkait
Sayangnya, gaya clean code miliknya dalam praktik kadang justru memecah konteks sehingga niatnya makin sulit dipahami
Yang lebih buruk, bukannya mengurangi total beban kerja, kita bisa saja hanya mengurangi waktu menulis sambil menambah waktu membaca
Belum ada yang menyebut tulisan Joel Spolsky tanggal 2 Oktober 2000 ini
Joel on Software: Painless Functional Specifications (2000)
Bottleneck yang sesungguhnya bukan kode, melainkan specification fitur. Yang lebih penting adalah membuat specification yang jelas tentang bagaimana software harus bekerja, entah dalam bahasa Inggris, diagram, user story, dan sebagainya. Jika specification sudah tertata baik, LLM pun bisa menghasilkan solution, test, dan integration test yang sangat bagus sekaligus. Jika terlalu besar, specification seharusnya tidak dikelola dalam satu file Markdown, melainkan dipecah per fitur seperti wiki dengan tautan dan referensi. Daya saing yang sebenarnya bukan ditentukan oleh sulitnya implementasi, tetapi oleh seberapa banyak usaha yang dicurahkan ke specification
Penulis komentar ini tidak setuju dengan pandangan penulis artikel. Dari sudut pandang perusahaan besar, mungkin kode bukan bottleneck, tetapi dari posisi startup, karena sumber daya terbatas dan perencanaan yang efisien lebih penting, pekerjaan menghasilkan kode yang benar-benar berfungsi itu sendiri kadang memang merupakan bottleneck terbesar. Pada akhirnya, dalam diskusi seperti ini kita tidak bisa menggeneralisasi “seberapa berguna AI/LLM”. Bagi sebagian tim, kode memang bottleneck; bagi tim lain, tidak
Seperti yang semua orang tahu, kode yang dihasilkan LLM sering kali berantakan dan bahkan mustahil direview. Saat kode LLM yang diajukan junior terlihat aneh lalu ditanya alasannya, dia pun tidak tahu dan menjawab bahwa itu dibuat oleh LLM. Pada akhirnya tren ini hanya menambah ‘noise’ dan ‘overhead’ pada maintenance kode. Jika adopsi LLM memang tidak bisa dihindari, mau tak mau review dan maintenance juga harus diserahkan ke LLM. Tentu hasilnya akan menjadi spaghetti yang lebih rumit. Namun secara realistis, di kebanyakan bisnis kualitas memang sering tidak terlalu penting, dan selama kode LLM bekerja seadanya itu sudah dianggap cukup. Atau selama LLM bisa terus ditambahkan seperlunya sampai masalahnya akhirnya terselesaikan, level seperti itu pun dianggap memadai