Late in Day 2, I typed this into Claude Desktop:

"Read my product vision and my tech stack decision, then suggest three features I should add to my backlog and write them to /Backlog/ideas.md"

Claude read two files from my local filesystem, reasoned about the product, generated three genuinely relevant features with detailed rationale, and wrote them directly into my Obsidian vault.

I didn't write a script. I didn't call an API. I just asked, in plain English, and watched an AI agent complete a real task on my actual system.

That's what Day 2 was about. Here's how we got there.

The company brain: Obsidian

The first thing I set up wasn't a coding tool. It was a knowledge system.

Most developers would skip this and start coding immediately. That would be a mistake — especially when you're building with AI agents. The reason is subtle but important:

AI models have no memory between sessions. Every time you call a language model, it starts completely fresh. It doesn't know your product vision, your architecture decisions, or your team's working principles. Without a knowledge system, every agent interaction is context-free.

The solution is a knowledge layer that agents can query. I set up Obsidian for this — not because it's a great note-taking app (though it is), but because of one property: every note is a plain markdown file on your local filesystem.

That matters because a plain markdown file can be read with a single filesystem call. No API, no extraction layer, no special integration. An AI agent can read it the same way you would.

I structured the vault like a real company:

app-brain/
├── Vision/          ← product north star
├── Product/         ← PRDs and features
├── Architecture/    ← technical decisions (ADRs)
├── UI/              ← design principles
├── AI/              ← prompt library
├── Research/        ← experiments and findings
├── Agent Memory/    ← what agents have decided
├── Decisions/       ← major choices with rationale
├── Backlog/         ← features and ideas
└── Journal/         ← daily learning log

This vault isn't just notes. It's the foundation of what will eventually become a RAG (Retrieval-Augmented Generation) memory system — where agents query it semantically before every task. I wrote the first real documents: a product vision, a tech stack decision, and today's journal entry.

The AI coding environment

Next: Cursor and Claude Code.

These are worth distinguishing clearly because most people treat them as the same thing.

Cursor is for me. It's an AI-native code editor (built on VS Code) that I use when reviewing code, debugging, or making direct changes. It understands my entire codebase.

Claude Code is for agents. It's a CLI tool that can read files, write code, run terminal commands, and open pull requests — autonomously, without me sitting there. It's what the implementation agents in my pipeline will use to actually write code.

One is a tool I use. The other is a tool that agents use. They complement each other perfectly.

A practical lesson here: I initially thought Claude Code needed a separate Anthropic API key. It doesn't. Claude Code works with a claude.ai Pro subscription — the same one you use for this interface. No separate billing. No API key. Just log in with your existing account.

My Mac is now an AI server

This was the most surprising part of Day 2.

I installed Ollama — a local LLM runtime — and pulled three models: qwen3, llama3, and gemma3. These are large language models running entirely on my Mac, using the GPU and Neural Engine inside Apple Silicon.

After about five minutes of setup, I had this running:

curl http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model": "qwen3", "messages": [{"role": "user", "content": "What is progressive overload?"}]}'

A local AI model, responding in under a second, with no internet connection, no API costs, no data leaving my machine.

The technical detail that matters: Ollama exposes an OpenAI-compatible API at localhost:11434. The same code that calls GPT-4 or Claude can call a local qwen3 model by changing one line. This compatibility is what makes local models a genuine alternative rather than a toy — your agents can switch between cloud and local models as a configuration choice, not an architectural one.

For this app specifically, this matters enormously. The app handles personal health data — workout history, body metrics, recovery patterns. That data should never leave the device by default. Local models make that possible.

MCP: giving AI hands

The last piece of Day 2 was the one that changed my understanding of what agents can actually do.

Up to now, Claude could read messages and reply with text. Useful, but limited. MCP (Model Context Protocol) is what changes that.

MCP is a protocol — think of it as USB-C for AI. Just as USB-C lets any peripheral connect to any computer through a standard connector, MCP lets any tool connect to any AI model through a standard protocol. You write an MCP server that exposes tools (read a file, create a GitHub issue, query a database), and any MCP-compatible AI client can use those tools.

I configured Claude Desktop with two MCP servers:

Filesystem MCP — lets Claude read and write files on my local system, specifically my Obsidian vault at ~/Documents/app-brain

GitHub MCP — lets Claude read issues, repositories, and pull requests from my GitHub account

A practical note: Claude Desktop needs the full absolute path to npx, not just the command name. It runs in a restricted shell environment where it can't find executables the same way your terminal can. Running which npx and using that full path in the config fixed a frustrating issue that took some debugging to identify.

The moment it clicked

Once MCP was working, I tested it with the request I opened this post with.

Claude read my Vision/product-vision.md. It read my Architecture/ADRs/001-tech-stack.md. It reasoned about the product — audio-first, local AI, personal health data — and generated three features that genuinely fit the product principles. Then it wrote all three directly to Backlog/ideas.md with detailed rationale for each.

I opened Obsidian. The file was updated.

This is a small version of the autonomous pipeline I'm building toward. The difference between today and the end goal is that today I'm in the conversation asking for it. In a few months, a GitHub Issue will trigger it, agents will run overnight, and I'll wake up to a pull request.

What I learned

1. The knowledge system comes before the code. Building Obsidian first was the right call. Agents are only as good as the context they have access to.

2. There are three different Claudes and they are not interchangeable. claude.ai is the web interface. Claude Code is the CLI coding agent. Claude Desktop is the local MCP host. Each does something different. Confusing them wastes hours.

3. Your Mac is genuinely capable AI hardware. Apple Silicon's unified memory architecture means 7B parameter models run well on 16GB RAM. Local AI is not a compromise — it's a legitimate production choice, especially for privacy-sensitive data.

4. MCP is the moment agents become useful. Text generation is interesting. An agent that can read your files, check your GitHub, and write to your knowledge base is actually useful. That line matters.

What's next

Day 3 starts the agent infrastructure layer: PydanticAI for structured agent outputs, FastAPI for the backend API, and the first real feature built entirely by an AI agent.

The stack is coming together. The foundation is solid.

Building with an AI engineering team — documenting everything.

X: [@ankitOnAIr]

But I'm not here to become a better programmer. I'm here to learn something more valuable: how to orchestrate AI systems that build products for me.

The setup: one app, six AI agents, zero human engineers. A PM Agent, an Architect Agent, a Frontend Engineer, a Backend Engineer, an AI Engineer, and a QA Agent. My role is CEO, product owner, and AI orchestrator.

Before any of that can work, I needed a foundation. This post covers exactly what I installed today, why each piece matters, and the mental model that reframed how I'm thinking about all of it.

The mental model that changed everything

A traditional software company has humans in every role. I'm building the same company — but AI fills every role below CEO.

My job is not to write code. My job is to design the system, direct the agents, review their outputs, and make product decisions. I am the only human in the building.

The long-term goal is a pipeline that looks like this:

Me on my phone → create a task → automated workflow triggers → PM Agent writes the spec → Architect designs it → implementation agent writes the code → QA Agent reviews it → Pull Request opens → I get notified.

All while I'm away. Or sleeping.

Everything I installed today serves that eventual goal. Nothing is arbitrary.

The full system — seven layers, each one enabling the layer above it. Screenshot from my setup session.

The foundation: four tools, one purpose

Before AI tooling, agents, or frameworks — I needed the ground floor. Four tools. Each one a prerequisite for the next.

1. Homebrew — the package manager

Everything else depends on this.

Homebrew is macOS's package manager. Instead of manually downloading installers and fighting with PATH configuration, one command handles installation, versioning, and updates for any tool.

brew install ollama
brew install uv  
brew install fnm

The reason this matters beyond convenience: the AI engineering ecosystem moves extremely fast. Models update weekly. Frameworks ship breaking changes monthly. A package manager means brew upgrade keeps everything current with one command. Without it, staying current becomes a part-time job.

The principle I'm carrying forward: understand each tool before installing it. Don't install things because a guide says to — install them because you understand what they do and why you need them.

2. Git + GitHub — the communication protocol

In an AI-native company, Git plays a role it was never designed for. It's not just version control — it's the communication protocol between me and my agents.

• GitHub Issues → how I give agents tasks

• Pull Requests → how agents deliver their work back to me

• GitHub webhooks → how the workflow engine gets notified and kicks off pipelines

One thing that came up: I already had Git installed via Xcode Command Line Tools. The right call was not to install a duplicate. Understanding what you already have is as important as knowing what to install.

The critical step was SSH key setup — the cryptographic handshake that lets Claude Code push pull requests to GitHub autonomously. Without it, the automated pipeline has no way to deliver.

3. fnm + Node.js — the JavaScript runtime

Several tools in this stack run on Node.js: Claude Code, the Ionic mobile framework, and n8n (the workflow engine I'll use to wire agents together).

But instead of installing Node.js directly, I used fnm — Fast Node Manager.

The reason: different projects need different Node.js versions. A version manager lets you install multiple versions and switch between them automatically, based on a .node-version file in each project directory. fnm is written in Rust and significantly faster than the older nvm alternative.

brew install fnm
echo 'eval "$(fnm env --use-on-cd --shell zsh)"' >> ~/.zshrc
fnm install --lts

The --use-on-cd flag is what makes it automatic — change directory, correct version activates. No thinking required.

4. uv — the Python revolution

This was the most satisfying step of the day.

Python historically required five separate tools to manage properly: pyenv for versions, pip for packages, virtualenv for isolation, pip-tools for locking dependencies, pipx for CLI tools. Five tools, five config formats, five things to keep in sync.

uv replaces all five.

uv collapses five tools into one. Written in Rust by the Astral team.

Written in Rust, uv is 10–100x faster than pip at installing packages. The workflow it enables is clean:

uv init my-project        # creates pyproject.toml
uv add fastapi anthropic  # installs + locks dependencies  
uv run python main.py     # runs in isolated environment

Three commands. Isolated environment. Locked dependencies. Reproducible on any machine — or inside any agent's Docker container. This matters enormously when agents run unattended.

The key concept: layers, not tools

The most important thing I learned today isn't about any specific tool. It's that these aren't isolated tools — they're layers in a stack, and each layer talks to the one above and below it.

Homebrew installs everything. Git tracks everything. Node.js runs the tooling. Python runs the AI.

Above these four layers comes the interesting part: local AI models, agent frameworks, workflow orchestration, memory systems, and eventually the autonomous pipeline that lets me manage the whole operation from my phone.

The foundation has to be solid before any of that works. Today it is.

What's next

• Obsidian — the company brain that eventually becomes RAG memory for agents

• Cursor + Claude Code — the AI-assisted development environment

• Ollama — running local AI models on my own Mac

• Claude Desktop + MCP — wiring agents to real tools and data sources

Building everything in public. Posting as I go. No gatekeeping.

If you're learning AI engineering, building with agents, or trying to figure out how to work with AI rather than just use it — follow along. I'll share everything, including the parts that don't work.

This is post 1 in a series on building an AI-native app solo. Follow me on X [@ankitOnAIr] for shorter updates between posts.