Vibecoding started out as something you do on your own. You tell an AI agent what you want, it writes the code, you look at what came out and tell it what to change. Andrej Karpathy put a name on it in early 2025 and a year later a lot of developers do some version of it every day.
The trouble starts when there's more than one of you. Two developers with two AI agents on the same repo get two versions of the same feature, and they won't match. The product owner and the people who run the process haven't seen either version, because the only place the requirements exist is in the chat history of the two developers. Nobody is looking at the same picture.
Some people call the fix multiplayer vibe coding. We'd describe it as collaborative visual modeling, with AI doing the modeling and the building: one model of the business process and the requirements that everyone involved can see, correct and agree on, which then becomes the spec the AI agents build from. Most of the spec-driven tooling that shipped this year skips the collaborative modeling part and alignment.
Spec-driven development is what the industry settled on. You write down what the system should do before anything is generated, and the AI agents build from that file instead of from whatever you typed last. GitHub Spec Kit, AWS Kiro, OpenSpec, Tessl, Antigravity, all the big vendors shipped some flavour of it this year. The spec lives in version control next to the code, and the AI agent reads it before it writes anything.
This is a different thing from vibecoding, even though the same AI agents do the work. With vibecoding there is a prompt and there is code, and nothing in between that a human can look at and approve. With a spec there is a file that people can read, comment on, version and disagree with before any code exists.
The problem is who gets to write the spec. In most of the tooling the spec is a markdown file in a repo, which suits developers fine and leaves everyone else out. The people who know the process, the ones who can tell you an order can be partially cancelled after picking but not after invoicing, don't open GitHub.
If the spec is going to hold the rules of the business, the people who know those rules have to be able to read it and point at what's wrong. A markdown file doesn't give them that. A picture of the business process does. In the Event Storming workshops we run, the disagreements come out as soon as the process is laid out step by step in front of the whole room.
Everyone assumes they agree on how a process works until they see it visualized. Then it turns out two teams have been using the same word for different things, or a step everyone assumed happens doesn't. You want to find that out in a workshop, with the people who disagree looking at the same board, and not after an AI agent has generated a working implementation of the wrong assumption.
That is what Qlerify is built for. Several people work in the same canvas at the same time, and if the team already has a Miro board or a PDF of process notes, the AI drafts a first version from that for the room to correct. The collaborative canvas contains the domain model and the domain model generates and updates the spec file. They are one object, not several static documents that drift apart, so a developer and a domain expert are looking at the same source of truth even though one reads it as a visual blueprint and the other as a JSON file. Nothing goes to the repository until someone has looked at the blueprint and approved it. The AI agent ends up building from a model the business has already signed off on, not from whatever someone typed into a chat, which is the difference between this and vibecoding.
The blueprint is for the domain experts. The AI agent needs the same information as a specification file, so Qlerify turns the blueprint into a domain model and exports it as JSON. It's the usual software engineering artifacts based on battle tested DDD principles: aggregates, commands, the events each command emits, read models, entities and a Given-When-Then acceptance criterion for each rule the business stated. That's enough for an AI agent to work out the schema, the API, the handlers etc. It doesn't say which database to use, which is deliberate - The domain model stays tech stack agnostic in the Qlerify tool.
Before the file leaves the tool, validation goes over the bounded context and lists what it finds as major issues, minor issues or notices. The major ones are commands with no parameters, two domain events with the same name, or a read model linked to an entity that has since been deleted. It can't tell you about a rule that's simply missing, which is what the discovery workshop was for. Then you look at the exact file that will be written, approve it, and push it. If there's already a version in the repo you get a diff.
After that, you point whichever coding agent your team uses at the repo and run the agent skill:
/code-generation
The AI agent reads the spec, runs a pre-flight check, asks which stack you want, and builds. Tell it the stack you actually run rather than letting it choose. A software component of normal size comes out in around fifteen minutes with a passing test suite, and each of those tests maps to a sentence a domain expert wrote.
Anyone can open a spec file. Whether a domain expert can review it is another matter. To spot that a command is missing an input, or that an acceptance criterion covers a case that never happens in practice, they need to see where it sits in the process, and a list of aggregates doesn't give them that. In Qlerify the process map and the domain model are part of the same model and the file is exported from it, so the review happens on the canvas, by the people who know the process, before the AI agent builds and again when the code changes.
For the second part there's another agent skill:
/sync
It goes both ways. Change the code and it reads the new entities, endpoints, events, etc. back into the model. Change the model and it spots the drift and hands over to generation. Treat what it pulls back from the code the way you'd treat a pull request, because not everything a developer put in a handler belongs in the domain model. The file is also reversible: import it into Qlerify and you get the workflow and the domain model back.
Two habits keep this working. Commit the updated spec in the same pull request as the behaviour change, and push again after every modelling session.
Most of the above is mechanics, and none of it is hard. The hard part, and the part most spec-driven tooling doesn't try to solve, is getting the people who run the process to agree on the model before anything is generated. They're not developers and the spec is a file in a repo, so they never get asked. Put the model somewhere they can see it and the disagreements get settled in the workshop instead of in production. You keep the speed of AI coding. What you add is control over what gets built and a record of it: any handler traces back to a command someone approved, any failing test traces back to a sentence a domain expert wrote, and whoever has to answer for the system later, in an audit or a compliance review, can follow the same trail.
If you want to see the whole flow, the spec-driven development guide goes from workshop model via pushed spec to generated app. Or start a trial and try it on one of your own use cases. There's no limit on how many people you can invite and collaborate with.
