ElectroBuddy

ElectroBuddy in one sentence

ElectroBuddy is an adaptive electronics apprenticeship for a child-parent pair: the child turns an idea into behavior they can predict, simulate, remix, and explain; the parent learns when to step in and when to step back. GPT-5.6 interprets bounded evidence, while deterministic code—not model confidence—owns pins, power, compilation, and flashing.

Why we built it

Children rarely run out of ideas. They stop making when the distance between an idea and a working object is too long to produce enough cycles of competence and confidence. Electronics makes that distance especially difficult: code, wiring, parts, tools, and safety arrive at once. Beside the child is often a parent who wants to protect the curiosity but does not know enough to help without taking over.

The generic “describe a circuit, generate code, and simulate it” category is already crowded. ElectroBuddy's distinct move is to treat the child-parent pair as the learning unit.

Other tools help people design circuits. ElectroBuddy helps a family grow a maker.

Working today

A public, runnable child journey from intent to an explicit behavior contract, reviewed wiring, prediction, simulation, remix, verification, and a parent-present hardware gate. A Build Week judge flow that exposes the technical and pedagogical architecture without burdening the child experience. Live, authenticated GPT-5.6 photo-and-voice recovery for an unplugged circuit. The model returns visible evidence and one reviewed next action; it cannot approve power, change pins, or control flashing. A deterministic simulator that lets the child change one behavior and replay before spending a model call or waiting for compilation. A frozen ESP32 traffic-light fixture with an exact board allowlist, four size- and SHA-256-locked binaries, pinned flash addresses, reboot, serial monitoring, and ordered behavior evidence. A parent dashboard that turns enjoyment, frustration, help required, and demonstrated competence into mentoring language, the next right-sized project, and the smallest useful purchase. Ten public remix seeds showing the learning runway while clearly separating product direction from verified hardware fixtures.

How it works

Make intent inspectable. The child describes an invention. ElectroBuddy turns the golden traffic-light idea into explicit states, events, timing, and one unresolved ending. Instead of guessing, Buddy gives the decision back to the child. Make cause and effect visible. The child predicts the behavior, runs it on a virtual board, stops the alarm, changes the ending, and replays. Prove before hardware. Compiler, timing, GPIO, non-blocking-loop, resource, and executable behavior checks decide whether a candidate can advance. Recover from physical friction. GPT-5.6 compares an unplugged photo, the child's spoken explanation, and a frozen fixture. It can describe evidence and choose one bounded action; deterministic software keeps the circuit unplugged. Keep hardware states honest. “Simulated,” “compiled,” “installed,” and “observed working” are separate states with separate evidence. Adapt the next confidence loop. The parent records what the child enjoyed, how hard it felt, and how much help was needed. ElectroBuddy changes the next project, parent intervention, and buying advice—not a fixed age label.

How we built it

ElectroBuddy is a Next.js, React, and TypeScript application built with Vinext for Cloudflare Workers and D1. The browser flashing path uses esptool-js. The reproducible submission film is built in Remotion.

Safety-critical boundaries are deterministic. Approved components, voltage and pin constraints, the unplugged-power rule, compiler checks, binary hashes, flash addresses, board identity, rate limits, and ordered physical evidence do not depend on model confidence.

Authenticated model routes keep provider credentials server-side and enforce same-origin requests, fixed models, bounded uploads and outputs, per-user and global limits, timeouts, generic client errors, store:false, and a hashed safety identifier. Child photos and voice clips are not placed in public profiles.

The firmware research harness contains versioned hardware manifests, strict response schemas, adversarial fixtures, frontier-authored golden firmware, deliberately broken candidates, a deterministic 100-point evaluator, host syntax checks, a pinned ESP32 compiler, executable behavior simulations, bounded repair experiments, frozen held-out suites, promotion gates, and cost controls designed around a RM5-per-child monthly target.

How Codex accelerated the work

Codex was an engineering partner across the repository rather than a one-shot code generator. It helped:

turn parent-child learning research into the product and safety contract; build the end-to-end child, judge, and parent flows; author and review stable firmware feature interfaces; create adversarial child-language and missing-hardware cases; construct compiler, behavior, security, economics, and promotion tests; debug the hash-locked browser flashing path; create the reproducible Remotion story, voice direction, captions, and submission guide.

One concrete example captures the workflow: weak-model firmware initially passed some static checks while still containing broken state behavior. Those failures were classified, turned into trusted feature APIs and executable timeline regressions, and then frozen into a held-out promotion protocol. Codex helped build the evidence around the model—not just the interface around the product.

How GPT-5.6 is used

GPT-5.6 powers the live recovery coach. It reasons over a circuit photo plus the child's transcribed explanation and returns a tightly structured response containing visible observations, evidence quality, one reviewed next action, a child explanation check, a parent move, and the immutable KEEP_UNPLUGGED power gate.

GPT-5.6 and Codex also act as an offline teacher: creating and reviewing golden firmware, rubrics, adversarial examples, safety cases, and repair traces used to evaluate less expensive runtime coding models.

The architecture deliberately uses judgment where judgment helps and code where safety must hold.

The result we are proudest of

ElectroBuddy's evaluation system knows when not to ship a model.

In the frozen Batch 4 climate held-out evaluation, the selected low-cost coding model passed only 1 of 3 cases, including after bounded repairs. There were no provider errors and no pinned compilation failures; the remaining defects were genuine safety and state-behavior problems. Promotion correctly failed.

That is the point of the system: not to make every AI answer look successful, but to require evidence before generated work can approach a child's hardware.

Design and potential impact

The child experience is deliberately friendly, visual, and fast. The serious machinery appears as evidence rather than technical burden. Buddy asks before guessing and celebrates what the child noticed or changed—not what the AI produced.

The parent is not merely an approver. ElectroBuddy apprentices the grown-up alongside the child with exact mentoring language, a support contract (“watch me,” “one clue,” or “first step together”), frustration guidance, competence evidence, an adaptive next-build ladder, and inventory-aware purchasing advice.

The initial economics are Malaysia-specific: inexpensive commodity parts, a RM5-per-child monthly price target, and measured model-cost gates. The project has not yet established retention, learning gains, or willingness to pay; the public waitlist and future supervised family pilots are designed to test those assumptions honestly.

Challenges and what we learned

The hardest problem was preserving child agency while keeping safety claims honest. A smooth AI demo can easily blur generated, simulated, compiled, installed, and physically observed states. ElectroBuddy makes those transitions visible and blocks advancement when required evidence is missing.

We learned that the most useful AI role is not unrestricted answer generation. It is translating intent into an inspectable contract, surfacing ambiguity, interpreting bounded evidence, and offering one recoverable next move.

We also learned that the underserved product unit is not the child alone. A parent needs to grow confidence and skill alongside them.

Try it

Open the direct Build Week golden flow:

https://electrobuddy-kids-lab.a-han-uk.chatgpt.site/?judge=1

The behavior contract, wiring, simulator, verification story, parent dashboard, parts lab, and remix garden require no account. Choose Sign in with ChatGPT inside the judge flow to exercise live GPT-5.6 photo-and-voice recovery.

The private repository is shared with the required judging accounts and includes setup instructions, frozen fixtures, compiled firmware artifacts, test suites, production specifications, model-evaluation results, and reproducible video source.

Honest beta boundary

The traffic-light fixture is the only end-to-end hardware golden path. The final physical hardware-in-the-loop run is still required before claiming device validation. Nine other public projects are remixable product-direction seeds, not completed hardware fixtures. General photo-to-project understanding is a prototype input surface; the live GPT-5.6 vision call is used in the bounded recovery coach. Custom firmware generation and compilation are simulated in the public visual flow. Untrusted generated firmware is never compiled or executed on the application host. The selected low-cost model remains blocked from promotion after failing the latest frozen held-out gate. The product has not yet proven educational outcomes or product-market fit.

What's next

Complete and record the physical ESP32 hardware-in-the-loop run. Test the full journey with supervised child-parent pairs. Add a public replay of a sanitized GPT-5.6 recovery result so judges can understand it before signing in. Expand hardware support only when each new fixture earns the same compiler, safety, and physical-evidence standard. Validate whether repeated evidence-backed confidence loops improve persistence and parent mentoring in real families.

Built With

• cloudflare-d1
• cloudflare-workers
• codex
• esptool-js
• gpt-5.6
• next.js
• react
• remotion
• typescript
• vinext