If you want to talk about developer productivity in the AI era, you have to talk about delivery performance. DORA metrics remain a stubborn reality check because they measure throughput and stability rather than volume: change implementation time, deployment frequency, change failure rate, and recovery time. The SPACE framework is also useful because it reminds us that productivity is multidimensional, and “feels faster” is not the same as “is faster.” AI often increases satisfaction early because it removes the drudgery. That matters. However, satisfaction can coexist with poorer performance if teams spend time validating, debugging, and refactoring AI-generated code that is verbose, subtly incorrect, or inconsistent with internal standards. For a manager-friendly measure that requires honesty, track time to satisfactory deployment: the time elapsed from when work is “ready” to actually running the software in production with required security, traceability, and policy controls.
This is the part the industry is still trying to dance around: AI makes the freedom problem worse. Gergely Orosz argues that as AI writes more code, engineers move up the ladder of abstraction. The task shifts from writing to revising, integrating and executing architectural decisions. That sounds like a promotion. Hooray, yeah? Maybe. In practice, this can be a burden because it assumes a level of systems understanding that is unevenly distributed across the team.
When this problem is complicated, creation becomes cheap, coordination becomes expensive. If you let each team use AI to generate custom solutions, you end up with a tangled blanket of stacks, frameworks, and operational assumptions. Everything might look good in pull requests and unit tests, but what happens when someone has to integrate, secure, and run it? At that point, the organization slows down, not because the developers can’t write, but because the system can’t cohere.