I Had All the Tools. Nothing Worked.
"I want to use AI to make my development faster."
With that thought, I installed every tool I'd heard about — Cursor, Claude Desktop, Obsidian, GitHub. I configured MCP connections, grabbed API keys, designed directory structures, and mapped out workflows.
Then I tore it all down and rebuilt it. Three times.
Looking back, the reason is clear. I started with tools before deciding what I actually needed to do.
This article isn't a setup guide. It's the story of three configurations I actually lived through — what broke, what clicked, and why each transition happened. If you've installed a bunch of AI tools and still feel like you're not getting the most out of them, this might resonate.
Building something with AI tools? I built Pure Mark Annotate — a PWA image annotation tool — using the exact workflow described in this article. Zero friction, browser-based. The tool and the process are inseparable.
The Two Configurations Compared
| Config A (Initial) | Config B (Current) | |
|---|---|---|
| Editor | Cursor | Cursor |
| AI | Claude Desktop | Claude Code |
| Knowledge mgmt | Obsidian (via MCP) | Obsidian (direct file access) |
| Research & writing | Claude only | Gemini API integration |
| Git/GitHub | Manual | Directly from Claude Code |
| Persistent settings | User Preferences | CLAUDE.md |
| Monthly cost | Pro $20 | Pro $20 (same) |
Bottom line: The tool choice mattered less than how clearly I'd defined my goal.
The Drift Before Purpose
Phase 0: "I want AI to make development faster" (vague)
That was the starting motivation. Combine Cursor with Claude Desktop and something amazing will happen, right?
At this stage, I couldn't articulate what to make faster. So even after installing everything, I kept thinking, "Okay, now what?"
Phase 1: "I want to accumulate knowledge in Obsidian" (somewhat specific)
Knowledge from AI chat sessions disappeared every time the session ended. That felt like waste. "What if conversations automatically accumulated in Obsidian?" — that was the first real goal.
→ Built Config A with Claude Desktop + mcp-obsidian
Phase 2: "I want to automate article writing too" + "I want AI to handle Git" (specific)
Not just storing knowledge — I wanted to write articles from it, push to GitHub, and publish to Zenn (a developer blogging platform). Claude Desktop can't run terminal commands, so I hit a wall.
→ Migrated to Config B with Claude Code + Gemini + GitHub
Every time the goal got sharper, the required setup changed. That's why I rebuilt three times.
Config A: Cursor + Claude Desktop + Obsidian
Goal at the time: "Chat with AI while saving notes to Obsidian"
What Worked
Setup was intuitive. Claude Desktop is install-and-login. Configure MCP server connections through the GUI, enable Obsidian's local REST API plugin, and Claude Desktop can read/write Obsidian files. Simple.
The chat UI is approachable. Even non-engineers can start immediately. "Save this to Obsidian" — and MCP handles it.
What Broke
Problem 1: Files created in WSL were invisible to Obsidian
This was the first and biggest trap.
# Created a file from WSL
echo "# Test" > ~/vault/test.md
# → Obsidian (Windows side) can't see it!
The reason was simple: before configuring automount, WSL local paths and Windows-side Obsidian paths are completely different locations. The file exists, but Obsidian can't see it.
WSL: ~/vault/test.md ← file created here
Windows: C:\Users\...\Obsidian\ ← test.md doesn't exist here
"File exists != Obsidian can see it." It took embarrassingly long to figure that out.
Problem 2: MCP connections were flaky
File operations through MCP worked... when they worked. Depending on when Obsidian's REST API plugin started up or the MCP connection state, writes would sometimes fail silently. "Saved successfully" — but nothing was saved.
Problem 3: Re-explaining rules to AI every session
Claude Desktop has User Preferences for persistent settings, but it has limits. I kept having to re-explain project-specific rules ("Use MCP tools for Obsidian writes," "The path is X") every session.
I ended up writing rules like this in User Preferences:
# Obsidian Rules (Required)
- USE mcp-obsidian:obsidian_append_content
- DO NOT create files in WSL local paths
- Reason: Without automount, files end up in the wrong location
It worked, but "teaching AI the rules every time" was itself the inefficiency I was trying to eliminate.
Problem 4: Terminal access requires stacking more MCPs
Claude Desktop can't run terminal commands on its own. You can add a Local Shell MCP server or GitHub MCP server, but each new capability means another MCP in your config.json. Obsidian needs mcp-obsidian, terminal needs Shell MCP, GitHub needs GitHub MCP...
The more connections, the more instability. I started spending time figuring out which MCP was running and which had silently dropped.
Claude Code has file operations, terminal, and Git built in natively. That difference became decisive as the MCP stack grew.
The original goal — "chat with AI while taking notes" — was well served. But when the goal shifted to "automate the entire dev workflow," the MCP-stacking approach hit its ceiling.
Config B: Cursor + Claude Code + Gemini + Obsidian + GitHub
The goal changed: "Run my entire dev workflow through AI"
- Write code
- Run tests and builds
- Accumulate knowledge in Obsidian
- Write articles and publish them
- Manage GitHub issues and PRs
All of this, from one environment, in conversation with AI.
What Worked
1. Direct Obsidian Access — Finally Stable
Claude Code runs inside WSL. After configuring automount (bind mount), it can Read/Edit/Write directly to ~/vault/. No MCP intermediary means no flaky connections.
# Config A (Claude Desktop)
Claude → MCP connection → Obsidian REST API → file operation
↑ This was unreliable
# Config B (Claude Code)
Claude Code → Read/Edit/Write → ~/vault/
↑ Native WSL operation. Stable.
2. CLAUDE.md — The Project's Memory
This was the single biggest improvement in Config B.
Place a CLAUDE.md file in your project root, and Claude Code automatically reads it at the start of every session.
# CLAUDE.md (excerpt)
## Obsidian Rules
- Use Read/Edit/Write tools for direct file access (preferred)
- Use mcp-obsidian only as fallback
## Article Writing Workflow
- Gemini research → outline review → Gemini draft → Claude review → publish
## GitHub Rules
- Always verify remote is private before git push
Config A's User Preferences were global — applied to every conversation. CLAUDE.md is per-project and version-controlled in Git.
The "re-explaining rules every session" problem was solved at the root.
3. Terminal Access — Just There
# Tell Claude Code "run the tests"
npm test
# Git — directly
git add . && git commit -m "feat: new feature" && git push
# GitHub CLI — directly
gh pr create --title "New feature" --body "Summary..."
Chat and terminal are unified. The development flow never breaks when collaborating with AI.
4. Claude + Gemini: Division of Labor
Instead of making Claude do everything, I split responsibilities by strength.
| Role | Owner |
|---|---|
| Research, drafting, image generation | Gemini API |
| Quality review, editorial judgment | Claude (editor-in-chief) |
| Code, Git operations | Claude Code |
| Knowledge accumulation | Obsidian (direct access) |
When writing an article, Claude orchestrates the loop: "Have Gemini research → review the outline → have Gemini draft each section → Claude reviews." Automated.
What Broke
Problem 1: Automount Configuration — Trial and Error
File sharing between WSL and Windows required automount (bind mount) setup. Get the /etc/fstab entry wrong and WSL won't boot. Tread carefully.
# Added to /etc/fstab (get it wrong and WSL won't start)
/mnt/c/Users/.../Obsidian/auto-empire ~/vault none noauto,x-systemd.automount,bind,... 0 0
I tried symlinks first, but some AI agents refused to write through symlinks. Ended up with automount.
Problem 2: Learning to Write CLAUDE.md
There's no established best practice for writing CLAUDE.md. I initially stuffed too much in, which made Claude Code's behavior erratic.
Through trial and error, I landed on these principles:
- Keep rules short and explicit (move long explanations to separate files)
- Include path mapping tables (so Claude Code doesn't guess wrong)
- State "don't do this" rules explicitly (e.g., "Never write code directly via GitHub API")
- Define trigger commands (e.g., "write an article about X" → auto-launches the workflow)
Problem 3: CLI Takes Getting Used To
Compared to Claude Desktop's "type in a chat window and send" experience, Claude Code is terminal-based. Even inside Cursor's terminal, there's an initial "where do I talk to this thing?" moment.
That said, Cursor's Claude Code extension provides an in-editor UI, so it's mostly a familiarity issue.
This is the workflow I used to build Pure Mark Annotate. Claude Code orchestrating the dev loop, Obsidian accumulating decisions, Gemini handling research. The same system described here, running in production.
Your Goal Determines Your Setup
After rebuilding three times, I'm certain of one thing:
The first step isn't setting up your environment. It's articulating what you want to do.
"Claude Code or Claude Desktop — which is better?" has no universal answer. It depends on your goal.
Recommended Config by Goal Clarity
| Your Goal | Recommended Setup | Why |
|---|---|---|
| Chat with AI | Claude Desktop alone | Sufficient. No extra setup |
| Chat + save notes to Obsidian | Claude Desktop + mcp-obsidian | One MCP connection does it |
| Dev + knowledge accumulation | Cursor + Claude Code + Obsidian | Direct file ops are stable |
| Automate the full dev workflow | Cursor + Claude Code + Gemini + Obsidian + GitHub | All-in. High setup cost |
The key: start from the top row and work down.
If you build the full-stack config first, you'll get buried in setup and lose sight of your actual goal. Wait until "what's missing" becomes obvious, then add the next layer.
"Starting With Tools" Leads to Config Hell
My failure pattern looked like this:
1. "Claude Code is amazing" → Install
2. "MCP can connect to Obsidian" → Configure
3. "Gemini API is available too" → Add it
4. "Wait, what was I trying to do...?"
Starting from the goal, it looks like this:
1. "I want to automate writing articles through to publishing" ← Goal
2. "Research with Gemini, editorial with Claude" ← Role split
3. "I need terminal access → Claude Code" ← Tool selection
4. "Knowledge in Obsidian → need WSL integration → automount" ← Env setup
You arrive at the same tools, but in reverse order. When you start from the goal, each tool has a clear "why," and setup decisions stop being ambiguous.
Summary
Before (tool-first, no goal):
- Install tools, drown in config
- "What was I doing again?" on repeat
- Rebuilt the environment 3 times
After (goal-first, then config):
- Say "write an article" and the pipeline runs from research to publication
- CLAUDE.md serves as the project's persistent memory
- Knowledge accumulates automatically from conversations
The first thing you should do isn't installing the latest tool.
It's writing down "What do I want AI to do for me?" in a notebook.
Once that's clear, the right setup reveals itself.
Next Steps
- Write down "things I want AI to handle" in bullet points — on paper or in Obsidian
- Pick the config that matches your current goal clarity from the table above
- Add the next tool only when you feel what's missing
Very few people need the full-stack setup. Start minimal.
References
Pure Mark Annotate — Zero-friction image annotation in your browser
Top comments (0)