Homestead — listen

Intro

I spent a year trying to improve Claude Code.

And this was the result.

Homestead running on a phone — a card from one of the steadings, with the row of steadings along the bottom.

To start, this is not an insult to Claude Code. In fact, quite the opposite.

Before it, I’d tried a few other AI coding helpers, like copy-and-pasting out of ChatGPT, or Copilot, Cline, and a handful of others.

And while those other tools did help me write code, Claude Code was so good at coding without my input that I stopped thinking about code — and instead just thought about what I wanted to build.

So that became the job. Imagining, describing, and iterating — until what I was imagining became a reality.

This new way of building is what created new bottlenecks, and in an effort to get around them — I built Homestead. A framework around Claude Code that enables it to be even more useful to me, by solving problems like the following.

Problem One

Problem OneThe agents didn't talk directly to each other.

One common technique I use to speed software development is that I’ll take one feature or bug fix and I’ll break it up across multiple agents, in order to accomplish more, faster.

Well, that was the theory. What I kept running into was that each agent had a different idea of where they should stop and start their part of the build.

I found myself playing telephone between these agents — spending a lot of time trying to understand what the agents were thinking and then attempting to align them.

I tried speeding this process up with techniques like asking the agents to write documents explaining their thinking and then I would pass those documents between them. But even that was tedious, and not as fluid as I felt the conversation could be.

Fix OneThe walkie-talkie tool.

In an effort to solve this, I gave every agent a walkie-talkie — a tool that allowed them to see who the other agents were, what they were working on, and talk directly to them.

This allowed me to split fairly large projects across many agents. Each agent could still come and ask me questions directly, but where they needed to coordinate, I would just ask them to do so.

And what started out as a simple tool to speed up software builds eventually became the foundation for many features and systems that solved problems like this next one.

Problem Two

Problem TwoNothing started without me.

Here’s a common scenario: I get an email, a Slack message, or a text about a project I am working on. It is usually a bug request, a question, or a new feature idea from someone I'm working on a project with.

Some of these requests are small enough, or so well described, that basically all I need to do to complete the job is to open up a Claude Code agent and copy and paste in the request.

But, no matter how simple the request, I was still responsible for relaying the message to Claude Code in order to get started.

Fix TwoI let Claude Code read my notifications.

I built an app for my phone that enables Claude Code to have total control of my phone, including allowing Claude Code to read all of my notifications as they come in.

What this meant was that Claude Code could just read the requests as they came in instead of me having to copy and paste them over. Now all I had to do was teach a Claude Code agent how I wanted these notifications to be handled, which led me to my next problem…

Problem Three

Problem ThreeI couldn’t trust them.

It took me a long time to figure out how to make use of Claude Code looking at all of my notifications.

At first, I tried to jam way too much responsibility into a single agent. I was asking this one agent to look at every notification, recognize whether the message is a request for any of the on-going projects, and then go fulfill the entire request to the standards I have for that specific project.

Unsurprisingly, when a notification came in, this one agent would rarely even get close to doing everything I was hoping for, sometimes doing more harm than good. I quickly turned off the feature.

Fix ThreeSpecialization.

My next approach was to split the responsibilities of the one agent. Before, I was asking it to know both how I wanted my notifications to be managed and how I wanted each project to be managed.

To split things out, I taught one agent to just handle the notifications and then, for each project, I taught a dedicated agent how I wanted that specific project to be managed.

Then, when a notification would come in, the agent handling the notifications could just focus on sending the request to the right project's agent and then that project's agent could just focus on implementing the actual request.

Problem Four

Problem FourGetting across the finish line.

While splitting up the responsibilities did dramatically improve the results of the Homestead system handling a notification on its own, I found that it was still rare for everything I was asking for to be done to perfection.

Granted, I was asking Homestead to do every part of the job that I used to do — up until literally clicking send on a reply message.

So for requests for certain projects, my expectations were that the Homestead system recreate the issue, write the fix, provide evidence that the fix works, write a guide for me to test the fix, push and deploy the code where needed, and finally draft a message back to the sender.

Homestead would regularly get steps one and two done but would become unreliable thereafter, maybe knocking out one or two of the remaining steps. So I would come back after it was done working to find I still needed to poke and prod that project's agent, often just repeatedly asking it to go read its instructions and complete all the tasks.

Fix FourSteadings.

Splitting up the responsibilities worked once - why not try it again?

Initially it was not clear to me where I should make this split. Do I divide up the tasks amongst multiple agents where say one agent writes the code and then another agent tests the fix and so on? If so, how many agents do I get involved? Would specializing this way even be helpful?

After some experimenting, the best split I found was not to divide up the actual development work — but to instead have one agent continue to do all of it, and then have another agent whose whole job is just to audit the agent that does the work.

What this system eventually turned into is what I call Steadings. Each Steading represents a project or a responsibility.

Each Steading has one agent called the Steward. The Steward’s job is to know how I want that Steading’s project or responsibility to be managed.

The other role inside of a Steading is the Worker. A Worker is spun up for one specific task or feature, and then spun down once complete.

Here is how Stewards and Workers work together: a Steward spins up a Worker for a specific task. Once the Worker stops working, the Steward is notified and begins to audit the work — to see if the Worker actually completed all the steps in the instructions for that Steading. If not, the Steward tells the Worker where it dropped the ball, and the Worker gets back to work. This cycle continues until the Steward is satisfied.

Homestead on a phone, with the row of steadings highlighted along the bottom.

The row of steadings: a top hat, an ID card, a coffin, a lemon, a house, a robot, a rooster, a bank and an office building.

For some concrete examples, here are all of my steadings. Over here on the very left is Alfred. Alfred’s steading is in charge of processing the notifications that come to my phone. Right beside it is Big Jim’s steading, who is in charge of the projects my neighbor Big Jim and I come up with.

Big Jim will text me with either a tweak to an existing project or a brand new idea. The notification lands on my phone, Alfred sees it, and then forwards on the request to the Big Jim Steward.

The Big Jim Steward will read the request and determine if there is already a Worker who can handle this request or if the request will require a new Worker.

So either a new or existing Worker gets the request and that Worker will work away until the Steward determines the Worker’s work is satisfactory.

A Worker reporting finished work: the card names the Steading and the Worker that did it, with the other Workers listed along the bottom. — Two Workers reporting back. Each card says which Steading it came from and which Worker did the job — the rest of that Steading’s Workers sit along the bottom.

Another Worker's report, separating what was a phone setting from what was actually its own bug. — Two Workers reporting back. Each card says which Steading it came from and which Worker did the job — the rest of that Steading’s Workers sit along the bottom.

That’s the whole story.

Watch the video Read the blog Back to Homestead