Two years into the era of everyday LLM coding assistants, the honest position is neither dismissal nor evangelism. These tools genuinely help on the right work, and they genuinely introduce a new class of risk when their output is trusted by default. Both statements are true at once. This is a practitioner's map of where the line falls, written for the people who commission software and the people who ship it.

Where the assistants earn their place

The productivity gains are real, and they cluster in predictable places. Studies of GitHub Copilot and comparable tools in 2025 reported meaningful reductions in task-completion time and higher developer satisfaction, with the largest gains on repetitive, well-specified work: boilerplate, standard CRUD endpoints, test scaffolding, format conversions, and first-draft documentation. On that kind of task an assistant is a genuine force multiplier, and enterprise deployments consistently found that developers enjoyed the work more.

The gains shrink as the work gets harder. Complex algorithms, novel architecture, and security-critical code show far more modest improvements, because those tasks reward exactly what an LLM does not have: an accurate model of your specific system, its threat model, and its constraints. The pattern to internalise is simple. An assistant accelerates the parts of engineering you already understand well enough to review quickly. It does not replace the understanding.

The core risk: AI output is untrusted input

The single most useful mental model is this: treat everything an LLM produces as untrusted input, on the same footing as a paste from a public forum or a pull request from a stranger. It looks confident and idiomatic, which is precisely why it slips past review. The confidence is a property of the text, not evidence about the code.

The data backs the caution. In 2025, Veracode's analysis found that a large share of AI-generated code — on the order of 45% in their sample — contained a weakness matching the OWASP Top 10, with authentication and input-handling logic among the weak spots. Other work suggests iterative "keep refining it" prompting can degrade security rather than improve it. Combine that with a widely reported human factor — a majority of developers admit they rarely review AI-generated code line by line — and you have the actual mechanism by which insecure code reaches production. Not the model alone. The model plus an unexamined trust.

Three concrete failure modes to guard against

  • Insecure generated code. Missing input validation, weak or hand-rolled crypto, injectable queries, and permissive defaults appear regularly. Mitigation is unglamorous and effective: the same static analysis (SAST), dependency scanning, and human review you would apply to any contribution — applied without exception to AI output.
  • Prompt injection. For the second edition running, prompt injection sits at the top of the OWASP Top 10 for LLM Applications (LLM01). LLMs read instructions and data through the same channel, so text hidden in a file, a web page, a code comment, or an issue can be read as a command. In an agentic assistant — one that can edit files, run commands, or call APIs — a successful injection is no longer a bad suggestion; it is an action. Published research shows indirect-injection success rates in agentic coding environments climbing sharply with repeated attempts. Defend with least-privilege tooling, human approval for high-consequence actions, and never granting an agent standing access it does not need for the task in front of it.
  • Package hallucination and "slopsquatting." Models routinely invent dependencies that do not exist. A 2025 study across 576,000 generated samples found roughly a fifth of recommended packages were non-existent — and, worryingly, the same fabricated names recur across runs. That predictability is the attack: register the hallucinated name on PyPI or npm with a malicious payload and wait for an install. Verify every dependency by hand; never assume a package named in generated code is real, let alone safe.

What good practice looks like

None of this argues for banning the tools. It argues for wrapping them in the controls we already know how to run. The teams getting durable value share a few habits:

  • Review AI output as you would a stranger's pull request — no line ships unread because it looked plausible.
  • Keep the existing safety net switched on for AI code: SAST, dependency and secret scanning, and tests in CI, with no carve-outs.
  • Constrain agents to least privilege and require explicit human approval before any irreversible or high-value action.
  • Verify dependencies and provenance before adding anything an assistant suggests.
  • Match the tool to the task: lean on it for the well-understood and the repetitive; stay hands-on for the security-critical and the novel.

The bottom line

LLM coding assistants are a real and welcome addition to the software lifecycle. They make good engineers faster and make routine work less tedious. They do not make code trustworthy, and they quietly widen the attack surface if you let their fluency stand in for verification. The discipline that made software safe before these tools — review, testing, least privilege, and healthy suspicion of unverified input — is exactly the discipline that makes them safe now. Used that way, the assistant is genuinely helpful. Trusted blindly, it is simply a faster way to ship someone else's mistakes.