Firmware, the Unexpected Agent Frontier

Embedded is the domain we least expected agents to reach: no browser to screenshot, no REPL to iterate in, and a bug that can physically brick the device. Two skills — embedded-systems at 9.2 and cpp-pro at 9.3 — say the ecosystem got there anyway. The mechanism is the surprise.

When we rank agent-friendly domains, embedded firmware sits at the bottom of every intuitive list. Web apps give the agent a refresh button; scripts give it a terminal; tests give it a green checkmark. Firmware gives it a chip on a board that must be flashed, on real hardware, at real voltages, where the feedback for a mistake may be a device that no longer accepts new firmware.

And yet the embedded skills in our directory score high, not merely acceptably. That inverted result taught us something about which workflows agents actually excel at, and it inverts a common assumption about agentic coding.

The two skills

embedded-systems — 9.2 is the domain core: microcontroller programming, hardware constraints, peripheral interfaces, the interaction between code and physical components — timing, memory budgets, interrupt behavior, the whole discipline of software that must respect hardware it cannot change.

Its companion is cpp-pro — 9.3, tied for the top of the entire framework-specialist cluster we surveyed. C++ on embedded is where the two skills' content converges: memory layout, ownership discipline, build-flag and linkage hygiene — the subset of C++ where a mistake isn't a crash but a silent corruption, or a binary that doesn't fit the flash.

Why "can't run it" forces the right workflow

Here's the counterintuitive core. The embedded developer can't iterate casually — every flash cycle costs minutes and carries risk, so the professional workflow front-loads scrutiny: desk-check the logic, review the register configuration, verify timing budgets on paper, then commit to hardware. Run-and-fix was never an option; review-before-flash is the native discipline of the field.

Now look at how agents behave in domains where running is cheap. The cheap loop — generate, run, see the error, patch — is exactly the slot-machine debugging that debugging-wizard exists to break: it works often enough to be seductive and fails expensively on the problems that matter. Embedded strips the slot machine away. What's left is the workflow agents are demonstrably strongest at: sustained, exhaustive, checklist-driven review of code before it executes. No environment in our scoring rewards "read every line and reason about it" more directly — and that's the one loop an agent runs without hardware.

The skills encode precisely that: cpp-pro at 9.3 carries review-grade discipline over C++ correctness — the class of checks that catch the bug before a device exists to manifest it. embedded-systems at 9.2 encodes constraint-first thinking: memory and timing budgets verified as constraints, not discovered as crashes.

What this predicts about the rest of the ecosystem

The embedded result reframes the question "what can agents work on?" The limiting factor was never the medium — it's whether the domain's native workflow rewards careful pre-execution analysis or rapid post-execution iteration. Domains in the second class reward the model; domains in the first class reward the process — and skills are how you package process.

Embedded, with the harshest iteration economics in software, turns out to be nearly optimal agent territory because of those economics, not despite them. The flash cycle the human resents is the discipline the agent needed all along.

It's the least likely frontier, and one of the best ones. Wherever iteration is expensive and review is mandatory — firmware, safety-critical code, one-shot deployments — expect the same pattern: high-scoring skills, and agents that look more like senior engineers there than anywhere else.