DEV Community: Oleh Veheria

AI Agent Workflows for Engineering Teams: What Actually Works

Oleh Veheria — Sat, 22 Aug 2026 15:43:17 +0000

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.

Every PR review is really two jobs stacked on top of each other. Mechanical verification: does it build, are edge cases handled, did someone forget to localize a string, is the naming consistent with the module. And judgment: is this the right abstraction, does it fit where this code is heading, will it bite us in six months. Humans are slow at the first and irreplaceable at the second. Classic review forces senior engineers to do both, so the mechanical part crowds out the judgment part until reviewers skim, type LGTM, and architectural drift accumulates one skimmed PR at a time.

The agent's job is the first stack. Never the second.

What actually worked

A first-pass reviewer on every PR. Agents fan out over the diff before any human looks, one dimension each: correctness and edge cases, consistency with surrounding patterns, whether tests cover the behavior change or just mirror the implementation, and mobile-specific checks like hardcoded strings and touch targets under 44pt. Every finding has to cite a file, a line, and a concrete failure scenario. A finding with no failure scenario gets dropped. That one rule is the difference between useful output and "consider improving readability" noise. I wrote up the exact mechanics in a separate post on the review workflow; the point here is that this is where the measured 30 minutes came from, not from code generation.

The metric decided before deployment. My biggest process mistake: I set the metric of record after the agents were already running, so for the first stretch I was tuning against a feeling. Decide what you are optimizing before an agent touches the workflow. For us it was review-cycle time held against review quality, not lines generated, not tickets closed. An agent optimizes exactly the proxy you hand it, so the proxy has to be the real goal.

A human owns every architectural decision. Module boundaries, offline-first, when to break MVVM, when not to rewrite. The agent executes those decisions faster once a person has made them. It does not make them. On a Williams-Sonoma build I stood up a modular SwiftUI codebase so two shopping apps could share it; that call, and the taste behind it, is not something I would ever hand to a model. Agents scaled the wiring underneath it.

What did not work, and what I would do differently

The ticket-speed agent is the clean example of the general failure: an agent with a prompt but no encoded intent will optimize the nearest measurable proxy and confidently ship the wrong thing. The fix is not a better model. It is encoding review taste and product intent into the workflow itself, the same standards a senior reviewer would apply, so the agent is pointed at the real goal instead of a number that correlates with it on a good day.

The second thing I would change is trust calibration. Early on I let agents touch too much at once and spent the saved time re-reviewing their output, which defeats the purpose. Draw the line explicitly: what the agent is trusted to do unattended, what it drafts for a human to approve, and what it never touches. That line is the whole design. Get it wrong toward trust and you inherit debt; get it wrong toward caution and you built an expensive linter. The same boundary question runs through my whole Claude Code iOS workflow: the setup is an afternoon, deciding where the agent may make decisions is the months-long part.

A framework you can actually apply

If you lead a team and want agents in the workflow without the theater, four questions in order:

What is slow because it is mechanical, not because it is hard? That is your first candidate. Review triage, test scaffolding, changelog and release notes, flagging missing localization. Not architecture, not product decisions.
What is the metric of record, decided now? Write it down before anything runs. If you cannot name it, you are not ready to deploy an agent against it.
Where is the human explicitly in the loop? Name what the agent does unattended, what it drafts for approval, what it never touches. This is a design decision, not a default.
What did you standardize versus leave autonomous? Standardize the few things that compound, the review bar and the definition of done, and leave the rest to the team. When I ran mentorship and review standards across EU locations, standardizing everything would have killed local ownership; standardizing nothing meant quality drifted. Agents make this sharper, because whatever you standardize, the agent will enforce relentlessly and literally.

None of this requires a swarm architecture or a control plane. It requires taking one pattern you already trust by hand, deciding what you are measuring, and moving it onto a trigger with a clear human boundary. Start with the smallest mechanical task you are sure about. Measure it against the number you wrote down first. Expand only where the measurement earns it.

The teams that get value from agents are not the ones with the most agents. They are the ones that kept judgment human and were honest about which of the two review jobs they were actually automating.

If you are working out where agents fit in your team's workflow and want a second opinion from someone who has measured it on a real product, that is what I do in a strategy session.

What is the one mechanical task on your team that everyone hates and no one would miss doing by hand? That is almost always where to start.

Originally published at veheria.tech/blog/ai-agents-engineering-team-workflow.

A Claude Code Review Workflow That Saved 30 Minutes Per Engineer a Day

Oleh Veheria — Sat, 22 Aug 2026 15:43:16 +0000

Code review is where mobile teams quietly lose a day per engineer per week. Not writing reviews. Waiting for them. I put Claude Code agents into the actual review loop for a multinational iOS team as the first pass on every PR, and in my own measurement it saved about 30 minutes per engineer per day. Review-cycle time came down and review quality held. Human reviewers went back to arguing about what actually matters: design.

This is the exact workflow, including the parts that didn't work.

The problem with human-first review

Every PR review mixes two very different jobs:

Mechanical verification. Does it build, are edge cases handled, is the naming consistent, did anyone forget to localize a string.
Judgment. Is this the right abstraction, does it fit where the module is heading, will this bite us in six months.

Humans are slow at the first and irreplaceable at the second. Classic review forces senior engineers to do both, so the mechanical part crowds out the judgment part. Reviewers skim, LGTM, and the architectural drift accumulates one skimmed PR at a time.

The workflow

I run Claude Code as a first-pass reviewer on every PR, before any human looks at it.

1. Agent review on PR open

A multi-agent review fans out over the diff, one agent per dimension:

Correctness: edge cases, nil-handling, concurrency. The classics that slip through when a human skims 400 changed lines.
Consistency: does the code match surrounding patterns, naming, error-handling idioms, module conventions.
Tests: do the tests actually cover the behavior change, or do they just mirror the implementation.
i18n and accessibility (mobile-specific): hardcoded strings, missing Dynamic Type support, touch targets under 44pt.

Each finding has to cite a file and line and describe a concrete failure scenario. A finding with no failure scenario gets dropped. That single rule is what keeps the output from turning into "consider improving readability" noise.

2. Author fixes before human review

The author gets findings in minutes, not hours. Mechanical issues die before a senior engineer ever context-switches into the PR. By the time a human opens it, the diff is clean enough that the review is about design.

3. Human review, redefined

Human reviewers now have one job: judgment. Module boundaries, API shape, whether this feature belongs here at all. The stuff I wrote about in iOS Architecture Decisions AI Can't Make is still 100% human, and now it actually gets the attention it needs instead of losing the reviewer's last hour to a missing nil check.

What didn't work

Auto-merge on green agent review. This is the one I regret shipping first. An agent with a prompt but no encoded intent optimizes the nearest proxy, "tests pass", not the real goal, "this change is correct and worth merging". It happily green-lit changes that satisfied the letter of the tests and missed the point. I pulled auto-merge and put a human back on the merge button. The agent advises, the human decides.

One mega-agent instead of dimensions. A single "review everything" pass produces shallow findings. Fan-out with narrow lenses is what surfaces the real bugs. The correctness agent is not distracted by naming, so it actually reasons about concurrency.

Deploying the agents before I had a metric of record. I measured the 30 minutes after the fact and had to reconstruct the baseline. I should have agreed the number I cared about, and how I would measure it, before the first agent ran. If I did this again, that would be step zero. I made the same mistake again at a much smaller scale shipping llms.txt on this site, and what I'd do differently there is the same fix: decide how you'll know it worked before you ship it.

What I actually measured

I am only going to quote what I measured, because a post like this lives or dies on that. On that multinational iOS team, over months of daily use: about 30 minutes saved per engineer per day, review-cycle time down, and review quality held (the human bar did not drop when the mechanical pass moved to an agent). I did not instrument escaped-defect rate or reclaimed senior hours cleanly enough to quote them, so I won't.

Where to start

Don't automate your whole review culture in a week. Start with one dimension (consistency is the safest), one repo, findings as suggestions, not gates. Keep the human on the merge button. Expand only when the team starts trusting the signal on its own. The review loop is one instance of a broader pattern; I wrote up how to choose and bound the rest in AI agent workflows for engineering teams.

If you want help setting up an AI-assisted engineering workflow for your team, the architecture, the tooling, and the change management around it, that is exactly what I do in strategy sessions.

One question I am still working out: where is the line for you between an agent that advises and an agent you would actually let merge? I have not found a team comfortable moving that line yet, and I would like to know if yours is.

Originally published at veheria.tech/blog/claude-code-code-review-workflow.