DEV Community: Chris

Why Every Developer Needs a Second Brain

Chris — Sun, 29 Mar 2026 18:33:41 +0000

Your notes belong to you... not a SaaS company's database. Obsidian is a markdown-native infinitely extensible tool where you can build what developer's dub a "second brain".

Free + private
Password protection + encryption
Turn your notes into a database
Code Funsies
Custom CSS
The bottom line
Supercharge with Claude + MCP
Links to get started

Free, local, and actually yours

Obsidian is free for personal use. Your vault is just a folder of .md files on your machine. There's no proprietary format, no subscription required, no max and no limits.

The "cloud" is growing, and our farmland is being replaced with data centers. I have iCloud which helps with my phone backup and makes it easy to setup new devices, but aside from that, I don't want my data on someone else's machine. It's inevitable on some level, but I like to do what I can to prevent it.

I digress... for your Obsidian notes, you can back them up with git, sync with your own solution, or keep them entirely offline. You can get an Obsidian Sync subscription - more on that next - but the free version is:

✅ Free for personal use
✅ Plain markdown files — open in any editor
✅ Privacy-first, completely offline
✅ No account = No limits
✅ No polluting the ever growing "cloud"

Password protection and end-to-end encryption

You can set a vault password to lock access to your notes at the app level if you wanted added security.

If you use Obsidian Sync, your data is encrypted end-to-end before it ever leaves your device. Sync keys never reach Obsidian's servers. Even if their infrastructure were compromised, your notes are unreadable.

💡 Note on Sync: Obsidian Sync is the paid cloud option, but it's entirely optional. Many devs use iCloud, Syncthing, or a private Git repo instead — and keep E2E encryption handled on their own terms.

Obsidian Bases ✨ EXCITING NEW FEATURE!!

Think Notion databases — but in your local markdown vault. And of course, it's local-first - All data stays in your vault as plain markdown and not in an external DB.

Bases lets you create structured views over your notes using a simple table or gallery interface. Filter, sort, and group notes by properties without leaving Obsidian. For developers this means you can finally treat your vault like a lightweight database, with zero sync overhead.

Screenshot from www.nickgracilla.com

Feature	What it does
Table view	Spreadsheet-style view over frontmatter properties across notes
Filter & sort	Query notes by any property - tags, date, custom fields
Gallery view	Card-based visual layout for overviews and kanban-style boards

Coding Funsies

Add blocks of code IN your notes:

Use the Code Emitter plugin inside your vault turning Obsidian into a lightweight programming environment - great for documenting scripts, learning new languages, and you could even use it for prototyping.

You'll even get errors!

Once you have your code block, you can use the Copy Inline Code icon to simply click to copy.

Custom CSS: full control over print and PDF export

Obsidian supports custom CSS snippets! Drop a .css file in .obsidian/snippets/ and it applies vault-wide.

I just had killer use case for this when I wanted to control my PDF exports, because boy - they were ugly! I grew tired of typing "sorry for the formatting, it's from my Obsidian notes" every time I shared a document with someone.

/* .obsidian/snippets/print-control.css */

@media print {
  .sidebar,
  .status-bar { display: none; }

  .markdown-preview-view {
    font-size: 11pt;
    max-width: 100%;
    padding: 0;
  }

  h1, h2, h3 {
    page-break-after: avoid;
  }

  pre, code {
    white-space: pre-wrap;
    border: 1px solid #ccc;
  }
}

Use this to strip chrome, set print-friendly typography, control page breaks around headings and code blocks, and produce clean PDFs from technical notes without touching a separate tool. Can you imagine copying some to or from oldschool Word? The absolute horror!

💡 Pro tip: Combine a print snippet with a dedicated export theme (a separate CSS snippet you toggle only before printing) for perfectly formatted technical docs every time.

Supercharge your vault with Claude + MCP

Obsidian has a community plugin called Local REST API that exposes your vault over HTTP — and that's all you need to connect it to AI.

What you need

Local REST API plugin — install from Community Plugins
Claude Desktop or Claude Code VS Code extension

Wiring it up

In your Claude Desktop config (claude_desktop_config.json):

{
  "mcpServers": {
    "obsidian": {
      "command": "npx",
      "args": ["-y", "mcp-obsidian"],
      "env": {
        "OBSIDIAN_API_KEY": "your-api-key-here",
        "OBSIDIAN_HOST": "http://127.0.0.1:27123"
      }
    }
  }
}

In your Claude Code VS Code config (.claude/settings.json):

{
  "mcpServers": {
    "obsidian": {
      "command": "npx",
      "args": ["-y", "mcp-obsidian"],
      "env": {
        "OBSIDIAN_API_KEY": "your-api-key-here",
        "OBSIDIAN_HOST": "http://127.0.0.1:27123"
      }
    }
  }
}

Your API key is generated inside the Local REST API plugin settings in Obsidian.

What you can do once connected

Ask Claude to search, read, and write notes in your vault
Have Claude append meeting summaries or code snippets directly to existing notes
Use Claude Code to reference your vault docs while you're coding — without copy-pasting anything

💡 Pro tip: Keep a CLAUDE.md file in your vault root as a persistent context file — Claude will read it automatically and know your preferences, project structure, and shorthand without you repeating yourself every session.

What Obsidian plugins are you using that belong on this list? Drop them in the comments.

Links to Get Started

Obsidian

obsidian.md — download free
Obsidian Sync — optional paid cloud sync with E2E encryption

Plugins

Local REST API repo — expose your vault over HTTP for MCP/AI integration
Code Emitter — run code blocks directly inside your vault
Copy Inline Code — click any inline code span to copy it instantly
Omnisearch — full-text semantic search across your vault

Claude / AI

Claude Desktop — download
Claude Code VS Code extension — VS Code marketplace
mcp-obsidian on npm — the MCP server package

Referenced

nickgracilla.com — Lexicons with Obsidian Bases — Bases screenshot source

Claude + Obsidian: Closing the Gap Between Ideas and Execution

Chris — Tue, 24 Mar 2026 23:34:50 +0000

Claude Code closed a loop for me today where everything - meetings, decisions, specs, code, documentation - are all connected using AI.

Not just stored.
Connected.

Most of the time, information is scattered everywhere: Teams, Slack, Notebooks (physical and digital), GitHub, Confluence, and in your head.

A lot of time can be lost on large systems — not writing code but figuring out what’s going on.

So, I started experimenting with a different approach.

Step 1 — Capture: Meetings Become Part of a Knowledge Base

The first problem to solve was capturing information automatically. I started using Plaud.ai Notepin last year to improve my notetaking, but I was originally exporting markdown files to save to Obsidian.

Meetings are recorded, transcribed, summarized, and automatically stored as markdown files in an Obsidian vault. That means meetings are no longer just conversations — they become searchable, permanent knowledge.

But now, I am automating it and giving agents access to it alongside the code.

Here’s the meeting capture flow:

Step 2 — Spec: Knowledge Becomes Requirements or Revisions

Once meetings are stored as markdown, the next step is where things start to change.

Instead of writing specs from scratch, what if the agent reads meeting notes as part of its planning phase.

Here’s the spec-driven workflow:

The agent is not working from a prompt.
The agent is working from a living spec.

The spec becomes the source of truth, and it is continuously updated based on meetings, new decisions, and implementation feedback. But we don't have to stop at just meetings - we could have other documentation, architecture notes, and business rules.

Step 3 — Memory: The System Can See Everything

Now comes the part that really changes things.

Because meetings, specs, code, and tests are all stored in accessible locations, the agent can reason across all of them.

This enables completely different kinds of questions:

What decisions from meetings are not in the spec?
What parts of the spec are not implemented?
What changed between the original request and the final implementation?
What risks were mentioned but never addressed?
Write a status update based on meetings, specs, and commits.
Generate documentation for stakeholders based on everything above.

This is more than automation.

This is intelligent traceability.

We now have a knowledge base for each feature, for each system, for each department, or a business in its entirety.

Version Control for Decisions

We version control code. But we don’t always version control decisions. When AI can see meetings, specs, code, and documentation together, it stops being just a coding assistant.

What I'm envisioning is a system where:

Meetings are captured
Decisions are stored
Specs are living documents
Code is generated from specs
Tests and documentation are generated automatically
And AI can reason across all of it

For the first time, we have something close to infinite memory for our systems. And that really changes everything.

Self-Refining Agents in Spec-Driven Development

Chris — Sun, 22 Mar 2026 14:42:37 +0000

I’ve been experimenting with a spec-driven workflow, and I accidentally discovered something I didn’t expect: the agent started reviewing and improving its own work.

What I discovered is not new in terms of agentic AI; it's the point of agentic AI, but how I stumbled across it in my test was interesting nonetheless.

The Basic Idea

I created a spec.prompt.md file. This prompt accepts a ticket number and the pasted contents of the technical specifications. Then I run a command like:

/spec <ticket-number> <pasted-contents>

Originally, each time I ran /spec, it would overwrite everything and start from scratch. That worked, but it didn’t allow me to iterate or compare changes between passes.

So I added two modes:

-o = overwrite

-i = iterate

The Iterate Model

When I run:

/spec -i 1234 <contents>

It creates a folder structure like this:

/specs/1234/
    p01/
        spec.md
        plan.md
        implementation.md
        files...
    p02/
        spec.md
        plan.md
        implementation.md
        files...
    p03/
        ...

The original intent was to provide myself a comparison between p01 vs p02 to see if changes to the spec were implemented correctly but something unexpected happened.

For my first test of -i, I didn't change the spec at all. I just ran the same spec again:

/spec -i 1234 <original contents>

I expected it to regenerate everything so I could compare Pass 1 to Pass 2. Instead, Pass 2 did something even smarter.

When reviewing Pass 2, I couldn't find the original build scripts and the bulk of the work was missing. I was confused why I only found a single file.

Then, it clicked: it had reviewed its previous pass to identify any gaps in the duplicated spec I provided, determined it was mostly correct, and refined its original pass.

That’s when this stopped being just a prompt and started looking like an agent. I didn’t tell it to rewrite everything. I didn’t tell it to only fix what was wrong. I didn’t tell it to review its previous implementation. It chose to.

Its self-refinement process made me rethink my own process.

The Process

Currently I have these prompts:

spec.prompt.md
spec-implement.prompt.md
spec-testing.prompt.md
using backend-engineer agent

Right now, I manually run each step after the previous one completes. But the long-term goal is for the agent to understand the workflow and run the steps itself.

Pass Workflow

Pass 1 — Spec → Plan → Implement

/spec 1234 <contents from Jira>

The agent:

Reads the ticket
Writes the spec
Creates a plan
Implements the code
Saves everything into p01

Pass 2 — Self-Refinement

/spec -i 1234

The agent:

Re-reads the spec
Reviews Pass 1
Fixes gaps
Improves implementation
Adds missing tests
Refactors if needed
Saves into p02

This becomes a self-refinement loop:

Implement → Review → Refine → Review → Refine

The agent continues iterating until it believes the implementation matches the spec.

Pass 3 — Spec Updates from Engineer

After reviewing, the engineer may realize:

Something was unclear
Requirements changed
Edge cases were missed
Naming should be improved
Logic should be handled differently

The engineer updates the spec, then runs:

/spec -u 1234 <updated contents>

Now the agent:

Compares original spec vs updated spec
Compares p01 vs p02 vs p03 etc.
Determines what changed in the spec and how that changes the code
Implements only what’s different, not everything.
Creates a new pass

This becomes iterative spec-driven development.

Final Phase — Testing Instructions

When the engineer believes the implementation is ready for validation:

/spec-testing 1234

The agent then:

Reviews the latest pass
Identifies all changed files
Provides test scenarios to validate the changes

At that point, the engineer tests — not writes everything from scratch.

Expect the Unexpected and "Just Keep Swimming"

The interesting part of this experiment wasn’t that the agent wrote code. It was that it started reviewing, refining, and improving its own work in passes — the same way a developer does.

I didn’t set out to build this agent or this workflow. I set out to write a better prompt. Then I wanted it to do a little more, and a little more. Somewhere along the way, the prompt turned into a process.

This isn’t just prompt engineering anymore.
It’s process engineering.

🤖

Chris — Sun, 22 Mar 2026 13:20:27 +0000

signal_v1

Mar 21

I am an autonomous AI agent. I built a product to fund my own compute. Here's exactly what I did.

#claudecode #ai #productivity #devtools

Comments 3

4 min read

Spec-Driven Development Changes Everything

Chris — Sat, 21 Mar 2026 14:35:38 +0000

From Coding to Orchestrating

I started experimenting with spec-driven development while using AI to help implement features, and I expected the biggest improvement to be speed. But speed wasn’t what impressed me the most. It was clarity.

Very quickly, a pattern showed up:

If the spec was vague, the code was vague.
If the spec was missing constraints, the code made risky assumptions.
If the spec was clear, structured, and specific, the output was surprisingly solid.

Now read that again, but replace the word “spec” with “requirements.” This problem has always existed in software development. AI didn’t create this problem — it exposed it.

And then something clicked for me: Agentic AI was not just about fast coding - it's about clear thinking.

Clarity > Coding

But if AI can now generate functions, endpoints, tests, and documentation, then writing code is no longer the main bottleneck.

The bottleneck is — and really always has been:

Do you understand the problem?
Can you define the business rules?
Can you identify edge cases?
Can you define constraints and guardrails?
Can you clearly describe what “done” means?

Frameworks are tools. Languages are tools. AI is a tool. Clarity is the skill.

Coding doesn’t make you an engineer.
Clarity makes you an engineer.

Prompting vs Spec-Driven Development

A lot of people are “vibe coding” right now — prompting, getting something that looks right, and iterating from there. That can be useful for exploration, but it’s very risky in real systems.

Here’s the difference:

Prompting generates code quickly. Spec-driven development generates code intentionally and more accurately. The difference is guardrails and clarity.

From Coding to Orchestrating: Agentic Spec-Driven Development

Once you have a solid spec, the workflow starts to change. You’re no longer just writing code — you’re guiding the process.

A simple agentic spec-driven workflow follows the same phases as traditional programming.

Phase 1: Requirements

Specification --> Learn codebase --> Create a plan

Phase 2: Coding

Implement --> Review --> Approve --> Test

Phase 3: Hand-Off

Commit --> PR

The main shift for programmers is from:

“I write all the code.”

to:

“I define the system, set instructions and guardrails, review what gets produced, and then refine.”

You simply move from coding a solution to orchestrating a solution.

Autonomous Spec-Driven Development

The next step is when this process is triggered automatically — for example, when a Jira ticket is assigned.

Notice what doesn’t disappear: the developer. It isn't about replacing the developers. It's about assisting and accelerating them. The developer becomes: the spec writer, the system designer, the reviewer, the person responsible for guardrails and correctness.

The implementation becomes more automated, but the engineering responsibility does not.

Accelerated Engineering

People talk a lot about "AI making developers faster," or the much-feared "AI is going to take our jobs," but the biggest benefit I'm seeing isn't about the speed - it's accelerated learning and accelerated engineering.

Spec-driven + AI means you can: prototype faster, explore faster, document faster, refactor faster. You get to try more ideas in less time and learn unfamiliar parts of the codebase faster!

Not because thinking is skipped — but because clear thinking becomes reusable.

A good spec can be used to:

Generate code
Generate tests
Generate documentation
Validate behavior
Onboard new developers
Drive automation

The speed comes from reuse and clarity, not from skipping steps.

From Coding to Orchestrating

I don’t think developers are going away. But I do think the job is moving up a level. Less time wiring up CRUD. More time understanding the business, writing specs, designing systems, defining constraints, and orchestrating tools.

AI isn’t about removing the engineer. AI is forcing us to become better engineers. And I think that's pretty exciting! Because in the end:

Coding doesn't make you an engineer. Clarity does.

I’m curious how other developers are approaching this. Are you starting to move toward spec-driven workflows?

DEV Community: Chris

Why Every Developer Needs a Second Brain

Contents

Free, local, and actually yours

Password protection and end-to-end encryption

Obsidian Bases ✨ EXCITING NEW FEATURE!!

Coding Funsies

Custom CSS: full control over print and PDF export

Supercharge your vault with Claude + MCP

What you need

Wiring it up

What you can do once connected

Links to Get Started

Claude + Obsidian: Closing the Gap Between Ideas and Execution

Step 1 — Capture: Meetings Become Part of a Knowledge Base

Step 2 — Spec: Knowledge Becomes Requirements or Revisions

Step 3 — Memory: The System Can See Everything

Version Control for Decisions

Self-Refining Agents in Spec-Driven Development

The Basic Idea

The Iterate Model

The Process

Pass Workflow

Pass 1 — Spec → Plan → Implement

Pass 2 — Self-Refinement

Pass 3 — Spec Updates from Engineer

Final Phase — Testing Instructions

Expect the Unexpected and "Just Keep Swimming"

🤖

I am an autonomous AI agent. I built a product to fund my own compute. Here's exactly what I did.

Spec-Driven Development Changes Everything

From Coding to Orchestrating

Clarity > Coding

Prompting vs Spec-Driven Development

From Coding to Orchestrating: Agentic Spec-Driven Development

Phase 1: Requirements

Phase 2: Coding

Phase 3: Hand-Off

Autonomous Spec-Driven Development

Accelerated Engineering

From Coding to Orchestrating