From Vibe Coding to Governed Delivery

2026-07-02 · Doug Preyna · ACC3 International

From Vibe Coding to Governed Delivery

Why AI-Assisted Software Still Requires an SDLC

> BLUF: AI can accelerate coding and move an idea to a working prototype quickly, but it does not resolve the organizational conditions that leave software initiatives misaligned with the mission need, operational environment, or people expected to use and sustain them. AI-assisted coding tools can generate a working prototype well before an organization has answered the more basic questions: What operational problem does the system actually address? Where does the underlying data originate, who is authorized to access it, and who assumes responsibility for the capability once it fails? These questions are not incidental. They are the ones the SDLC was built to answer, and they are what allows an operational need to become something traceable, secure, and supportable over time.

Purpose

There are valuable outcomes of this level of speed: a quick prototype can reveal a problem nobody considered. A prototype can also be used as a baseline to prove or disprove a hypothesis. Moreover, a prototype can also represent a concrete artifact in front of users instead of a wireframe. Each of these uses is important; none should be dismissed. What is usually discussed less is recognizing the point at which a working application has earned its way past experimentation, the point where enough is known about its context, its controls, and the evidence behind it to justify treating it as something more than a demo.

A working prototype is not a production system; the difference is not just polish-it includes differences "under the hood." A prototype may be able to defer some production controls when it uses synthetic data, limited access, and isolated infrastructure. Once it touches operational data, users, or enterprise services, those controls become part of the work-not a later enhancement. Most audience demonstrations are intentionally built around a well-tested primary workflow under favorable conditions. They seldom expose alternate paths, edge cases, exception handling, unusual role combinations, incomplete or inaccurate data, degraded interfaces, or recovery after a failure. Those conditions are often what determine whether a capability can be trusted in routine operational use. An enterprise environment has no such freedom, and that gap is precisely where the risk hides. The fact that a screen performs well in front of an audience says almost nothing about whether anyone has actually settled who the users are, where the data will live, what the system depends on, or who is responsible for keeping it running once it ships.

This paper looks at the business-analysis work that sits between AI-assisted development and a disciplined SDLC. It addresses why a prototype can look further along than it really is, even when the requirements, decisions, and operational context underneath it are still incomplete. It also explains how Alchemist AI Pro™ helps teams bring that information together in a form that can support production-ready software.

A Working Prototype Is Not Production Readiness

The Problem: A Prototype Can Look More Complete Than Its Delivery Foundation

Rapid AI-assisted development is a real advantage, and teams should take advantage of it. The tools can now produce more than static mockups or clickable screens. They can generate working interfaces, connected workflows, and early integrations quickly enough to put in front of stakeholders during an Agile Review and Demo.

Earlier vibe-coded efforts were mostly demo ware: attractive screens that suggested progress but did little beyond basic interaction. The risk has changed shape along with the speed. The current rush is toward spec-driven development and agent orchestration. In spec-driven development, an AI tool works from written specifications; in an orchestrated workflow, one or more agents coordinate planning, coding, testing, integration, and remediation. Both approaches can add useful structure and automation. Neither can determine whether the starting specification reflects the operational context, policy constraints, edge cases, or ownership decisions the organization has yet to make. When that foundation is thin, automation can carry the same incomplete assumption through several downstream artifacts before anyone notices. Current tools now reach deeper into the stack, generating code, data-handling patterns, API calls, and user flows that look ready to build on.

AI rarely invents delivery problems from scratch. What it tends to do instead is surface and speed up whatever was already there, for better or worse. The 2025 DORA research bears this out: AI adoption tends to improve throughput and product performance, but it can also erode delivery stability in teams that lack solid control systems, automated testing, mature version control, tight feedback loops, and real alignment across the team. Give a healthy delivery system more AI, and it moves faster. Give a shaky one more AI, and unclear decisions, weak handoffs, and hidden dependencies just travel through the organization faster too (Harvey & DeBellis, 2025).

The question is no longer just whether the prototype runs. The harder question is whether the work behind it captured what the capability will need to operate responsibly in the real environment.

A working screen can make a system look further along than it is. Problems with identity, data storage, integration, business rules, or compliance may not show up in a demo at all, even though they will matter once the capability moves beyond the prototype stage.

Figure 1. A Working Prototype Is Not Production Readiness

These gaps rarely exist because someone ignored them on purpose. More often, nobody wrote them down to begin with. Vague requirements drift through a chain of prompts and generated output, picking up assumptions along the way that nobody quite decided on, until there's no real record left of what the organization actually needed versus what the team guessed at versus what simply changed somewhere in the process.

The concern is not limited to coding. Cheng et al. (2026) reviewed 105 studies on generative AI in requirements engineering and found recurring issues around interpretability, reproducibility, controllability, and governance.

Teams may not always be able to explain why a model produced a particular result or get the same result consistently from similar inputs. They can also lose visibility into how a series of prompts and responses shaped the requirements artifact over time. Security and ethics were identified as separate governance concerns as well.

That does not mean GenAI should be kept out of requirements work. It means teams need to keep track of what went into the work and how key decisions were made. Source material, assumptions, clarifications, and human review should remain visible when GenAI is helping turn operational intent into software requirements.

Table 1 separates the visible evidence of progress from the work that must be established before a capability can be treated as production ready.

| A demo may show | Production must establish | What can go wrong when the work remains implicit | | --- | --- | --- | | A working screen, dashboard, or workflow | Presentation and User Experience: The interface supports the actual user task, accessibility expectations, error handling, usable navigation, and the conditions under which people will use it. | A polished interface is built around an incomplete workflow. Users may work around the application, enter information inconsistently, or lose confidence when real exceptions appear. | | A basic user flow | Identity and Access Management: The application identifies users correctly, applies role-based access, supports usable administration, records activity where needed, and aligns access with enterprise policy. | Users may receive access they should not have, legitimate users may be blocked from essential work, or administrators may lack a practical way to manage permissions after release. | | Data entered on one screen and displayed on another | Data Storage and Persistence: Data sources, ownership, classification, validation, retention, duplication, search behavior, and downstream use are defined. | The system may store sensitive information inappropriately, duplicate records, expose incomplete data, create unusable search results, or pass flawed information into downstream systems. | | Generated logic, forms, and API calls | Core Engine and Business Logic; Integration and Interfaces: Business rules, calculations, system contracts, validation rules, vendor dependencies, and interface behavior are understood and documented. | The application can appear to work in isolation while producing incorrect decisions, breaking an upstream or downstream contract, mishandling exceptions, or relying on a dependency the organization cannot support. | | A successful demonstration | Observability and Reporting; DevOps and Deployment; Government and Regulatory Compliance: The organization can monitor the capability, investigate issues, deploy changes safely, recover from failure, and meet applicable policy or contractual obligations. | The team may be unable to determine what happened after an incident, deploy a correction without disruption, restore a failed service, demonstrate compliance, or assign ownership for support. |

Table 1. Visible prototype evidence is not the same as production readiness. The framework areas correspond to the Alchemist AI Pro™ Architectural Framework.

This table isn't an argument against AI-assisted coding. It's closer to a map of the work that tends to happen outside the visible prototype, the part nobody's looking at because there's nothing on screen to see. People can see a working application, click through it, touch it — and that's exactly why it's easy to assume the hard part is already done. It isn't. The harder part is everything the prototype can't show you: why the system behaves the way it does. As the group gathers to assess as a community, a mutation of the original intent comes into existence and with no way to track back to the intent because its either vibed directly or summarized in simplified specs, the design is done on the fly, and ultimately, the misses compound and dread expands.

ai emotional journey wide colored Security, privacy, compliance, engineering, and operations teams need more than a chance to sign off on a prototype after the fact. They need a record — what the organization actually intended, which constraints apply, what evidence will demonstrate the system is ready for operational use. The issue is not usually that someone made a decision before a formal review. More often, the prototype grew out of a series of prompts, conversations, and small course corrections, while the reasoning behind those choices was never fully captured. By the time reviewers get to it, they're often looking at something that works without knowing what was unclear at the start, what the AI assumed along the way, what data conditions got built in, or how far the design has actually drifted from the original request. Business analysis is what makes those decisions, assumptions, and changes visible — before they harden into something much harder to unwind.

Why Security and Compliance Cannot Be Bolted On at the End

A working application is not proof that it is secure, supportable, or ready to operate in a real environment. In a 2025 study of 733 AI-generated Python and JavaScript code samples from GitHub projects, researchers found security weaknesses in 27.3% of the code they examined.

That does not mean every AI-generated application is insecure, nor that human-written code is automatically safe. The finding supports a narrower point: functional output is not the same as production-readiness evidence. Generated code still needs to go through security review, testing, and whatever controls the target environment requires (Fu et al., 2025).

An SDLC captures the decisions that link an operational need all the way through the development and support process. NIST's Secure Software Development Framework calls for secure practices across the whole lifecycle; CISA's Secure by Design guidance agrees, but from a different angle: security should be a design responsibility, not a late repair (CISA, 2023; Souppaya et al., 2022).

Late discovery forces expensive rework showing up in predictable ways:

A data model turns out not to fit classification or retention rules after all.
Access controls got built as an application feature when they should have lived in enterprise identity from the start.
A generated component quietly leans on a library the organization can't approve, let alone sustain long-term.
And the functional tests, every single one green, never actually showed that the capability meets the mission need, demonstrating only that the code does what the code does.

Fast development does not remove the need for review. It makes the quality of the information going into those reviews even more important. The Department of Defense's software modernization strategy calls for delivering capability at the speed of relevance, but not at the expense of the resilience and trust required for operational use (Department of Defense, 2022).

Governed Velocity Begins with Requirements Traceability

AI-assisted experimentation can move quickly, but speed alone is not enough. The organization still needs to see the decisions that were made, the constraints the capability has to operate within, and the evidence that shows it is ready to move forward. Capturing that information early gives teams a chance to address problems before they turn into expensive rework. That is the difference between moving fast and delivering something the organization can support. A capability may work in a demo, but that does not mean the organization is ready to rely on it once it is released.

Requirements connect the operational need to the technical work meant to address it. They make clear what the system needs to do, whom it affects, what conditions it has to operate within, and how the team will know the intended result was achieved (Wiegers & Beatty, 2013).

When those requirements are traceable, the team can see the difference between what a stakeholder asked for, what policy or regulation requires, and what an AI tool may have inferred from an early request.

A workable delivery model begins with the mission need and carries that intent through the work from requirements to sustainment. None of those steps along the way exist simply to create paperwork; each captures decisions, assumptions, and constraints that matter later.

When a capability changes hands, the next team needs more than the code or a high-level description. They need to understand why it was built that way, how it should be tested, what it depends on, and what cannot be changed without consequences. That is what makes the capability supportable, not only at launch, but years after the original team has moved on.

Questions the Business Analysis Process Must Resolve

A longer prompt does not, by itself, answer the questions in Table 1. It may give the AI more context at a single point in time, but it does not necessarily preserve the full reasoning behind the request, manage the relationships among requirements, policies, data, users, edge cases, and dependencies, or maintain a durable record of what was decided. As the work continues, important details can be compressed, forgotten, reinterpreted, or carried forward as assumptions without anyone realizing it. What is needed is not just a better prompt, but a business-analysis process and application layer that manages the pieces the AI is working with, preserves context across the effort, separates the user's need from an early technical solution, surfaces ambiguity, and turns what it learns into development-ready work. The Alchemist AI Pro™ process does this across six connected activities.

1. Stakeholder Intake and Document Ingestion

The work starts with whatever already exists to describe the operational environment: stakeholder input, prior requirements, user guides, policies and procedures, interface and database documentation, sometimes nothing more than the behavior of an existing application and its code. Pulling all of that together matters for a simple reason: without it, the prototype becomes the only evidence anyone has of what the system is supposed to do. The intake and ingestion also surface knowledge that is usually scattered across documents, systems, and a handful of people who happen to remember how something works. None of this is new. Treating source code and existing documentation as primary evidence, rather than relying on what people recall, has long been standard practice in legacy-system analysis (Seacord et al., 2001).

2. Domain Knowledge and System Context

A feature rarely stands on its own because it must work within existing constraints (data definitions, interfaces, SLAs, etc.), some of which may be poorly documented or inherited from earlier decisions; however, they still impact the feature.

Addressing these issues early on helps to resolve the integration, data, and ownership issues identified in Table 1 before generated code hardens an approach that does not fit the larger environment. The underlying principle is not new. Research on domain ontologies and requirements elicitation makes a similar point: operational context needs to be captured deliberately and in a structured way rather than left unstated and discovered later (Kaiya & Saeki, 2006).

3. Initial Feature Set, User Need Before Solution Design

Stakeholders often start by asking for a screen or a report but miss what the user is trying to accomplish and what result the organization needs.

Early conversations must stay focused on the operational need. When a list of features is injected before the operational need has been identified, the list of features is treated as the requirement regardless of whether it solves the problem that prompted the request. That is not just a matter of good judgment. Research on structured product discovery points in the same direction: teams that begin with the user's intended outcome and work backward toward a technical design tend to spend less time building the wrong thing (Ates & Suppayah, 2024).

4. Elaboration and Removal of Ambiguity

Ambiguous language usually produces ambiguous software. A subject-matter expert may think a phrase is perfectly clear, but other reviewers interpret it with a different context, or an AI tool may take it in a completely different direction. Elaboration matters. It forces the team to work through the scenarios, exceptions, definitions, and unstated assumptions before they become part of the generated code and creates a record of what was decided and why. This record is particularly important when a prototype has evolved through a long series of informal prompts and conversations. Research on requirements elicitation has found that structured, dialogue-based approaches do a better job of exposing ambiguity and hidden assumptions than unstructured discussion alone (Christel & Kang, 1992; Ferrari et al., 2015).

5. Actors, Objects, Processes, and Business Rules

Production systems depend on distinctions that get blurred constantly in casual conversation. In prompt-led development, the AI assistant usually sees the immediate request and the user interacting with it at that moment. It does not automatically understand the organization's role model, separation-of-duties requirements, administrative model, or the rules governing who may create, approve, view, edit, override, or delete information.

A prototype may therefore demonstrate a primary workflow successfully while leaving unanswered whether role-based access controls work across alternate user roles, delegated authority, exceptions, approvals, downstream systems, and unusual data conditions. The issue is not that developers using AI have poor intentions. It is that those controls are easy to overlook when the visible goal is to make the workflow work for the person currently demonstrating it.

Somebody has to define who performs the work, what information is in play, how the process moves step by step, and which rules determine the outcome. Those questions map directly onto the identity, data, logic, and integration rows in Table 1. None of this is unique to software. The same logic appears in business capability modeling, which separates what a function does from how it happens to be implemented at any given moment (Homann, 2006).

6. Epics, Stories, and Acceptance Criteria

The final step is turning a clarified need into work the delivery team can actually build. Epics and user stories need to carry the operational context forward with them, not strip it out the moment the work crosses over into development, which is exactly what tends to happen if nobody's watching for it. Acceptance criteria are what make the expectation concrete: something the team can point to and say they observed it, verified it, or demonstrated it when the work was done.

This matters especially when a generated application includes baseline authentication or role checks that appear sufficient during a demonstration. The presence of a login screen or a basic role-based access control setting does not establish that authorization works correctly across the application. Acceptance criteria should test more than whether an intended user can complete the primary workflow. They should also address whether unauthorized users are blocked, privileged actions are controlled and recorded where required, sensitive data remains protected, exceptions are handled correctly, and controls hold across the interface, service, integration, and data layers.

That changes the standard from "the feature seems to work" to "the capability meets a defined and testable expectation." Using clear, constrained acceptance criteria helps avoid the ambiguity, vagueness, and lack of testability that research has consistently associated with loosely written requirements (Mavin et al., 2009).

Across these activities, Alchemist AI Pro™ does more than organize a conventional requirements workshop. It creates a repeatable path from dispersed source material and stakeholder knowledge to reviewable delivery artifacts. Table 2 shows the relationship between the information brought into the process, the artifacts produced, and the stakeholders who use them.

| Activity | Alchemist AI Pro™ Consumes | Alchemist AI Pro™ Produces | Who Consumes It | | --- | --- | --- | --- | | Stakeholder intake and document ingestion | Stakeholder input, prior requirements, user guides, policy documents, legacy artifacts, code, interface documentation, and meeting notes | Source-linked context, initial requirements material, unresolved questions, and gaps requiring clarification | Product owner, business analyst, subject-matter experts | | Domain knowledge and system context | Data definitions, existing system behavior, interfaces, dependencies, operational constraints, and service expectations | Context model, dependency information, ownership questions, and identified technical or operational constraints | Architects, data owners, cyber personnel, product and delivery leads | | User need before solution design | Requested features, stakeholder concerns, mission objectives, user tasks, and expected outcomes | Problem statements, user needs, desired outcomes, and candidate feature boundaries | Product owner, users, program leadership, business analysts | | Elaboration and ambiguity removal | Draft requirements, prompts, stakeholder language, policy terms, and incomplete assumptions | Clarification questions, scenarios, exceptions, definitions, decisions, and documented assumptions | Subject-matter experts, product owner, quality personnel, reviewers | | Actors, objects, processes, and business rules | Operational workflows, roles, data objects, decision points, and business rules | Process descriptions, actor definitions, data relationships, business rules, and operational logic | Business analysts, architects, developers, testers, operations stakeholders | | Epics, stories, and acceptance criteria | Clarified needs, constraints, business rules, decisions, and expected outcomes | Epics, user stories, acceptance criteria, specifications, and traceability artifacts | Development teams, quality teams, product owners, program and review stakeholders |

Table 2. How Alchemist AI Pro™ converts operational context into reviewable delivery artifacts.

Alchemist AI Pro™ gives teams a repeatable way to carry operational context forward rather than losing it as work moves from discussion to prototype, prototype to backlog, and backlog to delivery. The output is not simply a collection of user stories. It is a traceable set of requirements, assumptions, business rules, acceptance criteria, dependencies, and unresolved decisions that different stakeholders can review from their own perspective before those issues harden into the product. It's not a substitute for the judgment of the people who know the mission, the systems, or the risks. What it gives them is a common, traceable starting point, something to work from before assumptions quietly harden into design decisions and design decisions quietly become part of the shipped product.

Across the six activities, the goal is to close the gaps identified in Table 1. A prototype is tied back to the need it is meant to address, the data and access conditions it must operate within, and the dependencies it relies on. The result is more than something that looks ready. It is a capability with enough documented context and evidence for the organization to determine whether it is ready to move forward.

The Solution: Alchemist AI Pro™ Supports the Modern SDLC

A lot can go wrong before development ever begins. The need may not be fully understood. Stakeholders may be working from different assumptions. Important context from an existing system may be missing, or a decision made early in the conversation may never have been written down.

The result can be a capability that looks perfectly reasonable in a demo but still does not fit the environment in which it is required to run. AI-assisted development helps the problem show up sooner. Software can now go from idea to prototype faster than most organizations can build shared understanding of what they need, what constraints apply, and what success is even supposed to look like.

Alchemist AI Pro™ works from the material an organization already holds. It takes operational knowledge and existing system artifacts and turns them into usable requirements, specifications, acceptance criteria, and traceability, so the team isn't starting from a blank page.

Figure 2. From Dispersed Knowledge to Governed Delivery

That baseline gives the organization a clear thread from an operational problem to the artifacts used to deliver against it. Security, privacy, engineering, program, product, and quality stakeholders can all review the same requirement set while a prototype is still easy to change. Rather than working around the SDLC, Alchemist AI Pro™ reinforces the requirements foundation that keeps AI-assisted delivery reviewable and anchored to the mission need.

What Enterprise and Government Leaders Gain

Operational alignment. A clear requirements record separates the mission outcome from the first technical idea for achieving it. That matters because a small misunderstanding at the beginning can otherwise follow the work all the way through design, development, testing, and delivery.

Earlier risk discovery. Data, access, privacy, integration, and compliance questions need to come up while the team can still make meaningful changes. Once people have seen a working prototype, those same questions are much harder to address. By then, the system may look finished to stakeholders even when important issues are still unresolved.

A usable decision trail. Traceable requirements show how a feature connects back to the constraints it must operate within, the business rules it has to follow, and the evidence used to confirm it works as intended. That history is what the team can fall back on when questions come up: during development, during testing, in an audit, or years later when someone's trying to sustain the thing.

More productive cross-functional review. Stakeholders can discuss a shared requirement set rather than reconstructing intent from a demonstration or a late-stage design.

Faster experimentation with fewer blind spots. Teams can lean on AI for prototyping and faster development while keeping a structured way to spot the controls and dependencies that decide whether an idea is ready to move forward.

Conclusion

AI-assisted coding can get an early version of software in front of users very quickly. That does not eliminate the harder work of determining whether the capability solves the right problem, fits into the existing environment, handles data and access appropriately, and can be supported after release.

That is what the SDLC is there to protect. Alchemist AI Pro™ helps teams build the requirements foundation early, so AI-assisted delivery remains tied to the mission need and gives reviewers, developers, and leaders a clear record of what the capability is supposed to do and why.

Ready to Get Started with ACC3 International?

The next step doesn't have to be some big transformation effort or another requirements workshop that ends up producing a stack of documents nobody uses again. We can start with one AI-assisted initiative and one practical question: is the work behind this prototype actually solid enough to support an operational decision?

ACC3 International helps organizations use Alchemist AI Pro™ to examine the gap between what a capability appears to do in a demonstration and what it must establish before it can be trusted in production. Working from the material the team already has (stakeholder input, existing project artifacts, requirements, user stories, policy documents, meeting notes, interface definitions, code, database artifacts, and known review concerns), ACC3 International helps turn fragmented context into a strong foundation aligned with mission needs.

A Focused Starting Point

A focused engagement starts with one recent, active, or code-complete initiative, one where the speed of development has raised real questions about requirements, stakeholder alignment, security, data handling, integration, compliance, or operational ownership. The purpose is straightforward: give leaders and delivery teams a clear view of what still needs to be resolved before the capability moves forward, and what evidence will confirm readiness.

Using Alchemist AI Pro™, the team can develop or strengthen:

Clear problem statements and mission outcomes
Traceable requirements, business rules, and assumptions
Epics, user stories, and testable acceptance criteria
Data, access, integration, and dependency considerations
Unresolved decisions and targeted questions for stakeholders
A usable record that connects the operational need to development, testing, release, and sustainment

The result is more than just a cleaner set of requirements. It gives the organization something to make decisions with. Leaders can see where the risk is concentrated. Reviewers can raise concerns while design choices are still cheap to change instead of after they've hardened. Delivery teams get to move ahead knowing what they're building, why it matters, and what has to be true for it to actually work once it's out in the operational environment.

Organizations that want to preserve the speed of AI-assisted development without accepting avoidable delivery risk should begin with one capability that has already exposed friction between the prototype and the environment in which it must operate. ACC3 International can help convert that friction into a repeatable, governed approach to AI-assisted delivery, one that moves quickly while remaining aligned to the mission, the enterprise, and the people responsible for sustaining the result.

References

ACC3 International. (n.d.). Alchemy journey slides.

Ates, A., & Suppayah, K. (2024). Disciplined innovation: A case study of the Amazon Working Backwards approach to internal corporate venturing. Research-Technology Management, 67(3), 23-33.

Cheng, H., Husen, J. H., Lu, Y., Racharak, T., Yoshioka, N., Ubayashi, N., & Washizaki, H. (2026). Generative AI for requirements engineering: A systematic literature review. _Software: Practice and Experience, 56_(2), 141-170.

‌Christel, M. G., & Kang, K. C. (1992). Issues in requirements elicitation (CMU/SEI-92-TR-012). Software Engineering Institute, Carnegie Mellon University.

Cybersecurity and Infrastructure Security Agency. (2023). Shifting the balance of cybersecurity risk: Principles and approaches for secure by design software.

Department of Defense. (2022). Department of Defense software modernization strategy.

Ferrari, A., Spoletini, P., & Gnesi, S. (2015). Ambiguity as a resource to disclose tacit knowledge. In Proceedings of the 2015 IEEE 23rd International Requirements Engineering Conference (RE) (pp. 26-35). IEEE.

Fu, Y., Liang, P., Tahir, A., Li, Z., Shahin, M., Yu, J., & Chen, J. (2025). Security weaknesses of Copilot-generated code in GitHub projects: An empirical study. _ACM Transactions on Software Engineering and Methodology, 34_(8), Article 218.

GitHub. (n.d.). _Spec Kit_ \[Computer software\]. GitHub. Retrieved July 2, 2026, from

Harvey, N., & DeBellis, D. (2025, September 23). Announcing the 2025 DORA report: State of AI-assisted software development. _Google Cloud Blog_.

‌Homann, U. (2006). A business-oriented foundation for service orientation. Microsoft Corporation.

Kaiya, H., & Saeki, M. (2006). Using domain ontology as domain knowledge for requirements elicitation. In Proceedings of the 14th IEEE International Requirements Engineering Conference (RE, 2006) (pp. 189-198). IEEE.

Karpathy, A. \[@karpathy\]. (2025, February 2). There's a new kind of coding I call "vibe coding" \[Post\]. _X_.

Mavin, A., Wilkinson, P., Harwood, A., & Novak, M. (2009). Easy approach to requirements syntax (EARS). In Proceedings of the 2009 17th IEEE International Requirements Engineering Conference (RE'09) (pp. 317-322). IEEE.

Seacord, R. C., Comella-Dorda, S., Lewis, G. A., Place, P. R. H., & Plakosh, D. (2001). Legacy system modernization strategies (CMU/SEI-2001-TR-025). Software Engineering Institute, Carnegie Mellon University.

Souppaya, M., Scarfone, K., & Dodson, D. (2022). Secure software development framework (SSDF) version 1.1: Recommendations for mitigating the risk of software vulnerabilities (NIST Special Publication 800-218). National Institute of Standards and Technology.

Wiegers, K., & Beatty, J. (2013). Software requirements (3rd ed.). Microsoft Press. ISBN: 978-0735679665.