Apa yang dapat kita pelajari dari eksperimen SQLite Rust Cursor
MMaximilian Schwarzmüller
Computing/SoftwareInternet Technology
Transcript
00:00:00SQLite ditulis ulang dalam Rust.
00:00:02Dan saya tahu baru saja ada penulisan ulang Bun dalam Rust,
00:00:04dan Anda mungkin bertanya-tanya mengapa semua orang menulis ulang
00:00:06segala sesuatunya dalam Rust, tetapi ini bukan tentang Rust.
00:00:09Ini bahkan bukan tentang SQLite.
00:00:11Saya tahu ada basis data Turso,
00:00:15yang sudah merupakan re-implementasi modern
00:00:18dari SQLite di Rust.
00:00:19Itu adalah yang ingin Anda gunakan
00:00:21jika Anda ingin menggunakan basis data
00:00:23SQLite berbasis Rust yang siap untuk produksi.
00:00:26Sebaliknya, eksperimen ini, mini SQLite,
00:00:29yang ditautkan di bawah, yang bisa Anda lihat,
00:00:32bukan tentang SQLite atau Rust.
00:00:34Ini justru eksperimen dari tim Cursor,
00:00:37yang sepenuhnya tentang kawanan agen dan merekayasa
00:00:40sistem agen AI serta mencari tahu apa yang berhasil
00:00:44dan tidak berhasil yang dapat membangun sesuatu
00:00:47seperti SQLite hanya dari dokumentasinya,
00:00:51karena itulah tujuan dari eksperimen tersebut.
00:00:53Ada postingan blog yang sangat mendalam dan menarik,
00:00:56dan kita akan mendalaminya.
00:00:57Ada banyak pelajaran menarik di dalamnya tentang
00:00:59hal yang perlu kita bahas, yang juga ditautkan di bawah,
00:01:02di mana mereka menjelaskan cara menjalankan eksperimen ini dan titik awalnya,
00:01:07dan ide di balik eksperimen itu adalah mengambil dokumentasi SQLite,
00:01:12yang totalnya mencapai 835 halaman jika disatukan ke dalam satu dokumen,
00:01:18yang tentu saja terutama ditulis untuk manusia.
00:01:23Maksud saya, ini bukan dokumentasi paling ramah yang pernah saya lihat,
00:01:27tetapi jelas ditujukan untuk manusia karena jauh lebih tua dari semua teknologi agen AI.
00:01:32Meskipun demikian, dokumen ini juga berfungsi sebagai spesifikasi yang sangat mendalam,
00:01:37spesifikasi yang amat terperinci karena menjelaskan secara rinci cara menggunakan SQLite
00:01:43dan apa perilaku atau fitur yang dimaksudkan.
00:01:48Dan tim Cursor mengambil dokumentasi tersebut
00:01:52dan kemudian mengambil kumpulan pengujian publik, SQLogicTest,
00:01:57yang merupakan serangkaian pengujian untuk menguji perilaku SQLite
00:02:02atau menguji kueri secara khusus.
00:02:05Dan mereka menggunakannya untuk memeriksa apakah implementasi
00:02:09yang dibangun agen mereka berdasarkan dokumentasi itu
00:02:13benar-benar berfungsi dengan suite pengujian resmi atau raksasa tersebut.
00:02:19Nah, ada beberapa catatan penting di awal.
00:02:23Suite pengujian ini fokus menguji kueri dan perilaku kueri.
00:02:29Pengujian ini tidak menguji semua fitur atau kemampuan yang dimiliki SQLite.
00:02:35Pengujian ini tidak menguji performa secara umum.
00:02:38Pengujian ini tidak menguji konkurensi.
00:02:40Ada banyak hal di SQLite yang tidak diuji oleh pengujian ini.
00:02:44Dan hasil mini SQLite dari eksperimen ini, salah satu hasilnya,
00:02:49mereka sebenarnya membangun ulang SQLite berkali-kali dengan kombinasi agen berbeda.
00:02:53Dan kita akan mendalaminya, hasil ini ada murni hanya untuk dieksplorasi.
00:02:57Ini tidak siap untuk produksi.
00:02:59Ini bukan sesuatu yang ingin Anda gunakan.
00:03:01Ini hanyalah hasil eksperimen dengan tujuan memanfaatkan dokumentasi
00:03:06lalu membangun ulang SQLite dan membuat versi buatan ulang itu lolos semua tes tersebut.
00:03:13Dan tim Cursor menggunakan berbagai kombinasi model di sini.
00:03:17Mengapa kombinasi?
00:03:18Karena seperti yang akan kita pelajari, mereka menggunakan pendekatan
00:03:21di mana beberapa agen bekerja sama, yaitu agen perencana, pekerja, dan peninjau.
00:03:28Dan mereka membangun ulang basis data SQLite itu dengan kombinasi berbeda dan juga mengukur kualitas yang serupa.
00:03:37Jadi semua kombinasi ini mencapai kualitas yang sama, jumlah tes yang lolos sama, tetapi mereka mengukur kombinasi mana yang menghabiskan berapa banyak biaya.
00:03:45Contohnya, GPT 5.5 yang digunakan untuk segalanya, baik agen perencana maupun pekerja, membutuhkan biaya implementasi SQLite dalam Rust berdasarkan dokumentasi sebesar sekitar $10.000.
00:03:59Di sisi lain, menggabungkan Opus 4.8 dengan Composer 2.5—dan Composer 2.5 adalah model dari Cursor yang sangat cepat, sangat murah, sangat efisien, tetapi tidak terlalu pintar—menggabungkan keduanya menghasilkan kualitas yang sama, jumlah tes yang lolos sama seperti kombinasi lain hanya dengan sebagian kecil biaya, yaitu $1.300.
00:04:24Dan ide di sini adalah menggunakan Opus 4.8, yang tentu saja merupakan model yang lebih mampu, untuk perencanaan, merancang tugas-tugas, yang kemudian diserahkan kepada agen pekerja yang menggunakan Composer 2.5.
00:04:39Dan itu sudah menjadi satu poin penting yang bisa dipetik dari artikel ini, yang tentu saja bukan hal yang benar-benar baru.
00:04:44Anda juga bisa melakukannya sendiri jika sedang membangun perangkat lunak.
00:04:47Membagi pekerjaan Anda—tentu tergantung pada kompleksitas pekerjaannya—ke dalam tugas-tugas berbeda yang dieksekusi oleh agen-agen berbeda menggunakan sub-agen adalah ide bagus, di mana beberapa agen berfokus pada perencanaan,
00:05:03tergantung merancang tugas yang fokus dari keseluruhan tugas, jadi seperti pekerjaan individu, dan kemudian memiliki sejumlah agen yang mengimplementasikan tugas tersebut.
00:05:14Karena ternyata hanya untuk menghasilkan kode yang bagus, Anda tidak selalu membutuhkan kecerdasan terdepan jika konteksnya bagus.
00:05:24Jadi jika tugasnya terdefinisi dengan jelas, jika semua informasi berguna ada dalam deskripsi tugas itu, dan tentu saja faktor-faktor lain juga bisa berpengaruh.
00:05:33Misalnya, tampilan basis kode di sekitarnya atau tampilan contoh yang Anda berikan kepada agen bisa berpengaruh.
00:05:39Itu semua memengaruhi hasil, tetapi agen pekerja yang hanya menulis kode dapat diperbanyak jumlahnya jika tugasnya terspesifikasi dengan baik dan konteksnya bagus.
00:05:49Dan itulah fokus utama dari eksperimen ini.
00:05:52Bagaimana merancang sistem yang dapat menangani tugas seukuran ini.
00:05:57Karena, tentu saja, seperti yang saya sebutkan, untuk proyek Anda juga layak dipertimbangkan penggunaan agen perencana ditambah agen pekerja.
00:06:07Tentu saja tidak untuk semua tugas.
00:06:10Jika Anda hanya ingin perbaikan bug cepat atau tugas yang sangat sederhana, tidak masalah untuk langsung memberi tahu agen koding Anda, entah itu Codex, Claude Code, atau apa pun.
00:06:19“Hei, saya punya masalah ini.
00:06:20Saya ingin kamu melakukan ini.”
00:06:21Berikan konteks ekstra dan biarkan ia bekerja.
00:06:24Ia mungkin memunculkan sub-agen, tergantung pada kerangka agen kodingnya.
00:06:28Meskipun begitu, Claude Code mungkin melakukan itu.
00:06:31Kerangka lain seperti PI mungkin tidak melakukannya jika Anda tidak memberinya ekstensi yang tepat.
00:06:36Namun bahkan tanpa sub-agen, banyak tugas bisa diselesaikan oleh satu agen saja dan itu sudah cukup.
00:06:43Tetapi untuk proyek yang lebih rumit, tugas yang lebih kompleks, pembagian itu bisa berguna, termasuk menyertakan agen peninjau.
00:06:51Itu adalah sesuatu yang secara pribadi juga suka saya lakukan.
00:06:54Sekali lagi, tergantung pada kompleksitas tugasnya.
00:06:56Namun memiliki pembagian seperti itu bekerja dengan sangat baik.
00:06:59Dan itu tentu saja bukan hal baru yang terobosan.
00:07:02Yang baru adalah untuk sesuatu seperti penulisan ulang SQLite di sini, Anda memiliki beberapa proses sejajar dari agen perencana, pekerja, dan peninjau, banyak pekerja, tetapi juga banyak perencana dan peninjau.
00:07:18Dan mereka terus bentrok setiap saat.
00:07:19Itulah yang akhirnya ditemukan oleh tim Cursor di sini.
00:07:22Di postingan blog ini, yang sangat-sangat menarik,
00:07:26mereka menyebutkan bahwa awal tahun ini, mereka sudah menjalankan eksperimen dengan kerangka agen tempat mereka membangun peramban web dari awal.
00:07:33Dan sekarang mereka menggunakan kerangka yang sama atau sistem agen yang sama untuk melakukan penulisan ulang SQLite tersebut.
00:07:40Namun mereka juga membangun sistem baru murni berdasarkan pelajaran yang mereka dapatkan sebagai sebuah eksperimen.
00:07:47Lalu dalam eksperimen dan postingan blog ini, mereka membandingkan berbagai pendekatan ini dan mendalami semua tantangan yang mereka hadapi saat mencoba menyiapkan dan menjalankan sistem yang membangun ulang SQLite.
00:07:59Dan salah satu tantangan pertama yang mereka hadapi saat bekerja dengan sistem di mana banyak, ratusan, atau ribuan pekerja bekerja secara bersamaan adalah kontrol versi tradisional, Git, tidak sanggup lagi.
00:08:13Seperti yang mereka tulis di postingan sebelumnya tentang kawanan agen, kita tahu bahwa alat seperti Git dan Cargo mengandalkan kunci kasar untuk kontrol konkurensi, yang berarti bagian data yang sama dikunci agar tidak bisa ditulis oleh banyak pihak secara bersamaan.
00:08:30Ini tidak masalah untuk satu pengembang, tetapi tidak bisa diterapkan untuk volume kerja yang dihasilkan oleh ratusan agen bersamaan.
00:08:36Kawanan peramban dari awal tahun ini mencapai puncaknya di sekitar 1.000 commit per jam.
00:08:41Jadi itulah kawanan agen yang membangun ulang peramban itu.
00:08:45Sistem baru, yang mereka rancang untuk eksperimen ini, mencapai puncaknya sekitar 1.000 commit per detik.
00:08:52Jadi kawanan lama, yang mereka jalankan awal tahun ini, melakukan 1.000 commit per jam, yang tentu saja sedikit lebih banyak daripada kebanyakan manusia.
00:09:02Namun, sistem baru ini memiliki sekitar 1.000 commit per detik, yang luar biasa banyaknya dan jelas-jelas bukan peruntukan pembuatan Git.
00:09:14Tentu saja.
00:09:15Untuk memfasilitasi tingkat aktivitas ini, kami membangun sistem kontrol versi baru dari awal.
00:09:21Throughput bukan satu-satunya alasan untuk menguasai lapisan ini.
00:09:25Masing-masing perubahan dalam sistem melewati sistem kontrol versi.
00:09:29Jadi di situlah bentrokan pertama kali terlihat.
00:09:31Dan beberapa mekanisme koordinasi di bagian berikutnya diimplementasikan langsung di dalamnya.
00:09:37Dan itu sungguh menarik.
00:09:39Mereka membangun sistem kontrol versi baru untuk era agen AI.
00:09:43Karena sistem lama, Git, yang biasa kita semua gunakan, tentu saja tidak ada yang salah dengannya.
00:09:48Hanya untuk memperjelas.
00:09:49Kita sedang membicarakan eksperimen dalam skala dan tugas yang mungkin tidak akan pernah ditangani oleh banyak dari kita, setidaknya tidak dalam waktu dekat.
00:09:57Namun tetap saja, sistem lama, Git, tidak dibangun untuk memiliki ratusan agen, ratusan entitas yang bekerja pada kode yang sama secara bersamaan.
00:10:07Jadi mereka membangun sistem kontrol versi baru, yang dapat menangani konkurensi yang sangat tinggi, tetapi juga dapat membantu menyelesaikan konflik melalui agen.
00:10:19Karena jelas di dalam sistem kontrol versilah konflik menjadi terlihat jika dua perubahan memengaruhi bagian kode yang sama dalam sebuah berkas.
00:10:28Jadi itu hal penting pertama di sini.
00:10:30Mereka membangun sistem kontrol versi yang sama sekali baru untuk eksperimen ini agar dapat menjalankan atau melaksanakannya secara efisien.
00:10:37Tentu saja, seperti yang mereka sebutkan di sini, mereka menemui banyak masalah pada skala dan tingkat perubahan sebesar 1.000 commit per detik itu.
00:10:48Misalnya, dan ini sangat menarik, semua masalah yang mereka temui dan cara mereka menyelesaikannya, memberikan kita gambaran tentang bagaimana rekayasa perangkat lunak di masa depan, setidaknya dalam skenario tertentu.
00:11:01Masalah desain otak terpisah (split-brain).
00:11:03Dua perencana, tanpa menyadari keberadaan satu sama lain, mengimplementasikan konsep yang sama dengan cara berbeda di bagian basis kode yang berbeda.
00:11:10Jadi ada duplikasi, konsep yang sama dengan cara berbeda di bagian basis kode yang berbeda.
00:11:16Biasanya Anda ingin mengekstraknya dan menggunakan kembali logika tersebut, bukan?
00:11:21Kami memperbaikinya melalui pembuatan instruksi (prompting).
00:11:24Jadi tidak ada sistem baru yang canggih yang dibangun di sini, melainkan melalui prompting.
00:11:28Perencana membuat keputusan desain itu sendiri, yaitu agen perencana itu sendiri, daripada mendelegasikannya.
00:11:34Dan kami mewajibkan mereka memastikan tidak ada dua sub-pohon tersalurkan yang memutuskan pertanyaan yang sama.
00:11:39Jadi ini masalah pengaturan.
00:11:40Ini semua tentang memastikan bahwa saat Anda membagi sistem itu menjadi perencana, pekerja, dan seterusnya, Anda memastikan bahwa perencana yang berbeda—karena ini bukan hanya pekerja sejajar, tetapi semua perencana sejajar—memiliki tugas terdefinisi jelas yang sangat kecil kemungkinannya untuk bentrok dan tumpang tindih.
00:12:02Jadi itu tentu saja dimulai dari desain oleh manusia.
00:12:08Jadi bagaimana Anda mengatur tugasnya, bagaimana Anda memberikan instruksi, bukan?
00:12:11Kami memperbaikinya melalui prompting.
00:12:13Jadi hal itu tentu akan menerus ke bawah pohon agen dengan semua simpul sejajar dan daun-daun sejajar tersebut, di mana Anda ingin memastikan bahwa saat agen membagi tugas menjadi sub-tugas, agen-agen tersebut diinstruksikan untuk memotong tugas yang memiliki peluang tumpang tindih yang rendah.
00:12:34Jadi itu pada akhirnya merupakan tantangan perencanaan bagi manusia, yaitu tentang mengatur sistem dengan cara yang benar dari sisi manusia.
00:12:43Jadi begitulah cara mereka menyelesaikan atau menangani masalah ini.
00:12:47Masalah lain yang mereka hadapi adalah perselisihan antar perencana.
00:12:51Bentuk perselisihan yang lebih sulit adalah ketika dua perencana saling mengetahui dan bertengkar melalui perubahan bolak-balik pada berkas yang sama.
00:12:59Masalahnya adalah dua gambaran realitas dan alat penggabung tidak dapat menyelesaikan ketidaksepakatan.
00:13:04Sebaliknya, kami membuat agen mencatat keputusan dalam dokumen desain bersama.
00:13:08Kode yang bergantung pada suatu keputusan membawa referensi pemeriksaan terkompilasi kembali ke dokumennya.
00:13:13Ketika para perencana tanpa sadar bertentangan, agen penyelaras mengabungkan dokumen tersebut dan referensi merambatkan resolusinya ke hilir.
00:13:21Jadi pada akhirnya, terkait dengan poin sebelumnya, saat membagi pekerjaan di antara para perencana, tentu saja dalam pengembangan perangkat lunak Anda tidak bisa sepenuhnya menghindari tumpang tindih atau domain bersama, logika bersama, area bersama yang perlu disentuh oleh perencana dan pekerja dalam basis kode.
00:13:43Jadi saat itulah agen perencana mulai merebutkan suatu implementasi, dan mereka memperbaikinya dengan menghadirkan agen penyelaras, saya rasa, yang menggabungkan dokumen yang dibuat oleh para perencana tersebut.
00:13:59Jadi dokumen yang dibuat itu kemudian diserahkan kepada para pekerja.
00:14:02Mempunyai langkah penyelarasan di antaranya yang menggabungkan dokumen-dokumen agen perencana yang berselisih membuat mereka berbicara dalam bahasa yang konsisten dan menyepakati satu implementasi, serta membantu memastikan hal yang sama tidak diimplementasikan ulang dengan cara berbeda di bagian basis kode yang berbeda.
00:14:21Jadi keduanya bekerja sama, sejauh yang saya pahami.
00:14:24Sekarang, tentu saja, mereka juga mengalami konflik penggabungan (merge conflict).
00:14:29Jadi merencanakan dan memastikan tidak ada tumpang tindih di sana atau sekecil mungkin, serta memastikan perencana berbicara dalam bahasa yang sama, adalah langkah penting pertama.
00:14:38Namun tetap saja, beberapa pekerja, bahkan beberapa pekerja yang mengerjakan satu rencana yang sama persis, tentu sangat mungkin menyentuh berkas yang sama dan saling bertentangan.
00:14:50Jadi ada banyak pekerja lain yang tidak bisa begitu saja memastikan mereka tidak mengerjakan berkas yang sama.
00:14:55Itulah mengapa mereka tidak akan mengerjakan berkas yang sama.
00:14:57Itulah mengapa mereka tidak akan mengerjakan berkas yang sama.
00:14:58Untuk menyelesaikan bentrokan, mereka harus berhenti, menyerap konteks agen lain, dan melakukan penggabungan di sekitarnya.
00:15:03Tentu saja, jika dua agen atau dua manusia mengerjakan berkas yang sama, untuk menyelesaikan konflik tersebut, keduanya harus berhenti, tidak peduli agen atau manusia, atau biasanya mereka harus berhenti agar bisa menemukan keputusan,
00:15:19sebuah implementasi yang menyelesaikan konflik tersebut.
00:15:23Namun, agen pekerja buruk dalam hal ini dan dalam praktiknya memilih menimpa perubahan lain atau meninggalkan perubahannya sendiri.
00:15:29Dan mungkin Anda juga memperhatikan hal ini.
00:15:31Saya tentu saja pernah.
00:15:32Jika Anda bekerja dalam basis kode bersama satu atau beberapa agen AI dan Anda membuat perubahan.
00:15:38Oke, saya tahu ini menakutkan, tetapi Anda masih bisa menulis kode.
00:15:40Jadi katakanlah Anda membuat perubahan.
00:15:42Anda mengubah sesuatu di kode.
00:15:44Agen akan selalu membatalkannya dan menimpanya.
00:15:48Ia tidak menghormati perubahan itu.
00:15:50Ia punya agendanya sendiri.
00:15:52Dan jika ia memutuskan harus menyunting berkas tertentu, ia akan melakukannya.
00:15:57Dan ia tidak peduli apakah Anda membuat perubahan padanya sementara itu.
00:16:01Sedikit berbeda jika Anda sudah melakukan commit pada perubahan itu karena agen-agen ini telah dilatih secara khusus untuk tidak mudah membatalkan commit Anda dan sejenisnya.
00:16:13Namun jika itu perubahan yang belum di-commit, agen pekerja tidak peduli.
00:16:17Agen tersebut tidak peduli.
00:16:19Dan itulah persis apa yang mereka temui di sini juga.
00:16:21Untuk membenahi ini, kami membuat sistem tempat agen pihak ketiga yang netral mengintervensi konflik penggabungan dan menyelesaikannya atas nama semua pihak.
00:16:29Satu-satunya tujuannya adalah menjadi tidak memihak dan efisien, serupa dengan cara kerja antrean penggabungan (merge queue) dalam tim rekayasa.
00:16:35Dan saya pikir itu juga menarik.
00:16:38Ini sekali lagi merupakan bentuk penyelarasan.
00:16:41Ini sekali lagi, se pemahaman saya, tentang menghentikan agen-agen tersebut, persis seperti di dunia lama di mana Anda harus berhenti, mengambil langkah mundur, dan menemukan
00:16:49solusi untuk sebuah konflik.
00:16:51Namun yang ditunjukkan dengan jelas oleh hal ini, dan ini juga bukan pelajaran baru, adalah bahwa konteks segar yang diberikan konteks yang tepat sangat-sangat penting.
00:17:03Jadi tidak peduli apakah Anda menangani tugas skala besar seperti Cursor di sini, yang tidak dilakukan oleh kita semua, atau jika Anda hanya bekerja pada proyek skala lebih kecil,
00:17:12keuntungan besar dari memiliki pembagian antara agen perencana, pekerja, dan peninjau terutama, atau sangat sering, adalah Anda bekerja dengan jendela konteks yang segar.
00:17:24Ini tidak berarti bahwa jendela konteksnya kosong.
00:17:26Ini hanya berarti Anda memiliki sesi agen baru yang diisi hanya dengan konteks yang tepat untuk tugas tertentu.
00:17:33Sebagai contoh, seorang pekerja cukup buruk dalam meninjau pekerjaannya sendiri karena memiliki semua konteks dari mengimplementasikan hal tersebut di jendela konteksnya.
00:17:41Jadi ia bias, jika Anda ingin menyebutnya begitu.
00:17:44Itulah mengapa agen peninjau harus mulai dalam jendela konteks yang segar, mendapatkan informasi tentang apa yang dikerjakan pekerja, apa rencananya, berkas mana yang disentuh, tetapi tidak ada yang lain.
00:17:55Sehingga ia dapat meninjau pekerjaan itu secara jujur.
00:17:59Itulah mengapa jendela konteks segar yang diisi dengan konteks yang tepat sangatlah penting.
00:18:04Dan itu hal yang sama persis di sini di mana mereka menyelesaikan konflik penggabungan melalui agen baru dengan konteks yang tepat tanpa memiliki bias yang kemudian dapat menyelesaikan konflik.
00:18:17Dan kemudian saya mengasumsikan sistem diatur sedemikian rupa sehingga agen pekerja tersebut menerima informasi bahwa ini adalah resolusi konflik dan mereka tidak boleh menimpanya, atau agen pekerja baru dimulai.
00:18:30Itu tidak sepenuhnya jelas bagi saya di sini.
00:18:32Masalah lain yang mereka temui adalah berkas mega (mega file).
00:18:35Beberapa berkas adalah tempat yang sangat populer bagi agen untuk bekerja.
00:18:39Setiap agen mungkin hanya menambahkan sedikit kode dan tidak ada agen tunggal yang bertanggung jawab menjaga berkas tetap kecil.
00:18:45Berkas-berkas mega ini menyumbat segalanya.
00:18:49File-file ini mahal untuk ditransfer, dibandingkan, digabungkan, dan menjadi sumber konflik yang terus-menerus.
00:18:54Sekali lagi, itu juga sesuatu yang mungkin pernah Anda temui dalam skala yang jauh lebih kecil.
00:19:00Saya tentu saja pernah.
00:19:01Salah satu hal yang kita miliki.
00:19:02Khususnya untuk pengujian.
00:19:03Pengalaman saya menunjukkan agen suka menambahkan semakin banyak pengujian di file yang sama.
00:19:08Tentu saja bukan cuma pengujian, tapi itu salah satu area yang sering saya lihat.
00:19:13Terutama jika Anda punya beberapa agen yang bekerja dan masing-masing punya agenda sendiri.
00:19:18Mereka tidak peduli karena mereka bukan manusia.
00:19:21Bagaimana mereka bisa peduli tentang sesuatu?
00:19:23Mereka cuma menjalankan tugas, kan?
00:19:24Mereka tidak peduli pada ukuran file atau arsitektur umum sebuah sistem.
00:19:30Jika Anda hanya memiliki sekumpulan agen yang menjalankan tugas, basis kode Anda akan berantakan pada akhirnya.
00:19:37Karena agen tidak peduli.
00:19:39Mereka peduli pada eksekusi tugas mereka.
00:19:42Dan file-file raksasa ini jelas menjadi salah satu indikator nyata dari masalah tersebut.
00:19:48File ini mulai bermunculan seiring makin banyaknya agen yang bekerja dalam jangka panjang di proyek Anda.
00:19:55Tidak ada agen yang bertugas memecah file itu atau menjaga arsitektur basis kode Anda tetap rapi.
00:20:02Itu memang bukan agenda mereka.
00:20:04Jadi, untuk mengatasinya, kami memberi cara bagi agen pekerja untuk menandai file yang terlalu membengkak.
00:20:09Setelah ditandai, kami memblokir commit baru dan agen terpisah mengurai file yang terlalu besar itu menjadi modul-modul lebih kecil.
00:20:16Jadi, sekali lagi, agen baru yang masuk.
00:20:19Ini adalah pola yang kita lihat di sini.
00:20:21Untuk semua masalah ini, kuncinya adalah mengidentifikasi masalah lalu menggunakan agen baru dengan tugas yang tepat,
00:20:28dan konteks yang tepat untuk menyelesaikan masalah itu agar agen lain dapat melanjutkan pekerjaan mereka.
00:20:35Hal yang sama juga berlaku untuk file raksasa ini.
00:20:38Osifikasi, masalah lain yang mereka hadapi.
00:20:40Agen belajar dari bekerja di basis kode yang ada bersama manusia,
00:20:44untuk tidak menyentuh kode inti bahkan saat kode tersebut perlu diubah.
00:20:48Ini bukan hal yang saya maksud sebelumnya.
00:20:50Saat Anda mengubah file tempat agen bekerja dan agen itu langsung membuangnya.
00:20:55Ini tentang hal yang lebih umum.
00:20:57Sebuah agen memiliki tugas jelas berdasarkan rencana dan petunjuk yang Anda berikan.
00:21:03Dan hal itu tentu melibatkan perubahan pada file-file tertentu.
00:21:07Satu hal yang sudah kita ketahui atau lihat setiap hari saat bekerja dengan agen adalah tergantung modelnya,
00:21:16beberapa model sangat ragu untuk merombak kode yang ada.
00:21:21Malah menambahkan 10 penanganan cadangan, 10 pemeriksaan 'if', dan makin banyak kode lama ke basis kode alih-alih menghapus dan merapikannya.
00:21:31Anda harus memberikan petunjuk eksplisit untuk memastikan agen benar-benar menghapus fungsi atau membuang file kode.
00:21:39Inisiatif itu jarang muncul sendiri karena fine-tuning, sebab penyedia model tidak ingin membuat model,
00:21:47yang bekerja sembarangan dan merusak kode produksi.
00:21:50Namun saat tidak bekerja di proyek lama, atau basis kode yang sudah berjalan di lingkungan produksi,
00:21:57kecenderungan untuk tidak merombak kode dan menyimpan semuanya selamanya bisa sangat bermasalah dan mengganggu.
00:22:05Ini juga memicu efek samping lain seperti yang dialami di sini, di mana agen tidak meningkatkan kode buatan agen lain,
00:22:16tetapi terus menumpuk kode di atasnya yang akhirnya membuat basis kode membengkak.
00:22:23Untuk mengatasinya, kami memberi izin perombakan secara sengaja.
00:22:27Agen yang menilai perubahan inti itu penting bisa membuat patch terfokus di luar cakupannya dan meninggalkan komentar yang menjelaskan alasannya.
00:22:36Dan itu, sekali lagi, dalam skala kecil adalah hal yang bisa Anda lakukan dalam proyek Anda seperti yang saya lakukan.
00:22:41Anda perlu memberi izin eksplisit dan memberi tahu agen, “Hei, kita sedang membangun ini.
00:22:46Ini masih tahap awal pengembangan.
00:22:48Ini belum dirilis secara publik.
00:22:49Saya ingin perubahan drastis.
00:22:51Jadi bersihkan kodenya secara agresif.
00:22:54Refactoring sangat diperbolehkan.”
00:22:56Hal-hal seperti itu.
00:22:58Anda ingin mendorong agen dan model AI ini serta mengesampingkan instruksi fine-tuning mereka.
00:23:04Bisa dibilang mengabaikan pembawaan bawaan mereka untuk memastikan mereka dapat mengembangkan basis kode, bukan sekadar menumpuk kode.
00:23:14Jadi ini hal yang bisa dilihat dalam skala kecil, dan tentu saja terjadi dalam skala besar.
00:23:19Lalu untuk peninjauan, mereka menggunakan pendekatan yang disebut 'lensa peninjau'.
00:23:24Kita punya agen perencana dan pekerja, namun hasil kerjanya harus ditinjau untuk membuat tugas lanjutan dan mengulang siklus hingga bug selesai diperbaiki dan basis kode makin baik.
00:23:38Dalam sistem jangka panjang dan melibatkan banyak agen, kesalahan akan menumpuk dan kawanan agen butuh cara mengoreksi diri sebelum kesalahan kecil menjadi besar.
00:23:47Sekali lagi, ini masuk akal.
00:23:48Kita semua juga pernah melihat ini dalam skala kecil.
00:23:50Kami mencoba berbagai lensa peninjau, seperti memberi agen peninjau transkrip penuh pekerja, hanya output-nya, atau hanya basis kodenya saja.
00:24:00Kami juga mencoba peninjau dari model berbeda dengan pelatihan dan kepribadian yang berbeda.
00:24:05Tidak ada satu lensa yang bisa mendeteksi semuanya, tapi kombinasi lensa berlapis ini melampaui keandalan manusia, mirip sistem kemudi otomatis tanpa perlu satu komponen yang sempurna.
00:24:16Daya komputasi untuk peninjauan memberi hasil tinggi karena peninjauan jauh lebih murah daripada proses pengerjaannya.
00:24:21Kami menduga sistem peninjauan berlapis ini menjadi penyumbang utama terjaganya kualitas eksekusi.
00:24:28Jadi poin utamanya di sini.
00:24:30Mustahil meminta satu atau beberapa agen peninjau meninjau seluruh basis kode.
00:24:39Itu terlalu berlebihan.
00:24:41Sebagai gantinya, mereka mencoba berbagai pendekatan seperti memberikan transkrip penuh, hanya output, atau hanya basis kode.
00:24:47Dan hasil akhirnya menunjukkan bahwa hal yang membantu mereka adalah memiliki peninjau berbeda dengan persona dan fokus lensa yang bervariasi pada aspek berbeda.
00:25:00Berikan mereka basis kode, sependengaran saya, dan mungkin beberapa informasi tentang apa yang dilakukan agen pekerja.
00:25:06Kombinasi hasil dari beberapa peninjau ini menghasilkan tinjauan akhir yang kemudian dapat diambil oleh perencana untuk dijadikan rencana baru agar pekerja memperbaiki kodenya.
00:25:23Dalam skala lebih kecil, saya pikir ini adalah sesuatu yang bisa kita terapkan juga.
00:25:28Tentu saja, kita tidak sedang membangun hal sekompleks itu saat ini.
00:25:34Namun berdasarkan pengalaman saya, hal yang bekerja sangat baik adalah memiliki banyak agen peninjau dengan tugas berbeda, di mana satu agen fokus pada: “Apakah ini gaya Rust yang idiomatis?”
00:25:46Agen lain mungkin fokus pada masalah performa dan keamanan jika alurnya memungkinkan.
00:25:51Peninjau lain fokus pada pola penamaan jika itu yang ingin Anda prioritaskan, dan seterusnya.
00:25:58Jadi Anda punya lensa berbeda, lalu berikan peninjau tersebut konteks yang pas.
00:26:03Contohnya seperti: “Hei, kita punya pekerja yang mengerjakan fitur itu.”
00:26:07Beri mereka rencana kerja dan sedikit informasi ringkas tentang langkah pekerja, tanpa hal berlebihan lainnya.
00:26:15Lalu Anda kumpulkan semua output peninjau dan gabungkan, mungkin dengan agen peninjau tambahan.
00:26:22Saya juga suka memakai peninjau untuk meninjau hasil tinjauan, karena tergantung modelnya, AI sering kali terlalu gatal ingin menemukan masalah.
00:26:36Tidak peduli kode apa yang diberikan, bahkan jika cuma satu baris.
00:26:40Terkadang saya merasa mereka tetap akan menemukan lima kesalahan di dalamnya.
00:26:43Jadi meminta peninjau mengategorikan temuan dan membuang yang bukan masalah sungguhan bisa bekerja sangat baik menurut pengalaman saya.
00:26:55Dan kombinasi peninjau berlapis ini membantu menghasilkan hasil bagus yang kemudian siap diambil dan diimplementasikan kembali.
00:27:06Tentu saja semuanya tergantung pada skala tugas dan perangkat lunak yang Anda bangun.
00:27:11Jelas untuk banyak perangkat lunak, ini terlalu rumit, tapi ini memberi gambaran menarik tentang masa depan rekayasa perangkat lunak dan sistemnya, yang menurut saya sangat menarik.
00:27:27Satu hal terakhir yang mereka lakukan adalah membiarkan agen membentuk lingkungannya sendiri.
00:27:32Gagasannya adalah membiarkan agen menulis panduan lapangan—sebuah dokumen atau kumpulan dokumen—tanpa instruksi khusus selain bahwa panduan ini menjadi konteks tugas utama, sehingga agen bisa membangun memori bersama tentang pembelajaran atau masalah utama yang teridentifikasi.
00:28:00Sehingga mereka memiliki sistem memori ekstra bagi para agen untuk mencatat dan mendokumentasikan keputusan.
00:28:10Secara keseluruhan, sama seperti penulisan ulang BUN di Rust, saya merasa eksperimen ini sangat menarik.
00:28:16Ini juga bisa terasa menakutkan.
00:28:17Saya sangat memahami hal itu.
00:28:18Dan kita tidak boleh menyimpulkan bahwa semua perangkat lunak harus dibangun seperti ini mulai sekarang.
00:28:24Di satu sisi, ini bahkan belum menjadi perangkat lunak yang siap untuk lingkungan produksi.
00:28:28Dan membuatnya siap produksi tentu akan memakan waktu yang cukup lama.
00:28:33Hal ini tidak boleh diremehkan.
00:28:35Ini bukan sesuatu yang bisa dibangun dalam beberapa jam lalu siap produksi hanya dengan sedikit waktu tambahan.
00:28:4380% pertama bisa dicapai jauh lebih cepat daripada 20% terakhir.
00:28:48Kita semua tahu itu.
00:28:49Jadi itu satu hal penting yang bisa dipetik.
00:28:51Penting juga untuk menyadari bahwa tugas khusus menulis ulang SQLite ini memang mungkin hanya menerima dokumen dan rangkaian pengujian yang digunakan di sini.
00:29:04Namun di sisi lain, ini adalah spesifikasi yang luar biasa terperinci, sesuatu yang tidak Anda miliki untuk proyek baru.
00:29:13Saat membangun perangkat lunak baru, Anda tidak punya spesifikasi sedetail dokumentasi perangkat lunak yang usianya sudah lebih dari 20 tahun.
00:29:24Dan tentu saja, meski agen hanya diberi dokumentasi, kode sumber SQLite serta implementasi ulang lain seperti di Rust oleh Turso sangat mungkin sudah menjadi bagian dari data pelatihan sebagian besar model ini.
00:29:46Jadi ini bukanlah hal yang benar-benar baru bagi model-model tersebut.
00:29:51Ini berbeda dengan membangun perangkat lunak baru dari nol di mana iterasi menjadi bagian penting dari prosesnya.
00:29:58Anda akan sangat kesulitan, bahkan bisa dibilang mustahil, membangun perangkat lunak baru dari nol tanpa ada perubahan di sepanjang prosesnya.
00:30:11Karena Anda tidak bisa menulis spesifikasi sempurna di awal lalu menganggapnya selesai begitu saja.
00:30:17Anda akan selalu menemukan hal baru atau hal yang ingin diubah saat proses pembuatan, dalam skala apa pun.
00:30:26Oleh karena itu, ini tidak mewakili cara perangkat lunak akan atau seharusnya dibangun secara umum.
00:30:34Meskipun begitu, ini tetaplah eksperimen yang sangat menarik.
00:30:37Ini eksperimen yang sangat menarik dan memiliki pelajaran penting bagi kita semua.
00:30:43Pelajaran penting yang sebenarnya bukan hal baru, seperti membagi pekerjaan dan menggunakan context window segar dengan konteks yang tepat.
00:30:50Wawasan menarik seperti kemungkinan munculnya sistem kontrol versi baru yang akan dibutuhkan di masa depan.
00:30:57Dan tentu saja, sistem orkestrasi multi-agen akan menjadi hal yang lumrah.
00:31:01Semua ini membuktikan pentingnya peran manusia dalam merancang sistem agen ini dan membuat keputusan tentang arsitektur perangkat lunak baru.
00:31:21Menulis file spesifikasi meski tidak sedetail ini, merancang arsitektur, lalu membangun sistem agen untuk mengimplementasi dan meninjaunya adalah hal penting.
00:31:33Inilah arah perkembangan kita, dan meski berbeda dari cara kita membuat perangkat lunak enam tahun lalu, ini hal yang membuat saya bersemangat.
00:31:45Sangat menarik melihat kita beralih ke pola pikir sistemik, baik dalam membangun sistem agen maupun merancang arsitektur perangkat lunak itu sendiri.
00:31:59Lalu kita membuat keduanya bekerja sama.
00:32:01Saya mendapati eksperimen seperti ini sangat, sangat menarik.
00:32:04Pelajaran yang didapat di sini sangatlah menarik.
00:32:07Dan beberapa pelajaran ini, dalam skala yang lebih kecil dan sederhana, juga berguna untuk proyek pengembangan perangkat lunak sehari-hari.
00:32:17Namun seperti biasa, beritahu saya pendapat Anda dan apa yang Anda pikirkan tentang eksperimen seperti ini.