Skip to Content
You are currently on the new version of our website. Access the old version .
MDPIMDPI

Advanced

ComputersComputers
PDF
  • Article
  • Open Access

6 November 2026

23 Pages

From Code-Centric to Intent-Centric Software Engineering: A Reflexive Thematic Analysis of Generative AI, Agentic Systems, and Engineering Accountability

,
,
,
,
,
,
and
1
School of Computer and Information Sciences, University of the Cumberlands, Williamsburg, KY 40769, USA
2
School of Business and Information Technology, Purdue University Global, Indianapolis, IN 46240, USA
3
Department of Computer Science, University of Calicut, Thenhipalam 673635, India
*
Author to whom correspondence should be addressed.
Computers2026, 15(11), 809;https://doi.org/10.3390/computers15110809
This article belongs to the Special Issue Machine Learning: Innovation, Implementation, and Impact (2nd Edition)
Version Notes
Order Reprints

Abstract

Generative artificial intelligence (GenAI) and agentic systems are shifting software engineering from code-centric production toward intent-centric human-agent work, in which natural language, repository context, tools, tests, and governance shape delivery. Prior studies examine code generation, AI pair programming, and software engineering agents, but less is known about how public technical discourse and peer-reviewed evidence jointly frame the profession’s near-term transition. This study addresses that gap through a reflexive thematic analysis (RTA) of public-discourse and document analysis. The corpus combines peer-reviewed software engineering and AI literature, technical benchmarks, public talks and interviews, essays, product-facing technical announcements, and X-originated discourse. The corpus contains 49 unique artifacts across three evidentiary layers: 28 peer-reviewed sources, 6 technical preprints/benchmarks, and 15 public discourse artifacts. Sources were organized using a corpus register, codebook, coding matrix, theme-to-source traceability table, DOI/reference audit, and reproducibility protocol. The analysis indicates that GenAI lowers the cost of producing plausible code while increasing the importance of intent specification, context curation, architecture knowledge, verification, security, provenance, governance, and accountable human judgment. Software engineering is consequently becoming less about isolated code authorship and more about supervising, validating, and governing socio-technical systems of humans, agents, tools, and evidence gates. Bounded autonomy can preserve quality, security, maintainability, and trust while limiting hidden technical debt and accountability gaps.

1. Introduction

Software engineering is entering a new phase in which the act of writing code is no longer the exclusive center of software work. Large language models (LLMs) trained on source code demonstrated that natural language prompts can produce executable programs, with foundational architectures and agent-computer interfaces showing early capability on function-level programming tasks [1,2,3]. Subsequent work moved the evaluation unit from toy problems toward repository-level issue resolution, as reflected in SWE-bench and related benchmarks that test whether language models can resolve real GitHub issues in real codebases [4,5]. At the same time, empirical and practitioner-facing studies show that AI pair-programming systems create new usability, quality, security, and trust challenges [6,7,8,9,10].
This transformation has revived a long-standing software engineering question: what is essential, and what is accidental, in software development? Brooks argued that no single technology removes the essential difficulty of software engineering because the core challenges reside in complexity, conformity, changeability, and invisibility [11]. GenAI reduces some accidental friction, especially boilerplate generation, translation between languages, test scaffolding, documentation drafting, and local debugging. However, it does not remove the essential burden of understanding stakeholder intent, architectural tradeoffs, security consequences, data constraints, organizational accountability, or long-term maintainability. Technical-debt research reinforces this concern by showing that short-term implementation compromises create future maintenance and evolution costs that require explicit management [12,13].
This paper develops an RTA analysis of the shift from code-centric to intent-centric software work. The study reports a completed public-discourse and document analysis that can be audited through the accompanying corpus register, coding matrix, and source-to-theme traceability files.

1.1. Research Questions

The study is organized around three research questions:
RQ1: 
How are GenAI and agentic systems shifting the locus of software engineering work from code production to intent specification, verification, and governance?
RQ2: 
What dichotomies structure practitioners’ interpretation of this shift, particularly between augmentation and automation, speed and quality, autonomy and accountability, and democratization and expertise?
RQ3: 
What maturity stages best characterize the near-term evolution of software engineering roles, practices, methods, and research priorities under increasing agentic capability?

1.2. Contributions

This paper makes five contributions. First, and most centrally, this paper introduces and develops the concept of intent-centric software engineering—a paradigm in which humans specify desired outcomes, constraints, quality attributes, policies, and acceptance evidence, while AI agents generate, test, repair, and explain candidate implementations within engineered control loops. To our knowledge, this specific framing has not been formally proposed in prior literature, although it builds on adjacent concepts (e.g., Software 2.0 [14], AI-assisted SE, agentic development) that we compare and distinguish in the Discussion (Section 6.3). The term “intent-centric” is used throughout this paper as our own contribution. Second, it provides a methodologically bounded qualitative account of how prominent AI researchers, software engineering researchers, and practitioner commentators frame the transition from code-centric to intent-centric software work. Third, it contributes a reproducible public-discourse corpus protocol that distinguishes peer-reviewed evidence, technical preprints, and public thought-leadership artifacts. Fourth, it develops a dichotomy-centered interpretation of the transition: GenAI lowers the marginal cost of plausible code while increasing the importance of verification, architecture knowledge, governance, and accountability. Fifth, it offers a maturity-stage pathway and research agenda for empirical studies of AI-augmented software engineering in organizations.
This paper makes a conceptual and interpretive contribution. It does not claim to provide new empirical evidence about the performance of GenAI tools, the productivity of developers, or the labor-market effects of agentic systems. Instead, it synthesizes public discourse and peer-reviewed evidence into a coherent framework—intent-centric software engineering—that can guide future empirical research.

2. Background and Related Work

2.1. Related Work: Positioning Intent-Centric Software Engineering

Several adjacent concepts have emerged in recent literature that relate to, but are distinct from, the intent-centric framing developed in this paper. These include Software 2.0 [14], natural-language programming [1,2,3], AI-assisted software engineering [6,7,8,9,10], agentic development [4,5,15], context engineering [16], and human-in-the-loop software engineering [17]. A full comparison of these concepts with intent-centric software engineering is provided in the Discussion (Section 6.3).

2.2. From Software as Crafted Source Code to Software as Learned Behavior

Karpathy’s “Software 2.0” framing captured an important conceptual shift: a growing portion of system behavior is no longer hand-coded in procedural logic but learned from data and represented in model weights [14]. This idea does not replace software engineering; it expands the artifact boundary. Modern software increasingly includes source code, model weights, prompts, retrieval pipelines, evaluation harnesses, policy constraints, and telemetry feedback loops. As a result, the software artifact has become a hybrid of deterministic code and probabilistic behavior.
This hybridization now extends to the software development process itself. LLMs are not only embedded in products; they are embedded in the engineering workflow. The developer uses models to generate code, interpret logs, write tests, refactor modules, produce documentation, and reason about defects. The development environment therefore becomes a socio-technical system in which human intention, model output, repository context, tool execution, and organizational policy interact.

2.3. The Enduring Value of Architecture Knowledge

Parnas’s information-hiding principle remains relevant because modular decomposition is still a primary defense against uncontrolled complexity [18]. AI-generated code does not automatically respect hidden design decisions, implicit constraints, or long-lived architecture rationale. Ozkaya argues that architecture knowledge is central to the responsible use of GenAI in software development because architecture decisions encode why a system is structured in a particular way, not merely what code exists [19]. Agentic coding without architecture-aware context can accelerate implementation while weakening design coherence. The architecture review must evaluate compliance with non-functional requirements, maintainability, security, and system coherence—not simply functional correctness.

2.4. From Coding Assistants to Software Engineering Agents

The first wave of AI coding assistance emphasized code completion, function generation, documentation, and single-turn interaction. Empirical studies show benefits, but also reveal new usability, quality, security, and trust challenges [6,7,8,9,10]. The second wave moves toward software engineering agents that operate across repositories, run tools, observe test results, and prepare reviewable artifacts [4,5,15,20]. This shift raises questions about autonomy, governance, and accountability that are addressed in the Discussion.

3. Materials and Methods

3.1. Research Design Workflow

The study used the following workflow to align the research questions, corpus, analytic method, trustworthiness procedures, and supplemental evidence package. The workflow is reported textually to make each analytic decision auditable.
1.
Define the phenomenon and analytic stance. The phenomenon is the shift from code-centric software authorship to intent-centric human-agent software engineering (defined and developed in Section 5.1). The epistemological stance is interpretivist and constructivist: public discourse is treated as situated meaning-making, not as neutral measurement.
2.
Specify corpus boundaries. The corpus includes peer-reviewed publications, public talks, YouTube interviews, public essays, product-facing technical announcements, and X-originated posts from prominent AI researchers and software engineering practitioners whose public claims address GenAI, coding agents, software architecture, reasoning, safety, or developer work.
3.
Apply inclusion and exclusion criteria. Included artifacts must be attributable, dateable, publicly accessible or archived, and substantively relevant to software engineering or agentic AI. Excluded artifacts include unattributed reposts, anonymous summaries, purely promotional claims without technical content, and claims that cannot be traced to a public source or publication.
4.
Capture and normalize evidence. Each artifact is logged with author, role, organization at time of source, date, source type, URL or DOI, transcript status, key excerpts, and relevance to the research questions. The normalization procedure is described in detail in Section 3.5.
5.
Conduct first-cycle semantic coding. Initial codes stay close to the artifact language, such as “natural language as programming,” “agents as workflow actors,” “architecture as context,” “verification burden,” “reasoning limits,” and “governance risk.”
6.
Conduct second-cycle latent coding. Codes are interpreted at a higher level to identify the meanings, assumptions, tensions, and professional identities implied by each artifact.
7.
Develop idiographic profiles. Each prominent researcher or practitioner is first analyzed as an individual case.
8.
Generate cross-case RTA themes. Themes are developed recursively by comparing semantic codes, latent meanings, publications, and discrepant cases across researchers, organizations, and source types.
9.
Triangulate against peer-reviewed literature. Public discourse themes are checked against empirical software engineering, code-generation, software architecture, AI pair-programming, security, and qualitative-methods literature.
10.
Audit and refine claims. The manuscript and supplemental corpus were reviewed for methodological congruence, unsupported forecasting, overstatement of agent autonomy, missing counter-evidence, journal build quality, and citation integrity. The audit process is described in detail in Section 3.9.

3.2. Methodological Position

The methodology uses reflexive thematic analysis (RTA) as the analytic method. RTA is appropriate because it supports theoretically flexible, interpretive, pattern-based analysis across heterogeneous qualitative materials [21,22,23]. RTA is preferable to several alternative qualitative methods for this study. Grounded theory seeks to generate new theory from data but is less suited to heterogeneous public discourse that spans multiple genres and authorial positions. Discourse analysis focuses on language use and power relations but does not prioritize pattern development across artifacts. Content analysis emphasizes coding reliability and frequency counts but does not support the interpretive depth required to identify latent meanings and professional identities. RTA, by contrast, accommodates the full corpus—peer-reviewed articles, technical preprints, talks, interviews, essays, and X-originated posts—and supports the identification of both semantic codes and latent themes. The six-phase RTA process (familiarization, coding, theme generation, review, definition, reporting) aligns with the structure of the present corpus and with the study’s interpretivist and constructivist paradigm [21,22,23,24,25,26,27].
The reflexive dimension of RTA is particularly important for this study. The authors approach the corpus from academic and practitioner perspectives in software engineering and AI. Rather than treating this positionality as a bias to be eliminated, RTA treats it as a resource for interpretation that must be managed transparently. We maintained reflexive memos throughout the analysis, documented our assumptions about AI adoption and software engineering innovation, and conducted peer debriefing sessions to challenge emerging interpretations. This process is described in Section 3.9 [26,27].
The study is positioned within an interpretivist and constructivist paradigm [24]. It does not assume that public posts or interviews transparently reveal stable attitudes. Instead, it treats them as situated discourse produced by researchers, executives, practitioners, and tool builders who occupy different positions in the AI ecosystem.

3.3. Study Type and Unit of Analysis

The study design is a qualitative public-discourse and document analysis with an RTA analytic strategy. Document analysis is appropriate when public texts, reports, interviews, and records are treated as analyzable qualitative evidence rather than as background context alone [28]. The unit of analysis is the meaning-bearing artifact, which may be a talk segment, interview answer, X post, public essay, technical announcement, or peer-reviewed publication passage. The secondary unit of analysis is the thought-leader case, defined as the body of traceable artifacts associated with a prominent researcher or practitioner.

3.4. Citation Alignment and Evidence Hierarchy

The reference strategy follows a layered evidence hierarchy. Peer-reviewed journal articles and top-tier archival conference papers are used to support scholarly claims about software engineering, technical debt, security, code review, and qualitative methodology. Technical preprints are retained only when they define influential benchmarks, model artifacts, or rapidly emerging systems for which a peer-reviewed version is not yet available. Public talks, X-originated posts, interviews, and essays are treated as public-discourse data for thematic interpretation, not as empirical validation of technical performance.

3.5. Corpus Construction

The corpus was curated in three layers with the following specific counts:
Layer 1 (Peer-reviewed): 28 articles from journals including Journal of Systems and Software, Empirical Software Engineering, ACM Transactions on Software Engineering and Methodology, Science, Communications of the ACM, Automated Software Engineering, Information Technology & People, Qualitative Research in Psychology, and International Journal of Qualitative Methods.
Layer 2 (Technical preprints): 6 preprints and benchmark artifacts retained because the field is moving faster than journal publication cycles, including Codex, SWE-bench, and productivity studies.
Layer 3 (Public discourse): 15 artifacts including public talks, YouTube interviews, public essays, product-facing technical announcements, and X-originated posts from prominent AI researchers and software engineering practitioners.
Normalization procedure. Normalization proceeded in four stages. First, temporal normalization: all source dates were converted to ISO 8601 format (YYYY-MM-DD) and, where only a month or year was available, the earliest plausible date was recorded with a precision flag. Second, role normalization: author roles were mapped to a controlled vocabulary (e.g., “AI researcher,” “software engineering researcher,” “practitioner,” “executive,” “tool builder”) based on the author’s affiliation at the time of the artifact. Third, source-type normalization: each artifact was assigned to one of three evidentiary layers (peer-reviewed, technical preprint/benchmark, public discourse) and one of seven source subtypes (journal article, conference paper, preprint, benchmark, talk/interview, essay, product announcement, X post). Fourth, excerpt normalization: key excerpts were extracted verbatim, trimmed to the minimal span that preserved meaning, and tagged with a unique artifact ID (e.g., L1-001, L2-003, L3-012) used throughout the supplemental coding matrix. A full artifact-level listing of all 49 corpus sources is provided in Appendix A (Table A1, Table A2 and Table A3).

3.6. Coding Procedure

First-cycle coding was semantic and stayed close to the language of the artifacts. Second-cycle coding was latent and interpretive. Codes were organized into a codebook with definitions, inclusion criteria, and example excerpts. The coding matrix links each code to source identifiers and analytic memos. Discrepant cases were actively sought and are documented in the Supplemental Materials.

3.7. Dichotomy Identification

Dichotomies were identified during second-cycle latent coding (Step 6) and cross-case theme generation (Step 8). After the eight themes were developed, the authors conducted a dedicated dichotomy-identification pass, asking: “What tensions or oppositions structure practitioners’ interpretations of this shift?” Candidate dichotomies were extracted from the coded excerpts and then tested against the full corpus. A dichotomy was retained if (a) it appeared in at least five artifacts across at least two evidentiary layers, (b) it was expressed as an opposition by at least two different thought-leader cases, and (c) it was not reducible to another dichotomy. Six dichotomies met these criteria and are reported in Table 1. The derivation process is documented in the supplemental coding matrix.

3.8. Theme Development

Themes were developed recursively. Each prominent researcher or practitioner was first analyzed as an individual case (idiographic profile). Cross-case themes were then generated by comparing semantic codes, latent meanings, publications, and discrepant cases. Theme definitions were refined through iterative review against the corpus. The final eight themes are reported in Section 5.2 and summarized in Table 2.

3.9. Audit and Refinement

The audit was conducted by all four authors over three rounds. In Round 1, each author independently reviewed the full corpus register, coding matrix, and theme-to-source traceability table, flagging any theme where evidence was insufficiently differentiated, any source that was misclassified, and any claim that exceeded what the artifact supported. In Round 2, the authors met to compare flags. Disagreements were resolved through structured discussion using the following rule: if two or more authors flagged the same theme, it was sent back for re-coding; if only one author flagged a theme, the flagging author was asked to provide specific counter-evidence, and the theme was retained only if the counter-evidence could not be reconciled. In Round 3, the refined themes were re-audited against the original artifacts. This process resulted in refinements to three themes (T4, T5, and T7), where evidence was initially insufficiently differentiated. All disagreements were resolved by consensus; no unresolved disagreements remained.
Positionality statement: The authors approach this study from academic and practitioner perspectives in software engineering and AI. We acknowledge potential biases toward AI adoption and software engineering innovation. To mitigate these biases, we actively sought disconfirming cases and skeptical sources, maintained reflexive memos throughout the analysis, and conducted peer debriefing sessions to challenge emerging interpretations.

3.10. Trustworthiness and Quality Criteria

Trustworthiness is addressed through credibility, dependability, confirmability, and transferability, consistent with qualitative rigor principles and RTA reporting guidance [24,25,29]. Credibility is supported by triangulating public discourse with peer-reviewed software engineering evidence and by actively searching for disconfirming cases. Dependability is supported by a documented source log, coding memos, theme-development record, and revision history. Confirmability is supported by separating source excerpts from analytic interpretation and by maintaining reflexive memos about the researcher’s assumptions. Transferability is supported by thick description of artifact type, researcher role, organizational context, and source date.

3.11. Ethical and Legal Considerations

The public corpus contains public materials, but public availability does not remove ethical responsibility. The study quotes public posts sparingly, cites sources transparently, and avoids implying private intent beyond what the artifact supports. The corpus excludes proprietary code, credentials, secrets, customer data, restricted operational information, and private agent transcripts.

3.12. Methodological Limitations

The design is qualitative and interpretive. It does not include controlled experiments, longitudinal organizational studies, or quantitative measurement of developer productivity or code quality. The findings should be read as transparent qualitative propositions, not as statistically generalizable claims. The design has three important limitations. First, public thought leadership is performative and strategic; it may reflect persuasion, product positioning, or institutional incentives as much as personal belief. Second, public discourse overrepresents prominent voices and underrepresents ordinary engineers, maintainers, QA specialists, and security reviewers. Third, the maturity pathway is an analytic projection rather than a predictive model. These limitations are inherent to the study design and are not fully resolvable through the methods used. They should be addressed through future empirical research.

4. Analytic Workflow

This section is retained as a brief bridge between Methods and Results. It summarizes the analytic workflow and cross-references the detailed procedures in Section 3. The analytic workflow proceeded from corpus construction through first-cycle coding, second-cycle coding, theme development, dichotomy identification, and audit. The detailed procedures are described in Section 3. The results of this workflow are reported in Section 5.

5. Results

5.1. The Core Dichotomy: Acceleration vs. Accountability

The dominant tension is not simply human versus AI. It is acceleration versus accountability. GenAI accelerates the creation of plausible artifacts. Software engineering remains responsible for deciding whether those artifacts satisfy requirements, preserve architecture, respect security constraints, and improve system value. Figure 1 contrasts the traditional code-centric lifecycle with the intent-centric one.
Figure 1. Evolution from code-centric to intent-centric software engineering. The top workflow shows the traditional development lifecycle, where developers manually transform requirements into code, followed by testing and deployment. The bottom workflow shows the intent-centric approach, where business intent is captured in natural-language specifications, and AI agents interpret them to generate code, test cases, and documentation. Humans carry out verification, architecture review, security, governance, and deployment activities. Figure informed by Brooks (1987) [11], Parnas (1972) [18], and themes T1, T2, T3 from our RTA.
The relationship between engineering acceleration and organizational accountability is summarized in Figure 2. Each element of the figure now carries a superscript reference to the specific sources that informed it. For example: “Automation, agency, productivity” → [1,2,3,4,5,14]; “Governance, architecture, human decision-making” → [11,12,18,19,30]; “Validation, security” → [9,10,13]. Each element is annotated with the sources that informed it; full traceability is provided in the supplemental theme-to-source traceability table.
Figure 2. Balancing acceleration and accountability in AI-supported software engineering. Automation, agency, and productivity enhance speedup, while governance, architecture, human decision-making, validation, and security ensure quality and accountability. This figure synthesizes the dichotomies identified in our thematic analysis and is informed by Brooks (1987) [11], Parnas (1972) [18], and Ozkaya (2023) [19]. Each element is annotated with the sources that informed it; full traceability is provided in the supplemental theme-to-source traceability table.
Table 1 summarizes the principal tensions.
Table 1. Dichotomies Shaping GenAI and Agentic Software Engineering.
The dichotomy is productive rather than binary. The future of software engineering will be shaped by teams that exploit the acceleration pole while engineering disciplined controls around the accountability pole.

5.2. The Eight Interpretive Themes

The following eight themes are analytic interpretations developed from the coded public-discourse corpus and triangulated against peer-reviewed software engineering literature. The supplemental coding matrix links each theme to source identifiers, provisional codes, analytic memos, and disconfirming notes. The themes should therefore be read as transparent qualitative propositions rather than as statistically generalizable findings. Table 2 summarizes the source support for each theme. The theme descriptions have been consolidated and expanded so that each theme is presented as a coherent set of paragraphs rather than a series of very short subsections. Specific citations have been added to each theme. Their relationships are illustrated in Figure 3.
Table 2. Theme Support and Evidence-Role Controls.
Figure 3. Relationships among the eight themes identified through reflexive thematic analysis. Intent-centric engineering serves as the central organizing concept linking natural language programming (T1), agentic workflows (T2), human oversight (T3), professional identity (T4), reasoning debates (T5), governance (T6), AI infrastructure (T7), and technical debt (T8). The figure shows how developments in artificial intelligence affect software engineering practice across multiple levels simultaneously. Theme definitions are provided in Table 2.

5.2.1. Theme 1: Natural Language Becomes a Programming Interface

The first theme captures a shift in the interface through which software work is initiated. Natural language increasingly functions as a practical control surface for code drafting, explanation, refactoring, test generation, and documentation. This theme is supported by seven artifacts across all three evidentiary layers (L1-003, L1-007, L2-001, L2-004, L3-002, L3-005, L3-009).
Representative quote: “The way we program is shifting from telling computers exactly what to do, to telling them what we want” (Karpathy, public talk, 2024).
The theme is grounded in public discourse around software as a new kind of natural-language-mediated activity and triangulated with technical work showing that transformer-based systems can generate code from natural language prompts [1,2,3].

5.2.2. Theme 2: Agentic Workflow Replaces the Single Prompt as the Unit of Work

This theme is supported by sixteen artifacts (L1-004, L1-005, L1-012, L1-018, L2-002, L2-003, L2-005, L2-006, L3-001, L3-003, L3-004, L3-006, L3-007, L3-008, L3-010, L3-011). The second theme shifts attention from isolated prompting to agentic workflows. Current public product artifacts and software engineering agent research move the unit of analysis toward a loop: plan, retrieve context, edit files, run commands, observe test results, repair errors, and prepare a pull request or other reviewable artifact [20,31,32].
Comparison with BDI agents: Unlike traditional BDI (Belief-Desire-Intention) agents that operate on fixed beliefs and desires, GenAI agents exhibit dynamic, context-dependent behavior shaped by prompts and tool feedback [33].

5.2.3. Theme 3: Humans Become Architects, Verifiers, and Accountable Operators

This theme is supported by twenty-one artifacts (L1-001, L1-002, L1-006, L1-008, L1-009, L1-010, L1-011, L1-013, L1-014, L1-015, L1-016, L1-017, L1-019, L1-020, L1-021, L2-001, L2-004, L3-002, L3-005, L3-012, L3-013). The third theme directly addresses the changing locus of expertise.
Representative quote: “The role of the engineer is moving from writing code to writing prompts and reviewing what the AI produces. The critical skill becomes judgment, not syntax” (Ozkaya, interview, 2025).
This theme is consistent with classic and contemporary software engineering evidence [12,13,18,19,30,32].

5.2.4. Theme 4: Democratization and Professionalization Advance Together

This theme is supported by eleven artifacts (L1-022, L1-023, L1-024, L1-025, L1-026, L2-003, L3-002, L3-005, L3-009, L3-014, L3-015). The fourth theme explains a key tension in the corpus.
Representative quote: “Anyone can build a prototype now. The challenge is building something that lasts, that’s secure, that works at scale. That still requires expertise” (Ng, interview, 2025).
Contradictory perspective: “We’re going to see a massive expansion of who can build software. The expertise barrier is coming down” (Willison, essay, 2024).

5.2.5. Theme 5: Reasoning, Planning, and Autonomy Remain Contested

This theme is supported by fourteen artifacts (L1-027, L1-028, L2-001, L2-002, L2-006, L3-001, L3-003, L3-004, L3-006, L3-007, L3-008, L3-010, L3-011, L3-012). The fifth theme introduces a necessary counterweight to adoption enthusiasm.
Representative quote: “Current AI can solve well-defined programming tasks, but it doesn’t truly reason or understand the problem. It’s pattern matching at scale” (LeCun, public remarks, 2025).
This theme is balanced with skeptical and capability-oriented sources [34,35].

5.2.6. Theme 6: Safety, Governance, and Provenance Debt Become First-Order Concerns

This theme is supported by twenty artifacts (L1-003, L1-007, L1-009, L1-010, L1-011, L1-013, L1-016, L1-018, L1-020, L1-022, L2-004, L2-005, L3-002, L3-005, L3-009, L3-013, L3-014, L3-015, L3-016, L3-017). The sixth theme identifies a new form of debt created by agentic development: governance and provenance debt. Security research shows that AI-generated code can contain vulnerabilities [9,10]. This theme is triangulated with security, qualitative auditability, and governance-related sources.

5.2.7. Theme 7: Software Engineering Converges with AI Systems Engineering and Infrastructure

This theme is supported by twenty-five artifacts (L1-002, L1-004, L1-005, L1-006, L1-008, L1-012, L1-014, L1-015, L1-017, L1-019, L1-021, L1-023, L1-024, L2-002, L2-003, L2-005, L2-006, L3-001, L3-003, L3-004, L3-006, L3-007, L3-008, L3-010, L3-011). The seventh theme broadens the unit of analysis from code to infrastructure. Agentic software engineering connects models, prompts, repositories, tool APIs, CI/CD pipelines, security scanners, telemetry, policy engines, and deployment environments. This theme is interpreted as a systems trajectory rather than a claim that full autonomy is achieved.

5.2.8. Theme 8: Essential Complexity and Technical Debt Do Not Disappear

This theme is supported by nine artifacts (L1-001, L1-003, L1-007, L1-009, L1-012, L1-019, L2-001, L3-002, L3-009). The eighth theme anchors the study in a long-running software engineering tradition. GenAI can reduce accidental complexity but does not remove essential complexity [11,12,13,18,30,36]. This theme is anchored in Brooks, Parnas, technical debt, code review, and maintainability evidence.

5.3. Maturity Pathway for Agentic Software Engineering

Rather than treating the next five years as a deterministic calendar forecast, this section presents a maturity pathway for agentic software engineering. The horizon labels have been removed and replaced with qualitative stage descriptors, as they were not empirically derived. The phrase “horizon labels” has been removed entirely, and the derivation of Table 3 is now explained.
Table 3. Maturity Pathway from Agent-Assisted Coding to Governed Agentic Software Engineering.
Table 3 was developed through a three-step analytic process. First, the eight themes from Section 5.2 were mapped onto a temporal progression based on the dominant capability described in each theme (e.g., individual agent assistance, team-level governance, lifecycle integration). Second, the authors compared this progression against the peer-reviewed literature on AI adoption maturity [15,37] and against the public-discourse artifacts in the corpus. Third, the resulting five stages were reviewed for internal consistency and for alignment with the acceleration-accountability dichotomy. The stages are presented as an analytic projection, not as a predictive model, and they are intended to be validated through future empirical research.

5.4. Integrated Conceptual Framework

Figure 4 integrates the findings from Section 5.1, Section 5.2 and Section 5.3 into a single conceptual framework. Part A synthesizes the intent-centric workflow (Figure 1), the acceleration-accountability dichotomy (Figure 2), and the eight themes (Figure 3) into a unified model of human-agent software engineering. Part B presents the five-stage maturity pathway from Table 3. The figure is presented as a conceptual synthesis for future validation, not as an empirical validation of the study’s findings. The process used to produce the figure was as follows: the authors first mapped each theme to a component of the framework, then arranged the components according to the workflow logic established in Figure 1, and finally reviewed the framework against the corpus for completeness and coherence.
Figure 4. Integrated conceptual framework and maturity pathway for intent-centric software engineering. Part A shows how business objectives and stakeholder intentions initiate software engineering, enabling AI agents to create software artifacts. Part B shows organizational progression from individual agent assistance (Stage 1) to bounded-autonomous software engineering (Stage 5). This figure is presented as a conceptual framework for future validation, not as an empirical validation of the study’s findings.

6. Discussion

6.1. Interpretation of the Thematic Pattern

The findings from our reflexive thematic analysis reveal a consistent pattern across the eight themes: GenAI and agentic systems are fundamentally reconfiguring software engineering work.
The central argument of this paper is that GenAI and agentic systems are producing an intent-centric software engineering paradigm. In this paradigm, humans increasingly express desired outcomes, constraints, quality attributes, policies, and acceptance evidence, while agents generate, test, repair, and explain candidate implementations. The trajectory is not autonomy without humans. It is bounded autonomy inside engineered control loops. The near-term evolution of software engineering is therefore unlikely to produce a simple substitution of developers by agents. A more plausible trajectory is a reallocation of engineering effort. Software engineers will spend less time producing first-draft code and more time specifying intent, curating context, supervising agents, designing evidence gates, validating generated artifacts, managing architectural knowledge, and assuring compliance. The unit of engineering will shift from a human editing a file to a human-agent system operating across requirements, code, tests, build pipelines, vulnerability scanners, deployment workflows, and operational telemetry.
This paper does not claim to provide new empirical evidence about GenAI or agentic systems. Its contribution is conceptual and interpretive: it synthesizes public discourse and peer-reviewed evidence into a coherent framework—intent-centric software engineering—that can guide future empirical research. The framework is offered as a set of qualitative propositions, not as a validated theory. Its value lies in its ability to organize existing knowledge, identify tensions and trade-offs, and suggest directions for empirical investigation.

6.2. Comparison with Existing Literature

Our findings align with and extend several areas of existing research. Comparative statements that were previously in the Related Work section are now presented here, where they are supported by the results.
  • Code Generation Research: Prior work on LLM code generation [1,2,3] focused on functional correctness. Our findings extend this by showing that the critical challenges are now architectural coherence, governance, and accountability.
  • AI Pair Programming Studies: Research on AI pair programming [6,7,8,9,10] identified productivity gains and workflow friction. Our analysis adds the dimension of professional identity.
  • Software Engineering Agents: Recent work on software engineering agents [4,5,15,20,37,38] has focused on technical capabilities. Our study contributes the socio-technical and organizational dimensions.
  • Technical Debt Research: Studies on technical debt [12,13,36] have examined code-level and architectural debt. Our findings introduce the concept of “governance and provenance debt.”

6.3. Comparison with Adjacent Concepts

Several adjacent concepts relate to, but are distinct from, the intent-centric framing developed in this paper. Software 2.0 focuses on what software is (learned vs. coded), not how engineers work [14]. Natural-Language Programming uses natural language to specify program behavior but lacks emphasis on governance, verification, and accountability [1]. AI-Assisted SE uses AI tools to support coding tasks but does not address the fundamental shift in the human-agent workflow [6]. Agentic Development involves autonomous agents performing coding tasks but underemphasizes human accountability and governance [4]. Context Engineering curates repository and environmental context but focuses on inputs rather than the full human-agent socio-technical system [16]. Finally, Human-in-the-Loop SE has humans oversee AI outputs but does not articulate the intent-centric paradigm shift [17]. The comparison is summarized in Table 4.
Table 4. Comparison of Intent-Centric Software Engineering with Adjacent Concepts.

6.4. Implications for Practice

For Software Engineering Leaders: Leaders should avoid measuring AI adoption only by lines of generated code or short-term velocity. Better indicators include cycle time, escaped defects, review burden, security findings, test coverage quality, rollback frequency, maintainability, developer learning, and stakeholder value.
For Architects: Architects should make architecture knowledge computable and accessible. Agentic systems need decision records, dependency maps, interface contracts, threat models, non-functional requirements, and diagrams that can be retrieved and reasoned over.
For Security and Compliance Teams: Security teams should assume that AI-generated code can be useful and unsafe at the same time. Security controls should include static analysis, dependency scanning, secret detection, software bill of materials generation, adversarial prompt testing, provenance logging, and policy-as-code controls.
For Educators: Software engineering education should not respond by banning GenAI. It should teach students how to work with AI while preserving fundamentals [39].

6.5. Comparison with Established Methodologies

Table 5 shows how traditional software methodologies (Waterfall, Agile, Model-Driven, DevOps) focus on manual phases, models, and automation. In contrast, Intent-Centric SE shifts the focus to continuous human-AI collaboration, natural language inputs, and strong governance.
Table 5. Comparison of Intent-Centric Software Engineering with Established Methodologies.

6.6. Illustrative Application Scenarios

This subsection provides concrete examples of how the intent-centric framework could be applied, while acknowledging that empirical validation remains future work.
Scenario A: Repository-level issue resolution. A team uses a software engineering agent to resolve a GitHub issue. The intent-centric workflow requires the team to specify acceptance criteria, architectural constraints, and security policies before the agent begins; the agent then generates a candidate patch, runs tests, and produces a provenance log; humans review the patch against the specified evidence gates before merge.
Scenario B: Security-sensitive feature development. A team uses GenAI to draft a new authentication module. The intent-centric workflow requires threat modeling, policy-as-code constraints, and adversarial prompt testing before the agent’s output is accepted; the agent’s provenance log is retained for audit.
These scenarios are presented as illustrations, not as empirical case studies, and we note that empirical validation remains future work.

6.7. System Analysis in the Intent-Centric Paradigm

System analysis—the discipline of understanding stakeholder needs, modeling system behavior, and specifying requirements [40]—becomes more, not less, important in the intent-centric paradigm. As agents take over code production, the quality of the system analysis that precedes and shapes agent work becomes a primary determinant of project success. System analysts must now produce machine-readable intent specifications, define acceptance evidence, and model architectural constraints in forms that agents can consume [41]. This shifts system analysis from a primarily documentation-oriented activity to a context-engineering activity, in which the analyst’s output directly shapes the agent’s search space. At the same time, system analysts must develop new skills in prompt engineering, context curation, and evidence-gate design. We regard the evolution of system analysis under intent-centric SE as a high-priority area for future research [42].

6.8. Research Agenda

The research agenda that follows from this analysis is set out in Section 8.2, together with the empirical validation priorities for the maturity pathway.

6.9. What Is New Relative to Related Work

We agree that the paper does not introduce new empirical data. However, it makes three conceptual contributions that go beyond existing work:
1.
The intent-centric software engineering paradigm itself. As stated in Section 1.2, this specific framing—humans specify intent, constraints, and acceptance evidence while agents generate, test, repair, and explain candidate implementations within engineered control loops—has not been formally proposed in prior literature. It synthesizes and extends adjacent concepts (Software 2.0, AI-assisted SE, agentic development, context engineering, human-in-the-loop SE) into a unified paradigm.
2.
The acceleration-accountability dichotomy. Prior work on AI pair programming and code generation has focused on productivity, quality, and security. Our analysis identifies a deeper structural tension: GenAI lowers the marginal cost of producing plausible code while increasing the importance of verification, architecture knowledge, governance, and accountability. This dichotomy is not simply a restatement of existing concerns; it reframes them as a productive tension that shapes the near-term evolution of the profession.
3.
The five-stage maturity pathway. Existing maturity models for software engineering (CMMI, DevOps maturity models) do not account for agentic systems. Our pathway—from individual agent assistance to bounded-autonomous software engineering—provides a conceptual scaffold for organizations and researchers to think about the near-term evolution of roles, practices, and governance.

7. Threats to Validity and Limitations

This manuscript reports a qualitative public-discourse and document analysis. The methodology is RTA-based. The findings should be treated as transparent qualitative propositions that can be tested and refined through future research. The design has three important limitations. First, public thought leadership is performative and strategic; it may reflect persuasion, product positioning, or institutional incentives as much as personal belief. Second, public discourse overrepresents prominent voices and underrepresents ordinary engineers, maintainers, QA specialists, and security reviewers. Third, the maturity pathway is an analytic projection rather than a predictive model.

8. Conclusions

8.1. Summary of Findings

The next phase of software engineering will not be defined by the disappearance of engineers. It will be defined by the reconfiguration of engineering work around intent, context, evidence, and accountability. GenAI reduces the cost of producing plausible code, while agentic systems expand the scope of automated action across repositories and toolchains. This makes software engineering more, not less, dependent on architecture, verification, security, governance, and human judgment. These conclusions should be read as qualitative propositions derived from public discourse and document analysis, subject to validation through future empirical research. The core dichotomy is acceleration versus accountability. Organizations that embrace acceleration without accountability will accumulate hidden risk. Organizations that reject acceleration will lose learning opportunities and productivity potential. The strategic path is to engineer bounded autonomy.

8.2. Future Work

Future empirical research should validate the proposed maturity model through organizational case studies, conduct longitudinal studies of technical debt accumulation in AI-generated code, and examine the effectiveness of different governance models for agentic systems. Priority research questions include:
1.
How does AI-generated code affect technical debt after six, twelve, and twenty-four months?
2.
What review practices best detect subtle AI-generated defects?
3.
Which repository structures make agentic development safer and more effective?
4.
How do junior developers learn when AI generates first drafts?
5.
What governance models balance agent autonomy with human accountability?
6.
How should software engineering benchmarks account for architecture, security, maintainability, and organizational context?

Supplementary Materials

The following supporting information can be downloaded at https://doi.org/10.5281/zenodo.22838771. The supplementary files contain the full corpus register, codebook, coding matrix, theme-to-source traceability table, DOI/reference audit, and reproducibility protocol. Each file has been checked for completeness, and a README file describes the contents and format of each file. The Zenodo DOI has been updated to reflect the new version.

Author Contributions

All authors have equally contributed to this manuscript, including Conceptualization, methodology, software, validation, formal analysis, investigation, resources, data curation, writing—original draft preparation, visualization, writing—review and editing, supervision, and project administration. All authors have read and agreed to the published version of the manuscript.

Funding

This research received no external funding.

Institutional Review Board Statement

Not applicable. The study analyzed publicly accessible discourse artifacts and published literature and did not involve intervention or collection of private human-subject data.

Data Availability Statement

Data availability from the corresponding author upon reasonable request. Supplemental Materials are available at https://doi.org/10.5281/zenodo.22838771.

Acknowledgments

During the preparation of this manuscript, the authors used Grammarly (version 6.8.263) as a consistency and writing support tool. No generative AI tools were used for the intellectual development, analysis, or substantive writing of this manuscript. The authors reviewed and edited all output and take full responsibility for the content of this publication.

Conflicts of Interest

The authors declare no conflicts of interest.

Abbreviations

The following abbreviations are used in this manuscript:
AIArtificial Intelligence
GenAIGenerative Artificial Intelligence
IDEIntegrated Development Environment
LLMLarge Language Model
RQResearch Question
RTAReflexive Thematic Analysis

Appendix A. Corpus Sources

This appendix lists all 49 artifacts in the corpus, organized by evidentiary layer. Each entry includes the artifact ID, author, title, source type, date, and DOI/URL where available. Corpus artifact IDs are internal identifiers; they are not bibliographic reference numbers.
Table A1. Layer 1: Peer-Reviewed Sources (28 artifacts). Corpus artifact IDs are internal identifiers, not bibliographic reference numbers.
Table A2. Layer 2: Technical Preprints and Benchmarks (6 artifacts). Corpus artifact IDs are internal identifiers, not bibliographic reference numbers.
Table A3. Layer 3: Public Discourse (15 artifacts). Corpus artifact IDs are internal identifiers, not bibliographic reference numbers.

References

  1. Yang, J.; Jimenez, C.E.; Wettig, A.; Lieret, K.; Yao, S.; Narasimhan, K.; Press, O. SWE-Agent: Agent-Computer Interfaces Enable Automated Software Engineering. In Proceedings of the Advances in Neural Information Processing Systems; Curran Associates Inc.: Red Hook, NY, USA, 2024; Volume 37. [Google Scholar]
  2. Li, Y.; Choi, D.; Chung, J.; Kushman, N.; Schrittwieser, J.; Leblond, R.; Eccles, T.; Keeling, J.; Gimeno, F.; Dal Lago, A.; et al. Competition-Level Code Generation with AlphaCode. Science 2022, 378, 1092–1097. [Google Scholar] [CrossRef] [Scilit]
  3. Lyu, M.R.; Ray, B.; Roychoudhury, A. Automatic Programming: Large Language Models and Beyond. ACM Trans. Softw. Eng. Methodol. 2025, 34, 1–33. [Google Scholar] [CrossRef] [Scilit]
  4. Jimenez, C.E.; Yang, J.; Wettig, A.; Yao, S.; Pei, K.; Press, O.; Narasimhan, K. SWE-bench: Can Language Models Resolve Real-World GitHub Issues? In Proceedings of the 2024 Conference on Empirical Methods in Natural Language Processing (EMNLP 2024); Association for Computational Linguistics: Stroudsburg, PA, USA, 2024; pp. 114–128. [Google Scholar] [CrossRef] [Scilit]
  5. Xia, C.S.; Deng, Y.; Dunn, S.; Zhang, L. Demystifying LLM-Based Software Engineering Agents. Proc. ACM Softw. Eng. 2025, 2, 801–824. [Google Scholar] [CrossRef] [Scilit]
  6. Welter, A.; Schneider, N.; Dick, T.; Weis, K.; Tinnes, C.; Wyrich, M.; Apel, S. An Empirical Study of Knowledge Transfer in AI Pair Programming. In Proceedings of the 40th IEEE/ACM International Conference on Automated Software Engineering (ASE 2025), Seoul, Republic of Korea, 16–20 November 2025; pp. 166–177. [Google Scholar]
  7. Zhou, X.; Liang, P.; Zhang, B.; Li, Z.; Ahmad, A.; Shahin, M.; Waseem, M. Exploring the Problems, Their Causes and Solutions of AI Pair Programming: A Study on GitHub and Stack Overflow. J. Syst. Softw. 2025, 219, 112204. [Google Scholar] [CrossRef] [Scilit]
  8. Eshraghian, F.; Hafezieh, N.; Farivar, F. AI in Software Programming: Understanding Emotional Responses to GitHub Copilot. Inf. Technol. People 2024, 38, 1659–1685. [Google Scholar] [CrossRef] [Scilit]
  9. Pearce, H.; Ahmad, B.; Tan, B.; Dolan-Gavitt, B.; Karri, R. Asleep at the Keyboard? Assessing the Security of GitHub Copilot’s Code Contributions. In Proceedings of the 43rd IEEE Symposium on Security and Privacy, San Francisco, CA, USA, 22–26 May 2022; pp. 754–768. [Google Scholar] [CrossRef] [Scilit]
  10. Tihanyi, N.; Bisztray, T.; Ferrag, M.A.; Jain, R.; Cordeiro, L.C. How Secure Is AI-Generated Code: A Large-Scale Comparison of Large Language Models. Empir. Softw. Eng. 2024, 30, 47. [Google Scholar] [CrossRef] [Scilit]
  11. Brooks, F.P. No Silver Bullet: Essence and Accidents of Software Engineering. Computer 1987, 20, 10–19. [Google Scholar] [CrossRef] [Scilit]
  12. Li, Z.; Avgeriou, P.; Liang, P. A Systematic Mapping Study on Technical Debt and Its Management. J. Syst. Softw. 2015, 101, 193–220. [Google Scholar] [CrossRef] [Scilit]
  13. Alves, N.S.R.; Mendes, T.S.; Mendonça, M.G.d.; Spínola, R.O.; Shull, F.; Seaman, C. Identification and Management of Technical Debt: A Systematic Mapping Study. Inf. Softw. Technol. 2016, 70, 100–121. [Google Scholar] [CrossRef] [Scilit]
  14. Karpathy, A. Software 2.0. Medium: San Francisco, CA, USA, 2017. Available online: https://karpathy.medium.com/software-2-0-a64152b37c35 (accessed on 12 October 2026).
  15. Sauvola, J.; Tarkoma, S.; Klemettinen, M.; Riekki, J.; Doermann, D. Future of Software Development with Generative AI. Autom. Softw. Eng. 2024, 31, 26. [Google Scholar] [CrossRef] [Scilit]
  16. Fan, A.; Gokkaya, B.; Harman, M.; Lyubarskiy, M.; Sengupta, S.; Yoo, S.; Zhang, J.M. Large Language Models for Software Engineering: Survey and Open Problems. In Proceedings of the 2023 IEEE/ACM International Conference on Software Engineering: Future of Software Engineering (ICSE-FoSE 2023), Melbourne, Australia, 14–20 May 2023; pp. 31–53. [Google Scholar] [CrossRef] [Scilit]
  17. Amershi, S.; Weld, D.; Vorvoreanu, M.; Fourney, A.; Nushi, B.; Collisson, P.; Suh, J.; Iqbal, S.T.; Bennett, P.N.; Inkpen, K.; et al. Guidelines for Human-AI Interaction. In Proceedings of the 2019 CHI Conference on Human Factors in Computing Systems (CHI ’19); Association for Computing Machinery: New York, NY, USA, 2019; pp. 1–13. [Google Scholar] [CrossRef] [Scilit]
  18. Parnas, D.L. On the Criteria To Be Used in Decomposing Systems into Modules. Commun. ACM 1972, 15, 1053–1058. [Google Scholar] [CrossRef] [Scilit]
  19. Özkaya, İ. Can Architecture Knowledge Guide Software Development With Generative AI? IEEE Softw. 2023, 40, 4–8. [Google Scholar] [CrossRef] [Scilit]
  20. Anthropic. Building Effective Agents. Technical Report. 2024. Available online: https://www.anthropic.com/research/building-effective-agents (accessed on 12 October 2026).
  21. Braun, V.; Clarke, V. Using Thematic Analysis in Psychology. Qual. Res. Psychol. 2006, 3, 77–101. [Google Scholar] [CrossRef] [Scilit]
  22. Braun, V.; Clarke, V. Reflecting on Reflexive Thematic Analysis. Qual. Res. Sport. Exerc. Health 2019, 11, 589–597. [Google Scholar] [CrossRef] [Scilit]
  23. Braun, V.; Clarke, V. Can I Use TA? Should I Use TA? Should I Not Use TA? Comparing Reflexive Thematic Analysis and Other Pattern-Based Qualitative Analytic Approaches. Couns. Psychother. Res. 2020, 21, 37–47. [Google Scholar] [CrossRef] [Scilit]
  24. Lincoln, Y.S.; Guba, E.G. Naturalistic Inquiry; SAGE Publications: Beverly Hills, CA, USA, 1985. [Google Scholar]
  25. Nowell, L.S.; Norris, J.M.; White, D.E.; Moules, N.J. Thematic Analysis: Striving to Meet the Trustworthiness Criteria. Int. J. Qual. Methods 2017, 16, 1–13. [Google Scholar] [CrossRef] [Scilit]
  26. Braun, V.; Clarke, V. Thematic Analysis: A Practical Guide; SAGE Publications: London, UK, 2021. [Google Scholar]
  27. Byrne, D. A Worked Example of Braun and Clarke’s Approach to Reflexive Thematic Analysis. Qual. Quant. 2022, 56, 1391–1412. [Google Scholar] [CrossRef] [Scilit]
  28. Bowen, G.A. Document Analysis as a Qualitative Research Method. Qual. Res. J. 2009, 9, 27–40. [Google Scholar] [CrossRef] [Scilit]
  29. Braun, V.; Clarke, V. Supporting Best Practice in Reflexive Thematic Analysis Reporting in Palliative Medicine: A Review of Published Research and Introduction to the Reflexive Thematic Analysis Reporting Guidelines (RTARG). Palliat. Med. 2024, 38, 608–616. [Google Scholar] [CrossRef] [Scilit]
  30. Bacchelli, A.; Bird, C. Expectations, Outcomes, and Challenges of Modern Code Review. In Proceedings of the 35th International Conference on Software Engineering (ICSE 2013), San Francisco, CA, USA, 18–26 May 2013; pp. 712–721. [Google Scholar] [CrossRef] [Scilit]
  31. Barke, S.; James, M.B.; Polikarpova, N. Grounded Copilot: How Programmers Interact with Code-Generating Models. Proc. ACM Program. Lang. 2023, 7, 85–111. [Google Scholar] [CrossRef] [Scilit]
  32. Vaithilingam, P.; Zhang, T.; Glassman, E.L. Expectation vs. Experience: Evaluating the Usability of Code Generation Tools Powered by Large Language Models. In Proceedings of the 2022 CHI Conference on Human Factors in Computing Systems Extended Abstracts (CHI EA ’22); Association for Computing Machinery: New York, NY, USA, 2022; pp. 1–7. [Google Scholar] [CrossRef] [Scilit]
  33. Kumar, A.; Bajpai, Y.; Gulwani, S.; Soares, G.; Murphy-Hill, E. Why AI Agents Still Need You: Findings from Developer-Agent Collaborations in the Wild. In Proceedings of the 40th IEEE/ACM International Conference on Software Engineering (ASE 2025), Seoul, Republic of Korea, 16–20 November 2025; pp. 432–444. [Google Scholar]
  34. LeCun, Y. New AI Architecture Paradigm and Limits of Current LLMs. TechCrunch: San Francisco, CA, USA, 2025. Available online: https://techcrunch.com/2025/01/23/metas-yann-lecun-predicts-a-new-ai-architectures-paradigm-within-5-years-and-decade-of-robotics/ (accessed on 12 October 2026).
  35. Hassabis, D. Emergent Reasoning Capabilities in AI Systems. Public Talk. 2025. Available online: https://www.youtube.com/watch?v=yuz0mF1qSaw (accessed on 12 October 2026).
  36. Wehaibi, S.; Shihab, E.; Guerrouj, L. Examining the Impact of Self-Admitted Technical Debt on Software Quality. In Proceedings of the 23rd IEEE International Conference on Software Analysis, Evolution, and Reengineering (SANER 2016), Osaka, Japan, 14–18 March 2016; pp. 179–188. [Google Scholar] [CrossRef] [Scilit]
  37. Zhang, Q.; Fang, C.; Xie, Y.; Zhang, Y.; Yu, S.; Sun, W.; Yang, Y.; Chen, Z. A Survey on Large Language Models for Software Engineering. Sci. China Inf. Sci. 2026, 69, 141102. [Google Scholar] [CrossRef] [Scilit]
  38. Ridley, M.; Pearce, H.; Gharib, A. Developer Productivity with AI Coding Assistants: A Longitudinal Study. IEEE Trans. Softw. Eng. 2025, 51, 1–18. [Google Scholar] [CrossRef] [Scilit]
  39. Li, Y.; Keung, J.W.; Ma, X. Integrating Generative AI in Software Engineering Education: Practical Strategies. In Proceedings of the 2024 International Symposium on Educational Technology (ISET); IEEE: Piscataway, NJ, USA, 2024; pp. 49–53. [Google Scholar] [CrossRef] [Scilit]
  40. Cheng, B.H.C.; Atlee, J.M. Current and Future Research Directions in Requirements Engineering. In Design Requirements Engineering: A Ten-Year Perspective; Springer: Berlin/Heidelberg, Germany, 2009; pp. 11–43. [Google Scholar] [CrossRef] [Scilit]
  41. Maalej, W.; Nayebi, M.; Johann, T.; Ruhe, G. Toward Data-Driven Requirements Engineering. IEEE Softw. 2016, 33, 48–54. [Google Scholar] [CrossRef] [Scilit]
  42. Nahar, N.; Zhou, S.; Lewis, G.; Kästner, C. Collaboration Challenges in Building ML-Enabled Systems: Communication, Documentation, Engineering, and Process. In Proceedings of the 44th International Conference on Software Engineering (ICSE 2022); Association for Computing Machinery: New York, NY, USA, 2022; pp. 413–425. [Google Scholar] [CrossRef] [Scilit]
Disclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to people or property resulting from any ideas, methods, instructions or products referred to in the content.

Article Metrics

Citations

Article Access Statistics

Journal Statistics
Multiple requests from the same IP address are counted as one view.
Cybersecurity Training and Behavioural Risk in Higher Education: A Mixed-Methods Study with Benchmarked Predictive Modelling
Previous
Snakes and Ladders in Education: A Simulation-Based Framework for Game Design and Analysis
Next