Once a system is managed by automation, why must changes be made in the automation code rather than directly on the server?

A manual change is invisible to the automation, so the next automation run can overwrite it, and the server drifts away from what the code describes.

The automation code is the description of how the server should look. If an admin logs in and edits a config file by hand:

• the code still describes the old state, so the next run puts the old state back and the manual fix is lost, or
• if the code does not touch that file, the server now differs from every other server built from the same code, which is exactly the inconsistency automation was meant to remove.

So the working habit has to change: to change a server, change the code and let the automation apply it. Organisations can go further and enforce this rule, allowing changes to the infrastructure only through automation, to minimise human error.

Go deeper:

• Configuration Synchronization (Martin Fowler / Kief Morris) — what happens to unmanaged manual changes when automation reapplies configuration.
• Snowflake Server (Martin Fowler) — argues for disabling direct shell changes and routing every change through version-controlled recipes.