Who Pressed the Button?

It Works. That's Exactly the Problem

One of my clients, a company I built two large modules for, has an employee who isn't a programmer. Smart, curious, and above all someone who gets irritated by repetitive work. So far so good. He discovered you can ask an AI to write a macro, and from that moment nothing could stop him.

A macro that opens one program and types into another. A macro that clicks buttons, prints from inside a system, moves data from window to window. And it works. I say that without cynicism: it really works, and the time saved was real. The owner, naturally, was delighted. And he was right to be — up to a point.

Because in his eyes the saving was double. Fewer hours of manual work, and also less need to call me. Here I owe you some honesty: I have a stake in this. I'm a programmer, and it's how I make my living. So take what follows with a grain of salt, and judge the arguments themselves rather than the person making them.

Macros That Grow Like Weeds

The first problem is the pace. The macros multiply not weekly but daily. Every small frustration becomes a new macro, and every new macro rests on the assumption that the screen will look today exactly as it did yesterday.

That's what a macro like this is: a script that assumes. It assumes the window will open, the button will be where it was, the printer will answer, the right customer will be selected in the list. Someone without experience writes it for one scenario — the one where everything goes right. Not for the case where a dialog pops up halfway through, the network is slow, the row is empty, or the user clicks something else while the macro is running.

That's not the employee's failure. It's exactly the difference between someone who can write code and someone who can write code that copes with the real world. The second takes years to learn, usually through your own mistakes.

And When Something Goes Wrong, There's Nothing to Read

The second problem is quieter and, I think, more serious: there are no logs. Not a single line. No macro writes down what it did, on which record, when, or how it ended.

Anyone who has worked in a banking or insurance system knows a log isn't decoration. It's the answer to the first question asked after any incident: what exactly happened? Without a log there's no answer, only guesses and a reconstruction from what people remember. And that, in most cases, isn't accurate.

So a macro can fail and nobody notices. A document wasn't printed, or was printed twice, or was printed with the previous row's data. Maybe it surfaces tomorrow, maybe next month, maybe when a customer calls.

The Moment It Stops Being a Technical Matter

Up to here it's an inconvenience. Now imagine one macro that produces a document or a message, and one day, for whatever reason, sends it not to the customer who was supposed to get it. One customer's details in another customer's hands.

That's no longer a bug. It's a data exposure, and anyone who has handled customer data knows how sensitive that is: complaints, demands, and in the bad cases a lawsuit and fines. And then comes the hard question: how did this happen? Who ran it? What exactly did the macro do? Who is responsible? And maybe the blame will fall on the employee whose email it was sent from?

When there's no log and nobody reviewed the code, the answer is a shrug. And for a business owner, a shrug in front of an angry customer and a lawyer is not an answer.

Doing the Savings Math

The idea was to save money by not paying someone whose profession this is. But let's do the math to the end.

In the best case, an employee who should be doing their own job spends a good part of the day hunting for the cause of a broken macro, with no log to show where. And not only them — everyone who depends on the result gets dragged along. In the worst case, once more: a lawsuit. And a single one is enough to wipe out years of savings.

There's a small irony here. Whoever wanted to save because it's "just code" discovers that code is a profession, like accounting — the kind of thing you can do yourself right up until the audit arrives.

I'm Not Against It. Not at All.

I use AI every day, and I write about it myself. It saves me time, shortens the road, and opens possibilities that didn't exist two years ago. And what this employee did deserves respect: he took initiative, understood a process, and automated it. That's exactly the trait a business wants in its people.

But the difference between a racing driver and someone who rented a fast car isn't enthusiasm. The tool gives a feeling of capability. It doesn't give experience, knowing what can go wrong, or the habit of asking "what if?" before you run it.

AI gives an answer with full confidence even when it's wrong — I wrote about that elsewhere. Someone who doesn't understand what was written for them can't see the mistake. And the macro will run it, faithfully, again and again.

On the "simple" request that never is: Two Glasses by the Bed→

What To Do Instead

You don't need to stop the initiative. You need to give it a frame. A few things I'd insist on, none of which needs a big budget:

First, an inventory. Every macro running in the organization: who wrote it, what it does, on which data, how often. You can't manage what you don't know exists.

Second, a log for every macro, even the simplest: when it ran, on what, and whether it succeeded. A text file is enough to start with.

Third, anything that touches customer data or sends something outside gets a professional's eyes before it runs for real. And no "send" step that fires on its own without a person seeing what is about to go out.

And fourth, the person who wrote them keeps writing. He even becomes the one who spots the needs and phrases them, and some of the macros become, with a professional's help, something stable. That's a healthy division of labor: he brings the knowledge of the process, and I bring what holds it up when something breaks.

The same idea from the other side: An AI Agent Is Not a Chatbot→

Do It Right the First Time

AI is a wonderful tool, and it helps many people. But chasing the trend, together with the false sense that the tool can do any job even when the person using it lacks the skills, can cost dearly, in every sense.

Let's do the work well from the start, rather than fix afterwards what was done crooked. Repair always costs more than the right way, and sometimes there's nothing left to repair.