Paper deep dive
Shift-Up: A Framework for Software Engineering Guardrails in AI-native Software Development -- Initial Findings
Petrus Lipsanen, Liisa Rannikko, François Christophe, Konsta Kalliokoski, Vlad Stirbu, Tommi Mikkonen
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 97%
Last extracted: 4/26/2026, 5:50:13 PM
Summary
The paper introduces 'Shift-Up', a framework designed to provide structural guardrails for AI-native software development. As Generative AI shifts development from manual coding to agent-driven 'vibe coding', issues like architectural drift and reduced maintainability arise. Shift-Up reinterprets traditional software engineering practicesâspecifically Behavior-Driven Development (BDD), the C4 model, and Architecture Decision Records (ADRs)âas machine-readable, persistent constraints. An exploratory evaluation comparing unstructured vibe coding, structured prompt engineering, and the Shift-Up framework suggests that while Shift-Up requires higher upfront investment, it enables higher-level strategic orchestration, increased human control, and more stable agent behavior through automated validation and structured requirements.
Entities (10)
Relation Signals (5)
Shift-Up â incorporates â BDD
confidence 100% ¡ The Shift-Up framework... integrates structured requirements engineering (BDD-based executable requirements), architectural modeling (C4), and architecture decision records (ADRs)
Shift-Up â incorporates â C4 Model
confidence 100% ¡ The Shift-Up framework... integrates... architectural modeling (C4)
Shift-Up â incorporates â ADR
confidence 100% ¡ The Shift-Up framework... integrates... architecture decision records (ADRs)
Shift-Up â addresses â Architectural Drift
confidence 95% ¡ The central problem addressed in this evaluation is the architectural drift, limited traceability, and reduced controllability observed in unstructured agentic workflows
Generative AI â enables â Vibe Coding
confidence 90% ¡ In such environment, the activity of developers focus on prompting... This emergent software development process is widely known as vibe coding
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:Generative AI (GenAI) is reshaping software engineering by shifting development from manual coding toward agent-driven implementation. While vibe coding promises rapid prototyping, it often suffers from architectural drift, limited traceability, and reduced maintainability. Applying the design science research (DSR) methodology, this paper proposes Shift-Up, a framework that reinterprets established software engineering practices, like executable requirements (BDD), architectural modeling (C4), and architecture decision records (ADRs), as structural guardrails for GenAI-native development. Preliminary findings from our exploratory evaluation compare unstructured vibe coding, structured prompt engineering, and the Shift-Up approach in the development of a web application. These findings indicate that embedding machine-readable requirements and architectural artifacts stabilizes agent behavior, reduces implementation drift, and shifts human effort toward higher-level design and validation activities. The results suggest that traditional software engineering artifacts can serve as effective control mechanisms in AI-assisted development.
Tags
Links
- Source: https://arxiv.org/abs/2604.20436v1
- Canonical: https://arxiv.org/abs/2604.20436v1
Trouble viewing inline? Open PDF directly â
Full Text
31,044 characters extracted from source content.
Expand or collapse full text
Shift-Up: A Framework for Software Engineering Guardrails in AI-native Software Development - Initial Findings Petrus Lipsanen â University of Jyväskylä Jyväskylä, Finland petrus.i.lipsanen@jyu.fi Liisa Rannikko â University of Jyväskylä Jyväskylä, Finland liisa.m.e.rannikko@jyu.fi François Christophe University of Jyväskylä Jyväskylä, Finland francois.m.christophe@jyu.fi Konsta Kalliokoski University of Jyväskylä Jyväskylä, Finland konsta.m.kalliokoski@jyu.fi Vlad Stirbu University of Jyväskylä Jyväskylä, Finland vlad.a.stirbu@jyu.fi Tommi Mikkonen University of Jyväskylä Jyväskylä, Finland tommi.j.mikkonen@jyu.fi Abstract Generative AI (GenAI) is reshaping software engineering by shift- ing development from manual coding toward agent-driven im- plementation. While âvibe codingâ promises rapid prototyping, it often suffers from architectural drift, limited traceability, and re- duced maintainability. Applying the design science research (DSR) methodology, this paper proposes Shift-Up, a framework that rein- terprets established software engineering practices, like executable requirements (BDD), architectural modeling (C4), and architecture decision records (ADRs), as structural guardrails for GenAI-native development. Preliminary findings from our exploratory evaluation compare unstructured vibe coding, structured prompt engineering, and the Shift-Up approach in the development of a web application. These findings indicate that embedding machine-readable require- ments and architectural artifacts stabilizes agent behavior, reduces implementation drift, and shifts human effort toward higher-level design and validation activities. The results suggest that traditional software engineering artifacts can serve as effective control mecha- nisms in AI-assisted development. CCS Concepts ⢠Software and its engineeringâSoftware development tech- niques; Designing software; Software design tradeoffs;⢠Com- puting methodologiesâArtificial intelligence; Machine learn- ing. 1 Introduction The emergence of Generative AI (GenAI) has had a profound im- pact on software engineering [1]. GenAI is becoming increasingly capable of aiding different software engineering tasks, whether it be requirements engineering, code generation, or documentation [9]. This has led to their widespread adoption in software devel- opment processes [19], which in turn has created a shift in which actual software development is performed by GenAI development environments such as Lovable 1 , Replit 2 or Bolt.new 3 . In such environment, the activity of developers focus on prompt- ing user needs for the software application to be developed, evalu- ating the functionality of the AI-generated prototype, and iterating â Both authors contributed equally to this research. 1 https://lovable.dev/, accessed on 25.2.2026 2 https://replit.com/, accessed on 25.2.2026 3 https://bolt.new/, accessed on 25.2.2026 this prompting process until the generated prototype reaches some kind of qualitative acceptance from developers. This emergent soft- ware development process is widely known as vibe coding [5]. The main promises of vibe coding environment rely on acceleration of delivery and software development expertise not being necessary. However, a recent study shows that these promises are often given at the cost of quality of prototypes, maintainability and rework iterations before achieving the status of a viable product [13]. This gap needs attention because of the conflict between development acceleration and end-product quality. To address this gap, our paper proposes Shift-Up, a framework for GenAI-native software development that leverages established soft- ware engineering practices as structural guardrails to guide and sta- bilize agent-driven implementation, embedding machine-readable and traceable artifacts directly into the development workflow. Through this investigation, we provide initial design knowledge on how traditional software engineering practices can be reinterpreted to structure and control AI-assisted development processes. 2 Background and motivation Software engineering has repeatedly undergone paradigm shifts that initially deprioritize established prescriptive design knowledge in favor of speed and flexibility. The transition from waterfall to agile development is a notable example. Early agile adoption empha- sized working software over documentation, abandoning formal prescriptions. However, the resulting structural deficits forced the reintroduction of this design knowledge in lightweight forms such as test-driven development (TDD) and continuous integration (CI). Several established frameworks function as prescriptive design knowledge. The V-model [3] operationalizes design control in quality-sensitive domains [10]. Shift-left and shift-right principles [7,17] prescribe continuous validation throughout the life cycle. Architectural modeling approaches such as the C4 model [2] and architecture decision records (ADRs) [11,22] provide formal pre- scriptions for preserving system representations and design ratio- nale. Furthermore, executable requirements [4], including behavior- driven development (BDD) [18], constitute prescriptive knowledge that dictates how stakeholder intent must link to automated valida- tion. A comparable dynamic appears to be emerging in the context of GenAI-assisted development. Agent-driven workflows and vibe coding emphasize rapid prototyping through iterative prompting, arXiv:2604.20436v1 [cs.SE] 22 Apr 2026 Petrus Lipsanen, Liisa Rannikko, François Christophe, Konsta Kalliokoski, Vlad Stirbu, and Tommi Mikkonen often suggesting that traditional engineering artifacts are unnec- essary. However, recent studies report recurring issues such as architectural drift, limited traceability, and reduced controllability in purely prompt-driven approaches [8,14,15]. This mirrors earlier transitions in software engineering, where the temporary abandon- ment of structure was followed by the reintroduction of practices in adapted forms. This historical pattern motivates our investigation: rather than discarding established software engineering practices in AI-native development, how can they be reinterpreted as lightweight struc- tural guardrails compatible with agent-driven workflows? 3 Methodology and objectives This work adopts the Design Science Research (DSR) paradigm to investigate how established software engineering practices can be reinterpreted as structural guardrails in GenAI-native development. DSR provides a rigorous, utility-driven process for designing, devel- oping and evaluating information technology (IT) artifacts to solve complex practical problems [6]. The use of DSR ensures a struc- tured pathway aligning with DSR methodologies that emphasize continuous context-aware artifact evolution [16, 21]. Following the DSR process model, the central problem addressed in this evaluation is the architectural drift, limited traceability, and reduced controllability observed in unstructured agentic workflows during GenAI-native development. The solution objectives focus on establishing structural guardrails that constrain and stabilize gener- ative behavior. The Shift-Up framework constitutes the proposed ar- tifact, which integrates structured requirements engineering (BDD- based executable requirements), architectural modeling (C4), and architecture decision records (ADRs) into GenAI-assisted devel- opment. These artifacts are designed not only as human-readable documentation, but as machine-readable, persistent contextual con- straints. The demonstration of this framework consists of applying the structured artifacts (BDD executables, C4, ADRs) as continuous inputs within the development pipeline. Following this, the present evaluation represents the initial exploratory evaluation of this framework. The objective is to assess the feasibility of guardrail mechanisms and refine the conceptual understanding of structured artifacts in agentic workflows. This objective is distilled in the following research questions: RQ1:How does the use of structured requirements and architec- tural artifacts (ADR, C4, BDD) influence the autonomy of GenAI agents during implementation? RQ2:To what extent do executable requirements reduce agent drift compared to prompt-only development? Together, these questions aim to uncover the mechanisms through which traditional software engineering artifacts [10] can serve as structural stabilizers in GenAI-native development processes. 4 The Shift-Up framework Assisted by GenAI tools, development teams can generate artifacts across multiple levels of abstraction from small code snippets to fully deployable modules integrated and monitored into larger sys- tems. In this setting, shift-left acquires a renewed meaning: the emphasis moves from manual coding to higher-level artifacts such Product development phases Requirements Analysis and architecture Design Coding Unit, model and subsystem tests Integration tests Acceptance tests Verification Verification Validation ConceptAI Native Software Development Release or Production Automation Cost Agents Humans Figure 1: AI-native software development with Shift-Up as prompts, refined specifications, and automated generation, plac- ing developer intent at the center of the life cycle. In addition, shift-right extends beyond traditional testing toward deployment and operations, where GenAI supports continuous monitoring, val- idation, and feedback-driven evolution to ensure robustness under production conditions. By combining these perspectives, we propose the concept of Shift-Up, which fits the layered structure of the V-Model. In this GenAI-native Software Development Life-Cycle (SDLC), intermedi- ate stages such as detailed design, implementation, and low-level verification are delegated to GenAI tools, allowing human devel- opers to focus on the higher layers of the V-Model. At the top-left, they concentrate on requirement specification, architectural de- sign, and system-level considerations, and at the top-right, they engage in acceptance testing, deployment oversight, and opera- tional feedback. The objective of Shift-Up is thus to free developers from low-level implementation details and empower them to focus on strategic, creative, and domain-specific aspects of software de- velopment, while ensuring that quality and reliability are preserved throughout the life cycle, as depicted in Figure 1. Upon perform- ing Shift-Up development, humans and GenAI co-operate to solve problems in ways that are best fit to the task at hand, following a shared responsibility working model [12]. 5Exploratory comparative evaluation: Shift-Up framework in practice To evaluate the Shift-Up framework, we conducted a comparative evaluation centered on the development of a web application for an online snack-bar. The scope of this snack-bar is a full-stack application that includes graphical user interface (GUI), PostgreSQL database, admin system, and other backend logic. The evaluation consists of three distinct developmental paradigms: (1)Unstructured vibe coding: An informal development ap- proach in which implementation progresses directly from high-level ideas, with limited upfront requirements model- ing, architectural planning, or formal validation artifacts. This is referred in the industry as "vibe coding". (2) Structured vibe coding through prompt engineering: This approach prioritizes an iterative process characterized Shift-Up: Framework for Software Engineering Guardrails in AI-native Software Development - Initial findings by reliance on agentic AI with minimal formal scaffolding achieved by prompt engineering. (3) Initial experimentation of Shift-Up: Partial application of the proposed framework specifically focusing on the initial two layers: requirements engineering and automated validation through executable acceptance tests, with agent driven architecture design. The objective is to analyze how structured requirements, com- bined with executable acceptance tests and generated C4 and ADR artifacts, influence the reliability and validity of AI-generated soft- ware and the development process. The methodology is then com- pared to a purely prompt-driven approach. The authors worked as human developers, one author working through a single approach. In none of the approaches did a human write any code; the respon- sibility was delegated to the GenAI agent through prompting. Data collection. Each prompt was recorded alongside a qualita- tive assessment of its efficacy. To capture the developer experience, developers were to document notes and observations in a journal. Quantitative metrics such as implementation time were recorded for all approaches. As this is an exploratory comparative evaluation, some prompt practices were also iteratively modified during the development process. A subsequent analysis will focus on the tech- nical evaluation of the generated code and test suites. The current results focus on the implementation process. Data analysis. The analysis of the prompts and coding of the categories was aligned with a general inductive approach [20]. The authors working on structured vibe coding and Shift-Up ap- proaches re-familiarized themselves with, analyzed, and categorized their own prompts. Subsequently, the authors cross-validated each otherâs categories to ensure consistency. The inductive approach was chosen due to the exploratory nature of this evaluation. 5.1 Unstructured vibe coding Unstructured vibe coding 4 was done via the Lovable app, which promises that there is no need for coding proficiency. The approach started through a short semi-structured interview with the stake- holder. The aim for the interview was for the developer to gain a vision for the future application and key characteristics of the functionality. Afterwards the developer made a description of the application and prompted the Lovable system through its GUI. The system worked well for generating GUI and quickly hosting it in the Lovable cloud system in a couple of prompts. Although the system works well for these kind of application, the scope is very limited. As Lovable has their own systems/guardrails in place it limits the choices of the developer. This also forces the developer to switch platforms and tools if they later want to host it somewhere else. Due to these reasons, this approach was left on the prototyping level and out of the larger comparison. 5.2Structured vibe coding: Prompt engineering approach The structured vibe coding 5 approach started through an in- terview with the stakeholder which was the same as for the un- structured vibe coding along with the notes gathered. Next, the 4 Unstructured vibe coding GitHub repository 5 Structured vibe coding GitHub repository developer generated an implementation plan based on the notes collected from the interview and started working from there. Dur- ing the implementation, the vibe developer used some prompting strategies (e.g. planning, progress description files) to manage the process and context. The project was done utilising VS Code and GPT-5.0-Codex agent. The first prompt was to plan an implementation for the whole process. The plans generated during implementation also included checklists to manage context and to keep the developer up to date on the progress. The developer used plans according to their view on when a plan is needed for a larger implementation and when only a prompt would suffice for a more minor functionality. The original plan generated in the first prompt ended up guiding the agentic development to a skeleton for the product. After this, the developer guided the agent on what kind of functionality the developer thought needed to be implemented. The development cycle was mostly to prompt the agent to implement a feature and then manually testing if it worked. The developer never prompted the agent to generate unit tests but some were generated and proved useful in identifying some breaking changes during development. 5.3 Shift-Up approach The Shift-Up framework 6 was used to transform stakeholder needs into a structured machine-readable context. This context is then used first as guardrails for code generation and second as acceptance tests for the generated code. The first part of this framework, shown in Figure 2a, proceeded with the following steps: Stakeholder interview â the experi- mental process began with a more in-depth stakeholder interview than in previous processes. To further elicit core functional and non-functional requirements, Claude Sonnet 4.5 was used as an interactive assistant; SRS generation â the interview output was synthesized into a Software Requirements Specification (SRS) doc- ument. The SRS was then refined through three iteration rounds, each guided by prompt: "Identify any ambiguous or vague terms and flag any requirements that seem to contradict"; User story map- ping â the refined SRS were further decomposed into user stories with the prompt: "Provide structured user stories based on the SRS document. Use a template âAs a <user>, I want <goal>, so that <bene- fit>â". In total 68 user stories were created; BDD transformation â each user story was decomposed into executable acceptance tests in Robot Framework 7 format with the prompt: "Write an accep- tance test-case for each user story in Robot Framework format. Write them in given-when-then format and use best practices". In total 175 test cases were generated; Generation of C4 and ADR artifacts â using the previous steps, C4 and ADR artifacts were generated for context purposes; Implementation roadmap generation â the project was composed into a roadmap where features were divided into implementation phases with the prompt "Make a com- prehensive step-by-step implementation plan for this project. Break it down into sequential batches based on themes of the acceptance tests and logical dependencies. Format: name, goal/theme, key architecture tasks, acceptance test IDs to validate, dependencies". This produced 10 implementation phases that were ordered by logical dependency; 6 Shift-Up approach GitHub repository 7 Robot Framework, accessed on 26.2.2026 Petrus Lipsanen, Liisa Rannikko, François Christophe, Konsta Kalliokoski, Vlad Stirbu, and Tommi Mikkonen Interview with stakeholder SRS document generation User story mapping BDD transformation C4 + ADR generation Implementation roadmap generation GitHub issue generation VSCode + 5.0 CodexClaude Sonnet 4.5 (a) Open new issue Human acceptance Creation of implementation plan Code generation Success Failure Acceptation test run Close issue when tests pass (b) Figure 2: Shift-Up workflow: (a) requirements and architectural grounding, and (b) GenAI-assisted implementation. finally, GitHub issue generation â structured GitHub issues were created based on implementation phases in the roadmap with the prompt "Create issues for each phase in roadmap. Format: imple- ment [name], description, constraint (test idâs that must pass for issue to close), context, links". The first four phases were done utilizing Claude Sonnet 4.5 while the last three were completed using GPT- 5.0-Codex integrated within VS Code. The implementation and verification loop was the second part of the framework, shown in Figure 2b, which proceeded one phase at a time. Each phase was developed in VS Code integrated development environment (IDE) and GPT-5.0-Codex in its own Git branch and submitted as a pull request upon completion. Each loop consisted of five steps: Open issue â the developer selects the next GitHub Issue from the roadmap, respecting the dependencies established in the plan phase; Implementation plan creation â implemen- tation begins with the standardized prompt, which was iteratively refined during the evaluation: "Create an implementation plan for features described in issue X, strictly adhering to architectural plans and technical requirements found in the workspace. Break the imple- mentation down into logical, sequential subtasks and identify which acceptance criteria/tests apply to each phase. Create a separate .md file that includes the plan"; Code Generation â after the plan has been established, the agent proceeds with implementation. In practice, after the plan was created and reviewed, the only instruction given by the developer was to proceed with the plan. Afterwards, the agent generates source code, configuration, and supporting files according to the sequential subtasks in its plan; Acceptance test execution â the Robot Framework acceptance tests linked to the current issue are executed. Two outcomes are possible. Firstly, if all linked tests pass, we simply go to the next step. Secondly, if one or more tests fail, the agent receives the output of these tests as an additional context for the additional iteration of the code generation step. This cycle repeats until all constrained acceptance tests have passed; Close issue â after all tests have passed, the open issue is closed, and the developer opens a new issue. 6 Results In total 176 recorded prompts were categorized from each the struc- tured vibe coding and the Shift-Up approach implementation phases. These are preliminary results, as the Shift-Up approach implemen- tation is not yet concluded, but they provide an overview of the prompt patterns that emerged from the experiment so far. In the Shift-Up approach, the interactions focused primarily on process orchestration and automated validation. Thematic distri- bution of the prompts revealed five distinct categories: proceeding with the next step (62 %), executing acceptance tests (16 %), developer identified fixes (9 %), acceptance of agent-proposed solutions (7 %), and initiating the next step of the overall plan (5 %). In contrast, the structured vibe coding approach was characterized by the developer reacting to agent output. More than half of all prompts were dedi- cated to addressing issues identified manually in GUI or IDE (52 %), followed by proceeding with the next step (27 %). Strategic prompts such as initial planning of a feature and new feature implementation each accounted for 5 % of the total distribution and 11 % of prompts were categorized as other. This thematic categorization revealed a divergence in the devel- oper interaction: the Shift-Up approach is characterized by strategic orchestration, with the majority of the prompts dedicated to advanc- ing the implementation and verifying via automated test suites. In contrast, the structured vibe coding consists of reactive intervention, where the role of the developer is to identify and remediate issues surfaced within the GUI or IDE. Regarding RQ1, we found that by establishing a foundation of autonomous continuous validation, the generative agent is enabled to operate with increased independence during implementation tasks. The integration of BDD principles and executable requirements function as behavioral guardrails al- lowing the agent to self-validate its progress. Table 1 presents a qualitative evaluation of the approaches ac- cording to 5 different categories: upfront investment, human con- trol, structured constraints, development speed, and guardrails. This evaluation compares between the approaches and focuses on the themes from the viewpoint of the developer. Upfront investment was evaluated as the workload prior to starting implementation, human control was evaluated as the ability of the developer to guide the agent during implementation, structured constraints were eval- uated as the formal rules of the approach or limitations imposed on design and code of the system, development speed was evaluated as the time to implement an idea, and guardrails are what were used to enforce human control beyond prompts. The main result from this qualitative evaluation is that Shift-Up has more human control, structured constraints, and guardrails in exchange for higher workload in upfront investment and slower development speed. The structured and unstructured vibe coding approaches were similar in upfront investment, but differences emerged from the amount of human control. For the unstructured approach, the exchange was giving control to the system and lock- ing some solutions in place for a quickly developed prototype. While the Shift-Up framework constrains agent behavior, we were only able to partially answer RQ2 regarding the reduction of agent drift. As an exploratory evaluation, it was intentionally limited to a small project in a relatively common application do- main. This likely made the project more feasible with a vibe coding approach, but this commonality could be a reason for preventing Shift-Up: Framework for Software Engineering Guardrails in AI-native Software Development - Initial findings Table 1: Qualitative evaluation of the approaches covered in exploratory comparative evaluation Development ParadigmsUpfront InvestmentHuman ControlStructured ConstraintsDevelopment SpeedGuardrails UnstructuredMinimalLow-Fastest prototype- StructuredMinimalModerateStructuredFastPrompt Engineering Shift-UpHighHighRigidSlowerBDD/TDD, C4, ADR us from observing drift. From this comparative evaluation, we hy- pothesize that to evaluate agentic drift, the target application needs a more complex domain of application. 7 Discussion and conclusion This paper introduced and explored Shift-Up, formalizing it as pre- scriptive design knowledge for GenAI-native software engineering. By recontextualizing established practices, specifically C4 modeling, architecture decision records, and behavior-driven development, as structural and behavioral guardrails, Shift-Up transitions the operational scope of the developer from low-level code authorship to high-level system orchestration. A primary theoretical contribution is the ability of the selected guardrails to enhance agent autonomy, which leads to the redis- tribution of developer attention throughout the development. In the structured vibe coding approach, the developer effort was con- centrated on reactive debugging and manual verification. In con- trast, Shift-Up necessitates greater engagement during the initial requirements engineering and design phases. The key tradeoff that achieved this greater agent autonomy was the increased workload prior to implementation phase. The Shift-Up approach demonstrates a new paradigm for GenAI- native software development. By supplying the developer with deterministic prescriptive guardrails rather than relying on prob- abilistic prompt optimization, the framework proves that future autonomous AI-native systems must remain grounded in estab- lished software engineering design knowledge. Acknowledgments This evaluation was supported by Business Finland projects ITEA GENIUS (2545/31/2024) and ANSE (1822/31/2025). References [1] Belzner, L., Gabor, T., and Wirsing, M. Large language model assisted software engineering: prospects, challenges, and a case study. In International conference on bridging the gap between AI and reality (2023), Springer, p. 355â374. [2]Brown, S. Visualising software architecture with the c4 model: Context, con- tainers, components, and code, 2018. https://leanpub.com/visualising-software- architecture. [3]Fowler, K. R., and Silver, C. L. Developing and Managing Embedded Systems and Products - Methods, Techniques, Tools, Processes, and Teamwork. Elsevier, 2015. [4] Fuchs, N. E., Schwertel, U., and Schwitter, R. Attempto controlled english - not just another logic specification language. In Logic-Based Program Synthesis and Transformation (Manchester, UK, June 1999), P. Flener, Ed., no. 1559 in Lecture Notes in Computer Science, Eighth International Workshop LOPSTRâ98, Springer. [5]Ge, Y., Mei, L., Duan, Z., Li, T., Zheng, Y., Wang, Y., Wang, L., Yao, J., Liu, T., Cai, Y., Bi, B., Guo, F., Guo, J., Liu, S., and Cheng, X. A Survey of Vibe Coding with Large Language Models, Dec. 2025. arXiv:2510.12399 [cs] version: 2. [6]Hevner, A. The duality of science: Knowledge in information systems research. Journal of Information Technology 36 (08 2020), 026839622094571. [7]Kaulgud, V., Saxena, A., Podder, S., Sharma, V. S., and Dinakar, C. Shifting testing beyond the deployment boundary. In Proceedings of the International Workshop on Continuous Software Evolution and Delivery (New York, NY, USA, 2016), CSED â16, Association for Computing Machinery, p. 30â33. [8]Mikkonen, T., and Taivalsaari, A. Software reuse in the generative ai era: From cargo cult towards ai native software engineering. In Proceedings of Inter- netwareâ25 (2025). [9] Nguyen-Duc, A., Abrahamsson, P., and Khomh, F. Generative AI for effective software development. Springer, 2024. [10]Nooper, D. Secure Software Development Life Cycle Processes. Technical AD1180035, Carnegie Mellon University, Sept. 2022. [11]Nygard, M. Documenting architecture decisions. https://cognitect.com/blog/ 2011/11/15/documenting-architecture-decisions, 2011. Accessed: 2025-09-17. [12] Ozkaya, I. A paradigm shift in automating software engineering tasks: Bots. IEEE Software 39, 5 (Sep. 2022), 4â8. [13] Pattyn, F., and Goetz, P. The Vibe Coding Trap: How AI Accelerates Delivery - and Quietly Breaks Responsibility. The Vibe Coding Series. AI Ventures Press, Jan. 2026. [14] Russo, D. Navigating the complexity of generative ai adoption in software engineering. ACM Transactions on Software Engineering and Methodology 33, 5 (2024), 1â50. [15]Russo, D., Baltes, S., van Berkel, N., Avgeriou, P., Calefato, F., Cabrero- Daniel, B., Catolino, G., Cito, J., Ernst, N., Fritz, T., et al. Generative ai in software engineering must be human-centered: The copenhagen manifesto. Journal of Systems and Software 216 (2024), 112115. [16]Schoormann, T., MĂśller, F., Chandra Kruse, L., and Otto, B. Bausteinâa design tool for configuring and representing design research. Information Systems Journal 34, 6 (2024), 1871â1901. [17] Smith, L. Shift-left testing. Dr. Dobbâs J. 26, 9 (Sept. 2001), 56âf. [18] Solis, C., and Wang, X. A study of the characteristics of behaviour driven development. In 2011 37th EUROMICRO Conference on Software Engineering and Advanced Applications (Aug 2011), p. 383â387. [19] Stray, V., Hanssen, G. K., Barbala, A., Ĺ mite, D., and Stol, K.-J. What is generative ai good for? introduction to the special issue on generative ai in software engineering, 2025. [20] Thomas, D. R. A general inductive approach for analyzing qualitative evaluation data. American Journal of Evaluation 27, 2 (2006), 237â246. [21]Tuunanen, T., Winter, R., and Brocke, J. v. Dealing with complexity in design science research: A methodology using design echelons1. Management Information Systems Quarterly 48, 2 (06 2024), 427â458. [22] Zimmermann, O., Wegmann, L., Koziolek, H., and Goldschmidt, T. Archi- tectural decision guidance across projects - problem space modeling, decision backlog management and cloud computing knowledge. In 2015 12th Working IEEE/IFIP Conference on Software Architecture (May 2015), p. 85â94.