Can a crew of Claude Code sessions handle small features in a Python backend?

Yes, Tares runs a crew of Claude Code sessions that turns small features in a Python backend into pull requests merged on main. Tares starts one builder per milestone and repo of the project, and each builder works its tickets on its own branch. A pull request merges once the reviewer passes it and CI is green.

How it works

You plan the features as a project. The plan holds a spec, milestones with acceptance checks, tickets with a working doc each, and an AGENTS.md. Tares keeps all of it, so the crew carries on where it stopped if it restarts.

The crew has these stations:

• Orchestrator: hands out work and is the only session you talk to.
• Builders: the orchestrator starts one per milestone and repo of your project, up to the number you allow. A Python backend in one repo with two milestones gets two builders. A second repo, such as a shared library, gets its own builder for each milestone that touches it.
• Reviewer: reviews every pull request to a fixed bar and posts its verdict on the pull request.
• Releaser: only if you ask for one. Without it, tickets end at merged on main.

Each builder takes a ticket, works on its own branch, opens a pull request, and merges it once the reviewer passes it and CI is green. Tares reads the pull request, CI and merge state of every ticket itself, so it needs its own GitHub access to the repo.

The gate on a pull request is therefore two checks: the reviewer’s verdict, and your CI being green. Whatever build and test steps your Python repo’s CI runs are what decide green. The milestone’s acceptance checks from the plan are what you verify at the end of each milestone. You can also set a project to wait for your yes before every merge.

For Python, tares factory doctor reads the repo’s manifests (pyproject.toml, setup.py, setup.cfg, Pipfile or requirements.txt, at the repo root or one folder down). It tells you whether Claude Code has a language server for Python, so builders and the reviewer can find definitions, references and callers. If one is missing, doctor prints what to run, and tares factory crew up offers the same install and runs it only when you say yes.

Set it up

The steps below are for a local Tares. For the full walkthrough, see Get started.

1. Check that Claude Code is signed in on a plan that allows background sessions. Check that gh is signed in with write access to the repos the crew works in, and that git, jq and curl are installed.
2. Install the CLI and start Tares.
3. In a second terminal, start the MCP endpoint every crew session shares.
4. In Settings > GitHub, add a GitHub token or App so Tares can read pull requests, CI and merge state.
5. Bring up the crew. The first run asks how far the crew may go: whether it merges on its own after review and green CI or waits for your yes, whether it releases, how many builders run at once, and anything you always allow.
6. In your Python repo, plan the features. Describe them in the quoted text.
7. Check the setup.

gh auth login
uv tool install tares     # or: brew install glassflow/tap/tares
tares up
tares mcp --transport streamable-http
tares factory crew up
tares factory spec "what you want to build"
tares factory doctor

Run tares mcp in its own terminal and leave tares up running. On Tares Cloud, run tares login instead of tares up and tares mcp, and choose Connect GitHub in your workspace settings.

tares factory spec opens Claude Code with /tares:spec. It interviews you one question at a time, has a second model attack the plan, and writes the project into Tares. It ends by asking whether to hand the project to the crew. Say yes and the orchestrator picks it up.

To answer the crew’s questions, run tares factory crew attach orchestrator. Follow progress on the Crew page at http://127.0.0.1:8787/crew.

What you get

• Features that arrive as pull requests, each reviewed to a fixed bar and merged only when CI is green.
• Builders matched to the shape of your work: one per milestone and repo, so parallel milestones move at the same time.
• A record on Tares of the plan, tickets, reviews, assumptions and your answers, written in your own words.
• Questions that reach you one at a time in the orchestrator’s session, each with a recommendation, so you spend your time on decisions and not on watching terminals.
• A written list of every choice the crew made on its own, which you can check at the end of each milestone.
• Tickets that can stay in Tares, in Linear, or in GitHub Issues. Sessions change them with their own tools and Tares only reads them.

When something else fits

• For one very small change, run tares factory session with your idea. It plans a small project and builds it in your own Claude Code session, still on Tares, with no crew.
• The software factory is for solo developers and very small teams on one machine, using your own Claude Code login and your own GitHub repos.

Related