2026-05-21T17:04:50+0000

When coding became cheap, what became more expensive?

The work that decides what to build, who for, and how to reach them did not get cheap when the code did.

Fabian TeichmuellerCo-Founder, Commercial & Operations

A head of product at a small B2B fintech, ten minutes into a discovery call, volunteers this without prompting:

"I have a senior engineer spending two, three grand a month on tokens, and he can churn so much out that I cannot keep pace with him. There's all these different workstreams and I'm having difficulty staying organised, doing discovery calls."

The engineer is now writing code at that pace himself, and the head of product cannot keep up. The discovery calls, the part of the product job that exists to understand users, are among the things being squeezed out. Several heads of product have described variants of this to us over the past two months. No one we speak to disagrees that coding became cheap. The more interesting question is what's gotten (relatively) more expensive.

The cost of producing code has collapsed

Gergely Orosz's March 2026 Pragmatic Engineer tooling survey of more than 900 software engineers found 95% using AI for engineering work weekly, with 56% doing more than 70% of their work through it. Product feels the same shift downstream: Cat Wu, head of product on Claude Code at Anthropic, told Lenny's podcast on 23 April that feature timelines have gone "from six month to one month, and sometimes to one week or even one day".

Constraints, not abundance

AI has not fully automated software production. It's cut a specific set of steps: writing code, translating specs into tickets. From the outside that reads as general abundance because the set is wide and the changes arrived near-simultaneously. The question is which other steps, performed without time pressure while code was costly, are now the constraint.

Eight readings of where the new scarcity sits

Here are eight recent interpretations of where the code abundance is creating new scarcity and constraints:

Typical Set : the work was never typing. "The work was negotiation, with users, with stakeholders, with the world. Externalising the artefacts of negotiation is not the same as doing the negotiation."
Reforge: discovery is the new bottleneck. With code production cheap, knowing what to build matters more than how to build it. Their acquisition by Miro was framed around exactly this thesis.
Andrew Brander: distribution. With supply abundant, the work that remains is getting the built thing seen and chosen. Marketing and audience-building, not engineering, are now what gates outcomes.
Pete Dominguez: taste. When production is cheap, the work that holds value is filtering. Selecting between options well, recognising which one is right. Taste is what cannot be automated.
John Kennedy: the customer interview is breaking. Product managers do less of it than they claim, and users are increasingly unwilling to share the problems they actually have. The methods that worked are no longer producing the signal teams need.
Dept of Product: org structure. The seams between PM, PMM, engineering, and design evolved in a slower world. At the new pace, the system creaks at the seams; handoffs and decision rights are poorly suited to what the team is being asked to do.
Steve Yegge (via Gergely Orosz at Pragmatic Engineer): absorption. Coding agents can run in parallel; humans cannot review them in parallel. The new constraint is the human capacity to absorb what gets produced: review, test, supervise, integrate.
A senior PM at a developer tools company (volunteered in our own discovery this quarter): ideation. "The bottleneck is people producing the ideas, because these things can be implemented in a whim right now." When implementation is fast, the constraint is having something worth implementing.

Each is reasonable, and each is partial. Six of the eight point at the work of deciding: what to build (Typical Set, Reforge, the senior PM on ideation), who for (Kennedy), how to reach (Brander), and how to filter between options (Dominguez on taste). The other two point at how to get people to work (together) well in orgs exposed to these changes.

Our bet

The work that decides what to build, who for, and how to reach them did not get cheap when the code did. That asymmetry is our bet. The elements that are becoming more important are those that do not run on tokens: user research, taste, distribution.

The early product decisions a team makes most weeks are where we're focused at Semilattice. We'll go deeper on that in the next post.

Product

Company