The AI wrote code that would have destroyed a live spreadsheet

The code looked right.

That was the problem.

I was working with a local nonprofit clinic that ran important parts of its operation out of Google Sheets. The workbook mattered. It was not a toy file, not a copy made for a demo, not a clean tutorial spreadsheet with three columns and harmless sample data. It was live work. People depended on it. The clinic had a Sunday operating rhythm, and the file had to be usable by the people who actually carried the work.

Gemini was asked to help improve part of that workflow. It produced Apps Script. At a glance, the answer had the shape of competence. The function names were reasonable. The comments sounded helpful. The structure was plausible. If you had asked a non-technical owner whether it looked like code, the answer would have been yes.

If you had pasted it into the live workbook and run it, it would have touched the wrong reality.

The script referenced sheet names and cell ranges that did not exist in the workbook. Not because Gemini was malicious. Not because the request was foolish. Not because AI is useless. It happened because the model was filling in the missing parts of the world with something that sounded likely.

That is the failure mode people miss.

Looks right is not the same as right

A spreadsheet has a surface that feels simple. Rows, columns, tabs, formulas, colors. Most business owners understand it because they live in it every day. But a live workbook is not simple. It is a small application with history.

It has tabs created months apart. It has formulas someone dragged across a range and never documented. It has naming habits that made sense to one person at the time. It has hidden assumptions. It has one column that must never be overwritten because another sheet depends on it. It has a manual step everyone remembers until the one week someone is sick.

When AI writes code against that workbook without actually inspecting it, the answer can only be as grounded as the context it was given.

That does not make the answer worthless. It makes it conditional.

The dangerous moment comes when the output is polished enough that people stop treating it as conditional. The indentation is clean. The function has a name. The comments explain intent. The model says what to paste and where to click. The whole thing carries the tone of a competent assistant.

But the workbook does not care about tone.

If the code points to a tab that does not exist, the script fails. If it points to a range that exists but is the wrong range, the result can be worse. It can quietly write over the wrong cells. It can move data into the wrong place. It can break formulas that nobody notices until the next clinic day. It can create a new problem while appearing to solve the old one.

That is why the review mattered.

The catch happened before the damage

I did not catch the problem by being clever. I caught it by refusing to treat the AI output as finished work.

The first pass was simple: compare the code to the workbook. Does this tab exist? Does this range exist? Does this column mean what the script assumes it means? What happens if the row is blank? What happens if the user runs it twice? What happens if the file has a filter on? What happens if someone renamed a tab last month?

Those questions are not glamorous. They are the difference between assistance and damage.

The code had to be checked against reality before it touched the live file. That meant reading it like a person responsible for the outcome, not like someone impressed by the output.

This is where many small businesses are exposed. They do not have a developer. They do not have an IT department. They do not have a staging environment. They have a workbook, a deadline, a staff member who needs the work to go faster, and an AI tool that can produce something that looks ready.

The gap between those things is where risk lives.

AI makes small automation feel deceptively reachable

Before AI, a small business owner usually knew when they were outside their depth. Apps Script looked like code because it was code. Automating a workbook felt like a technical task. That friction was annoying, but it also served as a warning.

AI lowers that friction. Now the owner can ask in plain language. The tool can answer in seconds. It can produce a function, a trigger, a menu item, a formula, or a script that sounds tailored to the situation.

That is genuinely useful.

It is also why review matters more, not less.

AI can help a small business build things it could not build before. But when the tool is operating from partial context, it can also invent the missing parts with confidence. It may invent a sheet name. It may assume a header. It may decide which row contains live data. It may create a cleanup step that deletes something the business still needs.

None of that looks dramatic in the answer. It looks like progress.

The owner sees a path. The staff member sees relief. The tool sees a task completed. The workbook sees instructions.

The workbook is the one that gets changed.

The right question is not whether AI can code

People argue about whether AI can write code as if the answer settles the business question.

It does not.

Yes, AI can write useful code. It can explain code. It can draft Apps Script. It can help with formulas. It can speed up the first version of a workflow. I use it for that kind of work.

The business question is different: can anyone in the room tell whether this code is safe to run here?

Here matters.

Not in a sample file. Not in the model's imagined workbook. Not in a forum answer from someone else's use case. Here, in this actual file, with these actual tabs, these formulas, these people, and this operating rhythm.

That is the question small businesses need to ask before AI-generated automation touches live work.

If the answer is no, the next step is not to give up. The next step is to create a safe review path. Make a copy. Test against the copy. Inspect every sheet name and range. Back up the file. Ask what the script can change. Write down how to undo it. Keep the first version small.

Small is not cowardice. Small is how you keep the business intact while you learn.

Why this changed how I teach AI

This is one of the reasons I do not teach AI as prompt tricks.

A better prompt might have helped. More context might have helped. A pasted list of sheet names might have helped. But the deeper lesson is not "write a better prompt." The deeper lesson is that AI output has to meet the world before the world is allowed to depend on it.

That is true for spreadsheets. It is true for policies. It is true for client emails. It is true for board materials. It is true for any workflow where a polished answer can move faster than review.

The skill is not being impressed. The skill is knowing where to slow down.

In this case, slowing down meant the live workbook stayed safe. The clinic could keep operating. The useful parts of the AI output could still be salvaged, but only after the invented parts were removed and the work was grounded in the actual file.

That is the posture I want small businesses to learn.

Use AI. Let it help. Let it draft. Let it suggest. But do not let it act on a live system until someone has checked the places where it can be confidently wrong.

The future of small-business AI will not be decided by who can paste fastest. It will be decided by who can tell the difference between a useful draft and a dangerous instruction.

If you need an assessment before AI touches live work, start a conversation.