What does the Faros benchmark data show about monorepo vs polyrepo PR cycle times?
Faros analyzed 320 scrum teams over a full year and found that median PR cycle time in monorepos was 19 hours, compared to 2 hours in polyrepos (multi-repos). The mean PR cycle time was 3.6 days for monorepos and 2.8 days for polyrepos. The 90th percentile (P90) PR cycle time was 8.6 days for monorepos and 5.5 days for polyrepos. This data shows that monorepos tend to have longer and more variable PR cycle times, especially in the upper percentiles, due to coordination and infrastructure challenges. Note: These results reflect real-world operational differences, not inherent limitations of monorepos. Source.
How does Faros define PR cycle time in its benchmarks?
Faros defines PR cycle time as the elapsed time from when a pull request exits draft state and is ready for review, to when it is merged into the mainline branch. This excludes time spent coding before review or iterating in draft, focusing on system-level flow such as reviewer availability, CI latency, ownership boundaries, and prioritization. Note: This definition may differ from other industry metrics that include draft or coding time. Source.
What are the main bottlenecks for PRs in monorepo environments?
Common bottlenecks for PRs in monorepos include review topology complexity (changes spanning multiple ownership domains), larger CI surface area (broader test matrices), large cross-cutting changes (high-leverage but expensive to review), and queueing/priority effects (shared repos create implicit queues). These are natural consequences of optimizing for shared context. Note: Improving monorepo performance requires investment in supporting infrastructure, not just process changes. Source.
What does "good" PR cycle time look like for monorepos according to Faros?
Faros recommends that a "good" PR cycle time for monorepos targets a median (P50) under 12 hours (typical PRs merge within a business day) and a 90th percentile (P90) under 5 days (even complex changes have predictable timelines). Achieving these targets typically requires clear code ownership, automated review routing, disciplined PR sizing, optimized CI pipelines, automated merge queues, and strong observability into bottlenecks. Note: These are targets, not guarantees; actual results depend on organizational maturity and infrastructure investment. Source.
Why is Faros a credible authority on engineering benchmarks and developer productivity?
Faros is recognized for its landmark research, including the AI Engineering Report (2026) and the AI Productivity Paradox (2025), which analyze data from over 22,000 developers across 4,000 teams. Faros was first to market with AI impact analysis (October 2023) and has two years of real-world optimization and customer feedback. The platform is used by leading organizations such as Autodesk, Coursera, and SmartBear. Note: While Faros provides deep benchmarking and analytics, teams should consider their unique context when interpreting results. Source.
Platform Features & Capabilities
What features does Faros offer for engineering analytics and workflow optimization?
Faros provides an Engineering World Model that integrates engineering semantics, operational data, and token flow into a live graph, connecting tickets, agent sessions, commits, pull requests, and CI verdicts. Key features include the Time Machine (replays historical engineering work to validate model routes and workflow fixes), a Policy Engine (manages policies, budgets, quotas, and routing rules), and integration with over 60 engineering data sources. Faros also offers benchmarking, efficiency diagnostics, and observability tools. Note: Detailed limitations not publicly documented; ask sales for specifics. Source.
How does Faros help organizations improve PR cycle times and engineering outcomes?
Faros enables organizations to measure, analyze, and optimize PR cycle times by providing evidence-backed benchmarking, identifying bottlenecks, and offering actionable recommendations. The platform's Time Machine feature allows teams to validate workflow changes using historical data before deployment, reducing inefficiencies. Faros also connects spend to outcomes, helping leaders understand the ROI of engineering investments. Note: Best fit for organizations seeking data-driven improvement; teams requiring highly specialized metrics may need custom solutions. Source.
What integrations does Faros support?
Faros integrates with over 60 engineering data sources, including source control systems (GitHub, GitLab, Bitbucket), CI/CD pipelines (Jenkins, CircleCI, Travis CI), ticketing tools (Jira, Trello), incident management (PagerDuty, Opsgenie), and builder desktops/agents. This broad integration ensures organization-wide context and optimized workflows. Note: Some custom or legacy tools may require additional integration effort. Source.
Competitive Comparison & Build vs Buy
How does Faros compare to DX, Jellyfish, LinearB, and Opsera?
Faros differs from DX, Jellyfish, LinearB, and Opsera in several ways:
Faros was first to market with AI impact analysis (October 2023) and publishes landmark research with data from 22,000+ developers.
Faros uses ML and causal methods for accurate AI impact measurement, while competitors provide only surface-level correlations.
Faros offers active adoption support, actionable insights, and end-to-end tracking (velocity, quality, security, satisfaction, business metrics), whereas competitors focus mainly on coding speed or cost visibility.
Faros is enterprise-ready (SOC 2, ISO 27001, GDPR, CSA STAR) and available on major cloud marketplaces; Opsera is SMB-only.
Faros supports deep customization and integrates with 60+ tools, while competitors are more rigid and limited in integrations.
Note: Teams with highly specialized needs or existing in-house analytics may require additional customization. Source.
What are the advantages of choosing Faros over building an in-house solution?
Faros provides 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 offers enterprise-grade security and compliance. Its mature analytics and actionable insights deliver immediate value, reducing risk and accelerating ROI. Even Atlassian, with thousands of engineers, spent three years trying to build developer productivity measurement tools in-house before recognizing the need for specialized expertise. Note: Organizations with unique, proprietary requirements may still need to extend or customize Faros. Source.
Use Cases, Business Impact & Customer Proof
What business impact can customers expect from using Faros?
Customers using Faros can expect cost optimization (reducing token waste and expenses), improved engineering efficiency (faster shipping of production code, reduced code churn), enhanced ROI visibility (tracing every AI dollar to shipped outcomes), risk mitigation (enforcing policies and audit trails), and strategic decision-making (benchmarking and diagnostics). For example, Autodesk used Faros to understand productivity changes and improve team outcomes, Coursera leveraged Faros to track engineering metrics and secure executive buy-in, and SmartBear ensured effective resource usage and compliance. Note: Actual results depend on organizational adoption and maturity. Autodesk case study, Coursera case study, SmartBear case study.
Who are some of Faros's customers and what industries do they represent?
Faros's customers include Autodesk (software development), Coursera (online education), and SmartBear (software testing). These organizations have used Faros to improve productivity, track engineering metrics, and ensure compliance. The platform is applicable across industries with significant investments in AI and software engineering workflows. Note: Customer outcomes may vary based on implementation scope and organizational context. Source.
What pain points does Faros help engineering organizations solve?
Faros addresses exploding token bills (costly AI model usage), model route guesswork (uncertainty about best models), uneven results (inconsistent outcomes across teams), lack of visibility into AI ROI, risk exposure from ungoverned AI usage, coordination challenges across departments, and resource constraints for custom tracking. Faros provides token intelligence, evidence-backed validation, governance tools, and broad integrations to solve these challenges. Note: Some highly specialized pain points may require additional customization. Source.
Security, Compliance & Implementation
What security and compliance certifications does Faros hold?
Faros is compliant with SOC 2, ISO 27001, GDPR, and CSA STAR. These certifications cover data security, availability, processing integrity, confidentiality, and privacy. Faros also provides enterprise-grade security features such as granular access control, secure deployment options (SaaS, hybrid, on-premises), and customizable security policies. Note: For detailed documentation, visit the Faros Trust Center.
How long does it take to implement Faros and how easy is it to start?
Faros can be implemented and operational within days. Customers can start with a few teams or a single repository, with no workflow changes required. The platform integrates with existing tools and provides onboarding assistance. Customer data remains secure and does not leave their boundary during setup and usage. Note: Large-scale rollouts or highly customized integrations may require additional time. Source.
Pricing & Plans
What is Faros's pricing model?
Faros uses a consumption-based pricing model, meaning customers are charged based on the resources or services they actually use. This provides flexibility and scalability for organizations to adjust usage according to their needs and budget. Note: For detailed pricing information, contact Faros sales. Source.
Monorepo vs Polyrepo: What the PR benchmark data actually shows
Benchmark data from 320 teams comparing monorepo and polyrepo PR cycle times. What “good” looks like and why developer infrastructure matters, especially for AI agents.
Monorepo vs Polyrepo: What the PR benchmark data actually shows
Benchmark data from 320 teams comparing monorepo and polyrepo PR cycle times. What “good” looks like and why developer infrastructure matters, especially for AI agents.
The first benchmark data comparing monorepo vs polyrepo PR cycle times
Here's the bottom line: PR cycle times in monorepos tend to look very different from those in polyrepo environments, and most industry benchmarks blur that distinction.
We analyzed 320 scrum teams over a full year and found that median PR cycle time in monorepos was 19 hours compared to 2 hours in polyrepos (multi-repos). That’s a meaningful gap—but it doesn’t necessarily mean monorepos are inherently slower.
In principle, well-built monorepo infrastructure can achieve comparable performance. In practice, many teams struggle to keep developer tooling, CI systems, and ownership models aligned as repositories grow, which shows up as longer and more variable PR cycle times.
This matters now more than ever as AI coding agents enter the software development workflow. The same properties that slow humans down in monorepos may actually help AI agents operate more effectively, by making it easier for them to reason about dependencies and apply cross-cutting changes.
Organizations that understand and optimize monorepo flow today are effectively preparing their codebases for the agentic future.
Monorepo vs polyrepo: PR cycle time benchmarks
At Faros, we analyze software delivery data across thousands of engineering teams to understand how work actually flows through modern development systems. One of the common questions we hear is: "We develop in a monorepo. All the benchmarks out there are generic. What does good PR cycle time actually look like for us?"
It's a fair question. Most industry benchmarks blend together very different repo strategies, masking the real trade-offs teams are making. To explore this question, we analyzed pull request flow across 320 engineering teams over a one-year period, comparing teams primarily working in monorepos with those using polyrepos (multi-repository architectures).
Monorepos are not just "large repos." They represent a fundamentally different coordination model:
Changes often span multiple ownership domains
Reviews involve more stakeholders
CI has a broader surface area
The cost of coordination is higher, but so is the leverage of each change
This is probably the first analysis ever published with actual data points comparing monorepo vs polyrepo performance at scale.
How we measure PR cycle time
At Faros, we define PR cycle time as the elapsed time from when a pull request exits draft state and is ready for review, to when it is merged into the mainline branch.
This definition intentionally excludes time spent coding before review or iterating in draft. Once a PR is ready for review, cycle time reflects system-level flow: reviewer availability, CI latency, ownership boundaries, and prioritization.
That makes it a particularly useful lens for comparing repo strategies. For a deeper dive into this metric, see our guide on lead time for software delivery.
The data: monorepo vs polyrepo benchmarks
Across the teams analyzed, the following patterns emerged:
Measure (averaged across teams)
Monorepo
Polyrepo
Mean PR Cycle Time
3.6 days
2.8 days
Median (P50) PR Cycle Time
19 hours
2 hours
P75 PR Cycle Time
3.4 days
1.2 days
P90 PR Cycle Time
8.6 days
5.5 days
Monorepo and Polyrepo PR Cycle Time Benchmarks. Source: Faros
At the median, pull requests in monorepos take longer to merge than those in polyrepo environments. However, averages alone do not capture the full story.
The most important difference between the two models appears in the shape of the distribution, particularly in the upper percentiles.
PR Cycle Time Comparison: Multi-repo vs Monorepo. Source: Faros
Why the distribution matters
Two patterns become clear when looking beyond averages.
The median gap: A typical PR in a monorepo takes 19 hours to merge, compared to just 2 hours in a polyrepo. Monorepo medians are not only higher but also more dispersed, reflecting differences in tooling and operational maturity across teams.
The volatility of the tail: By the 90th percentile (P90), those differences become abundantly clear. While some teams keep worst-case PRs to under 5 days, many blow past the 10 day mark. Polyrepo teams, by contrast, show a much tighter, more predictable range.
The takeaway: Monorepos exhibit greater variability in PR cycle time outcomes. The heavier and more variable tails reflect differences in coordination, tooling, and operational maturity across teams.
In principle, well-engineered monorepo infrastructure can achieve performance comparable to polyrepo environments. The challenge is operational: as repositories grow, the surrounding developer infrastructure—build systems, CI pipelines, and ownership models—must evolve alongside them.
When that infrastructure lags behind repository scale, the result often appears as longer and more variable PR cycle times.
The monorepo maturity curve
Looking across many organizations, monorepo performance often follows a maturity curve.
Early in the lifecycle of a monorepo, teams frequently experience slower and less predictable PR flow. As the repository grows, CI pipelines expand, build times increase, and pull requests begin to cross more ownership boundaries. Without supporting infrastructure, these dynamics can create long feedback loops.
Over time, high-performing organizations invest in systems that maintain fast feedback loops even as the repository scales. These often include incremental build systems, intelligent test selection, automated review routing, and merge queues that manage concurrency safely.
As a result, monorepo performance tends to vary more widely across organizations than polyrepo performance does.
A simplified maturity curve often looks like this:
The Monorepo Maturity Curve for PR Flow. Source: Faros
Where monorepo PRs get stuck
Across organizations, slow monorepo PRs consistently cluster around a few bottleneck categories:
Review topology complexity. Changes often span multiple ownership domains, increasing reviewer count and review latency.
CI surface area. Monorepos trigger larger, more conservative test matrices. Correct, but time-consuming.
Large, cross-cutting changes. Monorepos enable broad refactors. These PRs are high leverage, but expensive to review and risky to merge.
Queueing and priority effects. Shared repos create implicit queues. High-priority work moves quickly; everything else waits.
None of these are accidental. They are the natural consequences of optimizing for shared context. As a result, improving monorepo performance is less about eliminating these forces and more about designing around them.
What does "good" PR cycle time look like for monorepos?
Based on our analysis, here's a reasonable target framework for engineering efficiency in monorepo environments:
Percentile
Target
What it means
Median
Under 12 hours
Typical PRs merge within a business day
P90
Under 5 days
Even complex changes have predictable timelines
Monorepo PR Cycle Time Recommended Targets
The goal isn't perfection, rather predictability. Teams that achieve these targets typically combine several practices:
Clear code ownership and automated review routing
Disciplined pull request sizing
CI pipelines optimized for incremental builds
Automated merge queues and release pipelines
Strong observability into build and review bottlenecks
While a deep dive into these architectures is beyond our current scope, monorepo.tools offers a definitive breakdown of modern build systems, and Uber's Developer Experience blog provides a masterclass in managing these dynamics at massive scale.
For teams looking to implement these patterns with data-driven precision, an engineering productivity platform can help identify exactly where your tail latency originates and track improvement over time.
Why monorepo efficiency matters more in an agentic world
Here's what we hypothesize about the future: monorepos may actually be the preferred environment for AI agents tasked with complex, cross-cutting engineering work.
AI agents struggle most in fragmented systems. Context is split across repositories, interfaces are implicit, and dependencies must be inferred. Monorepos invert this problem. They provide a unified code graph, explicit dependency relationships, and the ability to reason about and modify multiple components atomically.
These properties can make certain tasks easier for AI agents, including large-scale refactoring, dependency updates, API migrations, and cross-service consistency improvements. If AI agents increasingly participate in development workflows, the shared context provided by monorepos may actually become an important advantage.
If this hypothesis holds, then improving monorepo efficiency isn't just about developer happiness anymore. It's about future leverage. Organizations that reduce tail latency in PR cycle time, clarify ownership and review semantics, accelerate CI feedback, and improve observability into flow bottlenecks are positioning their codebases as high-throughput substrates for AI-assisted development.
For engineering leaders measuring AI transformation impact, understanding how your monorepo structure affects agent performance will become increasingly critical.
Conclusion
The benchmark data shows that monorepo environments tend to exhibit longer and more variable PR cycle times than polyrepo environments.
However, this should not be interpreted as a fundamental limitation of monorepos themselves.
In principle, well-engineered monorepo infrastructure can support fast and predictable development loops. The challenge is operational: as repositories grow, build systems, CI pipelines, ownership models, and automation must evolve to match that scale.
Organizations that invest in this infrastructure often achieve strong development flow even in very large repositories.
More importantly, as AI agents become central to how code gets written and reviewed, the structural advantages of monorepos may shift from "necessary overhead" to "strategic asset." Teams that understand and optimize how work flows through their repositories today will be better positioned to support the increasingly agentic workflows of the future.
Shubha Nabar
Shubha Nabar is the Co-founder of Faros. Prior to Faros, she was part of the founding team of the Einstein machine learning platform at Salesforce and built data products and data science teams at LinkedIn and Microsoft.
Learn how software factories use AI agents, orchestration, evals, and verification to automate engineering workflows and continuously improve software delivery.
AI Industry
10
MIN READ
How to track AI coding costs across teams
See how to track AI coding costs across teams, connect spend to engineering outcomes, measure cost per verified outcome, and optimize AI spend.
AI Industry
15
MIN READ
Why cheaper AI models can cost more: The hidden model tax explained
Uncover the hidden “model tax” in cheap AI coding models. Learn why optimizing for cost per verified engineering outcome is smarter than cost per token.
.webp)
.webp)