From Polyrepo Chaos to a JVM Monorepo Backbone
Block’s approach to orchestrating AI coding agents across hundreds of services is a strategy that merges monorepo architecture with a centralized agent orchestration system to reduce dependency drift, simplify coordination, and automate software development workflows at scale. Before this shift, Cash App and Square backend teams operated in a polyrepo world where shared libraries and services lived in roughly 450 separate JVM repositories. That independence came with a cost: duplicated upgrade work, version drift, and diamond dependency surprises that could surface as runtime failures. By consolidating those 450 repositories into a single monorepo, Block created a unified dependency graph and a single source of truth for cross-service changes. According to Block’s engineering team, the monorepo now supports around 8,800 builds per week with p90 CI times of about 10 minutes, providing a stable backbone for software automation and AI-driven workflows.
Solving Dependency Drift with Monorepo Architecture
The core of Block’s monorepo strategy is tighter dependency management across its JVM services. In the older polyrepo setup, rolling out a new version of a shared library meant coordinating releases across many teams and repositories, often turning routine upgrades into “heroic” efforts that risked breaking downstream consumers. The monorepo reverses this pattern. Shared dependencies are resolved directly from source instead of via independently versioned internal libraries, so a single atomic commit can update multiple services at once. Block supplements this with merge queues to keep the main branch reliably green under heavy commit volume and a custom IntelliJ plugin that loads only relevant projects to keep developer workflows responsive. Build scoping uses a dependency graph to decide which projects to build and test for each pull request, which helps contain CI times while the codebase and the number of AI-driven changes continue to grow.
Builderbot: An Agent Orchestration System in Slack
On top of this monorepo architecture, Block built an agent orchestration system that makes AI coding agents a first-class part of daily work. The centerpiece is Builderbot, a framework built on the open-source Goose project. Engineers interact with it entirely through Slack: they tag @builderbot in a channel, describe the task, and the AI agents handle research, planning, and coding within the same thread. Builderbot pulls tickets from Linear and Jira, creates branches, opens pull requests, monitors CI, and iterates on feedback. The conversation effectively becomes the development environment, reducing context switching and making software automation feel like an extension of ordinary team chat. Block reports that the system now runs more than 200,000 operations per day and merges about 1,500 pull requests per week, representing roughly 15% of all production code changes across the company.
AI Coding Agents for Cross-Service Development
What distinguishes Block’s AI coding agents from typical code assistants is their ability to operate across the entire corporate codebase. Builderbot maintains a detailed map of services, APIs, and internal engineering conventions, so an engineer in the Cash App organization can request changes to an unfamiliar Square backend service and rely on the system’s context. Builderbot coordinates multiple agents as a central orchestration layer: it breaks down tasks ranging from small bug fixes to large architectural migrations that span several databases and services. Human engineers stay in the loop through the same Slack thread, guiding the agents and reviewing output while Builderbot drives the mechanical work of branch creation, CI monitoring, and iterative updates. Block emphasizes that Builderbot works solely on source code and system configurations, not on customer or payment data, aligning AI-driven automation with internal security and compliance expectations.
Why Monorepo plus AI Agents Scale for Large Engineering Orgs
The combination of monorepo architecture and AI coding agents gives Block both structural and operational advantages. The monorepo reduces dependency drift and coordination overhead, with around 8,800 weekly builds demonstrating that a single JVM codebase can scale when supported by dependency-aware build scoping and stable CI. On top of this backbone, the Builderbot agent framework automates cross-service tasks that would have required extensive human coordination in a polyrepo world. According to Brad Axen, Builderbot is “the missing layer between AI coding tools and how engineering actually works at scale,” enabling features that had been stalled for months to ship in days. Together, these choices show how an agent orchestration system, integrated into Slack and powered by AI coding agents, can transform software automation from isolated tools into a cohesive infrastructure strategy for large engineering organizations.
