← All writing

Two AIs Walk Into a Repo: My Hybrid Workflow with Claude and Jules

Let's be real: using AI for serious, production-level coding is still chaos. The dream is an agent that just builds. The reality is a mess of cumbersome chat…

Let’s be real: using AI for serious, production-level coding is still chaos. The dream is an agent that just builds. The reality is a mess of cumbersome chat UIs, context windows that snap shut, and a constant, low-grade paranoia about rate limits.

I was there. I used to rely on chat-based AI (mainly Gemini) to write code. It was a constant, high-friction loop of copy, paste, test, fail, re-prompt. It became a bottleneck, so I decided to take the plunge with Claude Code. After reading countless Reddit threads from developers getting rate-limited into oblivion, I knew I needed a sustainable workflow.

The problem is, you can’t just hand over the keys. Agentic AI, left unsupervised, will confidently drive your project off a cliff.

To make this work, I had to stop looking for a single magic bullet. Instead, I built a team. My workflow now relies on a hybrid model, treating different AIs as specialist members of my engineering crew:

  • Claude: The Senior Architect and Vision-Keeper.
  • Jules: The smart and ambitious Mid-Level Engineer.
  • Kilo code (and its models): The specialist “bench” for quick fixes.

Note on project management: I use GitHub for issue tracking and ensure each task is well-defined, with the necessary context and acceptance criteria.

Part 1: The Architect and Vision-Keeper (Claude)

In any functional engineering team, you need a senior member who not only understands the “what” and “why” but also safeguards the project’s integrity. For me, that’s Claude.

In my workflow, Claude pulls double duty.

Its first job is to be the primary driver of documentation. This is the most critical function. I use it to maintain:

  • The claude.md Constitution: A living document that details the project’s vision, architecture, key components, and strategic goals.
  • Product Requirements Docs (PRDs): Clear, unambiguous definitions of what we are building.
  • Mermaid Charts: Visualizing the system architecture and data flow.
  • The .claude/docs Folder: The home for all detailed architectural documents, acting as the deep-level reference for the entire system.

This collection of documents is the non-negotiable source of truth that the entire project (and every agent) must adhere to.

Its second job is to handle high-stakes new feature development. Because Claude is the one that manages the knowledge base and the “constitution,” I feel better using it for any novel development. It’s the agent that best understands the core vision, making it the right choice for writing the first draft of a new, complex feature that must align perfectly with the project’s architecture.

Its final job is Gatekeeper. I use Anthropic’s code review tool as the primary gatekeeper for any pull request targeting the main branch. It is the final, high-level check to ensure nothing violates the constitution.

Part 2: The Workhorse (Jules)

With the high-level vision, QA, and new feature-prototyping locked down by Claude, I still had a massive bottleneck: all the other work. The bug fixes, the refactoring, the implementation of existing patterns, the tasks that are less about vision and more about velocity.

I needed an “engineer” I could hand these tasks to, one who would respect the constitution and just… work.

This is where I introduced Jules, the most underrated player in the agentic coding space.

Jules is an AI agent that lives in your repository and works on your code in a secure, remote sandbox. Assign it a task (ideally a GitHub issue), and it dives in: reading files, writing code, and running tests within its isolated environment.

To bridge the gap between my Architect (Claude) and my new Engineer (Jules), I created a simple AGENTS.md file. This file acts as the “onboarding brief” for Jules, with instructions like:

“Read the claude.md file first to understand the project’s architecture and goals. Refer to it for any high-level decisions. You must also consult the detailed documents in .claude/docs if they are pertinent to the task.”

The first few tasks were rocky. Jules, like any new hire, fumbled. But then I discovered its killer feature: Jules learns.

To my pleasant surprise, Jules maintains a profile for each repository. Every time it completes a task, it adds “memories.” When it encounters a quirk in the build process, a specific way I like my error handling, or a dependency it needs to be aware of, it saves that note to its profile. You can also manually add your own directives to this profile.

It gets better over time.

This completely changed the game. I wasn’t re-explaining context on every single task. The agent was building project-specific institutional knowledge. My strategy became simple: start it with small bug fixes. As it learned the codebase, I ramped it up to medium-sized features.

Jules also runs an internal code review on its own changes before committing. Combined with Claude’s final PR review, this creates a powerful two-stage quality process.

Part 3: The jfix Alias: Wiring It All Together

Theory is great, but velocity comes from workflow. I live in the terminal, and I needed a way to assign tasks to my “engineer” without a dozen clicks.

I created a simple bash alias called jfix.

This script is the glue for the Jules part of my workflow. It lets me assign a GitHub issue to Jules with a single command: jfix <issue_number>. It fetches the issue from GitHub, formats it as a detailed prompt (reminding it to read the constitution), and pipes it directly to Jules to start working.

#!/bin/bash
# 'jfix' - Assign a GitHub issue directly to Jules

jfix() {
  # --- 1. VALIDATE INPUT ---
  if [ -z "$1" ]; then
    echo "Usage: jfix <issue_number> [optional: owner/repo]"
    return 1
  fi

  local issue_number="$1"
  local repo_override="$2"
  local repo=""

  # --- 2. DETERMINE REPO (Based on current folder) ---
  local dir_name=$(basename "$PWD")
  case "$dir_name" in
    puretome)
      repo="maxmillienjr/puretome"
      ;;
    puretome-ai-microservice)
      repo="maxmillienjr/puretome-ai-microservice"
      ;;
    puretome-e2e)
      repo="maxmillienjr/puretome-e2e"
      ;;
    *)
      if [ -n "$repo_override" ]; then
        repo="$repo_override"
      else
        echo "❌ Unknown repo directory. Specify manually:"
        echo "Usage: jfix <issue_number> <owner/repo>"
        return 1
      fi
      ;;
  esac

  echo "🔧 Fetching issue #$issue_number from $repo..."

  # --- 3. CHECK DEPENDENCIES ---
  if ! command -v gh &> /dev/null; then
    echo "❌ GitHub CLI ('gh') not found. Please install it."
    return 1
  fi
  if ! command -v jules &> /dev/null; then
    echo "❌ Jules CLI ('jules') not found. Please install it."
    return 1
  fi

  # --- 4. THE CORE LOGIC ---
  gh issue view "$issue_number" \
    --repo "$repo" \
    --json number,title,body \
    --template '
      {{.number}} - {{.title}}
      Fix the following GitHub issue.
      Read the claude.md, AGENTS.md, and .claude/docs files for project context and standards.
      Analyze the title, description, context, and any sub-tasks to provide a complete and actionable solution.
      ---ISSUE BODY---
      {{.body}}' | jules remote new --repo "$repo"
}

Part 4: The Mindset Shift (And Why Tests Are Everything)

Handing over the reins like this is anxiety-inducing, especially if you’re used to writing or reviewing every single line. To effectively use agentic workflows and embrace the velocity, you have to stop thinking at the code level.

You must check the work at a higher level of abstraction.

Your new job as a lead is to write high-quality, high-quantity tests. At a minimum, this means comprehensive unit and integration tests. For me, the real proof is End-to-End (E2E) testing. That is the only proof I need to feel confident that the core user flows are working.

My trust isn’t in the AI’s code. My trust is in my test suite. The AI’s job is to make the tests pass. My job is to write tests that are so brutal they can’t be “cheated.”

Part 5: The “Team” and The Failed Competition

Recently, I received free credits to use Claude’s new web-based coding environment. Frankly, I was disappointed. It would hang on tasks — even simple ones. I found myself constantly fighting it, and I quickly abandoned it to return to my Jules-Claude workflow.

The fact that my “team” members have human names helps, but it’s more than a gimmick. I am genuinely developing an intuition for task assignment, just as a team lead would:

  • Need to prototype a brand new, vision-critical feature? That’s a job for Claude.
  • Need to refactor five components to use a new data model? That is a perfect job for Jules.
  • Need a complex, tricky bug fixed in the auth service? I’ll probably do that myself.
  • Need to address minor code review items quickly? That’s where I use Kilo code.
  • Need to update all documentation and Mermaid charts? That’s back to Claude.

This is the system that works. It’s not magic. It’s engineering. It treats AI as a tool, as a specialist on a team, and not as a replacement for a brain.