Don't you mean extinct?

Claims that software engineers who refuse to use large language models will “fall behind” spark a broader debate over what productivity in programming really means. Commenters contrast speed and volume of code generation with long-term quality, maintainability, testing and design, with some reporting genuine gains from AI-assisted tooling and others seeing more bugs, unrealistic management expectations, and little net benefit. Underneath lies anxiety about job security, loss of autonomy to proprietary AI platforms, and whether AI-driven abundance of mediocre software is a good trade for society.

Scope of Disagreement About “Falling Behind”

  • Many see “those who refuse to use LLMs will fall behind” as vague, aggressive, and implicitly threatening, especially where devs are not judged on raw output volume.
  • Others argue it’s obvious: if two engineers of similar skill differ 5x in delivery speed due to tools, the slower one will be viewed as underperforming in many orgs.
  • Some report concrete cases where management doubled velocity expectations and effectively mandated LLM use; others say their companies have no such pressure.
  • Several posters criticize “adapt or die” rhetoric as FOMO marketing or insecurity rather than reasoned argument.

Impact on Quality, Bugs, and Testing

  • Enthusiasts say LLMs free time for tests, tooling, reproducible builds, and legacy bug-hunting; they now build sophisticated one-off tools and analysis harnesses that would never have been feasible before.
  • Skeptics report the opposite: teammates ship large, poorly tested AI-generated patches, leading to more bugs and production failures.
  • Concern that LLMs amplify an existing imbalance: creating messy code is already faster than cleaning it up; making everyone “twice as fast” can worsen this.
  • Several note that designing good tests is intellectually hard; auto-generated tests often mirror the implementation rather than true behavior.

Where LLMs Help Most vs Least

  • Widely praised for: navigating unfamiliar codebases, explaining architecture, debugging weird issues, log analysis, search, writing/updating tests, and rapid prototyping or internal tools.
  • Much less consensus that they speed up production-grade code that engineers must deeply understand and maintain; review and comprehension time can cancel typing gains.
  • A recurring guideline: learn LLMs well, but don’t outsource thinking.

Open vs Proprietary and Hacker Values

  • Strong unease that key coding models are paywalled, centralized, and controlled by large firms; seen as unlike previous tools (compilers, calculators) and at odds with a “hacker” ethos.
  • Some advocate fighting for open models and universal access; others dismiss LLMs as not worth defending at all.

Broader Social and Cultural Concerns

  • Analogies to cars: tech that starts optional can become de facto mandatory and increase surveillance and control.
  • Fears of devalued craft (VFX, knitting, hand animation) and developers reduced to “AI proofreaders.”
  • Several say AI hasn’t solved real-life problems for them, only added marginal convenience while consuming massive capital and potentially harming culture and jobs.