The future of AI development | Christopher Pitt

The future of AI development

Last updated on 27th May 2026

I want to tell you a story about what I learned I should be building, and what I think it means for the future of AI development. I'm a developer, and my employer recently encouraged me to start using AI in my daily work.

The truth is I didn't want to come back from my holiday break, at the start of the year (2026), so I put all the reasons I didn't want to use AI into a box, and gave Claude Code CLI another go.

I still have those reservations. These are interesting tools built on rampant theft and a complete disregard for the planet and the people they will destroy in the process of generating value for the shareholders. I wish we could start over, but better.

Fast forward: in early March I built a personal AI bot. I called it Friday, because that's what Tony Stark called one of his AI assistants. It runs on a 2018 Intel Mac mini that sits under my desk. I talk to it through a Telegram group with a topic-per-concern structure. The bot (really a meta harness) is built on Claude Agent SDK.

For the few months I've been running it, I've spent at least half of my work hours changing something on it. Making it better. Giving it the tools to do more and more of the work I was doing before.

Then, in mid-May, Anthropic announced that subscription tokens would no longer be valid through the Agent SDK or through claude code -p. The whole reason I'd built a meta harness on top of the Agent SDK was to use subscription billing to experiment, without having to pay a bunch of my own money.

I had a decision to make. Keep using Anthropic models through their own tools, or change Friday to run on top of something else.

I know it's possible to use other models with Claude Code CLI. Hopefully, by the time you've read through this post, you'll understand why that would have been a bad choice.

¶Part one: Friday

Let me describe Friday properly, because the contrast with what came after only makes sense if you understand what was already working.

Friday is a Telegram bot that bridges through to Claude Code via the Agent SDK. You send a message into a Telegram topic. A bridge layer forwards that message into a Claude Code session running on the Mac mini. The agent does whatever work the message implied. The response comes back as a Telegram reply.

The bridge handles the conversational round-trips, but the agent's actual intelligence — tool use, reasoning, memory of the conversation so far — all comes from Claude Code itself.

The interesting design isn't in the bridge. Bridges are easy. The interesting design is in how I structure the conversational surface, and how Claude Code's session state is tied to where it's operating in the filesystem.

In Telegram, the bot lives in a group with forum-style topics. Each topic is a workspace. I have an MCP tool that lets me ask Friday to spawn a new topic with a name of my choosing — "google auth research", "RPG tutorial draft", "fix the date picker bug" — and then I switch into that topic and start a conversation. Inside the topic, I can run /project example.com and that binds the topic to a codebase living at /home/friday/Code/example.com/. From then on, every message I send in that topic is routed into a Claude Code session scoped to that directory.

Switch topic, switch project, switch context.

There are three layers of context. The topic is the human-readable workspace: this is where I'm thinking about this thing. The project binding scopes the topic to a specific codebase: this thing lives in this repo. And once I start a feature, a worktree gives that feature its own physical checkout: this work happens in this isolated copy of the repo.

Topics can fan out two or three at a time per codebase — one researching the next feature, one in mid-implementation on the previous one, one debugging the live system, one writing a tutorial. The worktrees give each of them their own slice of repo state. They don't step on each other. I never have to stash work or juggle branches or remember which checkout is in which state.

The coding workflows are five slash commands:

custom-workflow-new-feature

custom-workflow-plan

custom-workflow-implement

custom-workflow-pr

custom-workflow-merge

They form a tight little pipeline. I'll describe two of them in detail, because the way I designed them turns out to be the heart of what I had to unlearn.

The new-feature workflow starts with a tiny brief — "integrate google auth", "RPG tutorial", two or three words. It looks in the project's features/ directory, finds the highest-numbered existing doc, increments the number, sanitises the brief into a slug, and arrives at something like feature/019-google-auth.

It creates a worktree at .worktrees/feature/019-google-auth/, copies a template file into the worktree as features/019-google-auth.md, leaves it uncommitted, and — as its final act — changes Claude Code's working directory into...