Ճանաչողական պարտք. ինչու է մշակողը ձեռքով վերատպում AI-ի կոդը

Մշակող Անկուր Սեթին իր բլոգում նկարագրել է աշխատանքային մոտեցում, որը թույլ է տալիս անձնական նախագծերում օգտվել AI-ի կոդ գրող օգնականներից՝ չկորցնելով վերահսկողությունը սեփական կոդի վրա։ Նա նշում է, որ դեռ օգտագործում է այդ գործիքները անձնական նախագծերում, սակայն ամբողջ ֆունկցիոնալությունը մեկ հրահանգով գեներացնելը նրա մոտ անբավարարվածություն և ապակողմնորոշում է առաջացնում. հաճույքը գալիս է միայն ձանձրալի հատվածները արագ շրջանցելուց։

Խնդիրը՝ ճանաչողական պարտք

Երբ օգնականն ազատորեն աշխատում է նախագծում, մշակողի մոտ կուտակվում է «հսկայական ճանաչողական պարտք», գրում է նա։ Django-ի փաստաթղթերը կարդալը՝ կայքին պիտակներ ավելացնելու համար, կարող է ձանձրալի լինել, բայց նա միևնույն է ուզում է հասկանալ, թե ինչպես է դա աշխատում. «Այն, որ խնդիրը ձանձրալի է, չի նշանակում, թե պատրաստ եմ լուծման ըմբռնումն ամբողջությամբ հանձնել մեքենային»։ Ամեն տողն ստուգելը՝ 2026 թվականին մշակողներից սպասվող մոտեցումը, նույնպես լուծում չէ. «Pull request-ները ռոբոտներն են բացում, մարդիկ՝ ստուգում։ Քաջ նոր աշխարհ»։ Ըստ նրա՝ հարյուրավոր տողեր «չափից ավելի պաշտպանողական, վատ մեկնաբանված ու նրբորեն սխալ» կոդ կարդալը հաճելի չէ. գործատուի համար դա երբեմն ընդունելի է, իսկ անձնական նախագծերի համար՝ երբեք, որովհետև դրանք առաջին հերթին պետք է հաճույք պատճառեն։

Միտումնավոր անարդյունավետ մոտեցում

Նրա լուծումը, իր իսկ խոսքերով, «կոպիտ անարդյունավետ է և գուցե մի փոքր ծիծաղելի». օգնականից խնդրում է կոդ գեներացնել չաթում, ապա բոլոր փոփոխությունները կատարում է ինքը։ Համապատասխան հրահանգները գրված են նրա անձնական նախագծերի բոլոր գործակալային ֆայլերում։ Ըստ նրա գնահատականի՝ այսպես աշխատում է ավելի արագ, քան առանց LLM-ի, բայց ավելի դանդաղ, քան նրանք, ովքեր թույլ են տալիս մեքենային մտածել իրենց փոխարեն. «10 անգամ արագ լինելու փոխարեն՝ հավանաբար ընդամենը 2 անգամ արագ եմ»։

Փոխարենը նա ստանում է ըմբռնում։ Ամեն տողը ձեռքով տպելը կառուցում է մտավոր մոդել այն մասին, թե ինչպես է կոդը տեղավորվում գոյություն ունեցող կոդային բազայում. անհասկանալի API-ի կամ ալգորիթմի դեպքում կարող է կանգ առնել ու ուսումնասիրել։ Տպելը դանդաղեցնում է նրան, ուստի ավելի հավանական է, որ կնկատի մոդելի հալյուցինացիաները կամ վատ ճարտարապետական որոշումները, և կկարողանա կոդը ճանապարհին կարգավորել ու մեկնաբանել։ Ամենակարևորը՝ այսպես ձևավորվում է կոդային բազայի «տարածական քարտեզը». նա գիտի՝ որտեղ է գտնվում յուրաքանչյուր ֆունկցիա, ինչը հետագայում բարելավում է նաև LLM-ին տրվող հրահանգները։

Ինչու է դա կարևոր

Սեթին այս գործելակերպը համեմատում է ծրագրավորում սովորողներին տրվող հին խորհրդի հետ. մի՛ պատճենիր կոդը, վերատպիր գրքերի ու բլոգների օրինակները, որ հասկանաս դրանք։ «Գուցե սա LLM-ի հետ աշխատելու ամենաարդյունավետ եղանակը չէ, բայց ես ըմբռնումը գերադասում եմ արտադրողականությունից», գրում է նա՝ հավելելով, որ արդեն մի քանի ամիս այսպես է աշխատում և պատրաստվում է շարունակել։ Նրա մտահոգությունն այն է, որ ծրագրային արդյունաբերությունը մեծ ճանաչողական պարտք է կուտակում, որը շուտով պետք կլինի մարել. «Կգա ժամանակ, երբ այլևս չենք հասկանա, թե ինչպես են կառուցված մեր թվային ենթակառուցվածքի մեծ մասերը»։