Heard the news? Coding isn’t a bottleneck anymore. Software engineers have the tools to be more productive than ever. And still, we don’t see value creation from volumes of code translating to actual economic output. Or, maybe you yourself can’t ship things that make a dent. What gives?

It’s always been hard for developers to relay “why they’re slow” to decision makers, even fairly technical ones. Software engineering is riddled with path dependency problems.

“We have to update the button styling, but the new button component uses Bootstrap 4 while we’re on Bootstrap 3. So we have to migrate the framework before we can change the button.”

Yak shaving, all the way down.

But a task like that no longer takes the budgeted two-month uplift. Claude Code can write a battery of regression tests. Components can be updated in bulk. You can take screenshots of every page and diff them using AI. In the same way, you can pay down enormous amounts of tech debt — if you have the right people capable of doing the thinking on how to pay it down.

So why aren’t companies moving 2x, 3x, or 10x faster?

1. You don’t have good ideas

Contrary to what you may have believed, shipping things was never your bottleneck. You may have gotten lucky with a good idea once, then extrapolated on that curve into a self-reinforcing belief that you’re capable of always having good ideas.

Your team can technically ship many small experiments now. But you don’t know what to ship. Or you have ideas on what to ship, and they’re all bad ideas.

“Taste” is not something easy to come by, and not all companies are meant to be successful. LLMs will probably help you get where you’re going much faster — even if it’s in the wrong direction.

2. You have larger organizational problems

Perhaps your org is beholden to Conway’s Law and you’re shipping your org chart rather than useful products.

Perhaps you’ve set your incentives in a way that people get paid more for making good decks than shipping actual products.

Or perhaps you haven’t really solved your PMF problem.

Whatever it is, there might be something at the macro level that puts a force dampener on your ability to ship good products. Your engineers might actually be 2x more productive, but the extra velocity is being burned off in places where you’re not capturing value.

3. You don’t have good operators

Developing tasteful products requires constant iteration via minimally viable drops. These drops require hard tradeoffs. Hard tradeoffs require good operators — people who can say “we’re optimizing for X and not Y, and that’s okay,” and then wear the consequences.

Then they go to market and make X work relentlessly.

Doing constant iteration via prototypes has never been cheaper in human history. If you still can’t do this, then — contrary to what you believed, dev velocity is not your problem anymore. You might not have good operators who can productize what you build.

If you have people on board who can’t think critically about those tradeoffs, vibecoding is not going to solve this. Everybody has access to the same LLMs you have and the tools are not going to be the differentiator if you don’t have the operators who can direct them in useful ways. [1]

4. You don’t have the vocabulary to understand how software works

So many people vibecode a tool over the weekend and extrapolate that into the experience of building complex software. People who do this are typically not software engineers and tend to have a surface-level understanding of how software works. (For example - sharing localhost URLs on LinkedIn)

If you don’t have a deep enough understanding of the underlying abstractions, you run into the XY problem [2]. The thing you’re asking Claude Code to do is not the thing you actually want it to do. You really want to solve Y, but you don’t have the vocabulary to ask the correct question.

You can vibecode your way through some complexity. And as long as the required complexity of the product stays well under that threshold, you’ll ship a successful product. But most “useful at scale” software lives above that threshold. [3]

[1] This is true for “right now” - where human creativity still has the upper hand.

[2] https://en.wikipedia.org/wiki/XY_problem

[3] I think this is the reason why most people can build their own personal note taking apps and to-do apps. Once you lack the need to scale beyond 1 user, most software becomes extremely simple.