I was shipping at a pace that felt sustainable right up until it didn't. Acolyte is not a small project. Eight subsystems talking to each other: daemon, sessions, tasks, lifecycle, tools, skills, memory, workspace. Around 27,000 lines of production code at the time of writing this post. Features landed, the codebase grew, and at some point I stopped being able to hold a clear picture of how the pieces fit together.

But the bigger problem wasn't complexity. The more I shipped, the worse Acolyte got as a tool I could actually use.

That's not how it's supposed to work. You add features, fix bugs, and the tool improves. What happened instead was that each addition introduced new ways for things to go wrong across module boundaries — and I started losing confidence that Acolyte would do what I wanted it to do. Not in edge cases. In normal use.

The irony isn't subtle. I'm building a coding agent. I can't reliably use it to build itself.

Shipping fast wasn't the problem. Not noticing when something broke was. With eight subsystems wired together, a bug rarely surfaces where it started. Tracing it back means crossing module boundaries you didn't expect to touch, and doing that across stacked merges is miserable.

Worst of it was the TUI renderer: a custom React reconciler I'd written to replace Ink. Renderer bugs showed up as visual glitches: duplicate output lines, broken scrollback, cursor desyncs. An AI can reason about the reconciler code and propose fixes, but it cannot see what the terminal renders. Every change meant manual testing: run it, look, find what broke elsewhere.

That was the pattern that wore me down. Every time the agent hit something it could not perceive, it fell back to inserting log statements and asking me to run it and report back. That works, but it is slow. When it happens repeatedly, something feels off: the agent is reasoning about the code, but you are its eyes. Every manual step costs more than the step itself. It breaks flow. When the bugs are deep and the iterations are many, the whole thing becomes a grind.

At some point I stopped trusting the codebase. Then I stopped trusting the agent. The project started feeling too big to hold — and worse, I had no clear sense of how long it would take to get to a point where I could trust it on real work. That uncertainty was harder to sit with than any specific bug.

I barely touched Acolyte for about a month. Some small fixes here and there, but nothing substantial. I needed to step away.

I'm giving a talk about the project at Future Frontend this week, which adds its own kind of pressure. I want Acolyte in good shape when people try it after the talk. But the conference comes first, and I'm not going to rush back into shipping just because there's a deadline. That's how I got here.

The path back isn't more features. Earlier in the project, when the codebase first grew past 18,000 lines, I stopped adding features and did a full manual review: read everything, mapped the connections, started understanding again. Same instinct now. But the question is harder: understanding the code is one thing. Whether the agent actually does what I want is another. Those are different problems.

Coding agents are getting better fast. The gap in capability is still real, but it is closing. At some point the tools I'm building with will be good enough to seriously help me build the tool itself. That day is closer than it was when I started.

What they do not provide is a clear idea of what the right tool should be. I've been building and breaking Acolyte long enough to have that. The capability gap closes on its own. The other one does not.

Acolyte is not dead. It's just been quiet. That's a different thing.