Brownfield example
Improve checkout error clarity without changing payment behavior.
A weak AI request sounds simple: "Make checkout errors better." That request is too broad for a
production system. It does not say which error states are confusing, which payment-provider behavior
must stay unchanged, what tests need to pass, or who accepts the wording.
AIDLC turns the request into a bounded Brownfield Flow. Product names the customer problem and
acceptance criteria. Engineering identifies the payment error mapping, UI component, tests, and
non-goals. The assistant is asked for a narrow candidate patch, then the team verifies that declined
card, expired card, provider timeout, and unknown error paths still behave correctly.
Greenfield example
Create a usage insights dashboard as one pilot slice.
A weak AI request says: "Build a dashboard for usage insights." That can easily produce a large
UI, guessed metrics, unclear data rules, and code that looks complete before the team agrees on the
first useful outcome.
AIDLC turns the idea into Greenfield Flow. Product defines the first decision the dashboard should
help a user make. Engineering chooses one data source, one API shape, one page, and one testable
path. The assistant helps scaffold a vertical slice, but the team accepts only the part that proves
the architecture, data contract, and user value.
Config and infrastructure example
Change a rate-limit policy with impact and rollback evidence.
A weak AI request says: "Update rate limits for the API." That can produce a configuration diff
without explaining customer impact, abuse risk, rollout timing, monitoring, or rollback ownership.
AIDLC routes the work through Config and Infrastructure Changes. The team states the operational
reason, affected services, expected traffic behavior, approval owner, monitoring signal, and rollback
steps. AI can help draft the config change and review checklist, but a human approves the final plan
before the change is applied.
Governance example
Turn a rejected AI suggestion into a reusable guardrail.
A weak workflow treats a rejected assistant suggestion as a private memory. One reviewer says no,
the team moves on, and the same bad dependency, broad rewrite, or unsafe shortcut appears again in
a future session.
AIDLC makes the rejection useful. The team records what was rejected, why it was rejected, and what
future prompts or repository instructions should say before generation begins. The next engineer
benefits from the review instead of rediscovering the same boundary.