Tiny Engineer

An open-source, 3D-printable desktop robot that physically acts out what a coding agent is doing — reading, thinking, typing, finishing — with movement, a face on a small monochrome OLED, and sound. It runs on an ESP32-C3 over Wi-Fi and exposes a plain REST API, so nothing about it is specific to any one agent: Cursor, Antigravity and Claude Code each ship as a small adapter package that translates that tool’s lifecycle hooks into HTTP calls, and anything else can be wired up by hand.

Who built itA maker in Kraków with a blog at jamro.net and twenty-eight public repositories going back to 2012, most of them small: a neural-network racing sandbox, a voice assistant, an AI sysadmin chatbot, a controller for a brass lamp shade. This is by a wide margin his most popular, and the only one where the hard part is the hardware.

1. 01

   The stated reason is the honest one

   The README opens with four words — give your AI coding agent a body — and then explains itself without dressing it up. The author’s problem was that agents now work for long stretches on their own and he wanted to know what his was doing without staring at the IDE, so instead of another spinner or status line he built a small robot that sits next to him and visibly reads, thinks and types. He calls it a slightly ridiculous desk robot, which is the right register. The behaviour set is small and legible: reading, thinking, typing, attention, error, abort, sleep, wake-up, welcome, a bell, and a dead state. Each is a movement plus a face plus, in several cases, a sound — six wav files ship in the repository, named for what they announce.

2. 02

   The robot is deliberately the dumb part

   The most important decision in the project is that the robot knows nothing about coding agents. It exposes one endpoint that takes an animation name, and everything else lives in small adapters that ship inside the repository as separate packages, one per agent: a Node command-line tool for Cursor that runs on its hooks, another for Antigravity’s lifecycle hooks, and a third for Claude Code’s project hooks. Each maps its own host’s events onto the robot’s vocabulary and then makes an HTTP request over the local network. The README states the principle in as many words — Cursor is one example client, not the architecture — and it is the kind of sentence that is easy to write and hard to earn. It is earned here by the fact that the fourth documented path is simply “bring your own”: Codex, or anything else, needs a script and an HTTP request and nothing more. The Claude Code adapter has one detail worth copying, which is that its hooks are declared asynchronous so that a robot that is switched off can never stall a tool call.

3. 03

   Five servos, one screen, and a face with four styles

   The hardware is a Waveshare ESP32-C3-Zero, a PCA9685 driving five servos — head, neck, both hands and the body — a 128×32 monochrome OLED for the face, and a MAX98357A amplifier with a small speaker. The firmware is organised far more carefully than a desk toy requires, and the organisation is the interesting part. Animations are one file each behind a registry, so the movement, the eyes and the audio for a state are separate contributions that a single name pulls together. The eyes have their own two-layer system: modes such as blink, impact and idle, and styles that decide what an eye actually looks like — classic rounded eyes, dots, a cover style that fills the panel so that any cut-out in a printed shell stays lit, and a kaomoji style contributed by someone else. Eye styles sit behind their own registry, which is what let that contribution land without forking the animation system. The same instinct shows up in the settings code, which is split into loading, saving, validation, caching, reset and the NVS layer underneath, and in an embedded web interface whose single generated page is seventy-seven kilobytes of C++ string.

4. 04

   A hardware tutorial written for people who write software

   The documentation contains something this archive has not seen before: a nine-part course called “From Code to Circuits”, written for software engineers who have never soldered anything. It runs through electricity and units, microcontrollers and the ESP32, wiring craft and schematics, buses and protocols, servos and mechanical motion, 3D printing and mechanical assembly, power budgets and safety, and debugging tools for embedded work, ending with a piece that ties it together. Each part is five to twelve thousand characters, and the whole series is roughly the length of a short book. It exists because the project’s own instructions start by telling a newcomer to shop, print, wire, flash and assemble, and the author evidently worked out that “wire” is not a step a software engineer can be told to perform. Alongside it sit separate reference pages for components, interfaces, pinout, power, servos, testing and wiring, an assembly guide with nineteen photographs, a page on parametric design, and a shopping list.

5. 05

   The board went to manufacturing and then got reviewed

   The electronics were originally separate modules on jumper wires, and replacing that with a fabricated board turned into the most eventful thread in the repository. A contributor submitted a first carrier board designed with Claude Code, sized against the actual enclosure rather than guessed dimensions, and it was merged. The author then designed a fuller integrated board carrying USB-C, the servo controller, the audio amplifier and the power distribution, and reported that the latest revision had gone to production. A day after that, a community member who had read the KiCad files and the datasheets but had not run KiCad posted a review. The finding that mattered was a bring-up blocker: a resistor pulls the servo controller’s output-enable pin high, but the firmware never drives the corresponding GPIO — a flag in the pin header is set to false — so all sixteen servo outputs would stay off and the robot would not move. The same review listed, for the next revision, an absent soft-start capacitor, missing ESD protection on the USB data lines, and a ground pour running under the ESP32 antenna. The author’s reply is the whole project in one line: this is very useful, especially with the boards already on their way. He said he would check the enable-pin issue first and treat the rest as reasons to plan a revision rather than to stop the batch.

6. 06

   What a community does to a hardware project

   Five contributors and seven co-author trailers across a hundred and thirty-seven commits, and the outside work is unusually substantive for a repository this young. One contributor ran a geometric census over every exported mesh file to fill a documentation gap — the project said in three places that exact screw lengths were not documented — detecting cylindrical features at the right diameter, validating the detector against a labelled test part, and producing a table of twenty-seven screw locations across eleven parts. The same analysis established that five deep channels in the chest are servo-wire routing rather than screw holes, that only the head has servo-tab pilots, and that the whole robot needs roughly thirty M2 screws of one length and five of another. The author’s response was to say he had not expected anyone to run a geometric census over all the exported models. Another contributor wrote a kaomoji expression library with sixteen animated faces, thirty frames each; another rebuilt the parametric underside cover so it works across all three supported servos, regenerating twenty-seven export files. A bot reviews every pull request, and the repository carries a licence compliance file and a code of conduct, which is a lot of civic infrastructure for a desk toy.

7. 07

   The unglamorous half

   Some of the issue thread is the ordinary loop of making a physical thing, and it is more instructive than the architecture. One person reported that servos rotated freely inside their holes even after screwing; the author explained that servo dimensions vary between manufacturers and that fused-deposition printing holds different tolerances horizontally and vertically, then reduced the shaft radius from 2.45 to 2.40 millimetres and printed a test piece on his own printer before answering. Another reported that the head seemed to have a large hole where the neck should attach, and was told that the hole was correct and was where the servo gearbox sits, with a screenshot of the assembly — which is what produced the assembly guide. A third found that one model was 1.6 millimetres too narrow for the servo it was designed around, and warned other builders to hold off printing until the fix landed. A fourth noticed that changing servo size in the parametric model silently deleted six of the laptop’s sixty-seven keys. None of this is clever. All of it is the reason the project is usable by someone who is not its author.

8. 08

   What the numbers look like

   A hundred and thirty-seven commits over five weeks, one release tagged as the first working prototype, seven open issues, four hundred and thirty stars and fifty-six forks. Two hundred and thirty-six megabytes in the repository, and the bulk of it is not code: the parametric model ships pre-generated meshes for three different servo families in three formats each, which is twenty-seven files per family, because the author decided a builder should not have to own Fusion to make one. The licensing is genuinely multi-part — the root is not a single licence GitHub recognises, because the software and the hardware are licensed differently, with the hardware under a strongly reciprocal open hardware licence and a compliance file listing which files fall under which. Reading through the whole thing, the impression is of a project where the author has been careful about the two things that decide whether a build guide works: whether a stranger can follow it, and whether the files they download are the ones that were tested.