Harness engineering: paggamit ng Codex sa mundong una ang agent

Sa nakalipas na limang buwan, nagsasagawa ng eksperimento ang team namin: pagbuo at pagpapadala ng internal beta ng produktong software na may 0 linya ng mano-manong isinulat na code.

Ang produkto ay may mga panloob na user araw-araw at mga panlabas na alpha tester. Naipapadala, naide-deploy, nasisira, at naaayos. Ang naiiba ay ang bawat linya ng code—lohika ng application, mga pagsubok, configuration ng CI, dokumentasyon, kakayahang masubaybayan, at panloob na tooling—ay isinulat ng Codex. Tinataya namin na binuo namin ito sa humigit-kumulang 1/10 ng oras na kailangan namin kung isusulat ang code nang mano-mano.

Ang mga tao ang nagmamaniobra. Ang mga agent ang nagpapatupad.

Sadyang pinili namin ang limitasyong ito upang mabuo ang kinakailangan para mapabilis ang pagbuo ng software nang malawakan. May ilang linggo kami na ipadala ang nauwi sa milyon-milyong linya ng code. Upang magawa iyon, kinailangan naming maunawaan kung ano ang nagbabago kapag ang pangunahing gawain ng software engineering team ay hindi na ang magsulat ng code, kundi ang magdisenyo ng mga environment, tukuyin ang layunin, at bumuo ng mga feedback loop na nagbibigay-daan sa mga Codex agent na makagawa ng mapagkakatiwalaang trabaho.

Ang post na ito ay tungkol sa aming mga natutunan sa pagbuo ng ganap na bagong produkto kasama ang isang team ng mga agent—kung ano ang nasira, kung ano ang nagpatong-patong, at kung paano sulitin ang nag-iisa naming tunay na kaunting kailangan: ang oras at atensyon ng tao.

Ang unang commit sa walang lamang repository ay naganap noong huling bahagi ng Agosto 2025.

Ang paunang scaffold—istraktura ng repository, configuration ng CI, mga patakaran sa pag-format, setup ng package manager, at application framework—ay nilikha ng Codex CLI gamit ang GPT‑5, na ginabayan ng maliit na hanay ng mga umiiral na template. Kahit ang paunang AGENTS.md file na nagtuturo sa mga agent kung paano gumawa sa repository ay isinulat mismo ng Codex.

Walang umiiral na code na isinulat ng tao na magsisilbing pundasyon ng sistema. Mula sa simula, ang repository ay hinubog ng agent.

Pagkalipas ng limang buwan, ang repository ay naglalaman ng humigit-kumulang isang milyong linya ng code sa lohika ng application, imprastraktura, mga tool, dokumentasyon, at mga internal na utility para sa mga developer. Sa panahong iyon, humigit-kumulang 1,500 pull request ang nabuksan at na-merge sa tulong ng maliit na team na binubuo lamang ng tatlong engineer na nagtutulak sa Codex. Maisasalin ito sa karaniwang throughput na 3.5 PRs bawat engineer bawat araw, at nakakagulat na ang throughput ay tumaas habang lumaki ang team at umabot na ngayon sa pitong mga inhinyero. Ang pinakamahalaga ay hindi ito output para lang sa output: ang produkto ay ginamit na ng daan-daang user sa loob ng organisasyon, kabilang ang mga power user na araw-araw itong ginagamit.

Sa buong proseso ng pag-develop, hindi kailanman direktang nag-ambag ng anumang code ang mga tao. Naging pangunahing pilosopiya ito para sa team: walang mano-manong isinulat na code.

Ang kakulangan ng hands-on na pag-code ng tao ay nagpakilala ng ibang uri ng gawaing pang-inhinyero, na nakatuon sa mga sistema, scaffolding, at leverage.

Mas mabagal kaysa sa inaasahan namin ang maagang pag-usad, hindi dahil hindi kaya ng Codex, kundi dahil hindi sapat ang detalye ng environment. Kinulang ang agent sa mga tool, abstraksyon, at panloob na istraktura na kinakailangan upang makausad patungo sa mga layuning mataas ang antas. Ang pangunahing trabaho ng aming engineering team ay naging ang pag-enable sa mga agent na makagawa ng kapaki-pakinabang na gawain.

Sa praktika, ang ibig sabihin nito ay magtrabaho nang depth-first: paghahati-hatiin ang mas malalaking layunin sa mas maliliit na building block (disenyo, code, review, test, atbp.), pagpo-prompt sa agent na buuin ang mga block na iyon, at paggamit sa mga ito para i-unlock ang mas kumplikadong mga gawain. Kapag may pumalya, halos hindi kailanman naging solusyon ang “magsikap pa.” Dahil ang tanging paraan para makausad ay ang ipagawa sa Codex ang trabaho, palaging pumapasok ang mga inhinyerong tao sa gawain at nagtatanong: “anong kakayahan ang kulang, at paano natin ito gagawing madaling maunawaan at maipapatupad para sa agent?”

Nakikipag-ugnayan ang mga tao sa sistema halos sa pamamagitan ng mga prompt: inilalarawan ng isang inhinyero ang gawain, pinapatakbo ang agent, at pinapayagan itong magbukas ng pull request. Upang makumpleto ang PR, inuutusan namin ang Codex na suriin ang sarili nitong mga pagbabago nang lokal, humihiling ng karagdagang partikular na pagsusuri ng agent kapwa sa lokal at sa cloud, tumutugon sa anumang feedback na ibinigay ng tao o agent, at nag-i-iterate sa isang loop hanggang masiyahan ang lahat ng tagasuri ng agent (sa madaling salita, ito ay ang ⁠(magbubukas sa bagong window)Ralph Wiggum Loop). Gumagamit ang Codex ng aming mga karaniwang development tool nang direkta (gh, mga lokal na script, at mga kasanayang naka-embed sa repository) upang mangalap ng konteksto nang hindi na kailangang mag-copy at paste ng mga tao sa CLI.

Maaaring suriin ng mga tao ang mga pull request, ngunit hindi ito kinakailangan. Sa paglipas ng panahon, itinulak namin ang halos lahat ng pagsisikap sa pag-review upang ito ay hawakan ng agent-to-agent.

Habang tumataas ang throughput ng code, ang naging hadlang sa amin ay ang kapasidad ng pag-QA ng tao. Dahil ang nakapirming limitasyon ay ang oras at atensyon ng tao, nagsikap kaming magdagdag ng mas maraming kakayahan ng agent sa pamamagitan ng paggawa ng mga bagay tulad ng application UI, mga log, at mga sukatan ng app na direktang nababasa ng Codex mismo.

Halimbawa, ginawa naming bootable ang app kada git worktree, upang mailunsad at mapatakbo ng Codex ang isang instance sa bawat pagbabago. Ikinabit din namin ang Chrome DevTools Protocol sa runtime ng agent at lumikha ng mga kasanayan para sa pagtatrabaho sa mga DOM snapshot, screenshot, at pag-navigate. Pinayagan nito ang Codex na muling likhain ang mga bug, patunayan ang mga pag-aayos, at direktang mag-isip tungkol sa gawi ng UI.

Ginawa rin namin ito sa observability tooling. Ang mga log, sukatan, at trace ay inilalantad sa Codex sa pamamagitan ng pansamantalang lokal na observability stack na mahalaga sa anumang ibinigay na worktree. Gumagana ang Codex sa isang ganap na nakabukod na bersyon ng app na iyon—kabilang ang mga log at sukatan nito, na tinatanggal kapag natapos na ang gawaing iyon. Maaaring i-query ng mga agent ang mga log gamit ang LogQL at ang mga sukatan gamit ang PromQL. Sa pagkakaroon ng kontekstong ito, nagiging mas madali ang mga prompt tulad ng “tiyakin na ang pagsisimula ng serbisyo ay makukumpleto sa hindi bababa sa 800 ms” o “walang span sa apat na kritikal na paglalakbay ng user na ito ang lalampas sa dalawang segundo”.

Regular naming nakikita na ang isang run ng Codex ay gumagana sa isang gawain nang mahigit sa anim na oras (madalas habang natutulog ang mga tao).

Ang pamamahala ng konteksto ay isa sa pinakamalalaking hamon upang maging epektibo ang mga agent sa malalaki at kumplikadong gawain. Isa sa mga pinakaunang aral na natutunan namin ay simple: bigyan ang Codex ng mapa, hindi ng 1,000-pahinang manwal ng mga tagubilin.

Sinubukan namin ang “isang malaking AGENTS.md⁠(magbubukas sa bagong window)” na paraan. Matataya ang pagpalya ng mga ito:

• Ang konteksto ay bihirang mapagkukunan. Isang napakalaking file ng mga tagubilin ang sumisiksik sa gawain, sa code, at sa mga kaugnay na dokumento—kaya't alinman sa hindi napapansin ng agent ang mahahalagang mga limitasyon o nagsisimula itong mag-optimize para sa mga maling limitasyon.
• Ang labis na patnubay ay nagiging hindi na patnubay. Kapag ang lahat ay “mahalaga,” wala nang mahalaga. Nauuwi ang mga agent sa lokal na pagtutugma ng pattern sa halip na sadyang mag-navigate.
• Agad itong nabubulok. Ang monolitikong manwal ay nagiging isang libingan ng mga lipas nang alituntunin. Hindi matukoy ng mga agent kung ano ang totoo pa rin, tumitigil ang mga tao sa pag-maintain nito, hanggang sa nagiging kaakit-akit na abala na ang file.
• Mahirap itong beripikahin. Hindi angkop ang blobg sa mga mekanikal na pagsusuri (saklaw, pagkabago, pag-aari, cross-links), kaya hindi maiiwasan ang paglihis.

Kaya sa halip na ituring ang AGENTS.md bilang encyclopedia, itinuturing natin ito bilang ang talaan ng mga nilalaman.

Ang knowledge base ng repository ay nasa isang naka-istrakturang direktoryo ng docs/ na itinuturing na sistema ng record. Isang maikling AGENTS.md (humigit-kumulang 100 linya) ang ini-inject sa konteksto at pangunahing nagsisilbing mapa, na may mga pointer patungo sa mas malalalim na pinagmumulan ng katotohanan sa ibang lugar.

Ang dokumentasyon ng disenyo ay naka-catalog at naka-index, kabilang ang katayuan ng beripikasyon at isang hanay ng mga pangunahing paniniwala na tumutukoy sa mga prinsipyo ng pagpapatakbo na inuuna ang agent. Ang Dokumentasyon ng Arkitektura⁠(magbubukas sa bagong window) ay nagbibigay ng mapa sa pinakamataas na antas ng mga domain at pag-layer ng package. Minamarkahan ng de-kalidad na dokumento ang bawat domain ng produkto at layer ng arkitektura, sinusubaybayan ang mga puwang sa paglipas ng panahon.

Ang mga plano ay itinuturing na mga pangunahing artifact. Ginagamit ang mga ephemeral lightweight plan para sa maliliit na pagbabago, habang ang kumplikadong gawain ay itinatala sa mga execution plan⁠(magbubukas sa bagong window) na may mga log ng pag-usad at desisyon na sinusuri sa repository. Ang mga aktibong plano, nakumpletong plano, at kilalang teknikal na utang ay nakab ersyon lahat at magkakasamang nakaayos, na nagbibigay-daan sa mga agent na makapagtrabaho nang hindi umaasa sa panlabas na konteksto.

Pinapagana nito ang progresibong pagsisiwalat: nagsisimula ang mga agent sa isang maliit, matatag na entry point at tinuturuan kung saan susunod na titingin, sa halip na mabigla agad sa simula.

Ipinatutupad namin ito nang mekanikal. Tinitiyak ng mga nakalaang linter at mga trabaho ng CI na ang batayan ng kaalaman ay napapanahon, may mga cross-link, at tama ang pagkakaayos. Paulit-ulit na “doc-gardening” agent ang nag-i-scan para sa mga lipas o hindi na napapanahong dokumentasyon na hindi sumasalamin sa aktwal na gawi ng code at nagbubukas ng mga pull request para sa pag-aayos.

Habang umuunlad ang codebase, kailangan ding umunlad ang balangkas ng Codex para sa mga desisyon sa disenyo.

Dahil ang repository ay ganap na binuo ng agent, ito ay na-optimize muna para sa kadaliang basahin ng Codex. Gaya ng layunin ng mga team na pagandahin ang pagiging madaling i-navigate ng kanilang code para sa mga bagong tanggap na inhinyero, ang layunin ng aming mga inhinyerong tao ay gawing posible para sa agent ang makapag-isip tungkol sa buong domain ng negosyo nang direkta mula sa repository.

Mula sa pananaw ng agent, ang anumang hindi niya ma-access sa konteksto habang ito ay tumatakbo nang epektibo ay hindi umiiral. Ang kaalamang nasa Google Docs, mga thread ng chat, o nasa isip ng mga tao ay hindi naa-access ng sistema. Ang mga artifact na nasa lokal na repository o nakabersyon (hal., code, markdown, mga schema, mga executable plan) ang tanging nakikita nito.

Natutunan namin na sa pagdaan ng panahon, kailangan naming magsikap at magdagdag ng mas maraming konteksto sa repo. Ang usapan sa Slack na nagpaayon sa team sa arkitektural na pattern? Kung hindi ito matutuklasan ng agent, hindi ito mababasa tulad ng hindi pagkakaalam rito ng isang bagong empleyado na sasali pagkalipas ng tatlong buwan.

Ang ibig sabihin ng pagbibigay ng mas maraming konteksto sa Codex ay ang pag-aayos at paglalantad ng tamang impormasyon upang mapangatuwiranan ito ng agent, sa halip na bombahin ito ng mga ad-hoc na tagubilin. Gaya ng sa pag-o-onboard ng bagong kasamahan sa mga prinsipyo ng produkto, mga pamantayan sa engineering, at kultura ng team (kasama ang mga preperensya sa emoji), ang pagbibigay ng impormasyong ito sa agent ay nagreresulta sa mas maayos na pagkakaayon ng output.

Nilinaw ng balangkas na ito ang maraming pamalit. Pinaboran namin ang mga dependency at abstraksyon na maaaring ganap na ma-internalize at mapag-isipan sa loob ng repo. Ang mga teknolohiyang madalas ilarawan bilang “nakakabagot” ay karaniwang mas madaling i-modelo para sa mga agent dahil sa composability, katatagan ng API, at representasyon sa set ng pagsasanay. Sa ilang mga sitwasyon, mas mura na muling ipatupad sa agent ang mga subset ng pungsyonalidad kaysa maghanap ng solusyon sa hindi malinaw na upstream behavior mula sa mga pampublikong library. Halimbawa, sa halip na gumamit ng generic na package na p-limit-style, nagpatupad kami ng sarili naming map-with-concurrency helper: mahigpit itong naka-integrate sa aming OpenTelemetry instrumentation, may 100% test coverage, at kumikilos nang eksakto sa paraang inaasahan ng aming runtime.

Ang pagdadala ng mas maraming bahagi ng sistema sa anyo na maaaring siyasatin, i-validate, at baguhin nang direkta ng agent ay nagpapataas ng bentaha—hindi lamang para sa Codex, kundi para rin sa iba pang mga agent (hal. Aardvark) na nagtatrabaho rin sa codebase.

Hindi sapat ang dokumentasyon lamang upang mapanatiling magkakaugnay ang codebase na ganap na binuo ng agent. Sa pagpapatupad ng mga invariant, hindi sa pagmamaliit ng mga implementasyon, hinahayaan naming makapagpadala nang mabilis ang mga agent nang hindi pinapahina ang pundasyon. Halimbawa, hinihiling namin sa Codex na i-parse ang mga hugis ng data sa hangganan⁠(magbubukas sa bagong window), ngunit hindi kami nagtatakda kung paano ito mangyayari (tila gusto ng modelo ang Zod, ngunit hindi namin tinukoy ang partikular na library na iyon).

Pinakaepektibo ang mga agent sa mga environment na may mahigpit na hangganan at mahuhulaang istruktura⁠(magbubukas sa bagong window), kaya't binuo namin ang aplikasyon alinsunod sa mahigpit na arkitektural na modelo. Ang bawat domain ng negosyo ay hinahati sa nakatakdang hanay ng mga layer, na may mahigpit na nabeberipikang mga direksyon ng dependency at limitadong hanay ng mga permissible edge. Ang mga limitasyong ito ay ipinatutupad nang mekanikal sa pamamagitan ng mga custom na linter (na Codex-generated, syempre!) at mga nakaistrakturang pagsubok.

Ipinapakita ng diagram sa ibaba ang patakaran: sa loob ng bawat domain ng negosyo (hal. Mga Setting ng App), ang code ay maaari lamang umasa “pasulong” sa pamamagitan ng isang nakapirming hanay ng mga layer (Types → Config → Repo → Service → Runtime → UI). Ang mga alalahanin sa cross-cutting (auth, connectors, telemetry, feature flags) ay pumapasok sa pamamagitan ng iisang tahasang interface: Providers. Ang iba pa ay hindi pinapayagan at ipinatutupad nang mekanikal.

Ito ang uri ng arkitektura na karaniwan ninyong ipinagpapaliban hanggang sa mayroon na kayong daan-daang inhinyero. Sa mga coding agent, ito ay maagang pangangailangan: ang mga limitasyon ang nagpapahintulot sa bilis nang walang pagkasira o paglihis ng arkitektura.

Sa praktika, ipinapatupad namin ang mga panuntunang ito gamit ang mga custom na linter at mga nakaistrakturang pagsubok, na may kasamang maliit na set ng mga “taste invariant.” Halimbawa, statically naming ipinapatupad ang nakaistrakturang pag-log, mga kombensyon ng pagpapangalan para sa mga schema at type, mga limitasyon sa laki ng file, at mga pangangailangang partikular sa platform na para sa pagkamaaasahan gamit ang mga custom na lint. Dahil pasadyang ginawa ang mga lint, isinusulat namin ang mga mensahe ng error upang magpasok ng mga tagubilin sa pag-aayos sa konteksto ng agent.

Sa isang workflow na inuuna ang tao, ang mga patakarang ito ay maaaring magmukhang masyadong pihikan o nakakasakal. Sa mga agent, pampadagdag ang mga ito: kapag na-encode na, naa-apply ang mga ito sa lahat ng aspekto nang sabay-sabay.

Kasabay nito, malinaw naming tinutukoy kung saan mahalaga ang mga limitasyon at kung saan hindi. Katulad nito ang pamumuno sa malaking organisasyon ng platapormang pang-engineering: ipatupad ang mga hangganan sa sentro, payagan ang awtonomiya sa lokal. Lubos ninyong pinahahalagahan ang mga hangganan, kawastuhan, at kakayahang maisagawang muli. Sa loob ng mga hangganang iyon, binibigyan ninyo ang mga team—o mga agent—ng malaking kalayaan sa kung paano ipinapahayag ang mga solusyon.

Ang resultang code ay hindi palaging tumutugma sa mga kagustuhan ng tao sa estilo, at ayos lang iyon. Hangga't tama, madaling mapanatili, at malinaw sa mga susunod na pagtakbo ng agent ang output, pumapasa ito sa pamantayan.

Ang preperensya ng tao ay patuloy na ibinabalik sa sistema. Ang mga komento sa pagsusuri, mga pull request para sa refactoring, at mga bug na nakikita ng user ay kinukuha bilang mga update sa dokumentasyon o direktang ini-encode sa mga tool. Kapag hindi sapat ang dokumentasyon, isinusulong namin ang panuntunan sa code

Habang tumataas ang throughput ng Codex, maraming kombensyonal na pamantayan sa engineering ang naging hindi produktibo.

Ang repository ay gumagana nang minimal lang ang mga merge gate na humahadlang. Panandalian ang mga pull request. Madalas na tinutugunan ang mga flake sa pagsusulit sa pamamagitan ng mga follow-up na pagtakbo sa halip na harangin ang pag-unlad nang walang hanggan. Sa isang sistema kung saan ang throughput ng agent ay higit na nakakataas kaysa sa atensyon ng tao, mura ang mga pagwawasto, at mahal ang paghihintay.

Ito ay iresponsable sa environment na may mababang throughput. Dito, ito ang kadalasang tamang pamalit.

Kapag sinasabi naming ang codebase ay binuo ng mga Codex agent, ang ibig naming sabihin ay lahat ng bahagi ng codebase.

Ang mga agent ay gumagawa ng:

• Code ng produkto at mga pagsubok
• Pag-configure ng CI at mga tool para sa pag-release
• Mga panloob na tool ng developer
• Kasaysayan ng Dokumentasyon at Disenyo
• Mga harness para sa pagsusuri
• Pagsusuri ng mga komento at tugon
• Mga script na namamahala sa repository mismo
• Mga file ng kahulugan sa dashboard ng produksyon

Palaging nananatiling kasali sa proseso ang mga tao, ngunit nagtatrabaho sa ibang antas ng abstraksyon kaysa sa nakaraan. Mas inuuna namin ang trabaho, isinasalin ang feedback ng user sa mga pamantayan sa pagtanggap, at pinapatunayan ang mga resulta. Kapag nahihirapan ang agent, itinuturing namin itong isang senyales: tukuyin kung ano ang kulang—mga tool, guardrail, dokumentasyon—at ibalik ito sa repository, palaging sa pamamagitan ng pagpapasulat sa Codex mismo ng pag-aayos.

Direktang ginagamit ng mga agent ang aming mga karaniwang tool sa pag-develop. Kinukuha nila ang feedback sa pagsusuri, sumasagot nang direkta, nagpu-push ng mga update, at madalas nilang i-squash at i-merge ang sarili nilang mga pull request.

Habang mas marami sa development loop ang direktang na-encode sa system—pagsubok, pagpapatunay, pagsusuri, paghawak ng feedback, at recovery—kamakailan ay tumawid ang repository sa makabuluhang hangganan kung saan kayang isulong ng Codex ang isang bagong tampok mula simula hanggang katapusan.

Sa isang prompt lang, magagawa na ngayon ng agent ang mga sumusunod:

• Suriin ang kasalukuyang estado ng codebase
• Ulitin ang naiulat na bug
• Mag-record ng video na nagpapakita ng pagpalya
• Magpatupad ng pag-aayos
• Patunayan ang pag-aayos sa pamamagitan ng paggamit ng application
• Mag-record ng ikalawang video na nagpapakita ng resolusyon
• Magbukas ng pull request
• Tumugon sa feedback ng agent at tao
• Tukuyin at ayusin ang mga pagpalya ng build
• Iakyat lamang sa isang tao kapag kinakailangan ang paghatol
• I-merge ang pagbabago

Ang gawing ito ay lubos na nakadepende sa partikular na istraktura at tooling ng repository na ito, at hindi dapat ipalagay na naaangkop sa lahat nang walang katulad na pamumuhunan—hindi pa sa ngayon.

Ang ganap na awtonomiya ng agent ay nagdudulot din ng mga bagong problema. Ginagaya ng Codex ang mga pattern na umiiral na sa repository—kahit na ang mga hindi pantay o hindi pinakamainam. Sa paglipas ng panahon, hindi maiiwasang humantong ito sa paglihis.

Sa simula, ito ay mano-manong tinugunan ng mga tao. Noong nakaraan, ginuguol ng team namin ang bawat Biyernes (20% ng linggo) sa paglilinis ng “AI slop.” Hindi kami nagulat na hindi ito lumaki.

Sa halip, sinimulan naming i-encode ang tinatawag naming “mga gintong prinsipyo” nang direkta sa repository at bumuo ng paulit-ulit na proseso ng paglilinis. Ang mga prinsipyong ito ay may kinikilingang pananaw, mga mekanikal na panuntunan na nagpapanatili sa codebase na madaling basahin at pare-pareho para sa mga susunod na pagtakbo ng agent. Halimbawa: (1) mas gusto namin ang mga naka-share na utility package kaysa sa mga hand-rolled helper upang mapanatiling sentralisado ang mga invariant, at (2) hindi kami nagsusuri ng data na parang “YOLO-style”—tinitiyak namin ang mga hangganan o umaasa sa mga typed SDK upang hindi aksidenteng makabuo ang agent batay sa mga hinulaang hugis. Sa regular na pagkakataon, mayroon kaming hanay ng mga background na gawain ng Codex na nag-scan para sa mga paglihis, nag-a-update ng mga grado ng kalidad, at nagbubukas ng mga naka-target na pull request para sa refactoring. Karamihan sa mga ito ay maaaring suriin nang wala pang isang minuto at awtomatikong i-merge.

Gumagana ito na parang pangongolekta ng basura. Ang teknikal na utang ay parang pautang na mataas na interes: halos palaging mas mainam na bayaran ito nang tuluy-tuloy sa maliliit na halaga kaysa hayaan itong dumoble at magbayad nang malakihan. Minsanan lang at nabibihag na ang preperensya ng tao, at pagkatapos ay patuloy na ipinapatupad sa bawat linya ng code. Binibigyang-daan din kami nito na matukoy at maresolba ang mga hindi magandang pattern araw-araw, sa halip na hayaang kumalat ang mga ito sa code base nang ilang araw o linggo.

Sa ngayon, ang estratehiyang ito ay gumana nang maayos hanggang sa panloob na paglulunsad at pag-adopt sa OpenAI. Ang pagbuo ng tunay na produkto para sa mga tunay na user ay nakatulong na i-angkla ang aming mga pamumuhunan sa realidad at gabayan kami patungo sa pangmatagalang pagpapanatili.

Ang hindi pa natin alam ay kung paano uunland ang arkitektural na pagkakaugnay-ugnay sa pagdaan ng mga taon sa sistemang ganap na binuo ng agent. Patuloy pa rin naming inaaral kung saan nagdadagdag ng pinakamalaking bentaha ang panghuhusga ng tao at kung paano i-encode ang panghuhusgang iyon upang ito ay magpatuloy na lumago. Hindi rin namin alam kung paano magbabago ang sistemang ito habang patuloy na nagiging mas may kakayahan ang mga modelo sa pagdaan ng panahon.

Ang naging malinaw: ang pagbuo ng software ay nangangailangan pa rin ng disiplina, ngunit mas nakikita ang disiplina sa scaffolding kaysa sa code. Ang tooling, mga abstraksyon, at mga feedback loop na nagpapanatiling magkakaugnay sa codebase ay lalong nagiging mahalaga.

Ang aming pinakamahihirap na hamon ngayon ay nakatuon sa pagdidisenyo ng mga environment, mga feedback loop, at mga sistema ng kontrol na tumutulong sa mga agent na makamit ang aming layunin: bumuo at magpanatili ng kumplikado at maaasahang software sa malawakang saklaw.

Habang tinutugunan ng mga agent tulad ng Codex ang mas malalaking bahagi ng lifecycle ng software, mas magiging mahalaga pa ang mga tanong na ito. Umaasa kaming makakatulong ang pagbabahagi ng ilang maagang aral upang matulungan kayong magpasya kung saan ilalaan ang inyong pagsisikap para makapagbuo na lang kayo ng mga bagay.