AI-assisted development lifecycle: requirements, evidence and release authority
Define controls for AI-assisted requirements, code, review, testing and operation. Keep generated proposals separate from release authority and evaluate outcomes using actual defects and recovery evidence.
TL;DR: AI-assisted development needs the same accountable requirements, verification and release decisions as other software work. Give tools bounded authority and require evidence independent of the generated proposal before accepting a change.
Define where AI assists the development workflow
AI-assisted development is the workflow in which AI tools help turn requirements into code and operational changes. The agent development lifecycle (ADLC) instead concerns building and operating an agent itself; its dedicated explanation covers task contracts, tool behavior and release evaluations. Both workflows still require an accountable software development process.
A useful interview answer names where assistance occurs and what evidence permits the next decision. “The agent writes and tests everything” leaves unanswered who defines correctness, which tools it may run and whether it can approve its own deployment.
NIST's Secure Software Development Framework provides a general secure-development reference. Its generative-AI community profile addresses AI-related software development practices; do not describe that profile as a certification for an individual coding assistant.
Separate proposals from authority
Independence means the checks can reject the proposal for reasons outside its own assumptions. A test generated from an incorrect requirement interpretation can agree perfectly with incorrect code. Add explicit invariants, known regressions and adversarial cases defined by the system owner.
Worked example: generated Terraform changes
Suppose an assistant is asked to reduce database costs. It proposes a smaller instance, shorter backup retention and deletion of a replica. The diff is syntactically valid and a plan can be produced, but the requirement never authorized reducing recovery capability.
Write acceptance conditions first: preserve the recovery objective, required availability and retention policy while evaluating cost alternatives. Give the assistant read access to relevant configuration and sanitized measurements. Its proposal must state assumptions and identify replacements or downtime in the plan.
A reviewer then compares predicted savings with capacity evidence and failure tolerance. If the proposed replica deletion violates the availability requirement, reject it even if all generated tests pass. The implementation task was underspecified, and the checks need to encode the missing constraint.
This is why AI-generated infrastructure validation should examine semantic effects and target identity, not only YAML or HCL syntax. A tool producing a correct plan for the wrong environment is still dangerous.
| Stage | Evidence the owner should require | Failure the evidence should catch |
|---|---|---|
| Requirements | Concrete behavior and constraints | Tool optimizes an unapproved objective |
| Implementation | Reviewable diff and dependency changes | Hidden privilege or package expansion |
| Verification | Relevant deterministic checks and counterexamples | Tests merely repeat the generated assumption |
| Review | Responsible owner and unresolved findings | Assistant effectively approves itself |
| Release | Approved artifact, target and recovery conditions | Untested output reaches production |
| Operation | Observed regressions and service outcomes | Faster code creation hides more repair work |
Treat repository content as input
A privileged assistant may read issue comments, source files, logs or dependency metadata. Those materials can contain instructions from untrusted parties. Tool authority should come from the authorized task and enforced permissions, not from text encountered while gathering evidence.
Bound filesystem, network and credential access to the work. Use short-lived workload credentials where appropriate, and avoid exposing deployment authority to a job that evaluates an untrusted pull request. The existing confused-deputy concept explains the failure mode: a trusted tool can be persuaded to act for a less-trusted input source.
For review assistance, require a reproducible finding and a relevant code path. AI code review discusses evaluating missed defects and false positives instead of counting generated comments.
Measure delivery after acceptance
Track time to a reviewed, verified change, subsequent defects and recovery effort. Lines generated and suggestions accepted are activity measures; neither establishes service quality. Compare similar work and disclose limitations when the sample is small or the task mix changes.
Record failures where a tool's plausible output survived review, then add the missing check or reduce the tool's authority. A blanket claim that every AI change receives human review says little if reviewers lack time or evidence to challenge it.
Can the same assistant write tests for its implementation? Yes, as a useful contribution. Independent acceptance cases and qualified review must still challenge shared assumptions.
What makes an AI-assisted development improvement defensible in an interview? Describe one workflow, its permission boundary, an error the checks caught and an observed outcome. Avoid inventing productivity percentages or implying a new acronym removes ordinary engineering responsibility.