- Klaim bahwa AI meningkatkan produktivitas insinyur 10 hingga 100 kali lipat tidak realistis
- Saat benar-benar menggunakan alat coding AI secara mendalam, peningkatan efisiensi ternyata terbatas, dan lonjakan produktivitas hanya terjadi sementara pada tugas yang berulang dan sederhana
- Bottleneck dalam pengembangan perangkat lunak (code review, kolaborasi, perencanaan, dll.) tidak bisa diatasi dengan AI, sehingga peningkatan 10x untuk keseluruhan pekerjaan tidak mungkin terjadi
- Mitos insinyur 10x muncul dari berbagai motif seperti distorsi angka, kepentingan para pelaku industri, atau pemicu kecemasan di dalam organisasi
- Mempertahankan cara mengembangkan software yang cocok untuk diri sendiri dan rasa senang dalam bekerja akan menghasilkan hasil yang lebih baik dalam jangka panjang serta budaya organisasi yang sehat
Skeptisisme terhadap mitos insinyur AI 10x
Kecemasan soal produktivitas dan pengalaman nyata memakai alat AI
- Di LinkedIn, Twitter, dan platform lain, narasi bahwa AI dapat meningkatkan produktivitas insinyur 10 hingga 100 kali lipat terus menyebar, membuat banyak developer merasa cemas akan tertinggal
- Penulis juga telah mencoba berbagai agen pembuat kode AI (Claude Code, Cursor, Roo Code, Zed, dll.) dalam pekerjaan nyata, tetapi meskipun nyaman untuk tugas sederhana yang berulang, alat tersebut tidak membawa perubahan mendasar pada pekerjaan kompleks di dunia nyata
- Kode berulang (boilerplate) di JavaScript (terutama React) bisa ditulis dengan cepat
- Namun, untuk standar codebase internal atau library yang tidak umum, AI tidak mampu mengikutinya dengan baik
- Untuk bahasa seperti Terraform, performa AI menurun karena tidak cukup familier
- Fenomena halusinasi (hallucination) dapat membuat AI menciptakan library yang sebenarnya tidak ada dan bahkan memicu kerentanan keamanan
- Kemampuan AI memahami konteks masih terbatas. Semakin kompleks codebase yang nyata, semakin sering muncul prompt berulang, error, dan pemborosan waktu
- Pada akhirnya, penulis memakai AI untuk skrip kecil atau tugas noninti, sementara tugas yang kompleks atau penting tetap ditangani langsung
Masalah dalam mengukur produktivitas pengembangan perangkat lunak
- Klaim bahwa produktivitas bisa naik 10 hingga 100 kali lipat dengan AI adalah angka yang jauh dari kenyataan
- Produktivitas 10x atau 100x bukan sekadar berarti jumlah baris kode bertambah, tetapi bahwa pekerjaan yang biasanya butuh 3 bulan (seluruh pengembangan, code review, QA, dll.) selesai dalam 1,5 minggu
- Dalam pengembangan perangkat lunak ada banyak bottleneck seperti perencanaan, estimasi story point, perbaikan bug, code review, menunggu deployment, testing, dan QA
- Agar target itu tercapai, setiap proses tersebut harus menjadi 10 kali lebih cepat dengan rasio yang sama
- Pada kenyataannya, waktu untuk menulis kode itu sendiri tidak besar; banyak waktu justru dipakai untuk memahami, merancang, meninjau, dan berkomunikasi
- Secara realistis, code review, kolaborasi, komunikasi, dan QA tidak bisa dipercepat dengan AI
- Bottleneck nyata dalam pekerjaan engineering ada pada manusia, proses, dan komunikasi
- LLM (large language model) memang mengurangi waktu mengetik di keyboard, tetapi waktu untuk kualitas kode, testing, dan review tetap dibutuhkan
- Walaupun AI bisa sementara meningkatkan kecepatan penulisan kode, kenaikan tingkat error, standar kode yang kurang baik, serta kebutuhan untuk melakukan prompt ulang membuatnya tidak memberi dampak menentukan pada peningkatan produktivitas secara keseluruhan
- Produktivitas 10x secara realistis adalah target yang nyaris mustahil
Wujud nyata dan batasan insinyur 10x
- Soal keberadaan "insinyur 10x", penulis menilai hal itu mungkin terjadi secara sementara dan terbatas
- Alasan terbesar adalah kemampuan mencegah pekerjaan yang tidak perlu yang terakumulasi dari pengalaman, seperti mencegah pengembangan yang tak diperlukan sejak tahap perencanaan, memperbaiki pengalaman pengembangan, atau dokumentasi
- Namun, tidak semua insinyur menghadapi situasi seperti ini setiap saat
- Insinyur yang sangat menonjol memang bisa mencegah pekerjaan tak perlu atau meningkatkan efisiensi organisasi secara keseluruhan lewat perbaikan sistem, tetapi secara praktik hampir tidak ada kasus yang secara konsisten menghasilkan kinerja 10x
- Alat coding AI tidak banyak membantu dalam mencegah pekerjaan yang tidak perlu
- Bahkan, rekomendasi AI bisa membuat implementasi menjadi berlebihan atau menyarankan arsitektur yang keliru
- Coding cepat tidak selalu berarti seorang insinyur itu baik
Latar belakang dan motif mitos AI 10x
Sebagian besar klaim tentang "produktivitas 10x" berasal dari faktor-faktor berikut
- Insinyur yang berniat baik tetapi salah mengukur
- Dengan alat AI, seseorang bisa merasakan ledakan efisiensi sesaat (misalnya: membuat aturan kustom ESLint secara otomatis)
- Namun, ketika pekerjaan seperti itu berulang, selisih produktivitas pada akhirnya menyusut tajam
- Kekaguman teknis dan adaptasi terhadap lingkungan baru pada awalnya bisa menimbulkan ilusi efisiensi yang berlebihan
- Insentif dan para pemangku kepentingan
- Pendiri startup AI, investor, dan pihak lain sering mengutip angka yang dibesar-besarkan demi keberhasilan bisnis
- Insinyur maupun manajemen juga bisa menyebut produktivitas yang dibesar-besarkan demi memenuhi ekspektasi di dalam organisasi
- Tujuan yang buruk
- Sebagian manajemen menyebarkan klaim yang dilebih-lebihkan untuk menciptakan kecemasan pada insinyur dan mencegah gejolak internal organisasi, seperti pindah kerja atau permintaan kenaikan gaji
- Ketakutan bahwa AI akan membuat siapa pun mudah tergantikan terus berulang secara berkala (mirip dengan perdebatan bootcamp coding di masa lalu)
Hasil AI dalam open source dan proyek nyata di lapangan
- Sebagian besar contoh nyata peningkatan produktivitas AI memiliki jarak antara penulis klaim dan insinyur yang disebut mengalami peningkatan produktivitas.
- Kasus penggunaan alat AI yang benar-benar dibuktikan langsung oleh insinyur menunjukkan gambaran yang realistis dan tidak berlebihan
- Hasil penggunaan AI di proyek open source sering kali justru tampil di bawah ekspektasi atau bahkan sebagai contoh kegagalan
- Dalam demo publik atau contoh dari insinyur sungguhan, AI kadang tampak seperti sulap, tetapi sebagian besar tetap tidak jauh berbeda dari "generator teks" yang sudah ada
Nilai yang lebih penting daripada "produktivitas" - mempertahankan cara mengembangkan software yang sesuai dengan diri sendiri
- AI kadang memungkinkan penulisan kode lebih cepat, tetapi penulis tetap lebih mengutamakan kesenangan dalam coding itu sendiri
- Jika Anda tidak menyukai coding dengan AI atau tidak merasa itu menyenangkan, tidak masalah untuk melepaskan sebagian produktivitas
- Sekalipun harus menerima tingkat inefisiensi tertentu, bekerja dengan cara yang cocok untuk diri sendiri akan menghasilkan keadaan yang lebih sehat dan hasil yang lebih baik dalam jangka panjang
- Saat bekerja dengan senang, kita bisa memiliki kemampuan pemecahan masalah, perancangan, dan kolaborasi dengan rekan yang lebih baik
- Rasa senang dan keterlibatan jauh lebih penting bagi produktivitas jangka panjang dan kualitas kode, sedangkan mengejar produktivitas secara paksa justru meningkatkan risiko burnout
- Sebaliknya, jika coding dengan AI benar-benar menyenangkan dan membantu, silakan gunakan secara aktif
Saran untuk budaya organisasi yang sehat
- Saat mengadopsi alat AI, menciptakan ekspektasi yang tidak realistis dan kecemasan pada semua insinyur justru merugikan produktivitas organisasi
- Obsesi untuk memaksimalkan produktivitas akan berujung pada penurunan kualitas, memburuknya codebase, dan kerugian jangka panjang
- Lebih baik memberi insinyur otonomi dan kepercayaan yang cukup, lalu membiarkan pemanfaatan AI dipilih sesuai cara yang paling cocok bagi masing-masing orang
- Organisasi sebaiknya menyediakan kesempatan untuk menggunakan AI, tetapi yang penting adalah suasana yang menjamin otonomi
- Jika LLM dan inovasi coding AI benar-benar memberi produktivitas 10x, para developer akan menemukannya sendiri secara alami
Kesimpulan
- Revolusi insinyur 10x karena AI lebih dekat ke mitos, dan pada praktiknya tidak ada resep rahasia yang sedang terlewatkan
- Kepercayaan pada kemampuan dan cara kerja diri sendiri adalah hal yang paling penting
- SNS (terutama LinkedIn dan Twitter) memperbesar mitos yang dilebih-lebihkan, sehingga boleh saja diabaikan
10 komentar
Apakah memang ada orang yang menafsirkan 10x benar-benar sebagai 10 kali lipat? Saya tentu menganggapnya sebagai ungkapan berlebihan untuk marketing/PR diri, jadi agak bingung melihat orang menanggapinya dengan serius.
Meski tidak sampai 10x, cukup banyak organisasi yang punya keyakinan serius terhadap Nx. Mereka berharap bisa mengganti biaya tenaga kerja dengan biaya AI dan mendapatkan hasil yang lebih besar dari itu…
Bukan berarti itu ilusi tanpa dasar, karena hal-hal seperti keinginan PM untuk mencoba
pocsederhana atau alat untuk pekerjaan berulang memang bisa dibuat dengan cepat.Jadi, apakah ada pengembang yang benar-benar percaya pada ini… menurut saya, tergantung situasi yang dihadapi masing-masing, suasana industri saat ini memang cukup kuat sampai-sampai wajar kalau orang merasa cemas.
Menurut saya, diskusi serius seperti ini perlu dilakukan, setidaknya demi komunikasi dengan pihak non-teknis dan para pimpinan organisasi.
Tentu saja saya tidak menyangkal hal-hal yang membantu produktivitas. (Pada tingkat AI saat ini) menurut saya klaim 10x jelas tidak masuk akal, dan karena isi tulisan aslinya memang secara tegas mengatakan "tidak bisa 10 kali lipat", saya menulis komentar ini karena merasa itu cukup janggal, tetapi sepertinya pilihan kata saya memang kurang baik.
Karena produktivitas AI seperti yang Anda katakan adalah ungkapan yang dibesar-besarkan untuk pemasaran/PR diri, saya juga merasa tulisan tersebut adalah artikel yang mengandung sedikit berlebihan.
Karena itu, isi seperti "apakah benar ada orang yang menafsirkan 10x secara harfiah sebagai 10 kali lipat" terasa seperti mencari-cari celah, jadi mungkin itulah yang membuat orang merasa kurang suka.
Sepertinya Anda membalas tanpa membaca artikel aslinya; padahal di mana pun dalam artikel itu tidak ada nada yang terlalu serius...
Penggunaan yang juga "puluhan kali lipat" dibanding Viewtrap pada DataTube.tv, layanan pencari ide viral YouTube yang Anda kembangkan, tentu juga merupakan ungkapan yang dilebih-lebihkan untuk keperluan pemasaran/PR pribadi, bukan?
Entah karena ini dunia online atau memang Anda biasanya seperti itu, kebanyakan komentar yang Anda tulis terasa dibuat dari sudut pandang yang kritis.
Semoga Anda bisa melihatnya dengan sudut pandang yang sedikit lebih terbuka.
Saya merasa kalau ada kegaduhan berlebihan soal AI, pasti ada juga kebalikannya, jadi saya sendiri tidak punya banyak pikiran soal isi artikelnya...
Komentar ini bikin merinding; sampai-sampai rasanya menakutkan bahwa Anda baru mendaftar hari ini lalu mencari tulisan-tulisan lama orang dan memasang komentar lagi
Melihat komentar yang Anda tulis dan riwayat saya sendiri, rasanya tidak ada satu pun komentar yang benar-benar memalukan. Apakah masalahnya adalah melihat sesuatu dari sudut pandang kritis? Apakah hidup yang baik berarti tidak menulis komentar apa pun seperti Anda...
Hah? Angka 10x itu bahkan sudah dikonversi ke jumlah bulan... kalau Anda terganggu dengan ungkapan seperti “terlalu serius”, saya bisa memahaminya. Puluhan kali lipat milik Datatube itu adalah angka kuantitatif. Ya, bagaimanapun juga sekarang memang tidak sedang dioperasikan...
Komentar Hacker News
Saya tidak paham mengapa hanya bidang rekayasa perangkat lunak yang begitu terobsesi pada mitos produktivitas "10x"; di rekayasa mesin, listrik, konstruksi, atau kimia, konsep ini tidak ada
Insinyur yang hebat adalah orang yang mampu mengurangi risiko dan merancang sistem di bawah berbagai batasan
Desain adalah proses memahami domain melalui model, serta memahami cakupan validitas dan batasannya
Tidak ada yang namanya "10x", yang ada hanya bertanggung jawab atas sistem yang baik
Jika memang ada insinyur perangkat lunak "10x", orang itu seharusnya adalah orang yang mencegah insiden seperti kebocoran data; saya justru ingin melihat insiden seperti itu berkurang 10 kali lipat
Saya juga setuju dengan banyak bagian dari tulisan ini
Saya penggemar besar pengembangan yang memanfaatkan alat AI, tetapi klaim produktivitas 10x tidak pernah terasa meyakinkan
Berkat LLM, beberapa pekerjaan seperti mengetik kode memang menjadi 2~5 kali lebih cepat, tetapi itu hanya sebagian dari keseluruhan pekerjaan
Memang banyak insinyur merasa tugas tertentu bisa 20~50% lebih cepat, tetapi saya setuju bahwa itu tidak otomatis berarti produktivitas total naik 20% atau menjadi 10x
Tentu saja, orang yang benar-benar sangat mahir memakai AI mungkin merasakan peningkatan produktivitas lebih dari 0,2x, tetapi karena kompleksitas hakiki dalam pengembangan perangkat lunak, 10x bagi kebanyakan orang tetap tidak realistis
Saat memakai AI, saya tetap harus terus mengawasinya di samping saya, jadi rasanya tidak terlalu efisien
Kadang saran copilot pas sekali dengan yang ada di kepala saya dan itu mengagumkan, tetapi secara keseluruhan rasanya bukan seperti junior developer yang sangat terampil, melainkan seperti "senior developer mabuk" yang sulit diarahkan
Setengah dari kode yang dihasilkan bahkan tidak bisa di-compile, dan yang berhasil di-compile pun sering tidak bekerja dengan benar
Dalam pengalaman saya, AI tidak memberi lonjakan produktivitas besar pada area baru yang sedang dibuat (creation), tetapi sangat membantu untuk eksplorasi (discovery), belajar, memecahkan kebuntuan, dan menulis kode berulang
Namun perubahan yang sesungguhnya terjadi pada side project
Dulu saya terlalu lelah sehingga sulit meluangkan waktu untuk proyek sampingan, tetapi sekarang, walau kodenya belum sempurna, saya bisa mewujudkan ide menjadi kenyataan dengan cepat dan dengan energi mental yang lebih sedikit
Keterampilan AI engineering juga bisa saya eksperimenkan dengan bebas tanpa batasan seperti tenggat, privasi data, atau alat
Bahkan orang-orang yang disebut "insinyur 10x" tampaknya menganggap kenaikan produktivitas dari AI akan kecil saja
Developer terbaik yang saya kenal punya dua kemampuan inti: daya ingat luar biasa dan hafal detail-detail kecil dari semua bahasa/library, serta kreativitas dan kemampuan memecahkan masalah yang nyaris ajaib
Yang mengesankan adalah mereka bisa mencapai solusi yang orisinal dan rapi, paling cocok untuk masalah itu, bahkan tanpa tahu rumus atau teori segala macam
Saat pair programming dengan AI untuk mencapai solusi serupa, AI perlu mencoba dan mengulang tanpa henti, dan justru memperlambat manusia yang jenius itu
Namun spektrum kemampuan sangat beragam, jadi dari posisi saya sendiri, produktivitas 10x berkat AI juga mungkin saja terjadi
Latar belakang saya bukan software, dan karena perfeksionis saya mengembangkan sesuatu dengan sangat lambat; berkat AI saya bisa cepat membuat versi pertama yang jelek dan itu berguna untuk mewujudkan ide
Saya juga mendukung pengembangan asisten AI, dan saya pikir peningkatan kecepatan 2~10x memang bisa ada dalam beberapa situasi
Tetapi kebanyakan produktivitas "10x" dipakai secara berlebihan seolah berarti seluruh proses pengembangan fitur, dari awal sampai akhir, menjadi 10 kali lebih cepat
Secara realistis, banyak bagian dari keseluruhan proses pengembangan (di luar coding) tidak menjadi 10 kali lebih cepat
Meski begitu, di lingkungan yang benar-benar kecil atau kerja sendirian, banyak prosedur merepotkan bisa dilewati, jadi secara nyata memang ada peningkatan kecepatan besar
Dalam konteks ini, kita memasuki era ketika tim kecil dan solo developer tiba-tiba menjadi lebih kompetitif
Terima kasih untuk komentar Simon
Komentar ini benar-benar terasa seperti ditulis oleh orang yang memang membaca artikelnya
Saya mengakui bahwa pada beberapa pekerjaan yang sangat spesifik terhadap bahasa atau alat tertentu, peningkatan produktivitas 2x memang benar terjadi
Selama puluhan tahun saya memimpikan otomasi pengembangan perangkat lunak, dan rasanya LLM mewujudkan mimpi itu dengan cara yang benar-benar berbeda
CASE tool, UML, IDE, dan semacamnya dulu berjanji akan "membiarkan kita fokus pada logika yang sesungguhnya", tetapi LLM langsung menghasilkan kode yang bisa dijalankan dari bahasa alami
Banyak developer merasa ritus peralihan lama runtuh dan cemas akan tertinggal di dunia baru ini (sindrom impostor)
Kita jadi kembali bertanya apa sebenarnya yang dimaksud dengan rekayasa perangkat lunak
LLM adalah bentuk pamungkas dari CASE tool masa lalu, tetapi proses ini datang terlalu cepat, membingungkan, dan destruktif
Bahkan orang yang tidak menguasai "bahasa suci" insinyur perangkat lunak kini punya kekuatan, dan banyak insinyur jadi bergulat dengan pertanyaan mendasar: "Sebenarnya apa pekerjaan saya sekarang?"
Baru sekarang saya mengerti bagaimana perasaan para seniman saat melihat stable diffusion
Kode buatan AI pada akhirnya sering salah, penuh bug, dan sarat kebiasaan aneh atau hal-hal yang tidak perlu
Untuk memperbaiki semua masalah itu, sering kali butuh waktu yang sama seperti membuatnya sendiri
Walau mencoba berbagai model atau memperhalus prompt, rasanya kode berkualitas tinggi yang benar-benar saya inginkan masih belum terjangkau
Seperti pada stable diffusion, orang yang tidak terlalu peduli tidak sadar ada yang aneh; begitu pula orang yang tidak paham AI code sering tidak tahu ada masalah di dalamnya
Baru-baru ini saya melihat kode milik rekan kerja terasa aneh, dan setelah dicek ternyata debugger pun tidak berjalan dan masalahnya sangat banyak; rekan itu lalu mengaku "saya cuma ngoding pakai feeling"
Melihat dunia belakangan ini, saya merasa modal terus menghancurkan tenaga kerja
Upah rendah, kondisi kerja buruk, pengawasan, tekanan metrik, perusahaan tak etis, kontrak jangka pendek, dan realitas kebanyakan pekerja terus memburuk
Selama ini kita terlalu terlindungi sehingga tidak benar-benar merasakan kenyataan itu, tetapi sekarang kita juga sedang berhadapan dengan masa depan yang tidak stabil
"Software engineering" pada akhirnya akan berubah menjadi pekerjaan memperbaiki vibe
Banyak pekerjaan memang bisa digantikan software, tetapi ada kenyataan bahwa para manajer enggan mempekerjakan SWE bila nilai yang sudah terbukti tidak bisa ditunjukkan
Dengan adopsi AI, para manajer akan menghasilkan banyak kode yang tak mereka pahami, lalu tiga tahun kemudian saat semuanya rusak mereka akan memanggil SWE lagi untuk memperbaikinya
Justru ada kemungkinan pekerjaan yang sulit dan bernilai tinggi untuk memperbaiki "masalah yang tidak bisa diselesaikan AI" akan semakin banyak
LLM membuat kode langsung tanpa model formal atau diagram
Justru saya ingin AI membuatkan desain formal atau diagram seperti itu
Alat seperti itu akan membantu pemahaman kode dan memperjelas desain
Saya berharap AI juga bisa mendukung bagian ini
Hambatan dalam pengembangan perangkat lunak bukan kecepatan mengetik atau generasi, melainkan verifikasi dan pemahaman
Bahkan jika LLM bekerja sempurna tanpa halusinasi omong kosong, developer yang bertanggung jawab tetap harus meninjau kode satu per satu
Karena manusia tidak bisa memahami kode 10 kali lebih cepat, dalam praktiknya justru bisa lebih lama untuk menelusuri ulang kode yang dihasilkan otomatis dan menguraikan maksud tersembunyinya
Istilah "produktivitas 10x" hanya berlaku bila output diserahkan mentah-mentah tanpa verifikasi kode, atau saat menangani kode yang sangat sederhana di mana kesalahan tidak penting
Untuk software produksi yang kesalahannya bisa menjadi bencana, kapasitas kognitif manusia tetap menjadi bottleneck; LLM hanya memindahkan beban dari menulis ke meninjau, sehingga malah berdampak negatif pada produktivitas keseluruhan
Diskusi ini terasa memperlihatkan produktivitas para developer rata-rata itu sendiri
Jika memahami teknologi proyek dan mampu membagi pekerjaan dengan baik, kita bisa memperkirakan kompleksitas kode lebih dulu lalu memberi tugas ke AI dalam unit yang sesuai
AI bukan sihir; ada batas atas pada kompleksitas yang bisa ditulisnya
Jika kita memahami batas itu dan memahami teknologi proyek yang sedang dibuat, kita bisa memecah komponen hingga di bawah batas tersebut lalu menginstruksikan AI
Pendekatan ini bekerja cukup baik
Ini hampir tautologi
Kalau instruksinya disederhanakan agar AI bekerja dengan baik, ya tentu hasilnya akan lebih baik
Tetapi kenyataannya kita harus menyuapi AI dengan petunjuk yang terlalu rinci, dan bahkan setelah itu pun hasilnya tetap harus diperiksa ulang secara teliti karena tidak bisa dipercaya
Justru pekerjaan memecah masalah jadi bagian-bagian kecil dan menjelaskannya ke AI bisa lebih merepotkan daripada menulis kodenya langsung
Kalau AI kebetulan benar sekali jalan memang efisien, tetapi dalam kenyataan sering perlu revisi berulang atau akhirnya dibuat ulang dari awal sehingga waktu dan tenaga terbuang
Kode AI yang terstruktur dan terlihat rapi justru berbahaya karena sering sebenarnya salah
Bagian yang benar-benar sulit dan memakan waktu adalah merancang bagian yang kompleks
Bagian sepele bisa tinggal diinput, tetapi menyelesaikan bagian kompleks itulah yang benar-benar menghabiskan waktu
Di balik komentar ini terasa nuansa "apakah saya menganggap diri saya developer di atas rata-rata?"
Bisa juga justru sebaliknya
Developer yang kurang bagus mungkin terkagum-kagum pada hasil AI sambil terus mengirim auto PR yang tak bermakna, sedangkan developer dengan standar tinggi mungkin tidak akan terkesan pada hasil itu
Karena sulit membedakan siapa yang benar-benar dapat dipercaya tanpa pernah bekerja langsung bersama mereka, saya memilih tetap netral
AI punya batas, manusia juga punya batas
Pada akhirnya yang dibutuhkan adalah manajemen proyek yang membosankan
Jika ada requirement yang benar, desain yang layak, dan informasi yang cukup lalu dipecah menjadi unit kerja kecil, kita bahkan bisa menyuruh AI "implementasikan GitHub issue #42" lalu menonton TV sambil menunggu
Tapi kalau bilang "tolong buatkan facebook", ya tentu arahnya akan berantakan
Bidang lain tempat AI sangat membantu adalah mencari bug
Saya terutama bekerja pada simulasi numerik, dan masalah yang membuat saya buntu berhari-hari—kesalahan skala dalam rumus karena beberapa tanda kurung hilang—langsung ditemukan penyebabnya setelah saya menjelaskan file dan gejalanya ke chatgpt
Kadang AI berperan menunjukkan dengan jelas bagian yang saya lewatkan
Ini memang tidak membuat saya menjadi developer 10x, tetapi bila dipakai dengan baik dampak positifnya terasa besar
Saya juga mirip
Membuat kode dengan AI biasa saja, tetapi untuk debugging ini benar-benar lompatan produktivitas besar
Semacam "rubber duck" yang sangat pintar
(dari sudut pandang hobiis) Berkat LLM, ngoding jadi jauh lebih mudah saat larut malam ketika otak sudah tidak jalan
Saya juga menghemat sangat banyak waktu berkat AI
Buat saya rasanya ada di antara 10x dan tak terhingga
Saya tidak menganggap diri saya insinyur 10x
Alasan saya lebih produktif daripada rekan-rekan di perusahaan adalah karena saya mendesain sistem dan tidak hanya mengikuti tiket yang ambigu sesuai bunyinya
AI tidak bisa menyederhanakan rekan-rekan saya karena mereka sejak awal tidak mengubah kebiasaan membuat hal jadi rumit
AI tidak menyelesaikan masalah itu
Gaji saya di perusahaan tidak sampai 2 kali rekan kerja saya, jadi saya melihatnya seperti itu
Adopsi alat AI pun tidak akan mengubah kenyataan itu
Tulisan ini menetapkan standar "10x" yang terlalu tinggi, lalu mencatat upaya pribadi penulis untuk melampauinya
Karena itu saya rasa penulis membagi para pendukung AI menjadi tiga kelompok: orang yang salah paham, orang yang menjual sesuatu, dan manajer buruk yang memanfaatkan kecemasan
Secara pribadi saya menganggap keluhan tentang "hallucination" agak seperti sebuah "sinyal"
Saya rasa pembahasan soal halusinasi memang wajib ada
Diskusi tentang LLM terlalu sering bergerak ke dua kutub ekstrem (sama sekali tak berguna vs akan menggantikan developer)
Misalnya Claude 4 Sonnet pernah salah menjawab soal kompilasi clang dan mengatakan Godbolt yang salah
Meski begitu, sepanjang sesi itu saya tetap sangat terbantu, jadi yang penting hanya mengingat bahwa kita harus kritis terhadap hasilnya
Halusinasi itu nyata, dan kita harus selalu waspada terhadap hasilnya
Terima kasih sudah meninggalkan komentar; tulisan-tulisanmu tentang AI membantu saya mengatasi sindrom impostor
Di tulisan itu, pengelompokan hanya ditujukan pada orang-orang yang mengklaim "berhasil 10x" berturut-turut, bukan untuk semua pendukung AI secara umum
Saya penasaran apakah Anda sudah menemukan cara yang benar-benar bebas halusinasi
Khususnya di Terraform dan semacamnya, LLM masih sering mengarang properti yang sebenarnya tidak ada, dan di JS pun saat memakai library yang jarang digunakan, kekeliruannya masih sering muncul
Jika keluhan tentang "halusinasi" adalah sinyal, maka pikiran seperti itu sendiri juga sinyal…
(sanggahan singkat)
Standar 10x ini adalah pemasaran berlebihan yang umum di industri
Contoh: klaim 10x dari Sam Altman
promosi produktivitas Cursor AI
developer 10x yang ditambah AI
Misalkan seseorang yang tidak tahu cara membuat web app belajar selama 6 minggu, 4 jam per hari (120 jam), dan susah payah baru berhasil membuat satu
Kalau dengan memanfaatkan AI seperti Claude code orang itu bisa membuat web app yang sama dalam dua hari akhir pekan (12 jam), maka produktivitasnya naik 10x
Ini mirip dengan yang benar-benar terjadi pada saya
Dulu saya tidak bisa melakukan hal-hal itu karena kurang motivasi atau energi, tetapi sekarang berkat AI saya bisa menyelesaikannya selama akhir pekan
Tetapi cara pertama tetap memiliki proses belajar yang bisa membantu saat nanti ingin mengubah sesuatu lagi
Faktanya, kalau meminta AI seperti Claude Code membuat scaffolding web app di luar React, hasilnya berantakan
Orang yang tidak punya pengalaman pengembangan aplikasi tidak akan mudah membuat aplikasi yang matang hanya dalam akhir pekan
Bahkan login pengguna pertama saja bisa langsung rusak
Dalam jangka panjang, menurut saya hitung-hitungan itu tidak masuk akal
Dengan LLM kita memang bisa cepat membuat app di awal, tetapi lama-lama kemampuan pemeliharaan menurun, dan pada titik tertentu sistem yang makin kompleks tak lagi muat dikelola dalam “context window”
Akhirnya produktivitas justru bisa mendekati nol
Itu berarti otak dan pengalaman belajarnya sepenuhnya dialihdayakan; aplikasinya memang jadi, tetapi pertumbuhan atau pembelajarannya hampir tidak ada
Apakah Anda benar-benar berniat langsung men-deploy itu?
Secara realistis, ini tidak setara
Output developer 1x saja sulit diukur, apalagi mengalikannya jadi angka seperti itu
Saya merasa AI sangat meningkatkan "produktivitas side quest"
AI sangat cocok untuk hal-hal yang selama ini saya tunda karena malas, seperti membuat mockup, menulis test, mengekstrak library, atau membuat dokumentasi
Walau mungkin tidak mempersingkat waktu pembuatan fitur, jika memasukkan pekerjaan tambahan itu hasil akhirnya jadi sedikit lebih mendekati sempurna
Saya berharap pekerjaan tambahan ini bisa mengurangi waktu mencari bug di masa depan
(pengalaman pribadi)
Ini hanya berlaku untuk kasus saya, tetapi di perusahaan kami, kode test yang dibuat dengan LLM umumnya terlalu terikat pada kode implementasi
Penyalahgunaan pola seperti test spy juga parah
Akibatnya, banyak test yang samar karena hanya memeriksa detail implementasi internal, bukan perilaku dari sudut pandang pengguna
Test jadi terlalu sering rusak setiap kali implementasi berubah, sehingga alih-alih meningkatkan produktivitas, test justru menjadi beban
Ini bukan semata masalah LLM; developer yang dari awal memang tidak bisa menulis test dengan baik justru membuat masalah ini makin parah dengan LLM
Bagi developer yang kurang pengalaman dengan TDD dan kode test yang dirancang baik, LLM memperkuat antipola seperti ini
Ungkapan "produktivitas side quest" bagus
AI bukan "seribu luka kecil yang mematikan", melainkan terasa seperti "hidup baru yang tersusun dari seribu plester"
Saya setuju dengan konsep "side quest"
Perubahan besar bagi saya justru adalah bahwa berkat AI, saya bisa membuat tool atau fitur yang sebelumnya tidak akan saya buat tanpa AI
Bukan sekadar menghemat 2 minggu, tetapi menghasilkan sesuatu yang tadinya tidak akan ada
Ekspektasi terhadap LLM memang lebih tinggi daripada kenyataannya, tetapi dalam praktiknya tetap sangat berguna di berbagai situasi
Jika dilihat dari "tingkat zoom", hasilnya jauh lebih baik ketika pekerjaan dipecah bertahap, dari level kasar seperti "vibe coding" sampai level seperti "tolong buatkan fungsi ini"
Selain generasi kode, LLM juga efektif untuk banyak kegunaan lain seperti mempelajari teknologi baru
Jika peran saya dipenuhi rapat atau banyak tugas manajerial, bantuan dari LLM berkurang
Ke depan, saya kira LLM juga bisa dimanfaatkan untuk workflow PR, merapikan commit, dan menyusun ulang urutan kerja
Bahkan kalau cuma dipakai untuk membantah para engineer yang sering asal bilang 'tidak bisa', 'mustahil diwujudkan', rasanya efek X10 itu benar-benar mungkin terjadi.
Saya juga sudah terlalu sering melihat pemandangan orang non-developer diperlakukan seperti orang bodoh lalu segala hal langsung dibilang tidak mungkin.