# Exemple de reguli în .cursorrules pentru proiecte TS/Next.js
- Always use TypeScript strict mode types.
- Never use 'any'. Define proper interfaces or types.
- Follow Tailwind CSS best practices and project existing design tokens.
- Prefer Server Components unless client reactivity (useState, useEffect) is required.
- Keep components small and modularized in /components UI layer.Am folosit GitHub Copilot încă din primele zile de beta și credeam că e tot ce am nevoie pentru autocomplete. Acum 5 luni am trecut pe Cursor pentru un proiect SaaS cu peste 15.000 de linii de cod în Next.js și TypeScript. Trecerea asta mi-a tăiat timpul de livrare pe feat-uri medii aproape la jumătate, dar nu fără mici dureri de cap.
Copilot e excelent pentru linie cu linie, dar atât
Dacă ai nevoie de o unealtă care să-ți ghicească linia următoare de cod sau să-ți scrie repede o funcție ajutătoare, Copilot își face treaba impecabil. La un abonament de 10 dolari pe lună, e practic moca pentru cât timp îți salvează la boilerplate și chestii repetitive.
Problema apare când ai de făcut un refactoring serios sau când vrei să adaugi o funcționalitate nouă care atinge 4-5 fișiere deodată: un controller, un DTO, două componente de UI și un fișier de tipuri. Copilot încearcă să ghicească local, dar pierde din vedere imaginea de ansamblu. De multe ori ajungi să dai accept la sugestii care folosesc tipuri învechite sau importuri greșite din alte directoare.
Unde schimbă Cursor jocul: Contextul și Composer
Cursor nu e doar o extensie, ci un fork de VS Code re-gândit în jurul modelelor de AI (în special Claude 3.5 Sonnet). Diferența majoră e modul în care gestionezi contextul.
În Cursor folosesc masiv @Files, @Folder sau @Git direct în prompt. Când am avut de refăcut modulul de plăți (Stripe webhooks + salvare în DB + notificări pe email), i-am dat context tot folderul de billing și schema de Prisma. A generat modificările sincronizate în toate cele 6 fișiere afectate. Ce îmi lua de obicei vreo 2 ore de navigat manual și modificat tipuri s-a rezolvat în sub 20 de minute, cu tot cu review-ul meu.
Totuși, există și trade-off-uri clare pe care trebuie să le știi:
- Prețul și limitările: Planul de 20$ îți oferă un număr limitat de request-uri rapide pe Claude 3.5 Sonnet. Dacă lucrezi 8 ore pe zi intensiv cu Composer, ajungi rapid la request-uri slow.
- Aplicație separată: Fiind un fork, trebuie să-ți reconfigurezi extensiile sau să le imporți din VS Code (deși importul automat funcționează decent în 90% din cazuri).
- Risc de lene mentală: E extrem de ușor să dai
Cmd+K->Acceptfără să citești codul. Am pățit o dată să-mi șteargă un check de securitate din middleware pentru că nu i-am dat contextul potrivit.
Workflow-ul care mi-a eficientizat munca
Trecerea eficientă nu înseamnă să lași AI-ul să scrie tot, ci să-i dai reguli clare. În rădăcina fiecărui proiect adaug un fișier .cursorrules scurt, adaptat pe stack-ul nostru.
Când scriu un feature nou, pașii mei sunt următorii:
- Creez un fișier nou de spec scurt unde descriu ce vreau să fac.
- Folosesc Composer (
Cmd+I) și atașez fișierele relevante cu@. - Îi cer să facă doar arhitectura de tipuri și interfețe.
- După ce aprob tipurile, îi cer să implementeze logica.
Copilot rămâne o alegere ok dacă vrei doar o autocompletare ieftină fără bătai de cap. Dar dacă lucrezi zilnic în aplicații complexe unde contează contextul dintre fișiere, Cursor joacă în altă ligă.
Voi ce folosiți în workflow-ul zilnic și câtă încredere aveți să dați accept fără review atent?