The DX Core 4, Explained: What It Fixes and What It Doesn't

Core 4 is an attempt to end the framework argument. Instead of choosing between DORA, SPACE and DevEx, it folds all three into four counterbalanced dimensions — Speed, Effectiveness, Quality and Impact — each with one headline metric and three supporting ones.

It solves a real problem: DORA was never built to measure developer productivity, and Nicole Forsgren, who created it, has said so repeatedly. Core 4 is the first serious attempt at a framework that survives contact with a CFO. It also makes one choice that a lot of engineers object to, and that objection is worth understanding before you adopt it.

What are the four dimensions?

The dimensions are designed to be oppositional. Laura Tacho of DX has framed the logic plainly: going faster while becoming less effective isn't a win, and business impact that comes with falling quality isn't one either. Each dimension is meant to act as a guardrail on the others.

Speed and Quality pull directly from DORA. Effectiveness pulls from DevEx and SPACE. Impact is the dimension none of the earlier frameworks handled well.

Why "diffs per engineer" instead of lead time?

Because lead time doesn't survive the trip to the boardroom.

This is the framework's most contested decision, and DX has been open about why they made it. Abi Noda's explanation is that lead time is well understood inside engineering and lands flat outside it — a CFO hears "lead time improved" and asks why that matters. "Each engineer ships 4.3 changes per week" moves the conversation forward.

The obvious objection is equally direct: diffs per engineer is trivially gameable by splitting pull requests into smaller pieces. The framework's creators acknowledge this openly and argue that the other three dimensions act as counterweights — you can inflate diff count, but not while holding change failure rate and DXI steady.

Whether that holds depends on your organisation. DX cites practitioners with experience running developer productivity programmes at large scale who report never encountering deliberate gaming. That's a real data point, and it's also a data point from organisations with mature engineering cultures. In an org where metrics feed performance reviews, assume the gaming will happen.

One rule that isn't optional: diffs per engineer is not tracked at the individual level. Every serious description of the framework repeats this. The metric is an organisational average, and the moment it appears on a one-to-one agenda the framework has been misused.

What is the DXI, and does the proprietary part matter?

The Developer Experience Index is an aggregated score built from a set of standardised survey items covering code quality, focus time, CI/CD friction, ease of delivery and similar drivers of daily work.

The catch worth knowing before you commit: the exact questions used to compute DXI are proprietary to DX. You can adopt the shape of Core 4 with any survey tool, but you cannot compute a comparable DXI outside their product, and you cannot benchmark against their dataset.

This creates a practical fork. DX recommends leaning primarily on surveys. Platforms like Swarmia argue for combining survey data with system data from your issue tracker and repository, on the grounds that survey-only measurement limits what the framework can tell you. Both positions are defensible; the important thing is knowing which one your tooling is quietly making for you.

Where does Core 4 still fall short?

Impact is the weakest dimension. Measuring the share of engineering time going to new capability versus maintenance depends entirely on how work is categorised in your issue tracker. If your Jira hygiene is poor — and in most organisations it is — this metric measures your tagging discipline rather than your investment allocation.

It doesn't solve AI attribution. Core 4 was designed before AI-assisted development became the dominant question, and it works on the same pipeline metadata and survey data as everything else. It can show you that quality moved after you rolled out coding assistants. It cannot tell you which changes came from those assistants.

It's a measurement framework, not a diagnosis. Core 4 tells you which dimension moved. Finding out why still requires the conversations, and no framework replaces that.

Adoption cost is real. Running it properly needs a repository integration, an issue tracker with usable categorisation, and a recurring survey with enough response rate to be meaningful. Teams that adopt the vocabulary without the survey layer end up with DORA plus a rebrand.

Should you use it?

It's the best available answer to a specific problem: you need one page of numbers that a non-technical executive can read, and you don't want that page to be actively misleading.

If your problem is different — you already know delivery is slow and you need to find the bottleneck — the framework isn't where to start. Cycle time analysis and a conversation with the people doing the work will get you there faster.

The honest summary is that Core 4 is a reporting framework that happens to contain diagnostic metrics, and it works best in organisations that already have somewhere to report to.

Frequently asked

Is Core 4 a replacement for DORA? No. It contains DORA metrics — change failure rate is its headline Quality metric, and DORA measures sit in Speed as supporting metrics. It's a superset built for a different audience.

Can I implement Core 4 without buying DX? Partially. The four dimensions and most metrics are public and can be assembled from your existing tooling plus any survey platform. The DXI specifically cannot be replicated, since its question set is proprietary.

Does Core 4 measure individual developers? No, and the framework is explicit about it. Diffs per engineer is calculated as an organisational average. Using it for individual comparison is the failure mode the framework's authors warn about directly.

Is diffs per engineer really gameable? Yes, in isolation. The framework's defence is that the other three dimensions constrain it. That defence is stronger in organisations where metrics inform decisions than in organisations where they inform performance reviews.