Every record in your app deserves a name.
Not its database ID. Nobody on a building site is ever going to say "did you see what record 287bc4d1-9fae-41d0-ae8a-3fa97c83f127 needs sign-off on today?". Nobody will remember that. Nobody will type it into a handover note. Nobody will quote it to the site manager over the radio.
Even sequential IDs blur quickly. "DEF-4152" and "DEF-4158" in the same conversation, and people are squinting at the site plan trying to remember which one was the cracked beam on level three and which one was the botched render out the back.
Docker solved this years ago - every container it launches gets a name like peaceful_einstein or cranky_hopper. Heroku did it. Gfycat turned it into their brand. There's a reason it's a pattern worth stealing: the name isn't the ID, it's a handle - the thing humans actually use to refer to the thing. Memorable in a way a sequence number never will be.
The requirement
We were building a construction project management system recently, and the defects module was becoming the place where the team spent most of their day - inspections, rework, sign-offs, photos, sign-offs being rejected, inspections again. Everyone was drowning in IDs.
The client wanted exactly what Docker had stumbled into twenty years earlier: a memorable nickname on every defect record, so conversations, WhatsApp threads, and handover notes could refer to things by name rather than an opaque ID.
The rules:
- Three words. Adjective, Animal, Noun.
- Server-side computed. Not editable through any client, including the API.
- Immutable after creation. Once a defect is called Brilliant Badger Blueprint, it stays that way forever.
- Unique across all defects on the project. No two defects share a name.
I wrote one prompt in the Designer.
The prompt
Nothing clever. Just the requirement:
"I need a 3-word auto-generated field on Defects. Format: Adjective Animal Noun (e.g. 'Brilliant Badger Blueprint'). Hidden from forms. Computed server-side. Immutable after creation. Guaranteed unique. 100 × 100 × 100 = a million-combination namespace. Nouns themed around construction - blueprints, scaffolds, foundations."
The assistant came back with three 100-word arrays - adjectives, animals, construction-themed nouns - spread thoughtfully across the alphabet. A snippet of SQL that takes the record's UUID, SHA-256 hashes it, pulls three bytes out, and uses each one modulo 100 to pick a word from each array. A field definition on the Defects resource with the right flags set: is_immutable_expr: true, is_unique_expr: true, and a generated_value_expr of type code, configured to run on create, applied serverOnly.
That was it. One prompt, one apply, one deploy. Every new defect now landed with something like:
- Brilliant Badger Blueprint
- Relentless Raven Reinforcement
- Thoughtful Tiger Trellis
- Luminous Leopard Lintel
A million-combination namespace. More than enough for this project many times over.
Why the Designer can do this in one prompt
This is the bit worth paying attention to, because it's a general story about how xMS is different from "you but with an AI assistant".
A memorable-nickname feature on a blank codebase isn't one prompt. It's a small project. You have to figure out:
- Where the logic runs (client? server? database trigger?). Wrong answer: client, because it can be manipulated.
- When it runs (on insert? update? read?). Wrong answer: on every read, because performance.
- How uniqueness is enforced (application check? database constraint? both?). Wrong answer: application-only, because race conditions will bite you.
- How the field is protected from edits (can the user see it? change it? can an admin change it? what about the API?). Wrong answer: "we'll handle that in the UI", because the API still accepts writes.
- What happens in migrations and backfills (existing records without a name?).
Each question has a right answer and eight subtly wrong ones. On a blank codebase, the AI is working through every one of them as an application-specific decision - and inconsistently, because those decisions entangle with whatever else is in the repo.
In the xMS Designer, those questions are already answered by the platform itself. generated_value_expr has a behavior, an applyOn, and an applyAt. is_immutable_expr already handles "this field can't be changed after creation". is_unique_expr already compiles into a database constraint. The platform knows what to do with those flags. The AI's job is just to describe the intent.
Which means the actual work of the prompt was the part that was genuinely creative: picking the right three hundred words.
The generalisation
We've written about this in another shape already - the difference between AI writing into a blank codebase and AI writing into a structured platform. Memorable nicknames are a small, delightful example of the same principle.
On a blank codebase: "let me think about immutability, uniqueness, server vs client, timing, race conditions, migrations…" and maybe a working feature at the end of the day.
In xMS: "here are three 100-word arrays and the SQL to pick one from each via SHA-256 of the ID" and a working feature in five minutes.
The AI is the same. The speed difference is entirely about what it's writing into.
Why this matters
We love this feature. It's a tiny thing - nobody will sign a contract because their defects are called Brilliant Badger Blueprint - but it's the kind of tiny thing that makes a system feel built for humans. The people on the project refer to defects by name. They remember them. They type them into WhatsApp without having to look anything up.
We could build this in a morning rather than a week not because our team is faster than anyone else's, but because our platform already knows how to handle generated fields, server-only computation, immutability, and uniqueness. The AI gets to spend its cycles on the interesting part (what makes a good memorable name?) rather than the undifferentiated parts (how do we stop this field being edited through the API?).
When we say xMS is AI-native, this is the kind of thing we mean. The AI isn't writing an application from scratch. It's filling in the blanks of a platform whose primitives already understand your intent.
Brilliant Badger Blueprint, signing off.