Source-linked AI summary

Towards AI-Native Software Engineering (SE 3.0): A Vision and a Challenge Roadmap

Ahmed E. Hassan, Gustavo A. Oliva, Dayi Lin, Boyuan Chen, Zhen Ming, Jiang

arXiv:2410.06107v2cs.SEcs.AI

TL;DR

AI-assisted SE 2.0 leaves developers with cognitive strain and task-driven work, while complex FMware serving must meet SLAs and use heterogeneous hardware efficiently. The paper proposes intent-centric, conversation-oriented SE 3.0 with AI teammates and supporting technologies; it presents this as a vision and challenge roadmap, while cautioning that models alone are not enough.

  • Problem

    SE 2.0 leaves developers with cognitive overload, while complex FMware must be served and evolved efficiently under SLAs across heterogeneous hardware.

    Source: §1 · p. 1, §4.3 · p. 15
  • Method

    The paper proposes intent alignment through conversation between developers and AI teammates, followed by AI-driven code synthesis and an SE 3.0 technology stack.

    Source: §1 · p. 2, §3.3 · p. 8, §3.4 · p. 8
  • Results

    The paper’s supported conclusion is a vision for intent-centric, AI-native development that combines human and AI strengths with efficient, knowledge-driven models.

    Source: §5 · p. 19
  • Takeaways & Limitations

    The vision treats SE 3.0 as a symbiotic process that uses human and AI strengths, rather than relying on AI as an assistive tool alone.

    Source: §1 · p. 2, §5 · p. 19

    Foundation models are only one part of enabling efficient and effective FMware development, so overfocusing on the models repeats an SE 2.0 pitfall.

    Source: §3.6 · p. 12

Abstract

from arXiv · show

The rise of AI-assisted software engineering (SE 2.0), powered by Foundation Models (FMs) and FM-powered coding assistants, has shown promise in improving developer productivity. However, it has also exposed inherent limitations, such as cognitive overload on developers and inefficiencies. We propose a shift towards Software Engineering 3.0 (SE 3.0), an AI-native approach characterized by intent-centric, conversation-oriented development between human developers and AI teammates. SE 3.0 envisions AI systems evolving beyond task-driven copilots into intelligent collaborators, capable of deeply understanding and reasoning about software engineering principles and intents. We outline the key components of the SE 3.0 technology stack, which includes Teammate$.$next for adaptive and personalized AI partnership, IDE$.$next for intent-centric conversation-oriented development, Compiler$.$next for multi-objective code synthesis, and Runtime$.$next for SLA-aware execution with edge-computing support. Our vision addresses the inefficiencies and cognitive strain of SE 2.0 by fostering a symbiotic relationship between human developers and AI, maximizing their complementary strengths. We also present a roadmap of challenges that must be overcome to realize our vision of SE 3.0. This paper lays the foundation for future discussions on the role of AI in the next era of software engineering.

1 Introduction

The paper argues that AI-assisted, task-driven software engineering leaves developers with substantial cognitive work and proposes an intent-centric, conversation-oriented shift to AI-native SE 3.0. The vision was informed by literature surveys, discussions with academic and industrial leaders, internal development experience, and industry partnerships.

1 Introduction

  • SE 2.0 leaves developers to decompose problems, prompt assistants, evaluate suggestions, debug failures, and iterate, while models also face training inefficiencies and code-quality risks.The paper also warns that AI-generated code can contaminate future training data and further degrade model quality.Source: §1 · pp. 1–2
  • SE 3.0 shifts development from code-driven tasks to iterative conversations around intents, with AI evolving from a copilot into a teammate.The vision pairs human and AI strengths and calls for models with deep SE knowledge, coding skills, and advanced reasoning.Source: §1 · p. 2
  • The vision draws on literature surveys, discussions with academic and industrial leaders, internal development experience, and interactions with more than 40 companies through OPEA.The authors also cite practical experience developing FMware and the SE 3.0 technology stack.Source: §1 · p. 2

2 A critical analysis of Software Engineering 2.0 (AI-assisted SE)

The section contrasts AI-assisted SE 2.0 with earlier software engineering and examines limitations in its development workflow, model training, generated code, and autonomous-engineer approaches.

2.1 What is Software Engineering 2.0?

  • SE 2.0 retains SE 1.0’s code-centric process while using AI models to support traditional software engineering activities.AI coding assistants can write, test, and debug code using patterns learned from large datasets and model fine-tuning.Source: §2.1 · pp. 2–3

2.2.1 High cognitive overload on humans.

  • In SE 2.0, developers drive code creation and must decompose problems, plan solutions, and explore options within their cognitive limits.The resulting workflow remains inefficient despite potential productivity gains from coding assistants, with prompting, testing, and debugging adding to the workload.Source: §2.2.1 · pp. 3–4

2.2.2 Inefficient (and ineffective) model training.

  • Frontier-model training relies on vast, unstructured internet data, driving computational, energy, and financial costs while leaving specialized reasoning and long-term model maintenance challenging.The passage also identifies data redundancy, noisy information, and repeated retraining as inefficiencies.Source: §2.2.2 · p. 4

2.2.3 Suboptimal code quality and the additive bias in AI coding assistants.

  • AI assistants’ bias toward additive suggestions can produce bloated, complex code that is harder to maintain, evolve, and modularize.He et al. [46] report that Cursor boosts short-term velocity while increasing code complexity and static-analysis warnings; the passage also notes unreliable multi-file edits and reduced trust.Source: §2.2.3 · p. 5
  • Widespread assistant use and difficulty distinguishing AI-generated from human-written code risk contaminating future model-training datasets and degrading outputs over time.The authors say this feedback loop threatens to increase the long-term cost of integrating AI into software engineering workflows.Source: §2.2.3 · p. 5

2.3 How about autonomous software engineers?

  • TRAE ranks first on SWE-Bench Verified in the passage’s account, solving 75.2% of benchmark tasks, but the authors say real-world performance remains unclear.They cite limited benchmark scope—Python projects, 12 projects total, and about 70% of tasks from three projects—and concerns about intent alignment and off-the-shelf models.Source: §2.3 · p. 5

3 Our Vision of Software Engineering 3.0 (AI-native SE)

SE 3.0 recasts software development as intent-centric collaboration between humans and AI, supported by a proposed technology stack. The vision spans adaptive teammates, conversational development, intent synthesis, SLA-aware execution, and knowledge-driven models.

3.1 What is Software Engineering 3.0?

  • SE 3.0 makes AI intrinsic to software engineering and shifts development from code-driven work to intents expressed through conversations between humans and AI teammates.The proposed stack supports this shift; the paper focuses on desired attributes rather than concrete implementation.Source: §3.1 · pp. 6–7

3.2 Teammate.next: From static and impersonal coding assistants to self-evolving personalized mentors

  • Teammate.next is envisioned as an adaptive, personalized partner that learns from feedback and self-reflection, clarifies intents, and mentors developers.It can retain project constraints and preferences, and explain its coding choices and trade-offs.Source: §3.2 · pp. 7–8

3.3 IDE.next: From code-centric to intent-centric IDEs

  • IDE.next uses back-and-forth conversation to help developers express and refine intents before the AI teammate drives code creation.Code is hidden by default but can be inspected and edited in low-level debugging; development iterates until the developer is satisfied.Source: §3.3 · p. 8

3.4 Compiler.next: From logic-rule realization to search-space exploration

  • Compiler.next synthesizes intents into runnable software through iterative search, code mutation, and self-reflection that evaluates intent fit and code quality.Its multi-objective optimization balances accuracy, latency, and cost, while goal tracking derives and adapts tests from intents.Source: §3.4 · pp. 8–9

3.5 Runtime.next: From the serving of models to compound apps

  • Runtime.next targets different application SLAs with priority-based routing and observability; its prototype decomposes workflow SLAs into per-task slack.In a real-world deployment under increasing load, evaluations showed fewer SLA violations and better hardware utilization than non-SLA-aware serving frameworks; edge routing to smaller models remains an open challenge.Source: §3.5 · pp. 10–11

3.6 FM.next: From data-driven inefficient FMs to knowledge-driven efficient FMs

  • FM.next is envisioned as a knowledge-driven model trained on a curated software-engineering curriculum, with competence spanning the software lifecycle.Curriculum engineering combines curated knowledge with synthetic examples and supports ongoing refinement; curricula are to be managed and versioned as reusable assets.Source: §3.6 · pp. 11–12
  • The paper cautions that improving FMs alone is insufficient for efficient and effective FMware development.It presents the stack as a vision for discussion, not a concrete implementation.Source: §3.1 · p. 7, §3.6 · p. 12

4 Challenges

The section identifies major challenges to realizing SE 3.0 and sketches research directions for addressing them. The challenges span human-AI alignment, code synthesis, runtime, model understanding, prompt engineering, and broader open questions.

4.1 Speeding up human-AI alignment

  • A 150-scenario study found that ToM-enhanced conversation significantly improved intent clarification, requirement completeness, and human-AI alignment.The proposed teammate learns a context-adjustable model of the developer from prior interactions and should provide signals that help humans judge whether their intent was understood; ToM is not a silver bullet, and requirements engineering remains important.Source: §4.1 · p. 14

4.2 Improving the efficiency of code synthesis

  • Compiler.next’s search-based compilation framework showed that reusing compilation traces, semantic caching, and self-reflective heuristics can improve code-synthesis efficiency and accuracy [28].The vision also proposes using local and crowdsourced search histories to guide future searches, tailor heuristics, and personalize synthesis.Source: §4.2 · p. 15

4.3 Improving runtime performance

  • The vision is to compile FMware workflows into declarative graphs that preserve rich intent, enabling runtime optimizations to reduce inference latency and data movement while maximizing resource utilization.Preliminary FMArts Fusion Runtime results show latency improvement in the order of 30% compared to Ray Serve [45].Source: §4.3 · pp. 15–16
  • For edge routing, adaptive in-context learning is proposed to handle unseen tasks; on MMLU subsets, it routes 50% fewer requests to expensive models while maintaining around 90% of general response quality.The section notes that profiled prompt datasets may not match real-world requests and that static routing can send requests to costly cloud models unnecessarily.Source: §4.3 · p. 16

4.4 Improving FM’s understanding of code and SE

  • Improving FM understanding may require richer runtime data, such as execution logic, variable states, and call stacks, alongside curriculum design and methods for studying internal representations.Symbolic execution and data-flow analysis are suggested to connect static and runtime information; designing an effective SE curriculum remains an open challenge.Source: §4.4 · pp. 16–17

4.5 Eliminating the need for prompt engineering

  • The vision shifts prompt construction to AI through intent-aligned training and user-feedback-derived examples and templates; OpenAI’s reasoning-model guidance discourages zero-shot chain-of-thought prompting [5].The section notes that prompt techniques do not generalize across models and that existing automatic prompt-engineering approaches can be costly or complicated to set up.Source: §4.5 · pp. 17–18, Figure 7 · p. 19

4.6 Other open questions

  • Other open questions range from SE education, programming languages, and IDE design to benchmarking, ownership of personalized teammates, jobs, open innovation, and equity.The authors describe these as questions for which they have not yet developed a thorough vision.Source: §4.6 · p. 18

5 Conclusion

The conclusion presents SE 3.0 as an intent-centric, AI-native process intended to combine human and AI strengths, in response to SE 2.0’s cognitive overload and slow, error-prone, costly development. It calls for parallel research across the stack and notes that the vision can be assessed as a whole only after prototypes exist for all components.

5 Conclusion

  • SE 3.0 replaces task-driven, code-centric development with an intent-centric, conversation-oriented process and a symbiotic human-AI relationship.The vision also calls for efficient knowledge-driven models with high reasoning capabilities.Source: §5 · p. 19
  • Challenges across the five stack components should be researched in parallel, but the vision can only be assessed as a whole once prototypes exist for all components.IDE.next depends on the other components to be fully functional and useful.Source: §5 · pp. 19–20
  • The paper aims to prompt deeper community discussion about rethinking software engineering with AI at its core.The authors welcome official responses, including opposing views.Source: §5 · p. 20
  • The authors identify democratization as a particularly important challenge and see cost-effective training, serving, and “small and mighty” FMs as promising directions for lowering barriers to entry.They note that early commercial vibe-coding platforms offer glimpses of SE 3.0, while its realization remains uncertain.Source: §5 · p. 20
Loading 2410.06107v2…