Theo’s AI Agent Workflow: Parallel Investigations, Review Loops and Safer Merges

Running companies and a YouTube channel has left me less time to code. I love the other work, but I miss solving hard problems and improving software I use every day. Recently I found a workflow that lets me contribute while handling the rest of my life.

My T3 Code chart rises from one to three merged PRs a week to 23, 37, 41 and then 52. The chart counts commits, but we squash merge, so I use it as a PR count. The week with 52 included travel to DEF CON. This is my own experience, not a controlled productivity study, and I do not expect every detail of the workflow to suit everyone.

Good agent tools help, but I have also changed T3 Code itself to support the way I work. A viewer reports that manually invoked skills work through a leading slash command but not through the dollar-sign picker. I had not encountered this bug myself, so I start an investigation.

I open a new thread and choose a remote Linux machine rather than making my laptop responsible for the job. The machine has my repositories, T3 Code server and agent harnesses, and I use a worktree to isolate the task. Worktrees are not perfect, but they are a useful enough abstraction for parallel jobs.

My prompt gives the agent context: real users are affected, and I want a fix that is simple to implement and easy to understand. I offer my opinion that a dollar-sign skill should work anywhere in the composer, but frame it as an opinion so the agent can challenge it. I also say what I do not know about Claude Code's behavior.

The actual request is an audit of Claude Code and our implementation. If it finds a simple solution, it should stop and report a confident path instead of exploring indefinitely. I clarify that I want a path, not necessarily code. Explaining priorities, uncertainty and stopping conditions helps the agent return information I can use.

Then I leave the thread alone. Watching a long-running agent feels productive but does not make it finish faster. Go do something else and return when there is a result. The complication is that I start so many threads that I can lose track of them, which is why I have built tools to manage the queue.

A contributor has opened a PR for usage-limit displays, but my CLI proxy setup means I cannot easily test normal authentication. I do not want to spend time rebuilding my environment only to discover an obvious defect, so I ask an agent to audit first. My aim is to reduce the frustrating moments that can break my focus and motivation.

The audit prompt gives the PR link and asks about API polling frequency, possible rate limits, correctness of displayed numbers and differences from other open-source implementations such as CodexBar. I ask for problems that could affect users if merged today, not merely a general thumbs-up. Voice transcription does not need perfect formatting for the model to understand the goal.

While the audits run, I show resource usage on my remote Linux box. I have run dozens of agents without saturating it, though heavy builds such as unbounded Rust compiles can consume substantial RAM. My experience is that Linux handles my parallel workflows better than macOS; hardware, workloads and environments will differ.

I also ask a cheaper model to inventory my open PRs: which are ready, which may need closing and which need another pass? I ask it to prioritize easy actions and use subagents to divide the work. I launch the same request with another model as well, so I can compare its recommendations rather than accepting the first list automatically.

T3 Code links a PR to its agent thread. When a linked PR merges, the thread can automatically move out of the active sidebar into a settled state; it can be restored later. I treat the sidebar as an inbox of work still needing attention, and snooze a thread when it matters but does not need action until later.

The skill audit returns three suspected defects: discovery ignores relevant skill settings, dollar syntax is sent to Claude untranslated, and a slash command only expands at the beginning even though the menu offers it elsewhere. This gives me useful context, but the proposed fix is hard for me to parse.

Instead of abandoning the work, I ask the agent to explain the solution in simpler language and connect each fix to the problem it addresses. That gives me permission to move to another finished thread while it rewrites the explanation. I also start a separate investigation when I notice a remote disconnection and a thread that did not mark itself done.

The usage-dashboard audit recommends holding the PR despite green CI. It identifies missing handling for rate-limit responses, frequent polling, a display of an unlimited window the API did not report, and overlooked local data sources. The model points to community reports of usage-limit requests failing; the suggested polling interval is an observation from that investigation, not an official guarantee.

The report is detailed, so I ask for a draft comment explaining the important issues to the contributor. I explicitly request the draft for my approval before it posts anything. The simpler explanation for the skill issue also comes back: the picker can offer disabled skills and sending a literal dollar-sign reference does not necessarily invoke a Claude skill.

I ask follow-up questions about how to communicate slash-command restrictions and whether the experience can be closer to Codex. For the PR comment, I correct the draft using what I know: a weekly Fable limit should be included, and locally cached Codex usage can be stale if the same account is used elsewhere. I want accurate data, not merely fewer requests.

After checking the revised direction, I authorize the agent to post the comment on my behalf. The contributor is also watching the stream. I can attach the existing PR to this thread and snooze it until the contributor expects to update it, so the conversation reappears when it is useful instead of occupying my immediate attention.

My babysitting skill automates a repetitive review loop. Once an agent files a PR, it watches for automated review comments, assesses whether they merit changes, pushes appropriate fixes and continues watching until the review cycle settles. Instead of manually copying each round of comments into the coding thread, I return when the loop is done.

The two PR-prioritization results also need judgment. One recommends a device-limit change that I do not want to merge yet because of infrastructure concerns, and another native iOS change that is more involved than the model suggests. I discard that list as unreliable for my purposes; another model's audit is still running. An agent recommendation is not the same as a merge decision.

Back at the skill issue, the agent explains that a translation layer could move a dollar-sign skill invocation into the position Claude expects, while raw slash commands retain their own restriction. It then tests whether multiple slash skills can stack in the SDK and reports that they do not work in the tested version, despite its reading of the documentation.

I ask it to search for existing reports rather than inventing a complicated workaround immediately. It finds an issue and I say a team member has confirmed the bug. For this particular case I allow the model to post a comment, identifying it as an agent acting on my behalf. I then snooze the thread until the following week.

I try to keep the active list short, with long-running work pinned. A SwiftUI version of T3 Code has been built largely in one long remote thread; it remains unmerged while I wait for another person's approval. Keeping a task visible does not make it ready to merge.

Testing must be easy before merging. For a file-upload change on a remote machine, I ask the agent to run our Tailscale share-dev command and return a URL with the pairing code. We improved bundling because the old dev server took 20–30 minutes to load on slow hotel Wi-Fi.

Through the remote preview, I drag in a non-image file and check that the agent can read the saved attachment. I then paste a screenshot to verify the image path: the harness renders the pixels directly, while the file is also saved. The experiment raises my confidence in these particular behaviors, although another audit suggests splitting the change further, so I do not merge it immediately.

For iOS, I use Swim to make a remote build available through a link I can open on my phone. It is convenient without a VPN, but it is not equivalent to a fully signed build: certain sharing and AirDrop permissions are restricted. It is useful for quick checks on the go, not complete coverage of every mobile behavior.

Desktop-only changes also need testing. I used to rely too much on web behavior, then found authentication redirects that broke only in the desktop app. I added a preview:mac PR label that triggers a macOS DMG build and supplies a download link, making it easier to try the change on a separate machine.

I tested on a mostly clean MacBook and discovered the artifact initially required GitHub authentication. Another change made the preview downloadable without signing in for this use case. A later build-signing optimization cut the overall build time by roughly a minute and a half; the displayed 81% reduction referred to signing calls, not total build time.

The repeated pattern is to find the friction that keeps you from reviewing, testing or merging, then improve the surrounding tools. Those investments made it easier for me to verify work while traveling. PR count is not a complete measure of software quality, but reducing the effort needed to test gives me more opportunities to make informed decisions.

Mistakes still happen, especially when we do not read every line. T3 Code uses a safety net: despite the name, nightly builds go out approximately every three hours to a few thousand users who opt into that channel. They know things can break and report problems before a stable release. This works for our particular audience; it is not perfect and will not fit every project.

Other teams might use a staged rollout, monitor a small percentage of users and roll back, or maintain a formal QA team. The common requirement is to catch and contain failures before they affect everyone. My phrase is 'safety nets, not guardrails,' but I am not arguing against tests: we have many tests and keep adding more.

De-risking merge has two sides. Before review, use investigations and automated feedback to raise confidence that a change is worth human attention. Then make it easy to test the behavior yourself and have a plan to detect and fix regressions after release. The point is not blind merging; it is reducing both the friction of checking and the consequences when checks miss something.

The inbox-like thread list, automated review loops, preview builds, human checks and a way to recover all work together for my team. These are examples of improving tools in response to problems, not a prescription that everyone copy my setup. I expect some parts of my workflow to look silly in six months, and I want to keep learning and changing it.