Ծրագրավորողի գործիքները պետք է բաց կոդով լինեն. գործակալներն անհատականացումը դարձնում են էժան

exe.dev-ի ինժեներ Դեյվիդ Քրոշոն 2026 թվականի օգոստոսի 2-ին հրապարակել է «Devtools must be open source» վերնագրով գրառում, որտեղ պնդում է, որ AI գործակալներն այնքան էժան են դարձրել ծրագրային ապահովման անհատականացումը, որ ելակետային կոդի հասանելիությունը դառնում է գրեթե պարտադիր։

Կոնֆիգուրացիայից՝ անձնական ծրագրեր

Հեղինակը հիշում է, որ հինգ տարի առաջ իր ծանոթ ինժեներներից գրեթե ոչ ոք չուներ իր համար գրված ծրագիր. ամբողջ օրը նրանք օգտագործում էին ուրիշների գրած ծրագրերը, որպեսզի ծրագրեր գրեին ուրիշների համար։ Սեփական օգտագործման համար ծրագիր գրելը, հատկապես՝ դրա սպասարկումը, եկամտաբեր չէր. օրական միայն սահմանափակ քանակի կոդ կարելի էր գրել, իսկ մեկ տարի անց նախագծին վերադառնալը՝ ցավալի։ Հենց այդ տնտեսական տրամաբանությունն է բացատրում, թե ինչու բարդ ծրագրերը թողարկվում էին կոնֆիգուրացիայի ֆայլերով ու պլագինների համակարգերով. բազմաթիվ օգտատերերի համար նախագծելը արդարացնում էր ծախսերը։

Երկու պրոմպտ, որ փոխում են հաշվարկը

Այսօր, գրում է Քրոշոն, ծրագրերի անհատականացումը զարմանալիորեն հեշտ է։ Հիմնական աշխատանքը կատարում են երկու տեսակի պրոմպտներ. առաջինը՝ ներբեռնիր ծրագրի ելակետային կոդը, կառուցիր լոկալ օգտագործման համար և փոփոխիր այն. գործակալի հիշողության մեջ գրանցիր, որ ապագա ցանկացած փոփոխություն նշանակում է փոփոխել կոդն ու փոխարինել ընթացիկ տարբերակը, իսկ փոփոխության դրդապատճառը արձանագրիր տարբերակների կառավարման համակարգում։ Երկրորդը և ավելի կարևորը՝ կարգավորիր գիշերային cron առաջադրանք, որը բերում է upstream-ի փոփոխությունները, դրանց վրա տեղափոխում լոկալ փոփոխությունները, ստուգում, որ ծրագիրը աշխատում է, և փոխարինում ընթացիկ տարբերակը։ Գործակալները, նշում է նա, կարողանում են ոչ միայն կոդ գրել, այլև կառավարել upstream-ի հետ սինխրոնացումը, ուստի անհատականացման վերադարձը բարելավվում է միանգամից երկու կողմից. ավելի հեշտ է սկսել և ավելի հեշտ է շարունակել։ Քանի որ այս պրոմպտները կարելի է ներկառուցել գործակալի մեջ որպես skill՝ պարզ տեքստային հրահանգ, ծրագրավորում նույնիսկ պետք չէ. exe.dev-ը դա ներկառուցել է իր Shelley գործակալում, և բավական է գրել՝ «Shelley-ի ինտերֆեյսը դարձրու բարձր կոնտրաստային»։

Ելակետային կոդը հենց ինքն է ընդլայնման համակարգը

Որպես գործնական օրինակ՝ Քրոշոն պատմում է, թե ինչպես իր meat.dev diff-երը կրճատող գործիքը Shelley-ի մեջ ներկառուցեց ընդամենը մեկ պրոմպտով՝ ներառյալ commit-ների ֆոնային նախնական մշակումը և Diffs դիտքի փոխարկիչը։ Նույնը VS Code-ի ընդլայնումների API-ով անելը, նրա խոսքերով, «ոլորապտույտ տանջանք» կլիներ, որովհետև ընդլայնման կետերը սխալ ձևի մեջ են։ Այս ամենի համար, պնդում է հեղինակը, պետք է հասանելիություն ելակետային կոդին։

Որտեղ են բաժանվում Codex-ն ու Claude Code-ը

Skill-ի վրա հիմնված այս մոտեցումը հեշտությամբ աշխատում է նաև այլ բաց գործակալների հետ, օրինակ՝ Pi-ի. Քրոշոն զարմանում է նույնիսկ, թե ինչու Pi-ին ընդհանրապես պետք է ներկառուցված ընդլայնումների համակարգ, եթե «ելակետային կոդը հենց ինքն է ընդլայնման համակարգը»։ Նույնը կարելի է անել Codex-ի հետ, որը բաց կոդով է, սակայն դա շատ ավելի շատ token կպահանջի։ Պատը Claude Code-ն է. այն փակ է, ուստի հնարավոր չէ անհատականացնել, մնում են միայն արտադրողի տրամադրած customization hook-երը։ Խորհուրդը հստակ է. եթե ձեր ուզած աշխատանքի ձևը չի տեղավորվում այդ hook-երի մեջ, անցեք գործակալի, որը թույլ է տալիս անհատականացում։