My AI dev stack

October 2026 Edition: Fewer Tools, More Iterations

Why This Article Has a Version Number

If I wrote a "definitive guide to AI developer tools," it would be out of date before you finished reading it. I find and test new tools nearly every week. Most are gone a month later.

What surprised me this year: my stack got smaller, not bigger. I used to collect tools, a platform for this and a service for that. Now I spend less time inside tools and more time iterating with Claude: describing, reviewing, questioning, refining. Most of the specialized tools I used to recommend turned out to be wrappers around work an AI agent can now do directly.

I've also been moving almost everything I can onto my own VPS. Partly for cost and control, and partly because nothing teaches you infrastructure like being the one who has to fix it at midnight.

So this isn't a guide. It's a snapshot of what I actually use, how I use it, and what I've dropped.

Changelog

1. The Core: Iterating with Claude

My workflow is no longer "pick the right tool for each job." It's mostly a conversation:

1. I describe what I want, as precisely as I can.

2. Claude does the grunt work: scaffolding, boilerplate, refactors, migrations, tests, config files.

3. I review, question and push back.

4. Repeat until it's right.

The skill that matters isn't knowing which of fifty tools to use. It's knowing what "right" looks like, and being able to spot when something only looks right.

A good example: I had a Next.js project running on Google Cloud. As an experiment, I forked it and ported the whole thing to my VPS with Claude. A few years ago I wouldn't have attempted that in a weekend. Self-hosting Next.js means dealing with things the platforms normally hide: standalone builds, image optimization, caching on a single server, environment variables at build time vs. runtime. Claude handled most of the tedious parts. I handled the decisions.

I learned to unlike Umami, an open source tracker tool which is a memory hog, so I rolled my own with Claude. In Go. In 1000 lines. The kicker is: IT WORKS EXACTLY THE SAME. And I had never seen Go before.

2. Bonnie, Clyde & Marshal: Running Multiple Agents

When I need speed and the tasks are clearly defined, or I have several projects running at once, one Claude session isn't enough. So I run several, with roles:

• Marshal is the coordinator. I give Marshal the cards: the tasks, the constraints, what "done" means. Marshal deals them out.

• Bonnie and Clyde are the workers. Each takes a task, works on it in parallel, and reports back.

• When they report, Marshal reviews the work against what I asked for and raises questions: things that don't add up, edge cases, choices that need my input.

• Then I either answer Marshal's questions or go straight to the diff myself. Then the next round of cards.

              [ Me: the tasks ]
                      │
                      ▼
            ┌─── Marshal ───┐   deals the cards, reviews, asks questions
            │               │
            ▼               ▼
         Bonnie           Clyde       work in parallel, report back
            │               │
            └──────►◄───────┘
                      │
                      ▼
      Marshal reviews → questions → me → diff
                      │
                      ▼
                 next cards

What I've learned running it this way:

• Clear cards make a clean heist. Parallel agents only work when the tasks are well defined and independent. Vague tasks give you two agents confidently building different interpretations.

• Don't let them work on the same files. Separate branches or separate parts of the codebase. Otherwise Bonnie undoes Clyde's work.

• Marshal doesn't write code. The reviewer stays separate from the workers. That separation is what makes the review honest.

• The diff is the last word. Marshal catches a lot, but I'm the one who decides what gets merged.

To make this semi-autonomous and not get stuck, you need to give it a "Heartbeat", a cron job for Claude to dish out tasks and collect info.

3. Documentation: Obsidian, Committed to Git

My docs are Markdown files in Obsidian, and I commit them alongside the code. That gives me:

• Version history for my thinking. Decisions, architecture notes and how-tos change with the code, and I can see when and why.

• No vendor lock-in. Plain Markdown files. If Obsidian disappears tomorrow, I lose nothing.

• Context for the AI. Docs in the repo are docs Claude can read. Good notes mean better results with less explaining every time.

4. Hosting: My Own VPS

Most of my projects now run on a single VPS, in Docker. One project still runs on Google Cloud.

Why self-host:

• Cost. One server with a predictable bill instead of a growing list of per-project subscriptions.

• Control. No platform limits, no surprise pricing changes, no features locked to one vendor.

• Privacy. My data and my users' data stay on infrastructure I control.

• Learning. You understand networking, TLS, reverse proxies and firewalls once you have to run them yourself.

What it costs instead: you're the ops team now. Updates, backups, monitoring and security are your job. This is also where AI-generated configuration is most dangerous. Agents write Dockerfiles and Compose files quickly, but they publish ports to 0.0.0.0 and assume your firewall protects them. It might not: Docker bypasses UFW (I wrote about that in [Docker + iptables]). Review infrastructure code more carefully than application code.

Setup: nginx with Let's Encrypt in front, a Docker Compose stack per site, and deploys through a single make command that pushes to git and then pulls and rebuilds on the server, falling back to the previous images if anything fails.

5. Local AI: Where Claude Builds the Test Bench

Some of my coding is for local AI: benchmark tests for open source models, comparing how they handle real tasks.

There's a nice irony in it. I use Claude to build the tools that test whether open models can do what Claude does. The frontier model does the grunt work (benchmark harnesses, scripts, result parsing) so I can spend my time on the interesting question: how close are open models getting, and for which tasks are they already good enough to self-host?

That's also where this is heading for me: the more an open model can handle, the more of my AI workflow can live on my own hardware too.

When benchmarking, even the yardstick needed calibrating: running the identical test twice changed 23 of 273 results, and two AI judges disagreed by about 20 percentage points, so without careful measurement we would have drawn the wrong conclusions.

What's Actually Different Now

Before (pre-2023): Many tools, many dashboards, many subscriptions. Write boilerplate by hand. Push to separate CI. Deploy to a platform. Wait.

Now, for me:

• Fewer tools, more conversation. Most of my work happens in iterations with Claude, not hopping between apps.

• Parallel work when it makes sense. Multiple sessions with clear roles turn one developer into a small, well-coordinated team.

• Owning the stack. AI made self-hosting realistic. Porting a Next.js app off a managed platform used to be a project in itself. Now it's a weekend experiment.

• The job moved. Less typing code, more typing specification, review and judgment.

Pros and Cons

Pros

• Huge speed for grunt work: scaffolding, ports, refactors, config, tests.

• A simpler stack. Fewer tools to learn, pay for and keep updated.

• Self-hosting and infrastructure work are within reach for a solo developer.

• Parallel agents for well-defined work feel like having a team.

Cons

• Code that looks right but isn't. Plausible isn't correct. Read every diff.

• Infrastructure mistakes are expensive. A wrong port binding or firewall assumption is a security hole, not a bug.

• Coordination overhead. Multiple agents need clear tasks, or you spend more time untangling their work than you saved.

• Self-hosting means owning the problems. No platform team to call.

• Skill atrophy. If you never do the hard parts yourself, you eventually can't review them either.

My Rules

1. Every change goes through a diff I've (mostly) read.

2. Clear cards or no heist. Parallel agents only get well-defined, independent tasks.

3. The reviewer doesn't write the code.

4. Infrastructure code gets extra scrutiny: ports, firewalls, secrets.

5. Docs live in the repo, versioned and readable by humans and AI.

6. Self-host what I can, but only what I can maintain.

7. Return in a while and ask same hard questions with newer frontier model.

Outro: The Outlaws and the Marshal

My stack fits on a napkin: Git, Docker, a VPS, Obsidian, and Claude. Five things.

The work doesn't happen in the tools anymore. It happens in the loop: Marshal deals the cards, Bonnie and Clyde ride off and do the job fast and with plenty of confidence, and Marshal brings them back in and asks the awkward questions. Then I look at the diff.

Which makes me the judge. Nothing gets merged without a verdict. 🤠⚖️

If you're starting out, you don't need the fifty-tool stack the listicles recommend. Pick one good AI, learn to iterate with it, give it clear tasks, and always read the diff.

Check back next month. Half of what I tried will be gone. Git will still be here, and Bonnie and Clyde will appear here and there.