AI Can Write the Script. But What Runs It?

A few weeks ago I wrote about how AI is changing Windows automation.

One of the most obvious changes is that it’s becoming remarkably easy to generate code.

Need a PowerShell script to process a folder full of files? Ask an AI.

Need some Python to call an API and turn the response into a CSV? It can probably get you most of the way there in seconds.

Need a bit of VBScript, JavaScript or even Macro Scheduler code? Same thing.

For developers – and increasingly for people who aren’t developers – AI has dramatically lowered the barrier to creating small pieces of automation.

But there’s an important distinction which I think sometimes gets overlooked:

Writing the script isn’t the same as running the automation.

THE SCRIPT IS ONLY PART OF THE JOB

Imagine you’ve asked an AI to create a PowerShell script which downloads a report, processes it and saves the result somewhere.

Great. You now have a script.

But perhaps the actual requirement is:

– Run it every weekday at 6am
– Run it unattended
– Pass it the correct parameters
– Capture the output
– Know whether it succeeded
– Do something else afterwards
– Retry or take another action if something fails
– Keep a log of what happened

At that point the problem isn’t really “how do I write this script?” any more.

It’s “how do I turn this script into a reliable automation?”

And those are two different problems.

AI IS MAKING THE BUILDING BLOCKS EASIER

I’ve been writing automation software for nearly 30 years, and one thing that has remained fairly constant is that useful automations tend to be made up of lots of different pieces.

A Macro Scheduler script might launch an application, interact with its user interface, run a command-line utility, execute some PowerShell, query a database, move some files and send an email.

It doesn’t particularly matter where those individual pieces came from.

You might have written them yourself.

A colleague might have written them ten years ago.

You might have copied and adapted something from Stack Overflow.

Or, increasingly, you might have asked an AI to create them five minutes ago.

The interesting thing about AI is that it makes many of those building blocks much easier to create.

That doesn’t necessarily remove the need for automation tools.

Arguably, it gives us more things to automate.

ORCHESTRATION STILL MATTERS

This is where I think traditional automation tools still have an important role.

Something needs to join all those pieces together.

Something needs to decide when they run, in what order, with what parameters and what happens when something goes wrong.

And sometimes the thing you’re trying to automate doesn’t have an API or a convenient command-line interface at all.

It’s still a Windows application with buttons, menus, dialogs and fields that somebody would otherwise have to operate manually.

AI can help you write code.

But code generation doesn’t magically make every application programmable, nor does it automatically give you reliable unattended execution.

USE AI AND AUTOMATION TOGETHER

I don’t see this as AI versus traditional automation.

The more interesting combination is AI plus automation.

Use AI to help create scripts, regular expressions, SQL, PowerShell, Python or whatever other building blocks you need.

Then use the appropriate automation tools to put those pieces together and run them reliably.

That might be Macro Scheduler. It might be Windows Task Scheduler. It might be a CI system, a cloud service or something else entirely.

Use the simplest tool that solves the problem.

But don’t confuse generating a piece of code with solving the whole automation problem.

AI can write the script.

Something still has to run it.