Automation Is the Last Step, Not the First

Automate a workflow only after you can perform it manually, explain its decisions, and verify its result. Begin with a working procedure. Document it, move deterministic steps into code, test the code, and add scheduling only when monitoring and recovery are ready.

Automation multiplies the workflow you give it. If the workflow is unclear, automation repeats unclear decisions faster.

Perform the work manually first

Complete the task on a small, representative example. Record:

• the starting state;
• required inputs;
• each action;
• decisions that require judgment;
• expected outputs;
• failure conditions; and
• evidence of success.

Suppose you want to organize weekly course downloads. Perform one week manually. You may discover that some filenames lack course codes, two courses use the same assignment name, and one PDF belongs in administrative records rather than a course folder.

Those are design requirements. A script written before the manual pass would have to guess.

Turn the observed workflow into instructions

Write the confirmed process as a checklist:

# Sort course downloads

1. Inspect the download folder.
2. Exclude incomplete downloads and unrelated personal files.
3. Match each file to a course using the filename and current syllabus.
4. Preview the destination path.
5. Copy one file.
6. Open the copy and compare its name and size.
7. Remove the original only after verification.
8. Record files that need human classification.

Instructions expose ambiguity before it becomes code. If two readers would make different decisions at step 3, define a rule or preserve that step for human review.

Automate deterministic steps with code

A deterministic step produces the same result from the same relevant inputs under stated conditions. Examples include:

• checking a filename against a defined pattern;
• calculating a destination path;
• validating required fields;
• generating a report; and
• comparing a file hash.

Judgment-heavy steps include interpreting an unclear filename, deciding whether material is private, and resolving conflicting course rules. Code can present these cases, but it should not silently invent the decision.

Create the smallest useful script. Keep its inputs and outputs visible. Add a preview mode before allowing file changes.

Verify the script independently

Test more than the successful example:

Run the script on disposable copies. Compare the resulting files with the documented expected state. A zero exit status is useful, but it does not prove that files reached the correct destinations.

Keep the manual checklist until the automated result has been verified across representative cases.

Add a trigger only after manual execution is reliable

A script can be run:

• manually;
• on a schedule;
• when a file or event appears; or
• as part of another workflow.

Manual invocation is the safest first interface because the student can inspect inputs and observe output. A schedule or event trigger removes that pause.

Before enabling a trigger, specify:

• which account runs it;
• its working directory and environment;
• what happens when the device is asleep or offline;
• how simultaneous runs are prevented;
• where output and errors are recorded;
• how a failure is reported; and
• how to disable the trigger.

Do not schedule a script that still needs interactive judgment.

Monitoring is part of the automation

An unattended process needs observable evidence. Record:

• start and finish time;
• input count;
• changed and skipped items;
• warnings and errors;
• verification result; and
• next required action.

“No message” is not evidence of success. Monitoring should make failures visible without exposing secrets or private filenames unnecessarily.

Set a review interval. Course folders, naming conventions, software versions, and platform behavior change. A script that was correct last semester may now apply an obsolete rule.

Prepare recovery before deployment

Automation can repeat one mistake across many files. Limit its consequences:

1. Use a preview or dry-run mode.
2. Work on a small batch.
3. Refuse unexpected paths and overwrites.
4. Preserve an appropriate checkpoint or backup.
5. Record exactly what changed.
6. Provide a documented way to stop the process.
7. Test recovery on disposable data.

If rollback cannot be made safe, design the operation to copy or report rather than delete or overwrite.

Use an automation-readiness check

# Automation readiness

- [ ] I completed the workflow manually.
- [ ] The instructions work without the original conversation.
- [ ] Deterministic steps are separated from judgment.
- [ ] Inputs, outputs, and exclusions are explicit.
- [ ] Preview and representative tests pass.
- [ ] Verification checks the real result.
- [ ] Errors and partial completion are visible.
- [ ] A checkpoint and recovery path exist.
- [ ] The trigger can be disabled.
- [ ] A review date is scheduled.

If several boxes remain open, improve the manual process or script before adding a schedule.

Common mistakes

• Automating a task performed only once.
• Encoding an unexplained manual habit as a permanent rule.
• Hiding human judgment inside a filename guess.
• Testing only the expected case.
• Scheduling before adding logs and failure notification.
• Treating command completion as result verification.
• Using automatic deletion without a tested recovery path.
• Keeping an automation after its course or purpose ends.

Do this now

Choose one repeated low-risk task. Perform it manually and write the checklist. Mark each step as deterministic, judgment-based, or verification. Automate only one deterministic step and keep execution manual.

Log what you learned

Record only:

• Result: What did the action produce?
• Evidence: What observation, test, or source supports that result?
• Next action or unresolved question: What should happen next?