AI Blindspots – Titik Buta LLM yang Ditemukan saat AI Coding

 (ezyang.github.io)
12 poin oleh GN⁺ 2025-03-20 | 1 komentar | Bagikan ke WhatsApp

Titik buta LLM yang ditemukan saat AI coding. Berdasarkan Claude Sonnet

  1. Stop Digging → Sulit mengubah arah saat masalah muncul
  2. Use Static Types → Perlu menetapkan tipe statis
  3. Black Box Testing → Terlalu bergantung pada detail implementasi
  4. Use MCP Servers → Masalah konfigurasi dan keamanan server MCP
  5. Preparatory Refactoring → Dapat melakukan refactoring yang tidak perlu
  6. Mise en Place → Masalah muncul jika penyiapan lingkungan gagal
  7. Stateless Tools → Masalah muncul pada alat yang bergantung pada state
  8. Respect the Spec → Kemungkinan tinggi melanggar spesifikasi
  9. Bulldozer Method → Melakukan terlalu banyak pekerjaan berulang
  10. Memento → Masalah akibat kurang memahami konteks
  11. Requirements, not Solutions → Perlu memperjelas requirement
  12. Scientific Debugging → Masalah muncul saat memperbaiki berdasarkan tebakan
  13. Use Automatic Code Formatting → Terjadi ketidakkonsistenan gaya kode
  14. The Tail Wagging the Dog → Terobsesi pada masalah sepele alih-alih tugas penting
  15. Keep Files Small → Masalah muncul saat mengubah file besar
  16. Know Your Limits → Model kurang menyadari keterbatasannya sendiri
  17. Read the Docs → Kesalahan muncul pada informasi di luar pengetahuan yang telah dipelajari
  18. Culture Eats Strategy → Kurang konsistensi gaya kode
  19. Walking Skeleton → Perlu memprioritaskan sistem minimal yang berjalan
  20. Rule of Three → Perlu refactoring saat ada duplikasi kode

Tidak Terjebak dalam Masalah (Stop Digging)

  • LLM saat ini kurang mampu menghentikan pekerjaannya sendiri dan mengubah arah ketika terjadi masalah di tengah tugas
    • Contoh: saat mengimplementasikan fitur X, meskipun muncul situasi bahwa fitur Y harus dibuat lebih dulu, LLM tetap mencoba menyelesaikan tugas awal (X)
    • Ini memang kelebihan dari sisi kepatuhan pada instruksi, tetapi sulit baginya menyadari masalah lalu beralih arah
  • Strategi untuk menghindari masalah
    • Pada tahap perencanaan, gunakan model penalaran untuk menentukan prioritas kerja dan tugas prasyarat
    • LLM agen seperti Sonnet membaca file dan menyusun rencana kerja → dapat memahami pekerjaan yang diperlukan meski pengguna tidak mengarahkannya secara eksplisit
  • Idealnya, LLM harus bisa mengenali masalah dan meminta konfirmasi kepada pengguna
    • Namun, ini menghabiskan konteks, sehingga mungkin lebih baik ditangani oleh LLM pengawas terpisah

  • Example

    • Setelah mengubah metode sampling bilangan acak pada simulasi Monte Carlo, Claude Code diminta memperbarui tes
      • Implementasi baru bersifat non-deterministik sehingga hasil tes kadang lolos/gagal secara acak
      • Claude Code tidak menyadari hal ini dan mencoba menyelesaikan masalah dengan melonggarkan kondisi tes
      • Padahal seharusnya ia menyarankan refactoring agar simulasi menjadi deterministik

Gunakan Tipe Statis (Use Static Types)

  • Perdebatan sistem tipe dinamis vs tipe statis pada dasarnya adalah soal keseimbangan antara kemudahan prototyping dan maintainability jangka panjang
    • Karena LLM bisa menangani boilerplate code dan refactoring, beban memilih bahasa yang cocok untuk prototyping menjadi berkurang
    • Karena itu, lebih memungkinkan memilih bahasa yang lebih menguntungkan untuk pemeliharaan jangka panjang daripada untuk prototyping
  • Strategi memperbaiki type error
    • Atur agen agar LLM dapat mengenali type error yang muncul setelah perubahan
    • Dengan begitu, file lain yang juga perlu diperbaiki dapat lebih mudah ditemukan
  • Hal yang perlu diperhatikan
    • Untuk Python dan JavaScript, digunakan sistem tipe bertahap → perlu mengonfigurasi type checker secara ketat
    • Rust pada prinsipnya cocok untuk LLM, tetapi saat ini hasil generasinya belum sebaik Python/JavaScript

Pengujian Black Box (Black Box Testing)

  • Black box testing adalah cara menguji fungsi komponen tanpa mengetahui struktur internalnya
    • Karena file implementasi ikut masuk ke konteks, LLM sulit mematuhi prinsip black box testing
    • Pada Sonnet 3.7 (menggunakan Cursor), ada kecenderungan menjaga konsistensi kode → mencoba menghapus duplikasi di file tes
      • Namun, dalam black box testing, mempertahankan duplikasi justru membantu mendeteksi bug
  • Solusi ideal
    • LLM harus bisa melakukan masking atau ringkasan atas detail implementasi dari file yang dimuat
    • Arsitek perlu mendefinisikan dengan jelas batas information hiding

  • Example

    • Saat memperbaiki tes yang gagal, Sonnet 3.7 mengubah konstanta hardcoded agar dihitung berdasarkan algoritme asli
      • Padahal konstanta aslinya seharusnya tetap dipertahankan

Gunakan Server MCP (Use MCP Servers)

  • Server Model Context Protocol (MCP) menyediakan antarmuka standar agar LLM dapat berinteraksi dengan lingkungan
    • Server MCP banyak digunakan di mode agen Cursor dan Claude Code
    • Tanpa sistem RAG terpisah, LLM tetap bisa mencari dan mengubah file yang diperlukan lewat pemanggilan MCP
    • Model juga bisa langsung memperbaiki masalah setelah menjalankan tes atau build
  • Hal yang perlu dipertimbangkan saat membuat server MCP kustom
    • Di Cursor, setelah mengaktifkan mode YOLO, aturan Cursor dapat ditambahi perintah shell
      • Ini berbahaya → perintah shell arbitrer dapat merusak lingkungan
    • Alternatifnya: buat server MCP kustom yang hanya mengekspos perintah tertentu → keamanan lebih baik
      • Namun, per Maret 2025, pengaturan server MCP per proyek di Cursor masih kurang matang

  • Example

    • Sonnet 3.7 menggunakan MCP saat melakukan type check dan memperbaiki error pada proyek TypeScript
      • Proses bisa ditangani otomatis tanpa perlu copy-paste output terminal secara manual
      • Namun, kadang model menyimpulkan perintah yang salah (npm run typecheck)

Refactoring Persiapan (Preparatory Refactoring)

  • Refactoring persiapan adalah strategi melakukan refactoring lebih dulu sebelum perubahan utama agar pekerjaan menjadi lebih mudah
    • Karena refactoring adalah pekerjaan yang mempertahankan makna, evaluasinya lebih mudah dibanding perubahan aktual
    • Refactoring dulu lalu lakukan perubahan → review dan perbaikan error menjadi lebih mudah
  • Masalah pada LLM saat ini
    • Cenderung mencoba menangani seluruh pekerjaan sekaligus tanpa refactoring awal
    • Bahkan dapat melakukan pekerjaan perapian yang tidak diperlukan → berpotensi terjadi refactoring berlebihan
    • Cursor Sonnet 3.7 memiliki akurasi eksekusi instruksi yang kurang baik → dapat memicu refactoring yang tidak relevan
  • Cara perbaikan
    • Perlu instruksi eksplisit agar LLM hanya memodifikasi kode pada tahap refactoring sebelum perubahan utama
    • Definisikan dengan jelas cakupan kode yang boleh diedit oleh LLM → mencegah perubahan yang tidak perlu

  • Example

    • LLM diberi instruksi untuk memperbaiki error import → setelah itu ia menambahkan anotasi tipe pada fungsi lambda
      • Sebagian anotasi ditambahkan secara salah sehingga memicu loop agen

Mise en Place

  • Dalam dunia memasak, mise en place berarti menyiapkan semua bahan dan alat sebelum mulai bekerja
  • Dalam konteks LLM, mise en place berarti menyiapkan sepenuhnya aturan, MCP, dan lingkungan pengembangan yang dibutuhkan sebelum bekerja
    • Sonnet 3.7 lemah dalam memperbaiki lingkungan yang rusak
    • Ia bisa mencoba menyelesaikan masalah dengan copy-paste perintah dari StackOverflow → berisiko merusak lingkungan
    • Lingkungan harus dikonfigurasi dengan benar sebelum mulai agar Sonnet tidak terjebak dalam loop debugging

  • Example

    • Karena masalah npm link, VSCode gagal mengenali import dari proyek lokal lain
      • Cursor terobsesi menyelesaikan masalah ini saat memperbaiki lint dan tes, tetapi gagal menyadari bahwa npm unlink perlu dijalankan

Penggunaan alat tanpa status (Stateless Tools)

  • Alat harus dijalankan secara independen setiap kali tanpa menyimpan status
    • Shell bergantung pada status direktori kerja saat ini → dapat menimbulkan kebingungan akibat penyimpanan status
    • Sonnet 3.7 tidak dapat melacak status direktori kerja saat ini secara akurat
    • Perlu menyiapkan semua perintah agar dapat dijalankan dari direktori root proyek
  • Cara perbaikan
    • Minimalkan penggunaan perintah alat yang memerlukan perubahan status
    • Jika status benar-benar diperlukan, terus berikan status saat ini kepada model agar konsistensi terjaga

  • Contoh

    • Jika proyek TypeScript terdiri dari tiga modul: common, backend, dan frontend
      • Saat Cursor dijalankan dari root, perlu cd ke direktori yang sesuai → menimbulkan kebingungan direktori
      • Masalah teratasi dengan membuka tiap modul sebagai workspace terpisah

Mematuhi spesifikasi (Respect the Spec)

  • Saat mengubah sistem, bagian yang boleh diubah dan yang tidak boleh diubah harus dibedakan dengan jelas
    • Saat mengubah API publik, perlu mencegah rusaknya kompatibilitas ke belakang
    • Saat terintegrasi dengan sistem eksternal, harus menyesuaikan dengan API yang benar-benar ada → tidak bisa diubah sesuka hati
    • Jika pengujian gagal, tidak boleh menghapus test → harus mencari penyebabnya dan memperbaikinya
  • Masalah pada LLM
    • Peluang melanggar spesifikasi tinggi → bebas melakukan hal seperti menghapus test, mengubah API, dan sebagainya
    • Mematuhi spesifikasi memang masuk akal, tetapi mungkin tetap perlu dinyatakan eksplisit di prompt
    • Beberapa batasan hanya bisa ditemukan melalui code review

  • Contoh

    • Setelah gagal memperbaiki test, Sonnet mengganti isi test menjadi assert True
    • Fungsi public mengembalikan dict yang berisi key pass → Sonnet mencoba mengubahnya menjadi pass_ (masalah reserved word)

Metode buldoser (Bulldozer Method)

  • Metode buldoser adalah strategi menyelesaikan masalah lewat pekerjaan berulang yang sederhana dan meningkatkan kecepatan lewat efek pembelajaran
    • AI coding pada dasarnya kuat dalam pekerjaan berulang → dengan token yang cukup, refactoring skala besar dimungkinkan
    • Masalah yang ditinggalkan manusia karena merasa "terlalu banyak pekerjaan" juga bisa diselesaikan LLM
    • Namun, karena LLM dapat mengulang pekerjaan yang sama, perlu ditinjau apa yang sebenarnya sedang dilakukannya

  • Contoh

    • Saat mengubah fungsi inti di Haskell atau Rust, sering dibutuhkan refactoring yang luas
      • LLM dapat mengotomatisasi proses membaca error kompilasi → memperbaiki → kompilasi ulang
    • Saat mengubah nilai test yang di-hardcode, LLM dapat menjalankan ulang test lalu melakukan perbaikan otomatis

Memento

  • LLM tidak dapat mengingat status → pada setiap tugas, ia harus memahami ulang codebase dari awal
    • Pekerjaan dilakukan hanya dengan prompt, konteks eksplisit/implisit, dan file yang dimuat model dalam mode agent
    • Karena codebase dipahami ulang di setiap tugas, kegagalan setup awal meningkatkan kemungkinan salah jalan
  • Strategi pencegahan masalah
    • Sediakan dengan jelas dokumen yang bisa dirujuk LLM
    • Atur agar model dapat dengan mudah menemukan informasi yang dibutuhkannya
    • Berikan konteks seluruh proyek terlebih dahulu sebelum meminta perubahan penting

  • Contoh

    • Sonnet 3.7 diminta menyusun rencana end-to-end test untuk proyek yang sudah ada
      • Ia salah paham dan mengira tujuan utama seluruh proyek adalah testing → mengubah README agar berfokus pada test

Memperjelas kebutuhan (Requirements, not Solutions)

  • Kesalahan yang umum dalam software engineering adalah langsung mengusulkan solusi tanpa mendefinisikan kebutuhan dengan jelas
    • Jika ruang masalah cukup dibatasi, solusi bisa otomatis ditentukan hanya dengan mendefinisikan kebutuhan secara jelas
    • Jika kebutuhan tidak jelas, perdebatan yang tidak perlu tentang solusi bisa muncul
  • Masalah pada LLM
    • LLM tidak mengetahui kebutuhan → menghasilkan jawaban yang paling mungkin berdasarkan pola yang dilatih
    • Jika diminta mengerjakan sesuatu tanpa kebutuhan yang jelas, hasil yang melenceng bisa muncul
    • Salah tafsir dapat diperbaiki dengan mengubah prompt → tetapi jika salah tafsir itu sudah tertinggal dalam konteks, perbaikannya menjadi sulit
  • Cara perbaikan
    • Jika solusi dengan pendekatan tertentu memang dibutuhkan, instruksikan itu secara eksplisit
    • LLM mengikuti perintah dengan akurat, jadi jika diarahkan dengan cara yang salah, hasilnya juga bisa tidak akurat

  • Contoh

    • Saat Sonnet diminta membuat visualisasi, secara default ia membuat SVG
      • Jika disebutkan "interaktif", ia membuat aplikasi berbasis React → satu kata kunci dapat menimbulkan perbedaan besar

Debugging ilmiah (Scientific Debugging)

  • Cara memperbaiki bug terbagi menjadi dua
    • Mencoba perubahan secara acak lalu menyerahkannya pada keberuntungan
    • Menganalisis secara logis cara sistem bekerja untuk menemukan penyebab ketidaksesuaian antara keadaan nyata dan keadaan yang diharapkan
    • Debugging ilmiah (analisis logis) adalah pendekatan yang lebih baik dalam jangka panjang
  • Masalah pada LLM
    • LLM kurang memiliki kemampuan penalaran sehingga sulit memakai pendekatan ilmiah
    • Setelah "menebak jawaban yang benar", ia langsung mencoba memperbaiki → jika gagal, ia mengulang perubahan acak (agent loop)
    • Untuk debugging, model penalaran seperti Grok 3 dan DeepSeek-R1 lebih cocok
  • Cara perbaikan
    • Perintahkan model untuk menganalisis penyebab, atau pengguna memberi tahu penyebabnya → tingkat keberhasilan perbaikan meningkat
    • Jika penyebab masalah dijelaskan dengan tepat, model dapat mengusulkan solusi yang lebih baik

  • Contoh

    • Sonnet 3.7 mengalami error instalasi paket di lingkungan uv default yang tidak memiliki pip
      • Karena gagal menemukan penyebab, ia mengulang percobaan acak → token terbuang dan debugging gagal

Gunakan pemformatan kode otomatis (Use Automatic Code Formatting)

  • Alat pemformatan kode otomatis seperti gofmt, rustfmt, dan black berguna untuk menjaga konsistensi gaya kode
    • LLM lemah dalam mematuhi aturan mekanis (misalnya tidak ada spasi pada baris kosong, batas panjang baris 78 karakter, dll.)
    • Pemformatan sebaiknya diserahkan ke alat, dan LLM difokuskan pada pekerjaan yang lebih kompleks
  • Prinsip yang sama berlaku untuk perbaikan lint
    • Disarankan menggunakan lint yang bisa diperbaiki secara otomatis
    • Fokuskan resource LLM pada penyelesaian masalah yang kompleks

Ekor menggoyang anjing (The Tail Wagging the Dog)

  • Ini merujuk pada situasi ketika masalah kecil justru mengendalikan masalah yang lebih penting
    • Bisa terjadi ketika terlalu terobsesi menyelesaikan masalah level rendah hingga lupa tujuan utama penulisan kode secara keseluruhan
    • LLM memasukkan semua informasi ke dalam konteks sesi chat → sulit menilai tingkat kepentingan
  • Cara perbaikan
    • Berikan prompt yang jelas sejak awal → arahkan LLM agar fokus pada tugas penting
    • Claude Code menggunakan sub-agent untuk menjalankan tugas tertentu sehingga mencegah pencemaran konteks global

  • Contoh

    • Saat LLM diminta memikirkan cara melakukan tugas tertentu, ia bisa mencoba benar-benar melakukannya alih-alih hanya memikirkannya

Jaga ukuran file tetap kecil (Keep Files Small)

  • Perdebatan tentang ukuran file kode sudah berlangsung lama
    • Menerapkan prinsip tanggung jawab tunggal (satu kelas per file) vs membolehkan file besar sesuai situasi
    • Jika ukuran file terlalu besar, masalah bisa muncul saat sistem RAG memuat konteks per file
    • Di IDE seperti Cursor, penerapan patch bisa gagal → bahkan jika berhasil, waktu penerapannya menjadi lama
      • Contoh: di Cursor 0.45.17, penerapan 55 perubahan pada file 64KB memerlukan waktu yang cukup lama
    • Sonnet 3.7 kesulitan mengubah file yang lebih besar dari 128KB (batas context window 200K token)
  • Cara perbaikan
    • Jaga ukuran file tetap kecil → LLM dapat menangani hal seperti import secara otomatis

  • Contoh

    • Sonnet 3.7 mencoba memindahkan kelas test kecil di file Python berukuran 471KB
      • Perubahannya kecil, tetapi penerapan perubahan gagal di patcher Cursor

Mengenali Batasan (Know Your Limits)

  • Dalam situasi kekurangan alat atau keterbatasan kemampuan, perlu mengenali masalah dan meminta bantuan
    • Sonnet 3.7 lemah dalam mengenali keterbatasannya sendiri
    • Jika diberi prompt yang jelas, ia bisa mengenali batasannya → perlu menetapkan peringatan tentang kemungkinan halusinasi pada topik tertentu
  • Masalah
    • Sonnet 3.7 keliru mengira dirinya bisa menjalankan perintah shell
      • Jika tidak ada perintah shell, ia mencoba membuat skrip shell acak → berisiko merusak lingkungan
      • Setelah mengatakan "saya akan menjalankan X", bisa saja ia malah membuat pemanggilan untuk Y yang sama sekali berbeda
  • Cara perbaikan
    • Ubah prompt atau sediakan alat khusus yang hanya menjalankan tugas yang diinginkan
      • Dengan menyediakan alat tertentu, panggilan shell yang tidak relevan bisa dicegah

  • Example

    • Sonnet 3.7 mencoba membuat skrip shell yang tidak relevan saat memberi izin eksekusi pada file
      • Setelah terjadi kesalahan perintah, ia berulang kali mencoba perbaikan yang keliru

Baca Dokumentasinya (Read the Docs)

  • Saat mempelajari framework atau library baru, tugas sederhana bisa dilakukan dengan memodifikasi kode tutorial
    • Namun pada akhirnya, perlu membaca dokumentasi dari awal sampai akhir untuk memahami cara kerja keseluruhan
  • Kelebihan LLM
    • Framework populer sering kali sudah termasuk dalam pretraining sehingga sebagian besar cara pakainya diingat
    • Namun untuk alat yang kurang umum atau alat yang muncul setelah knowledge cutoff, halusinasi bisa terjadi
    • Sonnet tidak mendukung pencarian web → dokumentasi perlu diberikan secara manual
      • Di Cursor, saat URL diberikan, itu bisa otomatis dimasukkan ke dalam konteks

  • Example

    • Saat diminta menulis YAML untuk pemanggilan fungsi Python, LLM membuat konfigurasi yang salah
      • Setelah dokumentasi diberikan, perbaikan berhasil dan format output juga membaik

Budaya Mengalahkan Strategi (Culture Eats Strategy)

  • Budaya tim sangat memengaruhi kemampuan mengeksekusi strategi
    • LLM menghasilkan kode berdasarkan gaya yang telah dipelajari sebelumnya dan context window
    • Ia cenderung memilih library atau gaya yang sering muncul dalam konteks
      • Jika tidak dinyatakan secara eksplisit, gaya default akan diterapkan
  • Strategi untuk mengubah gaya LLM
    • Ubah aturan Cursor (mengubah prompt)
    • Refactor gaya kode yang ada menjadi bentuk yang diinginkan → memengaruhi prediksi token berikutnya
    • Ukuran codebase memberi pengaruh lebih besar daripada prompt → memodifikasi codebase adalah solusi yang lebih mendasar

  • Example

    • Sonnet 3.7 cenderung menyukai kode sinkron di Python
      • Agar kode asinkron dapat dihasilkan, sebagian besar kode yang ada dipindahkan ke async, lalu berhasil

Walking Skeleton

  • Walking Skeleton adalah strategi implementasi sistem end-to-end yang minimal
    • Meski belum sempurna, buat seluruh sistem berfungsi terlebih dahulu lalu lanjutkan dengan penyempurnaan detail
    • Di era AI coding dengan LLM, membangun seluruh sistem dengan cepat menjadi lebih mudah
    • Jika sistem sudah berjalan, langkah berikutnya menjadi jelas → penting untuk cepat mencapai kondisi berfungsi
    • Karena LLM tidak bisa langsung menggunakan kode yang ditulisnya sendiri, memastikan sistem dalam keadaan berjalan menjadi penting

Aturan Ketiga (Rule of Three)

  • Menyalin kode yang sama diperbolehkan sampai dua kali, tetapi saat salinan ketiga muncul, refactoring diperlukan
    • Ini adalah versi yang disempurnakan dari prinsip DRY (Don't Repeat Yourself)
    • Waktu untuk menghilangkan duplikasi jadi lebih jelas → lakukan refactoring pada salinan ketiga
  • Masalah pada LLM
    • LLM cenderung menghasilkan duplikasi kode
    • Jika diminta melakukan perubahan tanpa prompt yang jelas, ia akan menyalin ulang seluruh kode lalu mengubahnya
    • Penghapusan duplikasi hanya dilakukan jika model memutuskan sendiri untuk melakukannya → perlu instruksi yang jelas
  • Cara perbaikan
    • Perlu instruksi eksplisit untuk menghilangkan duplikasi
    • Jika kode yang ada sudah penuh duplikasi, model bisa terus menghasilkan duplikasi

  • Example

    • Saat diminta menulis kode pengujian, LLM membuat logika yang sama berulang di beberapa tes
      • Masalah terselesaikan setelah diberi instruksi eksplisit untuk membuat metode pembantu
      • mode agent

Bacaan terkait

1 komentar

 
GN⁺ 2025-03-20
Opini Hacker News

  • LLM membuat kesalahan dengan cara yang berbeda dari manusia, dan lebih sulit untuk menangkapnya

    • Kita punya pengalaman panjang dalam menangkap kesalahan manusia, tetapi sulit memahami cara berpikir LLM
    • Sulit merancang sistem untuk menangkap kesalahan LLM

  • Jika LLM tidak mengetahui kebutuhannya, ia akan mengisi jawaban yang paling mungkin dari data pelatihannya

    • Pelanggan harus menjelaskan dengan tepat apa yang diinginkan agar AI bisa menggantikan programmer

  • Dalam rekayasa perangkat lunak, memperjelas kebutuhan itu penting

    • Jika kebutuhan jelas, solusinya akan terarah dengan sendirinya
    • Saat mempelajari framework atau library baru, sebaiknya baca dokumentasinya dengan saksama
    • Saat memperbaiki bug, penting untuk meninjau asumsi sistem secara sistematis
    • Untuk duplikasi kode, sebaiknya lakukan refactor saat itu terjadi untuk ketiga kalinya

  • LLM memiliki kemampuan coding setara dengan "programmer junior yang sangat cerdas"

    • Kurang mampu melihat gambaran besar, dan hanya mengerjakan apa yang diminta
    • Model diperkirakan akan terus membaik

  • LLM terlalu berusaha memberi terlalu banyak jawaban

    • Jika tidak diberi data yang cukup, ia menghasilkan jawaban yang salah
    • Akan bagus jika LLM bisa mengatakan "butuh lebih banyak informasi"

  • Seiring makin banyaknya posting di blog, perlu ada penataan

    • Belum menemukan sistem pengorganisasian yang baik

  • Saran yang berguna saat coding dengan LLM

    • Ada perbedaan pendapat soal penggunaan static typing
    • Clojure memberi hasil yang lebih baik daripada Typescript
    • LLM lebih cocok untuk pendekatan yang berpusat pada fungsi

  • LLM lemah dalam komputasi dan aritmetika

    • Saat menghasilkan kode, penting mengambil angka dari posisi yang tepat
    • Debugging kode yang dihasilkan LLM memakan waktu

  • Hal-hal yang perlu dipertimbangkan bersama coder manusia

    • Manajer produk juga perlu memperhatikannya

  • Contoh tiga LLM yang menemukan "bug" yang sebenarnya tidak ada

    • Kodenya memang tidak dioptimalkan, tetapi bukan bug
    • Jarak antar blok kode pendek