4.4 KiB
4.4 KiB
type:: REVIEWS tags:: year:: 2024 venue:: TOSEM full-title:: Towards AI-Native Software Engineering (SE 3.0): A Vision and a Challenge Roadmap date-start:: 16-11-2024 - 08:51 date-submitted:: 16-11-2024 external-links:: status:: DONE deadline-submission:: file:: @Towards AI-Native Software Engineering (SE 3.0): A Vision and a Challenge Roadmap parent:: todoist:: https://app.todoist.com/app/task/tosem-2024-0255-r1-revised-version-6WPJhjxPqQhVWh4g
- ### [[Highlights]]
- ### [[Comments]]
- Summary: The paper presents the author's vision of using AI technology at the next level to support the development of software systems. The authors envision the usage of AI beyond the current Copilot-like interactions where human developers still drive the entire process. Next-generation AI-based tools are presented, including Teammate.next, IDE.next, Compiler.next, Runtime.next, and FM.next. The authors envision the availability of AI-based pairs that developers can interact with since the definition of the system's requirements. A set of challenges hampering the achievement of such a vision have been discussed.
- Comments: The paper is an interesting reading, overall well structured and organized. Even though I understand the visionary nature of the manuscript, it lacks sufficient technical details regarding the feasibility and practical implementation of the proposed core technologies. For instance:
- I see the SLA-aware part very complex and it is not clear how to decide what are the requests that can be managed locally and those that instead require more sophisticated cloud instractures. How will the system determine which requests can be handled locally and which require cloud-based resources? This decision-making process is not clearly explained and seems to be an essential component of the proposed system.
- The manuscript also lacks specificity on the SLAs themselves. What specific attributes (e.g., latency, throughput, error rates) are intended to be part of the agreements in the SE 3.0 context? How will these SLAs vary across different application scenarios?
- While the concept of curriculum engineering for training foundational models is interesting, its application in software engineering remains unclear. How would the curriculum be defined and maintained over time, and what specific software engineering domains or processes (e.g., debugging, testing, architectural design) will benefit most from this approach?
- The paper assumes interaction with a singular AI counterpart, which oversimplifies the reality of current AI ecosystems. In practice, developers often have access to multiple AI agents, each specializing in specific tasks or offering distinct capabilities. For instance, one agent may excel at generating code snippets, while another is better suited for testing or optimization tasks. This raises questions about how SE 3.0 technologies will mediate and align a multitude of AI agents. What mechanisms will ensure consistency and coherence in their responses, particularly when agents provide conflicting or contradictory suggestions?
- The paper could benefit from discussing how the envisioned technologies will address variability in computational infrastructure across organizations. For example, how would smaller companies or even universities with limited resources effectively leverage such systems?
- The manuscript introduces a broad and ambitious set of technologies, from Teammate.next and IDE.next to Runtime.next and FM.next. However, it does not clearly prioritize these technologies or outline which components require the most urgent focus from the community. For instance, is the development of conversational alignment in Teammate.next more pressing than curriculum engineering for FM.next? Highlighting these priorities would help guide the community in directing its research efforts, and could provide insights on which components are most critical to achieve and validate the proposed SE 3.0 vision.
- Typos:
- Line 275: ... redefines the those activities ... -> redefines those activities
- Line 541: ... natural language in inherently ambiguous ... -> ... natural language is inherently ambiguous ...
-
- ### [[REVIEWS/Notes]]
- ### YELLOW CONCERNS
background-color:: yellow
- {{query (and [[ffd400]] [[TOSEM-2024-0255.R1]] )}}
collapsed:: true
- ### ❓️Questions
- {{query (and [[question]] [[TOSEM-2024-0255.R1]] )[[question]]}}
query-table:: true
query-properties:: [:block]