Most "pair programming" tools stop at screen share. You watch a colleague scroll, you narrate a fix, they type it. That loop is slow, and it is why remote reviews drift into "just send me the branch".
The room model
A DEVAE room has three things that can be shared: your voice, your screen and a terminal. The terminal is the one that changes behaviour. When a reviewer can run the test suite themselves, the conversation moves from "try adding a null check" to "I ran it, the failure is in the fixture".
How it is built
Voice and screen share are WebRTC between peers. Presence and chat ride on realtime channels, so joining a room is one subscription, not a dedicated server per room. When two networks cannot connect directly, traffic falls back to a TURN relay we run ourselves; that fallback was the single biggest reliability fix of the beta.
The terminal is a pseudo-terminal bridge in the desktop app. The host decides whether it is read-only or interactive, and can revoke it at any point.
What we learned
- Read-only terminal is the default people want. Interactive is used for tests and builds, rarely for editing.
- Rooms with a terminal shared are shorter. People stop describing and start running.
- Latency matters more than resolution. We tuned for the former.
Rooms are invite-only by default and nothing inside one is public unless you post it. Open one from any project with a single click, or devae room join <name> from the CLI.
