- Alberto Fortin, software engineer dengan pengalaman 15 tahun, menaruh harapan besar pada adopsi LLM (large language model), tetapi dalam lingkungan produksi ia mengalami berbagai keterbatasan
- Saat membangun ulang infrastruktur berbasis Go dan ClickHouse, ia merasakan langsung sisi nyata dan ilusi AI, serta merasa bahwa bahkan dengan peningkatan model, masalah inti masih belum terselesaikan dengan baik
- Ia menunjukkan bahwa ada ilusi peningkatan produktivitas, padahal pada praktiknya bug dan masalah tak terduga justru bertambah
- Ia menekankan pelajaran bahwa LLM harus dipandang sebagai asisten (assistant), dan desain serta keputusan inti harus tetap dilakukan sendiri oleh developer
- "AI memang revolusioner, tetapi belum sempurna, jadi pemanfaatan yang seimbang dan pemahaman realistis atas kenyataan tetap diperlukan"
Pengalaman dan refleksi Alberto Fortin tentang LLM
- Software engineer Alberto Fortin yang memiliki pengalaman 15 tahun aktif mengadopsi LLM dalam pekerjaan pengembangan dengan ekspektasi tinggi
- Dalam proses membangun ulang infrastruktur menggunakan Go dan ClickHouse, ia menghadapi berbagai tantangan dan batasan, lalu menulis posting blog tentang kesenjangan antara AI dan pengembangan nyata
- Setelah itu, lewat analisis tambahan terbaru, ia juga memverifikasi apakah model terbaru seperti Claude Opus 4 telah menyelesaikan masalah-masalah tersebut
- Pengalaman Alberto memberikan pelajaran praktis bagi engineer yang mempertimbangkan adopsi LLM di lingkungan kerja nyata, sekaligus menawarkan sudut pandang realistis tentang bagian mana alat ini memberi nilai, dan di mana batasannya berada
Kutipan utama Alberto tentang pengalaman dengan LLM
"Saya benar-benar terkejut karena ternyata masalahnya bukan sekadar perilaku yang salah atau fitur yang tidak berjalan. Sebagai developer yang harus memelihara kode ini selama beberapa tahun ke depan, kodenya harus cukup rapi."
"Masalahnya terasa seperti akan segera selesai, tetapi pada akhirnya error baru muncul lagi berikutnya, dan pengalaman menghabiskan sekitar 2 minggu lagi untuk memperbaikinya terus berulang."
"Jika output error diberikan ke LLM, memang akan muncul jawaban baru, tetapi sering kali ia justru membuat sesuatu menjadi lebih rumit atau merusak bagian lain."
Kesadaran tentang ekspektasi berlebihan terhadap LLM
"Saat pertama kali menggunakan fitur kecil seperti autocomplete awal, semua developer merasa takjub. Rasanya seperti alat itu membaca pikiran saya, sehingga ekspektasi mudah membesar."
"Terasa seolah-olah produktivitas pengembangan bisa naik 10 kali lipat, tetapi pada kenyataannya ada kecenderungan untuk memiliki ekspektasi sebesar itu terlalu cepat."
Menata ulang peran dan ekspektasi
"Perbedaan terbesarnya adalah perubahan dalam memandang peran. Saya adalah arsitek sekaligus developer senior, dan LLM hanyalah asisten saya. Saya yang membuat rencana, dan LLM mengambil peran pendukung."
"Setelah kehilangan kepercayaan, saya tidak lagi menyerahkan fitur penting kepadanya. Saya hanya memanfaatkannya untuk unit kecil seperti refactoring."
"Saya mulai memperbaiki bug sendiri. Jika kita benar-benar memahami codebase, menyelesaikan masalah secara langsung itu jauh lebih cepat dan efisien."
Perubahan cara pandang terhadap LLM dan saran
"Sebagai developer senior, saya mengakui pada diri sendiri bahwa jika adopsi LLM tidak cocok, itu bukan berarti kemampuan saya kurang. Intinya adalah mempertahankan cara kerja yang sudah ada sambil menggunakan AI secara pendukung."
"Memang benar teknologi ini telah maju satu tahap, tetapi masih belum mencapai tahap berikutnya. Pengambilan keputusan dan arsitektur tetap harus ditangani manusia."
"Revolusi AI memang luar biasa, tetapi saat ini kita membutuhkan ekspektasi yang seimbang dan realistis."
2 komentar
> https://id.news.hada.io/topic?id=20955
Komentar Hacker News
Alasan terasa seperti menghabiskan terlalu banyak waktu di HN adalah karena di hampir semua tulisan dan komentar, cerita yang sama terus diulang. LLM memang menarik, tetapi kode yang dihasilkan terasa rumit dan tidak punya rasa kepemilikan; karena strukturnya tidak sepenuhnya masuk ke kepala seperti kode yang kita tulis sendiri, kode itu jadi sulit dirawat. Untuk skrip pendek yang memang tidak akan dipelihara, LLM cukup berguna, tetapi untuk proyek besar justru bermasalah. Di sisi lain, ada juga orang-orang yang mengatakan workflow yang membagi dan menggabungkan berbagai tugas dengan mengerahkan banyak agen LLM itu keren, tetapi mereka tidak pernah benar-benar menunjukkan kodenya dan kesannya hanya pamer
Menurut saya ringkasan ini benar-benar menangkap inti persoalannya. LLM memang sangat meningkatkan kecepatan pengembangan, tetapi karena saya tidak benar-benar memahami keseluruhan kode, jadi sulit mengetahui kapan dan di bagian mana masalah muncul. Rasanya seperti developer baru yang sedang beradaptasi dengan proyeknya sendiri. Karena itu saya sering commit kode, lalu secara berkala meminta LLM menjelaskan lagi kodenya. Dalam proses ini, LLM juga sering menemukan bug-nya sendiri. Untuk pekerjaan dengan cakupan sempit seperti analisis data, ini cukup bisa dikelola sambil tetap melaju cepat. Sebaliknya, kalau tidak punya kemampuan dan kebiasaan untuk memanfaatkan LLM dengan benar di codebase besar, hasilnya mudah berantakan. Menulis prompt, mengelola konteks, mengatur tempo, mengorganisasi pekerjaan, dan meninjau hasil LLM dengan akurat adalah kemampuan wajib untuk memanfaatkan LLM. Belum ada yang benar-benar mengajarkan ini secara formal, jadi semua orang masih belajar lewat trial and error. Meski begitu, setelah merasakan manfaatnya, sulit kembali ke cara lama. Pekerjaan yang merepotkan atau berulang bisa diserahkan ke LLM. Setelah lebih dari 20 tahun ngoding, kesabaran saya juga tidak seperti dulu lagi, dan ide yang saya belum terlalu paham cara mengimplementasikannya pun bisa dikerjakan jauh lebih efisien dengan bantuan LLM
Saya suka cara memandang pemrograman sebagai proses "membangun teori". Lihat Programming as Theory Building. Saya tidak anti terhadap penggunaan AI itu sendiri. Namun saya tidak setuju dengan sikap yang melepas tanggung jawab atas hasil kode yang dihasilkan. Seperti saat memakai alat seperti grep, hasil yang diperoleh lewat alat tetap harus ditangani dengan penuh tanggung jawab agar bermakna. Apalagi untuk kode yang dihasilkan; ini bukan masalah yang selesai hanya dengan disclaimer
Saya paham rasa lelah melihat tulisan tentang AI. Memang benar pendapat soal ini terbelah. Meski begitu, ada juga contoh orang yang benar-benar membuka kode mereka. Armin Ronacher, pembuat Flask/Jinja2/Sentry, mengunggah video workflow di YouTube dan perkenalan library AI buatannya sendiri, dan saya sendiri membuat sekitar 50%~80% proyek open source saya dengan AI. Lihat cijene-api
Rasanya basis pengguna terbagi seperti kurva lonceng. Di satu sisi, ada pengguna yang kewalahan karena LLM mengeluarkan terlalu banyak kode dengan gayanya sendiri, sehingga konteksnya tidak benar-benar masuk ke kepala mereka. Sebaliknya, bagi pengguna yang tadinya tidak mungkin mengimplementasikan sesuatu sendirian, LLM membuka jalan untuk mencoba membuat apa pun. Lalu di sisi lain ada pengguna yang sebenarnya bisa mengimplementasikan sendiri secara perlahan, tetapi dengan LLM mereka memanfaatkannya seperti pasukan developer junior, cukup fokus mengingat gambaran algoritme tingkat tinggi sambil merakit proyek yang jauh lebih besar dengan cepat
Menurut saya ini tidak jauh berbeda dari bekerja di codebase besar yang dikerjakan lebih dari 25 developer sekaligus. Organisasi saya punya 160 engineer yang menangani frontend dan middle tier, dan kami selalu harus mengobrak-abrik kode tanpa rasa kepemilikan sambil sering melihat nama kontraktor dari 3 tahun lalu di git blame. LLM tampaknya cocok untuk skala kecil, tidak terlalu cocok untuk skala menengah, lalu kembali cocok saat dipakai sebagai modul kecil dalam proyek besar
LLM sangat membantu saya mencapai tujuan, tetapi rasanya juga menurunkan kemampuan saya untuk benar-benar memprogram sendiri. Rasanya seperti steroid: otot cepat membesar, tetapi efek sampingnya banyak, dan begitu dihentikan semuanya bisa runtuh seketika. Perusahaan hanya peduli pada hasil cepat, bukan kesehatan jangka panjang, jadi gejala ini makin parah. Saya mulai memakainya dengan lebih terukur dan menjaga batas yang wajar
Berkat LLM, rasanya banyak developer melupakan pelajaran yang ditekankan dalam "Simple Made Easy". Kode yang dibuat LLM sangat unggul dalam menghasilkan 'Ball of Mud' (kode amburadul yang kompleks, sulit direfactor, dan susah dirawat). Kekuatan yang sebenarnya adalah memecah masalah kompleks menjadi bagian-bagian kecil, membuat tiap komponen kecil bekerja secara sederhana, lalu membiarkan interaksi di antara komponen itu mewujudkan kompleksitas. Jika tiap komponen sederhana, pemahaman, debugging, dan prediksi performa jadi lebih mudah. Kalau suatu saat LLM benar-benar mampu mengikuti prinsip ini dengan baik, mungkin saat itulah developer benar-benar tidak lagi dibutuhkan
Sebenarnya kita bisa langsung memberi tahu LLM arah yang kita inginkan. Perbedaan antara orang yang merasa LLM berguna dan yang tidak adalah apakah mereka memahami kekuatan dan kelemahan LLM, serta bisa memperkirakan bahwa kualitas hasil akan berubah tergantung input-nya (prompt). Misalnya, saya suka meminta LLM membantu memecah masalah kompleks untuk memastikan tidak ada bagian yang saya lewatkan, lalu setelah itu menyerahkan implementasi spesifik. Saya tidak pernah memintanya menghasilkan seluruh proyek besar tanpa arahan apa pun
Masalah 'Ball of Mud' bukan hanya terjadi di kode. Di tempat kerja saya juga ada pemimpin yang mendorong agar "AI diterima secara agresif", dan saya pernah melihat gagasan untuk menjalankan sistem deployment dan operasi yang rumit dengan AI. Pada akhirnya itu berarti menaruh black box kompleks di atas sistem yang sudah kompleks, dengan logika "untuk memahami black box ini kita butuh black box baru", dan menurut saya itu tidak masuk akal. Suasana yang menekan di organisasi juga kadang membuat saya merasa seolah-olah saya yang aneh karena berpikir begitu
Saya juga bertanya-tanya, kalau LLM benar-benar sempurna, apakah developer benar-benar akan tidak dibutuhkan lagi. Rasanya tidak ada orang yang benar-benar ingin LLM berjalan 24/7 seperti "mesin penghasil" software tanpa henti. Pada akhirnya tetap dibutuhkan orang yang bisa memecah masalah, menemukan software yang benar-benar dibutuhkan, lalu membuatnya. Seperti hari ini kita menyebut mereka software developer
Pada akhirnya saya juga sampai pada kesimpulan yang mirip. LLM kurang bagus jika dipakai untuk mengisi seluruh codebase dalam bentuk autocomplete. Masalahnya adalah model mental tentang apa yang ada di mana dan melakukan apa menghilang dari kepala saya. Jauh lebih efisien memakai LLM sebagai StackOverflow yang dipersonalisasi, hanya untuk menjelaskan kata kunci, merangkum konsep yang belum saya pahami, atau memberi arah, sementara implementasi nyata dan pengambilan keputusan tetap saya lakukan sendiri
Saya juga memakainya seperti itu, tetapi cursor terus-menerus dengan gigih menyarankan perubahan kode. Saya penasaran apakah ada trik agar dia hanya introspect tanpa menyentuh isi codebase
Dalam kasus saya justru berbeda. Kalau saya selalu meninjau kode yang diajukan LLM dengan teliti, saya bisa tahu cukup jelas apa yang ada di mana dan bagaimana semuanya saling berinteraksi
Saya juga sedang banyak mengurangi frekuensi pemakaian. Cukup sering jawaban LLM itu salah. Jadi belakangan saya hanya menanyakan kira-kira harus mencari di manual atau dokumentasi yang mana, lalu isi nyatanya saya cek sendiri. Cara ini membantu melatih kemampuan memahami lokasi informasi, sekaligus mengurangi ketergantungan pada search engine dan LLM. LLM tetap hanya alat, dan tingkat akurasinya juga tidak terlalu tinggi
Ada satu hal yang belum disebut di mana pun, yaitu bahwa LLM kadang justru bisa menurunkan produktivitas. Kalau dia menuntun kita ke arah yang salah dengan jawaban yang terdengar meyakinkan, waktu yang terbuang bisa sangat besar. Secara keseluruhan memang sering membantu, tetapi "memeriksa dasar/rujukan" itu penting, dan cukup sering juga implementasi langsung sendiri justru lebih cepat
Batasan LLM itu jelas. Sangat kuat, tetapi sulit melakukan lompatan kreatif seperti manusia. Misalnya, untuk pertanyaan "Di Android tidak bisa bind ke port di bawah 1000, lalu bagaimana menjalankan web server?" Claude dan Gemini sama-sama hanya memberi tiga solusi masuk akal berikut: 1) reverse proxy 2) rooting 3) menaikkan nomor port. Solusi yang sebenarnya saya cari adalah HTTPS RR record (referensi terkait). Keduanya sebenarnya tahu spesifikasi ini, tetapi tidak bisa menerapkannya ke situasi tersebut. Saya harus menambahkan konteks sendiri dulu baru jawabannya keluar
Sebenarnya menurut saya tidak aneh kalau LLM tidak merekomendasikannya. Sulit juga mengharapkan mereka menyarankan spesifikasi terbaru yang bahkan belum didukung resmi di Chrome, dan saya sendiri mungkin juga tidak akan terpikir sejauh itu
Informasi ini juga saya catat. Belakangan, setelah benar-benar bercakap-cakap dengan LLM, saya merasa stres berkurang kalau memperlakukannya sedikit seperti manusia. Misalnya saat menulis kode dengan cursor lalu saya menunjukkan "bagian ini terlewat", saya jadi berpikir saya sendiri pun bisa membuat kesalahan yang sama. Saya juga pernah memakai LLM sebagai partner 'klub buku' dan 'klub film' untuk mendiskusikan dua film, dan meskipun ada kesalahan seperti salah menjelaskan situasi karakter, percakapannya jadi jauh lebih luwes kalau saya tidak menuntut akurasi 100% dan memberi toleransi yang sama seperti saat berbicara dengan manusia. Menurut saya bagus juga bersikap positif saat berbicara dengan AI
Saya pernah dengar SRV record, tapi rasanya hampir tidak pernah dipakai; HTTPS RR justru baru pertama kali saya tahu. Dukungan nyatanya juga tampaknya lebih baik daripada SRV
Ini masalah klasik LLM: "baru menambahkan suatu solusi ke daftar setelah kita sendiri menyebut jawaban yang benar"
Kalau tujuan dan batasannya dijelaskan dengan cukup jelas, ChatGPT o3 memang bisa mengusulkan solusi ini. Namun dia juga menjelaskan dengan tepat bahwa itu hanya berfungsi di browser terbaru. Contoh referensi
Saya cukup sering memakai ChatGPT Enterprise, dan seiring waktu saya belajar beberapa hal. Jangan memasukkan kode dalam jumlah besar; hasilnya jauh lebih baik kalau ditangani per fungsi yang sangat independen atau per kelas kecil. Untuk permintaan pembuatan atau pelengkapan kode, sekitar 10% kasus masih bisa diselamatkan dengan instruksi tambahan meski kualitasnya menurun, tetapi sekitar 25% kasus kualitasnya tetap tidak naik seterang apa pun dijelaskan. Dalam situasi seperti itu, lebih baik langsung diabaikan dan dikerjakan sendiri. Sebaliknya, untuk review kode yang baru ditulis, ini cukup berguna. Setengah komentarnya tidak berguna, sebagian lagi abu-abu, tetapi kadang benar-benar berhasil menunjukkan bug atau isu penting. Sebaiknya jangan memasukkan banyak halaman sekaligus; pecah-pecah saat memakainya. Untuk bidang niche seperti HLSL shader atau SIMD, jawabannya hampir tidak ada karena data latihnya kurang. Secara keseluruhan ini membantu meningkatkan kualitas kode. Karena kode terus dipecah dan divalidasi dalam unit-unit kecil, struktur arsitektur seperti fungsi/kelas/modul ikut terbelah lebih rapi sehingga kualitas keseluruhan membaik
Untuk pengembangan software jangka panjang, hal paling menarik adalah memakai LLM sebagai 'generator boilerplate tingkat lanjut'. Untuk pekerjaan sekali pakai yang tidak perlu dipelihara, ini memang sudah bagus, tetapi bahkan dalam pengembangan jangka panjang pun sangat berguna untuk kode berulang yang sulit diabstraksikan, misalnya kode test. Awalnya saya agak menolak, tetapi sekarang sangat puas. Bagian yang membosankan dan repetitif berubah menjadi semacam permainan baru yang menarik berupa 'optimasi prompt', dan produktivitas saya juga meningkat besar. Menulis prompt dan mereview kode selesai jauh lebih cepat daripada mengerjakan pekerjaan mekanis secara langsung. Hasilnya, yang tersisa hanya bagian menarik yang benar-benar butuh dipikirkan
Pada akhirnya saya menyadari bahwa LLM, bukan hanya untuk coding tetapi juga untuk banyak pekerjaan lain, mirip seperti 'diet populer' yang sedang tren. Semua orang menginginkan solusi yang cepat dan mudah, tetapi pada akhirnya tidak ada jalan pintas. Kenyamanan selalu datang dengan trade-off, dan pada suatu saat semua orang akan menerima kenyataan itu