Compiler.next: Search-Based Intent Compiler

• Compiler.next is a search-based compiler that synthesizes human intents into runnable software by exploring candidate cognitive architectures and optimizing multi-layer parameters.
• It employs multi-objective optimization, using techniques like NSGA-II to balance accuracy, latency, and cost, ensuring reliable intent-to-code transformation.
• Integrated within the SE 3.0 stack, Compiler.next collaborates with IDE.next and Teammate.next to support conversational intent alignment, iterative code mutation, and dynamic re-optimization.

Searching arXiv for the cited Compiler.next and closely related compiler papers to ground the article and verify current metadata. Compiler.next is a search-based compiler proposed for Software Engineering 3.0, an AI-native paradigm in which software development becomes intent-first and conversation-oriented rather than code-first and task-fragmented. In this formulation, Compiler.next is responsible for synthesizing human-written intents—possibly enriched with examples and data—into runnable software or, more specifically in the later dedicated formulation, into optimized FMware by searching over candidate cognitive architectures, prompts, foundation model configurations, and system parameters. It is therefore positioned neither as a traditional logic-rule compiler nor as an SE 2.0 copilot, but as a multi-objective synthesis engine that drives code creation through search-space exploration, code mutations, self-reflection, and goal tracking tied to requirements rather than to pre-existing code (Hassan et al., 2024, Cogo et al., 27 Oct 2025).

1. Conceptual position within Software Engineering 3.0

Compiler.next originates in the SE 3.0 vision, which reframes software engineering around aligned human-AI intents. In that stack, intent alignment occurs in IDE.next through conversation, the AI teammate participates as an adaptive collaborator, and Compiler.next executes the code-creation loop after alignment. The core definition is explicit: Compiler.next is “the piece of software responsible for synthesizing intents ... into runnable software via an efficient search process,” operating “at hyper speed” and iteratively developing solutions through “code mutations and a self-reflection mechanism” that evaluates both intent match and code quality (Hassan et al., 2024).

This role distinguishes Compiler.next from both traditional compilers and current copilots. Traditional compilers are framed as systems for “logic-rule realization”: they take a program as given and realize it into an executable form. Compiler.next instead performs “search-space exploration,” because the primary artifact is not finished source code but human intent. Current SE 2.0 copilots are characterized as task-driven systems that “can essentially only add code,” often without a durable representation of goals; Compiler.next is designed to synthesize from aligned intents, optimize across several objectives, and preserve a persistent connection between requirements and resulting tests (Hassan et al., 2024).

The dedicated 2025 formulation sharpens this distinction by treating FMs as “probabilistic CPUs” and prompts as the “binaries” executed by those CPUs. In that framing, compilation is no longer a deterministic code-to-binary pipeline but a dynamic search over FMware configurations. This implies a separation between stable intent and evolving implementation: when models, data, or requirements change, recompilation from the same intent becomes the primary mechanism for restoring quality, rather than manually re-editing brittle prompts or code-adjacent orchestration logic (Cogo et al., 27 Oct 2025).

A common misconception is that Compiler.next is merely a more aggressive code generator. The papers instead describe it as an intent compiler whose scope extends beyond source generation to the synthesis and optimization of prompts, model settings, workflows, agents, retrieval parameters, and runtime-related choices. Code may still be produced, but code is “of secondary importance and hidden from the human by default,” with low-level inspection treated as an optional debugging mode rather than the primary development interface (Hassan et al., 2024).

2. Intent compilation as a multi-objective search problem

Compiler.next formalizes development as search. In the SE 3.0 paper, the fitness function is defined by “how well the produced code satisfies the human-AI aligned intents,” while the synthesis loop explicitly evaluates both intent satisfaction and code quality. The later architecture paper expands this into a full multi-objective compilation problem over FMware configurations, balancing “accuracy, latency, and cost” without requiring a priori objective weights. The prototype specifically implements NSGA-II and presents a Pareto frontier of trade-offs rather than a single weighted optimum (Hassan et al., 2024, Cogo et al., 27 Oct 2025).

The optimization variables span several layers. At the prompt level, Compiler.next can optimize template structure, instructions, few-shot examples, and formatting; at the model level, it can optimize release-FM choice, evaluator-FM choice, and decoder parameters such as temperature and top-$k$; at the system level, it can optimize RAG parameters, agent roles, memory size, guardrails, and related operational knobs. The architecture groups these under the broader concept of a cognitive architecture, defined as the specification of what components are invoked, how they are invoked, and in what order (Cogo et al., 27 Oct 2025).

The operational loop is explicitly iterative. Intents describe tasks at a high level—for example, “Generate source code from documentation”—and are paired with scenarios that include gold labels and evaluation criteria. Initial candidates may be user-provided or FM-synthesized from the intent. Those candidates are instantiated, executed through the release-FM, scored against gold labels by an EvaluationBench, optionally critiqued through evaluator-FM-based self-reflection, and then improved through selection, crossover, and mutation. Scores are aggregated across $n$ scenario instances, and optimization continues until a stopping condition such as iteration count, time budget, or threshold score is met (Cogo et al., 27 Oct 2025).

The conceptual paper does not provide explicit LaTeX objective functions, weighted sums, Pareto-front equations, or formal SLA constraints. It names measurable criteria—accuracy or intent satisfaction, latency measured for example by the number of FM requests, token-based cost, and code quality for human debuggability—but leaves the formal mathematical model unspecified. The 2025 paper resolves part of this gap by making Pareto optimization via NSGA-II concrete, while still keeping the larger search framework extensible to random search, FM-driven mutation, and differentiable prompts (Hassan et al., 2024, Cogo et al., 27 Oct 2025).

This formulation also reframes testing. Rather than evaluating only whether generated artifacts compile or resemble reference code, Compiler.next attaches evaluation to intent-derived success conditions. In the earlier paper, the goal-tracking mechanism ensures that intents are translated into tests, that tests adapt as requirements change, and that tests “will eventually pass.” In the later paper, gold-label-driven evaluation plays an analogous role for FMware compilation, with release-FM outputs scored against scenario-specific ground truth (Hassan et al., 2024, Cogo et al., 27 Oct 2025).

3. Architecture, components, and stack integration

Compiler.next appears in two closely related architectural descriptions. In the SE 3.0 stack, it sits alongside Teammate.next, IDE.next, Runtime.next, and FM.next. IDE.next hosts the conversation-oriented alignment process; Teammate.next explains rationale, trade-offs, and design choices; Compiler.next performs synthesis and optimization; Runtime.next provides execution substrate and telemetry; and FM.next supplies “efficient and knowledge-driven FMs” strengthened through curriculum engineering. Runtime-side “semantic observability” and SLA-aware telemetry feed back into FM.next, which in turn improves the FMs used by Compiler.next (Hassan et al., 2024).

The later dedicated paper embeds Compiler.next in a three-layer FMware platform called FMArts. The top layer is an FMware hub of reusable artifacts and tools; the middle layer is an FMware framework containing conceptual primitives for FMware programs; the bottom layer is a graph compiler and fusion runtime oriented toward execution and serving. Within this stack, Compiler.next acts as a higher-level synthesizer that produces or refactors FMware assets and then hands a compiled plan to the graph compiler and runtime for execution (Cogo et al., 27 Oct 2025).

The paper’s internal abstractions are deliberately metaprogrammatic. FMware is represented as compositions of Operations, where an Operation is a stateful unit such as FM inference or vector-database retrieval with optimizable parameters and an associated Optimizer. Operations exchange messages and support prompt chains, DAGs, and agentic cognitive architectures. An Optimizer defines how an Operation’s parameters or prompts are searched or mutated, while an EvaluationBench defines the gold-label format and evaluation logic used to score candidates (Cogo et al., 27 Oct 2025).

A notable design decision is the separation of evaluator-FM and release-FM. The release-FM is the model deployed in the final FMware; the evaluator-FM is used to guide search or generate feedback. This permits a small or cheap release-FM to be paired with a stronger evaluator-FM during compilation. The same architecture also supports scenario expansion, in which scenarios are paraphrased or diversified to reduce overfitting and encourage robustness across variations of the same task (Cogo et al., 27 Oct 2025).

Caching and orchestration are treated as first-class infrastructure. The system uses a two-level semantic cache: an L1 cache keyed by a hashable representation of “intent + training data description” that routes to an L2 cache keyed by a hash of the optimizable parameter, such as a prompt. Cached artifacts include fitness evaluations, mutation outputs, crossover outputs, and FM inferences. Checkpointing supports mid-optimization recovery, and parallel evaluation plus distributed runtime support scaling across candidates and nodes. Similarity thresholds in the range 0.80–0.95 control the balance between reuse and exploration (Cogo et al., 27 Oct 2025).

For the developer experience, the interaction model remains conversational. Intents may be expressed informally, through pseudocode, UI sketches, and example data. Conversations are archived and versioned, and can be reused to rerun synthesis, for example after the release of a new FM. Code is hidden by default, but low-level debugging mode allows manual inspection and edits when required (Hassan et al., 2024).

4. Assurance, reproducibility, and developer control

Compiler.next’s assurance model is centered on traceability from intent to evaluation. In the SE 3.0 formulation, the central assurance mechanism is the goal-tracking system, which “ensures that (i) intents are translated into tests, (ii) tests are adequately adapted as requirements change, and (iii) tests will eventually pass.” This is presented as a direct correction to an SE 2.0 failure mode exemplified by deriving tests from existing code, a practice explicitly criticized because it is “no guarantee that the code does what it is supposed to do” (Hassan et al., 2024).

The later architecture paper extends assurance into reproducibility and quality governance. It argues that bit-for-bit determinism is not always feasible because FM inference and exploratory search are stochastic, and therefore reframes reproducibility as “quality-level reproducibility.” Proposed controls include setting decoding parameters to reduce randomness, pinning search seeds, controlling runtime nondeterminism, logging seeds and model versions, checkpointing optimization iterations, and enabling deterministic replay of compilation traces. Semantic caching and artifact tracking are also treated as mechanisms for deterministic reuse of previously computed results (Cogo et al., 27 Oct 2025).

Quality gates are explicit. The paper proposes compile-time validation against gold labels and confidence-interval-based thresholds, and states that compilation should fail when quality requirements cannot be met. It also recommends that compilers estimate, with a specified confidence level, that an FMware artifact will execute within predefined quality thresholds. This pushes Compiler.next beyond heuristic “best effort” generation toward a compile-or-fail discipline conditioned on measurable success criteria (Cogo et al., 27 Oct 2025).

Safety is present but not formalized as a theorem-proving framework. Guardrails are treated as first-class FMware components, and safety-related parameters can themselves be optimized. Observability and trace retention are used for debugging both successful and failed compilation trajectories. However, neither of the core Compiler.next papers introduces contracts, static proof obligations, or a formal verification system. The assurance model is instead based on intent-derived testing, gold-label evaluation, observability, self-reflection loops, and traceable control over compilation conditions (Hassan et al., 2024, Cogo et al., 27 Oct 2025).

Interpretability remains an open problem. The SE 3.0 paper asks how the overall performance of Compiler.next should be evaluated and how FMs for code can be made more interpretable, but does not finalize a benchmark suite or interpretability framework. In practice, explainability is delegated partly to Teammate.next, which is expected to explain rationale, design patterns, and trade-offs on request, and partly to the concrete pass/fail feedback generated by Compiler.next’s testing and evaluation mechanisms (Hassan et al., 2024).

5. Evaluation, metrics, and initial empirical results

The conceptual SE 3.0 paper defines current Compiler.next metrics only at a high level: fitness is tied to how well code satisfies aligned intents; multi-objective criteria include accuracy, latency, and token-based cost; and code quality is evaluated for human debuggability. It also states that benchmark design is an open question and acknowledges limitations in existing benchmarks for autonomous coding agents (Hassan et al., 2024).

The dedicated 2025 paper provides an initial empirical validation on HumanEval-Plus for Python function synthesis from signature and docstring. The optimization target was a system prompt derived from the intent “Generate source code for a function given a problem description found in the function’s documentation.” The search protocol used NSGA-II over three objectives—accuracy, latency, and cost—with 5 generations × 10 candidates, yielding 50 candidates per run. Seventy percent of HumanEval-Plus tasks were used as gold labels for optimization, and thirty percent were held out for evaluation. The study used Qwen2.5-7B-Instruct and GPT-4o-mini, together with a two-level semantic cache using a Euclidean similarity threshold of 0.85 (Cogo et al., 27 Oct 2025).

Model	Accuracy	Avg. latency / Avg. tokens
Qwen2.5-7B-Instruct	initial 0.26 → optimized 0.56	14.2 s → 10.8 s / 537.1 → 369.3
GPT-4o-mini	initial 0.68 → optimized 1.00	8.7 s → 5.0 s / 500.0 → 417.1

In this setup, accuracy for code generation was measured as the proportion of unit tests passed, latency as the runtime required to execute generated code, and cost as the number of input and output tokens consumed per run. Aggregation occurred across multiple problem instances for each candidate, and selection used Pareto-front diversity via crowding distance in NSGA-II (Cogo et al., 27 Oct 2025).

The paper also reports a caching ablation for GPT-4o-mini using the best optimized prompt. In that experiment, accuracy changed from 1.00 without cache to 0.70 with cache; average latency changed from 5.0 s to 5.9 s; average tokens changed from 417.1 to 467.0; and total running time changed from 8m:15s to 10m:27s, which the paper reports as a 22.1% difference. This is significant because it shows that semantic caching is not uniformly beneficial: threshold selection can trade off reuse against exploration, and in some settings premature reuse can degrade quality rather than improve throughput (Cogo et al., 27 Oct 2025).

These results remain explicitly preliminary. The papers do not claim that a universal benchmark or stable evaluation methodology has been established. Instead, they present the HumanEval-Plus study as an initial validation of automated system-prompt synthesis, multi-objective optimization, and the practical consequences of caching and evaluator-guided search (Hassan et al., 2024, Cogo et al., 27 Oct 2025).

6. Relation to compiler research, program transformation, and open directions

Compiler.next is presented as distinct from several existing compiler and optimization traditions. Relative to traditional compilers, it is dynamic, search-driven, and intent-centered. Relative to deep-learning compilers such as TVM, XLA, or Glow, it optimizes application-level FMware semantics—prompts, cognitive architectures, model choices, retrieval parameters, and agent workflows—rather than only computational graphs and kernels. Relative to prompt optimizers such as APE, Promptbreeder, EvoPrompt, ProTeGi, and program-level optimizers such as DSPy, TextGrad, and SAMMO, it is framed as a broader compiler architecture with explicit integration into requirements, testing, CI/CD, maintenance, interoperability, and runtime infrastructure (Cogo et al., 27 Oct 2025).

Within the SE 3.0 roadmap, one of the most important open directions is Search-Based Software Engineering. The paper proposes improving synthesis efficiency by caching past search outcomes, reusing historical search data to “start searches closer to optimal solutions,” tuning search algorithms such as genetic algorithms or simulated annealing, learning heuristics via self-reflection from past successful searches, and personalizing searches based on prior user behavior and preferences. This places Compiler.next in direct continuity with SBSE, but extends the search object from conventional code variants to intent-grounded FMware configurations (Hassan et al., 2024).

The papers also leave the internal programming model deliberately unsettled. The 2025 work calls for “quality programming constructs” and a common IR for FMware, inspired by LLVM/MLIR-like standardization, but does not finalize a DSL. Related compiler theory suggests several possible directions. A plausible implication from proof-theoretic IR research is that typed intermediate representations based on formal contexts—such as VFS/LJQ, where CPS can be delayed to a final negative-translation stage—could supply a disciplined substrate for effect-aware optimization while avoiding premature double-negation encodings (Santo et al., 2023). A plausible implication from hierarchical program-transformer research is that process-tree-based transformations with semantic preservation, $$\llbracket R(T_k(e,\Delta),\Delta) \rrbracket = \llbracket e \rrbracket$$, and WQO-based termination guarantees could inform future Compiler.next passes that optimize synthesized code or intermediate FMware programs more formally (Hamilton, 2021).

Execution-control research suggests another likely trajectory. Source-to-source systems such as Stopify show that continuations, periodic yielding, pausing, single-stepping, breakpoints, deep stacks, and blocking abstractions can be layered over compiled JavaScript while preserving language-level runtimes and signatures. This suggests that Compiler.next-generated Web artifacts could benefit from a reusable execution-control backend rather than embedding browser-specific workarounds into every language front-end or synthesized program (Baxter et al., 2018).

The open roadmap is therefore broad rather than purely algorithmic. The dedicated paper enumerates ten research directions: defining FMware programming constructs and a shared IR; broadening compilation from prompt templates to all FMware free parameters; identifying effective heuristics; constructing high-quality gold labels; enforcing quality gates; reducing cost while preserving search diversity; making intent compilation reproducible; supporting user-defined concurrent multi-objective optimization; improving interoperability between compilers; and building community-sharing platforms for compilation traces (Cogo et al., 27 Oct 2025). The earlier SE 3.0 paper adds open questions around FM understanding of code, multimodal training signals such as execution traces and static analyses, the elimination of brittle prompt engineering, and benchmark design for evaluation and interpretability (Hassan et al., 2024).

Taken together, these papers define Compiler.next less as a single finished compiler than as a compiler architecture for intent compilation. Its core commitments are already specific: intents as primary artifacts, search-space exploration rather than fixed translation, goal-tracked evaluation from requirements, Pareto optimization across accuracy, latency, and cost, and a stack-level integration of teammate, IDE, model, runtime, and observability components. What remains unsettled—by design—is the formal IR, the long-term benchmark regime, the standardization of FMware constructs, and the eventual synthesis of heuristic search with stronger semantic guarantees (Hassan et al., 2024, Cogo et al., 27 Oct 2025).