AI & Automation ·

Automate One Thing — Part 2: Don't ask AI to do it. Ask AI to build it.

Header graphic for Automate One Thing — Part 2: Don't ask AI to do it. Ask AI to build it

In Part 1 I introduced the task: a multi-week enterprise cutover where ~130 notifications had to go to 60+ people at exactly the right minute, and the manual version of that job was a senior PM acting as a human alarm clock at 3 AM.

The obvious 2025-era instinct is: "AI can do that now, right? Just tell ChatGPT to send my emails on schedule."

That instinct is wrong, and understanding why it's wrong is the single most valuable mental model I can give you about workplace automation. Get this one idea right and everything else in this series follows naturally.

Two kinds of work

Every task you might automate is a mix of two fundamentally different kinds of work:

Deterministic work has one correct answer, every time. Given the same inputs, it must produce the same output. Send the notification for task #47 to its owner at 02:40, not 02:39, not 02:41, not twice, not never. Payroll. Interest calculations. Compliance deadlines. Cutover notifications.

Non-deterministic work has many acceptable answers. Draft a friendly reminder email. Summarize what went wrong last night. Suggest how to phrase the escalation to the steering committee. Ten different good versions exist; any of them would do.

Deterministic vs non-deterministic, by stakes. A 2 by 2 grid: what kind of work goes to programs, humans, simple rules, or AI directly.

Here's the thing about large language models: they are non-deterministic by design. That's not a flaw — it's the property that makes them creative, flexible, and able to handle fuzzy human language. Ask the same model the same question twice and you can get two different answers. For drafting, summarizing, brainstorming and translating, that's a feature.

For sending 130 time-critical notifications during a go-live weekend, it's disqualifying. "Usually right" is a fantastic property in a writing assistant and a catastrophic one in a scheduler. Nobody wants a probabilistic payroll run.

The trap most teams fall into

I see organizations conclude one of two wrong things from this:

Wrong conclusion #1: "So AI can't help with our critical processes." They fence AI off into a chat window for drafting emails, and the 2 AM alarm-clock work stays manual.

Wrong conclusion #2: "Just put the AI in the loop anyway." They wire a language model directly into an operational process and discover, at the worst possible moment, what "usually right" means at volume. An agent that correctly sends 128 out of 130 notifications didn't get an A grade — it silently broke a go-live twice.

There's a third path, and it's the one that actually works.

The reframe: AI as the builder, not the doer

Software is the original deterministic machine. A program that says "when the clock reaches the task's start time, send the email to the task's owner" does exactly that, every single time, forever. We've known how to write that program for fifty years.

What's changed is who can write it, and how fast.

AI in the loop vs AI builds the loop. Two panels comparing a model deciding every send with a model writing a program that decides every send.

The reframe is this: don't put the AI in the loop — use the AI to build the loop. When you need deterministic behavior, you don't ask the model to perform the task. You ask the model to write the program that performs the task. The AI's non-determinism is spent where it's harmless and even helpful — in the design conversation, in the code drafting, in the "what edge cases am I missing?" review. The output of that process is boring, rule-following, testable software. The dice write the clockwork; the clockwork runs the show.

This is exactly how the cutover notifier got built. I never once asked an AI "please send Maria an email at 02:40." Instead I spent my evenings in a conversation that sounded like:

  • "Here's my task export. Write a routine that computes, for every task, the exact UTC time its notification should fire."
  • "Now make status survive a plan re-import — keyed on the task's stable unique ID, not its row number, because rows renumber when the plan changes."
  • "A task can be in progress AND past its finish time at once. One status column can't express that — split it into two: what the owner reports, and what the clock says."
  • "What happens if two status updates arrive for the same task before the next processing cycle? Freshest signal must win. Write it that way and log the conflict."

The AI drafted the code in minutes. I reviewed it, tested it against the real plan, found what broke, and went back for the next iteration. We'll get into the actual build in Part 3 — the point here is the shape of the collaboration.

Where the human stays essential

Notice what I was doing in that conversation, though — because this is where your experience is the multiplier, not a nice-to-have.

The AI didn't know that MS Project renumbers task IDs when you insert a row. I did. It didn't know that task owners self-report "I've started" on tasks that haven't officially begun, and that the system should believe them. I did. It didn't decide that a blocked task should never fire a notification in the first place. I did.

Every one of those is a business rule extracted from lived experience and handed to the machine as a specification. The AI turned my specifications into working code at a speed no human developer could match — but the specifications were the product of twenty years of watching cutovers go sideways. This is the division of labor that actually works: domain expert supplies the rules and the judgment; AI supplies the implementation speed; the resulting program supplies the determinism.

If you've spent a career in enterprise IT, in project management, in finance operations — you are sitting on exactly the raw material this process needs. You know where the bodies are buried in your processes. That knowledge was always valuable; AI just collapsed the cost of turning it into running software.

The one-line takeaway

When the task needs judgment, creativity, or language — use the model directly.
When the task needs the same correct answer every time — have the model build you the machine.

In Part 3, we build that machine — and I'll show you why the first version deliberately ran on nothing fancier than Excel, and why that was appropriate technology rather than a compromise.

— Jerome

Previous: Part 1 — The task that ate my nights. If you're mapping which of your own processes are deterministic-at-the-core, that's precisely the kind of working session I do with teams — say hello.

Originally published on LinkedIn, July 28, 2026.