Jack Dorsey just cut 4,000 jobs at Block. Revenue is up. Profits are up. And he still cut nearly half the company.
His reason: writing code is no longer the bottleneck.
I can prove he’s right with four days of data: 57 pull requests, 12 repositories, +142,000 lines of code—while running a go-live project across 20 clients, four countries, and 30+ locations in parallel. Less than 1% of that code written by me.
But the numbers aren’t the point. The point is where the bottleneck moved.
Writing Code Was Never the Hard Part
For the last 20 years, software development had a simple scaling problem: you needed engineers to write code, and engineers were expensive and scarce. So companies hired teams of 10, 20, 50 developers. Every abstraction layer—architect to senior to mid to junior—existed because translation was manual. Someone had to convert vision into system design into components into implementation into tests. Human APIs at every level.
That ratio is collapsing. One person with an LLM can now do what previously required a team. The 20:1 ratio is becoming 1:1. The translators are being automated away—not because they’re bad people, but because translation is now cheap.
What this means: writing code, which was the constraint, is no longer the constraint.
The Bottleneck Moved
The new constraint is understanding what to build and why.
That sounds obvious. It isn’t. Here’s how you can tell: most developers don’t know their users. They know their tickets. They know their codebase. They know their architectural patterns. But the person on the other end—their workflow, their frustrations, their actual goals—is often fuzzy at best.
This is what the Germans call Bodenhaftung—ground contact, traction. Or rather, the loss of it. A car with no Bodenhaftung loses control. A developer with no Bodenhaftung loses the user. They’ve been heads-down in the codebase for two years and now know less about the people using that system than a product manager who joined last month. Or an LLM that has ingested thousands of similar user contexts.
And here’s the uncomfortable reality: if the agent knows your users better than you do, you don’t have a job anymore.
Not as a prediction. As a current state. This is happening now.
The Handwerk Problem
A lot of developers ended up in software because they love the Handwerk—the craft of coding itself. The elegant architecture. The clever pattern. The clean abstraction. There’s genuine joy in building a system that fits together perfectly, and that joy has been a reliable predictor of quality work.
But craft and outcomes are not the same thing.
The developers who consistently ship valuable software were never the best coders. They were the ones who cared about what the code actually does—who stayed close to the customer, who questioned whether the feature being built was the right feature, who felt the friction when something didn’t work and couldn’t rest until they understood why.
Herzblut for the code itself isn’t enough anymore. The knitting machine can knit. What it can’t do is care about whether anyone actually wants the pullover.
The Handwerk-lover is in trouble. The outcome-driver has more leverage than ever before.
What Survives
The developers who will thrive in this environment share a few characteristics:
They know their domain. Not just the codebase—the actual business problem, the actual users, the actual constraints that matter. They’ve earned the right to make judgment calls because they have the context to make good ones.
They own end-to-end. Not just the code they write, but what happens after it ships. QA, release safety, monitoring, rollback. The AI generates code cheaply; what’s expensive is understanding whether it actually worked.
They’re close to the outcome. They feel it when something doesn’t land. They don’t need a ticket to know there’s a problem—they already know, because they’re paying attention to the right signals.
They make assumptions. This is the underrated one. When requirements are ambiguous, they don’t wait for perfect specifications—they explore, they build a version, they come back with options. The LLM taught us this is the right approach. The best developers were already doing it.
The Organizational Consequence
This isn’t just about individual developers. It changes what a healthy engineering organization looks like.
We don’t need bigger teams. We need smaller teams of people who know what they’re doing, why they’re doing it, and for whom. Teams that can take a problem from first principles to production without hand-offs that lose context at every boundary. Teams where the person who understood the user problem is also close enough to the implementation to notice when the solution misses.
A team shrunk from 10 to 2 has to reinvent how it works. A team shrunk from 10 to 8 just shuffles assignments. The first team will be faster in six months. The second will be slower.
Companies that treat this as a headcount problem are solving the wrong equation. The question isn’t how many developers you need—it’s whether the developers you have are the kind who care about what gets built.
The Deadline
There is a deadline on this. Not an arbitrary one.
The competitive dynamics are shifting fast enough that companies which haven’t restructured around this by end of year will find themselves outrun by smaller teams that moved earlier. Not because AI magic—because execution speed compounds. A team of three outcome-driven developers with good tooling can outship a team of fifteen Handwerk-focused coders on almost any product problem. That gap, once it opens, is very hard to close.
The companies that understood this early are already moving. The rest will understand it when they see the output.
The One Question That Matters
If you’re a developer reading this: you already know which side you’re on. The fact that you’re interrogating this puts you ahead of most.
If you’re leading a company or an engineering organization, the question is different—and harder:
Do you actually know whether your team is outcome-driven or craft-driven? Not based on what they tell you in sprint reviews. Based on whether they could describe your customers’ real problems without looking at a Jira ticket.
Most leaders can’t answer that with confidence. And that gap—between what you assume about your team and what’s actually true—is where the competitive risk lives.
The moat you built by investing in headcount is gone. The new moat is organizational clarity: small teams, full ownership, Bodenhaftung to the actual problem being solved.
Companies that figure this out in 2026 will look back and wonder why it took so long. Companies that don’t will feel it first in their pipeline—and understand it only after.
Companion piece: The Knitting Machine Ate Your Job — the longer argument about craft vs. outcomes.
Jack Dorsey’s announcement at Block — the signal that kicked this off.
Inspired by this video breakdown of the full context.