Eight Myths on Software Engineering and GenAI
Claims that generative AI can only speed up the ~14% of a developer’s day spent typing code are strongly contested, with many engineers reporting that modern tools now accelerate research, design docs, debugging, test authoring, and even product planning. Commenters argue over whether code is still the real bottleneck, how much AI-generated “slop” and security risk teams can tolerate, and whether lines of code or self-reported speedups are meaningful productivity metrics. Underneath is a broader anxiety about hype, job displacement, and the long‑term maintainability of systems built with aggressive AI assistance.
Impact on developer time and workflow
- Many dispute the article’s “AI only touches 14% coding time” framing, saying current tools accelerate far more than typing: debugging, reading legacy code, test writing, scaffolding, docs, Jira/Linear admin, dashboards, and research.
- Some report spending most of their day “driving agents,” reviewing outputs, and orchestrating work, with coding now a larger share of time because other tasks got faster.
- Others say AI only modestly speeds encoding once a problem is understood, similar to smarter IDEs.
Code quality, review, and security
- Sharp disagreement over how much AI-generated code can be trusted.
- Some selectively review only “important” or security‑adjacent code and rely on tests or security scanners for the rest.
- Others argue this is reckless, especially for endpoints touching user input or production data; they see “AI code bloat” and huge, hard‑to‑review PRs.
- Concern that high volume from LLMs makes thorough human review infeasible, pushing teams toward riskier norms.
Productivity gains and metrics
- Lines of code are widely criticized as a bad productivity metric, especially for AI, though a minority defend LoC as a useful personal proxy in well‑curated projects.
- Several point out that studies and surveys on AI productivity are rapidly going stale; citing early‑2025 work is seen as misleading.
- Some stress that productivity must be measured at system or outcome level, not by code volume or token spend.
Design, requirements, and meetings
- Debate whether AI shortens or lengthens design cycles:
- Pro: faster research, auto‑drafted design docs, cheap prototypes that tighten the idea → test → refine loop.
- Con: encourages “vibing” and gold‑plated demos that look finished but conceal poor or missing design.
- Some argue that if coding becomes cheap, more of PRD will be done via code/prototypes rather than meetings and documents.
Organizational and career effects
- Reports of leadership expecting 10–100× productivity and using AI budgets per developer; many see this as unrealistic or dangerous.
- Observations of uneven adoption: some engineers go “all in,” others avoid or quietly use AI, sometimes due to perceived competence penalties.
- Several foresee bifurcation into “code factories” churning AI‑assisted slop and smaller “artisanal” teams maintaining critical systems.
Limitations, risks, and human factors
- Concerns about hallucinations, mis‑handled edge cases, and long‑term tech debt from quickly generated but poorly understood code.
- Worries about “cognitive surrender”: relying on AI to the point of skill atrophy and losing the ability to reason about systems.
- Some developers report reduced joy and connection to their work when large portions are generated by LLMs, especially on side projects.