Claude Code men-debug kode kriptografi tingkat rendah

 (words.filippo.io)
2 poin oleh GN⁺ 2025-11-02 | 2 komentar | Bagikan ke WhatsApp
  • Dalam proses implementasi Go untuk ML-DSA, algoritme tanda tangan tahan kuantum yang ditetapkan NIST, muncul masalah verifikasi tanda tangan yang gagal
  • Claude Code v2.0.28 hanya dengan kode uji dan path sumber berhasil menemukan bug kompleks tingkat rendah dengan cepat
  • Penyebabnya dipastikan sebagai kesalahan penggabungan fungsi yang menghitung ulang bit atas dari w1 pada tahap Verify
  • Dalam eksperimen kedua yang menyusul, Claude juga menemukan kesalahan perhitungan konstanta Montgomery dan bug ketidakcocokan panjang tanda tangan
  • Ketiga percobaan berhasil mengidentifikasi bug, menunjukkan potensi pemanfaatan AI untuk debugging tingkat rendah

Implementasi ML-DSA dan masalah awal

  • Penulis mengimplementasikan ulang ML-DSA (Post-Quantum Signature Algorithm) yang ditetapkan NIST dalam bahasa Go
    • Setelah 4 hari live coding, pengujian memunculkan masalah bahwa fungsi Verify menolak semua tanda tangan
    • Di log pengujian, error invalid signature terus muncul berulang
  • Karena kelelahan, debugging dihentikan dan Claude Code diminta menganalisis masalah tersebut

Debugging pertama oleh Claude Code

  • Claude Code v2.0.28 (model Opus 4.1, tanpa system prompt) diberi informasi berikut
    • Perintah menjalankan tes (bin/go test crypto/internal/fips140/mldsa)
    • Lokasi kode (src/crypto/internal/fips140/mldsa)
    • Penjelasan bahwa “tanda tangan selalu ditolak” dan petunjuk bahwa “w1 berbeda”
  • Dalam hitungan menit, Claude mengembalikan usulan perbaikan yang lengkap
    • Penyebabnya adalah setelah HighBits dan w1Encode digabung menjadi satu, hasil UseHint yang pada Verify sudah menghasilkan bit atas kembali diambil bit atasnya sekali lagi
    • Dengan kata lain, ini adalah kesalahan struktural karena bit atas dari w1 dihitung dua kali
    Iklan
  • Claude memahami penyebabnya segera setelah selesai memuat kode, lalu menulis tes sendiri untuk memverifikasi hipotesis
    • Perbaikan yang diusulkan tidak sepenuhnya sempurna, tetapi identifikasi akar masalahnya mempersingkat waktu debugging
  • Setelah itu penulis merombak w1Encode agar menerima bit atas sebagai input, sekaligus mempersingkat proses konversi representasi Montgomery

Eksperimen kedua: bug pada tahap pembuatan tanda tangan

  • Implementasi pembuatan tanda tangan juga mengalami kegagalan tes
    • Bug pertama: kesalahan perhitungan konstanta (1, -1) di domain Montgomery
      • Ini masalah yang sulit ditemukan, membutuhkan banyak printf dan tebakan, serta memakan waktu sekitar 1~2 jam
    • Bug kedua: kesalahan panjang nilai yang dimasukkan ke tanda tangan (32-bit, bukan 32-byte)
      • Ini relatif mudah ditemukan karena perbedaan panjang tanda tangan
    Iklan
  • Penulis menilai dua bug ini cocok untuk menguji performa Claude, lalu menjalankan ulang Claude Code pada versi kode sebelumnya

Hasil debugging kedua oleh Claude Code

  • Pada prompt pertama, Claude melakukan debugging dengan printf dan pelacakan nilai, lalu menemukan konstanta yang salah dan memperbaikinya
    • Waktu pemrosesannya lebih singkat daripada manusia, dan penyebab kegagalan tes berhasil diidentifikasi dengan tepat
  • Pada prompt kedua, Claude menemukan masalah ketidakcocokan panjang tanda tangan
    • Setelah menelusuri beberapa jalur, Claude mengusulkan perbaikan yang hanya mengubah panjang alokasi
    • Perbaikan yang diusulkan tidak sepenuhnya sempurna, tetapi berhasil menunjuk lokasi inti kesalahannya dengan akurat
  • Dalam tiga percobaan independen, Claude sendiri berhasil menemukan penyebab bug yang benar
Iklan

Efisiensi debugging AI dan implikasinya

  • Pendekatan Claude efektif sebagai asisten otomatis yang khusus menelusuri penyebab kegagalan tes
    • Pengguna tidak langsung menerapkan usulan perbaikan Claude, melainkan memeriksa lokasi bug lalu memperbaikinya sendiri
  • Penulis menyinggung perlunya alat yang “secara otomatis membuat LLM menganalisis dan memberi tahu penyebab saat tes gagal”
    • Dibanding chat sederhana atau pembuatan PR otomatis, bentuk agen debugging berbasis tes dinilai lebih ideal

Dukungan dan informasi lain

  • Pemeliharaan open source penulis didukung melalui Geomys,
    dengan sponsor seperti Smallstep, Ava Labs, Teleport, Tailscale, dan Sentry
  • Ava Labs menekankan pentingnya pengembangan open source berkelanjutan untuk protokol kriptografi
  • Teleport memperkenalkan platform Teleport Identity untuk mencegah pengambilalihan akun pengguna dan memperkuat kontrol akses

Lampiran: gambar dan penyebutan pribadi

  • Artikel ini menampilkan Clippy dari Microsoft Office dengan balon kata yang mengatakan “bit atas w1 diambil dua kali”
  • Di bagian akhir juga ada foto kucing, disajikan sebagai humor untuk meredakan perdebatan emosional tentang AI

Bacaan terkait

2 komentar

 
ajh508 2025-11-02

Belakangan ini saya cukup sering mengembangkan kernel GPU menggunakan triton atau cuda, dan kalau di versi 3.5 saya hampir tidak pernah melihatnya bisa menjalankan sesuatu dengan benar, tetapi di 4.5 terlihat bahwa ia sudah bisa menghasilkan kode atau optimisasi yang cukup layak.
 
GN⁺ 2025-11-02
Komentar Hacker News

  • Menggunakan agen coding untuk melacak akar penyebab bug ternyata bekerja cukup baik
    Ketiga percobaan debugging one-shot semuanya berhasil. Kuncinya adalah LLM tidak langsung memperbaiki kode, melainkan berperan sebagai asisten yang hanya memberi tahu lokasi bug agar saya bisa menilai dan memperbaikinya sendiri
    Pendekatan seperti ini juga bisa menjadi titik awal yang bagus bagi mereka yang skeptis terhadap LLM. Jangan suruh menulis kode pengganti, cukup beri peran untuk menemukan bug yang menyebalkan

    • Agen seperti ini sering kali terlalu agresif mencari solusi hingga melewatkan inti masalah
      Usulan “ini harus diperbaiki” memang tidak selalu salah, tetapi sering kali tidak relevan dengan akar persoalannya. Akibatnya, usulan perubahan yang tidak perlu menumpuk, dan jika developer junior menerapkannya mentah-mentah, yang bertambah hanya pekerjaan yang tidak perlu
      Saya juga memakai alat seperti ini, tetapi sering terasa seperti “malah butuh waktu lebih lama untuk menjelaskannya ke junior”
    • LLM cukup kuat untuk bug algoritmik, tetapi lemah untuk bug konkurensi
      Pembuatan test juga bagus untuk sisi algoritmik, tetapi ada batasan dalam situasi konkurensi. Meski begitu, untuk penggunaan seperti “pembuatan test” atau “debugging”, nilainya tetap tinggi
      Dari sudut pandang refactoring kode atau maintenance jangka panjang, masih kurang
    • Secara pribadi, LLM sangat bagus untuk proyek hobi, tetapi kurang berguna pada codebase skala besar
      Namun saat saya memakainya sebagai pemburu bug seperti yang disarankan di blog, hasilnya sangat efektif. Dalam beberapa minggu saja, ia membantu menemukan beberapa bug production
    • Cara penggunaan favorit saya adalah menyerahkan pekerjaan dokumentasi kepada LLM
      Jika diminta menulis dokumentasi terkait secara panjang sebelum benar-benar menggali kode, risikonya rendah meski ada kesalahan, dan ini juga jadi titik awal yang bagus bagi orang yang skeptis
    • Proses mencari dan memperbaiki bug adalah salah satu bagian pekerjaan developer yang paling memberi kepuasan intelektual
      Akan terasa sayang jika proses ini diserahkan ke mesin. Berburu bug membuat kita memahami struktur sistem secara mendalam dan dalam jangka panjang membantu kita tumbuh menjadi programmer yang lebih baik
      Tanpa pengalaman seperti ini, ada risiko akhirnya kita bahkan bergantung pada LLM untuk menilai kode kita sendiri

  • Saran saya cuma satu: AI First
    Lemparkan dulu masalahnya ke AI, maka Anda bisa mempelajari batas model sekaligus mengasah kemampuan menyusun prompt
    Model-model terbaru sudah cukup kuat untuk diperlakukan seperti rekan kerja dalam kebanyakan masalah. Yang penting adalah memahami pola kegagalannya dan membangun intuisi
    Setiap kali generasi model baru muncul, saya sarankan membuang proses lama dan bereksperimen lagi dengan model terbaru seperti GPT-5-Codex atau Sonnet 4.5

    • Namun pendekatan “lempar dulu ke AI” tidak sepenuhnya berhasil
      Jika Anda ahli di domainnya, Anda bisa membedakan halusinasi dan kesalahan dari LLM, tetapi jika tidak, justru jadi buang waktu
      Pada akhirnya, alat-alat ini paling berguna bagi para ahli, sedangkan bagi pemula kualitasnya masih naik turun
      Saya juga sudah mencoba Sonnet 4.5, tetapi rasanya hanya sedikit lebih baik daripada versi sebelumnya. Tetap saja sering membuang waktu

  • Anthropic memberi saya Claude Max gratis selama beberapa bulan
    Belakangan, konten terkait Claude juga membanjiri iklan Instagram. Melihat iklan seperti “instal Claude Code” terus muncul, rasanya tim marketing mereka benar-benar bekerja keras

    • Mungkin mereka sudah menemukan product-market fit
      Para developer merasa Claude Code sangat berguna, dan pelanggan langganan 200 dolar per bulan juga banyak. Jika memang menguntungkan, wajar saja mereka menggelontorkan uang ke marketing

  • LLM membantu saat mencari bug, tetapi kadang juga memberi penjelasan yang meleset dan membuang waktu
    Pada akhirnya, yang penting adalah tetap menjaga daya pikir kritis

    • Yang dimaksud OP adalah “bukan LLM, tetapi saya sendiri yang menilai”
      LLM adalah alat yang hebat, tetapi sangat mudah terburu-buru menarik kesimpulan. Begitu manusia berhenti berpikir, model akan melaju ke arah yang salah

  • Saya setuju dengan pendapat bahwa “memakai LLM hanya dalam bentuk chat atau autocomplete itu kurang menarik”
    Saya sendiri baru benar-benar melihat potensinya saat memakai Claude Code/Codex. Akan lebih menarik lagi jika ada mode yang berjalan terus-menerus

    • UI chat itu lambat dan tidak efisien, tetapi memberi LLM akses ke sistem juga berisiko dari sisi keamanan dan privasi
      Ia bisa saja tanpa sengaja menghapus file atau merusak repositori Git. Karena itu saya hanya bereksperimen di lingkungan sandbox
    • Saya juga berpikir begitu. Yang benar-benar saya inginkan adalah copilot yang ngoding bersama
      Saya ingin alat kolaborasi bergaya Sokratik di mana model bertanya kepada saya, lalu saya ikut campur langsung sambil belajar
      Pendekatan “serba otomatis” saat ini berisiko membuat developer buta kode. Sebaliknya, jika dirancang dengan baik, ini bisa menjadi alat yang memperkuat pemahaman dan intuisi

  • Terminal CLI tetap merupakan antarmuka yang kuat
    Gemini CLI atau Qwen Code gratis, dan API yang kompatibel dengan OpenAI juga mudah dipasang.
    Tugas sederhana bisa diotomatisasi, lalu bagian yang sulit diselesaikan one-shot dengan Grok. Hanya dengan CLI + server MCP + file MD pun kita bisa membuat program yang cerdas

    • Saya penasaran bagaimana Gemini CLI dibandingkan dengan Claude Code atau OpenAI Codex
    • Meski begitu, UX Claude Code memang luar biasa

  • Ide agar setiap kali test gagal, LLM otomatis menganalisis penyebabnya terasa menarik
    Ini bisa dilakukan dengan menjalankan Claude CLI lewat Git hook.
    Contoh dan cheat sheet bisa dilihat di panduan ini

    • Jika ingin menjalankannya secara manual, ini juga bisa dibuat dengan skrip Bash sederhana. Saya pun terpikir membuatnya sekadar untuk iseng

  • Sepertinya sebentar lagi akan muncul kasus serangan adversarial terhadap data pelatihan LLM untuk memicu kesalahan kriptografis

  • Bahwa “perbaikannya mencakup penambahan fungsi yang sepenuhnya baru” terasa berbahaya dalam konteks implementasi kriptografi
    Rasanya tulisan itu memberi saran yang keliru

    • Namun inti tulisannya adalah bahwa LLM dipakai hanya untuk menemukan bug
      Kode perbaikannya dibuang, dan manusialah yang menulisnya sendiri. Justru ini tampak seperti contoh penggunaan yang konservatif dan bertanggung jawab
    • Seperti yang dijelaskan jelas dalam tulisan itu, yang penting adalah proses deteksi, bukan solusinya
      LLM sebaiknya dipakai bukan sebagai “tukang reparasi”, melainkan seperti detektor kebocoran gas yang menunjukkan lokasi masalah

  • LLM telah mengenali pola-pola ambigu dalam kode dan menghilangkan banyak masalah yang membosankan
    Tetapi ini juga bisa menjadi efek samping. Codebase saya terlihat seperti Node.js, padahal sebenarnya bukan, sehingga model terus salah mengira itu sebagai proyek Node