
Building a complex, multi-phase cloud project like a RAG migration is as much about orchestration as it is about code. You have to manage infrastructure (Terraform), backend services (Python), frontend UI (Next.js), data pipelines (BigQuery/AlloyDB), and documentation - all while maintaining a consistent technical strategy.
Standard IDE completions are great for snippets, but they lack the system-level context needed for this kind of engineering. To build this reference architecture, I didn't just use an AI to write code. I used an AI to orchestrate the entire project.
In this final post (see previous part 1 and part 2), I'll share a behind-the-scenes look at using Gemini CLI with the Conductor extension to orchestrate this migration.
In this post, you will learn:
Before we dive into the workflow, let's briefly discuss why orchestration is the next logical step for AI-assisted development.
Let's walk through my development process step-by-step. The entire specification, plan, and implementation logic is available in the conductor directory of the rag-migration repository.
Central to my workflow, is the Conductor extension. It's built on the principle of spec-driven development. Instead of jumping straight into code, we define the "source of truth" in Markdown files.
product.md): What are we building?
tech-stack.md): What tools are we using?
tracks.md): What are the major milestones?
plan.md for each of the tracks): What are the step-by-step tasks?
workflow.md): How are we building the solution?By having these documents in the codebase, the AI agent (Gemini CLI) always has the high-level context it needs to make smart decisions. It's also a good practice to share those with your team so everyone (including AI agents) is on the same page about the project's direction.
The first step for the project initialization is to create product definition and tech stack files. This is handled by running:
/conductor:setup
Gemini CLI will ask you a series of questions to help you define your project, including:
It will then create the initial project structure in the conductor directory, including the product.md and tech-stack.md files.
Each major feature in this project was implemented as a "Track". A typical track lifecycle consists of:
/conductor:newTrack):
spec.md file that describes the goals of the track
plan.md file that describes the steps needed to achieve the goals
/conductor:implement):
conductor/archive directoryFor example, when I started the initial embeddings track, I initialized it with:
/conductor:newTrack
Gemini CLI researches the codebase, asks clarifying questions and creates a spec.md and plan.md files. Only after I review and approve them, the actual implementation starts.
My product.md file instructs Gemini CLI to write Terraform code for all the resources created during the project. This works really well as all the resources are consistently managed by source code and it's easy to spin up a new environment when needed.
You can see all the Terraform files and infrastructure scripts used in the first track in the infra directory.
Moreover, in the course of the project creation I instructed Gemini CLI to always run terraform plan before terraform apply. Keeping this information in the workflow.md file ensures that such an approach is applied to all tracks.
One of the most powerful aspects of this workflow is AI-driven Test-Driven Development (TDD). I didn't just ask the agent to "write the code". It followed a strict protocol:
This ensures that the AI-generated code isn't just "syntactically correct" but functionally verified against my requirements. This workflow is described in the workflow.md file.
At the end of every phase, Gemini CLI runs a "Checkpoint" protocol. This includes:
git notes and update plan.md with the new commit hash.Conductor commits demonstrating the checkpoint protocol.
To achieve an effective AI agent-human development synergy I heavily depended on following solutions:
This approach provided safe guardrails and allowed me to jump into work on other projects while the AI was working on this one. I was always able to jump back quickly thanks to timely notifications. Moreover the checkpointing mechanism of Conductor allowed me to always have a possibility to revert unnecessary changes or to restart from a known working state.
I also used Antigravity to polish the generated code and the documentation. It was particularly helpful for minor tweaks or refactoring of the code that was generated by Gemini CLI.
Throughout the project I used several models (Gemini 3 Pro, Gemini 3 Flash and Gemini 2.5 Flash Lite). The total token consumption was:
Notice the high number of cached input tokens, which significantly impacts the spend. The total Vertex AI token cost was around $30. Not bad for several days of AI assisted work.
See the pricing page for more details and please mind that your mileage may vary.
Software engineering is evolving from writing code to orchestrating agentic workflows. By using tools like Gemini CLI and frameworks like Conductor, you can scale your impact as an architect while ensuring consistent, high-quality implementation.
Ready to build your own AI-assisted development projects?
If you found this article helpful, please consider adding 50 claps to this post by pressing and holding the clap button 👏 This will help others find it. You can also share it with your friends on socials.
I'm always eager to share my learnings or chat with fellow developers and AI enthusiasts, so feel free to follow me on LinkedIn, X or Bluesky.