# It works on my machine syndrome "It works on my machine" is the classic deflection developers reach for when their software runs locally but breaks everywhere else. It points to a deeper failure: the developer never separated the artifact from the environment that made it work. The root causes are almost always environmental, not algorithmic: - Different OS, kernel, or architecture between dev and target machines - Implicit dependencies installed long ago and forgotten (system libraries, global tools, language runtimes) - Configuration living in shell profiles, IDE settings, or environment variables that were never documented - Path assumptions, locale settings, line endings, file permissions - Network access, DNS, proxies, or credentials available locally but absent elsewhere - Version drift between local tooling and what teammates or CI use - Hidden state: caches, lock files, half-applied migrations, leftover data from previous experiments The pattern repeats across every layer of the stack, from scripts and CLIs to AI agents, prompts, and skills. Anything stateful, anything dependent on an ambient configuration, is at risk. The cure is to make the environment explicit and reproducible. Containers, declarative environments (Nix, devcontainers), pinned dependencies, infrastructure-as-code, and CI runs that mimic production all push the artifact toward portability. The discipline is to assume nothing about the target machine and prove the software runs from a clean slate. ## References - ## Related - [[Why Your AI Skills Break on Other Machines (Article)]] - [[AI Skill Portability]] - [[AI Skill Portability Checklist]] - [[AI Skill Resilience]] - [[AI Agent Portability]]