How does putting changes into automation code reduce operational risk?

Code can be reviewed before it runs, by peers and subject-matter experts, and the code itself documents the procedure.

A manual change happens in someone's terminal, and usually nobody sees it until something breaks. A change expressed as automation code can go through the same quality steps as software:

• Code review / peer review: several experts read the change before it is applied and catch mistakes early.
• Self-documentation: the code is the procedure. There is no separate runbook to forget to update.
• Repeatability: the reviewed change runs identically on every target.

This is the same reasoning as in software development: a change that is written down, reviewed and tested is much less likely to cause an outage than one typed live.

Go deeper:

• Infrastructure As Code (Martin Fowler) — practices such as versioning everything and self-documenting systems, applied to infrastructure.
• Validating tasks with check mode and diff mode (official docs) — how to preview what a change would do before it touches production.