CanItWork

CanItWork takes a plain-English description of a system and builds an interactive model of it. You run it, break it, and compare fixes by what they actually do and what they cost.

Agents propose. The simulator decides.

Inspiration

Ask a model to design a circuit, a hospital, or a fleet of drones and it will hand you something that looks finished. You cannot tell whether the pump would hold the soil in range, whether the adder sums, or whether the database survives Friday's traffic. We wanted a place where the model has to face a simulator that can say no, and where a fix is kept only if a replay shows it works.

What it does

You describe a system. CanItWork works out what kind of system it is, designs it, checks it, and runs it in a simulator built for that kind of system. If it cannot model the request, it says so.

Thirteen kinds of system, each with its own simulator and 3D view:

Electronics. From a battery and a bulb to logic chips and microcontroller projects: voltages, currents, gates, op-amps, motors, sensors, and a real breadboard. A circuit too big for one board continues onto the next. A 16-bit calculator is 20 chips and 341 wires across 4 boards, and the build guide names every hole.
Software. Traffic, capacity, latency and cascading failures, with circuit breakers, rate limits, and autoscaling that takes time to boot.
Databases. Query cost, indexes and locks, plus the classic outages: an exhausted connection pool, lagging read replicas, and N+1 queries.
Operations. Warehouses, queues, power grids, water networks, supply chains, hospitals, factories, airports, and call centers. Every person in these scenes is a 3D character: shoppers walk between the tills, patients wait in the ER, riders step into an elevator in a glass tower whose floor count comes from the prompt.
Autonomous fleets. Drones, rovers, and robot teams with roles, batteries, and radio range.

The landing page runs real designs behind the headline: a breadboard, a power grid, a supply chain, an airport, and a supermarket. Each one is a live simulation, not a picture. Below it, every kind of system has its own panel of verified examples, like a 2-bit calculator, a self-watering planter, a drone swarm, a Friday-night ER, and an office tower's elevators. The calculator wires a 74HC86, a 74HC08, and a 74HC32. Click the switches and the LEDs show the binary sum, and the trace says 16 of 16 behaviour tests pass. These examples already passed every check, so they open instantly and cost nothing.

Every number says where it comes from. Each stat is labelled as measured by the simulator, added up from a price list, or estimated by the AI, so you always know which ones were checked. The Steps tab shows what each agent decided, right under its name.

Every design has a monthly bill. Software, databases, hospitals, power grids, warehouses and fleets show what they cost to run each month, with line items and each line's share. Circuits are the exception, because their parts are paid for once.

Break it, and a recovery council proposes fixes. The simulator replays each one and ranks them, and each fix says what it adds to the bill: four more ER beds are +$100,000/mo, while batching an N+1 query costs nothing extra. When fixes tie on the replay, the cheapest one wins. On the planter, burning the pump dries the soil out of its 30–70% band, and replacing the pump wins because the replay measured it. If no proposal beats doing nothing, the report says so.

Bring your own system. Paste a SQL schema, a Docker Compose file, or a Kubernetes manifest, and it becomes a running model. Click the database inside a software design to open its schema as its own linked simulation, then step back out.

Edit, save and share. You can drag, duplicate, and delete parts in the 3D view. The validator runs the edited design before it replaces the one on screen. Save a system under a name: My systems shows them as cards with a picture, and a system marked Listed appears on the landing page beside the verified examples.

Share copies a link of about 2 KB, or a QR code drawn in the browser. The link holds the environment, the seed, and the event log. Opening it replays the run and recomputes a SHA-256 of the result. Change one event in the link and the page reports that the hash does not match. The same hash is anchored on Solana: the share panel links to the transaction, so anyone can check when the result existed without trusting our server. The link can also open a live session: everyone sees the same run, and a break, a fix, or a switch flip shows up for the whole room.

How we built it

The pipeline is Interpreter, Architect, Validator, Reviewer, Simulator, Red Team, then a recovery council. Simulators are deterministic: the same environment, seed, and event log always replay to the same result. The server relays the action log, and each browser replays it.

TypeSafe's Jev picks which simulator should handle the request.
Gemini writes the design, repairs it, and reviews it against the request.
Prune carries every Gemini call.
Swarms attacks the design and proposes fixes.
Auth0 decides who can spend a build.
Tiger Data keeps saved systems and live rooms.
Solana timestamps every shared run's proof hash.
Vultr hosts the app.

The validator does not grade prose. In electronics it runs the design at each sensor's extremes and rejects anything that burns out, never turns on, or misses its target. In software it checks that the design keeps up with its traffic without retry storms. A failed check comes back as a trace the architect can act on. When a repair still leaves something small, such as a loop in a flow or a missing radio relay, each domain settles it in code without calling a model.

Costs come from the simulator, not the model. Each component kind has a monthly price, plus a price per unit of work where the work itself costs money, such as fuel per megawatt or freight per pallet. To price a fix during an incident, the simulator replays the incident with the fix applied and compares the two bills. The AI's own effort and cost notes are shown too, but labelled as an AI estimate the simulator doesn't check.

The app is TypeScript: a shared simulator core, a Hono API, and a React Three Fiber frontend. The browser and the server run the same simulators. Designs that pass every check are cached under the exact prompt. The cache holds 88 verified designs across all 13 kinds of system. On the latest full eval pass, 90 of 100 general cases pass and 73 of 76 software and database cases pass. A design that ships with a check still failing counts as a fail.

We used React, Three.js, react-three-fiber, Hono, Vite, Vitest, and the APIs above, with 3D models by Kenney (CC0). The simulators, validators, agent pipeline, and 3D scenes are ours.

How we used Cursor and Grok Bot

Cursor was the coding agent for the whole team. It is named as co-author on most commits. Those commits are the electronics simulator and the breadboard, the queue and flow domains, the 100-case eval, live sessions, Auth0 sharing, Tiger Data, and the UI. People stayed the authors. Cursor wrote the code with us.

Grok Bot ran the workflow around that code. It rotated the API keys, reviewed pull requests, ran the tests, handled conflicts, and merged the ones that passed.

How we used the Gemini API

Gemini is the Architect, the repair step, the Reviewer, the Analyst, and the chat editor.

Architect: a person describes a system in plain English, and Gemini writes a structured design that one of the 13 simulators can run.
Repair: when the simulator rejects the design, Gemini gets the failure trace, such as which gate is wrong or why a transistor never switches, and rewrites the design up to two times.
Reviewer: reads the finished design next to the request, so "nine robots" cannot come back as three and a 16-bit calculator cannot come back as one gate.
Analyst: after an incident, explains the ranked fixes in plain words. Its notes on effort and cost are labelled as an AI estimate, next to the price-list figure the simulator calculated.

Gemini proposes. A design that still fails its checks is refused.

How we implemented the Swarms API

Swarms runs the Red Team and the Recovery Council.

Red Team: writes failure claims the simulator can actually run, and each one comes back Confirmed or Refuted with a measurement. Burning the XOR chip on the calculator, with 0 + 3 on the switches, drops working outputs from 100% to 49%.
Recovery Council: after a break, the council proposes fixes, the simulator replays each one, and the ranking is the measurement. Each fix is priced, so the council's answer is "this works, and this is what it costs."
Design council (optional): three Swarms architects, Literalist, Engineer and Builder, design the same request in parallel. The simulator scores the three designs and builds the winner.

How we implemented the Prune API

Every Gemini call goes through Prune, and the Usage tab shows the receipts.

Cache off: Prune's response cache is off on purpose, because semantic matches were ignoring numbers in the prompt.
Per-minute limit: waited out and retried through Prune.
Daily quota or rejected key: calls go direct to Gemini for ten minutes, then Prune is tried again.

How we used TypeSafe's Jev

Jev makes the first call on every request: what kind of system is this? It picks a domain and reports how likely each of the 13 simulators is to model the request.

Code routes on those probabilities. A confident answer goes straight to that simulator's Architect, so most builds skip a model call just to classify the prompt.
Unsure cases go to Gemini to decide between the closest domains.
If nothing fits, the app refuses and names the closest domain, instead of forcing a request into a simulator that cannot model it.

How we used Tiger Data

Saved systems, the Listed gallery, and live sessions are stored in Tiger Data's Postgres.

A saved system is the environment, the seed, the event log, and its provenance hash, under a short link the owner controls.
A live session is the same log plus the room's clock, written a second after each change, so a server restart picks the room back up.

The simulators are deterministic, so Tiger Data only has to keep the log: every browser replays it and lands on the same state. The top bar shows a Tiger Data chip once the database answers.

How we used Auth0

Auth0 is what lets the agents run in public.

Spending: a new build calls Gemini and Swarms and costs real money. With sign-in required on the public deploy, the server checks the Auth0 token and turns a guest away before any model is called, with a Sign in button where the build would have been. Examples and shared links stay free.
Hourly limit: counts a signed-in person by their Auth0 account, so a new network does not reset it and a whole hackathon venue does not share one allowance.
Saving and sharing: saving a system needs an account. A saved system can be public, listed on the landing page, private to its owner, or shared with named emails. A run shared with an email only opens once that address is verified.
Live sessions: everyone sees the same run, and signed-in people show up by their own name on each break and fix.

How we used Solana

Every shared run's proof hash is written to Solana, so anyone can check when a result existed, and that it has not changed since, without trusting our server.

What gets written: when someone shares a run, the server sends a memo transaction through Solana's memo program containing canitwork:<SHA-256 of the run>. Each hash is written once.
What you see: the share panel shows "Anchored on Solana" with a link to the transaction on Solana Explorer. Anyone can read the memo there and compare it with the hash the link recomputes when it replays.
Why it matters: the share link already proves nothing in it was edited, but only if you trust our site. The chain adds a public record of when the result existed, kept by a network we don't control, and not even we can change it afterwards. It fits the rest of the app: you don't take the AI's word for a design, and now you don't have to take ours for a result.
What it doesn't claim: Solana proves when a result existed and that it hasn't changed. Whether the design works is the simulator's job.

It runs on devnet, where a memo is free. A failed anchor never blocks sharing: the link just doesn't appear.

How we used Vultr

The public app is one Docker container on a Vultr Cloud Compute instance running Ubuntu, with 2 vCPU and 4 GB. The simulators run on that machine, and the models stay remote, so the box does not need a GPU.

API keys live in an env file on the server and never go into the image, including the wallet that pays for Solana memos. Caddy terminates HTTPS. Auth0 and the hourly limit sit in front of Gemini and Swarms, so a public URL cannot drain the credits.

Base44

Students at Miami Dade design circuits, club projects, apps, and campus systems, and then find out they fail when someone builds them. CanItWork lets someone describe the thing in plain English and watch it run: a breadboard for a class, the schema from a databases course, the line at a campus security desk, the elevators in a tower, a Friday-night ER. They can break it, see the measured fix and what it costs, and share the run with a classmate. The examples are free to open, so anyone can try a working system before they spend a build of their own.

Challenges we ran into

The first calculator prompt came back as an Arduino with four buttons. The model had no vocabulary for gates or a breadboard, so we built logic, chip state, and a breadboard layout that the simulator and the 3D view share. Chips straddle the channel in datasheet pin order.

A semantic cache once returned five robots when the prompt asked for nine. The verified cache is exact-match only, and it is re-checked before use, so a seed that no longer passes is dropped. The Reviewer now reads the request beside the finished design, so a shrunken design is sent back.

Software designs melted under their own retries. Sizing a service for the traffic it saw during a retry storm only made the storm bigger. Capacity is now sized from the demand the design would see with infinite capacity and no retries. Rate-limited requests also count as rejected rather than retried.

People couldn't tell a measured number from a guessed one. The simulator's figures, the price list's totals, and the AI's estimates all looked the same on screen. Every number now says which of the three it is.

The Red Team was attacking circuits in the wrong state, so a burned chip sometimes changed nothing visible. Claims can now set the inputs first, and the attack is judged where the damage shows.

A burst of Gemini calls through Prune hit a per-minute limit. That looked like the day's quota, so Prune was skipped for ten minutes, and every call fell onto direct keys that were already exhausted. Now a short wait is retried through Prune, and only a daily quota benches it.

Swarms bills runs that fail. Two models crashed on their side and were still charged, so the Red Team and the council stay on a model we have seen complete.

Solana's public faucets closed. The test network no longer hands out free tokens to a program, so the server's wallet couldn't fund itself. The wallet now lives in the server's env file, funded once by hand, so it survives every redeploy.

Accomplishments that we're proud of

A 2-bit adder you can flip with the mouse, with 16 of 16 sums proved in simulation before the page will show it. A 16-bit calculator on 4 breadboards passes 65535 + 1.

A planter whose soil moisture is a simulated quantity. Change the sensor reading and the pump responds. Burn the pump and the recovery is ranked by replay.

Triple the traffic on a chat app and watch requests fail. The council's fixes come back ranked by replay, each with what it adds to the monthly bill.

A live room where a break on one screen is the same break on every screen, saved in Tiger Data so a restart picks the session back up.

A shared result anyone can check without trusting us. The link proves it wasn't edited, and Solana proves when it existed.

The app will refuse a design, and it will say that doing nothing is the best fix when the replays agree. That was the point.

What we learned

A confident design is not a working one. The useful AI step is the one a deterministic check can accept or send back.

Exact numbers in a prompt are the first thing a shortcut will smear. Caching, routing, and repair all had to treat "9 robots" and "30 to 70 percent" as load-bearing.

A fix that works is only half an answer. The other half is what it costs, and the simulator can measure that too. When the AI does guess, the honest move is to say so on screen.

The same rule applied to writing the code. The agents drafted large parts of the simulators and the UI, and the commits still have a person on them, because someone had to read the diff, run the suite, and decide what was true.

What's next for CanItWork

An open verifier: the simulator core as a package anyone can run, so npx canitwork verify <link> replays a shared run and checks its hash against the Solana memo, without our server.
A small hardware controller whose buttons break and fix parts in the live scene.
Importing more of what teams already have, such as Terraform plans and OpenAPI specs, so a real stack can be tested before it ships.

Watch the 1:22 demo · GitHub · MIT licensed