Feature Discovery UX Research

Embedder is a YC S25 startup building an AI coding agent for embedded and firmware development. It runs in the terminal and as a VS Code extension, reads datasheets, and can build, flash and monitor a connected board. Think Cursor, but for firmware.

In Winter 2026 I led a six-person research team through Atlas Digital, a consulting group at the University of Michigan, working with Embedder's CEO, Ethan Gibbs, and their head of product. Over ten weeks we ran 23 hour-long usability interviews, a heuristic evaluation and a competitor analysis, then handed over seven design recommendations backed by coded data.

The founders came to us with a long list: debugging, a hardware debug mode they were considering, whether people understood the value of the product, and a target of 50 to 100 participants. I suggested we pick one thing and do it well: the first five minutes, from installing Embedder in the terminal or VS Code to getting a first useful answer.

There were two reasons. We had no hardware to test with, so we couldn't fairly test flashing or live debugging. And our team's strength was UI and UX, not hardware bring-up. A specific focus would give Embedder something they could act on, where a broad one would give them a pile of opinions.

After 10 to 15 interviews, the answers started to overlap. Rather than chase the 50 to 100 number in the brief, we put the time into depth. Each session ran about an hour and started with the participant's own projects and tools before moving into think-aloud tasks. We finished with 23 interviews, mostly computer engineering and computer science students, with about a fifth of them working engineers.

Alongside the interviews, we ran a competitor analysis against Claude Code, Codex and Cursor, and a heuristic evaluation of Embedder in both the terminal and VS Code.

Each researcher wrote up think-aloud notes, then we coded every session onto a shared rainbow sheet: a row for each behaviour, a column for each participant. Patterns showed up as solid bands of colour and the outliers showed up as gaps. These are some of the rows that shaped the findings.

Only 30% got Embedder running on the first try. Half hit installation problems: a quarter couldn't install at all, and another quarter got there after errors like “command not found”, PATH issues and antivirus software deleting the file. 60% didn't read the instructions printed in the terminal, including the one telling them to restart it.

73% didn't understand what the Embedder Console was for at first. It opens next to the terminal and shows serial output from the board, but some people tried to chat in it and others closed it as clutter.

Over 60% never found slash commands, mode switching or file attachments. Most didn't notice the Act, Plan and Debug toggle, and Act mode was on by default with no explanation of what it would do.

Preferences split between VS Code and the terminal, so both paths matter. In VS Code, the marketplace listed two Embedder extensions, and several people weren't sure which one was real.

Every participant compared Embedder to Copilot, Claude or Cursor. People called it a “Claude wrapper” and “just a chat box”, something they could put together themselves. Without a clear first impression of what made it different for firmware, they judged it as a general coding assistant.

Embedder came to us with a brand problem they could feel but not yet measure. Their product sat in the same tools, with the same chat-and-agent layout, as Claude Code, Codex and Cursor, and they wanted to know how people actually saw Embedder next to them.

So alongside the interviews, each researcher took one product and we compared all four across the same 12 categories, from interaction model and context handling to system feedback and unique strength. We weighted the four that shape a first impression most: interaction model, input efficiency, context handling and system feedback.

The comparison explained the brand dilution. There's no widely used AI agent built for firmware, so engineers default to general tools and bring those expectations with them. Embedder's real advantage is hardware context: datasheets, board selection, flashing and serial output. But that advantage lived in exactly the parts people found confusing in the first five minutes, like platform setup and the monitor. Everything people understood instantly looked like every other agent.

We evaluated Embedder in the terminal and in VS Code against Nielsen's 10 heuristics, plus two of our own for AI tools: AI transparency, and mouse versus keyboard. We rated every issue on Nielsen's 1 to 4 severity scale.

It found the same problems from another angle. Embedder's users live on the keyboard, but key controls only worked with a mouse. The loading indicator sat far from where people were typing, so they sent duplicate prompts thinking nothing was happening. Approval prompts could scroll out of view while the agent kept working, and internal labels like “Todo Write” showed up where a plain status should be.

The team already had questions about their interface going in, but they needed data before acting on them. Our interviews gave them that. Not every recommendation was built, but together they helped the team spot the low-hanging fruit: changes they could make quickly that would make a real difference. They also told us they valued that every recommendation came with numbers behind it, along with the full transcripts, recordings, coded data and competitor analysis.

Since the handoff, Embedder has replaced the browser redirects that linked the terminal, VS Code and a web account with verification codes. The redirects had been one of the more error-prone steps in setup. They've also changed some of the language in the interface based on our recommendations. For example, the Embedder Console is now called the Embedder Monitor.

They also asked for our read on their marketing site and how well it got across the product, its key features and the brand. They have since rebuilt the whole site, and we gave input on the final design.

Narrowing the scope was the most useful call I made. Saying no to most of a client's brief felt risky, but a focused question is what made the findings specific enough to act on.

Depth beat volume. Once answers started repeating, more sessions would only have added confidence to things we already knew. Longer sessions about people's own projects told us why they got stuck, not just where.

Next time, I'd bring hardware. Most of our participants were students and none of our team were hardware engineers, so we couldn't judge the parts of Embedder that matter most once someone is past setup. Recruiting more working firmware engineers would close that gap.