Harness engineering: агент-эхний ертөнцөд Codex-ийг ашиглах нь

Сүүлийн таван сарын турш манай баг нэг туршилт хийж байна: гараар бичсэн кодын 0 мөртэйгээр програм хангамжийн бүтээгдэхүүний дотоод бета хувилбарыг бүтээж, гаргасан.

Энэ бүтээгдэхүүн дотоодын өдөр тутмын хэрэглэгчид болон гадаад альфа тестлэгчидтэй. Энэ нь гардаг, байршуулдаг, эвдэрдэг, засагддаг. Ялгаа нь гэвэл кодын мөр бүрийг—аппликейшний логик, тестүүд, CI тохиргоо, баримтжуулалт, observability, дотоод хэрэгслүүдийг—Codex бичсэн. Бид үүнийг гараар код бичихтэй харьцуулахад ойролцоогоор 1/10 хугацаанд бүтээсэн гэж тооцож байна.

Хүн чиглүүлнэ. Агентууд гүйцэтгэнэ.

Бид инженерчлэлийн хурдыг хэд дахин нэмэгдүүлэхэд шаардлагатай зүйлийг бүтээхийн тулд энэ хязгаарлалтыг зориуд сонгосон. Эцэст нь сая мөр код болсон зүйлийг гаргахын тулд бидэнд хэдхэн долоо хоног байсан. Үүнийг хийхийн тулд програм хангамжийн инженерийн багийн үндсэн ажил нь код бичих бус, харин орчин зохион бүтээх, зорилгыг тодорхойлох, Codex агентуудыг найдвартай ажиллуулах эргэх холбооны гогцоог байгуулах болоход юу өөрчлөгдөхийг ойлгох хэрэгтэй болсон.

Энэ нийтлэл нь агентуудын багаараа цоо шинэ бүтээгдэхүүн бүтээхдээ бид юу сурсан, юу эвдэрсэн, юу хурдацтай өссөн, мөн үнэхээр хомс цорын ганц нөөц болох хүний цаг хугацаа, анхаарлыг хэрхэн хамгийн их ашиглах тухай юм.

Хоосон репозиторт хийсэн эхний commit 2025 оны 8-р сарын сүүлээр орсон.

Анхны scaffold—репозиторын бүтэц, CI тохиргоо, форматлах дүрэм, багц менежерийн тохиргоо, аппликейшний framework—Codex CLI дээр GPT‑5 ашиглан, багахан хэмжээний бэлэн template-үүдийн удирдлагаар үүсгэсэн. Агентууд репозиторт хэрхэн ажиллахыг заадаг анхны AGENTS.md файл хүртэл Codex-оор бичигдсэн.

Системийг түшиглэх урьдчилан байсан хүний гараар бичсэн код огт байгаагүй. Эхнээсээ л репозитор агентын нөлөөгөөр хэлбэржсэн.

Таван сарын дараа уг репозитор аппликейшний логик, дэд бүтэц, хэрэгслүүд, баримтжуулалт, дотоод хөгжүүлэгчийн utility-үүдийг хамарсан ойролцоогоор сая мөр код агуулж байна. Энэ хугацаанд ердөө гурван инженер Codex-ийг жолоодон ажиллуулж, ойролцоогоор 1,500 татах хүсэлт нээж, нэгтгэсэн. Энэ нь инженер бүр өдөрт дунджаар 3.5 PR гэсэн нэвтрүүлэх чадамжтай гэсэн үг бөгөөд баг одоо долоон инженер хүртэл өссөн ч энэ нэвтрүүлэх чадамж өссөн нь сонирхолтой. Чухал нь, энэ нь зүгээр л гарцын төлөөх гарц биш байсан: бүтээгдэхүүнийг дотооддоо өдөр бүр идэвхтэй хэрэглэдэг хүчирхэг хэрэглэгчдийг оролцуулаад хэдэн зуун хэрэглэгч ашигласан.

Хөгжүүлэлтийн бүх явцад хүмүүс шууд ямар ч код оруулаагүй. Энэ нь багийн үндсэн философи болсон: гараар бичсэн код байхгүй.

Хүн өөрөө код бичихгүй байх нь систем, scaffold, хөшүүрэгт төвлөрсөн өөр төрлийн инженерийн ажлыг бий болгосон.

Эхний ахиц бидний бодсоноос удаан байсан нь Codex чадваргүйдээ биш, харин орчин хангалттай тодорхойлогдоогүйд байсан. Агент өндөр түвшний зорилгын зүг ахихад шаардлагатай хэрэгслүүд, абстракцууд, дотоод бүтэцгүй байсан. Манай инженерийн багийн үндсэн ажил нь агентуудад хэрэгтэй ажил хийх боломж бүрдүүлэх болсон.

Практикт энэ нь гүнзгийрүүлэн ажиллах гэсэн үг байсан: том зорилгуудыг жижиг барилгын блокууд болгон задлах (дизайн, код, review, test гэх мэт), агентээр тэдгээрийг бүтээлгэх, дараа нь түүгээрээ илүү төвөгтэй ажлуудын түгжээг тайлах. Юм бүтэлгүйтвэл шийдэл нь бараг хэзээ ч “илүү хичээ” байгаагүй. Урагшлах цорын ганц арга нь Codex-оор ажлыг хийлгэх байсан тул хүний инженерүүд үргэлж тухайн ажил руу орж, “ямар capability дутуу байна, үүнийг агент ойлгож, дагаж мөрдөхөөр яаж ил тод, хэрэгжихүйц болгох вэ?” гэж асуудаг байв.

Хүмүүс системтэй бараг бүхэлдээ өгөгдлөөр харилцдаг: инженер даалгаврыг тайлбарлаж, агент ажиллуулаад, түүнд татах хүсэлт нээх боломж олгодог. PR-ийг дуусгахын тулд бид Codex-д өөрийн өөрчлөлтүүдээ локал дээр review хийх, локал болон cloud-д нэмэлт тусгай агентын review хүсэх, хүн эсвэл агентын өгсөн аливаа feedback-д хариулах, бүх агент reviewer сэтгэл ханах хүртэл давталтаар сайжруулахыг заадаг (үнэндээ энэ нь Ralph Wiggum Loop⁠(шинэ цонхонд нээгдэнэ) юм). Codex нь хүмүүс CLI руу copy-paste хийхгүйгээр контекст цуглуулахын тулд манай стандарт хөгжүүлэлтийн хэрэгслүүдийг (gh, локал script-үүд, репозиторт суулгасан skill-үүд) шууд ашигладаг.

Хүмүүс татах хүсэлтүүдийг review хийж болно, гэхдээ заавал биш. Цаг хугацаа өнгөрөх тусам бид review-ийн бараг бүх ачааллыг агент-агент хооронд шийдэгдэх чиглэл рүү түлхсэн.

Кодын нэвтрүүлэх чадамж өсөхийн хэрээр бидний bottleneck нь хүний QA хүчин чадал болсон. Хүний цаг хугацаа, анхаарал тогтмол хязгаар болж байсан тул аппликейшний UI, лог, аппын metric зэрэг зүйлсийг Codex-д шууд ойлгогдохуйц болгож, агентын capability-ийг нэмэхээр ажилласан.

Жишээ нь, бид аппыг git worktree бүр дээр асааж болдог болгосон тул Codex өөрчлөлт бүрт нэг instance ажиллуулж, удирдах боломжтой болсон. Мөн Chrome DevTools Protocol-ийг агент runtime-д холбож, DOM snapshot, screenshot, navigation-той ажиллах skill-үүдийг бүтээсэн. Ингэснээр Codex алдааг давтан гаргах, засварыг баталгаажуулах, UI-ийн зан төлөвийг шууд тайлбарлан ойлгох боломжтой болсон.

Бид observability хэрэгслүүдэд ч мөн адил хандсан. Лог, metric, trace-үүд нь тухайн worktree-д түр зуурын локал observability stack-аар дамжин Codex-д ил гардаг. Codex тухайн аппын бүрэн тусгаарлагдсан хувилбар дээр ажилладаг—түүний лог, metric-үүдтэй нь хамт—мөн даалгавар дуусмагц тэдгээрийг буулгадаг. Агентууд логийг LogQL-ээр, metric-үүдийг PromQL-ээр query хийж чадна. Энэ контекст бэлэн болсноор “service startup 800ms-ээс доош дуусдаг болго” эсвэл “эдгээр дөрвөн чухал хэрэглэгчийн замнал дахь ямар ч span хоёр секундээс хэтрэхгүй байг” гэх мэт өгөгдлүүд хэрэгжихүйц болдог.

Нэг Codex ажиллуулалт нэг даалгавар дээр зургаан цагаас ч илүү ажиллахыг бид тогтмол хардаг (ихэвчлэн хүмүүс унтаж байх хооронд).

Контекстийн менежмент нь агентуудыг том, төвөгтэй ажлуудад үр дүнтэй болгох хамгийн том сорилтуудын нэг. Бидний эрт ойлгосон хамгийн эхний сургамж маш энгийн байсан: Codex-д 1,000 хуудас зааврын гарын авлага бус, газрын зураг өг.

Бид “нэг том AGENTS.md⁠(шинэ цонхонд нээгдэнэ)” аргыг туршиж үзсэн. Энэ нь урьдчилан таамаглаж болох байдлаар бүтэлгүйтсэн:

• Контекст бол хомс нөөц. Аварга том зааврын файл нь даалгавар, код, холбогдох баримтуудыг шахаж гаргадаг—ингэснээр агент чухал хязгаарлалтуудыг алдах эсвэл буруу зүйлийг оновчлох эхлэл тавигддаг.
• Хэт их зааварчилгаа нь зааварчилгаа биш болдог. Бүх зүйл “чухал” бол юу ч чухал биш болдог. Агентууд зориуд чиглэн явахын оронд локал pattern matching хийж эхэлдэг.
• Энэ нь дорхноо хуучирдаг. Нэгэн цул гарын авлага нь хуучирсан дүрмүүдийн оршуулгын газар болдог. Агентууд юу нь одоо ч үнэн болохыг ялгаж чаддаггүй, хүмүүс түүнийг арчлахаа больдог, файл чимээгүйхэн анхаарал татсан саад болдог.
• Баталгаажуулахад хэцүү. Нэг том blob нь механик шалгалт (хамрах хүрээ, шинэчлэгдсэн эсэх, эзэмшил, cross-link) хийхэд тохиромжгүй тул drift зайлшгүй үүсдэг.

Тиймээс AGENTS.md-ийг нэвтэрхий толь гэж үзэхийн оронд бид үүнийг агуулгын хүснэгт гэж үздэг.

Репозиторын мэдлэгийн сан нь record-ын систем гэж үздэг бүтэцтэй docs/ директорт байрладаг. Богино AGENTS.md (ойролцоогоор 100 мөр) нь контекстэд оруулагдаж, голчлон газрын зураг болж, бусад гүнзгий truth source-ууд руу заагч болдог.

Дизайны баримтжуулалтыг баталгаажуулалтын төлөв болон агент-эхний ажиллагааны зарчмыг тодорхойлох суурь итгэл үнэмшлүүдийн хамт каталогжуулж, индексжүүлдэг. Архитектурын баримтжуулалт⁠(шинэ цонхонд нээгдэнэ) нь домэйнүүд болон багцын давхаргын дээд түвшний газрын зургийг өгдөг. Чанарын баримт нь бүтээгдэхүүний домэйн болон архитектурын давхарга бүрийг үнэлж, цоорхойг хугацааны явцад хянадаг.

Төлөвлөгөөг нэгдүгээр зэрэглэлийн артефакт гэж үздэг. Түр зуурын хөнгөн төлөвлөгөөг жижиг өөрчлөлтөд ашигладаг бол төвөгтэй ажлыг репозиторт check in хийдэг явц болон шийдвэрийн лог бүхий гүйцэтгэлийн төлөвлөгөөнд⁠(шинэ цонхонд нээгдэнэ) хадгалдаг. Идэвхтэй төлөвлөгөө, дууссан төлөвлөгөө, мэдэгдэж буй техникийн өр зэрэг нь бүгд version-той, нэг дор байрладаг тул агентууд гаднын контекстэд найдалгүй ажиллах боломжтой.

Ингэснээр шаталсан ил болголт боломжтой болдог: агентууд жижиг, тогтвортой entry point-оос эхэлж, эхнээс нь мэдээллээр дарагдах бус дараа нь хаашаа харахаа сурдаг.

Бид үүнийг механикаар мөрдүүлдэг. Тусгай linter болон CI job-ууд нь мэдлэгийн сан шинэчлэгдсэн, харилцан холбогдсон, зөв бүтэцтэй эсэхийг шалгадаг. Тогтмол ажилладаг “doc-gardening” агент нь бодит кодын зан төлөвийг тусгаагүй хуучирсан эсвэл хүчингүй баримтуудыг сканнердаж, засварын татах хүсэлт нээдэг.

Кодын сан хөгжихийн хэрээр дизайны шийдвэр гаргахад Codex-ийн framework ч мөн өөрчлөгдөх шаардлагатай болсон.

Репозитор бүхэлдээ агент-үүсгэсэн учраас юуны өмнө Codex-д ойлгомжтой байхаар оновчлогдсон. Багууд шинэ инженерүүдэд кодоо ойлгомжтой болгохоор navigability-ийг сайжруулахыг зорьдогтой адил, манай хүний инженерүүдийн зорилго нь агент бизнесийн домэйныг репозитороос нь шууд тайлбарлан ойлгох боломжтой болгох байсан.

Агентын өнцгөөс харахад ажиллаж байх үедээ контекстэд нь хүрч чадахгүй юу ч байсан бараг оршдоггүйтэй адил. Google Docs, чат хэлхээ, эсвэл хүмүүсийн толгойд байдаг мэдлэг системд нэвтрэх боломжгүй. Репозитор доторх, version-той артефактууд (жишээ нь код, markdown, схемүүд, ажиллуулж болох төлөвлөгөөнүүд) бол түүний харж чадах бүх зүйл юм.

Цаг хугацаа өнгөрөх тусам бид улам их контекстийг repo руу түлхэх хэрэгтэйг ойлгосон. Архитектурын хэв маягийн талаар багийг нэг мөр болгосон тэр Slack хэлэлцүүлэг үү? Хэрэв агент түүнийг олж чадахгүй бол энэ нь гурван сарын дараа шинээр орсон ажилтанд үл мэдэгдэхтэй яг адилхан, агентын хувьд ойлгомжгүй хэвээр байна гэсэн үг.

Codex-д илүү их контекст өгөх нь агент дээр логик дүгнэлт хийхэд хэрэгтэй зөв мэдээллийг зохион байгуулж, ил гаргахыг хэлнэ, дур мэдэн өгсөн заавруудаар түүнийг дарахыг биш. Шинэ багийн гишүүнийг бүтээгдэхүүний зарчим, инженерийн хэм хэмжээ, багийн соёлд (emoji сонирхлыг хүртэл) онборд хийдэгтэй адил, энэ мэдээллийг агентад өгөх нь илүү сайн нийцсэн гарцад хүргэдэг.

Энэ хүрээлэл олон tradeoff-ыг тодруулсан. Бид repo дотор бүрэн шингээж, дээр нь логик дүгнэлт хийж болох dependency, abstraction-уудыг илүүд үзсэн. Ихэвчлэн “уйтгартай” гэж нэрлэгддэг технологиуд нь нэгтгэгдэх чадвар, api-ийн тогтвортой байдал, сургалтын багцад төлөөлөлтэй байдлаасаа болж агентуудад загварчлахад илүү амар байдаг. Зарим тохиолдолд нийтийн сангуудын opaque upstream зан төлөвийг тойрон гарахаас илүүтэй агентээр функцийн дэд хэсгүүдийг дахин хэрэгжүүлэх нь хямд байсан. Жишээлбэл, ерөнхий зориулалтын p-limit төрлийн багц татахын оронд бид concurrency-тэй map helper-ээ өөрсдөө хэрэгжүүлсэн: энэ нь манай OpenTelemetry instrumentation-тэй нягт уялдсан, 100% test coverage-тэй, манай runtime-ийн хүлээдэгтэй яг адил ажилладаг.

Системийн улам их хэсгийг агент шууд шалгаж, баталгаажуулж, өөрчилж чадах хэлбэрт оруулах нь зөвхөн Codex-д бус, кодын сантай ажиллаж буй бусад агентуудад ч (жишээ нь Aardvark) хөшүүргийг нэмэгдүүлдэг.

Зөвхөн баримтжуулалт нь бүрэн агент-үүсгэсэн кодын санг уялдаатай байлгаж чаддаггүй. Бид хэрэгжилт бүрийг хэт удирдах бус, тогтмол байх ёстой нөхцлүүдийг мөрдүүлснээр агентуудыг суурийг нь нураалгүй хурдан гаргах боломж олгодог. Жишээлбэл, бид Codex-ээс өгөгдлийн хэлбэрийг хил дээр parse хийхийг⁠(шинэ цонхонд нээгдэнэ) шаарддаг, гэхдээ яаж хийхийг нь нарийн заадаггүй (загвар Zod-д дуртай бололтой, гэхдээ бид тэр санг тусгайлан заагаагүй).

Агентууд хатуу хил, урьдчилан таамаглаж болох бүтэцтэй⁠(шинэ цонхонд нээгдэнэ) орчинд хамгийн үр дүнтэй ажилладаг тул бид аппликейшнийг хатуу архитектурын загвар дээр байгуулсан. Бизнесийн домэйн бүр тогтсон давхаргуудын багцад хуваагдаж, dependency-ийн чиглэл хатуу баталгаажсан, зөвшөөрөгдөх edge-үүдийн тоо хязгаартай байдаг. Эдгээр хязгаарлалтыг тусгай linter-үүд (мэдээж Codex-оор үүсгэсэн!) болон structural test-үүдээр механикаар мөрдүүлдэг.

Доорх диаграмм дүрмийг харуулж байна: бизнесийн домэйн бүрийн дотор (жишээ нь App Settings) код нь зөвхөн тогтсон давхаргын багцаар “урагш” хамаарч болно (Types → Config → Repo → Service → Runtime → UI). Хөндлөн огтлолын асуудлууд (auth, connector-ууд, telemetry, feature flag-ууд) нь ганцхан ил тод интерфейсээр орж ирнэ: Providers. Бусад бүх зүйл хориглогдсон бөгөөд механикаар мөрдүүлдэг.

Ийм төрлийн архитектурыг та ихэвчлэн хэдэн зуун инженертэй болтлоо хойшлуулдаг. Код бичдэг агентуудын үед энэ нь эрт үеийн урьдчилсан шаардлага болдог: хурдыг ялзрал, архитектурын drift-гүйгээр хадгалах боломжийг эдгээр хязгаарлалтууд олгодог.

Практикт бид эдгээр дүрмийг тусгай linter болон structural test-үүд, дээр нь цөөн хэдэн “амтын invariant”-аар мөрдүүлдэг. Жишээлбэл, structured logging, схем ба төрлүүдийн нэрлэх дүрэм, файлын хэмжээний хязгаар, платформд онцгой найдвартай байдлын шаардлагыг бид тусгай lint-үүдээр статик байдлаар мөрдүүлдэг. Lint-үүд тусгай тул алдааны мессежийг агентын контекстэд засах заавар шингээхээр бичдэг.

Хүн-эхний workflow-д эдгээр дүрэм хэтэрхий нарийн ширийн эсвэл хязгаарласан мэт санагдаж магадгүй. Агентуудын хувьд бол тэд үржүүлэгч болдог: нэгэнт кодолбол бүх газар нэгэн зэрэг үйлчилнэ.

Үүний зэрэгцээ, хязгаарлалт хаана чухал, хаана чухал бишийг бид ил тод заадаг. Энэ нь том инженерийн платформ байгууллагыг удирдахтай төстэй: хил хязгаарыг төвөөс мөрдүүлж, дотоод автономийг зөвшөөр. Та хил, зөв байдал, дахин давтагдах боломжид ихээхэн ач холбогдол өгнө. Тэр хил дотор багууд—эсвэл агентууд—шийдлээ хэрхэн илэрхийлэхдээ нэлээд эрх чөлөөтэй байна.

Үүссэн код нь хүний стилистик хүсэлд үргэлж таардаггүй, энэ нь зүгээр. Гарц зөв, арчлах боломжтой, цаашдын агент ажиллуулалтад ойлгомжтой байвал шаардлагыг хангаж байна гэсэн үг.

Хүний амтыг системд тасралтгүй буцаан оруулдаг. Review comment, refactor хийх татах хүсэлт, хэрэглэгчид харагдах алдаануудыг баримтжуулалтын шинэчлэлт болгон хадгалж эсвэл шууд хэрэгслүүдэд кодолдог. Баримтжуулалт хүрэлцэхгүй үед бид дүрмийг код руу шилжүүлдэг

Codex-ийн нэвтрүүлэх чадамж өсөхийн хэрээр уламжлалт инженерийн олон хэм хэмжээ эсрэг үр дүнтэй болсон.

Репозитор нь merge-ийг хаадаг хаалт маш багатай ажилладаг. Татах хүсэлтүүд богино настай. Test flake-ийг ахиц дэвшлийг тодорхойгүй хугацаагаар зогсоохын оронд дараагийн ажиллуулалтаар шийдэх нь элбэг. Агентын нэвтрүүлэх чадамж хүний анхаарлаас хавьгүй давсан системд засварууд хямд, хүлээлт үнэтэй байдаг.

Бага нэвтрүүлэх чадамжтай орчинд энэ нь хариуцлагагүй хэрэг байх байв. Харин энд энэ нь ихэвчлэн зөв tradeoff байдаг.

Бид кодын санг Codex агентууд үүсгэсэн гэж хэлэхдээ кодын сан дахь бүх зүйлийг хэлж байна.

Агентууд дараах зүйлсийг бий болгодог:

• Бүтээгдэхүүний код ба тестүүд
• CI тохиргоо ба release хэрэгслүүд
• Дотоод хөгжүүлэгчийн хэрэгслүүд
• Баримтжуулалт ба дизайны түүх
• Үнэлгээний harness-ууд
• Review comment ба хариултууд
• Репозиторыг өөрийг нь удирдах script-үүд
• Үйлдвэрлэлийн dashboard-ийн тодорхойлолтын файлууд

Хүмүүс үргэлж гогцоонд үлддэг ч өмнөхөөс өөр абстракцын түвшинд ажилладаг болсон. Бид ажлын эрэмбэ тогтоож, хэрэглэгчийн feedback-ийг acceptance criteria болгон хөрвүүлж, үр дүнг баталгаажуулдаг. Агент гацах үед бид үүнийг дохио гэж үздэг: юу дутуу байгааг—хэрэгсэл, guardrail, баримтжуулалт—олон, репозиторт буцаан оруулдаг, засварыг үргэлж Codex-оор өөрөөр нь бичүүлдэг.

Агентууд манай стандарт хөгжүүлэлтийн хэрэгслүүдийг шууд ашигладаг. Тэд review feedback-ийг татаж, inline хариулж, шинэчлэлт push хийж, олонтаа өөрсдийн татах хүсэлтийг squash хийж merge ч хийдэг.

Хөгжүүлэлтийн гогцооны улам их хэсгийг—тест, баталгаажуулалт, review, feedback боловсруулах, сэргээх—систем рүү шууд кодлохын хэрээр репозитор саяхан нэг чухал босгыг давж, Codex шинэ feature-ийг эхнээс нь дуустал жолоодох чадвартай болсон.

Одоо нэг өгөгдөл өгөгдвөл агент дараахыг хийж чадна:

• Кодын сангийн одоогийн төлөвийг баталгаажуулах
• Мэдээлэгдсэн алдааг давтан гаргах
• Алдааг харуулсан видео бичих
• Засвар хэрэгжүүлэх
• Аппликейшнийг жолоодон засварыг баталгаажуулах
• Шийдэгдсэнийг харуулсан хоёр дахь видео бичих
• Татах хүсэлт нээх
• Агент болон хүний feedback-д хариулах
• Build failure-ийг илрүүлж, засах
• Зөвхөн дүгнэлт шаардлагатай үед л хүн рүү escalation хийх
• Өөрчлөлтийг merge хийх

Энэ зан төлөв нь энэ репозиторын тодорхой бүтэц, хэрэгслээс ихээхэн хамаардаг бөгөөд ижил хэмжээний хөрөнгө оруулалтгүйгээр ерөнхийлөн хэрэглэж болно гэж үзэж болохгүй—ядаж одоохондоо.

Бүрэн агент автономи нь шинэ төрлийн асуудлуудыг бас бий болгодог. Codex репозиторт аль хэдийн байгаа хэв маягуудыг—even uneven or suboptimal ones—давтан үржүүлдэг. Цаг хугацааны явцад энэ нь зайлшгүй drift рүү хөтөлдөг.

Эхэндээ хүмүүс үүнийг гараар шийддэг байсан. Манай баг баасан гараг бүрийг (7 хоногийн 20%) “AI slop” цэвэрлэхэд зарцуулдаг байсан. Мэдээж энэ нь масштаблагдаагүй.

Үүний оронд бид “алтан зарчмууд” гэж нэрлэдэг зүйлсээ репозитор руу шууд кодолж эхэлсэн бөгөөд тогтмол цэвэрлэгээний процесс байгуулсан. Эдгээр зарчмууд нь цаашдын агент ажиллуулалтад кодын санг ойлгомжтой, нэг мөр байлгадаг байр суурьтай, механик дүрмүүд юм. Жишээлбэл: (1) invariant-уудыг төвлөрүүлэхийн тулд гараар хийсэн helper-үүдээс илүү shared utility package-уудыг илүүд үздэг, мөн (2) бид өгөгдлийг “YOLO маягаар” шалгадаггүй—хил дээр баталгаажуулдаг эсвэл typed SDK-д тулгуурладаг, ингэснээр агент таамагласан shape дээр санамсаргүй барилт хийхгүй. Тогтмол хуваарийн дагуу арын Codex даалгавруудын багц нь зөрчлүүдийг сканнердаж, чанарын үнэлгээг шинэчилж, чиглэсэн refactor татах хүсэлтүүд нээдэг. Эдгээрийн ихэнхийг минут хүрэхгүй хугацаанд review хийж, автоматаар merge хийж болно.

Энэ нь garbage collection шиг ажилладаг. Техникийн өр нь өндөр хүүтэй зээлтэй адил: түүнийг хуримтлуулах, дараа нь өвдөлттэй тэсрэлтээр шийдэхээс илүүтэйгээр бага багаар тасралтгүй төлөх нь бараг үргэлж дээр. Хүний амтыг нэг удаа барьж аваад, дараа нь кодын мөр бүр дээр тасралтгүй мөрдүүлдэг. Энэ нь мөн муу хэв маягийг өдрүүд, долоо хоногоор кодын санд тархаахаас өмнө өдөр тутам барьж, засах боломж өгдөг.

Энэ стратеги одоогоор OpenAI дахь дотоод нээлт, хэрэглээнд сайн ажилласан. Бодит хэрэглэгчдэд зориулсан бодит бүтээгдэхүүн бүтээсэн нь бидний хөрөнгө оруулалтыг бодит байдалд уяж, урт хугацааны арчилгаатай байдлын зүг чиглүүлэхэд тусалсан.

Одоогоор бидний мэдэхгүй зүйл гэвэл бүрэн агент-үүсгэсэн системд архитектурын уялдаа олон жилийн турш хэрхэн өөрчлөгдөх вэ гэдэг юм. Хүний дүгнэлт хамгийн их хөшүүрэг өгдөг цэг хаана байгааг, мөн тэр дүгнэлтийг хуримтлагдахуйц байдлаар хэрхэн кодлохоо бид одоо ч сурч байна. Мөн загварууд цаг хугацааны явцад улам чадварлаг болох тусам энэ систем хэрхэн хувьсахыг бид хараахан мэдэхгүй.

Тодорхой болсон зүйл нь: програм хангамж бүтээхэд сахилга бат одоо ч шаардлагатай хэвээр, гэхдээ энэ сахилга бат нь код дээр бус харин scaffold дээр илүү их илэрдэг болсон. Кодын санг уялдаатай байлгадаг хэрэгслүүд, абстракцууд, эргэх холбооны гогцоонууд улам бүр чухал болж байна.

Одоо бидний хамгийн хэцүү сорилтууд нь агентуудыг зорилгодоо хүрэхэд туслах орчин, эргэх холбооны гогцоо, хяналтын системүүдийг зохион бүтээхэд төвлөрч байна: цар хүрээтэй, найдвартай, төвөгтэй програм хангамжийг бүтээж, арчлах.

Codex шиг агентууд програм хангамжийн амьдралын мөчлөгийн улам том хэсгийг хариуцах тусам эдгээр асуултууд бүр ч чухал болно. Бид эрт үеийн зарим сургамжаа хуваалцах нь таны хүчин чармайлтаа хаашаа чиглүүлэхээ тунгаахад тусалж, ингэснээр та зүгээр л юм бүтээж чадна гэж найдаж байна.