I worry our Copilot is leaving some passengers behind
GitHub Copilot and similar AI coding assistants are praised by some experienced engineers as powerful autocomplete tools but criticized by others for encouraging bloated, inaccessible, or subtly wrong code that teammates must later untangle. Commenters worry that overreliance on LLM-generated code, especially by less experienced developers and in areas like security and accessibility, will accelerate a long-running decline in software quality and deepen “enshittification” pressures. Many argue these tools are best used with strong tests, reviews, and clear norms: treat them as junior collaborators or translators, not as replacements for understanding, design, and long-term maintainability.
Team norms and misuse of codegen tools
- Several describe colleagues who paste large, LLM-generated changes with irrelevant code, can’t explain it, and expect teammates to debug and style-fix it.
- Many argue this should be treated like any other bad engineering: reject PRs, demand explanations, require conformance to codebase norms; some think habitual offloading of reasoning is grounds for firing.
- Concern that “LLM developers” shift effort from the author to reviewers, which is seen as disrespectful.
Where Copilot helps vs. hurts
- Seen as most useful for: boilerplate, repetitive structures, translations between formats (e.g., JSON → types), quick doc lookups, test scaffolding, and “rubber-duck” debugging.
- Some keep it off by default and only enable when they know exactly what they want.
- Others report it has become worse or inconsistent, often returning guesses with little context or no solution at all.
- Effective use patterns: treat it as powerful autocomplete, pair with it like a very junior dev, accept only what you already intended.
Code quality, accessibility, and security
- Many agree Copilot mirrors the (often poor) quality of public code: div-soup HTML, weak accessibility, bad Bash, etc.
- Worry that LLM-generated code will normalize bad practices (accessibility, security, internationalization) that “seem to work” and thus ship unnoticed.
- Some think these issues can be mitigated by better training data and integrating linters, accessibility checkers, and tests into the generation loop.
Learning, hiring, and overreliance
- Tool is considered a boost for experts (who can spot errors) and a trap for novices (who can’t).
- Concerns that juniors will outsource thinking, learn wrong patterns, and never build fundamentals.
- Hiring: interviewers see candidates secretly using AI in remote tests; countermeasures include full-screen sharing, pseudocode-only tasks, or focusing on reasoning instead of rote coding.
Broader industry and future directions
- Several link LLMs to “enshittification”: they may accelerate already-bad incentives (move fast, never clean up, accept mediocre UX/perf).
- Others argue garbage apps are driven by markets, not tools; LLMs might even help small teams outcompete entrenched bad systems.
- Some envision richer workflows: organization-specific models, generation constrained by compilers/grammars, refactoring suggestions, and multi-pass generation validated by tests and linters.