The Tool That Changed the Feedback Loop
Before Claude Code, my workflow looked like this: open a browser tab with Claude Cowork, describe what I needed, get generated code back, copy it, switch to VS Code, paste it into the right file, save, reload the browser, see what broke, go back to Claude, explain the error, get new code, repeat. It worked. I built real things with it — ten live apps, a custom static site, 40+ blog posts. I can't complain about the results.
But there was always friction. Not the frustrating kind that makes you quit — the low-grade kind that compounds invisibly. Every copy-paste is a context switch. Every context switch costs a beat of focus. When you're building in the margins of a full-time job, those beats add up.
Claude Code in VS Code removes that layer entirely. Claude isn't in a tab anymore — it's in the same place the files are. It can read them, edit them, and verify what it changed without you touching a clipboard. That sounds like a small thing. It isn't.
The Moment That Made It Obvious
A few weeks into using Claude Code, I needed to add a security token to every Make.com webhook call on my site. The reason: I'd set up Token Guard filters in Make.com to reject unauthorized requests, but I hadn't yet added the matching token parameter to the front-end fetch calls. Every webhook call needed one additional line in the payload: the secret token.
Doing that manually meant opening 40+ HTML files, finding each fetch call, confirming the right webhook URL was there, adding the token line, saving, and moving on. Each file takes 3–4 minutes if you're careful. That's somewhere between 2 and 3 hours of tedious, error-prone work — the kind of task that's easy to put off because it's not interesting, just necessary.
In Claude Code, I described what I needed. It scanned every file in the repo, identified each Make.com webhook call, added the token parameter to the payload, and listed exactly what it changed. The whole thing took one session. Not two hours — one session. And because every file edit was shown to me before it was applied, I could verify each change was correct before accepting it.
That's the moment the category difference became real. This wasn't a task I could have done in Chat — too much context to maintain across too many files. Cowork could have handled some of it but would have needed careful session management. Claude Code handled it the way a competent developer would: systematically, completely, with verification at each step.
What Actually Changes When Claude Lives in the Editor
The obvious answer is speed. But that's not the most important thing. The most important thing is that the task surface changes — there are things you'll actually attempt in Claude Code that you'd never tackle in Chat or Cowork, because the friction of doing them manually made them feel not worth it.
The 40-file webhook update is one example. Here are others from my own recent sessions:
- Cross-file consistency checks. I asked Claude Code to verify that every blog post had the correct newsletter webhook URL and GA4 tag — not just the one I was editing, but all of them. It read every file, flagged the two that had stale values, and fixed them. I would never have done this manually.
- In-place iteration. When building the Reading Buddy app, I could describe a UI behavior, see the code change appear in the file, reload the app in the browser, and confirm it worked — all without leaving VS Code. The cycle from "I want this" to "it works" is measured in seconds, not minutes.
- Error diagnosis from the source. When something breaks, Claude Code doesn't just read the error message I paste into a chat window — it reads the actual file where the error is. It traces the problem back to the line, explains what's wrong, and fixes it in place. No copy-paste required to get it the context it needs.
Each of these sounds incremental. Together they represent a different way of working.
The Transparency Factor
One thing I didn't expect to matter as much as it does: Claude Code shows you everything it's about to do before it does it. Every file edit is displayed. Every command is listed. You approve or reject each step. It doesn't batch up a bunch of changes and surprise you with the results.
For someone who isn't a professional developer, this matters a lot. I'm not just trusting that something happened correctly — I'm in the loop on every change. When I accept an edit, I've seen it. When something goes wrong, I know what the last action was. That transparency builds the kind of trust that makes you willing to let Claude attempt bigger, more complex tasks.
The model is collaborative, not autonomous. Claude does the work, but you're present for it. That's the right balance when you're a non-developer working on a real site with real users.
What It Still Doesn't Do
Claude Code is not magic. It still needs clear direction. Vague prompts produce vague results — that hasn't changed from Chat or Cowork. If you ask it to "make the app better," you'll get something, but it might not be what you wanted. Specific prompts with clear success criteria produce things that work.
It also makes mistakes. I've had Claude Code misread a file structure, suggest an edit to the wrong line, or fix a symptom instead of a root cause. None of that is disqualifying — a human developer would do the same — but it means you still need to read what it's proposing before accepting it. The show-your-work transparency isn't just a nice UX feature: it's a necessary safeguard.
And context still matters. If you're working in a large repo without a reference document that gives Claude the full context of your project, you'll spend the first part of every session re-orienting it. That investment is worth making. The sessions where I have solid context set up go measurably faster than the ones where I don't.
Where This Leaves Me
I wrote recently about how I use all three Claude tools — Chat for daily life, Cowork for project sprints, Code for active development. That breakdown still holds. But if I'm being honest about where most of my building happens now, it's in VS Code with Claude Code running.
The things I've shipped since making that switch — including the Reading Buddy app, site-wide security improvements, and a bunch of structural work that would have been too tedious to tackle manually — have changed my sense of what's feasible in an evening session. The ceiling moved. Not just a little.
If you've been using Claude in a browser and haven't tried it inside your editor, I'd strongly encourage you to. Not because it's the right tool for everything — it isn't — but because until you see what it does differently, you're working with an incomplete picture of what's possible.
The full inventory of what I've built using this system — 10 apps, 1 auto-publishing pipeline, 1 rebuilt website, 40+ blog posts — is its own story. But it started here: the moment a 40-file task took one session instead of a whole afternoon.