If you spend any time automating routine tasks at work, you have probably already reached for AI to help write a script. Maybe it gave you something that ran. Maybe it gave you something that ran and also did something you did not intend. Both outcomes are instructive.
The professionals getting the most out of AI here are not the ones who run the first output and hope for the best. They are the ones who understand enough to interrogate what the AI produced before anything touches a live system. This guide covers how to do that.
The tool, and how to set it up
Claude works well for this, as does GitHub Copilot if you are already in VS Code or an IDE. The difference matters less than the approach.
Use a tool where you can have a conversation, not just a single prompt box. You will almost certainly need to iterate: paste an error message, ask it to explain a line, narrow the scope of what the script does. A chat interface handles this naturally.
Paste code directly into the chat. Do not use file upload for scripts unless the file is too large to paste, because inline context makes the back-and-forth faster.
No special mode or plugin is required. Standard chat is fine.
How to do it
1. Describe the task in plain English first, including the constraints.
Do not ask for code immediately. Start with what you are trying to accomplish, what the inputs are, what the expected output is, and what must not happen. "Rename all files in a folder that match a certain pattern" is much weaker than "rename all .log files in C:\Logs\Archive that are older than 90 days by prepending the date, without touching anything in subfolders, without deleting anything."
The constraints are where scripts go wrong. State them explicitly.
2. Ask for a commented script.
Say you want comments on every block explaining what it does. This serves two purposes: it forces the AI to be explicit about the logic, and it gives you something to read and question. A script with no comments is asking you to trust output you cannot audit.
3. Build regex from examples, not from description.
If you need a regular expression, do not describe what you want it to match in abstract terms. Give the AI five real examples of strings that should match, and three that should not. "Match UK phone numbers" produces something plausible but often wrong. "Match these five strings but not these three" produces something testable.
4. Use AI to explain inherited code before you touch it.
Paste the script and ask: "Explain what each section of this script does in plain English. Flag any lines that could modify, delete, or overwrite files or data." This is one of the highest-value uses of AI for non-developers. You can understand a script you did not write, and spot anything that deserves a closer look, before you run it or alter it.
5. Iterate on the error, not the vibe.
When a script breaks, paste the exact error message back into the chat. The full error, including the line reference. Do not describe the error in your own words if you can help it. Ask what caused it and what to change. Then read the change before accepting it.
The prompt
Write me a [PowerShell / Python / SQL] script that does the following:
Task: [describe in plain English what it should do]
Inputs: [what files, directories, data sources, or arguments it takes]
Output: [what it should produce or modify]
Constraints (important):
- [what it must NOT do, e.g. must not delete anything, must not touch subfolders, must run read-only first]
- [any environment details that matter, e.g. Windows Server 2019, Python 3.11, SQL Server 2022]
Please add a comment above every block of logic explaining what it does and why.
Flag any line that modifies, deletes, moves, or overwrites anything.
For explaining inherited code:
Explain what this script does, section by section, in plain English. Flag any line that deletes, moves, modifies, or writes to anything.
[paste script]
How to QA it
Read the script before you run it. This is not optional. Comments make it faster, but you still need to read it.
Specific things to check:
- Find the destructive operations. Search the script for
Remove,Delete,Move,Rename,Overwrite,DROP,TRUNCATE,rm,del, or anything that writes back to a file or database. Understand each one before proceeding. - Check the scope. Is the script scoped to the right directory, server, or database? A script that targets
C:\instead ofC:\Logs\Archiveis technically correct and catastrophically scoped. - Test on sample data first. Create a folder with dummy files. Run on that. Confirm the output is what you expected before pointing the script at anything real.
- Run in read-only or dry-run mode first. Many PowerShell cmdlets have a
-WhatIfflag that shows what would happen without doing it. Ask the AI to add-WhatIfto every relevant operation, run it, read the output, then remove it when you are satisfied. - The classic failure mode: a script that works as described, but also does something destructive you did not notice because it was one line in a block of twenty. Mass delete, overwrite without backup, hitting a production database instead of a staging one. Reading the script is how you catch it. Not running it and hoping.
How to stay safe
Never paste real credentials, API keys, connection strings, or user data into a prompt. Replace them with placeholders before pasting. username, yourserver, YourPassword are fine. The actual values are not, regardless of which tool you use or what their privacy policy says.
Never run an unreviewed script against production. Test environment first, always. If you do not have a test environment, create a sample directory or database snapshot to run against.
Be especially careful with anything that operates at scale. A script that renames one file is forgiving. A script that iterates over 40,000 Active Directory user accounts, or drops tables, or modifies every record in a database is not. The blast radius of a mistake is proportional to the scope of the operation.
AI does not know your environment. It does not know that C:\Archive is actually a network share mounted on twelve servers. It does not know that the table it is querying has triggers. It does not know what your backup schedule looks like. You do. That knowledge has to come from you, which is why the constraints step exists.
If a script is doing something you do not understand after asking for an explanation, do not run it until you do. That is not a failure of the tool. It is the right call.
Start with the smallest version of the task you can test safely. Get that working. Then extend it. Incremental scripts are easier to debug than ones that try to do everything in one pass.