If you want to talk about developer productivity in the AI era, you have to talk about delivery performance. The DORA metrics remain a stubborn reality check because they measure throughput and stability rather than volume: lead time for changes, deployment frequency, change failure rate, and time to restore. 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 boosts satisfaction early because it removes drudgery. That matters. But satisfaction can coexist with worse performance if teams spend their time validating, debugging, and reworking AI-generated code that is verbose, subtly wrong, or inconsistent with internal standards. If you want one manager-friendly measure that forces honesty, track the time to compliant deployment: the elapsed time from work being “ready” to actual software running in production with the required security controls, observability, and policy checks.
This is the part the industry still tries to dance around: AI makes the freedom problem worse. Gergely Orosz argues that as AI writes more of the code, engineers move up the abstraction ladder. The job shifts from writing to reviewing, integrating, and making architectural choices. That sounds like a promotion. Hurray, right? Maybe. In practice, it can be a burden because it assumes a level of systems understanding that is unevenly distributed across a team.
Compounding the problem, when creation becomes cheap, coordination becomes expensive. If you let every team use AI to generate bespoke solutions, you end up with a patchwork quilt of stacks, frameworks, and operational assumptions. It can all look fine in pull requests and unit tests, but what happens when someone has to integrate, secure, and operate it? At that point, the organization slows down, not because developers cannot type, but because the system cannot cohere.
