The useful part of this subject is not the slogan or the diagram. It is the way the idea changes an ordinary decision when a system has to be built, operated or repaired with limited time and incomplete context.
The question behind automation should expose failure, not hide it is what changes in practice. The useful answer is usually found between success is not silence and keep a human-readable trail: the point where a broad idea becomes a choice that can be made, observed and revised.
A quiet job is not automatically a healthy job. Useful automation records what it attempted, what changed, what did not change and where the evidence lives. A success message should mean the expected outcome was checked, not merely that a command returned zero.
Failures are easier to handle when they are explicit. Name the step, preserve the error, avoid printing secrets and leave enough state to retry safely. A vague red light creates work; a precise failure creates an action.
Design the recovery at the same time
Before automating the happy path, decide how the process is stopped, retried and rolled back. Idempotent operations, dry-run modes and narrow permissions are not decoration. They are what make automation safe enough to trust.
The final output should make sense to someone who did not write the script. A short summary, a link to evidence and one clear next step are usually more useful than hundreds of lines of raw logs.
The practical test is whether the idea leaves the system easier to understand and recover. A design that produces clearer evidence and a smaller failure surface usually creates more value than one that merely looks sophisticated.
That is the standard I would use when returning to automation should expose failure, not hide it: keep the reason visible, make the next decision small enough to understand, and leave enough evidence to know whether the approach is still helping.