Designing an Agentic Flywheel for iOS Development

My previous post about the agentic flywheel was intentionally generic.

This one is the follow-up: how I would design an iOS-development-specific flywheel.

The framing still comes from Kief Morris’s article, Humans and Agents in Software Engineering Loops, especially these points:

1. Harness = the collection of specifications, quality checks, and workflow guidance.
2. The loop improves only if agents can evaluate performance and failure scenarios.
3. For each workflow step, the agent should review results and recommend harness improvements.
4. Recommendations should be scored by risk, cost, and benefit, and low-risk/high-value ones can be auto-applied.

Why a domain-specific flywheel?

A generic flywheel is useful, but iOS development has domain-specific constraints:

1. Figma-level state accuracy matters, not only functional behavior.
2. Logging requirements are product requirements, not optional implementation details.
3. Team conventions (architecture, event handling, logging format, UI framework rules) matter for maintainability.
4. TDD loop quality and static checks affect long-term velocity.

If the harness does not encode these constraints, the agent can still produce code, but the loop quality will be unstable.

Human workflow I am mapping

In my real workflow, development can be summarized as:

1. Estimation
2. Design
3. Implementation

Before coding starts, PM shares task context (PRD + design/Figma). Then:

1. Estimation is split by stage:
   • design
   • implementation
   • integration with backend/other iOS developers
   • developer self-test (requirement checks, design QA, logging QA)
2. Design artifacts are created and reviewed:
   • feature flow charts, including A/B branches if needed
   • API flow and handling flow
   • request/response/path contract details
3. Implementation proceeds in small requirement-level TDD commits and small PRs.
4. Final checks include UI parity with Figma, logging requirements, and developer self-test.

Recasting this as AI workflow commands

I would encode the same flow into three AI-first commands:

1. /estimation
2. /design
3. /implementation

And I would treat each as a measurable loop step, not just content generation.

+-------------------+
| /estimation       |
+-------------------+
          |
          v
+-------------------+
| /design           |
+-------------------+
          |
          v
+-----------------------------+
| Test-case package           |
| (from design output)        |
+-----------------------------+
          |
          v
+-----------------------------+
| Human review of test cases  |
+-----------------------------+
          |
          v
+-----------------------------+
| /implementation             |
| per TC -> TDD micro-loop    |
+-----------------------------+
          |
          v
+-------------------+
| loop review       |
| + harness update  |
+-------------------+
          |
          v
+-------------------+
| next task         |
+-------------------+

Step 1: /estimation

Input:

1. PRD
2. Figma
3. integration constraints
4. team rules

Output:

1. MD estimate by stage:
   • design
   • implementation
   • integration
   • developer self-test
2. explicit assumptions
3. risk flags

Quality checks:

1. Did the estimate include all stages?
2. Are assumptions explicit and testable?
3. Are dependencies called out early?

Harness improvement examples:

1. If estimates repeatedly miss design QA effort, update estimation rubric.
2. If integration effort is underestimated, add stronger dependency prompts.

Step 2: /design

This step should produce both design artifacts and executable test intent.

Output bundle:

1. Functional flow chart (including A/B branches when relevant)
2. API contract spec (path, params, request/response, edge cases)
3. Test cases in Given/When/Then, grouped by screen and feature
4. Snapshot-style UI expectations for Figma states
5. Logging test cases (“when X happens, Y log is sent”)
6. Additional engineering safety behavior (for example, error alert behavior)

I treat this as the key bridge from product intent to implementation.

+-------------------------+
| /design                 |
| PRD + Figma             |
| + logging requirement   |
| + QA TC                 |
+-------------------------+
       /                 \
      v                   v
+-------------------------+   +-------------------------+
| Design artifacts        |   | Test-case package       |
| - flow charts           |   | - requirement TC        |
| - API contracts         |   | - design snapshot TC    |
+-------------------------+   | - logging TC            |
                              | - safety/edge-case TC   |
                              +-------------------------+

Quality checks:

1. Can all requirements map to at least one test case?
2. Are UI states in Figma mapped to testable snapshot expectations?
3. Are logging requirements represented as test cases?
4. Are critical negative/error scenarios included?

Harness improvement examples:

1. If a requirement repeatedly escapes to implementation without a test case, tighten design output schema.
2. If logging regressions repeat, promote logging TCs to a required section.

Step 3: /implementation

The implementation skill should consume design test cases and execute a strict TDD loop.

TDD loop per requirement-level unit:

1. write test case
2. confirm failure
3. implement
4. confirm pass
5. run quality checks before commit

Quality checks should include:

1. a static-rules gate before commit
2. lint/format checks
3. code coverage checks
4. globalization checks (localized strings, layout safety for longer text)
5. team-enforced style/architecture checks (for example, SwiftUI requirement for new views, MVVM, event handling style, logging style)

+-------------------------+
| test-case unit          |
| (from /design output)   |
+-------------------------+
            |
            v
      [TDD micro-loop]
   test fail -> implement -> test pass
            |
            v
+-------------------------+
| pre-commit checks       |
| static rules gate       |
| - lint/format           |
| - coverage              |
| - globalization         |
| - team style/arch       |
+-------------------------+
            |
            v
+-------------------------+
| small commit / small PR |
+-------------------------+

Harness improvement examples:

1. If lint failures recur, strengthen implementation prompts and pre-commit check gating.
2. If generated code repeatedly deviates from team style, add explicit templates or pattern references.
3. If certain rules are always violated, convert them from guidance to hard checks.
4. If team style/architecture keeps drifting, check whether the project itself has inconsistent patterns across modules. In that case, invest in clearer templates and stronger harness guidance before expecting stable agent output.

This investment takes real effort, and in that sense AI development is not very different from human development: if a project is hard for humans to code consistently, it is also hard for AI to code consistently.

What “giving agents information to evaluate the loop” means in iOS

For iOS work, this usually means giving the agent:

1. task specs (PRD, acceptance criteria, dependencies)
2. UI truth (Figma states and behavior)
3. quality truth (lint/static rules/architecture conventions)
4. observability truth (logging requirements)
5. test truth (required failure scenarios and expected behavior)

Without these, the agent can generate output but cannot reliably evaluate loop performance.

Scoring recommendations and auto-applying harness updates

After each step, recommendations can be scored:

1. risk
2. cost
3. benefit
4. recurrence frequency
5. reversibility

Then use policy gates:

1. Low risk + high recurrence + low cost + reversible -> auto-apply
2. Medium risk or unclear impact -> backlog + human approval
3. High risk or architecture-impacting -> manual review required

This is how the flywheel stays safe while still getting faster.

Practical questions I expect

What if PRD misses important cases?

This is critical, and it is exactly why the design step must output a structured test-case package and why a human must review it carefully.

The key review question is:

1. “If these screen-by-screen and feature-by-feature TCs are implemented and combined, will the feature be correct?”

If the answer is no, the next action is to resolve the missing input, not to guess:

1. missing logging requirement -> request it explicitly
2. missing PRD behavior -> ask PO/PM and clarify
3. unclear edge-case behavior -> add explicit test cases before implementation

The harness side should also improve: the design skill should actively flag likely missing inputs and unresolved assumptions to the developer.

What if QA TC or logging requirements arrive late during implementation?

Use an incremental loop:

1. continue with available inputs
2. when new QA TC/logging requirements arrive, run additional /design and /implementation loops for the delta

This is not fundamentally different from human development. The loop should support iterative updates instead of assuming perfect upfront inputs.

What about small bug fixes or tiny features?

The same workflow still applies, just at smaller scope.

1. Run /design with a concise problem statement.
2. Generate and review the resulting TCs.
3. Implement via the same TDD + static-rules gate loop.

I do not want hard constraints like “must provide a Jira ticket.” The skill should represent a workflow stage, not a rigid input format. It should evolve with context.

Practical example of loop improvement

If /implementation repeatedly fails static checks:

1. detect failure pattern
2. propose harness change
   • strengthen prompt constraints
   • add missing template
   • move a soft rule into hard gate
3. score recommendation
4. auto-apply if policy threshold is met
5. verify next task passes the same check

That is the flywheel in practice: not only fixing code, but improving the system that generates code.

Closing

My goal is not to remove humans.

My goal is to move humans from repetitive correction work to harness engineering work.

For iOS development, that means encoding estimation rules, design-to-test conversion, TDD execution, and static quality gates into a loop that can measure itself and improve itself task after task.