Exercise 3: Why Hardcoding the API Key Is a Bad Idea — Possible Solution
====================================================================

Hardcoding the AI Gateway API key directly into route.ts means the key
becomes part of the source code itself - and source files are exactly
the kind of thing that gets committed to version control, shared with
collaborators, or accidentally made public in a way .env.local is
specifically designed to avoid. Next.js's own default .gitignore
already excludes .env.local for this reason, but a key typed directly
into route.ts has no such protection at all.

A leaked API key isn't just an inconvenience - it's a real security
and billing risk, since anyone who obtains it could make requests
through the Vercel AI Gateway using that key, potentially running up
real costs or abusing the access it grants. Using .env.local also
keeps the key genuinely swappable per environment (a different key for
local development versus production) without touching the application
code at all, something a hardcoded key can't offer either.

ANSWER: Hardcoding the key into route.ts removes the real protection
.env.local provides against accidental exposure through version
control, and turns a leaked key into a genuine security and billing
risk, since anyone who obtained it could use the Gateway under that
key. .env.local also lets the key vary per environment without
touching the application code - "saving a step" trades away both real
safety and real flexibility.

WHY THIS WORKS AS AN ANSWER
------------------------------
This correctly identifies both the real security risk (exposure via
version control) and the practical flexibility cost (per-environment
configuration) of hardcoding the key, rather than only stating that
"secrets shouldn't be hardcoded" as a rule without explaining why.