# Jack Dorsey's Block says Builderbot now accounts for 15% of its production code changes > Source: > Published: 2026-06-19 15:04:35+00:00 [Jack Dorsey (@jack)](https://x.com/jack?ref=runtimewire) and [Block](https://block.xyz/?ref=runtimewire) have pulled back the curtain on Builderbot, an internal AI engineering system the Square and Cash App parent says now accounts for about 15% of all production code changes across the company. The disclosure, surfaced by [Aligned News](https://di.gg/ai/2jhwb6pr?ref=runtimewire) and detailed in [Block's June 17 post](https://block.xyz/inside/block-rolls-out-builderbot-a-new-suite-of-ai-native-tools-that-changes-the-way-we-ship?ref=runtimewire), is not a product launch. Builderbot is not being sold, priced, waitlisted, or opened to outside developers. It is a look inside how a large fintech company is reorganizing software work around agents before packaging that work for anyone else. That distinction matters. Dorsey, Block's cofounder, chairperson, and Block Head, has spent much of his career building systems that collapse a messy workflow into a simpler interface: a card reader for sellers, a cash-transfer app for consumers, a public timeline for Twitter. Builderbot applies the same founder instinct to the engineering org itself. The interface is Slack. The job is shipping code across a codebase too large for single-repo coding assistants to handle cleanly. Dorsey framed the announcement as the start of a broader reveal. "This is the beginning of the beginning," he wrote, saying Block would begin talking more about its intelligence tools. [Jack Dorsey on X](https://x.com/jack/status/2067319680654594543?ref=runtimewire) ### What Builderbot actually does Block says Builderbot lets an engineer tag the agent in Slack with a short task description. From there, Builderbot researches the codebase, makes a plan, opens a branch, writes code, opens the pull request, watches CI, iterates on feedback, and merges changes. Block also says the system can operate across hundreds of services. The numbers are the reason this announcement landed. Block says Builderbot executes more than 200,000 operations per day and merges approximately 1,500 pull requests per week. Block says that represents about 15% of all production code changes across the company. Those are Block-reported numbers. Block did not publish the measurement window, the distribution of PR sizes, the rejection rate, the share of human-written code inside Builderbot-authored PRs, or the review policy that determines what counts as a Builderbot production code change. Those omissions do not make the numbers meaningless. They do make them hard to compare against ordinary engineering productivity metrics. A 1,500-PR-per-week agent can mean several different things depending on the work mix: migrations, dependency updates, scaffolding, test fixes, configuration changes, or small feature work. In Block's description, engineers initiate tasks and review the work; the agent handles the context gathering, boilerplate, CI loops, and other glue work between a ticket and a merged change. ### The infrastructure bet underneath the announcement Builderbot is built on [goose](https://github.com/aaif-goose/goose?ref=runtimewire), Block's open-source AI agent framework, which moved from Block's GitHub organization to the Agentic AI Foundation under the Linux Foundation. The goose repository describes it as a native open-source AI agent with desktop, CLI, and API surfaces for code, workflows, and other tasks. Block introduced goose publicly in January 2025 as an interoperable framework for connecting large language models to real-world actions, as described in its earlier [Block Open Source post](https://block.xyz/inside/block-open-source-introduces-codename-goose?ref=runtimewire). The second foundation is the [Model Context Protocol](https://www.anthropic.com/news/model-context-protocol?ref=runtimewire), an open standard Anthropic introduced in November 2024 to connect AI assistants to data sources, content repositories, business tools, and development environments. The production impact did not come from a generic coding chatbot dropped into an IDE. It came from a stack: an agent framework, a protocol for tool and context access, internal connectors, Slack as the collaboration surface, ticketing, source control, CI, and review workflows. The product insight is that coding agents become more valuable when they are embedded where engineering work is assigned, discussed, tested, and approved. For startups selling AI coding tools, Block is a warning and a proof point at the same time. The proof point is that large companies can move meaningful software work through agents today. The warning is that the most valuable layer may be the internal orchestration a company builds around its own codebase, not the generic assistant alone. ### What Block is not saying Block says Builderbot does not access customer data. That boundary is essential for a company whose brands include Square, Cash App, Afterpay, Bitkey, and Tidal. Block has not said which models Builderbot uses, how model vendors are selected, what evaluation gates are required before merge, or how risk is tiered across code paths. It also has not announced a public version of Builderbot, an open-source release for the orchestration layer itself, or a timeline for external access. That leaves the commercial question open. Block has already put goose into the open-source ecosystem. Builderbot is different: its value appears to come from the private map of Block's software estate and the operational machinery around it. Open-sourcing the skeleton would not reproduce the system. Selling it would require turning a deeply internal tool into a secure, configurable enterprise product. Keeping it internal would still give Block a lever on engineering throughput across its own brands. Dorsey's post points to a broader agenda: Block wants to talk publicly about intelligence tools as a core part of how it builds. The near-term story is not that Builderbot is coming to market. It is that Block is using its own engineering org as the proving ground for agentic software work at scale, with enough volume to force the questions that demos avoid: how agents touch production, how humans remain accountable, and how much of a company's software factory can be routed through an orchestration layer before the org itself starts to change.