AI coding assistants genuinely accelerate development, and the failure mode is specific: output that is syntactically correct, stylistically confident, and subtly wrong. Because it reads like code a competent developer wrote, it receives less scrutiny than code that looks uncertain.

The failures worth watching for

  • Outdated patterns and deprecated APIs reflecting the age of training data.
  • Missing authorisation checks — code that verifies a user is logged in but not that they own the record.
  • Validation that exists client-side only, or that sanitises rather than rejects.
  • String-concatenated queries where parameterised ones are required.
  • Error handling that swallows failures silently, which is invisible until it matters.
  • Dependencies that do not exist, or that exist but are abandoned.

Non-existent packages are a supply chain risk

Assistants sometimes suggest plausibly-named packages that were never published. Attackers monitor for commonly hallucinated names and publish malicious packages under them, so the install succeeds and the code runs. Verify that any suggested dependency is real, maintained, and widely used before adding it.

Apply more scrutiny to security-relevant code

Authentication, authorisation, input validation, database access, file handling, and cryptography deserve line-by-line review regardless of origin. These are precisely the areas where confident-looking but incorrect code causes breaches rather than bugs, and where the failure is silent until exploited.

Practical workflow

  • Treat generated code as a draft from an unfamiliar contributor, not as reviewed work.
  • Run it: tests, linting, type checking, and dependency scanning, as you would any change.
  • Ask the assistant to explain what a section does, then verify the explanation independently.
  • Never paste proprietary code or credentials into a consumer-tier assistant.
  • Require human review before merge, particularly for security-relevant paths.

The realistic position

This is a genuinely useful tool that shifts where the work sits: less typing, more reviewing. Teams that recognise the shift and invest in review capacity get the productivity gain. Teams that treat generated code as finished work accumulate a particular kind of technical debt that is difficult to find later precisely because it looks fine.