Cursor 2026: Kuidas Cursoriga alustada

Vana koodibaas on nagu Lasnamäe korteri elektriskeem aastast 1998: kõik töötab, kuni sa valest juhtmest kinni võtad. Arendaja teab seda tunnet hästi — üks väike muudatus, kolm katkist integratsiooni ja reede õhtul helisev telefon.

2026. aastal ei kasuta sa AI-koodiredaktorit enam ainult kiirema autocomplete’i (koodisoovituse) jaoks. Cursor suudab lugeda tervet repo (koodihoidlat), järgida projekti reegleid, aidata refaktoreerida ja hoida vestluses konteksti. Aga see ei tähenda, et sa peaksid laskma tal kohe makselahendust ümber kirjutada.

Eesti ettevõttes on see eriti praktiline teema. Kui sul on 10 aastat vana e-poe backend, mille kirjutas kolm arendajat tagasi lahkunud tiim, siis dokumentatsioon võib piirduda failiga README_old_final2.md. AI aitab siin hästi, aga ainult siis, kui sa paned talle piirded ette.

Selles juhendi esimeses pooles võtame vana koodibaasi üle nii, et sa ei murra tootmist. Sa seadistad Cursoris projekti, lood reeglifailid, lased AI-l koostada arhitektuurikaardi ja valid esimese väikese pull request’i (muudatusettepaneku), millest on päriselt kasu.

1. Võta Cursorit nagu uut tiimiliiget, mitte nagu võlukeppi

Kas sa annaksid uuele arendajale esimesel päeval ligipääsu tootmisandmebaasile ja ütleksid: “Vaata ise, mis teha annab”? Loodetavasti mitte. Cursoriga peaksid sa käituma sama kainelt.

Esimene eesmärk pole koodi muuta. Esimene eesmärk on panna AI aru saama, mis tüüpi projektiga tal tegemist on, kus on riskid ja millised reeglid on pühamad kui kontori kohvimasin.

Võtame näiteks Tartu väikese tarkvarafirma, kus 8-liikmeline tiim hooldab kohaliku hulgimüüja tellimuste süsteemi. Projektis on Node.js API, vana Reacti frontend ja PostgreSQL. Uus arendaja kulutas varem umbes 3–4 päeva, et aru saada, kus tellimuse staatus tegelikult muutub. Cursoriga saad sama esmase kaardi kätte umbes 45–90 minutiga, kui seadistad konteksti õigesti.

Alusta nii:

1. ✅ Ava repo Cursoris, aga ära tee kohe muudatusi.
2. ✅ Lase Cursoril projekt indekseerida, et ta saaks failide vahel seoseid näha.
3. ✅ Ava vestlus ja ütle selgelt, et AI peab esmalt ainult analüüsima.
4. ✅ Lisa piirang: ta ei tohi pakkuda suuri refaktoreerimisi enne, kui arhitektuurikaart on valmis.

Analüüsi seda koodibaasi ilma muudatusi tegemata. Koosta 1) peamised moodulid, 2) andmevood, 3) välised sõltuvused, 4) kohad, kus tellimuse olek muutub, 5) failid, mida ei tohiks esimese PR-i käigus puudutada.

See prompt (AI-le antud tööjuhis) töötab hästi, sest sa ei küsi “paranda kood”. Sa küsid kaarti. Kaart on vana koodibaasi puhul nagu RMK matkaraja silt: võib-olla sa oskad metsas käia, aga märgistusega jõuad kiiremini tagasi.

Kui Cursor annab sulle arhitektuurikaardi, ära võta seda tõena. Võrdle seda failistruktuuri, testide ja käivitusskriptidega. Küsi kohe täpsustusi kohtades, kus AI kasutab ebamääraseid sõnu nagu probably või seems. Eesti palgataseme juures maksab ühe vanemarendaja tund sageli 45–80 eurot; kui AI säästab kaks tundi uurimist, on see juba 90–160 eurot võitu. Aga vale eeldus võib hiljem maksma minna terve sprindi.

2. Kirjuta Cursorile reeglid, muidu kirjutab ta sulle uue projekti

AI armastab korrastada. See kõlab hästi, kuni ta otsustab, et sinu 2017. aasta autentimiskiht vajab “väikest moderniseerimist” ja muudab viis faili, mida keegi ei julge deploy’da.

Cursoris saad kasutada projektipõhiseid reegleid. Ametlik Cursor Rules dokumentatsioon kirjeldab, kuidas määrata juhised, mida AI peab konkreetse repo puhul järgima. Vana koodibaasi puhul on see üks olulisemaid turvavöösid.

Hea reeglifail ei ütle ainult “kirjuta puhast koodi”. See ütleb, millist koodi sa selles projektis ei taha. Näiteks: ära muuda andmebaasiskeemi ilma migratsioonita, ära lisa uut teeki ilma põhjenduseta, ära puutu makse- ega autentimisloogikat esimese PR-i käigus.

Näide Tallinna logistikafirmast: nende vana PHP ja Vue süsteemis oli 42 000 rida koodi ja ainult 18 automaattesti. Kui tiim pani Cursorile reeglitesse kirja, et esimese muudatuse ulatus võib olla kuni 3 faili ja peab lisama vähemalt 2 testi, vähenes review aeg ühelt PR-ilt umbes 2,5 tunnilt 50 minutile. Väike piirang, suur vahe.

Lisa projekti reeglitesse vähemalt need punktid:

• ✅ Arhitektuuripiirid: millised kihid tohivad omavahel suhelda.
• ✅ Keelatud alad: maksed, autentimine, isikuandmed ja migratsioonid ilma eraldi loata.
• ✅ Testinõue: iga käitumuslik muudatus vajab testi enne tootmiskoodi muutmist.
• ✅ PR-i suurus: esimene AI-abiga PR kuni 150 muudetud rida.
• ✅ Stiil: järgi olemasolevat mustrit, isegi kui see pole ideaalne.

Sa töötad vanas tootmiskoodibaasis. Ära tee suuri refaktoreerimisi. Ära muuda avalikke API vastuseid. Enne loogikamuudatust lisa test. Kui muudatus puudutab autentimist, makseid või isikuandmeid, peatu ja küsi kinnitust.

Reeglite mõte pole AI-d aeglaseks teha. Sa teed temast arendaja, kes tunneb maja kombeid. Kui tahad laiemalt mõista, miks AI-agentide (iseseisvate AI-töövoogude) kontroll on arenduses nii tähtis, loe ka tehisarukas.ee artiklit AI agendid võtavad võimu.

Üle 5000+ AI tööriista ja mudeli. Üks platvorm. Üks agent.

Magica koondab kõik parimad teksti-, pildi-, video- ja helimudelid ning ainus autonoomne AI superagent kasutab neid sinu eest:

✓Käitab kõiki tipptasemel AI mudeleid (tekst, pilt, video, heli)

✓Täielik arvuti (salvestusruum, arvutusvõimsus, mälu)

✓Päris brauser (mitte lihtsalt “veebiotsingu tööriist”)

✓Ühendub sinu tööriistadega (Gmail, Drive, Slack jne)

✓Õpib kohandatud oskusi (õpeta oma töövoog ühe korra)

✓Loob, salvestab ja muudab faile (ning mäletab, kuhu need pani)

✓Töötab sujuvalt veebis, iOS-is ja Androidis

✓API + MCP ligipääs (ühenda millega iganes)

Pole vaja tehnilisi teadmisi. Pole vaja õpetusi. Pole vaja mõelda, millist mudelit valida.

Kirjelda mida soovid – Magica teeb ülejäänu. Autonoomselt. Algusest lõpuni.

Liitu miljonitega, kes on valinud Magica →

3. Lase AI-l koostada arhitektuurikaart ja riskiregister

Kui dokumentatsioon puudub, ära alusta dokumentatsiooni kirjutamisest nullist. Lase Cursoril teha esimene mustand ja pane inimene seda parandama. See on umbes nagu raamatupidaja, kes laseb süsteemil pangatehingud eelsorteerida, aga kinnitab lõpliku aruande ise.

Arhitektuurikaart peab vastama kolmele küsimusele: kus andmed tekivad, kus neid muudetakse ja mis võib katki minna. Vana koodibaasi puhul on eriti tähtis leida varjatud sõltuvused: cron-tööd, käsitsi käivitatavad skriptid, vanad webhook’id ja vaikimisi eeldused, mida keegi pole dokumenteerinud.

Näiteks Pärnu tootmisettevõtte laoarvestuse süsteemis leidis Cursor analüüsi käigus, et laoseisu vähendati kolmes kohas: veebitellimuses, käsitsi paranduse vaates ja öises impordiskriptis. Tiim arvas, et kohti on kaks. Selle ühe avastuse tõttu jäeti ära riskantne refaktoreerimine ja alustati hoopis testidega. Tulemus: 6 uut testi, 0 tootmiskatkestust ja umbes 1 tööpäev vähem käsitsi uurimist.

Küsi Cursorilt riskiregister tabeli kujul. See aitab sul valida esimese PR-i, mis on piisavalt väike, aga mitte mõttetu.

Koosta riskiregister. Iga rea kohta lisa: fail või moodul, äriline mõju, tehniline risk, testide olemasolu, soovitatud esimene turvaline muudatus. Hinda riski skaalal 1–5.

Hea riskiregister võib välja näha nii: OrderService risk 5, sest see muudab tellimuse olekut ja saadab kliendile arve; EmailTemplateHelper risk 2, sest see mõjutab ainult teksti; LegacyReportExport risk 3, sest seda kasutab raamatupidamine kord kuus.

Siin tasub kasutada ka tööriistade ja rollide selget jaotust:

Ära lase Cursoril riskiregistrit ainult nimetada. Palu tal viidata konkreetsetele failidele ja funktsioonidele. Kui ta ütleb “auth module is risky”, siis küsi: milline fail, milline funktsioon, milline sisend, milline väljund?

4. Testid enne muudatusi: esimese PR-i kindlustuspoliis

Vanas koodibaasis on test nagu turvavöö. Sa loodad, et sul pole seda vaja, aga kui midagi juhtub, on hilja seda tagaistmelt otsida.

Enne kui Cursor kirjutab esimese tootmiskoodi muudatuse, lase tal kirjutada test. See on eriti tähtis siis, kui projektis on vähe teste või need ei kata ärikriitilisi kohti. Test ei pea olema täiuslik. Ta peab tõestama, et olemasolev käitumine on fikseeritud enne, kui sa seda puudutad.

Näide Viljandi e-poest: arendaja tahtis parandada vea, kus sooduskood rakendus mõnel juhul kaks korda. Cursor leidis vastava funktsiooni ja pakkus kohe parandust. Tiim peatas ta, küsis esmalt testi ning avastas, et probleem tekkis ainult siis, kui ostukorvis oli vähemalt 3 sama kategooria toodet ja kliendil oli püsikliendi staatus. Testi kirjutamine võttis 35 minutit, paranduse tegemine 12 minutit ja review 25 minutit. Ilma testita oleks viga tõenäoliselt liikunud tootmisesse.

Kasuta sellist tööjärjekorda:

1. 👉 Vali riskiregistrist madala või keskmise riskiga probleem.
2. 👉 Palu Cursoril kirjeldada olemasolev käitumine lihtsas keeles.
3. 👉 Lase tal kirjutada test, mis kukub läbi ainult siis, kui käitumine muutub.
4. 👉 Käivita testid lokaalselt ja CI-s (automaatkontrollis).
5. 👉 Alles siis luba väike tootmiskoodi muudatus.

Kirjuta esmalt test olemasolevale käitumisele. Ära muuda tootmiskoodi. Test peab katma juhtumi, kus sooduskood ei tohi rakenduda kaks korda sama ostukorvi kohta.

Kui kasutad GitHubi, seo see töövoog pull request’iga. GitHubi ametlik pull request’ide juhend aitab hoida AI tehtud muudatused nähtava review-protsessi sees. Turvakihi jaoks lisa GitHub code scanning, mis otsib automaatselt tüüpilisi turvavigu. Koodi ülevaatamisel võta kõrvale ka OWASP Code Review Guide, sest AI võib kirjutada korrektse süntaksiga, aga turvariskiga koodi.

Sinu esimene AI-abiga PR võiks sisaldada näiteks ühte testi ja ühte väikest parandust. Pealkiri olgu konkreetne: “Lisa test ja parandus topelt sooduskoodi rakendumisele”. Kirjelduses märgi, mida Cursor tegi, mida inimene kontrollis ja millised testid jooksid.

See loob tiimis usalduse. Mitte sellepärast, et AI oleks maagiline, vaid sellepärast, et sa kasutad teda nagu tugevat nooremarendajat: kiire, abivalmis, vahel liiga enesekindel ja alati review’d vajav.

5. Esimese PR-i täpne retsept

Hea esimene pull request (koodimuudatuse ülevaatuse taotlus) on nagu väike remonditöö vanas korteris: sa ei võta kandvat seina maha, vaid vahetad ühe logiseva lüliti ära ja kontrollid, et elekter jäi alles. Vana koodibaasi puhul vali muudatus, mille maht jääb 30–150 rea vahele ja mille mõju on ühe lausega selgitatav.

Näiteks Tartu e-poe tiimis märkab arendaja Kärt, et sooduskood rakendub mõnes ostukorvis kaks korda. Ta ei palu Cursoril kogu hinnastamise moodulit ümber teha. Ta laseb AI-l kõigepealt leida seotud failid, kirjutada ühe regressioonitesti ja pakkuda väikese paranduse. Ajakulu: 2 tundi varasema 6 tunni asemel. Rahaline võit, kui arendaja kulu on 45 eurot tunnis: umbes 180 eurot ühe väikese vea kohta.

Retsept näeb välja nii. Esiteks kirjuta Cursorile ülesanne väga kitsalt: “Leia topelt sooduskoodi rakendumise põhjus. Ära muuda andmemudelit. Lisa üks test olemasolevasse testifaili. Hoia muudatus alla 120 rea.” Teiseks kontrolli diff (muudatuste vaade) ise läbi. Kolmandaks käivita testid lokaalselt ja salvesta tulemus PR-i kirjeldusse.

PR-i kirjeldus võiks olla konkreetne, mitte luulevõistlus. Kasuta näiteks seda malli:

• ✅ Probleem: sama sooduskood võis rakenduda ostukorvis kaks korda.
• ✅ Muudatus: lisasin kontrolli ja regressioonitesti olemasolevasse hinnastamise testikomplekti.
• ✅ AI roll: Cursor pakkus testistsenaariumi ja esmase paranduse; inimene kontrollis ärireegli ning äärejuhtumid.
• ✅ Testid: npm test pricing läbis 42 testi / 42.
• 👉 Reviewerile: palun kontrolli, kas muudatus mõjutab kampaaniakoode ja kinkekaarte.

Kui kasutad GitHubi, seo see töövoog ametliku GitHub pull request’i juhendiga. Nii ei jää AI tehtud muudatus sinu arvutisse vedelema, vaid liigub läbi sama nähtava kontrolli nagu iga teine koodimuudatus.

6. Turvakontrollid ja inimreview

AI kirjutatud kood ei tohi saada erirada tootmisse. Kui inimene peab läbima review, testid ja turvakontrollid, siis peab sama tegema ka Cursoriga loodud kood. AI on siin nagu väga kiire praktikant: ta jõuab palju, aga sina ei anna talle serveriruumi võtit lihtsalt sellepärast, et ta naeratab tekstis viisakalt.

Alusta projektireeglitest. Cursoris saad kasutada Rules seadistust, kuhu paned kirja tiimi piirangud: ära logi isikuandmeid, ära lisa uut sõltuvust ilma loata, kasuta olemasolevat autentimise abifunktsiooni, ära muuda maksete loogikat ilma eraldi PR-ita. Eesti väikeettevõttes, kus kaks arendajat haldavad korraga e-poodi, raamatupidamisliidest ja kliendibaasi, vähendab selline reeglifail tüüpiliselt review edasi-tagasi suhtlust 20–30%.

Järgmine kiht on automaatne kontroll. Lülita sisse GitHub code scanning (automaatne turvaskaneerimine), et PR-is tuleksid välja näiteks ebaturvalised päringud, saladuste lekked või ohtlikud teegid. See ei asenda inimest, aga püüab kinni vea, mida väsinud arendaja reede õhtul kell 16:42 võib mitte näha.

Turvareview jaoks kasuta OWASP Code Review Guide’i. OWASP (veebiturbe kogukond) annab praktilise kontrollnimekirja: sisendite valideerimine, ligipääsuõigused, veateated, logimine, sessioonid ja andmebaasipäringud. Sa ei pea kogu juhendit iga väikese PR-i juures läbi närima. Tee oma tiimile 10-punktiline lühiversioon.

Näiteks Pärnu tarkvaramajas vaatab Martin AI tehtud kasutajaõiguste parandust. Ta kulutab review’le 35 minutit, mitte tavapärased 90 minutit, sest PR-is on testitõendid, code scanning ei näita kriitilisi vigu ja kirjelduses on välja toodud kaks riskikohta. Ettevõtte tunnikulu 50 eurot tähendab umbes 46 eurot säästu ühe review kohta, aga tähtsam on see, et ligipääsuviga ei jõua kliendiandmeteni.

7. 30 päeva plaan vana koodibaasi AI-abiga korrastamiseks

Vana koodibaasi ei korrastata kangelasliku nädalavahetusega. Sa saad parema tulemuse, kui teed 30 päeva jooksul väikseid, mõõdetavaid samme. Mõtle sellest nagu garaaži koristamisest: kui sa tõstad kõik asjad korraga õue, sajab kindlasti vihma.

1. nädal: kaardista. Lase Cursoril kirjeldada peamised moodulid, riskantsed failid ja kohad, kus teste pole. Ära lase tal veel suuri muudatusi teha. Eesti 3-liikmelises tootetiimis võiks eesmärk olla 10 kõige olulisema voolu nimekiri: sisselogimine, makse, arve, tellimus, kasutajaõigused ja muu selline. Ajakulu: 4–6 tundi.

2. nädal: kasvata testikatet. Vali iga päev üks väike koht ja lisa test enne parandust. Kui Harjumaa SaaS (veebipõhine tarkvara) tiim lisab 5 tööpäevaga 12 testi, siis väheneb käsitsi kontrollimise aeg näiteks 3 tunnilt 1,5 tunnile väljalaske kohta.

3. nädal: tee ainult väikseid PR-e. Üks PR parandab ühe vea või lihtsustab ühe funktsiooni. Mõõdikud olgu nähtavad: PR-i suurus alla 150 rea, review alla 45 minuti, kriitilisi code scanning leide 0. Kui PR läheb suuremaks, lõika see pooleks. Jah, see tundub tüütu. See on odavam kui kaks päeva merge-konflikti spaad ilma massaažita.

4. nädal: kinnista tööviis. Uuenda Cursor Rules faili, lisa PR-i mall, kirjuta tiimi väike OWASP-põhine kontrollnimekiri ja vaata numbreid. Kas vigade parandamise aeg langes? Kas reviewerid said kiiremini aru, mida AI tegi? Kas tootmisse jõudnud regressioone tuli vähem?

Kui sa alustad täna, vali üks igav, aga oluline viga. Kirjuta Cursorile kitsas ülesanne, lisa test, tee alla 150 rea PR ja palu revieweril kontrollida konkreetseid riske. Nii õpib tiim AI-d usaldama mitte loosungite, vaid korduvate väikeste võitude kaudu.

Sinu järgmine samm: võta järgmised 45 minutit, loo projektile üks Cursor Rules fail, vali üks väike bugi ja tee esimene AI-abiga PR koos testitõendiga. Kui see läheb hästi, korda sama homme. Vana koodibaas hakkab liikuma siis, kui sa lõpetad suure päästeoperatsiooni ootamise ja teed esimese turvalise lõike.