更快，可是为了什么？Nicole Forsgren 谈 AI 时代如何衡量开发者生产力

Host Lenny Rachitsky welcomes Nicole Forsgren back two and a half years after their first episode, in which AI barely came up. Forsgren, creator of the DORA and SPACE frameworks and author of *Accelerate*, defines DevEx as what it is like to build software day to day, including friction, workflows and support. When it is poor, she says, the best processes and tools will not help.

She stresses that productivity is not just output, since high-toil or high-friction work eventually burns developers out, and high cognitive load leaves no brain space for innovation. She calls this a self-reinforcing loop: doing better work makes you do more work. It is good for people, for systems and for customers.

Asked about flow, which Rachitsky, a former engineer, loved most, Forsgren says DevEx has three key parts: flow state, cognitive load and feedback loops. Prompting, reviewing code and integrating it can interrupt flow. She has also seen senior engineers build tool chains where agents work on pieces in parallel, so the engineer stays in the flow of goals and architecture rather than line-by-line writing.

In the workflow she describes, the engineer first specifies the architecture, stack and workflow, then lets an agent per component work in parallel with instructions to use appropriate APIs and conventions. The result, she says, is a bit better than vibe coded, because the upfront planning was systematic. Rachitsky sums it up as spending a little time planning rather than powering through.

Asked how companies get AI productivity measurement wrong, Forsgren says lines of code was always a bad metric, but AI has blown it out of the water. Agents are verbose by nature, so it is easy to game and to add complexity and technical debt. The metric can still be useful if teams can separate human and AI code, which allows questions about code survivability, quality and whether machine-generated code is feeding back into fine-tuning.

She applies the same caution to DORA, which has two speed metrics (deployment frequency and lead time) and two stability metrics (MTTR and change fail rate). They still work for assessing overall pipeline speed and stability, but AI creates feedback loops much earlier and throughout the pipeline. So existing metrics cannot be applied blindly or they will miss important changes in how people work.

SPACE, by contrast, is a framework that does not prescribe metrics, and she says that is why it still fits: satisfaction, performance, activity, communication and collaboration, and efficiency and flow. She would add trust, because LLMs are non-deterministic and output must be checked for hallucinations, reliability and style. Even the share of work offloaded to a chatbot rather than a senior engineer is a signal, although more or less is not always better.

Rachitsky recalls that Forsgren predicted two and a half years earlier that engineers would spend more time reviewing code than writing it, and that trust in generated code would be a central issue. She says the shift is a chance to rethink not only workflows but also how days and work are structured, since attention now has to focus at different moments.

Speculating, she cites Gloria Mark's work on attention that humans get about four hours of good deep work a day. In the past, a four-hour block might yield two or three hours of focused work, but coding with AI is interrupt-driven. The open question is whether a four-hour block is still useful, and whether a 45-minute block can now work too, since the machine can help you back into flow by restoring context and generating diagrams.

Rachitsky frames this as every engineer becoming an engineering manager coordinating junior AI engineers, while the tools remind you where you left off. Forsgren calls it a ripe area for research and invites people to do it and report back.

Forsgren makes the business case for DevEx: software meets business needs such as market share and retaining customers, and good DevEx enables fast experimentation. Prototypes and A/B tests that once took a long time can now happen in hours. Her tactical advice for this week is to go talk to people and listen, rather than starting with tools and automation, which often means building the thing that is easy or that bothered you personally.

Her suggested question is to ask developers to walk through yesterday, including what was delightful, difficult, frustrating or slow. A handful of conversations often reveal low-lift fixes or an unnecessarily complex process. She tells of a company stuck on a mainframe process that nobody touched because replatforming was too big, where someone physically printed an approval and walked it down several flights of stairs. The fix was to send an email.

Asked about common improvements, she says almost every company has a process that can be improved without much engineering headcount. Large companies often keep steps because they always existed, while small ones can be too YOLO and benefit from a lightweight process. For business leaders, she says the role is to provide structure, communicate priorities and why they matter, and celebrate wins, because an isolated side project struggles to keep momentum.

Rachitsky notes none of this concerns specific technology, and Forsgren agrees that technical work, such as rethinking build and test systems and tailored feedback to users, is necessary but not sufficient, and does not have to be the starting point.

Asked how a founder knows whether the team is moving fast enough, Forsgren says most teams can move faster and that she knows of none that cannot. Signs of friction include constant talk of broken builds and flaky tests, overly long processes, painful environment provisioning, and difficulty switching tasks. If people avoid moving to another part of the company for unclear, non-political reasons, switching costs may be as high as a new hire's.

She cautions that speed has diminishing returns and says quality matters: "We can ship trash faster every single day." Strategy comes first, she argues, including what to ship, what to experiment with and in what order. Without it, faster delivery just means garbage in, garbage out.

AI can help refine strategy, messaging and experiment targets, and prototypes and customer-facing tests that once took months can happen in a day or two. But teams still need to build and test the right things. She suggests AI as a partner for deciding what data and instrumentation to use and then checking with data science teams so large tests do not disrupt users, break privacy or security protocols or yield unusable data.

Asked what gains she sees from AI, Forsgren says they are real but measures are immature. The best measure is velocity across the whole system, which is hard to tie to one tool. In one set of companies she knew of, regular users of AI coding environments produced significantly more code, and the engineers' own increase was double what the agent contributed. She sees AI as good at unblocking, rapid prototyping, unit tests and documentation, and notes that better docs and comments yield better AI performance.

She is publishing *Frictionless: 7 Steps to Remove Barriers, Unlock Value, and Outpace Your Competition in the Age of AI*, written with Abi Noda of DX. Rachitsky notes that DX, the developer experience company Noda started, was recently sold to Atlassian for a billion dollars, which he says shows how much companies value this area. Forsgren says it shows how much untapped potential there is.

The book is meant for technology leaders and anyone starting a DevEx program, and she thinks it is especially relevant for PMs, whose instincts engineering teams often miss. It will be at developerexperiencebook.com, with a free workbook of almost a hundred pages, and she expects it out by the end of the year.

The steps are: start the journey with a listening tour; get a quick win; use data to optimize the work, including surveys; decide strategy and priority; sell your strategy; drive change at your scale, whether grassroots, top-down or in the middle; and evaluate progress and show value, then loop back. She says you can jump in at any step but should start at step one if kicking off. The book adds practices on resourcing, change management, sustainable technology and a PM lens.

Forsgren stresses the term developer experience is deliberate: it is about unlocking value, not only output, and engineers solve problems better when given freedom. For a pilot, a few engineers plus a PM or program manager for communications can go after quick wins she calls paper cuts, such as cleaning up a test suite. With top-down backing, quick wins can be organization-wide, like replacing a cumbersome process or investing in cleaning up environment provisioning.

She has seen impact of hundreds of thousands of dollars at smaller companies and billions at large ones, but says the gains follow a J-curve: quick wins first, then a divot when obvious work is done and more infrastructure and telemetry are needed, after which benefits compound.

She advises framing results for each audience. Developers care about time saved, reduced toil, fewer manual compliance steps and more focus time. Leaders care about costs, revenue acceleration, time to value and velocity. A cleaned-up test and build suite means less rerunning to developers, but cloud cost savings to the business, and correlation with outcomes like market share is usually the best one can do.

Asked what to do today to understand the effect of AI tools, Forsgren says it depends on what leadership cares about. If they talk about market share, focus on speed, such as feature to production, customer or experiment. If they talk about profit margin, measure money saved, recovered headcount cost or reduced vendor spend. Mirroring their words, whether productivity, velocity or disruption, means they do not have to work to see the value.

For velocity she would take as broad a swathe as possible, such as idea to customer, and disclose attribution honestly: say that AI tools rolled out alongside a DevEx effort and both contributed. She suspects AI tools without DevEx improvements would have yielded some gains, but not nearly as many.

If starting from nothing, she recommends talking to people and then surveys, because instrumentation may be missing or built for another purpose. Her example survey asks about satisfaction, lets respondents pick just three biggest barriers, then asks how often each hits them, from hourly to quarterly, plus open text. She warns against double-barreled questions like asking whether build and test were slow or complicated, and suggests using Claude, Gemini or ChatGPT to review the questions and check what you could answer with the data.

Forsgren does not love happiness surveys, since happiness depends on work, family, hobbies and more. Satisfaction with tools, job and team is more useful and feeds into happiness. She jokes that happy devs make happy code, and says directly trying to influence happiness is too all-encompassing.

On tools, she says Copilot, Cursor, Gemini and Claude Code are huge. Rachitsky says he is writing about non-engineering uses of Claude Code, such as asking it to clean up laptop storage, and cites Dan Shipper calling it the most underrated AI tool.

Her closing advice is to bring a product mindset to DevEx and its metrics: identify a problem for a set of users, build MVPs, get fast feedback, have a strategy, communications and go-to-market, and consider sunsetting things. With AI changing so quickly, she says, it is worth asking whether a metric kept for ten years still drives useful decisions.

In the lightning round she mentions she is now senior director of developer intelligence and core developer at Google, focused on improving developer experience, productivity and velocity and on how measurement and feedback loops change. She uses ChatGPT and Gemini to render room redesigns, and points listeners to developerexperiencebook.com and nicolefv.com.