Setting up your vibe coding workspace as a non-engineer

Why scattered context across 10 tools is what slows you down

Most people building today are juggling ten tools at once. Notion for notes. HubSpot for the CRM. Mailchimp for emails. Figma for graphics. ChatGPT in one tab, Claude in another, Gemini in a third. Each one is good at the specific thing it does. The friction is that none of them know about each other.

Context is the thing that matters most when you're working with AI — and right now it's scattered. Your customer notes live in one place, your marketing copy in another, your product roadmap in a third. When you want to do something that touches more than one — draft a re-engagement email for customers who haven't logged in for a month, say — you spend half an hour copy-pasting between tabs before any actual work begins. The tools aren't the problem. The fragmentation is.

AI coding tools work the opposite way. Everything related to a project lives in one folder on your laptop: code, notes, customer data, marketing copy, scripts, past decisions. The AI reads all of it at once. When you ask it to draft that re-engagement email, it already knows your tone of voice, your customer list, your past campaigns, and what shipped in the product last week — because it can see all of it in the same place.

That's the unlock. Not "AI is faster" or "the tools are better." The shift is that the AI can finally hold your whole business in its head at once, because your whole business lives in one place.

Once you're set up here, the equation changes. The tools that genuinely earn their keep, you can rebuild yourself in an afternoon — now sitting on top of the same shared context as everything else you do. Years of compounding instead of months of tab juggling.

What the day-to-day vibe coding workflow actually feels like

Cursor collapses the gap between 'I have an idea' and 'the first version exists'. You think of something. You open a folder. You describe it. The first version exists by the end of the evening. You look at it, decide what's wrong, describe the fix, and the second version exists in another hour. That's the workflow. Once you've felt it a few times, going back to the old way of starting projects feels physically slow.

Step 1: Install Cursor

Cursor is a code editor. If you've ever used Microsoft Word or Google Docs, you already understand the basic idea: it's a window where files live and you can edit them. The thing that makes Cursor different is the AI panel on the right side. You can highlight a piece of text or a chunk of code, ask the AI a question, and it responds in context with what you've selected.

Go to cursor.com, download the version for your operating system (Mac, Windows, or Linux), and run the installer. The whole process is about two minutes including the download. The first time you open it, it'll ask if you want to sign in. Use a real email so you can move your settings between machines later.

Cursor has a free tier that's enough to play around with. If you find yourself using it daily, the Pro plan is $20 a month. I pay for it. It's worth it.

Step 2: Create your first project folder (one per business)

The mental model I've found most useful is: one folder per business idea. Every business, project, side hustle, or experiment lives in its own folder on your laptop. The folder holds everything related to that business: the website code, the customer notes, the marketing scripts, the database details. The folder is the business.

📁 Documents/
└── 📁 Projects/
    ├── 📁 coffee-shop-tool/        # one business = one folder
    │   ├── 📁 website/              # landing page code
    │   ├── 📁 customers/            # CSVs, notes, emails
    │   ├── 📁 marketing/            # copy, social posts
    │   ├── 📄 notes.md              # running brain dump
    │   └── 📄 CLAUDE.md             # instructions for the AI
    ├── 📁 get-psyched/             # tutoring + course + app
    │   ├── 📁 website/
    │   ├── 📁 course/               # online course portal
    │   ├── 📁 app/                  # TutorPro AI
    │   └── 📁 customers/            # student data, payments
    └── 📁 newsletter/

Make a folder somewhere easy to find. Mine all live in a folder called Projects, inside Documents. Inside Projects, I have folders for each business I've built or am building. The names are short and descriptive: get-psyched, tutorpro, solostack, photography. If you're starting fresh today, pick a working name for the idea you're going to test first. Something like coffee-shop-tool or online-course-portal. It doesn't have to be perfect. You can always rename it later.

Open Cursor. Go to File, then Open Folder, and pick the folder you just made. Cursor opens it. The folder is empty. That's fine. You're about to fill it.

Step 3: Write your first prompt

Open Cursor's AI panel on the right (or hit Cmd+L on Mac, Ctrl+L on Windows). A blinking cursor appears, inviting you to describe what you want.

For your first prompt, pick something concrete and small. Not 'build me a business'. Not 'make a CRM'. Something more like:

I want a one-page website that says my name, what I do, and has a button that opens my email. Build it as a single HTML file I can open in a browser.

The AI will think for a moment and then write the file. You'll see it appear in Cursor's sidebar. Click it to open it. Right-click in Cursor and choose 'Reveal in Finder' (or Explorer on Windows). Double-click the file. It opens in your browser. That's your first website, sitting on your laptop, built by describing what you wanted.

The first time this happens it's a strange feeling. Stay with that strangeness for a moment. The thing that just happened used to take a non-developer either a weekend of fighting with Squarespace or $500 paid to a freelancer. It now takes about ninety seconds.

Step 4: Run the describe → review → adjust loop

The loop is the whole skill. It looks like this:

1. Describe what you want. One outcome per prompt. Specific is better than abstract.
2. Look at what it built. Open the file. Run the script. Click around the page. Whatever the right test is.
3. Say what's wrong (or what to add). 'The button should be yellow, not blue.' 'Add a section underneath that lists my services.' 'The form should send to my actual email.'
4. Repeat. Most useful things take five to ten loops to reach the version you'd actually use.

The loop is the work. Once it feels natural, you can point it at almost anything: a landing page, a CRM, an email script, a data dashboard, a booking form. The thing that makes someone good at this is not coding ability. It's the ability to look at what came back and notice what's missing.

Step 5: Save your work with Git

Once you've built something you don't want to lose, save a version of it using Git. Git is a free tool that takes snapshots of your folder over time, so if you break something later you can roll back. You don't need to understand how Git works to use it. You just need to ask Cursor's AI panel, 'set up git in this folder and commit what's here'. It does the work.

Create a free GitHub account if you don't have one, then ask Cursor to push your folder up to GitHub. (This is the first moment where you'll feel the pull of a plugin — once the GitHub CLI is installed, Cursor can create the repo and push to it in the same sentence. More on that in the next step.) Now your work lives in two places: your laptop and the cloud. If your laptop dies, your business survives. This is the kind of small protective step that experienced builders do automatically and beginners often skip until it's too late.

Step 6: Run a security check before any public push

Pushing your folder to a public GitHub repo is the single highest-risk moment in the vibe coding workflow. Scraper bots crawl new public commits within minutes — if a real API key is sitting in a file you didn't realise was tracked, it can be found and weaponised before you've closed the laptop. The cost can be anywhere from a surprise $400 OpenAI bill to a full AWS account hijack, depending on which key got out.

The fix is a discipline, not a tool: secrets live in a .env file, which Git is told to ignore. Your code references them as variables (process.env.OPENAI_API_KEY), never the actual value. If you've been pasting real keys into files, stop and ask Cursor to "move every API key in this folder into a .env file and update the code to read from it" — the AI handles the refactor.

// real key hard-coded into a tracked file
const key = "sk-proj-a1B2c3D4e5F6g7H8i9...";

fetch(api, {
  headers: { Authorization: key }
});

// app.js — only references the variable name
const key = process.env.OPENAI_API_KEY;

// .env — real value, never committed
OPENAI_API_KEY=sk-proj-a1B2c3D4e5F6...

// .gitignore — tells Git to skip .env
.env

Before the first push to a public repo (and before flipping a private repo to public), run an audit. The security check skill scans your tracked files and git history for anything that looks like a leaked key, verifies .gitignore actually covers .env and credentials files, checks that your frontend bundles aren't accidentally shipping server-side secrets to the browser, and audits any Claude Code skills or MCP servers you've installed for supply-chain risk. It runs in about 30 seconds and tells you exactly what (if anything) to fix before you push.

Even .env isn't enough: the traces you leave by handling the key

This is the part most beginner tutorials skip. .gitignore only protects against Git leaks. Every other place you touch the key is a separate leak vector — and none of them are caught by the security-check skill above, because they don't live in your repo at all:

• Your shell history. A key you type into a command (export OPENAI_API_KEY=sk-proj-...) gets saved to ~/.zsh_history or ~/.bash_history in plain text. Any other program on your laptop (or any unauthorised access to it) can read it.
• Your AI chat with Cursor or Claude Code. A key you paste into the chat panel to ask "is this key valid?" or "help me debug this auth error" becomes part of the AI provider's session logs. Treat anything pasted into a chat as if you'd written it on a postcard.
• Terminal scrollback and error messages. A key printed during a failed API call or a console.log sits visible in the terminal until you close the window — sometimes a screen recording away from being exfiltrated.
• Screenshots. If you screenshot a terminal or editor to ask for help and the key is in frame, anyone you sent it to has it.

For local development keys (a personal database, a Stripe test-mode key, a sandbox LLM key with a $20 monthly cap), this risk is acceptable — the worst case is bounded and reversible. For production keys, it's not. The cleaner rule:

Netlify has a Site configuration → Environment variables page. You paste the live key once, in a browser tab, into a field that never gets typed into your terminal or pasted into a chat. The deployed function reads process.env.STRIPE_SECRET_KEY at runtime from Netlify's encrypted store. Your local code uses a separate test key; your deployed code uses the production one. The production value never lives on your machine. (Vercel, Cloudflare Pages, Render all have the same pattern — they call it "environment variables" or "secrets" in the dashboard.)

This matters most for the two categories of key where a leak costs real money before you notice:

Why these two categories specifically:

• Stripe live keys aren't just a billing problem. Anyone with the key can issue refunds, create payment intents to attacker-controlled cards, or read your customer list. Always use Stripe test mode for local development (it gives you a separate set of keys that move fake money), and paste the live key only into Netlify when you're ready to accept real payments.
• OpenAI and Anthropic keys are usage-billed with no default hard cap. A key in a scraper bot's hands can rack up four-figure inference bills in a single weekend before the provider notices the abuse pattern. For local dev, create a separate "sandbox" key with a $20 monthly spend cap set in the provider dashboard — that way even if it leaks, the damage is contained to the cap.

One thing worth knowing: if a real key has already landed in a commit, force-pushing a "cleaned" history does not un-leak it. Anyone (or any bot) who saw the original commit has the key forever. The only real fix is to rotate the key at the provider — regenerate it in the OpenAI/Anthropic/Stripe dashboard, which invalidates the old one. Run the check before the push and you avoid the whole problem.

Step 7 (optional): Add CLI plugins (Claude Code, GitHub CLI) to extend Cursor

Once the basic loop feels natural, you'll start hitting moments where you wish Cursor could reach outside the editor — push to GitHub from a sentence, run a longer-form coding agent, query your calendar. That's when you add command-line tools (CLIs) to your machine.

Think of CLIs as plugins for Cursor. Each one is a small program that gives Cursor a new capability. You install it once, and from then on you can ask Cursor in plain English to use it — Cursor opens its built-in terminal, runs the CLI for you, and shows you the result.

A few worth knowing about:

• Claude Code CLI — Anthropic's terminal agent. Same Claude model that powers Cursor's AI panel, but in a longer-form, more agentic mode: better at planning across many files at once, running shell commands, reading databases. You can call the Claude Code CLI from inside Cursor's built-in terminal whenever a task is bigger than a single function, or drive it directly if you prefer it over Cursor's panel. Pricing starts at $20/month for Pro and $200/month for Max. The Max number sounds high in isolation; in context you're replacing the work of a small development team, and a single mid-level developer costs more than that per day.
• GitHub CLI (gh) — lets Cursor create repos, open pull requests, and comment on issues from a prompt. "Push this folder to a new private GitHub repo" becomes a sentence, not a tutorial.
• Google Workspace CLI (gws) — lets Cursor read your calendar, search Drive, and send emails. Useful once you start wiring AI into your actual workday.

None of these are required. Cursor's built-in AI panel will carry you a long way on its own. Add CLIs as you hit the moments where you wish Cursor could "just go do that thing for me" — at which point installing one is usually a five-minute trip to the tool's docs.

Four mistakes that slow new builders down

A few things I see new builders trip on, that I'd save you from:

Trying to learn Cursor before using it. Don't sit down and read the Cursor documentation. Open it, click around, ask the AI panel to do something small. The tool is designed to be learned by using it. Reading about it first is a comfortable form of procrastination.

Asking for too much in one prompt. 'Build me a full e-commerce store with payment processing, user accounts, and inventory tracking' is too big. The AI will try, but it'll skip details and you'll get a half-broken result. Smaller prompts compound into bigger things. Ask for the homepage. Then ask for the product page. Then ask for the cart. Each prompt builds on the last.

Not telling the AI when something is broken. If you run the result and it doesn't work, paste the error back into Claude Code and say 'I got this error'. The AI is good at fixing problems it can see. It's not psychic. The whole loop depends on you feeding back what actually happened.

Switching tools every week. The whole point of this setup is to make AI tool FOMO irrelevant. Every new wrapper that launches on Product Hunt is doing a version of what Cursor and Claude Code already do — usually worse, almost always more expensive. The compounding benefit comes from getting fluent with one toolkit, not from sampling everything. The people who get good at this in 2026 will still be using essentially the same setup in 2046, just with smarter models underneath. That's the trade: one setup, one skill, twenty years of leverage.

How your thinking shifts after two weeks of using Cursor daily

After about two weeks of using Cursor daily, something shifts in how you think about software. You stop seeing tools as things you have to pay for and start seeing them as things you can describe. The next time you find yourself looking at a SaaS pricing page, instead of clicking 'start free trial', you'll catch yourself thinking 'I could probably just build this'. That instinct is the unlock.

It also changes what you do with annoying problems. A recurring task at your day job. A spreadsheet you keep manually updating. A piece of data you keep wishing you could see. Those used to be things you put up with. Now they're prompts. Most of them take less than an hour to solve once you describe the problem clearly. The cumulative effect of solving ten of those is that your week gets noticeably lighter, and you start trusting the tool with bigger asks.

The other thing that changes is your tolerance for slow software. Once you've felt how fast a custom-built tool can be, sluggish SaaS apps start to feel like wading through honey. That's not a complaint, it's a signal. The next version of your work life involves owning more of your tools, because the cost of owning them has fallen to almost nothing.

What to do next: build one tiny thing tonight

Once the setup is in place, you have everything you need to start building real things. The next article in this series is the one I think matters most: the validation loop, where you find a real problem and pre-sell it before writing a single line of product code. That's the step that separates 'I built a thing' from 'I built a thing people will pay for'.

Before you move on, the most useful exercise you can do today is to build one tiny thing. A landing page for an idea you've had. A script that does a small annoying task you've been putting off. A simple form that sends to your email. Don't pick anything important. Pick something you can finish in an evening. The point is to run the loop a few times, feel it work, and prove to yourself that the setup is real.

The hardest part of starting any new way of working is the moment between 'I've installed the tools' and 'I've used them for something real'. The gap is small. Walk across it tonight.

Skills referenced in this article

Every AI skill referenced above, in one table you can bookmark.