Software Is Free. Hardware Is the Wall.

In February 2026, Andrej Karpathy vibe-coded a custom cardio tracking dashboard in about an hour — reverse-engineering his Woodway treadmill’s cloud API to pull real-time data into a custom UI. His takeaway was broader than fitness: the concept of an “app store” — a fixed catalog of discrete apps you browse and download — is becoming obsolete. When an LLM agent can generate a custom application in seconds, tailored exactly to your need, why search through a store for the closest approximation?

But Karpathy also identified the bottleneck: 99% of products still don’t have AI-native interfaces. His treadmill had no open API. He had to reverse-engineer a proprietary cloud protocol just to read his own data. The software was trivial to generate. The hardware was the wall.

His vision of the “one-minute future” — where you say “help me track my cardio for the next 8 weeks” and the system just works — requires hardware to cooperate. And hardware, overwhelmingly, does not.

10 Euros and a Relay Board

Developer Andre Grandoch took Karpathy’s idea further. He wanted his AI to actually control the treadmill — adjusting speed based on heart rate, running interval programs. His treadmill had Bluetooth and WiFi, but both were locked to the manufacturer’s ecosystem. No API, no open protocol.

His workaround: a webcam pointed at the LCD screen for the AI to read via OCR, and an Arduino with a relay board wired to the physical buttons for the AI to “press.” Total cost: about 10 euros. He built most of it while walking on the treadmill.

The most powerful AI in history can write any program in seconds — but needs a relay board and jumper wires to adjust a treadmill.

The Gap: AI Got Smart, Hardware Stayed Dumb

We’re living through an asymmetric revolution. Software has had its breakthrough — LLMs, AI agents, vibe-coding, instant generation of custom tools. The marginal cost of producing software is approaching zero.

Hardware hasn’t had an equivalent moment.

Devices ship in 2026 with Bluetooth radios but proprietary protocols. They have WiFi but no API. They build human-readable dashboards instead of machine-readable endpoints. A treadmill from 2022 behaves like it was designed in 2005 — not because the engineering is bad, but because the design assumption is wrong. These devices were built for a world where the user is a human tapping a screen. They weren’t built for a world where the user might be an AI agent sending commands.

The result is absurd: the most powerful AI in history can write any program in seconds but can’t adjust a treadmill without a relay board and jumper wires.

Hardware Is the Interface to Physics

This is where Norbert Wiener becomes relevant again. In The Human Use of Human Beings (1950), he argued that intelligence — whether biological or mechanical — requires three things: sensing (perceiving the world), deciding (processing information), and acting (changing the world).

AI has the deciding part covered. LLMs can reason, plan, generate code, make judgments. But sensing and acting both depend on hardware. Sensors are AI’s eyes and ears. Actuators are AI’s hands and feet. Without them, AI remains trapped in the digital world — a brain in a jar, powerful but unable to touch physical reality.

Grandoch’s hack is a perfect illustration of this. His system has all three layers:

  • Sensor layer: webcam reads the display, BLE reads the heart rate monitor
  • Decision layer: AI agent runs the control loop, compares current state to target program
  • Actuator layer: Arduino triggers relays that press physical buttons

That’s Wiener’s complete feedback loop, assembled from $10 in parts because the treadmill manufacturer didn’t provide an interface.

What “Smart” Should Mean in 2026

The word “smart” has been co-opted. In 2015, a “smart device” meant: companion app, cloud dashboard, subscription plan. The device talks to its own server, and the server talks to you through a proprietary app. The intelligence lives in the cloud, locked behind a walled garden.

In 2026, “smart” should mean something different: my AI agent can talk to this device directly. A local API. An open protocol. Machine-readable data streams. The intelligence doesn’t need to live in the device’s cloud — it lives in the user’s agent. The device just needs to be a good sensor, a good actuator, or both.

Wearable recorders like Plaud, Omi, and Mobvoi TicNote are early examples. They’re starting to expose integrations with third-party tools (Slack, Notion, Apple Health). But most hardware is still locked down, still designed as if the only entity that will ever interact with it is a human finger on a touchscreen.

Where This Leads: One Device, Infinite Software

Here’s where it gets interesting. If software can be generated on demand by AI, and hardware is the stable interface to the physical world, then the product logic flips. You don’t build a device for a specific app. You build a device that can host whatever software the user needs right now.

Imagine a small, portable hardware device — microphone, optional camera, BLE/WiFi, a small local model for edge inference. The hardware stays the same. What changes is the AI-generated software layer, customized per user, per context:

A student clips it on during a lecture. The device records the class in real time. Afterward, the AI generates structured notes organized by topic, extracts key concepts and formulas, and cross-references them against the course’s exam question bank. It knows which topics the student has already mastered from past quiz performance and which areas need work — then generates a personalized study plan with practice problems ranked by relevance. Before an exam, the student says “quiz me on this week’s material,” and the device generates questions calibrated to their specific weak points, adjusting difficulty in real time as they answer. Over a semester, the system builds a map of what the student knows and doesn’t know — a tutor that has sat through every lecture alongside them and remembers everything. No two students get the same output from the same class.

A sales rep wears it to client meetings. The AI analyzes talk-time ratios, identifies objection patterns, tracks which pitches lead to conversions versus stalls, and generates coaching notes after each call. The device is invisible — a small clip, not a phone on the table.

A language learner wears it throughout the day. The AI captures real conversations (not textbook exercises), extracts vocabulary encountered in the wild, tracks pronunciation patterns, and builds spaced-repetition drills from actual usage. The immersion becomes the curriculum.

A therapist uses it during sessions (with consent). The AI generates structured session notes, tracks treatment themes across weeks, flags patterns the therapist might have missed, and maintains continuity between sessions — all processed locally, never leaving the device.

Same hardware. Completely different software. Generated on the fly.

This is what Karpathy meant by “the app store is an outdated concept.” The future isn’t a catalog of pre-built apps. It’s a hardware platform that captures physical-world signals, paired with AI that generates the right software for whatever you’re doing right now.

The Three-Layer Architecture

The pattern across all these scenarios is the same:

Layer 1: Hardware (stable) — captures raw physical signals. Microphone, camera, sensors. This doesn’t change.

Layer 2: Domain knowledge (swappable) — an exam question bank, a sales playbook, a language corpus, a clinical guideline set. These are modular knowledge packs that give the AI context for a specific field.

Layer 3: Personalized software (generated) — the AI combines your real-time data from Layer 1 with the domain knowledge from Layer 2 to produce software that is unique to you. Not configured. Not customized. Generated.

The business model follows naturally:

  • Hardware sold once (at cost or slim margin)
  • Domain modules on subscription (education, sales, language, clinical)
  • Open SDK for third-party developers to build new domain modules

It’s not an app store. It’s a soul store — domain-specific knowledge packs that give the same hardware a different purpose. Swap the soul, and the device becomes a different product.

Why This Hasn’t Happened Yet

Two obstacles:

The hardware industry hasn’t internalized the shift. Most device manufacturers still think their job is to build a complete product: hardware + firmware + app + cloud. They don’t see themselves as infrastructure for someone else’s AI. Opening an API feels like giving away control. But the companies that figure this out first — that build hardware designed to be orchestrated by AI agents rather than operated by human fingers — will define the next platform.

The protocol layer is missing. We have USB for physical connections. HTTP for network communication. But there’s no equivalent standard for “AI agent talks to physical device.” Matter/Thread is a step in the right direction for smart home, but it’s narrow. What’s needed is a broader convention — a way for any AI agent to discover, query, and control any nearby device. A kind of “USB for the AI era.”

The Breadboard and the API

Today, bridging AI and the physical world requires a breadboard, some jumper wires, and a willingness to hack around proprietary firmware. Grandoch’s project proves it’s possible. It also proves it’s absurd that it should be necessary.

The real inflection point comes when hardware ships expecting an AI on the other end — not a human. When the default interface isn’t a touchscreen but an API. When the question a product designer asks isn’t “how will the user interact with this?” but “how will the user’s agent interact with this?”

We’re not there yet. But the gap between “impossible” and “one afternoon with an AI agent and a breadboard” has already collapsed. The next gap to close — from “one afternoon” to “one minute” — is a hardware problem, not a software one.

Software ate the world. Now it needs a body.

中文翻译

软件是免费的，硬件才是那堵墙

2026 年 2 月，Andrej Karpathy 花了大约一小时 vibe-code 了一个定制的心肺训练仪表盘——逆向工程了他 Woodway 跑步机的云端 API，把实时数据拉到自定义界面里。他的结论不仅仅关于健身：他认为"应用商店"的概念——一个固定的 App 目录供你浏览下载——正在过时。当 LLM 代理可以在几秒钟内生成一个完全定制的应用，精确满足你的需求，你为什么还要在商店里找一个最接近的近似品？

但 Karpathy 也指出了瓶颈：**99% 的产品仍然没有 AI 原生接口。**他的跑步机没有开放 API，他不得不逆向工程一个专有云协议才能读取自己的数据。软件生成是轻而易举的事。硬件才是那堵墙。

他描绘的"一分钟的未来"——你说"帮我追踪接下来 8 周的有氧训练"然后一切自动运转——需要硬件的配合。而硬件，绝大多数情况下，并不配合。

10 欧元和一块继电器板

开发者 Andre Grandoch 把 Karpathy 的想法往前推了一步。他不只是想读取跑步机数据，还想让 AI 直接控制跑步机——根据心率调速度、跑间歇训练。他的跑步机有蓝牙和 WiFi，但都锁定在厂商生态里。没有 API，没有开放协议。

他的方案：摄像头对准 LCD 屏幕让 AI 用 OCR 读数，Arduino 加继电器板连接物理按钮让 AI “按键”。总成本约 10 欧元，大部分是在跑步机上边走边搭的。

史上最强大的 AI 可以在几秒内写出任何程序——却需要一块继电器板和几根跳线才能调节一台跑步机。

鸿沟：AI 变聪明了，硬件还是傻的

我们正在经历一场不对称的革命。软件已经有了突破——LLM、AI 代理、vibe-coding、即时生成定制工具。生产软件的边际成本正在趋近于零。

硬件还没有经历同等级的时刻。

2026 年的设备出厂时配备蓝牙但用专有协议，有 WiFi 但没有 API，建设了面向人类的仪表盘却没有机器可读的端点。2022 年的跑步机表现得像 2005 年设计的——不是因为工程水平差，而是因为设计假设错了。这些设备是为人类用手指点触屏幕的世界而造的，不是为 AI 代理发送指令的世界而造的。

结果很荒谬：史上最强大的 AI 可以在几秒内写出任何程序，却没法在没有继电器板和跳线的情况下调节一台跑步机。

硬件是通往物理世界的接口

这里维纳又变得相关了。在《人有人的用处》（1950）中，他论证智能——无论是生物的还是机械的——需要三样东西：感知（感受世界）、决策（处理信息）、行动（改变世界）。

AI 已经有了决策能力。LLM 可以推理、规划、生成代码、做判断。但感知和行动都依赖硬件。传感器是 AI 的眼睛和耳朵，执行器是 AI 的手和脚。没有它们，AI 困在数字世界里——一个瓶中大脑，强大但无法触及物理现实。

Grandoch 的 hack 完美地展示了这一点。他的系统有维纳的完整三层：

  • 传感器层：摄像头读取显示屏，BLE 读取心率带
  • 决策层：AI 代理运行控制循环，比较当前状态和目标方案
  • 执行器层：Arduino 触发继电器按下物理按钮

这就是维纳的完整反馈回路，用 10 美元的零件拼出来——因为跑步机厂商没有提供接口。

2026 年，“智能"应该意味着什么

“智能"这个词已经被滥用了。2015 年的"智能设备"意味着：配套 App、云端仪表盘、订阅制。设备跟自己的服务器对话，服务器通过专有 App 跟你对话。智能住在云端，锁在围墙花园里。

2026 年，“智能"应该意味着不同的事：**我的 AI 代理可以直接与这个设备对话。**本地 API，开放协议，机器可读的数据流。智能不需要住在设备的云端——它住在用户的代理里。设备只需要做好传感器、做好执行器，或者两者兼有。

可穿戴记录设备——Plaud、Omi、Mobvoi TicNote——是早期的例子。它们开始暴露与第三方工具的集成（Slack、Notion、Apple Health）。但大多数硬件仍然是封闭的，仍然假设唯一会与它交互的是人类手指在触摸屏上的点击。

这引向何处：一个设备，无限软件

这里变得有趣了。如果软件可以由 AI 按需生成，而硬件是通往物理世界的稳定接口，那么产品逻辑就反转了。你不是为一个特定 App 造一台设备，而是造一台设备来承载用户当下需要的任何软件。

想象一个小型便携硬件设备——麦克风、可选摄像头、蓝牙/WiFi、一个用于边缘推理的本地小模型。硬件不变，变的是 AI 生成的软件层，按用户、按场景定制：

学生上课时夹上它。设备实时录制课堂内容。课后，AI 生成按主题组织的结构化笔记，提取关键概念和公式，交叉匹配这门课的考题库。它根据过往测试表现知道学生已经掌握了哪些知识点、哪些还需巩固——然后生成个性化学习计划，练习题按相关性排序。考试前，学生说"用这周的内容考考我”，设备就会根据他的薄弱点生成针对性题目，随着作答实时调整难度。一个学期下来，系统构建出一张学生知识掌握全景图——一位和你一起听过每堂课、记住一切的随身家教。同一堂课，没有两个学生得到相同的输出。

销售戴着它见客户。AI 分析说话时间比例，识别异议模式，追踪哪些话术促成成交、哪些导致僵局，每次通话后生成辅导笔记。设备是隐形的——一个小夹子，不是桌上的手机。

语言学习者全天佩戴。AI 捕捉真实对话（不是课本练习），提取实际遇到的词汇，追踪发音模式，从真实使用中构建间隔重复练习。沉浸本身就是课程。

治疗师在咨询中使用（经同意）。AI 生成结构化的咨询笔记，跨周追踪治疗主题，标记治疗师可能遗漏的模式，维持咨询间的连续性——全部本地处理，数据不离开设备。

同一个硬件，完全不同的软件，即时生成。

这就是 Karpathy 说的"应用商店是过时概念"的意思。未来不是一个预制 App 的目录，而是一个捕获物理世界信号的硬件平台，加上为你当下正在做的事生成恰当软件的 AI。

三层架构

所有这些场景的模式是相同的：

第一层：硬件（稳定的） — 捕获原始物理信号。麦克风、摄像头、传感器。这一层不变。

第二层：领域知识（可切换的） — 考题库、销售话术集、语言语料库、临床指南集。这些是模块化的知识包，给 AI 提供特定领域的上下文。

第三层：个性化软件（生成的） — AI 将第一层的实时数据与第二层的领域知识结合，产出对你独一无二的软件。不是配置，不是定制，是生成。

商业模式自然随之而来：

  • 硬件卖一次（成本价或微利）
  • 领域模块订阅制（教育、销售、语言、临床）
  • 开放 SDK 让第三方开发者构建新的领域模块

这不是应用商店，而是灵魂商店——赋予同一个硬件不同目的的领域知识包。换一个灵魂，设备就变成不同的产品。

为什么还没发生

两个障碍：

**硬件行业还没有内化这个转变。**大多数设备制造商仍然认为自己的工作是造一个完整产品：硬件+固件+App+云端。他们不把自己看作别人 AI 的基础设施。开放 API 感觉像是交出控制权。但最先想通这一点的公司——那些设计硬件时就预设会被 AI 代理编排而不是被人类手指操作的公司——将定义下一个平台。

**协议层缺失。**我们有 USB 统一物理连接，有 HTTP 统一网络通信，但没有一个等价的标准用于"AI 代理与物理设备对话”。Matter/Thread 在智能家居方向迈了一步，但范围太窄。需要的是一个更广泛的约定——一种让任何 AI 代理发现、查询和控制附近任何设备的方式。一种"AI 时代的 USB”。

面包板和 API

今天，要桥接 AI 和物理世界，你需要一块面包板、几根跳线，以及绕过专有固件的决心。Grandoch 的项目证明了这是可行的。它也证明了这不应该是必要的。

真正的拐点会在硬件出厂时就预设另一端是 AI 而不是人类的时候到来。当默认接口不是触摸屏而是 API。当产品设计师问的不是"用户怎么跟这个交互？“而是"用户的代理怎么跟这个交互？”

我们还没到那一步。但从"不可能"到"一个下午搞定"的距离已经坍塌了。下一个要闭合的差距——从"一个下午"到"一分钟"——是个硬件问题，不是软件问题。

软件吞噬了世界。现在它需要一具身体。