How I Vibecoded a Backend (and Frontend) on InterSystems IRIS

I wanted to try vibecoding a real backend + frontend setup on InterSystems IRIS, ideally using something realistic rather than a toy example. The goal was simple: take an existing, well-known persistent package in IRIS and quickly build a usable UI and API around it — letting AI handle as much of the boilerplate as possible. Here is the result of the experiments.

Choosing the Data Model

For this experiment, I picked the Samples BI Demo. It’s good for vibecoding:

• Contains several well-designed persistent classes
• It’s widely known and easy to install
• It already works nicely with IRIS BI

Installation is trivial using IPM:

zpm "install samples-bi-demo"

Once installed, I verified that everything worked correctly in IRIS BI. For convenience and a better browsing experience, I also installed DSW (DeepSee Web). and made sure that data is there and all works perfectly - here is the screenshot of installed data viwed by DSW:

Sampels Bi Demo shows the sales of an imaginary company HoleFoods that produces and sells products with Holes. The setup goes with HoleFoods package of persistent classes:

• Product
• Outlet
• Country
• Region
• Transaction

Quite a match for a CRUD demo.

Vibecoding Setup

Here is my "vibecoding with IRIS" setup:

• VS Code
  • InterSystems ObjectScript extension
  • OpenAI Codex plugin
• Docker
• A very basic ObjectScript project template from Open Exchange

That’s it. No heavy scaffolding, no custom frameworks.

The UI Recipe

The architecture I followed is straightforward and repeatable:

1. A frontend UI
2. Communicating with IRIS via a REST API
3. Defined by a Swagger (OpenAPI) specification
4. Implemented natively in InterSystems IRIS ObjectScript and IRIS SQL.

Generating the Swagger API

In this approach, OpenAPI spec or Swagger is the middleman that both the frontend UI and IRIS understand. IRIS 2025.3 supports Swagger / OpenAPI 2.0 so I asked Codex to generate a CRUD-style API for one of the persistent classes — starting with Product. To make this easier for the AI, I exported the source code of the persistent classes from my local IRIS instance and shared them with Codex.

I decided to begin with a simple requirement:

A page to create, edit, list, and delete Products

To support this, I asked Codex to:

• Generate a spec.cls Swagger definition
• Make Product derive from %JSON.Adaptor
• Follow the conventions and preferences described in my AGENTS.md file
  (basically accumulated “wisdom” from previous interactions)

I also chose a base API path:

/holefoods/api

Codex generated the class:

Holefoods.api.spec After compiling it, IRIS automatically produced two additional classes:

• Holefoods.api.disp
  Always generated by IRIS and responsible for endpoint routing and request/response plumbing
• Holefoods.api.impl
  Where the actual business logic lives - it goes with method stubs initially.

This is one of those IRIS features that feels almost magical when paired with vibecoding. Being thoughtful (or maybe cautious 😄), Codex asked:

• Whether the web application should be registered in module.xml
• What dispatch class name should be used

I confirmed both — which means the API is automatically created when IRIS starts - and it added web app setup in module.xml so the web app appears in IRIS with next docker rebuild or manual module load:

<CSPApplication
Url="/holefoods/api"
DispatchClass="HoleFoods.api.disp"
MatchRoles=":{$dbrole}"
PasswordAuthEnabled="0"
UnauthenticatedEnabled="1"
Recurse="1"
UseCookies="2"
CookiePath="/holefoods/api/"
CorsAllowlist="*"
CorsCredentialsAllowed="1"
CorsHeadersList="Content-Type,Authorization,Accept-Language,X-Requested-With,session"
/>

Security Setup

Anyone who has worked with IRIS knows that web applications + security can sometimes be… eventful. So I explicitly asked Codex to generate:

Holefoods.api.security.cls

, following the instructions in AGENTS.md

This class introduced the required security adjustments to enable the API development phase to run smoothly, but also clearly and easily escalatable to any higher security level, mostly focusing on all the security relations to a special role that is given to an application and thus projected to everyone who is logged into this application.

Implementing the API

Next step: implementation.

I asked Codex to fully implement the CRUD logic inside:

Holefoods.api.impl And it just did. At this point, everything was ready to test.

Testing with Swagger UI

To quickly validate the API, I installed Swagger UI:

zpm "install swagger-ui"

Important note (learned the hard way earlier):
Swagger UI requires a _spec endpoint, which must always be implemented in the impl class. Once that’s in place, Swagger UI works perfectly.

After restarting IRIS, I could see the full API definition exposed — and test it interactively.

The request:

GET /holefoods/api/products

returned some meaningful data. At this stage, the backend was essentially “done”.

Vibecoding the Frontend

With a working API and a clean Swagger spec, building the frontend becomes trivial. You have options:

• Ask Codex to generate the frontend
• Use tools like Lovable to scaffold a UI directly from the spec

I chose the latter — and within minutes had a working local UI connected to IRIS. After some testing (and fixing a small issue with deletion), the full round-trip experience was there: UI → API → IRIS → persistent storage. Here is the screenshot of the first result (It can be viewed locally at http://localhost:5174/ ):

Adding Unit Tests (Because Adults Do That)

The last missing piece was unit testing. I asked Codex to generate:

HoleFoods.api.Unittests.cls

covering all endpoints defined in the Swagger spec.

Once generated, I added the test class to the module configuration so tests could be run via IPM with this line

<UnitTest Name="/tests" Package="HoleFoods.api.tests" Phase="test"/>

so tests can be called as:

zpm "test esh-vibe-back-demo" 

And just like that, all API endpoints were covered and visible in the IRIS unit test portal:

Later I asked to add /transactions endpoint and Codex introduced code into spec class, has built the implementation in impl and introduced unit-tests. And has built a UI the result of which you can see here:

Final Thoughts

InterSystems IRIS + Swagger + vibecoding looks like a powerful and effective combination.

Yes, the result is a prototype —but almost real, and testable, built shockingly fast.

Here is the repository.

Leveraging AGENTS.md and conducting open source examples with best practices on dealing with the IRIS backend can boost the leverage of IRIS as a robust backend for comprehensive full-stack applications.

The coachable code-generation capability of OpenAI Codex or Claude Code opens the opportunity of building superperformant backends on IRIS, as the nature of any SQL on IRIS backend is no other than code generation over the globals traversing. 

P.S.

This article is written by a human and reviewed by AI for better English :)

P.P.S.

And as a bonus track - built the UI on Lovable too - so you can play with the online demo: