Cursor for Non-Engineers: The Guardrails That Prevent Disasters

A non-technical founder opens Cursor for the first time, installs the default settings, connects it to their Supabase project, and types a prompt that ends with the words "clean up the database." Two minutes later the users table is empty, the auth rows are gone, and the production app is returning five hundreds to every visitor. Nobody pressed a red button. Nobody ignored a warning. The tool did exactly what it was designed to do, because the person driving it did not know which settings turn an AI coding assistant into something with the same blast radius as a very confident junior engineer who has been given sudo access on their first day.

This happens more than the Cursor marketing pages suggest. It has happened to founders we now onboard at WitsCode, and it is the reason our intake for every non-engineer client starts with a guardrails pass before anyone writes a prompt. What follows is the setup we install for every vibe coder who wants to use Cursor without losing a week of work, a customer database, or an entire product in a single bad conversation. All of it is invisible until the first disaster, which is why almost nobody sets it up until they have already had one.

The one setting that turns Cursor into a blast radius

The most dangerous control in Cursor is buried in the chat settings and labelled something close to auto-run or auto-approve terminal commands. With it off, the agent asks before running any shell command, and a founder who does not recognise a command can decline it. With it on, the agent executes whatever it thinks is needed, in sequence, without stopping. That is the setting that turns the tool from an assistant into an unsupervised engineer with full shell access to your machine, your repo, and by extension any database your environment variables can reach.

The problem is not that the agent is malicious. Language models do not have a human concept of a non-reversible command. A prompt that says move the old rows out of the users table gets translated into a truncate or a delete depending on how the model feels about efficiency that minute, and if your .env.local contains a Supabase service role key the agent will cheerfully open psql and run it. There is no undo. There is no bin. The rows are gone.

We leave auto-run disabled for every non-engineer account we set up. The friction of having to approve each terminal command is exactly the friction a non-dev needs, because the approval prompt is the only moment where a human with product context looks at the literal string drop table users and decides whether that is what they meant. If the founder later wants to enable auto-run for obviously safe commands like running the dev server or installing a package, Cursor supports an allowlist for specific command patterns. We add npm run dev, pnpm install, and the test command to the allowlist, and we leave everything else manual. The founder loses ten seconds per approval and gains the ability to sleep.

The rules file that blocks the destructive commands

Cursor reads a rules file from every project you open and treats it as a persistent system prompt for the agent. The modern location is a directory called .cursor/rules with one or more .mdc files inside, each with a small bit of front matter declaring whether the rule always applies or only applies to specific file globs. The older format is a single file called .cursorrules at the root of the repo, which still works and is simpler for founders to edit by hand. Either way, this file is the highest leverage guardrail in the entire setup, because the agent reads it before every response and actually respects what it finds there when the model is strong enough.

The rules we install for non-engineers look something like this in plain prose. Never run any command that drops, truncates, resets, or deletes data from a database, including supabase db reset, prisma migrate reset, drizzle-kit drop, any psql invocation containing drop or truncate or delete, and any raw SQL matching those patterns. Never run rm with the recursive flag on any directory above the current file you are editing. Never run git push with the force flag. Never run git reset with the hard flag on a branch that has commits not yet pushed to origin. Never commit any file matching the patterns .env, .env.local, or any path containing the word secrets. Never write a service role key or a private API key into a file that lives outside .env.local. Never push directly to the main or master branch. If a task seems to require any of the above, stop and explain what you would do and why, and wait for explicit confirmation.

These are not suggestions the model politely declines to follow. Frontier-class models, including the Claude and GPT tiers most founders default to in Cursor, treat a well-written rules file as authoritative and refuse the operation when asked. Weaker models drift, which is why the second half of the rule set tells the agent to always prefer creating a new migration over editing an existing one, to write a plan before touching more than three files, and to surface a diff summary at the end of every multi-file edit. A hard denylist and a process checklist give the founder two chances to catch a mistake before it lands.

The rules file lives in the repo, which means it travels with the project. When the founder clones the repo to a new machine or hands it to a contractor, the guardrails come with it. That matters more than it sounds, because most Cursor mistakes happen on fresh machines, late at night, on a branch someone forgot to push.

Why agent mode should be the exception, not the default

Cursor ships with three modes. Ask mode is read only and cannot modify files or run commands. Manual or edit mode can modify files but cannot touch the terminal. Agent mode can do both, in sequence, until it decides the task is done. Most tutorials tell founders to use agent mode because it is the most impressive demo, and most founders then leave it there because switching modes feels like friction.

The friction is the point. Agent mode is correct for tasks where the founder does not know what files need to change and is happy to accept edits across the codebase. It is wrong for the ninety percent of tasks where the founder knows exactly which page or component they want to tweak. For those, manual mode produces better output, because the model focuses on a specific file instead of wandering through the tree looking for things to refactor, and safer output, because the model cannot open a terminal and discover that your Supabase CLI is authenticated.

We set up our non-engineer clients with manual mode as the default and agent mode as an explicit opt-in for tasks they have flagged as bigger than a single file. The cost is one extra click when they start a new conversation. The benefit is that the riskiest mode is never the accidental mode. When they do switch to agent mode, they know they are switching, and they pay more attention.

There is also a middle ground most founders never discover. Cursor supports running agent mode with auto-run disabled, and this is what we recommend for most multi-file tasks. The agent writes and runs commands, but every terminal step pauses for approval. It is slower than full auto, but the slowness is concentrated on the exact moments where human judgement is worth something.

Branch per prompt, PR before merge, preview before prod

The worst production incidents we clean up for founders are not AI incidents in the strict sense. They are git incidents caused by AI speed. The founder vibe coded directly on main for a week, never committed, had one bad agent turn, and lost everything. Or they did commit, but pushed straight to main on GitHub, which was connected to Vercel production, and a broken build took the checkout page down for three hours during a sale.

The fix is the same discipline a junior engineer learns in their first week, compressed into three rules the founder can memorise. Start every new prompt session by creating a branch. Every branch opens a pull request. Every pull request deploys to a preview URL before anything merges to main. None of this is Cursor-specific, but Cursor makes it more important than it used to be, because the speed at which changes land means the gap between good code and a broken deploy is now measured in seconds rather than hours.

On the GitHub side we enable branch protection on main from the first day of the project. Main requires a pull request. Pull requests require the preview deploy check to pass. Force pushes to main are disallowed. These settings take ninety seconds to configure and prevent the single most expensive category of founder mistake, which is the moment at midnight when the founder types git push origin main into a terminal the agent opened and watches production break in real time. With branch protection enabled, the push is refused, and the founder has a moment to understand why before anything bad happens.

On the Cursor side we train the founder to treat each prompt conversation as a branch. The workflow is create branch, prompt, review diff, commit, push, open PR, wait for preview, click preview link, poke around, merge. It sounds slow written out and takes less than two minutes in practice once the muscle memory is there. The founder never works directly on main, never merges without a preview, and never loses more than one branch worth of work to a bad agent turn. The bad agent turn still happens, occasionally, but the blast radius is now one feature instead of the entire product.

Secrets, backups, and the things a rules file cannot protect you from

A rules file stops most of the in-repo mistakes. It does not stop the founder from pasting their Supabase service role key directly into the Cursor chat window because they wanted the agent to help debug an auth issue. It does not stop them from storing that key in a file called notes.md that then gets committed. And it cannot bring back rows that a prior agent turn deleted before the rules file existed.

For secrets, the rule we teach is that environment variables live in .env.local and nowhere else, that .env.local is listed in .gitignore from the first commit, and that service role keys or any other server-side secrets never appear in client-side files or in chat messages. Cursor's agent can read your env file when it genuinely needs to, and any frontier model respects the instruction to not echo those values back into chat or commit them elsewhere. The mistake is almost always the founder pasting the key themselves because they do not yet understand that the chat is a transcript that persists.

For backups, the rule is that anything that would be painful to lose has point-in-time recovery enabled on day one. Supabase offers PITR on paid tiers. Neon and Planetscale offer branching that achieves the same thing. Firebase has scheduled exports. Whatever the stack, the founder should be able to answer the question of what happens if the database is empty tomorrow morning, and the answer should involve a restore that takes minutes, not a post-mortem that involves apologising to customers. This is not a Cursor setting. It is a platform setting, and it needs to exist before Cursor is pointed at the database, because the first bad prompt will come before anyone remembers to enable it.

The remote repo is the third piece. A local-only repo is a single hard-drive failure from being gone. We set up a private GitHub remote before the founder writes any code, and we add a commit-and-push step to the end of every working session. A founder who commits and pushes at the end of every session loses at most a session of work, and in practice they lose nothing because the agent auto-checkpoints between turns and Cursor lets them rewind mid-session.

What the WitsCode Cursor onboarding covers

The founders we work with do not want to become engineers. They want to ship product, and they have correctly identified that Cursor lets them do that faster than hiring a team. The part they should not have to figure out alone is the half day of configuration that turns Cursor from a dangerous tool into a safe one. That is what our Cursor onboarding for non-technical founders covers. We install the rules file, configure the auto-run allowlist and denylist, set up the GitHub repo with branch protection, connect Vercel or Netlify preview deploys, enable PITR on the database, wire up the env vars correctly, and walk the founder through the branch-per-prompt workflow with three real tasks on their own codebase so the muscle memory exists before they are on their own.

It is a one-time session that prevents the specific category of disaster that ends most vibe-coded products before they ship. If you are about to start building, or you are already building and none of the above is in place, that is the moment to put the guardrails in. The tool is genuinely good. It just needs the bumpers up before a non-engineer rolls a strike.

WitsCode is the last mile developer for vibe coders. We have run this onboarding across two hundred and fifty plus founder projects and the setup holds up across Cursor versions, model changes, and stack swaps. If you want the guardrails installed on your project this week, that is the fastest thing we do.