Development speed is not a bottleneck

Here's a summary of the themes from the Hacker News discussion:

The Role and Definition of "Development Speed"

A significant portion of the discussion revolves around what "development speed" actually means and whether it's the primary bottleneck. Some argue it's primarily about the speed of writing code (typing speed), which they believe LLMs are improving but not fundamentally changing the overall project much. Others contend that "development speed" encompasses the entire process of ideation, validation, design, testing, debugging, and deployment, and that accelerating the writing of code does not necessarily speed up this broader process.

• "Development speed is not just the time to write code, but also test, stabilize and debug it, with most of the latter being a risk that might cost you a lot much later." (titzer)
• "The difference between Software Engineers (or Developers) vs Programmers; with the latter designation being a stretch for some." (throwaway-18) This is countered by: "I can highly recommend these talks to get your eyes slightly opened to how stuck we are in a local minima." (j-pb) referring to a talk that suggests current software development practices are stuck in local minima.
• "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." (seneca)
• "Development speed is 100% the bottleneck. Just to quote one article 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 just development velocity." (thenanyu)
• "Title feels like a bait and switch. Development speed absolutely is a bottleneck. But coding speed? Like, typing? Yeah, I can definitely type faster than I can think about code, or anything really..." (dismalaf)
• "Development speed has been a bottleneck in every major product development effort that I have been involved in." (wglb)

The Impact of LLMs on Software Development

There's a clear division in opinions regarding the impact of LLMs. Some believe they are revolutionary, enabling the creation of foundational software that was previously too daunting. Others feel that while LLMs can speed up the "inner loop" of coding, the "outer loop" of integration, testing, and deployment remains the primary bottleneck. Concerns are also raised about "vibe-coding" leading to technical debt and a lack of understanding in the codebase.

• "What these LLMs enable is fixing the foundations. If you considered writing a novel database, operating system, or other foundational piece of software two years ago, you had to be mad. Now you still do, but at least you got a chance." (j-pb)
• "Vibe coding is like sugar and crack mixed together for these people." (HumblyTossed) referring to shallow programmers.
• "The vibe coders can deliver on happy path results pretty fast but I already have seen within 2 months it starts to fall apart quick and has to be extensively refactored which ends up ultimately taking more time than if it was done with quality in mind in the first place" (no_wizard)
• "the tech debt of load-bearing code that no one really understands is going to be immense." (titzer)
• "We’ve only had these tools for, less than 2 years? I think those “fall apart in 2 months” kinds of projects will still keep happening, but some of us had experienced that and are refining our use of the tools. So I think in the future we will see a broader spread of “percent generated code” and degrees of success" (bckr)
• "With LLMs, you can type so much faster! So we should be going faster! It feels faster! (We are not going faster.)" (trjordan)
• "I think people are largely split on LLMs based on whether they've reached a point of mastery where they can work close to as fast as they think and the tech would therefore slow them down rather than accelerate them." (add-sub-mul-div)
• "You can code PRs fast, but CI, review, merge, deployment, monitoring, all takes just as long as it did before. The inner loop is shrinking; the outer loop is the real bottleneck" (fosterfriends)
• "The verbose LLM approach that Cursor and some others have taken really annoys me. I would prefer if it simply gave me the results (written out to files, changes to files or whatever the appropriate medium is) and only let me introspect the verbose steps it took if I request to do so." (no_wizard)
• "I feel like I can skip the effort of typing, which is still effort, despite years of coding. I feel like I actually did end up spending quite a lot of time doing trivial nonsense like figuring out syntax errors and version mismatches. With an LLM I can conserve more of my attention on the things that really matter, while the AI sorts out the tedious things." (lordnacho)
• "Whenever a development effort involves a lot of AI-generated code, the nature of the task shifts from typing-heavy to code-review-heavy. Cognitively, these are very different tasks. With the former, we actively drive technical decisions (decide on architecture, implementation details, even naming). The latter offers all these decisions made, and we first need to untangle them all before we can scrutinize the details." (flail)
• "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." (sega_sai)
• "the real question is delivering value over the long run. ... AI coding tools are quite inadequate and don't really deliver the value they purport to." (ciconia)

The Bottleneck of Validation, Decision-Making, and Business Processes

A recurring theme is that the most significant bottlenecks are not in writing code itself, but in validating ideas, making decisions, and navigating organizational or business processes. This includes long product lifecycles, indecisive leadership, politics, security policies, lengthy QA processes, and slow deployment cycles. The ability to iterate quickly and validate ideas before full implementation is seen as crucial.

• "It’s infecting expectations I’ve noticed as well. The thing LLM coding tools expose very plainly if someone wasn’t already aware is that management would rather ship with bugs or missing features - no matter how many - as long as the “happy path” works." (no_wizard)
• "About a decade ago, I was the sole developer for a special project. The code took 2 weeks to complete (a very simple Java servlet + JDBC app) but an entire year to actually deliver due to indecisive leadership, politics, and extremely overzealous security policies." (temporallobe)
• "I saw two projects in a row in a German Fintech (the one that has AI in its name that forbids usage of AI) go exactly the same way. Two/three months to code everything ("It's maximum priority!"), about four to QA, and then about a year to deploy to individual country services by ops team." (whstl)
• "The bigger and clunkier the corporation is, the slower the speed of deliveries. And actual development FWIW is somewhere in the range of 1-5% of it all." (jajko)
• "The pace of learning and decisions is exactly what drives development velocity." (trjordan)
• "The map is not the territory. Validating against anything other than the actual feature is a lossy proxy. It may be an acceptable tradeoff because building the feature is too costly but that’s the whole discussion at hand." (thenanyu)
• "Trying things and changing if it doesn’t work is the only way I know how to build software. What would you do? Don’t change?" (thenanyu)
• "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." (flail)
• "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)." (flail)
• "I have witnessed development teams requiring weeks to change a single flag in a configuration flag? Were they slow? Well, yes, but I'd argue they were mostly clueless." (laurent_du)
• "The bottleneck for that is 100% development speed. If you can shrink your iteration time, then there are fewer meetings trying to determine prioritization. There are fewer discussions and bargaining sessions you need to do. Because just developing the variations would be faster than all of the debate." (thenanyu)
• "This echoes my feelings as well. I’d go further, I’ve long said that the real problem in software is verification, but my actions didn’t match that because I’d spend less time on that than code creation. With the llm I really can spend most of my time on the verification problem." (kasey_junk)
• "Validation is definitely the bottleneck, if you make all your product decisions through a/b tests and wait for a statistically significant result for each feature." (mlinsey)
• "How fast can you react to the learning you have from the market, that's the bottleneck. And yes, the development is the big chunk of that reaction time." (witnessme)
• "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. ... 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)." (inerte)
• "It's completely absurd how wrong this article is. Development speed is 100% the bottleneck." (thenanyu)

The Nature of Programmer Skill and Effort

The discussion touches on the difference between experienced and less experienced programmers, the value of deep knowledge versus breadth, and how LLMs might affect these dynamics. Some feel LLMs can help experienced developers focus on higher-level problems, while others worry they might further enable less skilled individuals or create a dependency that hinders true understanding.

• "You have the unbelievably productive programmers - we all know their names, we use the code they wrote every day. Then you have the programmers who want to be there and will try everything they can to be there - except gain depth of knowledge. They tend to be shallow programmers." (HumblyTossed)
• "If your engineers have to take a two hour or two day or two week timeout to debug issues from weeks, months, or years back, then that really costs as development time." (titzer)
• "With AI I can conserve more of my attention on the things that really matter, while the AI sorts out the tedious things." (lordnacho)
• "The question is, why doesn’t it work? Erroneous code, erroneous algorithm, missing feature in the underlying infrastructure? The effort it takes to implement a feature makes is more likely you think twice before you start. If the effort goes to zero, so does the thinking." (croes)
• "Development is often divided into 80% known unknowns and 20% unknown unknowns. AI can only help with one of those, and it's the one that takes the least amount of time to complete. Research and thinking is always going to be the bottleneck." (rekrsiv)
• "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." (sega_sai)
• "AI can help in that by letting you prototype faster and get feedback on your prototypes. If your prototype fails, you have not wasted much time building the actual functionality." (titzer)

The Disconnect Between Perceived and Actual Productivity Gains

Several commenters suggest that while developers might feel more productive with AI tools, the actual impact on project timelines and success is not as significant as expected. This disconnect is attributed to factors like the shift from coding to code review, the mental overhead of invalidating AI-generated code, and the persistent bottlenecks in non-coding aspects of development.

• "Developers sure report their perception of being more productive. We do discuss how much these perceptions are grounded in reality, though." (flail)
• "The programmer is constantly invalidating and re-building their mental model of the code, which is not only slow but exhausting (and a tired programmer makes more errors in judgement). It's basically the wetware equivalent of page thrashing." (marginalia_nu)
• "I see how development teams define health routines around working with generated code. Especially around limiting context switching. But also retaking tasks to be made by hand." (flail)
• "lol.... development speed and quality are both the bottleneck my dude. But if you have enough speed, you can fix quality issues as you are able to test and fix things faster." (ardit33)