Inspiration
A keyboard, a game controller, and a smartwatch, each from a single sentence. That was the goal we wrote down before Cal Hacks.
Building a gadget today takes weeks. You pick parts, read datasheets, wire pins, lay out a board, route it, design a case around it, and write firmware, often without being sure it will all fit. Yet almost every part you need already exists as an open, buyable component with a KiCad footprint and a 3D model. The pieces are all out there. What's missing is the engineer who knows how to put them together, and most people with a great idea don't have one.
"What if you could describe a device and get the real thing?" That question became Tangible Parts, and Bara is the engineer inside it.
What it does
You type or say what you want, like "a wireless split keyboard with an OLED". Bara, our agent with two eyes, walks onto a 3D canvas and engineers it live:
- Real parts only. Every part is sourced, with its licence and provenance shown. Bara never invents a component.
- A routed circuit board. Built in KiCad, autorouted, and checked against design rules.
- A case shaped like the product. A sculpted shell with button wells, a screen window, and port slots.
- Firmware generated for that exact board.
- A bill of materials, plus the reasoning behind every pick.
Then you can explore and change it. Drag the explode slider and the device separates layer by layer. Click a part and it flies into focus so you can ask Bara about it out loud. Say "swap the OLED for e-ink" and the edit is re-checked before it lands. Press Simulate and the firmware runs on a virtual copy of the device, so you can type on your real keyboard and watch the keystrokes, layers, and OLED respond.
How we built it
Engine (FastAPI, Python). A build streams over one WebSocket in stages, each with its own time budget:
- Classify. The prompt becomes a structured spec. If a wrong guess would change the device, Bara asks a clarifying question. Missing details come from the closest archetype, a real open design of that device class.
- Reuse. Search GitHub and open KiCad projects for an existing design. Reuse it exactly, substitute only the failing parts, or compose from scratch.
- Compose. Split the device into function blocks (audio out needs a source, an amp, and a speaker) and resolve each one to a real part. The search goes curated catalog, then stock KiCad libraries, then generated KiCad parts, then LCSC by part number.
- Form. Work out the product's silhouette, thickness, and where hands touch it, grounded on photos of the real product.
- Place, case, board. Parts are packed inside the silhouette on both sides. pcbnew builds the board, Freerouting routes it, and
kicad-cliruns DRC and renders it. DRC failures trigger a re-route with wider rules. - Firmware and render.
Every build then runs checks for I2C clashes, current budget, logic levels, case fit, floating parts, and missing 3D models. Power and track checks use ngspice, and trace widths follow IPC-2221:
$$I = k \cdot \Delta T^{0.44} \cdot A^{0.725}$$
Last comes the identity judge. We render the finished device and ask a vision model whether a person would call it the device that was requested. If the answer is no, its critique drives one repair pass of the form stage.
Anthropic. Claude Sonnet 5.5 at high effort is Bara's brain, making every reasoning call: specs, part choice, form, the vision judge, firmware, edits, and part Q&A. When Bara picks a part, its answer is constrained to the IDs of real candidates that survived filtering, so it chooses but never invents. Cerebras handles a fast first try on simple calls, and keyword rules make sure a build always finishes. We also built most of Tangible Parts with Claude Code, including an overnight loop that ran a 27-prompt suite against the live engine, screenshotted every build, found root causes, and pushed fixes.
Figma. We designed everything there first, driven through the Figma MCP. FigJam held the UX teardown, Figma Design the design system with 21 components and 20+ screens, Figma Make a clickable explode/focus/ask prototype, and Figma Slides our deck. Tokens came straight into CSS with get_variable_defs, and our HTML landing pages went back into Figma with html_to_figma.
OpenAI. Bara listens with gpt-4o-transcribe, hinted with the build's part names, and speaks with gpt-4o-mini-tts in the cedar voice, steered by a written personality prompt. Audio plays sentence by sentence while the next one is prefetched, so Bara starts talking before the full answer is ready.
Frontend. Vite, React, and React Three Fiber in a Figma-style workspace (layers, canvas, properties), deployed on Vercel. The engine runs on a Mac behind a Cloudflare tunnel, and when it's offline the site plays a recorded build instead of breaking.
Challenges we ran into
- Everything came out as a keyboard. Our first engine filled gaps with keyboard-era defaults. A plain "a keyboard" produced 48 keys in the parts list and 16 on the board, and a game controller came out as a 197 × 79 mm slab with buttons in rows. Patching each device would never scale, so we set a rule that no code may branch on a device name. The fix was the archetype, function-block, form, and identity stages.
- Making it look real. Hundreds of parts had no 3D model and rendered as grey boxes. We added fallbacks that borrow a model from a same-package KiCad sibling or fetch one from LCSC by part number, and made placeholders a failing check.
- Real tools are slow. Routing a full keyboard takes real time, and LCSC rate-limits fetches. We cached aggressively, ran independent checks in parallel, and showed live time budgets so waiting never felt like a freeze.
- Figma's limits. The Starter plan cut off our agent mid-build. We moved plans and rebuilt the file in about 20 minutes by replaying saved scripts. Bound colours silently dropped their opacity four times before we found the cause.
What we learnt
"Fix the mechanism, not the device," we realized around 2 AM. Every bug we patched for one gadget came back in another, and every generic fix closed a whole class of failures.
We also learnt that models are strongest when constrained. Claude is excellent at choosing among real options, and deterministic checks catch what it misses. Designing in Figma before writing code saved us more time than it cost, because every new feature started as a frame we could argue about.
Thirty-six hours also taught us to trust what we saw over what we assumed. Our best fixes came from watching a build fail live, staring at a controller that looked like a cutting board, and asking why. We stopped guessing and started screenshotting.
What's next for Tangible Parts
Today Bara takes you from a sentence to a buildable design. Next is closing the loop to a physical object: one-click board orders, printable case files, and a parts cart ready to check out. After that come more device classes, live multiplayer editing so a team can build one device together, and a Bara that gets better with every build people make.
Software has had compilers for decades. Hardware is next, and the next great device won't start in a CAD file. It'll start as a sentence.
Built With
- anthropic
- cerebras
- claude
- claude-code
- cloudflare
- fastapi
- figjam
- figma
- figma-make
- freerouting
- github
- gpt-4o-mini-tts
- gpt-4o-transcribe
- kicad
- lcsc
- ngspice
- openai
- python
- react
- react-three-fiber
- three.js
- typescript
- vercel
- vite
- websockets
Log in or sign up for Devpost to join the conversation.