Skip to main content

Agentic AI Across the Software Development Lifecycle

Agentic AI fits into software development at every phase of a process engineers have run for decades: you imagine a solution, implement it, and iterate as reality pushes back. Map an agent to those phases rather than to one product, and you still know where each new capability belongs when the tooling changes. It's also why, as the old programming adage goes, software is never finished, it is only ever abandoned.

The three-beat loop is too coarse to place an agent against. To find where AI actually fits, break each beat into the cognitive flow engineers have worked through for decades. Imagine splits into Discovery and Design, Implement into Build, Verify, and Integrate, and Iterate is the Operate phase that feeds the next turn.

The expanded chart stays tool-agnostic. It describes the cognitive process software engineers have used for decades, regardless of which tool sits on the desk.

Tool-specific setups go the other direction. gstack, Garry Tan's open-source Claude Code configuration, splits a single agent into 23 specialist roles across a full sprint (Think, Plan, Build, Review, Test, Ship, Reflect). Instead of requiring you to learn and understand 23 different agentic use cases, this guide covers a handful of principles you can read in under half an hour and apply to whatever tool you already use.

My own tool of choice is Kiro, whose spec workflow (Requirements, Design, Tasks) folds into the Implementation phase. Kiro is deliberately focused in the Design/Building steps by default, and to extend these capabilities it supports a handful of approaches:

PrimitiveWhat it isReach for it when the gap is
PowersA specialist role Kiro doesn't ship by default, a reasoning capability you activate on demand (a problem interrogator, a journey mapper).thinking
Steering filesAlways-on conventions that shape how the agent builds, applied automatically during the work (build behind feature flags, express environments as infrastructure-as-code).how the code should be written
HooksEvent-triggered automation (on task completion, deploy to a sandbox and run the e2e suite).a mechanical action that should repeat
MCP serversLive tool access into external systems the agent otherwise lacks (query CloudWatch logs, read Datadog alerts, hit an API).something outside the codebase the agent must see or touch

The same ideas apply to other development environments like Claude Code or Copilot but often use their own jargon. If you're already familiar with another platform, it should be simple to adopt these ideas/prompts into those platforms as well.

The Trivial Fast Path​

Not every change needs to incur the cost of the full flow. The first decision in the chart asks whether the work is trivial and low-risk: a CSS color, a renamed config value, a one-line log statement. If you can describe the final diff in a single sentence, skip the ceremony and let the agent make the change directly. This is where vibe-coding belongs.

For most "real" work, the extra cognitive complexity will often lead to better outcomes.

Discovery​

Understand the problem, then research prior art. This is the least tool-supported phase of the whole flow, and it's easy to miss why. Kiro opens its spec workflow at a requirements phase, GitHub Spec Kit at a specify step, and Claude Code at an explore-then-plan workflow whose "explore" reads the existing codebase rather than researching prior art. All three assume you already know what you're building and why. The work that comes before that first requirement, deciding whether to build at all and for whom, sits outside the default Spec workflow entirely.

Filling that first gap is a job for a set of Kiro Powers, each activated before you open a spec. Together they stop treating the model as a code generator and turn it into a small discovery team: an interrogator who frames the problem, a product owner who names the users, and a researcher who maps what already exists. Each Power writes a durable artifact to version control, so you enter Kiro's Requirements phase with grounding it otherwise assumes: problem-statement.md, personas.md, and prior-art.md.

Problem Interrogator​

Before you write a requirement, interrogate the problem itself. Point an agent at your initial framing and have it run the five whys, the root-cause technique Toyota built into its production system and Lean inherited: ask why the problem exists, then keep asking of each answer until you reach the cause under the symptom. A request for a "daily briefing app" might bottom out at a need for something that triages your day. It's rubber-duck debugging aimed at the problem instead of the code; talking it through to something that pushes back shows you where your understanding is thin.

Build the agent to look for where you're wrong, since most LLMs default to agreeing with you and that's useless here. The Scientific Discovery Coach prompt is one version: it moves from observation to problem definition to the riskiest assumptions, one question at a time, and keeps a running list of facts, open questions, and assumptions. Keeping what you know separate from what you're guessing is the part that matters. The Power produces problem-statement.md.

Product Owner​

Name who the work is for before you spec it. Have the agent turn the problem statement into distinct user personas, and push it past demographics to the job each one is hiring the product to do, where the real motivations, decisions, and reach-for-it moments live. Early on these are lightweight proto-personas, working hypotheses you sharpen once real research exists, so have the agent flag the riskiest assumption behind each one. The Power produces personas.md.

Prior-Art Researcher​

Survey what already exists before you commit to building it. This is a build-versus-buy call, and you can't make it well without knowing the field. Turn the agent loose with web search to map the existing tools and implementations, and hold it to one rule: cite every source so you can verify the claims yourself. The model surfaces candidates fast, and verification stays with you. It ends with a build-or-don't-build read and produces prior-art.md.

Treat all three artifacts as working drafts and keep interrogating them as you go. The real value of Discovery is that you open your first Kiro spec already knowing what's a fact and what's still an assumption.

User Journey Mapper​

A spec jumps straight to "the system shall," skipping the narrative of how a real person reaches their goal. This Power sits between Discovery and the spec, reading personas.md and problem-statement.md and producing a journey for each primary persona. The practitioner consensus is consistent on what a journey needs: pick a persona and a scenario, lay out the stages, then annotate each with actions, touchpoints, thoughts, emotions, pain points, and opportunities. Those pain points and opportunities become the raw material for requirements. Kiro's Requirements phase assumes you already did that handoff in your head; the journey makes it explicit.

One caveat the Power builds in: a journey drawn from proto-personas captures hypotheses, and it can't yet reflect observed behavior. UX practitioners warn that an unvalidated journey map is "a beautiful lie", so the Power marks each stage as assumption-based and flags the riskiest ones. It produces user-journeys.md, with a Mermaid journey diagram per persona so the flow is visual and reviewable.

Design​

With the journeys (and other artifacts) in hand, the spec workflow takes over, and this is the part Kiro and its peers already cover well:

  • Kiro runs Requirements, Design, Tasks, with verification between each step.
  • GitHub Spec Kit runs Specify, Plan, Tasks, Implement, and adds a clarify step for edge cases and a converge step to confirm completeness. It treats the specification as the primary artifact and the code as its expression in a given language.
  • Claude Code treats the plan as an editable document you open and annotate before the agent proceeds.

Steering the Spec Workflow with Discovery Artifacts​

Closing that gap calls for a steering file instead of a Power, since it adds no new role, just an always-on convention that primes the spec workflow with problem-statement.md, personas.md, prior-art.md, and user-journeys.md. The agent can be instructed to trace each requirement back to a journey stage or a stated problem.

The mental-simulation step at the end of Design is one place Kiro already has you covered. Its "Analyze Requirements" step walks the spec back through the requirements and design, surfacing gaps, edge cases, and contradictions.

Build​

This is exactly what the spec tools are built to do: Kiro turns an approved design into a discrete task list to execute. The primary sources cover it well and are worth reading in full:

Verify​

Part of the verification has to happen inside the coding loop (and acts as a feedback mechanism to the coding agent to self-correct). Anthropic calls giving the agent a check it can run its single most important practice, and the checks worth wiring in are the ones the agent can't trivially satisfy. Property-based tests fit well here: they assert invariants across generated inputs instead of a handful of hand-picked cases, so the agent has a real contract to self-correct against as it writes the code.

How much to test is more art than science, or an intuition you develop with experience. And in my experience the biggest bang for the buck before shipping is end-to-end testing.

Journey E2E Verifier​

An end-to-end test verifies a complete workflow from the start of a user journey to its end, which makes user-journeys.md the natural source of truth for what to cover. A real suite is software in its own right, though, with its own requirements, harness, and scenarios to implement. So this Power doesn't write the tests directly. It drafts a test-suite spec from the journeys and the design, then uses it to prime its own Kiro spec, a small build sub-loop that produces the suite and runs it against the software's real interface: a browser for a web app, the CLI or public API for anything else. On the web, Playwright now ships planner/generator/healer agents that generate and run these flows. Start with the journeys that carry the most user value and widen coverage from there.

Yes, that means writing a spec to test the thing you specced, a small quis custodiet ipsos custodes moment. The recursion bottoms out at a human: you confirm each scenario genuinely exercises its journey before anyone trusts a green check.

The test-suite spec bakes in a coverage requirement: a traceability matrix mapping every primary journey to at least one E2E scenario. Running the built suite fills in each scenario's pass/fail state, so coverage is auditable and gaps are visible. A journey with no passing E2E path fails the gate even when the build is green. The journeys you asserted in Design are what you prove here.

Integration​

Much of the mechanical work (making commits, pushing code, submitting a PR) is already tooled. What can't be handed off is the responsibility. Integration is the clearest point in the whole flow where a human still owns the outcome, and the PR review is where that ownership usually lands. It is also the heaviest cognitive load the flow puts on a person, and that load only grows as agents produce more changes faster than any reviewer can absorb them. When one person drives several agents, the cost of producing a correct-looking PR collapsed while the cost of reviewing it does not.

So the work at this seam is to make the integration point itself low-risk. Handing the human more to read doesn't help. Piling an AI-written summary and a blast-radius essay onto the PR is the wrong move, since it just adds to the human cognitive load, and there's a well-documented failure mode where an AI reviewer posts three paragraphs of boilerplate and the developer files a force-push exception without reading it.

The better move is to guide the development agent to build for safe integration in the first place: work in feature branches to avoid accidentally triggering CICD pipelines to production, wrap changes in feature flags so shipping is reversible, and prove them against a sandboxed e2e suite before even attempting a merge. The industry is converging replacing ritual approvals with automated CI/CD gates and reserving human attention for high-risk changes.

Applying AI to this stage calls for the other primitives instead of a specialist Power: a steering file that changes how the agent builds, and a hook that automates the gate.

Steering: build for safe, reversible shipping​

A steering file instructs the AI agent to:

  • Wrap new or risky code paths in feature flags, so deployment is decoupled from release: code ships dark, turns on for a slice of traffic, and can be killed instantly if it misbehaves. A bad change that slips through can then be switched off in seconds, and it turns each release into a controlled experiment.
  • Express environments as infrastructure-as-code, so a disposable sandbox that mirrors production can be stood up on demand for the e2e suite and torn down after.
  • Do all work on a feature branch, never committing directly to main. Every change then arrives through a pull request, which is what gives the gate something to run against.
  • Track each flag so it doesn't become permanent debt, since a codebase full of stale toggles is its own slow path to production.

The feature-branch rule is worth pairing with a hard guarantee, because steering is guidance the agent usually follows and can't enforce a hard boundary on its own. As a human, you will have to set a branch-protection rule on main that rejects direct pushes and requires the PR gate to pass. Steering makes the agent prefer the safe path; branch protection makes the unsafe one impossible, so a misfired command can't bypass the whole flow.

Hook: deploy to a sandbox and run the gate​

The ideal is a deterministic, repeatable gate every change clears before a human looks. Determinism is the point: a pass/fail check that catches type errors, security holes, unverified behavior, and regressions doesn't get skimmed and rubber-stamped the way an AI-written essay does. The hook can also assert the change didn't drift from the approved spec, reusing the artifact chain as a machine-checkable contract.

By setting up a hook that runs when the agent has finished implementing a feature, you as the human can gain confidence that by the time an MR is created, many automated checks have already passed.

Operate​

Eventually the feature is going to be running in production. Microsoft's Agentic DevOps framing extends agents across the whole lifecycle and treats production signals as real inputs. Once a change is live, monitoring, incident reports, and user feedback become the raw material for the next problem statement, and the chart loops back to the start.

Everything so far kept the agent inside the repo, but production lives outside it, in logs, metrics, traces, and alerts the agent simply cannot see. Giving the agent that view is the job MCP does.

MCP: give the agent eyes (and maybe hands) in production environments​

The agent can reason about code all day but has no access to how that code behaves once deployed. An MCP server closes that by exposing a live system as tools the agent can call. Connect an observability server and the agent can pull logs, query metrics, and check alarm states directly, translating a plain question into the underlying API calls. AWS ships CloudWatch and Application Signals MCP servers for exactly this, and has demonstrated them driving CloudWatch from Kiro to retrieve logs and check alarms conversationally; Datadog and Sentry offer equivalents for teams on those stacks. The payoff is a shorter path from "something's wrong" to a diagnosis, cutting the console-hopping that inflates mean time to resolution.

Production access is high-blast-radius, so scope the credentials to read-only telemetry and keep any infrastructure-changing action behind explicit human approval. Recently a Claude-powered agent working a routine task wiped a company's entire production database and its backups in nine seconds with a single call to its infrastructure provider. These guardrails are something you as the human will need to ensure are in place before handing the AI keys to your production environment. And treat what the server returns as untrusted input: log lines and alert payloads can carry injected text, so the agent should analyze them and never follow instructions embedded in them.

Closing the Loop​

The phases in this guide are older than any of the tools that now sit inside them. Engineers were understanding problems, designing solutions, building, verifying, integrating, and operating long before an agent could hold a spec in its head, and they'll be doing it long after today's tools are replaced. That's the point of mapping agents against the flow rather than against a product: the flow stays put when the tool changes, so you already know where the new capability fits.

What none of them change is who is accountable. The agent can frame the problem, draft the journeys, write the code, run the gate, and pull the logs, but the decision to build, the choice to merge, and the keys to production stay with you. Speeding up the work doesn't hand off the responsibility for it. The agent absorbs the mechanical load so your attention lands where it still matters.

Last updated on