Skip to main content

Why "It Works on My Machine" Is Dangerous

If you've ever built something with AI assistance, tested it locally, and thought "Looks good, let's ship it" — you've already encountered the "works on my machine" problem.

This phrase is a running joke in software engineering for a reason. It describes the moment when code runs perfectly in your local environment but breaks immediately in production, on a teammate's computer, or on someone else's device.

With AI-generated code, this problem gets worse — because you may not understand why it worked in the first place.

What Does "Works on My Machine" Mean?​

When you run code locally, you're running it in a controlled environment:

  • Your specific operating system
  • Your specific software versions
  • Your specific configuration files
  • Your specific environment variables
  • Your specific network setup
  • Your specific database state

The moment that code leaves your machine, none of those assumptions are guaranteed.

What works on your Mac may fail on:

  • A Linux server
  • A Windows desktop
  • A different version of Node.js, Python, or PHP
  • A clean environment without your local packages
  • A mobile browser with different capabilities

Why AI Code Makes This Worse​

AI coding tools generate code based on patterns, not context. They don't know:

  • What operating system you're deploying to
  • What version of a dependency you're using
  • What environment variables are available in production
  • What file permissions exist on the server
  • What database engine your hosting provider runs

Common AI-Generated "Works on My Machine" Traps​

IssueWhat Happens
Hardcoded pathsAI uses C:\Users\... or /Users/yourname/... that doesn't exist on the server
Missing environment checksCode assumes NODE_ENV or APP_KEY is always set
Local-only dependenciesAI imports packages you have installed globally but aren't in package.json
Database differencesSQLite works locally; production uses PostgreSQL with different syntax
File system assumptionsCode writes to /tmp/ or a directory that doesn't exist in production
Case sensitivityWorks on macOS (case-insensitive by default) but fails on Linux (case-sensitive)
Port conflictsHardcoded port 3000 is already in use on the server
Missing CORS configAPI calls work from localhost but fail from your actual domain

Real Example: The Upload Feature That Worked Locally​

A developer used AI to build a file upload feature. It worked perfectly on their machine.

When deployed to production:

  1. The upload directory didn't exist — the AI code assumed it would be created automatically
  2. File permissions were wrong — the server couldn't write to the directory
  3. The file size limit was exceeded — the AI didn't add any validation
  4. The file type check used extension-only validation — someone uploaded a malicious file
  5. The production server had a different max upload size configured in PHP/nginx

The developer's machine had none of these problems. The production server had all of them.

How to Avoid This Trap​

1. Test in a Production-Like Environment​

Don't just test on your machine. Use:

  • Staging servers that mirror your production setup
  • Docker containers that replicate the production environment
  • CI/CD pipelines that run tests in a clean environment
  • Cloud-based testing platforms that simulate different browsers and devices

2. Never Hardcode Environment-Specific Values​

Bad:

DATABASE_URL = "sqlite:///local_dev.db"
API_KEY = "sk-test-12345"
UPLOAD_DIR = "/Users/me/project/uploads"

Better:

import os

DATABASE_URL = os.getenv("DATABASE_URL")
API_KEY = os.getenv("API_KEY")
UPLOAD_DIR = os.getenv("UPLOAD_DIR", "/var/www/uploads")

3. Use Environment Variables for Configuration​

Every value that changes between environments should be configurable:

  • Database connection strings
  • API keys and secrets
  • File storage paths
  • Log levels
  • External service URLs
  • Feature flags

4. Document Your Environment Requirements​

Your project should include:

  • A README.md with setup instructions
  • A .env.example file showing required environment variables
  • A list of system dependencies (e.g., "requires Redis 7+")
  • Node.js/Python/PHP version requirements in a .nvmrc, .python-version, or composer.json

5. Run Your Code on a Clean Machine​

Before deploying, test your code on:

  • A fresh cloud server (cheap $5/month VPS works fine)
  • A teammate's computer
  • A Docker container with no pre-installed packages
  • A CI pipeline that starts from scratch

If it fails, you'll catch the "works on my machine" issues before users do.

The Mindset Shift​

Before:

"It worked when I ran it. Ship it."

After:

"It worked in my environment. Let me verify it works in the target environment too."

AI-generated code makes it easy to build things fast. But speed without environment awareness is just creating problems for later.

The goal isn't to stop using AI. The goal is to stop assuming your machine represents the real world.

Last updated on