The first agent workflow I put in front of an engineering team optimized the wrong thing beautifully. It had a clean prompt, it closed tickets fast, the burndown looked great. It also shipped work that was technically done and missed what the customer actually needed, because "ticket closed" was the only signal it had. That failure taught me more about agent workflows than any of the ones that worked.
Most of what you read about AI agents for engineering teams is written by people selling the platform. It describes the architecture diagram, not the Tuesday. I put Claude Code agents, MCP servers, and browser automation into the real review and test loop for a multinational iOS team, and in my own measurement it saved about 30 minutes per engineer per day without dropping review quality. Here's what actually moved that number, and what quietly wasted our time.
The mistake: automating output instead of judgment
The seductive pitch is that agents write the code, so engineers write less. That is the part that works least well and matters least.
An LLM gives you the average of the internet. In Swift, where there is less training data than in JavaScript or Python, that average is worse. So an agent left to generate freely produces plausible code that a senior engineer then has to read line by line to trust, which is not obviously faster than writing it. The time did not come from letting agents build. It came from letting them do the mechanical verification a human is slow at and bored by.
