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