Бид Codex-ийг ашиглан 28 хоногт Android-д зориулсан Sora-г хэрхэн бүтээсэн бэ

2026 оны 4-р сарын 26-ны байдлаар Sora бүтээгдэхүүн цаашид ашиглах боломжгүй болсон.

11-р сард бид Sora Android аппыг дэлхий даяар танилцуулж, Android төхөөрөмжтэй хэн бүхэнд богино өгөгдлийг тод видео болгон хувиргах боломжийг олгосон. Нээлтийн өдөр апп Play Store-д №1-т хүрсэн. Android хэрэглэгчид эхний 24 цагт нэг саяас олон видео үүсгэсэн.

Энэ нээлтийн цаана нэг түүх бий: Sora-ийн Android продакшн аппын анхны хувилбарыг 28 хоногт бүтээсэн бөгөөд үүнд ямар ч баг, хөгжүүлэгч ашиглаж болох тэр л агент болох Codex тус болсон.

2025 оны 10-р сарын 8-наас 11-р сарын 5 хүртэл Codex-тэй хамтран ажилласан, ойролцоогоор 5 тэрбум токен ашигласан цомхон инженерийн баг Sora for Android-ийг прототипоос дэлхий дахины нээлт хүртэл хүргэсэн. Хэмжээний хувьд том байсан ч аппын гацалтгүй ажиллах түвшин 99.9 хувь байсан бөгөөд бидний бахархдаг архитектуртай болсон. Хэрэв бид нууц загвар ашигласан уу гэж та бодож байвал, бид GPT‑5.1‑Codex загварын эхэн үеийн хувилбарыг ашигласан — энэ нь өнөөдөр ямар ч хөгжүүлэгч эсвэл байгууллага CLI, IDE өргөтгөл, эсвэл вэб аппаар ашиглаж болох яг тэр хувилбар юм.

Sora iOS дээр нээгдэхэд хэрэглээ огцом өссөн. Хүмүүс тэр даруй тасралтгүй видео үүсгэж эхэлсэн. Харин Android дээр бидэнд дотоод жижиг прототип, мөн Google Play дээр урьдчилан бүртгүүлсэн хэрэглэгчдийн өсөн нэмэгдэж буй тоо л байсан.

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

Америкийн компьютерийн архитектор Фред Брукс “хоцорч яваа програм хангамжийн төсөлд илүү олон хүн нэмбэл бүр ч хоцордог” гэж алдартайгаар анхааруулсан. Өөрөөр хэлбэл, төвөгтэй төслийг хурдан хүргэх гэж оролдох үед олон инженер нэмэх нь харилцааны ачаалал, ажлын бутрал, интеграцийн зардлыг нэмснээр үр ашгийг ихэвчлэн сааруулдаг. Бид энэ санааг үл тоомсорлолгүйгээр ашигласан; инженер бүрийн нөлөөг эрс нэмэгдүүлэх Codex-ээр тоноглогдсон дөрвөн хүчтэй инженерээс бүрдсэн багийг бүрдүүлсэн.

Ингэж ажилласнаар бид Sora for Android-ийн дотоод хувилбарыг 18 хоногийн дотор ажилтнуудад хүргэж, 10 хоногийн дараа олон нийтэд нээлээ. Бид Android инженерчлэлийн практикт өндөр босго баримталж, засвар үйлчилгээний чадварт хөрөнгө оруулж, уламжлалт төслөөс хүлээхтэй адил найдвартай байдлын түвшинд аппыг хүргэсэн. (Мөн өнөөдөр ч бид аппыг хөгжүүлж, шинэ боломжууд нэмэхдээ Codex-ийг өргөн ашигласаар байна).

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

Codex-д хаана чиглэл хэрэгтэй вэ

1. Codex одоогоор өөрт нь хэлж өгөөгүй зүйлийг (жиш., таны илүүд үздэг архитектурын хэв маяг, бүтээгдэхүүний стратеги, бодит хэрэглэгчийн зан төлөв, дотоод хэм хэмжээ эсвэл товчлол) сайн таамаглаж чаддаггүй.
2. Үүнтэй адил Codex аппыг бодитоор ажиллаж байгааг харж чаддаггүй байсан: төхөөрөмж дээр Sora-г нээж, гүйлгэх хөдөлгөөн эвгүй байгааг анзаарах, эсвэл урсгал ойлгомжгүй байгааг мэдрэх боломжгүй. Ийм туршлагын шинжтэй ажлуудыг зөвхөн манай баг хийж чадна.
3. Тухай бүрт ажлын орчинд оруулах хэрэгтэй. Тодорхой зорилго, хязгаарлалт, мөн “бид юмыг яаж хийдэг вэ” гэсэн заавартай контекст хуваалцах нь Codex-ийг сайн ажиллуулахад зайлшгүй байсан.
4. Мөн энэ адилаар Codex гүн архитектурын шүүлт дээр бэрхшээлтэй байсан: өөрт нь орхивол бидэнд одоо байгаа view model-ийг өргөтгөх нь зөв байхад илүү view model нэмэх, эсвэл репозиторт харьяалагдах логикийг UI давхарга руу түлхэх магадлалтай. Түүний зөн совин нь урт хугацааны цэгцтэй байдлыг бус, ямар нэг байдлаар ажиллуулж өгөхөд чиглэдэг.

Codex-ээр кодын санд олон AGENT.md файл үүсгэж, арчлах нь бидэнд хэрэгтэй санагдсан. Ингэснээр ижил заавар, шилдэг практикуудыг олон сешний турш хэрэгжүүлэхэд амар болсон. Жишээлбэл, Codex-ийг манай хэв маягийн удирдамжийн дагуу код бичүүлэхийн тулд бид дээд түвшний AGENTS.md файлдаа дараахыг нэмсэн:

Codex юунд онцгой сайн бэ

1. Том кодын санг хурдан уншиж, ойлгох: Codex бараг бүх гол програмчлалын хэлийг мэддэг тул төвөгтэй хийсвэрлэлгүйгээр ижил ойлголтуудыг олон платформ дээр ашиглахад хялбар болгодог.
2. Тестийн хамрах хүрээ: Codex олон янзын тохиолдлыг хамарсан нэгж тест бичихдээ (онцгой байдлаар) маш дуртай. Бүх тест гүн биш байсан ч өргөн хамрах хүрээ нь регрессээс сэргийлэхэд тустай байсан.
3. Санал хүсэлт хэрэгжүүлэх: Үүнтэй төстэйгээр Codex санал хүсэлтэд сайн хариу үзүүлдэг. CI бүтэлгүйтэхэд бид логийн гаралтыг өгөгдөлд хуулж, засвар санал болгохыг Codex-оос хүсдэг байв.
4. Асар их хэмжээнд зэрэгцээ, нэг удаагийн гүйцэтгэл: Нэг дор хэдэн сешн ажиллуулж болохынхоо дээд хязгаарыг олон хүн тулгахгүй байх. Олон санааг зэрэг туршиж, кодыг нэг удаагийн зүйл мэт үзэх нь бүрэн боломжтой.
5. Шинэ өнцөг санал болгох: Дизайны хэлэлцүүлгийн үед бид Codex-ийг алдаа гарах боломжит цэгүүдийг судалж, асуудлыг шийдэх шинэ аргууд олоход ашигладаг үүсгэгч хэрэгсэл болгон ашигласан. Жишээлбэл, видео тоглуулагчийн санах ойн оновчлолыг боловсруулах үед Codex олон SDK-г шүүж, бидэнд судалж амжихгүй байсан аргуудыг санал болгосон. Codex-ийн судалгаанаас гарсан ойлголтууд эцсийн аппын санах ойн ул мөрийг багасгахад үнэлж баршгүй тус болсон.
6. Илүү өндөр үр нөлөөтэй ажлыг боломжтой болгох: Практик дээр бид кодыг өөрсдөө бичихээс илүү шалгаж, чиглүүлэхэд илүү их цаг зарцуулсан. Гэхдээ Codex кодын хяналтад ч маш сайн бөгөөд нэгдэхээс нь өмнө алдааг олонтаа илрүүлж, найдвартай байдлыг сайжруулдаг.

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

Хамгийн шилдэг шинэ ахлах ажилтан хүртэл урт хугацааны буултуудыг шууд зөв шийдэх өнцөг хараахан олж амжаагүй байдаг. Codex-ийг үр дүнтэй ашиглаж, түүний ажлыг бат бөх, арчлахад хялбар байлгахын тулд аппын системийн дизайн болон гол буултуудыг бид өөрсдөө хянах нь чухал байсан. Үүнд аппын архитектур, модульчлал, dependency injection, navigation-ийг тодорхойлох; мөн бид баталгаажуулалт болон сүлжээний суурь урсгалуудыг хэрэгжүүлсэн.

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

Зорилго нь аль болох хурдан “ажилладаг зүйл” хийх бус, харин “бид юмсыг яаж ажиллуулахыг хүсдэгийг ойлгодог зүйл” хийх байсан. Код бичих “зөв” олон арга бий. Бид Codex-д яг юу хийхийг нэг бүрчлэн хэлэх шаардлагагүй байсан; харин манай багт юу нь “зөв” болохыг харуулах хэрэгтэй байв. Бид эхлэх цэгээ, мөн хэрхэн бүтээх дуртайгаа тогтоосны дараа Codex ажиллаж эхлэхэд бэлэн болсон.

Юу болохыг харахын тулд бид “iOS код дээр үндэслээд Sora Android аппыг бүтээ. Эхэл” гэж өгөгдөл өгч үзсэн ч тэр замыг хурдан зогсоосон. Codex-ийн бүтээсэн зүйл техникийн хувьд ажиллаж байсан ч бүтээгдэхүүний туршлага хангалтгүй байв. Мөн эцсийн цэгүүд, өгөгдөл, хэрэглэгчийн урсгалын талаар тодорхой ойлголтгүй тул Codex-ийн нэг удаагийн код найдвартай биш байсан (агент ашиглахгүй байсан ч мянга мянган мөр кодыг нэгтгэх нь эрсдэлтэй).

Сайн бичигдсэн жишээнүүдийн sandbox орчинд Codex илүү сайн ажиллана гэж бид таамагласан; мөн бид зөв байсан. Бараг ямар ч контекстгүйгээр Codex-оос “энэ тохиргооны дэлгэцийг бүтээ” гэж хүсэх нь найдвартай биш байв. Харин “чиний сая харсан нөгөө дэлгэцтэй ижил архитектур, хэв маягийг ашиглаад энэ тохиргооны дэлгэцийг бүтээ” гэж хүсэхэд 훨씬 илүү үр дүнтэй байсан. Хүмүүс бүтцийн шийдвэрүүдийг гаргаж, тогтмол нөхцлүүдийг тогтоосон; дараа нь Codex тэр бүтцийн дотор их хэмжээний кодыг дүүргэсэн.

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

Codex-ийг ашиглаж эхэлж байх үедээ бид “Энэ бол боломж. Эдгээр нь файлууд. Үүнийг хийгээрэй” гэх мэт өгөгдөл рүү шууд үсэрдэг байсан. Энэ нь заримдаа ажилласан ч ихэнхдээ техникийн хувьд компайлддаг мөртлөө манай архитектур, зорилгоос хазайсан код үүсгэдэг байв.

Тиймээс бид ажлын урсгалаа өөрчилсөн. Тривиал биш аливаа өөрчлөлтийн өмнө бид эхлээд Codex-оос систем, код хэрхэн ажилладгийг ойлгоход туслахыг хүсдэг болсон. Жишээлбэл, холбоотой файлуудын багцыг уншиж тухайн боломж хэрхэн ажилладгийг — тухайлбал өгөгдөл API-гаас репозитор давхарга, view model, улмаар UI руу хэрхэн урсдгийг — дүгнэхийг хүсдэг байв. Дараа нь бид түүний ойлголтыг засаж, нарийвчилдаг байсан. (Жишээ нь, тодорхой нэг хийсвэрлэл үнэндээ өөр давхаргад харьяалагдах ёстой, эсвэл нэг класс зөвхөн офлайн горимд зориулсан тул өргөтгөх ёсгүй гэдгийг заадаг байсан.)

Шинээр ирсэн, өндөр чадвартай багийн гишүүнтэй ажиллахтай адил бид Codex-тэй хамтран бат бөх хэрэгжүүлэх төлөвлөгөө боловсруулсан. Тэр төлөвлөгөө нь ихэвчлэн ямар файлууд өөрчлөгдөх, ямар шинэ төлөвүүд нэмэгдэх, логик хэрхэн урсахыг чиглүүлсэн жижиг загварын баримт бичиг шиг харагддаг байв. Зөвхөн үүний дараа л бид Codex-оос төлөвлөгөөг алхам алхмаар хэрэгжүүлж эхлэхийг хүсдэг байсан. Нэг хэрэгтэй зөвлөгөө: маш урт ажлууд дээр, контекст цонхны хязгаарт хүрэх үед бид Codex-оос төлөвлөгөөгөө файлд хадгалахыг хүсэж, ингэснээр ижил чиглэлийг олон инстанц дээр хэрэгжүүлэх боломжтой болдог байсан.

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

Энэ динамик нь сайн загварын баримт бичиг tech lead-д төслийн талаарх итгэл өгдөг аргатай төстэй санагдсан. Бид зүгээр л код үүсгээд байсангүй: бид хамтын замын зураглалыг дэмжих код бүтээж байсан.

Төслийн оргил үед бид олон Codex сешнийг зэрэг ажиллуулж байсан. Нэг нь playback дээр, нөгөө нь хайлт дээр, өөр нэг нь алдааны боловсруулалт дээр, заримдаа бас нэг нь тест эсвэл рефактор дээр ажиллаж байв. Энэ нь хэрэгсэл ашиглаж байгаа мэт бус, баг удирдаж байгаа мэт санагддаг байсан.

Сешн бүр үе үе ахицынхаа талаар бидэнд тайлагнана. Нэг нь “Би энэ модулийн төлөвлөлтийг дуусгалаа; миний санал ийм байна” гэж хэлэх бол, нөгөө нь шинэ боломжийн том diff санал болгоно. Аль аль нь анхаарал, санал хүсэлт, хяналт шаарддаг байв. Энэ нь яг л хэд хэдэн шинэ инженер удирдаж, бүгд ахиц гаргаж, бүгд чиглэл шаарддаг tech lead байхтай хачин төстэй байсан.

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

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

Энд Brooks-ийн ойлголт шинэ байдлаар биелж байна. Та инженерүүдийг төсөлд нэмсээр байгаад хуваарь шугаман байдлаар богиносно гэж найдаж болдоггүйтэй адил Codex-ийн сешнүүдийг зүгээр л нэмж, шугаман хурдны өсөлт хүлээж болохгүй. Нэмэлт “гар бүр”, виртуал байсан ч гэсэн, уялдаа зохицуулалтын зардал нэмдэг. Бид ердөө илүү хурдан ганцаарчилсан тоглогчид бус, харин найрал хөгжмийн удирдаач болсон байлаа.

Манай төсөл асар том давуу талаас эхэлсэн: Sora аль хэдийн iOS дээр гарсан байсан. Бид Codex-ийг iOS болон backend кодын сан руу байнга чиглүүлж, гол шаардлага ба хязгаарлалтуудыг ойлгуулахад ашигласан. Төслийн туршид бид кросс-платформ фреймворкийн санааг шинээр нээчихлээ гэж хошигнодог байсан. React Native, Flutter-ийг март; кросс-платформын ирээдүй бол зүгээр л Codex.

Энэ хошигнолын цаана хоёр зарчим бий:.

1. Логик зөөврийн. Код Swift эсвэл Kotlin-оор бичигдсэн эсэхээс үл хамааран үндсэн аппын логик — өгөгдлийн загвар, сүлжээний дуудлага, баталгаажуулалтын дүрэм, бизнес логик — ижил байдаг. Codex Swift хэрэгжилтийг уншаад утгыг нь хадгалсан Kotlin эквивалентыг гаргахад маш сайн.
2. Тодорхой жишээнүүд хүчтэй контекст өгдөг. “Энэ iOS дээр яг ингэж ажилладаг” болон “Android архитектур нь ийм” гэдгийг харж чадах шинэ Codex сешн зөвхөн байгалийн хэлний тайлбараас ажиллаж байгаагаас хавьгүй илүү үр дүнтэй.

Эдгээр зарчмыг ажил хэрэг болгохын тулд бид iOS, backend, Android репозиторуудыг нэг орчинд ашиглах боломжтой болгосон. Бид Codex-д дараах мэт өгөгдөл өгдөг байсан:

“iOS код дахь эдгээр загварууд болон эцсийн цэгүүдийг уншаад, дараа нь манай одоо байгаа API client болон загвар классуудыг ашиглан Android дээр ижил зан төлөвийг хэрэгжүүлэх төлөвлөгөө санал болго.”

Нэг жижиг боловч хэрэгтэй арга бол ~/.codex/AGENTS.md-д локал репозиторууд хаана байрладаг, юу агуулдгийг нарийвчлан бичих явдал байсан. Ингэснээр Codex холбогдох кодыг олох, чиглүүлэхэд илүү хялбар болсон.

Бид үндсэндээ хамтын хийсвэрлэлийн оронд орчуулгаар дамжуулан кросс-платформ хөгжүүлэлт хийж байсан. Codex орчуулгын ихэнхийг хийсэн тул бид хэрэгжилтийн зардлыг хоёр дахин өсгөхөөс зайлсхийсэн.

Илүү өргөн сургамж нь Codex-ийн хувьд контекст бол бүх зүйл гэсэн үг. Codex тухайн боломж iOS дээр хэрхэн ажилладгийг, мөн манай Android апп хэрхэн бүтэцлэгдсэнийг ойлгосон үедээ хамгийн сайн ажилласан. Codex-д тэр контекст дутах үед “хамтран ажиллахаас татгалзаж” байсан хэрэг биш; зүгээр л таамаглаж байсан. Бид түүнийг шинэ багийн гишүүн мэт үзэж, зөв оролтууд өгөхөд хөрөнгө оруулах тусам улам сайн ажилласан.

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

AI-гаар дэмжигдсэн хөгжүүлэлт нь нягт нямбай байдал хэрэггүй болгодоггүй, харин илүү чухал болгодог нь тодорхой болсон. Codex ямар чадвартай байлаа ч түүний зорилго бол яг одоо A-гаас B хүртэл очих. Тиймээс л AI-гаар дэмжигдсэн кодчилол хүмүүстэй хамтгүйгээр ажилладаггүй. Програм хангамжийн инженерүүд системийн бодит ертөнцийн хязгаарлалтыг ойлгож, хэрэгжүүлж, програм хангамжийг хамгийн зөвөөр архитектурчилж, ирээдүйн хөгжүүлэлт болон бүтээгдэхүүний төлөвлөгөөг харгалзан бүтээж чадна. Маргаашийн програм хангамжийн инженерийн супер хүч нь системийн гүн ойлголт болон AI-тай урт хугацааны турш хамтран ажиллах чадвар байх болно.

Програм хангамжийн инженерчлэлийн хамгийн сонирхолтой хэсгүүд нь сэтгэл татам бүтээгдэхүүн бүтээх, өргөтгөх боломжтой систем зохиох, төвөгтэй алгоритм бичих, өгөгдөл, хэв маяг, кодтой туршилт хийх явдал юм. Гэвч өнгөрсөн ба одоогийн програм хангамжийн инженерчлэлийн бодит байдал ихэвчлэн илүү энгийн зүйлс рүү хазайдаг: товчийг голлуулах, эцсийн цэгүүдийг холбоход, boilerplate код бичихэд. Харин одоо Codex нь програм хангамжийн инженерчлэлийн хамгийн утга учиртай хэсгүүд болон бид яагаад энэ мэргэжлээ хайрладгийг төвлөрөх боломжийг олгож байна.

Codex-ийг зорилгоо болон хэрхэн бүтээх дуртайгаа ойлгодог, контекстоор баялаг орчинд зөв тохируулсны дараа ямар ч баг боломжоо хэд дахин өсгөж чадна. Манай нээлтийн эргэн дүгнэлт бол бүгдэд таарах нэг жор биш, мөн бид AI-гаар дэмжигдсэн хөгжүүлэлтийг бүрэн шийдсэн гэж мэдэгдэхгүй. Гэхдээ бидний туршлага Codex-ийг танд хүч өгөхөд хамгийн сайн аргуудыг олоход тусална гэж найдаж байна.

Codex долоон сарын өмнө судалгааны preview хэлбэрээр нээгдэхэд програм хангамжийн инженерчлэл маш өөр харагдаж байсан. Sora-гийн ачаар бид инженерчлэлийн дараагийн бүлгийг судлах боломжтой болсон. Манай загварууд болон harness улам сайжрах тусам AI нь бүтээх ажлын улам бүр орлуулшгүй хэсэг болно.

Та өөрийн Codex багаараа юу бүтээх вэ?