Understanding is the new bottleneck
As AI coding assistants flood codebases with far more changes than humans can comfortably review, many engineers argue that comprehension, not typing speed, is now the limiting factor in software development. Commenters describe a growing gap between rapid LLM-generated code and human ability to understand architectures, assess risks, and maintain long‑term quality, with worries about “vibe‑coded” systems, tech debt, and brittle tooling. Suggested responses range from stricter specs, smaller PRs, and better testing to new workflows and tools that use AI to explain, visualize, and interrogate code rather than just write more of it.
Role of Understanding in Software Work
- Many argue understanding has always been the bottleneck; LLMs just expose and amplify it by generating much more code, faster.
- Others see the bottleneck as shifting: we now “backload” understanding to after code is generated, rather than building it while writing code.
- Some push back on “X is the new bottleneck” framing, arguing there was never a single bottleneck; user value and good product decisions remain core constraints.
Reading, Ownership, and “Don’t Read the Code”
- Several developers insist on reading and understanding all production commits; they see this as non-negotiable responsibility.
- Others admit they ship unreviewed “slop” for low-risk CRUD work and rely on targeted tests.
- The “don’t read the code” stance is seen as tempting for speed but widely viewed as dangerous long-term, especially for complex or security-adjacent systems.
LLMs as Code Generators: Quality and Debt
- Common complaints: verbose, over-engineered diffs; duplicated logic; missing obvious simpler solutions; subtle algorithmic mistakes.
- Some report codebases degenerating into unreadable “vibe-coded” messes where only LLMs can safely touch the code.
- Others note this is an extension of pre-LLM “works but breaks the model” problems, now at higher velocity.
PRs, Specs, and Explanations
- Auto-generated PR descriptions are often criticized as long, mechanical, and missing why the change exists.
- Some teams successfully clamp descriptions to short “what + why” summaries, sometimes LLM-written but human-validated.
- A recurring theme: humans should own intent. Approaches like SPEC.md / “spec-driven development” try to put understanding into specs first, then let agents implement.
Testing, Assurance, and Tooling
- One camp argues you can treat LLMs like contractors: don’t over-interpret code, just build strong tests and QA.
- Others highlight existing bodies of practice (unit tests, fuzzing, formal methods, static analysis) and suggest LLMs should help there too, not only generate code.
- Proposed aids for understanding include explain-diff tools, “grill-with-docs” workflows, time-travel debugging, and using test coverage as a map of behaviors.
Organizational and Cultural Dynamics
- Several comments describe pressure to optimize for throughput, token usage, and visible AI adoption over maintainability.
- There is concern about “mass psychosis”: engineers and managers checked out, approving AI-generated PRs they don’t understand.
- Others see emerging “agent management” as similar to program/people management: decomposing work, setting expectations, and knowing when to trust versus dive into details.