AI agents no longer stop at autocomplete. They now participate across the whole software development lifecycle, from drafting requirements to refactoring code in maintenance, and the reason most of them still fail in production is not a weak model. It is missing context. Atlan is the Context Layer for AI: the governed layer between your fragmented development and data systems and the agents acting on them, so an agent reasons from one trusted, certified, policy-enforced source at every stage instead of guessing from a bare schema. The model was never the bottleneck. The function-specific context an agent can reach at each lifecycle stage is.
That gap is widest in the stages where an agent touches data. A coding agent that generates a query, a pipeline change, or a dashboard edit is not just writing text. It is acting on entities, metrics, joins, and downstream contracts it cannot see from a schema alone. This page frames AI agents around the lifecycle as a process and the context each stage requires. For the coding practice itself, plan, write, review, deploy, see the software-engineering deep-dive. For how building agents differs from building software, see ADLC vs SDLC.
How are AI agents used across the SDLC? An overview.
Permalink to “How are AI agents used across the SDLC? An overview.”Adoption is already broad. According to the 2024 DORA Accelerate State of DevOps Report from Google Cloud, more than 75% of respondents rely on AI for at least one daily professional responsibility, most commonly writing code, summarizing information, and explaining code. The 2024 Stack Overflow Developer Survey found 62% of developers currently use AI tools, up from 44% the prior year, with code writing the leading use case.
Agents now show up at every stage of the lifecycle, not just the coding step:
- Requirements and design: agents draft user stories, propose data models, and map how a new feature relates to existing entities and systems.
- Coding: copilots like GitHub Copilot, Cursor, and Claude Code generate application code, SQL, and pipeline logic against an existing codebase.
- Testing: test-generation and code-review agents write unit and integration tests, flag regressions, and check changes against contracts.
- Deployment: CI/CD agents assemble releases, run checks, and gate promotions based on what a change affects.
- Maintenance: agents triage incidents, propose refactors, and reconcile schema and definition changes as systems evolve.
- Data and analytics engineering: a fast-growing class of agents acts directly on pipelines, semantic models, SQL, dashboards, and cross-platform data products, where a wrong join is not a style issue but a broken number in a board deck.
The productivity ceiling is real. A controlled study published on the GitHub Blog found developers using Copilot completed a task 55% faster than those without it. The catch is that raw speed is not the same as safe change, which is exactly where context decides the outcome.
Why the SDLC is a hard context environment
Permalink to “Why the SDLC is a hard context environment”Speed without context has a cost, and the data now shows it. The 2024 DORA report found a paradox: as AI adoption rose, teams saw an estimated 1.5% decrease in delivery throughput and a 7.2% reduction in delivery stability, even as individuals felt more productive. InfoQ’s analysis of the report framed this directly as a trust and integration problem, not a model problem. Trust is scarce for a reason: the Stack Overflow survey found only 43% of developers expressed confidence in AI tool outputs.
Code-quality data tells the same story. As reported by DevClass on GitClear’s 2025 research, copy-pasted code has been rising while refactored code falls, and duplicated code blocks climbed sharply as AI assistance spread. An agent generating plausible code with no view of the surrounding system produces exactly this: local output that ignores global structure.
The SDLC is hard for agents because the important context is never in the file the agent is editing. It lives in the relationships between systems: which pipeline feeds which model, which dashboard depends on which column, which metric definition a downstream contract assumes. Miss that context and a change that compiles and passes local tests still breaks something two systems away. This is the core reason AI agents fail in production, and it is why context quality, not model quality, drives agent accuracy.
The definition problem: why bare schemas break data-touching agents
Permalink to “The definition problem: why bare schemas break data-touching agents”The problem is sharpest in data and analytics engineering. An agent asked to build a report on “active customers” or “monthly revenue” needs a canonical, certified definition of each term. Without one, it invents a plausible definition, or picks whichever table responds first, and produces a number that cannot be validated against any authoritative source.
Bare schemas do not carry this meaning. A schema tells an agent that a column named rev_amt exists. It does not tell the agent:
- What the term means: which of several competing revenue definitions this column encodes, and whether finance and product agree.
- Where it comes from: the column-level lineage from source system through transformations to the agent-facing view.
- What depends on it: the dashboards, models, and cross-platform data products that would break if the column or its logic changed.
- What is allowed: the access policies and sensitivity classifications that govern whether an agent can read or act on it at all.
- The edge cases: the tribal knowledge about the one region that reports in a different currency, or the backfill that skews the first quarter.
Give an agent only the schema and the predictable failures follow: hallucinated definitions, wrong joins, missed cross-platform dependencies, and answers no one can explain. This is the semantic layer problem, and it is why grounding matters. Research from Atlan and Snowflake showed that governing context delivered roughly 3x text-to-SQL accuracy compared with bare schemas, with referenced studies reporting 94 to 99% accuracy on governed context versus 10 to 31% on bare schemas alone.
Knowledge, Expertise, and Norms: the three parts of SDLC context
Permalink to “Knowledge, Expertise, and Norms: the three parts of SDLC context”Function-specific context is not one thing. An SDLC agent needs three kinds, and missing any one produces a different failure.
- Knowledge, what things mean: the entities, metrics, and definitions in play. A design agent that does not know what “customer” resolves to will scope the wrong feature. A coding agent that does not know a column’s certified definition will generate the wrong transformation.
- Expertise, how work actually gets done: the playbooks and procedures a team follows. How this org names models, how it stages migrations, how it validates a pipeline change before promotion. An agent without this produces code that works in isolation but violates every convention the team relies on.
- Norms, what is allowed: the access policies, approval rules, and sensitivity controls that decide whether an agent may read a dataset or promote a change. Enforce these at the point context is delivered, not inside each agent, so policy context is consistent no matter which agent asks.
Knowledge, Expertise, and Norms together are what lets an agent reason like an experienced engineer on your team rather than a capable stranger. This is the substance of AI agent context, and keeping it current is what prevents context drift.
The context an SDLC agent needs at each stage
Permalink to “The context an SDLC agent needs at each stage”The lifecycle is the useful lens because each stage has a distinct context requirement. Map the context to the stage and the failure modes become obvious.
Requirements and design
Permalink to “Requirements and design”Agents here need canonical business definitions, entity relationships, and the record of prior decisions. The job is to scope the right thing, and scoping depends on knowing what terms mean and how entities connect. An Enterprise Data Graph gives a design agent the map of what data exists and how it relates, so a proposed model fits the systems already in place.
Coding
Permalink to “Coding”Coding agents need downstream impact and governed context so generated changes respect contracts. A query or pipeline edit should be shaped by what depends on the tables it touches. Without governed definitions and lineage, an agent optimizes for code that runs, not for code that keeps the number correct three systems downstream.
Testing and deployment
Permalink to “Testing and deployment”These stages need active lineage, blast-radius analysis, and current policies to validate what a change affects before it ships. This is where tool use and planning meet governance: an agent should be able to query, before promotion, every dashboard, model, and data product a change would touch, and check the change against the policies in effect.
Maintenance
Permalink to “Maintenance”Maintenance agents need fresh schema, ownership, quality signals, and decision history, so they do not drift into silent failure. Systems evolve, definitions change, owners move. An agent working from stale context will confidently maintain a system that no longer exists as it remembers it. A queryable decision trace of what data and definitions produced a prior output is what lets a maintenance agent reason about why something was built the way it was.
What a governed SDLC agent architecture looks like
Permalink to “What a governed SDLC agent architecture looks like”A production-grade architecture for SDLC agents delivers the right context to the right stage through shared infrastructure rather than bolting it onto each agent.
- A unified context graph: one living Enterprise Data Graph that unifies schemas, column-level lineage, ownership, quality, and definitions across 100+ connectors, so every agent reasons from the same map.
- Column-level and cross-platform lineage: provenance, root-cause analysis, and blast-radius, reverse-engineered from SQL, pipelines, and BI, so an agent can see what a change affects before it ships.
- Versioned, portable context: context repositories that are model-agnostic and policy-embedded, so certified context is reused across agents and preserved for audit.
- Policy enforcement at delivery: role, use-case, and sensitivity checks applied before any context reaches an agent, not reimplemented per agent.
- Decision traces: a queryable record of what data, definitions, and policies produced an agent output, for debugging, review, and maintenance.
- Activation over open interfaces: certified context delivered to Copilot, Cursor, Claude Code, and analytics agents through MCP, API, SQL, and graph access.
Together these give agents the complete stack they need, and give teams a governed way to grow from a handful of agents to many without context sprawl. For the full component breakdown, see how AI agent architecture works.
How Atlan supports AI agents across the SDLC
Permalink to “How Atlan supports AI agents across the SDLC”Atlan is the Context Layer for AI: the governed layer between your development and data systems and the agents that act on them across the lifecycle.
- Enterprise Data Graph: one living graph of what data exists, what it means, and how it connects, unifying schemas, lineage, ownership, quality, and definitions so agents scope, code, and test against a single trusted map.
- Column-level and cross-platform lineage: reverse-engineered from SQL, pipelines, and BI, giving agents provenance for root-cause analysis and blast-radius before a change ships to deployment.
- Context Agents: AI agents that mine descriptions, metric definitions, and ontology from SQL history, BI, and pipeline code, then hand them to human reviewers to certify.
- Context Engineering Studio: the workspace where teams build, test, review, approve, deploy, and learn on the context layer before agents reach production.
- Context Repos: versioned, portable, model-agnostic context bundles with policy embedded, so certified context is reused across coding and analytics agents and preserved for audit.
- AI asset registry: a governed inventory of every model, agent, and prompt, linked to the data it uses.
- MCP, API, and SQL activation: Atlan’s MCP Server is the governed endpoint that delivers certified context into Copilot, Cursor, Claude Code, and analytics agents, enforcing what an asset means, whether it is fresh enough, and which policies apply before context reaches the agent.
A real customer proof point: grounding agents in shared context
Permalink to “A real customer proof point: grounding agents in shared context”The clearest evidence is what happens when an agent is grounded in shared, certified context instead of raw schemas.
"Atlan captures Workday's shared language to be leveraged by AI via its MCP server. As part of Atlan's AI Labs, we're co-building the semantic layer that AI needs."
- Joe DosSantos, VP Enterprise Data & Analytics, Workday
"Atlan is our context operating system to cover every type of context in every system including our operational systems. For the first time we have a single source of truth for context."
- Sridher Arumugham, Chief Data Analytics Officer, DigiKey
The pattern generalizes beyond a single agent. Across 50+ enterprise customers, Context Agents have generated 690,000+ descriptions, with 87% rated on par with or better than human-written ones. At one customer, Context Agent work automated an estimated 1,279 hours, roughly $128,000 or close to a full-time role, of manual context effort. That is the difference between an agent that guesses at your definitions and one that reads them from a certified source.
Moving forward with AI agents for the SDLC
Permalink to “Moving forward with AI agents for the SDLC”The path to reliable SDLC agents is an architectural one, and it runs through context, not through a better model. Start by building the shared context layer: the canonical definitions, the column-level lineage, the policies, and the decision history that each lifecycle stage depends on. Then point your agents at it.
Begin where the payoff is clearest and the risk of a wrong answer is highest, usually the data and analytics-engineering stages where a bad join breaks a real number. Ground those agents in certified context, prove the accuracy gain, and use that baseline to extend context to coding, testing, and maintenance agents across the lifecycle. As intelligence commoditizes, the function-specific context you build and keep is the compounding advantage. Context is IP. Keep yours.
FAQs about AI agents for the SDLC
Permalink to “FAQs about AI agents for the SDLC”What are AI agents for the SDLC?
Permalink to “What are AI agents for the SDLC?”AI agents for the software development lifecycle are autonomous or semi-autonomous systems that participate across requirements, design, coding, testing, deployment, and maintenance. They include coding copilots, test-generation and code-review agents, CI/CD agents, and data and analytics-engineering agents that act on pipelines, SQL, and semantic models. Unlike a single code assistant, they operate across the whole lifecycle, and their reliability depends on the context they can reach at each stage.
Why do SDLC agents need more than a database schema?
Permalink to “Why do SDLC agents need more than a database schema?”A bare schema tells an agent that a column exists, but not what it means, where it comes from, which policies apply, or what breaks if it changes. Agents that reason from schemas alone hallucinate definitions, pick wrong joins, and miss cross-platform dependencies. They need schema and semantic awareness, column-level lineage, breaking-change impact, trusted metric definitions, and the tribal knowledge that explains edge cases.
What context does each SDLC stage require?
Permalink to “What context does each SDLC stage require?”Requirements and design need canonical business definitions, entity relationships, and prior decisions to scope the right thing. Coding needs downstream impact and governed context so generated changes respect contracts. Testing and deployment need active lineage, blast-radius analysis, and current policies to validate what a change affects before it ships. Maintenance needs fresh schema, ownership, quality signals, and decision history so agents do not drift into silent failure.
How is this different from AI agents for software engineering?
Permalink to “How is this different from AI agents for software engineering?”AI agents for software engineering focus on the coding practice itself: how agents plan, write, review, and deploy code reliably. AI agents for the SDLC take a wider view of the lifecycle as a process and the context an agent needs at each stage, with a strong data and analytics-engineering emphasis. The two are complementary. The software-engineering guide is the coding-practice deep-dive, and the ADLC vs SDLC guide explains how building agents differs from building software.
How does Atlan help AI agents across the SDLC?
Permalink to “How does Atlan help AI agents across the SDLC?”Atlan is the Context Layer for AI: the governed layer between fragmented development and data systems and the agents that act on them. It unifies schemas, column-level lineage, ownership, quality, and definitions into one Enterprise Data Graph, uses Context Agents to mine descriptions and metric definitions from SQL history and BI, lets teams build and certify context in the Context Engineering Studio, and activates that context into Copilot, Cursor, Claude Code, and analytics agents through MCP, API, and SQL.
Sources
Permalink to “Sources”- Accelerate State of DevOps Report 2024, DORA (Google Cloud)
- 2024 Accelerate State of DevOps Report Shows Pros and Cons of AI, InfoQ
- AI — 2024 Stack Overflow Developer Survey, Stack Overflow
- Research: Quantifying GitHub Copilot’s impact on developer productivity and happiness, The GitHub Blog
- AI is eroding code quality, states new in-depth report, DevClass
