PRISMA — AI CASE STUDIES

Background and challenge

Prisma’s engineering work crosses repositories, services and runtime environments. Coding assistants could write code in an individual repository, but they lacked product context and the relationships between systems. The team identified a coordination problem alongside the coding problem: specifications, architecture decisions, conventions and accountability were often held by people rather than available as durable, machine-readable documentation. [1] [2]

The AI-powered approach

Prisma described agentic engineering as a supervised method, not unattended “vibe coding.” Engineers own architecture, tradeoffs and acceptance criteria. AI agents break work into bounded tasks, produce changes and run verification. Its Drive process organized work around projects with stages named Plan, Execute, Review, Ship and Delivery Review. A Maker owned a product or technical outcome end to end, while agents performed many implementation tasks. [2] [13]

Implementation workflow

When prototyping the Prisma 8 architecture, engineers first investigated feasibility and then documented subsystem responsibilities before delegating major implementation work. Agents could run tests, linters and type checks after code changes, retry failed work, and prepare reviewable diffs. Cross-repository context was stored in an internal documentation monorepo called Ignite; local repository notes remained close to the code. No evidence supports claiming a specific LLM family was used for every task. [1] [2]

Observed outcomes and limitations

Tyler Hogarth reported seeing agents resolve some issues that might otherwise take an engineer roughly half a day in under an hour. This is an internal observation of selected issues, not a controlled benchmark or organization-wide average. More revealingly, Prisma’s June retrospective acknowledges that the first approach became over-specified and costly to maintain. The team began testing leaner skills with clearer inputs, outputs and quality standards. Review loops remained important. [2] [3]

Practical lesson: agents benefit from explicit architecture, feedback loops, repository context and accountable human owners. A rigid orchestration process can itself become technical debt when underlying models improve. Prisma’s experience supports disciplined experimentation, not blind autonomy.

Customer background and challenge

Co.dev is an AI-first application builder aimed at founders, creators and people without conventional software-development skills. A user describes an app in ordinary language and the platform generates interfaces and backend behavior. But generated code has to store user accounts and application records in a reliable database. For nontechnical customers, manually acquiring connection strings, configuring schemas and debugging authentication would undermine the promise of prompt-to-app development. [4]

Why Prisma, and what was implemented

According to Prisma’s July 2025 case study, Co.dev integrated the Prisma Postgres Partner API to provision databases as part of its app-generation flow, and supported Prisma through an MCP server. Prisma Postgres appears as a database selection for the end user rather than requiring a separate infrastructure setup. The partnership included technical collaboration between the teams; this is a named product integration, not a generic product demo. [4]

The explicit Prisma schema gives an AI agent a shared representation of models and relationships. Co.dev’s co-founder Andrew reported that the schema allowed the app to be regenerated or reverted without losing track of the intended database structure. He also reported that authentication worked in a single integration attempt after unsuccessful or awkward alternatives. These statements describe the customer’s experience, not a universal comparison benchmark. [4]

Documented workflow

Prisma’s published user-facing flow is intentionally compact: describe the application, select a database, optionally add MCP-connected integrations. Behind that interface, Co.dev has to align application code, data models and its provisioning system. The source supports calling this a live integrated product workflow; it does not disclose the exact LLM provider, every internal API call, infrastructure topology or production incident rate.

Outcome and evidence boundary

The direct outcome is removal of database setup steps from the nondeveloper’s journey. Andrew’s feedback supports smoother schema recovery and simpler authentication. There are no publicly disclosed verified values for median setup time, paid-user retention, database migrations per day, or reduced developer headcount. The strategic point is that AI-generated applications require reliable, machine-manageable infrastructure and clearly specified data contracts.

What SiteGPT needed

SiteGPT lets organizations build AI chatbots using their websites, support material and other content. Although its customers interact with language-model responses, the business also requires ordinary application data: accounts, content ingestion, records about sources, query activity and other backend state. SiteGPT’s founder Bhanu Teja described frustration with provisioning decisions, unclear scaling costs and database operations responsibilities. [5]

Database selection and migration

Prisma’s case article says SiteGPT was moving away from FaunaDB following its announced shutdown. Bhanu was familiar with Prisma ORM and wanted managed Postgres with usage-based billing and less infrastructure administration. Prisma staff helped with the migration; the customer attributed confidence in the transition partly to that hands-on support. The article reports a fast and low-risk migration, without publishing a detailed migration runbook or independently reviewed availability figures. [5]

AI and infrastructure roles

The case explicitly refers to customers with content collections of 30,000 or more pages, and to embedding-related processing. It does not disclose the exact foundation model, vector index architecture or complete retrieval pipeline. The diagram above is a conceptual division of responsibilities rather than a verified diagram of the entire SiteGPT stack. Prisma stores and serves application data; it is not identified as the model generating chatbot responses.

What actually changed

Bhanu reported simpler cost management, no need for manual server sizing, and closer integration between his existing Prisma ORM workflow and hosted Prisma Postgres. The article’s section heading refers to 10 million-plus database operations daily; in the interview text, Bhanu states more than 8 million queries daily. Queries and operations may be defined differently, and the source provides no reconciliation or independent telemetry. Both statements are preserved rather than recast as a single precise performance statistic. [5]

Takeaway: infrastructure simplification can matter as much as inference quality in an AI SaaS. The story documents a founder’s database-operating experience, not a controlled study proving that Prisma improved the chatbot’s response accuracy, revenue or customer retention.

Business problem and project context

Ali Fatemi, who runs a boutique software agency, was exploring an unusual outreach workflow: rather than pitch a business an abstract website service, create a preliminary site tailored to that business first and invite the owner to inspect the live result. Code generation alone could not accomplish this. To be useful, the AI-generated files needed hosting, approval and shareable links without an agency employee manually deploying every site. [6]

AI-generated assets, human approval and deployment

Ali supplied Claude with Prisma documentation and CLI instructions so the agent could automate code generation and deployment. The workflow searched a target market—spas in Vancouver—researched businesses, generated tailored sites and prepared them for human approval. Prisma Compute supplied the hosting destination and command-line feedback. The article says many of the generated pages lived within a single Prisma application, which matters: “50 websites” is not necessarily 50 isolated deployments or paying customers. [6]

What was demonstrated

By morning the system had generated approximately 50 sites, according to Prisma’s account of Ali’s experiment. The story shows a dashboard for reviewing outputs and explains that the agent could execute deployment steps and receive a working URL. The customer described deployment setup as simple. This is an important demonstration of the handoff between AI code generation and operating infrastructure. It is not proof that all 50 outputs were commercially acceptable, individually deployed, secure, accessible, or delivered to business owners. [6]

Limits and wider meaning

The project was explicitly early-stage; the article describes a future step of deploying the generator itself so it would no longer depend on Ali’s laptop remaining online. It does not report revenue, client responses or adoption rates. A human approval gate appears in the described workflow, so the project should not be misrepresented as completely autonomous commercial website delivery.

Takeaway: infrastructure with predictable CLI commands and concise feedback lets coding agents turn prototypes into reviewable live URLs. Agencies can explore this approach, but still need to evaluate factual accuracy, rights, security and quality before contacting customers.

What the demonstration tried to prove

Prisma’s Aidan McAlister published a hands-on example in May 2025 using an AI assistant to assemble a Next.js e-commerce application. The article identifies VS Code Copilot with Claude 3.5 Sonnet as the AI setup used in that specific walkthrough. Its purpose was to test whether agent-driven development could establish a relational database, write application logic and correct problems without the author hand-writing the application. [7]

Prisma’s concrete role

The assistant scaffolded a Next.js project and configured Prisma ORM. Through the Prisma MCP server it created a Prisma Postgres database and connected the application. The AI defined Category and Product models with a relational link, produced seed data, created filtered product retrieval and built a client-side cart. Prisma Studio was used to inspect data. Unlike a generic capability page, the article shows commands, schema definitions, selected generated code and screenshots. [7]

Implementation workflow

Instructions were broken into small architectural specifications, then concrete implementation steps. The team had to distinguish server components from client behavior; the generated cart used browser local storage rather than assuming that all customer state belonged in Postgres. This is a useful example of two different persistence decisions within the same app.

What went wrong and what worked

The agent initially produced invalid image URLs and a React client/server integration error. The humans supplied the failure messages, after which the agent made corrections. The published outcome was a working learning prototype with rendered products, category filtering and cart interaction. Prisma’s article does not disclose an automated evaluation suite, deployment availability SLA, production users or verified monetary savings. [7]

Safety lesson: successful agent database access does not mean it should hold unrestricted credentials. Destructive database operations, access to personal data and production migrations need scoped permissions and explicit review. The tutorial illustrates MCP integration; Prisma’s later credential and approval controls provide the operational governance context. [9] [10]

The engineering bottleneck

Small errors and polish tasks interrupt engineers despite being individually simple: a bug in a settings page, a repeated Sentry exception or a tiny API response change. Investigating them can cost more attention than making the correction. Tyler Hogarth’s June 2026 Gremlin article describes an internal attempt to isolate this class of work so product engineers can focus on architecture and higher-judgment projects. [8]

Architecture and orchestration

The system accepts scoped tasks from Sentry issues and from human instructions in Linear or Slack. Mastra prepares context, authenticates, controls workflow and provides an execution boundary. OpenCode acts as the sandboxed code-editing agent. The model provider is explicitly exchangeable; Prisma did not announce a singular proprietary foundation model powering Gremlin. [8]

Output, verification and limitations

The final artifact is a pull request, not an automatically merged production change. It should state what triggered the work, what changed, what checks were run and what uncertainty remains. This makes Gremlin compatible with existing CI, code ownership and review conventions. Prisma’s author says a bounded investigation that might take 45 minutes can sometimes shrink to five; the article does not publish a representative sample, median latency or audited failure rate.

Gremlin is explicitly not positioned as a universal autonomous developer. It is not suited to large architecture changes or ambiguous product decisions. Its distinction from the larger agentic-engineering case is operational: it focuses on interrupt-driven, small changes, while Drive and Maker concern the full project lifecycle. That separation explains why these can be studied as different internal implementation patterns without treating them as independent enterprise customers. [8] [2]

Takeaway: a reliable AI development system is more than a model; task boundaries, credentials, context, validation and review determine whether useful changes reach a safe handoff point.