Building an Autonomous Engineering Org

How can an engineering organization use AI extensively without shipping any faster? At Block, Angie Jones was working on that problem across an organization of 3,500 engineers. The company had started building goose early—before LLMs supported tool calling, Jones says—and worked with Anthropic on the initial Model Context Protocol release. She describes goose as its reference client implementation. After a couple of months, Jones reports that about 90% of engineers regularly used tools such as goose and Claude Code to generate code.

Yet the CEO was convinced engineering was not using AI: the organization was not shipping faster. Usage metrics and token bills showed that engineers were using it, but features were still taking just as long to reach customers. Tool adoption had not become delivery impact.

Jones separates AI enablement into experimentation, adoption, and impact. Most engineers were still using AI inside the IDE to answer questions or write boilerplate. Moving beyond that required integrating agents into the process of building and shipping, rather than improving only the act of writing code.

During the first half of 2025, Jones led AI enablement across Block’s 12,000 employees, including marketing, design, finance, and legal. The next assignment was narrower but more demanding: build an agentic engineering organization. Her working definition was an organization in which engineers use agents as their primary means of producing engineering outcomes. Engineers would decompose problems, delegate tasks, review results, and verify the work. Directing agents would become their default workflow.

To make the gap concrete, Jones developed a maturity model measuring the engineer’s relationship with agents: how they think, delegate, and orchestrate. She had an earlier version in the third quarter of 2025 and later reorganized it with help from Steve Yegge’s Welcome to Gas Town. The six stages below are Jones’s model.

The progression changes who carries the task forward: first the engineer accepts assistance, then delegates bounded work, and eventually directs complete tasks.

At the end of the first half of 2025, most engineers were between stages 1 and 2. Stage 5 was the destination, but the immediate problem was getting engineers to trust agents with work that could become a pull request.

Training every engineer to discover effective agent workflows independently was unlikely to work. Practices could become obsolete with the next model or tool release. Engineers were experiencing AI fatigue, and pressure from leadership was making some less receptive. Jones turned to the 1-9-90 participation rule: a small minority creates, another group contributes occasionally, and most people consume what those groups produce. She used this as an adoption heuristic, not a measured distribution of Block’s workforce.

In engineering, the creators would discover agent patterns and useful techniques. Occasional contributors might adjust an AGENTS.md file. Most engineers would use the resulting capabilities without spending extra time developing them. That suggested a different scaling strategy: make the work of a few specialists improve the default environment for everyone.

Jones handpicked about 50 AI champions from critical teams rather than opening a volunteer program. Candidates needed to commit at least 30% of their time to enablement and persist through nondeterministic failures, including tools that did not work out of the box. She spent a week talking with tech leads and managers to identify engineers who could represent the most important repositories.

The champions’ first target was stage 3. Around June 2025, models could write a feature, but the result often failed to follow the team’s conventions and standards. That inconsistency made engineers reluctant to delegate. Champions began adding repository context and rules so agents could understand the codebase, navigate it, and contribute appropriately. The repository was the distribution point: guidance embedded there could benefit every contributor, not just the champion who wrote it.

The program covered Square, Cash App, Afterpay, and TIDAL, with engineers from frontend, backend, mobile, data, and infrastructure. They tested patterns against large legacy monorepos, small services, and mobile applications. For monorepos, JVM developers applied a familiar inheritance pattern: shared context and rules at the root, with more specific guidance at the service level.

That arrangement can be expressed as a small repository structure:

repo/
├── AGENTS.md
└── services/
    ├── payments/
    │   └── AGENTS.md
    └── notifications/
        └── AGENTS.md

The root file holds shared guidance; each service file adds local conventions. The service names illustrate the arrangement, while the root-and-service layering is the pattern Jones describes.

The champions also discovered that web patterns did not necessarily transfer to mobile, and Android and iOS sometimes needed different approaches. Each champion chose what worked for their repository. Teams with similar repositories then converged on useful tools and patterns. This produced common components without requiring identical implementations.

The repository toolkit consisted of:

• Context: AGENTS.md or CLAUDE.md to explain the repository and guide contributions.
• Rules: Guardrails for agent behavior.
• Repeatable workflows: Slash commands, followed later by agent skills.
• AI review: A code reviewer with instructions about what matters and what to inspect.
• Attribution: Identification of AI involvement on pull requests.

Agents were now writing PRs, but delegation was still concentrated among the champions. Repository preparation had improved the work agents could do; it had not yet made delegating to them routine across the teams.

Even champions were still babysitting agents. To make delegation more hands-off—and accessible to engineers outside the program—the team connected agents to the places requirements already arrived: Jira or Linear, GitHub issues, and informal Slack conversations. Champions implemented entry points for all three.

A Slack bug discussion shows how this changed the workflow:

1. An engineer reported a product bug and asked whether anyone else had seen it.
2. After another engineer replied, a third mentioned goose and asked it to investigate.
3. goose retrieved the repository files, confirmed the bug, and proposed three solutions with code snippets in the thread.
4. The engineers agreed on option one and asked goose to implement it.
5. goose made the change and returned a PR link.

Jones reports that this particular cycle—from discussion through diagnosis, issue creation, alignment, and a fix returned as a PR—took about five minutes. The human decision remained explicit: goose proposed alternatives before the engineers selected an implementation.

Engineers could also assign Linear tickets, Jira tickets, and GitHub issues directly to an agent for implementation. Agents became part of sprint execution. In the first team trial Jones describes, the team ran out of planned work and pulled in more tickets twice. Managers and product teams liked the flow, while engineers could delegate without first learning every technique the champions had developed. The prepared repositories supplied the foundation; familiar work surfaces supplied the interface.

Three months after launching the champions program, Jones reported these changes:

The talk does not supply baseline definitions, absolute volumes, or measurement methods. These are reported program results, including self-reported time savings; they do not directly measure the original problem of elapsed time to customer delivery.

Once engineers could delegate reliably, moving to stage 4—multiple agents working in parallel—was comparatively easy. But the added production shifted pressure downstream. Jones describes engineers tripling or quadrupling their PR output while changes waited for review. Human reviewers had already struggled to keep up before agents increased the volume.

Earlier in the program, AI review had been optional because poor results frustrated engineers. Repository preparation, better models, and improved tools made it more useful. Block enabled Codex across its repositories and added an autofix loop:

1. Codex reviews the PR and identifies issues.
2. A separate agent fixes the identified issues.
3. That agent commits the changes to the PR.
4. Human reviewers receive a cleaner change to inspect.

The separate fixing agent was part of Block’s workflow, rather than a capability to infer from Codex’s review integration alone. The loop reduced complaints about reviewing sloppy bot PRs, though Jones says review capacity remained an incompletely solved problem.

Parallel execution also created a local infrastructure problem. Agents interfered with each other while working, and engineers’ laptops ran short of memory and CPU capacity. Block moved the work into dedicated cloud workspaces, with each agent running in its own isolated environment. This separated concurrent work and let engineers run agents from anywhere without carrying the entire compute load on a laptop.

Jones describes engineers running four or five agents at a time, with concurrency continuing to grow. A small group, including many champions, began building Builder Bot, an internal orchestrator to coordinate that work. Isolated execution made concurrency practical; orchestration addressed how to direct the growing group of agents.

An orchestrator cannot coordinate complete engineering tasks if its agents do not know where services live or what depends on what. Jones says Block built a company world model from its 25,000-repository codebase: a machine-readable view of services and their connections. This extended context beyond the local guidance that champions had placed inside individual repositories.

The world model let the orchestrator and its delegated agents retrieve context as needed. Multiple agents could explore different areas of the system concurrently, build an understanding of their assigned areas, and return their findings. The orchestrator then combined those findings into a plan spanning multiple codebases. That was especially useful for offerings that crossed product boundaries, where a feature could not be understood as a change to one repository alone.

Jones describes this as reaching stage 5: engineers could delegate complete tasks and receive shippable results without guiding the agent through each step. The interface also opened the workflow beyond engineering. Anyone at the company could mention Builder Bot in Slack to request a bug fix or a feature without needing GitHub. The outcome described is shippable work, not an established process for automatically deploying it to production. What had seemed like an extraordinary success then gave way to a much harder question.

The closing turns to layoffs. Jones describes this round as feeling different and asks whether she was responsible: had enabling employees to do extraordinary work ultimately contributed to their dismissal? She presents that as a painful question, not a demonstrated causal relationship between the champions program and the layoffs.

The day before, she had felt proud of what employees could accomplish and of having built an autonomous engineering organization. That pride now sat beside uncertainty about its purpose. The talk ends with questions rather than another maturity stage: “What are we doing? Where are we heading?” And finally: “And are we sure that it's where we want to end up?”