Skip to main content
  1. Describe your idea. For example: I want to build an app that reads vehicle temperature events, flags anything above a threshold and writes alerts to a separate topic.
  2. Vapr creates a draft. The application starts in draft, in its own isolated dev container, with a dedicated Coding Agent. Nothing is deployed.
  3. The Coding Agent asks questions. Which technology to use, which input and output topics, what an event looks like, and how the application should behave, for example whether an alert fires once per breach or on every reading.
  4. It writes the code and runs the tests inside the dev container, then gives you a summary.

​
An example conversation

  • You: I want an app that reads vehicle temperature events, flags anything above a threshold and writes alerts to a separate topic.
  • Vapr: Sounds good. Let me spin up an application for it.
  • Coding Agent: I will develop this in Python. A few questions first: which input and output topics, what does an event look like, and should an alert fire once per breach or on every reading?
  • You: Input is the temperature topic, output is alerts. One alert per breach.
  • Coding Agent: The code is ready and the test cases pass. Here is the summary.
This conversation is an illustration of the flow. Your own conversation will differ.

​
What stays with the application

The agent records the decisions that matter: the technology stack, the input and output topics, the event structure and the expected behavior. Vapr aims to carry them with the application from phase to phase, so the next agent does not ask again.

​
Why a dev container for each application

Each application lives in its own container with its own Coding Agent. Its code, its dependencies and its test runs stay separate from every other application, so one project cannot affect another. The draft waits until you approve the next step.