Ngayong linggo, inilabas ng Meta ang Muse Code, isang coding agent na nakabatay sa terminal at binuo sa modelo nitong Muse Spark 1.2, kaya direktang nakikipagkumpitensya ito sa Claude Code ng Anthropic, Codex ng OpenAI, at Cursor. Ang pangako, sa mismong mga salita ni Mark Zuckerberg, ay kaya nitong humawak ng “kumpletong mga gawain sa software engineering sa malalaking repo: pagpaplano ng mga pagbabago, pagsulat ng code, at pagpapatunay sa mga resulta.” Ang detalyeng dapat pagtuunan ay kung paano nito hinahawakan ang malalaking gawain: “Kapag sapat ang laki ng isang gawain, hinahati ito sa magkakahiwalay na sub-agent na sabay-sabay na nagtatrabaho sa magkakahiwalay na worktree. Hindi kailanman ginagalaw ang iyong working copy.” Iginiit ni Zuckerberg na sa isang test run, “sabay-sabay itong nakabuo ng anim na feature para sa isang laro nang walang banggaan” — pahayag ito ng vendor, hindi benchmark na independiyenteng napatunayan, kaya dapat pagdudahan ang partikular na bilang. Totoo naman ang padron sa likod nito: ito na ngayon ang karaniwang pangako sa buong industriya, hindi natatanging feature ng Meta.

Ibig sabihin, mabilis na lumiliit ang pagkakaiba ng mga tool na ito. Magplano, mag-code, mag-validate, mag-parallelize — nagsasama-sama ang lahat ng pangunahing lab sa parehong apat-na-hakbang na loop. Kung bumubuo ka ng karera sa paligid ng “magaling akong magpagawa sa isang agent,” ginagawa nang komoditi ng mga vendor mismo ang kasanayang iyon habang nangyayari ito. Ang hindi ginagawang komoditi, at hindi talaga nalulutas ng alinman sa mga paglulunsad na ito, ay ang nangyayari pagkatapos ng fan-out: kailangan pa ring magpasya ng isang tao kung tama ang bawat isa sa anim na piraso ng code na isinulat nang sabay-sabay ng anim na sub-agent na hindi nakikita ang gawa ng isa’t isa, at kung magkakaugnay ang mga ito bilang kabuuan.

Nilulutas ng magkakahiwalay na worktree ang problema sa merge conflict, hindi ang problema sa kawastuhan

Tunay na pagpapahusay sa engineering ang pagpapatakbo ng mga sub-agent sa magkakahiwalay na worktree — pinipigilan nitong mabura ng isang agent ang mga edit ng isa pa. Ngunit nangangahulugan din ito na walang anumang nakitang desisyon ng isa’t isa ang mga agent na bumubuo sa anim na feature habang nagtatrabaho sila. Kung dalawa sa kanila ang magkahiwalay na nagdagdag ng magkatulad na helper function, nagpasok ng bahagyang magkaibang validation logic para sa parehong input, o gumawa ng hindi magkatugmang mga palagay tungkol sa isang shared data shape, hindi iyon nahuhuli ng isolation — ipinagpapaliban lang nito ang banggaan mula sa “merge conflict” tungo sa “integration bug na nailalabas.” Ibang uri ito sa estruktura ng failure mode kaysa sa pinipigilan ng mga tool na ito, at ito ang kailangang mahuli ngayon ng isang tao.

Mahalagang maging tumpak dito, dahil madaling paghaluin ang “sinuri ng agent ang sarili nitong output” at “nasuri ang output.” Ang pag-check ng isang agent kung nagko-compile ang code nito at pumapasa sa mga test na isinulat nito ay hindi katulad ng pagtatanong ng isang reviewer kung magkakatugma ang anim na pagbabagong ginawa nang sabay-sabay at kung tugma ang mga ito sa natitirang bahagi ng codebase. Magkaibang trabaho ang mga iyon, at isa lamang sa mga iyon ang aktuwal na ibinebenta ng mga harness na ito.

Ang kasanayang talagang nagiging kakaunti

Kung nagtatrabaho ka sa software o malapit dito — engineer, PM, QA, technical support, maging hindi engineer na ngayon ay nagpapalabas ng maliliit na tool gamit ang mga agent na ito — ang praktikal na implikasyon ay ang “pagsusuri sa consistency ng multi-file, multi-agent na output” ay nagiging sarili nitong disiplina, hiwalay sa pagsulat ng code at hiwalay sa mahusay na pag-prompt sa isang agent. Ilang konkretong bahagi nito:

  • Pagkakalibrate ng tiwala. Ang pag-alam, bago ka pa magbasa ng isang linya, kung aling uri ng pagbabago ang nangangailangan ng maingat na pagsusuri (anumang umaabot sa shared state, API contract, o anumang maaaring nahawakan din ng higit sa isang sub-agent) kumpara sa kung aling uri ang ligtas na silipin lamang.
  • Pagbabasa ng cross-diff. Kapag ang isang gawain ay hinahati sa magkakasabay na trabaho, hindi isang diff ang yunit ng pagsusuri — ang kabuuan ng mga diff ang yunit nito. Ibig sabihin, sadyang sinusuri kung may nadobleng logic, magkakaibang pag-uugali sa parehong input, at hindi magkakatugmang pagpapangalan o mga palagay sa iba’t ibang bahagi, sa halip na basahin lamang ang bawat file nang hiwalay.
  • Pagsulat ng spec para sa isang executor na hindi sinusubaybayan. Ang upstream na solusyon sa panganib ng banggaan ay isang paglalarawan ng gawain na sapat ang linaw upang hindi na kailangang mag-ugnayan ang magkakasabay na agent dahil tama na sa simula pa lamang ang pagguhit ng kanilang mga hangganan. Ang pagsulat ng ganitong spec ay mas malapit sa kasanayan sa systems design kaysa sa kasanayan sa pag-prompt.

Wala sa mga ito ang bago sa pangkalahatan — palaging mahalaga ang code review at interface design. Ang bago ay ang dami at ang blind spot: kapag kayang magpasimula ng isang tao ng anim na magkakasabay na workstream sa loob ng isang hapon, lumalaki kasabay nito ang dami ng cross-cutting review na kailangan, ngunit hindi nakasabay ang mga tool para gawing madali ang cross-cutting review sa mga tool na nagpapadali ng parallel generation.

Ano talaga ang dapat gawin tungkol dito ngayong buwan

Kung nagpa-pilot ang team mo ng isa sa mga harness na ito — Muse Code, Claude Code, Codex, o isang katunggali — sulit gawin ngayon ang ilang murang hakbang, bago maging matigas ang mga nakasanayan:

  • Kapag nagre-review ka ng gawaing ginawa ng agent, tahasang itanong ang “may iba pa bang bahagi ng gawaing ito na humawak sa parehong file, function, o shared type?” bago mag-apruba — karamihan sa mga checklist sa review ay hindi nagtatanong nito dahil isinulat ang mga ito para sa mga diff na iisang author lamang.
  • Kung walang nakasulat na format ng spec ang team mo para sa pagbibigay ng mga gawain sa isang agent, magboluntaryong gumawa ng unang draft. Ang taong may hawak sa “kung paano natin bibigyan ng briefing ang agent” ay nagkakaroon ng higit na impluwensiya kaysa inaasahan sa dami ng review debt na maiipon ng team sa hinaharap.
  • Manatiling pamilyar sa higit sa isa sa mga harness na ito sa halip na itaya ang iyong kasanayan sa alinman ang pinili ng kasalukuyan mong employer. Sapat ang pagkakaiba ng kanilang pag-uugali — sa paghawak ng worktree, sa kung gaano sila kaagresibong nagpa-parallelize, at sa kung ano ang ipinapakita nila para sa review — kaya malaking totoong oras ang mawawala kung lilipat ka sa ibang tool nang walang paghahanda.

Ang pangunahing balita mula sa siklong ito ng mga paglulunsad ay tungkol sa kung aling lab ang may pinakamabilis o pinakamurang agent. Mas matibay na hudyat sa karera ang mas tahimik: lahat ng kumpanyang naglalabas ng mga tool na ito ay tahasang nag-o-optimize para sa mas maraming code na mas mabilis na nalilikha, nang sabay-sabay. Sa ngayon, hindi sila naglalabas ng katumbas na mas mahusay na paraan para suriin ang consistency ng code na iyon. Sa puwang na iyon lilitaw ang susunod na bugso ng pangangailangan sa pagkuha ng empleyado, at lilitaw ito bilang kasanayan sa review at systems thinking, hindi bilang kasanayan sa pag-prompt.