The most dangerous number in technology right now is a multiple with no denominator.
Last week a press release from Block, the publicly traded fintech company that used to be called Square, arrived with exactly one quantitative claim attached to it: three times the feature delivery, produced by a smaller team, credited to AI tooling. No baseline year. No product line named. No definition of what counts as a feature, and no statement about whether machine-generated code is included in the count. Just the multiple itself, polished and unattached, floating above the evidence like a balloon with no string.
I have read a great many of these. In the spring of 2020, when DeFi Summer turned yield farming into a spectator sport, I ran three free safety workshops a week for people who had just deposited their savings into contracts they could not read. Three hundred of them came. I did not teach them DeFi theory. I taught them a checklist: name the failure mode, then find the line of code that contains it. The lesson I carried out of that year is the one I bring to every announcement like this one. A number without a stated failure mode is not information. It is advertising.
Let me be precise about what I am and am not arguing. I am not calling Block dishonest. I am not claiming AI does not accelerate software work, because it plainly does, and I use it every day. I am arguing something narrower and more useful: as stated, the claim cannot be tested. And untestable claims are how an industry talks itself into a position it cannot later defend.
Context: Why a Fintech Press Release Belongs in a Crypto Conversation
To understand why this should matter to anyone holding crypto, you have to start with what Block actually is, because the company is not a crypto project and never has been. Square was founded in 2009 as a payments hardware company. It renamed itself Block in 2021, went public on the New York Stock Exchange, and in early 2025 changed its ticker from SQ to XYZ. Its revenue comes from merchant acquiring, from Cash App, from the Afterpay acquisition, and from a hardware and lending portfolio that has nothing to do with distributed systems.
What makes Block a permanent fixture in crypto conversations is a set of adjacent bets. Cash App lets users buy, hold, and withdraw bitcoin. Bitkey is a self-custody hardware wallet built with a multi-signature recovery design. Proto sells bitcoin mining hardware and manages mining operations. Spiral and TBD fund open-source bitcoin and Lightning work, including the goose project. And on the balance sheet, Block has held roughly eight thousand bitcoin for years, a treasury position that makes its equity partially a bitcoin proxy whether management wants it framed that way or not.
None of that appears in the efficiency announcement. Not one word about Cash App, Bitkey, mining, or the bitcoin reserve. The press release is about software delivery inside a corporation. Which is exactly why it deserves attention, and exactly why the crypto framing around it has been so lazy.
The second piece of context is the tooling. Between 2023 and 2026, AI coding assistants moved from novelty to default infrastructure. GitHub Copilot, Cursor, Anthropic's Claude Code, and a dozen IDE-integrated competitors now sit inside the development workflow at nearly every large technology employer. Sundar Pichai said in late 2024 that more than a quarter of new code at Google was being generated by AI and then reviewed by engineers. Microsoft executives put their own figure near thirty percent in early 2025. Meta's leadership spent 2025 telling analysts that mid-level engineering work would be substantially automated within a year or two.
The point is not that Block is lying. The point is that Block is describing a baseline, not an advantage. Every serious engineering organization on earth is running this same experiment simultaneously. When a company presents the industry's common condition as its own achievement, the correct analytical response is not skepticism about AI. It is skepticism about the framing.
The third piece of context is the one nobody puts in a press release: we are in a sideways market. Nine months of range-bound price action have taught traders that narratives are now cheaper than catalysts. In a chop, announcements like this one do a specific kind of work. They are not price signals. They are positioning material, and they are consumed by people who are waiting for direction and will accept almost any direction they can find. That is the condition under which an undefined multiple becomes dangerous.
The Measurement Problem: DORA Has Four Numbers, and None of Them Is "Features"
If you want to know whether a software organization got faster, there is a well-established way to ask. The DORA research program, which has been surveying engineering teams for a decade, tracks four metrics: deployment frequency, lead time for changes, change failure rate, and time to restore service. Two of those measure speed. Two of those measure whether the speed was real.
A claim of three times the feature delivery is a claim about one half of that ledger. It says nothing about change failure rate, which is the percentage of deployments that cause an incident. It says nothing about time to restore, which is how long you are down when the incident happens. And it says nothing about the denominator problem that has plagued every productivity study since the first line of code was written.
I have done this work from the other side. When I audited contracts manually with community members in 2020, the checklist we used was crude, and it worked for a reason that generalizes here. A checklist forces you to name the specific failure mode before you evaluate the control. "Is this safe" is not a question. "Can the owner drain the pool without a timelock" is a question. The difference is not academic. One produces a feeling. The other produces a yes or no.
This is where the 2024 DORA report matters. Its finding was uncomfortable and widely misread. AI adoption correlated with improvements in individual developer productivity and code quality perceptions, and simultaneously correlated with worse delivery stability at the team level. Engineers felt faster. Systems became less predictable. Those two facts are not contradictory. They are the natural result of generating more change than your review and testing capacity can absorb.
GitClear's longitudinal analysis of hundreds of millions of changed lines found something similar, and more specific. Code churn, meaning lines written and then reverted within weeks, rose sharply. Copy-paste volume began to exceed moved-code volume for the first time in the dataset's history. The industry added throughput without adding durability, and the accounting showed it.
So when a company says three times, the honest follow-up is not "impressive." It is: three times what, over what window, measured against which baseline, at what change failure rate, and verified by whom? A multiple that cannot answer those questions is not a data point. It is a mood.
Where AI Genuinely Helps, and Why That Is Not Reassuring
I want to be fair to the technology, because the reflexive dismissal of AI tooling is its own kind of intellectual laziness. There are categories of software work where these models are unambiguously transformative, and I have felt it in my own hands.
Boilerplate is the obvious one. Struct definitions, serialization layers, HTTP client wrappers, SDK bindings across eight languages, configuration parsing, CLI argument handling. A model that has seen ten thousand implementations of a REST client can produce the eleventh in seconds, and the eleventh is usually correct. Test scaffolding is another. Generating property-based fuzz harnesses that I would never have had the patience to write by hand has genuinely improved the depth of review work I do, because it lets me spend my attention on the invariants rather than the plumbing. Front-end components, data migrations, documentation drafts, changelog generation, and refactoring mechanical patterns all fall into the same bucket.
Now look at what that list has in common. In every case, the failure mode is cheap. A wrong serialization call throws an exception at compile time or in a test. A broken UI component is visible. A bad migration is annoying but recoverable. The blast radius is local, the feedback loop is short, and the cost of being wrong is measured in hours.
Compare that with the work where the failure mode is expensive. Consensus rules. Incentive design. Oracle handling. Upgrade and governance paths. Liquidation logic. Access control. Cross-chain message verification. In these domains a mistake is not a compile error. It is a nine-figure protocol loss, and the feedback loop is measured in months, if you get feedback at all.
The efficiency gains from AI are concentrated precisely where errors are survivable, and thin out exactly where errors are catastrophic. That is not a complaint about the tools. It is an observation about what the tools can and cannot tell you about a claim like three times.
If a team triples its output on the cheap-failure half of the stack and holds steady on the expensive-failure half, the aggregate number looks spectacular while the risk profile is essentially unchanged. The arithmetic of the announcement is doing no work that the arithmetic of safety would not contradict.
The Three Times That Does Not Compound
Here is the part of the story where I stop hedging.
Protocol development is not a throughput problem. It is a redundancy problem. The reason open, permissionless systems can be trusted by strangers is that the code path from idea to deployment is intentionally slow and intentionally over-populated with humans whose job is to say no. Draft proposals. Public discussion periods. Independent implementations. Testnet deployments that anyone can interrogate. Bug bounties. Multiple reviewers on every commit that touches value.
That redundancy is the product. It is what a user is actually buying when they trust a contract with their savings. Not the elegance of the code, but the number of independent human minds that tried and failed to break it before it went live.
Now read the announcement again. Three times the features. Smaller team. Those two clauses are not independent. One of them pays for the other. If output per person triples and headcount falls, the people who left are overwhelmingly likely to be the ones in the review path, because review is the work that does not show up in a feature count. You can delete a reviewer and your deployment frequency goes up on the same afternoon.
I watched a version of this in 2021. When I built ArtOnChain to connect local Denver artists with on-chain tooling, the loudest conflict was never technical. It was between the people who wanted the thing to be legible and slow, and the people who wanted it to be liquid and fast. The traders won the argument about speed. The artists won the argument about meaning. What both sides lost was the shared vocabulary they had started with, and rebuilding it took longer than shipping anything.
That is the version of three times I worry about. Not the code. The shared vocabulary.
What Block's Bitcoin Business Actually Depends On
There is a second, quieter question hiding inside the announcement, and it is about bitcoin rather than about AI.
Block's crypto footprint is unusual because it spans the full vertical. Cash App is a consumer distribution channel for bitcoin. Bitkey is a self-custody product, which means its security properties are the product, not a marketing attribute. Proto sells and operates mining hardware, where firmware integrity matters. Spiral funds open-source work whose value is measured in the opposite of efficiency: careful, slow, adversarial refinement of consensus-adjacent software.
If AI-assisted development genuinely accelerates iteration across that portfolio, the benefits will not distribute evenly. They will land hardest on the fast-feedback products, which is to say the consumer surfaces, the interfaces, the onboarding flows, the things that make a customer acquisition metric move. They will land lightest on the adversarial surfaces, because that work is defined by the absence of a feedback loop. You cannot fuzz your way to confidence in a hardware wallet's key-recovery design. You can only put more careful humans in front of it.
This is the uncomfortable corollary of an efficiency narrative inside a company that holds roughly eight thousand bitcoin and sells self-custody hardware. The story that supports the treasury thesis is a story about margin. The story that supports user safety is a story about redundancy. They are not the same story, and the second one is not improved by the first.
There is also a broader point about what bitcoin has become that sharpens this. In the years since spot ETF approval, the asset has been progressively repackaged into a portfolio instrument, with custody, yield, and access layers that look increasingly like the products they were designed to replace. Block sits on both sides of that line, holding bitcoin and building self-custody tools. When a company on both sides of that line announces an efficiency program, the question of which side gets the efficiency is not a rhetorical one.
The Contrarian Angle: The Wrong Debate
Everything I have written so far is, I suspect, the conventional skeptical take, and I want to push against it, because the conventional skeptical take is answering a question nobody asked.
The popular framing goes like this: AI either does or does not make engineers faster, and Block's announcement is evidence in that debate. That framing is a distraction. The real question is not about velocity at all. It is whether the AI-native small team is structurally compatible with the trust requirements of open, permissionless infrastructure.
Consider the counterargument, and take it seriously. Open-source has always been small teams. Bitcoin was a handful of people writing C on a mailing list for years. Linux was famously one person before it was thousands. If small teams built the things we trust most, why would a smaller team at Block be evidence of decay?
It would not be, except for one difference that the analogy hides. The early bitcoin and Linux contributors produced a surplus of reasoning, not just a surplus of code. The mailing list archives, the design debates, the rejected proposals, the long arguments about why a specific approach was wrong. That public argumentation is what allowed a stranger to evaluate the software without trusting its authors. The artifact was never the point. The legibility was.
Here is where I land, and it is a less comfortable place than pure skepticism. The risk is not that AI shrinks engineering teams. The risk is that AI produces code without producing the argument, and the argument is the thing that makes code contestable.
A model can generate a working implementation. It cannot tell a stranger on a forum why the implementation is safe, what alternatives were considered, or which assumptions would invalidate the whole design. A small team that still writes things down is a healthy team. A small team that lets the model output the artifact and skips the argument has quietly converted its codebase into something nobody can audit, including itself.
I have seen this in miniature. When I generated fuzz harnesses with a model during a review, the harness found nothing interesting in the first pass. It was the process of explaining to myself why it found nothing that surfaced the actual problem, which was a missing invariant rather than a broken line. The tool produced the test. The reasoning produced the bug. Those are different workflows and only one of them scales by a factor of three.
Takeaway: The Question for 2026
Three times is not a lie. It is an incomplete sentence, and the industry's habit of completing such sentences with enthusiasm rather than evidence is how we got a decade of protocols that were fast to ship and slow to survive.
The productive response is not to reject AI-assisted development. I use it, and its gains in the mechanical layers of software are real and worth having. The productive response is to insist on denominators. Ask what the baseline was. Ask what the change failure rate did. Ask which reviews were removed. Ask whether the reasoning that used to live in a mailing list now lives anywhere at all, or whether it left with the people.
Because the thing that makes a decentralized system trustworthy was never its shipping velocity. Community is not a user base; it is a shared soul, and souls are made of arguments that a stranger can still read five years after the merge. We build not for the token, but for the tribe, and the tribe needs to be able to see the seams.
So here is the question I am holding heading into the rest of this cycle, while the charts chop sideways and everybody hunts for a signal with a clean number attached to it. If your protocol doubles its shipping speed and halves the number of humans who can explain what it does, what exactly got faster?
I do not think the answer is the product. I think the answer is the exit.