Ask HN: Apakah coding agentik benar-benar efektif?

• Saya sudah mencoba coding dengan agen, tetapi saya pusing karena jarak antara apa yang saya lihat di online dan hasil yang benar-benar saya dapatkan saat mengimplementasikannya; adakah bukti bahwa ini benar-benar membawa hasil positif?
• Di luar promosi yang berlebihan, jika ada yang pernah berhasil menerapkan coding agentik, mohon bagikan secara detail bagaimana Anda melakukannya
• "Berhasil menerapkannya" berarti hal-hal seperti berikut
  • Menciptakan nilai yang lebih besar daripada technical debt
  • Menulis kode yang kokoh secara struktural hingga bisa disetujui oleh penanggung jawab arsitektur
• Belakangan ini tampak ada tren meminimalkan atau bahkan menghapus code review, disertai argumen bahwa kita harus beralih dari "validasi arsitektur" ke "validasi perilaku"
• Dalam praktiknya, ini tampaknya berarti merilis jika lolos test dan CI tanpa melihat kodenya, dan saya ragu apakah pendekatan seperti ini bisa berkelanjutan dalam jangka panjang

• Menurut saya, jika menggunakan Codex, pada jalur normal memang bisa bekerja, tetapi besar kemungkinan akhirnya menjadi "spaghetti code" yang menumpuk error halus dan sulit di-debug seiring waktu
• Saat saya mencoba menerapkan Codex pada codebase yang sudah ada, baik dengan panduan maupun tanpa panduan, setengah waktu saya habis untuk memperbaiki error halus atau kode duplikat yang dibuat Codex

• Akhir pekan lalu saya mencoba membangun ulang dari nol aplikasi iOS pengingat makanan hewan peliharaan
  • Saya meminta Codex terlebih dahulu meneliti dan mengusulkan cetak biru arsitektur berbasis SwiftUI, lalu bersama Codex menulis spesifikasi yang menjelaskan apa yang harus diimplementasikan dan bagaimana caranya
  • Implementasi pertama punya beberapa bug, tetapi di luar dugaan cukup lumayan; setelah itu, keadaannya memburuk dengan cepat
  • Sepanjang sisa akhir pekan, saya berusaha membuat Codex bekerja dengan benar, memperbaiki bug tanpa menciptakan bug baru, dan meneliti best practice alih-alih menulis kode secara sembarangan
  • Setiap kali menemukan panduan baru, saya menyuruh Codex mencatatnya, tetapi keadaan tidak membaik, dan akhirnya saya menyerah
• Secara pribadi, merilis kode yang belum ditinjau tidak bisa saya terima
• Sepertinya ada yang salah. Produk harus berfungsi dengan benar, tetapi kualitas kodenya juga harus tinggi

[GN⁺]

Komentar Hacker News

• Karena LLM dianggap sebagai kunci penghematan biaya, ada dana sangat besar yang dipertaruhkan
  Influencer atau pakar terkenal juga kerap membuat pernyataan berlebihan demi mempertahankan citra sebagai pihak yang “terdepan”
  Namun pada praktiknya, pendekatan optimal untuk pengembangan berbasis LLM masih belum mapan
  Saat ini, menurut saya lebih penting melihat langsung cara kerjanya daripada memercayainya seperti sebuah keyakinan

  • Saya juga baru-baru ini menerima tawaran 200 dolar dari sebuah perusahaan untuk mempromosikan “agentic coding platform” baru
    Fakta bahwa tawaran seperti ini sampai ke pengguna acak berarti kampanye pemasaran yang cukup besar sudah berjalan
  • LLM jelas merupakan alat lompatan besar, tetapi bukan kunci universal untuk pengembangan otonom sepenuhnya
    Untuk pekerjaan CRUD sederhana memang menyenangkan, tetapi pada proyek kompleks justru sering membuat frustrasi
    Saat ini, karena persaingan benchmark dan dana VC mengalir deras, ini adalah masa ketika diskusi yang dingin dan objektif sulit dilakukan
  • Seperti saat GUI pertama kali muncul, saya rasa sekarang kita sedang berada di tahap merasakan nilai yang intuitif
    Bukti kuantitatif memang masih kurang, tetapi meski pengembang tidak akan benar-benar hilang, cara mengembangkan perangkat lunak sudah berubah untuk selamanya

• Seorang Principal Engineer di Google menulis di Twitter bahwa “Claude Code menyelesaikan pekerjaan 1 tahun hanya dalam 1 jam”
  Namun belakangan terungkap bahwa yang dibuat AI hanyalah ‘versi mainan’ yang sederhana
  Pernyataan berlebihan seperti ini mendistorsi ekspektasi dan menimbulkan kekecewaan
  Tautan tweet terkait

  • Tweet seperti ini sering muncul karena tekanan internal untuk menunjukkan hasil kepemimpinan AI
  • Ada yang bereaksi, “Mengatakan hal seperti itu benar-benar tidak masuk akal”
  • Orang lain juga menyoroti bahwa “hasil AI bergantung pada tingkat pengalaman dan biaya investasi”
  • Ada pula respons sinis yang mengatakan, “AI masih hanya menghasilkan kode yang tidak bisa di-deploy”
  • Ada juga yang menyindir bahwa “hal seperti ini sangat menggambarkan Google”

• Jika melihat kilas balik 6 bulan terakhir, pada kode infrastruktur (misalnya Terraform) saya mendapatkan efisiensi 10x
  Namun pengembangan fitur khusus masih tetap naik turun
  Meski begitu, waktu yang dihemat dari berkurangnya pekerjaan berulang bisa dipakai untuk meningkatkan kualitas pengujian dan keamanan
  Yang paling penting, saya kembali merasakan kesenangan dalam ngoding

  • Saya juga sudah 35 tahun melakukan pengembangan sebagai hobi, dan AI membantu mengurangi pengetikan yang membosankan sekaligus menghidupkan kreativitas
  • Saya sendiri juga menjadi lebih dari 2x lebih cepat pada build script dan pekerjaan CI, tetapi proyek HPC yang kompleks masih tetap sulit
    Pendekatan assisted coding adalah yang paling efisien
    Tautan proyek
  • Saya membuat pencari file NAS rumah dengan Claude, dan menyelesaikan backend Go serta UI web yang melakukan pengindeksan otomatis harian hanya dalam satu hari
    Menurut saya, proyek pribadi seperti inilah yang benar-benar menjadi game changer
  • Jika pekerjaan dipecah menjadi bagian-bagian kecil, agen bekerja jauh lebih baik
  • Namun kualitas kode pengujian masih tetap rendah. Ini karena data pelatihannya sendiri lemah dalam penulisan test

• Saya meraih sukses besar dengan menempelkan agen ke aplikasi yang sudah ada
  Agen lemah dalam perancangan arsitektur, tetapi bekerja sangat baik pada kode yang strukturnya sudah tertata
  Semakin ketat type system dan semakin luas cakupan test, semakin besar efektivitasnya

  • Saat ini saya sedang bereksperimen agar proyek Rust dikelola dan dikembangkan langsung oleh LLM
    Pekerjaan berjalan berdasarkan ROADMAP.md, TASKS.md, dan STATUS.md yang ditulis Claude
    Dan yang mengejutkan, saat ini sudah sekitar 20% selesai
  • C# cocok dengan agen berkat compiler yang ketat dan lingkungan berbasis aturan
    Sebaliknya, Python atau JS sulit dipercaya karena type system yang lemah
  • Semakin rapi codebase yang sudah ada, semakin tinggi performa agen
    Memulai dari nol itu sulit, tetapi jika diberi spesifikasi yang jelas, efisiensinya tinggi
  • Go mudah ditangani LLM berkat bahasanya yang sederhana dan polanya yang konsisten
  • Typescript ideal untuk agen berkat kompilasi cepat dan type system yang kuat
    Sebaliknya, tipe opsional di Python justru menyebabkan perambatan error

• Saya menulis 100% monitor detak jantung Bluetooth real-time untuk Linux dengan Claude Code
  Tautan proyek
  Ditulis dalam C murni, dan antarmuka web serta grafik real-time juga selesai hanya dalam satu hari
  Implementasi komunikasi dBus–blueZ yang sebelumnya gagal, kali ini berhasil saya wujudkan

  • Namun ketika pengguna lain meninjau kodenya, ternyata implementasi SSE sebenarnya tidak berfungsi
    Di dokumentasi tertulis SSE, tetapi secara internal hanya mengembalikan respons HTTP biasa
  • Orang lain juga menunjukkan bahwa “kode yang ditulis AI awalnya terlihat bagus, tetapi lama-lama kualitasnya menurun”
  • Ada pula yang menilai ini sebagai contoh tanpa berlebihan, sambil berkata “terima kasih sudah membagikan contoh nyata seperti ini”
  • Ada juga komentar yang bertanya soal desain karena gaya UI-nya dianggap menarik

• Saya menggunakan Augment + Claude Opus 4.5 setiap hari
  Saya hampir tidak menulis kode sendiri, dan menyelesaikan proyek lewat pekerjaan iteratif berbasis spesifikasi
  Menjalankan beberapa agen secara paralel lalu me-review hasilnya sangat efisien
  Kuncinya adalah menulis spesifikasi yang jelas dan memberi umpan balik bertahap

  • Saya tidak terlalu paham Ruby, tetapi sangat terbantu dalam pengembangan aplikasi Rails
    Ini terasa sebagai perubahan paling revolusioner dalam 30 tahun karier saya, dan saya yakin seluruh industri akan berubah
  • Ada yang bercanda, “Menyebut proyek 1 minggu sebagai proyek skala menengah itu kecil sekali”
  • Ada juga yang menilai, “Ini sebenarnya lebih dekat ke pengembangan kolaboratif dengan LLM daripada pengembangan agen yang sesungguhnya”
  • Ada pula pendapat bahwa “pengembangan berbasis spesifikasi (spec-driven) adalah kunci kualitas produksi”
  • Saya menambahkan tahap agar Claude mengajukan pertanyaan terlebih dahulu untuk merapikan kebutuhan secara jelas
    Saat ini saya sedang mengerjakan proyek kamus Jepang–Inggris dengan Claude
    Tautan GitHub, situs web

• Sebagai pengembang dengan pengalaman 20 tahun, berkat LLM prediksi kecepatan kerja saya jadi meleset total
  Pekerjaan yang dulu butuh 2 minggu sekarang bisa selesai dalam 2 hari
  Code review dan interaksi tetap diperlukan, tetapi rasanya lebih baik daripada kebanyakan pengembang manusia
  Berbicara dengan LLM terasa lebih seperti berkolaborasi dengan pengembang senior,
  dan pengalaman panjang saya dalam code review dan pembagian tugas sangat membantu

  • Ada yang penasaran soal jenis masalah yang dikerjakan, sambil berkata bahwa peningkatan kecepatan sebesar itu sulit dipercaya
  • Ada juga yang menyinggung singkat, “Saya mengharapkan bukti, tapi ternyata tidak ada”

• Metode paling stabil yang pernah saya coba adalah menyerahkan pekerjaan kepada Claude dalam unit tugas kecil dan jelas
  Saya mengulang siklus membuat rencana, meninjau, mengimplementasikan, lalu me-review hasilnya
  Ini memang tidak sempurna, tetapi sangat berguna untuk membuka jalan saat buntu
  Namun karena ia tidak terlalu patuh pada guideline, verifikasi dan perapian manual tetap wajib

  • Saya juga memakai Claude mirip rubber duck debugging
    Saya memberinya satu fungsi tiap kali, lalu memakai hasilnya sebagai referensi untuk mendapatkan ide yang lebih baik
  • LLM sangat kuat untuk dokumentasi atau analisis
    Tetapi saat masuk ke masalah yang berpusat pada desain, keterbatasannya terlihat jelas
  • Menjawab pertanyaan “guideline diletakkan di mana”, ada saran bahwa informasi build dan test sebaiknya dimasukkan ke CLAUDE.md

• Banyak orang salah memahami coding berbantuan AI
  AI bukan anggota tim, melainkan asisten
  Bug atau malfungsi bukan dilihat sebagai kegagalan, melainkan proses ketika pengembang terampil membereskan kekacauan itu yang justru menjadi inti

  • Ada yang bertanya, “Kalau tetap butuh banyak campur tangan tangan, apa bedanya dengan autocomplete IDE?”
  • Orang lain juga bertanya apakah ada kasus di mana teknik terbaru benar-benar membuktikan peningkatan kualitas
  • Ada juga yang menyindir, “Pada akhirnya terdengar seperti bilang ‘kamu saja yang memakainya salah’”
  • Ada pula lelucon, “Kalau kamu berharap bisa menonton baseball sambil dibuatkan aplikasi sempurna, berarti yang kamu beli itu bukan AI melainkan penyihir”

• Saya juga memakai Claude setiap hari, tetapi kode test yang dibuat AI sering kali berantakan
  Pada praktiknya, ia menghasilkan test tak bermakna seperti expect(true).to.be(true)

  • Model lama memang gagal, tetapi saya pernah membaca tulisan bahwa model terbaru membuat kode yang lolos dengan cara curang
  • Karena itu, saya menulis dan meninjau test lebih dulu dengan pendekatan TDD
    Jika implementasi dan test diserahkan sekaligus, akan muncul kesalahan menilai diri sendiri
  • Ada yang berkata, “Saya sudah menyerah memakai Claude untuk menulis test”
  • Ada juga yang tertawa sambil bilang, “Ini solusi yang terlalu manusiawi”