From SDLC to SAIDLC:Rethinking Software Development in the Age of AI

Software development has changed considerably over the years. What began as a relatively structured process of gathering requirements, writing code, and delivering applications has expanded to include continuous integration, automated testing, security engineering, and, more recently, artificial intelligence.

Most developers are already familiar with the Software Development Life Cycle (SDLC). It provides a practical way to organize development activities, from requirements gathering to maintenance. As security threats became a greater concern, organizations began incorporating security practices throughout development, leading to wider adoption of the Secure Software Development Life Cycle (SSDLC).

Now, AI is influencing how developers perform those same activities. Coding assistants can generate implementations, suggest architectures, write tests, and help investigate defects. More advanced AI agents can complete multiple development tasks with relatively limited human intervention.

This has led to growing interest in the AI-Driven Development Life Cycle (AIDLC), an approach that incorporates AI into the development process itself.

But AI-assisted development introduces risks that existing workflows may not fully address. Generated code can contain vulnerabilities, agents may receive excessive permissions, and teams may struggle to verify changes produced at machine speed.

These concerns provide a reason to explore what I refer to in this article as the Secure AI-Driven Development Life Cycle (SAIDLC), a proposed approach that combines AI-driven development with established secure software engineering practices.

1. SDLC: Establishing a development process

The Software Development Life Cycle defines the activities involved in building and maintaining software. Its purpose is to give development teams a consistent process for transforming business requirements into working applications.

A typical SDLC covers requirements analysis, system design, implementation, testing, deployment, and maintenance.

During requirements analysis, the team identifies what the system needs to accomplish. These requirements guide architectural decisions, including database design, application components, and external integrations.

Implementation follows, with developers translating approved designs into working code. Testing helps verify that the application behaves as expected before deployment. Once released, the system enters maintenance, where defects are addressed and new requirements are incorporated.

Different development methodologies organize these activities differently. Waterfall follows a more sequential structure, while Agile approaches allow teams to revisit requirements and deliver improvements iteratively.

SDLC is flexible enough to support either approach.

However, the existence of a development lifecycle does not guarantee that security requirements will receive sufficient attention. A team can follow a structured process and still produce software with insecure authentication, excessive permissions, or vulnerabilities introduced through third-party dependencies.

Security must be incorporated deliberately.

2. SSDLC: Building security into development

The Secure Software Development Life Cycle extends conventional development practices by incorporating security activities throughout the lifecycle.

Security considerations begin during requirements gathering, when the team identifies sensitive information, access restrictions, and applicable compliance obligations.

During system design, developers and security engineers examine how information moves between components. Threat modeling helps identify possible attack paths and weaknesses in trust boundaries.

Implementation includes secure coding practices, dependency management, and code review. Testing adds security-focused checks such as static application security testing (SAST), dynamic application security testing (DAST), software composition analysis (SCA), and penetration testing where appropriate.

Deployment also introduces security responsibilities. Teams must review configuration settings, manage credentials, restrict access to production resources, and protect the release pipeline.

These activities continue after deployment through vulnerability monitoring, incident response, and patch management.

The NIST Secure Software Development Framework (SSDF) provides an established reference for organizing secure development practices. OWASP also publishes guidance that teams can apply to specific application security concerns.

One important characteristic of SSDLC is that security becomes part of normal engineering work. Developers can identify potential problems before they reach production, when remediation is often more difficult.

This approach remains relevant even as development tools change.

3. AIDLC: When AI becomes part of the development process

AI coding assistants have changed how developers approach everyday tasks. Instead of manually writing every component, developers can ask AI systems to propose implementations, generate repetitive code, or prepare an initial set of tests.

The AI-Driven Development Life Cycle takes this idea further by incorporating AI across multiple development activities.

AWS introduced an AI-DLC methodology in 2025, describing a process organized around three broad phases: Inception, Construction, and Operations.

Inception covers the early development activities, where AI can assist in analyzing business needs, refining requirements, and identifying work that needs to be completed.

Construction focuses on architecture, implementation, and testing. AI systems contribute development artifacts, while human engineers review decisions and verify the resulting work.

Operations addresses deployment and the ongoing management of applications, where AI may assist with infrastructure tasks, monitoring, and troubleshooting.

The extent of AI involvement depends on the tools and controls an organization chooses to adopt.

For example, a developer working on an ASP.NET Core application might use an AI assistant to generate a controller, service implementation, and unit tests based on existing project patterns.

A more autonomous development agent might examine the repository, identify related components, modify several files, execute tests, and propose changes for review.

Both workflows use AI, but the second introduces a larger degree of delegated execution.

Where AI-driven development becomes difficult

AI-generated code is not inherently reliable. An implementation may compile successfully and pass basic tests while still containing authorization flaws or incorrect assumptions about business rules.

Consider an application that restricts access to employee information based on organizational assignments.

An AI system may correctly implement authentication while overlooking a requirement that users can only retrieve records belonging to their authorized office.

From a functional perspective, the endpoint may work. From a security perspective, the missing authorization check could expose sensitive information.

Autonomous agents introduce additional concerns. A tool with repository access may modify files outside its intended task. Access to a terminal, cloud environment, or database can increase the consequences of an incorrect action.

Prompt injection is another consideration. Instructions embedded in untrusted repository files, documentation, or external content may attempt to influence an agent's behavior.

These risks do not make AI-driven development impractical. They show why organizations need controls that match the authority granted to AI systems.

4. SAIDLC: A proposed approach to secure AI-driven development

The Secure AI-Driven Development Life Cycle (SAIDLC) is a proposed way of applying secure development practices to workflows in which AI participates directly in software engineering activities.

The term is used here as a conceptual model, rather than as an established industry standard.

The approach draws on three existing areas of practice:

• SDLC provides the structure for development activities.
• SSDLC incorporates security requirements and verification throughout those activities.
• AIDLC introduces AI-supported planning, implementation, testing, and operations.

In SAIDLC, these practices are applied together. AI tools operate within defined boundaries, generated outputs are subject to appropriate verification, and human engineers remain accountable for consequential development decisions.

The proposed lifecycle can be organized into six phases.

Phase 1: Secure requirements and planning

AI can help analyze business requirements, identify missing information, draft specifications, and organize development tasks.

Before using an AI system, the team needs to determine which information can be shared with it. Internal source code, employee records, credentials, and confidential business information may be subject to organizational restrictions.

Security requirements should also be defined early enough to influence implementation.

For an HR management system, these might include role-based access control, organizational data restrictions, audit logging, and protection of personally identifiable information.

AI can assist in drafting these requirements, but their accuracy and completeness require review by people familiar with the system and its operating environment.

Phase 2: Secure system design

During design, AI can propose architectures, database relationships, API contracts, and integration patterns.

The development team evaluates these proposals against system requirements and security constraints.

Threat modeling is particularly useful at this stage. It helps identify which components handle sensitive information, where trust boundaries exist, and how an attacker might exploit weaknesses.

When AI functionality is part of the application, the team may also need to consider model access, prompt injection, data leakage, and the permissions available to AI-connected tools.

Architecture approval remains a human responsibility, supported by technical analysis and security review.

Phase 3: Controlled AI-assisted implementation

Implementation is where AI-generated code becomes part of the project.

Developers may use AI to create new components, refactor existing services, generate migrations, or investigate defects.

The degree of control depends on the task. Low-risk changes may require ordinary code review and automated testing, while changes involving authentication, authorization, financial transactions, or sensitive data may require additional review.

AI agents should receive only the permissions necessary for their assigned work. Repository protections, restricted execution environments, and approval requirements can reduce the impact of unintended actions.

Generated code should meet the same coding standards and review requirements as human-written code.

Phase 4: Security and quality verification

AI-generated implementations need independent verification.

Functional testing establishes whether the implementation satisfies expected behavior. Security testing examines whether it introduces vulnerabilities or violates established security requirements.

Automated checks may include static analysis, dependency scanning, secret detection, dynamic testing, and configuration validation.

AI can help generate test cases and interpret findings, but relying exclusively on AI-generated tests creates a risk that the same incorrect assumptions will appear in both the implementation and its tests.

For sensitive functionality, teams should develop independent security test cases based on approved requirements and identified threats.

For example, an employee records API should be tested with users from different offices to confirm that authorization restrictions are enforced even when valid authentication credentials are provided.

Phase 5: Secure deployment

Deployment introduces another set of risks, especially when AI agents can interact with infrastructure or delivery pipelines.

Before release, teams should verify the application build, dependencies, configuration, access permissions, and deployment artifacts.

Production changes should follow established approval procedures. AI may prepare deployment scripts or analyze failed releases, but its authority to execute changes should be limited according to operational risk.

Changes affecting production credentials, sensitive databases, or security controls deserve stronger approval requirements.

Phase 6: Monitoring and continuous improvement

Once the application is deployed, operational monitoring helps identify defects, security incidents, and unexpected behavior.

Teams should maintain sufficient records to investigate significant changes, including those proposed or executed by AI agents.

Findings from incidents and security reviews should inform subsequent development work. They may also reveal gaps in agent instructions, tool permissions, testing practices, or human review procedures.

SAIDLC therefore remains an iterative process. Its controls can be adjusted as the organization gains experience with AI-assisted and autonomous development.

5. How the four approaches compare

These approaches overlap.

An organization may already follow SSDLC practices while introducing AI coding assistants. It may also adopt an AIDLC methodology without abandoning its existing development and security controls.

SAIDLC provides a way to organize these overlapping responsibilities when AI plays a substantial role in development.

6. Applying SAIDLC to an enterprise application

Consider a government organization developing a Human Resource Management Information System.

The application manages employee profiles, recruitment information, performance evaluations, and payroll records. It serves users with different responsibilities and levels of access.

In an ordinary SDLC workflow, developers gather requirements, design the system, implement the modules, test functionality, and prepare deployment.

Under SSDLC, the team incorporates security requirements such as access restrictions, audit trails, secure authentication, and protection of employee information.

With AIDLC, developers may use AI to generate application services, frontend components, database queries, documentation, and automated tests.

Suppose an AI agent is assigned to implement an endpoint that retrieves employee records.

The agent produces a working endpoint, and the application passes its basic functional tests. However, the implementation only checks whether the requesting user is authenticated. It does not verify whether the user has permission to view the requested employee's record.

The implementation is functionally operational but violates the system's authorization requirements.

Under the proposed SAIDLC approach, the development process would include controls specifically intended to detect this type of problem.

The agent would receive the relevant security requirements before implementation. Its proposed changes would be checked against the application's authorization architecture, and independent tests would attempt to access employee records using accounts with insufficient permissions.

The implementation would also undergo appropriate review before being merged and deployed.

These controls cannot guarantee that every vulnerability will be found. They provide multiple opportunities to identify a failure before it affects production users.

7. What changes for software engineers?

As AI tools take on more implementation work, developers need to become increasingly effective at evaluating generated results.

Code review remains important, but engineers also need to understand how AI tools receive context, which tools they can execute, and what permissions those tools possess.

Requirements engineering becomes particularly important because incomplete instructions can produce implementations that appear correct while overlooking business constraints.

Security engineers also have additional responsibilities. They need to assess the risks introduced by AI development tools alongside the vulnerabilities that may exist in the applications being produced.

Development teams may need policies covering approved AI tools, data sharing, agent permissions, automated execution, and the retention of development records.

Existing engineering disciplines remain useful. Architecture review, version control, automated testing, secure coding, and change management provide much of the foundation needed to manage AI-generated work.

8. From a concept to an engineering framework

For SAIDLC to become useful beyond a conceptual model, it needs defined controls and measurable outcomes.

A practical implementation could establish required artifacts and release criteria for each phase.

During requirements analysis, teams could require documented security constraints and data-handling rules. During design, they could require threat models for sensitive components.

Implementation controls could include restricted agent permissions, mandatory peer review, and protected branches.

Verification could require successful functional and security tests, with defined procedures for handling unresolved findings.

Deployment controls could specify which activities agents may perform autonomously and which require explicit approval.

Organizations could measure the effectiveness of these controls through indicators such as security defects discovered before release, unauthorized changes prevented, remediation time, and compliance with code review requirements.

These measures would help determine whether introducing AI improves delivery without creating unacceptable security risks.

Conclusion

SDLC remains the foundation for organizing software development. SSDLC strengthens the process by incorporating security practices throughout the lifecycle. AIDLC introduces AI as an active contributor to development activities.

As teams adopt AI agents capable of modifying repositories, executing commands, and preparing releases, they need to account for the risks associated with those capabilities.

The proposed Secure AI-Driven Development Life Cycle combines established security practices with controls for AI-assisted development. Its practical value will depend on how clearly those controls are defined, implemented, and measured.

AI can reduce the effort required to produce software, but engineers still need reliable ways to determine whether the result satisfies business requirements and security expectations.

References

1. National Institute of Standards and Technology. Secure Software Development Framework (SSDF), SP 800-218.
2. National Institute of Standards and Technology. Secure Software Development Practices for Generative AI and Dual-Use Foundation Models, SP 800-218A.
3. Amazon Web Services. AI-Driven Development Life Cycle.
4. OWASP. Artificial Intelligence Security Verification Standard.