Development speed is not a bottleneck

What “development speed” means

• Many distinguish between “typing/code generation speed” and overall development lifecycle (design, debugging, testing, deployment, validation).
• Several argue that coding is a small fraction (sometimes ~1–5%) of delivery time; bottlenecks are specs, reviews, CI/CD, ops, security, and organizational decision-making.
• Others insist that if you define development speed as end‑to‑end iteration time from idea → working feature → market feedback, then it is the main bottleneck.

Is development speed a bottleneck? – Conflicting views

• Pro‑bottleneck camp:
  • Faster iterations let you test more ideas than you can debate in meetings; compounding speed advantage builds a moat.
  • In experimentation-heavy environments, engineering capacity clearly limits how many A/B tests and features can be run and supported.
• Anti‑/qualified‑bottleneck camp:
  • The true constraint is knowing what to build; much shipped code creates no value or negative value.
  • Feature validation (A/B tests, user feedback) can take weeks–months regardless of how fast code is written.
  • Expertise and clarity are scarce: a few people who actually understand the system or problem become the bottleneck.

LLMs, “vibe coding,” and actual productivity

• Supportive experiences: LLMs help with boilerplate, syntax, unfamiliar stacks, and small tools that were previously not worth building; they enable more quick prototypes and personal automations.
• Critical experiences:
  • “Vibe coding” encourages shallow development, happy‑path features, and large piles of code no one fully understands, increasing long‑term debugging and refactor cost.
  • Reading/reviewing AI-generated code can be slower than writing it; developers report mental‑model “thrashing” and bigger, harder‑to‑review PRs.
  • Empirical measurements in some orgs show little or negative net productivity gain, despite strong subjective feelings of going faster.
• Consensus trend: LLMs are most effective for prototypes and well-bounded tasks; their value drops in large, messy, legacy systems.

Product discovery, validation, and “building the right thing”

• Many comments invoke Lean/continuous discovery: major gains come from validating ideas cheaply before full development, not from coding faster.
• Yet others counter that these techniques themselves arose to work around slow/expensive development; if build cost fell toward zero, you’d validate more by building and trying.
• Agreement that most organizations still overbuild: they ship large “major releases” without measuring which parts actually help users.

Organizational and long‑term factors

• Numerous anecdotes: features coded in weeks but stuck for months or a year in QA, ops, or political limbo; developers blamed despite non‑engineering bottlenecks.
• Large companies pay heavy coordination and risk‑management costs; small teams can ship faster but often lack good product sense.
• Over the long run, patience, product taste, marketing, and focus on sustainable quality may matter more than raw coding throughput.