AI adoption did not improve delivery speed until agents were integrated into repositories, requirements, reviews, and deployment workflows.
2
A small AI champions program helped 3,500 engineers adopt repository patterns and delegation flows without imposing one uniform setup.
3
Multi-agent work created new review, compute, coordination, and organizational problems that remain unresolved.
Summary
Angie Jones describes Block's attempt to move a 3,500-person engineering organization from occasional AI assistance to agent-led software delivery. Early adoption was high, but delivery did not get faster because engineers mainly used agents inside their IDEs. Jones introduced a maturity model, then formed a handpicked group of about 50 AI champions who prepared repositories with context files, rules, workflows, reviewers, and attribution. They connected agents to Slack, Jira, Linear, and GitHub so engineers could delegate work through existing processes. This produced reported gains in AI-authored code, time savings, and automated pull requests. Moving to multiple agents required automated review fixes, isolated cloud workspaces, and an orchestrator called Builder Bot. A machine-readable model of Block's repositories helped agents coordinate work across services. Jones ends with the human cost of this progress after layoffs at Block, questioning what an autonomous engineering organization is meant to achieve.
High AI usage did not automatically make software delivery faster
Block began building Goose before language models supported tool calling and worked with Anthropic on the initial release of MCP. After a few months, about 90% of engineers regularly used Goose or Claude Code to generate code. The usage numbers and token bills showed clear adoption, but features were not reaching customers faster. Jones places adoption in three phases: experimentation, adoption, and impact. Block had moved beyond experimentation, yet most engineers were still asking questions or generating boilerplate inside their IDEs. She concluded that impact required integrating AI into the way teams built and shipped software, rather than treating it as a coding helper.
An agentic engineer delegates and verifies work as a normal workflow
Jones defined an agentic engineering organization as one where engineers use AI agents as their primary way to produce engineering outcomes. Agents become part of the workflow: engineers decompose problems, delegate tasks, review results, and verify the work. Her maturity model tracks that relationship. Stage zero means no AI use. Stage one is autocomplete, stage two is chatting with agents, and stage three is delegating tasks and reviewing the output. Stage four involves running multiple agents in parallel. Stage five means an agent can complete a task and produce a shippable result without constant human guidance. Most Block engineers were between stages one and two, while Jones wanted to reach stage five.
A small group of selected champions can spread agent practices across the organization
Jones rejected a strategy that depended on all 3,500 engineers teaching themselves new agent techniques. She used the 1990 rule as a model: a small group creates patterns, a larger group interacts with them, and most people consume the results. She selected about 50 engineers from critical teams for an AI champions program. This was not an open volunteer effort. Champions needed to spend at least 30% of their time on AI enablement and tolerate the unreliable behavior of early tools. They represented different products, disciplines, repository sizes, and legacy systems. Their role was to reach stage three first, then give other engineers a usable foundation.
Repository preparation makes agent delegation useful to whole teams
In mid-2025, developers often did not trust agents to write code that followed local conventions. The champions therefore made repositories AI ready. They added context files such as agents.md or claude.md, rules files, repeatable workflows through slash commands and later agent skills, AI code reviewers with specific instructions, and AI attribution on pull requests. The approach varied by repository. Monorepos used shared context and rules at the root, with more specific guidance at service levels. Web, Android, and iOS repositories sometimes needed different patterns. Teams chose what fit their codebase, while similar teams gradually converged on common tools and practices.
Delegation works better when it starts in tools engineers already use
The champions connected agents to the three places where engineers commonly receive work: issue trackers such as Jira or Linear, GitHub issues, and Slack. In one Slack example, an agent named Goose inspected a reported bug, confirmed it, suggested three implementation options, and created a pull request after engineers selected one. The full cycle from discussion through diagnosis, issue creation, agreement, and implementation took about five minutes. Engineers could also assign Jira, Linear, or GitHub work directly to an agent for end-to-end implementation. Because the repository groundwork was already in place, most engineers did not need to learn a separate agent workflow.
Parallel agents create review and infrastructure problems that need their own systems
After three months, Jones reported that AI-authored code had risen by 69%, reported time savings had increased by 37%, and automated pull requests had increased 21 times. Moving to stage four, with several agents working in parallel, exposed new bottlenecks. Engineers produced far more pull requests than reviewers could handle. Block enabled Codex across repositories and built an auto-fix loop in which another agent corrected issues found during review and committed the changes. Parallel agents also competed for laptop memory and CPU. Dedicated cloud workspaces gave each agent an isolated environment, allowing engineers to run several agents without making their own machines the limiting factor.
An orchestrator needs a machine-readable model of the company's code
Engineers running four or five agents at once began building Builder Bot, an orchestrator for coordinating them. They also created a machine-readable model of Block's 25,000 repositories. It described where services lived and how they depended on one another. Orchestrators and delegated agents could pull the needed context while working, rather than treating each repository as an isolated project. Multiple agents could investigate different parts of the system, return their findings, and have the orchestrator combine them into a plan spanning several codebases. This helped with offerings that crossed product boundaries and supported stage five, where agents completed tasks without constant human hand-holding.
Autonomous delivery raised questions about layoffs and purpose
Stage five eventually allowed anyone at Block to mention Builder Bot in Slack and ask it to fix a bug or implement a feature without using GitHub. Jones describes that achievement as turning into a nightmare after layoffs. She asks whether enabling employees to do the most impressive work of their careers contributed to their dismissal. The talk does not resolve that question. Jones ends by asking what the organization is doing, where it is heading, and whether that destination is one people actually want. Her account is candid about the gap between technical capability and a clear answer about its human purpose.
"I defined an agentic engineering org as one where engineers leverage AI agents as their primary means of producing engineering outcomes."02:13
Who should watch
You are responsible for AI adoption in a large engineering organization and need a concrete rollout pattern beyond giving developers access to coding assistants.
Your teams use agents inside IDEs but have not seen faster delivery, and you want examples of repository preparation and workflow integration.
You are building multi-agent infrastructure and need to think about pull-request review, isolated workspaces, cross-repository context, and the human consequences of automation.
