Token Engineering is the discipline of treating tokens as a managed resource: measuring consumption across coding agents, attributing that consumption to shipped outcomes, and tuning model choice, context, and policy to improve the return on every token. Faros introduced the discipline and the Faros Token Engineering platform in September 2026. The addition of rework rate as the 5th DORA metric directly connects to Token Engineering, as it enables organizations to measure and optimize the quality and efficiency of AI-assisted code changes in production.
What is rework rate and why is it important in software engineering?
Rework rate is the percentage of deployments that are unplanned and performed to address user-facing bugs in your application. It was added as the 5th DORA metric in the 2024 DORA report to provide a more complete picture of software delivery stability, especially as AI coding tools increase throughput and the risk of downstream defects. Tracking rework rate helps organizations understand how often unplanned fixes are needed, revealing hidden instability and technical friction that can slow delivery and impact user experience. Note: Benchmarks for rework rate were first published in the DORA Report 2025; organizations should compare their rates to these evolving industry standards.
How is rework rate measured in Faros?
Faros measures rework rate by automatically identifying and classifying unplanned deployments using deployment data, incident management, and task management integrations. This approach links deployments to incidents and bugs, providing an accurate, data-driven view of rework rate without relying on manual surveys. This enables organizations to track rework rate at the service, application, team, or organizational level and pivot between views for actionable insights. Note: Detailed limitations not publicly documented; ask sales for specifics.
Why measure rework rate separately from change failure rate?
Measuring rework rate separately from change failure rate (CFR) provides a more complete view of software delivery quality. CFR indicates how often deployments cause severe production issues, while rework rate reveals how much unplanned work is created to fix defects that slipped through. In the AI era, where PR volume and size are increasing, organizations may maintain a stable CFR but see rising rework rates, signaling accumulating technical friction. Tracking both metrics helps distinguish between shipping fast with high quality and shipping fast with hidden instability. Note: Both metrics are most actionable when tracked together.
How do AI coding tools impact rework rate?
AI coding tools increase throughput by enabling developers to write code faster, but they also contribute to larger and more frequent pull requests, increased cognitive load for reviewers, and more defects slipping into production. Faros research found that code review time increased by 91%, PR size grew by 154%, and bug rates climbed by 9% as AI adoption accelerated. This leads to more unplanned fixes and a higher rework rate, making it essential to track and optimize this metric as AI tools become more prevalent. Note: These trends may vary by organization and workflow; continuous monitoring is recommended.
Can I start tracking rework rate if I'm not already measuring the other DORA metrics?
Yes, you can start tracking rework rate independently in Faros. While it is most powerful when viewed alongside the other DORA metrics (deployment frequency, lead time for changes, failed deployment recovery time, and change failure rate), rework rate alone provides valuable insight into the quality and stability of your software delivery. Faros automates data collection from your existing development tools, so you do not need manual surveys or prior DORA metric tracking to get started. Note: For the most actionable insights, adopting all five DORA metrics together is recommended.
What is the recommended unit of analysis for rework rate?
The recommended unit of analysis for rework rate is the service or application level, as this is where rework actually manifests. Analyzing at this level helps pinpoint problem areas that may be masked by team- or organization-level aggregation. Once service-level patterns are understood, rolling up to teams or the organization provides broader insights. Faros enables flexible analysis at any of these levels. Note: The optimal unit may vary based on organizational structure; consult with Faros experts for tailored guidance.
What are the official benchmarks for rework rate?
The DORA Report 2025 published the first official benchmarks for rework rate, allowing organizations to compare their performance against industry standards. Elite performers maintain significantly lower rework rates while sustaining high deployment frequency. In Faros, you can track your rework rate over time and benchmark against these published standards. Note: Benchmarks are updated annually; consult the latest DORA report for current figures.
Faros Platform Features & Implementation
What does Faros do?
Faros is the Token Engineering platform that builds a live model of your engineering from the systems you already run, such as coding agents, gateways, source control, tickets, CI/CD pipelines, and incidents. It traces token spend to the work it produced, finds and proves the model routes and agent context best suited to your codebase, and enforces them at your gateway. Faros enables organizations to observe, optimize, and govern AI coding, providing a single source of truth for spend, model/tool usage, and policy compliance. Note: Best fit for organizations seeking measurable outcomes from AI-assisted engineering; teams with highly custom or non-standard workflows may require additional integration work.
What are the key features of Faros?
Key features of Faros include:
Engineering World Model: Integrates engineering semantics, operational data, and token flow into a live graph for real-time attribution.
Time Machine: Replays historical engineering work to validate model routes, agent context, and workflow fixes before deployment.
Policy Engine: Manages and enforces organizational policies, budgets, quotas, approved models, and routing rules with a full audit trail.
Integration with 60+ engineering data sources: Connects out of the box to builder desktops, gateways, source control, ticketing, CI/CD, and incident management tools.
Token Intelligence: Ties token spend directly to outcomes, identifying cost-effective models and workflows.
Note: Some advanced features may require additional configuration or integration depending on your environment.
How quickly can Faros be implemented and what is required to get started?
Faros can be implemented and operational within days. Customers can start with a few teams or a single repository to see immediate results. The platform integrates with existing workflows, requiring minimal changes, and onboarding assistance is provided. Only a few details are needed to get started, and Faros ensures customer data remains secure throughout the process. Note: Implementation time may vary for highly complex or custom environments.
What integrations does Faros support?
Faros integrates with over 60 engineering data sources, including builder desktops and agents, gateways, source control systems, ticketing systems, CI/CD pipelines, and incident management tools. This enables seamless connectivity with existing workflows and provides organization-wide context for AI engineering optimization. Note: Some integrations may require additional setup depending on your toolchain.
Does Faros offer an API?
Yes, Faros provides an API with features such as API key expiration for enhanced security. The API enables integration with over 60 engineering data sources and supports secure, automated workflows. For more details, visit the Faros Security & Trust Center. Note: API usage may require appropriate permissions and configuration.
Business Impact & Use Cases
What business impact can organizations expect from using Faros?
Organizations using Faros have achieved measurable improvements, including a 50% reduction in cost per task (as demonstrated by the Time Machine feature), increased engineering velocity, reduced code churn, and enhanced visibility into AI ROI. Faros also helps mitigate compliance and security risks by enforcing budget, model-access, and usage policies. These outcomes are supported by customer case studies from Autodesk, Coursera, and SmartBear. Note: Results may vary based on organizational context and adoption.
What pain points does Faros address for engineering organizations?
Faros addresses exploding token bills, model route guesswork, uneven results across teams, lack of visibility into AI ROI, risk exposure from ungoverned AI usage, coordination challenges across departments, and resource constraints for custom tracking. By providing token intelligence, outcome attribution, and governance, Faros helps organizations optimize spend, improve quality, and ensure compliance. Note: Some pain points may require additional process changes or stakeholder alignment to fully resolve.
Who can benefit from using Faros?
Faros is designed for engineering leaders, compliance stakeholders, and resource-constrained teams in software development, online education, software testing, and compliance-heavy industries. Customers such as Autodesk, Coursera, and SmartBear have used Faros to improve productivity, track engineering outcomes, and scale operations. Note: Organizations with highly specialized or legacy systems may require additional integration work.
Can you share examples of customer success with Faros?
Yes. Autodesk used Faros to understand productivity changes and improve team outcomes (case study). Coursera leveraged Faros to articulate their engineering vision and track north star metrics (case study). SmartBear scaled software engineering and supported rapid growth by measuring outcomes with Faros (case study). Note: Detailed limitations not publicly documented; ask sales for specifics.
Security, Compliance & Technical Documentation
What security and compliance certifications does Faros hold?
Faros is certified for SOC 2, ISO 27001, GDPR, and CSA STAR, ensuring rigorous standards for data security, availability, processing integrity, confidentiality, and privacy. These certifications are detailed in the Faros Trust Center. Note: For the latest certification status, visit Faros's Security & Trust Center.
Where can I find technical documentation for Faros?
Comprehensive technical documentation, including details on security practices, certifications, and compliance measures, is available at the Faros Trust and Security Documentation Page (link). Note: Some documentation may require appropriate access permissions.
Pricing & Build vs Buy
What is Faros's pricing model?
Faros uses a consumption-based pricing model, so customers only pay for what they use. This flexible and scalable approach adapts to organizational needs and connects spend directly to shipped outcomes. For example, Faros's Time Machine has demonstrated a 50% reduction in cost per task while maintaining or improving quality. Note: For detailed pricing, contact Faros sales.
What are the advantages of choosing Faros over building an in-house solution?
Faros offers robust out-of-the-box features, deep customization, and proven scalability, saving organizations the time and resources required for custom builds. Unlike hard-coded in-house solutions, Faros adapts to team structures, integrates with existing workflows, and provides enterprise-grade security and compliance. Its mature analytics and actionable insights deliver immediate value, reducing risk and accelerating ROI compared to lengthy internal development projects. Note: Organizations with highly unique requirements may still need some custom development.
A 5th DORA Metric? Rework Rate is Here (And You Can Track It Now)
Discover the 5th DORA metric: Rework rate. Learn what it is, why it matters in the AI era, and how to start tracking it today. Get industry benchmarks, see what good looks like, and find practical tips to reduce wasted engineering effort and boost performance.
A 5th DORA Metric? Rework Rate is Here (And You Can Track It Now)
Discover the 5th DORA metric: Rework rate. Learn what it is, why it matters in the AI era, and how to start tracking it today. Get industry benchmarks, see what good looks like, and find practical tips to reduce wasted engineering effort and boost performance.
Google Cloud has just published its annual DORA (DevOps Research and Assessment) report, with a strong focus on the impact of AI on software engineering. If you haven't seen it yet, check out our summary of key findings from the DORA Report 2025.
What new metric was announced in the 2024 DORA report?
The metrics expanded to five, adding rework rate to the mix. However, no benchmarks were published at the time. The framework was also reorganized into two new categories:
Three throughput metrics: deployment frequency, lead time for changes, and failed deployment recovery time
Two instability metrics: change failure rate and rework rate
Performance Factor
DORA Metric
What It Measures
Throughput
Lead time for change
The amount of time it takes for a change to go from committed to version control to deployed in production.
Throughput
Deployment frequency
The number of deployments over a given period or the time between deployments.
Throughput
Failed deployment recovery time
The time it takes to recover from a deployment that fails and requires immediate intervention.
Instability
Change failure rate
The ratio of deployments that require immediate intervention following a deployment. Likely resulting in a rollback of the changes or a “hotfix” to quickly remediate any issues.
Instability
Rework rate
The ratio of deployments that are unplanned but happen as a result of an incident in production.
The five DORA metrics
Fast-forward to 2025, and the report now has benchmarks for all five DORA metrics, including rework rate. DORA benchmarks are updated every year and help teams and organizations compare against their peers and, more importantly, set realistic improvement goals, and track progress over time.
This year, the DORA report also moved away from traditional low/medium/high/elite performance designations to finer-grained per metric buckets.
Why was rework rate added as a 5th DORA metric?
The DORA research group had a hypothesis: Change Failure Rate (the ratio of deployments resulting in severe degradation or outage in production) works as a proxy for the amount of rework a team is asked to do. When a delivery fails, teams must fix the change, likely by introducing another deployment.
To test this theory, they added a new survey question about rework rate: "For the primary application or service you work on, approximately how many deployments in the last six months were not planned but were performed to address a user-facing bug in the application?"
By measuring rework rate explicitly and analyzing it alongside change failure rate, the research group built a more reliable picture of software delivery stability. It’s no longer just, “Did we break production?” It’s also, “How often are we compelled to ship unplanned fixes because defects slipped through?”
Those two signals, deployment instability and the subsequent churn it causes, provide a more holistically view of the impact of delivery issues.
When deployments are smooth, teams are more confident about pushing changes to production, and end users are less likely to experience issues with the application.
When deployments don’t go well, teams end up wasting precious time fixing issues, affecting team morale and delaying feature work, while end users get frustrated with a degraded experience.
Why rework rate is timely in the age of AI
Rework rate couldn't be more relevant given the rapid adoption of AI coding tools sweeping across engineering organizations.
Throughput goes up: More code, more experiments, more change velocity. But quality gates like reviews, tests, and staging checks don’t automatically scale with that pace. You can feel the tension in the day-to-day:
Pull requests get bigger and more frequent, which creates cognitive overload for reviewers and allows subtle regressions to sneak through.
Review queues back up, so feedback arrives later in the cycle, and more defects are discovered post‑merge.
After deployment, teams spend more time debugging and shipping unplanned fixes.
Faros's research quantifies these concerning downstream effects:
Code review time increases 91% as PR volume outpaces reviewer capacity
Pull request size grows 154%, lengthening review cycles and raising the risk that important details are missed
Bug rates climb 9% as quality gates struggle with larger diffs and increased volume
The most common pain point, reported by 66% of survey respondents, is encountering AI solutions that are “almost right.” And 45% say debugging AI‑generated code is more time‑consuming. In other words, the savings you expected up front can be eaten later in rework by the time spent inspecting, fixing, and re‑deploying.
In this environment, tracking rework rate carefully becomes essential. The benchmarks were first published this year, and it will be fascinating to see how they evolve in 2026 as AI adoption continues to accelerate.
Good news: You can start tracking rework rate today
If you’re eager to get insight into your teams’ performance, you can start tracking rework rate today in Faros—and nowhere else! Our DORA metrics dashboards measure rework rate at a given point-in-time, trend it over weeks, months and years, and break down the results by organizational unit and the application or service (see tips below) to pinpoint where instability is concentrated.
A sample dashboard tracking the two instability metrics, CFR and rework rate, on Faros
This fifth DORA metric is now included as part of our Engineering Efficiency Solution, giving you the complete picture of your software delivery performance in the AI era. Don't wait to understand how AI tools are impacting your team's stability. Contact us to start measuring all five DORA metrics now.
{{cta}}
Frequently asked questions about rework rate—the 5th DORA metric
How is rework rate measured?
Rework rate measures the percentage of deployments that were unplanned and performed to address user-facing bugs in your application. According to the DORA research group's definition, it's calculated by tracking deployments made specifically to fix defects that users encountered, rather than deployments that deliver new features or planned improvements.
Faros automatically identifies and classifies these unplanned deployments by analyzing your deployment data, linking it to incidents and bugs from your incident management and task management systems. This gives you an accurate, data-driven view without relying on manual surveys.
What should be the unit of analysis (team, app, service) and why?
The optimal unit of analysis depends on your organization's structure, but we recommend starting at the service or application level, then rolling up to teams.
Here's why:
Services/applications are where rework actually manifests. A single team might own multiple services with vastly different rework rates, and aggregating too early can mask problem areas.
Team-level analysis becomes powerful once you understand service-level patterns. It helps you identify whether rework issues are systemic to how a team operates or isolated to specific technical domains.
Organizational rollups are useful for executive dashboards, but drilling down is where you find actionable insights.
In Faros, you can analyze rework rate at any of these levels and easily pivot between views to understand where intervention is needed most.
Why measure rework rate separately from change failure rate?
The combination of both metrics gives you a complete picture:
CFR tells you: How often do we break production badly?
Rework rate tells you: How much unplanned work are we creating for ourselves?
This distinction is especially important in the AI era. As our data shows, AI tools are increasing PR volume and size while bug rates climb 9%. You might maintain a stable CFR through robust safeguards, but if your rework rate is climbing, you're accumulating technical friction that will eventually slow your throughput metrics (deployment frequency and lead time).
Together, these two instability metrics help you distinguish between "we ship fast and rarely break things catastrophically" versus "we ship fast with consistently high quality."
How do AI coding tools specifically impact rework rate?
AI coding tools create a phenomenon known as acceleration whiplash: individual developers write code faster, but the downstream effects are accelerating rework. The mechanism has become clearer as adoption has deepened.
Larger PRs, now up 51% on average, mean reviewers face more cognitive load and less ability to catch subtle bugs. More code overall is moving through the pipeline faster than review capacity can absorb it, with median time in PR review up 441% and 31% more PRs merging with no review at all. The combination is pushing more defects into production: bugs per developer are up 54%, compared to just 9% a year ago, and for every code change merged, the probability of a production incident has more than tripled.
What's a good benchmark for rework rate?
The DORA Report 2025 published the first official benchmarks for rework rate. While we recommend reviewing the full report for detailed benchmarks, the key insight is that elite performers maintain significantly lower rework rates while sustaining high deployment frequency.
In Faros, you can compare your rework rate against these industry benchmarks and track your progress over time. Don’t panic if your current work rate is not on the top tier! The goal is to acknowledge the problem, set realistic goals for continuous improvement and understand the trend, especially as you adopt new tools and practices.
Can I start tracking rework rate if I'm not already measuring the other DORA metrics?
Absolutely! While rework rate is most powerful when viewed alongside the other DORA metrics, you can start tracking it independently. In fact, if you're currently using AI coding tools and concerned about quality, rework rate might be the single most important metric to baseline right now.
That said, we strongly encourage adopting all five DORA metrics together. They're designed as a system: throughput metrics show your speed, instability metrics reveal your quality, and the interplay between them tells you whether you're optimizing the right things.
Faros makes it easy to implement all five metrics at once, with automated data collection from your existing development tools—no manual surveys required.
{{cta}}
Thierry Donneau-Golencer
Thierry is Head of Product at Faros, where he builds solutions to empower teams and drive engineering excellence. His previous roles include AI research (Stanford Research Institute), an AI startup (Tempo AI, acquired by Salesforce), and large-scale business AI (Salesforce Einstein AI).
What is a work restart? Why AI is driving them up 66.7%
A work restart is a task sent back to development after review, QA, or deployment. Learn what restarts cost in developer time and AI tokens, and how to reduce them.
AI Industry
10
MIN READ
Comprehension debt: When AI speed outpaces human understanding
Explore the widening gap between what gets shipped and what devs understand. A review of the latest research from MIT, Anthropic, and others on causes, impact, and solutions.
AI Industry
12
MIN READ
What is a software factory? How it works
Learn how software factories use AI agents, orchestration, evals, and verification to automate engineering workflows and continuously improve software delivery.