If a data team adopts an AI-SDLC method — AWS's AI-DLC or Claude's data-engineering plugin — which half of their work does it actually cover?

Method: Primary sources, read directly. Cloned and read three repositories at their current heads: awslabs/aidlc-workflows (head 488ab10, 2026-09-19; CHANGELOG at 2.9.0, 2026-09-15), anthropics/claude-plugins-official (Anthropic's own plugin marketplace manifest), and astronomer/agents (head cbe1141, 2026-09-17) — enumerating stages, scopes, agents, skills and cache code, and grepping the full AI-DLC markdown corpus for data-domain vocabulary. dbt's semantic-model definition was read from the raw docs.getdbt.com page and the quote checked against the page text. What was blocked: claude.com and www.claude.com (→ redirects to claude.com), aws.amazon.com, arxiv.org — all refused at the proxy CONNECT (response 403), i.e. the allowlist, not the sites. So Anthropic's own AI-Native SDLC playbook and its data-engineering plugin page are SECONDARY here, and the 21% → ~95% figures from the Sep 17 digest remain unverified for the second session running. Access changed since 2026-09-17, measured (recorded for research-loop/ACCESS.md): docs.getdbt.com, www.anthropic.com and www.databricks.com all answer 200 this session, having been recorded as blocked on 2026-09-17. claude.com is still refused. www.anthropic.com/engineering/ai-native-sdlc returns a genuine 404 — the playbook is not mirrored there.

---

The one-paragraph answer

Every AI-SDLC method now shipping covers the half of a data team's work that looks like software, and hands back the half that decides whether the numbers are right. AWS's AI-DLC is at 2.9.0 with 33 stages across 5 phases — intent capture, user stories, domain design, code generation, build and test, deployment, incident response — and not one of them is data-shaped (VERIFIED, core/aidlc-common/stages/). A grep of its entire markdown corpus returns zero files mentioning data warehouse, dbt, semantic layer or data governance, and exactly one word-boundary match for ETL — line 72 of a 74-line knowledge file about DynamoDB single-table design attached to the developer agent (VERIFIED, core/knowledge/aidlc-developer-agent/data-modelling-patterns.md). No scope keyword routes a pipeline intent anywhere sensible, so "build me a pipeline" falls through to classic, the software-delivery default (VERIFIED, core/scopes/). Anthropic's own AI-Native SDLC playbook is the same shape — Plan → Design → Build → Test → Deploy → Maintain (SECONDARY; claude.com blocked). The one method that is built for data teams turns out, on reading Anthropic's own marketplace manifest, to be a vendor's tooling listed twice: data-engineering and astronomer-data-agents resolve to the same repository at the same commit — github.com/astronomer/agents @ 9b5a331 (VERIFIED, .claude-plugin/marketplace.json, 310 plugins, owner "Anthropic"). It ships 34 skills, of which 26 are Airflow/Astronomer mechanics and 8 touch the warehouse (VERIFIED). And its context layer is where the whole thing shows its seam: warehouse-init generates .astro/warehouse.md from INFORMATION_SCHEMA plus whatever descriptions exist in dbt YAML, then ships the business-meaning section as literal placeholder comments — <!-- Add your concept mappings here -->, under a header reading "Edit freely to add business context" (VERIFIED). Meanwhile analyzing-data lets the agent write its own concept→table mappings via concept learn, cached to ~/.astro/ai/cache/concepts.json with a 90-day TTL — a home directory, per-machine, outside the repo, never code-reviewed (VERIFIED, scripts/cache.py:13,16). So the tool has two context stores with opposite governance properties, and the agent-authored one is the invisible one. That is the finding a PM should carry: these methods automate the pipeline and leave the definitions blank, and where they do fill definitions in, they do it in a place nobody reviews.

---

§1 — AI-DLC at 2.9.0: a software lifecycle, measured

The Sep 3 digest established what AI-DLC v2 is (Research Digests/2026Sep/2026Sep03_Amazon_AI_DLC_v1_vs_v2). This section asks a narrower, checkable question: does any of it fit data work?

The complete stage inventory (VERIFIED — 33 files under core/aidlc-common/stages/):

Phase	Stages
Initialization (3)	state-init, workspace-detection, workspace-scaffold
Ideation (7)	intent-capture, market-research, rough-mockups, scope-definition, team-formation, feasibility, approval-handoff
Inception (9)	requirements-analysis, user-stories, domain-design, contract-design, units-generation, delivery-planning, practices-discovery, refined-mockups, reverse-engineering
Construction (7)	functional-design, nfr-requirements, nfr-design, infrastructure-design, code-generation, build-and-test, ci-pipeline
Operation (7)	environment-provisioning, deployment-pipeline, deployment-execution, observability-setup, performance-validation, incident-response, feedback-optimization

Read the list as a data engineer. There is no stage for source ingestion, none for dimensional or analytics modelling (as distinct from domain-design, which produces application components, VERIFIED from its frontmatter produces: components, decisions, traceability), none for data quality testing, none for lineage, none for backfill or reprocessing, and none for metric definition. The lifecycle is code is written, code is deployed, code is operated. A data team's lifecycle is data arrives, data is transformed, data is trusted — and the trust step has no home here.

The vocabulary audit (VERIFIED — whole-repo grep, --include=*.md)

Term	Files matching
data warehouse	0
dbt	0
semantic layer	0
data governance	0
analytics engineer	0
Airflow	0
ELT (word-boundary)	0
ETL (word-boundary)	1
data contract	1
data quality	1

The data contract and data quality hits are incidental — they land in docs/reference/01-architecture.md and core/knowledge/aidlc-product-agent/prioritization-frameworks.md, not in any data workflow. The single ETL hit is line 72 of core/knowledge/aidlc-developer-agent/data-modelling-patterns.md: "ETL batch migration: Export, transform, load. Use for one-time moves with a maintenance window." That file is 74 lines long and is about OLTP schema design — relational vs DynamoDB, 1NF through BCNF, single-table partition/sort key patterns. It is database design for an application, not data engineering for analytics.

Nothing routes a data intent

AI-DLC picks a scope from keywords. The full set (VERIFIED, core/scopes/*.md):

fix · bug · broken · express · lightweight · infrastructure · deploy · infra · mvp · minimum viable · proof of concept · prototype · poc · spike · refactor · clean up · simplify · security · CVE · vulnerability · patch · workshop · lab · training

classic, enterprise and feature declare keywords: [] deliberately. classic is the implicit default — its own file says so: "used when neither the user nor AWS_AIDLC_DEFAULT_SCOPE names one." So a data-pipeline intent does not get refused or routed somewhere sensible; it silently gets the v1-style software flow, 18 of 33 stages through Build and Test (VERIFIED, core/scopes/aidlc-classic.md).

This is not a criticism of AI-DLC. It never claimed to be a data method. It is a finding about what a data team would actually get if someone senior read a conference talk and said "let's adopt AI-DLC."

---

§2 — Anthropic's marketplace: the data-engineering plugin is Astronomer's, listed twice

anthropics/claude-plugins-official carries Anthropic's own marketplace manifest — owner: {"name": "Anthropic", "email": "support@anthropic.com"}, 310 plugins (VERIFIED, .claude-plugin/marketplace.json).

Two entries are relevant, and they are the same thing (VERIFIED, quoted from the manifest):

{ "name": "astronomer-data-agents",
  "description": "Data engineering for Apache Airflow and Astronomer. Author DAGs with best
   practices, debug pipeline failures, trace data lineage, profile tables, migrate Airflow 2 to 3,
   and manage local and cloud deployments.",
  "category": "development",
  "source": { "url": "https://github.com/astronomer/agents.git",
              "sha": "9b5a33171e36ecda135f22e77a845d9c405b519e" } }

{ "name": "data-engineering",
  "description": "Data engineering plugin - warehouse exploration, pipeline authoring,
   Airflow integration",
  "source": { "url": "https://github.com/astronomer/agents.git",
              "sha": "9b5a33171e36ecda135f22e77a845d9c405b519e" } }

Same repository. Same commit. The generic-sounding data-engineering entry carries no category and no author block, so in a listing it reads like a first-party Anthropic capability. It is Astronomer's Airflow tooling. (The repo is Apache-2.0 and explicitly "compatible with open-source Apache Airflow", VERIFIED, README.md — this is not a bait-and-switch, but the naming does obscure whose opinion you are installing.)

The manifest's category distribution is the second tell (VERIFIED):

development 123 · productivity 65 · database 39 · monitoring 22 · security 18 · (none) 14 · deployment 9 · design 8 · automation 3 · learning 3 · location 2 · testing 2 · migration 1 · math 1

There is no data category. 39 plugins are filed under database — connectors to a store. Data work — modelling, quality, governance, semantics — is not a category the marketplace recognises.

---

§3 — What the 34 skills actually cover

VERIFIED — every skill name and description read from astronomer/agents/skills/*/SKILL.md.

26 skills are Airflow/Astronomer mechanics: airflow, airflow-hitl, airflow-plugins, airflow-state-store, authoring-dags, authoring-go-sdk-tasks, authoring-java-sdk-tasks, authoring-language-sdk-tasks, blueprint, configuring-airflow-language-sdks, dag-factory, debugging-dags, delegating-to-otto, deploying-airflow, deploying-go-sdk-bundles, deploying-java-sdk-bundles, managing-astro-deployments, managing-astro-local-env, migrating-ai-sdk-to-common-ai, migrating-airflow-2-to-3, migrating-dagster-to-airflow, setting-up-astro-project, testing-dags, troubleshooting-astro-deployments, cosmos-dbt-core, cosmos-dbt-fusion.

8 touch the warehouse: analyzing-data, warehouse-init, profiling-tables, checking-freshness, tracing-upstream-lineage, tracing-downstream-lineage, annotating-task-lineage, creating-openlineage-extractors — and the last two are really Airflow-side lineage plumbing.

That ratio is the point. This is orchestration tooling with a warehouse-reading attachment, which is a fair description of what it says it is. testing-dags tests the DAG, not the data. cosmos-dbt-core executes dbt test inside Airflow (VERIFIED, reference/cosmos-config.md:247) — it runs tests someone else wrote; it does not help write them.

Being fair about data quality: it is not absent, it is observational. profiling-tables has a real Step 6 "Data Quality Assessment" across Completeness / Uniqueness / Freshness / Validity / Consistency (VERIFIED) — genuinely useful. But look at what it emits:

Data Quality Score

• Completeness: X/10 · Uniqueness: X/10 · Freshness: X/10 · Overall: X/10

That is a model assigning a score out of ten with no stated rubric and no threshold — a number that looks like a metric and is not computed by a program. By the AI-DLC distinction worth stealing from the Sep 3 digest, this is an Inferential check dressed as a Computational one, and a check the model grades itself on is not a gate (frameworks/ai-dlc).

---

§4 — The seam: two context stores, opposite governance

This is the section that matters, and it is entirely VERIFIED.

warehouse-init builds the scaffold and leaves the meaning blank

The skill discovers databases, schemas, tables and columns from INFORMATION_SCHEMA, enriches from dbt schema.yml descriptions, gusty SQL frontmatter, and AGENTS.md/CLAUDE.md, then writes .astro/warehouse.md — described in the skill as "project-specific, version-controllable" (VERIFIED). Good instinct: that is documentation living with the code, exactly the practice the Sep 17 digest reported.

But read the template it emits (VERIFIED, quoted verbatim):

# Warehouse Schema
> Generated by `/astronomer-data:warehouse-init` on {DATE}. Edit freely to add business context.

## Quick Reference
| Concept | Table | Key Column | Date Column |
<!-- Add your concept mappings here -->

The business-meaning layer ships as a TODO comment. The machine can enumerate every table you own; it cannot tell you what "active customer" means. So it writes the part it can and leaves an HTML comment where the agreement goes. That is honest engineering — and it is precisely the layer the Sep 17 digest identified as the one that does not automate and the one that decides reliability (concepts/semantic-layer-as-agent-context).

analyzing-data lets the agent write definitions into a place nobody reviews

The analysis loop caches what it learns (VERIFIED, SKILL.md step 5):

uv run scripts/cli.py concept learn <concept> <TABLE> -k <KEY_COL>
uv run scripts/cli.py pattern learn <name> -q "question" -s "step" -t "TABLE" -g "gotcha"

And the cache's own docstring says where that lands (VERIFIED, scripts/cache.py, lines 1–16):

"""Persistent cache for concepts, patterns, and table schemas.
Cache files are stored at ~/.astro/ai/cache/:
- concepts.json: concept → table mapping (e.g., "customers" → "HQ.MODEL.ORGS")
- patterns.json: question type → query strategy
- tables.json: table schema cache (columns, types, row counts)
"""
CACHE_DIR = Path.home() / ".astro" / "ai" / "cache"
DEFAULT_TTL_DAYS = 90

So: ~/, not the repo. Per-machine, not per-team. Invisible to code review. Expiring after 90 days. And the thing being stored is "customers" → which table — a concept→entity mapping, which is the cheap end of the definitional work but is still definitional.

The contrast is the finding. One store (.astro/warehouse.md) is in the repo, version-controlled, human-editable, and ships empty where meaning goes. The other (~/.astro/ai/cache/concepts.json) is outside the repo, machine-written, unreviewed, and fills itself. The layer that gets populated automatically is the one nobody can see. Two engineers on the same team can hold different cached answers to "which table is customers," and neither will know.

I am not claiming this reproduces the reported result that LLM-generated metric definitions worsened accuracy — that claim is SECONDARY and stays SECONDARY (claude.com blocked twice now). What is VERIFIED is the governance shape: agent-authored context is being persisted outside version control by default.

What "in the repo" looks like when someone does it deliberately

dbt is the contrast case, and it is VERIFIED — read from docs.getdbt.com/docs/build/semantic-models and checked against the raw page text:

"Semantic models are the foundation for data definition in MetricFlow, which powers the Semantic Layer."

"Configure semantic models in a YAML file within your dbt project directory, embedded within your model definitions rather than as separate configurations."

Human-authored YAML, in the project, next to the model it describes, moving through the same pull request as the schema change. That is the governance property the cache lacks — and it is available today, without adopting any AI-SDLC method at all.

---

§5 — So what is the AI-SDLC method for a data team?

Honest answer from this session's evidence: there isn't one yet, and the gap is specific rather than total.

Half of the work	Covered by?
Pipeline as software — authoring, testing the DAG, deploying, debugging failures, migrating versions, infra	Yes, well. AI-DLC's 33 stages fit this; Astronomer's 26 orchestration skills fit this more concretely.
Data as a product — what a metric means, who owns the definition, which numbers are contractual, how a definition change is reviewed and released	No. Zero stages in AI-DLC; a placeholder comment in the Astronomer plugin; an unreviewed home-directory cache where it does get populated.

Anthropic's own playbook does not close it either. SECONDARY (claude.com blocked): published around 2026-08-21, six stages Plan → Design → Build → Test → Deploy → Maintain, passing context between agents as version-controlled Markdown artifacts (intent.md, spec.md, plan.md) with human approval gates at each handoff. The versioned-artifact idea transfers cleanly to data work — a definitions.md reviewed like a spec is exactly right. The stage names do not: a data team has no Design→Build→Deploy for a metric definition change, it has propose → agree → migrate consumers.

---

How a PM applies this

Written for the data-team engagement, but general.

1. Ask where the definition layer lives, before asking which tool. Three answers, in descending order of safety: in the repo, reviewed (dbt semantic models, a definitions.md) → in the repo, unreviewed (a generated warehouse.md nobody edited) → outside the repo (~/.astro/ai/cache/, someone's laptop). Most teams are at the third and think they are at the first.
2. Run one concrete check this week: if the team uses this plugin, cat ~/.astro/ai/cache/concepts.json on two different engineers' machines and compare. If they differ, you have just found an ungoverned definition layer, cheaply, with no meeting.
3. Treat the <!-- Add your concept mappings here --> comment as the actual project. The tool did the enumerable 80% in minutes. The remaining 20% is the agreement work — and it is the part that decides whether an answer given to a government-agency stakeholder is right. That is a PM's work, not a tooling task.
4. Do not let "we're adopting AI-DLC" pass unexamined in a data context. Ask which of the 33 stages maps to ingestion, to quality, to lineage. The answer is none, and asking the question is a 30-second demonstration of technical literacy.
5. Steal the versioned artifact, not the stage list. The one genuinely portable idea across AWS's method, Anthropic's playbook and dbt's semantic models is the same: the context an agent uses is a reviewed file in version control, not a chat message and not a cache.
6. Distinguish an observational quality check from a contractual one. A profiling score of 7/10 assigned by a model is a hint. A dbt test that fails the build is a gate. Both are useful; only one is a control.

---

Course relevance

Feeds the DevOps leg of the offer directly (training/offers/pm-second-brain-cohort.md): "read the tool, find where the human decision was left blank" is a repeatable exercise a PM can run on any agent tooling, and this digest is a worked instance of it. It also gives the ⚙️ DevOps Basics pillar something a PM can literally run this week (move 2 above) rather than a concept to nod at.

---

Open questions for a future session

• Does the Anthropic self-service-analytics post actually say what the Sep 17 digest reports? Two sessions blocked on claude.com. Worth allowlisting claude.com (Tier 2) specifically to close this — it is now the single highest-value missing domain for the data lane.
• The renames map in the marketplace manifest includes "adlc": "agentforce-adlc" (VERIFIED) — Salesforce ships an Agent Development Life Cycle under a near-identical acronym. Whether AI-DLC / ADLC collision is causing real confusion is unchecked.
• Does astronomer/agents intend the ~/.astro/ai/cache/ location, or is a repo-local cache on the roadmap? Their README.md has a Roadmap section that was not read in full.
• Is there any shipping AI-SDLC method with a data-shaped stage list? Nothing in the 310-plugin manifest suggests one; a targeted search was not run.

Parked candidates

• The claimed "over 30 specialized skills" framing of the plugin (SECONDARY, from a search extract of the blocked claude.com/plugins/data-engineering page) — the real count is 34, VERIFIED from the repo, so the marketing line is accurate and was not worth a section.
• dbt Labs' 2026 semantic-layer benchmark: docs.getdbt.com is now reachable, but the benchmark is a blog/report, not a docs page, and no reachable URL was identified this session.

---

Cross-References

Related: concepts/semantic-layer-as-agent-context, frameworks/ai-dlc, Research Digests/2026Sep/2026Sep17_Grounding_Beats_Prompting_For_Data_Agents, Research Digests/2026Sep/2026Sep03_Amazon_AI_DLC_v1_vs_v2, Research Digests/2026Sep/2026Sep05_Spec_Kit_PM_Bundle_Reality_Check, concepts/verification-debt, frameworks/spec-driven-development

Sources

Primary (VERIFIED — cloned and read directly this session)

• github.com/awslabs/aidlc-workflows — head 488ab10956cce2c06eceaa102fd149e5f56e9c85 (2026-09-19). Read: CHANGELOG.md (2.9.0, 2026-09-15), all 33 files under core/aidlc-common/stages/, all 11 core/scopes/*.md, the 14 core/agents/*.md filenames, core/knowledge/aidlc-developer-agent/data-modelling-patterns.md (74 lines), core/aidlc-common/stages/inception/domain-design.md frontmatter. Vocabulary grep run over the full *.md corpus.
• github.com/anthropics/claude-plugins-official — .claude-plugin/marketplace.json: 310 plugins, owner: Anthropic; the data-engineering and astronomer-data-agents entries and their identical source.url / source.sha; the category distribution; the renames map.
• github.com/astronomer/agents — head cbe1141f547bcf0506babb9778a7696bf15eff66 (2026-09-17), Apache-2.0. Read: README.md, all 34 skills/*/SKILL.md frontmatter, skills/warehouse-init/SKILL.md (full), skills/analyzing-data/SKILL.md and skills/analyzing-data/scripts/cache.py, skills/profiling-tables/SKILL.md, skills/checking-freshness/SKILL.md, skills/cosmos-dbt-core/reference/cosmos-config.md.
• docs.getdbt.com/docs/build/semantic-models — fetched and the quoted sentences checked against the raw page text.

Search extracts (SECONDARY — page not opened; URL recorded as it appeared)

• The AI-Native SDLC playbook — claude.com/blog/the-ai-native-sdlc-playbook. Publication date (~2026-08-21), the six stages, and the intent.md / spec.md / plan.md artifact pattern all come from search extracts and third-party write-ups, not from the post.
• How Anthropic enables self-service data analytics with Claude — claude.com/blog/how-anthropic-enables-self-service-data-analytics-with-claude. Still unopened; the 21% → ~95% figures carried in Research Digests/2026Sep/2026Sep17_Grounding_Beats_Prompting_For_Data_Agents remain SECONDARY and must not be quoted as established.
• Data Engineering Plugin — claude.com/plugins/data-engineering. The "over 30 specialized skills" description; the real count (34) was verified in the repo instead.

Not reachable this session (recorded, not guessed): claude.com, www.claude.com, aws.amazon.com, arxiv.org — all refused at the proxy CONNECT (response 403), i.e. allowlist, not the sites refusing. www.anthropic.com/engineering/ai-native-sdlc resolved and returned a genuine 404.

Newly reachable, measured 2026-09-19 (contradicts the 2026-09-17 record; per ACCESS.md, the probe wins): docs.getdbt.com 200, www.anthropic.com 200, www.databricks.com 200.