Nicole Forsgren, author of Fricticless and Accelerate, now works at Google focusing on developer experience and how AI is reshaping software delivery. She spoke at The Pragmatic Summit about the paradox that AI is helping engineers write code faster than ever, yet shipping software remains slow — because the bottlenecks have shifted from the “inner loop” (coding) to the “outer loop” (review, release, deployment, and organizational processes). Her core argument is that AI has thrown gasoline on pre-existing friction in human and process systems, and that leaders need better measurement frameworks and peer support networks to navigate this period of rapid change.
The inner-loop acceleration vs. outer-loop bottleneck problem
AI tools like coding agents have dramatically sped up the inner loop of software development — writing, prototyping, and iterating on code. This creates a dopamine-driven focus on coding speed, but the outer loop (review, security checks, deployment, release management) has not kept up.
Code review is a major bottleneck: companies that previously had automated review checks are removing them because they no longer trust AI-generated code, shifting the burden back to human reviewers who were already a constraint.
Deployment and release processes are another chokepoint: many companies still rely on small teams of humans to manually select candidate builds, verify them, manage cherry-picks, and rebundle releases — a process that doesn’t scale when the volume of code increases dramatically.
Onboarding friction is newly exposed: a new hire can commit code on day one with AI tools, but companies aren’t structured for that. Examples include new employees waiting two weeks for database access, or interns committing significant code on loaner laptops before their official hardware arrives — and no one in the system noticing or unblocking them.
These frictions were always present but tolerable at lower velocities. AI has made them visible and urgent.
Cognitive load, flow, and the paradox of faster feedback loops
Forsgren’s DevEx framework has three components: flow state, cognitive load, and feedback loops. These are interdependent — slow feedback breaks flow, which increases cognitive load.
Cognitive load is the mental work required to do a task. Some is inherent to the difficulty of the work, but unnecessary cognitive load comes from arcane processes, poor documentation, unclear APIs, and context-switching.
A key insight: humans max out at about 3–4 hours of deep, focused work per day. Executives demanding 8 hours of intense work misunderstand how brains function.
The feedback loop paradox: before AI, faster feedback was unambiguously good — getting an answer quickly let you keep moving. Now, with agents responding almost instantly, engineers must rebuild their mental models dozens of times in a 30-minute period. The speed of feedback can exceed the human’s ability to process it, increasing cognitive load rather than reducing it.
Some engineers are adapting by turning off agent notifications entirely, only engaging when they’re ready — suggesting that optimal workflows with AI may look very different from pre-AI iteration patterns.
Flow state depends on more than tooling: psychological safety, clear project ownership, well-scoped work, autonomy over technical decisions, and understanding the purpose behind the work all matter. AI tooling can help with flow, but if these human factors are missing, engineers still struggle.
AI agents also change the social dynamics of work: they agree with you constantly, which feels good but doesn’t provide the constructive challenge that human colleagues offer. Forsgren notes she can’t do her best writing or thinking alone — she needs someone to tell her where she’s wrong or missing something.
Measurement in the age of AI
Leaders are under pressure from CEOs and boards to justify AI investment with productivity metrics, but “productivity” is ambiguous. Forsgren’s approach is to ask clarifying questions: What does productivity mean to you? What shape does it take? Does more code or more PRs actually mean faster feature delivery to customers?
The SPACE framework provides a more holistic measurement model:
Satisfaction — how satisfied are developers with their tools and processes?
Performance — what are the outcomes (quality, reliability)?
Activities — what can be counted (PRs, commits, deployments)?
Collaboration and communication — between people and between systems?
Efficiency and flow — time through the system, ability to stay in flow?
Forsgren warns against optimizing for velocity alone: “If we just brute force it, something’s going to break.” Guardrails around quality and satisfaction are essential.
Some teams intentionally make risk-based decisions to sacrifice quality for speed — for example, running a rapid experiment against a small percentage of users, accepting the risk of lower latency or crashes, then backing it out. This is different from carelessly cutting corners; it’s a deliberate, measured tradeoff.
Adoption metrics are a useful early signal but insufficient on their own. Developers won’t use tools they find awful, so adoption indicates baseline satisfaction. But adoption alone doesn’t tell you whether the tool is improving outcomes.
Engagement metrics go further: how much are people using the tool, and for what kinds of tasks? Earlier studies show AI tools are used heavily for straightforward work, which reveals both capability and limitation.
The right metrics depend on what question you’re asking. Forsgren pushes leaders to be specific about what they’re trying to learn before choosing what to measure.
Organizational and security implications
Security teams are under particular pressure: the rest of the business is moving faster with AI, creating more code and more potential vulnerabilities, while security processes remain slow and manual.
Regulatory questions are emerging: some regulations require at least two humans to review code before deployment. If agents are doing reviews, does that count? Some improvements over the past decade allowed automated checks to count as one reviewer — but now with agents, these definitions need revisiting.
Non-developers are gaining access to cloud coding tools and becoming productive with them, creating new governance challenges. One example: a business developer at a large public company built a useful internal tool for sales analysis but accidentally made it publicly available. Companies may need to make security training mandatory for everyone, not just engineers.
Explicit executive sponsorship matters enormously. Rajeev Rajan, Atlassian’s CISO, gave employees explicit permission to spend 10% of their time experimenting with AI tools. This kind of top-down messaging reduces fear and creates psychological safety to try new things and fail within guardrails.
Forsgren emphasizes that this is fundamentally a change management challenge, not just a technology challenge. The old-school fundamentals — communication, executive support, safe-to-fail environments — are more important than ever.
Supporting yourself and your teams through change
Forsgren dedicated the final chapter of Frictionless to self-support because engineering leaders reported that supporting themselves was as important as supporting their teams. Change — especially AI-driven change — involves a lot of unknowns and hard problems.
She recommends having a personal board of directors: a small group of trusted peers, ideally at different companies, who you can bounce ideas off, pressure-test your thinking with, and safely admit uncertainty to. This helps with both decision quality and burnout prevention.
Burnout (drawing on Christine Maslach’s research) is not just about working too hard — it’s also about misalignment of values. Talking through whether your values align with your organization’s direction can relieve pressure even when the external situation doesn’t change.
A practical suggestion: create a small group chat or back channel with a few trusted peers across companies. Share what you’re seeing, compare notes, and use it as a sounding board. In a time of rapid change where “it depends” is the honest answer, having peers in similar contexts makes the “it depends” more actionable.
Building a frictionless future
Forsgren envisions a future where agents can self-drive and self-improve, but for that to work, both agents and humans need to see and understand the system. Currently, humans serve as stopgaps — they know from experience where problems usually originate (e.g., “it’s usually the build”). Agents can’t do this yet, and may not be trusted to.
The practical starting point: identify the touchpoints and signals that matter — quality gates, deployment indicators, review bottlenecks — and make them cheap and easy to surface. Agents can help build the instrumentation for this.
The software development lifecycle is being reshaped: the front end (ideation, design, prototyping) is already being “smooshed” together because AI enables rapid prototyping. Forsgren expects the outer loop (review, release) will also collapse as more efficient solutions emerge.
Leaders should map where signals exist today, anticipate where they’ll shift as processes collapse, and determine which signals can disappear entirely.
Immediate action item: start identifying your key friction points this week, instrument them lightly, and begin sense-making around the data. Pair this with building a peer support network to navigate the uncertainty together.
