The app that fixes itself: Tightening the feedback loop with agent orchestration

I've been building a personal knowledge base app- a read-it-later with feeds, digests from multiple sources, saved highlights. Simple, but something I've always wanted tailored for me.

As the sole alpha user, I feel every paper cut. A few weeks ago I added a ticket system to the app itself- A little form where I can report bugs and request features, while I'm using the thing. In my free time I'd direct agents at the tickets.

The next step became obvious quickly- wiring up an orchestrator to fix tickets without my intervention.

The Loop

Here's what my workflow looks like now:

1. I'm reading an article in my app. I hit Cmd+F to search for something. Nothing happens- my app intercepted the keystroke.
2. I open the ticket form, type "Don't override Cmd+F in reader mode," and submit.
3. A Firestore listener fires. The orchestrator picks up the ticket, spins up a Claude agent in an isolated git worktree, and points it at the problem.
4. The agent reads the codebase, finds the keyboard handler, fixes it, updates the ticket to "done" with a note explaining what it changed, commits to its branch, merges to master (via simple merge queue), and deploys.
5. My service worker picks up the new version. The app reloads.
6. Cmd+F now works.

I didn't switch windows, open a terminal, or review a diff. I filed a bug from inside the app and the app fixed itself.

This happened 25 times in one weekend. And these weren't all trivial fixes- some were substantial features:

• Text-to-speech listen mode with voice and speed selection
• Podcast transcript extraction and summarization
• Bluesky integration that pulls articles from people I follow
• A feed of popular Github projects on topics I'm interested in

Ascending to Stage 8

Steve Yegge's now-classic Gas Town post lays out an eight-stage progression of how developers adopt AI coding agents:

1. Zero AI, maybe autocomplete
2. Agent in IDE, asking permission for every tool call
3. IDE agent, YOLO mode, permissions off
4. IDE agent fills the screen, code is just diffs now
5. CLI, single agent, diffs scrolling by
6. CLI, multi-agent, 3 to 5 parallel instances
7. 10+ agents, hand-managed, pushing the limits
8. Building your own orchestrator

At the frontier, you stop managing agents and start building the system that manages them.

My work here isn't going full Gastown, but I see the progression. Manual management worked, but I was the bottleneck- the scheduler, the dispatcher, the babysitter. The tickets piled up faster than I could feed them to agents.

The need to remove myself from the loop and let the system go to work was painfully obvious.

What the Orchestrator Actually Does

It's about 300 lines of JavaScript. It uses the Claude Agent SDK. On startup it:

• Connects to Firestore and listens for tickets with status open
• Resets any orphaned in_progress tickets from crashed sessions back to open
• Maintains a pool of an adjustable number of concurrent workers

When a ticket comes in, it:

• Creates a git worktree so the agent works in isolation
• Spawns a Claude session with the full CLAUDE.md context
• The agent updates the ticket to in_progress as it starts
• If it needs clarification, it sets the ticket to waiting_for_user with a question, which shows up in my app's ticket detail view
• When I answer, the orchestrator resumes that exact session
• On completion, the agent merges its worktree branch back to master

The ticket system isn't just a task list- it's also the communication protocol. The agent writes status notes as it works. I can watch a ticket's history timeline update in real-time from the app. And because all state lives in Firestore - not in a running process - work survives failures. If an agent stalls or crashes, the orchestrator resets its ticket status and another worker picks it up, with the full history of what was already attempted.

Here's the orchestrator dashboard. An adjustable worker pool burning down a job queue.

And drilling into a single worker, you can watch the agent think through the problem- reading files, forming a plan, making edits:

Tightening the feedback loop

The traditional version of this workflow has about twelve steps: notice the bug, switch to terminal, open the file, understand the code, make the fix, test it, commit, push, deploy, verify. Each step is a context switch, friction.

The new version has three steps: notice the bug, describe the bug, verify the fix. Everything between "describe" and "verify" is automated; and, crucially, "describe" and "verify" happen with no context switches.

One of my tickets was "The bug/feature intake system incorrectly assesses bugs vs features. Bug reports are being labeled as features."

The system was misclassifying tickets, so I filed a ticket about it, and the agent fixed the classifier. The improvement loop can improve itself.

The next stage

When agents handle code generation this quickly, the bottleneck, as Maggie Appleton observed about Gas Town, shifts from implementation to design- the scarce resource becomes taste. Knowing which bugs matter. Describing features well enough that an agent can build the right thing. Having opinions about how your software should feel.

I spent the weekend reading articles, taking notes, and filing tickets from wherever I happened to be. The agents coded. The app got better. Feels like the future.

To be clear: the tightness of this loop doesn't fit all software. Guardrails, particularly human approval gates, are still important. But the direction is inevitable. The apps that win in this new world will be those that collapse the space between "user wants change" and "user gets change."