How cognitive overload is undermining the AI productivity promise, and what leaders must change in their development and product pipelines to fix it.
In the past three years, I’ve worked on GenAI enablement across financial services, first as a Chief Technologist at AWS, and now as SVP for our Mastercard’s Software Builders Experience program. And I keep running into the same problem. Different job families approach AI tooling through the lens of what they already know. The questions we ask are shaped by the problems we’ve solved before, and our imagination for what a tool can do is bounded by the scope we’re comfortable operating in. That knowledge gap isn’t abstract, it directly limits how teams consume AI.
At Mastercard, I’ve been working with an incredible group of people focused on re-imagining the SDLC and PDLC. We measure developer experience through CORE4, SPACE, DORA, and other frameworks. We’ve invested in giving our developers the latest tooling so they can move faster than ever. And like most of our industry peers, we introduced code assistants. The data we got back told us something we didn’t expect: code was moving faster from developer to pipeline, but revert rates spiked, PR sizes ballooned, and it became clear that our SDLC and PDLC flows were not built for AI-scale development.
Three pieces published in quick succession crystallized what I was seeing. Francesco Bonacci wrote about “Vibe Coding Paralysis”, the exhaustion of managing AI, not doing the work. BCG and Harvard Business Review published research quantifying “AI Brain Fry” across 1,488 workers. And Carlos Arguelles at Amazon declared the traditional testing outer loop dead. Each was describing a different facet of the same problem. None connected them. This article is my attempt to do that, and to propose what the SDLC and PDLC need to look like on the other side.
To be clear, this isn’t a victory lap. We haven’t implemented this yet. This is a framework we’re building toward, informed by what the data is already telling us and what these three pieces helped me crystallize. I’m publishing it now because I think the industry needs to have this conversation before the patterns calcify.
The Paradox: AI Makes Us Frantic, Not Fast
AI was supposed to make us faster. Instead, it’s making many of us frantic.
Across the software industry, developers spin up multiple AI coding sessions, watch features scaffold in minutes, and end the day exhausted, not from building, but from managing the building. Product managers generate roadmap scenarios, competitive analyses, and PRDs at unprecedented speed, yet struggle to commit to a single direction. The raw capability is real. The coherent output is not.
Bonacci’s description hit a nerve: “I end each day exhausted, not from the work itself, but from the managing of the work. Six worktrees open, four half-written features, two ‘quick fixes’ that spawned rabbit holes, and a growing sense that I’m losing the plot entirely.”
The BCG/HBR data put numbers to the feeling. Workers experiencing AI brain fry report 33% more decision fatigue, 39% more major errors, and a 39% increase in intent to quit.
The promise was amplification. The reality, for many, is fragmentation. And the root cause isn’t the technology, it’s that our development pipelines, role structures, and organizational incentives were designed for a world where implementation was the bottleneck. That world no longer exists. Coherence, judgment, and cognitive capacity are the new bottlenecks, and our systems haven’t caught up.
Directing vs. Chasing: The Divide That Explains Everything
Not everyone struggles equally with AI. Observing how different roles interact with AI tools reveals a critical distinction: some professionals naturally direct AI, while others end up chasing it.
Directing means approaching AI with a clear problem frame, defined constraints, and a mental model of what “done” looks like. The human steers; the AI executes within boundaries.
Chasing means reacting to AI output, re-prompting, re-planning, spinning up new streams, without a stable anchor point. The AI generates; the human scrambles to keep up.
This distinction maps unevenly across three key personas in software organizations.
The Solutions Architect: Natural Director
Solutions Architects operate at the altitude of system coherence,decomposing problems, defining boundaries, making tradeoff decisions. When an architect engages AI, they bring constraints: “Design a system that handles X throughput with Y latency, using Z technology stack, within these cost boundaries.” AI explores the solution space; the architect evaluates and decides.
Architects are the most resilient to AI-induced cognitive overload because their core value, system vision and judgment, remains firmly human. AI doesn’t erode their confidence; it validates their thinking faster.
The Software Developer: Most Vulnerable to Chasing
Developers face the sharpest disruption. Their traditional value proposition, writing code, is the layer AI has most directly commoditized. This creates a cascade of vulnerabilities.
The confidence spiral. When AI writes most of the code, developers begin questioning their own understanding. As Bonacci describes: “When something breaks, and something always breaks, you’re staring at code you didn’t fully write, solving a problem you didn’t fully understand, in a codebase that’s grown faster than your mental model of it.” The response? Prompt more. Defer more. Learn less. Spiral continues.
Maximum oversight burden. The BCG/HBR study found that AI oversight, not mere use, is the most cognitively taxing engagement pattern, producing 14% more mental effort, 12% more fatigue, and 19% more information overload. Developers bear this burden most directly.
Reactive parallelization. The tooling actively encourages it: worktrees, background agents, parallel sessions. On paper, velocity soars. In practice, attention fragments. The research quantified the cliff: productivity gains plateau and then decline after three simultaneous AI tools.
Misaligned metrics. When organizations measure lines of AI-generated code or token consumption as performance proxies, they structurally incentivize chasing, rewarding volume of AI interaction, not quality of AI-directed outcomes.
The HBR study’s most telling finding about developers: “The ones who are most advanced with AI start to feel blocked in progress unless they can develop critical new skills such as problem framing, analysis planning, and strategic prioritization.”
These are architect-level skills. Some senior developers do get there, I’ve seen some amazing Senior Principal Engineers who think and operate like architects, having built that muscle across different projects, products, and scales over the course of a career. But it’s the exception, not the norm, and it’s certainly not a path today most organizations deliberately cultivate. It should be.
The Product Manager: Chasing in Disguise
Product managers occupy a deceptive position. Their role, problem framing, prioritization, outcome definition, should make them natural directors. In practice, AI introduces a unique form of chasing that is harder to detect precisely because it looks like strategic work.
The planning loop on steroids. AI generates competitive analyses, personas, market sizing, and roadmap scenarios in minutes. Each artifact feels like progress. But the actual decision, what will we commit to building? Keeps getting deferred. Planning becomes procrastination in disguise.
The possibility explosion. For developers, AI expands what they can build. For PMs, AI expands what they can envision. The PM equivalent of six open worktrees is six roadmap variants, each plausible, none committed to. The old forcing function, implementation was expensive, so you had to choose, is gone. Decision paralysis fills the vacuum.
Validation theater. PMs can now synthesize user feedback and build business cases at extraordinary speed. The danger: AI becomes a justification engine rather than a discovery tool, confirming decisions already made, manufacturing the appearance of rigor without the substance of genuine inquiry.
Loss of customer intuition. When AI processes all your customer signals, you stop building the gut-level understanding that comes from sitting with messy, ambiguous, human feedback. PMs know what the data says but lose the feel for the customer, the intuition that was never in the data to begin with.
Why the Traditional SDLC and PDLC Can’t Handle This
The traditional Software Development Lifecycle was designed around a simple assumption: implementation is slow and expensive, so front-load planning to minimize rework.
AI inverts this. Implementation is now fast and cheap. But the pipelines haven’t adapted. Organizations are pouring AI-accelerated code through processes designed for human-speed development, and the seams are showing. Features ship faster than they can be validated. Code merges faster than it can be understood. Developers approve PRs for code they didn’t write and don’t fully comprehend, building what Bonacci calls “a house of cards, each card placed by a different Claude session, each card slightly misaligned with the others.” More gets built, but less coheres.
The PDLC faces a parallel failure. It assumes that deciding what to build is the hard, slow part, and that once decided, the build phase imposes natural discipline. With AI, the build phase no longer imposes discipline. PMs must create that discipline themselves, and the PDLC doesn’t help them do it.
The Validation Crisis Underneath
There’s a dimension of this breakdown that goes beyond cognition and roles, it’s infrastructure. Arguelles’ argument about the dead outer loop crystallizes the technical crisis hiding beneath the people problem.
For decades, software testing operated on a simple split. The inner loop, a developer’s local machine, ran unit tests in seconds, keeping you in flow state. The outer loop, CI/CD pipelines, integration suites, E2E environments, ran the heavier tests that caught catastrophic bugs at the seams between components. This split worked because humans wrote code slowly enough that a multi-hour CI/CD cycle was acceptable feedback.
AI broke this contract. Engineers generate code at an order of magnitude faster speed, but the outer loop didn’t get faster. More changes per day means more runs against the same fragile infrastructure, more flaky failures, more retries, more erosion of trust.
The problem goes deeper than throughput. AI-generated code has a characteristic failure mode: today it works in isolation but fails at the seams. The code is based on the context the AI has been given, typically a single file, a single service, a single component. It passes unit tests because they validate components in isolation, which is exactly the scope the model had when generating the code. But failures surface in integration, hours later, after context is lost, after other engineers have built on top of your changes.
This is the technical manifestation of the coherence problem. Each AI session has context for one component, not the system. And the infrastructure that should catch the misalignment, integration testing, is too slow, too flaky, and too late.
The cognitive cost compounds. When integration feedback arrives hours later through a flaky CI/CD pipeline, the developer has already moved on to other tasks, spawned new AI sessions, built more cards on the house. The late, unreliable signal forces them to context-switch back, debug whether the failure is real or environmental, and potentially unwind work that others have already built upon. The dead outer loop isn’t just a testing problem, it’s a cognitive load amplifier.
The AI-Era SDLC
The new pipeline must expand the phases where humans direct, compress the phases where AI executes, and introduce new gates where coherence is verified.
Problem Frame becomes the most important phase. Before any AI interaction, teams must articulate: What problem are we solving? What are the constraints? What does “done” look like? What is explicitly out of scope? This is the “directing” document. Without it, everything downstream becomes reactive. With spec-driven development, where humans and AI collaborate on requirements and design documents before generating code, the problem frame also becomes the source from which validation criteria are auto-generated.
Decompose becomes a first-class engineering activity. Systems are broken into bounded, well-scoped units with clear acceptance criteria. Each unit is small enough that a developer can hold it in their head, because that mental model is what prevents the confidence spiral. Critically, decomposition must also define the integration contracts between components, the seams where AI-generated code most frequently fails.
A word of caution: the pipeline diagram above implies decomposition happens once, upstream, as a planning activity. In practice, it’s iterative. You start with a decomposition, direct AI against the first unit, learn something about the integration surface you didn’t anticipate, and adjust the decomposition of the next unit. The best teams treat decomposition as a living artifact, not a phase gate you pass through once. The principle matters more than the sequence, and Bonacci’s version of that principle applies: “The plan doesn’t have to be perfect. It has to be done.”
Direct AI + Continuous Validation replaces both “Implement” and the traditional “Test” phase. Instead of generating code now and validating later, validation signals run continuously during development, in the inner loop. The developer directs AI within guardrails (maximum two to three concurrent streams, each scoped to a decomposed unit), and the pipeline provides integration and contract test signals in real time.
This requires four infrastructure investments: reliable test environments that eliminate the “is this real or environmental?” question (Google uses hermetic, ephemeral environments; Uber injects test traffic into production graphs); mutation-tested validation that measures what was actually verified, not just what was touched; smart test selection that analyzes what changed and runs only relevant tests (Meta’s implementation catches 99.9% of faulty changes while reducing test executions by 3x); and evaluation-based assessment that asks “does this achieve what the builder intended?” rather than just “does it pass?”
Coherence Gate is entirely new. Before merging AI-generated code, a human must demonstrate they understand it, not just that tests pass. The gate is strengthened by the continuous validation signals: developers have real integration feedback confirming the code works at the seams, not just green unit tests in isolation.
Evaluate reflects the most profound conceptual shift: the question moves from “does this code work?” to “does this change achieve what the builder intended and adds customer value?” As systems grow more agentic and non-deterministic, the same input can legitimately produce different outputs. You need judges that assess whether a response is appropriate, and critically, know when to escalate to a human.
The AI-Era PDLC
Discover goes deeper, not faster. AI can synthesize a thousand support tickets in minutes. The temptation is to accelerate discovery. The right move is to go deeper, use the time savings for qualitative work AI can’t do: observe users, develop intuition, sit with ambiguity. The HBR study found that using AI to eliminate toil reduces burnout by 15%. Use AI to remove the grunt work from discovery, not to skip discovery itself.
Frame demands sharper problem statements. Before any AI-assisted solution generation, the PM must articulate a tight problem frame: Who is the user? What is the pain? What is the measurable outcome? What is explicitly out of scope? This is the PM’s “directing” artifact. Without it, the development pipeline has no anchor.
Commit is an entirely new phase, and the hardest cultural change in the AI-era PDLC. In the old world, commitment was forced by implementation cost: you couldn’t build everything, so you had to choose. AI removes that forcing function. PMs must now impose commitment discipline themselves. Once a direction is chosen, alternatives are killed explicitly. No “keeping option B warm.”
Constrain is also new. PMs must define the cognitive budget for a feature, not just the scope. How many concurrent AI streams should engineering run? What’s the maximum PR size? What coherence checkpoints are required? This operationalizes the HBR finding that three-plus simultaneous AI tools degrade productivity. The PM doesn’t just define what to build, they define the cognitive parameters of how it gets built.
Co-Direct replaces the handoff. The old “throw the PRD over the wall” model assumed a slow build phase that naturally surfaced misalignments. With AI generating implementations in hours, the feedback loop between PM intent and engineering output must tighten dramatically. Structured checkpoints, not constant oversight, where the PM validates that system-level direction matches the problem frame.
Coherence Check gates launch. Not “does it work?” but “does it matter?” AI-accelerated development produces more features faster. Without this gate, products accumulate capability nobody asked for, built because it was easy, not because it was needed.
Measure Outcomes, not output. Velocity, features shipped, story points, these are now inflated by AI and effectively meaningless. Measure customer outcomes (adoption, retention, satisfaction), decision quality (how often do we build right the first time?), and product coherence (does the product tell a unified story?).
The Unified Pipeline: Three Altitudes of Direction
When the SDLC and PDLC are overlaid, the organizational design becomes clear. Each role directs at a different altitude, and the pipeline must enforce that each altitude does its job:
Product Managers direct at the outcome altitude. They own the problem frame and the commitment. Their job is to say what needs to be true for the customer, and to say no to everything else. Their problem frame also serves as the source for evaluation criteria: the specs from which intent-based validation is generated.
Solutions Architects direct at the system altitude. They own the decomposition and the boundaries. Their job is to ensure that what gets built coheres as a system, regardless of how fast individual pieces are generated. They also own the integration contracts, the interface definitions where AI-generated code most frequently fails, which feed directly into the continuous validation loop.
Developers direct at the implementation altitude. They own the AI interaction and the understanding. Their job is to ensure that code is not just functional but comprehended, that their mental model keeps pace with the codebase. The continuous validation loop gives them something the old outer loop never did: real-time integration feedback during development, not hours-late signals through flaky CI/CD.
The Coherence Gate is shared. All three roles must pass it: Does this solve the problem? (PM) Does this fit the system? (Architect) Do I understand this code? (Developer) This shared gate is the most important new artifact in the pipeline, backed not just by human assertion, but by evidence from reliable, mutation-tested, efficiently-selected test suites that validate both functional correctness and builder intent.
Six Organizational Imperatives
The pipeline changes won’t work without supporting organizational shifts. Drawing from BCG’s research that 70% of AI transformation effort should focus on people and processes:
1. Upskill for Direction, Not Just Execution. Developers need training in problem framing, decomposition, and strategic prioritization. The skills the HBR study identifies as critical for advanced AI users. This isn’t about making developers into architects. It’s about ensuring every role can direct at their altitude rather than defaulting to chasing.
2. Establish AI Spans of Control. Just as organizations define spans of control for managing humans, they must define limits for human-AI oversight. The research is clear: productivity declines after three simultaneous AI tools. Make this a policy, not a suggestion.
3. Shift Metrics from Activity to Impact. Incentivizing token consumption, lines of AI-generated code, or raw velocity produces waste, low-quality work, and unnecessary mental strain. Start from business objectives with measurable outcomes. And don’t rush to backfill work recently automated by an innovative team member, doing so immediately feels punitive and kills further innovation.
4. Make Managers Accountable for AI Enablement. The HBR data is unambiguous: workers whose managers actively answer their questions about AI had 15% lower mental fatigue scores. When managers expect employees to “figure it out on their own,” there’s a measurable 5% increase in fatigue, a small but real “AI orphan tax.” Manager engagement with AI isn’t optional; it’s a direct lever on team cognitive health.
5. Protect Cognitive Capacity as a Strategic Resource. Mental fatigue is more likely to go undetected than burnout in existing workplace surveys. Organizations must evolve people analytics to monitor cognitive load as a novel occupational risk. Build recovery time, deliberate non-AI thinking time, into sprint cadences, because sometimes the thinking is the work.
6. Invest in Continuous Validation Infrastructure. Every hour spent waiting for CI/CD, every flaky test debugged, every context-switch back to code you’ve already mentally left compounds the brain fry problem. Organizations must invest in reliable test infrastructure, meaningful validation, efficient execution, and evaluation-based assessment. This is not optional infrastructure modernization, it’s a prerequisite for every other change in this article. You cannot direct AI effectively when your validation signals arrive too late to act on.
The Bottom Line
The developer disadvantage isn’t about capability, it’s about operating altitude. Architects naturally work at the altitude where AI is directed. Developers were trained to work at the altitude where AI now operates. Product managers sit at the right altitude but lack the organizational structures to enforce the commitment discipline that AI demands.
The fix isn’t to transform every developer into an architect or every PM into a strategist. It’s to retool the SDLC and PDLC so that every role spends more time directing and the pipelines themselves enforce the guardrails that prevent chasing.
The organizations that will thrive in the AI era aren’t the ones that adopt AI fastest. They’re the ones that learn to direct it most coherently, across every role, at every altitude, through pipelines purpose-built for a world where the bottleneck is no longer building, but knowing what to build and why.
The tools are new. The failure modes are new. But the solution is ancient: discipline, focus, and the courage to commit, now encoded into the systems we use to build.
This is my practitioner’s view, shaped by what I’ve seen across financial services since the rise of GenAI and what I am learning at Mastercard in real time. I’d love to hear whether this resonates with what you’re experiencing. Are your teams directing AI or chasing it? Has your SDLC held up, or are you seeing the same cracks? Drop a comment or share your story, the more perspectives we bring to this, the faster we all figure it out.