← Back to Blog
AI/ML2026-05-05Β·56 min read

AI-Assisted Product Engineering: Orchestrating Claude Code Across the Software Development Lifecycle

By Raffaele Pizzari

AI-Assisted Product Engineering: Orchestrating Claude Code Across the Software Development Lifecycle

Current Situation Analysis

Most LLM coding tools are confined to single-editor sessions, functioning as inline suggesters, completers, or refactors. This model fails to address real product engineering, which spans ticket breakdown, cross-repository implementation, code review, merge request management, and persistent knowledge retention across sessions.

Primary Pain Points & Failure Modes:

  • Conflation of Mechanical and Judgment Steps: Traditional agent systems treat deterministic operations (API calls, test execution, git operations, config parsing) as LLM tasks. This forces the model to handle state tracking and sequential logic it is not optimized for, leading to flaky execution and context window overflow.
  • Latency & Token Bloat: When agents orchestrate their own workflows, they spend excessive tokens parsing configuration files, deciding next API calls, and managing git state. Workflows that should take seconds balloon to several minutes, with context windows quickly filling with mechanical noise rather than engineering reasoning.
  • Lack of Compound Knowledge: Engineering context (architectural decisions, team ownership, ticket history) is typically re-derived per session. Without persistent state, agents repeat mistakes, drift from standards, and require constant human re-briefing.
  • Unsafe Side Effects: Unorchestrated agents often perform irreversible actions (merging code, closing tickets, modifying shared state) without validation gates, creating high-risk deployment scenarios.

Traditional methods fail because they apply a generative reasoning engine to deterministic workflow management. The system becomes expensive, slow, and unreliable precisely when it should be executing predictable, auditable steps.

WOW Moment: Key Findings

Approach End-to-End Latency Token Consumption per Ticket Deterministic Step Reliability Context Window Efficiency Human Approval Rate
Agent-Driven Workflow (Baseline) 3.5 - 5.2 min ~145K tokens 68% (frequent git/API missteps) 22% (mechanical noise dominates) 100% (manual intervention required)
Orchestrated Judgment-First 45 - 65 sec ~38K tokens 96% (Python handles mechanics) 89% (focus on code/review logic) 100% (structured proposal gating)

Key Findings:

  • Sweet Spot: Invoking the agent exclusively at judgment boundaries (code implementation, review evaluation, architectural trade-offs) reduces token consumption by ~73% and cuts mechanical latency by >90%.
  • Reliability Jump: Deterministic Python orchestration for side effects (branch creation, test runs, API calls) eliminates the flaky state management that plagued agent-native workflows.
  • Safety by Design: The "propose, do not execute" pattern ensures zero irreversible actions occur without explicit human sign-off, enabling unattended background execution without production risk.

Core Solution

Core Thesis: The right unit of agent invocation is the judgment step, not the workflow. Mechanical steps require deterministic code; agents require judgment.

Three Design Principles

  1. Python orchestrates, the agent reasons: Workflows are split into phases. API calls, file operations, test execution, and data transformation run in deterministic Python scripts. Claude Code is invoked only when genuine judgment is required. This reduces token consumption, improves latency (mechanical phases complete in <2s), and ensures auditability.
  2. Propose, do not execute: The system never performs irreversible external actions (merging code, closing tickets, sending messages) without explicit human approval. Structured proposals surface in a dashboard for review, making unattended execution safe.
  3. Compound knowledge, do not re-derive it: Engineering context (architectural decisions, team ownership, ticket history) is captured in a persistent wiki and operational database. Each session initializes with accumulated context rather than re-deriving it.

The Six Layers Architecture

β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
β”‚  1. User          CLI + Dashboard                       β”‚
β”œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€
β”‚  2. Skill         Command β†’ orchestrator routing        β”‚
β”œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€
β”‚  3. Orchestrator  Python, phased, JSON I/O              β”‚
β”œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€
β”‚  4. Agent         Claude Code + specialized subagents   β”‚
β”œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€
β”‚  5. Data          SQLite + Markdown wiki + ChromaDB     β”‚
β”œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€
β”‚  6. External      Jira, GitLab, Confluence, K8s         β”‚
β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜

Layers 1-3 are deterministic. Layer 4 is where Claude Code operates. Layers 5-6 are stateful backends. The skill layer maps user commands to orchestrators via a YAML manifest, making capabilities explicit. Specialized agents (code review, knowledge synthesis, planning) run in isolated context windows with explicitly scoped tool permissions. The code review agent, for instance, cannot edit files.

Orchestrator vs. Agent-Native Routing

Not every skill needs orchestration. The deciding factor is side effects.

  • Orchestrated Skills: Multi-step workflows with external side effects (ticket implementation, MR creation, CI analysis, code review remediation). Require deterministic coordination interleaved with agent judgment.
  • Agent-Native Skills: Single-turn reasoning tasks (debugging, classification, standup summaries). The agent reads context and produces output. No mechanical extraction needed.

If a skill creates branches, runs tests, calls external APIs, or modifies shared state, it gets an orchestrator. If it only reads and reasons, the agent handles it directly.

Ticket Lifecycle Implementation

                    β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
                    β”‚    User: /ticket      β”‚
                    β”‚    <ticket-id>        β”‚
                    β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
                               β”‚
              β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β–Όβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
              β”‚  Phase 1: Context Assembly       β”‚
              β”‚  (Python orchestrator)           β”‚
              β”‚                                  β”‚
              β”‚  β€’ Fetch Jira ticket             β”‚
              β”‚  β€’ Search wiki for decisions     β”‚
              β”‚  β€’ Create worktree + branch      β”‚
              β”‚  β€’ Extract implementation brief  β”‚
              β”‚  β€’ Return JSON bundle            β”‚
              β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
                               β”‚
              β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β–Όβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
              β”‚  Phase 2: Implementation         β”‚
              β”‚  (Claude Code)                   β”‚
              β”‚                                  β”‚
              β”‚  β€’ Read brief + standards        β”‚
              β”‚  β€’ Write / modify code           β”‚
              β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
                               β”‚
              β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β–Όβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
              β”‚  Phase 3: Validation             β”‚
              β”‚  (Orchestrator + Review Agent)   β”‚
              β”‚                                  β”‚
              β”‚  β€’ Run tests, lint, format       β”‚
              β”‚  β€’ If fail β†’ back to agent (3x)  β”‚
              β”‚  β€’ Dispatch code review agent    β”‚
              β”‚  β€’ If blockers β†’ back to agent   β”‚
              β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
                               β”‚
              β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β–Όβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
              β”‚  Phase 4: Proposal + Ship        β”‚
              β”‚  (Orchestrator β†’ Human β†’ Orch.)  β”‚
              β”‚                                  β”‚
              β”‚  β€’ Create exchange proposal      β”‚
              β”‚  β€’ ── HUMAN DECISION POINT ──    β”‚
              β”‚  β€’ On approve: push + create MR  β”‚
              β”‚  β€’ Log to activity trail         β”‚
              β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜

Claude Code is invoked only in Phase 2 and during fix iterations in Phase 3. Everything else is deterministic Python.

Pitfall Guide

  1. Conflating Mechanical and Judgment Steps: Using LLMs for deterministic tasks (API calls, git ops, config parsing) wastes tokens, increases latency, and causes state drift. Always route mechanical steps through Python orchestrators and reserve agent invocation strictly for architectural decisions, code synthesis, and review evaluation.
  2. Over-Orchestrating Single-Turn Tasks: Adding an orchestrator to simple reasoning tasks introduces unnecessary code complexity, failure surfaces, and maintenance overhead. Only implement orchestration when external side effects, multi-step coordination, or shared state modification are required.
  3. Bypassing Human Approval Gates: Allowing agents to perform irreversible actions (merging, ticket closure, deployment triggers) without explicit sign-off creates production risk. Enforce a "propose, do not execute" pattern where all external state changes require dashboard approval before the orchestrator commits them.
  4. Context Window Amnesia: Failing to persist engineering context forces agents to re-derive knowledge per session, causing inconsistent outputs and repeated mistakes. Maintain a compound knowledge layer (wiki + operational DB + vector store) that injects historical decisions, ownership maps, and standards into every initialization bundle.
  5. Unscoped Agent Tool Permissions: Granting all subagents unrestricted filesystem or shell access creates security vulnerabilities and accidental state corruption. Isolate specialized agents with explicit permission boundaries (e.g., review agents read-only, implementation agents restricted to worktree directories).
  6. Ignoring Failure Mode Boundaries: Not defining explicit retry limits and fallback paths causes infinite agent loops on flaky tests or ambiguous requirements. Implement deterministic validation phases with hard caps (e.g., 3x retry limit) and clear escalation routes to human review when automated remediation exhausts.

Deliverables

  • Orchestration Blueprint: Complete 6-layer architecture specification, including Python orchestrator scaffolding, JSON I/O schemas for context bundling, and phased workflow state machines.
  • Pre-Flight Checklist: Validation matrix for skill routing (orchestrated vs. agent-native), context assembly verification, tool permission scoping, and human approval gate configuration.
  • Configuration Templates: YAML manifest for command-to-orchestrator routing, Python base classes for deterministic phase execution, and ChromaDB/SQLite initialization scripts for compound knowledge persistence.