Notes

Current AI Development Setup

last modified: orginally published: 10 min read

Update (April 2026):

Anthropic dropped the ball with Opus 4.7. Between a slew of bugs, a refusal rate that went through the roof, and a new tokenizer that made it more expensive, it’s felt really bad to use.

Meanwhile, the rest of the field has been closing the gap. GPT-5.5 dropped, along with a flurry of open source releases - GLM 5.1, Kimi K2.6, DeepSeek, MiniMax M27, MiMo v2.5 Pro, and Qwen 3.6. I haven’t been able to put them all through their paces but initial impressions are encouraging. GPT-5.5 feels like a real step up - faster and more powerful, though a good chunk more expensive. Interestingly, OpenAI treats it like a brand new model, recommending rethinking your prompts from scratch. The bigger open source models are still much slower than Opus but some feel like they’re getting close to Opus 4.6-level reasoning

Anthropic’s ecosystem moat is still real but it doesn’t help if the model and harness behind it are regressing. I haven’t tested Opus 4.7 much since the cache bug was fixed - I’m hoping the fixes stick and it gets back where it needs to be.

Unfortunately, my company has shifted its stance on the use of Anthropic models for code generation as a result of the conflict between the Department of Defense and Anthropic. The practical effect is that my home and work setups have strongly diverged for the first time.

My home setup hasn’t changed. Claude Code remains my primary harness and I still use skills from my marketplace regularly. I’ve also leaned harder into the rest of the Claude Code ecosystem, especially the combination of Remote Control and auto mode. While I generally avoid extensions in my editor, I’ve found some benefit from the VS Code extension.

My work setup has changed significantly. Our company policy prevents us from using Anthropic models to write code. They’re still safe to use in circumstances like agent orchestration, reviewing, and planning, but, given how that can suggest code, we’re encouraged to not use them at all. As a result, my main harness is now Codex CLI running GPT-5.4. I adapted all of my plugins to be vendor neutral, so my workflow is mostly the same. OpenCode is currently my test bench where I try a bunch of models. I’ve even mixed Opus for planning with GPT-5.x for execution in compliance with our policy.

Deep Research got a GPT-5.2 refresh in mid-February. I now favor it over Agent Mode though it doesn’t really ask as many clarifying questions as it used to (or, in some cases, needs to).

Rationale

I still prefer using Claude Code with Opus over every other combination I’ve tried. Obviously, with my subscription I have no choice. But the overall package of the harness, model, and ecosystem is hard to beat and close to the bleeding edge. They built skills first, then shared them with everyone else. While everyone is finally rolling out subagents, they’re working on agent swarms.

They also put care into the developer experience. For example:

  • their Github Action has niceties like the in-line comment MCP
  • after launching skills, they folded previous alternatives like slash commands and subagents all into skills automatically
  • auto mode is a safer middle ground between allowing everything manually and yolo mode
  • Remote Control lets me walk away from my machine and check in from my phone instead
  • VS Code extension lets me resume a terminal session (and vice versa)

At work, I’m trying to make the best of a less than optimal situation. Codex CLI is the daily driver because it’s the most stable pick that’s still near the bleeding edge. OpenCode is a close second but it has rough edges, like the lack of a skill distribution system. My company has never embraced Google models so I never gave their tools a fair shot - but Gemini CLI uses its own GEMINI.md file and puts skills in .gemini/skills instead of the now industry standard AGENTS.md and .agents/skills, making it a nuisance to support.

GPT-5.x models force a different rhythm than Claude models: the model thinks deeply between turns instead of going back and forth, making each human-agent iteration slower. GPT-5.4 doesn’t reason as well as Opus 4.6, so plans require more careful review and more editing. Unfortunately, cutting corners is even more punishing since the model problem-solves on its own rather than flagging confusion, even when guided to do so. I catch the misalignment much later unless I watch the model work the entire time.

Assuming the policy doesn’t change, I’d eventually like to switch to OpenCode as my daily driver at work. I’d love to use frameworks like oh-my-openagent that truly leverage subagents and multiple models.

Details

There are just a few things I do to customize my setup.

Dual Subscriptions

When I need both accounts on the same machine, I use my work API keys as the main subscriptions for my account. That ends up in the default configuration locations.

For the personal subscriptions, I created a second configuration folder and then added an alias that invokes the instance with the second configuration.

alias pclaude="CLAUDE_CONFIG_DIR=~/.other-claude claude"
alias pcodex="CODEX_HOME=~/.other-codex codex"

That way claude and codex use the work API key while pclaude and pcodex use my personal subscriptions. The one downside is that pclaude does not use pcodex for its MCP server while using my codex plugin. I solve that by editing the skill within the Claude cache and disabling auto-updates.

Workspaces

I’ve found a happy medium of three different copies of my git repositories, what I call three “tracks.” I use three different color profiles to help easily identify which track a tab is in.

One is for small or immediately relevant tasks I’m working on. I use worktrees to work on multiple tiny projects in parallel. This track usually connects to my Docker instances, unless they’re being used by the other two.

The second is for slightly larger projects. This is usually my “real” work, the larger task I’m currently assigned. I spend time working on a plan, then let the agent take over for execution. While that’s running, I’ll move over to the first track and try to tackle little tasks from the backlog. When I’m running tests here it’ll block the first track, but I’m usually focusing on the work at that point so that’s not a problem.

The third is where I do exploratory work like testing new tools and forklifting full rewrites. I often use my personal subscriptions since these attempts don’t always pan out. OpenCode tends to live in this track as well.

Model Variants

In Claude Code, I’m using the latest Opus model generally with high effort. I bump up to max when reviewing.

In Codex CLI, I’ve switched to the mainline GPT-5 models since OpenAI says GPT-5.4 combines the best of 5.2 and 5.3-Codex.

In OpenCode, it’s a free-for-all - that’s where I test various model combinations including open source models.

Agent Skills and Guidance

I’ve moved most of my guidance out of the AGENTS.md and CLAUDE.md files and into skills instead. Since Claude Code wasn’t always loading the AGENTS file, I’ve started using more forceful language in the CLAUDE file

ALWAYS load @AGENTS.md for guidance.

The CLAUDE file also contains any extra guidance that’s Claude-specific like references to plugins. The AGENTS file, on the other hand, stays harness-neutral since it’s the primary guidance for all harnesses.

After a few early mishaps with auto mode, I added the following blocks to my global CLAUDE.md file. I wrote the first version as a simpler version of the first paragraph. On subsequent failures I asked Opus to improve the guidance, adding both more examples and the “how to apply” sections.

**NEVER** post anything to GitHub (PR comments, review replies, issue comments), Linear, Slack, email, or any external system on the user's behalf unless the user explicitly says "post it" / "send it" / "reply" / equivalent **in the same turn as the action**. Drafts always stay in chat. Do not infer authorization from earlier turns, from the user confirming the substance of a draft, from auto-mode being on, or from the action feeling like the obvious next step. Silence is not consent.
 
**How to apply:**
- Drafting a reply → keep it in chat as a quoted block, ask "want me to post this?", stop.
- Confirmation of substance ("yeah the bot is right", "fix it") is NOT confirmation to post — the user is talking about the underlying issue, not authorizing publication.
- Opening a PR the user explicitly asked you to open IS authorization for that one action; a PR-body edit, comment, label, or follow-up later is a new action needing new authorization.
- Auto-mode doesn't relax this; the system rules already exempt actions affecting shared state from auto-execution.
- If unsure, default to "draft, wait." Cost of waiting is one round-trip; cost of posting wrong is impersonation.
 
**NEVER** install software on the user's machine — Homebrew formulas/casks (`brew install`), system package managers (apt/pacman/dnf/yum/zypper), language-level global installs (`npm`/`pnpm`/`yarn` `-g`, `pip install --user`, `pipx install`, `cargo install`, `gem install`, `go install`), `gh extension install`, `mise plugin add` or `mise use --global`, Claude Code plugins, IDE extensions, or anything else that places a binary on `$PATH` or writes outside the current project working directory — unless the user explicitly authorizes that specific install **in the same turn as the action**.
 
**How to apply:**
- "I need it to test / verify / compare X" is NOT authorization. If a tool is missing, ask. Do not install on the assumption you'll uninstall after — uninstalls aren't always clean (config, caches, PATH residue, launch agents).
- Project-scoped commands (`pnpm install`, `uv sync`, `npm ci`) and ephemeral runners (`npx pkg@ver`, `uvx --from pkg`, `pipx run pkg`) are fine — they don't place binaries on `$PATH`.
- Auto-mode doesn't relax this; installing software is exactly the "affects shared state beyond local" case the system rules already exempt from auto-execution.
- Authorization is per-package and per-method. "yes install ripgrep via brew" doesn't authorize installing fzf later, nor installing ripgrep via cargo.
- If unsure, default to "ask, don't install."

I had mediocre results with the official LSP plugins from Anthropic. They’re resource heavy and don’t always get used even after explicit guidance. I’ve stopped using them for now but will try again to see if they’ve improved.

My general approach for sharing project-local skills between harnesses is to pick one folder as the primary source of truth and symlink skills into the other locations as needed. For example, at home I use .claude/skills as the source of truth but symlink things like language conventions into .agents/skills so that Codex can pick them up when reviewing. At work I do the reverse.

Plugins aren’t as simple. Claude Code still has the only mature plugin distribution mechanism. Codex recently shipped plugins but self-serve distribution is still coming, while OpenCode’s plugin system is for extending the harness itself rather than distributing skills.

In order to expose plugin skills to Codex and OpenCode you need to install them as project-local skills within .agents/skills. The rest of the plugin (like MCP servers and subagents) needs to be added by hand, often in multiple places since it’s different for each harness. When a plugin updates you’ll need to go back and update everything manually.

It was tedious, but I reworked my personal plugins to use harness-neutral terminology when possible. They perform slightly worse since they leave more for the model to interpret. On the plus side, I took the same opportunity to ready the marketplace for Codex distribution whenever that lands.

Graph View

Recent Notes