Nobody touches VBA

In February 2022 Microsoft announced that Office would stop running VBA macros in files that came from the internet. The reasoning was not subtle. From Microsoft's own documentation: "VBA macros are a common way for malicious actors to gain access to deploy malware and ransomware."

Then look at how long it took to ship one default. The change reached the preview channel in April 2022. Microsoft paused it at the end of June after user feedback, called the reversal temporary, and resumed in July. It did not land in the Semi-Annual Enterprise Channel until January 2023. Nine months, one pause, to change a default.

Now read the document that came out of it. Most of it is not about blocking macros. It is about how to keep them running — Trusted Locations, trusted publishers, Site to Zone Assignment lists, Unblock-File, removing Mark of the Web, opening from SharePoint via Open in Desktop App. There is a table of scenarios and the workaround for each. And there is one line that names the department Microsoft had in mind:

If you have a group of users, such as the Finance department that needs to use files from OneDrive or SharePoint without macros being blocked… Microsoft 365 Apps documentation

That is a security team writing an exception path for a business function it could not switch off. It is the clearest public statement anyone has made about how load-bearing this code is.

"Legacy" is not the same as "unused"

VBA gets filed under legacy, and the word does real damage, because it quietly implies declining usage. Microsoft's own behaviour says otherwise. You do not spend nine months and a public reversal disabling something nobody runs, and you do not then document eight separate ways to keep it alive.

What is actually true is narrower and more awkward: the language is frozen, the tooling around it stopped improving, and the people who depend on it were never going to be the ones who moved. That is a different problem from obsolescence. Obsolescence resolves itself. This does not.

Where the AI tooling stops

Ask a spreadsheet assistant to write you a macro and most will. Ask what the macro already in the file does, and the answer thins out. The gap is not subtle in the products either — Copilot will generate VBA and then hand it back to you to install and run yourself. As one walkthrough of the feature puts it: "Copilot can't execute and automate this macro on its own."

So the supported case is generation: new code, for a new task, in a file with no history. That is the easy half. It is also the rare half. What people actually have is the other one — a module written in 2011 to fix one client's file, extended by four people who have since left, that now produces the month-end pack. Nobody is asking for a fresh macro. They are asking what the existing one does before they touch it.

Generation and comprehension fail differently, and that is why the split persists. Generated code that is wrong is visible immediately: you run it, it errors, you discard it. An assistant that misreads existing code is wrong invisibly. It answers about the part it can see, in the same confident register it uses for everything else, and the user has no signal that the answer is bounded. Partial knowledge delivered at full confidence is worse than a refusal.

Why the avoidance is rational

It would be easy to call this negligence. It is not. Three reasons hold, and they are good ones.

The code runs with the user's full authority. A macro can reach the filesystem, the network, and anything else on the machine. Anything that reads it has to reason about what it does; anything that writes it is handing a model a loaded instrument. "The assistant edited a formula" has a simple safety story. "The assistant modified the routine that emails results to the board" does not.

It was never designed. This code accretes. It has no tests, no documentation, and frequently no author still at the company. Any system touching it is operating on code that nobody currently understands — including the people who depend on it daily.

It does not demo. Formula generation is legible from a stage in thirty seconds. Correctly explaining an undocumented macro is not, and the person who would appreciate it is usually not the person signing.

Who this strands

The cost lands on the users with the most invested in their tooling and the least ability to move.

The analyst whose reporting pack has one manual step in the middle: run the macro, wait, check the output. Everything on either side of that step is now assisted. The step itself is not, and cannot be, because the assistant cannot see it. The workflow is faster and still not automated, which is its own specific frustration.

The team that has inherited a model they cannot fully account for. They can ask about every formula on every sheet and still not learn what happens when the button is pressed. The audit question — what does this file do — remains unanswerable by the tool that claims to understand the file.

What taking it seriously would require

This is not a feature. It is four commitments, and most of them are about restraint.

Read before you write, for longer than is comfortable. Nearly all of the value is in comprehension: what a routine does, what it touches, what breaks if it changes. That is achievable and safe. The urge to move on to modification should be resisted well past the point where it becomes technically possible.

State the blast radius, not the intent. Anything that reads this code should be able to say what it reaches — which sheets, which files, which network calls — before anyone acts on it. A summary of what the code appears to be for is not the same claim and should not be presented as one.

Be loud about what you cannot see. A system that cannot read the automation layer should say so at the moment its answer becomes incomplete, not in a footnote. This is the cheapest of the four and the one most often skipped.

Separate the three permissions. Reading code, running existing code, and authoring new code are three different acts with three different failure modes. Collapsing them into one consent prompt is convenient and wrong.

What we are claiming

VBA is frozen, not unused. Microsoft's nine-month rollout, its pause, and its list of workarounds are the evidence.
The AI tooling supports generation and not comprehension, and that is backwards relative to what users have in front of them.
The avoidance is rational — the code is unreviewed, undocumented, and runs with full user authority.
Rational avoidance still strands people, and it strands the ones with the least room to move.
Comprehension without modification is most of the value and carries a fraction of the risk. It is the part worth building first.

The argument that this layer is legacy and will age out has been made for twenty years. Meanwhile the routines still run, the packs still ship, and Microsoft is still writing documentation for the Finance department.