22 lines
3.8 KiB
Markdown
22 lines
3.8 KiB
Markdown
type:: [[REVIEWS]]
|
||
tags::
|
||
year:: 2026
|
||
venue:: [[ICSE2026-WS]]
|
||
full-title:: AI-Assisted Modeling: DSL-Driven AI Interactions
|
||
date-start:: [[07-12-2025]] - 16:08
|
||
date-submitted::
|
||
external-links::
|
||
status:: [[DONE]]
|
||
deadline-submission::
|
||
file:: [[@AI-Assisted Modeling: DSL-Driven AI Interactions]]
|
||
parent::
|
||
todoist:: https://app.todoist.com/app/task/l-arc-2026-new-review-assignments-6fGCJrj25FF2VXw8
|
||
|
||
- ### [[Comments]]
|
||
- SUMMARY: The paper proposes an approach to assist programming activities by integrating domain-specific modeling techniques with real-time graphical visualizations of AI-generated code. The conceived technique has been implemented as a Visual Studio Code extension for the Lingua Franca language that enables iterative model development through structured prompt templates and dialog-driven feedback mechanisms.
|
||
- COMMENTS: The paper is about an interesting application of AI technologies and domain-specific modeling. However, I have some major concerns that are related to the presentation of the work. Most notably, the paper's primary goal, whether it targets modeling activities (e.g., defining system behavior) or code development (e.g., generating implementation artifacts), remains unclear. The examples (e.g., adding a "compute" reactor that multiplies input by three) and workflow descriptions suggest a modeling-centric focus, yet phrases like "automatically integrated in the overall system" imply code generation is the end goal. This dual perspective risks confusion for readers. The authors should explicitly state whether the extension prioritizes model refinement before code generation or enables parallel modeling/code development with visual feedback.
|
||
- The concept of "visual verification tailored to DSL development" also lacks specificity. The paper mentions model checking but does not clarify the scope of verification, whether it involves syntax validation, semantic consistency checks, or runtime behavior testing. Given the example where the multiplier function is defined in code rather than the model (e.g., "multiplies input by three" vs. "multiplies input by five"), it is essential to specify how the system handles manual interventions. For instance, if a model source is altered post-generation, does the system automatically update the code? The current description implies such updates are manual, yet the workflow claims to support "iterative" refinement without detailing this feedback loop.
|
||
- Additionally, the paper underestimates the complexity of DSL-specific tooling. Listing 2 shows the Lingua Franca timer definition, but the efforts required to define language-specific APIs are not properly discussed. The authors note that "generating graphical models via AI is technically demanding" yet fail to address how this challenge scales across diverse DSLs. A more thorough discussion of the trade-offs in API design, particularly for languages with complex semantics, would strengthen the paper's relevance. The example in Figure 4 further highlights this gap: the configuration step (e.g., reactor connections) is omitted, and the Lingua Franca language's settings are not visualized. Clarifying that this is a modeling phase rather than a code generation step would prevent misinterpretation.
|
||
- Overall, the approach is innovative but requires sharper articulation of its boundaries and mechanisms. The paper would benefit from a dedicated section addressing how manual interventions (e.g., modifying model sources) trigger automated code updates, as this is central to the claimed "iterative" workflow. With these refinements, the contribution could more effectively advance the field of DSL-driven AI interactions.
|
||
- Despite these considerations, which can be addressed through minor revisions, the paper presents interesting insights to be discussed during the workshop.
|
||
- |