Tutorials

Step-by-step AI workflow guides for product and engineering teams.

Learn how to run Brownfield, Greenfield, and configuration or infrastructure work through AIDLC Studio. Then apply the same model-agnostic workflow in Claude Code or Codex.

AI development styles

See how the same AI-assisted change looks across four development styles.

The example is the same in every card: improve checkout error clarity without changing payment provider behavior. Watch how the prompt improves as it adds intent, constraints, acceptance criteria, review evidence, and release ownership.

Fast exploration

What is vibe coding?

Vibe coding means you describe the feel, behavior, or rough outcome you want, then use an AI assistant to quickly generate and refine code until the result feels close.

Same example

"Reduce failed checkout retries by showing a clearer payment error, without changing payment provider behavior."

Prompt example

"Make the checkout error feel clearer and calmer. Try a better message and update the UI until it feels right."

What gets better

The prompt is fast and creative, but it does not define files, tests, non-goals, or release evidence.

Best for quick exploration, but risky if the result moves toward production without tests and review.

Defined before build

What is spec-driven development?

Spec-driven development starts with a written specification. The team defines behavior, constraints, interfaces, tests, and acceptance criteria before asking AI to implement.

Same example

"Reduce failed checkout retries by showing a clearer payment error, without changing payment provider behavior."

Prompt example

"Use the checkout error spec. Update only the displayed error copy and UI state. Preserve provider calls, status handling, telemetry names, and retry behavior. Add or update tests for the allowed error states and acceptance criteria."

What gets better

The prompt now gives the assistant rules, expected behavior, non-goals, and tests before generation starts.

Use it when accuracy, contracts, compliance, or cross-team review matters more than speed alone.

Outcome first

What is intent-driven development?

Intent-driven development starts with the reason for the change. You name the user, business, security, or operational outcome before deciding what code, configuration, or tests should change.

Same example

"Reduce failed checkout retries by showing a clearer payment error, without changing payment provider behavior."

Prompt example

"The goal is fewer failed checkout retries caused by confusing payment errors. Improve the message so customers know what to do next. Keep provider behavior unchanged. Explain how the change supports the metric and what evidence should prove it worked."

What gets better

The prompt connects the work to a business outcome, success metric, customer behavior, and human acceptance.

Use it when the team needs AI output to stay connected to product value, risk, and release evidence.

Lifecycle control

What is AIDLC?

AIDLC turns the AI-assisted change into a lifecycle: intent, context, generation, verification, acceptance, release evidence, and learning. The assistant can help, but the team owns the decision.

Same example

"Reduce failed checkout retries by showing a clearer payment error, without changing payment provider behavior."

Prompt example

"Use AIDLC Brownfield Flow. Intent: reduce failed checkout retries caused by unclear payment errors. Scope: checkout error copy and UI state only. Non-goals: no provider call, retry, telemetry, or payment logic changes. Return affected files, candidate diff, assumptions, regression checks, acceptance evidence, release notes, and rollback signal."

What gets better

The prompt becomes production-ready: bounded scope, context, non-goals, verification, acceptance, release, and rollback are all visible.

Use it when AI output needs to be reviewable, testable, explainable, and safe enough for a real release.

Workflow guides

How to use each AIDLC workflow

Start with the workflow that matches the change type. Do not choose based on which AI model or assistant you plan to use.

Brownfield Flow

Use this when AI touches existing product behavior, legacy code, or active customer workflows.

  1. Map current behavior, dependencies, and known defects.
  2. Define the smallest safe change and explicit non-goals.
  3. Create a context packet with relevant files, tests, APIs, and constraints.
  4. Ask the assistant for a narrow candidate patch, not a broad rewrite.
  5. Run regression checks for changed and unchanged behavior.
  6. Review the patch until a human can explain it without model authority.
  7. Accept with a before/after product demo.
  8. Release with monitoring, rollback criteria, and a learning log.

Greenfield Flow

Use this for new features, services, internal tools, and MVP surfaces.

  1. Frame the user problem, MVP boundary, success metric, and non-goals.
  2. Write an architecture note with data contracts, ownership, and risk controls.
  3. Prepare a model-neutral prompt contract for one vertical slice.
  4. Generate a scaffold or candidate implementation inside that boundary.
  5. Validate tests, performance, usability, and architecture fit.
  6. Run product acceptance against the original customer scenario.
  7. Pilot with a controlled audience, owner, monitoring, and support path.
  8. Scale, stop, or iterate from pilot evidence.

Config & Infrastructure

Use this when AI touches deployment, policy, configuration, environments, or infrastructure as code.

  1. Declare the operational intent, affected customers, and non-goals.
  2. Map blast radius, dependencies, permissions, cost, security, and rollback.
  3. Inventory current state, runbooks, and validation commands.
  4. Ask the assistant for a minimal config diff and rollback notes.
  5. Review plan output, security posture, and operational readiness.
  6. Approve the change window, owner, communication, and rollback trigger.
  7. Roll out under observation with incident path ready.
  8. Complete post-checks and update runbooks.

Claude and Codex

Use AIDLC with AI coding assistants

The same workflow works with Claude Code, Codex, or any assistant because the durable artifact is the context packet and evidence contract, not a vendor-specific prompt.

Claude Code

  1. Review the Starter Kit preview and decide which repository instructions your team needs.
  2. Use the Starter Kit for the workflow runbook that matches the change type.
  3. Update CLAUDE.md with project build commands, review rules, and the AIDLC guide location.
  4. Start Claude Code from the repository root.
  5. Ask Claude to use the matching flow and produce a candidate artifact plus evidence notes.
  6. Run the required checks and update the evidence ledger before merge or release.

The Claude-ready starter instructions and runbook wording are included in the AIDLC Team Starter Kit.

Codex

  1. Review the Starter Kit preview and decide which AGENTS.md coverage your repo needs.
  2. Use the Starter Kit for the chosen workflow guide, prompt contract, and review gate.
  3. Add durable repo instructions in AGENTS.md so Codex sees the workflow expectations.
  4. Open Codex in the app, CLI, IDE extension, or web surface from the repository context.
  5. Prompt Codex with the workflow type, risk level, allowed scope, and required evidence.
  6. Review all edits, commands, and test results before accepting the output.
  7. Use the evidence ledger for acceptance, release, and learning decisions.

The Codex-ready starter instructions and high-risk workflow prompt are included in the AIDLC Team Starter Kit.

Reusable Prompt Contract

  1. Name the workflow: Brownfield, Greenfield, or Config/Infra.
  2. State product intent, risk level, and non-goals.
  3. List relevant files, APIs, tests, and constraints.
  4. Define allowed and prohibited actions.
  5. Ask for output, verification steps, risks, and evidence updates.
  6. Keep human review and release decisions outside the assistant.

The reusable prompt contract format is included in the AIDLC Team Starter Kit.