Hexode v3.0: AI-Native Collaborative Cloud IDE
An AI-native collaborative cloud IDE for writing, running, and discussing code directly in the browser.
On this page
Overview
Hexode is a browser-based, cloud-backed collaborative IDE designed to bring AI-native development and real-time collaboration directly into the browser.
It enables multiple users to collaboratively edit multi-file projects, run code, and consult an integrated AI coding assistant without any local installation. Hexode also serves as a zero-setup browser coding playground tailored for technical interviews and DSA practice.
Why I Built Hexode
"I wanted a development environment that lived entirely in the browser: no local setup, a place to write and run code, practice interview and DSA problems, collaborate with other people in real time, and use AI inside the same workflow."
Architecture
- LevelDB is used for CRDT persistence.
- Clerk provides authentication.
- Vercel hosts the frontend.
Real-Time Collaboration
Monaco serves as the primary editing surface, while Yjs provides CRDT-based shared document state. File contents are represented as Y.Text, and project files are tracked using a Y.Map. Synchronization is transported over WebSocket, with Awareness providing real-time presence and cursor state. Chat messages are also persisted within the shared Yjs document.
Crucially, the server implements the Yjs binary synchronization and awareness protocol directly using y-protocols/sync, y-protocols/awareness, and lib0 encoding/decoding.
By avoiding the standard y-websocket server package, the HTTP and WebSocket state live together in the same Node.js process. This means the server already has access to the live Yjs documents, allowing the AI endpoint to access that state without requiring the browser to resend the full code context.
Hard Problem Callout
The Synchronization Bug: Solving the Initialization Race Condition
In the original approach, a simple setTimeout was used before initializing a project. This risked overwriting the state before the CRDT synchronization had fully completed.
The final approach waits for the Websocket/Yjs provider to emit a 'synced' event. By combining provider.on('synced') with a check to ensure yFilesMap.size === 0, the project initializes only when appropriate. This is a correctness and race-condition fix, ensuring reliable document state.
setTimeout(() => init(), 1000)provider.on("synced", ...) + yFilesMap.size === 0Multi-File Code Execution
Hexode supports multi-file projects, but Judge0 receives a single source_code string. This central mismatch requires a language-specific transformation pipeline.
For Java, public classes are renamed to Main, packages are stripped, access modifiers are handled, and Main collisions are managed.
For JavaScript, a custom require() shim is injected, resolving relative modules through an in-memory registry.
For C, C++, and Python, files are merged via ordered concatenation.
HexodeAI
When a user sends a message, it hits the /api/ai/chat endpoint. After rate limiting, the server reads the current Yjs document state directly from memory. It builds the context (capped at 2000 characters) and sends it to the Gemini API (gemini-3-flash-preview).
The response is streamed back via SSE (Server-Sent Events) and consumed by the client using a ReadableStream for incremental React rendering.
The AI endpoint enforces limits of 5 requests per minute and 20 requests per day. Additionally, a keyword-based query firewall blocks unrelated queries before they even reach the Gemini API.
Engineering Challenges
1. CRDT Initialization Race Condition
Problem: Initializing default project files could overwrite remote state if synchronization hadn't finished.
Approach: Listen to the Yjs provider's 'synced' event and check if the document is empty before initializing.
Result: Removed the initialization race that could overwrite synchronized project state.
2. Multi-File Project Execution
Problem: Executing multi-file code against a single-string execution API (Judge0).
Approach: Implement language-specific merging pipelines (e.g., custom require shims, class renaming, concatenation).
Result: Enables multi-file execution across 5 supported languages.
3. Manual Yjs WebSocket Protocol
Problem: Need to share HTTP and WebSocket state without running separate processes.
Approach: Implement the Yjs binary sync protocol directly on the Express server using lib0 and y-protocols.
Result: Unified server state, enabling the AI to read live documents from memory.
4. SSE Mid-Stream Error Handling
Problem: HTTP status codes cannot be changed once headers are sent during a Server-Sent Events stream.
Approach: Stream specialized error event payloads that the client interprets and renders gracefully.
Result: Robust UI error states even when the LLM API fails mid-generation.
5. Monaco/Yjs Re-binding
Problem: Switching files in the IDE left lingering CRDT bindings on the editor instance.
Approach: Destroy the previous MonacoBinding and rebind on file name changes.
Result: Clean transitions between files with correct cursor and edit tracking.
Technical Decisions
Manual Yjs Server
Sharing the HTTP and WebSocket server provides direct access to the server-side document state in memory.
Sync-Event Initialization
Prevents premature default initialization that would corrupt incoming CRDT state.
Server-Side Yjs Context for AI
Avoids sending the full document contents over the network from the browser with every AI request.
Derived WebSocket URL
Deriving the WebSocket URL from the API URL reduces frontend deployment configuration surface.
Trade-offs & Limitations
- In-memory Yjs docs prevent straightforward horizontal scaling.
- Authorization is currently client-side only.
- The Judge0 CE public API is used, which has rate and SLA limitations.
- There is no automated test suite.
- The codebase is JavaScript without TypeScript.
- The terminal is simulated rather than a true PTY.
- There is no dedicated conflict-resolution UI, as Yjs handles CRDT conflicts automatically.
What I Learned
Real-time systems are fundamentally synchronization problems.
CRDT state changes the way persistence and initialization must be reasoned about. You can no longer just load state from a database; you have to merge it securely.
Multi-file AI context is an architecture problem, not simply 'calling an LLM API'. Designing the system so the server has access to the live documents completely removes the client payload burden.
Reliable execution requires designing around the constraints of the execution service.
What I Would Build Differently Today
"If I started Hexode today, I would make the platform AI-native from the architecture level rather than treating AI as an assistant added to an existing IDE. I would also choose Judge0 from the beginning instead of going through the earlier Piston-based approach."
Technology Stack
| Technology | Role |
|---|---|
| React | Frontend UI library |
| Vite | Frontend tooling and bundler |
| Monaco | Code editor surface |
| Yjs | CRDT for real-time collaboration |
| WebSocket | Real-time synchronization transport |
| Node.js | Backend runtime environment |
| Express | Backend API and WebSocket host |
| MongoDB Atlas | Primary database for user and project metadata |
| Mongoose | MongoDB object modeling |
| LevelDB | Persistent storage for CRDT document updates |
| Gemini | LLM powering HexodeAI |
| Judge0 | Code execution engine |
| Clerk | User authentication |
| Framer Motion | UI animations |
| Tailwind | Utility-first CSS styling |