Copper: Unifying Correctness and Performance Specification in Code Generation

Abstract: Generative AI has made remarkable progress in producing functionally correct code, yet ensuring both correctness and performance remains an open challenge. We present Copper, a framework that combines formal verification with performance-aware specification to generate code that is provably correct and efficiently executable. Our approach integrates AI-driven code synthesis with formal verification tools, and automated performance profiling loops. Evaluated on a diverse set of algorithmic and real-world programming tasks, Copper produces solutions that satisfy strict correctness guarantees while delivering significant improvements in runtime and memory efficiency compared to baseline AI-generated code. This work demonstrates that it is feasible to bridge the gap between trustworthiness and performance in AI-assisted programming, offering a practical pathway toward reliable, high-performance code generation.

• The paper presents Copper, a framework that unifies functional correctness with performance specification using formal methods and ghost variables.
• It details a multi-stage pipeline combining AI-driven synthesis, formal verification via Dafny, and performance analysis with iterative repair loops.
• Experimental results emphasize improved repair success and reveal model limitations, highlighting the need for enhanced language support in formal code generation.

Unifying Correctness and Performance in AI Code Generation: The Copper Framework

Motivation and Problem Formulation

Current generative AI techniques have demonstrated an improved capacity to produce functionally correct code; however, ensuring both correctness and performance in generated code remains largely unresolved. While software engineering relies on correctness for reliability, performance is essential for scalability and real-world applicability. Existing approaches separately address correctness (through empirical/tests or formal methods) and performance (via empirical runtime metrics), but no unified framework addresses both within code generation pipelines. This work introduces Copper, a formal framework that composes AI-driven synthesis, formal verification, and automated performance profiling, using Dafny as an intermediate verification-aware language.

The Copper Pipeline: Architecture and Workflow

Copper is designed as a multi-stage, iterative pipeline:

1. Prompt Construction (PromptBuilder): Prompts are constructed with varying levels of specification, including short natural language, extended natural language, and formal Dafny contracts (pre/post-conditions).
2. Model Request (ModelRequester): An LLM receives the prompt and returns a candidate Dafny implementation, which is parsed and syntactically validated.
3. Correctness Verification (CorrectnessVerifier): Dafny is used to check that the code meets all contracts. For formal prompts, computational complexity is enforced as a postcondition using ghost state constructs.
4. Performance Analysis (PerformanceAnalyzer): The generated code is further analyzed for empirical execution time by translating it to Python ("dafny build") and running complexity estimation.
5. Sanity Checking: The final code is tested on canonical inputs and compared to reference outputs.

This pipeline operates in two modes. Single-attempt mode executes the pipeline independently per prompt. Repair/Feedback loop mode incorporates history: failed code, errors, and exceptions are provided in subsequent prompts, allowing iterative guided repair up to a fixed number of attempts. The pipeline therefore tightly couples automated formal correctness proofs with complexity guarantees.

Specification and Enforcement of Complexity

A key innovation is the unification of functional correctness with algorithmic complexity via formal specification. Since SMT-based deductive verifiers such as Dafny lack native support for asymptotic complexity reasoning, the approach encodes complexity by requiring the model to synthesize ghost variables (resource counters) and connect them through inductive invariants to data structures or loop indices. For instance, binary search is required to prove:

ensures steps == if arr_A.Length <= 1 then arr_A.Length else Log2(arr_A.Length) + 1

This mechanism provides a deductively checkable proxy for performance, with ghost state guaranteeing no runtime penalty, as such constructs are erased during compilation. The Copper design thus forces the model not only to synthesize code satisfying input-output specifications but also to co-synthesize a formal proof of resource boundedness.

Prompt Engineering and Model Evaluation

The framework supports three prompt classes:

• Short Prompts: Minimal natural language about the task and expected complexity.
• Detailed Prompts: Longer, more explicit natural language with explicit requirements, edge cases, etc.
• Formal Prompts: Directly structured Dafny contracts with explicit method signatures and contracts.

Experiments assess prompt effectiveness across three model scales: Gemini 3 Flash Preview ("large"), Gemma 4 31B ("medium"), and LLaMA 3 8B ("small"). The evaluation uses pass@k (success in k attempts) and repair@k (success after k guided repairs), both for functional and complexity correctness.

Experimental Results

Empirical results delineate clear boundaries between model/prompt variants:

• Pass@1 is near zero for all but trivial settings, emphasizing that one-shot LLM responses do not reliably produce code that is both correct and performant, even when LLMs assert so.
• Guided repair loops produce substantial improvements. Large models (Gemini 3, Gemma 4) achieve high repair@10 (close to 1.0) with guided feedback even under formal prompts.
• Prompt specificity impacts success rates. Contrary to intuition, short prompts outperform detailed or formal prompts under independent trials—likely because excessive prompt complexity overwhelms model inference or triggers insufficient symbolic alignment with specification.
• Small models (≤8B) fail on all metrics, evidencing an inability to learn syntax and semantics of formal verification languages lacking in their pretraining data.

On the statistical axis, chi-square analyses confirm the significance of the model–prompt interaction: larger models with short prompts under independent runs, and large/medium models with guided repair across all prompt types, exhibit significantly higher success rates for both correctness and performance metrics.

Theoretical and Practical Implications

Copper demonstrates that integrating formal verification with resource-aware specification is both feasible and effective for AI code generation. Methodologically, the use of deductive ghost state for performance transforms the classic post-generation tuning workflow into a specification-driven synthesis that guarantees both trustworthiness and efficiency.

Practically, this suggests immediate value for high-assurance, performance-sensitive domains that require certification of both functional and nonfunctional requirements at the source level. The iterative repair architecture—coupling verification errors as context—enables current LLMs to iteratively converge toward valid solutions, an essential property absent in direct sampling.

However, model size and coverage of the formal language (here, Dafny) remain major bottlenecks. The inability to generate correct, efficient, and verifiable code by small models emphasizes the need for explicit inclusion of formal verification languages in pretraining corpora and possible finetuning protocols.

Limitations and Future Directions

The experimented scope is largely algorithmic (e.g., binary search), with generalization to large-scale, non-toy software pending. Modern LLMs still struggle with inductive invariants and complex contract synthesis, especially outside the mainstream software engineering language ecosystem. As formal verification languages become more mainstream in AI-assisted programming, additional model support and dataset curation will be required.

Future research should explore:

• Finetuning on large, high-quality corpora of formal specifications (e.g., Dafny annotated codebases),
• Automated abstraction and contract inference to reduce prompt engineering burden,
• Extending the approach toward probabilistic or resource-sensitive programming settings,
• Tight integration with existing MLOps and verification toolchains in software CI.

Conclusion

Copper provides a principled and practical method for unifying formal verification and performance specification in LLM-driven code generation. By leveraging Dafny’s verification toolchain as both constraint and performance oracle and iteratively closing the feedback loop on generated code, Copper demonstrates the practical potential of trustworthy, high-performance, and specification-driven code synthesis. Nevertheless, widespread adoption is gated by advances in model capacity, language exposure, and improved synergy between AI synthesis and formal methods.