Skip to content

Java · Spring Boot · Claude agents

Keep every Java service current. Without the heroics.

An orchestrated pipeline of Claude agents that upgrades Java and Spring Boot services consistently, safely and repeatably, with a human approving every step.

Quick start See how it works

Orchestrator Coordinates

  • Discover Collects
  • Determine Plans
  • Test Strengthens
  • Code Upgrades

01 · The problem

Every enterprise has that one service nobody wants to upgrade

  • Still on Java 8
  • Half its dependencies are past end-of-life
  • The person who understood the build left two years ago
  • The upgrade ticket is old enough to have an anniversary

Now multiply that by hundreds of repositories.

Why it never gets prioritized

The business sees

  • No new feature
  • No visible change for customers
  • "Fixes some vulnerabilities"

Engineering sees

  • Weeks of careful work
  • A risky, poorly tested build
  • A growing pile of CVEs

It sounds like a chore, so it loses to the roadmap every time.

What changed

Frontier models like Claude Mythos made finding vulnerabilities fast and cheap. In Anthropic's Project Glasswing, partners found:

10,000+ high and critical issues, in a single month

The bottleneck was not detection. It was verifying and shipping the patches.

The new reality

Finding the holes is fast now. Fixing them is the slow part.

If defenders find flaws at that pace, attackers will too. When a patch lands, how fast you can apply it depends on how current your stack is:

flowchart LR
    CVE([🚨 Vulnerability disclosed]) --> PATCH[📦 Patched library released]
    PATCH --> Q{Is your stack current?}
    Q -- Yes --> FAST[Bump version<br/>run tests<br/>ship]
    Q -- "No, 3 majors behind" --> SLOW[Forced migration<br/>you postponed for years]
    FAST --> SAFE([✅ Patched in days])
    SLOW --> RISK([⚠️ Exposed for weeks or months])

    classDef good fill:#1f6f43,stroke:#2ea043,color:#fff
    classDef bad fill:#7a1f1f,stroke:#f85149,color:#fff
    class FAST,SAFE good
    class SLOW,RISK bad

Staying current isn't hygiene anymore. It's how fast you can respond when it matters.

Upgrading one app isn't hard. Doing it consistently, safely and repeatedly across a portfolio is, and it eats senior engineering time.

02 · How it works

A controlled workflow, not one giant prompt

Not a single prompt that says "upgrade my app". Each agent has one job, and a human approves every phase before the next one starts.

  • Discover

    Collects a factual inventory of dependencies, versions, vulnerabilities and test coverage. Changes nothing.

  • Determine

    Plans the upgrade from that evidence, and scores whether your tests are strong enough to trust it.

  • Test

    Strengthens weak tests, round by round on its own branch, before anything is upgraded.

  • Code

    Upgrades Java, Spring Boot and dependencies, one verified commit at a time.

The Orchestrator ties the phases together, persists state between them and pauses for your approval. Nothing is merged or pushed: the result is a branch for your team to review.

03 · Why this approach

Tools do the work. The model does the thinking.

Most of the pipeline is deterministic. Anything with a known right answer is handled by proven tools, not worked out by the model each time. The LLM reasons only where there is a real need.

Deterministic

OpenRewrite

Recipes rewrite the Java code for the target Java and Spring Boot versions. The same migration, applied the same way, every time.

Deterministic

Bash and Python scripts

Run the Maven scans, reconcile dependencies and plugins, compute the testability score, track state and verify every build.

Judgment

Claude

Writes the plan from the reports, writes tests that assert real behaviour, and summarises each report for you to approve.

  • Fewer tokens, lower cost

    Reasoning is spent on judgment, not on work a tool already does reliably.

  • Reproducible

    Same input, same output. Scans, scores and rewrites don't vary between runs.

  • Reviewable

    Plans are approved before code changes. Changes land as small, verified commits.

  • Fast

    Scans run in parallel and the analysis scripts finish in seconds.

The model thinks only where there is a real need. Fewer tokens, lower cost, and results you can reproduce.

What it unlocks

Before After
Every upgrade done differently Same playbook every time
Long gap between patch released and patch deployed Shorter exposure window
Surprises discovered in the diff Plans reviewed before code changes
Test gaps found in production Test gaps found up front
"Why did we change this?" Audit trail of what changed and why
Seniors hand-editing pom.xml Seniors reviewing changes
An LLM reasoning through every step Tokens spent only on judgment

What it is not

Not a magic "modernize everything" button. Humans still approve the plan and review the PRs. The goal is to take the repetitive, error-prone work off people's plates, not the judgment.

Try it on your project

From zero to your first modernization run in three steps.

Quick start Meet the orchestrator