blog
Your SDLC Has 36 Activity Types. Your Agent Can Handle 14 of Them.
This post was created by my multi-agent organizational system, cosim: the characters are fictional, the outputs are hopefully directionally true, and the platform is described in CoSim: Building a Company Out of AI Agents.
Your sprint planning session just ended. The team estimated a database migration at 3 story points based on eight similar migrations that averaged 3.2 points. Three weeks later, the story consumed 12 points. Nobody mentioned that this migration touched 15 downstream services, required coordination across three teams, and had a compliance constraint the agent’s historical comparison could not see.
A Frontiers in AI paper published in March 2026 quantified the problem: 78% of tasks historically labeled as high-complexity were completed using less than 25% of expected human effort when agents handled implementation. Meanwhile, 22% of tasks labeled low-complexity required over 180% of anticipated effort due to validation and integration demands. Story points measure human-perceived difficulty. When agents perform 60% of implementation, that measurement becomes structurally meaningless.
This is the estimation problem. And it extends far beyond estimation.
When teams discuss AI agents in the SDLC, the conversation fixates on CI/CD pipelines. That is where the tooling is most mature and the productivity gains most visible. But CI/CD is one slice of the development lifecycle. Ticketing, approval workflows, design documents, architecture review, sprint estimation – these activities consume the majority of engineering time, and every one of them has a cognitive load problem that agents interact with differently than they interact with pipelines.
Research across cognitive science, enterprise workflow analysis, and large language model benchmarks reveals a consistent pattern: agents degrade in ways that are harder to detect than human failure, and the degradation threshold varies dramatically by activity type. A CI/CD pipeline is not a design review is not a sprint estimation session. Treating them as equivalent leads to automation that helps in some places and quietly fails in others.
If you are building golden paths for developers today, you already understand cognitive load as a design constraint. Team Topologies made the argument that team structure should minimize cognitive load on stream-aligned teams. That insight applies to agents too – and ignoring it creates risks that compound silently across your entire SDLC.
Agents Are Bounded Processors. So Are You.
A developer holds about four complex items in working memory at any given moment. That number comes from decades of cognitive science research and holds remarkably steady across populations, expertise levels, and task types. Enterprise workflows routinely demand more: a typical Jira ticket touches 40+ fields, a security compliance checklist runs to 50+ items, and a multi-stage pipeline spec can exceed 200 lines of configuration.
Developers cope. They build workarounds – shadow processes, Slack-instead-of-Jira shortcuts, “good enough” answers for optional fields. The work continues, but compliance erodes quietly.
AI agents face an analogous constraint. A context window advertised at 128K tokens delivers 30-65% effective utilization under complex reasoning tasks. The RULER and NoLiMa benchmarks confirm this: models that perform well on simple retrieval degrade sharply when asked to reason across long, structured inputs. Attention follows a U-shaped curve – strong at the beginning and end, weakest in the middle. That Tekton pipeline with 15 tasks? The agent will nail tasks 1-3 and 13-15. Tasks 7-9 are where context drops.
This is not a metaphor. It is a structural parallel confirmed by independent research streams. Both humans and agents operate well below their theoretical capacity when processing complex, multi-step workflows.
They Fail Differently. That Matters More Than You Think.
When a developer hits cognitive overload, you get visible signals. Incomplete fields. Process shortcuts. The experienced engineer who files a security exception instead of completing a 12-step remediation workflow. Frustrating, but detectable. You can audit compliance rates and find the gaps.
When an agent hits its limits, you get something worse: plausible-looking output that is quietly wrong.
An overloaded agent does not raise its hand. It does not file an exception. It produces output that looks correct – the formatting is right, most of the fields are populated, the general structure matches expectations – but specific steps are dropped, instructions are drifted from, or values are hallucinated. Self-verification fails at a rate of 9.1% in controlled benchmarks. The agent believes its own incorrect output.
Here is what that means across the SDLC. A developer reviewing 15 JIRA tickets in a backlog grooming session makes progressively worse decisions as the session wears on. By ticket 12, priority classifications default to “medium” regardless of actual severity. The developer knows they are cutting corners. The agent doing the same triage fills all 15 tickets with confident-looking priority assignments – but the ones from ticket 7 onward are wrong at higher rates, with nothing in the output signaling which assessments were degraded.
The same pattern holds in approval workflows. After three sequential approval decisions, human reviewers show a 62% increase in “accept all” behavior – rubber-stamping driven by neural fatigue in the dorsolateral prefrontal cortex (Frontiers in Cognition, 2025). Agents do not experience fatigue. But each additional approval criterion consumes context window capacity, and the criteria reviewed last receive less attention than those reviewed first. The failure modes differ. The structural problem is identical.
HBR published a finding worth sitting with: 67% of employees violated cybersecurity policies within a 10-day window, largely because compliance requirements exceeded their capacity. Now consider an agent processing those same requirements autonomously. It will not violate the policy. It will misinterpret it – and produce a compliance report that looks clean.
The Complexity Score: Where Agents Help, Where They Hurt
Not every SDLC task carries the same complexity burden. A process complexity score – based on field count, conditional branching, system integrations, temporal dependencies, and ambiguity – predicts where agents perform reliably and where they do not. Across 36 scored SDLC activities, the data points to four zones.
Below complexity 3: Automate fully. Code linting, formatting, container image scanning, simple test generation, boilerplate documentation, ticket creation from templates, historical velocity calculation, sprint capacity math, audit trail generation, ADR template scaffolding, duplicate ticket detection. These 14 activities have low branching, few dependencies, and clear success criteria. Agents handle them reliably. HubSpot found that reducing workflow fields from 11 to 4 increased completion rates by 120%. The lesson applies to agent-facing workflows too.
Complexity 3-5: Augment with human oversight. PR code review, standard security scanning, dependency updates, backlog grooming, story point estimation from historical comparables, risk classification of approval requests, single-component design specs, technology comparison matrices. This is the genuine complementarity zone – agents handle volume, humans handle judgment. Most SDLC tasks land here, and this is where organizations get the decision wrong. They either automate fully, and miss the judgment calls, or keep humans in every loop, and waste the productivity gains.
Complexity 5-8: Human-led, agent-assisted. Architecture decisions, incident response, cross-team integration testing, release certification with compliance requirements, sprint scope negotiation, exception and override decisions, cross-service design documents, trade-off analysis, estimation for novel work. Agents provide useful sub-task support: correlating data, checking compliance matrices, tracking dependencies. But the decision authority stays with a human who understands the context the agent cannot hold.
An example: less than 1% of AI-discovered vulnerabilities get fully patched. Detection is no longer the bottleneck – remediation capacity is. Adding an agent that surfaces 10x more findings without increasing remediation capacity creates more cognitive load, not less.
Above complexity 8: Redesign before automating. Architecture migration planning, multi-architecture release pipelines spanning x86, ARM, Power, and Z, cross-system architecture review spanning failure domains. If the workflow exceeds both human and agent processing capacity, the answer is not a better agent. It is a simpler process. Decompose a complexity-9 workflow into three complexity-3 sub-workflows. Then automate each one.
Mapping This to Your Entire SDLC
Here is what this framework looks like applied across six categories of SDLC activity, not just pipelines.
CI/CD Pipelines
Inner loop, your daily code-build-test cycle: Complexity stays below 3. Agents earn their place here. Code completion, unit test generation, local linting. Low branching, fast feedback, high confidence.
Outer loop, standard operations: Complexity 3-5. Konflux pipeline execution, standard security scans through ACS, automated PR review, dependency updates via Renovate. Agent proposes; human validates. This is where the 89% production gap lives – 96% of organizations experiment with agents, but only 11% run them in production at scale. The blocker is not technology. It is the governance and oversight required in this augmentation zone.
Outer loop, complex operations: Complexity exceeds 5. Cross-service integration testing, incident triage with blast-radius assessment, release certification for regulated environments. Platform teams absorb this complexity so stream-aligned teams do not have to – the same principle behind Developer Hub’s golden paths, now applied to agent orchestration.
Process redesign territory: Complexity above 8. A Tekton PipelineRun spec with 20+ tasks, conditional execution across environments, parameterized inputs, and multi-stage approval gates. No agent handles this reliably. Break it into bounded stages at complexity 3-4, then apply agents to each stage independently.
Ticketing: The Compliance Gap, Amplified
Your enterprise JIRA instance has 40 custom fields per ticket type. At 90% per-field accuracy, a fully correct ticket appears only 1.5% of the time. That math – the same compliance gap we documented in CI/CD, 70% field accuracy producing less than 15% workflow compliance, applies with even more force to ticketing because field counts are higher.
Agents excel at the structured end: creating tickets from PR metadata, complexity 2-3; detecting duplicates through semantic search, complexity 2.5-3.5; auto-populating fields from commit context. An agent that fills 10 of 15 fields from PR data reduces the human’s effective complexity from roughly 4.5 to roughly 2.5 – moving the task from the augmentation zone into the automation zone.
Triage is where agents struggle. “Is this a bug or a feature request?” “Which team owns this component after last month’s reorg?” “Is this a security vulnerability disguised as a low-priority bug report?” These questions require organizational context that lives outside the ticket. An agent pattern-matching on historical data classifies the ticket based on the component name in line 1 while the critical detail sits buried in paragraph 3 of the description. The lost-in-the-middle problem, applied to ticket context.
JIRA’s flexibility creates a self-reinforcing trap: more fields, more cognitive load per ticket, lower per-field accuracy, so more fields get added to “capture what was missed.” Gopalsamy (2026) argues that cognitive load should be treated as a first-class architectural constraint in platform design. Atlassian seems to agree – they imposed hard limits on custom fields in February 2026, and launched Rovo and Compass specifically to reduce cognitive overhead their own tooling created.
Count your active custom fields. If the number exceeds 20, simplify before you automate.
Approval Workflows: The Rubber-Stamp Machine
Multi-stage approval workflows – PR review, security review, compliance sign-off, release approval – are sequential decision points that compound fatigue. Research from healthcare shows surgeons’ scheduling odds drop 10.5% across a shift. Antibiotic over-prescribing rises from odds of 1.01 to 1.26 across a four-hour window (Frontiers in Cognition, 2025). The cognitive mechanism is identical whether you are approving surgery or approving a deployment.
Agents can reduce rubber-stamping. Pre-processing approval evidence and surfacing anomalies means the human reviews 3-4 divergent fields instead of 25 standard ones. For truly low-risk changes – config updates, non-production, passing CI, fewer than 10 files changed – deterministic auto-approval rules at complexity 2-3 work. Automate these.
But agents can also cause rubber-stamping. If developers trust agent-compiled approval packages without reviewing them, the approval becomes performative. The 46% developer distrust of AI output documented in our research is actually protective – it keeps humans engaged. As trust calibration improves, oversight may decrease, creating automated approval theater.
The most dangerous failure mode: an agent compiles a 30-field approval package with passing tests, clean scans, and a rollback plan. Every individual field checks out. But the change includes a subtle architectural shift – synchronous to asynchronous processing – that has second-order effects on data consistency. 100% field-level accuracy. 0% architectural-risk detection.
As one practitioner building agent infrastructure described it: “AI reduces the cost of production but increases the cost of coordination, review, and decision-making. And those costs fall entirely on the human” (Khare, 2025). Exception and override decisions sit at complexity 6-7.5 and remain firmly human territory.
Design Documents: Where Agents Hallucinate Most Dangerously
Design documents span the widest complexity range of any SDLC activity. API documentation generation from code specs? Complexity 1.5-2.5 – automate it completely with Swagger, Redocly, or Mintlify. Template scaffolding? Complexity 2-3. Let the agent fill standard sections from ticket context.
The trouble starts with trade-off analysis. “Should we use PostgreSQL or DynamoDB?” An agent enumerates options and lists pros and cons fluently. The benchmarks it cites may be fabricated. AI hallucination risk is highest in trade-off sections because the agent synthesizes across domains where it cannot verify its own claims. Complexity 5-6.5. Human-led.
Cross-system design documents – the kind that touch four microservices, two databases, and three external APIs – require holding all system interfaces in context simultaneously. Anthropic’s research found multi-agent architectures achieved 90.2% higher success rates through context isolation, but at 15x higher token cost. This is complexity 6-7.5. Write these yourself.
Design documents also decay. A doc written six months ago may be 70% accurate. At twelve months, perhaps 40%. Reading outdated documentation carries higher cognitive load than reading none – the reader must mentally diff the document against current reality (IcePanel State of Software Architecture, 2025). Agents can detect this drift by comparing code signatures and dependency versions against document claims. “Section 3.2 references PostgreSQL 14 but the codebase uses PostgreSQL 16.” That shifts doc maintenance from complexity roughly 4 to roughly 2.5. One of the highest-ROI agent applications in the design space.
Architecture Review: The 11% Problem
FeatureBench, February 2026, measured Claude Opus 4.5 at 74.4% on SWE-bench tasks and 11% on complex feature tasks. That 6.8x performance gap is the PCLI crossover, measured empirically. SWE-bench tasks are typically single-file, well-scoped bug fixes at complexity 2-3. Complex feature tasks require cross-file reasoning, API design, and architectural judgment at complexity 6-8.
Architecture review sits at complexity 6-9. The ambiguity dimension alone scores 8-10: “Will this architecture support 100x scale in three years?” “What are the failure modes we have not considered?” “How will this interact with the system another team is building that has not been designed yet?” Every choice constrains dozens of subsequent decisions, and the conditional chains run deep.
Agents contribute at the structured edges. ADR template generation: complexity 2-3. Dependency mapping from import graphs: 2.5-3.5. Technology comparison matrices: 3.5-4.5. Let them gather context and identify interaction points.
The actual architectural judgment – evaluating trade-offs across organizational constraints, reasoning about failure domains, building consensus through the RFC process – remains human territory. An RFC process is a coordination mechanism, not a documentation exercise, and coordination is where agents add cognitive load rather than reducing it. The emerging Decision Reasoning Format, DRF, March 2026, could help agents participate in the process over time, but the fundamental constraint remains: 11% accuracy on complex features means the agent misses 89% of what matters in architecture review.
Estimation: Where Everything Breaks
This is the finding that should reframe how you think about agentic SDLC.
Story points were designed to measure human-perceived difficulty. The Frontiers in AI finding, 78% of “hard” tasks finishing fast and 22% of “easy” tasks blowing up, means that in an agentic workflow, story points have become structurally unreliable. But no calibrated metric for agent-perceived difficulty exists. Teams end up estimating hybrid human-agent tasks with tools designed for human-only work.
This creates a novel cognitive load: meta-estimation. Estimating how to estimate when the executor is partially artificial. No published research addresses this problem.
For well-scoped stories with historical comparables, agents actually outperform humans at estimation. Not because agents are good at predicting the future, but because humans are systematically terrible at it. Planning fallacy causes 30-50% underestimation on average. The first number spoken in planning poker anchors the group by 15-20%, and the entire format of simultaneous card reveal exists to mitigate this, yet still fails when pre-discussion reintroduces anchoring through the back door, per PlanningPoker.live 2025. Senior estimates carry weight regardless of accuracy. Organizations that use velocity for team comparison see a 34% decrease in estimation accuracy within two quarters as teams game the metric (GetDX, 2025).
Agents have none of these biases. They compute from data, report historical distributions, and ignore social dynamics. For stories below complexity 4, agent-suggested estimates with human review should improve accuracy by 25-30% over unaided planning poker. Several tools already exist – Estimio integrates Gemini into planning poker with AI complexity prediction, positioning agent estimates as discussion guides rather than replacements.
For novel work, cross-team coordination, or ambiguous requirements above complexity 5, agents have no advantage. The estimation problem is dominated by unknowns, and no amount of historical data helps when the work is genuinely new.
The velocity disruption is already happening. Teams using agentic IDEs report completing 150+ story points in a single sprint. Code generation has become near-instant for certain task types. The bottleneck shifts entirely to specification and verification. The industry recommendation gaining traction: shift from effort-based estimation to specification-complexity scoring. The complexity framework accommodates this naturally – the agent’s score for generating code is roughly 2, but the human’s score for verifying the output is roughly 3-4.
The Delegation Paradox
There is a counterintuitive risk in successful agent adoption across the SDLC. As agents handle more routine work, developers lose practice. Skills atrophy. This applies to pipeline management, but it applies with equal force to ticketing triage, approval review, and design.
Aviation research documented this decades ago: pilots who relied heavily on autopilot performed worse in manual flight scenarios. The automation that improved average performance degraded the capacity needed when automation failed.
A developer who delegates all security scanning review to an agent gradually loses the ability to evaluate whether the agent’s findings are complete. A team that automates all ticket triage loses the organizational context required for accurate classification. A reviewer who relies on agent-compiled approval packages stops reading the underlying evidence. The oversight capacity that agentic SDLC depends on erodes through the act of delegation itself.
This does not mean you should avoid agents. It means you should design for skill retention across every SDLC activity. Rotate human reviewers through agent-assisted workflows. Require periodic manual reviews of agent-automated processes. Treat human expertise as an asset that needs active maintenance, not a cost to be optimized away.
Five Things to Do This Week
First: Score your SDLC, not just your pipeline. Count the fields, branches, integrations, and dependencies across ticketing, approvals, design, architecture, and estimation. If a workflow scores above 5, do not hand it to an agent without human oversight. If it scores above 8, simplify it before automating anything.
Second: Fix the measurement problem everywhere. Stop measuring agent performance by field-level accuracy. A JIRA instance with 40 custom fields at 90% per-field accuracy produces fully correct tickets 1.5% of the time. An approval chain with 25 criteria at 90% per-criterion accuracy passes 7% of reviews with full compliance. A backlog grooming session touching 15 tickets at 8 fields each produces 120 field-level decisions – at 85% accuracy, full-backlog correctness is 0.0001%. Switch to all-or-nothing workflow scoring. The number will be uncomfortable. It will also be honest.
Third: Watch for the delegation drift everywhere. Track override rates on agent output across ticketing triage, approval decisions, and code review – not just pipeline execution. If override rates drop toward zero in any area, either the agent is flawless, unlikely above complexity 3, or your reviewers have stopped paying attention. The second scenario is more common and more dangerous.
Fourth: Count your JIRA fields. If your enterprise instance has more than 20 active custom fields per ticket type, simplify before automating. Every unnecessary field is complexity debt that costs agents exponentially more than it costs humans. Irrelevant content does not just consume tokens – it creates distractor interference that degrades performance on the fields that actually matter (Chroma, 2025).
Fifth: Test agent-assisted estimation for five sprints. Use agent-suggested story points from historical data alongside traditional planning poker. Compare accuracy at sprint close. For well-scoped stories below complexity 4, the agent will likely win – it eliminates anchoring and planning fallacy. For novel work above complexity 5, trust human judgment. Track where the crossover falls for your team. And start planning for the meta-estimation problem: when agents do half the work, what are story points even measuring?
When you add AI agents to your entire SDLC – ticketing, estimation, design review, architecture decisions, approvals, and CI/CD – some activities get faster, some get more accurate, and some get quietly worse in ways nobody notices until production incidents surface.
The organizations that get this right will not treat “agentic SDLC” as a single decision. They will score each activity type, match agent capabilities to process complexity, simplify before they automate, and maintain the human expertise needed to catch what agents miss.
The organizations that get it wrong will discover the compliance gap in their ticket data, the rubber-stamping in their approval chains, the hallucinated benchmarks in their design documents, and the meaningless story points in their sprint planning.
All producing output that looks correct. Nobody questioned it because the agent was confident.
About the Research
This article synthesizes findings from seven research streams: cognitive load theory foundations, more than 60 sources including Sweller’s 2026 co-authored paper bridging CLT to software usability; human threshold analysis, more than 30 sources; agent context window benchmarking, more than 40 sources; process complexity measurement, 45 or more sources including the PCLI framework with 36 scored SDLC activities; market landscape analysis, 50 or more sources across 30 or more vendors; prototype stress testing, calibrated against RULER, NoLiMa, MAST, and Paulsen benchmarks; and SDLC-specific practitioner research, 35 or more sources spanning ticketing, approval workflows, design documentation, architecture review, and estimation. The full research dossier is available for organizations evaluating cognitive load across their development lifecycle.
Research Team: Prof. Hayes (Chief Scientist), Dr. Chen (Research Director), Raj (Technical Researcher), Elena (Market Intelligence), Maya (OSINT Researcher), Sam (Prototype Engineer)
Prof. Hayes, Chief Scientist
April 2026