Environment-in-the-Loop

Code migration tools typically follow a linear path: analyze source code, generate target code, hope it works. When it doesn’t — a dependency that won’t resolve, a Docker service that won’t start, a component that doesn’t exist for the target runtime — the developer is left debugging alone. The AI agent finished its job and moved on.

Camel-Kit takes a different approach. The execution environment is not an afterthought — it’s a first-class participant in the code generation pipeline. Inspired by the Environment-in-the-Loop paradigm (Li et al., ReCode ‘26), camel-kit creates a closed feedback loop where environment signals actively drive code refinement.

The Core Insight

“Without automated environment interaction, the automation of code migration is only half complete.” — Li et al., ReCode ‘26

Traditional code generation treats the environment as static: generate code based on specifications, then verify at the end. This approach has three problems:

1. Late discovery of failures — dependency conflicts, missing runtime extensions, and service availability issues are only found after significant code has been generated
2. No automatic recovery — when the environment rejects the generated code, the AI can’t fix it without starting over
3. Disconnected testing — test generation happens independently of test execution, so tests are never iteratively refined based on actual runtime behavior

Camel-Kit solves all three by embedding environment interaction at every stage of the pipeline.

How It Works

The pipeline creates a continuous feedback loop between three concerns: code generation, environment verification, and test validation.

The Closed Loop

One approval gate. You approve the design (the architecture, the components, the integration patterns). After that, planning, probing, implementation, and verification flow continuously. If the environment discovers a problem, the system fixes it — either at the code level (self-repair, re-implement) or at the design level (re-plan).

This means:

• No wasted implementation work — the probe catches infeasible plans before code is generated
• No manual test debugging — test failures route automatically to the right fix target
• No silent failures — every error is classified, every fix attempt is tracked, every escalation includes context
• No stale tests — when tests are wrong, they’re re-generated from the design spec, not manually patched

Error Taxonomy

Every error discovered during probing or verification is classified and routed. The classification determines what gets fixed and how.

Mechanical vs Architectural

The probe and verify loop use an “assume mechanical, promote on failure” rule:

The key insight: MCP is the oracle that distinguishes mechanical from architectural. When a dependency fails, the probe queries camel_catalog_component — if MCP confirms the component doesn’t exist for this runtime/version, it’s architectural. If MCP returns a valid artifact with a different name, it’s mechanical.

How Errors Promote

Not every error reveals its nature immediately. The system uses a two-tier promotion model that mirrors how experienced developers think:

Fix Routing

Every classified error routes to a specific fix target. The taxonomy covers errors from both the probe (pre-implementation) and the verification loop (post-implementation):

What Makes This Different

Most AI coding tools follow a generate-and-hope model: produce code, let the developer figure out if it works. Some add a build check at the end. Camel-Kit goes further: