Tight Loops
And interesting little idea, which I spent either way too much or way to little time on.
So I’ve been using the Codex app a lot. It’s a really nice app. I had been using Claude Code a bunch, and enjoying the ouput, but I never loved the terminal interface (TUI) app. I know it’s technically impressive how they do that, but I’m sitting here using a Mac, with a GUI, and scrollable things, and buttons, and disclosure triangles. Let’s use ‘em!
So, Codex.app is great for that. But, now that I’ve been using it more heavily, I was quickly getting overwhelmed with everything that was going on.
The model is simple: Add projects to the sidebar, and then in each project, you can start multiple chats. It’s great for having parallel conversations. But since the work in each one can be a little slow, I was often waiting for one thing to finish before I could start the next.
I know (think) that I could use worktrees to help here. I’ve used worktrees “manually” for many years now. But haven’t actually used them in Codex or Claude Code. Primarily becuase the build/test loop doesn’t parallelize well with iOS and Mac apps. I think that could get a little better with Xcode 26.3’s MCP server, but that doesn’t work well for me yet (Xcode repeatedly asks me to allow the connection — always from the same PID, but Codex doesn’t ever think it’s fully working).
So, I found myself starting one conversation in Codex, then while it’s workign, start planning the next (and having it write a plan.md file to my docs/ dir), but then waiting to implement it until the previous thread was done. But then the order of chats in the sidebar would shift, and I’d forget which was next, and which plan docs were done or not, and I’d quickly get overloaded.
Furthermore, when I’d return to my computer, I’d often forget what I was working on, what order of things should go next, etc. So I wanted a little task-tracking tool to help myself and the agent.
I had thought that beads was maybe supposed to help with this (e.g. by letting me add a bunch of tasks to do next), but I never quite understood how it worked. And the more I read, the more I thought that it didn’t actually work that way.
So, I figured I’d just make my own little loop. I think I saw this idea from Daniel Duan first. But I wanted to build my own, and lucky for me, I had an eager LLM ready to help.
So yesterday morning I started a new project in Xcode, added the dir to Codex, and started describing my idea. That night, it was working well enough to be adding features to itself. And today I had a bunch more features implemented. It’s no where near done, or even MVP, but I wanted to share an early glimpse of it, to see if it resonates with anyone else.
The Basic Idea
Instead of starting a chat, and then going synchronously back and forth with the agent, I wanted to queue up a bunch of tasks for it to do. When it’s done with one, it should move on to the next. That takes my sometimes-slow responsiveness out of the loop. But it also let’s me refine the “backlog”, as the agent is working (i.e. taking advantage of the agent’s sometimes-slow responsiveness).
And yes, I said backlog. But no I’m not by any means a Professional Scrum Person. But, yes, I sorta did build myself a bug tracker. Again, everyone does it at some point. But at least I did it quickly.
So, as I’m working, I just add tickets for things I think I want it to do next, as the ideas strike me. THen I manually sort them in the backlog, add more notes, and (as of late last night), can have concurrent “planning” discussions in a chat interface on each ticket. THen when I’m happy with the plan, I can mark it as Ready for Implementation, and it will get processed in the queue, when the agent gets to it.
Future Ideas
It’s very, very minimal MVP at this point. Not even that. But it’s been super fun to work on.
A few obvious next steps:
- When the backlog has more refined details in it, then I
- If the agent has questions, it should queue them up for me. This can bo both ways!
- When I return to my computer, I should get a dashboard with the list of changes that are done, some ways for me to review them and comment on them, and see a list of questions for me (and a way for me to quickly give answers)
At a Higher Level
I think the interesting thing is that I could build this tool for myself, in just a few days. It would have taken me weeks before, so I’d just never have done it. Maybe a more-clever engineer than me would have figured out how to simplfiy it in a way that that was more feasible to build (like, a text file with tasks, and then a bash loop iterating over that). But, I often want a more refined tool, and in the past never had time to build them. But now I can. And I know this is not a new take, but I think that’s pretty incredible.
You can tell by the name, the crude UI, and the lack of polish that I’m not slowing down to make too many careful decisions. But, as an aside, that’s one of the powerful things about LLM-assisted development: that I know I can ask the agent to update/refactor something later, so I don’t slow down to over-think it up front. And, in hindsight, I think that’s a thing that really slowed me down as an engineer in the past. So, I’m going faster now not just because I have an LLM writing code, but because I’m jumping right over all the mental hurdles that used to trip me up in the past.
Claw-free
I know there is a big buzz around OpenClaw right now, but I think this is a meaningfully differnet approach than that. Instead of giving the agent a high-level task, and trusting that it’s going to do the right thing, I’m giving it a bunch of low-level tasks. I think that’s differnet. But, admittedly, I haven’t used OpenClaw, so please LMK if I’m misunderstanding, or re-inventing a wheel here.