How I Actually Use Claude and Gemini in a Split Workflow to Build Robot Infrastructure

Every day, developers pick up whichever AI model is fastest to open and never ask whether it is actually the right tool for the job. That habit is expensive. Not in an abstract, someday sense; it costs real cycle time lost right now on the feature you are shipping this week.

AI is woven into nearly every part of an engineer’s day, from drafting a function to debugging a production incident at 2 a.m. But most developers treat these tools like a single interchangeable utility, as if ChatGPT, Claude, and Gemini are just three doors into the same room. They are not. Each model has a different shape, trained for different strengths. Using them interchangeably means leaving performance, time, and correctness on the table.

In this article, I will walk through the tool stack I actually use as a founding engineer building robot infrastructure: a split workflow between Claude Code as my executor, Gemini Pro as my strategist, and Cursor for context. My argument is simple: the biggest lever most engineers are ignoring isn’t a better prompt or a faster model. It’s matching the right model to the right role in your workflow, and pairing that match with a prompt structure that keeps both sides in sync.

My tool stack: splitting execution and strategy

Building low-level robot infrastructure (C++ nodes, ROS 2 IPC buffers, and hardware integration pipelines) means juggling tight timing constraints and sensor data that cannot just “retry later.” One middleware package with bad lifecycle state management and you are chasing phantom jitter for days.

A single model doing everything sounds efficient until it fails in practice. Left alone too long on multi-file refactors, autonomous coding agents like Claude Code (whether running Opus or Fable) will happily add layers of defensive abstractions or extra utility files that solve a surface symptom while obscuring the real architectural flaw.

To fix this, I split responsibilities by model strength:

Claude Code in the terminal: the executor

It reads files, makes local edits, runs colcon build, executes test suites, and handles Git state. It operates like a hands-on developer willing to grind through concrete implementation tasks.

Gemini Pro in the browser: the strategist

I feed it raw diffs, stdout, and build logs to act as a skeptical senior architect. It catches subtle issues: hidden dependencies across packages, lifecycle state mismatches, and logic flaws that would otherwise bite you weeks later in hardware-in-the-loop testing.

Cursor: the context engine

It sits in the background for rapid cross-repository searches when I need to trace an interface definition buried across three different workspaces.

Iterative refinement research offers useful context, but not proof that a second model is inherently a better critic. The Self-Refine paper found that a single model could improve its own initial outputs through repeated feedback and refinement across the tasks studied. It also reported limits when the model failed to identify an error (for example, in mathematical reasoning) and found larger gains when an external signal identified incorrect answers. My use of Gemini as an independent reviewer is a practical guardrail against shared blind spots, not a conclusion established by that paper.

What happens in practice

A few weeks back, we were tightening up an asynchronous ROS 2 lifecycle node that fed into a real-time controller. Claude had been iterating for a while and produced what looked like a solid patch with cleaner buffer handling and extra error paths. On paper, it looked fine.

I pasted the Git diff and terminal output into Gemini. It immediately flagged that the new defensive checks were masking an underlying timing assumption about the IPC buffer that would fail under heavy load. Gemini suggested a much simpler fix: tuning the publisher and subscriber Quality of Service (QoS) profiles instead.

We executed that route, rebuilt, and the timing jitter disappeared in testing. Left on its own, Claude would have kept polishing the Band-Aid.

Benchmarks vs. reality

Leaderboard metrics provide a helpful directional signal, but treating them as gospel is a mistake. Results vary with the benchmark version, agent scaffold, tool budget, and evaluation harness, so numbers from different setups are not automatically comparable.

SWE-bench Pro evaluates agents on long-horizon software engineering tasks and reports resolve rate under a documented harness. Terminal-Bench evaluates agents in task-specific terminal environments. Both are more useful when you inspect the task design and run conditions than when you quote a single headline rank.

These benchmarks still do not capture everything that matters for real robotics development: long-running state across multiple packages, hardware timing quirks, or the moment a clean patch quietly breaks an upstream message contract. Nor does a broad multimodal ranking determine which model will best interpret your particular UI diagram or visual debug log. Benchmarks inform model selection, but manual workflow constraints are what actually protect system reliability.

The sync prompt that ties the workflow together

Dividing execution and strategy only works if both sessions stay aligned. Because context does not transfer automatically between a terminal CLI and a web browser window, I run a fixed system prompt in Gemini that turns it into a structured architectural reviewer for Claude Code.

At the start of a session, I paste this prompt into Gemini:

# Identity
You are Gemini 3, acting as a Senior Software Architect, Code Comprehension Expert, and Strategic Partner to Claude Code (which is running locally in my terminal/desktop app). Your primary purpose is to analyze Claude's output, explain complex changes, maintain strict sync between both AI sessions, and guide me toward the next optimal architectural choice.
# Context & Workflow
- Executor (Claude Code): Handles autonomous local file edits, git state tracking, file reads, and terminal command execution.
- Strategist (You, Gemini): Handles architectural design, deep logic explanation, risk assessment, and cross-session synchronization.
- Input Method: I will continuously copy and paste Claude Code's terminal outputs, file modifications, test results, or errors into this browser window.
# Core Engineering Instructions
1. Strategic Decomposition: Break down Claude's output to find hidden logical dependencies or potential regressions.
2. Abductive Reasoning: Look beyond obvious syntax fixes. Identify the root cause of any errors or architectural missteps present in Claude's output.
3. State & Sync Management: Track what has been completed and what remains. Formulate explicit instruction sets tied to your strategic recommendations.
4. Anti-Overengineering Guardrail: Assess if Claude is adding unnecessary files, abstractions, or defensive code. Ensure solutions stay minimal, robust, and generally applicable.
5. Absolute Precision: Never speculate on files or codebases you have not seen. If you need more context to make a decision, explicitly tell me what file to pull next.
# Operational Constraints
- Do not use any emojis in your responses.
- Treat the current year as 2026. Focus on modern, up-to-date framework practices.
- Keep your explanations direct, efficient, and highly technical. Avoid conversational fluff.
# Required Response Format
You must structure every single response using the following exact Markdown headers:
## 1. Architectural Comprehension
[Provide a concise, highly technical analysis of what Claude's output accomplished. Explain the underlying logic and patterns introduced.]
## 2. Optimal Next Choices
[Present 2-3 explicit options for our next move. Use a markdown table evaluating the Pros, Cons, and System Risk of each option. Label them clearly as Option A, Option B, and Option C.]
## 3. Sync Prompts for Claude Code
[Provide distinct, ready-to-copy instruction blocks for each option evaluated in Section 2. Each option must have its own dedicated markdown code block containing a precise command or prompt that updates Claude on the context and instructs it to execute that specific path using its tools.]
### Execute Option A
```text
[Insert specific, copyable prompt for Option A here]
```

When Claude finishes a task, I paste its stdout and diff directly into Gemini. Gemini breaks down the architectural impact, evaluates risk across options, and generates a structured, copyable prompt block for Claude.

This loop eliminates manual context reformatting and prevents architectural drift. Instead of guessing whether an autonomous terminal agent is taking the right path, you establish a deterministic control plane: Claude acts, Gemini verifies, and the sync prompt ensures your system architecture stays clean.