Code is only half the story. It needs somewhere to run, and that place decides whether the same program works perfectly or fails completely.
Think about a kitchen. A recipe on paper isn’t dinner. Dinner happens when the recipe meets the oven, pans, ingredients, and timing, and the same recipe can fail in another kitchen if the oven is different or the ingredients are missing. That’s runtime. Your codebase says what should happen; the runtime is the kitchen where it happens. It might be Node.js, Python, a browser, or a cloud function, and it includes the language version, installed packages, memory, and permissions the code depends on.
How it shows up
This is why something works on one machine and fails elsewhere. The recipe didn’t change, the kitchen did: maybe the local machine has a newer Node, maybe the production server is missing a dependency, maybe the agent assumed a file path that only exists on your laptop. A container makes the kitchen portable, packaging the runtime so the code gets the same oven and ingredients everywhere. Serverless is another shape: you don’t manage the full server, you hand the cloud provider a function and it runs inside a managed runtime when something triggers it.
Why you care
For AI tools, runtime matters because agents often write code and then run it. If it’s unclear, the agent may write something that looks right but can’t execute. A good agent needs to know where the code will run, what’s installed, and what permissions exist. When a developer asks “what runtime is this using?” they’re really asking “which kitchen are we cooking in?”, and that answer decides whether the work is simple, broken, or impossible without setup. Runtime matters because written instructions are only useful when the environment can carry them out.