Editor's Note: Kapag ang AI Agent ay naging mas mura at mas madaling i-trigger, ang software development ay pumasok sa isang bagong yugto: ang tanong ay hindi na kung kaya naming i-start ang higit pang mga Agent, kundi kung may sapat pa bang atensyon ang tao upang pamahalaan, husgahan, at i-merge ang kanilang mga output.

Ang artikulong ito ay nagtatampok ng isang napakalaking konsepto—ang “orchestration tax.” Ang pagpapalawak ng isang Agent ay mura, kailangan lamang ng isang Prompt o isang pag-click; ngunit ang totoong mahal ay ang mga susunod na hakbang: ang pagsusuri kung tama ang resulta, ang pag-unawa sa epekto nito sa arkitektura ng sistema, ang pagharap sa mga konflikto sa pagitan ng iba’t ibang Agent, at sa huli, ang pagpapasya kung aling code ang maaaring maipasa sa pangunahing branch. Ang mga gawain na ito ay hindi maaaring madaliing parallelize, at kailangan pa ring bumalik sa iisang serial na yunit: ang paghuhusga ng tao.

Ipinapahiwatig ng may-akda ang mga developer bilang ang “GIL” sa loob ng AI Agent system—ang iisang thread lock na naglalimita sa pinakamataas na throughput ng concurrent system. Maaaring magtrabaho nang sabay-sabay ang maraming Agent, ngunit kung pumasok sila sa mga yugto ng pagtataya ng arkitektura, pagsusuri ng code, at pagpapagsama ng mga konflikto, kailangan nilang bumalik sa isip ng developer. Kaya, mas maraming Agent ay hindi nangangahulugan ng mas mataas na output; maaari itong magdulot lamang ng mas mahabang listahan ng mga gawain na kailangang suriin, at magdulot ng mas madalas na pagbabago ng konteksto at pagkapagod sa kognisyon para sa developer.

Ito ay isang madalas na nakakalimutang aspeto sa kasalukuyang pagtaas ng mga AI tool para sa pag-program: ang pakiramdam ng efficiency ay hindi laging katumbas ng totoong produktibidad. Ang isang dashboard na puno ng mga nagpapatakbo na Agent ay maaaring maglikha ng maling pagkakaintindi ng "malaking produktibidad"; kung ang mga developer ay hindi talaga naiintindihan, sinusuri, at inaayos ang mga pagbabago, ang sistema ay maaaring mag-umpisa na mag-akumula ng teknikal at kognitibong utang, hindi produktibidad.

Kaya ang tunay na pinag-uusapan ng artikulong ito ay hindi ang “paano gamitin ang higit pang Agent,” kundi ang “paano muli itaas ang workflow batay sa atensyon ng tao.” Sa panahon ng Agent, ang mahalagang kakayahan ay hindi lamang ang pagtatanong o pagkakaloob ng mga gawain, kundi ang pagkilala sa mga gawain na maaaring ibigay sa machine para sa paralel na pagproseso at mga gawain na dapat manatili sa pagdedesisyon ng tao; kailan dapat mag-batch review, at kailan dapat tumigil sa pag-organisa at muling mag-focus sa isang pangunahing problema.

Ang AI ay nagpapalawak sa kakayahan ng paggawa ng software nang sabay-sabay, ngunit ang atensyon ng tao ay patuloy na ang pinakakakulang at hindi maaaring kopyahin na yaman sa sistema. Ang totoong matatag na workflow ng Agent ay hindi ang paghahatol ng lahat ng gawain sa makina, kundi ang pagdidisenyo nang maingat ng sariling arkitektura ng atensyon, tulad ng pagdidisenyo ng isang sistema ng produksyon.

Narito ang orihinal na teksto:

Ngayon, mas madali na ang pagpapagana ng higit pang AI Agent. Ngunit ang pagpapagana ng higit pang Agent nang sabay-sabay ay hindi nangangahulugan na lumalaki ang 'ikaw'. Hindi ma-parallelize ang iyong cognitive bandwidth. Ang lahat ng tunay na pagpapasya para sa paggabay sa kanila, paghuhusga sa mga resulta, at pagpapagsama at pagpapabago ay kailangan pa ring dumadaan sa iisang serial processor—ikaw mismo.

Ang tinatawag na “tax ng pagkakasunod-sunod” ay sa katotohanan ang halaga na iyong binabayad pagkatapos mong kalimutan ang punto na ito. At ang tanging tunay na solusyon ay ang pagdidisenyo ng iyong sariling atensyon, tulad ng pagdidisenyo ng anumang concurrent system.

Nakilahok ako sa isang panel discussion sa Google I/O kung saan pinag-usapan namin ni Richard Seroter, Aja Hammerly, at Ciera Jaspan kung ano ang kalagayan ng software engineering ngayon at kung paano ito maaaring mag-evolve sa susunod. Sa malapit na pagtatapos, tanong ni Richard sa amin: Ano ang isang bagay na dapat dalhin at pagbabaguhin ng mga developer pagkatapos marinig ang talakayan?

Sinabi ko ang isang bagay na palaging isinasaalang-alang ko sa mga nakalipas na buwan: ang pagmamalaki na sobrang busy ka ay hindi katumbas ng tunay na output. Maaari mong i-run ang 20 Agent nang sabay-sabay at maramdaman mong sobrang busy ka. Pero hindi ito nangangahulugan na nagbigay ka ng 20 na katumbas na workload ng bawat Agent.

Sa mas maagang bahagi ng usapan, ibinigay ni Richard ang pangalan sa tanong na ito. Sinabi niya: "Ang sinabi mo kanina ay talagang tax orchestration. Hindi mo kayang mag-manage ng 20 na Agent sa iyong isip."

Tama siya nang buong-pusong. Gusto kong mas detalyadong ipaliwanag ang konseptong ito, dahil hindi ito isyu ng disiplina, kundi isyu ng arkitektura.

Sa isang roundtable, may isang pahayag na ako'y malayang sinabi, at patuloy na namumulat sa aking isipan: Ang pagpapatakbo ng maraming Agent ay hindi nangangahulugan na may karagdagang ikaw sa mundo.

Ang asymmetry na hindi isinama ng mga tao

Mayroong nakatagong asimetriko sa workflow ng agent.

Ang pagpapagana ng isang Agent ay napakababa ang gastos. Kailangan mo lang i-type ang isang beses sa keyboard, o isulat ang isang Prompt. Ngunit ang pagkumpleto ng loop ng Agent ay hindi napakababa ang gastos. Dapat may tao na susuriin kung tama ang mga resulta na ibinigay nito, at i-coordinate muli ang mga pagbabago na gawin ng iba pang Agent.

Ito ang ikaw. At ikaw ay isa lamang.

Noong nakaraang buwan, sinulat ko ang ilang bahagi ng tanong na ito sa “Iyong Limitasyon sa Parallel Agent”, na pangunahing tumatalakay sa uri ng anxiety na kaugnay sa kapaligiran: hindi mo alam kung aling parallel thread ang nagkakaroon ng tahimik na pagkabigo. Ang artikulong ito ay tutalakay sa istruktura sa likod ng gastos na ito.

Kapag nagsimula ka na ring tingnan ang pag-unlad ng Agent bilang isang concurrent system, makikita mo na ang tao ay isang komponent lamang ng sistema na ito. Isang napakalalim na serial na komponent.

Ikaw ang iisang thread na mapagkukunan

Kung nag-write ka na ng concurrent code, mayroon ka nang intuitibong pag-unawa sa tanong na ito. Simple lang, ginamit mo na ang intuitibong ito sa maling lugar.

May global interpreter lock sa Python, o GIL. Maaari mong lumikha ng anumang bilang ng threads, ngunit sa isang panahon, isa lamang ang thread na makakapag-execute ng Python bytecode dahil kailangan nilang makakuha ng susi na ito.

Ikaw ay ang GIL ng iyong AI Agent.

Maaari silang mag-run nang sabay-sabay. Ngunit kailangan nilang kumuha ng susi muna kung ang kanilang trabaho ay nangangailangan ng tunay na pag-unawa sa arkitektura ng sistema, o kung kailangan nilang lutasin ang mga conflict sa merge. At ang susi ay isang susi lamang, at nasa iyong kamay.

Mas tiyak na ipinapaliwanag ng Amdahl's Law na ang limitasyon sa pagpapabilis mula sa pagpaparalelo ay nakadepende sa bahagi ng trabaho na kailangan pa ring gawin nang serial. Kung may malaking bahagi sa iyong proseso na hindi maaaring paralelin, kahit gaano pa karaming core ang iyong ipapasok, magtatapos ka sa isang matigas na limitasyon.

Sa pag-unlad ng Agent, ang serial na bahaging ito ay ang pagkakaroon ng pagkakataon.

Hindi magpapabilis ng iyong oras ng pagdedesisyon ang pagpapagana ng 8 na Agent. Ito ay magpapahaba lang ng queue ng mga naghhintay sa iyo para prosesuhin.

Ito ay isang matandang katotohanan sa performance engineering, ngunit marami pa ring nababahala dito: ang pag-optimize sa mga bahaging hindi bottleneck ay hindi magpapataas ng kabuuang throughput. Nagdadagdag ka lang ng higit pang hindi natatapos na trabaho sa harap ng bottleneck.

Dinadagdagan ng Agent ang bahagi na hindi talaga isang limitasyon. Ang totoong limitasyon ay ang review na bahagi, at ang kabuuang throughput ng sistema ay eksaktong katumbas ng throughput ng bahaging ito.

Ang tax na pagkakaayos ay ang estruktural na puwang sa pagitan ng kapasidad ng agent at ng mga bagay na talagang maaari mong i-merge. Ito ay nangyayari kapag pinapayagan mong ang isang single-threaded na yunit na pamahalaan ang isang concurrent na sistema.

Hindi lutasin ng pagpapilit ang structural limit

Sa mesa ng roundtable, sinabi ko ang isang pahayag: Hindi ko pa nararamdaman na ang aking mga kasangkapan ay ganitong epektibo, ngunit hindi ko rin pa nararamdaman na ganitong pagod.

Ang parehong damdamin ay lubos na totoo, at sila ay nagmumula sa iisang dahilan.

Mayroong napakaspesipikong pinagmulan sa pagod na ito: ito ang pakiramdam kapag patuloy na pinipilit ang isang serial processor sa 100% at walang anumang buffer.

Bawat beses mong titingin sa isang Agent na naiwan sa iyong sakop ng atensyon, kailangan mong magbayad ng gastos sa pagbabago ng konteksto. Kailangan mong linisin ang iyong isipan, tapos muling i-load ang isang ibang konteksto mula sa zero.

Ang CPU ay makakapagtapos nito sa loob ng microsecond, bagaman ang mga arkitekto ay patuloy na iiwasan ang madalas na pagbabago. Samantala, ikaw ay kailangang mag-wait ng ilang minuto para makapagtapos, at hindi mo maiiwasan na mawala ang konteksto.

Hindi ang 5 na Agent ay paulit-ulit na 1倍 na workload. Ito ay 5 beses na context reload na parang cold start, kasama ang isang patuloy na nagpapatakbo na proseso sa background na laging nag-aalala kung aling Agent ang dapat mong i-check ngayon.

Hindi mo malulutas ang isang structural limitation sa pamamagitan ng paggawa nang mas maraming pagsusumikap. Palaging kailangang bayaran ang buwis na ito.

Kung subukan mong ipagtanggol ito, mangyayari ito sa huli sa ibang anyo: o ang code review ay magiging mas mababaw, o ikaw ay magkakaroon ng isang 'cognitive surrender' state—dahil ang pagbuo ng iyong sariling pagtataya ay sobrang nagkakahalaga ng atensyon, pinipili mong tanggapin nang direkta ang code na isinulat ng Agent.

O magbayad ka nang aktibo sa buwis na ito, o hayaan mong ito ay mabagal na pagsira sa iyong pag-unawa sa iyong sariling sistema.

Disenyo ang iyong atensyon tulad ng isang design system

Kaya, kailangan mong treating ang iyong atensyon bilang isang kakaibang, serial na yaman.

Hindi mo isasama ang mga bottleneck sa pagdidisenyo ng isang distributed system. Kaya, bigyan mo rin ng parehong paggalang ang iyong utak.

Ito ay ilang mga paraan na talagang gumagana para sa akin:

Ang isang mabuting concurrent system ay gagamit ng backpressure mechanism upang maiwasan ang walang hanggang paglalago ng queue. Dapat mabagalin ng producer ang bilis upang tugma sa kakayahan ng consumer.

Ang bilang ng iyong Agent ay ang mga tagapaglikha, at ang iyong kakayahang mag-review ay ang tagapakinig. Ang tamang bilang ng paralel na Agent ay ang bilang na kayang mong mabuting i-review. Para sa karamihan, ito ay karaniwang isang maliit na isahan.

Ang mga tool sa AI ay siguradong magiging masaya na pagsimulan mo ang 20 na Agent, ngunit iyon ay isang UI function lamang at hindi nangangahulugan na may kakayahan ka talaga na pamahalaan sila.

Nang tanungin ako ni Richard kung paano ko masisolve ang bagay na ito, binanggit ko ang paraang ito. Ihihiwalay ko ang gawain sa dalawang grupo.

Ang unang grupo ay isang relatibong independiyenteng gawain, at handa kong ibigay sa Agent na tumatakbo sa cloud backend. Maaaring i-execute nang asinkrono ang mga gawain na ito, at karaniwan ay kailangan lang ng isang pagpapatotoo mula sa akin sa huling yugto.

Ikalawang grupo ay ang mga kumplikadong gawain, kung saan ang tunay na trabaho ay ang pagpapasya. Halimbawa, isang napakakakaibang bug o isang pagdidisenyo ng arkitektura.

Ang pinakamalaking pagkakamali ay ang pagsubok na parallelize ang mga ikalawang klase ng gawain. Ang pagpaparalelo ng maraming kumplikadong gawain ay hindi magpapalawig ng iyong output, kundi magpapakita lamang ng paulit-ulit na pakikidigma para sa susi, at sa huli ay masasira ang lahat ng resulta.

Ang bawat pagbabago ng konteksto ay nagdadala ng mataas na gastos. Mas mura ang pag-upo nang isang beses at pag-review ng mga resulta ng 4 na Agent, kaysa tingnan ang isang isa, gawin ang iba pang bagay, at muling mag-start para tingnan ang isa pang isa.

Bigyan ng mas mahabang tali ang Agent. Hayaang makalikom ng kaunting trabaho, tapos bigyan ng isang batch para prosesuhin.

Huwag mag-waste ng iyong isipan sa mga bagay na maaaring i-verify ng machine. Pahintulutan ang Agent na sumulat ng mga subok na makakapasa, o mag-generate ng screenshot.

Hayaan nilang patunayan ang 80% na mababaw at mapapatotohanan. Sa ganitong paraan, ang iyong limitadong atensyon ay maaaring i-focus lamang sa 20% na nangangailangan ng tao na pagpapasya.

Ang bottleneck ay nangangailangan ng iyong pinakamahusay na oras, hindi ang mga piraso ng oras na natitira mo pagitan ng ilang Agent check.

minsan, ang pinakamataas na leverage ay ang paghinto sa buong pagkakasunod-sunod: pagsarado ang computer na puno ng Agent, at mag-focus lamang sa isang tanong, habang masisiguro ang pagkakaroon ng susi sa buong proseso.

Ang pag-ayos ay hindi totoong trabaho. Ito ay simpleng gastos na nagmumula sa trabaho.

Tinukoy ni Aja na ang kakayahan sa arkitektura ay naging pinakamahalagang kasanayan ngayon: kailangan mong malaman kong anong mga gawain ang angkop na isama sa isang Agent at anong mga gawain ay sobrang malaki para sa kanya.

Gusto kong dagdagan pa: ikaw ay isang komponente rin sa loob ng sistema. Mayroon ka namang kilalang, mababang serial throughput. Ang sistema ay o sumusunod sa numero na ito, o iiwas dito sa pamamagitan ng pagbabawas nang tahimik sa iyong mga pamantayan.

Ang pagiging malakas ay hindi katumbas ng mataas na produktibidad

Mahalaga ito, dahil ang uri ng pagkabigo na ito ay halos hindi makikita sa iyo.

Ang 20 na nagpapatakbo na Agent ay magbibigay sa iyo ng pakiramdam na “nagkakaroon ng sobrang produktibidad.” Punong-puno ang dashboard, at lahat ay gumagalaw. Ngunit ang pakiramdam na ito ay naging hiwalay na sa tunay na pagpapaloob ng mataas na kalidad na code sa pangunahing branch.

Maaari kang maging sobrang busy, ngunit may kaunting tunay na output. Sa panloob na pagkakakita, pareho sila ng halos magkakapareho.

Binanggit ni Ciera ang pag-aaral ni Margaret-Anne Storey tungkol sa utang. Nag-usap kami tungkol sa teknikal na utang at sa kognitibong utang.

Walang pagpapataw ng buwis sa pagpapalit, na magiging sanhi ng pagkakaroon ng parehong utang.

Pinagsama mo ang mga bagay na hindi mo seriosong binasa. Ang iyong mental model sa codebase ay lubos na luma. Hindi ito magkakaroon ng problema sa dashboard ngayon. Magkakaroon ito ng problema sa production—kapag nagkakaroon ng error ang sistema, at biglang naiintindihan mo na hindi mo na alam kung paano ito gumagana.

Kaya, ang totoong konklusyon ay: ang pagpapagana ng Agent ay hindi isang kakayahan. Maaaring i-run ng sinuman ang 20.

Ang tunay na kakayahan ay ang pagdisenyo ng sistema sa paligid ng serial resource na hindi maaaring kopyahin o parallelize.

Ang resource na ito ay ang iyong atensyon.

I-design it tulad ng anumang mahalagang komponente na nakadepende sa isang production environment.