Cursor IDE Agentas: Repozitorijos masto pakeitimai ir kūrėjų ataskaitos

Cursor yra dirbtinio intelekto pagrindu sukurta kodo redagavimo priemonė (VS Code atšaka), skirta valdyti visas kodų bazes su integruotu dirbtiniu intelektu. Skirtingai nuo pagrindinių automatinio pildymo įrankių, „Cursor“ Agento režimas leidžia DI veikti „vairuotojo vietoje“, vienu metu skaitant, redaguojant ir kuriant kodą keliuose failuose (federicocalo.dev) (www.datacamp.com). Šiuo režimu DI gali ieškoti jūsų kode, atnaujinti importus, keisti funkcijų apibrėžimus visur, kur jie pasirodo, vykdyti kūrimo ar testavimo komandas ir taisyti klaidas cikliškai – labai panašiai kaip patyręs kūrėjas dirbdamas paraleliai (federicocalo.dev) (www.datacamp.com). Jis išties veikia repositorijos mastu: pavyzdžiui, vienas vadovas aprašo, kaip DI buvo pasakyta „Pridėti JWT autentifikavimą prie šios Angular programos“ ir stebėjo, kaip jis kuria paslaugas, atnaujina komponentus, paleidžia testus ir taiso klaidas be rankinių pakeitimų (federicocalo.dev). Šias agentines funkcijas palaiko „įrankių naudojimo“ architektūra: DI gali iškviesti funkcijas, tokias kaip read_file, edit_file, search_files ar net run_terminal_command, kad patikrintų ir modifikuotų jūsų projektą (federicocalo.dev). Praktiškai „Cursor“ agentas gali autonomiškai atlikti didelius refaktoringus ir funkcijų kūrimą, derindamas kalbos supratimą su tiesioginiu kodo manipuliavimu.

„Cursor“ suteikia kelis sąveikos režimus. Galingiausias yra Kompozitorius (kelių failų agento režimas), leidžiantis DI skaityti, kurti ir perrašyti blokus keliuose failuose viena operacija (www.slashavi.com). Agento režimu atidarote į pokalbį panašų „Kompozitoriaus“ langą, nurodote savo tikslą, o jis iteratyviai planuoja, veikia ir tikrina rezultatus (www.datacamp.com) (federicocalo.dev). Agentas, pavyzdžiui, suras visus reikiamus failus pakeitimui, taikys nuoseklius redagavimus, paleis jūsų projekto testus ar kūrimo įrankius ir sugrįš, jei atsiras klaidų. Kiekvienas žingsnis yra versijuojamas su kontroliniais taškais, kad galėtumėte peržiūrėti ir atšaukti bet kokius pakeitimus. Komandos dažnai naudoja „Cursor“ taisyklių sistemą, kad nukreiptų DI: paprasti „Markdown“ pagrindu sukurti taisyklių failai (.cursor/rules/) aprašo projekto konvencijas (kodavimo stilių, architektūros modelius ir kt.), kad agentas rašytų kodą, atitinkantį jūsų standartus. Šis taisyklių, semantinio repositorijos indeksavimo ir įrankių naudojimo derinys leidžia „Cursor“ agentams protingai tvarkyti užduotis visoje repositorijoje (federicocalo.dev) (www.datacamp.com).

Agentai planavimui ir vykdymui

Be ad hoc pakeitimų, „Cursor“ siūlo Plano režimą ir Fono agentus sudėtingiems darbams organizuoti. Plano režimu aprašote aukšto lygio tikslą, o DI užduos patikslinančius klausimus, parengs žingsnis po žingsnio planą ir tada įvykdys tuos žingsnius tik jums juos patvirtinus (www.datacamp.com). Pavyzdžiui, DI gali pasiūlyti suskaidyti didelę funkciją į smulkesnes užduotis, paklausti apie prielaidas, o tada vykdyti kiekvieną žingsnį paeiliui. Tai padeda išvengti klaidų, kylančių duodant vieną didelį, miglotą nurodymą (kas dažnai sukelia klaidas), išlaikant DI suderintą su jūsų ketinimais (lilys.ai) (docs.cursor.com). „Cursor“ taip pat palaiko Debesies agentus ir kelių agentų darbo eigas: kiekvienas agentas veikia savo aplinkoje (pvz., atskiroje Git darbo medžio šakoje ar net nuotoliniame serveryje), todėl galite turėti kelis DI „darbuotojus“, kurie lygiagrečiai sprendžia skirtingas projekto dalis. Viename pranešime pažymima, kad „Cursor“ gali paleisti iki 8 agentų vienu metu refaktorinimui. Šie agentai netgi turi tokius įrankius kaip naršyklė; vienoje demonstracijoje parodyta, kaip agentas atidaro sukurtą programą naršyklėje, spusteli per UI ir įrašo trumpą vaizdo įrašą, kad parodytų sėkmę (www.datacamp.com). Praktiškai „Cursor“ teigia, kad daugiau nei 30% sujungtų „pull“ užklausų vienoje įmonėje atėjo iš šių automatizuotų agentų (www.datacamp.com).

Nesvarbu, ar tai būtų Agento, Pokalbio, ar Redagavimo režimas, „Cursor“ DI veikia cikliškai: jis stebi dabartinę projekto būseną, planuoja reikiamus pakeitimus, veikia rašydamas kodą arba vykdydamas komandas, tada vertina rezultatus (įskaitant testavimo ar kūrimo išvestis) ir iteruoja, kol pasiekia sėkmę arba jam prireikia žmogaus įvesties (federicocalo.dev) (www.datacamp.com). Tai yra pagrindinis skirtumas nuo daugelio pokalbių pagrindu veikiančių kodavimo asistentų: agentas turi tiesioginę prieigą prie jūsų kodo ir įrankių, todėl jis gali vykdyti komandas, tokias kaip npm install ar git diff, ir iškart pamatyti rezultatus. Pavyzdžiui, jei DI įveda klaidą, jis perskaitys kompiliatoriaus/testo išvestį ir bandys ją pataisyti, užuot palikęs klaidą kūrėjui. Ši glaudus planavimo, vykdymo ir tikrinimo integravimas daro „Cursor“ agento režimą unikaliai galingu repositorijos masto pakeitimams (federicocalo.dev) (www.datacamp.com).

Kūrėjų atsiliepimai: kodo kokybė, skirtumai ir testavimas

Vartotojai paprastai praneša, kad „Cursor“ DI rašo kontekstui tinkantį kodą, atitinkantį projekto modelius, tačiau, kaip ir bet kuris DI sugeneruotas kodas, jam vis dar reikia kruopščios peržiūros. Vadovai pabrėžia, kad dideli ar neaiškūs nurodymai gali lemti klaidas – paprastai geriau dideles užduotis suskaidyti į mažesnius, testuojamus žingsnius (lilys.ai) (docs.cursor.com). Praktiškai „Cursor“ pateikia siūlomų pakeitimų skirtumus ir skatina kūrėjus juos nuodugniai peržiūrėti. Kelių failų redagavimui sistema rodo agreguotą skirtumų vaizdą: galite spustelėti kiekvieno agento pakeitimus ir pamatyti, kas tiksliai buvo pridėta ar pakeista. DI sukuria kontrolinius taškus kiekvienam agento vykdymo iteracijos etapui, kad galėtumėte atšaukti bet kurią refaktoringo dalį, jei kas nors atrodo neteisingai (www.datacamp.com) (www.datacamp.com).

Dažna vartotojų rekomendacija yra priimti pakeitimus po vieną agentą ir tada nedelsiant paleisti testus. Pavyzdžiui, vienas vadovėlis pataria: „Atidžiai peržiūrėkite skirtumus… Priimkite pakeitimus iš vieno agento vienu metu. Išbandykite tuos failus prieš pereidami prie kito“ (ginno.net). Tai atspindi nuomonę, kad „Cursor“ redagavimai yra galingi, bet ne be trūkumų. Išties, viename pavyzdyje buvo nurodytas savybės pervadinimas 50 komponentų, kur „Cursor“ praleido kai kuriuos failus – tuos, kurie buvo netiesiogiai importuojami per indekso failą – reikalaujant, kad kūrėjas juos rankiniu būdu pridėtų į kontekstą (ginno.net). Tas tyrimas rodo, kad „Cursor“ modeliu pagrįsta analizė kartais gali praleisti netiesiogines nuorodas, nebent nurodyme jos yra aiškiai įtrauktos.

Kita vertus, daugelis vartotojų mano, kad „Cursor“ drastiškai pagreitina refaktoringus ir kelių failų užduotis. Pavyzdžiui, vienas kūrėjas pranešė, kad dviejų dienų refaktoringas (150+ failų) sutrumpėjo iki 20 minučių naudojant kelių failų redagavimus (ginno.net). Apžvalgos (pvz., G2) pažymi, kad didžioji dauguma „Cursor“ vartotojų sako, kad kelių failų refaktoringas dabar yra pagrindinė priežastis, kodėl jie naudoja šį įrankį (ginno.net). Tačiau jie taip pat pabrėžia budrumą: visada atlikite patvirtinimą prieš paleidžiant agentą, testuokite po kiekvienos partijos ir prisiminkite, kad DI nesupranta jūsų verslo logikos taip, kaip jūs (ginno.net). Praktiškai komandos paleidžia savo testavimo rinkinį po agento pakeitimų ir taiso visas sulūžusias testavimo atvejis – traktuodamos DI kaip pagalbininką, kuris pagreitina darbą, bet vis dar reikalauja žmogaus priežiūros, kad būtų užtikrintas teisingumas (ginno.net).

Dėl skirtumų detalizavimo, „Cursor“ kelių agentų sistema iš tikrųjų suteikia labai detalų valdymą. Kiekvienas agentas dirba su failų pogrupiu su savo darbo sritimi, ir jūs galite peržiūrėti arba atšaukti bet kurio agento pakeitimus nepriklausomai. Galutinis skirtumas yra organizuojamas pagal agentą arba pagal failą, todėl galite tiksliai matyti, kas pasikeitė kiekvienoje kodo dalyje (www.datacamp.com) (www.datacamp.com). Tai skiriasi nuo įrankių, kurie generuoja vieną didelį pakeitimų rinkinį. Kaip pastebėjo vienas kūrėjas, „Cursor“ metodas išlaiko pagrindinę šaką nepaliestą, kol jūs nepatvirtinate, o klaidos vieno agento darbe neištrina kitų (ginno.net) (www.datacamp.com).

Apskritai, nuotaika dėl kodo kokybės yra atsargiai optimistiška: „Cursor“ paprastai sukuria logiškai nuoseklų kodą, kuris atitinka projekto konvencijas (ypač jei naudojate taisykles), tačiau vis dar gali įvesti loginių klaidų ar subtilių netikslumų. Štai kodėl kūrėjai pabrėžia kodo peržiūrą ir testavimą po kiekvienos partijos. DI produktyvumo padidėjimo ir reikalingos žmogaus kokybės kontrolės derinys yra pasikartojanti tema: vartotojai vertina, kaip greitai jis gali dirbti (pavyzdžiui, redaguoti dokumentus „akimirksniu“, palyginti su stebėjimu, kaip „Copilot“ rašo eilutę po eilutės (www.reddit.com)), tačiau jie taip pat praneša apie „tiek daug klaidų“ ankstyvosiose versijose ir pabrėžia siūlomų pakeitimų patvirtinimo ar atmetimo svarbą (forum.cursor.com) (ginno.net). Šis mišrus atsiliepimas rodo, kad DI rezultatas apskritai yra naudingas, bet ne be trūkumų.

Žinomos ribos ir geriausia praktika

Nors „Cursor“ agentai yra galingi, jie turi ribas. Vienas pagrindinis apribojimas yra mastas. Tvarkant labai didelius monorepo (šimtus tūkstančių failų) bet koks įrankis gali būti perkrautas. Plačiai cituojamas vartotojo vadovas aiškiai įspėja, kad bandyti refaktorinti kodų bazę, viršijančią ~100 000 failų vienu metu, yra nepatartina: „priklausomybės grafas tampa per daug painus“, o agentai „suklumpa vienas ant kito“ (ginno.net). Tokiems didžiuliams projektams patariama pakeitimus suskaidyti į mažesnius pogrupius (aplankus ar gabalus), o ne naudoti vieną visuotinę komandą. „Cursor“ dokumentacija siūlo tokias technikas kaip tik dalies repositorijos indeksavimas, nereikšmingų aplankų išskyrimas ir darbo suskaidymas į mažesnius pokalbius ar planus (docs.cursor.com) (ginno.net).

Kitas apribojimas yra dvejetainiai arba ne kodo failai. „Cursor“ DI ir semantinė paieška veikia su tekstu (pirminiu kodu, konfigūracijos failais, dokumentacija). Planuodamas pakeitimus, jis paprastai ignoruos paveikslėlius, vaizdo įrašus ar sukompiliuotus dvejetainius failus. Praktiškai tai reiškia, kad negalite paprašyti „Cursor“, pavyzdžiui, pridėti vandens ženklą prie visų PNG paveikslėlių jūsų repositorijoje – jis tiesiog nepalygina ir neredaguoja dvejetainių formatų. Kitaip tariant, bet koks visos repositorijos pakeitimas turi būti susijęs su kodu/tekstu (funkcijomis, komentarais, konfigūracija ir t. t.), o ne su savavališkais failais. Todėl vartotojai sutelkia dėmesį į tokias užduotis kaip kodo simbolių pervadinimas, kodo modelių atnaujinimas ar failų generavimas, o ne užduotis, susijusias su ne kodo failais.

Sudėtingos kūrimo sistemos ir pritaikytos aplinkos taip pat gali kelti iššūkių. „Cursor“ gali paleisti komandas, tokias kaip „npm test“ ar „make“, terminale, tačiau ji žino tik matomą išvestį. Jei jūsų kūrimui reikia kelių žingsnių, pasirinktinių scenarijų ar nuosavybės teisių turinčių įrankių, agentui gali prireikti nurodymų. Pavyzdžiui, jei projektas naudoja kelių etapų „Docker“ kūrimą ar neįprastą įrankių grandinę, agentas gali automatiškai to neapdoroti. Tokiais atvejais turėtumėte suteikti agentui pakankamai konteksto (pavyzdžiui, išvardyti kūrimo žingsnius savo nurodyme ar taisyklėse) ir planuoti mažesnius žingsnius. Apskritai, „Cursor“ geriausiai veikia, kai jūsų kodas yra tekstiniuose failuose diske ir gali būti kuriamas/testuojamas iš CLI; labai sudėtingoms kūrimo sistemoms gali prireikti iteracinių nurodymų ar net rankinio įsikišimo.

Apskritai, tai reiškia: „Cursor“ spindi gerai struktūrizuotose kodų bazėse, kur pakeitimai atitinka aiškius modelius (pvz., importų atnaujinimas, bendrų kodo idiomų refaktoringas ar standartinių komponentų pridėjimas). Jis mažiau tinkamas užduotims, susijusioms su paslėptomis ar netiesioginėmis priklausomybėmis (pvz., objektų grafikas, sujungtas tik vykdymo metu, arba dinamiškai registruojami komponentai) ar ne kodo duomenims. Geriausia praktika yra traktuoti „Cursor“ kaip super-įkrauta kopilotą: religingai naudoti versijų kontrolę (patvirtinimus ir šakas), dažnai paleisti testus ir likti įtrauktam į ciklą. Kaip nurodoma viename vadove, „Naudokite jį kaip patyrusį inžinierių, kuris puikiai atlieka rutininius darbus, bet vis dar reikalauja antros akių poros“ (ginno.net).

Lyginant Cursor, Copilot ir ChatGPT

Lyginant „Cursor“ su kitais DI kodavimo asistentais, išryškėja pagrindiniai skirtumai. Tiek GitHub Copilot (ir jo agentų režimai), tiek „Cursor“ yra valdomi DI, tačiau jie naudoja skirtingus architektūrinius metodus. „Copilot“ yra plėtinys, integruojamas į esamus redaktorius, o „Cursor“ yra atskira DI pagrindu sukurta IDE. Glaudi „Cursor“ integracija leidžia indeksuoti ir įdėti visą repositoriją, suteikiant jai „architektūrinio lygio supratimą“ apie jūsų projektą (opsera.ai) (www.datacamp.com). Išties, „DataCamp“ pažymi, kad „Cursor“ indeksuoja visą jūsų kodų bazę… todėl ji gali samprotauti per visus jūsų failus pagal numatytuosius nustatymus“ (www.datacamp.com). „Copilot“, priešingai, tradiciškai mato tik atidarytus failus ir remiasi „GitHub“ paieška, kad gautų platesnį kontekstą. („Copilot“ neseniai pridėjo daugiau repositorijos indeksavimo per „GitHub Code Search“, tačiau stebėtojai sako, kad „Cursor“ vis dar turi pranašumą dideliuose projektuose dėl visiško IDE valdymo (www.datacamp.com).)

Praktiškai tai reiškia, kad „Cursor“ gali tiesiogiau tvarkyti kelių failų ir tarpinių paslaugų refaktoringus. „Cursor“ Agento režimu viena komanda gali redaguoti dešimtis failų vienu metu ir nuosekliai atnaujinti importus ar testus (www.datacamp.com). „Copilot“ dabar taip pat palaiko kelių failų pakeitimus „Agento režimu“, tačiau jis linkęs būti labiau rankinis: paprastai pasirenkate, kuriuos failus keisti, ir peržiūrite juos po vieną (www.datacamp.com). „Copilot“ taip pat siūlo atskirą „GitHub“ hostinamą „Kodavimo agentą“, kuris veikia asinchroniškai, kad atidarytų „pull“ užklausą su pakeitimais (užduotį deleguojate „GitHub“ ir grįžtate peržiūrėti PR vėliau). „Cursor“ atitikmuo yra naudoti savo foninius agentus arba „hook“ funkcijas PR generavimui, tačiau pagrindinis dalykas yra tai, kad „Cursor“ darbo eiga yra realaus laiko ir redaktoriuje su smulkiais kontroliniais taškais (www.datacamp.com).

Kalbant apie kodo pildymą ir greitus pasiūlymus, gili „Copilot“ integracija reiškia, kad jis veikia bet kurioje palaikomoje IDE (VS Code, JetBrains ir kt.) su greitais įterptais „šešėlinio teksto“ pasiūlymais. „Cursor“ taip pat siūlo įterptus pildymus (naudodamas savo „Tab“ modelį), tačiau jo tikrasis stiprumas yra ne vienos eilutės automatinis pildymas. Abu įrankiai dabar palaiko pažangius „agentų“ režimus. „Cursor“ dizainas skatina didesnes suplanuotas užduotis: jame yra integruotas Plano režimas, o numatytoji sąveika yra ta, kad kūrėjas dalyvauja cikle, kol agentas vykdo (www.datacamp.com). „Copilot“ dizainas pabrėžia nuolatinį kodavimą su retu delegavimu: visą dieną gaunate automatinio pildymo ir pokalbių pagalbą, o didelės funkcijos atveju paprastai paleidžiate agentą (arba „Copilot Chat“) ir grįžtate vėliau.

Kalbant apie kodo kokybę ir patikimumą, abu įrankiai tobulėja, bet nė vienas nėra tobulas. Viename palyginime buvo pažymėta, kad „Cursor“ pateikia patikimus kontekstui tinkamus pakeitimus su kontroliniais taškais – tačiau bendruomenės pranešimuose pasirodė retų kontrolinių taškų gedimų ir nepageidaujamų atšaukimų (www.augmentcode.com). „Copilot“ pakeitimai remiasi „Git“ šakojimo ir PR darbo eigomis, kurios kai kurioms komandoms atrodo labiau pažįstamos. „Cursor“ gali pasigirti tokiomis funkcijomis kaip automatinis atšaukimas ir kelių agentų skirtumai, tačiau vartotojai turėtų kruopščiai išbandyti šias funkcijas gamyboje. Priešingai, „Copilot“ agento režimas taip pat generuoja pakeitimus, tačiau kūrėjai dažnai pasitiki savo esamu kodo peržiūros procesu dėl saugumo.

Galiausiai, lyginant su tradiciniais pokalbių asistentais, tokiais kaip ChatGPT, skirtumas yra ryškus. „ChatGPT“ (arba „Claude Code“ pokalbių sąsajoje) yra bendras pokalbių robotas: jis žino tik tai, ką įklijuojate ar aprašote, ir negali pats rašyti į jūsų failus ar paleisti jūsų testų (www.lowcode.agency) (www.lowcode.agency). „Cursor“, priešingai, yra sukurtas kodavimui: jis turi „visišką kodų bazės supratimą“ ir gali tiesiogiai manipuliuoti failais be kopijavimo ir įklijavimo (www.lowcode.agency) (www.lowcode.agency). „LowCode“ vadovas paprastai sako: naudojant „ChatGPT“ kodavimui, paprastai tenka rankiniu būdu kopijuoti kodą į pokalbį ir iš jo, o „Cursor“ išlaiko jūsų darbo eigą IDE viduje (www.lowcode.agency) (www.lowcode.agency). Tai daro „Cursor“ daug efektyvesniu iteraciniam vystymui. Apibendrinant:

• Cursor ir ChatGPT: „Cursor“ yra DI pagrindu sukurta IDE, kuri gali redaguoti jūsų kodų bazę vietoje, suprasti projekto architektūrą ir atlikti kelių failų pakeitimus (www.lowcode.agency) (www.lowcode.agency). „ChatGPT“ yra bendras asistentas, su kuriuo bendraujate, neturintis jokios integruotos informacijos apie jūsų failus (turite įklijuoti kodą) (www.lowcode.agency) (www.lowcode.agency). Repositorijos masto refaktoringams „Cursor“ laimi, nes jis natūraliai integruojasi su jūsų projektu.
• Cursor ir GitHub Copilot: „Copilot“ yra plačiai naudojamas DI asistentas, integruotas į daugelį redaktorių, puikiai tinkantis įterptiems pasiūlymams ir greitai kodavimo pagalbai įvairiuose įrankiuose. „Cursor“ siūlo universalesnę patirtį giluminiams, kelių failų kodavimo uždaviniams. „Cursor“ agento režimas („Composer“) gali vienu metu atnaujinti daugelį failų su kontroliniais taškais (www.datacamp.com), o „Copilot“ agento režimas keičia failus po vieną arba per „pull“ užklausas. „Copilot“ naudojasi plačiu IDE palaikymu ir oficialiomis įmonės funkcijomis, tačiau „Cursor“ pabrėžia didelę galią sudėtingiems refaktoringams per lygiagrečius agentus ir platesnį kontekstą (www.datacamp.com) (www.datacamp.com). Praktiškai komandos renkasi „Copilot“ bendrai kodavimo pagalbai ir suderinamumui, o „Cursor“ pasirenkamas, kai reikalingas gilus, architektūrinis kodo supratimas ir didelio masto pakeitimai.

Išvada

„Cursor“ agentinės funkcijos suteikia naują automatizavimo lygį kodavimui. Traktuodamas DI kaip autonominį asistentą, turintį prieigą prie failų sistemos, kelių žingsnių samprotavimo ir planavimo galimybių, „Cursor“ leidžia kūrėjams daug greičiau atlikti repositorijos masto redagavimus, migracijas ir testus, nei tai būtų daroma rankiniu būdu. Vartotojai praneša apie dramatišką laiko sutaupymą (vienas nurodė 90% sumažinimą refaktoringo užduotyje (ginno.net)), nors šie pranašumai ateina su atsakomybe kruopščiai peržiūrėti DI išvestį. Trumpai tariant, „Cursor“ DI agentai gali paversti didelius, pasikartojančius kodavimo darbus į valdomas darbo eigas, tačiau jiems reikia aiškių nurodymų ir žmogaus priežiūros. Komandoms, susiduriančioms su išsiplėtusiomis kodų bazėmis, „Cursor“ gali būti galingas produktyvumo daugiklis – jei jis naudojamas atsargiai su kontroliniais taškais ir patikimu testavimu.

Ar „Cursor“ yra tinkamas įrankis, priklauso nuo jūsų projekto. Jei jums reikia gilaus, tarpfailinio intelekto ir galite pereiti prie naujos IDE, „Cursor“ siūlo specializuotas galimybes, viršijančias tipiškų automatinio pildymo asistentų galimybes (www.datacamp.com) (www.datacamp.com). Jei pageidaujate likti savo dabartiniame redaktoriuje ir dirbti laipsniškai, „GitHub Copilot“ (arba kiti pokalbių pagrindu veikiantys įrankiai) gali būti patogesni. Atrodo, kad kodavimo ateitis yra tokia, kur DI agentai, tokie kaip „Cursor“, papildo žmogaus kūrėjus: tvarkydami nuobodžias smulkmenas ir leisdami programuotojams sutelkti dėmesį į dizainą ir strategiją. Kaip pažymi vienas ekspertas, „kodavimo ateitis nėra apie daugiau kodo rašymą, ji yra apie mažesnį jo keitimą – ir „Cursor“, gerai naudojamas, leidžia tai daryti“ (ginno.net).