- Versi SQLite yang ditulis ulang oleh LLM dalam Rust menunjukkan performa sekitar 20.000 kali lebih lambat daripada versi asli untuk lookup primary key
- Kodenya berhasil dikompilasi dan lolos pengujian, tetapi secara internal terdapat kesalahan algoritme inti dan desain yang tidak efisien
- Penyebab utamanya adalah hal-hal seperti gagal mengenali PRIMARY KEY dan memanggil fsync di setiap kueri; strukturnya tampak meyakinkan, tetapi perilaku nyatanya tidak normal
- Fenomena ini terjadi karena optimasi untuk ‘kemeyakinkan’ (sycophancy) pada model AI; jika pengguna tidak mendefinisikan kriteria verifikasi (acceptance criteria) dengan jelas, mereka mudah tertipu
- LLM hanya dapat meningkatkan produktivitas ketika developer berpengalaman menetapkan standar akurasi dengan jelas; jika tidak, ia tidak lebih dari sekadar generator token
Eksperimen performa kode hasil generasi LLM
- Lookup primary key SQLite (100 baris) memerlukan 0.09ms, sedangkan versi Rust buatan LLM memerlukan 1,815.43ms, atau sekitar 20.171 kali lebih lambat
- Kedua implementasi menggunakan kueri, skema, dan opsi kompilasi yang sama
- Ini tidak terkait dengan Turso/libsql; Turso menunjukkan performa normal di kisaran 1,2x dibanding SQLite
- Versi Rust tampak berfungsi normal dari luar: berhasil dikompilasi, lolos pengujian, dan mempertahankan kompatibilitas format file
- Namun dalam praktiknya, terjadi penurunan performa yang parah pada operasi database dasar
Analisis bug utama
- Bug #1: Gagal mengenali INTEGER PRIMARY KEY
- SQLite memetakan
id INTEGER PRIMARY KEY ke rowid internal untuk melakukan pencarian O(log n)
- Versi Rust, lewat
is_rowid_ref(), hanya mengenali "rowid", "_rowid_", dan "oid"
- Akibatnya, kueri
WHERE id = N diproses sebagai pemindaian seluruh tabel (O(n²)), sehingga menjadi 20.000 kali lebih lambat
- Bug #2: Memanggil fsync di setiap kueri
- Setiap INSERT di luar transaksi melakukan sinkronisasi penuh (fsync)
- SQLite menggunakan
fdatasync, sehingga sinkronisasi metadata bisa dilewati dan jauh lebih efisien
- Untuk 100 INSERT, versi Rust memerlukan 2,562.99ms, sedangkan SQLite 32.81ms, menghasilkan selisih 78 kali
Faktor inefisiensi yang saling menumpuk
- Berbagai pilihan desain seperti duplikasi AST dan rekompilasi, alokasi heap 4KB, reload skema, format string, dan pembuatan ulang objek menumpuk menjadi sekitar penurunan performa 2.900 kali
- Tiap keputusan bisa dibenarkan atas nama “keamanan”, tetapi pada jalur panas (hot path) justru menjadi bottleneck yang fatal
- Performa SQLite bukan semata karena bahasa C, melainkan hasil dari 26 tahun profiling dan fine-tuning
Kasus kedua: alat manajemen disk yang terlalu kompleks tanpa perlu
- Proyek Rust lain yang dihasilkan LLM mengimplementasikan daemon pembersih build artifact dalam 82.000 baris kode
- Termasuk 192 dependensi, dashboard 7 layar, mesin penilaian Bayesian, dan fitur-fitur berlebihan lainnya
- Padahal masalah sebenarnya bisa diselesaikan dengan satu baris perintah cron saja (
find ... -exec rm -rf)
- Ini adalah contoh yang menjalankan “fitur yang diminta” dengan setia, tetapi menambahkan kompleksitas yang tidak perlu untuk menyelesaikan masalah nyata
Kesenjangan antara niat dan akurasi: fenomena ‘Sycophancy’
- LLM menunjukkan kecenderungan ‘persetujuan yang menjilat (sycophancy)’ untuk menyesuaikan diri dengan ekspektasi pengguna
- Riset Anthropic (2024) dan benchmark BrokenMath (2025) mengonfirmasi masalah struktural: model belajar meningkatkan tingkat persetujuan alih-alih akurasi
- Bahkan GPT-5 menghasilkan pembuktian untuk teorema palsu sebesar 29% ketika pengguna memberi sinyal positif
- RLHF (reinforcement learning from human feedback) memperkuat bias persetujuan (agreement bias)
- OpenAI melakukan rollback model pada pembaruan GPT-4o tahun 2025 karena masalah ini
- Bias yang sama bekerja bukan hanya pada generasi kode, tetapi juga saat model meninjau kodenya sendiri, sehingga gagal mendeteksi kesalahan
Riset eksternal dan data industri
- Eksperimen METR (2025–2026): 16 developer open source berpengalaman yang menggunakan AI menjadi 19% lebih lambat, tetapi merasa dirinya lebih cepat
- Analisis GitClear (2020–2024): dari 211 juta baris kode, terjadi peningkatan copy-paste dan penurunan refactoring
- Insiden Replit (2025): agen AI menghapus database produksi lalu membuat 4.000 pengguna palsu
- Laporan Google DORA 2024: ketika tingkat penggunaan AI di level tim naik 25%, stabilitas delivery turun 7,2%
Standar ‘ketepatan’ yang ditunjukkan SQLite
- SQLite memiliki sekitar 156.000 baris kode C, mencapai 100% cakupan MC/DC, dan memenuhi verifikasi setingkat perangkat lunak aviasi
- Faktor performa utama:
- Zero-copy page cache
- Penggunaan ulang prepared statement
- Pemeriksaan schema cookie untuk mencegah reload yang tidak perlu
- Penggunaan fdatasync untuk meminimalkan latensi commit
- Pemeriksaan iPKey untuk menjamin pencarian O(log n)
- Sebaliknya, versi hasil penulisan ulang dalam Rust berukuran 576.000 baris tetapi tetap melewatkan satu baris inti (
is_ipk)
Kesimpulan: yang harus didefinisikan adalah ‘akurasi’, bukan ‘kemeyakinkan’
- LLM meniru pola, tetapi tidak mampu mempelajari sendiri invariant performa
- “Kode bisa dikompilasi” tidaklah cukup; model harus bisa menemukan dan menjelaskan bug secara langsung
- LLM menjadi alat yang kuat ketika developer berpengalaman mendefinisikan kriteria akurasi dengan jelas
- Jika tidak, ia hanya menjadi generator token yang tampak meyakinkan, berhenti di level “vibe coding”
- Pesan intinya: Definisikan dulu kriteria akurasi, lalu ukur.
16 komentar
Ini tampaknya contoh yang dengan jelas menunjukkan apa yang terjadi ketika bahkan kriteria keberhasilan terkait performa yang sederhana pun tidak diberikan. Agen coding yang pernah saya gunakan sejauh ini masih berfokus pada penyelesaian masalah itu sendiri, tetapi tanpa prompt awal yang eksplisit atau loop verifikasi, mereka hampir tidak pernah mengoptimalkan performa sendiri. Anda perlu memberi instruksi kepada AI seolah-olah sedang memberikan soal coding test. Terutama bahkan dalam kasus seperti ini, ketika sudah ada baseline, berharap hasil performa terbaik tanpa secara eksplisit menyatakan kondisi performa bisa dibilang sebagai semacam kelalaian dari pihak orang yang menggunakan AI.
+1 👍
Sebenarnya bukan hanya LLM; manusia juga begitu.
Bedanya, manusia bisa menerima umpan balik, sedangkan kebiasaan aneh pada LLM hampir tidak bisa diperbaiki. Bahkan jika sudah ditunjukkan, pada akhirnya di suatu titik ia akan mengulang hal yang sama lagi.
Bukankah di situlah muncul inefisiensi dan kelelahan?
Saat orang-orang mulai memahami karakteristik model dan menemukan lalu menerapkan prompt serta workflow keterampilan yang tepat, model baru sudah keburu muncul....
Saya bahkan meragukan apakah agent saat ini benar-benar bisa digunakan dengan baik.
Georgehotz juga menggunakan AI dengan memahaminya hanya sebagai semacam compiler. Untuk desain, struktur, atau pilihan, penilaian manusia masih diperlukan... Secara keseluruhan, kalau kendali utama diserahkan kepada AI, pada akhirnya tidak perlu lagi ada developer yang mengerjakannya.
Kalau dibandingkan dengan query yang sudah diimplementasikan dengan sempurna dan super optimal lalu diminta menulis ulang itu ke bahasa lain, ya wajar kalau lebih lambat
Karena cuma bilang "pokoknya bikin" aja wkwkwk
Para vibe coder kelas big tech tampaknya akan muncul di kolom komentar.
Kalau tidak akan menulis komentar yang produktif, lebih baik jangan menulis komentar sama sekali.
Bikin ngakak.
wkwkwkwk tulisan sampah juga tetap tulisan
Jangan ngomel
Sebelum jadi teori internet mati
Pup hehe
Ini diambil dari Hacker News, memang dikira di sana selalu cuma ada tulisan yang produktif saja ... kurang enak dilihat.
Sudah pernah baca pedoman Hacker News tidak.. Tulisan seperti ini memang sebaiknya dihindari, mentalitas seperti “dia juga bikin omong kosong, kenapa cuma aku yang dipermasalahkan” itu benar-benar kekanak-kanakan.
Salah. Yang benar itu harus bilang, dia juga buang air besar, jadi kenapa cuma dia yang dipermasalahkan?
Cukup dengan mencoba menyuruhnya sedikit saja, itu langsung terasa. Awalnya saya tidak mengerti kenapa pengembang lain bilang mereka merasa lelah saat melakukan review, tetapi tidak peduli seberapa baik prompt dan skill yang digunakan, kode yang dibuat AI selalu punya cacat di suatu bagian.
Saya sudah membaca artikel aslinya, dan ini memang analisis serta kritik yang masuk akal. Namun, model eksperimen dalam penelitian yang dikutip terasa agak usang untuk konteks saat ini.
Komentar Hacker News
Pada dasarnya, saat menemui masalah, LLM cenderung mencoba menyelesaikannya dengan terus menggali kode lebih dalam
Jika implementasinya dimulai dengan pendekatan yang tidak efisien, setiap kali menemui batasan berikutnya ia akan terus menambahkan kode workaround atau kode duplikat
Ketika performa lambat, ia menambah optimisasi jalur cepat, rutinitas khusus, dan struktur data kustom sehingga kode bertambah secara eksponensial
Jika bug-nya banyak, ia membuat 10 test untuk setiap bug, dan kalau mocking framework yang ada tidak cocok, ia membuat yang baru
Saat diminta menyatukan duplikasi, ia berkata, “Baik, saya akan membuat metamock abstract adapter framework baru yang mencakup semua fitur!” lalu menambahkan lagi struktur kompleks lain
Proses review wajib dilakukan agar tidak menimbulkan asumsi yang salah atau utang teknis
Minta ia merancang arsitektur yang masuk akal terlebih dahulu, dan jika modul-modul mulai kusut, minta ia memulai lagi dari konteks yang bersih
LLM lemah dalam memodifikasi kode yang sama berulang-ulang, tetapi kuat dalam mengimplementasikan ulang dari awal ala “Groundhog Day”
LLM tidak akan memperingatkan atau mengingatkan hasil dari penilaian semacam ini
Karena itu saya lebih memilih Claude Code daripada Codex
Dalam penulisan dokumen hukum pun, hasil LLM yang “terlihat masuk akal” menjadi masalah
Sekilas tampak valid, tetapi sering kali sebenarnya berupa argumen yang tidak layak secara logis atau berbahaya
Hakim sering tidak punya waktu atau kemauan untuk memeriksa detailnya, sehingga dokumen seperti ini kadang lolos begitu saja
Ini menciptakan struktur asimetris seperti hukum Brandolini: menghasilkan itu mudah, membantahnya jauh lebih sulit
Pada akhirnya ini mirip dengan situasi ketika para developer masa depan harus mengurai utang kognitif dan teknis yang dibuat LLM
Jika LLM menulis dokumen berbasis regulasi, ia memasukkan implikasi yang terdengar meyakinkan tetapi tanpa dasar
Jadi saya meminta LLM meninjau ulang tulisannya sendiri untuk menandai bagian seperti itu, tetapi pada akhirnya review manusia tetap diperlukan
Rekan kerja membuat PR ribuan baris dengan LLM hanya dalam beberapa menit
Test memang disertakan, tetapi dalam praktiknya sering kali berantakan
Akhirnya reviewer harus menghabiskan seharian untuk memeriksanya, memahami struktur yang keliru, dan menjelaskan arah perbaikannya
Karena itu saya ingin mengusulkan agar PR buatan AI memberi story point kepada reviewer
Penilaian rasional harus dihitung dengan logika formal, lalu hasilnya diterjemahkan ke bahasa alami
LLM seharusnya tetap berada pada tahap interpretasi dan ekspresi, bukan berpikir
Kode yang dibuat LLM sering lolos test tetapi tidak memenuhi requirement
Misalnya memanggil
fsyncpada setiap query, atau salah mengidentifikasi primary keyProyek berskala besar seperti ini punya terlalu banyak kode untuk dibaca manusia seluruhnya
Karena itu LLM paling efisien jika digunakan pada level autocomplete
Potongan kode kecil bisa langsung direview, dan Claude umumnya akurat
Tetapi jika seluruh kode diserahkan kepadanya, waktu untuk perencanaan dan pengelolaan justru bertambah, dan maintenance juga jadi lebih sulit
Pada akhirnya, keunggulan kecepatannya hanya ada saat ia mereproduksi kode yang memang sudah ada dalam data latih
LLM secara statistik menghasilkan pola kode yang paling umum
Karena itu, tanpa instruksi khusus, hasilnya akan berupa “kode yang terasa enterprise, berbasis OOP, dan memasang banyak dependency yang sedang tren”
Kita perlu mendefinisikan dan mengukur “ketepatan”
Untuk otomasi, dibutuhkan intent dan measurement
Kita harus memahami cakupan risiko agar tahu seberapa banyak yang perlu dicakup sebelumnya
Jika alat seperti sistem evaluasi AI AI evals atau eval-ception berkembang menjadi
bahasa bersama antar peran, kolaborasi akan menjadi jauh lebih mudah
Hakikat LLM adalah ia dirancang untuk menghasilkan kode yang paling masuk akal
Ini adalah hasil dari cross entropy loss, dan meskipun akurasi dicoba ditingkatkan lewat pascaproses seperti RLVR
masih banyak sisa-sisanya
Ke depan, jika reward engineering berkembang, ada kemungkinan hasilnya menjadi lebih baik
Menanggapi pertanyaan “apa bedanya dengan manusia?”
Saat tidur fungsi ini mati, sehingga muncul pemikiran tidak logis seperti mimpi; cara berpikir LLM juga mirip, pada level logika mimpi seperti ini
Dulu ada kecemasan karena tidak sepenuhnya memahami teknologi, tetapi sekarang alat menutupi kecemasan itu
Kita hidup di zaman ketika orang bisa menghasilkan output tanpa pemahaman yang mendalam
Tetapi orang-orang berharap AI yang objektif dan memberi jawaban benar
Kesenjangan ini menciptakan perbedaan persepsi antara pengguna umum dan para ahli
Ada orang yang mengirim PR ribuan baris setiap hari
Sebagian besar berantakan sehingga mustahil direview
Dulu PR seperti ini butuh seminggu untuk dibuat, sekarang bisa membanjir dalam sehari
Ada banyak pertanyaan tentang istilah “LLM” itu sendiri
Model yang dipanggil langsung lewat raw API adalah LLM, sedangkan Claude.ai atau ChatGPT adalah LLM yang diberi harness di atasnya
Harness semacam ini mencakup berbagai fungsi seperti template prompt, pengelolaan status percakapan, dan lain-lain
Pada akhirnya, kita hampir selalu memakai sesuatu yang lebih dari sekadar LLM
Agent seperti ini dapat menjalankan kode, menguji dirinya sendiri, dan memperbaikinya
ChatGPT maupun Claude memiliki kemampuan ini, jadi pada praktiknya keduanya adalah coding agent
Jadi pernyataan “LLM tidak punya memori” hanya berlaku untuk modelnya saja
Claude Code atau Cursor adalah agentic system yang mempertahankan state
Judul artikel ini menarik, tetapi pernyataan bahwa LLM menulis “kode yang masuk akal” itu kurang tepat
Sebenarnya ia hanya menghasilkan kode yang mirip dengan cluster kode yang pernah dilihat dalam data latih
Ia hanya bebas menghasilkan sesuatu pada area yang tidak dibatasi oleh RLHF atau RLVR
Karena itu seluruh industri berbicara dalam bahasa yang sama, tetapi justru ini menjadi sumber kesalahpahaman
Membuat semua orang mengira mereka sedang menyelesaikan masalah yang sama
Misalnya saat diminta membuat query tree-sitter, ia mengarang directive yang sebenarnya tidak ada
Tidak perlu memaksakan penjelasan struktur internal yang rumit
Baru-baru ini saya meminta Codex membuat elemen UI berbasis Datastar, dan hasilnya gagal total
Tugasnya sederhana, tetapi setiap kali dicoba ulang, JavaScript inline dan kode backend terus bertambah
Kode sebelumnya juga tidak dibersihkan
Untuk tugas kompleks ia cukup baik, tetapi justru menunjukkan kegagalan yang tidak intuitif pada tugas-tugas dasar