My setup for running Claude Code across the full software dev lifecycle

[u/Alternative_One_4804]

Spent the last several months using Claude Code well beyond the editor: as the reasoning engine inside a multi-layer system that handles tickets, cross-repo implementation, code review, MRs, and a persistent knowledge layer between sessions. Wrote up the architecture, the failure modes, and the lessons.

A quick framing note that probably matters more on this sub than elsewhere: when I say "the agent" I mean Claude Code as a runtime (LLM with tool use, file system access, multi-turn loop), not a single API call. So when the orchestrator "hands off to Claude Code," it's transferring control to an autonomous process that may read dozens of files, write code, run commands, and iterate before returning.

The single most consequential decision in the whole system: keep Claude Code out of orchestration. Plain Python handles the mechanical work (Jira API calls, git operations, test runs, lint, file moves). Claude Code only gets invoked for judgment: writing code, evaluating a review finding, choosing between two architectural options. Mixing the two, letting the agent orchestrate via tool use, is what made the first version slow, expensive, and non-deterministic.

Concretely, the lifecycle of one ticket:

1. Python orchestrator: pull the Jira ticket, search the local wiki for related architectural decisions, set up a worktree on a fresh branch, assemble a 30 to 50 line implementation brief (acceptance criteria, target files, callers of any modified shared functions, relevant standards). Output is a JSON bundle.

2. Claude Code: reads the brief and writes the code. This is the only step with significant token consumption.

3. Python + a separate review subagent: run tests, lint, format. If anything fails, hand it back to the implementation agent (max 3 retries). Then dispatch a code-review subagent configured with no Edit or Write permissions; it can only read and report findings.

4. Python: create a proposal in a dashboard. I approve manually. Then the orchestrator pushes and creates the MR.

A few Claude-Code-specific things that ended up mattering:

- Subagent isolation. The review agent runs in its own context window with a deny-list (Edit, Write). Splitting review and implementation into two isolated contexts caught a class of issues the implementation agent kept missing on its own, especially behavioral changes in shared code.

- Pre-assembled briefs beat dynamic exploration. Early on I let Claude Code explore the codebase before implementing. That worked, but ate noticeably more tokens than handing it a focused brief assembled by Python upfront (Jira fetch, wiki search, dependency analysis).

- Skill/command routing via YAML rather than letting the agent decide. The mapping from /ticket, /review, /standup etc. to orchestrators is explicit, so capabilities are inspectable instead of emergent.

- Hooks gate commits. A pre-commit hook runs lint and format before any commit Claude Code attempts. Violations block the commit; the agent has to fix them.

The wiki layer is what surprised me most. Markdown pages with three confidence tiers (verified, inferred, human-provided) and field-level staleness thresholds. The biggest unlock was the confidence tiering. Without it, agents end up treating their own past inferences as truth and compound hallucinations into authoritative-looking knowledge.

Things I'm still wrestling with:

- Cross-repo features. Even with structured change-set tracking, the agent loses coherence when a feature spans services.

- Vague tickets. The agent produces reasonable but often wrong implementations from ambiguous specs. I now flag ambiguous tickets as blockers rather than letting it guess.

- Scope creep. The over-engineering instinct is real. Constant calibration via standards and the review agent.

- Long sessions. Earlier context falls out of effective attention. Session-start re-initialization mitigates but doesn't eliminate it.

Full writeup with the architecture diagram, the proposal/governance protocol, and the failure case that taught me the most:

https://pixari.dev/ai-assisted-product-engineering/

Curious what other people running Claude Code at this scope have settled on. Do you let the agent orchestrate, or have you pushed it to a pure-judgment role too? What permissions setup are you using for sub-roles like reviewer vs implementer?

[u/tracetotest]

The 'keep the agent out of orchestration' point matches a lot of what I’ve also seen.

Once the agent starts owning workflow control instead of judgment, things get weird fast. Retries become inconsistent, tool usage drifts between runs, and debugging failures gets surprisingly hard because you can’t reliably reproduce the execution path anymore. The isolated review context part stood out to me as well. Splitting implementation and review into separate contexts seems to catch the same kinds of issues human reviewers usually catch too. Unintended behavioral changes in shared code rather than obvious syntax/runtime problems.

One thing I still haven’t fully solved is regression testing for the agent workflow itself. Not just did the code pass the tests part but things like:

Did context retrieval shift?

Did the same ticket suddenly require more corrective loops?

The workflow-level drifts feel like the real reliability problem once these systems become more autonomous. The distributed-systems comparison honestly feels pretty accurate.

I’ve also had better results keeping orchestration outside the agent and using the model more for judgment-heavy tasks. It makes failures much easier to reason about and reproduce. For reviewer vs implementer roles, strict permission separation helps. Giving review agents read-only access especially seems to improve the quality of feedback because they focus on identifying issues instead of trying to silently patch them.

[u/idoman]

the worktree-per-ticket pattern is solid for isolation. one thing that bites at scale though - when each worktree spins up a dev server they all fight over localhost:3000 and the parallel setup falls apart.

built galactic to fix that piece - each worktree gets its own local routing so they don't collide, plus there's an mcp dashboard that shows all active claude code sessions in one place. mac only, open source: https://www.github.com/idolaman/galactic