Juggling AI tools works, until it does not

This isn't a teardown. This stack is a genuinely reasonable way to start. An AI-first editor handles day-to-day writing. A terminal-based coding agent takes on tasks that need more autonomy: a full feature, a migration, a stubborn bug. A few scripts connect the pieces, trigger a run, and post a result somewhere. An observability tool checks what happened after the fact.

Every part of that is a real, capable tool. For the first few months, on a small team, it works. The failure mode isn't in any single tool. It's in what nobody built between them.

What's genuinely good about this stack

Key takeaway: The stack is fast to set up because it's built entirely from parts a small team already knows, no new infrastructure, no new vendor relationships.

An AI-first editor gives an individual developer a faster loop, inline suggestions, chat, and refactors; all inside the place they already write code. A terminal-based coding agent extends that further, handing off a well-scoped task and getting a working attempt back. Scripts are cheap and fast to write, a webhook here, a cron job there, and they let a small team automate the obvious repetitive steps without waiting on anyone else. An observability tool, pointed at the right logs, gives you a way to see that something ran and roughly what it did.

Where it breaks, and it's not the tools

Key takeaway: The trade-off shows up once more than one or two people depend on the stack at once, in three specific places: cost, review load, and shared knowledge.

• Cost nobody can explain. Each tool bills separately, on its own terms, at its own granularity. A script triggers a coding agent run. The run retries, or explores further than expected. Nobody sees that until the invoice, and even then, the invoice doesn't say which workflow, which repo, or which task actually drove the spend. The observability tool wasn't built to answer that question, it was built to watch infrastructure, not to attribute an agent's token spend to the decision that caused it.    
• Review load that outpaces the reviewers. The editor and the coding agent both make it easy to generate more code faster than one person used to write. Nothing in this stack changes who reviews it, or how. The review queue absorbs the difference, and it absorbs it unevenly. Whoever happens to be free reviews whatever happens to be next, regardless of how much scrutiny that specific change actually needs.    
• No shared playbook. Each script is written by whoever wrote it, for the problem they had that week. There's no common definition of what a workflow actually is, what should stop for a human, or what shouldn't. When that person is out or moves teams, the workflow they built moves with them, half-documented at best, in nobody else's head at all.

These aren't bugs in the editor, the agent, or the observability tool. Each was built to do its own job well. What's missing is the layer between them, and building that layer was never any of their jobs to begin with.

Worth naming honestly: a shared layer doesn't remove the judgment call of what counts as low-risk versus high-risk. That decision still has to be made by someone. What changes is where it lives, in a workflow definition everyone can see and reuse, instead of whichever engineer happened to write the script.

What a shared layer actually needs to do

Key takeaway: The fix isn't a fourth tool. It's a layer built from the start to be the connective tissue between the tools already in use.

The fix isn't a fourth tool bolted onto the other three. It's a layer built to be the connective tissue from the start: a defined workflow instead of a script, a human gate that's a real decision point instead of a queue everyone dumps into, and a record of cost and action attributed to the run that caused it, not reconstructed from an invoice weeks later.

Upsun Dispatch™ is built to be that layer. It doesn't replace the editor your developers write in, or the coding agent doing the heavier lifting. It operates independently of whichever one produced the change, triggered by the same repo events, running the workflow the rest of the stack was never designed to run, and recording what happened as it goes.

Read the Upsun Dispatch docs to see how the workflow and gate layer is actually built.

Frequently asked questions (FAQ)

Do we need to replace our existing tools to use Upsun Dispatch?     
No. Upsun Dispatch works alongside your stack, not instead of it. It runs its own workflows for planning, coding, and review against the tools you already use (GitHub, GitLab, Jira), it doesn't require you to give up your editor or coding agent to adopt it.

At what point does a scripts-based setup actually become a problem?     
Usually once more than a couple of people depend on it at the same time. A single developer's own scripts are fine for that developer. The gaps show up when review load, cost, and workflow knowledge all have to scale past one person.

Is this a criticism of any specific tool in that stack?     
No. Each tool does what it was built to do well. None of them were built to be the shared layer a team needs once several people rely on the same setup, and that's a different problem than any one tool failing at its job.