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 addresses all three by interacting with the environment before and after code generation within the execution stage.

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 in a chained pipeline. You approve the design (the architecture, the components, the integration patterns). After that, planning, probing, implementation, and verification flow continuously. When the environment exposes a classified problem, Camel-Kit attempts bounded code-level repair or design-level replanning. Skipped checks and unresolved failures are reported for user action.

This means:

• Earlier feasibility feedback — the probe can catch infeasible plans before code is generated
• Bounded automatic test diagnosis — classified failures route to the appropriate fix target within retry limits
• Explicit outcomes — fixes, skipped checks, unresolved errors, and escalations are recorded with context
• Design-derived test repair — when a test is classified as wrong, it is regenerated from the design specification

Error Taxonomy

Errors that match the taxonomy are classified and routed; unknown, complex, or persistent failures are reported or escalated. The classification determines which bounded repair is attempted.

Mechanical vs Architectural

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

For Camel component, dependency, and runtime failures, MCP is the catalog oracle that distinguishes mechanical from architectural. When a dependency fails, the probe queries camel_catalog_component_doc — 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. Docker image, port, and service failures follow the probe’s separate classification rules.

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: