FormulaAI shipped something small that's worth taking apart. In a recent update it added natural-language-to-VBA generation and dropped the login requirement for anonymous users. You describe what you want in plain language, pass along the spreadsheet's column names and headers, and the model returns VBA you paste straight into Excel's macro editor. The team's own framing is honest about scope: VBA usage is still low because few people write VBA at all, and the feedback from the handful who tried it has been positive. That last part is their read, so treat it as unverified.
What caught my attention isn't the feature. It's where the actual engineering value sits. People hear "AI generates code" and assume the model call is the product. It isn't. The model call is the commodity. The reusable half of this tool is the schema-aware prompt assembly and the ledger that records what went in and what came out. That's the part you own, the part you can improve, and the part that keeps working when you swap models underneath.
What's actually load-bearing
Strip FormulaAI's VBA feature to its bones and you get three moving parts. First, prompt assembly: you take the user's request, pull the live table structure (column headers, sheet layout), and fold both into a prompt that constrains VBA syntax, forces comments, requires explicit variable declarations. Second, the model call itself. Third, returning the text. Only the middle piece is interchangeable. The first and third are where quality and trust live.
The prompt assembly is load-bearing because a bare "write me VBA to sum sales by department" produces generic code that references columns that don't exist. Feed the real headers in and the output lines up with the user's sheet. That mapping, from messy spreadsheet state to a clean structured block inside the prompt, is parsing and string work. It's deterministic. It's testable. It's the opposite of the model call, which is the part you least control.
Rebuilding it as a Python endpoint
Here's how I'd reconstruct the generator on VicroCode, and where I'd stop. The whole thing fits as a hosted Python backend. You can run Python online for the parsing and prompt-assembly layer, expose it through API Endpoint Hosting so a front end or a script can POST a request, and reach the model through the Model Center APIs for whatever model the platform already offers. No separate server to babysit.
The flow is plain. The endpoint receives a payload: the user's natural-language request plus the table schema (header row, column types if you have them). Your Python code validates that payload, normalizes the schema into a compact description, and slots it into a prompt template that carries all the hard constraints: declare variables, add comments, target the Excel object model correctly. You call the model, get VBA text back, and return it. The schema normalization and template rendering are ordinary Python, which means you can unit-test them without ever touching the model.
For the model being wrong, and it will be wrong, there's a sharp lesson in the evidence worth internalizing. Someone tried using an AI model to reverse-engineer C# from a DLL and watched it confidently misread a branch target, mapping an if-body to the wrong store. Their conclusion was blunt: once it got that wrong, they couldn't trust the rest of the output. Generated VBA has the same failure mode. It compiles in your head and breaks in the editor. That's exactly why the output ledger matters more than the generation.
The ledger is the product
Every request and every output goes into a store. On VicroCode that's a SQLite table: timestamp, the raw request, the normalized schema you built, the exact prompt you sent, the model's response, and whichever model answered. You can inspect and correct rows directly through the SQLite editor, which turns a black-box generator into something you can audit. When a user says "the code you gave me errors out," you pull the row and see precisely what prompt produced it. That's how you improve the template instead of guessing.
This ledger is also where the login-free decision lives, and I'd argue it's a backend concern, not a feature. FormulaAI framed anonymous access as giving users control over their personal information, and reported the change moved new-user conversion, with the number still being watched. Both of those are their observations, so unverified. But the mechanism is clean: you don't gate the endpoint behind auth. Instead you assign anonymous callers a temporary quota, tracked in the same SQLite table by a session token or similar key. Login only enters the picture when someone wants to save history or pay. The quota logic is a few columns and a counter, not an identity system. Keep it in the backend where it belongs.
One caution worth stating plainly: an open, unauthenticated endpoint that calls a paid model is a cost surface. The temporary quota isn't just a conversion lever, it's your rate limit against abuse. Build it before you publish, not after.
The line you can't cross, and why that's fine
Here's the honest boundary. VBA runs inside Excel's macro editor. Excel is not on VicroCode, and VBA is not Python. The platform runs Python, not VBA, so you can generate the code and log it, but you cannot execute or verify it here. There's no "did this macro actually sum the right column" check available on the platform. You ship text that the user runs somewhere else, in an environment you don't touch.
That's not a flaw to paper over. It's the shape of the problem. The one tool-maker in the evidence who leaned into this got it right: the AI drafts, the human runs it in their own environment, and the generator stays in its lane. Pretending otherwise, promising verified or guaranteed-runnable output, is the kind of thing that burns trust the first time a macro fails. Say what the tool does: it assembles a schema-aware prompt, calls a model, logs the exchange, and hands you code to review. The reviewing is yours.
If you want to go deeper on structuring prompts and the surrounding plumbing, the AI coding material is a reasonable place to start. And when the generator earns its keep, project publishing and monetization are there to turn it from a weekend endpoint into something you charge for. The whole stack, Python logic, hosted endpoint, model access, and the ledger, sits in one place. The part you'd otherwise cobble together from a backend, a database, and a deploy pipeline is already assembled.