How a hardware bottleneck became a synthetic test bench that takes direction in plain English.
Every team building software for physical devices hits the same wall. Boards take weeks to revise. Specifications change late. And the failures that matter most are precisely the ones nobody can stage safely: you can't test against a thousand real hubs, you can't make a real propane tank run dry on a schedule, and you definitely can't trigger a real catastrophe on demand to see whether the mobile app handles it gracefully.
The traditional answer is to write software against the spec manual and hope. Features get built blind, integration with physical boards happens at the final stretch of the pipeline, and minor logical bugs surface late enough to become expensive, sometimes hardware-destroying, failures.
On a recent client engagement, we at Red Foundry took the opposite approach: build the synthetic environment first, and give every developer a fleet of devices on their laptop from day one. Using Claude Code, we built the emulator in a fraction of the time a hand-built version would have taken. Then we put an AI layer inside the emulator itself, and it changed who gets to run a test.
The Virtual Wireless Bench
Our client is a manufacturer of consumer HVAC and power sensors with a companion mobile application. Their product is a hub that monitors a household of devices: power systems, batteries, climate sensors, doors, thermostats, and a propane tank.
Working in Claude Code, we fed the hardware schema directly to the AI layer and had it generate the virtual environment: standard state metrics, interface definitions, and simulation logic for the full device tree. The result models a complete hub of ten sensors producing roughly 22 live readings, and it goes well beyond replaying canned data.
Multi-tenant by default. The bench spins up unlimited independent hubs at once, each with its own sensor state and its own MQTT topic. Every developer gets a fleet, instantly, with no provisioning, certification, or wiring.
Realistic, continuous simulation. Every sensor drifts on a roughly one-second tick with mean-reverting, physically plausible behavior. Voltage sags and recovers. Temperature responds to thermostat state. Nothing sits frozen at a hardcoded value, so the application under test experiences the same living data stream it would see in the field.
A fault model on every reading. Each sensor carries a plausible fault threshold and a fault status flag, making boundary conditions a designed part of the simulation instead of an afterthought.
Real transport, no shortcuts. In normal mode the emulator connects with device certificates and publishes telemetry through AWS IoT Core over MQTT, exactly as production hardware does. A REST API and a live web control panel round out the interfaces.
Modeling a dozen sensors with realistic physics, fault logic, a control panel, and a test suite is a large amount of careful, tedious code. Claude Code wrote the bulk of it. The build cost collapsed from a project into a sprint.
Steering the emulator in plain English
Fast construction was the first win. The second one reaches further.
The AI layer we embedded inside the emulator surfaces as a single scenario field in the control panel. Instead of editing code or nudging sliders to stage a situation, you describe the situation and the emulator becomes it.
Type "all is well" and every sensor settles into normal operation. Describe a stressed system, and the bench pushes out voltage fluctuations, bad sensor readings, and packet failures so you can watch how the application holds up at its boundary limits. Test design moves from "write a fixture" to "describe the situation."
That shift matters beyond the engineering team. A QA lead, a support engineer, or a product manager can now say "show me what a customer sees when their tank is critically low and the door's been left open" and watch it play out on the companion app in real time. No code, no hardware, no waiting for someone to build the scenario.
What emulation-first changes
Three outcomes stood out from this engagement, and they generalize well beyond this client's product.
Edge cases become a line of config. The bugs that matter live in the fault states: a sensor browning out, a door flapping, a tank near empty, the network dropping mid-publish. On real hardware these are rare, dangerous, or impossible to stage on demand. In emulation they are trivially repeatable, which means they actually get tested.
Chaos testing becomes routine. Pairing dropouts, erratic Bluetooth failures, and injected system friction stop being special events and join the everyday validation loop. The application ships having already survived the situations that would otherwise become support tickets.
Resilience gets validated before hardware exists. We confirmed that client devices handle failures gracefully, without lagging, locking up, or crashing, while the physical boards were still moving through manufacturing. Hardware delivery and software validation stopped being sequential.
One principle sits underneath all of it:
Fake it before you make it. An AI hallucination in a simulated testing environment is a breakthrough. An AI hallucination in physical production is a recall.
Ready to scale your engineering?
If your team is staring down a hardware bottleneck, a stuck rollout, or a vibe-coded prototype that needs to become a real product, we can help you map the path from prototype to production-grade reality.
