Spec-Driven Coding Workflow: Claude-Led Planning and Gemini-Isolated Execution

One-sentence takeaway

When dealing with complex, long sessions and strict coding rules, a 4-step pipeline—where Claude Opus handles requirements decomposition and architecture auditing, Gemini 3.1 Pro executes single tasks in isolated new sessions, and Claude conducts final auditing and verification—effectively prevents Gemini 3.1 Pro from drifting on instructions or skipping steps, maximizing its advantages in high speed and low cost.

Use cases

• Suitable tasks: Complex feature development, large codebase refactoring, multi-module parallel implementation, and cost-effective agentic coding workflows under budget constraints.

• Unsuitable tasks: Attempting to have Gemini 3.1 Pro autonomously handle the entire end-to-end planning + coding + self-testing + documentation lifecycle within a single long session exceeding 50 turns.

• Applicable model versions: gemini-3.1-pro, gemini-3.1-pro-preview, paired with Claude Opus 4.6 / 4.7.

• Applicable clients, agents, or APIs: Google Antigravity, Gemini CLI, Cursor / Windsurf, and multi-agent orchestration frameworks.

• Recommended reasoning levels and parameters: Use thinking_level=high during the Gemini 3.1 Pro execution phase, keep the default temperature=1.0, and ensure that every subtask runs in a fresh, isolated session (New Session).

Ready-to-use content

Step 1: Discovery and Spec Decomposition (Handled by High-Planning-Capability Model)

Prompt template (run in the planning session):

You are a senior software architect. We will break down feature requirements through a 3-stage interview:
1. Clarification of business logic and edge conditions
2. Module decomposition and input/output contract design
3. Decomposition into fully independent, unit-testable micro-spec documents (<300 lines of code changes per spec)

Please output strictly formatted Spec Markdown files containing:
- Target file list
- Exact code signatures and type definitions
- Acceptance test cases and edge assertions
- Explicit negative constraints (strict prohibition against modifying any non-target files)

Step 2: Spec Safety and Side-Effect Audit

Prior to execution, verify the self-containment of the spec via static checks or architectural review models, generating an execution Context Artifact.

Step 3: Gemini 3.1 Pro Single-Task Isolated Execution

Prompt template (must be in a completely fresh session, fed only a single spec):

You are a focused code implementation Agent.
Strictly implement the target code based solely on the self-contained spec provided below.

<spec>
[Paste the content of a single micro-spec document here]
</spec>

Execution rules:
1. Strictly DO NOT refactor, modify, or reformat any existing code or files unrelated to this spec.
2. Strictly DO NOT skip writing test cases; you must implement test cases first, then implement the business logic.
3. If you encounter any undefined external dependencies, stop immediately and report an error—do not guess or introduce new dependencies on your own.
4. Output complete code files; do not use ellipses (...) or unimplemented placeholders.

Step 4: Independent Audit and Multi-Model Regression Verification

Place the generated artifacts from Gemini 3.1 Pro into an isolated verification environment to run automated tests and type checking. Strictly avoid having Gemini review its own output within the same session (avoid "guarding its own henhouse").

Test/workflow steps

1. Decompose the Epic into micro-specs (.md) through 3 rounds of interaction on the planning side.

2. Distribute the specs across separate, fresh Gemini 3.1 Pro sessions for parallel implementation.

3. Consolidate the code and run CI / typecheck and automated test suites.

4. Record task success rates, time elapsed, and token consumption.

Original evidence and data

• Real-world developer tests on the forum show that Gemini 3.1 Pro achieves extremely fast generation speeds and meets code quality standards when handling single-turn, highly focused, well-defined tasks.

• In long-running sessions and environments with complex prompt preambles containing ~4,000 words of rules, Gemini 3.1 Pro tends to skip planning and jump straight into coding, ignore negative constraints, etc. Session isolation brings single-task execution success rates back into a controllable range.

Applicability boundaries

• This workflow relies heavily on the clarity of upstream specs; if requirements are ambiguous, Gemini 3.1 Pro is prone to locking onto a flawed interpretation and rapidly producing non-compliant code at high speed.

• Strict session isolation is mandatory; never continuously dispatch new tasks in a "dirty" session accumulated with heavy historical debugging context.

Source excerpt or observation (compliance short quote only)

Developer YNd concluded: "Every small, testable step in a new session with detailed, dedicated instruction is the only way Gemini can work nearly properly... We moved to a 'Claude-led, Gemini-fed' pipeline."