Chatto is Robots

[ I’ve recentlyopen-sourced Chatto, my self-hostable team and group chat app that I’ve been working on for the past 9 months or so. I think it’s really good! Everyone who’s tried it seems to agree! (Which I appreciate so much! The positive reaction to Chatto has been humbling.)

But here’s the kicker: my workflows in building and maintaining Chatto are pretty much 100% agentic; I have, in fact, not written a single line of code since February this year. Yet, I have never felt as involved in a codebase as here. Agentic engineering has allowed me to spend a much larger portion of my time reasoning about the code instead of typing it out. The result is what I feel is the best application I have ever built.

In this blog post, I want to give you a good overview of my workflow. If you fundamentally hate the very idea of software being built with the help of AI, I’ll humbly ask you to make the effort to keep reading; your notion of what it means to work with coding agents may be incomplete, and maybe this post will help paint a more nuanced picture.

(Oh, and by the way: yes, I wrote the entire post myself. Having AI write blog posts is stupid! Don’t do it!)

Let’s dive in. The three pillars of my workflow are tools, agent guidance, and code reviews. I’m going to go through each of these one by one.

Tools

Models and Agents

I’ve had a €200/month subscription with one of the leading frontier labs since around December last year. Up until two months ago, this was Anthropic’s Claude Code; I have since fallen out of love with them and switched to OpenAI and Codex. Claude has become a weirdly unreliable mess, and Anthropic generally has some outright unpleasant views on what their users are allowed to do with their subscription and not. OpenAI’s models are fantastic, get to the point faster, and are way less obnoxiously chatty than Anthropic’s; the codex CLI is a significantly better computer citizen than claude; and to top it all off, OpenAI are being very generous with the many rate limit resets they’re handing out.

I don’t love paying €200 a month to a US-based frontier lab. It’s a lot of money — I keep referring to it as “half a PS5 every month”, even though this is no longer accurate — and being this dependent on a vendor, and one in the US to boot, is not great. But I see these as temporary caveats, and ultimately, the value this subscription provides is immeasurably higher. It allows me to move extremely fast by basically stripping most of the tedium from building complex applications. Some form of Chatto would exist without it, but it probably wouldn’t be as good.

It really is the easiest €200/month I’ve ever spent.

But like many others, I, too, am looking forward to local models eventually taking over “the bottom 80%” of this work. I’m super excited about the things happening in this space, and I’m convinced that 5 years from now, we will look back at 2026 and laugh at ourselves for shelling out all this money just to have a supercomputer write some Go for us. (Unless that supercomputer kills us first, an event that I reckon by now has a 50% chance of happening. Bring it, robots!)

Multi-Agent Orchestrators

Coding agents sometimes take their sweet time. If you’re just running a single session, you’ll end up with plenty of downtime.

The answer to this is parallelization; just run a bunch of agents working on different tasks in parallel. You can’t feasibly do that in the same directory, so you use git worktrees in order to give each agent its own little space to work in. Within each worktree, you’ll want to run your project’s setup task, and a copy of your coding agent. All this adds up, and you don’t want to spend half your workday manually managing git worktrees and running scripts, so instead, you’ll use an agent orchestration tool that does these things for you.

And there are so many of these out there. The one I’ve been using for the past half a year or so is Conductor, one of the few closed-source options. I don’t love that aspect of it, but other than that it’s generally fine. It’s also had some pretty terrible performance issues in the past; the main reason why I’m still using it is that I’ve grown accustomed to it, and switching to another tool introduces friction that I’m not eager to deal with.

But when I do eventually switch away from it, my new tool of choice will likely be Paseo. It follows the same UI paradigm as Conductor — they all do — but it’s open source and has a much saner architecture, with a server process running the actual agents and the UI only being a client that connects to it. It’s how I would have imagined such a tool to work if I had built my own, and I appreciate that.

In Conductor, starting work on a new task is one Cmd-N away; I enter the task, Conductor sets up the worktree, initializes the project, and gets going. When the agent is done, I get a notification; I can then review the code it has written, or click on a “Run” button to start a local copy of the project (this is configurable, and Conductor can assign per-worktree port ranges so you can run multiple copies of your app with no conflict). Another button opens the project in my browser for testing.

When there’s something I need to discuss with the agent, I can just keep the conversation going; the PR view even lets me leave comments on individual diff lines, like some sort of mini GitHub. There’s a big “Review” button that starts a second agent session with instructions to review the changes; Conductor lets you configure different agents and models for these if you want that.

Once I’m happy with the results, another button will post them as a PR with a single click; Conductor will notify me when CI is green, and then yet another button lets me merge the work into my main branch. If CI fails, the “Merge” button instead says “Fix errors”; one click on that will instruct the agent to inspect the CI output (Conductor will attach it to the prompt) and handle the failures.

This is what it looks like:

That’s the high-level workflow. Start a new task, review the code, post a PR, handle CI, merge. Just like you’re used to! Except now you can just do multiple of these in parallel.

You might think that if it’s all just about clicking the next button to move things forward, why not fully automate it? I understand the sentiment — but I think it’s the fact that the user is still making these decisions that’s ultimately making Conductor and its ilk so powerful. I don’t believe that full automation is or should be a goal, and recommend that you be wary of people telling you that it is.

Agent Guidance

The most important thing you must understand about coding agents and LLMs in general — and that a surprisingly large number of people fail to — is that they’re not tiny little oracles that just hold the answers to your questions, or can magically whip up things you ask of them.

Try to think of LLMs and agents as natural language automation glue. I’m convinced that once you internalize this, you’re a better AI user than 95% of everyone else.

Agent Skills

Your primary tool for automation is Agent Skills. They’re your secret superpower, acting as a surface for codifying your workflows, preferences, style guides, and more.

Custom skills are what turn a model that can count the number of “r” in “strawberry” or not into a machine that knows the ins and outs of your project. I believe that writing and maintaining good skills contributes 90% to your agentic engineering success, and much more so than just downloading collections of random third-party skills (I would strongly advise against doing so for more reasons than one.)

I’m going to describe some of my skills from the Chatto repository.

Glossary and Architecture Inventory

First of all, for any non-trivial project, you have to establish some language. The glossary skill takes care of this, creating and maintaining an inventory of terms used in the project and what they refer to. You will have a much easier…