My AI Tech Stack

My AI stack is organized by job: two places to work, four coding agents matched to the kind of task, one reviewer, two research assistants, and local models for experiments. The model names will change. The jobs stay the same, so the map above follows the jobs, and so does this post.

Where I work

Visual Studio Code is my primary IDE. It is where I work directly: following a call through several files, debugging, running commands, and reading a diff closely.

Orca is my Agent Development Environment. It coordinates coding agents, their sessions, and separate Git worktrees. A separate conversation does not separate the files being edited, so each agent gets its own checkout. That keeps parallel changes from colliding and makes each one easy to inspect on its own.

The same agents run in either place. VS Code is for work I do myself; Orca is for work I hand off.

Coding agents

I pick the agent by the work, not by a favorite model. Four questions decide it: how much of the system the task touches, how clear the requirements are, what a subtle mistake would cost, and how hard the result is to check.

Contained edits go to OpenCode, including models through OpenCode Go: small scripts, transformations, repetitive cleanup. The scope is narrow and I can check the result directly.

Documentation drafts go to Gemini Flash in Google Antigravity. First drafts of explanations and README updates, which I then check against what the code actually does.

Hard problems go to Claude Code or OpenAI Codex: features, difficult debugging, architecture changes, large refactors. These need an agent that can reason about consequences across files and components.

These are working preferences, not rankings. A cheaper model is not always faster, and a stronger one does not always need less supervision. The real cost includes the time I spend explaining the task, correcting the result, and verifying it. Size is a poor guide to risk, too: a documentation change can alter how someone runs a migration, and a five-line code change can touch an authentication boundary.

If I cannot say what success looks like, a stronger model will not fix that.

Review

GitHub Copilot reviews my pull requests as a second opinion. An agent can write a confident summary while missing a regression, an unsupported assumption, or a change that wandered out of scope.

Two models agreeing proves little, since they can make the same mistake. I treat each finding as a lead and confirm it against the diff, a failing check, or behavior I can reproduce.

Research and diagrams

ChatGPT and Gemini are my research assistants. I use them to learn unfamiliar concepts, compare technical approaches, and work through questions about papers and documentation. When accuracy matters, I go back to the primary source; the summary helps me find it.

ChatGPT and Mermaid.js turn a rough description into a diagram. Mermaid diagrams are text, so they can live beside the code and change when the design does. If I cannot draw where a decision happens or what crosses a boundary, the design is not finished.

How I talk to these tools depends on the request:

Voice

Long, context-heavy prompts, so I can explain how the pieces connect.

Text

Small, exact changes, so names and paths are unambiguous.

Images

Architecture, sent as a picture of a diagram I have drawn.

Local models

I run Qwen models through Ollama on my Windows development machine and a Linux home server. Running locally gives me control over the runtime and a place to experiment with bounded workloads, within the memory and compute of my own hardware.

What it costs

The price of this stack is coordination: several subscriptions, overlapping capabilities, and context that drifts between tools. A tool stays when it has a clear job that nothing else in the stack does better. When a new one blurs those jobs, it is one tool too many.