You watch an agent produce a code change that would have taken a senior engineer two days. The code is clean, the tests pass, and the commit message reads like a senior engineer wrote it.
So for a moment you wonder what this means for your job. If the machine writes firmware faster than your best people, what does a VP of Engineering do on Monday morning?
The work moves toward more judgment, not less. When code output becomes cheap, the decisions about what to build, what quality bar to set, and how to verify that output become the scarce resource.
When code output becomes cheap, the decisions about what to build, what quality bar to set, and how to verify that output become the scarce resource.
Those are leadership decisions. They run on product judgment, customer understanding, and knowing what has broken before. An agent has none of that.
The person who has spent years learning which version combinations fail in the field, which hardware errata affect which production boards, and which customer workflows cross the seams between firmware, app, and cloud: that person's judgment is what turns fast code into safe code.
What decisions become more important when agents write code?
Every change from an agent needs someone to decide how hard to look at it. A change to a logging format is different from a change to the Bluetooth Low Energy (BLE) pairing sequence. A firmware update that only touches the latest hardware revision is different from one that reaches three-year-old boards sitting in a warehouse.
The agent can't tell which is which. You can.
The VP who has been through two hardware revisions knows which firmware-app combinations break. The engineer who spent a month in the field chasing intermittent disconnects knows which radio timing margins are safe and which hide a 2% failure rate. That kind of knowledge, the kind that builds up over years of shipping products and reading support tickets, gets more valuable the moment agents produce changes faster than anyone can verify by hand.
So the judgment calls multiply. Some changes need a deep read from your most experienced engineer. Some cross-domain flows need full verification before they ship.
The undocumented constraints, the hardware errata and timing quirks and silicon stepping differences, need writing down, so the agent can be handed them as context next time. Each of those is a call that needs knowing the product, the fleet, and the failure history.
Take a concrete one. An agent refactors the way your device reports sensor data over BLE. The change is clean, the unit tests pass, the new code reads better than the old.
But the previous format carried a padding byte the Android app relies on to parse, a quirk added two years ago to work around a Bluetooth stack bug on Samsung phones. Nothing in the codebase records it. The engineer who fixed the Samsung issue carries it in their head.
Whether the refactor ships or gets sent back depends on whether that person sees it, and that routing decision is yours.
How does the team structure change?
Code review becomes the primary engineering skill. When writing code was the bottleneck, the fastest authors set the pace.
When agents write the first draft, the people who can read code closely, spot the cross-domain implications, and see how a firmware change lands in the app and the cloud become the most valuable people on the team. The senior-engineer profile shifts from typing speed to reading, questioning, and verifying.
Building that across the team is leadership work. Deciding who reviews what, pairing junior engineers with senior reviewers on cross-domain changes, marking which changes need a second set of eyes: those choices decide whether agent velocity turns into shipped quality or shipped risk.
An agent can produce ten changes in a day. Whether those ten improve the product depends on who reviews them and what they know.
So your role shifts from unblocking authors to building a review organization. That means recognizing reviewers, giving them good tools, and treating turnaround time as a first-class metric. It also means writing down the knowledge that lives in senior engineers' heads, because every constraint on paper is one more thing the agent can be told and one fewer thing a reviewer has to catch from memory.
This is where a VP's experience becomes structural. You carry a map no agent will: which three engineers can spot a cross-domain problem in a firmware change, which people are still learning that skill and need mentoring, which parts of the codebase hide undocumented timing dependencies that trip up anyone who wasn't there for the original incident. Spreading review capacity across those lines is a leadership call no agent can make, and it decides whether the team banks the productivity gain or drowns in review debt.
What does a Monday morning look like?
You come in to six changes from agent sessions, with more landing through the day.
Two are easy: a logging improvement and a unit test for an existing module. A junior engineer handles both with light guidance.
One touches the over-the-air (OTA) update path, which has a history of subtle failures when the device already took a prior update. That goes to your most experienced firmware engineer.
Two change the BLE characteristic format, so the app's parsing has to be checked against them. For those, the agents run the full cross-domain suite on their changes and act on the results before anything reaches review. You decide which changes need that level of validation.
The sixth refactors the power management state machine. It compiles, the unit tests pass, the commit message explains the change clearly. But you remember three customers reporting battery drain last quarter, and the cause was a race between the radio wake and the sensor sampling timer. That history lives in a support ticket, not in the code. You send it to the engineer who debugged it and ask them to confirm the refactor keeps the timing fix.
None of this is new work. You made these calls before agents existed, every time a contractor sent a change or a new hire pushed their first code.
What is new is the volume and the pace. Six changes at once instead of six a week. The judgment is the same. Spending it well, and writing down the reasoning so it feeds the next review, is what the pace demands.
A step you can take this week: list the three cross-domain flows that would cause customer-facing incidents if they broke. Device onboarding, OTA updates, and cloud-to-device commands are the usual suspects, but your list will fit your product and your customers.
If only one person on the team can name all three, that is the first thing to fix. Write them down, assign review ownership for each, and make sure the next agent change that touches any of them gets the right eyes before it ships.
The agents will keep getting faster. The code will keep arriving. Your leadership, the judgment about what matters, who reviews it, and how the team checks it, is what makes that speed worth having.
What could your team hand to the agents if their work arrived validated across firmware, app, and cloud? See the platform.