Մի քանի տարի առաջ ծրագրավորողի աշխատանքի մասին պատկերացումը պարզ էր․ նստում ես, գրում ես կոդ, ուղղում ես բագերը։ Այսօր շատ թիմերում կոդի մեծ մասը գրում են AI ագենտները, իսկ մարդը ձևակերպում է խնդիրը, ստուգում արդյունքը և որոշում, թե ինչն է պատրաստ թողարկման։
Սա բնական հարցեր է առաջացնում։ Եթե կոդը գրում է մեքենան, ծրագրավորողն էլ պե՞տք է։ Աշխատանքը պակասե՞լ է։ Եվ ի՞նչ հմտություններ արժե զարգացնել հիմա։
Կոդ գրելը դադարում է լինել հիմնական հմտությունը
Շատ մշակողներ այսօր ձեռքով գրում են միայն փոքր, կետային փոփոխություններ։ Նոր ֆունկցիոնալը, թեստերը, ռեֆակտորինգն ու միգրացիաները ավելի ու ավելի հաճախ վստահում են ագենտներին՝ Claude Code-ին, Codex-ին, Cursor-ին և նմանատիպ գործիքներին։
Հեշտ է եզրակացնել, որ կոդ գրելու հմտությունն այլևս ոչինչ չարժե։ Բայց «պարզապես կոդ գրելը» երբեք էլ ծրագրավորողի գլխավոր արժեքը չի եղել։ Ձևաթղթեր հավաքելը կամ տիպային CRUD endpoint-ներ գրելը միշտ էլ համարվել է աշխատանքի ամենահեշտ փոխարինելի մասը։
Արժեքավոր էին և մնում են այն մարդիկ, ովքեր հասկանում են, թե ինչու է համակարգը կառուցված հենց այսպես, որտեղ այն կարող է կոտրվել, ինչպես կազդի փոփոխությունը մյուս մասերի վրա, և ինչպես անցնել մի գործիքից մյուսին՝ առանց ամեն ինչ զրոյից սովորելու։ AI-ն այս տարբերությունը պարզապես ավելի տեսանելի դարձրեց։
Որքա՞ն է AI-ն իրականում արագացնում աշխատանքը
Այս հարցի պատասխանները շատ տարբեր են։ Ոմանք ասում են, որ աշխատում են մի քանի անգամ ավելի արագ։ Ուրիշները գրեթե արագացում չեն զգում, իսկ երբեմն ագենտի գրած կոդը դեբագ անելն ավելի երկար է տևում, քան եթե այն ինքներդ գրեիք։
Հակասություն չկա․ արագացումը կախված է աշխատանքի տեսակից։
Աշխատանքի տեսակ | Ինչ է սովորաբար տալիս AI-ն |
|---|---|
Շաբլոնային կոդ, կոնֆիգուրացիաներ, թեստերի կմախք | Շատ մեծ արագացում |
Նոր նախագծի կամ MVP-ի արագ հավաքում | Զգալի արագացում |
Նոր ֆունկցիոնալ մեծ, երկար ապրող պրոդուկտում | Չափավոր արագացում |
Հազվադեպ, դժվար վերարտադրվող բագի որոնում | Կարող է նույնիսկ դանդաղեցնել |
Սա ընդհանուր պատկեր է, ոչ թե չափումների արդյունք։
Կա նաև ավելի կարևոր պատճառ։ Մեծ պրոդուկտներում կոդ գրելը երբեք էլ ամենաերկար փուլը չի եղել։ Ժամանակի մեծ մասը գնում է պահանջները պարզաբանելու, քննարկումների, code review-ի, թեստավորման, համաձայնեցումների ու թողարկման վրա։ Եթե գործընթացի մեկ փուլն արագացել է տասն անգամ, իսկ մնացածը չեն փոխվել, ամբողջ ցիկլը տասն անգամ չի արագանա։
Հաճախ փորձառու մշակողներն ավելի զուսպ են գնահատում արագացումը։ Հնարավոր պատճառներից մեկն այն է, որ նրանք ավելի լավ են տեսնում, թե ինչ խնդիրներ կարող է ստեղծել առանց վերահսկողության գեներացված կոդը։
AI-first մշակում և «human in the loop»
AI-ն աստիճանաբար հայտնվում է ոչ միայն կոդ գրելիս, այլև մշակման բոլոր փուլերում՝ պահանջների վերլուծություն, դիզայն, թեստեր, review, դոկումենտացիա, մոնիթորինգ։ Այս մոտեցումը հաճախ անվանում են AI-first SDLC։
Բայց ամբողջ ցիկլում մի դեր մնում է անփոփոխ․ ինչ-որ մեկը պետք է որոշի՝ արդյունքը ճի՞շտ է, թե ոչ, և պատասխանատվություն կրի դրա համար։ Սա էլ «human in the loop»-ն է։
flowchart LR
A["Խնդրի ձևակերպում և սպեցիֆիկացիա"] --> B["Ագենտը գրում է կոդը"]
B --> C["Մարդը ստուգում է՝ review և թեստեր"]
C -->|Պետք են ուղղումներ| A
C -->|Պատրաստ է| D["Թողարկում"]
D --> E["Մոնիթորինգ և հետադարձ կապ"]
E --> AԱշխատանքային օրը սկսում է ցիկլի նմանվել․ գրում ես առաջադրանքի հստակ նկարագրություն, գործարկում ագենտին, ստուգում արդյունքը, ճշգրտում ուղղությունը և կրկնում։ Կոդի հեղինակից մշակողը դառնում է դրա խմբագիրն ու պատասխանատուն։
Աշխատանքը պակասե՞լ է
Տրամաբանական կթվար, որ եթե կոդն ավելի արագ է գրվում, աշխատանքն էլ պետք է պակասի։ Գործնականում հաճախ հակառակն է լինում։ Երբ ղեկավարությունը տեսնում է, որ կարելի է ավելի արագ աշխատել, աճում են նաև ակնկալիքները՝ ավելի շատ ֆունկցիոնալ, ավելի սեղմ ժամկետներ, ավելի շատ փորձարկումներ։
Աշխատանքը չի վերացել, փոխվել է դրա բովանդակությունը։ Ավելի քիչ ժամանակ է գնում տպելու վրա, ավելի շատ՝ ճարտարապետության, system design-ի, պրոդուկտային որոշումների և ստուգման վրա։
Միաժամանակ շատ մշակողներ AI գործիքներն օգտագործում են բավականին զուսպ՝ որպես օգնական, ոչ թե որպես զուգահեռ աշխատող մի քանի ագենտների «թիմ»։ Գործիքների ամբողջ ներուժն օգտագործողները դեռ փոքրամասնություն են։
Կփոխարինի՞ AI-ն ծրագրավորողներին
Պատասխանը կախված է նրանից, թե ինչ աշխատանքի մասին է խոսքը։
Փոքր, առանձին խնդիրներում փոխարինումն արդեն տեղի է ունեցել։ Պարզ Telegram բոտ, լենդինգ էջ կամ փոքր ներքին գործիք պատրաստելու համար այլևս միշտ չէ, որ ֆրիլանսեր է պետք․ մարդը կարող է դա ինքնուրույն անել AI գործիքով։
Մեծ պրոդուկտներում պատկերն այլ է։ Այնտեղ մի քանի մարդ միաժամանակ փոփոխում է նույն կոդային բազան, կան CI/CD խողովակաշարեր, թեստեր, անվտանգության պահանջներ, հաճախորդներ և պատասխանատվություն։ Այս ամենի մի մասը կարելի է ավտոմատացնել, բայց որոշում կայացնող և պատասխանատու մարդը մնում է։
«Եթե նախկինում 100 մարդ էր պետք, հիմա 10-ը կբավարարի» փաստարկը նույնպես պարզեցում է։ Պրոդուկտային ընկերություններում աշխատանքը սովորաբար չի վերջանում․ միշտ կա հաջորդ ֆունկցիան, մրցակիցը, նոր շուկան։ Եթե թիմն ավելի արագ է աշխատում, ընկերությունը սովորաբար ավելի շատ բան է ուզում անել, ոչ թե պակաս մարդ պահել։
Իրական որոշիչը հաճախ տնտեսությունն է։ Փող և աճի հնարավորություն ունեցող ընկերությունները կշարունակեն վարձել և արագացնել տեմպը։ Դժվարություններ ունեցողները կկրճատեն աշխատակիցներին՝ երբեմն դա ներկայացնելով որպես «ավտոմատացում»։
Վարձման պարադոքսը
Այսօր շատ թիմերում իրավիճակը հակասական է։ Առաջադրանքները շատ են, պահանջներն աճել են, լիդները սիրով կվերցնեին ևս մի քանի մարդ, բայց բյուջեները սեղմ են, և նոր վականսիաներ գրեթե չեն բացվում։
Աշխատանք փնտրողների համար սա նշանակում է ավելի երկար որոնում և ավելի մեծ մրցակցություն։ Բայց աշխատաշուկան ալիքաձև է․ դժվար շրջաններին հաջորդում են ակտիվ վարձման շրջաններ։ «IT-ն մեռավ» խոսակցությունները նոր չեն, դրանք հնչում էին դեռ AI ագենտների ի հայտ գալուց առաջ։
Պատկերը տարբեր է նաև ըստ ոլորտի և երկրի։ Օրինակ՝ բանկային և այլ կարգավորվող ոլորտներում արտաքին AI ծառայությունների օգտագործումը հաճախ սահմանափակված է, և այնտեղ փոփոխություններն ավելի դանդաղ են ընթանում։
Վայբ-կոդինգ և «AI slop» պրոդուկտներ
AI գործիքների մատչելիությունը նոր ալիք է ծնել․ շատերը փորձում են մենակով, մի քանի օրում հավաքել ամբողջական պրոդուկտ։ Արդյունքում շուկան լցվում է արագ հավաքված, իրար նման ծառայություններով, որոնց հաճախ անվանում են «AI slop»։
Մենակով պրոդուկտ սարքելու հնարավորությունն իսկապես արժեքավոր է։ Բայց թողարկումից հետո հարցերը նոր են սկսվում․
Ո՞վ է պատասխանելու օգտատերերի հարցերին և բագերի մասին հաղորդումներին։
Ո՞վ է հետևելու ենթակառուցվածքին, անվտանգությանը, պահուստային պատճեններին։
Ինչպե՞ս ավելացնել նոր ֆունկցիոնալ՝ առանց հինը կոտրելու, եթե կոդը գրվել է արագ և առանց ճարտարապետական պլանի։
Ո՞վ է «վճարելու» կուտակված տեխնիկական պարտքի համար։
Եթե պրոդուկտը հաջողում է, թիմն անխուսափելիորեն մեծանում է։ Պետք են լինում ծրագրավորողներ, սափորտ, DevOps և այլ դերեր։
Թիմերը կդառնան ավելի փոքր և ունիվերսալ
Ավանդական թիմում կարող էին լինել մի քանի ֆրոնտենդ և բեքենդ մշակողներ, առանձին թեստեր և դիզայներ, և յուրաքանչյուրը զբաղվում էր իր հատվածով։ AI գործիքների հետ ավելի տրամաբանական է դառնում այլ կառուցվածք։
Հատկանիշ | Ավանդական թիմ | Փոքր ունիվերսալ թիմ |
|---|---|---|
Կազմ | Առանձին ֆրոնտենդ և բեքենդ մշակողներ, թեստեր, դիզայներ | 2–3 ֆուլսթեք մշակող, թեստեր, պրոդուկտ մենեջեր, դիզայներ |
Պատասխանատվություն | Ամեն մեկը՝ իր շերտի համար | Ամբողջ թիմը՝ ֆունկցիայի համար՝ սկզբից մինչև վերջ |
Ագենտների դերը | Օգնական առանձին առաջադրանքներում | Աշխատանքի հիմնական մասի կատարող՝ մարդու վերահսկողությամբ |
Հիմնական ռիսկը | Համաձայնեցումների երկար շղթա | Կախվածություն մի քանի մարդու գիտելիքից |
Մեկ մեծ թիմի փոխարեն կարող են լինել մի քանի փոքր թիմեր, որոնք ավելի արագ են որոշումներ կայացնում և ավելի քիչ ժամանակ են կորցնում համաձայնեցումների վրա։ Սա կանխատեսում է, ոչ թե օրենք, բայց ուղղությունն արդեն երևում է։
Ի՞նչ հմտություններ զարգացնել հիմա
Ճարտարապետություն և system design։ Ագենտը կարող է գրել կոդը, բայց համակարգի կառուցվածքի մասին որոշումը մնում է մարդուն։
Խնդիրը հստակ ձևակերպելու կարողություն։ Լավ սպեցիֆիկացիան այսօր նույնքան կարևոր է, որքան լավ կոդը։ Որքան հստակ է առաջադրանքը, այնքան քիչ ժամանակ է գնում ուղղումների վրա։
Կոդ կարդալ և ստուգել։ Գեներացված կոդի review-ն դառնում է ամենօրյա աշխատանքի հիմնական մասը։ Պետք է արագ նկատել անվտանգության խնդիրները, ավելորդ բարդությունն ու սխալ ենթադրությունները։
Լայն մտահորիզոն։ Ֆրոնտենդի, բեքենդի, տվյալների բազաների, DevOps-ի և անվտանգության հիմունքների իմացությունը թույլ է տալիս ագենտին ավելի մեծ առաջադրանքներ վստահել և դրանք ստուգել։
Պրոդուկտային մտածողություն։ Ծրագրավորողի խնդիրը միշտ էլ եղել է ֆունկցիան որակով և ժամանակին հասցնել օգտատիրոջը, ոչ թե պարզապես կոդ գրել։
Թիմային աշխատանքի փորձ։ Մենակով վայբ-կոդինգը և թիմում աշխատելը տարբեր բաներ են։ Կոնֆլիկտների լուծումը, review-ն, ընդհանուր կանոններն ու պատասխանատվության բաշխումը հնարավոր չէ սովորել միայն սոլո նախագծերով։
Եզրակացություն
AI-ն փոխում է ոչ թե այն, թե արդյոք ծրագրավորողներ պետք են, այլ այն, թե ինչ է նշանակում լինել ծրագրավորող։ Տպելու արագությունը կորցնում է իր արժեքը, իսկ դատողությունը, ճարտարապետական մտածողությունն ու պատասխանատվությունը դառնում են գլխավորը։
Ոչ ոք չի կարող վստահ ասել, թե ինչպիսին կլինի շուկան մի քանի տարի հետո։ Բայց մի բան արդեն պարզ է․
Կոդը կարող է գրել ագենտը, բայց որոշում կայացնողն ու պատասխանատուն մարդն է։









Comments (2)