Code-as-Policies Framework for Systems

• Code-as-Policies (CaP) involves synthesizing executable code from language models, creating interpretable and editable policies for robotic and software systems that directly handle sensory inputs to determine actions.
• CaP supports both reactive and waypoint-based approaches in robotics, allowing for direct code execution on platforms like UR5e and Everyday Robots, and can generate policies for tasks like obstacle avoidance and precision maneuvers by integrating deterministic code operations and reusable functions
• Applications of CaP extend to governance, infrastructure compliance, and decision-making, such as Prose2Policy translating natural language into executable Rego for Open Policy Agent, achieving 95.3% compile rate on access control me.

Code-as-Policies (CaP) is a paradigm in which a LLM generates executable programs that function as policies for an embodied or software-controlled system. Instead of producing only a plan, a sequence of discrete actions, or a direct motor command, the model synthesizes code that processes observations, invokes available interfaces, computes parameters, maintains state, and determines subsequent actions. The resulting program may be executed directly by a robot, evaluated against infrastructure, compiled into a governance engine, or searched and refined through environmental feedback. CaP therefore occupies an intermediate position between high-level language planning and end-to-end policy learning: the policy is an inspectable program whose logic explicitly connects language, perception or state, computation, feedback, and action.

1. Conceptual foundations and scope

The defining characteristic of CaP is that executable code is treated as the policy itself rather than merely as an implementation of an externally specified plan. In the original robotics formulation, a Code-as-Policies language-model program reacts to perceptual inputs, parameterizes low-level control primitives, and is compiled and executed directly on a robot (Liang et al., 2022). A program such as a while loop that repeatedly checks whether an object is visible and changes robot velocity accordingly is a reactive policy because its actions depend on ongoing feedback rather than on a single prediction.

CaP differs from several adjacent paradigms:

• High-level language planning produces textual steps such as “pick up the can, move right, and place it.”
• End-to-end action prediction maps language and observations directly to motor commands through learned representations.
• Skill selection chooses among a predefined vocabulary of capabilities.
• Code-as-Policies generates a program containing control flow, arithmetic, state, API composition, and feedback logic.

The representation can include sequences, branches, loops, functions, memory, geometric operations, and calls to external libraries. In robotics, the generated code may invoke perception APIs, NumPy or Shapely operations, motion primitives, inverse kinematics, gripper controls, navigation, or trajectory execution. In systems, it may implement a cache heuristic or congestion-control callback. In access control, it may be Rego evaluated by Open Policy Agent. In online governance, a declarative policy may be compiled into PolicyKit-compatible Python.

The broad computational pattern is:

$$\text{natural-language requirement} \rightarrow \text{structured or executable policy} \rightarrow \text{environmental evaluation} \rightarrow \text{action, authorization, or adaptation}.$$

The term is consequently used across several distinct settings. These settings share the use of executable policy artifacts but differ in whether code is generated at runtime, compiled from a declarative representation, synthesized offline through evolutionary search, or statically verified through a type system.

2. Embodied policy synthesis

2.1 Perception, computation, and control

The foundational robotics system uses few-shot prompting: natural-language commands are represented as Python comments, while demonstrations pair commented instructions with valid implementations. Hints expose the programming environment, available APIs, informal types, coordinate conventions, and third-party libraries. The model then completes code for a new command, generally using OpenAI Codex code-davinci-002 with greedy decoding and temperature $0$ in the reported experiments (Liang et al., 2022).

A typical architecture contains:

1. a natural-language interface;
2. language-model program generation;
3. perception modules;
4. geometric and symbolic computation;
5. embodiment-specific control primitives; and
6. runtime execution.

The perception layer may expose object names, positions, bounding boxes, segmentation masks, and visibility. The original experiments use MDETR for tabletop manipulation and whiteboard drawing and ViLD for mobile manipulation. RGB-D data and calibrated camera-to-robot transformations convert visual detections into robot-frame coordinates.

Generated programs can use ordinary Python and libraries such as NumPy and Shapely to perform vector addition, comparisons, sorting, interpolation, averaging, distance calculations, shape construction, and coordinate transformations. This allows language to be translated into spatial-geometric computation rather than only into symbolic action names. The system demonstrated tabletop manipulation, whiteboard drawing, mobile navigation, mobile manipulation, and reactive controllers on UR5e and Everyday Robots platforms.

2.2 Hierarchical code generation

A central mechanism is hierarchical code generation. The model may write a high-level program that calls functions not yet defined. An auxiliary language-model program then generates the missing functions recursively. The procedure is:

1. generate a top-level code block;
2. parse its abstract syntax tree;
3. identify undefined function calls;
4. generate missing definitions;
5. add them to the execution scope;
6. recursively inspect their bodies; and
7. repeat depth-first.

This converts functional decomposition into an executable analogue of chain-of-thought prompting. Rather than emitting only an informal reasoning trace, the model decomposes reasoning into helper functions that can be inspected and executed.

Hierarchical generation improved RoboCodeGen pass rates from 81% to 95% for Codex davinci and from 68% to 84% for GPT-3 175B. On HumanEval, hierarchical generation achieved 39.8% P@1, compared with 34.9% for the corresponding flat setting (Liang et al., 2022). The reported improvement was especially pronounced for problems requiring longer programs and multiple abstraction layers.

2.3 Closed-loop and geometric behavior

CaP supports both waypoint-based and reactive policies. A reactive controller can repeatedly query perception, compute a target, invoke a primitive, and re-perceive the world. Generated programs include cart-pole proportional-derivative control and end-effector impedance control. The latter computes an end-effector error, maps stiffness and damping terms into a Cartesian force, and transforms it through a Jacobian into joint torques. The demonstrated controller works in PyBullet for a UR5e but omits gravity and Coriolis compensation.

Waypoint-based policies generate trajectories for drawing, pick-and-place, navigation, and mobile manipulation. Generated code can construct circles, convex hulls, lines, polygons, and transformed trajectories. The same language instruction can produce different programs on different robots if the prompt exposes different action interfaces.

The original code-reasoning benchmark reported 98% overall accuracy for code reasoning, compared with 58% for chain-of-thought prompting and 35% for vanilla natural-language reasoning. The reported interpretation is that Python and NumPy provide deterministic mechanisms for comparisons, vector operations, distances, and interpolation (Liang et al., 2022).

3. Declarative governance and policy-as-code systems

CaP also includes systems in which users author policies through a structured representation that is later compiled into executable code. Pika applies this design to online-community governance. It provides a declarative language, a library of modular policy components, and a form-based web interface for non-programmers (Wang et al., 2023).

Pika decomposes governance policies into:

• base actions, such as renaming a channel, inviting a user, posting a message, granting a role, or editing a document;
• filters, which restrict action fields;
• base procedures, such as consensus voting, juries, benevolent dictatorship, majority voting, ranked voting, quadratic voting, or liquid democracy;
• decorators, which modify procedures through time limits, reminders, or voting requirements; and
• executions, which perform actions after a procedure outcome.

Its conceptual data flow is:

$$\text{component settings} \longrightarrow \text{component variables} \longrightarrow \text{compatible settings of later components}.$$

Variables carry context between components. They may represent a triggering channel, selected jurors, candidate users extracted from a command, or the final number of affirmative votes. Typed settings and entity-aware controls allow a readable channel such as #general to be selected instead of entering a raw platform identifier.

The completed declarative policy is compiled into PolicyKit-compatible Python. PolicyKit monitors platform events, identifies matching actions, orchestrates asynchronous procedures such as voting, evaluates outcomes, and executes approved operations. Pika therefore separates policy representation, grounding, compilation, verification and control, and deployment.

Pika’s user studies involved 10 non-programmers and 7 programmers. Nine of ten non-programmers completed the first governance task, and seven of nine completed the second. Programmers authored policies more quickly with Pika than with PolicyKit code: the reported average times were 3.6 and 4.4 minutes with Pika versus 19.9 and 21.6 minutes with PolicyKit, with $p<0.01$. The paper summarizes this as an approximately 2.5-fold authoring-speed improvement (Wang et al., 2023). These results measure authoring efficiency and perceived workload, not long-term correctness, fairness, or governance quality.

3.1 Natural-language access policies and Rego

Prose2Policy translates natural-language access-control policies into executable Rego for Open Policy Agent. Its pipeline performs policy detection, coreference resolution, text segmentation, DSARCP component extraction, schema validation, Rego generation, Regal linting, OPA compilation, automatic test generation, and test execution (Gupta et al., 16 Mar 2026).

DSARCP represents:

• Decision;
• Subject;
• Action;
• Resource;
• Condition; and
• Purpose.

The intermediate representation makes the interpretation of prose explicit before synthesis. Organization-specific JSON schemas constrain the vocabulary of subjects, actions, resources, and attributes. Missing essential fields cause rejection rather than silent invention.

On the ACRE dataset, 485 access-control statements were processed and 389 were accepted as valid natural-language access-control policies. Of those, 371 compiled successfully, giving a 95.3% compile rate. Automated LLM-generated tests achieved an 82.2% positive-test pass rate and a 98.9% negative-test pass rate. Rule-based tests achieved 62.1% and 97.1%, respectively (Gupta et al., 16 Mar 2026).

Compilation and testing do not establish semantic equivalence between prose and Rego. Automatically generated tests may share interpretation errors with the generated policy, and the evaluation did not provide direct expert comparison against authoritative Rego. The system is therefore a policy-generation and validation workbench rather than a complete semantic-verification system.

3.2 Infrastructure compliance

ARPaCCino applies an agentic Retrieval-Augmented Generation pipeline to Policy as Code for Infrastructure as Code. Given a natural-language requirement, it retrieves OPA, Rego, Terraform, and provider documentation; synthesizes Rego; checks it syntactically and semantically through tools and an external domain expert or oracle; evaluates Terraform plans; and modifies non-compliant infrastructure (Romeo et al., 11 Jul 2025).

Its workflow is:

1. retrieve policy-language knowledge;
2. generate Rego;
3. check the rule;
4. preprocess infrastructure with Terraform;
5. evaluate the plan with OPA;
6. retrieve infrastructure knowledge when violations occur;
7. modify Terraform;
8. re-plan and re-evaluate.

The evaluation used five Terraform-ProxMox prompts and compared LLM-only, RAG, and agentic-RAG configurations. Qwen3:30b and GPT-4o produced zero syntactically correct rules in the LLM-only and RAG settings but achieved 4/5 and 5/5 syntactically and semantically correct policies, respectively, with Agentic RAG. Claude Sonnet 4 achieved 5/5 in all three configurations.

The paper distinguishes syntactic validity from semantic validity. opa check can establish that a rule parses, but not that it checks the intended field or expresses the natural-language requirement correctly. Automated semantic verification is identified as future work.

4. Formalization, verification, and reliability

4.1 Policy as Type

“Policy as Type” strengthens the policy-as-code idea by representing a policy as a dependent type rather than merely as an executable predicate. In this formulation, an authorized action is a well-typed value, while an unauthorized action lacks an inhabitant of the required type (Fuchs, 2 Jun 2025).

A conventional policy can be viewed as a predicate over a right, accessor, object, and environment:

$$P(\mathit{right},\mathit{accessor},\mathit{object},\mathit{environment}).$$

Policy as Type instead represents a proposition such as $\mathsf{SafeAction}\;a$ as a type indexed by the action $a$. Code that performs the action must receive a value carrying evidence that $a$ satisfies the policy.

The paper implements examples in Agda using dependent vectors, equality types, ordering propositions, server-configuration policies, and attribute-based access control. A function such as safeCall requires dependent pairs containing both an object and a proof that the object satisfies the relevant policy. An unauthorized request cannot be passed to the protected operation through that function unless a proof term exists.

This approach supports compile-time invariants, decidable policy checks, regression proofs, and explicit modeling of trusted external claims. It does not establish that external databases, clocks, identity providers, network services, or credentials are truthful unless those assumptions are modeled and verified. It also requires specialized expertise, proof construction, terminating computations, and suitable strategies for maintaining proofs.

4.2 Neuro-symbolic embodied verification

NeSyRo extends embodied CaP with symbolic verification and interactive validation (Ahn et al., 24 Oct 2025). Standard CaP may generate syntactically valid code that assumes unobserved facts, violates symbolic preconditions, or attempts an impossible action. NeSyRo first generates a symbolic specification and checks it against a domain model containing actions, predicates, preconditions, and effects.

It then evaluates each generated skill through a Neuro-Symbolic Confidence score:

$$\mathrm{NeSyConf}_{f_n} = \mathrm{CSC}_{f_n}\times \mathrm{LC}_{f_n}.$$

Here, $\mathrm{CSC}$ is an LLM-derived common-sense confidence and $0$0 is a logical-consistency measure. A skill is accepted only when its score exceeds a threshold $0$1. Otherwise, the system generates a safe exploratory policy to acquire missing information, executes the probe, updates the observation history, and recursively re-verifies the main policy.

Examples include checking whether a drawer is locked or occupied, turning on a light, determining object identity, and verifying visibility or pose. Verified code segments are frozen while unvalidated portions are regenerated. The architecture therefore preserves both accumulated observations and previously validated program structure.

The paper reports a 46.2% task-success improvement over Code-as-Policies baselines and 86.8% executability of task-relevant actions. The supplied details do not specify the exact baseline, denominator, confidence intervals, or formal definition of executability. The reported mechanism is active information gathering before risky execution, not a complete formal guarantee against perception, dynamics, or hardware failure.

4.3 Reliability-oriented benchmark frameworks

CaP-X evaluates coding agents across abstraction, temporal interaction, and perceptual grounding (Fu et al., 23 Mar 2026). CaP-Gym provides a stateful code-execution loop, while CaP-Bench evaluates seven manipulation tasks across single-turn and multi-turn conditions. Success generally improves with human-crafted abstractions but falls when agents must synthesize low-level perception and control code from signatures and docstrings alone.

Adding API examples to low-level interfaces increased average performance by roughly 20 percentage points relative to signatures and docstrings alone. Multi-turn execution feedback improves performance, but raw images can be less useful than structured textual visual differencing. CaP-Agent0 combines multi-turn recovery, a visual-differencing module, an automatically synthesized skill library, and ensemble code generation. It achieves performance comparable to or better than human programs on four of seven CaP-Bench tasks and reports 22%–26% aggregate success on perturbed LIBERO-PRO subsets.

CodeActionBench evaluates agentic CaP without specialist perception, grasp modules, privileged state, predefined task policies, or demonstrations (Lyu et al., 27 Sep 2026). It contains 25 fixed manipulation tasks and 675 attempts across nine configurations. Success rates range from 2.7% to 73.3%; the strongest configuration achieves 55/75 successes and solves 22 of 25 fixed task instances at least once. Failure analysis distinguishes spatial arrival, object control, retention, final-state satisfaction, and completion judgment. The benchmark shows that reaching a target region is substantially easier than securely grasping, transporting, placing, or verifying the final physical relation.

5. Search, evolution, memory, and policy improvement

5.1 Evolutionary code synthesis

PolicySmith treats policy design as offline search over executable heuristics rather than manual rule engineering (Dwivedula et al., 9 Oct 2025). An LLM generates candidate code, a checker compiles and validates it, a simulator or trace-driven evaluator assigns performance, and high-performing candidates are reused in later prompts.

For web caching, the system synthesizes a priority function over access counts, recency, object size, eviction history, and distribution-relative thresholds. Using libCacheSim, 105 CloudPhysics traces, 14 MSR traces, and a cache size equal to 10% of trace footprint, all eight generated heuristics matched or outperformed the 14 baselines on their original traces. Generalization to other traces varied from 14% to 64% of traces on which a generated heuristic beat all baselines.

For congestion control, generated code is compiled to eBPF and attached dynamically to Linux kernel callbacks. Of 100 candidates, 63% passed the eBPF verifier on the first attempt and another 19% compiled after receiving compiler feedback. The principal failures involved floating-point arithmetic and missing division-by-zero checks. The study demonstrates feasibility and safe integration, not a new universally superior congestion-control algorithm.

Code Evolution for Control applies similar LLM-driven evolutionary search to LunarLander-v3 (Guo et al., 11 Jan 2026). Policies are Python functions mapping an eight-dimensional state to one of four discrete actions. Under approximately one million environment steps, EvoEngineer+ achieved an average reward of 143.6 and a 70% success rate, compared with 214 and 60% for PPO. The synthesized policy is a 59-line, three-phase altitude-based controller. It is inspectable and editable but has lower mean reward and higher inference-related cost than local PPO optimization.

5.2 Memetic policy evolution

MEMENTO treats embodied policy improvement as execution-guided program search (Sygkounas et al., 24 Jul 2026). It first evolves an evaluator that maps rollouts to scalar fitness and structured feedback, then evolves a single elite policy through sequential hill-climbing, macro-mutation, and crossover.

The evaluator’s structured feedback includes phase scores, milestone times, object visibility, grasp and placement quality, failed movements, illegal placements, and final task predicates. Hill-climbing accepts non-degrading candidates sequentially and stores rejected edits in memory. Macro-mutation provides broader exploration, while crossover recombines partial strategies.

On Robosuite Franka Tower-of-Hanoi and AI2-THOR household interaction, MEMENTO achieved $0$2 and $0$3 task success, respectively, outperforming adapted Eureka and REvolve baselines. It achieved 0.78 success on held-out AI2-THOR scenes and transferred the best Robosuite policy to a physical Franka robot with a 0.90 success rate over 10 trials. Zero-shot generation and unevolved evaluators failed to solve either domain.

The principal limitation is evaluator dependence. The evaluator is evolved from initial rollouts and then frozen, so later policies may expose failure modes absent from the evaluator’s training trajectories. The approach also requires substantial rollout and model-call budgets.

5.3 Function-level reuse and cache grafting

FCGraft addresses latency and robustness in embodied CaP by maintaining validated function skeletons, implementations, and Transformer key-value caches (Chun et al., 11 Jun 2026). It uses stitching to compose cached function structures and patching to modify only localized task-specific code regions after execution errors.

The two-tier cache separates function interfaces from function implementations. Interface caches help synthesize orchestration code, while validated implementations are linked into the executable policy. Patching preserves the prefix and suffix of a program and regenerates a bounded middle span using execution feedback.

Across the reported embodied benchmarks, FCGraft achieved an 18.31% higher task success rate and 2.3-fold faster policy synthesis than RAGCache. In RLBench, its Open-Composition result was $0$4 success with $0$5 seconds of synthesis latency. On real-world office and cooking tasks, it achieved $0$6 and $0$7 success, respectively.

The approach does not provide formal safety guarantees. Incorrectly validated functions may contaminate the cache, error-span localization is imperfect, and GPU–CPU cache transfer introduces overhead.

5.4 Decomposing runtime code generation

RACaP moves code generation from deployment time to evolution time (Li et al., 24 Sep 2026). Reusable physical mechanisms are encoded in frozen, typed Policy APIs such as pickplace, insert, stack, push, articulate, and actuate_control. At deployment, a ReAct harness chooses APIs, arguments, subgoal order, recovery strategies, and stopping decisions but cannot generate or modify source code.

This separates mechanism coding from task-specific decisions. The system combines Policy APIs, a ReAct policy, working memory, and long-term experience memory. Its reported success is 54.4% on LIBERO-90, 45.0% on zero-shot LIBERO-PRO, and 46.0% on LIBERO-Long, compared with at most 4.0% for CaP baselines on long-horizon tasks. Median LIBERO-PRO policy time is reported as 380 seconds for RACaP Phase 2, compared with 454 seconds for Phase 1.

RACaP is therefore a decomposition rather than a rejection of CaP. It retains executable code as the medium for reusable physical mechanisms but replaces runtime source synthesis with typed API calls and visual ReAct. The tradeoff is reduced online structural adaptation: a genuinely new physical skill must be added through a later evolution or promotion process.

6. Applications, trade-offs, and future directions

6.1 Mobile manipulation and humanoid control

MoCaP combines passive human video with closed-loop mobile CaP (Cai et al., 14 Oct 2026). Offline processing extracts spatial memory and human interaction-event memory. Spatial memory records places, landmarks, objects, surfaces, connectivity, and transition cues. Interaction memory records a ready frame, a preceding frame, and a contact frame, providing an approach-direction prior.

At runtime, a startup advisor relates the memory to the instruction and the robot’s initial view. Generated programs then call segmentation, navigation, grasp-generation, depth, relative-pose, inverse-kinematics, and motion-planning APIs. The human trajectory is not copied directly. It informs where to search and which side may be favorable, while robot-specific geometry and feasibility checks determine actual base and arm motions.

On a real mobile manipulator, MoCaP achieved 80% success on both evaluated mobile-manipulation tasks. Video-derived spatial memory improved object-navigation success from 70% to 100%, and human approach priors improved reachable-base-pose discovery from 0% to 100% in an unfavorable-start comparison.

HuGo applies CaP to humanoid loco-manipulation (Choi et al., 24 Sep 2026). An LLM generates high-level closed-loop code over a frozen ten-dimensional whole-body command interface. The code maintains memory, implements temporal stages, and produces commands at 50 Hz or 10 Hz; the LLM is not queried at control frequency.

Across five simulation tasks, HuGo substantially outperformed high-level reinforcement learning. With the rl_isaac low-level controller, refined HuGo policies achieved 96.20% on narrow-gate passing, 79.97% on push-button, 89.33% on push-box, and 75.92% on lift-box. Best-of-10 selection raised average success from 43.9% for best-of-1 to 79.1%. On hardware, selected policies achieved 93.3% success on push-button and 66.7% on lift-box in the strongest reported cases. Hardware refinement improved one push-button policy from 20% to 90% without demonstrations or low-level policy retraining.

These results illustrate a recurring architectural constraint: high-level code cannot compensate for absent low-level capabilities such as force control, compliant contact, or reliable grasp maintenance.

6.2 Reverse engineering and interpretability

RevengeBench studies the inverse direction of CaP: reconstructing an executable policy from behavioral traces (Rahmani et al., 24 Jun 2026). It contains 75 hidden LLM-generated game policies across BattleSnake, Halite, Poker, RoboCode, and RobotRumble. Learners observe target behavior, construct executable hypotheses, and optionally design custom opponent policies as behavioral probes.

Across twelve frontier models, recovery closed approximately 34%–72% of the initial action distance. GPT-5 achieved 71.9%, while GPT-oss-120B achieved 33.8%. Active probing improved 16 of 20 model–game comparisons, although the mean improvement was approximately $0$8. Reconstructed code also improved downstream counter-strategy generation in player-versus-player experiments.

The benchmark demonstrates that executable policy representations can support behavioral interpretation, opponent modeling, active experimentation, and counter-strategy synthesis. It does not establish unique recovery of source code: finite traces and interventions generally identify a class of behaviorally equivalent programs rather than a single causal mechanism.

6.3 Strengths

Across these domains, recurring strengths include:

• Expressiveness: code represents loops, branches, state, memory, arithmetic, and modular composition.
• Interpretability: thresholds, variables, phases, and API calls can be inspected.
• Editability: localized changes can modify behavior without retraining a neural policy.
• Compositionality: reusable functions and APIs can be combined for new tasks.
• Feedback integration: execution traces, images, tool reports, and evaluators can guide revision.
• Cross-embodiment adaptation: the same high-level logic can target different interfaces when APIs are exposed.
• Offline optimization: evolutionary search can generate specialized policies without placing model inference on the control path.
• Human accessibility: declarative systems such as Pika and Prose2Policy can expose policy authoring through forms, schemas, and intermediate representations.

6.4 Limitations and controversies

CaP is not synonymous with reliability or safety. Common failure modes include hallucinated APIs, incorrect argument types, invalid numerical parameters, syntactically valid but semantically wrong code, missing safety guards, unstable loops, perception errors, stale state, and incomplete verification.

The policy is bounded by its interfaces. A robot can only perceive concepts exposed by its perception modules and perform operations exposed by its control primitives. A governance system can only govern events exposed by the platform API. A Rego system can only inspect attributes included in the input document. A typed policy system can only prove propositions represented in its formal model.

Runtime execution also creates safety risks. Basic filters that reject imports, eval, exec, and special variables are not complete sandboxing. Physical deployment requires workspace and velocity limits, collision checking, force constraints, timeouts, emergency stops, loop bounds, human approval, simulation, formal validation, or runtime monitoring. In infrastructure, automatic remediation can satisfy a generated rule while breaking another dependency or violating the user’s actual intent. In access control, compilation and negative-test success do not prove that no unintended allow path exists.

Evaluation is another point of controversy. Many reported systems use small task suites, fixed environments, curated prompts, or specialized interfaces. Success may depend heavily on human-designed abstractions, prompt examples, evaluator quality, or hidden scaffolding. CodeActionBench and CaP-X specifically expose this dependence by comparing high-level and low-level interfaces. MEMENTO, PolicySmith, and Code Evolution for Control show that search quality depends on evaluators and feedback design. NeSyRo shows that symbolic consistency does not resolve unobserved physical state. Natural Language as Policies shows that natural-language reasoning can improve semantic transfer in some settings but lacks the explicit compositional feedback structure of executable code (Mikami et al., 2024).

6.5 Future directions

The research trajectory points toward hybrid systems rather than a single universal representation. Natural-language reasoning can preserve semantic context and support transfer; executable code can provide deterministic computation, loops, state, and feedback; formal types and symbolic validators can constrain authorization or task validity; learned controllers can provide fast embodiment-specific execution; and evolutionary or agentic search can improve programs through external evaluation.

Prominent directions include:

• combining natural-language semantic reasoning with executable code and formal controllers;
• evolving evaluators alongside policies;
• integrating active information gathering with symbolic verification;
• using function-level validated code reuse and localized repair;
• separating reusable mechanisms from runtime task decisions;
• grounding policies in structured 3D geometry and object-centric state;
• improving completion judgment and object-retention verification;
• supporting shared policy libraries and multi-agent cache learning;
• applying independent test generation and formal semantic validation;
• incorporating safety, robustness, fairness, and resource constraints into policy objectives;
• developing hybrid CaP–VLA architectures in which code handles decomposition and recovery while learned policies handle contact-rich execution.

Code-as-Policies is consequently best understood as a family of architectures rather than a single algorithm. Its common premise is that policy logic should be represented, synthesized, or improved as executable structure. Its practical success depends on the quality of interfaces, perception, evaluators, validation, search procedures, and deployment safeguards surrounding that code.