How a running program can get new behavior
In languages that allow it, a program’s functions and methods are often reachable through names or object properties. Monkey patching changes one of those links while the process is still alive: a replacement function is assigned where the old one used to be, so later calls may run the new code without restarting the application.
Imagine a service repeatedly calling a method named `send`. A patch can replace that method with one that adds a retry when a network request fails. The service keeps running; the next call that looks up `send` can use the replacement. The change affects the program’s behavior, not the source file automatically—saving edited code to disk does not, by itself, update code already loaded into memory.
The timing is the tricky part
A patch does not necessarily alter work already underway. A function that has started keeps executing its current instructions, and code that saved an earlier reference to the original function may continue calling that reference. Other parts of the program may see the replacement immediately. The result can be a brief period when different parts of the same process behave differently.
That makes monkey patching useful for targeted hotfixes, debugging, or adding instrumentation—code that observes activity—without a full restart. But it can also make behavior hard to trace: the replacement may come from a separate module, depend on assumptions about the original, or conflict with another patch.
Changing a live program is not the same as changing it safely. A patch can buy time when restarting is costly, but it still needs testing and a clear path to removal; otherwise, the temporary fix can become an invisible part of the system.
