Ngayong linggo, inilabas ng Meta ang Muse Code, isang coding agent na nakabatay sa terminal at binuo gamit ang Muse Spark 1.2 model nito, kaya direktang nakikipagkumpitensya ito sa Claude Code ng Anthropic at Codex ng OpenAI. Hindi ang kalidad ng modelo ang tampok na tampok — ang arkitektura nito. Gaya ng paglalarawan ni Mark Zuckerberg, “kapag sapat ang laki ng isang gawain, hinahati ito sa magkakahiwalay na sub-agent na sabay-sabay na nagtatrabaho sa mga nakahiwalay na worktree. Kailanman ay hindi ginagalaw ang working copy mo.” Sinabi niyang sa sariling pagsusuri ng Meta, nagawa ng tool na bumuo ng anim na feature para sa isang laro nang sabay-sabay at walang nagkabungguan.

Tanggapin ang partikular na pahayag na iyon nang may nararapat na pag-iingat — salaysay iyon ng isang vendor tungkol sa sarili nitong internal na pagsusuri, hindi isang benchmark na independiyenteng napatunayan, at ang “beta” ay nangangahulugang hindi pa napapakinis ang mga magaspang na bahagi. Ngunit hindi naman talaga pinag-aalinlanganan ang direksiyong ito, dahil hindi lang Meta ang gumagawa nito. Parehong kumikilos sa ganitong paraan ang Claude Code at Codex: isang instruksyon ang ipinapasok, maraming nakahiwalay na workstream ang inilalabas, at bawat isa ay isang candidate diff na naghihintay ng desisyon. Mas malakas na senyales ang pagsasama-sama ng tatlong magkakahiwalay na vendor sa iisang anyo ng tool kaysa sa alinman sa mga pahayag sa marketing ng mga ito.

Lumilipat ang bottleneck, hindi nawawala

Sa nakalipas na dalawang taon, ang usapan tungkol sa karera kaugnay ng mga AI coding tool ay kadalasang umiikot sa kung papalitan ba ng mga ito ang taong nagsusulat ng code. Ang pattern ng mga parallel agent ay naglalabas ng mas tahimik ngunit mas agarang tanong: sino ang susuri nang sapat sa anim na sabay-sabay na diff para mahuli ang isang bahagyang maling bersiyon? Magkaibang kasanayan ang pagsulat ng isang feature at pagsusuri ng isang PR, pero kahit paano ay magkapareho ang saklaw ng mga ito. Ang pagsulat ng isang instruksyon at pagsusuri ng anim na parallel na output ay hindi ganoon — ang hakbang ng pagsusuri na ngayon ang bahagi ng proseso na hindi bumibilis dahil lang gumanda ang modelo.

Tunay na pagbabago ito sa kung ano ang kapos. Kung kayang hatiin ng isang agent ang isang gawain sa magkakahiwalay na worktree at gumawa ng ilang kumpletong pagtatangka, hindi na ang pagbuo ang hadlang sa paglalabas — ang hadlang ay ang kakayahan mong magbasa ng mga diff, mapansin ang banggaang hindi nakita ng tool, at magpasya kung alin sa ilang kapani-paniwalang implementasyon ang talagang gusto mong ilagay sa production. Ang mga team na ituturing itong “AI na ang gumagawa ng coding ngayon” at lalaktawan ang pamumuhunan sa kapasidad ng pagsusuring iyon ay maglalabas ng bersiyong mukhang tama sa unang tingin, hindi ng bersiyong talagang tama.

Ano talaga ang mas nagiging mahirap

Kalidad ng espesipikasyon. Kapag isang output ang ginagawa ng isang agent, nalilinaw ang malabong instruksyon sa pamamagitan ng pabalik-balik na usapan. Kapag ang isang instruksyon ay hinahati sa anim na parallel na sub-agent bago ka pa makakita ng anuman, napaparami nang anim ang kalabuan sa halip na malutas minsan. Ang instruksyong isinusulat mo bago simulan ang isang fan-out na gawain ay kailangan na ngayong gawin ang trabahong dating nagaganap sa kasunod na pag-uusap.

Pagbeberipika nang mabilis. Tinatanggal ng maingat na pagbasa sa anim na diff, isa-isa, ang saysay ng pagpaparallelize ng gawain. Ang kasanayang sulit linangin ay mabilis at sistematikong triage: pag-alam kung alin sa anim ang babasahin nang linya bawat linya, alin ang sasailalim sa spot-check laban sa mga test, at alin ang itatapon batay pa lang sa kutob — nang hindi itinatapon ang isa na siya palang tama.

Paghuhusga sa merge at integration. Inilalarawan ng “nakahiwalay na worktree, walang banggaan” ang mekanika ng git, hindi ang lohika ng produkto. Maaaring malinis na ma-merge ang dalawang feature at magkasalungat pa rin ang mga ito — maaaring tahimik na pahinain ng pagbabago sa caching ng isang agent ang pag-aayos ng isa pa sa pagiging napapanahon ng data. Para mahuli iyon, kailangan ng taong nauunawaan ang buong sistema, hindi lang ang diff na nasa harap niya.

Ano ang dapat talagang gawin ngayong linggo

  • Kung gumagamit na ang team mo ng agentic coding tool, subukang magtalaga rito ng gawaing tahasang nakatakdang hatiin sa 2–3 sub-agent sa halip na isa. Pansinin kung gaano katagal kang nagsusulat ng paunang instruksyon kumpara sa pagsusuri ng output — ang ratio na iyon ang nagbabagong bagay.
  • Magsanay na magsulat ng acceptance criteria bago simulan ang isang gawain, hindi pagkatapos makita ang resulta. Gumagana lang ang “hatiin at piliin ang pinakamahusay” kung tinukoy mo na nang maaga kung ano ang ibig sabihin ng “pinakamahusay.”
  • Kung nasa unang bahagi ka pa ng iyong karera at nag-aalala kang paliitin nito ang trabaho mo, tingnan mo ito sa ibang paraan: ang kakayahang mabilis at wastong magbasa ng diff ng isang taong hindi mo kilala, na hinasa sa loob ng maraming buwan ng code review, ay isa na ngayong kasanayang maaaring direktang pagkakitaan sa halip na isang gawaing nakakabit sa mas nakatataas na titulo.
  • Kung namamahala ka ng team, iwasang sukatin ang output batay sa mga feature na nailalabas bawat linggo habang nagaganap ang pagbabagong ito. Ang team na agresibong naghahati ng mga gawain ngunit pabaya kung magsuri ay magmumukhang mabilis hanggang sa linggong may masirang bagay sa production.

Wala sa mga ito ang nangangailangan na paniwalaan nang literal ang pahayag ng Meta tungkol sa anim na feature nang sabay-sabay, o pumili ng mananalo sa Muse Code, Claude Code, at Codex. Ang kailangan ay mapansin na tatlong laboratoryong may sapat na yaman ang independiyenteng nagpasiyang ang susunod na lever na hihilahin ay parallelism, hindi lamang hilaw na kalidad ng modelo — at planuhin ang sarili mong paglinang ng kasanayan batay sa bottleneck na nalilikha nito, sa halip na sa bottleneck na nilulutas na para sa iyo.