How We Build Hardware Products in the AI Era

Shenzhen, October 9, 2026 — Shenzhen MeToclaw Technology Co., Ltd. hosted a delegation of UbiComp/ISWC scholars at its Shenzhen office. Tom Yao, founder and CEO, received the delegation and gave a talk titled "How We Build Hardware Products in the AI Era."

The talk did not open on technology trends. It opened on a single question, put on the screen first: "AI can write code — so why can't it build a piece of hardware?" He then said:

October 9 — Tom Yao presents to the visiting UbiComp/ISWC delegation.

For the visiting scholars, the first exhibit was the meeting room itself.

The room where the session took place runs on MeToclaw's own smart-classroom products and systems — large-format display, lecture capture, live sound reinforcement, lighting control and temperature control — all supplied by the company. The conversation about how to build hardware products took place inside one.

The delegation was organised around the Human-Computer Interaction and Pervasive Computing Laboratory at Tsinghua University (Prof. Yuanchun Shi) and the School of Software at Nankai University (Prof. Haining Zhang), joined by senior researchers in ubiquitous and wearable computing from Northeastern University, Lancaster University, the University of Washington, KIT and Georgia Tech. The visit formed part of the industry programme around UbiComp/ISWC 2026, held in Shanghai on October 13–15.

The three-part structure: the three products we already ship · which cost line AI removes · and what we actually want to build.

The talk was built as three questions in sequence: how we develop, three products already shipping, and a judgement plus the thing we actually want to build.

The sharpest part was its answer on cost. AI, he argued, flattens the fixed cost of software development; it does not flatten the marginal cost of hardware — materials, SMT, assembly and test are paid on every single unit. The consequence is not cheaper hardware but a moved bottleneck: from "can we write it?" to "can we verify it, and can we change it back?"

In the first section he split wasted cost into two bills: one on the screen (rebuilding context, retry loops, manual shuttling of information, absent verification) and one on the bench (every new project means re-rigging instruments, re-running cables, re-locating probe points, re-confirming power-up sequencing). Neither produces any new information — and both are paid again every time.

4.1 The people counter: making a "solved problem" hard again

The counter runs at the door of a hotel room and counts locally; only the state — occupied or not — leaves the device. Its value lies not in counting but in integration: joined to the hotel's existing property-management system, it can shut the air conditioning off once a guest leaves, notify housekeeping, and leave a trace for safety.

He spent more time on why it is difficult: the space is one or two metres deep, so the field of view forces a wide-angle lens and a person's apparent size varies several-fold; people crowd together and detection boxes overlap heavily — "where is the box" and "how many are there" are problems of very different difficulty; and counting is a discrete metric, so a detector may be a little wrong while a count that is off by one is off by a hundred percent.

4.2 PURA Neo: each side correct, together wrong

A substantial part of the session took place around the hardware itself.

PURA Neo is the only machine in the company that has gone from product definition all the way through OTA iteration — every one of the nine stages walked by the team itself — and it is in production. He used it to describe a concrete class of problem: cross-boundary consistency.

The firmware states that a certain command is 114 bytes long — and by its own definition, it is. The older app version sent 82 bytes — and by its own protocol, it was correct too. Each side is self-consistent; together they do not agree. Chasing that by hand means reading two codebases and two tables.

He was equally direct about the boundary: there is no online model on the device itself — a fixed set of brewing parameters plus environmental compensation, and a single advisory card in the app. The generative part (a device digital twin, supply chain and consumables, customer service) sits in the cloud backend.

4.3 T9: turning "does it sound right?" into something measurable

T9 is an audiobook player for blind users, fully offline — what someone listens to is private. This edition is Vietnamese, and it was delivered on September 30, 2026.

Rather than the product, he described a real regression and its fix: after multiplying the training data, quality went down. It was the automated evaluation that caught it first — a human ear adapts, and by the two-thousandth sentence it stops noticing. Following the score back led to a parameter in the training script that was named "freeze" but never actually froze the encoder. It was fixed before delivery.

Discussion after the talk, with Chinese and international scholars taking part.

Forty minutes of talk and twenty minutes of open discussion were planned; in practice, much of the discussion happened around the hardware, with scholars asking about implementation details while passing the products around.

The final section was a personal judgement, and a thing that does not exist yet. Before it, he gave numbers that can be checked — this line has run for fourteen years, serving blind and visually impaired users throughout.

The bus guidance system and T6 are two different products. T6 is the predecessor of the T9 delivered this month — and T6 had no minority languages, which is precisely why T9 had to be built.

What he wants to build: for a blind person to be able to go out alone and complete a journey — satellite positioning with RTK outdoors, UWB where satellites cannot reach, the surroundings expressed through sound rather than coordinates, and AI making the judgement calls.

Two things are still in progress, and he drew the line explicitly.

First, multi-card on-device LLM deployment: putting 3B–27B class VLM/MoE models on site on a multi-card cascade platform, for digital humans and local RAG. His own dividing line: anything that must return inside 100 ms stays on the device; 100 ms to 1 s goes to local compute; only beyond 1 s is allowed into the cloud. This work is ongoing.

Second, letting AI touch a whole machine: a device under development that "sees" via screen capture, "acts" via simulated keyboard and mouse, "listens and speaks" through a microphone array and speakers, with the cloud model making decisions — and the machine under test needs no modification at all. Alongside it, a workstation still on the drawing board.

Shenzhen MeToclaw Technology Co., Ltd. designs and manufactures intelligent hardware for the AI era, spanning on-device vision and acoustic modules, consumer electronics and health-monitoring devices, and smart-classroom systems — with end-to-end capability from product definition and hardware/software design through pilot runs to volume delivery.

The company has built hardware for 18 years, has worked on Rockchip platforms since 2012, is headquartered in Shenzhen with two further R&D and delivery sites, and has accumulated a portfolio of core boards (SoMs) and standard boards. Its platforms cover the RK1828 + RK3588, RV1126, RK2218, RK2108D and RK3576 families, with −40 to 85 °C operation and EN50155, CE/FCC certification capability — and a full IDH path from SoM to evaluation board, pilot run and volume production.

Media contact — Marketing Department, Shenzhen MeToclaw Technology Co., Ltd. · Tel: +86 755 2721 6756 · Email: tomyao@bestom.net · www.metoclaw.com · www.bestom.net