Engineering organizations spent the past decade learning to measure developer and team productivity. Measurement of the organization itself did not keep pace. Now that agents are responsible for writing most of the code across many engineering organizations, it’s more important than ever to have an effective methodology for measuring productivity.
DORA's 2025 State of AI-Assisted Software Development, a survey of roughly 5,000 technology professionals, found AI adoption close to 90% of respondents. AI adopters shipped more code than non-adopters in 2025, reversing the 2024 finding, and still had higher delivery instability. In DORA's 2026 ROI report, Nathen Harvey, DORA lead at Google Cloud, argues that the returns come from the surrounding organizational system, meaning internal platform quality, workflow clarity, and team alignment, and that without them AI produces localized gains that do not add up at the organizational level.
DX Core 4 and DRIVE answer different questions. Core 4 quantifies how productive your developers and teams are. DRIVE measures whether the engineering organization is getting more effective, and gives leadership a standing cadence to act on the answer.
The key points:
DX Core 4 (Noda, Tacho, Storey, Greiler, 2024) measures developer and team productivity across four counterbalanced dimensions: Speed, Effectiveness, Quality, and Impact.
DRIVE measures the engineering organization across five pillars: Delivery, Reliability, Initiatives, Vigilance, and Efficiency, and it folds in DORA's four delivery signals inside Delivery and Reliability.
Different altitudes. Core 4 sits at the developer and team level. DRIVE sits at the organizational level.
Different mechanisms. Core 4 stops at measurement. DRIVE couples its metrics to a recurring Operational Excellence review where leaders reallocate time, budget, and headcount against what the data shows.
What DRIVE measures
The DRIVE framework measures engineering organizational effectiveness in the age of AI. It asks whether the organization as a whole is sustainably turning customer needs into reliable, secure software at a reasonable cost (the core question of engineering operations as a discipline), and it does that across five pillars, each with a small set of critical metrics:
Delivery: the speed and sustainability of shipping, including deploy frequency, lead time for changes, and on-call pager volume as an early signal of delivery health.
Reliability: whether shipped software delivers on its promises to customers, grounded in functional SLO pass/fail rates and Sev0 and Sev1 incident counts.
Initiatives: progress on the cross-team strategic work that never shows up in any single team's metrics, tracked through Tier 1 milestone completion and OpEx action item completion.
Vigilance: the security and risk posture of the estate, including open Critical and High fixable CVEs, assets below the minimum security bar, and orphaned services with no clear owner.
Efficiency: where capacity and spend are going, including cloud spend against budget, internal AI and LLM token costs, and the percentage of engineering capacity spent on innovation rather than maintenance.
DRIVE also includes the Operational Excellence review, a recurring leadership meeting where engineering leaders interrogate the pillar data and reallocate resources against what they find. The engagement has direct precedent in similar reviews already run at Amazon, Stripe, and Google. With AI output increasing forward pressure on the SDLC and rendering many historic checks and balances (like manual code review) unsustainable, the OpEx review becomes one of the few remaining human-in-the-loop backpressure mechanisms keeping the team in alignment.
What DX Core 4 measures
DX Core 4 is a unified framework for measuring developer productivity that builds on DORA, SPACE, and DevEx. It was published by DX in December 2024, authored by Abi Noda, Laura Tacho, and the researchers behind SPACE and DevEx, Dr. Margaret-Anne Storey and Dr. Michaela Greiler.
The framework covers four dimensions:
Speed is throughput: PRs per engineer, lead time, deployment frequency.
Effectiveness is the environment engineers work in, measured through the Developer Experience Index (DXI). DX designed the DXI as the counterweight to raw throughput.
Quality is whether shipped software meets SLAs: change failure rate, incident count, availability.
Impact is where engineering time goes: percentage of time on new capabilities, feature time ratios.
The four dimensions contain sixteen metrics, some collected from systems and others from developer surveys and experience sampling.
Does DRIVE replace DX Core 4? No. It complements Core 4 by answering a different question at a different altitude.
How DRIVE and DX Core 4 differ
There are two major differences between the two frameworks.
Altitude. Core 4's atomic unit is the developer and the team. Its four dimensions describe how a team ships, the environment it works in, whether its output holds up in production, and where its hours go. DRIVE's atomic unit is the organization: whether cross-team initiatives are finishing on the timelines leadership committed to, whether risk is piling up faster than teams can work it down, whether capacity is flowing to the work that matters. Those questions sit above any individual team, and a developer-productivity framework has no way to answer them. At scale, individual throughput is less important than the system as a whole: who owns which service, which review gates still hold, how fast unreviewed attack surfaces are accumulating, and whether the operational controls scale with the output. Core 4 has no line of sight into that layer, and it was never meant to.
Mechanism. Core 4 is a measurement framework: four dimensions, sixteen metrics, and a mix of system-based and survey-based signals. DRIVE combines measurement with a recurring review: the Operational Excellence review.
Core 4 also measures developer experience directly, through the DXI and the Effectiveness dimension. DRIVE does not track those signals, so use Core 4 for developer experience questions.
When to use DRIVE vs DX Core 4
Reach for DX Core 4 when the question is developer productivity and experience: how a team is shipping, where developer friction exists, how changes are holding up in production, and where engineering time is going. Core 4's four dimensions and sixteen metrics are built for those questions, and DX has published guidance on avoiding throughput-only measurement.
Reach for DRIVE when the question is about the organization: whether cross-team initiatives are finishing on the timelines leadership set, whether the org's risk posture is degrading as output climbs, whether engineering capacity is going into new work or into maintenance, and whether the organization is getting more effective quarter over quarter.
In an engineering organization of more than 800 people, Skyscanner shipped three engineering-wide initiatives in succession, each one finishing faster than the previous. The metrics that describe that result, like Tier 1 milestone completion and initiative cycle time across the organization, do not appear in Core 4's four dimensions.
For most organizations at scale, the answer is both, at different levels. A DevEx or platform team runs the Core 4 program at the team level, and engineering leadership runs DRIVE at the organization level. Core 4's output feeds DRIVE's Delivery and Reliability pillars, and a DRIVE review can flag team-level DevEx problems that Core 4 is better equipped to diagnose.
What's next for engineering measurement as agents scale?
DORA's 2026 ROI report found change failure rate rising from 5% to 6% after AI adoption, and DORA included that as a real cost in its ROI model. Veracode's 2026 GenAI Code Security Report found that around 44% of AI code-generation tasks produced a risky security vulnerability, roughly unchanged from the year before. The failure rate per task is flat, but the volume of AI-generated code is growing, so the total number of risky vulnerabilities keeps climbing.
Developer productivity looks healthier while organizational risk concentrates. Engineering leaders now have to answer whether the organization can absorb, validate, and operate what agents produce while meeting its commitments to customers.
The full framework, including the OpEx review mechanics, is at cortex.io/report/drive-framework.
Frequently Asked Questions
Can DRIVE and DX Core 4 be used together?
Yes. Core 4's output, like DORA's, can feed the Delivery and Reliability pillars of a DRIVE review. Many organizations run both.
Does DRIVE replace DORA, SPACE, or DX Core 4?
No. DRIVE includes DORA's four delivery metrics in its Delivery and Reliability pillars. It complements team and individual productivity frameworks like SPACE and DX Core 4.
Who owns each framework inside the organization?
DX Core 4 typically belongs to the DevEx or platform engineering team. Engineering leadership owns DRIVE, and runs the recurring Operational Excellence review.
Which framework should a VP take to the board?
DRIVE. The board and the rest of the C-suite are asking whether the engineering organization is getting more effective, whether risk is concentrating, and whether capacity is going into the right work. DRIVE was built to answer those organizational questions in language executives use. DX Core 4 is the right framework for the DevEx program, but its team-level dimensions do not answer the organizational questions boards are asking.
What’s the difference between DX Core 4 and SPACE?
Both measure developer and team productivity. Core 4 builds directly on SPACE. SPACE is a lens with no required metric set. Core 4 turns that thinking into a defined program of four dimensions and sixteen metrics. Use SPACE to decide what productivity means for your teams, and Core 4 to run the measurement.
