Michelle DaSilva
Portfolio · Initiative

This page is password protected.
Enter the password to continue.

Don't have the password? Request access

Michelle DaSilva
Get in Touch
Back to AI Transformation
Initiative · AI Transformation · In Progress

From Software to
Agentic
Development Lifecycle.

Redefining how Product, Engineering, Data, and UX build together with AI. With my cross-functional quad, I'm defining an Agentic Development Lifecycle (ADLC) pilot that will take one real Access & Security Manager initiative from discovery to delivery using the BMAD method. It's designed to eventually replace our current software development lifecycle (SDLC).

Pilot Window
Q4 2026
One real initiative, run end to end with BMAD, while we define the pilot's scope and timeline with the quad.
Client
Leading US Bank
Role
UX Design Lead · Quad Partner
Scope
Operating Model · Enablement
Method
ADLC · BMAD
Status
Defining — Pilot Q4 2026

Overview

Changing How the Work Gets Done, Not Just What Gets Built

AI is changing how product teams work, and our delivery process hasn't caught up. Alongside my product design work on Access & Security Manager, I'm helping lead the move from a traditional software development lifecycle (SDLC) to an Agentic Development Lifecycle (ADLC). In ADLC, AI agents work with the team through discovery, design, build, and verification, while people keep ownership of every decision. We'll run it with the BMAD method, a structured, role-based way to run AI-assisted delivery. The first step is a pilot on one real initiative in Q4 2026.

This is work in progress. The pilot is still being defined, and so are the enablement materials behind it. I'm sharing it here because it's the other half of how I lead today: bringing a design team, and its partners, into a new way of working.

A cross-functional team gathered around a laptop, discussing their work
4
Disciplines
Product, Engineering, Data, and UX
8
ADLC phases
Each with a human review gate
1
Real initiative
Discovery to delivery
Q4
2026
Pilot window

Why Change

Where the Current SDLC Falls Short

Our SDLC describes what happens over time: plan, design, build, test, deploy, and maintain. It doesn't define how teams share decisions and context when AI tools are doing part of the work, and that gap shows up in the same places every time.

Separate Tracks
Requirements, design, and engineering often move on their own tracks, so they only come together at handoff.
Static Handoffs
Specs and files are passed along once and go out of date as soon as the work moves forward.
Lost Context
The reasons behind decisions get lost between phases, so teams explain the same thing again, or rebuild it.
Unstructured AI Use
People use AI tools on their own, without shared methods, review gates, or rules for handling data.

The Model

SDLC, ADLC, and BMAD: Related, but Not the Same

The first job was getting everyone to use the same words. The three terms get used interchangeably, but each one does a different job.

SDLC / PDLCThe lifecycle stages

The stages we already know: plan, design, build, test, deploy, and maintain. It covers what happens and when, but not how teams coordinate AI-assisted work.

ADLCThe operating model

How delivery works when AI and agents take part. Context is created early and reused, planning and building are connected through shared artifacts, and feedback loops get shorter. People still own every decision.

BMADThe method

A structured way to run the ADLC. Specialized agents (Analyst, PM, UX Designer, Architect, and Developer) each produce a document the next step builds on, so decisions stay visible and don't have to be explained again.

Fig. 1 SDLC compared with ADLC

SDLCOne pass in a line. Launch is the finish line.
  1. Plan
  2. Design
  3. Build
  4. Test
  5. Deploy
  6. Maintain
ADLCA continuous loop, with a human review gate at every phase.
  1. Phase 0Prepare
  2. Phase 1Scope
  3. Phase 2Define
  4. Phase 3Simulate
  5. Phase 4Implement
  6. Phase 5Test
  7. Phase 6Deploy
  8. Phase 7Govern
What the team learns feeds the next cycle

The stages look similar. The difference is that deployment isn't the finish line: the team keeps evaluating, and what it learns feeds back into the work.

01
Chapter 01 · Define
The quad
Who is shaping the pilot, and what does each discipline own?

The Quad

Defining the Pilot Together

The pilot isn't a design initiative with other teams brought in later. It's being defined by a quad: the four disciplines that will run it together. Each one owns a different part of the loop, and every phase ends with a review by a named person.

A team brainstorming with sticky notes on a glass wall
Product
Priority & Scope
Owns priority, scope, tradeoffs, and when decisions get made. Produces the product brief, backlog priorities, and decision log.
Engineering
Buildability & Review
Owns technical constraints, the implementation plan, and the technical review gates. Turns validated prototypes into scoped work.
Data
Evidence & Measurement
Owns baselines, metric definitions, and evaluation data, so the answer to "did it work?" is backed by evidence.
UX
Experience & Trust
My team, spanning UX design, research, and content design. Research owns the evidence, design owns the quality of the flows, and content owns clear messaging in high-risk security moments.
02
Chapter 02 · Run
The pilot
How will one real initiative run from discovery to delivery with BMAD?

The Pilot

One Real Initiative, Discovery to Delivery, Run With BMAD

We're not running a sandbox exercise. The pilot takes a real Access & Security Manager initiative through the whole lifecycle using the BMAD method. AI agents draft the artifacts: the brief, spec, UX documents, architecture, stories, and code. A named person from the quad reviews each one and approves it or sends it back, and every decision is logged.

Fig. 2 The review gate at every phase

01
An agent drafts
A brief, spec, design, or code, built on everything decided before it.
02
A named person reviews
Someone from the quad approves it or sends it back with changes.
03
The work moves on
The decision and its reasons go in the log, and the next phase starts.
Context carries forward
  1. Brief
  2. Requirements
  3. UX documents
  4. Architecture
  5. Stories
  6. Code
  7. Review

Fig. 3 BMAD's agents and the people who review them

Every Agent Has a Human Counterpart

BMAD (v6.12) organizes its agents across four phases. In our pilot, the agents draft the work in each phase, and the quad reviews it before anything moves forward.

01
AnalysisUnderstand the problem
Agents draft
MaryBusiness Analyst

Research and the product brief

People decideUX ResearchProduct
02
PlanDecide what to build
Agents draft
JohnProduct Manager

Requirements, epics, stories

SallyUX Designer

How it looks and behaves

WinstonArchitect

Architecture decisions

People decideProductUX DesignContent DesignEngineering
03
ImplementBuild it
Agents draft
AmeliaSenior Software Engineer

Specs, code, and tests

People decideEngineering
04
VerifyCheck that it works
Agents draft
AmeliaSenior Software Engineer

Code review, retrospectives

MuratTest Architect Add-on

Test coverage and risk

People decideEngineeringUX DesignContent DesignData

↺ What Verify finds feeds back into Plan for the next cycle. Data checks results against the agreed metrics before anything is called done. Murat ships in BMAD's optional Test Architect module.

What Success Looks Like Right Now

For this first pilot, the goal is to learn and document. Formal success metrics will come out of what we learn.

Learn where the method helps and where it doesn't. Which phases speed up, which gates slow things down, and where the agents need the most human correction.
Document a repeatable playbook. Roles, artifacts, review gates, and handoffs that the next team can pick up without starting from scratch.
Test our assumptions. For example, that shared artifacts reduce the context lost at handoff, which is an expected benefit, not a proven one.
03
Chapter 03 · Enable
The team
How do we help people learn this new way of working?

Enablement

Bringing the Team Along

A new operating model only works if people can use it. To support the pilot, I'm building two internal resources. Both are still in progress:

An AI delivery guide and training site for design, research, and content designers. It covers what ADLC and BMAD are, who does what in the loop, a skills ladder, role-based tracks, hands-on labs, and a 30/60/90 adoption plan.
A current-state to future-state journey site that shows where we are today, where we're heading, and how we get from the current SDLC to the new way of working.
A designer coaching teammates through work on a shared screen
Work in progress The AI delivery guide shown on laptop and mobile
The AI delivery guide. An internal site that explains the model and gives each discipline a clear role in it, with a skills ladder, role-based tracks, hands-on labs, and a 30/60/90 adoption plan.

Guardrails

Moving Fast, Safely, in a Regulated Environment

This is a bank, so trust comes first. The guardrails are part of the model from day one, not added later.

Approved Tools and Data Only
Only masked or representative data. No customer data, credentials, or unreleased security details go into any tool, and Security approves every tool first.
Every Artifact Is a Draft
Agents draft and people decide. Every review gate has a named owner, and the reasons are written in a decision log.
Evaluate Before You Build
AI output isn't deterministic, so we define what "good" looks like before the build starts and review against it.
Name the Gaps
Some of this isn't designed yet, including rollout and drift monitoring. We say so openly instead of pretending the model is complete.

The Principle

"Agents draft. People decide. Every artifact is a draft until someone on the quad puts their name on it."

Michelle DaSilva · UX Design Lead · Leading US Bank

Where It Stands

In Progress, Q4 2026

The quad is defining the pilot now. I'll update this page as the pilot runs. When it's done, it will become a full case study with what we learned.

Now
Defining the Pilot
Agreeing on scope, gate owners, and the initiative, while building the enablement materials.
Q4
Run the Pilot
One real ASM initiative, discovery to delivery, run with BMAD by Product, Engineering, Data, and UX.
Next
Learn, Document, Scale
Turn what we learn into a documented playbook, as the path to replacing the current SDLC.
Back to Case Studies Related: Access & Security Manager