AI-Assisted SDLC and Integrated Industry Practice

Introduction

Artificial intelligence is changing how software is specified, designed, built, tested, released, operated and improved. Generative AI systems can produce text, code, diagrams and test cases; coding assistants can predict implementation details; intelligent testing tools can identify likely defects; AIOps platforms can correlate operational events; and autonomous development agents can perform multi-step tasks. These capabilities do not eliminate the Software Development Life Cycle (SDLC). Instead, they alter the distribution of work, introduce new controls and increase the importance of human judgement.

An AI-assisted SDLC combines established engineering practices with machine-supported analysis and automation. The central professional principle is augmentation rather than blind replacement: people remain accountable for business value, safety, legality, security, accessibility and the consequences of deployed software.

This chapter examines AI applications across the SDLC and integrates them into a practical team project. It also evaluates risks including inaccurate outputs, insecure code, privacy violations, bias, intellectual-property concerns, excessive automation and loss of human capability.

Learning Objectives

After studying this chapter, a learner should be able to:

1. Explain how generative AI and coding assistants support each SDLC phase.
2. Distinguish assistive, automated and autonomous development activities.
3. Apply AI-supported requirements analysis, coding, testing, deployment and operations.
4. Evaluate low-code platforms, platform engineering and AIOps in context.
5. Identify technical, ethical, legal, security and managerial risks.
6. Design suitable human approval points and governance controls.
7. Participate in an integrated team project using the complete SDLC.

1. AI in the SDLC

The SDLC is a managed sequence of activities through which a need becomes a maintained software product. Common activities include discovery and requirements, planning, design, implementation, verification, deployment, operations and retirement. Agile teams may perform these activities iteratively rather than in a single pass.

AI may assist with:

• summarising interviews and identifying conflicting requirements;
• generating user stories, acceptance criteria and questions;
• proposing architectures, interfaces and data models;
• producing code, documentation and infrastructure definitions;
• generating tests, synthetic data and defect hypotheses;
• detecting anomalies in logs, metrics and traces;
• recommending remediation actions; and
• supporting release notes, knowledge bases and user support.

The quality of an AI-assisted activity depends on the quality of its context, the suitability of its model, the verification process and the consequences of error. A fluent response is not evidence of correctness. AI-generated content should therefore be treated as a candidate artefact requiring review.

A useful classification is:

Autonomy should increase only when the task is well specified, reversible, observable and low risk. Production database changes, safety-critical decisions and handling of sensitive personal data normally require stronger human control than formatting documentation or creating a draft unit test.

2. Generative AI and Coding Assistants

Generative AI models learn statistical relationships from training data and generate outputs in response to prompts and context. In software development, a coding assistant may complete a function, explain an unfamiliar module, translate between programming languages, propose regular expressions or draft a test.

Effective use requires more than writing a clever prompt. The developer should provide relevant repository conventions, interfaces, constraints, examples and acceptance criteria while excluding secrets and unnecessary personal data. The result should be inspected for compilation, logic, security, performance, maintainability and licensing implications.

A practical prompting pattern is:

1. Role and task: state the engineering task.
2. Context: identify the relevant domain, interfaces and existing behaviour.
3. Constraints: specify language version, security requirements, performance limits and style.
4. Evidence: provide tests, schemas or representative examples.
5. Output format: request a patch, explanation, test plan or decision record.
6. Verification: ask for assumptions and edge cases, then independently test the result.

For example, a request to “write a login function” is incomplete. A stronger request identifies the authentication protocol, password-storage policy, failure behaviour, rate limits, audit requirements and expected tests. Even then, the output remains a proposal.

Coding assistants can create several risks. They may reproduce vulnerable patterns, invent APIs, omit error handling or generate code whose licence is incompatible with a project. They may also encourage developers to accept code they do not understand. Teams should require code review, dependency scanning, secret scanning, static analysis and tests regardless of whether code was written by a person or generated by a model.

3. AI-Assisted Requirements Engineering

Requirements work is especially suitable for AI assistance because it involves large volumes of natural language. AI can transcribe interviews, cluster feedback, identify duplicate requests, extract actors and goals, suggest acceptance criteria and flag ambiguous terms such as “fast,” “secure” or “user-friendly.”

However, requirements express stakeholder intent, not merely linguistic patterns. An AI system cannot independently decide which stakeholder has authority, whether a proposed feature is lawful or what trade-off the organisation should accept. Product owners and domain experts must validate interpretations.

A useful requirement record includes:

• a unique identifier;
• the stakeholder or source;
• the business or user need;
• functional or quality requirement type;
• acceptance criteria;
• dependencies and assumptions;
• priority and rationale;
• privacy, accessibility and security implications; and
• traceability to design, code, tests and release evidence.

AI can support traceability by linking a user story to design elements and tests, but automated links may be plausible rather than correct. A reviewer should confirm that every high-risk requirement has an appropriate verification method.

Requirements quality example

Suppose an AI-generated requirement states: “The system shall quickly display reports.” This is ambiguous. A refined requirement might state: “For a report containing up to 50,000 records, the 95th-percentile response time shall not exceed 3 seconds under the agreed test workload.” The revised statement defines a measurable condition, population and performance metric. The team must still specify the environment, workload and measurement method.

AI can also support threat modelling. Given an architecture diagram and data-flow description, it may propose threats such as unauthorised access, injection, insecure direct object references or denial of service. These are hypotheses for security specialists to validate, not proof that the system is secure.

4. AI in Design and Implementation

During design, AI can compare architectural options, generate interface contracts, produce data-model alternatives and identify coupling or single points of failure. A design decision should nevertheless record the chosen option, alternatives considered, assumptions, consequences and approval authority.

In implementation, AI-generated code is most reliable when the task is narrow and surrounded by tests. Useful patterns include:

• generate a small function, then run unit tests;
• ask for tests before implementation to clarify behaviour;
• request a code explanation and inspect every external call;
• use static analysis and dependency checks;
• compare generated code with project standards; and
• make small, reviewable commits.

AI should not be used to conceal technical debt or bypass engineering controls. Generated code can increase output volume while reducing understanding, producing a maintenance burden sometimes called “code at the speed of suggestion.”

5. Intelligent Testing and Quality Engineering

AI-supported testing includes test generation, mutation-test selection, visual comparison, flaky-test detection, failure classification, prioritisation and defect prediction. A testing model may examine changed files and historical failures to recommend which tests should run first. This can reduce feedback time, but it can also reinforce historical bias: a component with few recorded defects may simply have poor test coverage.

Testing remains a collection of complementary activities:

• Unit testing: verifies a small component in isolation.
• Integration testing: examines interactions between components or services.
• System testing: evaluates the complete system against requirements.
• Acceptance testing: determines whether stakeholder needs are met.
• Security testing: investigates vulnerabilities and misuse.
• Performance testing: measures behaviour under defined workloads.
• Usability and accessibility testing: evaluates human interaction and inclusive access.

AI-generated tests are valuable for breadth but may reproduce the same misunderstanding as the generated implementation. Independent test design, boundary-value analysis, exploratory testing and human acceptance remain necessary.

Coverage is useful but incomplete. If a program has 90% statement coverage, that does not mean 90% of its requirements or behaviours are correct. Teams should combine coverage with defect trends, mutation testing, requirement traceability and risk-based test selection.

6. AIOps and Intelligent Operations

AIOps applies machine learning, rules and automation to operational telemetry. Telemetry commonly includes logs, metrics and traces. An AIOps platform may normalise events, group related alerts, detect unusual behaviour, estimate probable causes and recommend or execute remediation.

A basic operational feedback loop is:

observe → analyse → decide → act → verify → learn

For example, a platform may detect increased latency, correlate it with a recent deployment, recommend rollback and verify whether latency returns to normal. The recommendation must be supported by reliable telemetry and a safe rollback mechanism. Automatic remediation is inappropriate when the model cannot distinguish a genuine incident from a data-quality problem or when the action could worsen the outage.

Important operational controls include:

• clearly defined service-level objectives;
• centralised, tamper-resistant audit logs;
• alert thresholds and suppression rules;
• access control for remediation actions;
• canary or staged deployment;
• rollback and recovery procedures;
• human escalation for high-impact decisions; and
• post-incident review.

AIOps does not replace incident management. During a serious incident, people must communicate with users, coordinate suppliers, assess legal obligations and make decisions under uncertainty.

7. Low-Code and No-Code Platforms

Low-code platforms provide visual development components, configuration and limited custom code. No-code platforms target users who may not be professional programmers. They can accelerate prototypes, departmental workflows and simple business applications.

Their benefits include faster delivery, reusable components, reduced implementation effort and wider participation. Their limitations include vendor lock-in, restricted extensibility, opaque generated code, integration constraints, data-residency issues and the creation of ungoverned “shadow IT.” A visually configured application still has requirements, security, testing, deployment and maintenance obligations.

Before adoption, evaluate:

Low-code is not automatically safer than conventional development. Its speed increases the need for architectural standards and review.

8. Platform Engineering and Internal Developer Platforms

Platform engineering creates self-service tools, templates and paved paths that help development teams build and operate software consistently. An internal developer platform may provide repositories, CI/CD pipelines, approved infrastructure modules, observability, security scanning and deployment environments.

The platform should be treated as a product. Its users are development teams; its success depends on usability, reliability, documentation and feedback. A platform team should provide safe defaults without preventing justified exceptions. Standardisation can reduce cognitive load and improve compliance, but excessive central control can become a bottleneck.

AI may assist the platform by recommending templates, explaining pipeline failures or detecting configuration drift. Nevertheless, platform permissions must be least-privilege, and generated infrastructure changes require review because a small configuration error can affect many systems.

9. Autonomous Development Agents

An autonomous development agent can interpret a goal, plan subtasks, call tools, modify files, run tests and report results. Such an agent is more than a completion tool because it maintains a task loop across multiple actions.

A safe agent design defines:

• an explicit objective and scope;
• permitted repositories, tools and commands;
• time, cost and resource limits;
• protected files and environments;
• approval gates for merging, deployment or data changes;
• a complete action log; and
• a stop, rollback and recovery mechanism.

Agents are vulnerable to ambiguous goals, prompt injection in repository content, excessive permissions and compounding errors. For example, an agent instructed to “fix all failing tests” might weaken assertions, delete tests or change expected behaviour rather than repair the defect. The acceptance criterion must therefore protect the intended outcome, not merely the visible symptom.

A useful autonomy decision considers risk, reversibility, observability and competence. Low-risk reversible actions, such as creating a draft branch, may be delegated. Irreversible actions involving production data, legal commitments or safety should require explicit human approval.

10. Governance, Ethics and Professional Responsibility

AI governance should be integrated into ordinary engineering governance rather than treated as a separate paperwork exercise. Key concerns include:

Accuracy and accountability. Models can generate false claims. A named person must own each decision and verify consequential outputs.

Privacy and confidentiality. Prompts may contain personal, confidential or proprietary information. Organisations should define approved tools, retention settings, data classifications and redaction procedures.

Security. AI can generate vulnerable code, expose secrets or follow malicious instructions embedded in data. Secure development lifecycle controls remain mandatory.

Bias and inclusion. Training data and evaluation criteria can produce discriminatory recommendations or inaccessible interfaces. Test representative user groups and provide appeal mechanisms.

Intellectual property. Teams must understand supplier terms, source-code obligations and the organisation’s policy for generated content. Legal review may be needed for high-risk outputs.

Transparency. Where AI materially affects users, organisations should communicate its role and provide appropriate human review or challenge routes.

Environmental and financial cost. Model use consumes computing resources and may create variable costs. Select a model appropriate to the task rather than assuming the largest model is best.

A lightweight AI use record can capture the tool, purpose, data classification, model output, reviewer, tests performed, decision and date. This supports reproducibility and auditability.

11. Integrated Team Project: Campus Service Request Platform

The following is an illustrative case. A college wants a platform through which students can report facilities problems, attach photographs, track progress and receive notifications. Facilities staff need triage, assignment, status changes and performance reports.

Background and problem

The existing email process loses requests, duplicates work and gives students little visibility. The project team has eight weeks, a modest budget and a requirement to protect student identity and uploaded images.

Analysis

The team identifies students, facilities coordinators, technicians, administrators and support staff as stakeholders. Key risks include unauthorised access to requests, malicious file uploads, inaccurate status information, excessive notification volume and poor accessibility.

AI is used to cluster interview notes and draft user stories, but the product owner validates each story. One approved story is: “As a student, I want to submit a facilities request with a location and description so that the appropriate team can investigate it.” Acceptance criteria include required fields, confirmation to the requester, controlled image types, an accessible form and an audit trail.

Design and planning

The team chooses a web application with role-based access, an API, a relational database, object storage for approved images and an email notification service. A threat model addresses broken access control, injection, malicious uploads, data leakage and denial of service. The team records decisions in an architecture decision log and creates a traceability matrix linking risks and requirements to tests.

An internal developer platform supplies a repository template, CI pipeline, dependency scanning, secret scanning, test execution and a non-production environment. The platform accelerates delivery but does not remove the team’s responsibility to review configuration.

Implementation

Developers use a coding assistant for small functions and test drafts. Prompts exclude real student data. Every generated change is reviewed by another team member. The assistant proposes an upload validator, but review identifies that checking only a filename extension is unsafe. The implementation is changed to validate size, content type, file signatures and storage permissions, followed by security tests.

Verification

The team performs unit, integration, system, accessibility, security and acceptance testing. AI suggests boundary cases such as empty descriptions, oversized files, repeated submissions and unauthorised status changes. Testers independently add cases for horizontal privilege escalation and notification failures. A failed test is not automatically deleted or weakened; the team investigates its cause.

Release and operation

The first release uses a canary deployment to a small internal group. Dashboards monitor request creation success, API latency, error rates, queue depth and notification failures. AIOps groups repeated errors from the image service and recommends disabling a feature flag. A human approves the action, and the team verifies recovery.

Outcome

The platform reduces lost requests and gives students visibility, while facilities staff gain a prioritised queue. The team discovers that AI accelerates drafting but does not provide reliable judgement about privacy, security or stakeholder priorities. The most valuable controls are small changes, peer review, traceability, automated checks, staged release and explicit ownership.

Learning points

1. AI value depends on sound requirements and repository context.
2. Human review should focus on risk, not merely grammar or style.
3. Generated tests increase breadth but require independent challenge.
4. Platform engineering creates consistency when it is usable and governed.
5. Observability and rollback are prerequisites for responsible automation.

12. A Practical AI-Assisted SDLC Workflow

A diploma-level team can apply the following workflow:

1. Discover: collect stakeholder evidence and classify data.
2. Define: validate requirements, acceptance criteria, risks and priorities.
3. Plan: estimate work, select tools, define responsibilities and approval gates.
4. Design: record architecture, interfaces, data flows, threats and decisions.
5. Build: use assistants for bounded tasks; review and test every change.
6. Verify: combine automated, human, security, accessibility and acceptance testing.
7. Release: use versioned pipelines, staged deployment, approvals and rollback.
8. Operate: monitor objectives, incidents, security events and user feedback.
9. Improve: analyse outcomes, update the backlog and evaluate AI performance.
10. Retire: preserve required records, migrate data safely and remove access.

At each stage, ask three questions: What may the AI do? What evidence must it provide? Who has authority to approve the result? These questions convert enthusiasm for automation into accountable engineering.

Challenges and Limitations

AI tools can increase speed while reducing visibility into how an output was produced. Model updates may change behaviour, making results difficult to reproduce. Organisations may become dependent on suppliers or lose internal expertise. Automated prioritisation can amplify historical inequities. Excessive telemetry can create privacy risks, while insufficient telemetry prevents reliable operations. Finally, the cost of reviewing poor generated content may exceed the time saved.

The appropriate response is not to reject AI or accept it uncritically. Teams should begin with bounded, measurable use cases; establish baseline performance; run pilots; evaluate defects and rework; and expand autonomy only when evidence supports it.

Chapter Summary

AI-assisted SDLC practices support requirements analysis, design, coding, testing, deployment and operations, but they do not remove the need for disciplined engineering. Generative AI and coding assistants produce candidate artefacts; intelligent testing expands test possibilities; AIOps analyses operational evidence; low-code platforms accelerate delivery; platform engineering creates safe self-service paths; and autonomous agents perform multi-step tasks within defined boundaries.

Responsible use requires appropriate context, human accountability, privacy protection, secure development, independent verification, traceability, audit logs and staged deployment. The illustrative service-request project demonstrates that AI is most effective when embedded in a complete SDLC with clear requirements, peer review, testing, observability and rollback. Professional software engineers must evaluate not only whether AI can perform a task, but whether the task is safe, explainable, reversible and governed.

Key Terms

Generative AI: AI that produces new text, code, images or other content from learned patterns.

Coding assistant: A tool that suggests, explains or transforms software code.

AI-assisted SDLC: A software life cycle in which AI supports selected engineering activities.

Autonomy: The degree to which a system can act without direct human intervention.

Prompt injection: Malicious or misleading instructions embedded in input data that manipulate an AI system.

Requirements traceability: Linking requirements to design, implementation, tests and release evidence.

Acceptance criteria: Conditions that must be satisfied for a requirement to be accepted.

Intelligent testing: Use of AI or machine learning to generate, select, analyse or prioritise tests.

AIOps: Application of analytics, machine learning and automation to IT operations.

Telemetry: Operational data such as logs, metrics and traces.

Low-code platform: A development platform using visual configuration and limited custom code.

No-code platform: A platform intended to create applications with little or no traditional coding.

Platform engineering: Designing internal tools and services that provide reliable developer workflows.

Internal developer platform: A self-service platform offering standardised development and delivery capabilities.

Autonomous development agent: An AI system that plans and performs multiple software-development actions.

Human-in-the-loop: A control arrangement requiring human review or approval within an automated process.

Canary deployment: Releasing software initially to a limited user or infrastructure segment.

Observability: The ability to understand system behaviour through its outputs, especially logs, metrics and traces.

Model drift: A change in model performance caused by changes in data, context or the environment.

Shadow IT: Technology adopted without formal organisational governance or approval.

Review Questions

Short Answer Questions

1. What is the difference between assistive, automated and autonomous AI use in software development?
2. Why must AI-generated requirements be validated by stakeholders?
3. Name three types of operational telemetry used by AIOps.
4. State two benefits and two limitations of low-code platforms.
5. Why are rollback and audit logs important for autonomous actions?

Long Answer Questions

1. Explain how generative AI can support the SDLC from requirements through operations, and identify appropriate human controls at each stage.
2. Compare coding assistants with autonomous development agents in terms of capability, risk and governance.
3. Discuss how intelligent testing can improve quality while still failing to prove that software is correct.
4. Explain the role of platform engineering in an AI-assisted delivery organisation.
5. Evaluate the ethical, privacy, security and intellectual-property responsibilities of a team using generative AI.

Analytical / Application Questions

1. A team uses an AI agent to modify production database schemas automatically after analysing user stories. Evaluate this design and propose safer approval, testing and rollback controls.
2. Design an AI-assisted SDLC workflow for a student health application. Identify at least five risks and match each risk to a mitigation.
3. An AI-generated upload component checks only file extensions and passes its unit tests. Analyse why this evidence is insufficient and propose additional verification activities.

Multiple Choice Questions with Answers

Question 1

Which statement best describes an AI-assisted SDLC?

A. A life cycle in which people are removed from all engineering decisions

B. A life cycle in which AI supports selected activities while engineering accountability remains

C. A life cycle used only for artificial-intelligence products

D. A life cycle that replaces testing with model confidence

Correct Answer: B. A life cycle in which AI supports selected activities while engineering accountability remains

Question 2

Which practice is most appropriate when using a coding assistant?

A. Commit generated code without review if it compiles

B. Provide production secrets so the model has complete context

C. Review, test and scan generated code before integration

D. Remove peer review because the model was trained on code

Correct Answer: C. Review, test and scan generated code before integration

Question 3

What is a principal purpose of requirements traceability?

A. To link requirements with design, implementation, tests and release evidence

B. To increase the number of programming languages in a project

C. To allow AI to approve all stakeholder decisions

D. To replace acceptance testing

Correct Answer: A. To link requirements with design, implementation, tests and release evidence

Question 4

Which combination represents common operational telemetry?

A. Budgets, invoices and contracts

B. Logs, metrics and traces

C. Personas, stories and prototypes

D. Classes, methods and variables

Correct Answer: B. Logs, metrics and traces

Question 5

Why can AI-generated tests be insufficient on their own?

A. They can reproduce the same misunderstanding as the implementation

B. They cannot be executed by a computer

C. They always require handwritten assembly code

D. They test only user interfaces by definition

Correct Answer: A. They can reproduce the same misunderstanding as the implementation

Question 6

Which is a major governance concern when sending project information to an AI service?

A. The keyboard layout used by developers

B. Exposure of confidential or personal data

C. The number of comments in source code

D. The colour of the integrated development environment

Correct Answer: B. Exposure of confidential or personal data

Question 7

What is the main purpose of an internal developer platform?

A. To prevent developers from using version control

B. To provide standardised self-service tools and delivery paths

C. To replace all product owners with infrastructure engineers

D. To eliminate the need for monitoring

Correct Answer: B. To provide standardised self-service tools and delivery paths

Question 8

Which action is generally most suitable for autonomous execution?

A. Irreversible deletion of production records

B. Changing a legal compliance rule without approval

C. Creating a draft branch for a bounded code change

D. Deploying an untested database migration to all users

Correct Answer: C. Creating a draft branch for a bounded code change

Question 9

What is a canary deployment?

A. A release initially made to a limited segment

B. A deployment with no rollback capability

C. A method for encrypting source code

D. A requirements elicitation interview

Correct Answer: A. A release initially made to a limited segment

Question 10

A team wants to improve an AI-generated file-upload component. Which additional control is most appropriate?

A. Validate only the displayed filename

B. Disable all tests to increase delivery speed

C. Use content validation, size limits, permissions and security testing

D. Allow every file type if the extension appears familiar

Correct Answer: C. Use content validation, size limits, permissions and security testing