JAIPilot CLI

Ship code generated by agents with confidence.

Install · Quick Start · Use With Coding Agents · Development

JAIPilot is a Java CLI for backend-assisted JUnit generation and zero-config verification. It can call the JUnit LLM backend to generate or fix tests, then run JaCoCo and PIT checks to validate the result.

---

With high-coverage, robust unit tests, you can let coding agents such as Claude Code, Codex, and Cursor work on your codebase with a much tighter feedback loop. Existing tests validate new changes quickly, and weak spots become visible immediately.

If your repository already has high line, branch, and mutation coverage, agents can use that test suite as a guardrail. New code can then be held to the same standard.

It is designed to work alongside Claude Code, Cursor, Codex, and similar tools. Agents can change code, run jaipilot verify, inspect weak coverage and surviving mutations, add or improve tests, and repeat until the project is well protected.

Why JAIPilot

• Backend-assisted JUnit test generation and fix flows
• Java verification for Maven and Gradle projects
• A test safety harness for AI-assisted coding and refactoring
• Actionable output with exact coverage gaps and mutation failures
• No changes required in Maven target project pom.xml
• Uses a temporary mirrored workspace for Maven verification instead of editing your repo

This follows the idea described in AI is forcing us to write good code: as AI makes code generation cheaper, strong tests become the safety system that keeps quality high.

Install

Install with:

curl -fsSL https://jaipilot.com/install.sh | bash

That installs jaipilot into ~/.local/bin by default, downloads the platform-specific release archive for your machine, and verifies the release archive SHA-256 checksum before unpacking it.

The installer is project-agnostic. You can run it from any directory, and it does not require Maven, Gradle, or an existing local JDK just to install the CLI.

The published installer bundles a tested Java runtime for supported platforms, so you do not need to provide your own local JDK just to run the CLI.

Bundled-runtime releases target:

• linux-x64
• linux-aarch64
• macos-x64
• macos-aarch64

Make sure ~/.local/bin is on your PATH.

Update

Update to the latest release with:

jaipilot update

Check without installing:

jaipilot update --check

Enable automatic startup installs when a new release is available:

jaipilot update --enable-auto-updates

Disable them again with:

jaipilot update --disable-auto-updates

JAIPilot checks for updates on startup for installer-managed installs. Set JAIPILOT_DISABLE_UPDATE_CHECK=true to skip startup checks entirely.

Quick Start

Run inside a Maven or Gradle project:

jaipilot verify

Generate a JUnit test by calling the backend API:

jaipilot login
jaipilot generate src/main/java/org/example/CrashController.java

Fix an existing failing test with build logs:

jaipilot fix \
  src/test/java/org/example/CrashControllerTest.java

Run with explicit thresholds:

jaipilot verify \
  --line-coverage-threshold 85 \
  --branch-coverage-threshold 75 \
  --instruction-coverage-threshold 85 \
  --mutation-threshold 80

Use a specific build executable:

jaipilot verify --build-executable /path/to/mvn

Recommended Agent Workflow

1. Run jaipilot verify once on the existing codebase to establish the current safety baseline.
2. Have your coding agent make changes and rerun jaipilot verify.
3. Let the agent inspect coverage gaps and surviving mutations, then add or improve tests.
4. Repeat until the project passes at your target threshold.

For many teams, that means starting above 80% for the existing codebase and pushing newly written code toward 100% line, branch, and mutation coverage.

Use With Coding Agents

JAIPilot works best as a tight generation-and-verification loop around an agent. Ask Claude Code, Cursor, Codex, or another coding agent to generate or fix tests with JAIPilot, then keep running jaipilot verify until the project passes with coverage as high as possible.

Example prompt:

Use `jaipilot generate` or `jaipilot fix` to update tests, then keep running `jaipilot verify` until you reach 80% (or 100%).

Why this works well with agents

JAIPilot gives coding agents a concrete feedback loop. Instead of guessing whether a change is safe, the agent can rerun verification, inspect coverage gaps and surviving mutations, improve tests, and iterate until the project is protected.

What jaipilot verify Gives You

• Progress updates while the command runs
• A final PASS or FAIL
• Exact coverage gaps from JaCoCo
• Exact surviving mutations from PIT
• Concrete next actions

JUnit LLM Commands

Sign in once before using the backend-assisted flows:

jaipilot login

jaipilot generate reads the class under test, infers the output test path and backend metadata, uses any existing test file at that path as the baseline initialTestClassCode, submits the request to invoke-junit-llm-cli, polls fetch-job-cli, follows any requested requiredContextClassPaths, writes the returned finalTestFile, then runs a local build validation (test-compile / targeted test for Maven, testClasses / targeted test --tests for Gradle). Before it starts, JAIPilot also checks that the rest of the project still compiles without the target test file, so unrelated compile failures stop the workflow immediately instead of burning fix attempts. After the targeted test passes, JAIPilot collects JaCoCo coverage for the class under test and keeps iterating through the backend fix flow until the configured coverage threshold is met or --max-fix-attempts is exhausted.

jaipilot fix does the same, but it starts from the current test class as initialTestClassCode, sends an empty CUT payload to the backend fix flow, and automatically captures the first failing local build or coverage feedback before calling the backend.

Authentication commands:

• jaipilot login starts the browser flow and stores credentials in ~/.config/jaipilot/credentials.json with owner-only filesystem permissions when the OS supports them.
• jaipilot status shows the current signed-in user and refreshes the access token if needed.
• jaipilot logout clears the stored session.
• jaipilot doctor checks the bundled runtime, trust configuration, proxy mode, and connectivity to jaipilot.com plus the backend.

Common options:

• JAIPILOT_JWT_TOKEN can be used instead of a stored login session.
• --output overrides the inferred test file path when needed.
• --build-executable, --build-arg, --timeout-seconds, --coverage-threshold, and --max-fix-attempts control the local compile-test-coverage loop after generation.

How It Works

For generate and fix, JAIPilot reads the local source files, calls the Supabase edge function, polls the async job endpoint, optionally resubmits requested context classes, uploads sanitized local build failure output when a fix pass is needed, and writes the returned test file into your project.

For verify, JAIPilot keeps the existing zero-config mirrored-workspace flow for Maven projects. For Gradle projects, it runs the standard test, jacocoTestReport, and pitest tasks from the project root, parses the generated reports, and prints a simplified summary for humans and agents.

Maven projects do not need JaCoCo or PIT configured in their own pom.xml. Gradle verification expects standard jacocoTestReport and pitest tasks to be available.

Requirements

• Java 17+
• A Maven or Gradle project
• JUnit 4 or JUnit 5 tests
• Maven available via ./mvnw or mvn, or Gradle available via ./gradlew or gradle
• A JAIPilot login session or a valid JAIPILOT_JWT_TOKEN for backend-assisted generate and fix

Current Scope

• Maven and Gradle build support
• JUnit 4 and JUnit 5 only
• The target repo is not modified
• Maven verification uses a temporary mirrored workspace and reuses PIT history from ~/.jaipilot/pit-history to speed up repeat runs

Development

Build and test locally:

./mvnw -B verify

Smoke-test the install path:

./scripts/smoke-test-install.sh

Contributing

See CONTRIBUTING.md for development setup and pull request expectations.

Security

See SECURITY.md for vulnerability reporting guidance.

Enterprise SSL / Proxy

JAIPilot ships with a bundled Java runtime, but some corporate networks still intercept TLS or require an explicit proxy. If you hit a certificate or PKIX-style error, run:

jaipilot doctor

JAIPilot supports these network overrides:

• JAIPILOT_TRUST_STORE=/path/to/truststore.p12
• JAIPILOT_TRUST_STORE_PASSWORD=changeit
• JAIPILOT_TRUST_STORE_TYPE=PKCS12
• JAIPILOT_USE_SYSTEM_CA=true
• HTTPS_PROXY=http://proxy.example.com:8080
• HTTP_PROXY=http://proxy.example.com:8080
• NO_PROXY=127.0.0.1,localhost,.internal.example.com

On Windows and macOS, JAIPILOT_USE_SYSTEM_CA=true lets JAIPilot try the native OS root store when the bundled runtime supports it. For locked-down enterprise environments, the most reliable option is usually a dedicated trust store that contains your company root CA.

License

MIT