Editor’s Note: Ang artikulong ito ay galing kay Dominik Kundel, miyembro ng OpenAI na nakatuon sa developer relations, na naglalahad ng kanyang karanasan sa paggamit ng Codex na “goal mode //goal”. Hindi ito karaniwang teknik sa prompt, kundi isang pagbabago sa papel ng AI na tool sa pag-program: hindi na lamang ang Codex isang code assistant na sumasagot sa isang-linggong utos, kundi nagsisimula na itong maging isang execution agent na patuloy na nagpapalapit sa isang malinaw na layunin.

Sa /goal mode, ang tunay na mahalaga ay hindi ang pagkakasulat ng mga pangangailangan nang mas mahaba at mas detalyado, kundi ang pagtakda ng malinaw at masusukat na mga pamantayan para sa pagtatapos para sa Codex. Halimbawa: “bawasan ang deployment time ng 30%”, “abot ng 100% parity sa test coverage”, “bawasan ang LCP sa ilalim ng 2.5 segundo”. Ang mga sukat na ito ay nagpapahintulot sa Codex na matukoy kung kumpleto na ang gawain, at nag-iwas sa pagkakaroon ng walang katapusang pagsubok sa mga ambigong layunin. Samantala, kailangan pa ng user na magbigay ng sapat na direksyon, mga kasangkapan, at totoong kapaligiran upang makapag-sukat at makapag-verify ang Codex ng progreso at resulta, at hindi lamang magtapos ng isang solusyon na tila maaaring gawin sa lokal o hipotetikal na kondisyon.

Lalo ring binabanggit ng artikulo na ang mga gawain na may kaugnayan sa visual ang pinakamadaling ihihigop ng Codex sa detalye. Sa halip na hilingin ang “100% pixel-perfect reproduction”, ihihiwalay ang mga visual na layunin sa listahan ng mga function, mga pamantayan ng disenyo, at mga makikita at masusukat na indikador. Para sa mga mahabang gawain na tumatagal ng ilang oras o araw, kailangan din itong masunod nang patuloy gamit ang mga commit, draft PR, dokumento ng progreso, Slack updates, o side chat upang maiwasan ang pagkakaroon lamang ng isang malaking hanay ng hindi ma-trace na mga pagbabago.

Ang halaga ng artikulong ito ay nasa pagmamalikha nito ng bagong kahulugan para sa /goal bilang isang “mekanismo para sa pamamahala ng mahabang panahong gawain.” Kapag ang AI ay kayang magpatuloy na magpapatupad ng ilang sampu o higit pa sa isang daan na oras, ang pangunahing kakayahan ng mga developer ay nagbabago: hindi na lamang ang paggawa ng code ngunit ang pagtukoy ng mga layunin, pagbuo ng sistema ng pagsukat, pag-configure ng kapaligiran ng pagpapatupad, at ang paggawa ng pagsusuri at pagsusuri sa huli. Sa madaling salita, ang AI programming ay naglalakbay mula sa “pagsusulat ng prompt” patungo sa “pamamahala sa isang patuloy na gumagawa na inhinyero.”

Narito ang orihinal na teksto:

Isinilang namin ang Goal Mode (o /goal) upang tulungan ka na gawing patuloy ang Codex patungo sa isang tiyak na resulta. Kapag nagtatakda ka ng isang layunin, magtatrabaho ang Codex nang patuloy hanggang sa matupad ang layunin—ano pa man ang oras na kailangan, ilang oras o ilang araw. May mga tao na pinagtrabahuhan na ang Codex nang higit sa 120 oras para sa iisang layunin.

Ang target mode ay napakalakas. Upang maksimisahin ang paggamit nito, may 7 bagay na dapat tandaan kapag gumagamit ng /goal.

Tukuyin ang malinaw, masusuri na mga pamantayan

Ang mga prompt na ipinapasa mo kapag nag-activate ka ng target mode, ay maaaring gamitin bilang initial prompt, ngunit mas mahalaga, ito ay magiging standard para sa pagwawakas ng target. Ang Codex ay aayos na i-check bawat round: kung natapos na ba ang target.

Kaya ang iyong target prompt ay hindi dapat masyadong mahaba, kundi dapat nakatuon sa isang malinaw na pamantayan: saan mangyayari, masasabing natupad na ang target na ito.

Sa karamihan ng mga kaso, ang isang mabuting layunin ay dapat maglalaman ng isang malinaw na numerikal na tukoy upang masukat kung kumpleto na ang modelo. Halimbawa:

Nabawasan ang pagbuo at pag-deploy ng oras ng 30%.

I-transfer ang function na ito mula sa TypeScript patungo sa Rust at abutin ang 100% na test consistency.

Optimisahin ang application scaffold upang mabawasan ang Largest Contentful Paint (LCP), na sukat ng bilis ng pag-load ng pangunahing nilalaman ng pahina, sa ilalim ng 2.5 segundo sa production environment.

Hindi laging kailangan ng numero ang prompt, ngunit karaniwan, mas madaling ipagpatuloy ang mga susunod na hakbang kung may numero.

Kung hindi pa ka sigurado kung paano ipapakilala ang iyong layunin, o nais mong muna mag-brainstorm ng proyekto kasama ang Codex, hindi mo kailangang simulan ang usapan gamit ang mode ng layunin.

Ang Codex ay maaaring magtakda ng sariling layunin. Maaari mong magsimula ng isang normal na usapan, at pagkatapos ay bigyan ang Codex ng utos na magtakda ng layunin batay sa mga nakaraang pag-uusap.

Maaari mo ring i-edit ang target kahit kailan: Klikin ang button na I-edit sa app ng Codex, o gamitin muli ang /goal sa CLI.

Sundin ang mga gabay kung maaari

Ang mga paalala tulad ng “bawasan ang pagbuo at pag-deploy ng oras ng 30%” ay maaaring mukhang kakaibang mabuti at maaaring magbigay sa Codex ng ilang likas na solusyon. Ngunit kung ikaw ay may malinaw na ideya kung saan maaaring nangyari ang problema, maaari ring magdala ang ganitong paalala sa Codex sa isang maling direksyon.

Kaya, kung posible, mas mainam na sabihin sa Codex kung saan dapat magsimula ang paghahanap, anong mga kasangkapan ang maaaring gamitin upang matupad ang layunin, o ibigay ang iba pang mga payo upang maiwasan ang pagkakasala sa maling direksyon.

Halimbawa, ginawa ng aking kasamahan @reach_vb sa isang eksperimento: sinabi niya sa Codex na maaaring gamitin ang Chrome browser upang makapasok sa Google Colab, at binigay niya ang ilang tatanggapin na limitasyon, tulad ng pagpapahintulot sa Codex na maglikha ng sariling dataset habang tinuturuan ang modelo.

Kung nais mong maikliin ang oras ng pagbuo at alam mo na kung saan nagkakaroon ng pinakamaraming pagkakalat ng oras, mas mabuti na i-direct muna ang Codex sa nasabing lugar sa iyong prompt.

Ang isa pang paraan ay maaari mong hayaan muna ang Codex na gumawa ng ilang pagsusuri sa plan mode at gawin itong lumikha ng isang plan file na naglalaman ng mga potensyal na solusyon. Pagkatapos, pagsamahin mo ang iyong layunin sa plano na ito.

Gawing masusukat ang progreso

Kung ang iyong layunin ay malaki o kaya’y may maraming paraan ang Codex upang maabot ang layunin nang paunti-unti, mahalaga na bigyan mo ang Codex ng mga kasangkapan upang masukat ang progreso.

Para sa ilang mga gawain, ang punto na ito ay natural na tumutugma. Halimbawa, ang pag-optimize ng build time at pagpapataas ng test coverage, dahil ang Codex ay karaniwang nakakagamit na ng mga kaugnay na tool, o natural na gumagawa ng mga tool na ito.

Ngunit para sa iba pang mga layunin, mas mainam na mag-brainstorm ka muna kasama ang Codex: Anong mga kasangkapan ang nakakatulong sa pagtataya ng progreso? O ibigay ang ilang mga hint upang malaman nito kung paano matiyak kung ito ay nasa tamang direksyon patungo sa layunin. Halimbawa, lumikha ng isang tool para sa paghahambing ng visual difference sa dalawang screenshot, o lumikha ng isang set ng pagtataya para sa agent na pinagdududahan mo.

Nagbigay ako ng isang video kay Codex upang muling lumikha ng ilang mga komponent, at noong panahong iyon, nilikha ng Codex ang sarili nitong tool upang ihambing ang mga screenshot at suriin ang mga pagkakaiba. Pagkatapos, patuloy niyang pinag-isipan ang tool na ito at idinagdag ang iba’t ibang mode ng paghahambing ng pagkakaiba.

Batay sa gawain, kailangan mo ring isaisip kung mayroon pang karagdagang pamantayan na dapat sukatin o i-check. Kung hindi, maaaring akalain ng Codex na natapos na ang gawain, bagaman sa iyong pananaw ay hindi pa kumpleto.

Halimbawa, maaaring gawin ng Codex ang “pixel-perfect replication” ng isang UI sa pamamagitan ng pag-crop at pag-embed ng design reference image sa pahina; o upang makamit ang 100% na pass rate sa pagsubok, maaari itong bawasan ang test coverage. Ang mga ito ay hindi ang totoong paraan kung paano dapat matapos ang trabaho.

Lumikha ng isang totoong kapaligiran

Kung nais mong makamit ng Codex ang tunay na progreso patungo sa layunin, kailangan itong magsagawa sa isang sapat na totoong kapaligiran.

Sa praktika, nangangahulugan ito: kung gusto mong i-optimize ang oras ng deployment o mga problema sa latency, dapat makapag-access ang Codex sa deployment at testing environment, at dapat ang mga environment na ito ay maging kasing-kasing malapit sa production environment. Ibig sabihin, gamitin ang parehong teknikal na stack, parehong configuration switches, at katulad na database.

Halimbawa, noong nag-debug kami ng pag-optimize ng build at deployment time sa developers.openai.com, gamit na namin ang deployment preview, kaya makapag-deploy ang Codex sa mga preview environment at makakakita ng mga kaugnay na log. Ngunit ang problema ay ang aming mga preview deployment ay pinag-iisahan ang ilang build paths kumpara sa buong production environment.

Kaya, kailangan ng Codex na gawin ang manual deployment upang i-deploy ang code sa isang kapaligiran na mas malapit sa production configuration upang matukoy ang tunay na problema.

Gayundin, maaari mong gamitin ang Codex ang computer use (ang kakayahan ng modelo na mag-operate sa tunay na interface ng aplikasyon) upang subukan ang mga tunay na aplikasyon. Upang mapabuti ang ilang mga problema sa performance sa iOS, ginamit ni @dimillian ang mga pisikal na device upang makakuha ng pinakatumpak na pagsubok na kapaligiran.

Iwasan ang pagtakda ng mga visual na layunin

Ang pagbibigay ng isang visual target sa Codex, tulad ng “I-reproduce ang UI na ito sa 100% na pixel-perfect na pamamaraan batay sa larawang ito,” ay talagang nakakaaliw. Ngunit depende sa partikular na setting, maaari itong magdulot ng mga problema.

Kung hindi mo ibinigay ang tamang gabay at limitasyon, maaaring masyadong mag-focus ang Codex sa ilang detalye at mawala ang pangkalahatang layunin. Halimbawa, kung ang reference image ay naglalaman ng ilang graphic elements, at inaasahan mong gawin ng Codex ang mga ito—ano man ang SVG icons o mga larawan—maaari itong mag-wala ng malaking bahagi ng kanyang enerhiya sa “paano makuha nang tumpak ang mga materyales na ito” kaysa sa tamang pag-decompose ng buong problema.

Bukod dito, kailangan ng Codex ng mga kasangkapan upang makagawa ng tamang visual comparison. Ibig sabihin nito ay higit pang mga input na larawan, mas mataas na pangkabuuang token consumption, ngunit hindi naman tiyak na nagbibigay ito ng simpleng paraan sa Codex upang makakilala ng tunay na may halagang pagkakataon para sa pagpapabuti.

Kaya karaniwang mas angkop ang imahe bilang konteksto ng layunin, hindi bilang tanging pamantayan ng pagkumpleto. Dapat mong hanapin ang iba pang paraan upang matukoy ng Codex kung ang layunin ay naiabot na, tulad ng checklist ng mga tampok, mga spesipikasyon ng pagpapatupad, o pagkakasunod sa design system.

Sundin ang progreso

Kung ang Codex ay nagtatrabaho sa background nang ilang oras o kahit ilang araw, kahit sa ibang machine, madali mong kalimutan kung saan na ito at anong mga gawain na ang natapos.

Ayon sa iba’t ibang layunin, natuklasan kong ang mga sumusunod na paraan ay lubos na nakakatulong:

· Hayaan ang Codex na sumumite ng code sa mga mahahalagang punto at i-push ito sa isang draft PR. Lalo na kapag nagtatrabaho ka sa isang website at may preview deployment, sobrang kapaki-pakinabang nito.

· I-update ang Codex ng isang deliverable para sa management. Maaari itong isang HTML file na maaari mong i-open nang patuloy sa in-app browser; o isang page na ipinapalabas sa pamamagitan ng Sites para sa team na tingnan; maaari itong isang rendered progress chart, o kaya ay isang simpleng Markdown file.

Ipinapayo na mag-post ng mga update sa pag-unlad ang Codex. Maaari mo ring isama ito sa iyong layunin: upang ipadala ng Codex ang mga update sa Slack channel kapag may mahalagang pag-unlad, o sa anumang ibang lugar kung saan nais mong tandaan ang pag-unlad.

Gamitin ang ibang chat window para tanungin ang estado. Kung nais mo lang mabilis na malaman ang kasalukuyang estado, patakbuhin ang /side upang magsimula ng bagong side chat, at doon tanungin. Dahil ito ay magkakaroon ng buong konteksto mula sa kasalukuyang thread, ngunit may maikling buhay.

Ang isang alternatibong paraan sa app ng Codex ay: buksan ang isang bagong karaniwang chat, pahintulutan ang Codex na basahin ang ibang target thread, at sagutin ang iyong mga tanong. Lalo itong makapangyayari kung pahihintulutan mo ang Codex na itakda ang isang automated task na mag-check ng progreso nang patuloy.

Linisin at kumpirmahin ang resulta

Magandang balita, natapos na ang target! Kaya na ba natin agad i-pass ang resulta sa team at tapusin na ang trabaho?

Karaniwan, lalo na sa mga gawain na optimisasyon, natutunan kong makatulong na hayaan ang Codex na suriin at pagsuriin ang kanyang sariling ginawa. Maaari mong unang patakbuhin ang /review para sa lokal na pagsusuri ng code, ngunit mahalaga rin na hayaan ang Codex na mas malalim na mag-isip: Anong mga landas ang sinubukan nito upang makamit ang layunin? Anong mga subok ang epektibo? Anong mga subok ay hindi epektibo? Pagkatapos ay i-clear ang code batay dito.

Dahil patuloy na gumagana ang Codex hanggang makamit ang layunin, maaari itong subukan ang ilang paraan na hindi gaanong epektibo o lubos na walang epekto, at ang mga natirang pagbabago ay maaari pang manatili sa huling code.

Itakda ang isang goal para sa iyong susunod na gawain

Ang layunin ng Codex ay isang napakalakas na kasangkapan na makakatulong sa iyo na lutasin ang ilan sa pinakamahalagang inhinyeriyang hamon. Ngunit mas epektibo ito sa pagtutok sa layunin kung ibibigay mo ang tamang kapaligiran at mga utos.

Ano ang iyong ginawa gamit ang /goal?