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

კოდი, როგორც მანქანური ენა

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

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

რატომ არ მუშაობს ძველი მიდგომა?

Thoughtworks-ის ბოლო ანგარიშის მიხედვით, LLM-ების მიერ გენერირებული კოდი არადეტერმინისტულია. მისი წაკითხვა და გააზრება იმაზე მეტ დროს მოითხოვს, ვიდრე თავად კოდის გენერირება. შედეგად, ტრადიციული Pull Request-ების განხილვა ხდება არაეფექტური და შემაფერხებელი.

ამდალის კანონის (Amdahl's law) მიხედვით, თუ მხოლოდ კოდის წერის სისწრაფეს გავზრდით, მაგრამ პროცესებს არ შევცვლით, რეალურ პროდუქტიულობას ვერ მივიღებთ. ორგანიზაციამ უნდა უარი თქვას ადამიანის ჩართულობაზე თითოეულ ეტაპზე.

სად უნდა გადავიდეს კონტროლი?

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

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

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