Codex at multi-agent na daloy ng trabaho: makipagtulungan sa mga ahente nang hindi nawawala ang kontrol

spinny:~/writing $ vim codex-multi-agent-workflows.md

1~
2Sa unang pagkakataon na ang isang ahente ng coding ay aktwal na nag-aayos ng isang bug para sa iyo, ang reaksyon ay halos palaging pareho: isang pinaghalong sigasig at hinala. Maganda, sigurado. Ngunit pagkatapos ay tumingin ka sa diff at tanungin ang iyong sarili: "Ok, ngunit ano ang eksaktong hinawakan niya? Mapagkakatiwalaan ko ba siya? Gagawin ba niya ito muli sa parehong paraan bukas?".
3~
4Doon na yata magsisimula ang kawili-wiling bahagi. Hindi kapag ang ahente ay nagsusulat ng isang function, ngunit kapag ito ay naging sapat na may kakayahan upang gawin ang buong gawain: basahin ang repositoryo, gumawa ng patch, magpatakbo ng mga pagsubok, magbukas ng PR, bumalik pagkatapos ng komento sa pagsusuri. Eksaktong gumagalaw ang Codex sa direksyong iyon: background work, hiwalay na worktree, integrated browser, automation, plugin, memory at mas tahasang mga kontrol sa pahintulot.
5~
6Ang punto ay hindi isipin ang isang hinaharap kung saan wala nang nagbabasa ng code. Ito ay magiging isang kahila-hilakbot na hinaharap, pati na rin medyo walang muwang. Ang punto ay upang malaman kung paano makipagtulungan sa mga ahente na maaaring gumawa ng maraming nang hindi pinapayagan silang gawin ang lahat.
7~
8## Ang pagbabago ng ugali
9~
10Gamit ang tradisyunal na autocomplete palagi kang nasa gulong. Nagmungkahi ang AI ng isang linya, nagpasya ka. Sa isang ahente, gayunpaman, nagbabago ang relasyon: binibigyan mo siya ng layunin at dumaan siya sa maraming hakbang nang mag-isa.
11~
12Ito ay makapangyarihan, ngunit binabago nito ang problema. Ang tanong ay hindi na lang "pwede ba ang model program?". Ang tanong ay nagiging:
13~
14- Binigyan ko ba siya ng maliit na saklaw?
15- alam mo ba kung paano suriin ang resulta?
16- Nagtatrabaho ba ako sa isang nakahiwalay na kapaligiran?
17- Makatao at maingat pa rin ba ang huling pagsusuri?
18~
19Ang isang malusog na daloy ng trabaho ay mas mukhang ganito kaysa sa isang magic wand:
20~
21```mermaid
22flowchart LR
23    Idea[Gawain ng tao] --> Scope[Maliit, nabe-verify na layunin]
24    Scope --> Agent[Ahente sa worktree nakahiwalay]
25    Agent --> Checks[Subukan, lint, build, browser]
26    Checks --> Review[Pagsusuri ng tao]
27    Review --> Merge[Pagsamahin o bagong pag-ulit]
28    Review --> Iterate[Tumpak na mga komento sa diff]
29    Iterate --> Agent
30```
31~
32Mukhang hindi gaanong romantiko kaysa sa "ginagawa ng ahente ang lahat", ngunit mas mahusay itong gumagana. At ito rin kung paano gumagana ang mga team na mahusay sa mga tao: malinaw na gawain, mabilis na feedback, tahasang pananagutan.
33~
34## Ang magandang prompt ay halos isang magandang tiket
35~
36Ang pinaka-mapanganib na prompt ay ang malabo ngunit may kumpiyansa: "ayusin ang pahina ng mga invoice", "pahusayin ang arkitektura", "linisin ang module ng auth." Ito ay mga kahilingan na mukhang produktibo at bumubuo ng malalaking pagkakaiba. Ngunit pagkatapos ay nakita mo ang iyong sarili na gumagawa ng arkeolohiya.
37~
38Ang isang kapaki-pakinabang na prompt ay mas nakakabagot. Halimbawa: ipatupad ang pag-export ng CSV para sa page ng mga invoice, alam na ang talahanayan ay nasa `app/(dashboard)/invoices/page.tsx`, ang mga query ay nasa `src/server/invoices.ts` at mayroon nang katulad na pattern sa `app/(dashboard)/reports`.
39~
40Pagkatapos ay magdagdag ng malinaw na mga hadlang: huwag baguhin ang database schema, huwag magdagdag ng mga dependency kung sapat na ang isang maliit na utility, panatilihin ang umiiral na istilo ng UI. At isara sa pag-verify: `npm test -- invoices` at `npm run build`.
41~
42Ang ganitong uri ng maikling ay hindi para "ipaliwanag nang mas mahusay sa AI". Ito ay nagsisilbi higit sa lahat upang gawing mas malinaw sa iyo kung ano ang iyong itinalaga. Kung hindi mo maisulat ito ng konkreto, marahil ang gawain ay hindi pa handa para sa isang ahente.
43~
44## Tatlong trabaho na kusang-loob kong italaga
45~
46Ang una ay paulit-ulit ngunit nabe-verify na trabaho: pagdaragdag ng mga pagsubok, paglilipat ng mga tawag sa isang bagong panloob na API, pag-update ng mga pag-import, pagpapalit ng mga hindi na ginagamit na bahagi, pag-aayos ng mga error sa TypeScript. Dito ang ahente ay makakatipid ng oras at ang panganib ay nakokontrol.
47~
48Ang pangalawa ay gawaing eksplorasyon: "hanapin kung saan kinakalkula ang kabuuang ito", "ipaliwanag sa akin kung bakit marupok ang pagsubok na ito", "paramihin ang bug at sabihin sa akin kung aling mga file ang tila apektado". Kahit na hindi ito gumagawa ng isang patch kaagad, maaari itong gumawa ng kapaki-pakinabang na reconnaissance.
49~
50Ang ikatlo ay ang umuulit na gawain sa pagpapanatili: maliit na pag-update ng dependency, paglilinis ng mga lumang feature na flag, buod ng mga naka-block na PR, pagsuri sa mga nakalimutang TODO. Hindi ito kaakit-akit, ngunit ito mismo ang uri ng trabaho na may posibilidad na tumambak.
51~
52## Tatlong trabaho na pinapanatili kong tao
53~
54Ang mga desisyon sa produkto ay nananatiling tao. Kung binago ng isang pagbabago kung paano nagbabayad, nagde-delete ng data, nakakakita ng mga presyo, o nakakaunawa ng pahintulot ang isang user, gusto ko ng responsableng tao.
55~
56Ang mga hangganan ng seguridad ay nararapat ding pansinin ng tao: auth, mga tungkulin, mga token, sensitibong pag-log ng data, paglilipat ng database. Ang isang ahente ay maaaring makatulong sa pagpapatupad, ngunit hindi kailangang maging ang tanging gumagawa ng desisyon.
57~
58Sa wakas, pinapanatili ko ang lahat na nangangailangan ng panlasa ng arkitektura ng tao. Ang isang ahente ay maaaring magmungkahi ng isang refactor, ngunit ang pag-unawa kung ang isang abstraction ay talagang kailangan o kung kami ay nagpapakinis lamang ng isang hindi umiiral na problema ay nananatiling isang trabaho.
59~
60## Ang pagsusuri ay hindi opsyonal
61~
62Ang tukso, kapag magaling ang isang ahente, ay magtiwala sa berde ng CI. Naiintindihan naman. Ito rin ay kapag nagsimula ang mga problema.
63~
64Palagi akong tumitingin sa hindi bababa sa limang bagay:
65~
661. Niresolba lang ba ng patch ang hiniling na gawain?
672. Hinawakan ba niya ang mga file na walang kinalaman dito?
683. Sinasaklaw ba ng mga pagsusulit ang bagong pag-uugali o isang masayang pagkakataon lamang?
694. Sinusunod ba ng code ang mga lokal na pattern?
705. Ang mga error ba ay pinangangasiwaan tulad ng sa natitirang bahagi ng proyekto?
71~
72Kapag may mali, kailangang tiyak ang feedback. "Ayusin mo" ay tamad. Mas mabuti: ang utility na ito ay duplicate ang `parseMoney` sa `src/lib/money.ts`; muling gamitin ang function na iyon, magdagdag ng pagsubok para sa kaso ng EUR at huwag baguhin ang pampublikong API ng module ng pagsingil.
73~
74Mas mahusay na tumugon ang mga ahente sa maliliit, nabe-verify na komento. Nakakapagtaka, ganoon din ang mga tao.
75~
76## Ang mga guardrail ay nagkakahalaga ng pagsisikap
77~
78Kung ang isang ahente ay maaaring magbasa ng mga file, magsulat ng code, at magsagawa ng mga utos, dapat itong ituring bilang isang makapangyarihang proseso. Hindi na kailangan ng paranoia, kailangan mo ng kalinisan.
79~
80Gumamit ng hiwalay na worktrees o sanga. Para maihambing mo ang pagkakaiba, itapon ang mga nabigong eksperimento, at huwag ihalo ang trabaho ng ahente sa iyong ginagawa.
81~
82Limitahan ang mga pahintulot. Ang mga utos tulad ng `rg`, `git diff`, `npm test` at `npm run build` ay maaaring maging libre. Ang mga deployment, paglilipat ng database, pag-access sa mga lihim at mapanirang utos ay dapat manatiling tahasan.
83~
84Bawasan ang access sa network kapag hindi mo ito kailangan. Para sa maraming gawain, sapat na ang opisyal na dokumentasyon, pagpapatala ng package at mga partikular na panloob na serbisyo. Mas kaunting lugar sa ibabaw, mas kaunting mga sorpresa.
85~
86Subaybayan ang mga aksyon. Kapag dumating ang isang patch sa pagsusuri, dapat ay magagawa mong muling buuin ang mga senyas, naisagawa ang mga utos, naipasa ang mga pagsubok at binago ang mga file. Hindi para lumikha ng burukrasya, ngunit upang maunawaan kung ano ang nangyari kung may mali.
87~
88## Isang madaling paraan upang makapagsimula bilang isang koponan
89~
90Kung magpapakilala ako ng mga ahente sa isang maliit na koponan, magsisimula ako nang walang malalaking rebolusyon.
91~
92Gagawa ako ng label na `agent-ready` para sa mga isyu na may malinaw na saklaw. Magdaragdag ako ng isang template na may konteksto, mga hadlang at mga utos sa pag-verify. Hihilingin ko ang maliit na PR, mas mabuti sa ilalim ng ilang daang linya. Mangangailangan ako ng pagsubok o mga screenshot para sa mga nakikitang pagbabago. At higit sa lahat ay pananatilihin kong responsable ang isang tao sa pagsasanib.
93~
94Pagkatapos ng dalawang linggo, titingnan ko ang data: kung aling mga gawain ang talagang pinabilis, kung aling mga pagsusuri ang mabigat, kung aling mga senyas ang nakalilito, kung aling mga bahagi ng codebase ang masyadong marupok upang italaga.
95~
96Ito ay isang hindi gaanong kamangha-manghang diskarte kaysa sa "mula ngayon gagawin namin ang lahat kasama ang mga ahente", ngunit ito ang nagbibigay-daan sa iyo na makarating sa ikatlong linggo nang walang pagsisisi.
97~
98## Ang pinaka-pantaong bahagi
99~
100Ang nakakatuwang bagay ay kapag mas nagiging mga autonomous na ahente, mas nagiging mahalaga muli ang mga klasikong kasanayan: pagsulat ng magandang tiket, paggawa ng maliliit na pagbawas, paggawa ng mga pagsusulit, pagbabasa ng mga pagkakaiba, pakikipag-ugnayan sa mga trade-off. Pinapabilis ng ahente ang mga marunong nang magtrabaho nang maayos. Pinapalakas din nito ang kaguluhan ng mga taong hindi maganda ang delegasyon.
101~
102Kaya hindi, hindi ko nakikita ang mga multi-agent na daloy ng trabaho bilang isang shortcut upang ihinto ang paggawa ng engineering. Nakikita ko ang mga ito bilang isang paraan upang ilipat ang mas maraming enerhiya sa mga bahaging mahalaga: pagpapasya kung ano ang itatayo, pagtiyak na gumagana ito, pagpapanatiling naiintindihan ng system.
103~
104Ang mga ahente ay maaaring gumawa ng mahusay na hindi magkakasabay na mga kasamahan. Ngunit ang isang asynchronous na kasamahan, upang maging kapaki-pakinabang, ay nangangailangan ng konteksto, mga hangganan at pagsusuri. Katulad ng iba.
105~
106## Mga kapaki-pakinabang na mapagkukunan
107~
108- [Codex para sa (halos) lahat - OpenAI](https://openai.com/index/codex-for-almost-everything/)
109- [Ligtas na pinapatakbo ang Codex sa OpenAI](https://openai.com/index/running-codex-safely/)
110- [Ipinapakilala ang Codex - OpenAI](https://openai.com/index/introducing-codex/)
111- [Ano ang bago sa GitHub Copilot coding agent](https://github.blog/ai-and-ml/github-copilot/whats-new-with-github-copilot-coding-agent/)
112~

NORMAL · codex-multi-agent-workflows.md [readonly]112 lines · :q to close

2Sa unang pagkakataon na ang isang ahente ng coding ay aktwal na nag-aayos ng isang bug para sa iyo, ang reaksyon ay halos palaging pareho: isang pinaghalong sigasig at hinala. Maganda, sigurado. Ngunit pagkatapos ay tumingin ka sa diff at tanungin ang iyong sarili: "Ok, ngunit ano ang eksaktong hinawakan niya? Mapagkakatiwalaan ko ba siya? Gagawin ba niya ito muli sa parehong paraan bukas?".

4Doon na yata magsisimula ang kawili-wiling bahagi. Hindi kapag ang ahente ay nagsusulat ng isang function, ngunit kapag ito ay naging sapat na may kakayahan upang gawin ang buong gawain: basahin ang repositoryo, gumawa ng patch, magpatakbo ng mga pagsubok, magbukas ng PR, bumalik pagkatapos ng komento sa pagsusuri. Eksaktong gumagalaw ang Codex sa direksyong iyon: background work, hiwalay na worktree, integrated browser, automation, plugin, memory at mas tahasang mga kontrol sa pahintulot.

6Ang punto ay hindi isipin ang isang hinaharap kung saan wala nang nagbabasa ng code. Ito ay magiging isang kahila-hilakbot na hinaharap, pati na rin medyo walang muwang. Ang punto ay upang malaman kung paano makipagtulungan sa mga ahente na maaaring gumawa ng maraming nang hindi pinapayagan silang gawin ang lahat.

8## Ang pagbabago ng ugali

10Gamit ang tradisyunal na autocomplete palagi kang nasa gulong. Nagmungkahi ang AI ng isang linya, nagpasya ka. Sa isang ahente, gayunpaman, nagbabago ang relasyon: binibigyan mo siya ng layunin at dumaan siya sa maraming hakbang nang mag-isa.

11~

12Ito ay makapangyarihan, ngunit binabago nito ang problema. Ang tanong ay hindi na lang "pwede ba ang model program?". Ang tanong ay nagiging:

13~

14- Binigyan ko ba siya ng maliit na saklaw?

15- alam mo ba kung paano suriin ang resulta?

16- Nagtatrabaho ba ako sa isang nakahiwalay na kapaligiran?

17- Makatao at maingat pa rin ba ang huling pagsusuri?

18~

19Ang isang malusog na daloy ng trabaho ay mas mukhang ganito kaysa sa isang magic wand:

20~

21```mermaid

22flowchart LR

23 Idea[Gawain ng tao] --> Scope[Maliit, nabe-verify na layunin]

24 Scope --> Agent[Ahente sa worktree nakahiwalay]

25 Agent --> Checks[Subukan, lint, build, browser]

26 Checks --> Review[Pagsusuri ng tao]

27 Review --> Merge[Pagsamahin o bagong pag-ulit]

28 Review --> Iterate[Tumpak na mga komento sa diff]

29 Iterate --> Agent

30```

31~

32Mukhang hindi gaanong romantiko kaysa sa "ginagawa ng ahente ang lahat", ngunit mas mahusay itong gumagana. At ito rin kung paano gumagana ang mga team na mahusay sa mga tao: malinaw na gawain, mabilis na feedback, tahasang pananagutan.

33~

34## Ang magandang prompt ay halos isang magandang tiket

35~

36Ang pinaka-mapanganib na prompt ay ang malabo ngunit may kumpiyansa: "ayusin ang pahina ng mga invoice", "pahusayin ang arkitektura", "linisin ang module ng auth." Ito ay mga kahilingan na mukhang produktibo at bumubuo ng malalaking pagkakaiba. Ngunit pagkatapos ay nakita mo ang iyong sarili na gumagawa ng arkeolohiya.

37~

38Ang isang kapaki-pakinabang na prompt ay mas nakakabagot. Halimbawa: ipatupad ang pag-export ng CSV para sa page ng mga invoice, alam na ang talahanayan ay nasa `app/(dashboard)/invoices/page.tsx`, ang mga query ay nasa `src/server/invoices.ts` at mayroon nang katulad na pattern sa `app/(dashboard)/reports`.

39~

40Pagkatapos ay magdagdag ng malinaw na mga hadlang: huwag baguhin ang database schema, huwag magdagdag ng mga dependency kung sapat na ang isang maliit na utility, panatilihin ang umiiral na istilo ng UI. At isara sa pag-verify: `npm test -- invoices` at `npm run build`.

41~

42Ang ganitong uri ng maikling ay hindi para "ipaliwanag nang mas mahusay sa AI". Ito ay nagsisilbi higit sa lahat upang gawing mas malinaw sa iyo kung ano ang iyong itinalaga. Kung hindi mo maisulat ito ng konkreto, marahil ang gawain ay hindi pa handa para sa isang ahente.

43~

44## Tatlong trabaho na kusang-loob kong italaga

45~

46Ang una ay paulit-ulit ngunit nabe-verify na trabaho: pagdaragdag ng mga pagsubok, paglilipat ng mga tawag sa isang bagong panloob na API, pag-update ng mga pag-import, pagpapalit ng mga hindi na ginagamit na bahagi, pag-aayos ng mga error sa TypeScript. Dito ang ahente ay makakatipid ng oras at ang panganib ay nakokontrol.

47~

48Ang pangalawa ay gawaing eksplorasyon: "hanapin kung saan kinakalkula ang kabuuang ito", "ipaliwanag sa akin kung bakit marupok ang pagsubok na ito", "paramihin ang bug at sabihin sa akin kung aling mga file ang tila apektado". Kahit na hindi ito gumagawa ng isang patch kaagad, maaari itong gumawa ng kapaki-pakinabang na reconnaissance.

49~

50Ang ikatlo ay ang umuulit na gawain sa pagpapanatili: maliit na pag-update ng dependency, paglilinis ng mga lumang feature na flag, buod ng mga naka-block na PR, pagsuri sa mga nakalimutang TODO. Hindi ito kaakit-akit, ngunit ito mismo ang uri ng trabaho na may posibilidad na tumambak.

51~

52## Tatlong trabaho na pinapanatili kong tao

53~

54Ang mga desisyon sa produkto ay nananatiling tao. Kung binago ng isang pagbabago kung paano nagbabayad, nagde-delete ng data, nakakakita ng mga presyo, o nakakaunawa ng pahintulot ang isang user, gusto ko ng responsableng tao.

55~

56Ang mga hangganan ng seguridad ay nararapat ding pansinin ng tao: auth, mga tungkulin, mga token, sensitibong pag-log ng data, paglilipat ng database. Ang isang ahente ay maaaring makatulong sa pagpapatupad, ngunit hindi kailangang maging ang tanging gumagawa ng desisyon.

57~

58Sa wakas, pinapanatili ko ang lahat na nangangailangan ng panlasa ng arkitektura ng tao. Ang isang ahente ay maaaring magmungkahi ng isang refactor, ngunit ang pag-unawa kung ang isang abstraction ay talagang kailangan o kung kami ay nagpapakinis lamang ng isang hindi umiiral na problema ay nananatiling isang trabaho.

59~

60## Ang pagsusuri ay hindi opsyonal

61~

62Ang tukso, kapag magaling ang isang ahente, ay magtiwala sa berde ng CI. Naiintindihan naman. Ito rin ay kapag nagsimula ang mga problema.

63~

64Palagi akong tumitingin sa hindi bababa sa limang bagay:

65~

661. Niresolba lang ba ng patch ang hiniling na gawain?

672. Hinawakan ba niya ang mga file na walang kinalaman dito?

683. Sinasaklaw ba ng mga pagsusulit ang bagong pag-uugali o isang masayang pagkakataon lamang?

694. Sinusunod ba ng code ang mga lokal na pattern?

705. Ang mga error ba ay pinangangasiwaan tulad ng sa natitirang bahagi ng proyekto?

71~

72Kapag may mali, kailangang tiyak ang feedback. "Ayusin mo" ay tamad. Mas mabuti: ang utility na ito ay duplicate ang `parseMoney` sa `src/lib/money.ts`; muling gamitin ang function na iyon, magdagdag ng pagsubok para sa kaso ng EUR at huwag baguhin ang pampublikong API ng module ng pagsingil.

73~

74Mas mahusay na tumugon ang mga ahente sa maliliit, nabe-verify na komento. Nakakapagtaka, ganoon din ang mga tao.

75~

76## Ang mga guardrail ay nagkakahalaga ng pagsisikap

77~

78Kung ang isang ahente ay maaaring magbasa ng mga file, magsulat ng code, at magsagawa ng mga utos, dapat itong ituring bilang isang makapangyarihang proseso. Hindi na kailangan ng paranoia, kailangan mo ng kalinisan.

79~

80Gumamit ng hiwalay na worktrees o sanga. Para maihambing mo ang pagkakaiba, itapon ang mga nabigong eksperimento, at huwag ihalo ang trabaho ng ahente sa iyong ginagawa.

81~

82Limitahan ang mga pahintulot. Ang mga utos tulad ng `rg`, `git diff`, `npm test` at `npm run build` ay maaaring maging libre. Ang mga deployment, paglilipat ng database, pag-access sa mga lihim at mapanirang utos ay dapat manatiling tahasan.

83~

84Bawasan ang access sa network kapag hindi mo ito kailangan. Para sa maraming gawain, sapat na ang opisyal na dokumentasyon, pagpapatala ng package at mga partikular na panloob na serbisyo. Mas kaunting lugar sa ibabaw, mas kaunting mga sorpresa.

85~

86Subaybayan ang mga aksyon. Kapag dumating ang isang patch sa pagsusuri, dapat ay magagawa mong muling buuin ang mga senyas, naisagawa ang mga utos, naipasa ang mga pagsubok at binago ang mga file. Hindi para lumikha ng burukrasya, ngunit upang maunawaan kung ano ang nangyari kung may mali.

87~

88## Isang madaling paraan upang makapagsimula bilang isang koponan

89~

90Kung magpapakilala ako ng mga ahente sa isang maliit na koponan, magsisimula ako nang walang malalaking rebolusyon.

91~

92Gagawa ako ng label na `agent-ready` para sa mga isyu na may malinaw na saklaw. Magdaragdag ako ng isang template na may konteksto, mga hadlang at mga utos sa pag-verify. Hihilingin ko ang maliit na PR, mas mabuti sa ilalim ng ilang daang linya. Mangangailangan ako ng pagsubok o mga screenshot para sa mga nakikitang pagbabago. At higit sa lahat ay pananatilihin kong responsable ang isang tao sa pagsasanib.

93~

94Pagkatapos ng dalawang linggo, titingnan ko ang data: kung aling mga gawain ang talagang pinabilis, kung aling mga pagsusuri ang mabigat, kung aling mga senyas ang nakalilito, kung aling mga bahagi ng codebase ang masyadong marupok upang italaga.

95~

96Ito ay isang hindi gaanong kamangha-manghang diskarte kaysa sa "mula ngayon gagawin namin ang lahat kasama ang mga ahente", ngunit ito ang nagbibigay-daan sa iyo na makarating sa ikatlong linggo nang walang pagsisisi.

97~

98## Ang pinaka-pantaong bahagi

99~

100Ang nakakatuwang bagay ay kapag mas nagiging mga autonomous na ahente, mas nagiging mahalaga muli ang mga klasikong kasanayan: pagsulat ng magandang tiket, paggawa ng maliliit na pagbawas, paggawa ng mga pagsusulit, pagbabasa ng mga pagkakaiba, pakikipag-ugnayan sa mga trade-off. Pinapabilis ng ahente ang mga marunong nang magtrabaho nang maayos. Pinapalakas din nito ang kaguluhan ng mga taong hindi maganda ang delegasyon.

101~

102Kaya hindi, hindi ko nakikita ang mga multi-agent na daloy ng trabaho bilang isang shortcut upang ihinto ang paggawa ng engineering. Nakikita ko ang mga ito bilang isang paraan upang ilipat ang mas maraming enerhiya sa mga bahaging mahalaga: pagpapasya kung ano ang itatayo, pagtiyak na gumagana ito, pagpapanatiling naiintindihan ng system.

103~

104Ang mga ahente ay maaaring gumawa ng mahusay na hindi magkakasabay na mga kasamahan. Ngunit ang isang asynchronous na kasamahan, upang maging kapaki-pakinabang, ay nangangailangan ng konteksto, mga hangganan at pagsusuri. Katulad ng iba.

105~

106## Mga kapaki-pakinabang na mapagkukunan

107~

108- [Codex para sa (halos) lahat - OpenAI](https://openai.com/index/codex-for-almost-everything/)

109- [Ligtas na pinapatakbo ang Codex sa OpenAI](https://openai.com/index/running-codex-safely/)

110- [Ipinapakilala ang Codex - OpenAI](https://openai.com/index/introducing-codex/)

111- [Ano ang bago sa GitHub Copilot coding agent](https://github.blog/ai-and-ml/github-copilot/whats-new-with-github-copilot-coding-agent/)

112~