Gains:
- Ability to understand the strengths of Bash, Python and PowerShell and have artificial intelligence produce safe, protected script drafts
- Ability to add guardrails to scripts such as set -euo pipefail, empty variable checking, dry-run mode and logging
- Ability to read destructive commands and try them in an isolated environment and with dry-run first, and to apply the discipline of not embedding the secret in the script.
The spirit of DevOps is summed up in one sentence: “Automate the work you do twice.” Any repetitive task that is done manually — log cleanup, backup taking, server health check, batch file processing — takes time and is eventually corrupted by human error. Scripts take over these jobs: small programs that execute a series of commands in a sequential, reliable and repeatable manner. The DevOps professional frequently uses three languages: Bash (for Linux/Unix shell scripts), Python (for complex logic, API calling, data manipulation), and PowerShell (for Windows and cloud management).
AI is perhaps where it offers the most practical value in script generation: producing a working draft from a one-sentence description, solving a mysterious bug, translating a script into another language. But a script is dangerous when run blindly — a wrong rm, a Remove-Item -Recurse will delete files irreversibly. That's why the motto of this unit is: Let the AI write the script, you read it, try it in safe mode first, then run it.
Which language to choose and when? A rough rule of thumb: if the job consists of running several system commands in a row (copy file, restart service, retrieve archive) Bash is the most natural choice because Linux is ubiquitous on servers. If the job involves decision logic, looping, data transformation, requesting an API, or JSON processing—that is, logic exceeding 20 lines—Python stands out for its readability and rich libraries; A complex Bash script quickly becomes incomprehensible, while Python remains easy to maintain. If the job involves managing Windows servers, Active Directory, or Azure, PowerShell is the natural environment because its object-oriented nature integrates deeply with these platforms. Specifying which language you chose and why when requesting a script to the AI ensures that the output is appropriate and idiomatic for your environment.
Step by step: secure script generation
- Describe the task and environment. What will it do, which OS/shell, what constraints?
- Ask for safety railings. In bash, set -euo pipefail (stop on error, stop on undefined variable), confirmation prompt for dangerous operations, move first instead of delete.
- Request dry-run mode. Let the script write what to do with --dry-run, but don't do it.
- Read and understand. Verify what each row does, especially delete/move/network operations.
- Try it in an isolated environment. In the test folder, run it with sample data.
- Add to logging. Let the script record what it does so it can be viewed later.
Essentials of safe scripting
A production script should include these guardrails:
- Stopping in case of error. Bash: set -euo pipefail. PowerShell: $ErrorActionPreference = 'Stop'. If one step fails, the next ones should not work.
- Idempotency (repeatability). If the script runs twice, it shouldn't deal double damage; "If you already have it, skip it" logic.
- Approval and dry-run. For destructive operations "are you sure?" or the --dry-run flag.
- Input validation. Are the parameters as expected? An empty variable can turn rm -rf "$DIR"/ into rm -rf / disaster.
- Logging. Record of what was done and when.
Tip: The most dangerous mistake in Bash is deleting with an empty variable. rm -rf "$DIR" tries to delete the root directory if $DIR is empty. set -u (stop on undefined variable) and checking [ -n "$DIR" ] before deleting is a lifesaver. Explicitly request these protections when requesting scripts from the AI.
Security: secret and destructive commands
Two big dangers:
- Embedding the Secret into the script. The password must not be plaintext within the token script; Must be read from environment variable or vault. Scripts go into Git; buried secret is permanent leak.
- Destructive commands. rm -rf, Remove-Item -Recurse -Force, DROP TABLE, terraform destroy — when you see these in a script, stop and think twice. Never try the destructive command generated by the AI in prod first.
Caution: When you tell the AI to "write a script that cleans these files", carefully read the scope of the find ... -delete or rm command it produces. A wildcard (*) or the wrong path will delete more than you want to delete. Always run the script first with "list to delete" mode instead of deleting.
Comparison of three languages
criterion
bash
Python
PowerShell
Where it's best
Linux shell, command chain
Complex logic, API, data
Windows cloud management
Learning curve
Medium (trapped)
easy
medium
Error handling
set -euo pipefail
try/except
try/catch, -ErrorAction
portability
Unix/Linux/mac
everywhere
Cross-platform (PS 7+)
when
Short, system works
Logic longer than 20 lines
Windows/AD/Azure
three mini cases
Case 1 — 2 hours of craft into 5 minutes. An engineer was spending 2 hours collecting and archiving logs from 40 servers every week. He had the AI describe the task and set -euo pipefail + dry-run protections and generate a Bash script. First validated the script with dry-run, then linked it to the scheduled task (cron). Weekly work is reduced to 5 minutes and human error is eliminated.
Case 2 — null variable disaster averted. There was rm -rf "$TARGET"/* in the cleaning script produced by the AI, but if TARGET was not assigned somewhere, it remained empty. He realized this while studying as an engineer; set -u and [ -n "$TARGET" ] || added exit 1 control. During testing the variable remained null and the script stopped safely rather than catastrophically.
Case 3 — embedded token captured. For convenience, AI has added a TOKEN = "ghp_realtoken" line to a Python script that requests an API (as an example). The engineer removed this and changed it to reading from the environment variable with os.environ["TOKEN"] and canceled and renewed the token. If the script went to Git, the token would be public.
Four copyable templates
1) Secure Bash script:
Write a Bash script: [TASK]. Mandatory rules:- `set -euo pipefail` at the beginning.- Check that the variable is not empty wherever deleting/moving.- `--dry-run` flag: write what to do in this mode but do not do it.- Don't embed the secret; Read from environment variable. - Print informative log at each step. Comment the script and mark the most dangerous line.
2) Script description/control:
Describe the following script line by line and check for security: embedded secret, destructive command (rm/Remove-Item/DROP), unvalidated input, lack of error handling? Write each risk in order of importance and correction. Script: [CODE]
3) Language translation:
Translate that [SOURCE LANGUAGE] script into [TARGET LANGUAGE]. Keep the behavior verbatim, use idiomatic error handling of the target language, move any embedded secrets to an environment variable. Note points that may behave differently.Script: [CODE]
4) Planned task (cron/scheduled task):
Use this script [FREQUENCY: e.g. Write a schedule definition ([cron / systemd timer / Windows Task Scheduler]) that will run [at 02:00 every night]. Add how to warn me on failure (log/exit code/notification) and how to prevent overlap.
Weak prompt / Strong prompt
Weak: "Write a script that deletes old files."
Result: a scopeless, unprotected, dry-runless rm script; If it runs in the wrong folder, it will delete irreversibly.
Strong: "Write a bash script to delete .log files older than 30 days under /var/log/app. Use set -euo pipefail, stop if the target directory is empty, list what to delete with --dry-run first, log every transaction, do not embed the secret. Mark the most dangerous line."
Difference: the second claim gives the full scope, safety guardrails and dry-run expectation; The output can be run safely.
Common mistakes
- Running the script without reading it. Delete/move rows in particular lead to disaster.
- Not checking for empty variables. Classic disaster of deleting the root directory with rm -rf "$X"/.
- skip `set -euo pipefail` / `-ErrorAction Stop`. A step fires, the script continues blindly.
- Embedding the Secret into the script. Persistent leak to Git.
- Destructive process without dry-run. First "show me what to do", then do it.
- Making the first try in prod. Running without an isolated test environment.
In summary
DevOps is the art of automation; Repetitive work is delegated to Bash, Python and PowerShell scripts. AI is very handy at drafting scripts, debugging, and translating languages — but a secure script should include error guards like set -euo pipefail, null variable checking, dry-run mode, embedded secretlessness, and logging. It is your responsibility to read and test each script, especially those containing destructive commands, in an isolated environment and dry-run first.
Application task
Choose a recurring task (log archiving, backup, cleaning). (1) Have the AI generate a protected script with the "Secure Bash script" template. (2) Have the same script checked for security as the "Script description/audit" template and find the most dangerous line that the AI has flagged. (3) Verify its behavior by running the script with sample files in a test folder, first with --dry-run.
checklist
- [ ] I wrote the task that I don't want, the OS/shell and security guardrails.
- [ ] The script has error stopping like set -euo pipefail / -ErrorAction Stop.
- [ ] I added empty variable and input check before deletion/move.
- [ ] There is --dry-run/confirmation mechanism for destructive operations.
- [ ] There is no secret embedded in the script; the values come from the environment variable/case.
- [ ] I made the first test in an isolated test environment with dry-run.