Your Users Already Run AI-Generated Code

A few years ago, the request that landed on a product team looked like a feature ask. “Can the export include the regional breakdown.” “Can we get a webhook when a deal closes.” “Can the dashboard filter by the thing we care about and not the thing you decided we care about.” Each one went into a backlog, got prioritized against a hundred others, and shipped a quarter later as a rigid switch that solved 80% of the request for 20% of the people who asked.

That request has already changed shape. The same person who used to file a ticket now opens a chat with an assistant, describes the exact thing they want, and watches it get built in front of them. They are not waiting for your roadmap. They have their own tools, and those tools write code.

This is not a forecast. It is the current state, and the slope is up. We keep re-learning the same lesson about these models: the thing they are best at, by a wide margin, is writing code. Every capability jump lands first and hardest there. So that is where your users’ leverage is too. The more capable the assistant on someone’s desk, the more of their problems it solves by quietly writing a program. That curve does not flatten as the models improve. It steepens.

Whose Infrastructure

Code does not run in the abstract. It runs on infrastructure, against data, throwing off logs. So the real question is not whether your users will run model-generated code against your product. They will. The only question you actually control is whose infrastructure it runs on.

It can run on yours. In your environment, in your logs, under your controls, next to the data it needs to be useful. Or it runs somewhere you cannot see: a browser tab where an agent scrapes your UI, a personal API key pasted into a sandbox you have never heard of, a customer’s data copied onto a laptop so a model can finally do something with it. The code runs either way. One of those worlds you can audit. The other you learn the shape of during the incident review.

For anyone carrying a compliance or regulatory load, this sharpens to a point. You cannot make a regulated team productive by routing their data through an outside sandbox to get an answer back. The teams least permitted to let data leave are precisely the ones whose users most need to run code against it. If the only path to the leverage runs off your infrastructure, a regulated shop is stuck choosing between its rules and its tools. That is a losing position, and it is one you can design away by making your own infrastructure the place the code runs.

I spend most of my time on the operational side of this, and it keeps reducing to a single question: how do you keep it on the ranch. Keeping the code on your own land is not a default you get for free. It is something you build. In-house execution has to be easier than the laptop, more capable than the laptop, and wired into the data the user actually needs, or people take the work elsewhere and you find out later. If the ranch is the path of least resistance, the code stays home. If it is not, the herd wanders off, and it takes your data with it.

The Lego Move

So you decide the code runs on your infrastructure. The next question is what it runs against. The answer is not a bigger API, and it is not a thousand new features. It is primitives.

The question stops being which features to ship. It becomes which primitives to expose. A primitive is a small, safe, composable unit of your product’s capability. Read these records. Write to this collection. Call this calculation. Trigger this action. Each does a single legible thing and nothing else. None of them exposes your internals. Together they are a box of Legos, and your users are the ones who decide what to build.

The value of Legos is that the company does not anticipate the castle. They make bricks that fit together reliably and let a million people build a million things the design team never imagined. You are not in the business of guessing every report, integration, and workflow your customers need. There are fifty thousand variations of each and roughly one user apiece. You were never going to build those. You can let them be built.

This is a different discipline from feature work. A feature is a finished thing you hand someone. A primitive is a capability you expose and then refuse to over-specify. The hard work moves from designing the castle to designing bricks that compose cleanly and cannot be misused. That is mostly an interface and a boundary problem.

Weird First-Party Code

There is already a name for code that runs inside your system but that you did not write. We have done it for decades. Plugins. Extensions. Marketplace apps. Third-party code is a solved-enough genre: you sandbox it, you scope its permissions, you hand it an API surface instead of the keys to the building, and you assume it is at best careless and at worst hostile.

User-defined code is that same architecture pointed in an unfamiliar direction. It has the trust posture of third-party code. It is untrusted, it runs in your walls, it must be isolated from everything it has no business touching. But it has the authorship of first-party code. The author is your own customer, building for their own people, and the result is never published to a marketplace. It might run once and vanish, or it might become a tool a whole team leans on, but it stays inside one customer’s walls and is seen by no one outside them.

That combination matters, because getting it wrong in either direction builds the wrong thing. Treat it as fully trusted first-party code and you have handed every customer a loaded gun pointed at every other customer’s data. Treat it as a public third-party platform and you drown a simple capability in marketplace ceremony nobody asked for. What you are building is a private workshop for each customer, stocked with your bricks, walled off from every other workshop, where they and their agent assemble whatever they need.

The Decision

None of the engineering is the slog it would have been two years ago. The isolation boundary, the policy that scopes each tenant, the identity that rides into the sandbox so the code acts as the user, the broker that hands each run its credentials: managed primitives now, on more than one cloud, not infrastructure you stand up per customer.

The product decision in front of all of it is the uncomfortable one. Your users are going to run model-generated code against your product. Whether it runs on your infrastructure or someone else’s is the part you still control.