Best Practices for Vibe Coding with Cursor
The Journey
Over the past three months, I've developed half a dozen projects using Cursor, and both the tool and my workflow have evolved rapidly. Initially, I frequently prompted Cursor to correct linter bugs, but now it resolves over 95% automatically. This improvement is just the beginning, with the addition of rules, memories, and test-driven development.
That evolution hit a milestone during a recent session. I was re-architecting part of our project to support a multi-phase research workflow—a task that’s notoriously hard for AI due to legacy code remnants and complex interdependencies. Cursor navigated it more smoothly than expected, even when grappling with Google Cloud's tangled web of IAM permissions and API quirks. After hours of tweaking cloud configurations, orchestrating logic, and sanity-checking with Gemini and Sonnet agents, I stepped away for a break, leaving Cursor with test-driven prompts. I came back to find everything working perfectly on the first run. It felt like the culmination of months of iteration and setup—a true “vibe coding” moment.
Cursor Setup
Cursor is built on VS Code, like many modern IDEs are built on Chromium. This means VS Code plugins are compatible with Cursor. Beyond VS Code settings, Cursor has specific configurations to consider. Assuming familiarity with VS Code, let's focus on Cursor-specific settings.
Privacy Mode: Disabling Privacy mode allows full access to beta features like Background Agents. I initially kept it on but turned it off to explore new features.
Auto-Run: Consider the security implications before enabling Auto-Run. Cursor might execute CLI commands. My setup includes:
Auto-Run Mode On
File-Deletion Protection Off
MCP Tools Protection Off
Dotfile Protection On (initially, later experimented off)
External-File Protection On (to confine operations to my workspace)
Balancing convenience with security is key. Consider restricting some access through external file protection, a virtual machine, a dedicated user account, or a separate computer.
Tools and Integrations: GitHub integration is required for background agents. I haven't connected to Slack or used Custom MCP tools yet. MCP is like an API gateway for LLM agents.
Rules: Rules are baseline prompt components added automatically. They come in two types: User Rules (apply to all workspaces) and Project Rules (apply to the current workspace).
User Rules example: Direct Cursor to use Test-Driven Development (TDD).
Project Rules example: Specify a tool version for the project (e.g., a Gemini model) or mandate the use of Axios over Node-Fetch.
Memories (Beta): Cursor can record its insights and learnings as "Memories." These are distinct from Rules.
Cursor Ignore: Similar to .gitignore, .cursorignore prevents Cursor from modifying specific files
Beta Features: I keep Early Access on to try the latest features. I'm still working on getting Background Agents running.
Best Practices for Vibe Coding
Expect mistakes initially. Commit frequently and revert to known good states with git. Embrace reset head or checking out past commits. Automated tests are vital, particularly for major cases. Aim to let the AI loop and self-correct as much as possible to avoid manual QA.
During development:
Have the agent retrieve logs and iterate fixes, automating as much as possible.
Manage Cursor's tool call limits by hitting "Resume" when prompted and accepting changes incrementally.
For complex architectural tasks, observe and guide Cursor closely; for bug fixes, allow it to work more independently.
Use downtime to check on Cursor's progress, hit "Resume/Accept All," or perform manual interventions as needed.
Final Cleanup
Before major releases, ask the agent to:
Clean up documentation
Remove extraneous console logs
Check for security holes like slopsquatting
Refactor for redundancy reduction
Add test coverage
Ensure proper handling of environment-specific aspects
Starting a New Project
Begin by discussing the project with a chatbot like ChatGPT, using a top reasoning model. Develop two markdown files:
technical-design-doc.md: Defines tools, architecture, data model, and epics.
todo.md: Lists development phases with tasks and checkboxes.
Work on one phase at a time, referencing TDD. Instead of feature branches, use phase branches with frequent commits. Perform the cleanup steps at the end of each phase.
Happy vibing! There will be frustration, but also breakthroughs and joy, as coding has always been. At mention us on LinkedIn if you have any questions or cool projects to show off!
Read Other Posts
