💻 computer science

Assessing, Exploiting, and Mitigating Syntactic Robustness Failures in LLM-Based Code Generation

This paper investigates the lack of syntactic robustness in LLM-based code generation when prompts contain mathematically equivalent but syntactically varied formulas, demonstrates how attack strategies exacerbate this failure, and proposes a formula reduction pre-processing technique that significantly improves robustness from 54.05% to 74.42%.

Original authors: Laboni Sarker, Mara Downing, Achintya Desai, Tevfik Bultan

Published 2026-05-12

📖 5 min read🧠 Deep dive

CC BY 4.0

Original authors: Laboni Sarker, Mara Downing, Achintya Desai, Tevfik Bultan

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you have a very smart, but slightly literal-minded robot assistant (a Large Language Model, or LLM) whose job is to write computer code based on your instructions. You tell it, "Build a machine that adds two numbers."

If you say, "Add 2 and 2," it builds the machine.
If you say, "Add 4 and 0," it should build the exact same machine, because mathematically, $2+2$ is the same as $4+0$ .

This paper asks a simple but critical question: Does this robot understand that these two instructions are the same, even if the words and symbols look different?

The authors call this concept "Syntactic Robustness." Think of it like a person's ability to understand a joke whether it's told in a whisper, a shout, or with a funny accent. If the robot breaks or gets confused just because you changed the style of the math (the syntax) without changing the meaning (the semantics), it lacks robustness.

Here is a breakdown of their findings using everyday analogies:

1. The Problem: The Robot Gets Confused by "Math Speak"

The researchers tested this by taking a math problem and rewriting it in 18 different ways that are all mathematically identical.

Original: "The force is $F = 9.8 \times a \times b$ ."
Rewritten: "The force is $F = (9.8 \times a \times b) + 0$ ." (Adding zero changes nothing in math).
Rewritten: "The force is $F = (9.8 \times a \times b) \times 1$ ." (Multiplying by one changes nothing).

They found that the robots (LLMs) are not robust. When the math was rewritten, the robots often wrote completely different, and sometimes broken, code. It's as if the robot thought, "Oh, you added a zero? That must mean you want a different machine!" even though the result should be the same.

2. The "Distance" of Confusion

The researchers measured how "far" they had to twist the math to break the robot.

Distance 0: The original, clean math. The robot works okay.
Distance 5: The math has been twisted and turned five times (e.g., adding zeros, multiplying by ones, swapping order).
Result: As the "distance" increased, the robot's performance crashed. It's like trying to navigate a maze; the more twists and turns you add to the path, the more likely the robot is to get lost, even if the destination is the same.

3. Two Types of Tasks: "Translation" vs. "Reasoning"

The paper discovered the robots handle two types of math requests differently:

Translation Prompts: "Here is a formula, just write code that calculates it." (Like a translator copying a sentence). The robots were okay at this.
Reasoning Prompts: "Here is a physics problem; figure out the steps to solve it and write the code." (Like a student solving a word problem). The robots were terrible at this when the math was twisted. They couldn't "think" through the logic if the math looked weird.

4. The Attack: Breaking the Robot on Purpose

The researchers acted like hackers to see how easily they could break the robots. They used three strategies:

Random Twisting: Just changing the math randomly.
Smart Twisting: Using a "cheat sheet" to find the specific changes that confuse the robot the most.
The Result: They found that with just a few clever changes (like adding unnecessary zeros or swapping terms), they could make the robot fail almost every time. It's like finding the one specific word in a sentence that makes a translator freeze up.

5. The Solution: "Pre-Processing" (The Simplifier)

Since the robots get confused by complex-looking math, the researchers proposed a fix: Don't feed the robot the messy math; clean it up first.

They built a "pre-processor" (a filter) that sits between you and the robot.

You: "Calculate $F = (9.8 \times a \times b) + 0 - 0$ ."
Pre-processor: "I see you added and subtracted zero. I'll remove that. Here is the clean version: $F = 9.8 \times a \times b$ ."
Robot: Receives the clean math and writes the correct code.

The Outcome: This simple step of "cleaning" the math before giving it to the robot boosted its success rate from 54% to 74%. It's like giving a confused student a simplified study guide before the test; they perform much better.

Summary

The paper concludes that while AI code generators are powerful, they are fragile when it comes to math. They get tripped up by simple, harmless changes to how a formula is written. However, if we add a simple "cleaning" step to simplify the math before the AI sees it, we can make them much more reliable.

What the paper does NOT claim:

It does not claim this works for all types of AI (only code generation with math).
It does not claim this fixes the robot's ability to learn new things (it's just a pre-filter).
It does not claim this is a permanent fix for all AI weaknesses, only a specific one regarding math syntax.

Technical Summary: Assessing, Exploiting, and Mitigating Syntactic Robustness Failures in LLM-Based Code Generation

Problem Statement

Large Language Models (LLMs) are increasingly utilized for code generation, particularly in scientific computing and domains requiring mathematical reasoning. A critical reliability concern arises when LLMs are tasked with generating code based on prompts containing mathematical formulas. While two formulas may be semantically equivalent (e.g., $a \times x + b = 0$ and $a \times x + a + b = a$ ), they differ syntactically. The paper posits that a robust LLM-based code generator should produce semantically equivalent code regardless of such syntactic variations in the input prompt. However, the authors observe that current state-of-the-art models often fail to maintain this consistency, generating different or incorrect code for semantically identical but syntactically distinct formulas. This lack of syntactic robustness poses a risk for automated code generation pipelines, especially when inputs are subject to natural variations or adversarial manipulations.

Methodology

Formal Definition of Syntactic Robustness

The authors formalize syntactic robustness as the degree to which an LLM-based code generator ( $G$ ) produces semantically equivalent programs ( $C$ ) for semantically equivalent but syntactically different prompts ( $P$ ).

Prompt Structure: A prompt $P$ is defined as a tuple $\langle T, F \rangle$ , where $T$ is English text and $F$ is a mathematical formula.
Equivalence: Two formulas $F_1$ and $F_2$ are semantically equivalent ( $[[F_1]] \equiv [[F_2]]$ ) if they evaluate to the same value under the same valuation. Two programs are equivalent if they produce identical outputs for all inputs.
Metric: Syntactic robustness is measured as the percentage of syntactic variations of a formula for which the LLM generates code equivalent to a reference solution.

Experimental Design

Dataset Construction: The study utilizes 52 prompts from diverse sources, including the Clover dataset (formal specifications), HackerRank, MATH, and MaTT. Prompts are categorized into:
- Reasoning Prompts: Require mathematical manipulation (e.g., integration) to derive code.
- Translation Prompts: Require direct translation of a given formula into code.
Syntactic Mutations: The authors define a context-free grammar for mathematical formulas and introduce 18 mutation types for equations and 12 for expressions. These mutations (e.g., commutative addition, adding zero, variable renaming) preserve semantics but alter syntax. They generate variations up to a "syntactic distance" of 5 (number of mutation steps).
Evaluation Pipeline:
- Generation: LLMs generate code for original and mutated prompts.
- Verification: Generated code is compiled and subjected to differential testing against reference solutions using 100 random inputs. Floating-point comparisons use an epsilon threshold to account for rounding errors.
- Models Evaluated: GPT-3.5, GPT-4o, Llama-3.1-70B, CodeLlama, and reasoning-enhanced variants (Chain-of-Thought, Deeply Understanding Problems).

Attack Strategies

The paper proposes black-box attack strategies to exploit syntactic robustness failures by applying mutations to minimize the model's robustness score:

NaiveUniform: Random selection of mutations.
Uniform: Random selection ensuring a specific syntactic distance.
Weighted: Probabilistic selection based on mutation impact scores derived from profiling.
Top-K: Selection from the top 50% of mutations identified as most detrimental to robustness.

Mitigation Strategy

To counter these failures, the authors propose a pre-processing step involving formula reduction. This technique applies a set of reduction rules (e.g., removing redundant additions/subtractions, shifting terms to one side of an equation) to simplify the mathematical formula in the prompt before it is fed to the LLM. The hypothesis is that shorter, simplified formulas are easier for LLMs to process correctly.

Key Results

1. Lack of Syntactic Robustness (RQ1)

State-of-the-art LLMs are not syntactically robust. As the syntactic distance (number of mutations) increases, the robustness degree consistently decreases across all models.

GPT-4o+CoT performed best with an average robustness of 87.4%, followed by GPT-4o at 83.87%.
Even the best models showed a decline in performance as mutations increased, with GPT-3.5 experiencing a significant drop (-9.52% per distance step).

2. Reasoning vs. Translation (RQ2)

There is a significant disparity in robustness based on prompt type:

Translation prompts (direct formula-to-code) exhibited high robustness (~83.80%).
Reasoning prompts (requiring mathematical derivation) exhibited significantly lower robustness (~42.86%).
Reasoning prompts suffered a steeper decline in robustness as syntactic distance increased compared to translation prompts.

3. Effectiveness of Attacks (RQ3)

The proposed attack strategies effectively degrade syntactic robustness.

Top-K and Weighted attacks were the most effective.
Using the Top-K strategy, the syntactic robustness of GPT-3.5 on reasoning prompts dropped to 14.64% at distance 5.
Top-K attacks required fewer mutations to achieve a target low robustness level compared to other strategies (e.g., reducing robustness to 10% required only 3 mutations with Top-K vs. 5 with Weighted).

4. Mitigation via Reduction (RQ4)

The formula reduction pre-processing step significantly improved robustness.

Applying reductions to mutated prompts increased syntactic robustness by an average of 20.37% across models.
For GPT-4o+CoT, reductions improved robustness even over the original (unmutated) prompts by 0.6%.
The technique successfully mitigated the impact of Top-K attacks, restoring robustness levels close to those of the original prompts.

Significance and Claims

The paper claims to be the first to formally define and systematically evaluate syntactic robustness specifically for LLM-based code generation involving mathematical formulas. Its significance lies in:

Identifying a Critical Vulnerability: Demonstrating that LLMs are highly sensitive to syntactic variations in mathematical inputs, particularly when mathematical reasoning is required.
Adversarial Exposure: Showing that these vulnerabilities can be exploited via black-box attacks to induce code generation failures with minimal prompt modifications.
Practical Mitigation: Proposing a lightweight, model-agnostic pre-processing technique (formula reduction) that significantly enhances reliability without requiring model retraining or architectural changes.
Benchmarking: Providing a formal framework, a dataset of 52 prompts with mutation rules, and evaluation metrics to assess robustness in future research.

The authors conclude that while LLMs show promise in code generation, their lack of syntactic robustness in mathematical contexts necessitates the use of mitigation strategies like formula reduction before deployment in critical or automated pipelines.