How AI moves the bottleneck in product teams

For most of software history, implementation was the limiting step in producing valuable software.

You could have clarity, vision, and taste. But if you could not turn intent into working code quickly and reliably, none of that mattered.

That constraint is disappearing.

Over the weekend, I listened to Lenny Rachitsky’s interview with Boris Cherny of Anthropic. One of the headline phrases from that conversation was “coding is solved.” I’d been circling this idea for some time and found myself arriving at a similar conclusion, though I frame it a bit differently. Even still, it's clear something structural has shifted.

When I say “coding is solved,” I am not predicting fully autonomous software companies or flawless distributed systems written without oversight. Those futures may or may not arrive.

My claim is simpler and already true:

The mechanical act of translating intent into working code is no longer a meaningful constraint.

We do not need perfection for the economics to change. We only need implementation to stop determining the pace of progress. That threshold has been crossed.

A year ago, “AI-assisted coding” meant autocomplete. Now it means complete, working implementations built in minutes. Tests generated automatically. Refactors executed in seconds. Review feedback synthesized instantly.

When code production is 10×–100× faster, often with equal or better baseline correctness, the economics change. Even if models stopped improving tomorrow, the productivity gains already realized would permanently alter the economics of software. And the models are still getting better.

For all practical purposes, translating intent into working software has gone from being the slowest step to one that no longer determines the pace of progress.

The software production bottleneck moved.

The Engineering Loop

Product engineering is a loop:

1. Frame — define the outcome, constraints, tradeoffs, and success criteria
2. Build — implement the solution
3. Learn — measure results and decide what to do next

These stages feed into each other: Frame → Build → Learn → Frame → etc.

Framing is the disciplined act of defining outcomes, constraints, tradeoffs, and success criteria before building. Building turns that framing into correct code. Learning is the scientific process of testing the hypotheses embedded in your framing against real-world usage and outcomes.

Historically, Build dominated the timeline. It was manual, specialized, and slow. It was the bottleneck.

Now Build costs are collapsing toward zero.

Frame and Learn have become the rate limiters.

When execution becomes abundant, the scarce resource becomes judgment, clarity, and disciplined learning.
‍

AI Amplifies What You Feed It

AI amplifies the quality of the framing that precedes it.

If you do not define outcomes, constraints, and success criteria clearly, AI will accelerate noise.

If you define them rigorously, AI will accelerate signal.

On the left is the failure mode.

Weak framing feeds AI building. AI produces unhelpful output: unnecessary and unstable features that add complexity. Complexity creates noise, and makes the next round of framing even weaker. The system spirals downward.

On the right is the opportunity.

Strong framing defines outcomes. AI accelerates building. Well-framed software provides clear, measurable signals. Signal drives learning. Learning strengthens framing. The system compounds upward.

Melissa Perri describes the “build trap” as mistaking output for outcomes. She coined the term in 2014, so this is not a new challenge. The difference now is that AI coding can supercharge the build trap.

When coding is cheap, you can now produce slop at unprecedented speed.

Bad framing plus AI equals industrialized slop.

Code Is a Sandcastle. Incantations Are the Asset.

Here is a metaphor we’ve adopted at Bonusly.

Code is a sandcastle. If it was built from clear framing, there’s a good chance it’s useful. But it is not sacred. When requirements shift or reality contradicts your assumptions, you change or rebuild it.

What matters more than code is the thing that produced the sandcastle: the incantation.

By incantation, I mean the natural-language context, including:

• The outcome we want
• The constraints that matter
• The approach we are taking
• The edge cases we anticipate
• The success criteria
• The ways this could fail

In the old world, documentation was secondary and often written after implementation. In the new world, the incantation is the primary artifact.

Because the incantation generates the sandcastle.

Strong framing produces incantations that generate useful sandcastles.

Weak framing produces either a formless mound of wet sand — or an elaborate sandcastle that no one needs.

Context now has primacy over code.

What This Looks Like in Practice

This shift did not require our team at Bonusly to “start thinking about outcomes and measuring what we make.” We were already doing that.

Historically, our approach looked like this:

Product Leads, PMs, and Designers did most of the framing. They worked with a Tech Lead to break ideas into atomic tasks. Those tasks were handed to engineers for implementation. Product Leads and PMs handled most measurement and follow-up.

That division of labor made sense when Build was the limiting step. It breaks when Build costs next to nothing. If AI can generate complete, correct implementations in minutes, the bottleneck is no longer task execution. The bottleneck is framing quality and learning speed.

The only way to maximize throughput now is for everyone who builds products to become strong at framing and learning. Companies that preserve a framing/execution split between roles will be lapped by companies in which everyone both frames and builds.

Leverage now comes from clarity, judgment, and disciplined learning, while implementation is commoditized.
‍

Coding May Be Solved, But Engineering Isn’t.

I didn’t become an engineer because I loved coding. I learned to code because I loved building software products that provide value to users. Coding was a means to an end.

Coding, in the sense of translating intent into working software, is rapidly becoming a solved mechanical problem.

But engineering — building things that create real value for users — is not solved. Not even close.

Some critics push back on the phrase “coding is solved.” They point out that AI still produces subtle bugs, struggles with large codebases, and cannot autonomously design robust distributed systems. Those critiques are valid.

But they conflate two different claims. “Solved” does not mean perfect. It means no longer rate-limiting.

The mechanical act of translating intent into working software is no longer the bottleneck in most product teams.

AI compresses the mechanics. It does not compress judgment.

In a world where everyone can code quickly, advantage accrues to teams that:

• Frame clearly
• Define outcomes precisely
• Measure honestly
• Kill weak ideas early
• Go deep on strong signals

Coding is becoming mechanical. Engineering is not.

The bottleneck did not disappear. It moved to the stages before and after code — Frame and Learn.

That is where the engineering advantage now lives.