Ինչպես մենք օգտագործեցինք Codex-ը՝ Android-ի համար Sora-ն կառուցելու 28 օրվա ընթացքում
Փատրիկ Հում և ՌՋ Մարսան, Տեխնիկական անձնակազմի անդամներ
Սկսած 26 ապրիլի, 2026 թ.-ից, Sora ապրանքը այլևս հասանելի չէ։
Նոյեմբերին մենք աշխարհին ներկայացրեցինք Sora Android հավելվածը, որը թույլ է տալիս ցանկացած Android սարքի օգտատիրոջ՝ կարճ հարցումը վերածել վառ տեսանյութի։ Գործարկման օրը հավելվածը հասավ 1-ին տեղը Play Store-ում։ Android-ի օգտատերերը գեներացրեցին ավելի քան մեկ միլիոն տեսանյութ առաջին 24 ժամվա ընթացքում։
Մեկնարկի հետևում կա մի պատմություն. Sora-ի արտադրական Android հավելվածի նախնական տարբերակը կառուցվել է 28 օրվա ընթացքում՝ շնորհիվ այն նույն ագենտի, որը հասանելի է ցանկացած թիմի կամ ծրագրավորողի համար՝ Codex։
2025 թվականի հոկտեմբերի 8-ից նոյեմբերի 5-ը Codex-ի հետ համատեղ աշխատող և մոտ 5 միլիարդ թոքեն սպառող մի խումբ ինժեներական թիմ Android-ի համար նախատեսված Sora-ն նախատիպից մինչև համաշխարհային թողարկում իրականացրեց։ Չնայած իր մասշտաբին, հավելվածն ունի 99,9 տոկոս անխափան գործարկման ցուցանիշ և ճարտարապետություն, որով մենք հպարտ ենք։ Եթե հետաքրքրված եք, թե արդյոք մենք օգտագործել ենք գաղտնի մոդել, ապա մենք օգտագործել ենք GPT‑5.1‑Codex մոդելի վաղ տարբերակը՝ նույն տարբերակը, որն այսօր կարող է օգտագործել ցանկացած մշակող կամ բիզնես CLI-ի, IDE ընդլայնման կամ վեբ հավելվածի միջոցով։
Prompt: figure skater performs a triple axle with a cat on her head
Երբ Sora-ն գործարկվեց iOS-ում, օգտագործումը կտրուկ աճեց։ Մարդիկ անմիջապես սկսեցին գեներացնել տեսանյութերի հոսք։ Android-ի դեպքում, ի տարբերություն, մենք ունեինք միայն փոքր ներքին նախատիպ և Google Play-ում նախապես գրանցված օգտատերերի աճող թիվ։
Բարձր ռիսկային, ժամանակի սղությամբ գործարկման դեպքում սովորական արձագանքը ռեսուրսների ու գործընթացի ավելացումն է: Այս ծավալի և որակի արտադրական հավելվածը սովորաբար կպահանջի բազմաթիվ ինժեներների աշխատանք ամիսներով, որը դանդաղեցվում է համակարգված աշխատանքի պատճառով։
Ամերիկացի համակարգչային ճարտարապետ Ֆրեդ Բրուքսը հայտնի է իր նախազգուշացմամբ, որ «ավելի շատ մարդկանց ավելացնել ուշացած ծրագրային նախագծին այն ավելի ուշացնում է»։ Այլ կերպ ասած, երբ փորձում եք արագ առաքել բարդ նախագիծ, ավելի շատ ինժեներներ ավելացնելը հաճախ կարող է դանդաղեցնել արդյունավետությունը՝ ավելացնելով հաղորդակցության ծախսերը, առաջադրանքների մասնատումը և ինտեգրման ծախսերը։ Մենք հենվեցինք այս մտքի վրա՝ այն անտեսելու փոխարեն. մենք հավաքեցինք չորս ինժեներներից բաղկացած ուժեղ թիմ՝ բոլորն էլ հագեցած Codex-ով՝ յուրաքանչյուր ինժեների ազդեցությունը կտրուկ բարձրացնելու համար:
Այս կերպ աշխատելով՝ մենք Android-ի համար նախատեսված Sora-ի ներքին տարբերակը աշխատակիցներին ուղարկեցինք 18 օրում և 10 օր անց այն հրապարակայնորեն թողարկեցինք։ Մենք պահպանեցինք բարձր նշաձող Android-ի ինժեներական պրակտիկաների համար, ներդրումներ կատարեցինք պահպանելիության մեջ և հավելվածը պահեցինք նույն հուսալիության նշաձողին, ինչպիսին կսպասեինք ավելի ավանդական նախագծից։ (Մենք նաև այսօր լայնորեն օգտագործում ենք Codex-ը՝ հավելվածի նոր հնարավորությունները զարգացնելու և ավելացնելու համար):
Որպեսզի հասկանանք, թե ինչպես ենք աշխատել Codex-ի հետ, օգտակար է իմանալ, թե որոնք են դրա ուժեղ կողմերը և որտեղ է այն բարելավման կարիք ունենում։ Դրան վերաբերվելը որպես նոր ընդունված ավագ ինժեներ՝ լավ մոտեցում էր։ Codex-ի ունակությունը նշանակում էր, որ մենք կարող էինք ավելի շատ ժամանակ հատկացնել կոդի ուղղորդմանը և վերանայմանը, քան այն ինքներս գրելու վրա։
Որտեղ Codex-ը կարիք ունի ուղղորդման
- Codex-ը դեռևս լավ չի կարողանում եզրակացություններ անել այն մասին, ինչը նրան չի ասվել (օրինակ՝ ձեր նախընտրած ճարտարապետական օրինաչափությունները, ապրանքի ռազմավարությունը, իրական օգտատիրոջ վարքագիծը և ներքին նորմերը կամ կարճ ճանապարհները):
- Նմանապես, Codex-ը չէր կարող տեսնել, թե ինչպես է հավելվածն իրականում աշխատում. այն չէր կարող բացել Sora-ն սարքի վրա, նկատել, որ ոլորումը անհարմար է, կամ զգալ, որ հոսքը շփոթեցնող է։ Միայն մեր թիմը կարող էր կատարել այս փորձառական առաջադրանքները։
- Յուրաքանչյուր դեպք պահանջում է գրանցում: Համատեքստի, հստակ նպատակների, սահմանափակումների և «ինչպես ենք մենք անում բաները» վերաբերյալ ուղեցույցի կիսումը կարևոր էր Codex-ը լավ գործարկելու համար։
- Նույն ոգով, Codex-ը դժվարանում էր խորը ճարտարապետական դատողության հետ. մենակ մնալով՝ այն կարող էր ներմուծել լրացուցիչ տեսքի մոդել, որտեղ մենք իրականում կցանկանայինք ընդլայնել արդեն իսկ գոյություն ունեցողը կամ տրամաբանություն մտցնել UI շերտ, որը հստակորեն պատկանում էր պահոցին։ Դրա բնազդը ինչ-որ բան աշխատեցնելն է, ոչ թե երկարաժամկետ մաքրությունը առաջնահերթություն դարձնելը։
Մենք օգտակար համարեցինք, որ Codex-ը ստեղծի և պահպանի AGENT.md ֆայլերի մեծ քանակություն ամբողջ կոդային բազայում։ Սա հեշտացրեց նույն ուղեցույցներն ու լավագույն փորձառությունները կիրառել բոլոր աշխատաշրջաններում։ Օրինակ, որպեսզի Codex-ը գրի մեր ոճի ուղեցույցներին համապատասխան կոդը, մենք մեր բարձր մակարդակի AGENTS.md ֆայլում ավելացրեցինք հետևյալը.
Որտեղ է Codex-ը գերազանցում
- Մեծ կոդային բազաները արագ ընթերցելն ու հասկանալը։ Codex-ը գիտի հիմնականում բոլոր հիմնական ծրագրավորման լեզուները, ինչը հեշտացնում է նույն հասկացությունները կիրառել բազմաթիվ հարթակներում՝ առանց բարդ աբստրակցիաների։
- Փորձարկման ծածկույթ։ Codex-ը (եզակի) կրքոտ մոտեցում է ցուցաբերում միավորային թեստեր գրելու հարցում, որոնք ընդգրկում են օգտագործման դեպքերի լայն շրջանակ։ Ոչ բոլոր թեստերը խորքային էին, բայց ծածկույթի լայնությունը օգտակար էր ռեգրեսիաները կանխելու համար։
- Հետադարձ կապի կիրառումը. Նմանատիպ ձևով, Codex-ը լավ է արձագանքում հետադարձ կապին։ Երբ CI-ն ձախողվեց, մենք կարող էինք մուտքագրել մատյանների արտածումը հարցման մեջ և խնդրել Codex-ին առաջարկել շտկումներ։
- Զանգվածային զուգահեռ, ժամանակավոր կատարում։ Մեծ մասը չի գերազանցի միաժամանակյա աշխատաշրջանների քանակը։ Շատ հնարավոր է զուգահեռաբար փորձարկել մի քանի գաղափարներ և կոդը դիտարկել որպես միանգամյա օգտագործման։
- Նոր հեռանկարի առաջարկ։ Դիզայնի քննարկումներում մենք օգտագործեցինք Codex-ը որպես գեներատիվ գործիք՝ հնարավոր ձախողման կետերը ուսումնասիրելու և խնդիրը լուծելու նոր եղանակներ հայտնաբերելու համար։ Օրինակ, երբ մենք նախագծում էինք վիդեո նվագարկչի հիշողության օպտիմալացումները, Codex-ը զննում էր բազմաթիվ SDK-ներ՝ առաջարկելու այնպիսի մոտեցումներ, որոնք մենք ժամանակ չէինք ունենա վերլուծելու։ Codex-ի հետազոտության արդյունքները անգնահատելի էին հավելվածի վերջնական տարբերակում հիշողության ծավալը նվազեցնելու համար։
- Ավելի բարձր արդյունավետությամբ աշխատանքի հնարավորություն։ Գործնականում մենք ավելի շատ ժամանակ ենք ծախսում կոդի վերանայման և ուղղորդման վրա, քան այն ինքներս գրելու վրա։ Այդուհանդերձ, Codex-ը նույնպես շատ լավ է կոդի վերանայման մեջ՝ հաճախ հայտնաբերելով սխալները նախքան դրանց միավորումը՝ բարելավելով հուսալիությունը։
Երբ մենք ընդունեցինք այս հատկությունները, մեր աշխատանքային մոդելը դարձավ ավելի պարզեցված։ Մենք հենվեցինք Codex-ի վրա՝ լավ հասկացված օրինաչափությունների և հստակ սահմանափակված շրջանակների ներսում հսկայական ծավալի աշխատանք կատարելու համար, մինչդեռ մեր թիմը կենտրոնացավ ճարտարապետության, օգտատիրոջ փորձի, համակարգային փոփոխությունների և վերջնական որակի վրա։
Նույնիսկ լավագույն նոր, ավագ աշխատակիցը անմիջապես չունի երկարաժամկետ փոխզիջումների համար ճիշտ տեսանկյունը։ Codex-ը օգտագործելու և նրա աշխատանքը ամուր և պահպանելի դարձնելու համար կարևոր էր, որ մենք ինքներս վերահսկեինք հավելվածի համակարգերի նախագծումը և հիմնական փոխզիջումները։ Սրանք ներառում էին հավելվածի ճարտարապետության ձևավորումը, մոդուլյարացումը, կախվածությունների ներարկումը և նավիգացիան. մենք նաև իրականացրեցինք նույնականացում և հիմնական ցանցային հոսքեր։
Այս հիմքի վրա մենք գրել ենք մի քանի ներկայացուցչական ֆունկցիաներ՝ սկզբից մինչև վերջ։ Մենք օգտագործեցինք այն կանոնները, որոնք ցանկանում էինք, որ ամբողջ կոդային բազան հետևի, և նախագծի ընթացքում փաստագրեցինք նախագծի լայնածավալ ձևերը: Codex-ին ներկայացնելով ներկայացուցչական առանձնահատկություններ, այն կարողացավ ավելի ինքնուրույն աշխատել մեր չափանիշների շրջանակներում։ Նախագծի համար, որը մենք գնահատում ենք, որ 85%-ով գրվել է Codex-ի կողմից, մանրակրկիտ պլանավորված հիմքը թույլ տվեց խուսափել թանկարժեք հետադարձ քայլերից և վերակառուցումից։ Դա մեր կայացրած ամենակարևոր որոշումներից մեկն էր։
Գաղափարն այն չէր, որ հնարավորինս արագ ստեղծվեր «ինչ-որ բան, որը կաշխատի», այլ՝ ստեղծվեր «ինչ-որ բան, որը կաշխատի այնպես, ինչպես մենք ուզում ենք»։ Կոդ գրելու շատ «ճիշտ» եղանակներ կան։ Մեզ անհրաժեշտ չէր Codex-ին ճշգրիտ ասել, թե ինչ անել, մեզ անհրաժեշտ էր Codex-ին ցույց տալ, թե ինչն է «ճիշտ» մեր թիմում։ Երբ մենք որոշեցինք մեր մեկնարկային կետը և կառուցման մեր նախընտրած ձևը, Codex-ը պատրաստ էր սկսելու։
Տեսնելու համար, թե ինչ կպատահի, մենք փորձեցինք հարցում տալ. «Կառուցիր Sora Android հավելվածը՝ հիմնվելով iOS կոդի վրա»։ Go, բայց արագորեն հրաժարվեց այդ ուղուց։ Թեև Codex-ի ստեղծածը տեխնիկապես աշխատում էր, պրոդուկտի փորձը բավարար չէր: Եվ առանց վերջնակետերի, տվյալների և օգտատերերի հոսքերի հստակ ըմբռնման, Codex-ի միանվագ կոդը անվստահելի էր (նույնիսկ առանց ագենտի օգտագործման, ռիսկային է միավորել հազարավոր տողերի կոդը):
Մենք ենթադրում էինք, որ Codex-ը կզարգանա լավ գրված օրինակների պաշտպանված միջավայրում, և մենք ճիշտ էինք։ Codex-ին գրեթե առանց համատեքստի «կառուցել այս կարգավորումների էկրանը» խնդրելը անհուսալի էր։ Codex-ին խնդրելը «կառուցել այս կարգավորումների էկրանը՝ օգտագործելով նույն ճարտարապետությունն ու օրինաչափությունները, ինչ այս մյուս էկրանը, որը դուք հենց նոր տեսաք», շատ ավելի լավ աշխատեց։ Մարդիկ կայացնում էին կառուցվածքային որոշումներ և սահմանում անփոփոխները, այնուհետև Codex-ը մեծ քանակությամբ կոդ էր լրացնում այդ կառուցվածքի ներսում։
Codex-ի ներուժը մաքսիմալացնելու մեր հաջորդ քայլը պարզելն էր, թե ինչպես կարելի է Codex-ին հնարավորություն տալ աշխատել երկար ժամանակահատվածներում (վերջերս՝ ավելի քան 24 ժամ), առանց հսկողության։
Codex-ի օգտագործման սկզբնական փուլերում մենք անցանք հարցումների, օրինակ՝ «Ահա ֆունկցիան։ Ահա մի քանի ֆայլեր։ Կառուցիր այն»։ Դա երբեմն աշխատում էր, բայց հիմնականում ստեղծում էր կոդ, որը տեխնիկապես կոմպիլացվում էր, սակայն շեղվում էր մեր ճարտարապետությունից և նպատակներից։
Այսպիսով, մենք փոխեցինք աշխատանքային հոսքը։ Ցանկացած ոչ տրիվիալ փոփոխության համար մենք նախ խնդրեցինք Codex-ին օգնել մեզ հասկանալ, թե ինչպես են համակարգն ու կոդը աշխատում։ Օրինակ, մենք կխնդրեինք այն կարդալ մի շարք կապված ֆայլեր և ամփոփել, թե ինչպես է այդ հատկությունը աշխատում. օրինակ, ինչպես է տվյալների հոսքը API-ից անցնում պահոցի շերտով, տեսողական մոդելով և հասնում UI-ին։ Այնուհետև մենք կուղղենք կամ կկատարելագործենք դրա ըմբռնումը։ (Օրինակ, մենք կնշենք, որ որոշակի աբստրակցիան իրականում պատկանում է այլ շերտի, կամ որ տվյալ դասը գոյություն ունի միայն օֆլայն ռեժիմի համար և չպետք է ընդլայնվի:)
Նմանապես, ինչպես դուք կարող եք ներգրավել նոր, բարձր կարողություններով թիմակցին, մենք աշխատեցինք Codex-ի հետ՝ ստեղծելու ամուր իրականացման պլան։ Այդ պլանը հաճախ նման էր մանրանկարչական նախագծային փաստաթղթի, որը ուղղորդում էր, թե որ ֆայլերը պետք է փոխվեն, ինչ նոր վիճակներ պետք է ներկայացվեն և ինչպես պետք է ընթանա տրամաբանությունը։ Միայն դրանից հետո մենք խնդրեցինք Codex-ին սկսել կիրառել պլանը՝ քայլ առ քայլ։ Մի օգտակար հուշում. շատ երկար առաջադրանքների համար, երբ մենք հասնում ենք մեր համատեքստային պատուհանի սահմանին, մենք կխնդրենք Codex-ին պահել իր պլանը ֆայլում, ինչը թույլ կտա մեզ կիրառել նույն ուղղությունը տարբեր դեպքերում։
Այս լրացուցիչ պլանավորման ցիկլը արժեր ժամանակին։ Դա մեզ թույլ տվեց Codex-ին թողնել «անվերահսկելի» երկար ժամանակահատվածների ընթացքում, քանի որ մենք գիտեինք նրա պլանները։ Դա հեշտացրեց կոդի վերանայումը, քանի որ մենք կարող էինք ստուգել իրականացումը մեր պլանի համեմատ, այլ ոչ թե կարդալ տարբերություն առանց համատեքստի։ Եվ երբ ինչ-որ բան սխալ էր տեղի ունենում, մենք կարող էինք նախ վրիպազերծել պլանը, ապա կոդը։
Դինամիկան նման էր այն ձևին, թե ինչպես լավ նախագծման փաստաթուղթը տեխնոլոգիաների ղեկավարին վստահություն է տալիս նախագծի նկատմամբ: Մենք ոչ միայն գեներացնում էինք կոդ, այլև ստեղծում էինք կոդ, որը աջակցում էր ընդհանուր ճանապարհային քարտեզին։
Նախագծի գագաթնակետին մենք հաճախ միաժամանակ մի քանի աշխատաշրջաններ էինք վարում։ Մեկը աշխատում էր նվագարկման վրա, մյուսը՝ որոնման, մյուսը՝ սխալների մշակման, իսկ երբեմն մեկ ուրիշը՝ թեստերի կամ վերափոխումների վրա։ Այն ավելի քիչ նման էր գործիք օգտագործելուն և ավելի շատ՝ թիմը կառավարելուն:
Յուրաքանչյուր աշխատաշրջան պարբերաբար մեզ հետ կզեկուցի առաջընթացի մասին։ Մեկը կարող է ասել. «Ես ավարտել եմ այս մոդուլի պլանավորումը, ահա թե ինչ եմ առաջարկում», մինչդեռ մյուսը կառաջարկի մեծ փոփոխություն նոր գործառույթի համար։ Յուրաքանչյուրը պահանջում էր ուշադրություն, կարծիք և վերանայում։ Դա տարօրինակորեն նման էր տեխնիկական ղեկավար լինելուն մի քանի նոր ինժեներների հետ, որոնք բոլորն էլ առաջընթաց էին գրանցում, բոլորն էլ առաջնորդության կարիք ունեին։
Արդյունքը համագործակցային հոսք էր։ Codex-ի հում կոդավորման հնարավորությունները մեզ ազատեցին ձեռքով շատ մուտքագրումներից։ Մենք ավելի շատ ժամանակ ունեինք մտածելու ճարտարապետության մասին, ուշադիր կարդալու pull հարցումները և փորձարկելու հավելվածը։
Միևնույն ժամանակ, այդ լրացուցիչ արագությունը նշանակում էր, որ մենք միշտ ինչ-որ բան ունեինք մեր վերանայման հերթում սպասման։ Codex-ը չարգելափակվեց համատեքստի փոփոխության պատճառով, բայց մենք արգելափակվեցինք։ Մեր զարգացման խցանումը տեղափոխվեց կոդ գրելուց դեպի որոշումներ կայացնելը, կարծիքներ տալը և փոփոխությունները ինտեգրելը։
Ահա թե որտեղ է Բրուքսի մտորումները նորովի դրսևորվում։ Դուք չեք կարող պարզապես ավելացնել Codex-ի աշխատաշրջաններ և ակնկալել գծային արագացում, ինչպես նաև չեք կարող շարունակաբար ինժեներներ ավելացնել նախագծին և ակնկալել, որ ժամանակացույցը գծայինորեն կկրճատվի։ Յուրաքանչյուր լրացուցիչ «ձեռքերի զույգ», նույնիսկ վիրտուալ, ավելացնում է համակարգման բեռը։ Մենք դարձել էինք նվագախմբի դիրիժոր՝ ի տարբերություն պարզապես ավելի արագ մենակատարների։
Մենք սկսեցինք մեր նախագիծը մեծ առաջընթացով. Sora-ն արդեն թողարկվել էր iOS-ի համար։ Մենք հաճախ ուղղորդում էինք Codex-ին iOS և backend կոդային բազաներին՝ օգնելու համար հասկանալ հիմնական պահանջներն ու սահմանափակումները։ Նախագծի ընթացքում մենք կատակով ասում էինք, որ մենք վերագտել ենք բազմապլատֆորմային հարթակի գաղափարը։ Մոռացեք React Native-ը կամ Flutter-ը. խաչաձև հարթակների ապագան պարզապես Codex-ն է։
Կատակի տակ թաքնված են երկու սկզբունքներ։
- Տրամաբանությունը տեղափոխելի է։ Անկախ նրանից՝ կոդը գրված է Swift-ով թե Kotlin-ով, հիմնական հավելվածի տրամաբանությունը՝ տվյալների մոդելները, ցանցային զանգերը, վավերացման կանոնները, Business տրամաբանությունը՝ նույնն են։ Codex-ը շատ լավ է կարդում Swift-ի իրականացումը և ստեղծում Kotlin-ի համարժեքը, որը պահպանում է իմաստը։
- Կոնկրետ օրինակները ապահովում են հզոր համատեքստ։ Նոր Codex աշխատաշրջան, որը կարող է տեսնել «ահա, թե ինչպես է սա աշխատում iOS-ում» և «ահա Android-ի ճարտարապետությունը», շատ ավելի արդյունավետ է, քան այն աշխատաշրջանը, որը աշխատում է միայն բնական լեզվի նկարագրությունների հիման վրա։
Այս սկզբունքները գործի դնելով՝ մենք iOS, backend և Android պահոցները հասանելի դարձրեցինք նույն միջավայրում: Մենք Codex-ին տվեցինք հարցումներ, ինչպիսիք են՝
«Կարդա այս մոդելները և վերջնակետերը iOS կոդում, ապա առաջարկիր պլան՝ Android-ում համարժեք վարքագիծը իրականացնելու համար՝ օգտագործելով մեր առկա API սպասառուն և մոդելի դասերը»։
Մի փոքր, բայց օգտակար հնարք էր մանրամասն նկարագրել տեղական պահոցների գտնվելու վայրերը և դրանց պարունակությունը ~/.codex/AGENTS.md-ում։ Դա Codex-ի համար ավելի հեշտացրեց համապատասխան կոդը հայտնաբերելը և դրանում կողմնորոշվելը։
Մենք արդյունավետորեն իրականացնում էինք բազմապլատֆորմային մշակում՝ թարգմանության միջոցով, այլ ոչ թե ընդհանուր աբստրակցիայի։ Քանի որ Codex-ը կատարեց թարգմանության մեծ մասը, մենք խուսափեցինք իրականացման ծախսերի կրկնապատկումից։
Ավելի լայն դասը այն է, որ Codex-ի համար համատեքստը ամեն ինչ է։ Codex-ը լավագույնս աշխատեց, երբ հասկացավ, թե ինչպես է ֆունկցիան արդեն աշխատում iOS-ում՝ զուգակցված մեր Android հավելվածի կառուցվածքի ըմբռնմամբ։ Երբ Codex-ը չուներ այդ համատեքստը, դա «համագործակցելուց հրաժարվելը» չէր. այն ենթադրություն էր։ Որքան շատ մենք նրան վերաբերվում էինք որպես նոր թիմակցի և ներդրումներ կատարում ճիշտ խորհուրդներ տալու համար, այնքան ավելի լավ էր այն աշխատում։
Մեր չորսշաբաթյա արագընթացի ավարտին Codex-ի օգտագործումը դադարեց փորձարկում թվալ և դարձավ մեր կանխադրված մշակման ցիկլը: Մենք այն օգտագործեցինք գոյություն ունեցող կոդը հասկանալու, փոփոխություններ պլանավորելու և ֆունկցիաներ իրականացնելու համար։ Մենք վերանայեցինք դրա արդյունքը այնպես, ինչպես կվերանայեինք թիմակցի արդյունքը։ Դա պարզապես այն էր, թե ինչպես մենք առաքում էինք ծրագրակազմը։
Պարզ դարձավ, որ ԱԲ-ի օգնությամբ զարգացումը չի նվազեցնում խստության անհրաժեշտությունը. այն ավելացնում է խստությունը։ Չնայած Codex-ի ունակություններին, նրա նպատակը հիմա A կետից B կետ հասնելն է։ Ահա թե ինչու ԱԲ-ի օգնությամբ կոդավորումը չի գործում առանց մարդկանց։ Ծրագրային ապահովման ինժեներները կարող են հասկանալ և կիրառել համակարգերի իրական աշխարհի սահմանափակումները, ծրագրային ապահովման ճարտարապետության լավագույն մեթոդները և ինչպես կառուցել՝ հաշվի առնելով ապագա զարգացման և արտադրանքի պլանները։ Վաղվա ծրագրային ապահովման ինժեների գերհզորությունները կլինեն համակարգերի խորը ըմբռնումը և արհեստական բանականության հետ երկարաժամկետ համագործակցելու ունակությունը։
Ծրագրային ապահովման ճարտարագիտության ամենահետաքրքիր մասերն են գրավիչ պրոդուկտների կառուցումը, մասշտաբային համակարգերի նախագծումը, բարդ ալգորիթմների գրառումը և տվյալների, նախշերի և կոդի հետ փորձարկումները։ Այնուամենայնիվ, ծրագրային ապահովման ճարտարագիտության անցյալի և ներկայի իրականությունները հաճախ ավելի առօրյա են. կոճակների կենտրոնացում, վերջնակետերի միացում և շաբլոնային կոդի գրառում։ Այժմ Codex-ը հնարավորություն է տալիս կենտրոնանալ ծրագրային ապահովման ճարտարագիտության ամենակարևոր մասերի և մեր արհեստը սիրելու պատճառների վրա։
Երբ Codex-ը տեղադրվի համատեքստով հարուստ միջավայրում, որտեղ այն կհասկանա ձեր նպատակները և թե ինչպես եք նախընտրում կառուցել, ցանկացած թիմ կարող է բազմապատկել դրա հնարավորությունները։ Մեր գործարկման հետադարձ հայացքը համընդհանուր լուծում չէ, և մենք չենք պնդում, որ լուծել ենք արհեստական բանականության օգնությամբ մշակման խնդիրը։ Բայց մենք հույս ունենք, որ մեր փորձը կհեշտացնի գտնել լավագույն ուղիները Codex-ին հզորացնելու համար, որպեսզի այն հզորացնի ձեզ։
Երբ Codex-ը գործարկվեց հետազոտության նախադիտման տարբերակում յոթ ամիս առաջ, ծրագրային ճարտարագիտությունը շատ տարբեր էր թվում։ Sora-ի միջոցով մենք հնարավորություն ունեցանք ուսումնասիրել ճարտարագիտության հաջորդ գլուխը։ Քանի որ մեր մոդելներն ու զսպանակները շարունակաբար բարելավվում են, արհեստական բանականությունը կդառնա ավելի ու ավելի անփոխարինելի մաս կառուցման մեջ։
Ի՞նչ եք պատրաստելու ձեր սեփական Codex թիմով։
