Working in the editor

You'll spend more hours looking at this screen than any other. Most guides skip it because developers absorbed it years ago — but nobody ever taught them either, and for you it's the difference between feeling lost in someone else's tool and feeling at home in your own.

This page is Cursor-first, because that's what the previous page recommended. Cursor is a fork of VS Code, so almost everything here applies identically to plain VS Code.

The five regions

1. 1Activity bar. The icons down the far left switch what the sidebar shows. You need exactly two: the top one (files) and the one that looks like a branching line (source control, where you commit and read diffs).
2. 2Sidebar / file tree. Your project's folders. Click a file to open it. This is your map — if you can't find things here, ask the AI "where does X live in this project?" rather than clicking around.
3. 3Editor. The file you're looking at, with tabs across the top for everything you've opened. Tabs accumulate relentlessly; close them with ⌘/Ctrl+W.
4. 4Terminal panel. The black window from the next page — except it lives here, inside the editor, already pointed at your project. Open it with Ctrl+` (the backtick key, top-left of most keyboards).
5. 5AI panel. Cursor's chat and agent. Open it with ⌘/Ctrl+I.

Reading the file tree

Two things in the tree carry information beyond the file names:

• Colours and letters. Once a project is in Git, files that have changed turn a different colour with an M beside them (modified); brand-new files get a U (untracked). A glance tells you what this session has touched.
• Grey, faded files. Anything greyed out is ignored by Git — usually node_modules or .env.local. Seeing .env.local greyed out is a quick daily confirmation that your secrets aren't being committed.

The editor pane

Three bits of the editor talk to you, and beginners tend to ignore all three:

• Red squiggles. TypeScript telling you something doesn't add up — a misspelled name, a missing value, a mismatch. Hover to read it. This is the safety net from the stack page doing its job: a squiggle now is a bug that never reaches a user.
• Yellow squiggles. Warnings. Usually ignorable, occasionally useful.
• The gutter — the narrow strip left of the line numbers. Coloured marks there show which lines you've changed since your last commit.

Reading a diff

This is the section to actually learn. Click the source control icon in the activity bar and then any changed file, and you get this — the same view you'll see whenever an AI proposes a change.

1. 1Which file. Always check this first. "It edited a file I didn't expect" is the most common early warning sign of scope creep.
2. 2Removed lines — red, marked −. This is what you're losing. Read these more carefully than the green ones; deletions are where things quietly break.
3. 3Added lines — green, marked +. What replaces it.
4. 4Accept or reject. Nothing is permanent until you accept. Rejecting costs you nothing but the time already spent.

Two shortcuts worth memorising

The command palette — ⌘/Ctrl+Shift+P. Type what you want in plain words ("terminal", "theme", "format") and it finds the command. This is the escape hatch for "I know it can do this but I've no idea which menu" — which, for the first month, is constantly.

Search everywhere — ⌘/Ctrl+Shift+F. Searches every file in the project. The fastest way to answer "where does this button's text actually come from?" is to search for the words you can see on screen.

Claude Code inside the editor

Two ways to do it, and they're complementary rather than competing:

Start with the terminal panel. You get the whole tool, it matches every tutorial and every page of this guide, and you still have the file tree and editor right there to look at what it's doing.

The loop, visually

The blue box is the entire job. It's tempting — especially when the agent is confident and the change is long — to skim and accept. Don't. Three weeks of accepting changes you didn't look at produces a project you don't recognise and can't fix.

Selection as context

Select some code in the editor before you ask a question, and it goes onto the AI's desk automatically. This is the cheapest, most precise way to point at something: highlight the bit you mean, then ask "what does this do?" or "make this responsive". Far better than describing the location in words.

I'm a non-technical founder using Cursor (a VS Code fork) for the first time. I know HTML and CSS but have never used a code editor.

Give me a 20-minute orientation covering only what I actually need:

- What each region of the screen is for
- The 8 keyboard shortcuts worth learning in week one, and what each is for
- How to search across every file in a project, and when I'd want to
- What the coloured marks in the gutter and the file tree mean
- How to open a terminal inside the editor
- Three settings a beginner should change immediately, and why

Present it as a checklist I can work through with the app open. Skip anything about extensions, debugging, or language servers — I'm not there yet. Where Cursor and plain VS Code differ, say so.

I'm a non-technical founder. I can see the red and green lines in a diff but I can't judge what I'm looking at.

Take the current uncommitted changes in this project and walk me through them as a teaching exercise:

1. For each changed file: what is this file for, and why did it need to change?
2. For each block of changes: what was removed, what was added, and what's the practical difference?
3. Which changes are cosmetic and which change behaviour?
4. Is anything here deleted that looks like it might still be needed elsewhere?
5. Did anything change that wasn't part of what I asked for?

Then teach me the general skill: as a non-coder, what are the four or five things I should always check in a diff, in what order, and what does each one protect me from?

Help me configure Cursor for the workflow I'm using: Claude Code running in the integrated terminal, file tree visible, and a browser open beside it.

Tell me:
1. How to arrange the panels, and how to save that arrangement so it persists
2. Which settings to change so I can actually read the screen for six hours (font size, line height, word wrap, minimap)
3. How to make the terminal panel bigger and keep it that way
4. How to turn off anything that will distract or confuse a beginner
5. Which three extensions are genuinely worth installing at my level, and which popular ones I should ignore for now
6. How to make unsaved-file and Git-status indicators as obvious as possible

For each setting, tell me what it does and why it matters — I want to understand my tools, not just paste settings in.

I'm looking at my project in the editor and I don't know where anything is. Teach me to navigate by what I can see rather than by knowing the code.

Using this specific project, show me how to answer these questions myself:
1. I can see some text on my live page — which file does it come from?
2. I clicked a button and something happened — which file handles that?
3. This component appears on three pages — where is it defined, and where is it used?
4. Where does the data on this page actually come from?
5. Which files changed most recently, and what were they doing?

For each, give me the exact editor feature or search to use, and then walk me through doing it once on my own project so I've actually done it rather than read about it.