Debug flags in production: what AI setup guides leave behind

What AI setup guides actually optimise for

AI-generated README sections and setup guides are written to get you to "it works." That's a reasonable goal. The problem is that "it works" during local development almost always involves a pile of debug flags, verbose log levels, and environment variables set to values that would make a security engineer wince.

I've read a lot of AI-generated setup sections lately. Nearly all of them include something like LOG_LEVEL=debug or DEBUG=* in the example .env file. Some include NODE_ENV=development tucked in with no comment explaining it shouldn't go near production. The AI isn't being malicious. It's just that debug mode is what makes the happy path work on a fresh install, so that's what ends up in the example.

The trouble starts when someone copies that config and ships it.

What actually leaks

Debug logging in production isn't just noisy. It's a gift to anyone who can read your logs.

Stack traces expose internal file paths, function names, and the version of every library in your dependency tree. Query logging prints raw SQL to stdout, including values that might be passwords or tokens. Framework-level debug output in something like Express or Django can dump request headers, session cookies, and environment variables into log files that get shipped to a centralised logging service with weaker access controls than your secrets manager.

Here's a real pattern I see in AI-generated Node.js setup files:

# .env (generated by AI assistant)
NODE_ENV=development
LOG_LEVEL=debug
DEBUG=app:*,db:*,http:*
DATABASE_URL=postgresql://localhost:5432/myapp

That DEBUG=app:*,db:*,http:* wildcard is doing a lot of damage if it reaches a production container. Every database query, every HTTP request with headers intact, every internal event your app fires is now in your log stream. Log streams get breached. They get forwarded to the wrong destination, handed off to a third-party service via a Slack integration someone set up in 2022 and never revisited.

The fixed version is obvious once you're looking at it:

# .env.production
NODE_ENV=production
LOG_LEVEL=warn
# DEBUG intentionally omitted
DATABASE_URL=postgresql://prod-host:5432/myapp

Remove DEBUG entirely. Set LOG_LEVEL to warn or error. Make NODE_ENV=production the default assumption for anything that isn't explicitly a dev environment.

Why this keeps happening

Teams shipping fast rarely circle back to audit which environment variables made the jump from the initial setup to the production deploy. The AI wrote the .env.example, someone copied it to .env, it went into the container's environment block, and now it's been running like that for eight months.

This isn't a failure of developer intelligence. It's a failure of process. Configuration auditing isn't part of most deployment checklists. Most CI pipelines validate that the app starts, not that its log verbosity is appropriate for the environment it's starting in.

AI tools make this worse by normalising verbose configuration. When you ask an AI to help you set up a new service and the generated config always includes debug flags, you stop noticing them. They become invisible furniture.

What to actually look for

If you're auditing an existing codebase, check these specifically:

• Any use of DEBUG=* or broad wildcard patterns in environment files or container configs
• LOG_LEVEL set to debug, trace, or verbose anywhere near production
• Framework-specific flags: FLASK_DEBUG=1, DJANGO_DEBUG=True, RAILS_LOG_LEVEL=debug
• ORM query logging enabled at the library level rather than via environment variables
• Any environment variable containing the word debug or verbose set to a truthy value

The ORM logging issue deserves a separate call-out. A lot of AI-generated setup code enables query logging because it's useful during development, and it's set at the code level rather than in the environment file. That means it won't show up in a simple env audit. You have to look at the ORM initialisation config.

// Bad: AI-generated Sequelize setup
const sequelize = new Sequelize(process.env.DATABASE_URL, {
  logging: console.log,  // logs every query to stdout in production
});

// Fixed
const sequelize = new Sequelize(process.env.DATABASE_URL, {
  logging: process.env.NODE_ENV === 'production' ? false : console.log,
});

The audit is boring but short

You don't need a dedicated tool to find this. A grep through your config files and ORM initialisation code takes twenty minutes. What you're looking for is anything that's verbose by default with no production guard.

The harder part is making sure it doesn't drift back. The actual intervention is adding configuration review to your deployment checklist before you've already been leaking query output for a year.

Seaworthy flags this pattern automatically as part of its configuration and data exposure checks.