Two evaluation kits land on a firmware engineer's desk in the same week. Both chips meet the spec, and both cost about the same at volume. By Thursday, one has a working sensor driver, a passing test on the board, and a first power profile. The other is still blinking an LED while the engineer searches a reference manual of more than 1,500 pages for one clock configuration detail. The second chip might be the better part. It probably won't get the design win.
Developer experience, for a silicon vendor, is everything an engineer has to get through between unboxing a chip and running verified firmware on it: documentation, SDKs, drivers, board support packages, reference designs, debug tooling, and support. It has long ranked behind performance, power, and price in how vendors compete. AI coding agents are changing that ranking because engineers who use them everywhere else in their work now expect a new chip to be usable at the same speed.
A vendor that invests here benefits twice. Its own engineers ship SDKs, drivers, and reference designs faster, and its customers reach a working prototype sooner, which raises the odds that the chip gets designed in.
In JetBrains' Developer Ecosystem Survey 2026, 90% of professional developers were using AI coding agents at work at least weekly, and 68% were using them daily. Trust lags behind use: in Sonar's 2026 State of Code survey, 96% of developers said they don't fully trust AI-generated code to be functionally correct. Together, those numbers describe what a chip is now measured against: fast answers, with proof attached.
What engineers expect from a new chip
Firmware makes the proof harder to get. In web software, a wrong answer from a model usually shows up as a failed test within seconds. In firmware, a wrong register value can compile cleanly and go unnoticed until a board misbehaves on the bench or in the field. So an engineer evaluating a new part asks an AI agent for a driver, then asks where each value came from. If the vendor's documentation isn't in a form the agent can read, the answer is a guess that compiles.
An engineer starting on an unfamiliar chip in 2026 works from four assumptions:
- An agent can read the documentation, including register maps, clock trees, and errata, and every generated value traces back to a page.
- The SDK builds, flashes, and tests from the command line, so an agent can run the loop without a person clicking through a configurator.
- A technical question gets answered in minutes, inside the editor, instead of days later in a support portal.
- Example code is checked against the exact part and board, and the result is demonstrated on hardware.
Vendors are responding. In 2026, Nordic Semiconductor released MCP servers that give AI assistants direct access to its SDK documentation, API references, and device configurations. That covers the documentation layer. Building, flashing, and proving code on a board is a separate layer of work.
Ship the software around the silicon
Every chip ships with a software product around it. Before a customer can build anything, the vendor's engineers have written a hardware abstraction layer, peripheral drivers, board support packages, RTOS ports, example projects, and the firmware for the evaluation kit. That workload multiplies with every part variant, board, and toolchain the vendor supports.
Embedder's partnership with Verkor shows what happens when none of that software exists yet. Verkor's team used its Conductor system to produce VerCore, a complete RISC-V CPU core, from a 219-word prompt in roughly 12 hours. The engineers who pick up a core that new have no SDK, no drivers, and no reference firmware to start from. Embedder builds that context from the reference documentation, then drives test equipment to prove the firmware on hardware. As Embedder CEO Ethan Gibbs said at the time, faster chip design "makes firmware the next bottleneck."
The same loop applies to an established vendor's roadmap. For an internal SDK team, the engineers set the direction and an agent does the legwork:
- The agent reads the full reference manual for the new part, including register maps, the clock tree, and errata.
- It drafts an implementation plan that cites the section behind each hardware-specific decision. An engineer reviews and corrects the plan before any code is written.
- It writes the part-specific drivers and board support inside the vendor's existing repository and build system.
- It builds, flashes, and runs tests on the target through debug probes and bench instruments.
- It attaches serial logs, register dumps, and signal captures to each result, and an engineer decides whether the evidence holds up.
The engineers own every decision: what gets built, whether the plan is right, and whether the result is ready to ship. Their hours move to review, architecture, and coverage the team never had capacity for: the variant with no example project, the RTOS port that kept slipping by a quarter.
RTOS support is one place this shows up. Zephyr gives firmware teams a consistent driver model across hardware from different vendors. Embedder has helped multiple customers migrate their firmware from FreeRTOS to Zephyr. That migration work covers much of the same ground a vendor covers when it adds Zephyr support for a part: devicetree, Kconfig, build integration, and runtime validation on hardware.
Get from evaluation kit to customer hardware
A chip earns revenue only after someone designs it into a product. The difficult stretch of that path is between the evaluation kit and the customer's own board. The dev kit example runs, and then the customer's board uses different pins, a different sensor, and a different power topology, and the example no longer applies.
Firmware is getting easier to carry from one chip to the next. In the Linux Foundation's Zephyr Turns 10 report, published in March 2026, 49% of respondents said the biggest effect of adopting Zephyr was easier hardware portability. For a vendor, that means more designs are open to a new part, and tools, software support, and time to a working prototype carry more weight in the decision.
Bring-up on the customer's own hardware is one place AI shortens the path. Embedder reads the schematic alongside the datasheet and resolves pin muxing, pull-ups, bus addresses, and errata workarounds against the board the customer built, with nothing assumed from the dev kit. It works in the customer's existing repository with the compiler, build system, debugger, and RTOS already in place, across 600+ platforms from 13 manufacturers.
Porting is another. Firmware written for the previous microcontroller has to be adapted: HAL calls, peripheral initialization, and RTOS integration, followed by validation on the new target. An agent that can read both parts' documentation and test on the new board takes on much of that adaptation.
Porting cuts in both directions. If AI lowers the cost of adopting a chip, it also lowers the cost of moving to a different one, so more decisions get made on the part and the experience around it. Vendors that have invested in documentation, SDKs, and support get more credit for that work, and a vendor with a strong part and a thin ecosystem has a clear place to invest.
That is our prediction, and industry-wide data to test it does not exist yet.
Give FAEs more time for the hard problems
Field application engineers are how a silicon vendor's knowledge gets to a customer's bench. They are among the most experienced engineers a vendor employs, and a vendor has far fewer of them than it has customers. Large accounts typically get a named FAE. There aren't enough FAEs to provide the same support to every smaller customer. Those customers rely on distributors, forums, and support tickets.
A share of the questions an FAE receives are first-line: a clock that won't lock, a pin mux conflict, a driver returning zeros, an erratum the customer hasn't read. The answer usually exists somewhere in the vendor's own documentation.
An AI agent grounded in that documentation changes how the work is divided:
- First-line questions get answered at the customer's desk, with the datasheet section cited.
- When a problem does need an FAE, it arrives with the evidence already collected: serial traces, register dumps, schematic context, and the hypotheses already tested on the board.
- The FAE's hours go to system architecture, design reviews, and problems that depend on judgment built over many past designs.
- FAEs can use the same agent on their own bench to reproduce a customer's issue and confirm a root cause before replying.
The multiplier comes from that division. Customers too small for a named FAE get a first response of similar depth, and FAEs get more of their week for the design-ins where their experience changes the outcome.
The arrangement depends on FAEs. An agent answers from documentation and from what it can measure on a board. An FAE knows which reference design fit a similar product, which trade-off a customer will regret in production, and when the datasheet itself is wrong.
Find stalled evaluations before they disappear
Most stalled evaluations are recoverable if someone knows about them in time. The difficulty is that they are quiet. An engineer who gets stuck after a week rarely files a ticket saying so, and the first sign is usually an opportunity that never closed.
The stakes are larger than one order. A design win puts a part into a product that can ship for years. In the same Linux Foundation report, 52% of organizations said they support Zephyr-based products for five to ten years or longer, and firmware written for one product often becomes the starting point for the next. A customer won at evaluation tends to stay for those follow-on designs.
Smaller teams have the least support and often the tightest schedules. A team without a named FAE and without slack in its schedule has little reason to spend a second week on a part when an alternative is already running on the bench. Individually, these are small orders. Together, they are the accounts no FAE team can cover by hand.
AI changes the comparison, and it favors any vendor that prepares for it. A part an agent can bring up this week gets judged on its merits, including by the small teams no FAE has time to visit.
One way to see the problem early is to measure the time from kit arrival to the first verified peripheral on the customer's own board. Tracked per part and per customer segment, it shows where evaluations stall before a lost deal does.
Make silicon agent-ready
"Agent-ready silicon" fits in a headline. The work behind it is specific, and a vendor can audit its own parts against five layers:
- A machine-readable hardware description.
- Documentation that can be indexed and cited.
- A command-line toolchain.
- Examples tested on hardware.
- Support for open ecosystems such as Zephyr and MCP.
Embedder is the customer-side platform that puts those layers to work. It indexes manuals, datasheets, errata, and SVD files, ingests schematics from Altium, KiCad, Eagle, PADS, and Xpedition, and runs hardware-in-the-loop tests through debug probes and bench instruments. More than 8,000 engineers use it today.
Part of that hardware interface is open source. Embedder maintains pytrace, an Apache-2.0 Python SDK for SEGGER J-Link and J-Trace probes that covers instruction trace, code coverage, RTT, SWO, and target control. Any team can use it to give its own tooling the same access to a target.
Where the platform runs is part of the decision because schematics and source code are sensitive IP. Embedder runs in its own cloud, in the customer's cloud, or fully on-premises.
For a silicon vendor, the last mile is integration: making sure each part, its documentation, and its boards are represented accurately in the tools its customers already run.
Where the claim has limits
We expect developer experience to decide more design wins over the next few years than it has in the past. That claim has limits we can already see:
- An agent that cites a datasheet inherits the datasheet's mistakes. When the document is wrong or an erratum is unpublished, the citation is wrong too, and testing on hardware is what catches it.
- Older parts documented in scanned PDFs, and analog behavior that no document fully describes, still need an engineer who has seen the part misbehave.
- Safety-critical firmware needs human review and traceability, whatever wrote the first draft. AI can help prepare the evidence, and the engineer and the assessor still make the decision.
- Price, supply, and long-term availability still decide many designs. No SDK fixes a part that can't be delivered.
If you build chips, tell us what we got wrong. Bring the part your FAEs get the most tickets for to a working session with our team and see what an agent does with it on the bench.
If you write firmware, show us your setup. Tell us which chips were quick to bring up with an AI agent and which ones you gave up on.
Frequently asked questions
Why is developer experience becoming more important for silicon vendors?
In JetBrains' Developer Ecosystem Survey 2026, 90% of professional developers used AI coding agents at work at least weekly, and 68% used them daily. Engineers who work that way expect a new chip to be usable at the same speed: documentation an agent can read, a toolchain it can drive, and results proven on hardware.
How can AI help a vendor's SDK team?
An AI agent can take on driver, board support, and RTOS port work for each new part. It reads the reference manual, drafts a cited implementation plan, writes the code, and tests it on the target. Engineers review the plan and the evidence, and spend more of their time on architecture and on parts that have never had full software coverage.
Does AI replace field application engineers?
No. An agent answers first-line questions from the documentation and collects evidence from the board. FAEs work on system architecture, design reviews, and problems that depend on experience, and customers who never had a named FAE get a real first answer.
Why do customers abandon chip evaluations?
Usually because bring-up took longer than the team could afford. Moving firmware between chips has also become easier: in the Linux Foundation's 2026 Zephyr Turns 10 report, 49% of respondents said the biggest effect of adopting Zephyr was easier hardware portability. When bring-up on the customer's own board takes too long, a team with a competing part already running has little reason to wait.
What makes silicon agent-ready?
Five layers: a machine-readable hardware description, documentation that can be indexed and cited, a command-line toolchain, examples tested on hardware, and support for open ecosystems such as Zephyr and MCP.
What hardware and firmware does Embedder support?
Embedder's catalog covers 600+ platforms across 13 manufacturers and 6,000+ peripherals. It works with C, C++, and Rust on bare-metal and RTOS projects, including FreeRTOS and Zephyr, and teams can add custom platforms with their own documentation.