My Experience Learning to Use AI for Software Development: Q1 2026

Q1 2026 was not about adopting anything new, it was about going deeper with Claude Code: running several sessions at once in tmux, building an observability tool for my own agent runs, and trying a few agent command centers. Most of the new tools did not stick, and the post is honest about which ones and why.

This is the second in what I expect will be a recurring series about my experience using AI tools for software development. The first article covered early 2023 through the end of 2025, ending with Claude Code becoming my primary tool and the general feeling that software development had become fun again. This one picks up from January 2026 and covers Q1.

January–February — Going Deeper with Claude Code

By January, Claude Code was firmly my main tool. The shift this quarter wasn’t about adopting something new, it was about going deeper with what I already had.

The biggest change was how I started working with multiple sessions. I was running tmux with several Claude Code sessions going at once, sometimes within the same repo, sometimes across completely different projects. This meant a lot of context switching, constantly flipping between panes to check which sessions were waiting for input and which were still working.

That friction is what led me to build the Claude Code Radar. The idea started simple: a timeline view showing what a single session was doing. But it kept growing. I added subagent tracking, tool call visibility, input and output capture, token usage, failure rates. It became a full observability tool for watching your Claude Code sessions from a single dashboard. It was genuinely fun to build and satisfying to look at while agents worked. But I’ll be honest, it didn’t actually change how I managed my sessions day to day. It was more of a cool thing to watch than a workflow improvement. By the end of March I’d stopped using it.

Around the same time I started reading Steve Yegge’s articles on Medium, pieces on Gastown, Beads, the AI Vampire, The Anthropic Hive Mind. I also watched a few interviews with him. He comes across as a smart, slightly crazy guy whose excitement about this stuff is contagious. His writing about Beads in particular got me interested in trying it for issue tracking, with the idea that if you set up your issues and dependencies well enough upfront, agents can pick up work more independently and you spend less time manually checking in on them.

I started using Beads in a few of my smaller projects. It’s useful, but I’m definitely still in the “trying it out” phase. The main issues I’ve run into are keeping the work pipeline full and tracking issues across different clones. I think these are growing pains more than fundamental problems. I want to try it on a larger project where I can actually sustain a queue of work for a while, which is what Beads is really designed for.

The Terminal as Home Base

My setup solidified this quarter. On my Windows work computer I use Tabby, which makes it easy to save and quickly connect to SSH profiles on different servers. On my personal Mac I use Ghostty. Both are full-time terminal emulators, not VS Code’s integrated terminal.

VS Code’s role has shrunk to almost nothing. I use it to look at data and browse file systems, but I don’t write code in it anymore. Everything goes through Claude Code in the terminal. This is a significant shift from even six months ago, when I still had VS Code open side by side as a visual anchor while agents worked.

Things That Didn’t Stick

A recurring theme this quarter was experimenting with new tools and workflows, getting excited about them, and then quietly going back to what I was already doing.

Kintsugi was my first try at using an “agent command center,” a UI layer that sits on top of tmux and tries to organize agent sessions in a more structured way. It was very cool at first, but the habit didn’t stick and I ended up back in plain tmux.

The Claude Code Radar followed the same arc, exciting to build, interesting to look at, but not essential enough to keep using.

I also tried a couple of workflow experiments that didn’t survive the quarter. One was recording paper summaries in a repo for work-related reading, the idea being I’d come back later and ask questions about specific papers. The other was a similar concept for meetings and random ideas: quick conversations with Claude Code to capture thoughts for later. In both cases, I rarely came back to what I’d saved. The capture was easy but the retrieval habit never formed.

March — Branching Out (Briefly)

In March I briefly tried other coding agent tools. OpenCode caught my eye after reading an article comparing it to Claude Code from a CTO’s perspective. The thing that stood out wasn’t really about capabilities, it was about cost. With OpenCode you can define different models for different types of tasks, so you’re not locked into expensive models for everything. That model-per-role routing idea is genuinely interesting, and I’ll probably come back to it in the coming months. But I didn’t give OpenCode much of a chance this quarter. I already had a Claude Code subscription and kept naturally gravitating back to it.

Codex is a different story. I genuinely try it every once in a while, usually when my Claude Code quota runs out, which happens two or three times per week. But I just don’t get the same results. Too often I find myself typing things like “WHY DID YOU DO THAT, I TOLD YOU TO DO THIS THING” or stopping it mid-task as it goes down some weird rabbit hole. The frustration-to-productivity ratio is too high compared to Claude Code.

Where Things Stand

At the end of Q1 2026, I’m still using tmux and Claude Code as my main setup. I’m not writing code anymore. I describe what I want, review the results, and manage context. The skills that matter now are different from what I’d have called “coding skills” a year ago: knowing how to structure prompts, when to compact a session, how to write handoff documents so an agent can pick up where another left off, how to keep multiple parallel sessions productive without losing track of what each one is doing.

I’m more deliberate about context management than I was in January. I compact sessions at natural break points instead of waiting for the context window to fill up. I have a handoff skill that saves a markdown summary of what the agent accomplished, so the next session can start with full context rather than re-exploring the codebase from scratch.

I’m looking into more agent command centers and orchestration tools to try next quarter. The tmux setup works, but I suspect there’s a better way to manage five or six parallel agent sessions. Kintsugi didn’t stick, but the problem it was trying to solve is real.

The honest summary of Q1 is: I went deeper with the tool I already had, tried a bunch of new things on the side, and most of those new things didn’t stick. That’s fine. The core workflow is strong and keeps getting better. The experiments that didn’t survive still taught me something about what I actually need versus what just looks interesting.