Minggu ini Meta melancarkan Muse Code, ejen pengekodan berasaskan terminal yang dibina menggunakan model Muse Spark 1.2 miliknya, sekali gus meletakkannya dalam persaingan langsung dengan Claude Code keluaran Anthropic dan Codex keluaran OpenAI. Ciri utama yang ditonjolkan bukanlah kualiti model — tetapi seni binanya. Seperti yang diterangkan oleh Mark Zuckerberg, “apabila sesuatu tugasan cukup besar, ia dipecahkan kepada sub-ejen berasingan yang bekerja secara selari dalam worktree terasing. Salinan kerja anda tidak pernah disentuh.” Katanya, ujian dalaman Meta sendiri menunjukkan alat itu membina enam ciri untuk sebuah permainan secara serentak tanpa sebarang pertembungan.

Terimalah dakwaan khusus itu dengan kewaspadaan yang sewajarnya — ia adalah laporan vendor tentang ujian dalamannya sendiri, bukannya penanda aras yang disahkan secara bebas, dan “beta” bermaksud kelemahan yang masih belum diperhalus. Namun, hala tujunya tidak benar-benar dipersoalkan kerana ini bukan hanya tentang Meta. Claude Code dan Codex juga bergerak ke arah yang sama: satu arahan masuk, berbilang aliran kerja terasing keluar, setiap satunya calon diff yang menunggu keputusan. Tiga vendor berasingan yang menuju kepada bentuk alat yang sama merupakan isyarat yang lebih kukuh daripada mana-mana dakwaan pemasaran mereka secara individu.

Bottleneck sedang berubah, bukan menghilang

Sepanjang dua tahun kebelakangan ini, perbualan kerjaya tentang alat pengekodan AI kebanyakannya berkisar pada persoalan sama ada alat itu menggantikan orang yang menulis kod. Corak ejen selari menimbulkan persoalan yang lebih senyap tetapi lebih segera: siapa yang menyemak enam diff serentak dengan cukup baik untuk mengesan satu diff yang tersilap secara halus? Menulis satu ciri dan menyemak satu PR ialah kemahiran yang berbeza, tetapi sekurang-kurangnya skalanya sama. Menulis satu arahan dan menyemak enam output selari pula tidak — langkah semakan kini menjadi bahagian kitaran yang tidak menjadi lebih pantas hanya kerana modelnya bertambah baik.

Itulah perubahan sebenar tentang perkara yang menjadi terhad. Jika ejen boleh memecahkan tugasan kepada worktree terasing dan menghasilkan beberapa percubaan lengkap, kekangan untuk menghantar hasil bukan lagi penjanaan — tetapi keupayaan anda untuk membaca diff, mengesan pertembungan yang terlepas daripada alat itu, dan memutuskan antara beberapa pelaksanaan yang munasabah, yang manakah benar-benar anda mahukan dalam produksi. Pasukan yang menganggap ini sebagai “AI kini melakukan pengekodan” lalu tidak melabur dalam keupayaan semakan akan menghantar versi yang kelihatan betul sepintas lalu, bukan versi yang benar-benar betul.

Perkara yang sebenarnya menjadi lebih sukar

Kualiti spesifikasi. Apabila satu ejen menghasilkan satu output, arahan yang kabur diperjelas melalui perbualan berulang-alik. Apabila satu arahan dipecahkan kepada enam sub-ejen selari sebelum anda melihat apa-apa, kekaburan berganda enam kali, bukannya diselesaikan sekali. Arahan yang anda tulis sebelum memulakan tugasan pecahan kini perlu melakukan kerja yang dahulunya berlaku dalam perbualan susulan.

Pengesahan pada kelajuan tinggi. Membaca enam diff dengan teliti, satu demi satu, menggagalkan tujuan kerja dijalankan secara selari. Kemahiran yang wajar dibina ialah triage yang pantas dan berstruktur: mengetahui diff yang mana perlu dibaca baris demi baris, yang mana perlu disemak secara rawak berbanding ujian, dan yang mana perlu dibuang hanya berdasarkan firasat — tanpa membuang diff yang sebenarnya betul.

Pertimbangan penggabungan dan integrasi. “Worktree terasing, tiada pertembungan” menerangkan mekanik git, bukannya logik produk. Dua ciri boleh digabungkan dengan lancar tetapi masih bercanggah antara satu sama lain — perubahan caching oleh satu ejen boleh secara senyap menjejaskan pembaikan kesegaran data oleh ejen lain. Untuk mengesannya, diperlukan seseorang yang memahami sistem secara keseluruhan, bukan sekadar diff yang ada di hadapannya.

Apa yang patut dilakukan minggu ini

  • Jika pasukan anda sudah menggunakan alat pengekodan berasaskan ejen, cuba berikan tugasan yang secara jelas ditetapkan untuk dipecahkan kepada 2–3 sub-ejen, bukannya satu ejen. Perhatikan berapa lama anda meluangkan masa untuk menulis arahan awal berbanding menyemak output — nisbah itulah perkara yang sedang berubah.
  • Berlatih menulis kriteria penerimaan sebelum memulakan tugasan, bukan selepas melihat hasilnya. “Pecahkan dan pilih yang terbaik” hanya berfungsi jika anda telah mentakrifkan “terbaik” terlebih dahulu.
  • Jika anda masih di peringkat awal kerjaya dan bimbang hal ini menjadikan skop kerja anda lebih kecil, lihat dari sudut yang berbeza: keupayaan membaca diff orang yang tidak dikenali dengan cepat dan tepat, yang diasah selama berbulan-bulan melalui semakan kod, kini merupakan kemahiran yang boleh menjana pendapatan secara langsung dan bukannya tugasan sampingan yang terikat pada jawatan lebih kanan.
  • Jika anda menguruskan pasukan, elakkan mengukur output berdasarkan ciri yang dihantar setiap minggu sepanjang peralihan ini. Pasukan yang memecahkan tugasan secara agresif tetapi membuat semakan secara cuai akan kelihatan pantas sehingga tiba minggu apabila sesuatu rosak dalam produksi.

Semua ini tidak memerlukan anda mempercayai dakwaan Meta tentang enam ciri serentak secara bulat-bulat, atau memilih pemenang antara Muse Code, Claude Code dan Codex. Apa yang diperlukan ialah menyedari bahawa tiga makmal yang mempunyai sumber kukuh secara bebas memutuskan bahawa tuas seterusnya yang perlu ditarik ialah keselarian, bukan sekadar kualiti model mentah — dan merancang pembangunan kemahiran anda sendiri berdasarkan bottleneck yang terhasil daripadanya, bukannya bottleneck yang sudah diselesaikan untuk anda.