If you thought code writing speed was your problem you have bigger problems
Many engineers argue that large language models dramatically speed up coding but don’t automatically solve the real bottlenecks in software delivery: understanding what to build, coordinating teams, and safely shipping changes. Commenters contrast scenarios where rapid prototyping and solo work make AI a clear win with complex enterprise environments where faster code generation can just create more wrong features, tech debt, and review burden. A recurring theme is that AI is powerful as a “grunt work” assistant and experiment accelerator, but its impact depends heavily on organizational process, product clarity, and how carefully humans remain in the loop.
Coding speed vs. real bottlenecks
- Many argue that “typing speed” was rarely the bottleneck; understanding the problem, choosing the right thing to build, and navigating org politics are slower steps.
- Others counter that faster implementation can improve understanding, because building and running prototypes surfaces requirements and design flaws earlier.
- Several note the difference between solo/hobby work (where coding is a major bottleneck) and large B2B/enterprise settings (where customer time, approvals, and risk tolerance dominate).
Value of LLMs and coding agents
- Advocates report large gains for:
- Boilerplate and repetitive changes.
- Prototyping features or refactors to “see how it feels.”
- Complex but mechanical edits and edge-case coverage.
- Solo devs and side projects, where it frees time for non-coding work.
- Some see this as analogous to a dishwasher or power tools: not magical, but real labor-saving that shifts attention to architecture and product.
Risks: building the wrong thing faster & tech debt
- Common concern: speeding non-bottleneck steps just accelerates producing the wrong features, especially when requirements come from vague Slack messages or weak product discovery.
- Faster iteration only helps if it is coupled with good fitness functions (user feedback, proper specs); in enterprise, stakeholder attention is the real scarce resource.
- Several warn that agents tend to “brute force until the prompt stops,” accumulating entropy and making long-lived systems harder to maintain.
Compilers vs. LLMs
- One camp compares agentic coding to moving another level up the compilation stack: code as an intermediate representation, like assembly.
- Critics highlight key differences:
- Compilers are deterministic and formally specified; LLMs are probabilistic and non-deterministic.
- Compiler output is trusted without per-build review; LLM code must be reviewed and tested every time.
Organization, process, and bottlenecks
- Multiple comments reference bottleneck theory (Amdahl’s Law, “The Goal,” Factorio analogies): optimizing non-bottleneck steps can worsen the system by backing up downstream stages (review, QA, deployment, user validation).
- There is frustration that product and leadership often ignore flow metrics and treat engineering throughput as the only lever, now projected onto AI.
Developer experience and safety
- Agents enable parallel work but also increase context switching and cognitive load; some find this exhausting and demotivating, others energizing.
- Catastrophic mistakes are possible with both humans and AI; commenters emphasize strong QA, tests, and guardrails rather than trusting either blindly.