Ինժեներիայի կիրառումը՝ Codex-ն ագենտ-առաջնահերթ աշխարհում
Ռայան Լոպոպոլո, տեխնիկական անձնակազմի անդամ
Վերջին հինգ ամիսների ընթացքում մեր թիմը փորձարկում է իրականացրել՝ կառուցելով և թողարկելով ծրագրային պրոդուկտի ներքին բետա՝ 0 տողով ձեռքով գրված կոդ։
Ապրանքը ունի ներքին ամենօրյա օգտատերեր և արտաքին ալֆա փորձարկողներ։ Այն առաքվում է, տեղակայվում է, խափանվում է և վերականգնվում է։ Տարբերությունն այն է, որ կոդի յուրաքանչյուր տող՝ հավելվածի տրամաբանությունը, թեստերը, CI-ի կազմաձևումը, փաստաթղթավորումը, դիտարկելիությունը և ներքին գործիքակազմը, գրվել է Codex-ի կողմից։ Մենք գնահատում ենք, որ սա կառուցել ենք մոտավորապես այն ժամանակի 1/10-ում, որը կպահանջվեր կոդը ձեռքով գրելու համար։
Մարդիկ ուղղորդում են։ Ագենտները կատարում են։
Մենք միտումնավոր ընտրեցինք այս սահմանափակումը, որպեսզի կառուցենք այն, ինչ անհրաժեշտ էր՝ ինժեներական արագությունը բազմակի անգամ մեծացնելու համար։ Մենք շաբաթներ ունեինք՝ առաքելու այն, ինչը վերջում դարձավ մեկ միլիոն տող կոդ։ Դա անելու համար մենք պետք է հասկանայինք, թե ինչ է փոխվում, երբ ծրագրային ինժեներական թիմի հիմնական աշխատանքը այլևս կոդ գրելն չէ, այլ՝ միջավայրեր նախագծելը, մտադրությունը հստակեցնելը և հետադարձ կապի օղակներ կառուցելը, որոնք Codex գործակալներին թույլ են տալիս հուսալի աշխատանք կատարել։
Այս գրառումը վերաբերում է այն բանին, թե ինչ սովորեցինք ագենտների թիմի հետ նոր ապրանք ստեղծելով՝ ինչն է փչացել, ինչն է կուտակվել, և ինչպես մաքսիմալացնել մեր միակ իսկապես սակավաթիվ ռեսուրսը՝ մարդկային ժամանակը և ուշադրությունը։
Դատարկ պահոցում առաջին հաստատումը կատարվել է 2025 թ. օգոստոսի վերջին։
Սկզբնական կառուցվածքը՝ պահոցի կառուցվածքը, CI կոնֆիգուրացիան, ձևաչափման կանոնները, փաթեթների կառավարչի կարգավորումը և հավելվածի շրջանակը, ստեղծվել է Codex CLI-ի կողմից՝ օգտագործելով GPT‑5‑ը՝ առաջնորդվելով առկա ձևանմուշների փոքր հավաքածուով։ Նույնիսկ սկզբնական AGENTS.md ֆայլը, որը ուղղորդում է ագենտներին, թե ինչպես աշխատել պահոցում, գրվել էր հենց Codex-ի կողմից։
Համակարգը հիմնավորելու համար նախապես գրված մարդկային կոդ չկար։ Սկզբից ի վեր պահոցը ձևավորվել է ագենտի կողմից։
Հինգ ամիս անց, պահոցը պարունակում է մոտ մեկ միլիոն տող կոդ՝ հավելվածի տրամաբանության, ենթակառուցվածքի, գործիքների, փաստաթղթերի և ներքին ծրագրավորողների գործիքների համար։ Այդ ժամանակահատվածում բացվել և միավորվել են մոտ 1500 pull request-ներ՝ Codex-ը առաջ մղող ընդամենը երեք ինժեներներից բաղկացած փոքր թիմի կողմից։ Սա նշանակում է, որ միջին թողունակությունը կազմում է օրական 3,5 PRs մեկ ինժեների համար, և զարմանալիորեն, թողունակությունը աճել է, քանի որ թիմը մեծացել է՝ այժմ ունենալով յոթ ինժեներ։ Կարևոր է նշել, որ սա պարզապես արդյունք չէր արդյունքի համար. արտադրանքը օգտագործվել է հարյուրավոր ներքին օգտատերերի կողմից, ներառյալ ամենօրյա ակտիվ օգտատերերը։
Մշակման գործընթացի ողջ ընթացքում մարդիկ երբեք ուղղակիորեն որևէ կոդ չեն ներդրել։ Սա դարձավ թիմի հիմնական փիլիսոփայությունը՝ ձեռքով գրված կոդի բացառում։
Գործնական մարդկային կոդավորման բացակայությունը ներդրեց ինժեներական աշխատանքի այլ տեսակ, որը կենտրոնացած է համակարգերի, աջակցող կառուցվածքների և լծակների վրա։
Սկզբնական առաջընթացը ավելի դանդաղ էր, քան մենք սպասում էինք, ոչ թե այն պատճառով, որ Codex-ը անկարող էր, այլ որովհետև միջավայրը բավարար չափով չէր սահմանվել։ Ագենտը չուներ այն գործիքները, աբստրակցիաները և ներքին կառուցվածքը, որոնք անհրաժեշտ էին բարձր մակարդակի նպատակների ուղղությամբ առաջընթացի համար։ Մեր ինժեներական թիմի հիմնական գործը դարձավ ագենտներին հնարավորություն տալը՝ օգտակար աշխատանք կատարելու համար։
Գործնականում սա նշանակում էր աշխատել խորությամբ՝ ավելի մեծ նպատակները բաժանելով ավելի փոքր կառուցվածքային բլոկների (դիզայն, կոդ, վերանայում, թեստ և այլն), հուշելով ագենտին կառուցել այդ բլոկները և օգտագործելով դրանք՝ ավելի բարդ առաջադրանքներ բացելու համար։ Երբ ինչ-որ բան ձախողվում էր, լուծումը գրեթե երբեք «ավելի շատ ջանք գործադրել» չէր։ Քանի որ առաջընթաց գրանցելու միակ միջոցը Codex-ին աշխատանքը կատարեցնելն էր, մարդկային ինժեներները միշտ ներգրավվում էին առաջադրանքի մեջ և հարցնում էին. «Ո՞ր հնարավորությունն է բացակայում, և ինչպե՞ս ենք այն դարձնում ընթեռնելի և կիրառելի ագենտի համար»։
Մարդիկ համակարգի հետ գրեթե ամբողջությամբ փոխազդում են հարցումների միջոցով. ինժեները նկարագրում է առաջադրանքը, գործարկում է ագենտը և թույլ է տալիս նրան բացել pull request-ը։ PR-ը ավարտին հասցնելու համար մենք Codex-ին հրահանգում ենք տեղում վերանայել իր փոփոխությունները, պահանջել լրացուցիչ կոնկրետ ագենտի ստուգումներ թե՛ տեղում, թե՛ ամպում, արձագանքել մարդու կամ ագենտի կողմից տրված ցանկացած հետադարձ կապին և կրկնել ցիկլով, մինչև բոլոր ագենտ-ստուգողները գոհ լինեն (ըստ էության սա Ralph Wiggum Loop(բացվում է նոր պատուհանում) է)։ Codex-ը մեր ստանդարտ մշակման գործիքներն անմիջապես օգտագործում է (gh, տեղական սցենարներ և պահոցում ներդրված հմտություններ)՝ համատեքստ հավաքելու համար՝ առանց մարդկանց CLI-ում պատճենելու և տեղադրելու։
Մարդիկ կարող են վերանայել pull request-ները, բայց դա պարտադիր չէ։ Ժամանակի ընթացքում մենք գրեթե ամբողջ վերանայման աշխատանքը ուղղել ենք դեպի այն, որ այն իրականացվի ագենտից ագենտ։
Քանի որ կոդի թողունակությունն ավելացավ, մեր խցանումը դարձավ մարդկային որակի ապահովման (QA) կարողությունը։ Քանի որ ֆիքսված սահմանափակումը եղել է մարդկային ժամանակն ու ուշադրությունը, մենք աշխատել ենք ագենտին ավելի շատ հնարավորություններ ավելացնելու ուղղությամբ՝ Codex-ի համար անմիջապես ընթեռնելի դարձնելով այնպիսի տարրեր, ինչպիսիք են հավելվածի UI-ը, գրանցամատյանները և հավելվածի չափորոշիչները։
Օրինակ՝ մենք հավելվածը դարձրեցինք գործարկելի՝ ըստ git worktree-ի, որպեսզի Codex-ը կարողանար գործարկել և կառավարել մեկ օրինակ յուրաքանչյուր փոփոխության համար։ Մենք նաև Chrome DevTools Protocol-ը ինտեգրեցինք ագենտի runtime-ին և ստեղծեցինք հմտություններ՝ DOM-ի նկարահանումների, սքրինշոթների և նավիգացիայի հետ աշխատելու համար։ Սա հնարավորություն տվեց Codex-ին վերարտադրել սխալները, վավերացնել շտկումները և անմիջապես վերլուծել UI-ի վարքագիծը։
Մենք նույնը արեցինք նաև դիտարկելիության գործիքների համար։ Լոգերը, մետրիկաները և հետքերը հասանելի են Codex-ին տեղական դիտարկելիության փաթեթի միջոցով, որը ժամանակավոր է ցանկացած տվյալ աշխատանքային ծառի համար։ Codex-ը աշխատում է այդ հավելվածի ամբողջովին մեկուսացված տարբերակի վրա՝ ներառյալ դրա գրանցամատյաններն ու չափորոշիչները, որոնք հեռացվում են, երբ այդ առաջադրանքն ավարտվում է։ Ագենտները կարող են հարցումներ կատարել լոգերի վրա՝ LogQL-ով, և չափանիշների վրա՝ PromQL-ով։ Այս համատեքստի առկայության դեպքում, նման հարցումները, ինչպիսիք են՝ «համոզվեք, որ ծառայության գործարկումը ավարտվում է 800 միլիվայրկյանից պակաս ժամանակում» կամ «այս չորս կարևոր օգտատիրոջ ճանապարհորդություններից որևէ մեկում տևողությունը չի գերազանցում երկու վայրկյանը», դառնում են իրագործելի։
Մենք պարբերաբար նկատում ենք, որ Codex-ի առանձին գործարկումները մեկ առաջադրանքի վրա աշխատում են վեց ժամից ավելի (հաճախ այն ժամանակ, երբ մարդիկ քնած են)։
Համատեքստի կառավարումը մեծ և բարդ առաջադրանքներում ագենտներին արդյունավետ դարձնելու ամենամեծ մարտահրավերներից մեկն է։ Մեր սովորած ամենավաղ դասերից մեկը պարզ էր. Codex-ին տալ քարտեզ, ոչ թե 1000 էջանոց հրահանգների ձեռնարկ։
Մենք փորձեցինք «մեկ մեծ AGENTS.md(բացվում է նոր պատուհանում)» մոտեցում։ Այն ձախողվեց կանխատեսելի ձևերով։
- Համատեքստը սակավ ռեսուրս է։ Հսկայական հրահանգային ֆայլը դուրս է մղում առաջադրանքը, կոդը և համապատասխան փաստաթղթերը՝ այնպես որ ագենտը կամ բաց է թողնում հիմնական սահմանափակումները, կամ սկսում է օպտիմալացնել սխալ սահմանափակումների համար։
- Չափազանց շատ ուղղորդումը դառնում է ոչ ուղղորդում։ Երբ ամեն ինչ «կարևոր» է, ոչինչ կարևոր չէ։ Ագենտները ի վերջո տեղային օրինաչափություններ են համադրում՝ նպատակային նավիգացիայի փոխարեն։
- Այն անմիջապես փչանում է։ Մոնոլիտային ձեռնարկը վերածվում է հնացած կանոնների գերեզմանոց։ Ագենտները չեն կարողանում որոշել, թե ինչն է դեռևս ճիշտ, մարդիկ դադարում են այն պահպանել, և ֆայլը աննկատ դառնում է գրավիչ վտանգի աղբյուր։
- Դժվար է ստուգել։ Առանձին հատվածը չի կարող մեխանիկորեն ստուգվել (ծածկույթ, թարմություն, պատկանելություն, խաչաձև կապեր), ուստի դրեյֆը անխուսափելի է։
Այսպիսով, AGENTS.md -ը որպես հանրագիտարան դիտարկելու փոխարեն, մենք այն դիտարկում ենք որպես բովանդակության ցանկ։
Պահոցի գիտելիքների բազան գտնվում է կառուցվածքային docs/ գրացուցակում, որը համարվում է գրառումների հիմնական աղբյուր։ Կարճ AGENTS.md -ը (մոտ 100 տող) ներառվում է համատեքստում և հիմնականում ծառայում է որպես քարտեզ՝ հղումներով դեպի այլ վայրերում գտնվող ավելի խորը ճշմարտության աղբյուրներ։
Դիզայնի փաստաթղթերը կատալոգացվում և ինդեքսավորվում են՝ ներառյալ վավերացման կարգավիճակը և հիմնական համոզմունքների մի շարք, որոնք սահմանում են ագենտ-առաջին գործառնական սկզբունքները։ Ճարտարապետության փաստաթղթավորում(բացվում է նոր պատուհանում) տրամադրում է տիրույթների և փաթեթների շերտավորման վերին մակարդակի քարտեզ։ Որակական փաստաթուղթը գնահատում է յուրաքանչյուր արտադրանքի ոլորտն ու ճարտարապետական շերտը՝ հետևելով բացերին ժամանակի ընթացքում։
Պլանները դիտարկվում են որպես առաջնակարգ արտեֆակտներ։ Անցողիկ թեթև պլանները կիրառվում են փոքր փոփոխությունների համար, մինչդեռ բարդ աշխատանքը գրանցվում է կատարման պլաններում(բացվում է նոր պատուհանում) ՝ առաջընթացի և որոշումների գրանցամատյաններով, որոնք մուտքագրվում են պահոց։ Ակտիվ պլանները, ավարտված պլանները և հայտնի տեխնիկական պարտքը տարբերակավորվում և համատեղ տեղակայված են, ինչը թույլ է տալիս ագենտներին գործել՝ առանց արտաքին համատեքստից կախված լինելու։
Սա հնարավորություն է տալիս առաջադիմական բացահայտման՝ գործակալները սկսում են փոքր, կայուն մուտքի կետից և նրանց սովորեցնում են, թե որտեղ նայել հաջորդը, այլ ոչ թե սկզբից ծանրաբեռնվեն։
Մենք սա մեխանիկորեն կիրառում ենք։ Նվիրված լինթերներն ու CI առաջադրանքները ստուգում են, որ գիտելիքների բազան թարմացված է, խաչաձև հղումներով կապակցված և ճիշտ կառուցված։ Կրկնվող «doc-gardening» ագենտը սկանավորում է հնացած կամ անտեղի փաստաթղթավորումը, որը չի արտացոլում կոդի իրական վարքագիծը, և բացում է ուղղման pull request-ներ։
Քանի որ կոդային բազան զարգանում էր, Codex-ի դիզայնի որոշումների շրջանակը նույնպես պետք է զարգանար։
Քանի որ պահոցը ամբողջությամբ գեներացվել է ագենտի կողմից, այն նախ և առաջ օպտիմիզացված է Codex -ի ընթեռնելիության համար։ Նույն կերպ, ինչպես թիմերը ձգտում են բարելավել իրենց կոդի նավիգացիան նոր ինժեներական աշխատակիցների համար, մեր մարդկային ինժեներների նպատակը այն էր, որ ագենտը կարողանա վերլուծել ամբողջ բիզնես տիրույթը ուղղակիորեն հենց պահոցից։
Ագենտի տեսանկյունից, այն ամենը, ինչին այն չի կարող հասանելիություն ունենալ գործարկման ընթացքում համատեքստում, փաստացի գոյություն չունի։ Գիտելիքները, որոնք գտնվում են Google Docs-ում, չաթի թեմաներում կամ մարդկանց գլխում, համակարգին հասանելի չեն։ Պահոցին տեղային, տարբերակավորված արտեֆակտները (օրինակ՝ կոդ, markdown, սխեմաներ, գործարկվող պլաններ) այն ամենն են, ինչ այն կարող է տեսնել։
Մենք հասկացանք, որ ժամանակի ընթացքում անհրաժեշտ էր ավելի ու ավելի շատ համատեքստ ներառել պահոցում։ Այն Slack-ի քննարկումը, որը թիմին համահունչ դարձրեց ճարտարապետական մոդելի շուրջ: Եթե այն ագենտի համար հայտնաբերելի չէ, ապա այն նույնքան անընթեռնելի է, որքան երեք ամիս անց միացած նոր աշխատակցի համար կլիներ անհայտ։
Codex-ին ավելի շատ համատեքստ տալը նշանակում է կազմակերպել և ներկայացնել ճիշտ տեղեկատվությունը, որպեսզի ագենտը կարողանա դրա վրա հիմնվել, այլ ոչ թե այն ծանրաբեռնել պատահական հրահանգներով։ Նույն կերպ, ինչպես նոր թիմակցին կծանոթացնեիք արտադրանքի սկզբունքներին, ինժեներական նորմերին և թիմի մշակույթին (ներառյալ էմոջիի նախընտրությունները), այս տեղեկատվությունը տալով ագենտին՝ կհանգեցնեք ավելի համահունչ արդյունքի։
Այս ձևակերպումը հստակեցրեց բազմաթիվ փոխզիջումները։ Մենք նախընտրեցինք կախվածություններն ու աբստրակցիաները, որոնք հնարավոր էր ամբողջությամբ ներքնայնացվել և դրանց մասին հիմնավորել պահոցի ներսում։ «Ձանձրալի» հաճախ բնութագրվող տեխնոլոգիաները սովորաբար ավելի հեշտ են մոդելավորվում ագենտների կողմից՝ կոմպոզիցիոնության, API-ի կայունության և ուսուցման հավաքածուում ներկայացվածության շնորհիվ։ Որոշ դեպքերում ավելի էժան էր, որ ագենտը վերաիրականացներ ֆունկցիոնալության ենթաբազմությունները, քան հանրային գրադարանների անթափանց վերին հոսքի վարքագծի շուրջ շրջանցումներ անել։ Օրինակ, ընդհանուր p-limit-ոճի փաթեթ ներգրավելու փոխարեն, մենք իրականացրինք մեր սեփական համաժամանակյա քարտեզի օգնականը, որը սերտորեն ինտեգրված է մեր OpenTelemetry գործիքակազմի հետ, ունի 100% թեստային ծածկույթ և գործում է ճիշտ այնպես, ինչպես մեր runtime-ը սպասում է։
Համակարգի ավելի մեծ մասը բերելն այնպիսի ձևի, որը ագենտը կարող է ստուգել, վավերացնել և ուղղակիորեն փոփոխել, մեծացնում է ազդեցությունը՝ ոչ միայն Codex-ի, այլ նաև այլ ագենտների համար (օրինակ՝ Aardvark), որոնք նույնպես աշխատում են կոդային բազայի վրա։
Փաստաթղթավորումը միայնակ չի կարող ապահովել, որ ամբողջությամբ ագենտի կողմից գեներացված կոդային բազան մնա համահունչ։ Անփոփոխելիությունները պարտադրելով, այլ ոչ թե իրականացումները մանրակրկիտ վերահսկելով, մենք թույլ ենք տալիս ագենտներին արագ թողարկումներ անել՝ առանց հիմքը խաթարելու։ Օրինակ, մենք պահանջում ենք, որ Codex-ը վերլուծի տվյալների ձևերը սահմանային հատվածում(բացվում է նոր պատուհանում), բայց չենք սահմանում, թե ինչպես դա պետք է տեղի ունենա (մոդելին կարծես դուր է գալիս Zod-ը, բայց մենք այդ կոնկրետ գրադարանը չենք նշել)։
Ագենտները առավել արդյունավետ են այն միջավայրերում, որտեղ կան խիստ սահմաններ և կանխատեսելի կառուցվածք(բացվում է նոր պատուհանում), ուստի մենք հավելվածը կառուցեցինք խիստ ճարտարապետական մոդելի շուրջ։ Յուրաքանչյուր բիզնես տիրույթ բաժանված է շերտերի ֆիքսված հավաքածուի՝ խիստ վավերացված կախվածությունների ուղղություններով և թույլատրելի եզրերի սահմանափակ հավաքածուով։ Այս սահմանափակումները մեխանիկորեն կիրառվում են հատուկ լինթերների (իհարկե Codex-ի կողմից գեներացված) և կառուցվածքային թեստերի միջոցով։
Ստորև ներկայացված դիագրամը ցույց է տալիս կանոնը՝ յուրաքանչյուր բիզնես տիրույթում (օրինակ՝ Հավելվածի կարգավորումներ), կոդը կարող է կախված լինել միայն «առաջ»՝ շերտերի ֆիքսված հավաքածուի միջոցով (Types → Config → Repo → Service → Runtime → UI)։ Խաչաձև խնդիրները (auth, connectors, telemetry, feature flags) մուտք են գործում մեկ բացահայտ ինտերֆեյսի միջոցով՝ Providers։ Ցանկացած այլ բան արգելված է և մեխանիկորեն վերահսկվում է։
Սա այնպիսի ճարտարապետություն է, որը սովորաբար հետաձգում են մինչև հարյուրավոր ինժեներներ ունենալը։ Կոդավորման ագենտների դեպքում դա վաղ նախապայման է. սահմանափակումներն են, որ ապահովում են արագություն՝ առանց որակի անկման կամ ճարտարապետական շեղման։
Գործնականում մենք կիրառում ենք այս կանոնները՝ հատուկ լինթերների և կառուցվածքային թեստերի միջոցով, ինչպես նաև «ճաշակի անփոփոխների» փոքր հավաքածուով։ Օրինակ՝ մենք ստատիկ կերպով պարտադրում ենք կառուցվածքային լոգավորում, սխեմաների և տիպերի անվանման կոնվենցիաներ, ֆայլի չափի սահմանաչափեր և հարթակին հատուկ հուսալիության պահանջներ՝ հատուկ լինտերի միջոցով։ Քանի որ lint-երը հատուկ են, մենք գրում ենք սխալի հաղորդագրությունները՝ ագենտի համատեքստում վերականգնման հրահանգներ ներառելու համար։
Մարդկայինը առաջնային աշխատանքային հոսքում այս կանոնները կարող են թվալ մանրակրկիտ կամ սահմանափակող։ Ագենտների դեպքում դրանք դառնում են բազմապատկիչներ՝ մեկ անգամ կոդավորվելուց հետո դրանք միանգամից կիրառվում են ամենուր։
Միևնույն ժամանակ, մենք հստակ նշում ենք, թե որտեղ են սահմանափակումները կարևոր և որտեղ՝ ոչ։ Սա նման է մեծ ինժեներական պլատֆորմային կազմակերպություն ղեկավարելուն՝ կենտրոնացված կերպով սահմանները պարտադրելով, տեղում ինքնավարություն թույլ տալով։ Դուք խորապես կարևորում եք սահմանները, ճշգրտությունը և վերարտադրելիությունը։ Այդ սահմանների շրջանակում դուք թիմերին կամ գործակալներին թույլ եք տալիս զգալի ազատություն՝ լուծումների արտահայտման եղանակում։
Ստացված կոդը միշտ չէ, որ համապատասխանում է մարդկային ոճական նախասիրություններին, և դա նորմալ է։ Քանի դեռ արդյունքը ճիշտ է, պահպանելի և ընթեռնելի է ապագա ագենտի գործարկումների համար, այն համապատասխանում է պահանջվող չափանիշներին։
Մարդու ճաշակը շարունակաբար ներմուծվում է համակարգի մեջ։ Վերանայման մեկնաբանությունները, refactoring pull request-ները և օգտատերերին տեսանելի սխալները գրանցվում են որպես փաստաթղթավորման թարմացումներ կամ անմիջապես կոդավորվում են գործիքներում։ Երբ փաստաթղթավորումը թերի է մնում, մենք կանոնը վերածում ենք կոդի։
Քանի որ Codex-ի թողունակությունը աճեց, շատ ավանդական ինժեներական նորմեր դարձան հակաարդյունավետ։
Պահոցը գործում է նվազագույն խոչընդոտող միաձուլման դարպասներով։ Pull request-ները կարճատև են։ Թեստային անկայունությունները հաճախ լուծվում են հետագա գործարկումներով՝ առանց առաջընթացը անորոշ ժամանակով արգելափակելու։ Այնպիսի համակարգում, որտեղ ագենտի թողունակությունը շատ ավելի է գերազանցում մարդու ուշադրությունը, ուղղումները մատչելի են, իսկ սպասելը՝ թանկարժեք։
Սա անպատասխանատու կլիներ ցածր թողունակության պայմաններում։ Այստեղ հաճախ դա ճիշտ փոխզիջում է։
Երբ ասում ենք, որ կոդային բազան ստեղծվել է Codex ագենտների կողմից, նկատի ունենք կոդային բազայի բոլոր բաղադրիչները։
Ագենտները արտադրում են:
- Պրոդուկտի կոդ և թեստեր
- CI կազմաձևում և թողարկման գործիքներ
- Ներքին ծրագրավորողների գործիքներ
- Փաստաթղթավորում և նախագծման պատմություն
- Գնահատման գործիքներ
- Վերանայման մեկնաբանություններ և պատասխաններ
- Սկրիպտներ, որոնք կառավարում են պահոցը հենց իրենք
- Արտադրական վահանակի սահմանման ֆայլեր
Մարդիկ միշտ մնում են գործընթացի մեջ, բայց աշխատում են այլ մակարդակի աբստրակցիայի վրա, քան նախկինում։ Մենք առաջնահերթություն ենք տալիս աշխատանքին, օգտատերերի կարծիքները վերածում ենք ընդունման չափանիշների և հաստատում ենք արդյունքները։ Երբ ագենտը դժվարանում է, մենք դա դիտարկում ենք որպես ազդանշան՝ պարզելու, թե ինչն է պակասում՝ գործիքներ, սահմանափակումներ, փաստաթղթավորում, և այն վերադարձնում ենք պահոց՝ միշտ Codex-ին տալով ուղղման գրելու հնարավորություն։
Ագենտները անմիջապես օգտագործում են մեր ստանդարտ զարգացման գործիքները։ Նրանք հավաքում են վերանայման հետադարձ կապը, պատասխանում են տեղում, ուղարկում են թարմացումներ և հաճախ իրենց սեփական pull request-ները միավորում և միացնում են։
Քանի որ մշակման ցիկլի ավելի մեծ մասը անմիջապես կոդավորվեց համակարգի մեջ՝ թեստավորում, վավերացում, վերանայում, հետադարձ կապի մշակում և վերականգնում, պահոցը վերջերս անցավ մի նշանակալի շեմ, որտեղ Codex-ը կարող է ամբողջությամբ վարել նոր ֆունկցիոնալություն։
Տրված մեկ հարցումով, ագենտը այժմ կարող է՝
- Ստուգել կոդային բազայի ներկայիս վիճակը
- Վերարտադրել հաղորդված սխալը
- Տեսագրել տեսանյութ, որը ցույց է տալիս խափանումը
- Կատարել շտկում
- Վավերացնել շտկումը՝ փորձարկելով հավելվածը
- Ձայնագրել երկրորդ տեսանյութ, որը ցույց է տալիս լուծման գործընթացը
- Բացել pull request-ը։
- Արձագանքել ագենտի և մարդու արձագանքներին։
- Հայտնաբերել և շտկել build-ի ձախողումները։
- Փոխանցեքշլ մարդուն միայն այն դեպքում, երբ անհրաժեշտ է դատողություն կատարել։
- Միացրնել փոփոխությունը
Այս վարքագիծը մեծապես կախված է այս պահոցի կոնկրետ կառուցվածքից և գործիքակազմից և չպետք է ենթադրվի, որ այն կարող է ընդհանրացվել առանց նմանատիպ ներդրման՝ առնվազն՝ դեռևս։
Ագենտի լիարժեք ինքնավարությունը նաև նոր խնդիրներ է առաջացնում։Codex-ը կրկնօրինակում է այն օրինաչափությունները, որոնք արդեն գոյություն ունեն պահոցում՝ նույնիսկ անհավասար կամ ոչ օպտիմալները։ Ժամանակի ընթացքում սա անխուսափելիորեն հանգեցնում է փոփոխության։
Սկզբում մարդիկ այս խնդիրը լուծում էին ձեռքով։ Մեր թիմը նախկինում ամեն ուրբաթ (շաբաթվա 20%-ը) ծախսում էր «ԱԲ թափոնները» մաքրելու վրա։ Զարմանալի չէ, որ դա չմասշտաբավորվեց։
Փոխարենը, մենք սկսեցինք «ոսկե սկզբունքները» ուղղակիորեն կոդավորել պահոցում և ստեղծեցինք պարբերական մաքրման գործընթաց։ Այս սկզբունքները կարծրատիպային, մեխանիկական կանոններ են, որոնք կոդային բազան պահում են ընթեռնելի և համահունչ՝ ապագա ագենտների գործարկումների համար։ Օրինակ՝ (1) մենք նախընտրում ենք ընդհանուր օգտագործման օգտակարության փաթեթները՝ ձեռքով գրված օժանդակների փոխարեն, որպեսզի անփոփոխները կենտրոնացված մնան, և (2) մենք տվյալները չենք զննում «YOLO-ոճով»—մենք վավերացնում ենք սահմանները կամ ապավինում ենք ստեղնաշարված SDK-ներին, որպեսզի ագենտը պատահաբար չկառուցի ենթադրված կառուցվածքների վրա։ Կանոնավոր պարբերականությամբ մենք ունենք Codex-ի ֆոնային առաջադրանքների մի շարք, որոնք սկանավորում են շեղումները, թարմացնում են որակի գնահատականները և բացում են նպատակային վերափոխման pull request-ներ։ Դրանց մեծ մասը կարելի է վերանայել մեկ րոպեից էլ քիչ ժամանակում և ավտոմատ կերպով միավորվել։
Սա գործում է ինչպես աղբի հավաքագրումը։ Տեխնիկական պարտքը նման է բարձր տոկոսադրույքով վարկի՝ գրեթե միշտ ավելի լավ է այն շարունակաբար մարել փոքր քայլերով, քան թողնել, որ այն կուտակվի և զբաղվել դրանով ցավոտ պոռթկումներով։ Մարդու ճաշակը մեկ անգամ ֆիքսվում է, ապա շարունակաբար կիրառվում է կոդի յուրաքանչյուր տողի վրա։ Սա նաև թույլ է տալիս մեզ ամեն օր հայտնաբերել և լուծել վատ օրինաչափությունները՝ դրանք օրերով կամ շաբաթներով կոդային բազայում տարածվելու փոխարեն։
Այս ռազմավարությունը մինչ այժմ լավ է գործել OpenAI-ում ներքին գործարկման և ընդունման ընթացքում։ Իրական օգտատերերի համար իրական պրոդուկտ ստեղծելը նպաստեց մեր ներդրումների հիմնավորմանը իրականության մեջ և ուղղորդեց մեզ դեպի երկարաժամկետ սպասարկելիություն։
Այն, ինչ մենք դեռ չգիտենք, այն է, թե ինչպես է ճարտարապետական համահունչությունը զարգանում տարիների ընթացքում՝ ամբողջությամբ ագենտների կողմից ստեղծված համակարգում։ Մենք դեռ սովորում ենք, թե որտեղ է մարդկային դատողությունն առավելագույն ազդեցություն ունենում և ինչպես կոդավորել այդ դատողությունը, որպեսզի այն բազմապատկվի։ Մենք նաև չգիտենք, թե ինչպես այս համակարգը կզարգանա, քանի որ մոդելները ժամանակի ընթացքում ավելի ընդունակ կդառնան։
Ինչն ակնհայտ է դարձել՝ ծրագրային ապահովում կառուցելը դեռևս պահանջում է կարգապահություն, սակայն այդ կարգապահությունն ավելի շատ արտահայտվում է հենակառույցում, քան կոդում։ Գործիքակազմը, աբստրակցիաները և հետադարձ կապի ցիկլերը, որոնք ապահովում են կոդային բազայի համահունչությունը, գնալով ավելի կարևոր են դառնում։
Մեր ամենադժվար մարտահրավերներն այժմ կենտրոնացած են միջավայրերի, հետադարձ կապի օղակների և կառավարման համակարգերի նախագծման վրա, որոնք օգնում են ագենտներին հասնել մեր նպատակին՝ մասշտաբով կառուցել և պահպանել բարդ, հուսալի ծրագրային ապահովում։
Քանի որ Codex-ի նման գործակալները ստանձնում են ծրագրային ապահովման կյանքի ցիկլի ավելի մեծ մասեր, այս հարցերը էլ ավելի կարևոր կդառնան։ Հուսով ենք, որ որոշ վաղ դասերով կիսվելը կօգնի ձեզ կողմնորոշվել, թե որտեղ ներդնել ձեր ջանքերը, որպեսզի կարողանաք պարզապես ինչ-որ բան ստեղծել։
