How I AI: Daniel Roth’s Dueling Agent Workflow for Building iOS Apps

Daniel Roth is not an iOS engineer. He is a business writer and editor at LinkedIn who builds apps on weekends, largely by managing AI agents that can do the coding he cannot.

In this episode of How I AI, Daniel shows the system behind Commutely, an app that answers a very New York question: can I walk to the train, or do I need to run? His workflow pairs two Claude Code agents with deliberately opposing jobs, then keeps Daniel in the middle as the product owner and tie-breaker.

The interesting part is not that Claude can write Swift. It is that Daniel has designed a small organization around the model: one agent builds, one agent reviews, and a human decides what is good enough for the customer.

Start with the customer, even when the customer is you

Daniel describes himself as a picky customer rather than a software architect. That distinction gives him a useful advantage. He does not begin by asking what the code should look like. He begins with the experience he wants on his commute and the tradeoffs he is willing to accept.

His app already knew the train schedule. The feature in this episode adds a scheduled Live Activity that appears around 7:00 AM on weekdays, so the relevant departure is waiting on the phone before he leaves home. The product requirement is concrete: useful information at the moment of departure, without opening the app.

He uses Claude to keep a running feature tracker and rank ideas on three dimensions: estimated build time, likely back-and-forth effort, and potential impact. The impact can mean customer happiness, retention, or growth. Each dimension gets a simple one-to-three score.

The AI feature-prioritization workflow turns that lightweight scoring system into a repeatable backlog review. It is not a substitute for judgment; it makes the tradeoffs visible enough for Daniel to choose.

Because he returns to the app on weekends, Daniel also asks the agent to write decisions, plans, and open questions to Markdown. He jokes that both he and Claude forget what happened. The files become the durable memory neither side can reliably hold alone.

Give the builder and reviewer different incentives

Daniel runs two Claude Code sessions side by side. Bob is the builder. Ray is the reviewer. They use the same underlying model, but their instructions create different incentives and different definitions of success.

Bob owns the build

Bob is told to plan before coding, work modularly, document the implementation, and take responsibility for the result. Bob may delegate pieces to subagents, but cannot pass accountability to them. When the plan or implementation reaches a meaningful checkpoint, Bob must bring it to Ray.

That last instruction matters. A coding agent naturally wants to continue from plan to code to completion. Daniel inserts review into the workflow before momentum becomes a reason to skip it.

Ray is paid to disagree

Ray is framed as a senior engineer reviewing security, architecture, design quality, and member trust. Daniel explicitly tells Ray not to rubber-stamp Bob. Ray cannot spawn more reviewers, so the opinion remains legible and attributable.

The two personas are not theater. A builder optimizes for making the requested change work. A reviewer optimizes for finding what the builder missed. Separating those contexts produces a more useful argument than asking one long-running agent to critique its own decisions.

Keep one piece of friction on purpose

Daniel copies plans and review feedback between the two terminals. He could automate that handoff, but chooses not to. The copy-and-paste step forces him to read what Bob proposes, understand Ray's objection, and decide which direction serves the product.

That is where he learns. If Bob and Ray disagree, Daniel breaks the tie. If both agents focus on technical elegance while missing the customer experience, Daniel acts as the picky user. The workflow increases his technical range without pretending that he has stopped being responsible for the decision.

The complete dueling-agent workflow includes example role prompts for both agents and the handoff points between planning, review, implementation, and testing.

Plan, review, build, then test the real product

For the scheduled Live Activity, Bob first inspects the repository and writes an implementation plan. Ray reviews the plan for architectural and product risks. Bob revises it, writes the code, and returns the diff for another pass.

Daniel learned to require a feature branch after an earlier agent merged directly into main. That small rule protects the working app and makes the review loop reversible. It is exactly the kind of lesson worth encoding in persistent project instructions.

The agent can clean the Xcode build, compile, and launch the simulator. Daniel still checks the experience on his phone because the simulator gets him only about 80 percent of the way there. Notifications, timing, permissions, and the feel of a Live Activity all need the actual device.

From there the build goes through TestFlight and then the App Store. Daniel sees App Store submission as the remaining major friction: the coding loop is increasingly agentic, but distribution still demands human-operated steps and judgment.

Use the agent to learn management, not syntax

Daniel is not trying to memorize Swift. He is learning how to define a result, delegate work, read a plan, resolve competing recommendations, and insist on evidence. Those are management skills expressed through software development.

When an agent fails, he gets direct. He reminds it that the answer exists in project memory or that they have solved the problem before. The useful move is not a magical prompt phrase; it is pointing the agent back to the source of truth and restating the expected outcome.

The result is personalized software that would not have justified a conventional development team. A commute app for one exact routine can still be worth building when the cost of experimentation has fallen this far.

End the day by looking for dropped balls

Daniel uses Microsoft 365 Copilot for a second, much smaller workflow during the final 30 minutes of his workday. He asks one question:

What did I drop the ball on?

Copilot checks the work surfaces it can see, including Outlook, Teams, and recently updated files, then looks for drafts, promised follow-ups, or conversations that never got an answer. Daniel anonymizes names and projects for demos, but the real value comes from grounding the check in his own work history.

The end-of-day Copilot workflow works because it is a targeted review at the moment Daniel can still act. It is not another morning digest competing for attention.

The same principle connects both systems. Durable context lives in files and work history. Agents receive narrow roles. Important work gets an independent pass. The human remains close enough to understand the decision and test the outcome.

The operating model is the real product

Bob and Ray make a memorable demo, but the deeper idea is reusable. Give each agent a distinct mandate. Make the handoffs visible. Preserve the project memory outside the conversation. Use branches and real-device tests to keep mistakes recoverable. Keep the human at the point where product judgment matters most.

That is how a writer ships an iOS feature without pretending to be an iOS engineer. Daniel does not outsource the product. He builds a team of agents around the parts he cannot do alone, then stays accountable for what reaches the customer.