AI կոդավորման գործիքները դեռ գտնվում են հետազոտության և զարգացման փուլում

Ըստ Stack Overflow-ի 2024 թվականի հետազոտության ՝ ծրագրավորողների 76%-ն օգտագործում կամ ծրագրում է օգտագործել AI գործիքներ՝ նրանք այժմ աշխատանքի միայն մի մասն են: Նրանք օգնում են առօրյա գործերում, բայց կարող են նյարդայնացնել, երբ նրանք վստահորեն անհեթեթություն են առաջացնում: Մինչ YouTube-ները ChatGPT-ի հուշումներով կառուցում են «միլիարդանոց ստարտափներ», և AI գործակալները ամեն շաբաթ տիրում են աշխարհը, իրական թիմերը դեռ պարզում են, թե ինչպես արդյունավետ օգտագործել այս գործիքները: Այսօր արհեստական ինտելեկտի օգնության յուրացումը նույնքան հիմնարար է, որքան կոդավորումը կամ համակարգի ձևավորումը. մենք պետք է հարմարվենք և արագ:

Խնդիրն այն է, որ այս գործիքները, ըստ էության, դեռ գտնվում են հետազոտության և զարգացման փուլում. դրանք անընդհատ փոխվում են, կրկնօրինակում են միմյանց և արժանի են նախկինում չլուծված խնդիրների լուծմանը: Նրանք բոլորն էլ չունեն հստակ օգտագործման ուղեցույցներ: Նույնիսկ Copilot-ը, չնայած ավելի կայացած լինելուն, չունի հստակ ձեռնարկներ և լավագույն փորձ: Լուծումը. Մենք կանենք այն, ինչ լավագույնս անում են մշակողները՝ ինքներս կազմակերպել և ստեղծել շրջանակ:

Խաղի փոխարկիչ

...և նաև « Քվանտային ցատկ », « Պարադիգմային հերթափոխ », « Գործակալները գալիս են », դուք ասեք: Թեև այս գործիքներն իսկապես փոխում են մեր աշխատանքային հոսքը, փոփոխությունն ավելի գործնական է. ծրագրավորողներն այժմ գործում են թիմի առաջատարների պես՝ կառավարելով AI օգնականներին՝ ուղղակի կոդ գրելու փոխարեն: Հիմնական հմտությունները տեղափոխվել են նախագծման, պլանավորման, նկարագրության և վերանայման:

Հիմնական UX հասկացությունները, որոնք ներկայացնում են այս գործիքները, հետևյալն են.

1. Ներդիր առաջարկներ ՝ ինտեգրման ամենաբնական օրինակը: Երբ նրանք աշխատում են, դրանք անխափան են, բայց երբ դրանք խաթարում են ձեր կոդը, դա արտադրողականության անմիջական ընդմիջում է:
2. Զրուցարան ՝ դասական մոտեցում, որտեղ LLM-ները փոխազդում են ձեր կոդերի բազայի հետ՝ ուղղորդվող հուշումների միջոցով
3. Կոմպոզիտոր (« Copilot Edit », « Cline act ») - նոր հայեցակարգը շատերի համար շփոթեցնող է : Դա անցում է դեպի ինքնավար գործակալներ: Կոմպոզիտորն աշխատում է մի քանի ֆայլերի վրա և կարող է փոփոխություններ կիրառել և ինքնաբերաբար կրկնել՝ հիմնվելով սխալների, ցողունի խնդիրների և այլնի վրա:
4. Գործակալներ ՝ սպասվող հաջորդ էվոլյուցիան՝ լիովին ինքնավար և անհատականացված AI օգնականներ, որոնք ուղղակիորեն ինտեգրված են ձեր IDE-ին:

« Առաջարկություններին » ծանոթանալը բարդ չէ: AI օգնականները սկսեցին նրանցից, որոնք առաջին հերթին գրավեցին մեր ուշադրությունը: Զրույցները պարզ են. տեղադրեք ֆայլերը համատեքստում, կրկնեք, կիրառեք և հաստատեք արդյունքները:

Կոմպոզիտորի տիպի գործիքներն ավելի շատ դժվարություններ են ներկայացնում յուրացման համար, որոնք պահանջում են ուսուցման կոր և որոշ ոչ ակնհայտ մոտեցումներ: Ներկայումս Cursor-ի խմբագրիչն առաջարկում է առավել մատչելի «կոմպոզիտոր» գործիքը, մինչդեռ Copilot-ը սերտորեն հետևում է « Copilot Edits »-ին, որը վերջերս ներկայացրել է գործակալների վրա հիմնված աշխատանքային հոսքեր:

Կոմպոզիտորների հետ հմուտ դառնալու համար դուք պետք է հասկանաք երեք հիմնական հասկացություն.

1. Հրահանգներ
2. Կանոններ
3. Համատեքստ

Եկեք քննենք դրանցից յուրաքանչյուրը:

Հրահանգներ

Քանի որ թիմը ղեկավարում է ոչ թե պարզապես մշակողները, մենք պետք է սկսենք ցանկացած նոր նախագիծ կամ հիմնական գործառույթ՝ ստեղծելով դիզայնի փաստաթուղթ կամ հստակ արտադրանքի պահանջների փաստաթուղթ : Այս պրակտիկան զարգացնում է ուժեղ ինժեներական և արտադրանքի մտածողություն՝ միաժամանակ խնայելով իրականացման զգալի ժամանակը: Լավագույնն այն է, որ այս փաստաթղթերը կարող են լինել.

1. Ստեղծվել է AI-ի միջոցով
2. Եվ հետո օգտագործվեց որպես կոմպոզիտորների հրահանգ

Այս փաստաթղթերը ստեղծելու համար նախ հավաքեք մարդկանց պահանջները, այնուհետև քննարկեք պատճառաբանության մոդելը Chat-ում: Եվ Copilot-ը և Cursor-ը ունեն ներկառուցված հիմնավորման մոդելներ, որոնք հարմար են այս առաջադրանքի համար: OpenAI-ի o1 և o3-mini հասանելի են լռելյայնորեն, մինչդեռ Cursor's Chat-ն աջակցում է DeepSeek-R1-ին (թեև դեռ չկա իր Կոմպոզիտորում )՝ այս նպատակի համար նախատեսված բոլոր հիանալի գործիքները:

Լավ պրակտիկա է նախագծային փաստաթղթերը պահել ձեր ռեպո-ի վերին մակարդակում (մենք կօգտագործենք requirements թղթապանակ)՝ կազմակերպված ըստ առանձնահատկությունների՝ արմատում ProjectOverview.md ով: Ահա Twitter վեբ հավելվածի պահանջների կառուցվածքի օրինակ.

 requirements/ ├── ProjectOverview.md # Core product description └── Features/ ├── Authentication.md # User registration ├── Tweet.md # Tweet CRUD ├── UserProfile.md # Profile management ├── Engagement.md # Likes, retweets ├── Infrastructure.md # Storage, caching, etc └── ...

Եթե ամեն ինչ ճիշտ է կարգավորվել, նոր գործառույթի համար նախագծային փաստաթուղթ ավելացնելը նույնքան պարզ է, որքան այս հուշումը գրելը.

Ձեր կոդի բազայում հրահանգները պահելն առաջարկում է հստակ առավելություններ՝ տարբերակի վերահսկում, հեշտ սպասարկում և ստանդարտ PR աշխատանքային հոսք: Այնուամենայնիվ, ոչ տեխնիկական թիմի անդամներին, ինչպիսիք են Ապրանքի սեփականատերերը, ղեկավարները և UX դիզայներները, կարող են մուտքի կարիք ունենալ առանց git-ի օգտագործման: Ահա երեք լուծում.

1. Պահեք ամեն ինչ Notion-ում, հրապարակեք հրահանգների էջերը և ներարկեք դրանք որպես փաստաթուղթ՝ օգտագործելով @Docs դյուրանցումը

2. Ստեղծեք խողովակաշար, որը փոխակերպում է Notion էջերը .md ֆայլերի և պահում դրանք պահեստում
3. Սովորեցրեք ձեր թիմին օգտագործել git-ը` ամենաօգտակար տարբերակը ողջ թիմի համար

Երբ ձեր հրահանգները հասանելի լինեն ձեր խմբագրում, անցեք կոմպոզիտորին և սկսեք իրականացնել: Սա մեզ տանում է Կանոնների կազմակերպմանը:

Կանոններ

Ներկայումս միայն կուրսորն է աջակցում « կանոններ »՝ կոնկրետ ֆայլերի/թղթապանակների ուղղակի իրականացման հրահանգներ: Այս հատկությունը, ամենայն հավանականությամբ, կտարածվի այլ խմբագրիչների վրա, ներառյալ VSCode Copilot-ը, որն այժմ առաջարկում է միայն « հրատապ ֆայլեր », որոնք չեն կարող ուղղակիորեն կցվել կոդերի բազային:

Կուրսորի կանոններն ավելի ընդգրկուն են. պատկերացրեք CONTRIBUTING.md համակցված լինտերի կանոններով և ընդլայնված LLM հնարավորություններով: Այս կանոնները արտադրանքի ագնոստիկ են, համօգտագործելի և արդյունավետորեն փոխանցում են գիտելիքները, լավագույն փորձը և իրականացման մանրամասները թիմերի և գրադարանի օգտագործողների միջև:

Կանոնները կարող են ստեղծվել հրամանների պալիտրա միջոցով և պահվում են ձեր նախագծի .cursor/rules պանակում՝ .mdc ընդլայնմամբ: Այս ձևաչափը հնարավորություն է տալիս առաջադեմ գործառույթներ, ինչպիսիք են @mentioning որոշակի ֆայլեր ձեր կոդի բազայում: Խստորեն խորհուրդ է տրվում այս կանոնները հանձնել ձեր պահեստին և համագործակցել դրանք բարելավելու ուղղությամբ: Ահա կանոնների օգտագործման աշխատանքային ընթացքը.

1. Հետազոտեք կուրսորի կանոնները, որոնք հատուկ են ձեր տեխնոլոգիական փաթեթին՝ սկսած ընտրված ցուցակներից ՝ որպես հղումներ: Օրինակ, հաջորդ.js-ի և React-ի համար կարող եք գտնել կուրսորի լավ գրված կանոններ , որոնք ծառայում են որպես լավ ձևանմուշներ:
2. Մշակման ընթացքում ակտիվորեն թարմացրեք կանոնները: Երբ կոդ գրելիս նկատում եք մի օրինաչափություն, որը կարող է ձևակերպվել կանոնի, անմիջապես գրանցեք այն ձեր կանոնների ֆայլում:
3. Սովորեք ոլորտում լավագույններից: Գրադարան ստեղծողների համար գիտելիքների փոխանակման և ընդունումը մեծացնելու նոր մոտեցումը արհեստական ինտելեկտի օգնականների համար մասնագիտացված կանոններ է ստեղծում: Ես գիտեմ մի քանի ընկերությունների, ովքեր դա անում են. Convex-ն առանձնանում է թե՛ OpenAI, թե՛ Anthropic մոդելների համար կանոններ ստեղծելով և դրանք ներկայացնելով իրենց փաստաթղթերում : Թեև ես չեմ օգտագործել նրանց արտադրանքը, նրանց ուշադրությունը AI ինտեգրման միջոցով ծրագրավորողների փորձի բարելավման վրա ազդեցիկ է: Supabase-ը ևս մեկ հիանալի օրինակ է:

Շատ գրադարաններ հրատապ կարիք ունեն AI կանոնների: Առջևի ծրագրավորողի տեսանկյունից ես կշահեի դրանք TanStack Query-ի , React Spring-ի , Firebase-ի և շատ-շատերի համար: Այս կանոնները զգալի ժամանակ կխնայեն և կօգնեն կանխել սովորական սխալները, որոնք թույլ են տալիս մշակողները նոր տեխնոլոգիաներ սովորելիս:

Համատեքստ

Հիշեք, որ ներառեք բոլոր համապատասխան համատեքստը. որքան շատ որակյալ տվյալներ տրամադրեք, այնքան ավելի լավ արդյունքներ կստանաք: Կուրսորի խմբագիրն այստեղ առավելություն ունի Copilot-ի նկատմամբ՝ թույլ տալով մի քանի տեսակի համատեքստ.

1. Փաստաթղթեր - իսկապես լավ է աշխատում, պարզապես տրամադրեք այն մուտքի կետ ցանկացած փաստաթղթում, այն կներբեռնի այն, կվերլուծի և կպահի ապագա կարիքների համար:
2. Վեբ որոնում - ոչ խիստ համատեքստում, այն ապահովում է արագ մուտք դեպի առցանց ռեսուրսներ
3. Զարգացման տարբեր գործիքներ՝ հատուկ git commits, lint errors, Notepads և այլ արտեֆակտներ
4. MCP- սերվերները կարող են իրական ժամանակի համատեքստ տրամադրել: Թեև կարգավորումը մի փոքր բարդ է, դրանք արժեքավոր են, երբ անհրաժեշտ է կենդանի տվյալների հասանելիություն:

Այս գործիքներին տիրապետելուց հետո ձեր հաջորդ քայլը թե՛ անհատական, թե՛ թիմային աշխատանքի օպտիմալացումն է: Բայց ո՞րն է այստեղից առաջ գնալու ճանապարհը:

Cline և Roo-Code. Վերահսկողությունը

Դուք միշտ կբախվեք պարզության և վերահսկողության, ավտոմատացված լուծումների և ձեռքով որոշումներ կայացնելու միջև: Եթե ցանկանում եք խորը սուզվել և չեք վախենում վրիպակների, կատարողական մարտահրավերների և կոպիտ եզրերի հետ գործ ունենալուց, փորձեք Cline-ը (կամ դրա պատառաքաղը Roo-Code-ը , որն ունի մի փոքր այլ փիլիսոփայություն):

Երկու գործիքներն էլ նախագծված են հնարավորինս շատ ազատություն ապահովելու համար, թե ինչ է իրականում կատարվում գլխարկի տակ.

1. Դրանք բաց կոդով են և առանց բաժանորդագրության: Փոխարենը, դուք օգտագործում եք ձեր սեփական LLM API բանալիները կամ ծառայությունները, ինչպիսին է OpenRouter-ը , վճարելով միայն ձեր օգտագործածի համար:
2. Cline-ը հստակ ցույց է տալիս իր բոլոր գործողությունները, ներառյալ այն ֆայլերը, որոնք նա կարդում և փոփոխում է:
3. Cline-ը մանրամասն պատկերացումներ է տալիս LLM հաղորդակցությունների, համատեքստի պատուհանի կարգավիճակի և յուրաքանչյուր զրույցի նստաշրջանի արժեքի վերաբերյալ:
4. Այն առանձնանում է պլանի/գործողության ինտուիտիվ ռեժիմներով՝ տրամաբանական մոտեցում, որը պետք է դիտարկեն մյուս գործիքները:

Մարդասպանի առանձնահատկությունն այն է, որ Cline-ը կարող է իրականում գործարկել և կարգաբերել ձեր հավելվածը. այն իրական է և ֆունկցիոնալ, ինչպես կտեսնեք, երբ փորձեք այն:

Եթե այս ամենը ձեզ հետաքրքրում է, ստուգեք Ադի Օսմանիի վերջին հոդվածը , որը հիանալի ներածություն է տալիս այս խմբագիրներին:

Եզրակացություն

Այս գործիքների ընդունումը պարզ ճանապարհորդություն չէ, և մի ակնկալեք գրել «ամբողջ նախագիծը զրոյից 5 րոպեի ընթացքում»: Այնուամենայնիվ, սա հստակ առաջընթաց ուղի է:

Տեխնոլոգիան արդեն կա, բայց մենք բացակայում ենք AI-ով ինտեգրված ուժեղ աշխատանքային հոսքը, որը կազմակերպում է ամբողջ թիմը՝ ոչ միայն ծրագրավորողներին, այլև գլխավորապես ղեկավարներին և դիզայներներին, այս նոր գործիքների շուրջ: AI-ն կարող է վախեցնել, և դրա ազդեցությունը կիսելը սկզբում կարող է անհարմար թվալ (ինչպես ձեր թիմի ղեկավարին ասելը, որ AI-ն գրել է գործառույթի 80%-ը զգույշ կազմաձևման միջոցով): Այնուամենայնիվ, ծրագրային ապահովման մշակումը կզարգանա միայն այն ժամանակ, երբ այդ գործիքները դառնան թիմի աշխատանքային հոսքերի անբաժանելի մասը: Ամենահաջող անցումները տեղի են ունենում թիմերում, որոնք խթանում են AI-ի փորձի մասին բաց քննարկումները, համագործակցային գործիքների որոնումը և ակտիվորեն նպաստում են իրենց սովորած լավագույն փորձին ավելի լայն զարգացման համայնքին: