Nikki Siapno recently shared something that caught my attention: "SDLC Agent vs Specialized Agent vs Subagent. Most teams still treat these as competing ideas, but they actually describe different layers of how agent systems are built." That framing is the rare kind that makes a messy debate suddenly feel solvable.

In AI tooling conversations, I often hear teams argue for a single winner: "We need one end-to-end coding agent" versus "No, we need lots of small agents" versus "We should just spawn subagents for everything." Nikki’s point is that these are not mutually exclusive product choices. They are architectural layers. And once you see them as layers, you can design systems that are both usable and reliable.

Below, I’m expanding on Nikki’s mental model, adding practical examples and a few design heuristics you can apply whether you’re building internal developer agents, evaluating vendor tools, or just trying to keep your team from drowning in orchestration.

The three layers Nikki outlined

Nikki’s breakdown is concise and useful because it ties each layer to its real purpose:

"End-to-end SDLC agent = product promise"

"Specialized agents = reliability strategy"

"Subagents = scaling mechanism"

That is the key. Each layer optimizes for a different constraint. Confusion happens when teams expect one layer to do the job of another.

Layer 1: The end-to-end SDLC agent is the product promise

Nikki described an end-to-end SDLC agent as "one surface that plans, codes, tests, reviews, and ships" and noted it is "optimized for low context switching and clear ownership." This is the interface most users want. Developers do not want to open five different chat threads and stitch together an outcome. They want one place to say: "Take this ticket and get me to a PR I can trust."

In practice, an SDLC surface is a unifying workflow:

It starts from intent (a Jira issue, a GitHub issue, a support ticket).
It gathers context (repo structure, coding standards, prior similar changes).
It proposes a plan (milestones, files to touch, risks).
It executes (code changes, tests, docs).
It verifies (lint, unit tests, integration tests, security checks).
It hands off cleanly (PR description, reviewers, rollout notes).

The main benefit is not that the agent can do everything perfectly. The benefit is that users know where to go, and the system has a single "owner" for the outcome.

The risk Nikki called out matters: "becomes a generalist unless backed by strong tooling, guardrails, and verification." A single agent that tries to be great at everything often becomes mediocre at most things, especially under real production constraints like secrets access, dependency drift, flaky tests, and ambiguous requirements.

So the SDLC surface should be judged like a product: clarity, flow, and accountability. But you should not expect it to be the deepest expert in every domain.

Layer 2: Specialized agents are the reliability strategy

Nikki described specialized agents as having "narrow scope," "clear success criteria," and "tighter permissions," and said they are "great for code review, security, migrations, testing." This is where engineering teams should lean into specialization, because reliability is usually a function of constraints.

A few concrete examples of specialized agents that tend to work well:

Code review agent

A review agent can be trained or prompted against your team’s standards and enforcement rules:

"No breaking changes without a migration plan"
"Public APIs require docs updates"
"All new endpoints need authz checks"

It can run deterministic checks too: static analysis, pattern matching, dependency diffing, and test selection. Because it is not also trying to plan features or write product copy, it stays focused.

Security agent

Security work benefits from limited permissions and strict playbooks. A specialized security agent can:

scan diffs for risky patterns
verify secret handling
enforce dependency policies
propose least-privilege changes

It should not need broad write access to the repo. In many orgs, it should not have any write access at all.

Migration agent

Migrations are repetitive, high-impact, and easy to partially complete. A migration agent can be scoped to:

enumerate impacted files
apply mechanical transformations
update tests
produce a report of what it changed and what it could not change

Again, narrow scope makes it safer and more measurable.

Nikki also noted the risk: "orchestration overhead and fragmented context." This is real. If a developer has to manually coordinate five agents, the system becomes work. You trade away the SDLC surface benefit.

The design goal is not "more agents." The goal is "more reliability with fewer surprises." That requires good orchestration and shared context.

Layer 3: Subagents are the scaling mechanism

Nikki framed subagents as "a way to decompose work and run tasks in parallel," with benefits like "enforce constraints," "isolate context," and "speed things up." This is the part many teams overlook: subagents are not necessarily user-facing roles. They are internal execution units.

Think of subagents like a manager delegating tasks to specialists, except the manager is your SDLC surface:

Subagent A: search the codebase for relevant patterns and prior implementations
Subagent B: run tests and summarize failures
Subagent C: draft a PR description and rollout checklist
Subagent D: check compliance requirements for this change

Parallelism is the obvious win, but isolation is just as important. Subagents can operate with smaller context windows and narrower permissions, which reduces accidental leakage of sensitive data and reduces "prompt sprawl" where everything influences everything.

The risk Nikki mentioned is also familiar: "coordination failures and integration bugs." Parallel work creates merge conflicts in logic even when there are no Git conflicts. Two subagents can make locally reasonable changes that violate an invariant when combined.

This is why subagents need contracts:

input: the exact artifacts they are allowed to use
output: a structured result (diff, checklist, pass-fail, evidence)
constraints: what they must not do
verification: how their work is accepted or rejected

Without contracts, subagents become a source of entropy.

The "winning" combination: one assistant, many constrained experts

Nikki’s conclusion is the architectural answer: "the real question isn’t which type is best. It’s how they’re combined." And for most teams, the pattern looks like:

"An end-to-end SDLC surface users interact with"
"Internally delegating to role-locked specialized subagents"

This is the sweet spot because it matches how teams already want to work:

One place to start and one place to finish.
Many internal checks that raise quality and reduce risk.
Shared context and standards, but with permissions and responsibilities segmented.

If you are evaluating an AI developer tool, ask these questions to see whether it matches Nikki’s architecture:

Is there a single SDLC surface that owns the outcome, or am I orchestrating manually?
Are specialized capabilities actually constrained (permissions, scope, success criteria), or just marketing labels?
Are there explicit subagents behind the scenes to parallelize work, or does everything happen sequentially in one blob of context?
What are the verification steps, and are they mandatory before shipping?

A practical example: tying the surface to your system of record

Nikki mentioned this is the direction Atlassian Rovo Dev is built for, "anchored in Jira and Confluence, with specialized capabilities and explicit subagents under the hood." Whether you use that tool or not, the design principle is worth copying: anchor the SDLC surface to your system of record.

When the agent is anchored to your tickets, docs, and standards, it can:

start from a real requirement, not a vague prompt
pull the right context automatically
produce outputs that fit your team’s workflow (PRs, status updates, rollout notes)

This is what makes the shift "not more AI" but "better agent architecture." The differentiator becomes how well the system routes work to constrained experts and verifies results, not how confident the chatbot sounds.

Closing thought

Nikki’s post is a reminder that architecture beats hype. If your agent strategy is stuck in "one big brain" versus "a swarm of bots," this layered model is a better map. Build a great SDLC surface for usability. Add specialized agents for reliability. Use subagents to scale execution safely.

And then measure it like engineering: cycle time, defect rate, security findings, reviewer load, and rollback frequency.

This blog post expands on a viral LinkedIn post by Nikki Siapno, Eng Manager | ex-Canva | 400k+ audience | Helping you become a great engineer and leader. View the original LinkedIn post →