ჩვენ პროგრამული უზრუნველყოფის განვითარების გარდამტეხ ეტაპზე ვიმყოფებით. დისკუსია ხშირად ეხება საკითხს, თუ რომელი ხელოვნური ინტელექტი წერს საუკეთესო კოდს (Claude თუ ChatGPT), ან სად სად უნდა განთავსდეს ეს ხელოვნური ინტელექტი (IDE-ში თუ CLI-ში). თუმცა, ეს სწორი დასმა არ არის.
თუ ხელოვნურ ინტელექტს „ვაიბ-კოდერების“ სახით მივიღებთ — როდესაც ჩვენ განზრახვას ვუთითებთ, შესრულებას კი ხელოვნურ ინტელექტს ვანდობთ — ახალი პროგრამული უზრუნველყოფის უზარმაზარ ნაკადს შევქმნით. ხელოვნური ინტელექტის აგენტების გუნდს ერთ წუთში იმაზე მეტი კოდის გენერირება შეუძლია, ვიდრე უფროს დეველოპერს ერთ კვირაში შეუძლია გადახედოს. ადამიანი უკვე შემაფერხებელ ფაქტორად იქცა.
გამოსავალი არ არის მეტი ადამიანები. გამოსავალი არის ხელოვნური ინტელექტის დიზაინის მართვის ორგანო.
ტრადიციულად, „დიზაინის მართვის ორგანო“ არქიტექტორების მცირე ჯგუფია, რომელიც კვირაში ან თვეში ერთხელ იკრიბება დიზაინის დასამტკიცებლად ან უარსაყოფად. სამყაროში, სადაც სწრაფი ტემპით მიმდინარე ხელოვნური ინტელექტის განვითარებისა ეს მოდელი უიმედოდ მოძველებულია. ის ძალიან ნელი და რეაქტიულია.
თუ „ერთჯერად კოდზე“ გადავერთვებით — პროგრამულ უზრუნველყოფაზე, რომელსაც მოთხოვნების ცვლილებისას უსასრულოდ აღარ გადავამუშავებთ, არამედ გადავაგდებთ და თავიდან შევქმნით — ჩვენი როლი საფუძვლიანად შეიცვლება. ჩვენ აღარ ვართ აგურ-აგურ მშენებელი ქვისმთლელები. ჩვენ ქარხნის არქიტექტორები ვართ, რომლებიც კედლებს ბეჭდავენ.
მაგრამ ვინ ამოწმებს, სწორად დგას თუ არა ეს კედლები?
AI დიზაინის ავტორიტეტი ადამიანი კი არა, არამედ კონვეიერული პროცესია. „განტლეტი“, რომლის გავლაც წარმოებაში მოსახვედრად გენერირებულმა კოდის თითოეულმა სტრიქონმა უნდა შეძლოს. ეს პროცესი ადამიანურ კოდის მიმოხილვას არ ანაცვლებს არაფრით, არამედ რაღაცით უკეთესით.
ის სამ ფენად მუშაობს:
1. აღმასრულებელი ძალა (გენერაცია)
ჩვენ ერთ AI-ს არ ვთხოვთ გადაწყვეტას — სამს ვთხოვთ. Gemini 3-ს, GPT-5-სა და ღია კოდის მქონე მოდელს (მაგალითად, Llama-ს) ერთსა და იმავე პრობლემაზე პარალელურად ვამუშავებთ. ეს ხელს უშლის ვიწრო ხედვას და არღვევს „სიზარმაცეს“, რომელიც LLM-ებს ზოგჯერ ახასიათებთ. ეს მიდგომა ასევე მეცნიერულად არის გამოკვლეული და ადასტურებს, რომ შესაძლებელია AI-ის ჰალუცინაციების თავიდან აცილება და შეცდომების გარეშე ძალიან გრძელი ჯაჭვების აგება
2. მკაცრი ფილტრი (კანონი)
აქ დისკუსიის ადგილი არ არის. კოდი უნდა დაკომპილირდეს. ლინტერებმა პრეტენზია არ უნდა გამოთქვან. და რაც მთავარია, შავი ყუთის ტესტები უნდა გაიარონ. ჩვენ არ ვამოწმებთ, ფუნქცია შიგნიდან მუშაობს თუ არა (ამის მანიპულირება AI-ს შეუძლია); ვამოწმებთ, აკეთებს თუ არა სისტემა გარედან იმას, რაც უნდა გააკეთოს. ტესტი ჩავარდა? მაშინვე სანაგვეში.
3. რბილი ფილტრი (ხელოვნური ინტელექტის ჟიური)
ეს ნამდვილი ინოვაციაა. დარჩენილი გადაწყვეტილებები გადაეცემა სპეციალიზებულ „Voting AI“-ს. ეს აგენტი კოდს არ წერს, არამედ კითხულობს კოდი. ის გაწვრთნილია ჩვენი არქიტექტურული პრინციპების, უსაფრთხოების მოთხოვნების (ოვასპ, აისო) და შესაბამისობის წესების (ევროკავშირის ხელოვნური ინტელექტის აქტი) გათვალისწინებით.
ის აფასებს: „გადაწყვეტა A უფრო სწრაფია, მაგრამ გადაწყვეტა B უფრო უსაფრთხოა და უკეთ შეესაბამება ჩვენს მიკროსერვისულ არქიტექტურას.“
გამარჯვებული გადაწყვეტა გადადის წარმოებაში.
ეს მოდელი ძალაუფლების განაწილებას უზრუნველყოფს — პრინციპს, რომელიც ბევრ გუნდში არ არსებობს.
project-description.md, rules.md, skills.md en principles.md), მკაცრ მოთხოვნებს. არქიტექტორი განსაზღვრავს რას რას ვაშენებთ, ვინ აშენებს და როგორ რატომ.ის გვათავისუფლებს სინტაქსური შეცდომების ტირანიისგან და საშუალებას გვაძლევს, ყურადღება გავამახვილოთ იმაზე, რაც კარგად გამოგვდის: სისტემურ აზროვნებაზე, ჭეშმარიტების დადგენაზე, სტრუქტურასა და გადაწყვეტილებების მიღებაზე.
საკითხავი აღარ არის, შეუძლია თუ არა ხელოვნურ ინტელექტს ჩვენი კოდის დაწერა. ეს საკითხი უკვე გადაწყვეტილია. კოდი, ძირითადად, ერთჯერად პროდუქტად იქცევა.
საკითხავია: გაბედავ თუ არა, ხელი აიღო კონტროლზე კოდზე რათა ამით კვლავ მოიპოვო კონტროლი ხარისხზე დასაბრუნებლად?
შემატყობინე