- The paper introduces Wingbuilder, a 54-component aerospace Grasshopper library, an 18-task Aerospace Visual Programming Dataset, and a GPT 5.4 ReAct copilot for wing design.
- The paper finds that copilot assistance increases easy-task time from 34 to 78 seconds and medium-task time from 62 to 172 seconds, but improves hard-task time from 259 to 173 seconds and completion from 2/6 to 5/6.
- The paper shows that high-latency LLM assistance is most useful for complex aerospace design tasks, while small-scale evaluation, proprietary-model dependence, and unclear reasoning traces remain barriers to deployment.
Overview
This paper presents an LLM-based visual programming copilot for aerospace geometric design, built on a ReAct-style reasoning loop over Grasshopper canvases and powered by GPT 5.4. The work addresses a gap the authors identify explicitly: despite advances in LLM- and VLM-based visual code completion, no aerospace OEM has publicly deployed an LLM-based geometric design copilot, largely because the industry prioritizes safety and explainability over rapid adoption. The paper makes three contributions: (1) Wingbuilder, a Grasshopper plugin library of aerospace-specific geometry abstractions; (2) an Aerospace Visual Programming Dataset (AVPD) of 18 expert-designed tasks with ground-truth solutions; and (3) quantitative and qualitative results from a user trial with two experienced aerospace engineers from Airbus.
The paper situates itself at the intersection of two research threads. The first is LLM support for visual programming environments such as LabVIEW, Visual Blocks, ComfyUI, Simulink, and Scratch, where recent approaches include agentic frameworks combining Chain-of-Thought with reinforcement learning (Xu et al., 11 Jun 2025), reflective GRPO-based planning for Simulink (Liang et al., 8 Jan 2026), pseudocode generation for node-graph workflows (Zhou et al., 2023), VLM distillation for sub-billion-parameter visual program generation (EMNLP Findings 2025), retrieval-augmented fine-tuning with DPO for industrial ladder diagrams [ACL 2025], and VLM prompting with visual cues for block programming (Chen et al., 2024). The second thread is LLM-assisted parametric CAD, split into one-shot generation methods — transformer autoencoders (Wu et al., 2021), VLM-augmented shape description (Khan et al., 2024), CAD-sequence-to-code data synthesis (Li et al., 7 May 2025), and image-conditioned sketch generation (ECCV 2024) — and iterative CAD agents that plan and reason over CAD operations (Mallis et al., 2024, Ni et al., 1 Aug 2025).
The key methodological differentiation is deliberate: unlike CADDesigner-style agents that render intermediate models for LLM visual inspection, this copilot's ReAct formulation omits any visual analysis step. The rationale is to exploit GPT 5.4's pre-trained knowledge of Grasshopper component layouts directly, working on the canvas representation rather than rendered geometry. The authors also argue their task domain — full aerospace wing design — is substantially more complex than the single-component tasks (flanges, screws) typical of existing LLM-CAD evaluations.
Wingbuilder library and AVPD
Wingbuilder provides 54 custom Grasshopper components across seven categories: airfoil construction and transformation (10), wing assembly including planform construction and segment lofting (8), part factories for structural elements and control surfaces (14), cross-section primitives (8), analysis modules (8), geometry evaluation utilities (5), and a units-aware dimensional parameter. The design principle is abstraction: engineers compose high-level domain objects (airfoil, wing segment, spar, rib) with inputs labeled in aerospace vocabulary (chord, sweep, dihedral, span position) rather than raw geometric coordinates. Tasks that would otherwise require dozens of low-level primitives reduce to a handful of components — a property that also shrinks the action space the LLM must reason over.
The AVPD contains 18 canvases designed by a postdoc-level aerospace expert, averaging 37 components per canvas, each paired with a free-text task description, a completed gold-answer canvas, and a partially hidden starting canvas. Tasks are graded easy (2 minutes), medium (4 minutes), or hard (8 minutes). The dataset also ships textual descriptions of all Wingbuilder components for inclusion in completion prompts.
Copilot architecture
The copilot follows a tailored ReAct workflow (Yao et al., 2022). Each iteration prompts the LLM to generate free-text reasoning about needed actions, then select a concrete action executed via copilot-server Grasshopper scripts, producing observations (component options or canvas status reports) fed into the next call. The loop terminates when the LLM deems the task ready for human review. Three system prompts structure behavior: an agent instruction prompt defining the workflow (read canvas, search components, build a completion JSON, preview with up to three error-correction retries before automatic commit), a Grasshopper reference prompt covering data-tree and list operations, and a Wingbuilder reference prompt encoding the canonical wing assembly pipeline (planform → airfoils → scale → position → loft → build → add parts → deconstruct).
Two interaction properties are notable. First, LLM reasoning traces are surfaced in the UI, providing a degree of explainability relevant to aerospace adoption concerns. Second, the tool is advisory rather than autonomous: engineers can edit the canvas at any time, the copilot adapts, and suggestions can be previewed, accepted, or discarded.
User evaluation
The trial involved two experienced aerospace engineers from a large aircraft manufacturer, each completing the same 18 tasks (half control, half copilot-assisted, ordered easy-to-hard with control first) after a 60-minute training session, within a 120-minute protocol and per-task time budgets after which tasks were abandoned.
| Condition |
Avg time |
Completed |
| Easy, no copilot |
34s |
6/6 |
| Easy, copilot |
78s |
6/6 |
| Medium, no copilot |
62s |
4/6 |
| Medium, copilot |
172s |
4/6 |
| Hard, no copilot |
259s |
2/6 |
| Hard, copilot |
173s |
5/6 |
The headline result is a difficulty-dependent inversion. For easy and medium tasks the copilot was a net negative: it more than doubled completion time on easy tasks (34s vs 78s) and nearly tripled it on medium tasks, with no completion-rate benefit. For hard tasks the effect reversed sharply — participants were faster (173s vs 259s) and completed 5 of 6 tasks versus 2 of 6 unaided, where participants frequently gave up entirely. This asymmetry is attributable to inference cost: the ReAct loop averaged roughly 9 seconds per step, about 12 steps per solution, and approximately 113 seconds per solution. A near-two-minute wait is only justifiable when the underlying task is long enough; the authors attribute the latency to current commercial LLM inference speeds rather than their architecture, and expect improvement as models and GPU hardware mature.
Qualitative questionnaire responses (Likert scale) were broadly positive on helpfulness and future-use intent, particularly for hard tasks where participants struggled to start. Two caveats emerged: suggestions were reported as hard to understand, and the ReAct reasoning traces were described as somewhat confusing — indicating that exposing reasoning improves trust only if the traces themselves are legible. Participants expressed willingness to use such tools in future work.
Limitations and open questions
The paper is candid about several constraints. The evaluation rests on two participants from a single organization completing a fixed task order, so the quantitative results should be read as indicative rather than statistically robust; no variance or significance testing is reported. The system depends entirely on a commercial frontier model (GPT 5.4): the authors report from informal testing that open-source LLMs currently cannot execute the ReAct methodology accurately enough to serve as a viable copilot, which has implications for deployability in aerospace settings where data sovereignty and certification may preclude external API calls. Whether fine-tuned open-source models or heterogeneous ensembles — the authors' stated hypothesis being that different base models exhibit distinct visual-programming failure modes — can close this gap remains unverified. Methodologically, the omission of a visual analysis step trades grounding in rendered geometry for reliance on pre-trained layout knowledge; the paper does not measure how often this leads to plausible-but-wrong completions on novel canvas states. Finally, expanding the AVPD beyond 18 tasks is identified as necessary both for broader evaluation and for any future fine-tuning effort.
Conclusion
This paper delivers a concrete, open-source instantiation of an LLM copilot for aerospace wing design in Grasshopper, together with the first domain-specific dataset (AVPD) for evaluating visual code completion in this setting. Its central empirical finding — that multi-step ReAct reasoning is counterproductive for short tasks but yields materially higher completion rates and lower times on complex ones — offers a practical deployment heuristic: LLM copilots with high per-suggestion latency should be positioned as aids for difficult, time-consuming design work rather than as always-on assistants. The demonstrated willingness of practicing aerospace engineers to adopt such tooling, combined with the acknowledged dependence on proprietary frontier models and a small user sample, frames the immediate open problem: achieving comparable copilot accuracy with deployable, auditable models under aerospace-industry constraints.