AI kodavimo įrankiai vis dar yra mokslinių tyrimų ir plėtros stadijoje

Pagal Stack Overflow 2024 m. apklausą 76 % kūrėjų naudoja arba planuoja naudoti AI įrankius – dabar jie yra tik darbo dalis. Jie padeda atlikti kasdienes užduotis, bet gali erzinti, kai užtikrintai kuria nesąmones. Nors „YouTube“ nariai kuria „milijardų dolerių startuolius“ naudodami „ChatGPT“ raginimus, o dirbtinio intelekto agentai kiekvieną savaitę užvaldo pasaulį, tikros komandos vis dar sugalvoja, kaip efektyviai panaudoti šiuos įrankius. Šiandien dirbtinio intelekto pagalbos įsisavinimas yra toks pat svarbus kaip kodavimas ar sistemos projektavimas – turime prisitaikyti ir greitai.

Problema ta, kad šios priemonės iš esmės vis dar yra mokslinių tyrimų ir plėtros stadijoje – jos nuolat keičiasi, kopijuoja viena kitą ir nusipelno nuopelnų už anksčiau neišspręstų problemų sprendimą. Visiems jiems trūksta aiškių naudojimo vadovų. Netgi Copilot, nors ir labiau įsitvirtinęs, trūksta aiškių vadovėlių ir geriausios praktikos. Sprendimas? Darysime tai, ką kūrėjai moka geriausiai – patys organizuosime ir sukursime sistemą.

Žaidimo keitiklis

...ir taip pat „ Kvantinis šuolis “, „ Paradigmos pokytis “, „ Agentai ateina “, vadinasi. Nors šie įrankiai iš tikrųjų keičia mūsų darbo eigą, pakeitimas yra praktiškesnis: kūrėjai dabar veikia kaip komandos vadovai, valdydami AI padėjėjus, o ne tiesiogiai rašydami kodą. Pagrindiniai įgūdžiai perėjo į projektavimą, planavimą, apibūdinimą ir peržiūrą.

Pagrindinės UX koncepcijos, kurias pristato šie įrankiai:

1. Įtraukti pasiūlymai – natūraliausias integravimo modelis. Kai jie veikia, jie veikia sklandžiai, bet kai jie sutrikdo jūsų kodą, tai iškart nutrūksta produktyvumas.
2. Pokalbiai – klasikinis metodas, kai LLM sąveikauja su jūsų kodų baze vadovaudamiesi raginimais
3. Kompozitorius („ Copilot Edit “, „ Cline act “) – nauja koncepcija daugeliui atrodo paini . Tai perėjimas prie autonominių agentų. „Composer“ dirba su keliais failais ir gali pritaikyti pakeitimus bei kartoti automatiškai, atsižvelgdama į klaidas, pūkavimo problemas ir pan.
4. Agentai – numatoma kita evoliucija – visiškai savarankiški ir suasmeninti dirbtinio intelekto padėjėjai, integruoti tiesiai į jūsų IDE.

Susipažinti su „ pasiūlymais “ nėra sudėtinga. AI padėjėjai pradėjo nuo jų, o tai pirmiausia patraukė mūsų dėmesį. Pokalbiai yra nesudėtingi: įterpkite failus į kontekstą, kartokite, pritaikykite ir patvirtinkite rezultatus.

Kompozitoriaus tipo įrankiai kelia daugiau iššūkių, kuriuos reikia valdyti, todėl reikia mokymosi kreivės ir kai kurių neakivaizdžių metodų. Šiuo metu žymeklio redaktorius siūlo labiausiai prieinamą „kompozitoriaus“ įrankį, o „Copilot“ atidžiai seka „ Copilot Edits “, neseniai įdiegusi agentais pagrįstas darbo eigas.

Norėdami išmokti dirbti su kompozitoriais, turite suprasti tris pagrindines sąvokas:

1. Instrukcijos
2. Taisyklės
3. Kontekstas

Panagrinėkime kiekvieną iš jų.

Instrukcijos

Kaip komanda vadovauja, o ne tik kūrėjai, bet kokį naują projektą ar pagrindinę funkciją turėtume pradėti kurdami projekto dokumentą arba aiškų gaminio reikalavimų dokumentą . Ši praktika ugdo tvirtą inžineriją ir gaminio mąstymą, kartu sutaupant daug įgyvendinimo laiko. Geriausia tai, kad šie dokumentai gali būti:

1. Sukurta naudojant AI
2. Ir tada naudojamas kaip instrukcija kompozitoriams

Norėdami sukurti šiuos dokumentus, pirmiausia surinkite žmonių reikalavimus, tada peržiūrėkite samprotavimo modelį programoje „Chat“. Tiek „Copilot“, tiek „Cursor“ turi integruotus samprotavimo modelius, tinkamus šiai užduočiai atlikti. „OpenAI“ o1 ir o3-mini yra prieinami pagal numatytuosius nustatymus, o „Cursor's Chat“ palaiko „DeepSeek-R1“ (nors dar nėra jo „Composer“ ) – visi puikūs įrankiai šiam tikslui.

Gera praktika yra saugoti dizaino dokumentus aukščiausiame atpirkimo lygyje (naudosime requirements aplanką), suskirstytus pagal funkcijas, su ProjectOverview.md šaknyje. Štai „Twitter“ žiniatinklio programos reikalavimų struktūros pavyzdys:

 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 └── ...

Jei viskas tinkamai nustatyta, pridėti naujos funkcijos dizaino dokumentą yra taip paprasta, kaip parašyti šį raginimą:

Instrukcijų saugojimas kodų bazėje suteikia aiškių pranašumų: versijų valdymas, lengva priežiūra ir standartinė PR darbo eiga. Tačiau netechniniams komandos nariams, tokiems kaip produktų savininkai, vadovai ir UX dizaineriai, gali prireikti prieigos nenaudojant git. Štai trys sprendimai:

1. Išsaugokite viską „Notion“, paskelbkite instrukcijų puslapius ir įterpkite juos kaip dokumentus naudodami @Docs nuorodą

2. Sukurkite dujotiekį, kuris konvertuoja sąvokų puslapius į .md failus ir saugo juos saugykloje
3. Išmokykite savo komandą naudoti git – naudingiausias pasirinkimas visai komandai

Kai jūsų instrukcijos bus pasiekiamos redaktoriuje, pereikite prie kompozitoriaus ir pradėkite diegti. Tai veda prie taisyklių organizavimo.

Taisyklės

Šiuo metu tik žymeklis palaiko " taisykles " – tiesiogines konkrečių failų/aplankų diegimo instrukcijas. Ši funkcija greičiausiai išplis į kitus redaktorius, įskaitant VSCode Copilot, kuris šiuo metu siūlo tik „ prompt failus “, kurių negalima tiesiogiai prijungti prie kodų bazės.

Žymeklio taisyklės yra išsamesnės – įsivaizduokite CONTRIBUTING.md kartu su linter taisyklėmis ir patobulinta LLM galimybėmis. Šios taisyklės yra produktų agnostinės, bendrinamos ir efektyviai perduoda žinias, geriausią praktiką ir įgyvendinimo detales komandoms ir bibliotekos naudotojams.

Taisyklės gali būti sukurtos naudojant komandų paletę ir yra saugomos jūsų projekto .cursor/rules aplanke su .mdc plėtiniu. Šis formatas įgalina išplėstines funkcijas, pvz., @mentioning kodų bazėje. Labai rekomenduojama šias taisykles įtraukti į savo saugyklą ir bendradarbiauti jas tobulinant. Štai taisyklių naudojimo darbo eiga:

1. Tyrinėkite žymeklio taisykles, būdingas jūsų technologijų krūvai, pradedant kuruojamais sąrašais kaip nuorodomis. Pavyzdžiui, galite rasti gerai parašytas Next.js ir React žymeklio taisykles , kurios yra geri šablonai.
2. Kurdami aktyviai atnaujinkite taisykles. Kai rašydami kodą pastebėsite šabloną, kuris gali būti formalizuotas į taisyklę, nedelsdami dokumentuokite jį savo taisyklių faile.
3. Mokykitės iš geriausiųjų šioje srityje. Naujas bibliotekų kūrėjų būdas dalytis žiniomis ir didinti jų pritaikymą – sukurti specialias AI padėjėjų taisykles. Žinau keletą tai darančių įmonių – „Convex“ išsiskiria tuo, kad kuria taisykles tiek OpenAI, tiek Antropiniams modeliams ir dalijasi jomis savo dokumentuose . Nors nenaudojau jų produkto, jų dėmesys kūrėjo patirties gerinimui integruojant AI yra įtikinamas. Supabase yra dar vienas puikus pavyzdys .

Daugeliui bibliotekų skubiai reikia dirbtinio intelekto taisyklių. Žvelgiant iš sąsajos kūrėjo perspektyvos, man būtų naudinga turėti juos „TanStack Query“ , „React Spring“ , „Firebase“ ir daugeliui kitų. Šios taisyklės sutaupytų daug laiko ir padėtų išvengti įprastų klaidų, kurias kūrėjai daro mokydamiesi naujų technologijų.

Kontekstas

Nepamirškite įtraukti viso atitinkamo konteksto – kuo daugiau kokybiškų duomenų pateiksite, tuo geresnių rezultatų pasieksite. Žymeklio redaktorius turi pranašumą prieš Copilot, nes leidžia naudoti kelis konteksto tipus:

1. Dokumentacija – veikia tikrai gerai, tiesiog suteikite jai įvesties tašką prie bet kokios dokumentacijos, ji atsisiųs, išnagrinės ir išsaugos būsimiems poreikiams
2. Interneto paieška – ne tik kontekstas, bet ir suteikia greitą prieigą prie internetinių išteklių
3. Įvairūs kūrimo įrankiai – konkretūs git įsipareigojimai, pūkelių klaidos, užrašų knygelės ir kiti artefaktai
4. MCP serveriai gali pateikti kontekstą realiuoju laiku. Nors sąranka yra šiek tiek sudėtinga, jie yra vertingi, kai jums reikia tiesioginės prieigos prie duomenų.

Įvaldę šiuos įrankius, kitas jūsų žingsnis yra individualaus ir komandos veiklos optimizavimas. Bet koks kelias iš čia?

Cline ir Roo-Code. Kontrolė

Jūs visada susidursite su kompromisu tarp paprastumo ir valdymo, tarp automatinių sprendimų ir rankinio sprendimų priėmimo. Jei norite pasinerti gilyn ir nebijote susidurti su klaidomis, našumo iššūkiais ir grubiais kraštais, apsvarstykite galimybę išbandyti „Cline“ (arba jos šakutę Roo-Code , kurios filosofija yra šiek tiek kitokia).

Abu įrankiai sukurti taip, kad būtų kuo daugiau informacijos apie tai, kas iš tikrųjų vyksta po gaubtu:

1. Jie yra atvirojo kodo ir be prenumeratos. Vietoj to, jūs naudojate savo LLM API raktus arba paslaugas, pvz. , OpenRouter , mokėdami tik už tai, ką naudojate.
2. „Cline“ aiškiai parodo visas savo operacijas, įskaitant skaitomus ir modifikuojamus failus.
3. „Cline“ pateikia išsamias įžvalgas apie LLM ryšius, kontekstinio lango būseną ir kiekvienos pokalbio sesijos kainą.
4. Jame yra intuityvi planavimo/veikimo režimai – logiškas požiūris, kurį turėtų apsvarstyti kitos priemonės.

„Cline“ iš tikrųjų gali paleisti ir derinti jūsų programą – ji yra tikra ir funkcionali, kaip pamatysite ją išbandę.

Jei visa tai jus domina, peržiūrėkite naujausią Addy Osmani straipsnį , kuriame puikiai supažindinama su šiais redaktoriais.

Išvada

Šių įrankių pritaikymas nėra paprasta kelionė, ir nesitikėkite, kad „visą projektą nuo nulio parašysite per mažiau nei 5 minutes“. Tačiau tai yra aiškus kelias į priekį.

Technologija jau yra, bet mums trūksta patikimos į dirbtinį intelektą integruotos darbo eigos, kuri sutelktų visą komandą – ne tik kūrėjus, bet ir ypač vadovus bei dizainerius – apie šiuos naujus įrankius. Dirbtinis intelektas gali jaustis bauginantis, o dalintis jo poveikiu iš pradžių gali atrodyti nepatogu (pavyzdžiui, pasakyti komandos vadovui, kad DI parašė 80 % funkcijos kruopščiai konfigūruodamas). Tačiau programinės įrangos kūrimas vystysis tik tada, kai šie įrankiai taps neatskiriama komandos darbo eigos dalimi. Sėkmingiausi perėjimai vyksta komandose, kurios skatina atvirą diskusiją apie dirbtinio intelekto patirtį, bendradarbiauja su įrankiais ir aktyviai prisideda prie įgytos geriausios praktikos platesnei kūrimo bendruomenei.