AI software delivery connects three responsibilities: AI engineering teams design and build the application and verify its business logic; an independent AI QA team tests the candidate and approves or rejects its staging handoff; and AI DevOps configures infrastructure, deploys the approved application and verifies the result. Production deployment requires separate human authorization.
The goal is not simply to generate more code. It is to connect a clear specification, implementation checks, independent assessment and deployment evidence so the next owner can make an informed decision.
This guide explains that full lifecycle, using an illustrative purchase-request application. It describes a recommended delivery process, not a customer case study or a guarantee of autonomous, defect-free software.
What does an end-to-end AI development workflow include?
In this article, AI software development means using AI agents to build software, not necessarily building an application that contains an AI model.
The workflow has seven connected stages:
- Define the product outcome and resolve important business rules.
- Create the application specification and architecture.
- Implement the application and verify its business logic.
- Independently test the candidate and resolve QA findings.
- Prepare and review the infrastructure and operational configuration.
- Deploy the approved candidate to staging and verify the result.
- Obtain production authorization, deploy within scope and verify live behavior.
These stages are connected, not strictly sequential. DevOps can prepare an authorized preview environment while engineers build. QA can challenge acceptance criteria before implementation. What must remain controlled is the identity of the candidate, the evidence supporting each decision and the authority to make the next change.
Who is responsible for each delivery decision?
The teams contribute to one application, but their responsibilities are not interchangeable:
- AI engineering owns the specification, architecture, implementation, developer verification and fixes. Its handoff is an identifiable candidate with test results and known gaps.
- Independent AI QA owns its assessment, evidence and staging-handoff decision. It approves or rejects the tested candidate against agreed criteria and independently retests fixes.
- AI DevOps owns the environment plan, authorized infrastructure configuration, deployment execution and operational verification. Its handoff records what is running, where it is running and what was checked.
- The authorized human owner resolves consequential product decisions, approves production changes within the applicable policy and accepts or rejects documented risks. Team completion messages do not grant that authority.
1. Turn the application idea into testable rules
A useful brief describes the user outcome before prescribing the technology.
For our example, a company wants employees to submit purchase requests, managers to review them and finance to see a reliable approval history. The real work starts with questions that code generation cannot responsibly answer by guessing:
- Can a requester approve their own request?
- Can a manager see requests from another organization?
- Which purchases need additional finance approval?
- What happens if an approved request changes?
- What should happen when a user submits the same action twice?
The product owner resolves these decisions with engineering. The specification records roles, permitted actions, state changes, exception paths and acceptance criteria. Unresolved business rules remain explicit blockers or bounded assumptions awaiting a decision.
For this fictional application, suppose requests above $1,000 need finance approval, requesters cannot approve their own purchases, and editing an approved amount invalidates that approval. Exactly $1,000 is a boundary the specification must address explicitly.
Those rules provide a stronger foundation than an instruction to build a dashboard with a form and an approve button.
2. AI engineers design, build and check the application
An AI Engineering Team can coordinate application architecture, client interfaces, backend services, data changes, developer tests and code review around a shared specification.
For the purchase-request application, engineering needs more than a working screen. The design must connect identity, organizational boundaries, request states, approval authority, persisted records and any background notifications.
Engineering should divide the work into scoped tasks with explicit contracts. The interface and API must agree on what a state means. The database must enforce the constraints it owns. Background workers must handle retries without repeating consequential effects. Secrets belong in approved configuration systems, not source code.
Verify business logic, not just successful execution
A successful build proves that certain build steps completed. It does not prove that a user is allowed to approve a purchase or that an edited request loses its old approval.
Developer verification should cover the rules directly:
- Boundary cases: check values below, at and above the approval threshold.
- Authorization: reject self-approval and cross-organization access at the server, not only in the interface.
- State transitions: reject invalid actions, such as approving an already cancelled request.
- Changed information: ensure approval applies to the reviewed request version, not a later edit.
- Repeated actions: check that retries do not create duplicate approvals or duplicate downstream work.
- Concurrent actions: verify that conflicting updates cannot silently overwrite each other's decisions.
Use unit tests for isolated rules and relevant integration or contract tests for behavior across components. Code review should challenge the design, access controls and tests themselves. A reviewer repeating the implementation's assumptions is not independent confirmation of the business requirement.
Engineering owns fixes and developer checks. It then produces an identifiable candidate with its specification, revision, build references, test results and known gaps.
3. Independent AI QA approves or rejects the candidate
The AI QA Team has a different responsibility from engineering: evaluate whether the candidate satisfies the specification and whether important risks have been investigated.
Independent QA is a separate assessment, not necessarily a different model provider. It requires its own test design, evidence and decision rather than accepting the coding agent's completion message.
QA should combine risk-led checks across the interface, API and relevant data behavior in an authorized test environment. Use approved synthetic accounts and data. Missing access or unavailable dependencies must remain visible, not disappear into a passing summary.
In our example, imagine the interface hides self-approval correctly, but the API still accepts it. The application looks right during a demonstration while violating the business rule. QA records the candidate, preconditions, expected and actual behavior, reproduction steps and sanitized evidence, then rejects the staging handoff.
Engineering fixes the defect and checks the implementation again. QA independently retests the new candidate and relevant neighboring behavior. Earlier failures remain in the record; a passing retry does not erase them.
What does AI QA approval mean?
AI QA approval means that the identified candidate meets the agreed criteria for staging handoff, subject to recorded exclusions and residual risks. The decision must identify the revision or artifact and the evidence it relies on.
That approval does not automatically cover a later revision, a materially changed configuration or an untested environment. Changes that invalidate the evidence need renewed assessment and relevant tests. QA approval is neither a security certification nor permission to release to production; production authorization remains a separate human decision.
For detailed test outcomes and evidence requirements, see our guide to independent AI QA testing.
4. AI DevOps configures infrastructure around application needs
Infrastructure is part of the application design, not a place to upload code after testing finishes.
The AI DevOps & MLOps Team describes responsibilities spanning cloud environments, operational delivery, verification and recovery. In a practical workflow, DevOps translates the application's requirements into a reviewable environment plan.
For the purchase-request application, that plan might include an application runtime, a database, background processing, secret management, network boundaries, domain and TLS configuration, monitoring and backups. The actual services depend on the workload; not every application needs containers, Kubernetes or a queue.
Start with explicit requirements for data sensitivity, expected load, availability, recovery and cost. Then record:
- Environment boundaries and scoped service identities.
- Required resources, configuration references and dependencies.
- Database migration and application compatibility requirements.
- Health checks, logs, alerts and an operational owner.
- Backup, restore and recovery procedures that match the data risk.
- Expected resource costs, limits and review triggers.
Where infrastructure as code is appropriate, retain the configuration revision and review the proposed changes before applying them. A reviewed plan is not blanket approval for a different environment or a changed plan. Plans can also contain sensitive values and need controlled handling.
The team can provision authorized preview or QA infrastructure earlier in the project. Application QA approval and infrastructure-change approval are different decisions: neither automatically grants the other. Production infrastructure changes retain their own human authorization and validation requirements.
5. Deploy the approved application to staging and verify it
After the QA handoff, DevOps deploys the identified candidate into the intended staging environment under the configured permissions.
Preserve the connection between the tested application and what is deployed. Prefer promoting an identifiable artifact rather than rebuilding something different after review. Record environment-specific configuration without copying secrets into the release report.
Staging verification should establish that the application starts, reaches its dependencies and supports important workflows. For our example, a synthetic employee submits a request, an authorized manager reviews it, the finance rule is enforced and the approval history remains consistent.
This catches problems that developer tests alone may not expose: a missing permission, an incorrect environment variable, a failed migration or a worker that cannot access its queue.
A useful staging handoff includes the URL, deployed revision or artifact, configuration references, verification results, outstanding findings and a named review owner. Failed verification blocks progression. Changes that alter the candidate or invalidate earlier evidence require renewed review and relevant testing before another handoff.
6. Authorize production separately, then verify live behavior
Staging is evidence for a production decision, not automatic permission to make it.
An authorized human reviews the candidate, QA findings, staging results, infrastructure changes, rollout scope and recovery readiness. Approval should name the target and the specific change; it should not become ambient permission for future modifications.
DevOps then executes within that authorization. Depending on the application, the rollout may be gradual or use another bounded deployment method. The team needs agreed conditions for pausing, escalating or using an explicitly authorized recovery action.
Production verification checks the running version, service health and important user outcomes. A green deployment command does not show that purchases can be submitted correctly or that the approval worker is functioning. Use privacy-safe operational signals and tightly scoped synthetic checks where authorized; do not create real purchases merely to prove the system works.
Recovery also needs engineering judgment. Rolling back an application does not necessarily reverse a database migration or an external action. Check compatibility and recovery evidence before treating an earlier version as a safe escape route.
Our staging-to-production deployment guide covers the operational verification record in more detail.
One delivery record keeps the teams connected
The most useful output is not three independent messages saying that engineering, QA and DevOps have finished. It is a connected record that lets the next owner understand what was decided and what actually happened.
Keep these references together:
- Product intent, resolved business rules and specification version.
- Engineering tasks, candidate identity, developer checks and review findings.
- Independent QA coverage, evidence, defects, retests and staging decision.
- Infrastructure configuration, reviewed changes and environment permissions.
- Staging deployment identity, access details and verification results.
- Human production authorization and approved rollout scope.
- Production verification, outstanding risks, recovery criteria and ownership.
Permission should follow the work. A QA agent does not need production deployment authority to investigate a defect. A deployment agent does not gain permission to change product requirements. WorkOff's security and governance approach describes the budgets, tool policies, sandboxes, traces and human approvals that help define those boundaries.
From AI-generated code to an application people can use
The purpose of an end-to-end AI development workflow is to carry a product idea through accountable delivery, not to remove every human decision.
Engineering turns the idea into a specification and implementation, then verifies its logic. Independent QA challenges the candidate and returns defects for fixes. DevOps prepares the environment, deploys the approved application and verifies the result. People retain consequential product decisions and production authority.
WorkOff brings these roles into a shared human-and-agent workspace. Its public team pages describe the coordinated workflow; supported tools, environments and available execution capabilities should be confirmed for your workspace rather than inferred from this example.
To plan a bounded first application or feature, talk to WorkOff. Bring the user problem, the business rules you already know and a person who can resolve the decisions that remain.
