My Cursor Workflow: Fast Models for Simple Work, Strong Models for the Rest

I use Cursor to build and polish my own site, not to write code for its own sake. The same tool can feel like a quick sketch pass or like a long critique session, depending on which model I pick.

If I always reach for the strongest option, I wait longer and pay more for tasks I could have checked with my eyes in ten seconds. If I always reach for the lightest option, I waste time redoing work when the real question was never "type this" but "how should this behave when real people stress it?"

So I split the work the way I would split a project in Figma: fast iterations where the frame is already clear, and slower, deeper passes where the interaction model still needs room to breathe.

I stay on a lighter model when I already know what "done" looks like. The layout, the copy, or the pattern is decided; I mostly need execution and repetition.

Scenarios from shipping this portfolio (where a quick pass was enough):

• Tightening the shell of the site — Bringing top padding down on phones across every main page so the first screen felt less empty. Same idea everywhere; easy to eyeball.
• Tip chips on Fair Split — Swapping the selected state to the same peach tone as text selection, and fixing cramped chips on small widths. Visual rules were already set; it was craft and CSS.
• Hub and home copy — Updating the Hungry Cheetah list and the home blurb when a tool was renamed or replaced. Words and links, not a new system.
• The advanced split table on mobile — The desktop grid was fine; phones needed a card layout so Person / Share / Pays / Remove were not fighting for space. A layout split I could validate in a screenshot.
• Small interaction clean-ups — For example, making sure the spotlight on a list item followed the whole row, not only the label after the dash, once the intended hover behavior was clear.

In all of these, I could describe the outcome like a short note to myself—match this treatment, stack this on narrow, keep the spacing rhythm. That is when a fast model feels like a pair of hands, not a second brain.

I move up to a more capable model when the work is fuzzy, chained, or easy to get wrong—when I need someone (or something) to hold the whole problem alongside me.

Scenarios from the same project (where I deliberately chose a deeper run):

• Today I Learned — preview vs export — The card had to look right in the editor and match the exported image, with a signature that never collided with the body. That is typography, measurement, and edge cases across presets—not a one-off padding fix.
• Fair Split — from idea to rules — Replacing an old "meeting cost" toy with something people actually use, then adding Quick vs Advanced, then changing Advanced so only the last person’s share auto-fills to 100% while the rest stay editable. Product behavior and math had to stay in sync.
• SEO audit on the portfolio site — One pass had to cover metadata and social previews, sitemap/robots, JSON-LD, canonicals per route, heading semantics, and usability tweaks—without breaking layout or duplicating conflicting tags. Easier to let a capable model help trace routes and edge cases than to chase them line by line in isolation.
• Security review after those changes — Re-checking what must never leave the server (admin secret, env-only config), tightening admin token verification and upload validation, and making sure production API errors do not leak paths or internals in JSON. Judgment calls, not cosmetic copy.

Here I am not asking for speed. I am asking for judgment: tradeoffs, failure modes, and a plan I can still explain to myself a week later.

No matter which model I use, I still look at what shipped. A fast pass is only cheap if I actually review it. A deep pass is only worth it if I do not treat the answer as final just because it sounded confident.

Cursor helps me move between sketch and production. Choosing the model is how I decide whether this moment is draft energy or design review energy—and that has felt closer to how I already work in Figma than any jargon about tokens ever could.