Tickets That Are Tests

Most tickets are wishes. “Make the blog feel fresher.” “Fix the dashboard on mobile.” Somebody writes one, somebody else reads it, and the two of them never quite agree on what done means. With a human team that gap costs a conversation. With an AI agent it costs a confident pull request that solves a different problem.

So in xswarm, a ticket isn’t a wish. It’s a test.

The ticket is the spec

Every ticket that goes into the xswarm pipeline carries one to three scenarios, written in Gherkin before any code exists:

Given a new post at src/content/blog/13-tickets-are-tests.md
When a visitor opens /blog
Then the first article card has the heading "Tickets That Are Tests"

That’s the whole contract. No paragraph of intent for the agent to reinterpret, no “use your judgment”. If the scenario passes, the ticket is done. If it doesn’t, it isn’t.

Writing them is harder than writing wishes, and that’s the point. You can’t write Then without deciding what you’d actually see. Half the vague tickets I start never survive that step — and the ones that do are small enough to finish.

What the pipeline does with it

Once a ticket is queued, xswarm run takes it through the same stages every time:

1. Test first. The agent turns the scenarios into a real test and runs it. It has to fail. A test that passes before the code exists is testing nothing, and the pipeline checks the commits to make sure red came before green.
2. Code. The agent works in its own git worktree until that test passes, and only touches what the ticket names. Other tickets run alongside it on their own files.
3. Check. Lint, the full suite and the audits run after the agent stops — not by the agent’s own report of how it went.
4. Stage. The change deploys to staging and the end-to-end suite runs against the real thing, not a local build.
5. Ship. The exact commit that passed on staging is what gets promoted. Not a rebuild, not “the same branch”.

I don’t review diffs line by line any more. I review scenarios. If the scenario is right and the pipeline is honest, the code underneath is whatever made it pass, and that’s fine.

xswarm builds xswarm

This isn’t a demo setup. The dashboard, the daemon, the docs and this blog are built this way. This post went through it too: a ticket said the blog looked abandoned, three scenarios said what fixed looks like — a fresh post at the top of /blog, its own page with a dateline you can see, first in the RSS feed — and the pipeline wouldn’t call it done until a browser agreed.

When it goes wrong, it goes wrong in a way you can read. A failed ticket comes back with the scenario that failed and the evidence for it, not a summary that says “mostly working”. Sometimes the answer is that the scenario was wrong. That’s a real finding too, and a lot cheaper to fix than the code.

Why it works

AI agents are good at making things pass. That’s a problem when nobody wrote down what passing means, and the whole trick when somebody did.

Write the test first. Let the machine do the rest.