როგორ ამოწმებს Aviator 4-ჯერ მეტ AI კოდს ყოველი ხაზის წაკითხვის გარეშე

Aviator-ის თქმით, იგივე ცხრა ინჟინერმა 4-ჯერ მეტი pull request გააერთიანა, რადგან ნედლი დიფების ნაცვლად მიზანს, მიღების კრიტერიუმებს, ინვარიანტებს, გადაწყვეტილებებსა და მტკიცებულებებს ამოწმებდა. შერწყმის მედიანური დრო 2,1 დღიდან 3,4 საათამდე შემცირდა, უკუქცევები 40%-ით შემცირდა, ადამიანი კი კვლავ ყოველ pull request-ს ამტკიცებს.

პრობლემა: კოდის გადახედვა AI-ის ტემპს ვერ ეწევა

გუნდის კოდი ადამიანის მიერ AI-ის დახმარებით დაწერილიდან AI-ის მიერ გენერირებულზე გადავიდა, ადამიანის დახმარებით. კვირაში შერწყმული pull request-ები 100-დან 400-ზე მეტ რაოდენობამდე გაიზარდა, AI-ის მიერ გენერირებული pull request-ის მედიანა კი 640 ხაზია, 400 ხაზს გასცდა, რაც ფართოდ ითვლება ზღვრად, რომლის შემდეგაც შეცდომების აღმოჩენა ვარდება.

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

რა შეიცვალა: ამოწმებენ მიზანს, არა ხაზებს

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

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

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

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

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

შედეგები

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

წყაროები: The New Stack