Apabila Meta melancarkan Muse Code minggu ini, tumpuan utama adalah penentuan kedudukan kompetitif: satu lagi ejen pengekodan berasaskan terminal yang menyertai Claude Code, Codex, dan Cursor dalam persaingan aliran kerja pembangun. Namun, tersembunyi dalam penerangan Mark Zuckerberg sendiri tentang alat ini terdapat isyarat yang lebih menarik untuk sesiapa sahaja yang menulis atau menyemak kod untuk mencari nafkah.

"Apabila sesuatu tugas cukup besar, ia akan disebarkan kepada sub-ejen berasingan yang bekerja secara selari dalam worktree yang terasing," tulis Zuckerberg, menerangkan pendekatan Muse Code terhadap tugas-tugas besar. "Salinan kerja anda tidak akan disentuh sama sekali. Dalam ujian, kami menggunakannya untuk membina enam ciri untuk sebuah permainan secara serentak tanpa sebarang perlanggaran."

Itu bukan penerangan ciri. Itu penerangan tugas — untuk anda.

Apa maksud sebenar "worktree terasing"

Git worktree membolehkan anda mengeluarkan (check out) pelbagai cabang daripada repositori yang sama ke dalam direktori berasingan pada masa yang sama, supaya beberapa aliran kerja dapat diteruskan tanpa satu checkout mengganggu yang lain. Muse Code, menurut penjelasan Meta, menggunakan mekanisme ini untuk membolehkan beberapa sub-ejen menulis kod pada masa yang sama tanpa menyentuh salinan kerja langsung anda atau fail masing-masing. Ini adalah pilihan kejuruteraan yang munasabah: perlanggaran pada peringkat fail adalah jenis konflik multi-ejen yang paling mudah dicegah secara mekanikal, jadi anda mencegahnya secara mekanikal dan membebaskan model untuk fokus kepada pengekodan sebenar.

Perkataan yang perlu diberi perhatian ialah "disebarkan" (fans out). Seorang pembangun manusia tidak mengalami enam worktree selari sebagai enam aliran kod untuk disemak secara manual satu demi satu mengikut urutan — sebaliknya, enam aliran itu tiba di mejanya hampir serentak, setiap satu memerlukan satu keputusan: adakah ini patut dimasukkan, adakah ia perlu dikerjakan semula, adakah ia bercanggah dengan sesuatu yang baru sahaja dilakukan oleh ejen lain dalam worktree yang berbeza.

Kemahiran yang sebenarnya sedang berubah

Sejak beberapa tahun kebelakangan ini, model dominan bagi pengekodan berbantukan AI adalah bersifat perbualan dan tunggal: seorang pembangun, seorang pembantu, satu urutan dialog dua hala, disemak secara hampir masa nyata semasa ia dihasilkan. Kemahiran itu — memberikan gesaan (prompt) dengan baik, mengesan cadangan yang tidak tepat pada saat ia berlaku, dan menambah baik secara berulang — masih diperlukan. Tetapi itu bukan kemahiran yang menjadi tumpuan reka bentuk Muse Code. Penyebaran kepada sub-ejen mengandaikan anda telah beralih kepada mod kerja yang berbeza: memecahkan tugas terlebih dahulu kepada bahagian-bahagian yang boleh berjalan secara bebas, kemudian menyemak hasil siap (atau separuh siap) daripada beberapa ejen pada satu masa, bukannya mengarahkan satu ejen langkah demi langkah.

Ini lebih menyerupai seorang ketua teknikal yang membahagikan satu sprint kepada pasukan kecil, berbanding seorang pengaturcara berpasangan yang berkongsi skrin dengan chatbot. Keputusan pengekodan individu tidak sepenting proses pemecahan tugas (adakah anda membahagikan kerja mengikut garis yang benar-benar bebas antara satu sama lain?) dan pas semakan (bolehkah anda mengesan dengan cepat sama ada enam diff selari itu masing-masing betul dan koheren secara kolektif?).

Pengasingan menyelesaikan perlanggaran, bukan keselarasan

Ini patut difikirkan lebih mendalam kerana ia mudah tertinggal daripada perhatian: worktree terasing menghalang dua ejen daripada menulis ganti fail yang sama. Tetapi ia langsung tidak menghalang dua ejen daripada secara berasingan mencipta dua cara berbeza untuk melakukan perkara yang sama — pembantu pemformatan tarikh yang kedua, pembalut cuba-semula (retry wrapper) yang kedua, laluan API yang bertindih — kerana kedua-dua ejen tidak dapat melihat apa yang sedang dibina oleh ejen yang satu lagi. Pengasingan Git adalah jaminan pada peringkat sistem fail, bukan jaminan reka bentuk. Penyemak yang menggabungkan semula enam worktree itu adalah satu-satunya titik semakan di mana abstraksi yang bertindih, konvensyen penamaan yang tidak konsisten, atau dua ciri yang secara senyap mengandaikan bentuk data yang berbeza dapat dikesan. Jika penyemak itu hanya meninjau sepintas lalu diff kerana jumlah hasil selari itu melebihi kemampuan bacaan yang teliti, inilah jenis penyelewengan yang akhirnya turut dilancarkan.

Ini menyusun semula apa yang perlu difahami sebagai "semakan kod" apabila alat penyebaran (fan-out) menjadi perkara biasa: lebih kurang pemeriksaan baris demi baris bagi setiap diff (sintaks ejen biasanya sudah betul), dan lebih banyak penyelarasan silang-diff — memastikan aliran kerja selari yang dijana oleh AI bersetuju antara satu sama lain mengenai konvensyen yang dikongsi, model data yang dikongsi, dan pengendalian ralat yang dikongsi.

Apa yang perlu benar-benar diusahakan

Tiada satu pun daripada ini memerlukan Muse Code secara khusus — corak penyebaran yang sama muncul merentasi ejen pengekodan utama yang lain, yang menunjukkan ia sedang menjadi seni bina lalai dan bukan sekadar taruhan satu vendor. Beberapa perkara konkrit yang patut dilatih sekarang, tanpa mengira alat mana yang anda gunakan:

  • Tulis spesifikasi tugas yang boleh dipecahkan dengan bersih. Sebelum meminta kerja dijalankan secara selari, tanya diri anda sama ada bahagian-bahagian itu benar-benar bebas antara satu sama lain — adakah ia menyentuh fail yang sama, pemalar yang dikongsi sama, atau kontrak API yang sama? Jika ya, itu bukan tugas untuk enam ejen selari; itu tugas untuk satu ejen bekerja secara berurutan, atau untuk anda memecahkan bahagian yang dikongsi itu secara manual terlebih dahulu.
  • Latih diri untuk menyemak di titik penggabungan (merge), bukan di titik diff. Biasakan diri menarik beberapa cabang yang telah siap secara bersebelahan dan bertanya "adakah semua ini selari antara satu sama lain," bukan sekadar "adakah setiap satu daripadanya betul secara berasingan."
  • Ketahui asas-asas git worktree. Jika alat yang anda gunakan menerangkan mekanisme dalamannya dengan cara ini, memahami apa yang worktree jamin dan tidak jamin adalah syarat minimum untuk mempercayai — atau dengan betul, tidak mempercayai — hasil yang diberikan.
  • Jelaskan secara eksplisit pemilikan bagi perkara-perkara yang dikongsi. Pemalar, skema, utiliti yang dikongsi, konvensyen penamaan. Semakin banyak perkara ini anda tetapkan sebelum proses penyebaran bermula, semakin sedikit kerja penyelarasan yang perlu anda lakukan selepasnya.

Orang yang mendapat manfaat paling besar daripada alat seperti Muse Code bukanlah mereka yang paling mahir memberikan gesaan (prompt). Sebaliknya, mereka adalah orang yang secara senyap-senyap telah menjadi mahir dalam menguruskan sebuah pasukan yang kecil, pantas, dan kadangkala kurang kemas — walaupun setiap ahli pasukan itu adalah sebuah model.