Prisma Is Building the Stack for the Next Million Products

Prisma should give humans and agents the shortest path from an idea to working software.

Today that path is still broken across code, databases, deployment, logs, previews, and developer tooling. We want those pieces to behave like one system instead of a collection of hand-offs.

That idea has been taking shape across Prisma for a while. Prisma ORM simplified working with data. Prisma Postgres made isolated databases available on demand. Prisma Compute gave applications a place to run.

Together, they let builders and agents move from code changes to a running application without stitching the infrastructure together themselves.

The stack should fit inside the conversation.

Writing the code is easy now, shipping is still a challenge

An agent can already write a feature surprisingly well. The harder part is getting that feature running in a real application.

To do that, it needs a safe place to change data, somewhere to run the app, a way to deploy it, and enough visibility to understand what went wrong. Today, those pieces are spread across different products, so every handoff adds another API, credential, dashboard, and piece of context to recover.

A coworker once described an agent as a very smart intern who joins for a day, reads everything, ships one feature, and then disappears forever. That stuck with me because it captures the problem well.

You cannot assume the next agent remembers yesterday's work. The environment has to provide the right context while the work is happening, without forcing the agent to constantly rediscover the system.

Agents need to be able to access the information they need while they are working.

That changes what good infrastructure looks like.

A feature should move through one continuous loop

Consider a straightforward request: warn a customer before they reach their usage limit.

You describe the outcome, the constraints, and the trade-offs. The agent reads the codebase and data model, changes the schema, implements the backend and UI, runs the application against an isolated database, and deploys a preview where it can exercise the feature against realistic state.

During validation, the traces show that two concurrent requests can send the warning email twice. The agent fixes the race, runs the tests again, updates the preview, and checks the result before raising a pull request with a running environment and evidence that the change works.

That is the unit of work we care about: a working change that has been built, run, observed, and validated.

The Builder still owns the outcome, the judgment, and the trade-offs. The agent takes on more of the implementation and validation. Prisma provides the environment that lets the work continue without losing the thread.

Prisma is bringing that loop into one environment

The pieces already let an agent move much further through the job before a human has to step in.

Prisma Compute lets the agent run what it built. Prisma Postgres gives each task its own database.

Prisma ORM 8 keeps database changes inside the feedback loop.

Prisma Compute lets the agent run what it built

Once an agent has changed the code, it needs a real environment where it can run the application, exercise the feature, inspect the result, and keep iterating. Prisma Compute gives it that place.

Compute runs Bun on long-running servers with fast snapshot and restore, and it follows a usage-based model so spinning up another environment can become part of the development loop instead of a separate infrastructure decision.

The important change is that the agent no longer has to stop after producing code.

Prisma Postgres gives each task its own database

The same principle applies to data. An agent working on a feature should not have to wait for someone to provision infrastructure or share a development database that everyone is afraid to touch.

Prisma Postgres can be created programmatically, so an agent or preview deployment can get an isolated database for the work it is doing. Databases pause and resume automatically, and you pay for the requests made, which makes temporary environments practical instead of expensive overhead.

For the usage-limit feature, the agent can change the schema and test against realistic state without risking production data or colliding with somebody else's work.

Prisma ORM 8 keeps database changes inside the feedback loop

The data model remains one of the most important pieces of context in an application, which is why Prisma ORM is still central to what we are building.

Prisma ORM 8 gives agents faster, safer feedback as they change that model. Safeguards and linting can catch mistakes earlier and prevent destructive actions against a live database, while the ORM itself is substantially faster than Prisma 7 and is now implemented entirely in TypeScript.

In practice, the agent can change the data model, get useful feedback, correct the problem, and continue working without waiting for a human to discover the mistake later.

The real product is the connected loop

Compute, Postgres, and ORM are useful on their own, but the larger opportunity comes from removing the boundaries between them.

A Builder should not need to manually provision a database every time an agent needs an isolated environment, copy connection strings between providers, teach each agent how another deployment platform works, or reconstruct the history of a feature from several unrelated dashboards.

For an individual developer, that means an idea can get much further before infrastructure becomes the job. For a team, more work can arrive for review already running and already validated. For the agent, fewer system boundaries mean less context to reconstruct before it can continue.

This is also why we care so much about coherence. Memory systems and "company brain" products can help agents recover context, but they are optimisations around a more basic requirement: the system itself should expose the right information at the moment the agent needs it.

Over time, we plan to extend this environment with cloud agents, issue tracking, code hosting, and a tighter connection between operational data and the work that produced it. Logs, traces, errors, and customer behaviour should feed back into the next iteration so the next agent can see both the original intent and what actually happened in production.

The goal is a shorter, more reliable path from deciding what to build to seeing it work and improving it again.

We are building this from our own experience

This direction comes from how our own way of building software has changed over the past year.

At Prisma, we removed sprints and traditional teams. Most work no longer starts in an issue tracker, and everyone is a Builder who can pick up the most important work in front of them.

AI is not the only reason for that change, but it has made one thing very clear: writing the code is becoming a much smaller part of the job.

A feature might take twenty minutes to implement, but getting it into the hands of a user can still take much longer. You still need to provision infrastructure, deploy the application, test it in a real environment, inspect logs when something goes wrong, and make another change.

That gap matters even more for agents. An agent can write the code quickly, but if it has to stop and wait for a human every time it needs a database, a deployment, a log, or a safe place to run the application, it cannot complete the job on its own.

We do not think the answer is to teach agents how to navigate more tools, dashboards, and hand-offs. We think those steps should become part of one connected environment, so the agent can keep working from the initial idea all the way to a running, validated change.

That is the stack we want to build.

Start building with Prisma Compute

Prisma Compute is the newest step toward that vision. It works with the coding agents you already use, including Claude, Codex, and Composer, and comes with Prisma Postgres and Object Storage so you can give an agent a real project, let it build against real infrastructure, and run what it made.

Or start from the terminal:

npm create prisma@latest

For an existing project:

npx prisma@latest orm init

There is more on the way. Follow us on X or join the Discord to see the upcoming releases as they land.