AI Coding Agents Get EE Teams to Answers Faster
TL;DR
- StarFish Medical’s EE team went from concept to hardware on the bench in five weeks, including custom firmware, a Windows interface, and analysis scripts, using AI coding agents.
- Proof-of-principle work that used to take four times the person-hours now takes roughly 25% of the effort. A definitive ‘no’ on one approach can be the fastest route to a better one.
- Engineers now build both firmware and the application layer within their own workflow. No separate software resource required.
- AI coding tools shift engineer attention from implementation mechanics to systems-level thinking — architecture, data flow, and the behavior the product actually needs.
- Less effort spent building the test rig means more budget spent on the technical question itself.
Every development program runs on a fixed pool of time and money. The real risk is rarely the idea itself. It’s spending that budget without reaching a clear answer about whether the idea works.
Teams in this position ask the same question in different forms. Founders want to know if their concept holds up before they commit more capital. Teams with an active program want to know if a technical direction is sound before a delay turns into a missed milestone. Both are really asking the same thing: can we get to a real answer before we run out of runway?
Our electrical engineering (EE) team has been using tools like Claude and Codex for the past several months, and the honest answer is that they don’t just make engineers write code faster. They change how quickly a team can turn an idea into a tested, validated answer.
Fail fast without burning the budget
One recent program shows this clearly. An engineer went from a rough concept to hardware in hand, on the bench, in five weeks. In that window, the team built a custom board, wrote the firmware for it, built a Windows application to interface with it, and wrote the processing scripts needed to log and analyze the data.
That tooling ran several hundred test iterations. The result was not the outcome the client had hoped for going in: the approach would not reach the accuracy the application needed. That result led directly to a technology pivot, and we are now exploring innovative concepts that came out of that pivot.
That’s the actual win. Five weeks of client budget bought a definitive ‘no’ on the original approach, and opened the door to a better one. Proof-of-principle work like this now takes roughly 25% of the person-hours it used to and less than half the time. A team with a fixed budget for this kind of work can push much further into the real question, instead of spending most of that budget just building the tool needed to answer it.
What this means: if your program needs an early ‘yes’ or ‘no’ on technical feasibility, that answer can come at a fraction of the effort it used to take, without cutting corners on the testing itself, and a hard no on one approach can be the fastest route to a better one.
Want more insights like this? Join our monthly newsletter.
Built by your engineers, not handed off
For years, StarFish has run an internal program to give engineers a consistent way to pair hardware and low-level firmware with a higher-level Windows application for data acquisition and control, so every new prototype didn’t require building that connection from zero. The hardware side of that program is still relevant. What’s changing is the software tooling layer: coding agents can now build that connective software directly, on a case-by-case basis, as fast as a program needs it.
Engineers are able to build the firmware and the application layer themselves without needing a dedicated software resource to fall back on. Work that used to require handing a specification to a separate software team now happens inside the same engineer’s own workflow.
This also shows up in ongoing work on existing programs. On one client program with production firmware and a production application already deployed in the field, an engineer used these tools to explore and test new features directly against the existing codebase, without pulling in a separate software engineer to do it.
What this means: you’re not adding a new vendor relationship or a black-box dependency. The same engineers who understand your system are the ones building and modifying it, at whatever pace the program needs.
Engineers spend their time on the problem, not the plumbing
The deeper shift is where engineers spend their attention. Instead of working through loop logic or checking whether a variable is in scope, an engineer can describe the behavior they need and let the tool handle the implementation. One engineer described it as having a software minion: you say what you want done, and you get to think about the behavior, not the syntax.
That matters because EE work at StarFish already involves sitting at the systems level: thinking about architecture, how data moves through a design, and which mathematical operations need to happen where. These tools extend that same systems-level thinking into the software and firmware layer, instead of pulling engineers down into implementation work that used to require a separate skill set.
What this means: the people designing your system are also the ones building the tools to test it, and they’re spending their time on the questions that determine whether your product works.
AI coding agents free up budget for the real question
None of this replaces engineering judgment. Code is still reviewed, every result continues to be validated on the bench, and every claim still gets checked, the same way you’d question any other source. What’s changed is how much of the standard proof-of-principle overhead (building the test rig, the firmware, the application, the analysis pipeline) now takes a fraction of the effort it once did.
If your program is trying to reach a fast, credible answer on a technical direction, or you’re deciding whether a concept is worth the next round of investment, this is the kind of gap it closes: less effort spent building the tool to get the answer, more spent getting the answer itself, and a faster path to the next idea when the first one doesn’t hold up.
Astero StarFish is the attributed author of StarFish Medical team blogs. We value teamwork and collaboration on all our medical device development projects.
Images: Adobe Stock
Related Resources
When one team designs, lays out, and brings up a board, knowledge sticks. Splitting that work across specialists looks efficient but creates the risk it’s meant to avoid.
AI coding agents like Claude and Codex are helping EE teams turn concepts into tested hardware in weeks, not months, without adding a new vendor or software dependency.
PCB stack-up shapes signal integrity, EMC performance, and manufacturability long before layout begins. Getting layers and reference planes right avoids costly redesigns later.
Ariana and Mark explore how prototype strategy helps teams reduce technical risk and accelerate progress.
Explore Our Services
Our multidisciplinary teams have all the in-house capabilities to transform your medical device from concept to final product.
Medical device design and development with a commercial launch focus. See how we support clinical trials and facilitate seamless tech transfers.
We help you navigate complex regulatory landscapes to achieve commercial success. Explore our integrated approach to quality and regulatory services.