Noong Hulyo 2026, naranasan ng larangan ng AI programming ang malaking pagbabago. Ipinahayag ni Peter Steinberger sa platform na X ang pagtatapos ng panahon ng cyclic engineering, na nagdudulot ng paglipat ng industriya patungo sa graph engineering. Ang cyclic engineering, na nagmula sa Ralph method ni Geoffrey Huntley, ay naglalayong iwasan ang mga limitasyon ng context window sa pamamagitan ng pagpapagana ng AI Agent nang tuloy-tuloy hanggang makamit ang layunin. Noong Abril hanggang Mayo 2026, sinundan ng mga kasangkapan tulad ng Codex at Claude Code ang paglalabas ng tampok na Goal, na nagpapakita ng produktong naging realisado. Kasalukuyang sinusuri ng industriya ang mas kumplikadong graph engineering, na nagsasangkot ng koordinadong disenyo ng organizational graphs at workflow graphs.

May-akda at pinagmulan: WeChat Official Account InfoQ (ID: infoqchina)

Nagpapalitan pa ba tayo ng cycle, o nagsilip na tayo sa graph?

Noong Hulyo 18, 2026, ipinahayag ni Peter Steinberger sa platform na X ang pagtatapos ng erang circular engineering sa isang pangungusap lamang. Nakakuha ang post ng 2.6 milyong views sa loob ng dalawang araw mula sa pagpapalabas nito.

Bago ang anim na linggo, kumita siya ng 8.4 milyong pagtingin gamit ang “designing loops that prompt agents,” na nagpapakita sa mga developer sa buong mundo na ang panahon ng prompt engineering ay umuunlad, at ang loop engineering ang bagong direksyon.

Dalawang post, na may kabuuang pagtingin na higit sa 11 milyon, ay nagdala sa pinakamalaking diskusyon sa larangan ng AI programming sa susunod na yugto.

Ang pag-usbong ng siklo

Sa nakaraang buwan, ang “Loop Engineering” ay mabilis na naging isang sikat na konsepto sa larangan ng AI programming.

Ngunit ang totoong pinagmulan nito ay maaaring itala sa isang taon ang nakalipas. Noong Hulyo 2025, ang software engineer na si Geoffrey Huntley ay nagmungkahi ng isang paraan na tinawag niyang “Ralph”—isang simpleng Bash loop na nagpapakita sa Claude na paulit-ulit na gawin ang isang gawain hanggang maabot ang layunin:

habang :; do cat PROMPT.md | claude-code ; done

Ang core ng Ralph method ay ang pag-iwas sa limitasyon ng context window. Noong gitna ng 2025, ang pinakamalaking context window ay 200,000 Token. Ito ay lubos na sapat para sa mas kumplikadong mga gawain, kaya kailangang hatiin ang pagpapatakbo ng Agent sa mas maliit na mga yunit, at pagkatapos ay ipatakbo ang bawat isa nang hiwalay.

Sa ilalim ng kontekstong ito, ang paraan ng paggana ng Ralph ay sumusunod:

• Itakda ang isang layunin para sa proyekto, pagkatapos ay patuloy o muli pang i-run ang Agent hanggang maabot ang layunin.
• I-save ang naitatapos na trabaho sa file system sa anyong “compressed”, tulad ng pag-save bilang log o updated na plan.
• Gamitin ang bagong konteksto upang magsimula ang Agent, upang mabawasan ang "context corruption".
• Sa kailangan, payagan ang bawat Agent na magdagdag o baguhin ang “Pangkalahatang Plan”.

Ginawa ni Huntley ang isang programming language mula sa zero gamit ang paraang ito, at pinatunayan ang kanyang kakayahang magamit. Ngunit hanggang sa lumabas ang mas malakas na model, hindi ito mabilis na naging sikat sa komunidad ng mga developer.

Ang pagkakaroon ng tagumpay ng Loop ay hindi makakalimot sa ilang pangunahing developer ng Anthropic at OpenAI. Noong unang panahon sa developer conference ng Anthropic, si Boris Cherny, ang tagalikha ng Claude Code, ay nagsabi: “Hindi na ako nagpapahiwatig kay Claude. Ginagana ko ang ilang loop, at ang mga loop na ito ang nagpapahiwatig kay Claude at nagpapasya kung ano ang susunod na gagawin. Ang aking trabaho ay pagsusulat ng mga loop.”

Pagkatapos, nag-post din si Peter Steinberger na hilingin sa mga developer na tumigil sa pagpapahiwatig nang direkta sa programming Agent: “Bawat buwan na paalala: Hindi mo na dapat pansinin ang programming Agent nang direkta. Dapat mong disenyo ang isang loop na makakapagpapahiwatig sa Agent.”

Ang dating inhinyero ng Google na si Addy Osmani ay sumulat ng isang artikulo na may pamagat na “Loop Engineering,” kung saan inilalarawan ito bilang: “Ang loop engineering ay ang pagpapalabas ng sarili mula sa posisyon ng pagpapahiwatig ng Agent nang direkta, at pagbuo ng isang sistema na gagawin ang bagay na iyon para sa iyo.”

May konsepto na, may pangalan na, at mabilis na sumunod ang imprastruktura.

Noong Abril hanggang Mayo 2026, ang Codex, Claude Code, at Hermes ay naglabas ng utos na /goal, na nagpapalit sa mga manu-manong loop sa isang solong utos.

Animang anim na buwan pagkatapos ng mas malawakang paggamit ni Ralph, naglabas ang Codex ng function na goal

Isinusulat ng dokumentasyon ng Codex: "Ang Goals ay mga pangmatagalang layunin sa Codex na nagpapahintulot sa isang serye ng talakayan na magpatuloy patungo sa isang malinaw na resulta sa loob ng maraming pagkakataon. Ang Goal ay nagbibigay sa Codex ng isang kondisyon para sa pagkumpleto: anong estado ang dapat umiiral, paano isusuri kung tagumpay, at anong mga limitasyon ang dapat laging ipanatili."

Ang dokumento ay partikular na nagtutukoy: "Ang pangkaraniwang prompt ay nagsasabing: Gawin ang sumusunod na gawain. Ang Goal ay nagsasabing: Magpatuloy sa paggawa, hanggang sa maging totoo ang resulta."

Sa karaniwang kahilingan, gagawin ng Codex ang kasalukuyang utos, isasampa ang resulta, at maghihintay ng susunod na hakbang. Habang ginagamit ang Goal, may nakadikit na patuloy na layunin sa thread. Pagkatapos ng isang round ng pagsasagawa, maaari itong suriin ang kasalukuyang ebidensya at matukoy kung natapos na ang layunin. Kung ang sagot ay hindi, at patuloy pa ang Goal at hindi pa nawala ang budget, maaari ang Codex na magpatuloy sa paggawa mula sa pinakabagong estado.

Halimbawa: “Bawasan ang p95 latency sa checkout benchmark sa ilalim ng 120 na millisecond habang pinapanatili na laging nakakapasa ang test suite.”

Isang sapat na malinaw na “pamantayan sa pagtatapos” na maaaring ibigay sa Agent. Pagkatapos, gagawin ng Agent ang paghahati-hati ng gawain, paglikha ng mga sub-Agent, at magpapatuloy sa pagpapatakbo hanggang matapos ang trabaho. Ang koponan ng Codex ay nagsanay sa ideya ng Ralph Cycle at dito ay binuo ang imprastruktura: pagpapagana ng maraming Agent, pag-iwas sa kanilang pagkakainggitan; pagpapamahala ng estado; pagpapatakbo ng mga pagsubok; pagpapagsimula at pagpapahinto sa mga Agent; at pagkatapos ay idinagdag ang mga tampok tulad ng pagtatakda ng budget.

Arkitektura ng mga tampok na Mga Layunin

Paano gamitin ng developer ang loop

Ano nga ba ang ginagawa ng developer sa loop? Ayon sa feedback ng komunidad, ang pinakakaraniwang escenario ay ang pagproseso ng ilang periodic na gawain.

Ngunit ang kakayahan sa pag-loop ay higit pa rito. Ang tunay na pagpapakita ng halaga ng cycle engineering ay ang ilang mas kumplikadong, matagalang gawain na nangangailangan ng patuloy na iterasyon.

Halimbawa, ang pagkumpleto ng malawakang pagmigrasyon ng code. Kailangan ni Rafel Mendiola, ang founder ng startup, i-convert ang isang React application patungo sa React Native. Ang tradisyonal na paraan ay ang paglikha ng isang malaking Epic, paghahati-hati nito sa 50 hanggang 100 tickets, at ang pagbuo ng infrastructure ay nagiging nakakatakot na.

Ang kanyang alternatibo ay ang paglikha ng isang Skill na magpapahintulot sa Agent na sarili niyang makikilala ang mga code block na maaaring i-migrate, matapos ay makumpleto ang pagkonbersyon at masubaybayan ang progreso, at pagkatapos ay ilagay ang Skill sa isang Cron job na tumatakbo bawat 30 minuto. Kumpara sa pagpapamahala ng isang malaking migration plan, mas madali ito sa kognitibong aspeto.

Susunod na istasyon: Graph

Ang problema sa tweet ni Peter ay tumutukoy sa isang evolusyonaryong landas.

Isang taon ang nakalipas, ang prompt engineering ay isang pangunahing kasanayan. Noong 2025 hanggang sa simula ng 2026, ang pagkakasentro ay napalitan ng pagdidisenyo ng loop. Ngayon, ang direksyon ni Peter ay mas malayo pa: pagdidisenyo ng mga graph na binubuo ng maraming loop—bawat Agent ay nagpapatakbo ng sarili nitong loop, na nagkakaugnay sa pamamagitan ng mga pagkakadepende.

Ang pinakamagandang komento sa thread ng tweet na ito ay mula kay Luis Catacora: “May malaking tolerance sa loop. Ang diagram ay magpupukaw sa iyo na tanggapin kung gaano karaming bahagi ng workflow ay hindi pa talaga na-model.”

Nakikita dito ang pagkakaiba ng dalawang paraan. Ang pag-uulit ay nagpapahintulot sa iyo na ipagpaliban ang disenyo ng arkitektura: unahin ang pagbibigay ng lahat ng gawain sa isang Agent hanggang sa hindi na ito makapag-handle. Ang grap naman ay nangangailangan ng pagsasabi ng buong istruktura muna—sino ang responsable sa anumang bagay, alin ang mga gawain na nakadepende sa iba, at ano ang gagawin kung nabigo ang isang sangay. Ang pag-uulit ay pagpapaliban sa desisyon, habang ang grap ay nagpapasya nang maaga.

Si Shubham Saboo, senior AI product manager sa Google at may-akda ng Awesome LLM Apps repository (na may higit sa 124,000 stars sa GitHub), ay nagbigay ng isa pang pagkakahati: tinukoy niya ang dalawang antas: "ang organizational map ay nagtataglay ng mga kahulugan kung sino ang responsable sa bawat larangan at nagpapanatili ng konteksto; samantalang ang work map ay nagtatakda kung ano ang kailangang gawin sa kasalukuyan, at maaaring hiwain, i-merge, i-reorder, o mawala nang direkta batay sa ebidensya."

Ano ba talaga ang Graph?

Ang Loop ay nagiging programmable ang pag-uugali ng Agent. Ang Graph ay nagiging programmable ang organisasyon ng Agent.

Ang susunod na hakbang ay ang dinamikong organisasyon ng Agent: habang isinasagawa ang gawain, babaguhin ng Graph ang sariling istruktura.

Preston Holmes: May dalawang uri ng Graph na mahalaga. Ang una ay ang Graph na ipinakikita mo sa iyong larawan, na binubuo ng mga matagal nang umiiral na Agent na nagsisilbing区域联防, bawat isa ay responsable sa isang rehiyon. Ang pangalawa ay ang Graph na nabubuo ng mga gawain na kailangang tapusin. Ito ay dinamiko at patuloy na nagbabago.

Shubham Saboo: Ang matagal nang umiiral na “organizational map” ang nagdedesisyon kung sino ang responsable sa bawat rehiyon at responsable sa pagpapanatili ng konteksto. Ang “work map” ang nagdedesisyon kung ano ang mga gawain na kailangang matapos sa kasalukuyan. Habang lumalabas ang mga bagong ebidensya, maaari itong hatiin, i-merge, muling ayusin, o mawala nang direkta.

Ito ang susi sa production-grade na multi-Agent system: may dalawang grap na nagpapatakbo nang sabay-sabay.

Organizational Graph (Org Graph): Tukoy ang “sino ang responsable sa ano”. Ito ay binubuo ng mga matatag na Agent, kung saan bawat Agent ay responsable sa isang tiyak na larangan, at nagtataglay ng konteksto, propesyonal na kakayahan, at mga pahintulot sa mga kasangkapan sa larangang iyon. Ang organizational graph ay relatibong matatag, katulad ng organisasyon ng isang kumpanya.

Work Graph: Tukoy ang “ano ang dapat gawin ngayon at paano maaaring mag-flow ang mga gawain”. Ito ay patuloy na nagbabago kasama ang mga gawain at bagong ebidensya, at maaaring hiwain, i-merge, i-adjust ang pagkakasunod-sunod, o direktang kanselahin. Ang Work Graph ay mas katulad ng real-time na nabubuo na proyektong plano.

Si Preston Holmes ay naniniwala din na mahalaga ang dalawang mga graph, at nagpapatakbo sila sa iba’t ibang panahon. Ang organizational graph ay iinasikaso at i-deploy sa harap; ang working graph naman ay dinamikong nililikha para sa bawat gawain at tinatanggal pagkatapos ng gawain.

Kung ang siklo ang nagiging dahilan kung bakit ang pag-uugali ng Agent ay maaaring i-program, ang grap ay nagiging dahilan kung bakit ang organisasyon ng Agent ay maaaring i-program. Ang susunod na hakbang ay ang dinamikong organisasyon ng Agent—habang nagpapatupad ng gawain, ang grap ay magsasagawa ng sariling pagbabago sa istruktura nito.

Mula sa paggawa ng mabuting Prompt, hanggang sa pagdisenyo ng Loop, at pagbuo ng Graph, ang pagkakasentro ng kakayahan ng AI sa pag-program ay patuloy na umuunlad. Lalong kailangan ng mga developer na isipin kung paano disenyo ang mga estruktura ng pakikipag-ugnayan sa pagitan ng mga Agent, at hindi na kailangang mag-alala kung paano makipag-usap sa isang Agent lamang.