-
-
Both fixture tests passed in Nebius Sandbox. The patch is waiting for two human approvals.
-
Inspect Nemotron’s proposed fix to payments.py before reviewing it.
-
One workspace for coding requests, proposed changes, and team reviews.
-
A payment retry bug gives users a simple task to explore the full workflow
Why I built CO-AI
When I use an AI coding tool, getting a suggested fix is usually the easy part. Reviewing it takes more work. I still need to understand the change, check what was tested, and explain it to someone else.
I wanted those steps to happen in the same place. That became CO-AI: a shared thread where people can discuss a task, inspect an AI-proposed patch, see its test results, and review it together.
How it works
The demo uses a small Python payment function with a retry bug. You ask the agent to make retries idempotent, and it proposes a change to payments.py. A worker then runs the proposed revision against the existing tests in a disposable Nebius Sandbox.
The result appears alongside the diff. Teammates can inspect the evidence, approve or reject the change, and download a replay of the discussion.
How I built it
I built the interface with React, TypeScript, Vite, and Tailwind CSS. Supabase handles authentication, PostgreSQL storage, and live updates between browser sessions.
The coding agent uses NVIDIA Nemotron through Nebius Token Factory. A separate Python worker picks up saved proposals, sends the files to Nebius Sandbox, and records the command output against the patch that was tested.
What was difficult
The handoff between these pieces caused some of the hardest bugs. A worker could pick up a job before the patch had finished saving. Interrupted runs could stay stuck in the queue. Reviews from different users also needed to be saved without overwriting each other.
I changed how proposals are saved and queued, added worker leases and stale-run recovery, and moved review updates into database transactions.
One smaller issue took a real sandbox run to uncover: the API returned a signal value of -1 for a successful process exit. My adapter initially treated that as a failure. Looking at the actual response helped me fix the interpretation.
What I learned
Testing each component separately helped, but following one request through the whole system revealed problems I had missed.
The first complete live run was a useful milestone: Nemotron proposed the payment fix, the worker ran python -m unittest in Nebius Sandbox, and both fixture tests passed. The diff was then left for human review.
I also checked collaboration in two separate browser sessions, including shared messages, reload persistence, and replay downloads. There is more to build, especially broader repository support and durable worker hosting, but the core request-to-review flow now works on the demo fixture.
Built With
- dcoker
- nebius-sandboxes
- nebius-token-factory
- nvidia-nemotron
- postgresql
- python
- react
- supabase
- tailwind-css
- typescript
- vite
