There’s a belief going around that you can prompt your way to anything. Hand the AI a problem, walk away, come back to working code.
Fine for a side-project web app. Does not work for an inverted pendulum spinning on your desk.
The Pit and the Pendulum
MathWorks just published a Tech Talk by Brian Douglas. It is worth watching if you build hardware.
The setup is a Quanser cube servo with an inverted pendulum, a Raspberry Pi running the controller, and a coding agent wired into Simulink through the Simulink Agentic Toolkit. The agent’s job is to swing the pendulum up and balance it.
Balancing an inverted pendulum is a classic control problem because it’s unstable by nature. Get the math wrong and the pendulum falls. Get the code wrong and a 12V motor jerks the cube into something it shouldn’t.
What Happens If You Just Prompt It
The tempting move is the one most of us have done with web apps. Open a chat, describe the system, ask for the code. One prompt, big blob, ship it.
The MathWorks engineers walk through why that falls apart for hardware:
“If you rely on AI to generate code directly, that process is much less structured… it’s often unclear exactly how or why a particular implementation was created, making it harder to trust and verify.”
Brian Douglas
Hardware is unforgiving. You can’t roll back a destroyed motor with a git revert. When a physical system fails, you need to know which assumption broke, which equation got the wrong constant, which sample rate the controller is actually running at. A black box of generated C code doesn’t tell you any of that.
“You don’t want to let your AI agent skip parts of your engineering workflow. That’s how you can get yourself into trouble with a final product that doesn’t meet your objective or worse, is just purely unsafe.”
Brian Douglas
The Workflow Is the Script
The answer is to keep the AI inside the workflow engineers already trust: Model-Based Design. The agent doesn’t replace the workflow. It runs each step inside it, faster.
Define quantifiable requirements. Before any code, the human and the AI agree on what success looks like. Spin-up speed. Wobble limits. The 12V motor constraint. These targets become the benchmarks for verification later.
Use a trusted model. Instead of letting the AI invent a custom physics engine, the workflow points it at an existing Simulink model. The agent runs linearization through the Simulink Agentic Toolkit and reports the system’s poles back to the human. The math comes from validated tools, not from a language model freestyling differential equations.
Use a trusted controller. Same logic. The agent is told to use the MPC Toolbox. Model Predictive Control has decades of theory behind it and a deterministic implementation. If something looks wrong, you can tune it manually. You’re not debugging an optimizer the AI invented on the fly.
Verify in layers. Three stages before the code touches hardware:
- MIL (Model-in-the-Loop): the controller runs against the theoretical model
- SIL (Software-in-the-Loop): the generated embedded C code runs on a computer, behaving exactly like the simulation
- PIL (Processor-in-the-Loop): the C code runs on the actual target Raspberry Pi
Each layer catches different bugs. Skip one and you’ll catch that bug on hardware instead.
Deploy and iterate. Only after layered verification does the code go on the real pendulum.
“Instead of asking an agent to solve your problem however it wants, you tell it to follow an engineering workflow that you understand.”
Brian Douglas
The AI executes. The human directs.
The Hardware Truth
Here’s the part of the video I liked best. They ran the verified controller on the real pendulum and it didn’t quite work. The physical hardware behaved differently from the model.
This is what the vibe-coding fantasy ignores. Reality disagrees with simulation, especially the first time. You will need to iterate. The thing that matters is whether you can.
Because the team followed the workflow, they could. The model was traceable. The requirements were quantifiable. The controller was inspectable. They used the AI to update the physics model, ran it back through MIL, SIL, and PIL, and tried again. No starting over.
The workflow doesn’t promise perfect code on the first pass. It promises code you can fix.
The Director Pattern
A few months ago, I wrote about Seth DeLand’s framing of agentic AI for engineers. The headline idea: you’re not being replaced, you’re being promoted. The engineer becomes the one who defines the problem, sets the constraints, and shapes the space where the AI works.
The MathWorks Tech Talk is what that looks like in hardware. The AI isn’t the engineer. It’s the agent. You’re the director.
“Agentic AI is powerful, but for engineering, the value comes from how you use it. You get the speed and productivity benefits of AI without sacrificing trust, safety, or understanding.”
Brian Douglas
You don’t get speed and safety together by handing the AI a prompt and crossing your fingers. You get there by keeping the workflow you trust and letting the agent move faster inside it.
Speed without losing safety. Productivity without losing traceability.
For software, vibe coding is mostly fine. The blast radius is a wasted afternoon.
For hardware, the blast radius is a sparking motor and a pendulum on the floor.