00:00:00Anthropic baru saja melakukan sesuatu yang luar biasa, mereka mengerahkan 16 agen Claude untuk membangun
00:00:05sebuah compiler C dan setelah berjalan 24/7 selama dua minggu, mereka berhasil membuat satu yang bisa mengompilasi
00:00:11kernel Linux dan bahkan menjalankan Doom, yang sangat mengesankan dan pastinya tidak mungkin dilakukan
00:00:16dengan versi lama Opus 4. Namun orang-orang menyebut pencapaian ini sebagai clickbait dan
00:00:22setengah jujur karena teknik meragukan yang digunakan Anthropic untuk mendapatkan hasil ini.
00:00:28Jadi, apakah Anthropic curang? Klik subscribe dan mari kita cari tahu.
00:00:31Kita akan membagi video ini menjadi tiga bagian. Pertama, kita akan melihat bagaimana eksperimen ini disiapkan,
00:00:37lalu kita akan membahas temuan-temuan utamanya, yang menurut saya bisa dipelajari oleh setiap pengembang,
00:00:42dan terakhir, kita akan meninjau apakah hasilnya valid, karena saya punya beberapa pendapat
00:00:47tentang bagaimana Anthropic mampu membangun compiler ini. Oke, eksperimen ini dilakukan oleh Nicholas
00:00:52Carlini, yang menurut saya adalah manusia yang sangat cerdas. Maksud saya, mari kita lihat bagaimana dia
00:00:58menyiapkan ini. Jadi proyek aslinya berada dalam direktori bernama Upstream, yang dipasang
00:01:03ke 16 container Docker yang berbeda. Saya tahu hanya ada empat di sini, tapi mari kita bayangkan ada 16.
00:01:08Dan masing-masing container Docker ini berisi versi Claude Code yang menjalankan Opus 4.6 dan
00:01:15akan mengkloning repo Upstream ke Workspace, melakukan semua perubahan di Workspace, lalu
00:01:21melakukan push ke Upstream. Ini sangat cerdas karena setiap agen bisa bekerja secara terisolasi tanpa
00:01:27memengaruhi pekerjaan agen lainnya. Nah, jika ada konflik penggabungan, maka Claude
00:01:32akan cukup pintar untuk menyelesaikannya lalu mem-push kembali ke Upstream. Setiap agen akan memilih dari
00:01:38beberapa tugas. Saya tidak yakin apakah tugas-tugas ini dibuat oleh manusia atau oleh agen itu sendiri
00:01:44berdasarkan hasil pengujian, tetapi ada beberapa tugas dengan nama tertentu dan setiap agen akan
00:01:50mengambil tugas baru dan setiap kali mengambil tugas baru, agen tersebut akan membuat sesi baru. Jadi untuk menjaga
00:01:56agen-agen ini berjalan lama, loop Ralph digunakan sehingga para agen akan mengerjakan tugas,
00:02:02menyelesaikannya, push ke Upstream, lalu memilih tugas baru dengan sesi baru dan terus melakukannya berulang
00:02:08kali. Nah, jika Anda sudah menonton video kami tentang Ralph, Anda pasti tahu bahwa kunci agen yang berjalan
00:02:13lama adalah memiliki tugas yang terdefinisi dengan jelas. Namun jika Anda punya 16 agen yang berjalan bersamaan,
00:02:19bagaimana mencegah mereka mengambil tugas yang sama persis? Penguncian tugas. Cara kerjanya adalah
00:02:24di suatu tempat yang tidak disebutkan penulis, ada daftar tugas dan sebuah agen akan memilih tugas lalu memberinya
00:02:30file teks yang sesuai dengan nama tugas tersebut, akan membuat commit untuk mengunci tugas itu agar hanya mereka yang bisa
00:02:36mengerjakannya dan mem-push-nya ke direktori Upstream. Jika agen lain memilih tugas yang sama
00:02:42dan membuat file teks yang sama, saat mereka mencoba mem-push ke repo Upstream, Git akan menolaknya dengan pesan
00:02:48bahwa file tersebut sudah ada dan kemudian mereka harus mengerjakan tugas lain. Dan inilah dasar
00:02:53bagaimana Carlini menguji ketahanan agen yang berjalan lama yang ditenagai oleh Opus 4.6 dan hasilnya
00:03:00sungguh luar biasa. Namun dari eksperimen ini, dia menemukan beberapa hal menarik yang menurut saya
00:03:07bisa dipelajari oleh setiap pengembang. Hal pertama adalah membangun test harness atau skrip yang
00:03:12menjalankan berbagai jenis pengujian karena saat Nick menjalankan eksperimen tersebut, ya, kami sudah akrab sekarang,
00:03:17dia mendapati Claude merusak fitur yang sudah ada setiap kali fitur baru dikerjakan.
00:03:23Jadi dia membangun testing harness yang terdiri dari tes berkualitas tinggi dari repo open source populer seperti
00:03:29SQLite, libjpg, dan Redis. Dan untuk mencegah polusi konteks, dia memastikan testing harness hanya
00:03:35mengeluarkan log yang berguna bagi agen. Jadi pada dasarnya log kesalahan dan membuat file berisi semua
00:03:41jenis log lainnya agar Claude bisa memeriksanya kapan pun dibutuhkan. Namun, dengan ribuan
00:03:47tes, agen butuh waktu berjam-jam untuk menjalankan seluruh rangkaian tes padahal mereka bisa menggunakan
00:03:52waktu itu untuk hal lain. Di sinilah Nick melakukan sesuatu yang sangat cerdik. Dia menambahkan bendera “fast”
00:03:58ke testing harness-nya, artinya agen hanya akan menjalankan 1% atau 10% dari total tes berdasarkan
00:04:05angka yang diinginkan Nick. Jika setiap agen menjalankan 10%, maka itu menjadi 160% dari total tes,
00:04:13yang sebenarnya lebih dari cukup, tapi ini bukan hal yang buruk. Dan cara kerjanya adalah tes tersebut,
00:04:19jadi tes spesifik yang dijalankan oleh setiap agen diacak, tetapi angka seed-nya sama,
00:04:25membuatnya deterministik. Jadi setiap agen akan mendapatkan tes acak yang sama persis dan akhirnya menyelesaikan
00:04:31seluruh rangkaian tes jauh lebih cepat daripada jika mereka menjalankannya sendirian. Poin berikutnya
00:04:36juga cerdik, tapi agak kontroversial karena menggunakan teknologi yang sudah ada.
00:04:41Sejauh ini, setiap agen telah menjalankan unit test dari sekumpulan proyek open source yang sudah ada,
00:04:46yang berjalan dengan baik, membaginya menjadi potongan 1% atau 10%. Namun saat harus mengompilasi
00:04:53kernel Linux, karena file sumber ini bukan unit test individual, segalanya menjadi sedikit
00:04:58sulit karena setiap agen akan mencoba mengompilasi semuanya, menemukan kesalahan yang sama,
00:05:04dan mencoba memperbaikinya serta saling menimpa perbaikan satu sama lain. Jadi cara Nick mengatasinya adalah,
00:05:09sekali lagi, membiarkan setiap agen menjalankan persentase kompilasi dan kemudian membiarkan GCC, yakni
00:05:15GNU compiler, menjalankan sisanya. Nick menyebut GCC sebagai “oracle” karena kernel Linux seharusnya terkompilasi
00:05:22dengan sempurna menggunakannya. Jadi jika agen mengompilasi bagian dari kernel Linux dengan compilernya sendiri,
00:05:27yaitu bagian yang berbeda untuk setiap agen dan sisanya dengan GCC, jika ada yang rusak, itu pasti karena
00:05:34compiler milik agen dan bukan GCC, sehingga agen tersebut hanya akan memperbaiki hal itu alih-alih memperbaiki
00:05:40bug dari agen lain. Nah, ini kontroversial karena menggunakan compiler yang sudah ada untuk melakukan
00:05:46sesuatu yang diminta agar dikerjakan Claude dari nol. Tapi kita akan bahas ini lebih lanjut di akhir
00:05:51video. Mari beralih ke poin berikutnya, yaitu memberi memori pada agen Anda. Karena tugas baru
00:05:57dikerjakan oleh sesi Claude baru yang hampir tidak punya memori tentang apa yang dilakukan sebelumnya,
00:06:03Nick merasa berguna untuk memperbarui file readme dan memiliki file kemajuan yang berbeda dengan instruksi
00:06:09mengenai posisi terakhir dan kemajuan proyek sehingga sesi baru memiliki basis yang baik untuk memulai
00:06:13dan tidak memasukkan bug yang sudah diperbaiki sebelumnya. Dan poin terakhir yang lebih jelas adalah
00:06:18memberi peran berbeda pada agen Anda. Keindahan dari memiliki banyak agen yang bekerja pada basis kode
00:06:23secara paralel adalah banyak hal dapat dilakukan pada bagian kode yang sama persis secara bersamaan.
00:06:29Jadi ketika tidak ada kode baru yang ditulis, Nick memberikan peran unik kepada agen seperti
00:06:35satu untuk memeriksa kode duplikat, satu lagi untuk mencari cara membuat kode seefisien mungkin,
00:06:40dan dia bahkan meminta satu agen untuk mengkritik desain dari perspektif pengembang Rust yang saya harap tidak
00:06:45mengumumkan ke agen lain bahwa dia adalah pengembang Rust. Namun meskipun proyek ini sukses,
00:06:51pertanyaan sebenarnya adalah, apakah Anthropic curang untuk mendapatkan hasil ini? Ya, semacam itu.
00:06:57Tugasnya adalah membangun compiler C dari nol dan agen tersebut tidak memiliki akses ke internet, jadi ia
00:07:03membuat semua kodenya sendiri. Ataukah tidak? Karena ia memiliki akses ke test suite dari proyek
00:07:10open source dan ia memiliki akses ke versi GCC yang sudah dikompilasi. Jadi secara teknis ia bisa saja
00:07:16mengulik compiler GCC, memberinya input dan memeriksa output-nya lalu menggunakan itu untuk mengarahkan
00:07:24desain compilernya sendiri yang ditulis dalam Rust. Tapi sejujurnya, jika saya sedang membangun compiler C
00:07:31dari nol, saya akan melakukan hal yang sama. Saya akan melihat compiler yang sudah ada, melihat bagaimana mereka diimplementasikan
00:07:36dan menggunakan itu untuk membentuk arah compiler saya sendiri. Nah, jika saya membangun compiler untuk
00:07:41bahasa yang benar-benar baru, maka tentu saja hal itu akan jauh lebih sulit dan mungkin ini akan menjadi ujian yang sangat
00:07:47bagus untuk Claude guna melihat apakah ia benar-benar mahir membuat compiler dari nol. Mungkin
00:07:53itu ide lain untuk dicoba Nick, tapi mari kita lanjut membahas sifat otonom dari
00:07:57eksperimen ini karena hal itu juga diuji. Dan jujur saja, ya, Claude memang menulis semua kodenya, tetapi
00:08:04ia mendapat arahan yang kuat dari manusia. Seorang manusia memutuskan test suite mana yang akan dijalankan.
00:08:11Manusia yang memulai loop dan memutuskan untuk menggunakan Ralph. Manusia jugalah yang membangun test harness
00:08:16dan memberikan peran spesifik pada agen. Jadi meskipun ini jauh dari sekadar menyuruh Claude membangun compiler
00:08:22dan membiarkannya berjalan selamanya, saya tidak akan mengatakan kode tersebut ditulis oleh agen yang seratus persen
00:08:28otonom karena seberapa bagus compilernya jika tidak ada campur tangan manusia sejak awal?
00:08:33Dan bahkan dengan semua sistem yang dirancang oleh manusia, compiler C buatan Claude ini memiliki beberapa
00:08:39keterbatasan utama. Misalnya, ia menggunakan assembler dan linker dari GCC karena yang ia buat sendiri
00:08:46terlalu banyak bug. Ia juga butuh compiler x86 16-bit milik GCC untuk bisa menjalankan Linux.
00:08:54Dan lebih dari itu, kodenya tidak sangat efisien. Versi paling optimal dari compiler buatan Claude
00:09:00kurang performan dibandingkan versi paling tidak optimal dari compiler GCC. Jadi sepertinya para pengembang
00:09:05tidak akan tergantikan dalam waktu dekat, setidaknya untuk saat ini.