Every tool installed, nothing moved
Block is the fintech company behind the payment service Square. It handed AI coding tools to most of its engineers — 3,500 of them — and ran company-wide training. On adoption alone it sits near the top of the industry.
And yet products did not ship faster. Code came out more quickly; the product did not change at the same rate. The cause was not unused tools. Engineers had a psychological hurdle about how far to trust AI-written code before shipping it, and an approval process sat on top of that hurdle.
What finally worked was not training all 3,500 people harder. Fifty champions were picked to prove in practice that the thing worked, and the culture spread outward from them. Tool coverage was already near total, so the remaining variables were people and process.
Building a stretch of highway does not guarantee cars will drive on it. The highway exists and nobody enters it — that is the real bottleneck. If your organization has run AI training and still has no experience of work moving twice as fast, this is usually where it is stuck.
How Anthropic turned five or six months into one to three days
Anthropic came at the same problem from the opposite side. Building and releasing a product used to take it five or six months. That cycle is now one to three days — days, not months.
The mechanism was not a better tool but a new unit of release: the research preview. Instead of hiding a feature until it is finished, the in-development version is placed where interested users can switch it on and try it. Open the Claude desktop app and the layout keeps shifting — chat and code split apart, collaboration folding into chat — and that churn runs on this unit.
What the unit actually removed was not quality but waiting. The stretch where every decision goes up the chain for approval and everything waits for completeness disappeared. Instead of waiting for perfect, ship something small and learn from how people use it.
One thing is easy to misread here. Attributing the one-to-three-day cycle purely to AI-assisted coding sees half the picture. Coding speed was already high. What converted that into a step change was redesigning the structure of judgment and approval — laying new pipe so the speed the tools created could actually flow through the organization.
Rereading it through Pareto: the cost of lifting 80 to 100
The Pareto principle is the rule of thumb that 80 percent of results come from 20 percent of causes. It is often stated as the 80/20 rule — 80 percent of revenue from the top 20 percent of customers, and so on.
Applied to a development schedule it reads like this. The core 80 percent of features, the part people actually use, arrives in 20 percent of the total schedule. The remaining 80 percent of the schedule goes into lifting that 80 to 100: edge cases, screen polish, rare-path handling, internal review and sign-off.
The key question follows. Has the market ever asked for that last stretch of polish? In most projects it has never been tested. Eighty percent of the schedule goes to refinement nobody requested, while the other 20 percent the market actually wanted never gets touched before launch.
So reverse the order. Ship at 80 and let market response decide the remaining 20. Fill in what gets used; drop what nobody touches. The time to first release becomes 20 percent of the whole — a fifth. That is structurally what Anthropic did with the research preview.
If this sounds like abandoning quality, look at the ordering again. You are not giving up on 100. You are choosing which 20 percent to lift to 100 based on usage records rather than your own guess. It changes the distribution of polish, not its total.
So where do you cut the 80 percent?
Measured by feel, 80 percent means something different every time. A usable working definition: one core user flow runs end to end. If a single line — request comes in, result goes out, record is kept — turns without breaking, that is 80 percent. Edge cases attached to that line, the second user type, the admin screen: still the last 20.
For the first build, bound the scope like this. One kind of task only. Users limited to yourself or your team. One or two core features. Sample or de-identified data. A human reviews the output at the end. And a way to fall back to the old method the moment something goes wrong.
If it wants to grow past that, cut it back. The thought 'while we're at it, let's add this too' is the seed of failure. A wider scope pushes first release later, and once release is late you end up filling the last 20 percent with your own guesses before any market response arrives. At that moment you are back to option A.
How to build it is no longer the barrier. In an era where describing something in words gets you working code, you do not need deep programming knowledge to build one small solution yourself. What matters is not how you build but what you are testing. There is no need to learn to code before starting.
Without measurement you cannot tell 80 from 100
Shipping at 80 presupposes measurement. If you claim you will read the response and decide the rest, then measure nothing, all that remains is a feeling that things improved. Attachment to something you built yourself makes that illusion worse.
The numbers to take are fixed: working time, waiting time, errors and omissions, revision counts, and whether users actually came back to it. Put them beside the numbers from the old way. Drafting went from forty minutes to fifteen; revision requests from three to one. That is what confirmation looks like.
If you do not know where to measure, start from five bottleneck signals: waiting, where work stops pending an approval or a reply; rework, where the same document is rebuilt every week; person dependency, where nobody can proceed when one person is away; system breaks, where data is copied out of a messenger and pasted into a spreadsheet; and exception blowup, where exceptions outnumber the happy path. Whichever one makes you flinch is your first target.
The numbers may have gotten worse. Then fix it. If fixing does not help, throw it away — redesign differently and re-diagnose. Not being able to throw things away is the bigger waste. That is also why Anthropic can run a one-to-three-day cycle: because things that go unused can be dropped, the loop can stay short.
Who decides when something is finished?
What Block's case shows is that organizational speed comes from decision structure, not from a tool inventory. So the question to audit is not which AI you use, but who declares the work done, and when.
In practice it helps to split decisions in two. Reversible decisions ship without approval: interface wording, internal tools, experimental features — things you simply roll back if they are wrong. Irreversible decisions get human sign-off: anything sent to customers, payments, deletion of records, hiring and evaluation, confidential and personal data.
Draw that line in advance and most of the waiting evaporates. Approval queues form because reversible work is also sent up the chain. Anthropic's research preview is, in the end, a device that pulled reversible releases out of the approval path.
The same holds at the individual level. Decide up front what AI may handle on its own and what you must approve, and you stop halting to adjudicate every time. In real work, an AI that knows where to stop outlasts an AI that is merely capable.
What you can do today
Pick one thing you are working on and write it as a single sentence: I will change this bottleneck in this task by this method and produce a measurable result. All four slots must be filled for it to be a project. 'Our team will actively use AI' is a resolution, not a project.
Filled in, it reads like this. To reduce missed items and repeated edits in compiling the weekly report, I will build a collection tool with required fields and review criteria, and compare drafting time and revision counts against the old method.
Then define in one line where the 80 percent ends. Write down the point at which one core flow runs end to end, and actually release at that point. Use it in real work for at least a week and collect numbers.
The remaining 20 percent gets decided then. A week of usage records tells you where to fill in — more accurately than your guess, and without spending 80 percent of the schedule up front.