Here is the loop most people are stuck in when they use AI to fix a macro. Open the VBA editor, copy the sub out, paste it into a chat window, describe the problem, paste the answer back, run it, watch it throw error 1004 on some object it never saw, copy the error back, and go again. It works, sort of, but you are the integration layer. You are the clipboard, the compiler, and the test harness, doing it all by hand.
That loop is worse for VBA than for almost any other language, and the reason is specific.
The chatbot is guessing in the dark
Most code lives in files a model can read. VBA lives inside the workbook. Its behavior depends on the object model, the references that are enabled, the names on the sheets, and the actual state of the Excel instance that is open right now. When you paste one sub into a chat window, you have thrown all of that away. The model writes something that looks right, but it can't see the other module that already declared that variable, and it can't run the macro to find out that the range you handed it is one row short.
So it guesses. Sometimes the guess is good. Often it compiles and then does the wrong thing quietly, which is the worst outcome, because now you are debugging code you didn't write against data the model never saw.
What changes when the agent can actually run it
The fix is not a smarter chatbot. It is closing the loop, letting the thing that writes the code also read your real modules and run them.
Point an agent at the project itself: the .bas and .cls files, and the workbook that is open. You describe the change. It reads your actual modules, writes the code, runs the macro against the live workbook, and reads whatever comes back. If it throws, it sees the real runtime error, on your machine, against your data, and takes another pass before it ever hands the code to you. You review a result and a diff instead of playing clipboard.
The part that still gets me is watching it run the macro and react. Not "here is a macro that should work." It runs, it sees row 1,001 is blank, it fixes the bound, it runs again. That is the difference between an assistant that talks about your code and one that works on it.
Why this matters if you own a pile of VBA
Most serious VBA is old. Someone built a 4,000-line workbook years ago, they left, and now it is load-bearing and nobody wants to touch it. That is exactly the code where the paste-into-a-chatbot approach falls apart, because the context that matters is spread across modules and sheets you can't paste. An agent that reads the whole project and tests against the real file is the only version of "AI help" that survives contact with that kind of workbook.
Full disclosure: I built a tool for this, called VBridge. It runs Claude Code against your actual Excel VBA project on your own machine. It is not the only way to close the loop, but closing the loop is the point, so even if you wire up your own, do that part.
A two-minute before and after is here: vbridge.netlify.app
If you write VBA, or you inherited a workbook nobody wants to own, try describing a change and letting the agent run it against the real file. Going back to the chat window afterward feels like going back to hand-copying error messages, because that is what it is.
