Two months ago, I wrote about over-engineering my note-taking system and then simplifying it down to three folders in Obsidian. That post ended with what I thought was the final answer: Inbox, Projects, Knowledge. Let AI handle retrieval. Keep it simple.

I still believe all of that. But something shifted in the weeks after, and it went beyond note-taking.

It started with notes. I’d be deep in VSCode, working on code or writing, and I’d need to capture a thought. So I’d alt-tab to Obsidian, wait for it to load the vault, navigate to the right folder, create a note, type the thing, then switch back to VSCode. Thirty seconds of friction, repeated a dozen times a day. One day I just… stopped switching. I opened my Obsidian vault as a VSCode workspace and created a markdown file directly in the editor. Then another. Then I realised I’d been writing notes in VSCode for two weeks without opening Obsidian on my laptop at all.

Then I noticed the same pattern everywhere else. I needed to review a PDF. Alt-tab to Preview. I needed to check a CSV export. Alt-tab to Excel. I needed a terminal. I already had one in VSCode, but I still opened a separate Terminal.app out of habit. I was bouncing between a dozen apps when one of them could handle most of the work.

The system I’d carefully designed wasn’t competing with a better system. It was competing with the path of least resistance: the tool I already had open. And that tool kept being VSCode.

The Tool You Already Have Open

Here’s the uncomfortable truth about productivity apps: the best one is the one you’ll actually use. And the one you’ll actually use is the one that’s already on your screen.

As a developer, I spend hours inside VSCode every single week. My terminal is there. My git is there. My file tree is there. My search is there. My AI assistant is there. The muscle memory is there. I know the keybindings in my sleep. I can multi-cursor edit, regex search across files, and split panes without thinking.

So why do I keep leaving it? Why do I open a separate app to read a document, check a data file, or write three sentences of plain text when VSCode can handle all of them?

Habit. That’s it. Not because those apps are better at their specific jobs, but because I never questioned whether VSCode could do them.

The insight isn’t that VSCode is better than any dedicated app. It isn’t. The insight is that context switching has a cost that no feature set can overcome. A good-enough experience inside the tool you’re already using beats a perfect experience that requires you to leave it. Every alt-tab breaks flow. Every app switch costs a few seconds and a little bit of whatever you were holding in your head.

I started thinking about this the way the famous AI paper put it: attention is all you need. In productivity, familiarity is all you need. The tool that already has your attention, your muscle memory, your mental model, that’s the tool with the lowest friction for any task.

More Than a Code Editor

Once I started paying attention, I realised how much VSCode had quietly grown beyond writing code.

PDFs. I review research papers, insurance documents, contracts. I used to open them in Preview or a browser tab. Now I open them in a VSCode tab. Same window, same split-pane layout. I can have the PDF on the left and my notes about it on the right. No app switching.

CSVs and data files. I regularly check data exports, log files, configuration dumps. There are extensions that render CSVs as proper tables with column sorting, filtering, and search. It’s not Excel, but for a quick review of what’s in a file, it’s more than enough, and it’s already in my editor.

Writing. Blog posts, documentation, READMEs, emails I want to draft carefully. This post was written entirely in VSCode. Markdown preview on one side, source on the other. Spell-check extension running. Git tracking every revision. I’ve tried dedicated writing apps. They’re beautiful. But they’re another window, another app, another context to maintain.

Terminal workflows. Scripts, git operations, quick SSH sessions, running automation tools. The integrated terminal means I never need to leave VSCode to interact with the shell. I have multiple terminal panes, split however I need them, all within the same window where I’m editing the files those commands affect.

Reviewing anything, really. JSON configs, YAML pipelines, XML feeds, log files, diffs. VSCode handles all of these with syntax highlighting, folding, and search. The number of times I used to open a separate app to “just quickly look at” a file, only to lose five minutes to context switching, was absurd in hindsight.

None of these are groundbreaking individually. Each one is just “good enough.” But good enough across ten workflows, all in one window, adds up to something that dedicated apps can’t match: unbroken focus.

The Extensions That Complete It

VSCode can do most of this out of the box. Markdown rendering, file search, git integration, split panes, integrated terminal, syntax highlighting for dozens of formats: all built in. The gap between “code editor” and “everything workbench” is smaller than you’d think, and a handful of extensions close it entirely.

The extensions I rely on fall into a few categories.

Document rendering. Viewing PDFs, CSVs as sortable tables, image previews — all inline. Not trying to replace dedicated apps, just removing the alt-tab for quick checks.

Knowledge linking. Wiki-style [[double bracket]] linking between notes. Click a link, jump to the note. Create a link to a note that doesn’t exist yet, and it gets created when you follow it. This is the one feature that makes a folder of markdown files feel like a knowledge base instead of a directory listing.

Writing comfort. Spell-checking, table formatting, auto-completion for links and headings, table of contents generation, keyboard shortcuts for bold/italic/checkbox. Small quality-of-life improvements that remove the friction of writing in raw markdown. These matter when VSCode is your writing app, not just your coding app.

Task surfacing. Scanning for TODOs, FIXMEs, and other markers across your entire workspace. When you scatter action items across meeting notes, project documents, and code comments, you need something that pulls them into a single view.

That’s it. Maybe six or seven extensions total. The rest of what you need, git tracking for version history, integrated terminal for scripting, powerful multi-file search, side-by-side preview, extensions sync across machines, is already part of VSCode.

Compare that to my old setup: Obsidian with community plugins for git sync, AI integration, template insertion, Kanban boards, calendar views, and dataview queries. Preview for PDFs. Numbers for CSVs. A separate terminal app. I was spreading my attention across a dozen windows when one could handle it all.

The AI Chat Panel That Ties It Together

This is the part that makes the whole thing click. VSCode now has an AI chat panel built in. Open it on the side, ask a question about your workspace, get an answer grounded in your actual files. It’s just there, like the terminal or the file tree. Another native part of the editor.

I have a folder of markdown files, my knowledge base, open as a VSCode workspace. I open the chat panel and just… talk to my notes:

• “What were my key decisions on the auth migration project?”
• “Summarise everything I’ve written about rate limiting.”
• “Find any contradictions between my architecture notes and my implementation notes.”
• “Draft a status update based on my notes from this week.”

It searches, reads, cross-references, and synthesises. No copy-pasting into a separate chat window. No uploading files to an external AI service. No switching apps. Just a panel on the side of the editor I’m already in.

Remember the manifest system from my previous post ? I built MANIFEST.md files, simple tables listing every file with a one-line description, so AI assistants could navigate my vault without scanning everything. Here’s the thing: the chat panel leverages those manifests elegantly. It reads the manifest, instantly understands the structure of my knowledge base, and uses it to give more precise answers. The manifest isn’t redundant. It’s genuinely useful. A lightweight index that an AI can read in seconds turns a folder of markdown files into a navigable knowledge graph.

Inline chat is the other piece. Highlight a paragraph in my notes, say “expand this into a full section” or “turn these bullet points into a status update email.” The AI operates on my notes the same way it operates on my code: in-place, with full context. It’s convenient in the way that only native integrations can be.

I’m also rethinking how I write instructions for AI assistants. In my previous post, I maintained separate instruction files: CLAUDE.md for Claude Code, .github/copilot-instructions.md for Copilot, and AGENTS.md as a universal format. I’m increasingly leaning towards consolidating everything into AGENTS.md. It’s the most portable format, any AI coding agent can read it, and maintaining three files with overlapping content is exactly the kind of over-engineering I was trying to escape. One file. One source of truth. Let the tools adapt to it.

I wrote about how AI assistants are already better than me at finding and summarising my own notes . That’s still true. The difference is that now the AI lives inside the same window where I write the notes, one click away. No integration required. No setup. It’s just another panel.

Cloud Dev Environments: The Same Face Everywhere

The one limitation of “just use VSCode” is that it ties your workflow to one machine. Cloud dev environments remove that constraint.

I use Codespaces: a full Linux environment in the cloud, accessible from any browser or local VSCode instance. It looks and feels exactly like my local editor because it is my editor, just running on remote hardware. Extensions, settings, keybindings — everything travels with me.

The mental shift: a cloud dev environment isn’t just for coding. It’s a persistent, portable workspace for everything. My notes, my automation scripts, my agentic workflows, my MCP servers, all living in a git repository, all accessible from any device with a browser. Open the workspace on my laptop at home, pick up exactly where I left off on my work machine, or check something quickly from my iPad. Same workspace. Same state. Same familiar face.

You could achieve something similar with a VPS or a home server with Tailscale. I chose a managed environment because I didn’t want to be a sysadmin for my personal workspace. But the infrastructure choice matters less than the point: VSCode is the constant. Whether it’s running locally or in the cloud, it’s the same interface, the same muscle memory, the same tool.

Obsidian Still Has Its Place

I haven’t deleted Obsidian. I use it every day, on my phone.

Mobile capture is genuinely where Obsidian excels. The iOS app is fast. It syncs reliably via iCloud. The quick-capture widget lets me jot something from the lock screen. When I’m walking the dog and a thought hits, I’m not opening a cloud workspace on my phone. I’m opening Obsidian and typing three sentences into my Inbox folder.

The workflow is simple: capture on mobile with Obsidian, process on desktop in VSCode. iCloud keeps the files in sync. When I sit down at my computer, anything I captured on my phone is already there in my workspace, ready to be expanded, linked, or filed.

This isn’t about being anti-Obsidian. Obsidian is a beautiful piece of software and the community around it is remarkable. But I’ve stopped pretending I need the same tool on every device. I need the right tool for each context. On my phone, that’s Obsidian. At my desk, it’s VSCode. The notes are just markdown files in folders, so the tool doesn’t matter. The files do.

And to be honest, VSCode isn’t perfect for this either. It can get sluggish with too many extensions running. Large workspaces with thousands of files take longer to index than a dedicated tool like Obsidian. And the whole argument only works because I’m a developer who already lives in a code editor — if you don’t already have the muscle memory, the learning curve is real. This isn’t a universal recommendation. It’s a recognition that the tool I already know well happens to be good enough at everything else.

The Lesson

I keep arriving at the same conclusion from different directions. In the over-engineered note-taking post , it was: stop optimising the system and start using it. This time it’s the corollary: stop searching for the perfect tool for each job and start using the one you already have.

Developers have a blind spot here. We evaluate tools the way we evaluate frameworks: feature comparisons, plugin ecosystems, community size, roadmap promises. We install a dedicated app for notes, another for PDFs, another for data files, another for writing, and then wonder why we spend half our day switching between windows. It’s not a tooling problem. It’s a habit problem. And habits form around the path of least resistance.

For me, that path goes through VSCode. It’s open all day. It handles text of every kind beautifully. The AI chat panel gives me search and synthesis across my workspace. Git gives me version history. Cloud dev environments give me portability and compute. Extensions fill the small gaps. And I never have to leave the window I’m already working in.

Your path might be different. Maybe you’re a JetBrains user and the same argument applies to your IDE. Maybe you’re a terminal person and Neovim with some plugins is your answer. The specific tool matters less than the principle: the best workflow is the one that lives where you already work.

Two months ago I wrote that the goal isn’t a beautiful system, it’s a quiet mind. I still believe that. But now I’d add: a quiet mind comes from not having to think about your tools at all. When your notes, your documents, your terminal, your AI assistant, your entire workflow is just another tab in the editor you’re already using, that’s when you stop managing your setup and start doing actual work.

In AI research, attention is all you need. In productivity, familiarity is all you need. And for developers, the familiar face is usually the one staring back at you from your code editor.