What happens when an AI agent finishes a firmware change in an hour, but the verification queue holds it for three days?
The change passes its unit tests. It passes the firmware test suite. The code review takes twenty minutes. By 10 AM it is ready to ship.
Then it waits.
The cross-domain verification that confirms the new state machine works with the current app and the current cloud backend is a manual process. One engineer runs it, once a week, the day before release. The four days the agent saved never reached the customer. The change still shipped the following Thursday.
For connected products, that manual cross-domain pass is the bottleneck on how fast agent code reaches production. Automate it, and the team ships at the speed the agents write, instead of waiting days for one person to get to the queue.
The four days the agent saved never reached the customer. The change still shipped the following Thursday.
Why does the cross-domain gate stay manual?
Because testing a firmware change against the real app on a real phone talking to a real cloud backend needs physical hardware, coordinated timing, and a test environment that spans all three domains at once. Most teams run it by hand, or half by hand, with scripts that still need an engineer to set up the device, launch the app, and watch the result.
When development was slow, a weekly manual pass could keep up with the changes. When agents produce three or four unit-tested changes a day, that same pass becomes the constraint. The changes queue up, waiting for the one engineer who runs the full-stack verification.
What do AI agents need to close the loop?
Feedback they can read. An agent can trigger automated tests, read the results, interpret a failure, and iterate on its own code. It runs the whole write-test-fix cycle on its own, as long as the test infrastructure answers it.
Unit tests cover logic. Firmware tests cover compilation and static analysis. Cross-domain verification covers whether the product works end to end. The first two already answer an agent. The third usually doesn't.
Agents need tests that exist, that cover the cross-domain interactions, and that return results programmatically.
Agents need tests that exist, that cover the cross-domain interactions, and that return results programmatically. When the cross-domain scenarios are automated, an agent triggers them, waits, and acts on a failure the same way it acts on a failing unit test. The loop closes, and the agent's speed becomes the team's speed.
When those scenarios are manual, the agent's speed stops mattering past the coding stage. The code gets written fast, reviewed fast, and then it waits.
The gap between coding speed and shipping speed
Cross-domain validation usually gets sold as a quality improvement. When agents do the coding, it does something more basic: it gives the CTO validation that the whole product works end to end, running in the loop as the agents build.
A team with agents and manual cross-domain verification writes code at agent speed and ships at manual-verification speed. A team that automates that verification ships at the pace the agents write, because the work arrives validated end to end as it lands.
The investment case flipped. A year ago, cross-domain validation was a quality investment, paying back in fewer field bugs and lower support costs. Today, it's a speed investment: validation running in the loop as the agents work is what lets the team ship at the pace agents produce code.
Today, it's a speed investment: validation running in the loop as the agents work is what lets the team ship at the pace agents produce code.
The agents are already fast. The open question is whether the verification infrastructure lets the team keep up.