Cursor Bangun Ulang SQLite dengan Rust dan Agen AI

Cursor membangun ulang SQLite dalam Rust melalui sebuah eksperimen yang menguji batas koordinasi banyak agen kecerdasan buatan. Tantangannya tidak kecil: sistem tersebut hanya menerima manual SQLite setebal 835 halaman, tanpa kode sumber SQLite, tanpa berkas biner, tanpa test suite asli, dan tanpa akses internet. Hasil akhirnya berupa replika mesin basis data dalam Rust yang, menurut pengujian Cursor, mampu melewati 100% test suite SQL yang disimpan terpisah.

Eksperimen ini bukan sekadar demonstrasi bahwa model dapat menghasilkan kode dalam jumlah besar. Fokus utamanya adalah bagaimana sekumpulan agen dapat membagi pekerjaan, menyimpan keputusan desain, menangani konflik perubahan kode, melakukan peninjauan, dan mengendalikan biaya penggunaan model. Dari sini muncul pelajaran penting tentang agent swarm, arsitektur perencana-pelaksana, serta ekonomi penggunaan model AI untuk pekerjaan rekayasa perangkat lunak yang kompleks.

Apa yang Dilakukan Cursor dalam Eksperimen SQLite Rust?

Cursor menjalankan sekelompok agen AI untuk membuat implementasi baru SQLite menggunakan bahasa pemrograman Rust. Agen tidak diberi salinan kode SQLite, tidak diberi test suite, dan tidak dapat mencari jawaban dari internet. Satu-satunya referensi yang tersedia adalah dokumentasi resmi SQLite.

Eksperimen Cursor membangun ulang SQLite dalam Rust adalah pengujian sistem multiagen yang menerjemahkan spesifikasi perangkat lunak berukuran besar menjadi implementasi basis data fungsional, lalu mengukurnya dengan test suite SQL yang tidak pernah diperlihatkan kepada agen.

SQLite dipilih karena tingkat kompleksitasnya tinggi. SQLite bukan sekadar parser SQL. Sistem ini mencakup penyimpanan data, mesin kueri, tipe data, transaksi, ekspresi, indeks, penanganan kesalahan, dan banyak aturan perilaku yang saling berhubungan.

Dokumentasi SQLite memang luas, tetapi dokumentasi tetap berbeda dari kode sumber. Dokumen menjelaskan perilaku dan antarmuka, sedangkan implementasi memerlukan keputusan rinci mengenai struktur data, arsitektur modul, alur eksekusi, serta pengujian pada banyak kasus tepi.

Cursor menggunakan dokumentasi SQLite sebagai bahan spesifikasi. Setelah proses pembangunan selesai, hasil kerja agen dinilai memakai sqllogictest, yaitu pengujian yang membandingkan keluaran sistem basis data terhadap hasil SQL yang diketahui benar.

Batasan eksperimen yang perlu dipahami

Pencapaian 100% pada test suite tertahan tidak sama dengan membuktikan bahwa hasilnya identik dengan SQLite produksi dalam seluruh aspek. Pengujian SQL dapat memberikan bukti kuat terhadap kebenaran keluaran pada kasus yang diuji, tetapi tidak otomatis menilai:

Performa kueri dibandingkan SQLite asli
Efisiensi memori
Ketahanan terhadap kegagalan proses
Keamanan
Kompatibilitas penuh terhadap seluruh ekstensi dan perilaku SQLite
Ketepatan transaksi, penguncian, serta konkurensi pada semua kondisi
Kualitas pemeliharaan kode dalam jangka panjang

Pembedaan ini penting karena sebuah mesin basis data yang mengembalikan hasil SQL benar masih dapat memiliki kelemahan operasional. Basis data produksi menuntut lebih dari kompatibilitas keluaran kueri.

Meski begitu, eksperimen ini tetap menunjukkan kemajuan berarti. Sistem multiagen mampu menerjemahkan spesifikasi yang sangat besar menjadi program yang cukup lengkap untuk menghadapi evaluasi SQL tersembunyi.

Mengapa SQLite Menjadi Ujian yang Berat untuk Agen AI?

Membangun aplikasi sederhana dari spesifikasi tertulis berbeda jauh dari membangun mesin basis data. Pada aplikasi biasa, kesalahan lokal kadang hanya memengaruhi satu layar, satu formulir, atau satu integrasi. Dalam mesin basis data, kesalahan kecil dapat memengaruhi hasil kueri, konsistensi data, atau perilaku seluruh komponen.

SQLite juga terkenal sebagai perangkat lunak yang matang. Proyek ini telah berkembang selama bertahun-tahun dan digunakan secara luas pada perangkat seluler, peramban, aplikasi desktop, sistem tertanam, serta produk komersial.

Kompleksitas tidak hanya terletak pada SQL

Banyak orang menganggap basis data SQL terutama berkaitan dengan perintah seperti SELECT, INSERT, UPDATE, dan DELETE. Kenyataannya, implementasi database harus menangani lapisan yang lebih luas.

Beberapa bagian penting dalam sistem semacam SQLite antara lain:

Parser SQL
Bertugas membaca perintah SQL dan mengubahnya menjadi representasi yang dapat diproses mesin.
Perencana dan eksekutor kueri
Menentukan bagaimana kueri dijalankan, kemudian menghasilkan data atau perubahan yang sesuai.
Penyimpanan data
Menangani cara tabel, halaman data, indeks, dan metadata disimpan serta dibaca kembali.
Sistem tipe dan ekspresi
Mengelola angka, teks, nilai NULL, perbandingan, fungsi, operasi aritmetika, dan aturan konversi tipe.
Konsistensi perubahan data
Menjaga agar operasi tulis dan pembaruan tidak menghasilkan keadaan data yang rusak.
Penanganan kesalahan
Memberikan respons yang benar untuk sintaks salah, tipe yang tidak cocok, tabel yang tidak ditemukan, atau kondisi yang tidak didukung.
Pengujian lintas fitur
Memastikan fitur yang tampak terpisah tetap bekerja ketika digabungkan dalam satu kueri.

Pada sistem seperti ini, satu keputusan desain dapat berdampak ke banyak modul. Perubahan pada representasi nilai, misalnya, dapat memengaruhi filter, pengurutan, agregasi, indeks, dan penyimpanan.

Dokumentasi adalah spesifikasi, bukan resep implementasi

Manual SQLite menjelaskan perilaku yang diharapkan. Namun, dokumen tidak selalu memberi jawaban tunggal tentang cara membangun setiap komponen secara internal.

Agen harus menafsirkan spesifikasi, membuat keputusan desain, membagi pekerjaan, lalu menyatukan hasilnya. Di sinilah eksperimen Cursor tidak hanya menguji kemampuan menghasilkan kode, tetapi juga menguji kemampuan mengelola pekerjaan rekayasa.

Arsitektur Agent Swarm Cursor: Planner dan Worker

Temuan utama dari eksperimen Cursor adalah pemisahan peran antara agen perencana dan agen pelaksana. Arsitektur ini menempatkan masalah besar dalam bentuk pohon pekerjaan.

Tujuan utama berada pada bagian atas pohon. Tujuan tersebut kemudian dipecah menjadi komponen yang lebih kecil, lalu dipecah lagi hingga menjadi tugas implementasi yang dapat dikerjakan secara fokus.

Peran planner dalam agent swarm

Agen planner berperan menangani keputusan yang memerlukan pemahaman menyeluruh. Tugas planner dapat meliputi:

Memecah tujuan besar menjadi subproyek
Menentukan batas antarmodul
Menetapkan urutan ketergantungan pekerjaan
Membuat keputusan desain
Menyimpan keputusan penting dalam dokumen bersama
Mendeteksi pekerjaan yang tumpang tindih
Mengarahkan perbaikan ketika desain antarkomponen bertentangan

Planner tidak seharusnya tenggelam dalam detail implementasi yang sangat lokal. Jika planner ikut melakukan setiap perubahan kecil, konteks kerja akan dipenuhi log debugging, detail fungsi, dan masalah sempit yang mengaburkan gambaran besar.

Peran worker dalam agent swarm

Agen worker menerima tugas yang lebih terarah. Contohnya dapat berupa:

Menerapkan parser untuk bagian tertentu dari sintaks SQL
Menambahkan dukungan ekspresi
Membuat struktur data untuk tabel atau indeks
Menulis pengujian internal
Memperbaiki kesalahan kompilasi
Mengintegrasikan fungsi spesifik
Merapikan modul yang terlalu besar

Worker tidak perlu terus-menerus mempertimbangkan arsitektur seluruh basis data. Fokus yang lebih sempit membuat konteks kerja lebih efisien.

Aspek	Planner	Worker
Fokus utama	Strategi dan struktur sistem	Implementasi tugas spesifik
Tingkat konteks	Gambaran besar dan ketergantungan	Detail lokal pada modul atau masalah
Jenis keputusan	Arsitektur, prioritas, pembagian kerja	Kode, pengujian, perbaikan lokal
Model yang cocok	Model dengan penalaran kuat	Model cepat dan lebih hemat
Risiko utama	Menjadi hambatan keputusan	Kehilangan konteks antarbagian

Pemisahan ini menjawab masalah umum dalam agen jangka panjang. Agen tunggal harus memegang tujuan utama, riwayat perubahan, detail implementasi, hasil pengujian, dan kondisi kode sekaligus. Seiring waktu, konteks tersebut dapat membesar dan membuat keputusan makin tidak konsisten.

Mengapa Pemisahan Planner dan Worker Penting?

Satu agen yang mengerjakan proyek besar dapat mengalami dua masalah yang bertolak belakang. Agen dapat terlalu fokus pada detail lokal hingga kehilangan arah sistem, atau terlalu menjaga gambaran besar hingga implementasi lokal menjadi dangkal.

Cursor berargumen bahwa efisiensi konteks lebih penting daripada sekadar menjalankan banyak agen secara paralel. Paralelisme memang meningkatkan jumlah pekerjaan yang terjadi bersamaan, tetapi tanpa koordinasi yang baik, paralelisme justru mempercepat kekacauan.

Pohon tugas sebagai pengendali kompleksitas

Dalam model pohon, tugas besar diturunkan menjadi tugas yang makin spesifik. Misalnya, pembangunan mesin basis data dapat dibagi menjadi:

Arsitektur mesin SQL
Parser dan representasi sintaks
Penyimpanan tabel
Sistem nilai dan tipe data
Eksekusi kueri
Agregasi dan pengurutan
Penanganan error
Pengujian integrasi

Setiap cabang kemudian dipecah lagi. Cabang parser dapat dibagi menjadi tokenisasi, ekspresi, perintah definisi data, perintah manipulasi data, dan validasi sintaks.

Struktur ini membuat satu agen tidak perlu memahami seluruh proyek sebelum menghasilkan kontribusi. Namun, struktur tersebut juga harus memiliki titik koordinasi. Tanpa itu, banyak agen dapat membangun solusi berbeda untuk masalah yang sama.

Perencanaan berkualitas mengurangi biaya di lapisan bawah

Salah satu hasil paling penting dari eksperimen Cursor adalah biaya tidak hanya ditentukan oleh model yang dipilih. Biaya juga ditentukan oleh kualitas instruksi yang diteruskan dari planner ke worker.

Planner yang tepat dapat mengubah masalah ambigu menjadi tugas yang jelas. Worker yang lebih murah lalu dapat mengerjakan tugas tersebut tanpa menghabiskan token untuk menebak arah desain.

Sebaliknya, planner yang kurang tepat mungkin memakai token lebih sedikit, tetapi menghasilkan pekerjaan lanjutan yang lebih banyak. Worker kemudian mengulang implementasi, memperbaiki konflik, atau menghabiskan waktu menyesuaikan perubahan desain.

Hasil Pengujian: Dari 80% dalam Empat Jam hingga 100%

Cursor membandingkan sistem swarm lama dan sistem baru dalam tugas pembangunan ulang SQLite. Pada salah satu konfigurasi, swarm baru mencapai sekitar 80% kelulusan test suite SQL dalam empat jam, sementara sistem lama mengalami masalah sebelum melewati dua jam.

Dalam laporan Cursor, hasil empat jam pada konfigurasi baru berada dalam kisaran sekitar 73% hingga 85%, tergantung kombinasi model yang digunakan. Seluruh konfigurasi swarm baru kemudian dilaporkan mencapai 100% pada suite tersebut setelah waktu eksperimen perbandingan utama.

Perbedaan antara swarm lama dan swarm baru

Perbedaan tidak hanya tampak pada skor pengujian. Perilaku sistem juga berubah.

Sistem lama menghasilkan aktivitas yang jauh lebih tinggi dalam bentuk commit, tetapi aktivitas itu tidak selalu berarti kemajuan. Dalam satu perbandingan menggunakan Grok 4.5, sistem lama menghasilkan puluhan ribu commit dalam waktu singkat dan mengalami konflik merge dalam jumlah besar.

Sistem baru bergerak lebih teratur. Jumlah perubahan tidak dijadikan ukuran utama produktivitas. Fokusnya adalah menjaga arsitektur tetap koheren, menekan konflik, dan mengubah pekerjaan menjadi kemajuan yang dapat diuji.

Metrik	Swarm lama	Swarm baru
Pola kerja	Banyak aktivitas dan perubahan cepat	Pembagian tugas lebih terstruktur
Konflik merge	Sangat tinggi pada percobaan tertentu	Jauh lebih rendah
Struktur paket	Cenderung berkembang tidak terkendali	Lebih stabil dan terbatas
Kecepatan commit	Sangat tinggi, berisiko menghasilkan churn	Lebih terkendali
Hasil pengujian	Beragam dan dapat berhenti lebih awal	Mengungguli sistem lama pada konfigurasi yang diuji
Biaya model	Tidak seefisien pembagian peran	Dapat dioptimalkan dengan model campuran

Data tersebut memperlihatkan bahwa jumlah commit bukan ukuran kualitas rekayasa perangkat lunak. Sistem dapat membuat perubahan kode terus-menerus sambil sebenarnya menjauh dari arsitektur yang sehat.

Mengapa skor 100% tetap perlu dibaca secara hati-hati?

Cursor menyatakan bahwa agen tidak mengetahui keberadaan test suite evaluasi. Setelah setiap eksperimen, hasil juga ditinjau untuk mencari kemungkinan jalan pintas atau penyimpangan yang tidak merata.

Langkah ini memperkuat kredibilitas evaluasi, tetapi belum menggantikan reproduksi independen. Eksperimen dilakukan oleh pihak yang juga membangun sistem, memilih konfigurasi, dan melakukan pengujian internal.

Interpretasi yang paling tepat adalah sebagai berikut:

Cursor menunjukkan bahwa arsitektur swarm baru bekerja lebih baik daripada harness sebelumnya pada tugas ini.
Hasil tersebut memberi bukti kuat terhadap kemampuan koordinasi sistem pada evaluasi SQL yang digunakan.
Hasil tersebut belum membuktikan kesetaraan penuh dengan SQLite produksi.
Hasil tersebut belum membuktikan performa tinggi, keamanan menyeluruh, atau keandalan pada seluruh kondisi operasional.

Tantangan Koordinasi pada 1.000 Commit per Detik

Cursor menjelaskan bahwa sistem swarm terbaru dapat mencapai sekitar 1.000 commit per detik. Angka ini jauh melampaui ritme kerja manusia dan juga melampaui kapasitas alat pengembangan biasa yang dirancang untuk kolaborasi tim manusia.

Pada eksperimen terdahulu, swarm menggunakan Git dan mencapai sekitar 1.000 commit per jam. Untuk sistem terbaru, Cursor membangun sistem kontrol versi khusus agar mampu menangani laju perubahan yang jauh lebih tinggi.

Mengapa Git biasa tidak cukup untuk swarm berkecepatan tinggi?

Git sangat efektif untuk kerja pengembangan sehari-hari. Namun, proses Git normal mengasumsikan jumlah kontributor yang terbatas, ritme perubahan yang tidak ekstrem, dan banyak komunikasi manusia di sekitar pull request, code review, serta merge queue.

Dalam swarm besar, ratusan atau ribuan agen dapat mengubah berkas yang sama dalam waktu hampir bersamaan. Masalahnya bukan hanya throughput penyimpanan commit, tetapi juga makna dari perubahan yang saling bertabrakan.

Konflik semacam ini tidak selalu dapat diselesaikan dengan aturan merge otomatis. Dua agen mungkin sama-sama menulis kode yang valid, tetapi didasarkan pada asumsi arsitektur berbeda.

Lima kegagalan koordinasi yang dihadapi Cursor

Cursor mengidentifikasi beberapa pola kegagalan khas dalam proyek multiagen berskala besar.

1. Split-brain design

Dua planner dapat memutuskan solusi berbeda untuk konsep yang sama, tanpa menyadari bahwa keduanya sedang menjawab pertanyaan desain identik.

Contohnya, satu cabang proyek dapat membuat representasi nilai SQL tertentu, sementara cabang lain membuat representasi lain. Kedua pendekatan mungkin bekerja secara lokal, tetapi akan berbenturan saat integrasi.

Cursor mencoba mengatasinya dengan menugaskan planner untuk membuat keputusan desain secara eksplisit dan memastikan subpohon tugas tidak membuat keputusan yang sama secara terpisah.

2. Konflik antarplanner

Masalah yang lebih sulit muncul ketika planner saling mengetahui keberadaan, tetapi tetap mengubah berkas yang sama secara bolak-balik.

Cursor menggunakan dokumen desain bersama untuk menyimpan keputusan. Kode yang bergantung pada keputusan tertentu dapat membawa referensi yang diperiksa saat kompilasi. Saat terdapat kontradiksi, agen rekonsiliasi dapat menyatukan dokumen desain, kemudian perubahan mengalir ke bagian kode yang bergantung padanya.

3. Merge conflict

Worker sering kali tidak memiliki konteks cukup untuk menyelesaikan konflik merge secara adil. Agen mungkin menimpa perubahan pihak lain atau meninggalkan tugasnya.

Untuk mengatasi masalah ini, Cursor menggunakan agen netral yang bertugas menyelesaikan konflik. Perannya bukan membela perubahan dari satu pihak, tetapi mencari penggabungan yang efisien dan konsisten terhadap tujuan sistem.

4. Megafile

Berkas besar menjadi titik kemacetan. Banyak agen mungkin menambahkan sedikit kode ke berkas yang sama sampai berkas tersebut sulit dibaca, sulit dipindahkan, mahal untuk dibandingkan, dan rentan konflik.

Cursor memberi worker kemampuan menandai berkas yang terlalu besar. Setelah ditandai, perubahan baru dapat dibatasi sementara agen lain memecah berkas tersebut menjadi modul yang lebih kecil.

5. Ossification

Agen yang terbiasa dengan basis kode manusia dapat menghindari perubahan pada komponen inti. Sikap terlalu hati-hati ini dapat membuat desain lama bertahan meski sudah tidak cocok.

Cursor memperbolehkan perubahan inti yang disengaja apabila agen menyertakan alasan yang jelas. Kompiler kemudian membantu menyebarkan dampaknya karena bagian yang masih bergantung pada desain lama akan gagal dibangun dan membutuhkan penyesuaian.

Version Control Khusus untuk Agen: Lebih dari Sekadar Menyimpan Commit

Sistem kontrol versi dalam eksperimen Cursor tidak hanya berfungsi sebagai tempat menyimpan riwayat kode. Sistem tersebut menjadi lapisan koordinasi untuk mendeteksi benturan, menerapkan mekanisme resolusi, dan menjaga arus kerja ribuan agen.

Dalam pengembangan multiagen, sistem kontrol versi dapat menjadi lapisan koordinasi aktif: bukan hanya menyimpan perubahan, melainkan mendeteksi konflik desain, mengarahkan rekonsiliasi, dan menjaga perubahan tetap dapat diintegrasikan.

Konsep ini penting karena agent swarm menghadapi tingkat perubahan yang tidak lazim bagi tim manusia. Jika seluruh komunikasi harus dilakukan melalui percakapan langsung antarpelaku, biaya koordinasi akan meningkat tajam.

Sebagai gantinya, lingkungan kerja menjadi media komunikasi. Dokumen desain, compiler error, struktur folder, status berkas, dan riwayat keputusan dapat menjadi sinyal bagi agen lain.

Stigmergy dalam pengembangan perangkat lunak

Cursor mengaitkan pendekatan ini dengan stigmergy, yaitu pola koordinasi ketika pelaku memengaruhi lingkungan dan lingkungan tersebut memengaruhi tindakan pelaku berikutnya. Konsep ini sering digunakan untuk menjelaskan koordinasi pada semut atau rayap tanpa komunikasi langsung yang rumit.

Dalam konteks perangkat lunak, bentuknya dapat berupa:

Dokumen desain yang mencatat keputusan arsitektur
Berkas panduan yang diperbarui berdasarkan masalah sebelumnya
Status berkas yang menunjukkan sedang ada konflik atau restrukturisasi
Kesalahan kompilasi yang memberi tahu bagian mana perlu diperbaiki
Batas modul yang mengarahkan ruang lingkup tugas

Agen tidak perlu menerima seluruh riwayat percakapan proyek. Agen cukup menerima konteks yang relevan dari lingkungan kerja yang telah dibentuk.

Field Guide: Memori Bersama yang Dikurasi Agen

Cursor juga memperkenalkan konsep Field Guide, sebuah folder yang dikelola agen dan diinjeksikan ke konteks agen baru melalui berkas indeks.

Tujuannya adalah menangkap temuan yang tidak jelas sejak awal. Misalnya, pola kegagalan yang sering muncul, konvensi yang harus diikuti, atau cara penyelesaian masalah yang sebelumnya menghabiskan banyak waktu.

Namun, Field Guide tidak dibuat tanpa batas. Ada anggaran panjang atau line budget. Batas ini penting agar memori bersama tidak tumbuh menjadi dokumen besar yang justru menambah beban konteks.

Mengapa memori bersama perlu dibatasi?

Catatan bersama yang terlalu panjang dapat menimbulkan masalah baru:

Agen menghabiskan konteks untuk membaca informasi lama
Informasi penting tenggelam di antara detail yang tidak relevan
Panduan menjadi sulit dikurasi
Aturan lama dapat berbenturan dengan desain baru
Agen mengikuti kebiasaan usang tanpa mengevaluasi relevansinya

Field Guide mengharuskan agen memilih informasi yang paling berguna untuk generasi agen berikutnya. Prinsipnya bukan menyimpan seluruh aktivitas, melainkan menyimpan kejutan, jebakan, dan keputusan yang dapat mempersingkat pekerjaan setelahnya.

Ekonomi Model: Mengapa Biaya Bisa Berbeda hingga 15 Kali Lipat?

Salah satu temuan paling menonjol dari eksperimen Cursor adalah bahwa kualitas akhir yang serupa tidak selalu membutuhkan biaya model yang sama. Cursor melaporkan variasi biaya hingga sekitar 15 kali lipat bergantung pada kombinasi model yang digunakan untuk planner dan worker.

Pada konfigurasi yang dibandingkan, Cursor menguji model frontier sebagai planner dan worker, serta kombinasi planner berkemampuan tinggi dengan worker yang lebih hemat biaya.

Konfigurasi yang diuji Cursor

Cursor melaporkan empat kombinasi utama:

GPT-5.5 sebagai planner dan worker
Grok 4.5 sebagai planner dan worker
Opus 4.8 sebagai planner dengan Composer 2.5 sebagai worker
Fable 5 sebagai planner dengan Composer 2.5 sebagai worker

Tujuan perbandingan bukan hanya mencari model terbaik. Fokusnya adalah melihat bagaimana kualitas, konsumsi token, biaya, serta pola kerja berubah ketika peran strategis dan eksekusi dijalankan oleh model berbeda.

Distribusi token tidak sama dengan distribusi biaya

Worker menghasilkan sebagian besar token dalam eksperimen tersebut. Cursor melaporkan bahwa worker menggunakan setidaknya 69% dari total token pada setiap konfigurasi, dan pada sebagian besar konfigurasi jumlahnya melebihi 90%.

Namun, planner dapat menyumbang bagian biaya besar karena token planner berasal dari model yang lebih mahal.

Pertanyaan	Temuan dari eksperimen
Siapa yang menggunakan token paling banyak?	Worker, karena menangani banyak tugas implementasi
Siapa yang dapat menyumbang biaya besar?	Planner, jika memakai model premium
Apakah model termahal harus dipakai untuk semua tugas?	Tidak selalu
Mengapa worker murah dapat efektif?	Tugas sudah dipersempit melalui perencanaan yang jelas
Apa risiko model campuran?	Planner yang kurang tepat dapat meningkatkan pekerjaan worker

Pada salah satu perbandingan yang disebut Cursor, konfigurasi hybrid Opus 4.8 sebagai planner dan Composer 2.5 sebagai worker memiliki biaya sekitar US$1.339. Konfigurasi GPT-5.5 untuk planner dan worker mencapai sekitar US$10.565.

Perbedaan tersebut tidak berarti satu kombinasi selalu lebih baik pada semua proyek. Namun, data itu menunjukkan bahwa pemilihan model harus dilihat sebagai keputusan sistem, bukan sebagai keputusan tunggal berdasarkan peringkat benchmark.

Tugas mana yang membutuhkan model frontier?

Cursor menyampaikan gagasan bahwa hanya sebagian kecil dari proyek besar yang benar-benar memerlukan penalaran frontier. Contohnya:

Memecah tujuan yang ambigu
Memilih arsitektur
Menetapkan antarmuka penting
Menilai kompromi teknis
Mengoreksi konflik desain
Membuat keputusan dengan dampak lintas modul

Setelah keputusan tersebut berubah menjadi spesifikasi yang eksplisit, banyak pekerjaan pelaksanaan dapat diberikan kepada model yang lebih cepat dan lebih murah.

Pola ini menyerupai organisasi rekayasa manusia. Tidak setiap tugas membutuhkan keterlibatan arsitek senior, tetapi keputusan yang salah pada tahap awal dapat menyebabkan biaya perbaikan besar di tahap akhir.

Review Berlapis: Mengapa Satu Reviewer Tidak Cukup?

Dalam sistem agen yang berjalan lama, kesalahan dapat menumpuk. Kesalahan kecil yang tidak tertangkap dapat menjadi dasar bagi pekerjaan selanjutnya, lalu membesar saat banyak modul bergantung pada asumsi yang keliru.

Cursor mencoba menggunakan beberapa review lens atau sudut peninjauan. Setiap reviewer tidak harus melihat hal yang sama.

Beberapa pendekatan peninjauan dapat mencakup:

Meninjau hasil akhir kode
Meninjau perubahan tertentu
Meninjau konteks kerja agen
Meninjau struktur kode secara lebih luas
Menggunakan model yang berbeda untuk mengurangi bias seragam
Memeriksa hasil pengujian dan regresi

Nilai dari reviewer yang tidak berkorelasi

Jika semua reviewer memakai pendekatan, data, dan pola penalaran yang sama, kesalahan tertentu dapat lolos dari semuanya. Sebaliknya, reviewer dengan sudut pandang berbeda dapat menangkap masalah yang tidak terdeteksi oleh reviewer lain.

Misalnya:

Reviewer pertama fokus pada kompatibilitas antarmuka
Reviewer kedua fokus pada kompleksitas kode
Reviewer ketiga fokus pada hasil pengujian
Reviewer keempat fokus pada konsistensi dengan dokumen desain

Pendekatan ini tidak menjamin kesempurnaan. Namun, review berlapis dapat meningkatkan peluang menemukan masalah sebelum kesalahan menyebar lebih jauh.

Cursor menyebut biaya review sebagai investasi dengan potensi imbal hasil tinggi. Meninjau pekerjaan umumnya lebih murah daripada membuat ulang pekerjaan yang salah setelah terintegrasi ke banyak bagian sistem.

Spesifikasi Menjadi Unit Kerja Baru

Salah satu gagasan paling menarik dari laporan Cursor adalah pergeseran unit kerja rekayasa perangkat lunak. Dahulu, kemampuan AI mungkin dipahami sebagai bantuan untuk satu baris kode, lalu satu fungsi, satu berkas, atau satu fitur.

Dalam sistem swarm, unit kerja dapat bergeser menjadi spesifikasi.

Pada agent swarm, spesifikasi yang jelas dapat berfungsi seperti sumber program tingkat tinggi. Planner menerjemahkannya menjadi pohon tugas, lalu worker menurunkannya menjadi perubahan kode dan pengujian.

Analogi ini mirip proses kompilasi. Compiler menerjemahkan kode tingkat tinggi menjadi instruksi yang lebih rendah tingkatannya. Swarm menerjemahkan maksud atau kebutuhan menjadi keputusan desain, subtugas, kode, perbaikan, dan verifikasi.

Perbedaannya, compiler tradisional bekerja secara deterministik. Agent swarm bekerja secara probabilistik. Karena itu, sistem membutuhkan kontrol tambahan seperti dokumen keputusan, review, pengujian, rekonsiliasi, serta mekanisme konflik.

Kualitas spesifikasi menjadi semakin penting

Jika spesifikasi tidak jelas, planner dapat memecah masalah secara keliru. Worker kemudian menjalankan tugas dengan benar berdasarkan arahan yang salah.

Spesifikasi yang kuat biasanya mencakup:

Tujuan yang dapat diuji
Batas ruang lingkup
Perilaku yang diharapkan
Ketergantungan penting
Kriteria penerimaan
Batasan keamanan atau performa
Contoh kasus tepi
Prioritas kompromi teknis

Pada eksperimen SQLite, manual 835 halaman menjadi bentuk spesifikasi besar. Tantangan utama bukan hanya membaca manual tersebut, tetapi mengubahnya menjadi keputusan teknis yang konsisten di seluruh kode.

Apakah Hasil Ini Berarti AI Sudah Bisa Menggantikan Tim Engineer?

Tidak. Eksperimen Cursor menunjukkan bahwa koordinasi agen dapat menyelesaikan pekerjaan perangkat lunak yang besar pada lingkungan yang dikendalikan. Namun, hasil itu tidak membuktikan bahwa agent swarm dapat menggantikan tanggung jawab rekayasa perangkat lunak dalam semua situasi.

Proyek produksi memiliki faktor yang sering tidak hadir dalam eksperimen dari repositori kosong:

Sistem lama dengan dokumentasi tidak lengkap
Ketergantungan eksternal
Kontrak pelanggan
Batas kepemilikan antarorganisasi
Data sensitif
Persyaratan keamanan
Migrasi bertahap
Risiko kegagalan layanan
Keputusan bisnis yang tidak tertulis dalam spesifikasi

Repositori matang adalah ujian berikutnya

Membangun sistem baru dari spesifikasi memiliki tingkat kesulitan tersendiri. Namun, memodifikasi basis kode lama juga memiliki tantangan berbeda.

Basis kode matang dapat berisi asumsi historis, perubahan kompatibilitas, pengaturan operasional, dependensi usang, dan pengetahuan yang hanya tersimpan di percakapan internal. Dalam situasi ini, agen perlu memahami bukan hanya apa yang harus dibangun, tetapi juga apa yang tidak boleh diubah.

Pengujian yang lebih kuat untuk agent swarm akan mencakup pekerjaan seperti:

Migrasi komponen dalam proyek open source besar
Penambahan fitur lintas modul
Perbaikan keamanan dengan proses disclosure yang ketat
Pengurangan utang teknis tanpa merusak kompatibilitas
Peningkatan cakupan pengujian pada repositori lama
Refactor pada sistem yang memiliki pengguna aktif

Ukuran keberhasilan juga perlu berkembang. Bukan hanya skor benchmark atau jumlah kode yang dihasilkan, melainkan jumlah perubahan yang diterima, bertahan setelah rilis, tidak memicu regresi, dan tidak membebani proses review manusia.

Perbedaan Eksperimen Cursor dengan Proyek Rust SQLite Lainnya

Cursor bukan satu-satunya pihak yang mengeksplorasi implementasi SQLite atau kompatibilitas SQLite dalam Rust. Salah satu contoh yang sering dibahas adalah Limbo dari Turso.

Limbo adalah proyek yang bertujuan membangun ulang SQLite dalam Rust dengan fokus pada arsitektur modern, keamanan memori, I/O asinkron, dukungan WebAssembly, serta kompatibilitas tertentu terhadap SQLite. Informasi tentang arah proyek tersebut tersedia dalam pengumuman resmi Turso mengenai Limbo.

Fokus eksperimen Cursor dan Limbo berbeda

Keduanya sama-sama berkaitan dengan SQLite dan Rust, tetapi pertanyaan yang dijawab tidak identik.

Aspek	Eksperimen Cursor	Limbo dari Turso
Fokus utama	Menguji orkestrasi agent swarm	Membangun ulang SQLite dengan arsitektur modern
Cara pengembangan	Banyak agen AI dengan planner-worker	Proyek rekayasa perangkat lunak terbuka
Bahan awal	Manual SQLite tanpa kode sumber atau internet	Pengembangan proyek dengan tujuan kompatibilitas
Pertanyaan utama	Bisakah swarm menerjemahkan spesifikasi menjadi sistem besar?	Bagaimana membangun database modern berbasis Rust?
Nilai pembelajaran	Koordinasi, biaya model, review, konflik	Desain database, kompatibilitas, I/O, keandalan

Perbandingan ini membantu menghindari kesalahpahaman. Replika hasil eksperimen Cursor tidak otomatis dimaksudkan sebagai pengganti SQLite atau proyek database Rust yang sedang dikembangkan untuk penggunaan produksi.

Eksperimen tersebut lebih tepat dibaca sebagai studi tentang cara agen AI bekerja bersama dalam proyek kompleks.

Dampak bagi Tim Pengembang Perangkat Lunak

Pelajaran dari eksperimen Cursor dapat diterapkan secara lebih luas, bahkan tanpa menjalankan ribuan agen atau membangun sistem kontrol versi baru.

Nilai utamanya adalah memahami bahwa penggunaan AI dalam pengembangan tidak berhenti pada pemilihan model. Hasil kerja dipengaruhi oleh pembagian peran, kualitas konteks, pengujian, review, dan mekanisme koreksi.

Prinsip yang dapat diterapkan pada proyek nyata

Beberapa prinsip berikut dapat menjadi acuan bagi tim teknis yang mulai mengadopsi agen coding.

Pisahkan pekerjaan strategis dan pekerjaan eksekusi

Tugas desain arsitektur, evaluasi risiko, dan penentuan antarmuka sebaiknya diperlakukan berbeda dari tugas implementasi rutin. Model yang kuat dapat dipakai pada keputusan bernilai tinggi, sedangkan tugas yang terdefinisi jelas dapat dikerjakan oleh model lebih hemat.

Buat spesifikasi sebelum memperbanyak agen

Menambah jumlah agen tanpa spesifikasi yang jelas dapat mempercepat konflik. Sebelum pekerjaan dibagi, tim perlu menetapkan tujuan, batasan, kontrak antarkomponen, dan ukuran penerimaan.

Jadikan pengujian sebagai gerbang utama

Agen dapat menghasilkan kode yang tampak meyakinkan tetapi salah secara perilaku. Unit test, integration test, regresi, dan evaluasi berbasis skenario perlu menjadi bagian dari alur kerja, bukan tambahan di akhir.

Simpan keputusan desain secara mudah ditemukan

Keputusan penting sering hilang dalam percakapan atau pull request lama. Dokumentasi ringkas yang selalu diperbarui membantu manusia dan agen memahami alasan di balik struktur kode.

Gunakan review dari lebih dari satu sudut

Review kode dapat memeriksa lebih dari gaya atau kesalahan sintaks. Review juga perlu menilai risiko keamanan, dampak kompatibilitas, kelengkapan pengujian, serta konsistensi terhadap arsitektur.

Ukur hasil akhir, bukan sekadar aktivitas

Jumlah prompt, token, agent run, commit, atau baris kode tidak otomatis menggambarkan nilai. Metrik yang lebih bermakna mencakup:

Waktu hingga perubahan diterima
Jumlah regresi setelah integrasi
Waktu review manusia
Jumlah perubahan yang dibatalkan
Cakupan pengujian
Biaya per fitur yang selesai dan tervalidasi
Stabilitas sistem setelah rilis

Risiko yang Tetap Ada dalam Pengembangan Multiagen

Koordinasi yang lebih baik tidak menghilangkan seluruh risiko. Ketika jumlah agen meningkat, kesalahan juga dapat menyebar lebih cepat jika tidak ada pengendalian yang cukup.

Risiko keamanan

Agen yang dapat mengubah kode sensitif memerlukan pembatasan yang ketat. Kode autentikasi, pembayaran, data pribadi, atau infrastruktur produksi tidak seharusnya diperlakukan sama dengan tugas dokumentasi atau refactor berisiko rendah.

Penerapan kontrol dapat mencakup:

Akses minimum terhadap repositori dan kredensial
Lingkungan eksekusi terisolasi
Pemeriksaan rahasia dan dependensi
Persetujuan manusia untuk perubahan sensitif
Audit log
Pengujian keamanan sebelum penggabungan

Risiko evaluasi yang terlalu sempit

Test suite dapat menjadi target yang kuat, tetapi tetap memiliki batas. Sistem yang dioptimalkan untuk satu ukuran dapat terlihat berhasil tanpa memenuhi kebutuhan operasional yang lebih luas.

Karena itu, evaluasi agent swarm sebaiknya menggabungkan:

Correctness fungsional
Kinerja
Keamanan
Konsumsi sumber daya
Kemudahan pemeliharaan
Kualitas dokumentasi
Ketahanan terhadap perubahan kebutuhan
Beban review manusia

Risiko ketergantungan pada konteks yang salah

Agen bekerja berdasarkan konteks yang diberikan. Jika dokumen internal sudah usang, spesifikasi ambigu, atau keputusan lama tidak lagi relevan, agen dapat mempercepat penerapan asumsi yang salah.

Kualitas basis pengetahuan menjadi bagian penting dari kualitas hasil. Dokumen harus dapat dipercaya, ringkas, diperbarui, dan dibedakan antara aturan aktif dengan catatan historis.

FAQ tentang Cursor Membangun Ulang SQLite dalam Rust

Apakah Cursor benar-benar membuat SQLite baru dari nol?

Cursor melaporkan bahwa agent swarm membangun implementasi database dalam Rust berdasarkan manual SQLite setebal 835 halaman. Kode sumber SQLite, biner SQLite, test suite asli, dan akses internet tidak diberikan kepada agen selama eksperimen.

Namun, hasil tersebut lebih tepat disebut replika atau implementasi eksperimental yang diuji terhadap suite SQL tertentu, bukan pengganti resmi SQLite untuk penggunaan produksi.

Apakah hasil eksperimen Cursor lulus seluruh test SQLite?

Cursor melaporkan kelulusan 100% pada held-out SQL test suite, yaitu suite evaluasi yang tidak diperlihatkan kepada agen. Ini tidak sama dengan klaim bahwa seluruh test internal SQLite atau seluruh perilaku SQLite telah direplikasi secara sempurna.

Apa itu held-out test suite?

Held-out test suite adalah kumpulan pengujian yang disimpan terpisah dari proses pembangunan. Agen tidak melihat isi pengujian tersebut saat menulis kode, sehingga hasilnya dapat digunakan untuk mengukur kemampuan generalisasi dan mengurangi risiko optimasi langsung terhadap soal tes.

Mengapa Cursor menggunakan Rust?

Rust menawarkan keamanan memori pada tingkat bahasa, performa tinggi, dan ekosistem yang berkembang untuk pengembangan sistem. Bahasa ini juga sering dipilih untuk proyek yang ingin mengurangi risiko bug terkait pengelolaan memori.

Informasi dasar mengenai karakteristik Rust tersedia pada situs resmi bahasa pemrograman Rust.

Apa yang dimaksud dengan agent swarm?

Agent swarm adalah kelompok agen AI yang bekerja sama menyelesaikan tujuan besar melalui pembagian tugas, koordinasi, pertukaran konteks, pengujian, dan peninjauan. Dalam eksperimen Cursor, peran utama dibagi menjadi planner yang mengarahkan pekerjaan dan worker yang mengerjakan implementasi.

Mengapa biaya penggunaan model dapat berbeda hingga 15 kali?

Biaya berubah karena model memiliki harga token, kecepatan, dan pola penggunaan konteks yang berbeda. Jika model mahal digunakan untuk seluruh pekerjaan implementasi, biaya dapat meningkat tajam. Pendekatan planner-worker berusaha menempatkan model mahal pada keputusan strategis dan model lebih hemat pada pekerjaan eksekusi yang sudah jelas.

Apakah lebih banyak agen selalu menghasilkan perangkat lunak yang lebih baik?

Tidak. Lebih banyak agen dapat mempercepat pekerjaan, tetapi juga meningkatkan risiko duplikasi, konflik merge, desain yang bertentangan, dan pertumbuhan kode yang tidak terkendali. Kualitas koordinasi menjadi faktor penentu.

Apa pelajaran utama bagi organisasi yang menggunakan agen coding?

Pelajaran utamanya adalah bahwa keberhasilan tidak ditentukan oleh model saja. Organisasi perlu memperhatikan spesifikasi, pembagian peran, konteks, kontrol akses, pengujian, review, pencatatan keputusan, dan metrik kualitas hasil.

Kesimpulan

Eksperimen Cursor membangun ulang SQLite dalam Rust menunjukkan bahwa agen coding sudah mampu menangani pekerjaan rekayasa perangkat lunak yang kompleks ketika diberi spesifikasi jelas, pembagian peran yang tepat, dan evaluasi yang ketat. Kelulusan pada pengujian terpisah menjadi sinyal yang menarik, tetapi hasilnya tetap perlu ditempatkan sebagai implementasi eksperimental, bukan pengganti langsung bagi SQLite yang telah matang dan digunakan luas.

Nilai terbesar dari eksperimen ini bukan sekadar kemampuan menghasilkan kode dalam skala besar. Pelajarannya terletak pada cara mengelola agen: gunakan perencanaan untuk menjaga arah, pekerja khusus untuk mengeksekusi bagian yang terukur, serta pengujian dan review untuk membatasi kesalahan. Untuk memahami standar dan dokumentasi database yang menjadi rujukan, kunjungi situs resmi SQLite.

Ke depan, pertanyaan pentingnya bukan apakah AI dapat menulis lebih banyak kode, melainkan apakah tim mampu merancang proses yang membuat kode tersebut dapat dipercaya. Mulailah dari eksperimen kecil, ukur kualitas hasilnya, dan bangun sistem pengawasan yang kuat sebelum memperluas penggunaan agen coding ke pekerjaan yang lebih kritis.

Referensi

AlphaSignal. (2026). Cursor’s AI Swarm Rebuilt SQLite From Scratch at 15x Lower Cost.

daily.dev. (2026). Cursor’s Agent Swarm Rebuilt SQLite From Documentation Alone.

Fav0. (2026). Cursor Team Rebuilds SQLite From Its 835-Page Manual Using AI Agents.

AICrier. (2026). Cursor Swarm Rebuilds SQLite in Rust.

Remio. (2026). Cursor Agent Swarm Passed 80% of a SQL Test Suite, but the Architecture Matters More.

Cursor. (2026). Agent Swarms and the New Model Economics.

LinkedIn. (2026). Cursor’s Research Team Had an Agent Swarm Rebuild SQLite From Its 835-Page Manual.

LinkedIn. (2026). We Had a Team of Agents Rebuild SQLite From Its 835-Page Manual.

X. (2026). Cursor Rebuilt SQLite in Rust as an Experiment.

Turso. (2026). Introducing Limbo: A Complete Rewrite of SQLite in Rust.

Unrollnow. (2026). We Had a Team of Agents Rebuild SQLite From Its 835-Page Manual.