I'm working on a project to migrate Jenkins monitoring jobs from Groovy to Python SDK. The migration itself has progressed quite a bit, but I had 5 improvement issues piled up, each independent from the others, so I thought, "Maybe I can tackle these in parallel?"

I'd been curious about Claude Code's Agent Teams feature, so I decided to give it a try.

To be honest, it didn't work out as simply as "throw it to the agents and everything's done." But I did get a sense of how to use it effectively, so I'm recording what I've learned so far.

What I Tried to Do

I had 5 improvement issues for monitoring pipelines:

All of these shared a common theme: "properly migrate features from the old Groovy Jenkinsfile to the Python SDK side," and each was confined to a different job. This seemed well-suited for parallel processing.

How to Use Agent Teams

In the Claude Code terminal, I passed URLs for the 5 issues and instructed, "Please work on these with agent teams."

> Please work on these with agent teams.
  [issue URL x 5]
  Have each agent handle one of these issues.
  Check the issue contents with github cli.

The lead agent first checked the contents of each issue using GitHub CLI, then spawned 5 sub-agents.

graph TD
    Lead[Lead Agent] --> A1[aggregate-report-agent<br/>issue: Aggregate Report]
    Lead --> A2[aws-cpu-check-agent<br/>issue: CloudWatch Monitoring]
    Lead --> A3[metabase-check-agent<br/>issue: BI Integration Check]
    Lead --> A4[sqs-check-agent<br/>issue: Queue Monitoring]
    Lead --> A5[api-usage-check-agent<br/>issue: API Usage]

Each agent independently read the codebase, understood the issue content, and proceeded with implementation. The lead agent tracking progress was also helpful.

Implementation Phase: Smooth So Far

In about 10 minutes, all 5 agents completed their work.

Here's a rough overview of what was implemented:

Overall, 15 files changed: +1,154 lines, -63 lines. Committed as one, and up to this point, my impression was "Wow, this is impressive."

Verification Phase: Double-Checking to Be Safe

I paused here. "Implemented" and "correctly reproduced the old logic" are different things.

I used Agent Teams again, this time running 5 "verification agents." I instructed each agent to "check if the logic from Jenkinsfile.old is properly covered by the new implementation."

The verification results looked good. Code reduction averaged 87% (for the Jenkinsfile parts), functional coverage was fine. At this point, my judgment was "ready for production migration."

The Real Challenge Started Here

After merging and running on Jenkins, 4 jobs failed with the same error.

ModuleNotFoundError: No module named 'pandas'

...Oh, right.

Trap ①: Missing Dependency Declarations

The GCP-related analysis processing uses pandas and seaborn, but they weren't included in setup.py's install_requires. They were already installed in my local development environment, so I didn't notice.

And what was even more troublesome: unrelated jobs were also affected. The CLI's __init__.py imported all command modules at startup, so even jobs unrelated to GCP, like queue monitoring and BI integration checks, now required pandas.

I addressed this in two steps:

  1. Added pandas, seaborn, matplotlib to setup.py
  2. Implemented lazy imports (__getattr__) in __init__.py so modules are only imported when used

Trap ②: Circular Import in Lazy Loading

However, I messed up the lazy import implementation.

# What I wrote (NG)
def __getattr__(name):
    if name == "gcp_graph_helper":
        from monitoring_sdk.monitors.helpers import gcp_graph_helper
        return gcp_graph_helper

The problem is that monitoring_sdk.monitors.helpers is itself. from self import submodule triggered __getattr__ again, causing infinite recursion. I got RecursionError: maximum recursion depth exceeded.

The correct approach was to use importlib.import_module().

# Correct implementation
def __getattr__(name):
    if name in __all__:
        import importlib
        module = importlib.import_module(f".{name}", package=__package__)
        globals()[name] = module  # Cache
        return module
    raise AttributeError(f"module {__name__!r} has no attribute {name!r}")

To be honest, the agent's initial fix was insufficient, and I had to fix it twice.

Trap ③: Duplicate Parameter Management

Some jobs had parameter definitions remaining in the Jenkinsfile. I had designed Jenkins parameters to be centrally managed in the DSL file (Groovy), but the agent had added parameter blocks to the Jenkinsfile side during implementation.

Conversely, some parameters were missing from the DSL file. The agent might have judged that since it was written in the Jenkinsfile, the DSL wasn't necessary. This was an area where the agent didn't fully understand the project-wide parameter management policy.

Trap ④: OpenAI API Token Limit

In the CloudWatch monitoring job, the analysis result came back empty. Looking at the logs, I saw finish_reason='length' with an empty string for the response body.

max_completion_tokens was set to 2,500, but apparently that wasn't enough for analysis including an image (CPU usage graph). I raised it to 4,000 and resolved the issue.

While I was at it, I noticed that the config file had a temperature parameter that wasn't actually being used in the API call, so I removed that too. These "unused settings" are subtle sources of confusion.

Trap ⑤: Duplicate Data in Prompts

This was an issue the agent found. The prompt sent to OpenAI contained both "input data (raw data)" and "pre-analysis results," with largely overlapping content. A waste of tokens.

I removed the raw data and modified it to only pass the structured analysis results.

Looking Back at the Overall Flow

graph LR
    A[Submit 5 issues to<br/>Agent Teams] --> B[Implementation<br/>complete in ~10min]
    B --> C[Migration verified<br/>by verification agents]
    C --> D[Merge]
    D --> E[Production run:<br/>4 jobs failed]
    E --> F[Fix dependencies]
    F --> G[Fix circular import]
    G --> H[Migrate parameters]
    H --> I[Adjust token limit]
    I --> J[Confirmed working]

    style E fill:#f9d6d6
    style F fill:#fff3cd
    style G fill:#fff3cd
    style H fill:#fff3cd
    style I fill:#fff3cd
    style J fill:#d4edda

To be honest, the effort split between what the agents implemented (left half) and what I fixed myself (right half) felt about 50-50.

What I Learned from Using It

What Agent Teams Are Good At

Parallel execution of independent tasks is clearly a strength. Since the 5 issues were confined to separate files, there were almost no conflicts. The flow where each agent reads the issue, understands the existing code, and implements—this is much faster than a human doing it.

Code comprehension is also strong. They correctly identified missing features by reading the diff between the old Jenkinsfile (Groovy) and the new Jenkinsfile.

What Still Feels Difficult

Understanding project-wide design policies is a challenge. Rules not explicitly written in code, like parameter management policies (centrally managed in DSL), are easy to miss. I probably should have documented this in CLAUDE.md.

Seeing the full dependency graph also seems difficult. Predicting indirect impacts like "changing this module will affect another job through the import chain" is still more reliable when done by a human.

Differences from the production environment are information the agents simply can't see. Problems like "library exists locally but not in production" are structurally impossible for them to discover.

What I'd Change Next Time

Summary

Agent Teams dramatically increase "implementation speed." Completing 5 issues in 10 minutes is impossible for a human.

However, there's a gap between "implemented" and "works in production," and bridging that gap is currently human work. Dependency consistency, project-wide design rules, production environment-specific conditions—if you leave these entirely to agents, you'll regret it.

That said, the cycle of "agents implement → humans verify and fix" did work. Next time, I want to refine the instructions to agents to reduce the need for fixes.

Still in the trial-and-error phase, but that's where I am for now.

Further Reading: Deepening Your Claude Code Knowledge

For practical usage of Agent Teams, the following book is a valuable reference.

[📦 商品リンク: moshimo-book-9CeFY]

If you want to deepen your understanding of AI-driven development methods in general, these resources are also helpful.

[📦 商品リンク: moshimo-card-HD5Yl]

[📦 商品リンク: moshimo-card-tP9XC]