If you’re going to let generative AI loose on your PowerShell scripts, you need rules. Not lofty principles. Not vague best practice. Actual rules. The kind you mutter under your breath when you’re cleaning up after a script that technically runs, but only just. So this post is about that. Kamal’s rules for using generative AI to write PowerShell. Not because AI is useless. But because it’s enthusiastic. And enthusiasm without discipline is how you end up with 300 lines of code to set one registry value.
Rule 1: Try/Catch Is a Tool, Not a Lifestyle
Use try/catch when it helps. When you expect failure. When you need control. But AI tends to wrap every cmdlet like it’s handling radioactive material. You don’t need a bunker around Get-Item.
Rule 2: Comment for Your Intended Audience
Comment for the people who’ll actually read your work. If it’s another admin, explain the “why”. If it’s junior staff, spell out assumptions - you’re allowed to be basic. If it’s future-you, admit the workaround. Don’t write ”# set variable”. Write ”# legacy app fails without this fallback”.
Rule 3: Hyphens Over Colons in Write-Host
AI loves a tidy colon. Write-Host “Status: $Value” looks fine until it isn’t. Colons and variables don’t always mix well.
Use hyphens. Write-Host “Status - $Value”. It’s boring. It works. That’s the point.
Rule 4: Don’t Wrap Every Variable in $()
“The value is $Value” is fine. You don’t need “The value is $($Value)” unless you’re actually evaluating something.
AI overuses subexpressions because it’s playing it safe. All it really does is make the script harder to read if it’s not required.
Rule 5: Use -Type, Not -PropertyType
When setting registry values, it’s “-Type”. Not “-PropertyType”. AI gets this wrong constantly.
It looks plausible. It’s still wrong. And it’s the sort of mistake that quietly wastes your afternoon.
Rule 6: Remote Work Starts With “Are You Even There?”
Before running remote commands, check the target is reachable. AI assumes the server is online, reachable, and feeling cooperative.
Do a quick availability check first. Ping if that works in your environment. If not, test what matters, like WinRM. One dead server shouldn’t stall the whole script.
Validate reachability before you start swinging.
Rule 7: Never Assume Folders Exist
AI loves a script that confidently writes into “C:\Temp\Reports” as if every machine on earth agreed to that structure. But file system operations are literal.
Before you read from a folder, write to a folder, or enumerate anything under it, check it exists. If it doesn’t, create it when appropriate, or fail cleanly if it isn’t. The only thing worse than “path not found” is “path not found” after you’ve already done ten other steps.
Rule 8: Null Checks Aren’t Optional
This is one of AI’s favourite moves: run Get-ChildItem, assign it to a variable, and immediately start indexing or looping as if results are guaranteed.
If a command can return nothing, treat “nothing” as a valid outcome. Check for null. Check for empty arrays. Confirm there’s data before you use it. “Is there data to use? Great. No? Then don’t use it.” That’s not defensive coding. That’s just coding.
Rule 9: Output Should Be Objects, Not Vibes
AI loves output that looks nice on screen. A few Write-Host lines glued together with a timestamp and suddenly you’ve got “reporting”. Except you don’t. You’ve got formatted strings.
If your script is collecting data, return structured objects. That way you can pipe to Format-Table for quick viewing, or Export-Csv, or ConvertTo-Json, without rewriting the script. Objects make filtering, sorting, and reuse straightforward. Strings lock you into one presentation and make everything harder later.
Ultimately
AI writes code that looks right. Looks right. Your job is to actually make it right. Trim the garbage, fix the guesses, and keep the intent.