Say it. Build it. Test it for real.

VibeBB is Vibe BreadBoarding: describe what you want to build in natural language, and AI designs the circuit board, enclosure, and firmware. Pass or fail is decided by deterministic gates and real-hardware evidence — not by vibes.

The Idea

What is VibeBB?

Vibe Coding let developers fully give in to the vibes and forget that the code even exists. VibeBB brings that same conversational loop — see stuff, say stuff, run stuff — to hardware prototyping: boards, enclosures, and firmware. As Collins Dictionary's 2025 Word of the Year shows, the experience of stating intent in natural language, looking at the result, and giving the next instruction is spreading.

The AI is the primary designer: it handles requirements elicitation, part selection, circuit design, board layout, enclosure design, firmware, manufacturing data, and iteration driven by manufacturing and real-hardware feedback. Mass-production quality and certification are not assumed — the goal is a working prototype, as fast as possible.

No schematics required

Just as the breadboard made it possible to try as you think — no soldering needed — VibeBB lets you simply say what you want to build. Part selection, circuit design, board layout, enclosure, firmware, and manufacturing data all follow from the conversation. Not drawing a schematic is the hardware counterpart of not reading the code in Vibe Coding.

Heavy verification, hidden

VibeBB doesn't mean design or verification is light — it means the heavy verification is hidden from your hands. Simon Willison distinguishes true Vibe Coding, where the artifact is never reviewed, from AI-assisted work that includes review. VibeBB moves the reviewer's role from humans to deterministic gates and real-hardware evidence.

You judge the result, not the artwork

You stay the owner of the requirements, and can step in as a reviewer or make direct fixes when needed. What you check isn't a schematic or copper artwork — it's whether the board that arrives actually works and actually fits in its enclosure. Feedback goes straight back into the next design revision.

The Experience

The VibeBB Loop

Long desk studies take a back seat. The default cycle is to build first, check on real hardware, and turn the next change around immediately.

01

Describe

Say what you want to build in natural language. The AI turns the conversation into verifiable requirements.

02

AI designs, gates verify

The AI proposes parts, layout, enclosure, and firmware. Deterministic gates decide pass or fail.

03

Build & try

Manufacturing data goes out; a real board and enclosure come back. You power it up and see whether it works and fits.

04

Feed it back

Measurements and real-hardware findings flow back into the design inputs for the next revision. Then the loop runs again.

“Fully give in to the vibes, embrace exponentials, and forget that the code even exists.”
— Andrej Karpathy, on Vibe Coding (Feb 2025). VibeBB carries this loop into physical prototypes.

Why Trust It

Vibes propose. Gates decide.

From the requirements dialogue through manufacturing and real-hardware feedback, the agents proceed in parallel, exchanging opinions and requests with one another. Firmware is delegated to OpenHands' native software development capability, so board, enclosure, and firmware are designed and verified within the same interactive flow.

Reviews advise, gates decide

Each stage produces machine-readable and visual projections, which SDK subagents and vision review on a best-effort basis. Findings go to the fix loop as natural-language text; reviews hold no pass/fail authority.

Human review is optional

By default the AI runs end to end, from requirements to manufacturing data. What you verify is not schematics or artwork, but whether the delivered board and enclosure actually work and fit.

Re-verifiable, not repeatable

Unlike LLM-only CAD, the point isn't producing the same solution every time — it's that the produced design can be re-verified afterwards by deterministic measurement and independent parsers re-reading the output.

Rationale on record

Every value the AI chose — parts, placement, trace widths, silkscreen, stackup, design rules, net classes, safety boundaries, dimensions, pin assignments — is stored in the same git change as the design input, with the reason, rejected alternatives, driving requirements, and provenance.

Missing rationale is detected

Attributes that express design decisions are classified as required or exempt; anything in neither class becomes unclassified. When a record no longer matches its subject, the reason must be recorded again.

Traceable revisions later

“Why this part?”, “why this trace width?”, “why this dimension?” stay answerable to a different reader, several revisions on. Rationale explains; it never decides pass or fail.

Across Conversations

It learns your conventions

VibeBB writes what it learns while working into OpenHands' persistent memory and reads it back at the start of the next conversation, so proposals can start from the conventions of previous designs without the same explanation being repeated every time.

Parts and footprints

The parts and part numbers frequently used in the repository, and how footprints and stackups are chosen.

Values that passed

Clearance and trace-width values that actually passed, plus know-how about enclosure fastening and wall thickness.

Your preferences

Points repeatedly flagged by silkscreen or review, and the user's own design preferences, accumulating with use.

Persistent memory is disabled by default. To use it, enable Persistent memory in the OpenHands Local GUI settings. Memos assist the working context; pass or fail is decided by the deterministic gates and evidence.

Future Vision

Toward “printing” boards at home

VibeBB's premise — cheap and fast manufacturing — can go further. If printed electronics matures, boards could be made on the spot like a home 3D printer, shortening “build and try” from days to tens of minutes, and VibeBB would truly approach breadboard speed. The same applies to enclosures, brackets, and mechanical parts: 3D printing and CNC quoting, DFM, and ordering services become procurement channels on par with board fabs.

Soberly speaking, in-home manufacturing of simple one- and two-layer boards is already real (desktop milling, conductive ink printing). High-density multilayer boards, plated through holes, high current, and certified mass production will remain the domain of professional fabs for the time being. Conductive filament, conductive paste, and 3D-MID/LDS/IME are blurring the boundary between enclosure and circuit, but they presuppose verification of conductivity, solderability, contact resistance, and durability. VibeBB builds this future in from the start.

DRC with mechanical and material profiles

Minimum trace width and spacing, tool diameter, ink or filament resistivity and current capacity, via method, substrate, and curing/sintering conditions — verified as a separate profile within the same framework as fab-facing DRC.

Material-aware electrical analysis

Trace resistance, voltage drop, and temperature rise are estimated from measured material data rather than by assuming copper foil.

Hybrid manufacturing dispatch

From the same design graph: a locally prototyped version that can be built at hand, alongside a conventional fab mass-production version for when density or current exceeds what local methods can deliver.

Closed-loop inspection

Alignment, continuity, and resistance measurements are fed back into the design, and the quirks of each machine and material lot are accumulated as knowledge.

Room for structural electronics

Layout is not fixed to planar rigid boards. A design graph that does not preclude non-planar circuits — including enclosure surfaces and embedded wiring — is preferred.

Personally fitted wearables

Take a 3D body scan as a mechanical constraint and produce non-planar, stretchable circuits on the spot. When shape changes from person to person, schematics as the source of truth break down — so VibeBB regenerates manufacturing data every time from a design graph of requirements, constraints, and rationale.

This is a vision-level future direction, not a promise about the current implementation scope.