Teams testing AI agents keep hitting the same wall. The agent does its job, the task that used to take two days finishes in five minutes, and then the output waits a week in a review queue nobody thought to redesign. The tool worked exactly as advertised and the calendar didn’t move.
That gap is where most AI rollouts stall, and it gets easiest to see in teams that build physical products. Half of a hardware development cycle runs on lead times, procurement approvals, and bench validation that no amount of prompting will compress. When an agent collapses one segment of that loop and the rest of it holds still, the process doesn’t get faster so much as it gets lumpier.
The tools got fast before the processes did
Adoption stopped being the interesting variable a while ago. McKinsey’s 2025 global survey on AI found 88 percent of respondents say their organizations regularly use AI in at least one business function, up from 78 percent the year before, and yet only about a third have started scaling it across the enterprise. Most companies are sitting on a pile of pilots that work fine in isolation and change nothing about how the business runs.
The same survey names what separates the two groups, and it isn’t budget or model choice. AI high performers are nearly three times as likely as everyone else to have fundamentally redesigned their workflows as part of the effort. The companies getting real returns rebuilt the process around the tool. The ones stuck in pilots dropped the tool into a process built for the old speeds.
Software teams show the same split with harder numbers. DORA’s 2025 report on AI-assisted development, built on responses from nearly 5,000 technology professionals, found 90 percent now use AI at work and more than 80 percent say it made them more productive. Throughput went up. So did instability, change failures, and rework, which is why the report lands on the conclusion that AI amplifies whatever a team already is. Strong processes get faster, and weak ones get faster at producing mess.
An agent only touches part of the loop
It helps to lay out what a hardware development cycle actually contains before deciding where an agent fits. Someone specs a part. The part gets fabricated or ordered, which takes days or weeks. Someone assembles it, someone writes firmware to drive it, and that firmware gets brought up on the bench, tested, reviewed, and revised.
An AI agent touches two or three of those steps. It reads an unfamiliar codebase, writes a first pass of firmware, scripts a motion routine. Every other step in the loop runs on its old clock, because lead times, procurement approvals, review meetings, and sign-off don’t care how fast the code arrived. A large local gain gets swallowed by a process that never changed shape around it.
This is why pilots look spectacular in a demo and flat in a quarterly report. The demo measures the step, and the report measures the loop. Any team evaluating agents on task-level speed alone is measuring the thing that was never the constraint.
What the measured gains actually look like
The compression on the steps agents do touch is real and worth understanding in specifics, because the scale of it is what breaks the surrounding process. One device development team published documented bring-up times on real hardware, showing an eight-hour Arduino sensor integration dropping to roughly ten minutes and a three-axis gantry executing commanded motion in five minutes rather than two days. Comprehending an unfamiliar firmware codebase fell from three or four days of reading and tracing to about ten minutes.
Numbers like that are narrow in a way that’s easy to miss. They describe a segment, not a project, and nothing about them touches the five-week lead time on a machined part or the Thursday design review. What happens instead is counterintuitive. Total cycle time drops, and the share of that cycle spent waiting goes up, because the work that used to fill the gaps between reviews now finishes in an afternoon while the reviews stay exactly where they were on the calendar.
The bottleneck moves, it doesn’t disappear
Speed up one step and the constraint relocates to the next slowest thing, because every process has one and it never volunteers its new location. Compress firmware bring-up from three days to ten minutes and a queue forms somewhere else, at design review or part procurement or documentation or whoever signs off. That relocation is the mechanism behind the instability DORA measured. Local speed gains get absorbed by whatever nobody bothered to redesign, and the absorption is invisible until someone measures the whole path.
Finding the new constraint takes four honest questions. Which step is holding the most unfinished work right now, and who has to approve the agent’s output before it can move? How long does that approval take when you measure it instead of estimating it, and what happens to the queue when the person who owns that step takes a week off? Teams that answer those usually find the bottleneck sitting in a recurring calendar invite rather than in anybody’s tooling. A weekly design review that used to gate half a day of finished work now gates four days of it. The meeting didn’t get worse, the work behind it got faster, and nobody adjusted.
Write the checkpoint into the procedure
Faster output raises the stakes on review, because agents fail in ways that look fine at a glance. They hallucinate, they introduce bugs into code that was working the day before, and catching that takes somebody who understands the underlying system rather than somebody skimming a diff. DORA found 30 percent of respondents report little or no trust in the code their AI tools generate, even with adoption close to universal, which is a strange thing to tolerate at scale without a written verification step.
That distrust doesn’t argue against using the tool. It argues for putting the checkpoint in writing instead of leaving it to whoever happens to be careful that week. In practice that means three decisions made once and documented: the unit of work you’ll prompt for, whether that’s one sensor or one function or one ticket, the name of the person who reviews the output and what passing actually looks like, and the rollback path, since version control stops being optional the moment a tool can quietly break something that worked yesterday.
None of this is new thinking. The discipline comes straight out of SOPs in regulated and high-stakes industries, where a procedure only counts if someone wrote it down and someone owns it, and where the audit trail matters as much as the outcome. You don’t need an inspector showing up to benefit from that habit. You just need a process that survives a vacation, a new hire, and a bad week.
Redesign the cadence, not just the tooling
This problem extends well past engineering benches. AI agents across manufacturing operations are already handling production scheduling, quality checks, and predictive maintenance, and every one of those deployments creates the same downstream pileup when the reporting and approval rhythms around them stay fixed. The fix is unglamorous and mostly involves changing the shape of the process rather than buying anything else.
Shrink the batch. Review one working change at a time instead of a week’s accumulation, and move review off the calendar and onto a trigger so work gets looked at when it’s ready rather than on Thursdays. Cap work in progress so the fast step can’t flood the slow one, which feels backward right after a tool made you faster, until you notice that an unreviewed pile of agent output isn’t progress at all. It’s inventory, and it hides defects until they cost more to fix.
Give every handoff a named owner and a backup, then measure the path start to finish. Individual task times will look spectacular no matter what you do, and total cycle time is the only number that reaches a budget. Start with one process and one agent, time the steps honestly, and expect to repeat the exercise when the constraint moves again.
Ask whether your workflow is ready
The interesting question stopped being whether these tools work, because the measured evidence says they do on the specific steps they touch. The open question is whether the process around them has caught up, and for most teams the honest answer is no. That applies to a support desk, an agency, or a finance department as much as it does to a hardware bench. Any process where one step got fifty times faster and everything after it stayed the same has the same problem.
The agent is the easy part. Redesigning the twelve steps around it is the work, and it’s the work that shows up in the numbers.
