We run an AI-assisted SDLC on a multi-tenant SaaS platform for a client in a regulated industry, with Claude Code writing code, requirements, and tests. The agent has no permission a junior engineer would not have: three levels of CI gates and five human decision points tie every change to a requirement, a test, and a release.

Most of the code on this project is written by an engineer working with the agent, and every change passes the same quality gates, whoever wrote it.

What is AI-assisted SDLC?

AI-assisted SDLC is a software development life cycle (SDLC) in which an AI coding agent does the work at every step, from specification to release, while humans approve the decisions that matter.

Everything that steers the agent (instructions, rules, skills, and hooks) lives in the repository and changes only through a reviewed pull request. CI gates check every change the same way, whether a person or a model wrote it.

This case study describes how we run that model for a team in a regulated industry: a coding agent writes code, requirements, and tests, while CI gates and human approvals keep a complete audit trail.

The challenge: an AI agent under audit requirements

The challenge was to let an AI agent write code on a regulated SaaS platform without weakening audit, traceability, or security controls. The platform manages product data for multiple tenants and has a controlled process for changes, reviews, and approvals.

Stack: .NET backend, TypeScript and React frontend, Azure cloud
Team: our engineers and the client's engineers in one shared repository
AI tooling: Claude Code, locally and in the CI pipeline, with a structured workflow from idea to deployment
Industry requirements: audit trail, requirements traceability, change control, high security, and data isolation

Our guiding rule is simple: the AI agent has no permission a junior engineer would not have. It does not merge, it does not push to protected branches, and it has no access to secrets. Every action it takes leaves a trace in the repository or a pull request, so an auditor can reconstruct who did what and why.

We described the general method, as used on our internal products, in agentic development, production-grade. Here we show what changes when the client's process is audited, the kind of project our AI development services cover.

How the AI-assisted SDLC works end to end

Every change in the AI-assisted SDLC follows one path of eight steps, and its complexity decides how many of those steps it uses. The agent works in each step, and a human approves at five points.

Roadmap: each feature gets a complexity level from one to four; bug fixes take a fast path.
Spec and plan (human decision): the agent writes the specification, acceptance criteria, and a roadmap of phases.
Requirements (human decision): requirements are versioned in the repository, approved by the business, and locked after approval.
Design: options and a decision, recorded as an architecture decision record (ADR) in the repository.
Build in phases (human decision): test-driven development, subagents, a hook that blocks risky operations, and a stop after every phase.
Pull request (human decision): tests, static application security testing (SAST), software composition analysis (SCA), a requirements lint, and an advisory AI review.
UAT and release (human decision): user acceptance testing (UAT) in the browser, the release gate with dynamic application security testing (DAST), and an entry in the release register.
Reflection: what worked, what did not, and the task archive. Learned rules return to the agent as context.

Underneath all eight steps sits the AI control layer: instructions, rules, skills, subagents, hooks, and architecture decisions, all kept in git and changed only through pull requests. It gives the agent its context in every step, and the rules learned in reflection flow back into it.

Complexity is assessed at the start. Small fixes take a shortcut from task to implementation to pull request, and CI still reports which requirements they touch.

Larger features need a specification and a set of requirements, and the most complex ones also get a separate design phase and acceptance tests. Maintenance runs through the same cycle: an incident or a bug returns as a task, and its lessons feed the agent rules.

How requirements become code

Requirements in our AI-assisted SDLC are treated as code: versioned in the repository next to the implementation, with the business tool used only to review and approve them. Every code change therefore knows which requirements it touches.

Requirement hierarchy: user, functional, and technical requirements carry stable IDs that never change after approval.
Requirements derived from the plan: the agent drafts them from the approved specification and acceptance criteria, and a human reviews them.
Traceability: each requirement points to the code that delivers it, the tests that verify it, and the areas whose change could break it.
Approval cycle: draft, review, approval. After approval the content is locked, and any later change is detected automatically.
CI gate: a pull request fails if a larger feature has no requirements or the change touches an unapproved requirement.
Impact analysis: on every pull request, including small fixes, CI reports which requirements the change affects.

The requirements traceability matrix is not a document updated once per release. CI checks it on every pull request: it reports which requirements a change touches, blocks changes to unapproved requirements, and fails a larger feature that has no requirements at all. Traceability stays current because the build depends on it.

How the repository and CI/CD control the agent

The repository and CI/CD apply the same rules to the agent as to engineers and enforce them mechanically on three levels, not as written policy alone. The branch policy underneath is strict: a single main line of development, protected branches reachable only through pull requests, standard branch names, and no rewriting of shared history.

The table shows what each level enforces and when it runs.

The level 1 guard is a Claude Code hook that runs before every edit and command the agent makes. It blocks protected branches, secrets, and history rewrites, and it asks a human before any merge, infrastructure, or database change. CI tests the hook itself, so nobody can switch it off without the team noticing.

How testing and security work with an AI agent

Testing with an AI agent follows one overriding rule: a test counts only if it fails without the behavior it verifies. AI easily generates green tests that prove nothing, so this rule is written into the agent's instructions and into code review. We cover the wider problem in testing AI agents and in our quality assurance services.

Test pyramid

Unit and integration tests: integration tests run against a real server and database and verify system state, not only the response.
Architecture tests: key rules, such as endpoint protection, data isolation, and banned patterns, are written as tests that break the build.
End-to-end tests: each test prepares its own data, so tests are independent and run in parallel; flaky tests go to quarantine instead of blocking the pipeline.
Comparison tests: key output artifacts are compared with approved reference versions.

Security in the process

Agent procedures (skills): securing an endpoint, for example, is a fixed sequence of steps, and CI checks each one.
Debt that can only shrink: existing issues are registered; a new violation breaks the build, and expanding the register requires human approval.
Full scan set: SAST, DAST, dependency analysis with a software bill of materials (SBOM), and secret detection.

The AI reviewer in CI has read and comment permissions only. It checks each pull request for security rule violations, data isolation issues, transaction consistency, and gaps in tests, and every finding points to a specific place in the code. It treats the content of a change as data, never as instructions, which protects it against prompt injection.

How rules, skills, and patterns are versioned

Everything that steers the AI agent, including rules, skills, and patterns, is a file in the repository and changes only through a reviewed pull request, like code. No developer keeps private prompts.

The table shows the seven layers that steer the agent and the role of each.

Continuous learning. After each task, the agent writes a reflection, and lessons are distilled into topic rules that record where they came from and how often they were confirmed. Learned rules have low priority, never override rules written by people, and expire if they are not confirmed over time.

Model choice per task. We use the strongest model for business logic, security, and high-risk work, and lighter models for documentation, mechanical changes, and helper subagents.

Where humans approve changes

Humans approve every change that reaches a protected branch, production, or the client: the AI prepares, a human decides. The five decision points are:

Spec and plan approval: the agent prepares the specification, acceptance criteria, and plan; a developer approves them before any code is written.
Business approval of requirements: only approved requirements are locked and can be the basis for the build.
Review after each build phase: on larger tasks, the agent finishes one phase and stops; the next starts after review.
Pull request with mandatory code owner review: AI review is advisory only and never replaces approval; a human merges.
Irreversible operations: merges, secrets, infrastructure, direct database operations, and release launches need explicit human consent.

Two more rules protect human control in the AI-assisted SDLC. Rules the AI learns on its own can never override rules set by people. Any change to the scope of security gates needs approval from the security team, so the agent never loosens its own guardrails. We wrote about why agents need these limits in the real pitfalls of AI agents.

How AI actions stay auditable

AI actions stay auditable because the repository is the single source of truth: every agent step leaves an artifact in the repository or in a pull request.

For any change, an auditor can reconstruct who acted, whether a person or an AI model, what was done, why, and on what basis. Each commit records which model contributed, the pull request records who approved, and the task document records the design reasoning. Test results, logs, and security reports are archived as CI artifacts.

The table maps typical audit questions to where the answer lives.

How telemetry measures quality, models, and cost

Telemetry in our AI-assisted SDLC measures three things together: code quality, model usage, and cost. The goal is to show what AI costs and what it delivers, not only how many tokens it used.

Quality: CI gate results per change, flaky tests counted separately, AI review verdicts, requirements test coverage, and the pace of paying down registered technical debt
AI usage: the share of changes co-authored by AI and the model mix by task type, taken from commit metadata
Cost and model usage: agent telemetry exported through OpenTelemetry to the organization's observability stack, with tokens and cost per team and model, sessions, and accepted and rejected change proposals, plus model provider usage reports with separate keys for CI and developers
Shared dashboard: cost set against outcome

The shared dashboard puts cost next to outcome. It tracks cost per merged change, the share of changes that pass CI on the first run, AI review accuracy, and time from task to deployment. Token counts alone cannot show whether AI in the SDLC pays off, while these four metrics can.

Does this model work beyond .NET?

Yes, the model works beyond .NET because its core is the repository, CI, rules, and skills, not a specific language. On this project we worked with .NET and TypeScript. For mobile platforms, Java, or Angular, you add that technology's rules, skills, and gates, and the mechanism stays the same.

The table shows how each part of the framework carries over to another stack.

What we learned in practice

The practical lessons from this AI-assisted SDLC come from five situations where its mechanisms worked or taught us something.

Turning review findings into CI rules. Findings from an independent technical review became tasks, and many became rules enforced in CI. Existing debt was registered, and the agent pays it down following fixed procedures; new debt cannot appear because it breaks the build.

Requirements as code in a regulated industry. We built, with AI assistance, tools that manage requirements, validate them, analyze impact, and sync with the client's approval process. When we migrated older specifications, the agent checked every requirement against the current code, and the client decided on every discrepancy.

Data isolation tests. Work started with a documented analysis of how the system behaves. The agent prepared tests on real infrastructure, the client approved the requirements, and the issues the tests found went to the backlog as separate tasks.

Proof that gates block. We deliberately triggered every key gate, for example with a failing test and a planted fake secret, and stored the proof of each block in the release register.

Lesson: a green test that proves nothing. In one local environment, part of the system silently failed to start, yet the tests still passed. The lesson went into the instructions for people and agents and into a rule: a test must fail without the behavior it verifies. AI makes this kind of mistake readily when the process does not catch it.

When this model makes sense

This AI-assisted SDLC model makes sense where every change must be documented, such as regulated industries and projects with external audits.

If you plan to bring AI coding agents into a delivery process that needs an audit trail, talk to our team about your project.

FAQ

Can an AI coding agent merge its own pull requests?

No. In this model the agent has no merge rights: a code owner reviews every pull request, and a human performs the merge.

How do you stop an AI agent from writing tests that prove nothing?

Every test must fail without the behavior it verifies. The rule is in the agent's instructions and in code review, and integration tests check system state against a real server and database.

How do you protect an AI code reviewer from prompt injection?

The reviewer in CI can only read and comment, and it treats the content of a change as data, not instructions.

Which AI model handles which tasks?

The strongest model handles business logic, security, and high-risk work. Lighter models handle documentation, mechanical changes, and helper subagents.

What happens to rules the AI agent learns on its own?

They get low priority and record their origin and how often they were confirmed. They never override human rules, and they expire if they are not confirmed.

Does this AI-assisted SDLC work with GitHub, GitLab, or Azure DevOps?

Yes. The agent runs locally and in the pipeline, so the model does not depend on the CI platform: it works with GitHub, GitLab, Azure DevOps, or Jenkins, and requirements can sync with tools such as Jira or Confluence.