უკან დაბრუნება
„Devtools must be open source“: დევიდ კროშოუს არგუმენტი პერსონალიზებადი ინსტრუმენტებისთვის
SiTech Team2 წთ. საკითხავი

„Devtools must be open source“: დევიდ კროშოუს არგუმენტი პერსონალიზებადი ინსტრუმენტებისთვის

exe.dev-ის ინჟინერი დევიდ კროშოუ 2026 წლის 2 აგვისტოს პოსტში ამტკიცებს, რომ AI-აგენტებმა პროგრამების პერსონალიზაცია იმდენად გააიაფეს, რომ დეველოპერების ინსტრუმენტები ღია კოდის გარეშე ვეღარ არსებობს.

exe.dev-ის ინჟინერმა დევიდ კროშოუმ 2026 წლის 2 აგვისტოს გამოაქვეყნა პოსტი სათაურით „Devtools must be open source“, რომელშიც ამტკიცებს, რომ AI-აგენტებმა პროგრამული უზრუნველყოფის პერსონალიზაცია იმდენად იაფად აქციეს, რომ წყაროს კოდზე წვდომა სულ უფრო აუცილებელი ხდება.

კონფიგურაციიდან პირად პროგრამებამდე

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

ორი პრომპტი, რომელიც ამ გათვლას ცვლის

დღეს, წერს კროშოუ, პროგრამების პერსონალიზაცია საოცრად იოლია. ძირითად სამუშაოს ორი ტიპის პრომპტი ასრულებს: პირველი — ჩამოტვირთე პროგრამის წყარო, ააწყვე ლოკალურად და შეცვალე; აგენტის მეხსიერებაში ჩაწერე, რომ ყოველი მომავალი ცვლილება წყაროს შეცვლასა და მიმდინარე ვერსიის ჩანაცვლებას ნიშნავს, ხოლო ცვლილების მოტივაცია ვერსიათა კონტროლში აღრიცხე. მეორე და უფრო მნიშვნელოვანი — დაგეგმე ღამის cron-დავალება, რომელიც upstream-ის ცვლილებებს წამოიღებს, ლოკალურ ცვლილებებს მათ თავზე გადაიტანს, შეამოწმებს, რომ პროგრამა მუშაობს, და მიმდინარე ვერსიას ჩაანაცვლებს. აგენტებს, აღნიშნავს ის, არა მხოლოდ კოდის დაწერა, არამედ upstream-თან სინქრონიზაციის მართვაც შეუძლიათ — ამიტომ პერსონალიზაციის ანაზღაურება ორივე მხრიდან უმჯობესდება: დაწყებაც იოლია და გაგრძელებაც. რადგან ეს პრომპტები აგენტში უბრალო ტექსტურ ინსტრუქციად (skill) შეიძლება ჩაიდოს, პროგრამირება აღარც კია საჭირო — exe.dev-მა ეს საკუთარ აგენტ Shelley-ში ჩაშენა, და „გახადე Shelley-ის ინტერფეისი მაღალკონტრასტული“-ს დაწერაც კმარა მის გასაპერსონალიზებლად.

წყარო კოდი — ეს თავად გაფართოების სისტემაა

მაგალითად, კროშოუმ თავისი diff-ების შემამცირებელი ხელსაწყო meat.dev Shelley-ში ერთი პრომპტით ჩაშენა — commit-ების ფონური წინასწარი დამუშავებისა და Diffs-ის ხედში გადამრთველის ჩათვლით. იგივეს გაკეთება VS Code-ის გაფართოებების API-ით, მისივე სიტყვებით, „მრუდე ტანჯვა“ იქნებოდა, რადგან გაფართოების წერტილები არასწორ ფორმაშია. ამ ყველაფრისთვის კი, ავტორის არგუმენტით, საჭიროა წვდომა წყაროს კოდზე — მისი ბლოგიც სწორედ ამიტომ არის დამზადებული შეკვეთით, არა მზა პროდუქტით.

სად იყოფა Codex და Claude Code

skill-ზე დაფუძნებული ეს მიდგომა უპრობლემოდ მუშაობს სხვა ღია აგენტებზეც, მაგალითად Pi-ზე; კროშოუ იკვირდება კიდეც, რატომ სჭირდება Pi-ს ჩაშენებული გაფართოების სისტემა, თუ „წყარო კოდი თავად არის გაფართოების სისტემა“. იგივეს გაკეთება Codex-ზეც შეიძლება — ის ღიაა — თუმცა გაცილებით მეტ token-ს მოითხოვს. კედლის წინაშე კი Claude Code-ზე დგები: ის დახურულია, ამიტომ მისი პერსონალიზაცია შეუძლებელია — მხოლოდ იმ customization hook-ებს იყენებ, რაც მწარმოებელს მოჰყვა. რჩევა მკაფიოა: თუ შენთვის სასურველი მუშაობის სტილი ამ hook-ებში არ ჯდება, გადადი აგენტზე, რომელიც პერსონალიზაციის საშუალებას გაძლევს.

SSiTech

SiTech — AI-გაძლიერებული ვებ დეველოპმენტი

ვქმნით სწრაფ, თანამედროვე ვებსაიტებს და AI-ს ვაერთიანებთ ქართული ბიზნესებისთვის. გაქვთ პროექტი ან კითხვა? სიამოვნებით დაგეხმარებით.