როგორ გამოვიყენეთ Codex, რათა 28 დღეში Android-ისთვის Sora შეგვექმნა

2026 წლის 26 აპრილიდან Sora პროდუქტი აღარ არის ხელმისაწვდომი.

ნოემბერში Sora Android აპი მთელ მსოფლიოში გავუშვით და Android მოწყობილობის მქონე ნებისმიერს მივეცით შესაძლებლობა, მოკლე მოთხოვნა ცოცხალ ვიდეოდ ექცია. გაშვების დღეს აპმა Play Store-ში #1 ადგილი დაიკავა. Android-ის მომხმარებლებმა პირველ 24 საათში მილიონზე მეტი ვიდეო შექმნეს.

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

2025 წლის 8 ოქტომბრიდან 5 ნოემბრამდე მცირე საინჟინრო გუნდმა, რომელიც Codex-თან ერთად მუშაობდა და დაახლოებით 5 მილიარდ token-ს მოიხმარდა, Sora for Android პროტოტიპიდან გლობალურ გაშვებამდე მიიყვანა. მასშტაბის მიუხედავად, აპს 99.9-პროცენტიანი crash-free მაჩვენებელი აქვს და ისეთი არქიტექტურა, რომლითაც ვამაყობთ. თუ გაინტერესებთ, საიდუმლო მოდელი ხომ არ გამოგვიყენებია — გამოვიყენეთ 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-ს მოწყობილობაზე, ვერ ამჩნევდა, რომ სქროლი არაბუნებრივად მუშაობდა, ან რომ გარკვეული flow დამაბნეველი იყო. ასეთ გამოცდილებით ამოცანებს მხოლოდ ჩვენი გუნდი ფარავდა.
3. თითოეულ ინსტანციას ონბორდინგი სჭირდება. Codex-ის კარგი შესრულებისთვის აუცილებელი იყო კონტექსტის გაზიარება, მკაფიო მიზნებით, შეზღუდვებით და მითითებით, თუ „როგორ ვაკეთებთ ჩვენ საქმეებს“.
4. იგივე მიმართულებით, Codex-ს უჭირდა ღრმა არქიტექტურული განსჯა: თუ მას თავის ნებაზე დავტოვებდით, შესაძლოა დაემატებინა ზედმეტი 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 კოდის review-შიც ძალიან კარგია და ხშირად merge-მდე ამჩნევს შეცდომებს, რაც სანდოობას აუმჯობესებს.

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

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

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

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

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

ვივარაუდეთ, რომ Codex კარგად იმუშავებდა კარგად დაწერილი მაგალითების „sandbox“-ში — და მართლაც ასე მოხდა. Codex-ისთვის მოთხოვნა „ააწყე ეს settings ეკრანი“ თითქმის კონტექსტის გარეშე არასანდო იყო. ბევრად უკეთ მუშაობდა მოთხოვნა: „ააწყე ეს settings ეკრანი იმავე არქიტექტურითა და შაბლონებით, რაც იმ სხვა ეკრანს აქვს, რომელიც ახლახან ნახე.“ ადამიანები იღებდნენ სტრუქტურულ გადაწყვეტილებებს და აყენებდნენ უცვლელ წესებს; შემდეგ Codex ამ სტრუქტურაში კოდის დიდ მოცულობას ავსებდა.

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

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

ამიტომ სამუშაო პროცესი შევცვალეთ. ნებისმიერი არატრივიალური ცვლილებისთვის ჯერ Codex-ს ვთხოვდით დაგვხმარებოდა იმის გაგებაში, როგორ მუშაობს სისტემა და კოდი. მაგალითად, ვთხოვდით, წაეკითხა დაკავშირებული ფაილების ნაკრები და შეეჯამებინა, როგორ მუშაობს ეს ფუნქცია; მაგალითად, როგორ მიედინება მონაცემი API-დან რეპოზიტორიუმის შრის, view model-ის და შემდეგ UI-ის გავლით. შემდეგ მის გაგებას ვასწორებდით ან ვაზუსტებდით. (მაგალითად, მივუთითებდით, რომ კონკრეტული აბსტრაქცია რეალურად სხვა შრეს ეკუთვნის, ან რომ მოცემული კლასი მხოლოდ ოფლაინ რეჟიმისთვის არსებობს და მისი გაფართოება არ უნდა მოხდეს.)

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

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

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

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

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

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

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

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

პროექტი უზარმაზარი საწყისი უპირატესობით დავიწყეთ: Sora უკვე გაშვებული იყო iOS-ზე. ხშირად ვუთითებდით Codex-ს iOS-ისა და backend-ის კოდბეისებზე, რათა ძირითადი მოთხოვნები და შეზღუდვები უკეთ გაეგო. მთელი პროექტის განმავლობაში ვხუმრობდით, რომ თითქოს cross-platform framework-ის იდეა ხელახლა გამოვიგონეთ. დაივიწყეთ React Native ან Flutter; cross-platform-ის მომავალი უბრალოდ Codex-ია.

ამ ხუმრობის უკან ორი პრინციპი დგას:.

1. ლოგიკა გადატანადია. კოდი Swift-შია დაწერილი თუ Kotlin-ში, აპლიკაციის საფუძვლიანი ლოგიკა — მონაცემთა მოდელები, ქსელური გამოძახებები, ვალიდაციის წესები, ბიზნესლოგიკა — ერთია. Codex ძალიან კარგად კითხულობს Swift-ის იმპლემენტაციას და ქმნის Kotlin-ში მის ეკვივალენტს ისე, რომ სემანტიკა შენარჩუნდეს.
2. კონკრეტული მაგალითები ძლიერ კონტექსტს იძლევა. ახალი Codex სესია, რომელსაც შეუძლია დაინახოს „აი ზუსტად ასე მუშაობს ეს iOS-ზე“ და „აი Android-ის არქიტექტურა“, ბევრად უფრო ეფექტიანია, ვიდრე ის, რომელიც მხოლოდ ბუნებრივი ენის აღწერებზე მუშაობს.

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

„წაიკითხე ეს მოდელები და საბოლოო წერტილები iOS კოდში და შემდეგ შემომთავაზე გეგმა, როგორ განვახორციელოთ ეკვივალენტური ქცევა Android-ზე ჩვენი არსებული API კლიენტისა და model კლასების გამოყენებით.“

ერთი პატარა, მაგრამ სასარგებლო ხრიკი იყო, რომ ~/.codex/AGENTS.md-ში დეტალურად აღვწერდით, სად ინახებოდა ადგილობრივი რეპოზიტორიუმები და რას შეიცავდა თითოეული. ეს Codex-ს უადვილებდა შესაბამისი კოდის აღმოჩენასა და ნავიგაციას.

ჩვენ ფაქტობრივად cross-platform განვითარებას გაზიარებული აბსტრაქციის ნაცვლად „თარგმნის“ გზით ვაკეთებდით. რადგან თარგმნის უმეტეს ნაწილს Codex იღებდა თავის თავზე, იმპლემენტაციის ხარჯების გაორმაგებას ავცდით.

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

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

ცხადი გახდა, რომ AI-assisted განვითარება სიზუსტის საჭიროებას არ ამცირებს; პირიქით, ზრდის. მიუხედავად იმისა, რამდენად უნარიანია Codex, მისი მიზანია აქ და ახლა A-დან B-მდე მისვლა. სწორედ ამიტომ არ მუშაობს AI-assisted კოდირება ადამიანების გარეშე. პროგრამულ ინჟინრებს შეუძლიათ გაიგონ და გამოიყენონ სისტემების რეალური სამყაროს შეზღუდვები, საუკეთესო გზები software-ის არქიტექტურისთვის და ის, როგორ აშენდეს ყველაფერი მომავალი განვითარების და პროდუქტის გეგმების გათვალისწინებით. ხვალინდელი პროგრამული ინჟინრის სუპერძალა იქნება სისტემების ღრმა გაგება და AI-თან ხანგრძლივი დროის ჰორიზონტზე თანამშრომლობის უნარი.

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

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

როცა Codex შვიდი თვის წინ კვლევით preview-ში გაეშვა, software engineering ძალიან სხვანაირად გამოიყურებოდა. Sora-ს მეშვეობით ინჟინერიის შემდეგი თავის შესწავლის შესაძლებლობა მოგვეცა. ჩვენი მოდელებისა და harness-ის გაუმჯობესებასთან ერთად, AI შექმნის პროცესის სულ უფრო შეუცვლელი ნაწილი გახდება.

თქვენ რას შექმნით Codex-ის საკუთარი გუნდით?