All summaries · 2026-09-03

IterCAD: Iterative Program Repair for CAD Code Generation from Orthographic Views

Yuchuan Wu, Ke Niu, Haiyang Yu, et al.

arXiv:2608.24020 · abstract · pdf · summarized by meta/muse-spark-1.3-contributor on 2026-09-03

The one-paragraph version

IterCAD tackles a very practical engineering task: turning dimension-annotated orthographic drawings — the standard front, top, and side views with measurements that engineers actually use — into executable CAD code that builds the correct 3D part. Instead of asking a vision-language model to guess the whole program in one shot, the authors reformulate generation as iterative program repair. The model writes an initial draft, then repeatedly looks at its current code, writes a short rationale about what matches or mismatches the target drawings, makes an explicit choice to REVISE or STOP, and if revising, writes improved code. To teach this, they build a new supervision set called IterCAD-RS with both broken-but-fixable examples and already-correct examples, then train in three stages: learn to draft, learn to revise-or-stop, then optimize the whole multi-turn trajectory with reinforcement learning. On the CADExpert benchmark this closed loop beats strong one-shot systems on both shape accuracy and whether the code even runs.

The problem they're solving, and why it matters

In real manufacturing, ideas do not go straight to 3D. They go through engineering drawings: orthographic projections, meaning flat views looking straight at an object from the front, top, and side, plus precise dimension annotations like lengths, diameters, and depths. Someone must then translate those 2D views into a parametric CAD model, meaning a model defined not as a cloud of points but as a recipe of operations — draw this profile, extrude it that far, cut a hole here, round that edge.

That recipe form is what makes CAD code valuable: it is compact, editable, and directly usable downstream for simulation and fabrication. A mesh or point cloud cannot be easily edited by changing a hole diameter from 10 to 12; a program can.

The difficulty is that generating correct CAD code is tightly coupled and unforgiving. Here tightly coupled means an early choice affects everything after it. Pick the wrong sketch plane, meaning which flat surface you start drawing on such as XY versus XZ, or the wrong extrusion depth, or the wrong order of cuts, and the rest of the program may fail to run or produce the wrong shape. The paper shows that current vision-language approaches usually do one-shot generation, meaning they map drawings to code in a single pass with no chance to check their work. Once an error is made, there is no inspection step, no comparison to the target views, and no repair.

This matters because for CAD, approximate is often useless. A small error in diameter or Boolean operation, meaning an operation that adds or subtracts one solid from another like union or cut, can make the code non-executable or geometrically wrong. At the same time, CAD has a helpful property: intermediate outputs are executable programs that can be checked and fixed. IterCAD exploits that property.

The key idea, in plain words

Treat CAD generation not as writing the final answer immediately, but as fixing your own draft until it is good enough to stop.

Concretely, imagine a student doing a drawing exercise. First they make a rough solid: a block of the right overall size. Then they hold it next to the target engineering drawing and ask: is the outer silhouette right? Are the holes missing or in the wrong place? Is the thickness wrong? If something is off, they revise. If everything matches, they stop.

IterCAD gives a large vision-language model that same loop, inside a single unified model rather than as an outside checker. At each turn the model must produce three things: a thinking trace about discrepancies, an explicit decision of REVISE or STOP, and the CAD code itself. Stopping is a learned action, not a fixed rule like always do three rounds. Easy parts stop early; hard parts get more turns.

To make that learnable, the authors had to solve a data problem. Standard datasets only give the final correct program, not examples of what a plausible mistake and its fix look like, and not examples of when to stop. So they synthesize both: wrong-but-still-runnable versions paired with a REVISE instruction, and correct versions paired with a STOP instruction.

How it actually works, step by step

1. Formulation as a revise-or-stop walk. The input is the target views, call them the drawings. The process starts from an empty state with no code. At each turn, the model sees the drawings plus its own history — its previous rationales, decisions, and code — not just the latest code snippet in isolation. It then outputs a rationale, a decision, and code. If the decision is REVISE, that new code becomes the starting point for the next turn. If STOP, that code is taken as final. The walk ends on STOP or after a maximum, which is 4 turns in this paper.

2. Building IterCAD-RS supervision. Starting from correct programs in the training split of CADExpert, an existing benchmark for executable CAD code generation, the authors first convert each program into an intermediate structured description they call ShapeSpec. Think of ShapeSpec as a parts list of geometry: what the base profile is, what extrusion was used, what cuts or holes or edge finishes exist. They then inject one or two controlled perturbations in that structured space rather than randomly scrambling code text, so the result still runs but looks wrong.

For example, a body-level perturbation might switch the sketch plane so the whole part is oriented wrong, change the base profile shape, or change extrusion height so the part is too thin. A cut perturbation might change an inner cavity size. A hole-pattern perturbation might change hole count, layout radius, or diameter. An edge-finish perturbation might switch a fillet, meaning a rounded edge, to a chamfer, meaning a beveled flat edge, or change its size. A topology-level perturbation might add an extra spurious cut or hole. Each broken version is paired with the original correct version plus a short auto-generated repair description for the thinking field. Correct versions are separately used to teach STOP. After filtering out degenerate or unchanged cases, this yields 22,000 revise-or-stop examples. The paper leaves exact conversion, filtering rules, and repair-text generation to supplementary material, so those details are unclear from the main text alone.

3. Three-stage training. Stage I learns initial drafting from 8,960 standard drawing-to-code pairs, but already in the same think-decide-code format with decision forced to REVISE. This establishes basic vision-to-code mapping and format consistency.

Stage II learns revision and stopping from IterCAD-RS. Given drawings plus history, the model must both fix inconsistent states when needed and recognize when no fix is needed.

Stage III optimizes the full multi-turn policy with GRPO, meaning Group Relative Policy Optimization, a reinforcement learning method that compares multiple sampled trajectories for the same input and favors better ones. Here a trajectory means the whole sequence of drafts and revisions, not just a single correction step. The data for this stage is 4,480 additional samples disjoint from the earlier stages. All stages use one epoch at a small learning rate, with 4 sampled rollouts per example in Stage III.

4. Reward design. Because the final STOP turn may not contain new code, the authors evaluate the effective final code, meaning the most recent valid program in the history. The total reward is dominated by final geometric quality, with small auxiliary bonuses for following the required format, producing syntactically valid and executable code, and making sensible stop decisions — for instance, discouraging stopping early when the shape is still poor. Exact formulas are deferred to supplementary material.

5. Inference. At test time there is no external checker. The model drafts, then decides on its own whether to revise or stop, up to 4 rounds.

What they showed — results, honestly, with limitations

The authors test on CADExpert using four standard measures. Intersection-over-Union, or IoU, measures volumetric overlap between predicted and true shapes where higher is better. Mean and Median Chamfer Distance measure average point-cloud discrepancy where lower is better, with median less sensitive to outliers. Executability measures what fraction of programs actually run.

Their stronger system, built on Qwen3.5-9B, reaches 91.61% IoU, 0.5387 Mean Chamfer Distance, 0.1038 Median Chamfer Distance, and 99.33% executability. That beats the strongest one-shot baseline they cite, CME-CAD, which gets 80.71% IoU, 1.00 Mean Chamfer Distance, and 98.25% executability. Their lighter system built on Qwen3-VL-8B-Instruct also beats that baseline geometrically at 85.10% IoU and 0.8564 Mean Chamfer Distance, with 97.31% executability. General-purpose vision-language models without CAD-specific training score far lower, which supports the need for task-specific training.

Ablations, meaning removing parts to see what matters, are revealing. Simply adding Stage II supervision but still testing with single-turn generation does not help and can even hurt. The benefit appears only when multi-turn inference is allowed: on the Qwen3.5 backbone, Stage I+II goes from 54.46% IoU single-turn to 60.40% with multi-turn. Stage III is what coherently ties drafting, revising, and stopping together; the full three-stage plus multi-turn system jumps to 91.61%. Removing multi-turn at test time drops it back to 89.91%.

Behavior analysis shows monotonic improvement across turns, mostly in early turns, plus adaptive stopping: about 90.8% of examples stop by turn 2 and 98.9% by turn 3 for the larger backbone, so few need all four turns. Extra cost is modest: average time rises from 0.338 to 0.397 seconds per sample for the larger model, and from 0.258 to 0.435 seconds for the smaller one.

Limitations to keep in mind: all main results are on CADExpert only, with dimension-annotated drawings as input, so we do not learn from this paper how well the policy transfers to natural images, text prompts, or other CAD languages. The maximum horizon is only 4, the training details for ShapeSpec, filtering, and rewards are not fully verifiable from the main text, and there is no human or downstream editability evaluation beyond executability and geometric distance.

Why this might matter to me

For spatial reasoning in vision-language models, IterCAD is a concrete case where checking beats longer single-pass reasoning. The model must relate flat annotated views to a 3D construction sequence, spot projection mismatches and size errors, and ground language measurements to numeric parameters. The explicit REVISE versus STOP head is effectively a learned confidence and verification signal — highly relevant if you care about models that know when they are done.

For world models and iterative agents, this is a small, verifiable world with execution as ground truth. Each intermediate program is a testable state of the world: it runs or it does not, and its shape either matches the drawings or does not. Stage III shows how to turn supervised drafting plus local fix supervision into a trajectory-level policy with reinforcement learning. That pattern — synthesize plausible intermediate mistakes, supervise repairs, then optimize stopping over rollouts — could generalize to other procedural worlds where simulation or rendering gives feedback.

For text-to-CAD and parametric geometry, the perturbation taxonomy is directly reusable. It enumerates the failure modes that matter in practice: wrong plane, wrong profile, wrong extrusion, missing or extra cuts and holes, wrong layout, wrong fillet versus chamfer. If you build text-to-CAD or sketch-to-CAD systems, that taxonomy plus the ShapeSpec idea offers a way to generate targeted repair data and to evaluate whether models fix structure versus merely tweak numbers.

For 3D generation and scene representation, IterCAD argues for program-like, editable representations over raw geometry when precision and editability matter. Instead of diffusing points or voxels, the model searches in the space of construction programs and refines them by visual discrepancy. The adaptive stopping result — most gains in one or two fixes with bounded cost — suggests iterative refinement can be practical for 3D pipelines if termination is learned rather than fixed.

Terms worth knowing