Loop Engineering.
May-akda: Addy Osmani
Isinalin ni Peggy, BlockBeats

Editorial Note: Ang paggamit ng AI coding agent ay nagbabago mula sa “tao ay manual na sumusulat ng prompt at nagpapalakas ng task nang isang hakbang sa isang beses” patungo sa “tao ay disenyo ng loop, upang ang sistema ay magpatuloy na mag-schedule ng agent.” Ang Loop Engineering, ayon kay Addy Osmani, ay nakabatay sa pagbuo ng isang workflow na makakahanap nang awtomatiko ng task, mag-aalok ng task, i-check ang resulta, i-record ang progreso, at magdesisyon kung ano ang susunod na hakbang.

Ang siklo na ito ay binubuo ng limang module: Automations (panahon na paghahanap at pagtatala ng mga gawain), Worktrees (paghihiwalay ng maraming paralel na development environment), Skills (pagpapadali ng kaalaman sa proyekto at mga pagsasama ng team), Plugins/Connectors (pagkonekta sa mga totoong tool tulad ng GitHub, Linear, Slack, database), at Sub-agents (paghihiwalay ng tagapagpaganap at tagapag-imbento), kasama ang isang panlabas na layer ng memorya, tulad ng Markdown file o Linear board, upang i-save ang estado at progreso.

Ang artikulo ay nagpapahalaga na ang kahulugan ng Loop Engineering ay hindi lamang ang “pagpapagalaw ng AI sa higit pang mga siklo,” kundi ang pagpaprioritize ng paghuhusga ng mga inhinyero sa disenyo ng sistema. Ang mga loop ay maaaring malaki ang pagsusulong sa produktyibidad ng mga developer, ngunit hindi ito magpapalit sa pag-verify, pag-unawa, at paghuhusga. Ang totoong panganib ay hindi nasa paggamit ng mga loop, kundi sa paggamit nito bilang paraan upang iwasan ang pag-unawa sa code at sistema. Ang susunod na mahalagang kakayahan sa pakikipagtulungan sa AI sa paggawa ng code ay maaaring hindi na lamang ang pagbuo ng isang mahusay na Prompt, kundi ang pagdisenyo ng mga mapagkakatiwalaan, ma-verify, at mapagpatuloy na paggalaw ng Agent.

Ang sumusunod ay ang orihinal na teksto:

Ang Loop Engineering ay nagpapalit sa iyong papel bilang “tagapagbigay ng prompt sa mga agent.” Dapat mong disenyo ang isang sistema na magpapalit sa iyo upang magbigay ng prompt sa mga agent. Ang loop dito ay maaaring maunawaan bilang isang rekursibong layunin: tinukoy mo ang isang layunin, at ang AI ay magpapag-iterate nang patuloy hanggang matapos ang gawain. Ito ay binubuo ng limang mga komponente, at ang Claude Code at Codex ay mayroon na ngayon ang lahat ng limang komponenteng ito.

Naniniwala ako na ito ay maaaring paraan kung paano tayo magco-cooperate sa hinaharap sa mga coding agents. Gayunpaman, nasa maagap pa ito yata, at nananatili akong mapag-alala. Kailangan mong maging maingat sa mga gastos sa token, dahil maaaring lubos na magkaiba ang gastos batay sa iba’t ibang mode ng paggamit, lalo na kung ikaw ay “token-rich” o “token-tight.” Kailangan mo rin ng isang mekanismo upang siguraduhing hindi bumaba ang kalidad. Ang pag-aalala tungkol sa “AI slop” ay makatotohanan rin. Gayunpaman, tingnan natin kung ano talaga ang nangyayari.

Sinabi ni @steipete noong huling panahon: “Hindi mo na dapat isulat ang mga prompt para sa mga coding agents. Dapat mong disenyo ang ilang loop na magpaprompt sa iyong agent.” Sa parehong paraan, sinabi ng tagapamahala ng Claude Code ng Anthropic na @bcherny: “Hindi na ako nagpaprompt kay Claude. Mayroon akong maraming loop na tumatakbo, at sila ang nagpaprompt kay Claude at nagpapasya kung ano ang susunod na gagawin. Ang trabaho ko ay pagsusulat ng loop.”

Ano nga ba ang ibig sabihin nito?

Sa loob ng higit sa dalawang taon, ang paraan upang gawin ang anumang bagay sa isang coding agent ay isulat ang isang mahusay na prompt at magbigay ng sapat na konteksto. Ikaw ay nag-input ng isang pangungusap, binabasa ang resulta, at pagkatapos ay nag-input ng susunod na pangungusap. Ang agent ay isang kasangkapan, at ikaw ay palaging may kamay sa kasangkapan na ito, patuloy na nagpapagalaw nito sa bawat siklo. Ang yugto na ito ay bahagyang natapos, o kaya’y sa ilang pananaw, malapit nang matapos.

Ngayon, binubuo mo ang isang maliit na sistema: ito ay makakahanap ng sarili nitong trabaho, mag-aalok ng mga gawain, susuriin ang mga resulta, magtatala ng pagkumpleto, at pipiliin kung ano ang susunod na gagawin. Ibig sabihin, pinapagana mo ang sistema upang magdrive sa mga agent, hindi ikaw ang paulit-ulit na magpapahiwatig sa ito. Nagsulat na ako ng kanyang “malapit na kapatid”—agent harness engineering, na ang layunin ay bumuo ng environment para sa isang agent lamang; at factory model, na ang layunin ay bumuo ng isang sistema para sa paggawa ng software. Ang Loop engineering naman ay nasa antas na itaas ng harness. Ito ay tulad ng harness, ngunit gumagana batay sa timer, gumagawa ng mga maliit na asistente, at nakakapag-ugnay sa sarili nito.

Napakalaking pagkakamali na isipin na ito ay hindi na isang isyu sa antas ng kasangkapan. Isang taon ang nakalipas, kung gusto mo ng loop, kailangan mong isulat ang maraming bash script at pangalagaan ang mga iyon nang walang katapusan. Ito ay iyong sariling bagay, at tanging sa iyo lamang. Ngayon, ang mga komponenteng ito ay direkta nang nakabuilt sa produkto. Ang mga kakayahan na listahan ni Steinberger ay maaaring magsabay sa bawat isa sa Codex app, at parehong maaaring magsabay sa Claude Code. Kapag naintindihan mo na ang kanilang anyo ay pareho, hindi na magkakaroon ng pag-aalinlangan kung alin ang gagamitin—kundi magdidisenyo ka ng isang loop: anuman ang tool kung saan ka nakaupo, patuloy itong magpapatakbo.

Limang bahagi, at ilang mga paliwanag

Kailangan ng isang loop ng limang bagay, kasama ang isang lugar para tandaan ang impormasyon. Una kong listahan, tapos i-identify ang bawat isa.

Una, Automations (automated tasks): Triggered ayon sa jadwal, awtomatikong natutuklasan at hinahati.

Ikalawa, Worktrees (mga trabaho): Nagpapahintulot sa dalawang magkakaibang nagtatrabaho na agent na hindi makasagabal sa mga file ng isa't isa.

Ikatlo, Skills (kasanayan): Isulat ang kaalaman sa proyekto upang maiwasan ang paghula ng agent sa bawat pagkakataon.

Ikaapat, Plugins at connectors: Pahintulutan ang agent na makakonekta sa mga tool na iyong ginagamit na kasalukuyan.

Ika-lima, Sub-agents: Isang nagtataguyod ng solusyon, at isa pang nag-uusisa sa solusyon.

At ang ikapitong bagay: memory (memory). Maaari itong isang Markdown file, isang Linear board, o anumang lugar na hiwalay sa isang pag-uusap lamang at nakakapag-save ng mga "natapos na gawain" at "susunod na gawain". Maaaring mukhang simpleng hindi mahalaga, ngunit ito ang parehong teknik na ginagamit ng lahat ng matagal na tumatakbo na mga intelligent agent. Naisulat ko na ito nang detalyado sa long-running agents: ang model ay nakakalimot sa pagitan ng bawat pagpapatakbo, kaya ang memory ay dapat naka-save sa disk, hindi sa konteksto. Makakalimot ang intelligent agent, ngunit hindi ang code repository.

Ngayon, ang dalawang produkto ay may mga bahaging ito ng lima.

May iba-ibang pangalan sila, ngunit ang kanilang kakayahan ay本质上 ay pareho. Ipaipaliwanag ko ito nang isa-isa, dahil sa totoo lang, ang pagkakaroon ng isang loop na tumatakbo nang maayos o naglalaho nang tahimik sa iba't ibang lugar ay nakasalalay sa mga detalye.

Ang mga automation ang nagiging dahilan kung bakit ang loop ay totoo pang loop, at hindi isang isang-time na gawain na iyong ginawa nang manu-manong isang beses. Sa aplikasyon ng Codex, maaari mong lumikha ng isang automation sa tab ng Automations, piliin ang proyekto, ang prompt na gagamitin nito, ang frequency ng pagpapatakbo, at kung ito ay mangyayari sa iyong lokal na checkout o sa background worktree. Ang mga resulta ng pagpapatakbo na nakakatuklas ng mga problema ay papasok sa Triage inbox, habang ang mga pagpapatakbo na walang problema ay awtomatikong i-a-archive — isang magandang bagay. Ginagamit din ito ng OpenAI sa loob para sa ilang makakapagod ngunit kailangang gawain, tulad ng daily issue triage, pagbuo ng summary ng CI failures, pagsulat ng commit briefs, at pagtatakdang mga bug na dinala ng iba noong nakaraang linggo. Maaari rin ng mga automation na tawagan ang skill, kaya maaari mong panatilihin ang mga paulit-ulit na gawain na madaling pangalagaan: i-trigger ang $skill-name, kesa sa pagpapaste ng isang buong pader ng mga instruksyon sa isang plan na hindi na magkakaroon ng update.

Kasalungat na paraan ang Claude Code, ngunit pareho ang epekto: ito ay ginagawa sa pamamagitan ng scheduling at hooks. Maaari mong gamitin ang /loop upang i-run ang isang prompt o command sa regular na interval, o iset up ang isang cron job, o gamitin ang hooks sa ilang mga punto sa buhay ng agent upang i-trigger ang mga shell command. Kung nais mong magpatuloy ito kahit na isara mo ang iyong laptop, maaari mong i-deploy ang buong sistema sa GitHub Actions. Pareho ang ideya: tinutukoy mo ang isang autonomous task, ibinibigay mo sa ito ang isang ritmo, at pinapadala ang mga resulta sa iyo, hindi ikaw ang umaalala sa lahat ng dako.

May isa pang primitibo sa loob ng sesyon na dapat malaman, na mas malapit sa pangunahing paksa ng artikulong ito. Ang /loop ay magpapagana nang paulit-ulit ayon sa ritmo; ang /goal naman ay magpapagana nang patuloy hanggang sa matupad ang isang kondisyon na iyong isinulat. Pagkatapos ng bawat ronda, isang hiwalay na maliit na modelo ang magpapasya kung natapos na ang gawain, kaya ang agent na sumusulat ng code ay hindi ang nagpapasa ng sariling marka. Maaari mong bigyan ito ng isang kondisyon, tulad ng "nagpass lahat ng mga pagsubok sa test/auth at walang error sa lint," at pagkatapos ay umalis. Mayroon din ang Codex sa parehong kakayahan, na tinatawag din itong /goal. Ito ay magpapagana nang patuloy sa pagitan ng mga ronda hanggang sa matupad ang isang makikita at mapapatunayan na kondisyon sa paghinto, at sumusuporta sa pagpapahinga, pagpapatuloy, at paglinis. Parehong primitibo ang may-ari ng dalawang kasangkapan. Ito ay ang pangunahing pattern na paulit-ulit na lumilitaw sa artikulong ito.

Kaya ang Automations ang responsable sa pagpapalabas ng mga gawain. Ang natitirang bahagi ng loop naman ang responsable sa pagproseso ng mga gawain na iyon.

Kapag nagpapatakbo ka ng higit sa isang agent, ang file conflict ay naging punto ng pagkabigo. Ang pagkasulat ng isang file nang sabay-sabay ng dalawang agent ay katulad ng dalawang engineer na nagmodyfik ng iisang linya ng code nang walang komunikasyon. Ang git worktree ay maaaring lutasin ang problema na ito. Ito ay isang hiwalay na working directory sa isang hiwalay na branch, ngunit nagbabahagi ng iisang kasaysayan ng code repository, kaya ang pagbabago ng isang agent ay physically ay hindi makakasalungat sa checkout ng isa pang agent.

Ang Codex ay may built-in na suporta para sa worktree, kaya maaaring magtrabaho nang sabay-sabay ang maraming thread sa iisang repository nang walang pagkakasalungat. Ang Claude Code ay maaari ring gamitin ang git worktree para sa parehong paghihiwalay: maaari mong buksan ang isang session sa isang hiwalay na checkout gamit ang --worktree flag, o itakda ang isolation: worktree sa isang subagent upang makakuha bawat maliit na asistente ng isang bagong checkout at awtomatikong linisin ito pagkatapos. Isinulat ko ang tao aspeto nito sa the orchestration tax: ang mga worktree ay nag-aalis ng mga konflikto sa mechanical level, ngunit ikaw pa rin ang limitasyon. Ang totoong nagdedesisyon kung ilang agent ang maaari mong i-run nang sabay-sabay ay hindi ang mga kasangkapan, kundi ang iyong review bandwidth.

Ang Skill ay isang mekanismo na nagpapahintulot sa iyo na hindi na kailangang ipaliwanag muli ang parehong set ng mga item sa bawat sesyon tulad ng isang isda na may talaan. Pareho ang format ng dalawang tool: isang folder na may isang SKILL.md na naglalaman ng mga paliwanag at metadata; maaari ring mayroong opsyonal na mga script, mga sanggunian, at mga file ng resource. Iiralin ng Codex ang isang skill kapag tinawag mo ito gamit ang $ o /skills, at maaari ring awtomatikong iiralin nito kapag tumutugma ang iyong gawain sa paglalarawan ng skill. Ito ang dahilan kung bakit mas mabuti ang isang maikli at simpleng paglalarawan kaysa sa isang matalino o magandang-look na paglalarawan. Parehong gawaing ito ng Claude Code, at isinulat ko na ang pattern na ito sa agent skills.

Ang mga skill ay ang mga lugar kung saan hindi na ulit-ulitin ang pagkawala ng iyong intensyon. Sa intent debt, sinabi kong ang bawat sesyon ng agent ay nagsisimula mula sa cold start, at kung may blanko sa iyong intensyon, gagamit ito ng sariling malaking pagkakamali upang punan ang mga ito. Ang skill ay ang pagpapalabas ng ganitong intensyon: mga pagsang-ayon sa proyekto, mga hakbang sa pagbuo, “Hindi natin ginagawa ito dahil nangyari na ang aksidente na iyon,” at iba pa, isang beses lamang isusulat sa isang lugar na babasahin ng agent bawat beses ito ay iiralin. Walang skills, ang bawat loop ay kailangang muling i-derive ang buong proyekto mula sa zero; may skills, parang may compound interest na nagpapalago.

May isang bagay na kailangang malinaw: ang skill ay ang pagsusulat ng format, habang ang plugin ay ang paraan ng pagpapamahagi. Kapag nais mong i-share ang isang skill sa maraming code repository, o i-package ang ilang skill nang magkasama, isasama mo sila bilang isang plugin. Ganito rin ang Codex at Claude Code.

Isang loop na nagpapakita lamang ng file system ay isang maliit na loop. Ang mga connector ay binubuo batay sa MCP, na nagpapahintulot sa mga agent na basahin ang iyong issue tracker, i-query ang database, i-call ang staging API, o magpadala ng mensahe sa Slack. Ang Codex at Claude Code ay may suporta para sa MCP, kaya ang isang connector na isinulat mo para sa isa sa kanila, karaniwang maaaring gamitin din sa isa pa. Ang mga plugin naman ay nagpapakita ng mga connector at skills upang ang iyong mga kasamahan ay maaaring i-install ang buong konfigurasyon nang isang beses, imbes na subukan na muling gawin ang lahat batay sa alaala.

Ito ang pagkakaiba sa pagitan ng «isang agent na sabi sa iyo na 'ito ang solusyon'» at «isang loop na buksan ang sarili nito na PR, i-ugnay ang Linear ticket, at i-notify ang channel pagkatapos umabot sa CI». Mahalaga ang Connectors dahil pinapahintulutan nila ang loop na gumawa sa iyong tunay na kapaligiran, hindi lang sabihin sa iyo na 'kung maaari kong gawin, gagawin ko ito'.

Sa isang loop, ang pinakamalaking estructural na disenyo ay ang paghihiwalay ng “nagsusulat” at “nagsusuri”. Madaling maging sobrang mapagpatawad ang modelo na nagsusulat ng code kapag sinusuri nito ang sarili nitong gawain. Ang isang iba’t ibang agent na may iba’t ibang utos, minsan ay gumagamit ng iba’t ibang modelo, ay makakatanggap ng mga problema na pinag-iisipan ng unang agent pagkatapos ng sarili nitong pagsasabing tama.

Ang Codex ay gagawa ng subagents lamang kapag hiniling mo, at magpapatakbo sila nang paralelo bago isama ang mga resulta sa isang sagot. Maaari mong tukuyin ang sarili mong agents gamit ang TOML files sa .codex/agents/: bawat agent ay may pangalan, deskripsyon, mga utos, at opsyonal na modelo at lakas ng pag-iisip. Kaya, maaaring maging isang malakas na modelo na may mataas na lakas ng pag-iisip ang iyong tagapagsuri ng kaligtasan, habang ang iyong tagapag-eksplor ay maaaring isang mabilis, maliit na modelo na maaaring basahin lamang. Ang Claude Code ay may katulad na kakayahan sa pamamagitan ng mga subagents at mga team ng agent sa .claude/agents/, na nagpapahintulot sa maraming agent na ipasa ang kanilang trabaho sa isa't isa. Ang pinakakaraniwang paghahati ng trabaho sa parehong sistema ay: isang agent na nagpapalawak, isang agent na nagpapatupad, at isang agent na tumitingin sa pagkakatugma sa mga spesipikasyon.

Dalawang beses ko nang ipinahayag ang pananaw na ito: isa sa code agent orchestra, at isa pa sa adversarial code review. Mahalaga ito lalo na sa loop, dahil ang loop ay magpapatakbo nang walang iyong pagmamasid, kaya ang isang verifier na talagang tiwalaan mo ay ang iisang dahilan kung bakit makakalabas ka. Ang mga subagent ay talagang gumagamit ng mas maraming token, dahil bawat agent ay gumagawa ng sariling model call at tool call, kaya dapat mong gamitin sila sa mga lugar kung saan ang pangalawang opinyon ay worth ang bayad. Ito rin ang ginagawa ng /goal ng Claude Code sa ilalim: ginagawa ng isang bagong model kung natapos na ang loop, hindi ang model na nagawa ang trabaho. Ibig sabihin nito, inilalapat nito ang paghihiwalay ng “tagapaglikha” at “tagapag-verify” sa sariling kondisyon ng paghinto.

Ano ang hitsura ng isang loop

Isama ang lahat ng mga ito, at isang hiwalay na thread ay magiging isang maliit na control panel. Ito ang isang struktura na madalas kong ginagamit.

Bawat umaga, isang automation ang tumatakbo sa code repository. Ang prompt nito ay tumatawag sa isang triage skill na bumabasa sa mga CI failure noong kahapon, mga bukas na issues, at mga kamakailang commits, at isinusulat ang mga natuklasan sa isang Markdown file o Linear board. Para sa bawat isyu na值得处理, buksan ang isang isolated worktree, ipinapadala ang isang sub-agent upang maglikha ng isang draft ng solusyon, at pagkatapos ay ipinapadala ang ikalawang sub-agent upang suriin ang solusyon batay sa project skills at mga umiiral na pagsubok.

Ang mga connector ay nagpapagana ng loop upang buksan ang PR at i-update ang ticket nang sarili nito. Ang anumang bagay na hindi kayang handle ng loop ay papasok sa triage inbox para sa aking pagtratamento. Ang state file ay ang punglo ng buong sistema: ito ay nagtatala kung ano ang naranasan, kung ano ang nakapasa, at kung ano ang naiwan pa. Kaya, ang pagpapatakbo sa susunod na umaga ay magsisimula mula sa lugar kung saan itinigil ngayon.

Tandaan kung ano ang tunay mong ginawa. Nagdisen mo lang isang beses. Ang mga hakbang na iyon ay hindi mo pinrompt nang isa-isa. Ito ang real-world na bersyon ng pahayag ni Steinberger. At ang parehong loop ay maaaring tumakbo sa Codex o sa Claude Code, dahil ang mga komponente ay parehong mga komponente.

Hindi pa rin gagawin ng Loop ang anumang bagay para sa iyo

Binalik ang paraan ng paggawa ng Loop, ngunit hindi ito tinanggal sa iyo mula sa trabaho. Sa katotohanan, habang lumalakas ang loop, may tatlong problema na naging mas malalim, hindi mas madali.

Ang pag-verify ay naka-isa pa rin sa iyo. Isang loop na tumatakbo nang walang pagmamasid ay maaari ring magkamali nang walang pagmamasid. Ang dahilan kung bakit hinati mo ang verifier sub-agent at ang maker ay upang maging may-kahulugan ang pagsasabi ng loop na “nagtapos na.” Kahit pa man, ang “nagtapos” ay isang paghahayag, hindi isang patunay. Patuloy kong paulit-ulit ang parehong pangungusap sa code review in the age of AI: Ang iyong tungkulin ay magbigay ng code na iyong pinatotohanang epektibo.

Kung iiwanan mo ito sa sarili mong pag-unawa, ito ay magiging basura. Mas mabilis ang loop na ipapadala sa iyo ang code na hindi ikaw ang sumulat, mas malaki ang pagkakaiba sa pagitan ng ano ang iyong nauunawaan at ano ang totoo sa sistema. Ito ay tinatawag na comprehension debt (pag-unawa ng utang). Kung hindi mo binabasa ang mga produkto ng loop, ang isang malinis na loop ay magpapabilis lang sa paglalago ng utang na ito.

Atbp., oo, ang pinakakomportableng posisyon ay malamang ang pinakamapanganib. Kapag nagpapatakbo na ang loop, madali kang huminto sa pagbuo ng iyong sariling pagpapasya at tanggapin lamang anumang ibinabalik nito. Tinatawag kong cognitive surrender (cognitive surrender) ito. Kung nagdisenyo ka ng loop na may paghuhusga, ito ang gamot; kung nagdisenyo ka ng loop para lamang iwasan ang pag-iisip, ito ang pagpapabilis. Parehong kilos, magkakaibang resulta.

Buuin ang loop, ngunit patuloy na maging inhinyero

Naniniwala ako na ito ay nagpapakita ng direksyon ng aming pag-unlad sa trabaho sa hinaharap. Gayunpaman, kung hindi ko sariling ialis ang code o lubos na umaasa sa automated loop para i-fix ang code, masasaktan ang kalidad ng aking produkto. Malaki ang posibilidad na makakasali ako sa isang pagsabog na pababa: patuloy na maghuhukay sa sarili ko sa mas malalim na liblib.

Kaya mo naman gawin ang sarili mong loop, ngunit huwag kalimutan na ang direkta na pagpapahiwatig sa iyong intelligent agent ay patuloy na epektibo. Ang susi ay ang paghahanap ng tamang balanse.

Ang resulta ng Loop ay magkakaiba-iba para sa bawat tao. Maaaring magbuo ng dalawang tao ng ganap na magkaparehong loop, ngunit makakuha ng kabaligtarang resulta. Isang tao ay ginagamit ito upang mabilis ang trabaho na lubos niyang nauunawaan; ang isa pa ay ginagamit ito upang iwasan ang pag-unawa sa trabaho mismo. Hindi alam ng Loop ang pagkakaiba sa pagitan ng dalawa. Ikaw ang alam.

Ito ang dahilan kung bakit mas mahirap ang loop design kaysa sa prompt engineering, hindi mas madali. Hindi ibig sabihin ni Cherny na mas magiging madali ang trabaho, kundi na ang leverage point ay naglipat.

Bumuo ng loop. Pero gawin ito tulad ng isang tao na patuloy pa ring naghahangad na maging inhinyero, hindi tulad ng isang tao na lamang responsable sa pagpindot ng pindutang 'simulan'.

[Original link]

Klik para malaman ang mga posisyon na hinahanap ng BlockBeats

Maligayang pagdating sa opisyal na komunidad ng律动 BlockBeats:

Telegram subscription group: https://t.me/theblockbeats

Telegram group: https://t.me/BlockBeats_App

Twitter official account: https://twitter.com/BlockBeatsAsia