Loading today’s stories
Leadership1 distinct publisher3 min readPublished
Block has published the first hard distribution of AI adoption inside a large engineering org: one agent for most, three to five for the next cohort, and a small team building the orchestrator.
The Board Room · Leadership desk
Compiled by The Board RoomSomething wrong?How this is made
Fifty engineers at 30 percent of their time is fifteen full-time equivalents [15], and that invoice does not arrive from a vendor. What it bought is unglamorous: AGENTS.md context files with build and test commands, human-facing HOWTOAI.md guides, packaged agent skills for repeated jobs like API test generation and legacy refactors, automated AI review on pull requests, and headless assistance that iterates on tasks, fixes CI failures and pushes changes [11]. Block says the work was dull enough to need a wrapper, so its developer relations team built Repo Quest, an RPG in which developers collect companions through four tiers running Locked, Novice, Adept, Artisan [12][13].
Where that effort landed is the part other CTOs should read twice. Block put its champions at the repo level, reasoning that the repo is the central point of reference for everyone contributing code, and that agents must be able to discover and consume a codebase before they can be trusted to contribute to it and maintain it [10]. Read alongside the stage distribution, that implies the binding constraint on running five agents in parallel is not the model, it is whether the repository can brief five agents without a human in the loop translating.
The coverage was deliberately uneven in the useful way. The program reached Square, Cash App, Afterpay, Tidal, Proto and Platform teams, spanning frontend, backend, mobile, hardware, data engineering and infrastructure, and repos ranging from massive monorepos to tight focused services [14]. Block says this pressure tested patterns across different engineering realities rather than one. Meanwhile it declined to pick tools, buying a lot of frontier models and IDEs on the grounds that no clear winner emerged across 2025 and locking in would be foolish, while conceding it would like to standardize on a couple eventually [6][7].
Two things should stop anyone from lifting the 95 percent figure as a benchmark. First, Block's own finding that its mobile and JVM backend developers struggle with frontier models and tools in a way web developers do not [8]. A uniform adoption rate across a company with that spread is measuring logins, not leverage. Second, the distribution is ordinal only. Largest, second largest, small: no sizes, no percentages beyond the headline [16]. And Stage 5 is characterised in a single clause, a single agent run mostly outside an IDE [2], with the ladder itself prompted by Steve Yegge's Gas Town essay rather than defined in the post [5]. Nobody outside Block can audit their own position against it.
The org chart claim rests on the smallest group. A population is already building an internal agent orchestrator, described as preparation for the inevitable [4]. That is a platform team forming around agent supervision before any vendor has sold one, funded on the expectation that the Stage 6 cohort keeps growing. Fifteen FTE bought repo readiness. Supervision is the next bill.
Ranked by verification strength, evidence, and original report placement.
About 95% of Block's engineers are regularly using AI to assist with their development efforts.
The largest population of Block engineers is at Stage 5, running a single agent mostly outside of an IDE.
The second largest population is at Stage 6, running 3-5 agent instances in parallel.
A small population at Block is actively building the company's internal agent orchestrator, described as preparation for the inevitable.
The author says reading Steve Yegge's Gas Town article over the holiday break prompted him to consider where Block's engineers are on this journey.
Block buys a lot of AI tools and models rather than locking in, saying AI tooling and LLMs change so rapidly that there is no clear winner yet after this went on through 2025, and that locking in to a specific tool or model would be foolish.
Follow any of these and your For You feed starts watching them — no settings page required.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Detailed but wholly first-party and unaudited
The cluster rests on a single primary source: Block's own engineering blog, authored by the leader who launched the program. Its strength is specificity — named artefacts, named tiers, named business units, a published monorepo context architecture with concrete scale figures — which is hard to fabricate and easy to act on. Its weakness is that every load-bearing number is self-reported with no methodology: the 95% figure has no definition of 'regularly', no measurement window and no instrument, and the cohort split is ordinal only. No independent reporting, customer, or third-party telemetry corroborates any claim, and no outcome measurement (quality, throughput, defect rate) is offered.
Broad internal deployment, self-reported
Adoption evidence is stronger than typical AI-in-engineering posts because it is organisation-wide and structural rather than pilot-shaped: near-universal reported usage, a named 50-developer enablement cohort at 30% time running since August 2025, reach across six business units and six engineering disciplines, and seven distinct coding assistants wired into a 40,000-file monorepo through shared context files. It is capped short of high because all of it is one company's self-report, there is no external usage telemetry, and the intensity distribution (how many engineers actually run 3-5 parallel agents) is never quantified.
Modestly overstated in framing, not in substance
The underlying process disclosure is specific and, if anything, under-sold. The overstatement is in framing and in what the numbers can bear: the story headline says engineers use AI 'daily' while the source says 'regularly'; the 'hard distribution' framing rests on a ranked ordering with no sizes; and 'Stage 5/Stage 6' borrows an external narrative ladder as if it were a measured scale. Nothing in the cluster demonstrates that the multi-agent cohort produces better outcomes — no quality, velocity or defect evidence — and Block itself notes agents hallucinating and producing slop plus persistent mobile/JVM difficulty, which cuts against a maturity-curve reading.
First-party employer-brand and program-owner incentive
The sole source is Block's corporate engineering blog, and the author identifies himself as the person who launched the Champions program being evaluated — a direct interest in the program reading as successful, alongside standard engineering-brand and recruiting incentives for publishing a maturity story. The multi-vendor 'we buy them all' stance is disclosed without naming spend, which is consistent with both an honest hedging posture and a preference not to expose procurement detail. Mitigating factors: the post volunteers unflattering specifics (AI hallucination and slop, mobile and JVM backend struggle, readiness work being unexciting) rather than presenting an unbroken success narrative.
Confident about what was said, not about what it means
There is high confidence in the record of Block's stated practices and program design — the text is explicit, dated where it matters, and internally consistent. Confidence in the quantitative claims and in generalising them is materially lower: one publisher, one company, self-reported figures without methodology, ordinal cohort data, and no outcome measurement. Downstream framing ('daily' use) already drifts from the source wording, so the assessment is held near the midpoint.
leadership
At Ramp, 75% of merged PRs come from a harness no vendor sold it2 distinct publishers
product
Four leaderboards, four denominators: what you buy when you standardize on a coding agent1 distinct publisher
build
Ng's new DeepLearning.ai spec is a reskilling checklist, not a hiring req1 distinct publisher
build
Three named agents shipped in 27 days, and none of them can read each other's config1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
1 article · August 26, 2026