From Prompt to Production: Why AI Software Delivery Needs a Full SDLC
A strategic case for connecting requirements, AI-orchestrated development, automated testing, human validation, deployment, and continuous evolution.
Executive Summary
BLUF: AI coding assistants can turn a prompt into working code very quickly, but they do not replace the need for clear requirements, architecture rules, test results, human approval, deployment controls, or long-term system support. When a Federal program treats a prompt as its main source of truth, it does not remove this work. It only pushes important decisions and problems further into the development process where program risk is introduced.
The Department of Defense is preparing for a software environment where artificial intelligence can handle many common development tasks and support parts of the continuous integration and delivery process. At the same time, the Department's modernization plan still depends on strong leadership, teamwork, knowledge sharing, secure software delivery, and processes that continue to improve over time (Department of Defense Chief Information Officer, 2025). The goal is not to replace the software development life cycle with AI. It is to use AI within a stronger and more effective one.
DoD Instruction 5000.87 supports this same idea in practice. Programs are expected to use automated testing, continuous integration and delivery, regular user feedback, and ongoing improvements while also maintaining prioritized backlogs and coordinated testing plans (Department of Defense, 2020). These activities only work well together when the information passed from one team or stage to the next includes enough detail to keep the original meaning clear.
Alchemy SDLC™ is built to support that goal. It uses the materials created by Alchemist AI Pro™ to connect requirements with AI-supported development, human review, user acceptance testing, deployment, and future system changes. The goal is not to slow down how quickly code can be created. It is to make that speed easier to manage, control, and repeat across a real enterprise software environment (Campbell, 2026).
Introduction
"From prompt to production" sounds like a straight line. In a DoD or federal program, it is not. The idea may begin with a commander, analyst, product owner, or business process expert. The build may be performed by government developers, contractors, a software factory, or several vendors. Cybersecurity, data, identity, test, acquisition, operations, and end users may all hold information that changes what the system must do.
The real question is not just whether an AI model can write code. The organization must also be able to explain what the AI was asked to build, where those instructions came from, who approved the decisions, how the system was tested, and what changed after it was released. This is what separates a quick demonstration from a dependable software system the organization can trust and defend. Without this evidence, leaders may approve of a system that looks impressive but inadvertently presents both mission and program risk.
The market is already moving toward more careful planning before code is created. For example, GitHub's Plan mode reviews a task, identifies requirements and limits, points out unanswered questions, and creates an implementation plan before making code changes (GitHub, n.d.). This is a clear improvement over generating code immediately. It also shows that speed alone is not enough. A plan inside a coding assistant can be helpful, but it only becomes a reliable enterprise standard when it is supported by clear ownership, traceability, independent review, testing, approval, and long-term control.
The Problem: A Prompt Is Not a Production Baseline
The idea that teams can "just wing it" with AI-assisted development comes from a real and impressive experience. A person can describe an idea, watch an AI agent create the files, and quickly see a working screen. Because the results appear so fast, the software may seem more complete than it really is. A screen can work before the team has agreed on who will use it, what permissions are needed, which data source is correct, how errors should be handled, how well the system must perform, what security controls are required, how it will be tested, or how it will affect operations.
A prompt is a shortened description of what someone wants the system to do. It may be enough to start exploring an idea or build a prototype, but it usually does not include enough detail to guide a production system. The missing information does not go away. AI may fill in some gaps with assumptions, developers may make other decisions while building, testers may add details when creating test cases, and users may uncover the remaining problems during acceptance testing or daily use. The work was not eliminated. It was only pushed further down the development process.
The collaboration gap
The collaboration gap creates knowledge continuity risk when the person who understands the idea is not closely connected to the people responsible for building and reviewing it. In a small project, one person may be able to carry the idea from start to finish. In a Federal software program, the work usually passes through several roles, which makes clear documentation essential. Without it, each new developer, tester, cybersecurity reviewer, program manager, or replacement contractor may have to repeat part of the discovery process before moving forward.
When teamwork depends mainly on meetings and chat messages, the organization cannot be sure that everyone heard the same explanation or understood it in the same way. The person with mission knowledge may not be involved when an important technical decision is made. The engineer may not know which exception is critical to daily operations. The tester may receive acceptance criteria that explain the normal process but leave out the system status, data, and permission rules needed to test it correctly.
One coding assistant is not automatically a shared operating model
ACC3 has seen a similar problem when several people use the same coding assistant. The tool can still create useful results, but the session may become difficult to manage. Each person may use different terms, focus on different priorities, or provide different levels of detail. A new prompt can accidentally change a decision that was made earlier. Over time, one person may become responsible for remembering what the group intended, while the chat history becomes the closest thing the team has to an official record.
Alchemist AI Pro™ is designed to work differently by turning the knowledge of the group into shared documents and other reusable materials. Mission owners, product teams, technical experts, and reviewers can all provide information and clarification without allowing the latest prompt to replace earlier decisions. The results can be reviewed, checked for quality, approved or rejected by responsible people, and reused during the next stage of development. This turns teamwork into a lasting resource instead of letting important details get lost in the conversation (Campbell, 2026).
This difference matters because the operational risks created by generative AI cannot be controlled only when code is being created. NIST's Generative AI Profile explains that governance, risk identification, measurement, management, and testing before deployment must be handled throughout the entire lifecycle based on the organization's goals, level of risk, and operating environment (National Institute of Standards and Technology, 2024). Federal software programs need the same approach. AI can help teams work faster, but the organization must still control and approve what the work is supposed to mean.
Why the Problem Persists
The problem continues because the "wing it" approach often works well enough during the prototype stage. Teams can produce something visible very quickly, which can make the application seem more complete than it really is. Important details involving requirements, testing, security, and previous decisions may still be missing, but those gaps are easy to overlook until the software must operate in a real environment. At that point, the system may need to connect with other applications, serve users with different permissions, pass formal reviews, or be maintained by someone who was not involved in the original discussions.
Planning and specification tools can help teams think through an idea before they start writing code. However, the information they create may only stay connected to one task or one working session. As the project moves into testing, release, and future updates, important decisions can be forgotten or misunderstood. A program-wide process is needed to keep requirements, approvals, and supporting information connected over time. This gives future teams a clear record to use instead of making them repeat earlier discussions. Preserving that record reduces knowledge continuity risk and gives the program a more stable baseline for change.
Figure 1. Plan or spec mode improves coding preparation, but lifecycle discipline is what preserves authority, testability, and continuity.
Automated testing exposes the difference
Testing is where the problems in an incomplete plan become easier to see and measure. When acceptance criteria leave out the user, starting condition, trigger, failure path, expected result, or original requirement, the test team must fill in the missing details. This can lead to a test script that passes even though it is checking behavior that was never officially approved. The pipeline may appear successful, but the program still cannot prove that the software meets the mission need.
DoDI 5000.87 requires developmental, government, and operational testing to be connected and automated, with test scripts and results available for repeated verification and validation (Department of Defense, 2020). However, that process begins before the test is run. The requirement must first provide a clear and reliable target for automation.
From Acceptance Criteria to Automated Assurance explained one practical way to create that connection. Alchemist AI Pro™ exports approved acceptance criteria and test definitions into a structured CSV file that a Playwright-based testing system can use. This helps preserve important information, including identifiers, users, conditions, expected results, and source requirements, from the requirements process through testing and final evidence (Brooks, 2026).
The Solution: Alchemy SDLC™
Alchemy SDLC™ is a complete software development life cycle built around shared documents and development materials that move with the project from one stage to the next. Human experts remain responsible for defining the purpose, limits, priorities, and approval decisions, while AI helps teams analyze information, create and review materials, and reuse them more efficiently throughout development. Calling it a "full" life cycle does not mean adding unnecessary steps or processes. It means making sure the original intent, important decisions, and supporting information are clearly recorded and not lost as the work moves between people, teams, and stages.
Figure 2. The Alchemy SDLC™ carries approved artifacts through requirements, development, human validation, deployment, and future evolution (Derived from Campbell, 2026).
Alchemy Crew uses the approved package to coordinate specialized AI agents under a Master Designer across development, data, DevOps, security, quality, reliability, user experience, documentation, and integration. Human observers can inspect phase outputs and checkpoint reports instead of waiting until the end of an opaque build.
The Final Mile is still led by people. Developers connect the software to the customer's environment, user access systems, data, outside interfaces, and deployment tools. Alchemy UAT then checks whether the finished system matches the original business need. After deployment, Round-Trip keeps the code, requirements, test results, system connections, and human-made changes together. This allows the next update to begin with the system as it actually exists. Each release becomes the starting point for the next one.
More information about Alchemist AI Pro™ and Alchemy SDLC™ is available at acc3int.com/alchemist.
Benefits: What Complete SDLC Changes
For buyers, Alchemy SDLC™ provides greater confidence in what the organization is purchasing and delivering. Approved artifacts make it easier to understand the project scope, identify unresolved issues, and recognize assumptions that could affect cost or schedule. Business rules, enterprise limits, and acceptance conditions are reviewed before development decisions become expensive to change, which can reduce avoidable rework. Requirements, decisions, tests, defects, and release results can also be connected through a clear chain of authority. This gives leadership stronger evidence when deciding whether a release is ready and helps preserve important knowledge when people, vendors, or priorities change.
For IT experts, the approach provides clearer technical information before code generation begins. Important details involving architecture, identity, data, integrations, monitoring, deployment, and compliance can be identified early instead of being built around weak assumptions. Acceptance criteria and test definitions are created alongside the requirements, giving automation engineers a more reliable target. Engineers still maintain control through human review points where they can inspect AI-generated work, resolve implementation decisions, and manage tasks that depend on the customer's environment. The resulting artifacts are designed to work with existing repositories, development tools, CI/CD pipelines, and testing frameworks rather than replace them. This also reduces documentation problems because future releases can begin with the deployed code, approved specifications, test results, and recorded human changes instead of relying on outdated documents.
What the model does not remove
Alchemy SDLC™ does not replace the people and teams responsible for planning, building, securing, testing, and operating software. Instead, it gives them better information and keeps a clear record of the decisions made throughout the process. People still remain responsible for setting the project scope, deciding which operational risks are acceptable, connecting the system to its technical environment, and approving the final release.
This separation is important for organizations thinking about using AI in software development. The DoD Software Modernization Strategy explains that reliable software delivery is a responsibility shared across the entire organization. NIST guidance also states that risk management and secure development practices should be included throughout the full software life cycle (Department of Defense, 2022; National Institute of Standards and Technology, 2024; Souppaya et al., 2022). A complete SDLC keeps people in control of important decisions while still allowing AI to help teams work more quickly.
A practical adoption path
An organization does not have to change every program at the same time. A practical pilot can begin with one feature or workflow where acceptance criteria and regression tests are difficult to manage. The organization can then compare its current process with an artifact-centered approach by measuring requirement clarity, traceability, test readiness, and the quality of release evidence. GAO's Agile Assessment Guide provides a similar way to measure progress through user involvement, clear acceptance criteria, continuous integration, and automated testing (Government Accountability Office, 2023).
Tradewinds Awardable Positioning
Alchemist AI Pro™ is Tradewinds Awardable. ACC3 submitted the platform as the "Accelerating the Mission" solution, and the requirements engine was assessed through the Tradewinds Solutions Marketplace process. CDAO describes the marketplace as a repository of post-competition, readily awardable pitch videos addressing government challenges in AI/ML, digital, and data analytics (Chief Digital and Artificial Intelligence Office, n.d.).
Call to Action: Request an Executive Brief
ACC3 recommends holding an Executive Brief focused on an important software project where AI-assisted development is already being used or may be used in the future. The brief should go beyond a basic product demonstration. It should help decision-makers determine whether the organization has a complete enough process to move from an AI prompt to production software that is secure, testable, maintainable, and connected to the mission.
A focused Executive Brief can begin by showing how an idea moves through the software development process, from the first requirement and plan to coding, testing, approval, deployment, and future updates. It can then examine one example feature to see whether the users, conditions, limits, failure paths, acceptance criteria, source information, and test evidence are clear enough for the next team to continue the work.
The brief can show where teams rely too much on memory, where an AI coding assistant is being asked to fill in missing decisions, and where testing or security work starts too late. After finding these problems, the organization can choose a small pilot to show how shared documents and recorded decisions can improve the process without changing the entire organization at once.
References
Brooks, K. (2026, July 19). From Acceptance Criteria to Automated Assurance. ACC3 International. https://www.acc3int.com/whitepapers/acceptance-criteria-to-automated-assurance
Campbell, J. (2026). The Alchemy SDLC [Presentation]. AI Pro Holdings, Inc.
Chief Digital and Artificial Intelligence Office. (n.d.). Tradewinds. https://www.ai.mil/Industry/Tradewinds/
Department of Defense. (2020). DoD Instruction 5000.87: Operation of the software acquisition pathway. https://www.esd.whs.mil/Portals/54/Documents/DD/issuances/dodi/500087p.PDF
Department of Defense. (2022). Department of Defense software modernization strategy. https://media.defense.gov/2022/feb/03/2002932833/-1/-1/1/department-of-defense-software-modernization-strategy.pdf
Department of Defense Chief Information Officer. (2025). Software modernization implementation plan, FY25-26. https://dodcio.defense.gov/Portals/0/Documents/Library/SW-Mod-I-Plan25-26.pdf
GitHub. (n.d.). Asking GitHub Copilot questions in your IDE. Retrieved July 18, 2026, from https://docs.github.com/en/copilot/how-tos/chat-with-copilot/chat-in-ide
Government Accountability Office. (2023). Agile assessment guide: Best practices for adoption and implementation (GAO-24-105506). https://www.gao.gov/products/gao-24-105506
National Institute of Standards and Technology. (2024). Artificial intelligence risk management framework: Generative artificial intelligence profile (NIST AI 600-1). https://doi.org/10.6028/NIST.AI.600-1
Souppaya, M., Scarfone, K., & Dodson, D. (2022). Secure software development framework (SSDF) version 1.1: Recommendations for mitigating the risk of software vulnerabilities (NIST SP 800-218). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-218
© 2026 ACC3 International. Alchemist AI Pro™ and Alchemy SDLC™ are trademarks of their respective owners.
