As AI moves further into engineering workflows, knowing what it can do is only part of the challenge. The bigger question is where engineers should let it take the lead and where human judgment still needs to stay firmly in the loop.
In part two of this three-part conversation, EEWorld Editorial Director Aimee Kalnoskas continues to speak with Brian Neff, a technical engineer at Liquid Instruments, about that balance. They discuss generative instrumentation, verification-first workflows, and a real-time electromagnetic emission detection example, along with why clear requirements and human oversight remain essential as AI takes on more of the test and measurement process.
EEWorld: Welcome back to part two of our conversation on hardware AI with Brian Neff. In part one, Brian made the case that trust in AI-assisted test systems comes down to determinism. AI can help design something, but what it builds has to behave the same way every time.
That raises a practical question. Where does AI belong in your workflow? Is it just speeding up the boring parts, or is it making decisions you would normally make yourself? Today we will dig into those layers, walk through a real-time electromagnetic emission detection example, and find out where Brian draws a hard line on human oversight.
As a reminder, Brian is a technical engineer at Liquid Instruments and a former U.S. Air Force commander with extensive experience directing multimillion-dollar research and test programs. He specializes in developing solutions for complex engineering challenges, focusing on robotics, autonomous systems, and electromagnetic environments.
Brian holds a PhD in electrical engineering from the Air Force Institute of Technology and has deep expertise in the practical implementation and validation of advanced hardware and software systems.
Brian, in part one, you talked about engineers shifting toward defining intent, goals, constraints, and measurement, rather than working through low-level details. Where is the line between intent that is useful for AI to act on and intent that is really just vague engineering speak for “I haven’t thought this through enough”?
Brian Neff: One of the biggest misconceptions about AI is that it will eliminate the need for clear thinking. You wouldn’t hand a team of engineers a vague requirement and expect a great result. Why expect anything different from AI?
What AI can do is act like a large team of engineers and bring all their knowledge to the table. Here’s an example. With generative instrumentation at Liquid Instruments, you can build the custom instruments you always wished you had and push those features directly to the FPGA. Say I want to detect a drone signal around 2.4 GHz, I know the protocol, and I need latency under 100 ms. Those details are actionable. You’ll get an instrument that closely fits, if not exactly matches, what you asked for.
But if you prompt something like “I want to detect drone signals somehow,” you’ll get a vague response with little value, if any. If you can define the requirements, AI can translate them into an actionable solution. Just like with a team of engineers, being explicit gets rewarded.
One caveat: because AI draws on a body of knowledge no individual has, it can also make suggestions. Have you thought of this? Have you considered adding that feature? That’s exactly what we’re building into generative instrumentation.
EEWorld: I know it’s cliché, but I’m hearing garbage in, garbage out.
Brian Neff: Absolutely.
EEWorld: What I’m hearing is that AI makes engineering expertise more necessary, not less. A vague prompt won’t turn AI into the engineer for you. Your prompts are only as good as the skill set behind them. So where do you draw the line on human oversight and validation?
“AI should never have final authority on requirements, validation criteria, acceptance decisions, or risk assessments.”
Brian Neff: I agree. It still requires discipline and knowledge. When you work with these tools, there’s a back-and-forth where the AI asks, “Have you thought of this?” If you blindly answer yes without thinking through the ramifications, you can degrade the end result.
My hard line is this: AI should never have final authority on requirements, validation criteria, acceptance decisions, or risk assessments.
I’ve gotten real value from AI in building requirements and validation criteria. It can help create a test plan, suggest edge cases I would likely have missed, or identify potential failure modes. But deciding whether a system is safe to deploy, whether a requirement has been met, or whether a risk is acceptable remains a human responsibility. The final call rests with the engineers.
That may change in the future, but I’ve seen nothing so far that would let me make that jump.
EEWorld: You described a process where AI helps build the spec and the test conditions, and only then generates code. Why does that order matter, and what goes wrong if code comes first?
Brian Neff: When I taught programming at the university level, students would tell me, “It’s not working.” I’d answer, “No, it’s doing exactly what you told it to do.” You just told it to do the wrong thing.
The same applies here. Many engineering failures don’t come from bad code. The code works well at doing the wrong thing, because requirements were incomplete, assumptions were wrong, or test conditions didn’t reflect the real problem.
That’s where we bring discipline into generative instrumentation. Before we produce an instrument, we confirm the requirement and suggest improvements. The user accepts or clarifies the specification. Once it’s solid, we define how to test and evaluate, and the user can review, add, or modify test conditions if anything is incomplete or questionable. Only after the test conditions and logic are satisfied do we generate the instrument for the FPGA. Even then, you still have to go back and validate whether the instrument achieved the intended outcome.
Video: In Liquid Instruments’ GenInst Studio, an engineer requests a trigger for an RFD900x drone telemetry radio. The tool asks about detection method, trigger output, channel bandwidth, and hold time, then drafts an instrument plan and test plan for review before generating any FPGA code.
The good news, as we discussed in part one, is that AI shrinks the time it takes to get past the inertia of starting. If we’re disciplined, we can spend that time savings on the validation steps that too often get overlooked.
EEWorld: Let’s walk through the drone detection example in more technical detail. In the context of recognizing electromagnetic emissions in real time, what did the workflow look like five years ago versus now?
Brian Neff: It’s a process I’ve lived through. Over the last five to ten years, drone defense and drone awareness have become a major focus for the military, civilian airspace, and security in general. As recently as five or six years ago, that process was extremely manual.
To detect a particular drone or emission type, I’d start by defining the signal characteristics of interest. Then I’d select and build out a collection architecture, design the processing chain, develop detection algorithms, and integrate them into components I often had to assemble myself. After that came a long stretch of tuning thresholds and validating performance, usually on real hardware. Depending on complexity, that could take weeks, months, or even years.
Today, you can have a dialogue with an AI engine along these lines: “I have a specification sheet for the transmitter this type of drone uses. Can you develop a detection algorithm given the capabilities of the platform I want to deploy it on?” The AI can scrub the transmitter spec sheet, pair it with the detection platform’s capabilities, and compress work that used to take weeks or months into hours. I’ve already watched this happen with various systems, because you’re drawing on a huge body of prior work.
The biggest challenge will still be unknown signals. But AI has the potential to search for characteristics across any collection you’ve ever made. Bottom line, it’s a force multiplier for people doing difficult signals analysis work, and it should make our collection and detection systems far more effective.
EEWorld: What does a verification-first AI workflow look like day to day for an engineer used to a linear design-then-test process?
Brian Neff: In my flight test background, we’d typically receive a system already designed to a specification. Our job was to develop a test plan that verified the aircraft or subsystem met those requirements, sometimes in parallel with delivery. Verification was always central, but it generally followed implementation.
A verification-first workflow flips that around. From the beginning, you define how success will be measured. What signals will you inject? Which performance metrics matter? What counts as a successful outcome? Once those questions are answered, AI can generate the instrument, signal processing chain, or implementation needed to meet those requirements.
I’ll foot-stomp this one: it doesn’t eliminate testing. It reinforces it. The difference is that verification becomes part of the design process instead of something that happens late in the program.
EEWorld: Does that require a new mindset? You mentioned parallel. Is verification happening alongside design, or does it still have to come after?
Brian Neff: Verification-first means you decide what you’ll measure before you implement anything. The parallelism comes from speed. You can review results, refine the design, and even refine test conditions or methods much faster than before, iterating through all of it together.
EEWorld: For an engineer who’s spent a career hand-coding test sequences, what does the first week working this way feel like? What’s the hardest habit to unlearn?
Brian Neff: Early in a career, it’s fun to sit down and write code or procedures. How many lines of code you could write and validate in a day was almost a badge of honor.
That’s the habit to unlearn. Productivity won’t be measured by how much code you write or how many algorithms you employ. Your value will be in defining the problem correctly, recognizing when a solution is wrong, understanding the trade-offs, and validating the results.
To go back to your cliché, garbage in, garbage out. What matters isn’t how much you produce. It’s how many well-validated, refined tools you produce.
“The most effective engineers will be the ones who leverage AI without outsourcing their engineering judgment.”
EEWorld: AI gives you the edge. It doesn’t replace you.
Brian Neff: Engineers will also approach this differently depending on their career stage. New engineers will be comfortable collaborating with AI from day one. It probably helped them get through school. People who’ve been in the industry for a decade or more didn’t have that tool, so there will be more trepidation. Eventually it will become a normal, accepted tool.
But the most effective engineers will be the ones who leverage AI without outsourcing their engineering judgment. That won’t depend on when you entered the field.
EEWorld: I couldn’t agree more. Engineers with 10 or 20 years of experience bring that healthy skepticism we talked about, and they won’t let younger engineers lean too hard on AI. The AI-savvy younger engineers will show them what the tool can do. Each side keeps the other honest.
That’s part two. In part three, we’ll ask whether AI-generated test systems should be held to a higher standard. If you missed part one with the video interview, where we defined what hardware AI actually is, catch up there first. Thanks, Brian.
Brian Neff: Thank you.