Setelah Berbulan-bulan Coding dengan LLM, Saya Memutuskan untuk Kembali Menggunakan Otak Saya

• Menggunakan LLM berperforma tinggi untuk membangun infrastruktur, tetapi muncul masalah besar pada kualitas kode dan kemudahan pemeliharaan
• Karena inefisiensi AI dan hasil yang tidak konsisten, penulis merasa perlu kembali memahami kode secara langsung, melakukan riset, dan memperkuat kemampuan sendiri
• Tujuan untuk menyelesaikan proyek dengan cepat justru menyebabkan struktur kode yang kacau, duplikasi, dan ketidakkonsistenan
• Kini AI hanya dimanfaatkan secara terbatas sebagai alat bantu untuk pekerjaan berulang atau transformasi kode
• Karena penggunaan AI dapat menyebabkan penurunan feeling dalam coding dan kemampuan pemecahan masalah, penulis memilih untuk memprioritaskan penggunaan otak secara aktif

---

Pendahuluan: Upaya Membangun Infrastruktur dengan Memanfaatkan LLM

• Infrastruktur PHP+MySQL yang ada sudah mencapai batasnya, sehingga disadari perlunya infrastruktur baru
• Memilih Go dan Clickhouse, lalu melanjutkan desain dan perencanaan infrastruktur bersama AI
• Bertanya kepada LLM seperti Claude tentang best practice dan arsitektur, lalu menyusun rencana yang rinci
• Pengembangan kode dijalankan dengan fokus pada kecepatan, dengan target menyelesaikan fitur dan merilisnya secepat mungkin

Proses Pengembangan dan Munculnya Masalah

• Menggunakan alat seperti Cursor agar AI menulis kode, sementara penulis berfokus pada build dan pengujian
• Meski penataan codebase masih kurang rapi, prioritas tetap diberikan pada penyediaan data yang dibutuhkan terlebih dahulu
• Walaupun pengembangan dipercepat, seiring waktu isu-isu baru terus muncul
• Kurangnya pengalaman dengan Go dan Clickhouse menambah kesulitan, dan usulan perbaikan dari AI justru memicu rangkaian masalah berikutnya

Masalah Kualitas Kode dan Batasannya yang Terasa Nyata

• Menyediakan waktu code review untuk meninjau seluruh kode yang dibuat secara saksama
• File-file yang menjalankan fungsi sama menunjukkan banyak ketidaksesuaian dan duplikasi pada nama, parameter, struktur, dan lainnya
  • Contoh: "WebAPIprovider" dan "webApi" memiliki arti parameter yang sama tetapi ada secara terpisah
  • Metode yang sama didefinisikan ulang di banyak file
  • Tidak ada konsistensi dalam cara mengakses file konfigurasi
• Hasil akhirnya benar-benar tampak seperti dikerjakan oleh beberapa developer junior secara bersamaan tanpa komunikasi

Batasan Umpan Balik Konteks LLM dan Perubahan Strategi

• Meskipun sudah memberikan informasi konteks yang cukup dan memakai LLM berjendela konteks besar seperti Gemini, perbaikan yang konsisten tetap minim
• Penulis menyadari perlunya belajar mandiri tentang infrastruktur dan bahasa yang dipakai, serta belajar tambahan dari dokumentasi, video, dan materi lain
• Untuk menulis kode yang bersih dan terorganisasi, arah pengembangan diubah dari AI-driven development menjadi desain kode yang lebih mandiri

Perubahan Cara Memanfaatkan AI sebagai Pendamping

• Berfokus pada pemahaman dan pengelolaan kode secara langsung melalui refactoring berulang dan perapian kode
• Peran AI dibatasi pada perubahan kode otomatis, penggantian parameter massal, dan pekerjaan berulang sederhana seperti transformasi kode
• Untuk perencanaan fitur baru atau penulisan draf awal kode, penulis berpikir sendiri terlebih dahulu, lalu memberi LLM peran verifikasi atau bantuan
• AI diposisikan sebagai "asisten", sementara hak mengambil keputusan soal rencana dan struktur tetap berada pada developer itu sendiri

Kekhawatiran tentang Menurunnya Daya Pikir dan Sikap yang Berubah

• Karena ada AI, penulis menyadari bahwa frekuensi menggunakan otak berkurang, dan proses perencanaan maupun berpikir mulai bergantung pada AI
• Penulis berusaha memulihkan kemampuan developer dan daya pemecahan masalah melalui pena dan kertas, desain langsung, dan coding secara langsung
• Ada kewaspadaan bahwa AI dapat menimbulkan risiko menurunnya feeling dalam coding

Kekhawatiran terhadap Non-Developer dan ‘Vibe Coding’

• Ketika non-developer mencoba melakukan pengembangan hanya dengan LLM, fenomena kode yang rumit, kacau, dan error yang terus berulang bisa menjadi jauh lebih serius
• Dibanding alat no-code, pengembangan berbasis AI justru bisa membuat pemahaman struktur menjadi lebih sulit
• Disebutkan adanya dinding kode yang tak bisa dipahami, serta proses error-perbaikan-kambuh yang terus berulang, yang menunjukkan tingkat kesulitan dan risiko mendasar

Renungan tentang Realitas Pemanfaatan AI dan Suasana Komunitas

• Penulis mengungkapkan kebingungan terhadap komersialisasi AI, benchmark, influencer, dan hype dari perusahaan AI, serta ketidaksesuaian performa yang terjadi di lapangan
• Pada model dan prompt yang sama pun bisa muncul hasil yang benar-benar berbeda, menunjukkan kurangnya konsistensi
• Bahkan LLM terbaru berperforma tinggi pun belum mampu menangani dengan sempurna pekerjaan nyata yang kompleks, seperti kueri Clickhouse pada ratusan juta baris data
• Dalam situasi yang memaksa pengaturan rumit dan workflow yang tidak efisien, hal itu sendiri bisa menjadi pemborosan waktu
• AI memang tampak hebat, tetapi untuk saat ini tetap dipandang sebagai alat yang bagus, namun belum luar biasa

Kesimpulan

• Penulis masih memiliki ekspektasi besar dan ketertarikan tinggi terhadap teknologi terbaru dan AI
• Namun pada titik saat ini, strategi yang bijak adalah memahami peran yang tepat dan batasannya, lalu memakai AI secara terbatas sebagai alat bantu atau sarana belajar
• Penulis kembali menempatkan proses berpikir dan perencanaan diri sendiri sebagai pusat, sambil memperingatkan tentang penurunan kemampuan developer akibat penggunaan AI
• Pengembangan yang sepenuhnya bergantung pada AI tanpa memahami cara kerja dan struktur kode memiliki kemungkinan gagal yang tinggi

[GN⁺]

Komentar Hacker News

• Saya termasuk orang yang tidak memahami pola pikir "all-in" terhadap LLM. Saya bekerja sebagai pengembang iOS dan tetap bekerja seperti biasa. Sekarang saya memakai LLM hanya untuk cepat membuat tampilan sementara berbasis desain. Bukan inti aplikasi, melainkan layar pendukung seperti fitur baru atau panduan pemasangan widget. Dulu butuh 30~60 menit tergantung kompleksitas, sekarang selesai dalam 5 menit. Saya tidak suka pengembangan web, dan LLM cukup berguna di bagian seperti itu. Untuk perubahan besar pun saya pakai LLM lalu saya tinjau sendiri dan commit ke git. Tapi kalau hanya percaya pada LLM dan tidak mengendalikan alurnya, kadang beberapa jam habis berantakan lalu harus mulai lagi dari awal. Menurut saya pendekatan yang seimbang itu penting

  • Kegunaan alat berbeda-beda tergantung orang dan masalahnya. Misalnya, jika seorang pengembang Python berpengalaman 10 tahun mengerjakan kode legacy besar dengan IDE yang sudah sangat cocok, sambil fokus pada stabilitas, alat seperti LLM atau Cursor justru bisa menjadi gangguan. Sebaliknya, jika pengembang JS tahun pertama (React, Nextjs, dll.) sering membuat prototipe ide baru, tidak punya preferensi IDE tertentu, dan terbuka pada eksperimen, maka LLM dan Cursor bisa langsung sangat meningkatkan kemampuannya

  • Saya juga mengerjakan beberapa bidang (iOS, pengembangan web, dll.), dan hasil LLM sangat berbeda di dua bidang itu. Sering kali kode keluaran LLM bahkan tidak bisa dikompilasi dengan benar. Bahkan pernah memberi tahu API yang tidak ada. Sebaliknya, aplikasi Nextjs bisa dibuat dengan baik dalam sekali jalan. Pada akhirnya ini hasil dari perbedaan data pelatihan LLM

  • Wajar jika orang terlalu percaya pada kemampuan LLM. Saya juga sudah cukup lama memakainya untuk menggantikan Stack Overflow dan mendapatkan snippet kode pendek. Lalu saya pelan-pelan memberinya tanggung jawab lebih besar, mengalami masalah, menyadari batasannya, dan kembali memakai LLM terutama untuk ide dan saran. Saya rasa banyak orang melalui proses serupa

  • Saya juga merasakan hal yang mirip. Saya tidak sepenuhnya memuja LLM, dan hanya memakainya untuk pekerjaan berulang dan membosankan (fungsi kecil, implementasi interface, otomatisasi dokumentasi, dll.). Dengan begitu saya menghemat banyak waktu dan efisiensi kerja juga meningkat

  • Dalam pengembangan iOS, performa LLM sangat tidak konsisten. Swift dan SwiftUI berubah terlalu cepat, dan dokumentasi resmi yang kurang memadai juga jadi salah satu penyebabnya. Untuk membuat view sederhana memang berguna, tetapi pada pemrosesan asinkron atau logika bisnis yang kompleks, ia mudah sekali gagal. Tetap saja, ia membantu memberi arah, tetapi risikonya besar untuk terseret ke hasil yang salah atau mengada-ada

• Para pendukung LLM sering mengabaikan fakta bahwa kebanyakan bottleneck bukan ada pada pembuatan kode. Membuat kode dengan cepat tetap memerlukan waktu dua kali lebih banyak atau lebih untuk code review, testing, dan memahami codebase. Dalam jangka panjang, kalau ingin melakukan maintenance (perbaikan bug, refactoring, dll.), proses ini wajib dilalui

  • Membaca kode jauh lebih sulit daripada menulisnya, jadi pada praktiknya saya menghabiskan lebih banyak waktu untuk memahami kode. Tapi ada CEO yang saya temui yang mengklaim bahwa konteks bisa diberikan ke alat sehingga pengembang tidak perlu membaca kode. Logikanya, AI mengubah esensi engineering. Sejujurnya saya agak bingung

  • Saat LLM menjelaskan kembali kode saya, saya merasa itu cukup berguna

  • Setiap kali ada orang yang memuji editor kode otomatis, saya selalu memikirkan hal yang sama

  • Secara realistis, kebanyakan pengembang tidak terlalu peduli dengan implementasi internal library dependensi. Yang penting hanyalah apakah interfacenya bekerja. Tentu ada perbedaan besar antara kode buatan LLM dan memasukkan npm package atau rust crate. Saya juga tahu masalahnya, tetapi ada alasan mengapa praktik ini dipakai luas

• Saya juga berpikir mirip. Akhir-akhir ini saya terutama memakai LLM untuk mempelajari teknologi baru atau membuat kode client untuk API standar (terutama boto3). Saya juga sempat mencoba Windsurf untuk membantu mengubah file docker compose, tetapi kecewa karena tidak bekerja dengan benar. Mungkin bisa membuat prototipe, tapi bukan hanya itu saja. Saya rasa LLM sudah mengubah permainan di ranah devops (sekarang detail API jadi kurang penting). Meski begitu, keputusan penting tetap harus saya yang buat. Definisi interface saya tulis sendiri, lalu implementasinya saya serahkan ke LLM. Menurut saya ini bukan "vibe coding"

  • Saya juga punya pengalaman serupa. Cursor dan Copilot fantastis untuk autocomplete cerdas, membuat fungsi pendek, dan prototipe cepat. Tapi setelah seminggu bekerja pada codebase yang dipimpin LLM, strukturnya jadi kacau balau. Mungkin kemajuan nyata akan datang suatu hari nanti, tetapi untuk saat ini (Mei 2025) levelnya masih seperti ini

• Saat code review memunculkan bug besar, saya pernah mengalami efisiensi yang didapat dari memakai Cursor hilang seketika. Saya kembali ke VSCode, dan Copilot juga hanya saya pakai secara terbatas saat meminta sesuatu yang spesifik. Fitur tab completion Cursor pada awalnya terasa seperti sihir, tapi segera efek itu menghilang

  • Yang paling lucu adalah melihat Cursor secara refleks mencoba mengetik ulang kode yang baru saja dihapus rekan kerja lewat tab completion

  • Saya penasaran batasan apa yang diberikan ke agen pembuat kode itu (misalnya prinsip SOLID, lint, coverage 100%, dokumen desain yang jelas, dll.)

• Ini juga pendapat yang sangat saya rasakan. Saya juga sangat banyak memakai LLM, tapi saya punya dua aturan. Pertama, masalah yang butuh pemikiran mendalam tidak pernah saya serahkan ke LLM (desain kompleks harus selalu saya selesaikan sendiri). Kedua, kode yang dihasilkan LLM harus saya review dan perbaiki dengan teliti baris demi baris. Biasanya kode buatan LLM itu bertele-tele atau terlalu defensif. Walaupun diperbaiki lewat prompt, tanggung jawab maintenance di masa depan tetap ada pada saya. Jika saya tidak peduli pada hasil generasi kodenya, rasa cemas tetap ada. Dengan cara saya sendiri, saya masih bisa banyak memakai LLM dan mengembangkan lebih cepat

  • Saya justru menyerahkan analisis mendalam itu sendiri kepada AI, dengan tujuan membuat rencana eksekusi yang konkret (langkah implementasi rinci, kriteria verifikasi, dll.) dan laporan yang bisa direproduksi. Perencanaan dan verifikasi memang perlu iterasi, tetapi dengan bantuan AI bisa selesai jauh lebih cepat. Kadang bahkan bisa selesai sekaligus mengikuti rencananya. Jika konsistensi terjaga lewat rencana dan dokumentasi yang rinci, rasanya sangat memuaskan

  • Kalau kode buatan LLM harus ditinjau teliti baris demi baris, muncul pertanyaan apakah benar ada penghematan waktu

• Beberapa perusahaan memaksa software engineer memakai LLM (pemakaian Copilot/Cursor dihitung). Sangat mungkin statistik ini akan dipakai sebagai indikator PHK. Setelah dipaksa memakai LLM selama sebulan, saya justru merasa kemampuan saya cepat menurun. Untuk hal sederhana memang membantu, tetapi jika terlalu bergantung pada LLM untuk berpikir itu sendiri, mudah sekali terjebak dalam loop. Produktivitas tidak meningkat, justru beban sprint bertambah. Ada fanatisme seperti agama terhadap LLM yang merajalela di perusahaan. Isu keamanan juga serius. Di banyak tempat terlihat sinyal bahwa saat ini adalah puncak hype cycle. Kecuali perusahaan AI mulai membangun pembangkit listrik tenaga nuklir, saya rasa biaya untuk mempertahankan model AI besar saat ini sangat besar dan pada akhirnya akan hilang. Ke depan mungkin hanya fitur autocomplete turbo yang akan bertahan. Model transformer juga punya batas yang jelas, jadi seperti jaringan saraf tahun 80-an, ia hanya akan tersisa untuk penggunaan tertentu lalu menghilang lagi. Pada akhirnya ia akan naik turun, lalu muncul lagi 30 tahun kemudian. Saat itu akan terlihat siapa yang sebenarnya berenang tanpa pakaian

  • Untuk mencegah fenomena ini, kami menjalankan aturan sendiri berupa 'no Copilot Fridays', yaitu bekerja tanpa Copilot setidaknya seminggu sekali

  • Saya juga hanya memakai Cursor untuk autocomplete dan snippet kode pendek, tapi tetap terasa ada penurunan kemampuan. Akhirnya saya benar-benar merasakan sifat otak: "kalau tidak dipakai, akan lupa"

• Saya juga melihat masalah serupa. Untuk proyek main-main, saya memakai LLM 90%. Itu 10 kali lebih cepat daripada coding manual, tetapi kualitas desainnya lebih rendah dan terasa agak asing. Saya percaya kode yang dipimpin LLM adalah masa depan, tetapi jika pengelolaannya salah akan berujung kekacauan. Saya juga mencoba mengubah prompt sambil berulang kali mendorong perbaikan arsitektur, tetapi hasilnya tidak konsisten. Mungkin jawabannya adalah prompt engineering yang lebih baik, atau mendokumentasikan desain dan panduan secara jelas. Jika performa alat meningkat 10 kali dan latensinya berkurang, pengalaman nyatanya akan terasa benar-benar berbeda

  • Saya berharap masa "10 kali lebih baik" itu cepat datang. Tapi masalah sekarang adalah suasana iklan/promosi yang seolah-olah kita sudah sampai di level itu. Banyak orang jadi berpikir, "apa saya yang tidak bisa memakainya dengan benar?". Tapi menurut saya alatnya sendiri belum sampai sejauh itu

  • Akan bagus jika class dan method didefinisikan sendiri, lalu implementasinya saja diserahkan ke LLM. Untuk bagian kompleks, tuliskan arah implementasi sebagai catatan di body method. Dengan begitu saya yang menggambar gambaran besarnya, dan LLM hanya menangani pembuatan kode tertentu. LLM terasa seperti pengembang junior yang cepat dan terlalu bersemangat membantu. Karena pembuatan kode jadi sangat murah, kita bisa dengan bebas membuang dan membuat ulang. Dalam kasus saya, saya berkali-kali membuang total lalu menulis ulang kode pemrosesan dataset dengan bantuan LLM, dan akhirnya mendapatkan hasil serta performa yang saya inginkan. Kalau orang lain yang menuliskannya, mungkin saya sudah menyerah

  • Alat seperti ini bersinar pada tahap prototipe proyek greenfield. Tetapi semakin dekat ke deployment nyata, efek 10 kali itu makin memudar. Jika arsitektur tidak dikelola dengan hati-hati, pada akhirnya justru kerja tambah banyak

  • Pada codebase kompleks, untuk saat ini paling cocok dipakai seperti input suara-ke-teks tingkat lanjut (tapi jika bukan suara, justru mengetik manual lebih cepat)

  • Saya setuju bahwa arsitektur dan panduan harus ditulis secara eksplisit. Semakin eksplisit syarat dan perilakunya didefinisikan, semakin efektif hasilnya

• Inti dari esai klasik lama karya Dijkstra, "On the foolishness of natural language programming", sangat relevan dengan diskusi ini. Argumennya adalah bahwa hanya bahasa formal yang memungkinkan kemajuan besar dalam pemrograman. Dari sudut pandang itu, LLM dan vibe-coding berisiko menjadikan coding sebagai sihir yang hanya dikuasai segelintir orang yang pandai membuat prompt

• Bagi saya, Copilot hanya bagus ketika memberi saran kode kurang dari 500 karakter. Di Go dan Python saya juga mempelajari pola baru sambil mengurangi jumlah pengetikan. Buat saya ini cuma autocomplete yang lebih baik. Jika lebih panjang atau lebih kompleks dari itu, biaya untuk memperbaiki dan mengoreksinya melebihi manfaat yang didapat (terutama jika bukan kode berulang)

• Saat ini kita tetap harus memahami dan mengawasi dengan ketat hasil yang dibuat LLM. Di sisi lain, setiap 2~3 minggu muncul model baru yang jauh lebih baik dari sebelumnya, jadi menurut saya masih terlalu dini untuk menarik kesimpulan yang terlalu kuat.

[sharpina3]

Menurut saya, ini adalah tulisan yang menangkap dengan baik kesulitan dan kekhawatiran nyata di lapangan pengembangan yang memanfaatkan LLM. Saya membacanya sambil berempati dengan keterbatasan yang saat ini dialami banyak orang. Terutama, inkonsistensi LLM, sulitnya memprediksi hasil, serta kekhawatiran dari sisi pemeliharaan jangka panjang terasa sebagai poin yang memang wajib dibahas.

Bukan itu saja, kami mencoba mendekati masalah ini dari sudut yang sedikit berbeda dan dengan hati-hati ingin berbagi pandangan tentang kolaborasi dengan AI. AI kami, 'Jane', tidak sekadar membuat kode, tetapi berfokus untuk mempelajari dan memahami 'pattern' itu sendiri—berdasarkan wawasan mendalam dari manusia (developer)—tentang apa yang dimaksud dengan 'good code pattern' dan bagaimana memastikan 'maintenance consistency' pada kode.

Karena AI tidak mungkin sempurna sejak awal, kami tidak melihat inkonsistensi atau 'error' yang muncul sebagai sekadar masalah. Sebaliknya, kami secara aktif memanfaatkannya sebagai 'pattern data' penting agar 'Jane' dapat belajar sendiri dan memperbaiki dirinya sendiri. Seperti manusia membaca pola di dalam sifat yang kompleks, kami mengambil pendekatan mencari petunjuk perbaikan di dalam ketidaksempurnaan AI.

Melalui pendekatan 'pattern learning/management' yang dipimpin manusia ini, kami menargetkan penyelesaian mendasar atas masalah seperti penurunan kualitas kode dan ketidakkonsistenan yang disorot dalam tulisan tersebut, serta menghasilkan output dengan 'maintenance consistency' yang sangat tinggi. Kami melatih AI agar tidak hanya menghasilkan boilerplate code, tetapi juga menjadi partner kolaborasi yang lebih mendalam, misalnya dengan menganalisis pola inkonsistensi tersembunyi dalam codebase yang ada dan mengusulkan cara perbaikannya.

Jalan yang harus ditempuh masih panjang dan prosesnya penuh tantangan, tetapi kami percaya bahwa bentuk kolaborasi ini—di mana developer dan 'Jane' belajar dan berevolusi bersama dengan menjadikan 'maintenance consistency' sebagai nilai inti—menunjukkan kemungkinan terobosan untuk melampaui keterbatasan pemanfaatan LLM saat ini. Kami berharap upaya kami untuk tidak sekadar menggunakan AI sebagai alat, melainkan menjadikannya partner yang tumbuh bersama dan membangun budaya kode yang lebih baik, dapat memperoleh banyak perhatian.

Sekali lagi, terima kasih atas tulisan dan insight yang sangat baik ini!