I completely disagree. As a scientist who does a lot of coding, the modern LLM tools give me ability to code something which previously I could not afford, because I simply did not have time for it.
Now if I have an idea, I may be able to test it in an hour of tinkering with claude/gemini. I could technically still code it myself, but in some cases that would require maybe a day of work -- and I simply don't have that.
Development speed is not a bottleneck
51–60 of 153 posts
Re: Development speed is not a bottleneck
#52Most software projects don't even do A/B tests. A lot of them don't need, it's just what someone wants to ship. Another set can't even get to the sample size required.
But fine, let's take the subset of features / projects that can be tested or somehow validated. In my experience (having worked for 13+ years on companies that prefer to A/B almost everything), more than half of the tests fail. People initially might think the solution is to have better ideas, cook them more, do better analysis. That's usually wrong. I've seen PHDs with 20+ years of experience in a given industry (Search) launch experiments and they still fail.
The solution is to have some sort of "just enough" analysis like user studies, intuition, and business needs, and launch as fast and as many as you can. Therefore, development speed is A bottleneck (there's no Silver Bullet so it's not THE bottleneck).
Re: Development speed is not a bottleneck
#53Earlier quoted context omitted.
This article is right insofar as "development velocity" has been redefined to be "typing speed." With LLMs, you can type so much faster! So we should be going faster! It feels faster! (We are not going faster.) But your definition, the right one, is spot on. The pace of learning and decisions is exactly what drives development velocity. My one quibble is that if you want to learn whether something is worth doing, imp…
Naur’s theory of programming has always felt right to me. Once you known everything about the current implementation, planning and decision making can be done really fast and there’s not much time lost on actually implementing prototypes and dead ends (learning with extra steps). It’s very rare to not touch up code, even when writing new features. Knowing where to do so in advance (and planning to not have to do that…
I wouldn't discuss with that part, although there are definitely limits to how big a chunk of a big product a single brain can really grasp technically. And when the number of people involved in "grasping" grows, so does the coordination/communication tax. I digress, though.
We could go with that perception, however, only if we assume that whatever is in the backlog is actually the right thing to build. If we knew that every feature has value to the customers and (even better) they are sorted from the most valuable to the least valuable one.
In reality, many features have negative value, i.e., they hurt performance, customer satisfaction, any key metric a company employs.
The big question: can we check some of these before we actually develop a fully-fledged feature? The answer, very often, is positive. And if we follow up with an inquiry about how to validate such ideas without development, we will find a way more often than not.
Teresa Torres' Continuous Discovery Habits is an entire book about that :)
One of her recurring patterns is the Opportunity Solution Tree, which is a way of navigating across all the possible experiments to focus on the right ones (and ignore, i.e., not develop, all the rest).
Re: Development speed is not a bottleneck
#54It's completely absurd how wrong this article is. Development speed is 100% the bottleneck. Just to quote one little bit from the piece regarding Google: "In other words, there have been numerous dead ends that they explored, invalidated, and moved on from. There's no knowing up front." Every time you change your mind or learn something new and you have to make a course correction, there's latency. That latency is ju…
This article is right insofar as "development velocity" has been redefined to be "typing speed." With LLMs, you can type so much faster! So we should be going faster! It feels faster! (We are not going faster.) But your definition, the right one, is spot on. The pace of learning and decisions is exactly what drives development velocity. My one quibble is that if you want to learn whether something is worth doing, imp…
It's like speed of light in different mediums. It's not that photons slow down. They just hit more stuff and spend more time getting absorbed and remitted.
Better developer wastes less time solving the wrong problem.
Re: Development speed is not a bottleneck
#55It's completely absurd how wrong this article is. Development speed is 100% the bottleneck. Just to quote one little bit from the piece regarding Google: "In other words, there have been numerous dead ends that they explored, invalidated, and moved on from. There's no knowing up front." Every time you change your mind or learn something new and you have to make a course correction, there's latency. That latency is ju…
[deleted]
Re: Development speed is not a bottleneck
#56It's completely absurd how wrong this article is. Development speed is 100% the bottleneck. Just to quote one little bit from the piece regarding Google: "In other words, there have been numerous dead ends that they explored, invalidated, and moved on from. There's no knowing up front." Every time you change your mind or learn something new and you have to make a course correction, there's latency. That latency is ju…
> It's completely absurd how wrong this article is. Development speed is 100% the bottleneck. The current trend in anti-vibe-coding articles is to take whatever the vibe coding maximalists are saying and then stake out the polar opposite position. In this case, vibe coding maximalists are claiming that LLM coding will dramatically accelerate time to market, so the anti-vibe-coding people feel like they need to claim…
Since I haven't mentioned the context in the article, it is a small agency with a customer target of early-stage (ideally earliest-stage) product startups.
We have literally one half-hour-long sync meeting a week. The rest is as lightweight as possible, typically averaging below 10 minutes daily with clients (when all the decisions happen on the fly).
I've worked in the corpo world, too, and it is anything but.
We do use vibe coding a lot in prototyping. Depending on the context, we sometimes have a lot of AI-agent-generated code, too.
What's more, because of working on multiple projects, we have a fairly decent pool of data points. And we don't see much of speed improvement from a perspective of a project (I wrote more on it here: https://brodzinski.com/2025/08/most-underestimated-factor-es...).
However, developers sure report their perception of being more productive. We do discuss how much these perceptions are grounded in reality, though. See this: https://metr.org/blog/2025-07-10-early-2025-ai-experienced-o... and this: https://substack.com/home/post/p-172538377
So, I don't think I'm biased toward bureaucratic environments, where developers code in MS Word rather than VS Code.
But these are all just one dimension of the discussion. The other is a simple question: are there ways of validating ideas before we turn them into implemented features/products?
The answer has always been a wholehearted "yes".
If development pace were all that counted, Googles and Amazons of this world would be beating the crap out of every aspiring startup in any niche the big tech cared about, even remotely. And that simply is not happening.
Incumbents are known to be losing ground, and old-school behemoths that still kick butts (such as IBM) do so because they continuously reinvent their businesses.
Re: Development speed is not a bottleneck
#57It's completely absurd how wrong this article is. Development speed is 100% the bottleneck. Just to quote one little bit from the piece regarding Google: "In other words, there have been numerous dead ends that they explored, invalidated, and moved on from. There's no knowing up front." Every time you change your mind or learn something new and you have to make a course correction, there's latency. That latency is ju…
I would agree if the only way to achieve (digital product) success were to implement as many versions of software as possible. That's not true. The whole Lean Startup was about figuring out how to validate ideas without actually developing them. And it is as relevant as ever, even with AI (maybe, especially with AI). In fact, it's enough to look at the appalling rate of product success. We commonly agree that 90% of…
The whole point of lean startup was to route around the bottleneck of development velocity.
Re: Development speed is not a bottleneck
#58It's completely absurd how wrong this article is. Development speed is 100% the bottleneck. Just to quote one little bit from the piece regarding Google: "In other words, there have been numerous dead ends that they explored, invalidated, and moved on from. There's no knowing up front." Every time you change your mind or learn something new and you have to make a course correction, there's latency. That latency is ju…
Exactly the comment I came to make after reading this article. The article is basically claiming that "trying different things until something works" is what takes time, but the actual act of "trying things" requires development time. I can't see how someone can think about this topic this long, which the author clearly has, and come to this conclusion. Perhaps I've just misunderstood the point, but it seems like a n…
If only "trying things" always equaled "developing things". There's a whole body of knowledge (under the Lean Startup umbrella) that argues otherwise.
Do we always have to build it before we know that it will work (or, in 9 cases out of 10, that it will not work)?
Even more so, do we have to build a fully-fledged version of it to know?
If yes, then I agree, development is the bottleneck.
Re: Development speed is not a bottleneck
#59It's completely absurd how wrong this article is. Development speed is 100% the bottleneck. Just to quote one little bit from the piece regarding Google: "In other words, there have been numerous dead ends that they explored, invalidated, and moved on from. There's no knowing up front." Every time you change your mind or learn something new and you have to make a course correction, there's latency. That latency is ju…
I don't buy it.
Prototyping was never the issue.
The lessons you're talking about come from stressing applications and their design, which requires users to stress it.
Re: Development speed is not a bottleneck
#60It's completely absurd how wrong this article is. Development speed is 100% the bottleneck. Just to quote one little bit from the piece regarding Google: "In other words, there have been numerous dead ends that they explored, invalidated, and moved on from. There's no knowing up front." Every time you change your mind or learn something new and you have to make a course correction, there's latency. That latency is ju…
Exactly the comment I came to make after reading this article. The article is basically claiming that "trying different things until something works" is what takes time, but the actual act of "trying things" requires development time. I can't see how someone can think about this topic this long, which the author clearly has, and come to this conclusion. Perhaps I've just misunderstood the point, but it seems like a n…
> trying different things until something works
That sounds like an awful way of software design. Trial and error isn’t engineering but explains the current state of software security.