Harness engineering: Codex-ის გამოყენება აგენტ-პირველ სამყაროში

ბოლო ხუთი თვის განმავლობაში ჩვენი გუნდი ატარებდა ექსპერიმენტს: ვაშენებდით და ვუშვებდით პროგრამული პროდუქტის შიდა ბეტას ხელით დაწერილი კოდის 0 ხაზით.

პროდუქტს ჰყავს ყოველდღიური შიდა მომხმარებლები და გარე ალფა-ტესტერები. ის გამოიცემა, თავსდება, ფუჭდება და შემდეგ სწორდება. განსხვავება ისაა, რომ კოდის ყოველი ხაზი — აპლიკაციის ლოგიკა, ტესტები, CI კონფიგურაცია, დოკუმენტაცია, დაკვირვებადობა და შიდა ინსტრუმენტები — Codex-მა დაწერა. ჩვენი შეფასებით, ეს ავაგეთ დაახლოებით იმ დროის 1/10-ში, რაც კოდის ხელით წერას დასჭირდებოდა.

ადამიანები მართავენ. აგენტები ასრულებენ.

ეს შეზღუდვა განზრახ ავირჩიეთ, რათა აგვეშენებინა ის, რაც საჭირო იყო ინჟინერული სიჩქარის რიგებით გასაზრდელად. რამდენიმე კვირა გვქონდა იმის გამოსაშვებად, რაც საბოლოოდ კოდის მილიონი ხაზი გამოვიდა. ამისთვის უნდა გაგვეგო, რა იცვლება მაშინ, როცა პროგრამული ინჟინერიის გუნდის მთავარი საქმე უკვე აღარ არის კოდის წერა, არამედ გარემოების დიზაინი, განზრახვის დაზუსტება და ისეთი უკუკავშირის ციკლების აგება, რომლებიც Codex აგენტებს სანდო მუშაობის საშუალებას აძლევს.

ეს პოსტი იმაზეა, რა ვისწავლეთ აგენტების გუნდთან ერთად სრულიად ახალი პროდუქტის აშენებით — რა გაფუჭდა, რა დაგროვდა და როგორ მაქსიმალიზდეს ჩვენი ერთადერთი ნამდვილად მწირი რესურსი: ადამიანური დრო და ყურადღება.

ცარიელ რეპოზიტორიუმში პირველი commit 2025 წლის აგვისტოს ბოლოს მოხვდა.

საწყისი კარკასი — რეპოზიტორიუმის სტრუქტურა, CI კონფიგურაცია, ფორმატირების წესები, პაკეტების მენეჯერის გამართვა და აპლიკაციის ფრეიმვორკი — შეიქმნა Codex CLI-ით GPT‑5‑ის გამოყენებით, არსებული შაბლონების მცირე ნაკრებით მართული. თვით საწყისი AGENTS.md ფაილიც კი, რომელიც აგენტებს რეპოზიტორიუმში მუშაობას უთითებს, თავად Codex-მა დაწერა.

სისტემის დასამაგრებლად წინასწარ არსებული, ადამიანის მიერ დაწერილი კოდი არ არსებობდა. თავიდანვე რეპოზიტორიუმი აგენტმა ჩამოაყალიბა.

ხუთი თვის შემდეგ რეპოზიტორიუმი შეიცავს დაახლოებით მილიონ ხაზ კოდს აპლიკაციის ლოგიკაში, ინფრასტრუქტურაში, ხელსაწყოებში, დოკუმენტაციაში და შიდა დეველოპერულ უტილიტებში. ამ პერიოდში მხოლოდ სამი ინჟინრისგან შემდგარმა მცირე გუნდმა, რომელიც Codex-ს მართავდა, გახსნა და შეაერთა დაახლოებით 1,500 შერწყმის მოთხოვნა. ეს ნიშნავს საშუალოდ 3.5 PRs-ს თითო ინჟინერზე დღეში, და გასაკვირია, რომ მწარმოებლურობა გაიზარდა, რადგან გუნდი ახლა შვიდ ინჟინრამდე გაიზარდა. მნიშვნელოვანია, რომ ეს უბრალოდ გამომუშავებისთვის გამომუშავება არ ყოფილა: პროდუქტს შიგნით ასობით მომხმარებელი იყენებდა, მათ შორის ყოველდღიური გამოცდილი შიდა მომხმარებლები.

განვითარების მთელი პროცესის განმავლობაში ადამიანებს უშუალოდ არცერთი კოდი არ შეუტანიათ. ეს გუნდისთვის ძირითად ფილოსოფიად იქცა: ხელით დაწერილი კოდის გარეშე.

ადამიანის მხრიდან პრაქტიკული კოდირების არქონამ შემოიტანა სხვა ტიპის საინჟინრო სამუშაო, რომელიც სისტემებზე, კარკასზე და ბერკეტზე იყო ფოკუსირებული.

ადრეული პროგრესი იმაზე ნელი იყო, ვიდრე ველოდით, არა იმიტომ, რომ Codex-ს არ შეეძლო, არამედ იმიტომ, რომ გარემო არასაკმარისად იყო აღწერილი. აგენტს აკლდა ინსტრუმენტები, აბსტრაქციები და შიდა სტრუქტურა, რომლებიც მაღალი დონის მიზნებისკენ წინსვლისთვის იყო საჭირო. ჩვენი საინჟინრო გუნდის მთავარი საქმე აგენტებისთვის სასარგებლო სამუშაოს გაკეთების შესაძლებლობის მიცემა გახდა.

პრაქტიკაში ეს ნიშნავდა მუშაობას სიღრმის მიხედვით: უფრო დიდი მიზნების დაყოფას უფრო მცირე სამშენებლო ბლოკებად (დიზაინი, კოდი, მიმოხილვა, ტესტი და ა.შ.), აგენტისთვის ამ ბლოკების აგების მოთხოვნას და მათ გამოყენებას უფრო რთული ამოცანების გასახსნელად. როცა რამე ვერ მუშაობდა, გამოსავალი თითქმის არასოდეს იყო „უფრო მეტად ეცადე“. რადგან წინსვლის ერთადერთი გზა იყო Codex-ს გაეკეთებინა საქმე, ადამიან ინჟინრებს ყოველთვის ეს კითხვა დაჰქონდათ: „რომელი შესაძლებლობა გვაკლია და როგორ გავხადოთ ის აგენტისთვის ერთდროულად მკაფიოც და აღსრულებადიც?“

ადამიანები სისტემასთან თითქმის მთლიანად მოთხოვნებით ურთიერთობენ: ინჟინერი აღწერს ამოცანას, უშვებს აგენტს და აძლევს მას საშუალებას გახსნას შერწყმის მოთხოვნა. PR-ის დასასრულამდე მისაყვანად Codex-ს ვაძლევთ ინსტრუქციას, რომ ლოკალურად გადახედოს საკუთარ ცვლილებებს, მოითხოვოს დამატებითი სპეციფიკური აგენტური მიმოხილვები როგორც ლოკალურად, ისე ღრუბელში, უპასუხოს ადამიანისა თუ აგენტის ნებისმიერ უკუკავშირს და ციკლურად გაიმეოროს ეს, სანამ ყველა აგენტი-მიმომხილველი კმაყოფილი არ იქნება (ფაქტობრივად ეს არის Ralph Wiggum Loop⁠(იხსნება ახალ ფანჯარაში)). Codex პირდაპირ იყენებს ჩვენს სტანდარტულ დეველოპერულ ინსტრუმენტებს (gh, local scripts და repository-embedded skills), რათა კონტექსტი შეაგროვოს ისე, რომ ადამიანებს CLI-ში კოპირება-ჩასმა არ დასჭირდეთ.

ადამიანებმა შეიძლება შერწყმის მოთხოვნები გადახედონ, მაგრამ ეს აუცილებელი არ არის. დროთა განმავლობაში თითქმის მთელი მიმოხილვის ძალისხმევა აგენტიდან აგენტზე გადმოვიტანეთ.

კოდის მწარმოებლურობის ზრდასთან ერთად ჩვენი ვიწრო ადგილი ადამიანური QA-ის შესაძლებლობა გახდა. რადგან ფიქსირებული შეზღუდვა ადამიანური დრო და ყურადღებაა, ვმუშაობდით იმაზე, რომ აგენტისთვის მეტი შესაძლებლობა დაგვემატებინა და ისეთი რამეები, როგორიცაა აპლიკაციის UI, ლოგები და აპის მეტრიკები, უშუალოდ Codex-ისთვის წაკითხვადი გაგვეხადა.

მაგალითად, აპი თითო git worktree-ზე გასაშვები გავხადეთ, რათა Codex-ს თითო ცვლილებაზე ერთი ინსტანციის გაშვება და მართვა შეძლებოდა. ასევე Chrome DevTools Protocol აგენტის runtime-ში ჩავამაგრეთ და შევქმენით skills DOM snapshot-ებთან, ეკრანის სურათებთან და ნავიგაციასთან სამუშაოდ. ამან Codex-ს მისცა შესაძლებლობა თავად გაემეორებინა ბაგები, შეემოწმებინა შესწორებები და პირდაპირ ემსჯელა UI-ის ქცევაზე.

იგივე გავაკეთეთ დაკვირვებადობის ინსტრუმენტებისთვისაც. ლოგები, მეტრიკები და ტრასები Codex-სთვის ხელმისაწვდომია ლოკალური დაკვირვებადობის სტეკის საშუალებით, რომელიც ნებისმიერი მოცემული worktree-სთვის ეფემერულია. Codex მუშაობს ამ აპის სრულად იზოლირებულ ვერსიაზე — მის ლოგებსა და მეტრიკებთან ერთად, რომლებიც ამ ამოცანის დასრულების შემდეგ იშლება. აგენტებს შეუძლიათ ლოგების გამოკითხვა LogQL-ით და მეტრიკების — PromQL-ით. როცა ეს კონტექსტი ხელმისაწვდომია, ისეთი მოთხოვნები, როგორიცაა „უზრუნველყავი, რომ სერვისის გაშვება 800ms-ზე ნაკლებში დასრულდეს“ ან „ამ ოთხ კრიტიკულ მომხმარებლის გზაზე არცერთი span არ აღემატებოდეს ორ წამს“, პრაქტიკულად შესასრულებელი ხდება.

ხშირად ვხედავთ, რომ Codex-ის ერთი გაშვება ერთ ამოცანაზე ექვს საათზე მეტხანს მუშაობს (ხშირად მაშინ, როცა ადამიანებს სძინავთ).

კონტექსტის მართვა ერთ-ერთი ყველაზე დიდი გამოწვევაა, როცა გინდა აგენტები დიდ და რთულ ამოცანებზე ეფექტიანები იყვნენ. ერთ-ერთი ყველაზე ადრეული გაკვეთილი, რაც ვისწავლეთ, მარტივი იყო: მიეცით Codex-ს რუკა და არა 1,000-გვერდიანი ინსტრუქციის სახელმძღვანელო.

ვცადეთ „ერთი დიდი AGENTS.md⁠(იხსნება ახალ ფანჯარაში)“ მიდგომა. ის პროგნოზირებადი გზებით ჩავარდა:

• კონტექსტი მწირი რესურსია. უზარმაზარი ინსტრუქციის ფაილი ჩრდილავს თავად ამოცანას, კოდს და შესაბამის დოკებს — ამიტომ აგენტი ან მთავარ შეზღუდვებს გამოტოვებს, ან არასწორებზე იწყებს ოპტიმიზაციას.
• ზედმეტი მითითება მითითების არქონად იქცევა. როცა ყველაფერი „მნიშვნელოვანია“, მნიშვნელოვანი აღარაფერია. აგენტები ლოკალურად pattern-matching-ს იწყებენ, ნაცვლად განზრახ ნავიგაციისა.
• ის მყისიერად ძველდება. მონოლითური სახელმძღვანელო მოძველებული წესების სასაფლაოდ იქცევა. აგენტებს აღარ შეუძლიათ გაიგონ, რა არის ჯერ კიდევ მართალი, ადამიანები მის მოვლას წყვეტენ და ფაილი ჩუმად იქცევა მიმზიდველ პრობლემად.
• მისი შემოწმება რთულია. ერთიანი ბლობის მექანიკური შემოწმება (coverage, freshness, ownership, cross-links) რთულია, ამიტომ დრეიფი გარდაუვალია.

ამიტომ AGENTS.md-ს ენციკლოპედიად კი არ ვექცევით, არამედ სარჩევად.

რეპოზიტორიუმის ცოდნის ბაზა ცხოვრობს სტრუქტურირებულ docs/ დირექტორიაში, რომელსაც ჩანაწერის სისტემად ვექცევით. მოკლე AGENTS.md (დაახლოებით 100 ხაზი) კონტექსტში ინექცირდება და ძირითადად რუკის როლს ასრულებს, რომელიც სხვაგან მდებარე უფრო ღრმა ჭეშმარიტების წყაროებზე მიუთითებს.

დიზაინის დოკუმენტაცია კატალოგიზებულია და ინდექსირებულია, მათ შორის შემოწმების სტატუსი და ძირითადი რწმენების ნაკრები, რომლებიც აგენტ-პირველ ოპერაციულ პრინციპებს განსაზღვრავს. არქიტექტურის დოკუმენტაცია⁠(იხსნება ახალ ფანჯარაში) უზრუნველყოფს დომენებისა და პაკეტების ფენების ზედა დონის რუკას. ხარისხის დოკუმენტი აფასებს თითოეულ პროდუქტულ დომენსა და არქიტექტურულ ფენას და დროთა განმავლობაში აკვირდება ხარვეზებს.

გეგმები პირველკლასიან არტეფაქტებად მიიჩნევა. მცირე ცვლილებებისთვის გამოიყენება ეფემერული მსუბუქი გეგმები, ხოლო რთული სამუშაო ფიქსირდება შესრულების გეგმებში⁠(იხსნება ახალ ფანჯარაში) პროგრესისა და გადაწყვეტილებების ჟურნალებით, რომლებიც რეპოზიტორიუმში ინახება. აქტიური გეგმები, დასრულებული გეგმები და ცნობილი ტექნიკური ვალი ვერსიონირდება და ერთ ადგილას ინახება, რაც აგენტებს საშუალებას აძლევს იმუშაონ გარე კონტექსტზე დაყრდნობის გარეშე.

ეს შესაძლებელს ხდის პროგრესულ გამჟღავნებას: აგენტები იწყებენ პატარა, სტაბილური შესასვლელი წერტილიდან და სწავლობენ, სად ეძებონ შემდეგი ინფორმაცია, ნაცვლად იმისა, რომ თავიდანვე გადატვირთულები იყვნენ.

ამას მექანიკურად ვამკაცრებთ. გამოყოფილი linters და CI jobs ამოწმებენ, რომ ცოდნის ბაზა განახლებულია, ჯვარედინად დაკავშირებულია და სწორადაა სტრუქტურირებული. განმეორებადი „doc-gardening“ აგენტი მოძველებულ ან უსარგებლო დოკუმენტაციას ეძებს, რომელიც კოდის რეალურ ქცევას აღარ ასახავს, და შესწორების შერწყმის მოთხოვნებს ხსნის.

კოდის ბაზის განვითარებასთან ერთად უნდა განვითარებულიყო Codex-ის ჩარჩოც დიზაინის გადაწყვეტილებებისთვის.

რადგან რეპოზიტორიუმი მთლიანად აგენტის მიერ არის გენერირებული, ის პირველ რიგში ოპტიმიზებულია Codex-ის წაკითხვადობისთვის. ისევე, როგორც გუნდები ცდილობენ თავიანთი კოდი უკეთ გასაგები გახადონ ახალდაქირავებული ინჟინრებისთვის, ჩვენი ადამიან ინჟინრების მიზანი იყო, აგენტს სრული ბიზნეს-დომენის გააზრება შესძლებოდა უშუალოდ თავად რეპოზიტორიუმიდან.

აგენტის თვალსაზრისით, ყველაფერი, რაზეც მას გაშვებისას კონტექსტში წვდომა არ აქვს, ფაქტობრივად არ არსებობს. ცოდნა, რომელიც Google Docs-ში, ჩატების თემებში ან ადამიანების თავებში ცხოვრობს, სისტემისთვის მიუწვდომელია. რეპოზიტორიუმში ლოკალურად არსებული, ვერსიონირებული არტეფაქტები (მაგ., კოდი, markdown, სქემები, შესრულებადი გეგმები) არის ყველაფერი, რასაც ის ხედავს.

ვისწავლეთ, რომ დროთა განმავლობაში სულ უფრო მეტი კონტექსტის რეპოში შეტანა გვჭირდებოდა. ის Slack განხილვა, რომელმაც გუნდი არქიტექტურულ პატერნზე შეათანხმა? თუ ის აგენტისთვის აღმოსაჩენი არ არის, ის იმავე აზრით არაწაკითხვადია, როგორც უცნობი იქნებოდა ახალდაქირავებულისთვის, რომელიც სამი თვის შემდეგ შემოგვიერთდა.

Codex-ისთვის მეტი კონტექსტის მიცემა ნიშნავს სწორი ინფორმაციის ორგანიზებასა და გამოტანას ისე, რომ აგენტს მასზე მსჯელობა შეეძლოს, ნაცვლად იმისა, რომ ad-hoc ინსტრუქციებით გადაიტვირთოს. ისევე როგორც ახალ თანაგუნდელს გააცნობდით პროდუქტის პრინციპებს, საინჟინრო ნორმებსა და გუნდის კულტურას (ემოჯის პრეფერენციების ჩათვლით), ამ ინფორმაციის მიწოდება აგენტს უფრო უკეთ შეხამებულ შედეგს აძლევს.

ამ ჩარჩომ ბევრი კომპრომისი გაგვიმარტივა. უპირატესობას ვანიჭებდით ისეთ დამოკიდებულებებსა და აბსტრაქციებს, რომლებიც სრულად შეიძლებოდა შიგნით გააზრებულიყო და რეპოში მათზე მსჯელობა ყოფილიყო შესაძლებელი. ტექნოლოგიები, რომლებსაც ხშირად „მოსაწყენს“ უწოდებენ, აგენტებისთვის მოდელირებაში ხშირად უფრო იოლია კომპოზიციურობის, api სტაბილურობის და სასწავლო ნაკრებში წარმომადგენლობის გამო. ზოგიერთ შემთხვევაში აგენტისთვის ფუნქციონალის ქვეჯგუფების თავიდან რეალიზება უფრო იაფი იყო, ვიდრე საჯარო ბიბლიოთეკებიდან არაგამჭვირვალე upstream ქცევის შემოვლა. მაგალითად, გენერიკული p-limit-სტილის პაკეტის დამატების ნაცვლად, ჩვენ თვითონ განვახორციელეთ map-with-concurrency helper: ის მჭიდროდ არის ინტეგრირებული ჩვენს OpenTelemetry instrumentation-თან, აქვს 100% ტესტური დაფარვა და ზუსტად ისე იქცევა, როგორც ჩვენს runtime-ს სჭირდება.

სისტემის უფრო დიდი ნაწილის იმ ფორმაში გადატანა, რომელსაც აგენტი უშუალოდ ამოწმებს, ამოწმებს და ცვლის, ზრდის ბერკეტს — არა მხოლოდ Codex-ისთვის, არამედ სხვა აგენტებისთვისაც (მაგ. Aardvark), რომლებიც ასევე მუშაობენ კოდის ბაზაზე.

მხოლოდ დოკუმენტაცია სრულად აგენტის მიერ გენერირებულ კოდის ბაზას თანმიმდევრულს ვერ შეინარჩუნებს. ინვარიანტების აღსრულებით და არა იმპლემენტაციების მიკრომენეჯმენტით, აგენტებს საშუალებას ვაძლევთ სწრაფად გამოუშვან ცვლილებები ისე, რომ საფუძველი არ დააზიანონ. მაგალითად, Codex-ს ვთხოვთ, რომ მონაცემთა ფორმები საზღვარზე გააპარსოს⁠(იხსნება ახალ ფანჯარაში), მაგრამ არ ვუკონკრეტებთ, როგორ უნდა გააკეთოს ეს (როგორც ჩანს, მოდელს Zod მოსწონს, მაგრამ ეს კონკრეტული ბიბლიოთეკა ჩვენ არ დაგვისახელებია).

აგენტები ყველაზე ეფექტიანები არიან გარემოებში, სადაც მკაცრი საზღვრები და პროგნოზირებადი სტრუქტურაა⁠(იხსნება ახალ ფანჯარაში), ამიტომ აპლიკაცია მკაცრ არქიტექტურულ მოდელზე ავაგეთ. თითოეული ბიზნეს-დომენი ფიქსირებულ ფენებად იყოფა, მკაცრად ვალიდირებული დამოკიდებულების მიმართულებებით და დასაშვები კავშირების შეზღუდული ნაკრებით. ეს შეზღუდვები მექანიკურად აღსრულდება custom linter-ებით (რა თქმა უნდა, Codex-ის გენერირებულით!) და სტრუქტურული ტესტებით.

ქვემოთ მოცემული დიაგრამა წესს აჩვენებს: თითოეულ ბიზნეს-დომენში (მაგ. App Settings) კოდს შეუძლია დამოკიდებულება მხოლოდ „წინ“ ფიქსირებული ფენების ნაკრებში ჰქონდეს (Types → Config → Repo → Service → Runtime → UI). გამჭოლი საკითხები (auth, connectors, telemetry, feature flags) ერთ მკაფიო ინტერფეისში შემოდის: Providers. სხვა ყველაფერი აკრძალულია და მექანიკურად აღსრულდება.

ეს ისეთი არქიტექტურაა, რომელსაც ჩვეულებრივ იქამდე გადადებთ, სანამ ასობით ინჟინერი არ გეყოლებათ. კოდირების აგენტებთან ერთად კი ეს ადრეული წინაპირობაა: შეზღუდვები სწორედ ისაა, რაც სიჩქარეს გახრწნისა და არქიტექტურული დრეიფის გარეშე შესაძლებელს ხდის.

პრაქტიკაში ამ წესებს custom linter-ებითა და სტრუქტურული ტესტებით, პლუს მცირე რაოდენობის „გემოვნების ინვარიანტებით“ ვამკაცრებთ. მაგალითად, custom lints-ით სტატიკურად ვამოწმებთ სტრუქტურირებულ ლოგირებას, სქემებისა და ტიპების სახელდების კონვენციებს, ფაილის ზომის ლიმიტებს და პლატფორმისთვის სპეციფიკურ სანდოობის მოთხოვნებს. რადგან lint-ები custom-ია, შეცდომის შეტყობინებებს ისე ვწერთ, რომ აგენტის კონტექსტში გამოსასწორებელი ინსტრუქციებიც ჩაიდოს.

ადამიან-პირველ სამუშაო პროცესში ეს წესები შეიძლება ზედმეტად პედანტური ან შემზღუდავი ჩანდეს. აგენტებთან ერთად ისინი გამამრავლებლებად იქცევა: ერთხელ რომ დაკოდირდეს, ერთდროულად ყველგან მოქმედებს.

ამავე დროს, მკაფიოდ ვამბობთ, სად აქვს შეზღუდვებს მნიშვნელობა და სად — არა. ეს ჰგავს დიდი საინჟინრო პლატფორმის ორგანიზაციის მართვას: საზღვრები ცენტრალურად აღსრულდეს, ავტონომია კი ლოკალურად დაიშვას. ღრმად გაწუხებთ საზღვრები, სისწორე და გამეორებადობა. ამ საზღვრების შიგნით კი გუნდებს — ან აგენტებს — მნიშვნელოვანი თავისუფლება აქვთ იმაში, როგორ გამოხატონ გადაწყვეტები.

შედეგად მიღებული კოდი ყოველთვის არ ემთხვევა ადამიანის სტილისტურ პრეფერენციებს, და ეს ნორმალურია. სანამ შედეგი სწორია, მოვლადია და მომავალი აგენტური გაშვებებისთვის წაკითხვადია, ის ბარს აკმაყოფილებს.

ადამიანური გემოვნება სისტემაში უწყვეტად ბრუნდება. მიმოხილვის კომენტარები, რეფაქტორინგის შერწყმის მოთხოვნები და მომხმარებელზე ორიენტირებული ბაგები დოკუმენტაციის განახლებებად ფიქსირდება ან პირდაპირ ინსტრუმენტებში იკოდირება. როცა დოკუმენტაცია საკმარისი აღარ არის, წესს კოდში გადავიტანთ

როცა Codex-ის მწარმოებლურობა გაიზარდა, ბევრი ტრადიციული საინჟინრო ნორმა კონტრპროდუქტიული გახდა.

რეპოზიტორიუმი ფუნქციონირებს შერწყმის მინიმალური დამბლოკავი კარიბჭეებით. შერწყმის მოთხოვნები ხანმოკლეა. ტესტის flaky შემთხვევებს ხშირად შემდგომი გაშვებებით ვაგვარებთ, ნაცვლად იმისა, რომ პროგრესი უსასრულოდ შევაჩეროთ. სისტემაში, სადაც აგენტის მწარმოებლურობა ბევრად აჭარბებს ადამიანურ ყურადღებას, შესწორებები იაფია, ლოდინი კი ძვირი.

დაბალი მწარმოებლურობის გარემოში ეს უპასუხისმგებლო იქნებოდა. აქ კი ხშირად სწორი კომპრომისია.

როცა ვამბობთ, რომ კოდის ბაზა Codex აგენტებმა შექმნეს, ვგულისხმობთ კოდის ბაზაში არსებულ ყველაფერს.

აგენტები ქმნიან:

• პროდუქტის კოდსა და ტესტებს
• CI კონფიგურაციას და რელიზის ინსტრუმენტებს
• შიდა დეველოპერულ ინსტრუმენტებს
• დოკუმენტაციას და დიზაინის ისტორიას
• შეფასების harness-ებს
• მიმოხილვის კომენტარებს და პასუხებს
• სკრიპტებს, რომლებიც თავად რეპოზიტორიუმს მართავს
• პროდაქშენის დეშბორდების განსაზღვრის ფაილებს

ადამიანები ყოველთვის რჩებიან ციკლში, მაგრამ მოქმედებენ აბსტრაქციის სხვა ფენაზე, ვიდრე ადრე. ჩვენ ვანიჭებთ პრიორიტეტს სამუშაოს, მომხმარებლის უკუკავშირს ვთარგმნით მიღების კრიტერიუმებად და ვამოწმებთ შედეგებს. როცა აგენტს უჭირს, ამას სიგნალად ვიღებთ: ვადგენთ, რა აკლია — ინსტრუმენტები, დამცავი მექანიზმები, დოკუმენტაცია — და ამას რეპოზიტორიუმში ვაბრუნებთ, ყოველთვის ისე, რომ შესწორება თავად Codex-მა დაწეროს.

აგენტები პირდაპირ იყენებენ ჩვენს სტანდარტულ დეველოპერულ ინსტრუმენტებს. ისინი იღებენ მიმოხილვის უკუკავშირს, პასუხობენ inline, აგზავნიან განახლებებს და ხშირად თვითონვე squash-სა და merge-ს უკეთებენ საკუთარ შერწყმის მოთხოვნებს.

რადგან განვითარების ციკლის უფრო და უფრო დიდი ნაწილი პირდაპირ სისტემაში დაიკოდირა — ტესტირება, ვალიდაცია, მიმოხილვა, უკუკავშირის დამუშავება და აღდგენა — რეპოზიტორიუმმა ახლახან გადალახა მნიშვნელოვანი ზღვარი, სადაც Codex-ს შეუძლია ახალი ფუნქციის ბოლომდე მართვა.

ერთი მოთხოვნის საფუძველზე აგენტს ახლა შეუძლია:

• კოდის ბაზის მიმდინარე მდგომარეობის ვალიდაცია
• რეპორტირებული ბაგის გამეორება
• მარცხის დემონსტრირებისთვის ვიდეოს ჩაწერა
• შესწორების განხორციელება
• აპლიკაციის მართვით შესწორების ვალიდაცია
• გადაწყვეტის საჩვენებლად მეორე ვიდეოს ჩაწერა
• შერწყმის მოთხოვნის გახსნა
• აგენტისა და ადამიანის უკუკავშირზე პასუხი
• build-ის მარცხების აღმოჩენა და გამოსწორება
• ადამიანამდე ესკალაცია მხოლოდ მაშინ, როცა განსჯაა საჭირო
• ცვლილების შერწყმა

ეს ქცევა ძლიერ არის დამოკიდებული ამ რეპოზიტორიუმის კონკრეტულ სტრუქტურასა და ინსტრუმენტებზე და არ უნდა ვივარაუდოთ, რომ მსგავსი ინვესტიციის გარეშე განზოგადდება — სულ მცირე, ჯერ არა.

აგენტის სრული ავტონომია ასევე ახალ პრობლემებსაც ქმნის. Codex იმეორებს პატერნებს, რომლებიც უკვე არსებობს რეპოზიტორიუმში — მათ შორის არათანაბარ ან არაოპტიმალურებსაც. დროთა განმავლობაში ეს გარდაუვლად იწვევს დრეიფს.

თავდაპირველად ამას ადამიანები ხელით უმკლავდებოდნენ. ჩვენი გუნდი ყოველ პარასკევს (კვირის 20%) ხარჯავდა „AI slop“-ის გასაწმენდად. გასაკვირი არ არის, რომ ეს მასშტაბირებადი არ აღმოჩნდა.

ამის ნაცვლად დავიწყეთ იმის დაკოდირება, რასაც „ოქროს პრინციპებს“ ვუწოდებთ, პირდაპირ რეპოზიტორიუმში და ავაგეთ განმეორებადი დასუფთავების პროცესი. ეს პრინციპები მოსაზრებითი, მექანიკური წესებია, რომლებიც კოდის ბაზას მომავალი აგენტური გაშვებებისთვის წაკითხვადსა და თანმიმდევრულს ინარჩუნებს. მაგალითად: (1) ხელით დაწერილი დამხმარეების ნაცვლად უპირატესობას საერთო utility პაკეტებს ვანიჭებთ, რათა ინვარიანტები ცენტრალიზებული იყოს, და (2) მონაცემებს „YOLO-style“ არ ვსინჯავთ — ვალიდაციას ვაკეთებთ საზღვრებზე ან ვეყრდნობით typed SDK-ებს, რათა აგენტმა შემთხვევით ნავარაუდევ ფორმებზე არ ააგოს რამე. რეგულარული კადენციით გვაქვს ფონური Codex ამოცანების ნაკრები, რომლებიც გადახრებს ეძებენ, ხარისხის შეფასებებს ანახლებენ და მიზნობრივ რეფაქტორინგის შერწყმის მოთხოვნებს ხსნიან. მათი უმეტესობის მიმოხილვა ერთ წუთზე ნაკლებშია შესაძლებელი და ავტომატურად იშერწყმება.

ეს ნაგვის კოლექციას ჰგავს. ტექნიკური ვალი მაღალპროცენტიანი სესხივითაა: თითქმის ყოველთვის უკეთესია მისი უწყვეტად, მცირე ნაბიჯებით დაფარვა, ვიდრე მისი დაგროვების მიცემა და შემდეგ მტკივნეულ ტალღებად მასთან გამკლავება. ადამიანური გემოვნება ერთხელ ფიქსირდება და შემდეგ უწყვეტად აღსრულდება კოდის თითოეულ ხაზზე. ეს ასევე საშუალებას გვაძლევს ყოველდღიურად დავიჭიროთ და მოვაგვაროთ ცუდი პატერნები, ნაცვლად იმისა, რომ ისინი კოდის ბაზაში დღეებით ან კვირებით გავრცელდეს.

ამ სტრატეგიამ აქამდე კარგად იმუშავა OpenAI-ში შიდა გაშვებისა და დანერგვის ეტაპამდე. რეალური მომხმარებლებისთვის რეალური პროდუქტის შექმნა დაგვეხმარა, რომ ჩვენი ინვესტიციები რეალობაზე დაგვემაგრებინა და გრძელვადიანი გამართულობისკენ წაგვეყვანა.

რაც ჯერ არ ვიცით, არის ის, თუ როგორ ვითარდება არქიტექტურული თანმიმდევრულობა წლების განმავლობაში სრულად აგენტის მიერ გენერირებულ სისტემაში. ჯერ კიდევ ვსწავლობთ, სად ამატებს ადამიანური განსჯა ყველაზე მეტ ბერკეტს და როგორ უნდა დავაკოდიროთ ეს განსჯა ისე, რომ დაგროვდეს. ასევე არ ვიცით, როგორ განვითარდება ეს სისტემა, რადგან მოდელები დროთა განმავლობაში უფრო ქმედუნარიანები ხდებიან.

რაც ნათელი გახდა: პროგრამული უზრუნველყოფის შექმნა კვლავ დისციპლინას მოითხოვს, მაგრამ ეს დისციპლინა უფრო კარკასში ჩანს, ვიდრე კოდში. ინსტრუმენტები, აბსტრაქციები და უკუკავშირის ციკლები, რომლებიც კოდის ბაზას თანმიმდევრულს ინარჩუნებს, სულ უფრო მნიშვნელოვანი ხდება.

ჩვენი ყველაზე რთული გამოწვევები ახლა გარემოების, უკუკავშირის ციკლებისა და საკონტროლო სისტემების დიზაინზეა კონცენტრირებული, რომლებიც აგენტებს ჩვენს მიზანში ეხმარება: მასშტაბზე რთული, სანდო პროგრამული უზრუნველყოფის შექმნა და შენარჩუნება.

როდესაც Codex-ის მსგავსი აგენტები პროგრამული ციკლის უფრო დიდ ნაწილს იკავებენ, ეს კითხვები კიდევ უფრო მნიშვნელოვანი გახდება. ვიმედოვნებთ, რომ რამდენიმე ადრეული გაკვეთილის გაზიარება დაგეხმარებათ გაიაზროთ, სად უნდა ჩადოთ ძალისხმევა, რათა უბრალოდ რაღაცები ააშენოთ.