Moving away from Agile — ADLC — For years, Amazon’s Two-Pizza Team symbolized how modern software should be built: small, autonomous teams, fast feedback loops, and clear ownership.

That model is breaking.

Not because small teams failed — but because software itself has changed.

We are entering an AI-Native era, where systems don’t just execute code; they reason, plan, act, and adapt. In this world, teams are no longer just groups of humans writing code. They are humans + agents, operating across a new lifecycle.

This post brings together:

• Insights from an Amazon-inspired talk on AI-native teams
• IBM’s Agent Development Lifecycle (ADLC) and Model Context Protocol (MCP) architecture
• Real-world lessons from shipping agentic systems

The conclusion is clear: 👉 The Two-Pizza Team is evolving into an Agent-Augmented Product Cell.

From PRDs to Specs to Executable Intent

In the Amazon talk (linked below), one idea stands out:

Product Managers will no longer write PRDs. They will write executable specs — consumed by coding agents.

The emerging team structure looks like this:

Role Responsibility Product Manager Defines intent, constraints, outcomes — not UI flows.

Lead Builder Owns architecture, system boundaries, and agent design. Senior Builders Translate intent into specs, tests, guardrails Junior Builders (Human + AI) Generate code, tests, migrations, docs

Coding agents now:

• Scaffold services
• Generate tests
• Implement APIs
• Refactor aggressively

Humans focus on correctness, security, system shape, and judgment.

This shift demands a new lifecycle. Traditional SDLC or DevSecOps is not enough.

Enter ADLC: Agent Development Lifecycle

IBM formalizes this shift with ADLC — Agent Development Lifecycle.

ADLC acknowledges a hard truth:

AI agents are non-deterministic systems that must be governed continuously — not “shipped and forgotten”.

IBM’s ADLC consists of six phases, with two continuous feedback loops.

The ADLC Phases (IBM)

1. Plan

• Define agent goals, behaviors, and constraints
• Specify what tools the agent may use
• Decide data boundaries and security posture
• Treat prompts, tools, and policies as first-class artifacts

This is where “PRDs” die and Specs are born.

2. Build

• Implement tools as MCP servers (typed, auditable)
• Define agent instructions, personas, fallback logic
• Package agents as reproducible artifacts (containers, configs)

Agents are assembled, not hand-coded.

3. Test & Release

• Regression tests for reasoning, not just outputs
• Hallucination & abuse testing
• Champion / Challenger evaluations
• Human-in-the-loop gates

This phase replaces “QA” with behavioral validation.

4. Deploy

• Agents run behind an MCP Gateway
• Centralized:
• AuthN / AuthZ
• Policy-as-code
• Rate limits & kill-switches
• Least-privilege access to tools
• Sandboxed execution (gVisor / Firecracker / seccomp)

5. Monitor

Traditional metrics are insufficient.

You now monitor:

• Token cost per workflow
• Tool invocation patterns
• Drift in agent behavior
• Safety signals
• Reasoning traces

Observability becomes a governance primitive.

6. Operate

• Re-certify agents as environments change
• Rotate credentials and permissions
• Retire agents safely
• Maintain agent catalogs with ownership & evidence This is where enterprises prevent Shadow AI.

Why MCP Matters

IBM’s architecture leans heavily on Model Context Protocol (MCP).

MCP turns tools into:

• Typed interfaces
• Auditable contracts
• Policy-enforceable endpoints

Instead of agents calling random APIs, they operate inside a controlled capability graph.

This is how enterprises avoid:

• Prompt-based data exfiltration
• Privilege escalation
• Tool misuse amplification

Security Is Not Optional

IBM identifies four primary risks in enterprise AI agents:

1. Privilege Escalation
2. Data Leakage
3. Attack Amplification
4. Behavioral Drift

ADLC addresses these via:

• Identity-aware agents
• Just-in-time permissions
• Sandboxed execution
• Continuous evaluation

Security shifts left and right — into planning and runtime.

What This Means for Teams

The implication is profound:

Teams are no longer sized by pizzas. They are sized by decision bandwidth.

A small group of senior builders, armed with agents, can:

• Replace entire layers of manual delivery
• Ship faster without sacrificing safety
• Continuously evolve systems post-deployment

The bottleneck is no longer coding. It is judgment, architecture, and intent clarity.

AI-Native Is Not About Speed — It’s About Shape

AI-native development is not:

• “Vibe coding”
• “Let the LLM handle it”
• “Fewer engineers”

It is:

• Spec-driven development
• Lifecycle-aware governance
• Agents as production systems
• Humans as system designers

The Two-Pizza Team isn’t dead.

It has mutated. Agents are great at producing plans. Shipping requires selectively saying “yes” to correctness, clarity, and DX — and “not now” to everything else.

References & Further Reading

🎥 Video

• AWS AI-Driven Development talks (ADLC) https://www.youtube.com/watch?v=SZStlIhyTCY
• McKinsey SoftwareX on Moving away from agile — AI-native teams
• Kilo Spec-Driven Development https://kilo.ai/docs/contributing/specs/

📘 IBM

• Architecting Secure Enterprise AI Agents with MCP (Oct 2025) https://www.aigl.blog/architecting-secure-enterprise-ai-agents-with-mcp-ibm-oct-2025/
• IBM watsonx.ai — Agent Development https://www.ibm.com/products/watsonx-ai/ai-agent-development

📐 Links

• https://ampcode.com/@sqs — GitHub acts as the system of record, while coding agents capture execution history and persist prompts for traceability.