Why Java AI Coding Feels Slower and How to Build a Harness Environment in Five Steps

1. Where the Experience Gap Comes From

In lightweight projects such as front‑end tools or pure Python scripts, AI coding follows a fast local loop: edit → run → test → AI reads result → auto‑fix → verify, often completing dozens of iterations in seconds. In a Java micro‑service, the loop breaks because the code depends on OSS, remote sandboxes, HSF, TDDL, Diamond, etc., which are unavailable locally. The author describes a recent task where adding a new tool required pushing code to a pre‑release environment, waiting five minutes for deployment, manually inspecting NPEs, and iterating three times over half an hour, whereas a local project would finish in 30 seconds.

The gap is not the AI model or prompt but the lack of an AI‑friendly engineering environment, termed Harness Engineering.

2. The Root Cause

Java micro‑services heavily depend on cloud‑side infrastructure: HSF for service calls, TDDL for DB routing, Diamond/Switch for configuration, and MetaQ for messaging. An @Autowired may pull in an entire distributed stack that works in the cloud but cannot run locally, preventing AI agents from autonomously validating their output.

The typical workflow becomes:

Local Vibe Coding → Push to pre‑release → Human validates → Human feeds result back to AI → AI modifies → Repeat

Each step blocks on a human, unlike local projects where AI can iterate dozens of rounds unattended.

3. Five Refactoring Principles

1. Dependency Inversion, Interface First

Upper‑level logic should depend on abstract interfaces, not concrete cloud implementations. The author replaced direct OSS and sandbox calls with StorageAdapter and CommandExecutor interfaces, providing both cloud and local implementations. Example before refactor:

FilesystemService → OssStorageAdapter (calls OSS SDK)
AgentWorkspace → SandboxCommandExecutor (calls remote sandbox API)

After refactor:

StorageAdapter (interface)
├── OssStorageAdapter (cloud)
└── LocalStorageAdapter (java.nio.file)
CommandExecutor (interface)
├── SandboxCommandExecutor (cloud)
└── LocalCommandExecutor (ProcessBuilder + bash)

This allows the same upper‑level code to run unchanged while swapping implementations based on the active profile.

2. Zero Intrusion, Profile Isolation

Local code must not add extra branches to production paths. The solution uses Spring @Profile("local") beans for local implementations and @Profile("!local") for cloud ones, ensuring compile‑time invisibility of the opposite side. Component scanning excludes cloud‑only packages, and @Nullable parameters let Spring inject null when a bean is absent.

@Configuration
@Profile("local")
public class LocalRepositoryConfig {
    @Bean
    CommandExecutor localCommandExecutor() { ... }
    @Bean("localFsBasePath")
    String localFsBasePath() { ... }
    @Bean("sessionSequence")
    Sequence sessionSequence() { return new LocalSequence(); }
}

At runtime, null checks or profile mismatches automatically select the correct implementation without modifying production code.

3. Tool AI‑ification: CLI First

AI agents can only use command‑line interfaces. The author wrapped internal tools with mw-cli commands, e.g.:

# Query Diamond runtime config
mw diamond get --unit online --data-id application.properties --group DEFAULT_GROUP
# Query HSF service address
mw hsf address --unit daily --app my-application

A script scripts/fetch-switch-config.sh pulls Switch configuration from the pre‑release environment, parses JSON, and writes a local switch-config-local.properties file, making the data instantly consumable by AI.

4. Verification Scripts for AI

A Bash script scripts/verify-local.sh performs compilation, unit testing, health‑check, and a file‑system round‑trip test. AI can invoke this script after code changes to confirm the local environment works without human intervention.

#!/bin/bash
set -e
echo "=== 1. Compile ==="
mvn compile -q -Dspring.profiles.active=local
echo "=== 2. Unit Test ==="
mvn test -q 2>&1 | tail -5
echo "=== 3. Start Check ==="
timeout 30 mvn spring-boot:run -Dspring.profiles.active=local &
PID=$!
sleep 15
if curl -s http://localhost:8080/actuator/health | grep -q "UP"; then
  echo "✓ Local start succeeded"
else
  echo "✗ Local start failed"
  exit 1
fi
kill $PID 2>/dev/null
# File‑system closed‑loop test
TEST_FILE="/tmp/agentfs/$(date +%s)/verify.txt"
mkdir -p $(dirname $TEST_FILE)
echo "hello" > $TEST_FILE
if [ -f "$TEST_FILE" ] && [ "$(cat $TEST_FILE)" = "hello" ]; then
  echo "✓ File system closed loop OK"
else
  echo "✗ File system closed loop FAIL"
  exit 1
fi
rm -rf $(dirname $TEST_FILE)
echo "=== All Passed ==="

5. Harness Engineering Checklist

The checklist evaluates a Java project’s AI‑friendliness: can it start with a single command, does it have local substitutes for external middleware (H2 for MySQL, in‑memory queues for MetaQ), and are external dependencies abstracted behind interfaces switchable via profiles?

4. Practical Case: From Pre‑Release Validation to Local Closed Loop

The author refactored an AI Agent runtime platform. Original architecture used OSS for file storage, a remote sandbox for command execution, and Switch/Diamond for configuration. Locally, these were replaced with LocalStorageAdapter, LocalCommandExecutor, H2 database, and a generated switch-config-local.properties file.

After refactor, the workflow changed from a 5‑10 minute pre‑release cycle to a second‑level local loop where AI can read, write, and verify files directly. Benchmark comparison:

File operation verification: pre‑release via OSS console → now ls locally.

Bash execution: pre‑release sandbox → now local terminal.

AI autonomous verification: impossible → now ReadFile → verify WriteFile locally.

Iteration time: 5‑10 minutes (including deployment) → seconds.

AI autonomous fix rounds: 0 (manual each round) → average 3‑5 rounds auto‑converge.

The overall bug‑fix cycle dropped from >30 minutes and 3‑4 manual pushes to under 2 minutes with only a final human review.

5. Methodology Summary

The author distills five reusable lessons:

Find the Minimal Runnable Subset : Identify the core chain (request → LLM → tool → response) and only bring the necessary dependencies (DB, file system, command executor) locally.

Replace, Don’t Simulate : Use real H2 instead of a MySQL mock, real ProcessBuilder instead of a sandbox mock, ensuring local failures mirror production ones.

Script Every Manual Step : Convert UI actions (e.g., fetching Switch config) into CLI scripts that AI can invoke.

Layered Isolation and Verification : Verify compile, start, core interface, and end‑to‑end tests step by step, allowing AI to pinpoint issues at each layer.

Let AI Participate in Refactoring : After establishing the local foundation, let the AI generate adapters, scripts, and tests, creating a positive feedback loop.

6. Future Directions

Further work includes exposing JVM diagnostics as CLI tools (e.g., auto‑run jstack on timeouts) and ensuring test reports are structured JSON so AI can parse failures, locate source lines, and repair code autonomously.

7. Appendices

The article provides exhaustive lists of original cloud dependencies (OSS, remote sandbox, TDDL, Switch, Diamond, HSF, EagleEye, etc.) and their local replacements (java.nio.file, ProcessBuilder, H2, LocalStorageAdapter, LocalCommandExecutor, property files, component‑scan exclusions, and start‑local scripts).

Images illustrating architecture diagrams and checklists are retained: