Nang ilunsad ng Meta ang Muse Code ngayong linggo, ang pangunahing balita ay tungkol sa kompetisyon: isa na namang coding agent na nakabatay sa terminal ang sumasali sa Claude Code, Codex, at Cursor sa labanan para sa mga workflow ng developer. Ngunit nakabaon sa mismong paglalarawan ni Mark Zuckerberg sa tool ang mas kawili-wiling hudyat para sa sinumang nagsusulat o nagsusuri ng code bilang trabaho.

“Kapag sapat ang laki ng isang gawain, hinahati ito sa magkakahiwalay na sub-agent na sabay-sabay na nagtatrabaho sa mga nakahiwalay na worktree,” isinulat ni Zuckerberg, habang inilalarawan ang paraan ng Muse Code sa pagharap sa malalaking gawain. “Hindi kailanman ginagalaw ang iyong working copy. Sa pagsubok, sabay-sabay nitong binuo ang anim na feature para sa isang laro nang walang banggaan.”

Hindi iyan paglalarawan ng feature. Paglalarawan iyan ng trabaho—para sa iyo.

Ano talaga ang ibig sabihin ng “nakahiwalay na worktree”

Hinahayaan ka ng git worktree na i-check out ang maraming branch ng iisang repository sa magkakahiwalay na directory nang sabay-sabay, kaya maaaring magpatuloy ang ilang linya ng trabaho nang hindi naaapakan ng isang checkout ang isa pa. Ayon sa paglalarawan ng Meta, ginagamit ng Muse Code ang mekanismong ito upang makapagsulat ng code ang ilang sub-agent nang sabay-sabay nang hindi ginagalaw ang iyong aktibong working copy o ang mga file ng isa’t isa. Makatuwiran itong pagpiling pang-engineering: ang mga banggaan sa antas ng file ang pinakamadaling uri ng conflict sa multi-agent na mapipigilan sa pamamagitan ng mekanikal na paraan, kaya pinipigilan mo ang mga ito nang mekanikal at hinahayaan ang modelo na magpokus sa mismong coding.

Ang salitang dapat pansinin ay “hinahati ito palabas.” Hindi nararanasan ng isang human developer ang anim na parallel worktree bilang anim na code stream na isa-isang susuriin nang magkakasunod—anim itong stream na halos sabay-sabay dumarating sa mesa niya, at bawat isa ay nangangailangan ng desisyon: isasama ba ito, kailangan ba itong ayusin muli, sumasalungat ba ito sa ginawa ng isang katabing agent sa ibang worktree.

Ang kasanayang aktuwal na nagbabago

Sa nakalipas na ilang taon, ang nangingibabaw na modelo ng coding na tinutulungan ng AI ay pakikipag-usap at iisa ang daloy: isang developer, isang assistant, isang thread ng palitan, na sinusuri halos habang ginagawa. Kailangan pa rin ang kasanayang iyon—mahusay na pagpo-prompt, agarang pagtukoy sa maling mungkahi, at pag-uulit—ngunit hindi iyon ang kasanayang ino-optimize ng disenyo ng Muse Code. Ipinapalagay ng paghahati sa mga sub-agent na lumipat ka na sa ibang paraan ng pagtatrabaho: paunang paghahati ng isang gawain sa mga bahaging maaaring tumakbo nang hiwalay, at pagkatapos ay pagsusuri sa natapos o bahagyang natapos na output mula sa ilang agent nang sabay-sabay sa halip na pag-akay sa isang agent sa bawat pagliko.

Mas malapit ito sa pagiging tech lead na naghahati ng isang sprint sa isang maliit na team kaysa sa isang pair programmer na kahati ng screen ang chatbot. Mas kaunti ang halaga ng mga indibidwal na desisyon sa coding kumpara sa paghahati ng gawain (hinati mo ba ito sa mga bahaging talagang magkahiwalay?) at sa yugto ng pagsusuri (mabilis mo bang matutukoy kung tama ang bawat isa sa anim na parallel diff at magkakaugnay ang lahat?).

Nilulutas ng isolation ang mga banggaan, hindi ang pagkakaugnay

Mahalagang pag-isipan ito, dahil madaling hindi mapansin: pinipigilan ng mga nakahiwalay na worktree ang dalawang agent na patungan ang iisang file. Wala silang ginagawa upang pigilan ang dalawang agent na magkahiwalay na mag-imbento ng dalawang magkaibang paraan para gawin ang iisang bagay—isang pangalawang date-formatting helper, isang pangalawang retry wrapper, isang duplicate na API route—dahil hindi nakikita ng alinmang agent kung ano ang binubuo ng isa pa. Ang git isolation ay garantiya sa file system, hindi garantiya sa disenyo. Ang reviewer na nagsasama ng anim na worktree pabalik ang tanging checkpoint kung saan mahuhuli ang duplicate na abstraction, hindi magkakatugmang convention sa pagbibigay ng pangalan, o dalawang feature na tahimik na umaasa sa magkaibang anyo ng data. Kung nagmamadaling tingnan ng reviewer na iyon ang mga diff dahil mas mabilis dumami ang parallel output kaysa sa maingat na pagbabasa, eksaktong ganitong uri ng pagkalihis ang napapadala sa production.

Binabago nito ang kahulugan ng kailangang maging “code review” kapag naging karaniwan na ang mga fan-out tool: mas kaunting pagsusuri bawat linya ng isang diff (karaniwan namang maayos ang syntax ng agent), at mas maraming pagtutugma sa pagitan ng mga diff—pagsusuri kung nagkakasundo ang magkakatulad na stream ng gawaing binuo ng AI sa mga shared convention, shared data model, at shared na paghawak ng error.

Ano talaga ang dapat pagtuunan ng pagbuo

Wala sa mga ito ang nangangailangan ng Muse Code mismo—lumilitaw ang parehong fan-out pattern sa mga pangunahing coding agent, na nagpapahiwatig na nagiging default architecture na ito sa halip na taya sa iisang vendor. Narito ang ilang konkretong bagay na maaari nang sanayin ngayon, anuman ang tool na ginagamit mo:

  • Sumulat ng mga task spec na madaling hatiin. Bago ka humingi ng sabay-sabay na trabaho, tanungin ang sarili kung tunay na magkahiwalay ang mga bahagi—ginagalaw ba nila ang parehong file, parehong shared constant, o parehong API contract? Kung oo, hindi iyan gawain para sa anim na parallel agent; gawain iyan para sa isang agent na sunod-sunod na magtrabaho, o para ikaw mismo ang unang maghati ng magkakaparehong bahagi.
  • Magsanay ng pagsusuri sa merge point, hindi sa diff point. Masanay kang kumuha ng ilang natapos na branch at ilagay ang mga ito sa tabi-tabi, saka itanong na “nagkakasundo ba ang mga ito,” hindi lamang na “tama ba ang bawat isa nang mag-isa.”
  • Alamin ang mga pangunahing kaalaman sa git worktree. Kung ilalarawan ng mga tool na ginagamit mo ang kanilang mga internal sa ganitong paraan, batayang kaalaman na para sa pagtitiwala—o wastong hindi pagtitiwala—sa output ang pag-unawa sa mga ginagarantiya at hindi ginagarantiya ng isang worktree.
  • Gawing malinaw kung sino ang may pananagutan sa mga bagay na pinagsasaluhan. Mga constant, schema, shared utility, convention sa pagbibigay ng pangalan. Mas marami sa mga ito ang naitatakda mo bago magsimula ang fan-out, mas kaunti ang kailangan mong pagtutugmang gawin pagkatapos.

Ang mga taong pinakamaraming mapapakinabangan sa mga tool tulad ng Muse Code ay hindi ang pinakamahusay mag-prompt. Sila ang mga taong tahimik na naging mahusay sa pagpapatakbo ng isang maliit, mabilis, at kung minsan ay burara na team—kahit modelo ang bawat miyembro ng team na iyon.