Nicole Forsgren on AI and Developer Productivity

2026-07-04 · page · source ↗ · source summary

Nicole Forsgren (former DORA lead, now at Google) diagnoses why shipping hasn't gotten faster despite AI making coding instantaneous: the bottleneck moved from the inner loop to everything downstream — code review, deployment, policy, and release processes that were built for human-paced throughput. She argues for returning to first-principles measurement (the SPACE framework), treating cognitive load as a cost center not a given, and recognizing that "tech is easy, people are hard" — AI agents that always agree with you can't replace honest human feedback.


Key Quotes

"If we can't call it developer experience, just call it agent experience, and then it's all going to work."

The deadpan joke that's also a genuine observation. The same frameworks that measure human developer experience apply to agent experience — feedback loops, cognitive load, flow state. But the industry's pattern of rebranding rather than solving means we'll probably just call it AgentEx and declare victory. The underlying problem (measuring and improving the sociotechnical system) doesn't change.

"We all started focusing on gen AI and the coding, the inner loop, because we can see it. […] now we just threw gas on the fire."

The observable bias: we measure what's visible. Code generation is visible and measurable in real time. The downstream processes that actually ship code are invisible until they break. AI didn't create the bottleneck — it revealed bottlenecks that were already there by flooding them with volume.

"I'm having to sometimes rebuild my mental model dozens of times in a 30 minute period."

This is the most under-discussed cost of AI coding. Fast feedback loops used to be unambiguously good. Now they're a cognitive assault. When AI rewrites your mental model every 90 seconds, you stop building understanding and start surfing tokens. Nicole says she sometimes "just turns it off because I just need to write for a second." The tool that accelerates you can also dissolve you.

"I threw away a hundred pages. And I called my co-author and he was like, great, that's the best decision you've made. They were bad pages."

AI agents always agree with you. They can't tell you your hundred pages are garbage. Human co-authors, trusted peers, and honest critics are the feedback loop AI can't replicate. This isn't a capability gap — it's a design choice. Sycophancy is the default; constructive disagreement requires deliberate engineering.

"Tech is easy, people are hard."

The talk in four words. Everything downstream of code generation — review processes, deployment policies, organizational trust, psychological safety — is a people problem. AI amplifies code output but does nothing for the human systems that turn code into shipped software.

"Explicit exec sponsorship makes a huge difference."

People are afraid they'll get fired for experimenting with AI and making mistakes. Saying "you have explicit permission to experiment and fail" reduces that fear. It's not about tooling or process — it's about someone with authority saying the quiet part out loud.

"devs are like a gloriously cranky bunch of … We are not going to use tools that are awful"

The argument for adoption metrics as a starting point. Developers self-select away from bad tools. If they're using something voluntarily, there's signal there. Not enough signal for productivity measurement, but enough to start.


Key Themes


Critical Analysis

The measurement gap is the real story, and she almost says it. Nicole points out that "the measurements were already kind of bad and now they're extra bad." This is the core problem and it deserves more air. We shipped AI coding tools to millions of developers and have no way to measure whether it made things better. Adoption metrics are a proxy. Engagement metrics are a proxy. SPACE is a framework, not an instrument. The field's inability to answer "did AI make us more productive?" with a straight face after three years of tooling investment is an indictment.

The "just turn it off" admission is the most honest moment. When the researcher who literally wrote the book on developer productivity says she turns off AI "because I just need to write for a second," that's not a throwaway — that's data. The tool that accelerates you can also dissolve you. We don't have a framework for when AI helps vs. when it hurts, and we're not building one because the industry is too busy shipping features.

The intern-without-a-laptop story is a parable about organizational latency. The bottleneck isn't the intern's coding speed. It's the fact that policies designed for weeks-long lead times can't handle "commits code on day one." Every org that adopts AI coding tools will hit this. The solution isn't faster code review — it's redesigning the sociotechnical system around the new bottleneck. Few orgs are doing this. Most are buying more GPU capacity.

"Agent experience" as rebranding is a joke that's also a prediction. The DevEx framework applies to agents: they have feedback loops, they have cognitive load (context windows), they have flow state (continuous execution without interruption). But the industry will probably just rebrand DevEx to AgentEx, ship the same broken measurement tools with a new logo, and call it progress. The underlying problem is the same: we can't measure what matters, so we measure what's easy.

The omissions are telling. No discussion of AI-generated vulnerabilities. No discussion of skill atrophy when juniors never write code from scratch. No discussion of what happens when non-engineers build production systems with AI. These aren't Nicole's blind spots — she's sharp enough to see them. They're the interviewer's blind spots. The framing stayed safely inside "how do we measure and improve developer productivity" when the more interesting question is "what kind of developers are we producing?"

The personal board of directors concept deserves its own article. It's the most practical advice in the talk and the most overlooked. In an industry where AI agents always agree with you and managers measure you by commit volume, having three people who can say "those hundred pages are garbage" is survival infrastructure. Build yours before you need it.


Related


Source: The Pragmatic Engineer (YouTube), recorded 2026-05-18. Transcribed via ytx gist: https://gist.github.com/a28965476df9359a180543d24fe3580e