2026TauriRustReactDev Tools

VibeStudio

A native desktop environment for editing, compiling, and previewing spec-first collaborative software. The local IDE for vibes.

If VibeHub establishes vibes as the new primitive for version-controlled software, VibeStudio is how you actually work with them. It's a native desktop application built with Tauri 2 and React that treats .vibe/features/*.md files as the primary artifact, not an afterthought bolted onto an existing code editor.

The Problem with Existing Tools

Today's development environments are built around code. VS Code, JetBrains, vim: they all assume you're editing source files, running terminals, setting breakpoints. When AI handles the coding, these tools become the wrong abstraction. You're writing specs in one window, copy-pasting them into a chat in another, then manually applying the generated code back into your project. VibeStudio collapses this into a single workflow: edit the spec, compile, preview.

Spec Editing as a First-Class Experience

The sidebar presents your features as a navigable tree, built from the directory structure under .vibe/features/. Creating a feature with a path like payments/checkout automatically nests it under a payments folder. The tree is constructed on the frontend from the flat list returned by Rust:

typescript

// .vibe/features/auth/login.md → folder "auth", file "login"
function buildTree(raw: VibeFileEntry[]): FeatureNode[] { ... }

Every operation goes through Tauri's IPC layer via invoke. There are no HTTP calls during editing; file I/O is handled entirely by Rust commands:

Command	Description
`list_vibe_features`	WalkDir `.vibe/features/` up to depth 3
`write_vibe_file`	Write with `fs::create_dir_all` for parent dirs
`delete_vibe_file`	`fs::remove_file`
`rename_vibe_file`	`fs::rename` with parent dir creation
`read_remote_config`	Read `.vibe/remote.json`
`run_project`	Spawn dev command, stream stdout/stderr via Tauri events
`compile_vibes`	Call model REST API → parse JSON → write generated files

Local Compilation

The same two-phase agentic compilation pipeline that runs on VibeHub's cloud infrastructure runs locally in VibeStudio. You select your model, hit compile, and watch the agent generate code from your specs in real time. Generated files are written directly to your project directory.

What makes this powerful is the feedback loop. Edit a spec, compile, see the result immediately. No git workflow, no PR review, no deployment. Just the tight iteration cycle of editing intent and observing the output. When the feature looks right, you push it to VibeHub for collaboration.

Run and Preview

VibeStudio reads .vibe/project.json (generated by the agent during first compilation) and uses it to run your application directly from the desktop app:

json

{
  "language": "typescript",
  "framework": "next",
  "install": "npm install",
  "dev": "npm run dev",
  "build": "npx tsc --noEmit",
  "test": "npx vitest run"
}

The run_project command spawns the dev server and streams stdout/stderr via Tauri events. If there's no project manifest yet, it falls back to heuristic detection: Python project? python main.py. Node project? npm run dev. Zero configuration for the common case.

Sync with VibeHub

VibeStudio is designed to work seamlessly with VibeHub's collaboration model. Pushing and pulling use different strategies under the hood:

push_branch_to_backend: computes an intent diff against the base branch using git2 (libgit2 bindings for Rust), then POSTs to /api/projects/:owner/:repo/prs
pull_from_remote: GETs /api/projects/:owner/:repo/features, overwrites local .vibe/features/, commits via shell git
merge_branch_locally: uses git merge --no-ff through the shell (git2's merge API has too many edge cases for reliability)

The key insight is that the diff you review on a push isn't a code diff. It's an intent diff. You can see exactly what changed about the feature description, at the level of human-readable specification. Code is generated after the spec is merged, not before.

Why Native?

We built VibeStudio as a native app (Tauri 2, not Electron) for a reason. The file I/O is real filesystem access through Rust, not sandboxed browser APIs. The process management for run_project uses native OS process spawning. The git integration uses libgit2 bindings. These aren't things you can do well in a browser tab. Tauri's architecture (Rust backend, web frontend) means the app is 5-10x smaller than Electron while being equally capable, shipping on macOS, Windows, and Linux from a single codebase.

CLI Companion

For terminal-native workflows, VibeHub ships a Go CLI:

bash

vibe init my-app          # scaffold .vibe/ directory
vibe clone owner/repo     # fetch specs from VibeHub
vibe import --repo .      # extract vibes from existing codebase using AI
vibe compile              # generate code → typecheck → test → validate
vibe check                # validate without generating (safe for CI)
vibe read                 # print a summary of the project's vibes

vibe compile runs the same four-phase pipeline locally: code generation, type checking, tests, and requirement validation. Exit code 1 on failure; "partial" status when the average requirement score falls below 75%.

The Bigger Picture

As the way we interact with code continues to evolve, and as AI handles more of the translation from intent to implementation, the tools we use need to evolve too. VibeStudio is an attempt at what that looks like: a development environment built for the workflow where you describe what you want, and the machine figures out how to build it. The most accessible feature language is human language, and VibeStudio is designed to make working with that language feel native.

View project →Source code →