Obsidian Is the IDE, the LLM Is the Programmer, and the Wiki Is the Codebase

1. Ideas Are No Longer Enough in the AI Era

Several problems arise when using an IDE with AI plugins:

• A Q&A format: ask a question, get a code snippet, manually review the result.
• Communication history with the AI is hard to search.
• After multiple exchanges, the context accumulates and the AI loses focus; restarting a session wipes its memory, forcing you to teach it to code from scratch.
• A single requirement involves multiple microservices, and the code changes span more than one codebase.
• From the IDE's perspective, only code exists—there is no information about database structures or middleware.

IDEs can no longer meet the demands of code iteration in the AI era.

2. What Is Obsidian

https://obsidian.md/

Obsidian is a local-first, plain Markdown file-based knowledge management tool. Its core features:

• Local data: All notes are .md files on disk, not locked into any cloud service. They are available offline and fully under your control.
• Bidirectional links (Wiki-links): [[note-name]] connects fragments into a network. Any note can be reverse-queried to see "who references me."
• Graph view: Visualizes the reference relationships between notes, showing the shape of your knowledge network at a glance.
• Plugin ecosystem: An open plugin marketplace where the community has extended it into task management, calendars, Dataview queries, AI assistants, and more.
• Plain text = AI-friendly: Files are UTF-8 Markdown, which is a first-class citizen for AI—readable, writable, and diffable—without needing specialized plugin bridges like a traditional IDE.

Returning to the IDE + AI pain points listed above, Obsidian happens to address every single one:

IDE + AI Problem	Obsidian's Solution
Fragmented Q&A, results hard to review	Notes are persistent documents; every change the AI makes here leaves a trace and is traceable.
Communication history is hard to search	Full-text search + bidirectional links + tags; historical conversations become searchable knowledge assets.
Context accumulates, memory resets on session restart	Explicitly record project context in notes; in a new session, have the AI read the notes first to restore its memory.
A requirement spans multiple microservices	A single vault can hold notes for services A, B, and C simultaneously, with links connecting across services.
IDE only has code, no database/middleware perspective	A vault can hold code analysis, DB schemas, Kafka topics, and deployment topologies side-by-side.

In other words, Obsidian does not replace the IDE as an editor, but rather as its cognitive bearing layer—code is still written in the IDE, but all the context surrounding the code (design decisions, AI conversation history, database structures, cross-service call graphs) is moved into Obsidian for long-term accumulation.

3. Environment Setup

• Download Obsidian and enable plugins.
• Install the Claudian plugin: https://github.com/YishenTu/claudian

4. Theoretical Foundation

https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f

Karpathy's gist provides the theoretical origin for all the practices in this article. One sentence breaks it open (direct translation of the original text below):

"Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase."

That is, every note you write is not "documentation" but a codebase being maintained by the LLM—except it stores structured knowledge about the world, not executable instructions.

Open: Pasted image 20260715234540.png attachments/使用 Obsidian 作为 IDE/abb7ed0b8ab97cb4b1f0a13519e1e09a_MD5.jpg

4.1 Three-Layer Architecture

Karpathy divides the entire system into three layers, which correspond exactly to three types of files in a vault:

Layer	Definition	Correspondence
Raw sources	Immutable original materials, read-only for the LLM	Pasted meeting minutes, PDFs, code diffs, clipped articles
The wiki	Markdown pages generated/maintained by the LLM	Your analysis notes, decision records, concept pages
The schema	Configuration that turns the LLM into a "disciplined maintainer"	The vault root's CLAUDE.md

Key point: CLAUDE.md is not just a convenience tool to "avoid repeatedly telling the AI the project background"; it is the schema—it determines whether the LLM is a casual chatbot or a disciplined wiki maintainer.

4.2 Three Operations

The LLM performs three operations on this wiki:

1. Ingest — Intake new raw materials, update multiple wiki pages, and maintain cross-references.
2. Query — Search the wiki to synthesize answers; good answers are written back as new pages.
3. Lint — Check for contradictions, outdated statements, orphan pages, and missing links.

The first two are already being done by most people; Lint is a new capability—running a health check on the knowledge base, the same logic as running lint on code.

4.3 Why This Is Only Feasible Now

Humans once universally abandoned maintaining internal wikis because the maintenance cost exceeded the benefit—no one had the energy to continuously update cross-references, eliminate contradictions, and fill in links.

The LLM precisely fills this bottleneck: "Humans filter raw materials, specify analysis directions, and ask good questions"; the LLM bears all the bookkeeping work—a single ingest touches dozens of files at near-zero cost.

It's not that Obsidian got stronger; it's that the cost of wiki maintenance shifted from humans to the LLM.

5. How to Use It: Four Actions

5.1 One Project, One Vault + CLAUDE.md

Don't put everything in a single vault. Create a subfolder for each project, and place a CLAUDE.md in the vault root—tech stack, directory structure, commit conventions, common gotchas, and anything you'd repeatedly tell the AI at the start of a new conversation. Write it all down once. Claudian reads it automatically on startup; restarting a session no longer means starting from zero.

5.2 Typical Workflow for a New Requirement

Contrasting the past (open AI sidebar → ask a question → copy code → close → memory resets), the new path is:

1. Create a requirement note — Background, goals, constraints.
2. Have the AI read the context — Use [[]] to reference architecture, DB schemas, and historical requirement notes; Claudian reads them automatically.
3. Conversational analysis — Propose solutions, ask follow-ups, make decisions. Have the AI write key decisions back into the note.
4. Let the AI modify code directly in Obsidian — The plan in the note serves as the prompt.
5. Write back decisions — After coding, record "why this change was made / what pitfalls were hit / the commit hash" back into the note.
6. Next requirement — Old notes become the context for the new conversation.

Mindset shift: The AI's output is not a "disposable Q&A" but something to be precipitated into documentation.

5.3 High-Frequency Daily Actions

• @ file references — Directly inject a note into the conversation context; especially useful for cross-service alignment.
• Paste code into a note for the AI to modify — The result stays in the note, making it reviewable.
• Architecture Decision Records (ADRs) — One note per architectural decision, linked with [[]]. Six months later, you won't have to guess "why was it designed this way back then?"
• Daily notes for troubleshooting — Real-time thoughts go directly into the day's journal; the AI advances based on this stream.
• Graph view — See at a glance which modules have dense notes (core areas) and which are isolated (neglected areas).

5.4 Division of Labor with the IDE

Scenario	IDE	Obsidian + Claudian
Writing code, debugging, running tests	✅
Breakpoint debugging, profiler	✅
Requirements analysis, solution design		✅
Architecture docs, DB schema		✅
Long AI conversations, decision implementation		✅
Cross-service context linking		✅
Team knowledge sharing, retrospectives		✅

In one sentence: The IDE handles the "code"; Obsidian handles the "brain."

6. Real-World Case: A Two-Week Refactoring Span

A local project underwent six phases (P1-P6) of main body work plus four rounds of architectural refactoring, involving 15 technical decisions (D1-D15) over two weeks.

If done solely in an IDE, it would have been nearly impossible—memory reset with every new session, and repeatedly explaining the project background would have wasted half the time. Obsidian did five things here:

1. A single master plan note ran through the entire process — All conversations started from it, and the note itself was supplemented and revised by the AI.
2. All 15 decisions were written down — Each recorded "Background / Alternatives / Choice / Rationale," not left in the conversation.
3. Seamless continuation across sessions — On day seven, starting a new session required only one sentence: "Read this note and continue."
4. Commit hashes written back to notes — All 13 commits were registered; the notes directly became a changelog.
5. Final precipitation into CLAUDE.md — When the next round of modifications comes in, a new session immediately knows the current state.

Conversely, if done only in an IDE? The 15 decisions would be scattered across dozens of conversations, unsearchable and irreproducible; each new session would waste 20 minutes rebuilding context; the "design intent" between commits would be incomprehensible even to oneself three months later.

Conclusion: The larger the scale and the longer the span of the modification, the more obvious the leverage of Obsidian + Claudian becomes. This is not an optional aid; it is the infrastructure that makes "AI participation in long-cycle, complex modifications" feasible.

7. Hands-On: Running a Lint on Your Vault

Theory aside, let's return to the most practical action: periodically having the AI run a health check on your own vault. This is treating the wiki as a codebase for code review.

Two basic types of Lint are recommended, runnable with a single prompt. Running them on your own vault is what gives them meaning; what's provided here are templates + interpretation of results.

7.1 Dead Link Scan

Prompt (throw it directly at Claudian):

Scan the entire vault for all wikilinks of the form [[xxx]] where the target file does not exist. Sort by reference count and output the top 30. Ignore image embeds, content within code blocks, and Templater variables.

The resulting report can generally be divided into six categories:

Category	Typical Example	Handling
A. Daily note prev/next day jumps	[[2026-05-14_Thu]]	Normal template mechanism, can be ignored; or have Templater only render when the file exists.
B. Template placeholder misidentification	[[<% after_date %>]]	False dead link, ignore.
C. Clipping tool accidents	Commenter nicknames or URLs with [[]] on a webpage mistakenly converted to wikilinks	Batch search and replace to clean up.
D. Intended to link but never written	A concept repeatedly referenced but a note was never created for it	Clear action item—the more references, the higher the priority to write it.
E. Spelling / formatting errors	Trailing backslash, case mismatch	Fix directly like a bug.
F. Missing MOC index	A directory name is linked but no index page of the same name exists	Create the index page.

The value of Lint lies in Category D—high-frequency dead links equal concepts you yourself repeatedly felt "should have a note here" but never wrote. This is a concrete action list delivered by your knowledge network. Without running this scan, you have no idea how much debt you've accumulated.

7.2 Orphan Scan

Prompt:

Find orphan notes that are not referenced by any other note via wikilink. Exclude daily notes, entry files, CLAUDE.md, and empty notes. Sort by file size, with larger files first.

After running this, you'll typically see three patterns:

• Clusters of orphans at scale — An entire directory (chapter notes for a book, a series of articles on a topic) is completely orphaned → Missing a MOC index to string the series together. This is not a "add one link" problem; it's a hole in the knowledge organization structure. Such structural problems are only visible by running Lint; you'd never discover them by opening a single note.
• Orphan entry files — Files with names like entry points (xx Overview, xx Dashboard) but with zero inbound links → An entry was built but no one walks through it; it needs to be explicitly referenced in other notes.
• Empty / single-line notes — Untitled, or only a title was written with no follow-up → Delete directly.

7.3 The Payoff of Regular Linting

A single Lint run yields four types of concrete output:

• Clear next actions: High-frequency dead links = a list of core notes that should be created.
• Exposure of structural problems: Clusters of orphans = missing MOC indexes.
• Data hygiene: Clipping accidents, spelling errors, empty notes.
• Self-audit of entry files: A name that looks like an entry but has no inbound links = a dead-end entry.

Recommended cadence: Once a month, or after every bulk dump of material into the vault.

A vault without Lint, after two or three years, is basically a large graveyard—link density looks high, but the vast majority are dead links and isolated islands. Conversely, by consistently running Lint, the vault remains perpetually "alive"—every link is reachable, every node is referenced. This is the Lint Karpathy described.

8. Summary

• The IDE is the code editor. It hasn't changed and remains useful.
• Obsidian is the cognitive bearing layer, filling in the missing half of the IDE—design intent, AI conversation history, cross-service context, and decision threads.
• Claudian is the glue, enabling the AI to directly read and write your knowledge network, no longer a "disposable Q&A machine."
• CLAUDE.md is the schema, upgrading the LLM from a chatbot to a disciplined maintainer.
• The Lint operation is the core self-maintenance action, preventing the vault from rotting over the long term.

Combined, you truly possess an "IDE for the AI era"—not a collage of AI stuffed into an IDE sidebar, but a development workflow redesigned around knowledge organization.