Beyond the Prompt: Engineering the Loop for Software Change at Scale
B · Useful, limited A first-hand engineering account from Expedia Group's iOS platform team with a concrete system design and before-and-after delivery metrics; credible practice, but self-reported with no baseline method or token cost shown.
Summary based on the full text·Original: about 10 minutes to read
In short
A post on the Expedia Group Tech Blog (October 2026) by Karthik Bedre, a senior mobile engineer. It describes how the team split the shared iOS components stack, used by more than ten brands, into independently buildable domains while weekly releases continued. The method was a fixed control loop (analyze, decide, act, verify, memory, route, repeat) run by a coding agent, with deterministic scripts and a purpose-built MCP server doing inventory, file moves, builds and tests. Completion was decided by a ladder of builds and tests, never by the agent's own judgement.
Key numbers
- about two years to about three monthsestimated against actual duration of the iOS modularization program, with no code freeze
- about four months to under three daystime to migrate a medium-to-complex domain
- more than eight hoursautonomous run on one complex domain before the first human architectural decision
- 45 to 11 minutesCI build and test time before and after modularization
- about 15 to 2 minutesfocused domain build time before and after
As reported by the source.
English·Web page·opens medium.com
What it reports
- Work estimated at roughly two years finished in about three months, with Monday releases kept.
- A medium-to-complex domain migration fell from about four months to under three days.
- One large domain ran through the loop for more than eight hours before needing a human decision.
- Focused domain builds fell from about 15 to 2 minutes; CI build and test time from 45 to 11 minutes.
- P75 cycle time moved from about 5 to 2 days and P75 coding time from about 4 to 1 day.
- Build failures were first matched against stored failure signatures and recorded fixes; only unfamiliar ones went to model reasoning.
- Humans were called only at consequential architectural forks, with the dependency path, affected domains and ranked options prepared.
How they got it
The team studied how experienced engineers had done successful migrations and encoded the repeated sequence as a state machine. Deterministic tooling handled analysis, dependency mapping and Xcode index lookups; the agent chose transformations within a bounded goal and could not change the target architecture or skip a verification gate. Verification widened in six steps from the domain workspace to the shippable app and a single pull request.
Limits
- The two-year baseline is an estimate, and the method behind it is not given.
- No token or compute cost is reported, although cost is described as a design constraint.
- Agent models and tools are not named.
- One company, one codebase type (a modular iOS monorepo); the gains depend on having good build and test coverage.
Why it matters for companies
The useful lesson is where the speed came from: deterministic tools for the predictable work, executable tests as the definition of done, stored fixes for repeated failures, and humans placed at decision points with evidence prepared. Firms planning large code migrations with agents should first write down how their best engineers know a step is finished; if that cannot be made executable, the agent has nothing reliable to stop on.
Summary based on the full text. Read the original for the full argument and data.Read the original on medium.com