Skala Autonomous Coding yang Berjalan Jangka Panjang

• Cursor bereksperimen apakah agen coding otonom dapat dijalankan secara paralel selama berminggu-minggu untuk menyelesaikan proyek berskala besar
• Pada awalnya digunakan struktur kolaborasi dinamis, tetapi terjadi bottleneck karena konflik lock dan duplikasi pekerjaan
• Setelah itu, peran dipisahkan menjadi Planner dan Worker sehingga paralelisme dan efisiensi meningkat signifikan
• Dengan struktur ini, mereka mengimplementasikan web browser dari nol, dengan ratusan agen menulis lebih dari 1 juta baris kode
• Hasil eksperimen menunjukkan bahwa struktur yang sederhana dan desain prompt yang tepat adalah kunci untuk menskalakan autonomous coding jangka panjang

---

Batasan agen tunggal

• Saat ini, agen coding tunggal efisien untuk tugas sederhana, tetapi lambat pada proyek yang kompleks
  • Menjalankan banyak agen secara paralel adalah arah skala yang alami, tetapi koordinasi tugas sulit
• Pada tahap awal, dicoba metode kolaborasi dinamis tanpa perencanaan sebelumnya
  • Struktur di mana setiap agen melihat status agen lain dan menentukan sendiri tugas berikutnya

Proses belajar kolaborasi

• Diperkenalkan struktur di mana semua agen memiliki hak yang setara dan mengoordinasikan pekerjaan melalui file bersama
  • Setiap agen memeriksa status agen lain, menerima tugas, lalu memperbarui status
  • Untuk mencegah duplikasi, digunakan mekanisme lock
• Masalah yang muncul
  1. Agen menahan lock terlalu lama atau tidak melepaskannya, sehingga kecepatan keseluruhan turun ke level 2–3 dari 20
  2. Agen gagal saat masih memegang lock, atau mengubah file tanpa lock, sehingga memicu ketidakstabilan sistem
• Beralih ke optimistic concurrency control
  • Pembacaan dibiarkan bebas, sedangkan penulisan dibuat gagal saat terjadi perubahan status
  • Sederhana dan stabil, tetapi dalam struktur tanpa hierarki, agen cenderung berperilaku menghindari risiko
  • Mereka menghindari masalah sulit dan hanya mengulang perubahan kecil, sehingga terjadi siklus kerja tanpa kemajuan

Struktur Planner dan Worker

• Beralih ke pipeline hierarkis dengan peran yang dipisahkan
  • Planner: menjelajahi codebase sambil membuat tugas, dan bila perlu membuat planner turunan
  • Worker: hanya mengerjakan tugas yang diberikan lalu melakukan push atas perubahan setelah selesai
• Pada setiap siklus, agen judge memutuskan apakah lanjut ke tahap berikutnya
  • Dengan struktur ini, sebagian besar masalah kolaborasi teratasi, sehingga skalabilitas proyek besar dapat dicapai

Eksperimen jangka panjang

• Tujuan eksperimen: mengimplementasikan web browser dari nol
  • Berjalan sekitar 1 minggu, menulis lebih dari 1 juta baris kode di 1.000 file
  • Ratusan worker melakukan push ke branch yang sama secara bersamaan, tetapi konflik tetap minimal
  • Kode hasilnya dipublikasikan di GitHub
• Eksperimen tambahan
  • Migrasi Solid → React: selama 3 minggu, perubahan +266K/-193K, dan kelayakan merge telah dikonfirmasi
  • Peningkatan rendering video: versi Rust menghasilkan peningkatan kecepatan 25x, dengan fitur zoom, pan, dan motion blur ditambahkan
  • Kode tersebut dijadwalkan segera masuk ke production

Hasil pembelajaran utama

• Setelah menginvestasikan puluhan miliar token, hasilnya belum sepenuhnya efisien, tetapi kinerjanya lebih tinggi dari perkiraan
• Pemilihan model adalah inti dari pekerjaan otonom jangka panjang
  • GPT-5.2 unggul dalam menjaga fokus, mengikuti instruksi, dan implementasi yang akurat
  • Opus 4.5 cenderung berhenti lebih cepat
  • GPT-5.2 lebih cocok untuk peran planner dibanding GPT-5.1-codex
  • Model optimal dipilih dan digunakan sesuai peran
• Menghilangkan kompleksitas turut meningkatkan performa
  • Peran quality integrator justru menciptakan bottleneck
  • Worker dapat menyelesaikan konflik sendiri
• Struktur sederhana adalah yang paling efektif
  • Teori sistem terdistribusi atau model desain organisasi hanya sebagian yang relevan
  • Jika strukturnya terlalu sedikit, konflik dan duplikasi muncul; jika terlalu banyak, kerentanannya meningkat
• Desain prompt sangat menentukan perilaku sistem
  • Berperan penting dalam menjaga fokus jangka panjang, mencegah perilaku patologis, dan mendorong kolaborasi

Tantangan ke depan

• Koordinasi multi-agen masih merupakan masalah yang sulit
  • Perlu ditingkatkan agar planner otomatis merencanakan langkah berikutnya saat tugas selesai
  • Sebagian agen berjalan terlalu lama sehingga memerlukan restart berkala
• Namun, untuk pertanyaan inti, yaitu “apakah autonomous coding bisa diskalakan dengan menambah agen?”
  • Telah dikonfirmasi bahwa ratusan agen dapat berkolaborasi selama berminggu-minggu dan menghasilkan kemajuan nyata
• Teknologi ini rencananya akan diterapkan pada fitur agen Cursor di masa mendatang

[GN⁺]

Komentar Hacker News

• Menarik untuk dibaca karena ini berkaitan dengan tulisan Steve Yegge Welcome to Gas Town yang sedang saya ikuti

• Dalam tulisan prediksi LLM yang baru-baru ini saya bagikan, saya mengatakan bahwa sekitar 2029 membuat browser dengan coding berbantuan AI tidak akan lagi terasa mengejutkan, dan proyek terbaru Cursor ini adalah percobaan kedua
  Contoh lain bisa dilihat di posting Reddit ini

  • Kalau implementasinya cerdas, mungkin caranya cukup mengambil source Chromium dari GitHub, membuang fitur yang tidak perlu, lalu hanya mengubah tampilannya
  • Sekitar 2029, standarnya harus dinaikkan sampai muncul lelucon bahwa AI membuat browser untuk pelikan pun bukan hal istimewa lagi
  • Saya melihat kode contoh di Reddit sekitar 5 menit, dan perhitungan layout teks serta penanganan bidi (teks dua arah) berantakan. “Browser” yang tidak mempertimbangkan standar sulit disebut browser sungguhan
  • Ini memang mengesankan, tetapi saya jadi bertanya-tanya apakah kode browser open source sudah masuk ke data pelatihan model
  • Katanya prediksinya meleset, tapi saya penasaran kenapa seminggu kemudian dia muncul lagi di podcast yang sama untuk membuat prediksi baru

• Saya menjalankan sendiri test di repositorinya, dan hasilnya penuh error dan warning, bahkan CI juga sudah lama gagal. Dalam kondisi seperti ini, saya tidak yakin pantas disebut “contoh sukses”. Dibanding coding yang sepenuhnya otonom, pendekatan bantuan berpusat pada manusia terasa lebih realistis

  • Codebase-nya terpecah menjadi ratusan sampai ribuan file kecil, sehingga hampir mustahil memahami strukturnya. README juga asal-asalan dan tidak ada penjelasan dependensi. Mungkin ini kode buatan AI, tapi untuk maintenance rasanya seperti mimpi buruk
  • Penulisnya juga tampaknya melihat coding yang sepenuhnya otonom lebih sebagai eksperimen batas kemampuan LLM daripada upaya productization yang serius. Saat ini masih pada tahap hanya bisa menghasilkan “kode yang lumayan sendirian” untuk proyek kecil
  • Kalau PR dengan CI gagal tetap di-merge, pantas saja muncul lelucon bahwa ini berarti sudah mencapai kualitas setara manusia
  • Istilah “lambat” juga tidak jelas maksudnya apa. Kecepatan GPU? Lebih lambat dari manusia? Pada akhirnya terasa seperti tulisan yang membesarkan bubble AI

• Saya penasaran kenapa PR itu masih belum di-merge. Masa depan di mana sekumpulan agen AI menyelesaikan software kompleks dalam jangka panjang memang keren, tetapi contoh saat ini terlalu lemah. Titik kolaborasi dengan manusia justru lebih penting

  • Dari pengalaman saya, agen-agen itu tidak konvergen dan malah menghasilkan monster kode yang makin lama makin kacau
  • Tidak merilis bahkan satu proyek sederhana yang benar-benar berjalan membuatnya terlihat seperti umpan untuk menarik investor. Boom AI memang mirip bubble dot-com, tapi kali ini rasanya lebih fokus pada cari uang
  • Contoh seperti browser, Excel, atau Windows 7 mungkin sebagian ada dalam data pelatihan, tetapi itu saja tidak cukup untuk membuat replika penuh
  • Kodenya terlalu besar dan terlalu bermasalah sehingga tidak mungkin direview. Pada akhirnya satu-satunya jalan hanyalah merge gaya YOLO
  • Saya tertarik pada syarat konvergensi. Entah kodenya bertambah atau berkurang, yang penting ia stabil pada kondisi optimal

• Agak disayangkan eksperimennya tidak menaikkan tingkat kesulitan secara bertahap. Kalau diperluas pelan-pelan dengan urutan React CRUD → clone Paint → file manager → browser, tahap perkembangannya akan terlihat jauh lebih jelas

• Saya juga membuat tjs dengan pendekatan serupa. Ini adalah JSON Schema Validator tercepat dan paling akurat di dunia, dan pola planner/delegate berbasis git subtree terbukti efektif. Untuk software yang standar dan test-nya terdefinisi dengan baik, agen AI bisa dengan cepat menulis ulang dan mengoptimalkannya
  Perintah terkait bisa dilihat di spawn-perf-agents.md

• Membuat browser dari nol memang sangat sulit, tetapi isi tulisan itu kurang analisis mendetail. Kalau hanya sampai level “bisa dikompilasi”, nilainya jadi kecil. Verifikasi yang sesungguhnya adalah apakah perubahan berikutnya bisa digabungkan dengan stabil

  • Standar minimum untuk agent coding adalah urutan “berhasil compile” → “berjalan normal” → “menangani edge case”. Baru bisa dipercaya kalau sistemnya berjalan stabil lebih dari 1 tahun dengan bug lebih sedikit daripada manusia
  • Dalam praktiknya, CI saja masih gagal, jadi klaim “bisa dikompilasi” pun terasa meragukan

• Menurut blog tersebut, mereka memakai triliunan token, dan kalau dihitung dengan tarif API OpenAI nilainya mencapai puluhan juta dolar. Dengan skala seperti itu, mungkin lebih baik menyumbang ke tim browser saja

• Saya mencoba build sendiri, dan muncul lebih dari 100 compile error. Sebagian besar commit juga berada dalam kondisi CI gagal, dan kenyataannya ini adalah gabungan dari beberapa library open source.
  quickjs, wgpu, winit, egui, html parser, dan komponen yang sudah ada lainnya dipakai begitu saja, tetapi CEO mengklaim ini sebagai “custom JS VM”, sehingga menimbulkan kesalahpahaman
  Meski begitu, tetap mengesankan bahwa AI bisa mengintegrasikan hal-hal seperti ini secara otonom

  • Komponen yang dipakai sangat mirip dengan browser Rust blitz, jadi ada kemungkinan sudah termasuk dalam data pelatihan
  • Muncul juga candaan ala startup seperti, “apakah ini benar-benar berjalan tidak penting, ambil screenshot lalu tunjukkan ke investor”
  • Ada statistik bahwa dari sekitar 60 ribu workflow, hanya sekitar 1 ribu yang berhasil. Praktis ini terlihat seperti gumpalan kode yang belum tervalidasi
  • Ditutup dengan humor, “mari kita semua membuat Cursor kustom versi masing-masing”

• Kodenya terlihat sangat rapuh dan tidak stabil. Misalnya, fungsi render_placeholder tampak seperti kode sementara yang hanya mengisi frame buffer.
  Saya penasaran fungsi sebenarnya dari kode seperti itu, dan berapa biaya token/waktu untuk tiap test

  • Cara mengekstrak atribut tag juga terasa agak aneh, seperti pada bagian ini
  • Tetapi kalau Cursor bisa otomatis memperbaikinya, kelemahan seperti ini dalam jangka panjang justru bisa menjadi strategi untuk meningkatkan ketergantungan