Skip to main content
Back to the notebook

AI

My AI coding stack, honestly

OpenCode, Codex, and Claude as teammates — not toys. What I hand to agents, what I never do, and what changed about how I plan work.

I run AI coding agents on real work every day — this portfolio was built with an agent session open beside it, and Kanaboards exists as a product because of what that workflow taught me.

This isn’t a review piece. It’s the working stack, and what I’ve learned about where agents genuinely earn their place.

The stack

  • OpenCode (stable) — my daily interactive driver, pointed at whichever repo I’m in.
  • Claude (beta) — long-context reasoning over gnarly architecture questions and review of decisions I’ve already half-made.
  • Codex (beta) — parallel task execution, where I want a second pair of hands on an isolated worktree.
  • Kanaboards — the board that all of them report into, because an agent that can’t update the plan is an agent you babysit.

The heterogeneity matters more than any individual tool. Different runners have different CLI shapes, sandboxing, and approval models — treating them as interchangeable wastes what each is good at.

What I hand to agents

  • Well-bounded tasks with clear acceptance criteria. "Add read-time metadata to articles, derived from word count" — yes. "Improve the blog" — no. Agents are powerful, not psychic; a good card is a good prompt.
  • Test-driven work, where tests exist. Agents are excellent at writing the code that makes a failing test pass, because the test removes ambiguity from "done".
  • Mechanical migrations. Renaming a token, updating 40 call sites, normalising a config format — exactly the work that burns a human out and a machine doesn’t notice.
  • First drafts of things I’ll edit. A rough structure, a checklist, a migration plan. The agent produces the strawman; I keep the judgement.

What I never hand to agents

  • Architecture decisions with long half-lives. An agent will optimise the local problem while quietly eroding a boundary that matters for years. The expensive decisions stay with me — that’s the whole lesson of shipping solo.
  • Anything touching secrets, auth, or data deletion without my eyes on the diff. Agents are confident at exactly the wrong moments. The blast radius of a confident mistake in those areas is not worth the minutes saved.
  • Content that carries my name and judgement. Including this post — an agent got a first draft of the structure, and every sentence here survived a human rewrite. The day I stop editing is the day it stops being mine.

What changed about how I plan

The big shift: writing the plan became the work. If a card has clear intent, constraints, and a definition of done, almost any capable runner will land close to it. If it doesn’t, no runner saves you. I now spend more time on card bodies than on reviewing code — and that’s a good trade.

The second shift: the board became the interface. Kanaboards exposes 54 MCP tools precisely so agents can claim a card, stream logs, and report outcomes. When the plan and the work live in the same system, the glue work — the copying, pasting, status-dragging that used to be my evening — disappears.

The third: verification beats trust. Agents fail differently from humans — confidently, plausibly, and at 3am. The counter isn’t suspicion, it’s the same discipline as any junior hire you want to succeed: clear specs, tests that mean "done", smoke tests after deploys, and diffs small enough to actually read.

The honest summary

Agents took roughly 30–40% off my cycle time on mechanical work, and — more importantly — changed the shape of a solo founder’s day: less paste-between-windows, more architecture and review. The work that remains is the work that matters. That’s the whole point.

Keep reading

More from the blog.

Accessibility

Accessible by default: how I bake it in from the first sketch

Accessibility isn’t a checklist at the end — it’s a posture. Here’s how I keep it present from wireframe through to production code.

6 min read
Product

Shipping solo: what I learned building three live products

Horrorometer, Kanaboards, and SENDadvisor all started as itches I wanted to scratch. Some patterns held across all three — and a few surprised me.

8 min read
UX

Designing for stressful systems: lessons from SENDadvisor

Families navigating SEND services are already overwhelmed. How do you design a directory that feels calm, trustworthy, and genuinely useful?

7 min read