AI-DLC Has a Missing Phase
Amazon Web Services published a methodology called AI-DLC: the AI-Driven Development Lifecycle. It is a comprehensive framework for building software where AI acts as the primary driver of the development process while humans validate critical decisions. AWS open-sourced the workflow rules, documented the phases in detail, and embedded the methodology into Amazon Q Developer. It is one of the most significant shifts in how software gets built since Agile replaced waterfall.
AI-DLC has three phases: Inception, Construction, and Operations. Inception is where AI transforms business intent into requirements and user stories. Construction is where AI proposes architecture, generates code, and produces tests. Operations is where AI handles deployment and monitoring. The methodology generates a structured directory of artifacts at every step: requirements documents, user stories with explicit personas, functional design specs, acceptance criteria, audit logs of every decision. It is the richest, most structured record of why a feature was built and what it is supposed to do that has ever existed in a software development process.
Then the PR merges, Operations fires, the code reaches production, and all of that context sits in an aidlc-docs/ directory where nobody in marketing, sales, support, or customer success will ever read it. The methodology ends. The GTM motion does not begin. The gap between engineering done and market readiness, the gap every software company struggles with, is not just unaddressed by AI-DLC. It is wider than ever, because AI-DLC ships faster than any team that came before it.
What AI-DLC Actually Is
AI-DLC is not a tool. AWS is explicit about this. It is a methodology, a set of structured workflow rules that can be applied using any AI coding agent: Amazon Q Developer, Claude Code, Cursor, GitHub Copilot, Cline, or others. The rules live in a GitHub repository (awslabs/aidlc-workflows) and are designed to be vendor-agnostic by principle.
The core interaction pattern is: AI proposes, human approves. Every significant decision produces a structured question file in markdown. The developer fills in answers using [Answer]: tags. The AI reads the answers, validates them, and moves to the next stage only after receiving explicit approval. There are no surprises. There is no vibe coding. Every architectural choice, every design decision, every scope call is logged in an append-only audit.md with ISO 8601 timestamps.
This matters because it means AI-DLC is not just accelerating code production. It is capturing structured intent at a level of detail no previous development process came close to. The Inception phase alone produces more useful context about a feature than most organizations accumulate over the entire lifespan of that feature's development under traditional Agile.
The methodology is built on four tenets: reproducibility (clear enough rules that different AI models produce similar outcomes), agnosticism (works with any tool), human-in-the-loop (critical decisions require explicit approval), and no duplication (one source of truth, generated not copied). These tenets were designed for engineering quality. They have a side effect that nobody seems to have noticed yet: they produce exactly what GTM functions need, in exactly the format that automation can consume.
The Artifacts AI-DLC Generates
The aidlc-docs/ directory that AI-DLC populates over the course of a project is not a log. It is a structured knowledge base. Here is what it contains after a typical feature build:
| Artifact | What It Contains | GTM Value |
|---|---|---|
| requirements.md | Functional and non-functional specifications, the "why" behind every decision | Positioning rationale, feature value narrative |
| user-stories/ | INVEST-compliant stories with acceptance criteria and explicit user personas | Target audience, use cases, customer benefit framing |
| functional-design/ | Business logic, rules, domain entities, UI hierarchy | Demo scripts, product one-pager, support FAQ source |
| application-design-plan.md | Component architecture and strategic design decisions | Technical differentiation talking points |
| audit.md | Every decision made, every human approval, every scope call | Accurate history for release notes and customer comms |
Compare this to what a typical engineering team produces at merge time: a PR description, a ticket title, and maybe a changelog entry. AI-DLC produces requirements, personas, acceptance criteria, functional design, and a timestamped audit trail of every decision that shaped the feature. It is not more information in the same format. It is a fundamentally different category of artifact.
aidlc-docs/ directory for a feature has everything needed to write positioning, a blog post, a sales one-pager, a support article, and a customer announcement without a single follow-up conversation with engineering. The context is complete. The personas are named. The acceptance criteria describe exactly what the feature does from the user's perspective. No other development process in history has produced source material this good.
Where the Methodology Stops
AI-DLC's Operations phase covers deployment automation, infrastructure provisioning, monitoring setup, observability configuration, and production readiness validation. It is a complete, well-designed phase for getting code from a repository into a running production environment.
It does not cover anything that happens after the code is running. That is not a criticism. The methodology's scope is software development. Deployment is the natural end of software development.
The problem is what "after the code is running" actually means for a software business. After the code is running, marketing needs a positioning brief. Sales needs updated talking points and a revised battle card. Support needs a FAQ and an escalation path. Customer success needs to know which accounts to contact about this feature and what to tell them. Customers need an announcement that explains what changed and why it matters to them.
None of that is in scope for AI-DLC. None of that is produced automatically. None of that has a clear owner in the methodology. The aidlc-docs/ directory that contains everything needed to produce all of it sits in the repository, untouched by any downstream function, and will likely remain untouched indefinitely.
The Irony Is the Point
Sit with this for a moment. AI-DLC generates user stories with explicit personas. Marketing needs personas to write targeted messaging. Those personas exist, in structured markdown, in aidlc-docs/user-stories/. Nobody in marketing has ever seen them.
AI-DLC generates acceptance criteria that describe exactly what the feature does from the user's perspective. Support needs to know what a feature does from the user's perspective to answer customer questions. Those acceptance criteria exist, with checkbox tracking, in the construction phase artifacts. No support agent has ever read them.
AI-DLC generates requirements that capture why a feature was built and what problem it solves. Sales needs to know why a feature was built and what problem it solves to make a compelling case in deals. Those requirements exist in requirements.md. No sales rep has ever opened that file.
The richest GTM source material ever produced by a software development process is being systematically ignored by every GTM function that could use it. This is not because the information is hard to find. It is because no process exists to convert it into the formats those functions need, at the moment they need it, automatically.
The Missing Phase: GTM
A complete AI-DLC pipeline has four phases, not three. The fourth phase converts the structured context produced by Inception, Construction, and Operations into the artifacts that GTM functions need to act on the feature.
Phase 1: Inception
AI transforms business intent into requirements, user stories, and application design. Produces the "what" and "why."
Phase 2: Construction
AI proposes architecture, generates code, and produces tests. Produces the "how."
Phase 3: Operations
AI handles deployment and monitoring. Produces the "running." Code reaches production.
Phase 4: GTM (Missing)
AI converts structured context into market-facing artifacts. Produces the "launched." Marketing, sales, support, and customers are equipped.
The GTM phase consumes what the first three phases produce. It reads the requirements to understand the feature's strategic value. It reads the user stories to identify the target personas and their specific use cases. It reads the functional design to understand what the feature does in concrete terms. It reads the audit trail to understand the decisions that shaped it. From all of that, it generates:
- A positioning brief for marketing: value framing, target persona, competitive context, proof points from acceptance criteria
- Sales talking points: benefit narrative, objection handling based on requirements rationale, demo guidance from functional design
- A support FAQ: common questions derived from acceptance criteria and functional design, escalation path for edge cases
- A customer announcement: what changed, why it matters, how to get started, written for the persona defined in the user stories
Every piece of content this phase produces is derivable from artifacts that already exist. The GTM phase does not require any additional input from engineering, product, or anyone else. The work of understanding the feature is already done. The work of converting that understanding into market-facing content is what has been missing.
AI-DLC Was Built to Be Extended
AWS did not just build a methodology. They built an extensible one. The AI-DLC repository includes a formal extensions system specifically designed for teams to layer custom rules on top of the core workflow. The built-in extensions cover security and testing. The pattern for adding new extensions is documented and straightforward.
A GTM extension follows the same structure as any other extension: a rules file defining the phase's behavior, and an opt-in file that presents a structured question at the relevant gate. When the Operations phase completes and the code reaches production, the GTM extension activates. It reads the aidlc-docs/ artifacts. It generates the GTM content package. It delivers those artifacts to the functions that need them.
└── gtm/
└── content-generation/
├── gtm-content-generation.md # GTM phase rules
└── gtm-content-generation.opt-in.md # Opt-in gate at Operations
This is not a workaround. It is exactly what the extensions system was designed for. AWS made AI-DLC extensible because they knew that different organizations have different requirements beyond the core engineering workflow. A security extension ensures compliance gates. A testing extension enforces property-based testing. A GTM extension ensures that features are not just deployed but launched.
The methodology's tenets reinforce this. Reproducibility means the GTM content generated from the same aidlc-docs/ artifacts should be consistent regardless of which AI model runs the phase. Agnosticism means the GTM extension should work whether you are running Claude Code, Amazon Q Developer, or any other agent. Human-in-the-loop means the marketing brief and sales one-pager go through an approval gate before distribution, just as every code change goes through an approval gate before deployment.
Closing the Full Loop
Software development in the AI-DLC era is faster, more structured, and more thoroughly documented than anything that came before it. The artifact trail it produces is genuinely extraordinary. Requirements that capture why. User stories that name the persona. Acceptance criteria that describe the outcome. Functional design that explains the behavior. An audit log that records every decision.
All of it stops at the deployment gate. Marketing waits for a Slack message. Sales gets a changelog written for engineers. Support improvises on the first customer ticket. Customers find out about features through release notes they will never read, if those notes get written at all.
As we explored in The PM's Definition of Done Is Wrong, the engineering definition of done creates an artificial line that leaves the entire GTM motion unequipped. AI-DLC accelerates everything up to that line and makes the gap on the other side more visible than ever. The solution is not to slow down the engineering side. It is to automate the GTM side at the same speed.
OptibitAI is the GTM phase that AI-DLC is missing. It reads the structured context that AI-DLC produces, at the moment the Operations phase completes, and generates the full GTM content package automatically: positioning brief, sales talking points, support FAQ, customer announcement. The same AI-first, human-in-the-loop, reproducible-by-design principles that make AI-DLC work for engineering apply directly to generating GTM content from the artifacts it leaves behind.
You invested in AI-DLC to ship faster. The value of shipping faster is only realized when your organization can market, sell, support, and communicate what was shipped. Adding the GTM phase closes the loop that AI-DLC opened.
Try OptibitAI and turn your aidlc-docs/ directory into a complete launch package on every release.