Is there a glass ceiling in agentic mobile development?

Dani·Chief of StaffSep 22

Last week in London, Harry Davies iOS Engineer at Flo Health by day, founder of Haros Labs by night and Rory Smith, CTO here at Semaloop sat down to discuss a deceptively simple question, is there a glass ceiling in agentic mobile development?

Harry’s quick take, "I think coding is solved," he told the room, "I don't think anyone in this room can out-code a frontier model now." But that's only one part of what being a mobile developer actually means, and the rest of the evening was spent picking apart everything that part doesn't cover.

The code monkey is dead

Harry didn't soften this one, stating that being purely "a code monkey" is, in his words, a liability now. If frontier models can write the code, the job has to move somewhere else, into a mix of product thinking, design taste, QA, and the parts of shipping software that were always more than typing.

His advice to anyone still defining their job as "I write code" is to start thinking about how you get involved in the product side of things, how you get a say in design, and what specialty you're building beyond the syntax.

Vibe coding at home vs. vibe coding at work

There's a real gap between weekend Harry and weekday Harry. At Flo Health, a MedTech product with lawyers and doctors in the loop, he joked that with how cheap and accessible AI is, it feels like he's writing fewer lines of code every month. Everything is agent-driven, but held to a much higher bar than a personal project ever needs to be.

About 10% of Flo's pull requests are now built, reviewed, and merged entirely by agents, with no human ever touching them. The other 90% fluctuates month to month, gated by which changes legally require a human sign-off. The target turnaround is 24 hours, though Harry was quick to point out some companies manage two.

At home, the constraints flip, where cost matters more than compliance, so Harry is deliberate about which model he reaches for and how he manages context. So he prioritises fresh sessions rather than one long, sprawling conversation, "I speak to vibe coders all the time and they're just having one giant session," he said "this is how you really, really burn through it."

Why web got the agentic head start

Rory asked “If coding is genuinely this fast now, why hasn't mobile kept pace with the wave of AI-built web products?” Harry's answer, “the App Store.”

Web in his words, “is simply solved”. You can deploy to Vercel and you're live in ten seconds. Mobile means privacy policies, nutrition labels, sole trader paperwork, and a review process that can hold up a release for two weeks over reasons Apple won't fully explain. Add in device access, where you need real hardware to test on, not just a simulator, and it's easy to see why web-first tools like Lovable never bothered chasing mobile.

Rory pushed back gently, wondering if it's less about the review process and more about access to devices. This year alone Xcode has added MCP support and coding agents have gained the ability to drive a simulator directly. Connective tissue he thinks could make 2026 the year of mobile agentic development. Harry agreed, but flagged a practical wall behind it, that a lot of would-be builders are on Windows laptops, and you simply can't make Apple apps without Apple hardware.

What happens when your product becomes an API

Rory isn't just hosting this conversation, Semaloop has lived through its own version of the ergonomics question. When an audience member asked how you weigh designing for humans versus designing for agents, Rory pointed to what happened after Semaloop shipped its own MCP, "the first thing that customers did was build their own UI on top of it." Rather than fight that, Semaloop leaned in, treating the raw interface as a way to learn where customers actually wanted to go next, then folding those patterns back into the product.

That openness raises an obvious follow-up, if you're the API, can you still capture value, or do you just get commoditised? Rory's answer was that the risk is real, but survivable, it comes down to what sits behind the API that competitors can't easily copy. For Semaloop, that's owning its own hardware running in a data centre, not just a thin software layer. "There's reduced risk of commoditisation there," he said, "but for sure there're many, many companies that I imagine are terrified by this aspect."

Rory also brought a security lens from his time at Apple, arguing the same shift-left thinking that applies to security applies here, catching problems earlier is always cheaper than catching them right before launch. It's part of why he pushed Harry on whether Apple's review objections could be caught before submission rather than after.

Voice as the real interface

The most animated part of the night was Harry's belief that voice, not touch, is where agentic interfaces are headed. He's built his own network of bots, connected to Gemini and xAI, with full tool-calling, that he talks to like colleagues. "Go and add a ticket to the board," he can say, or "go bump the version and release it," and the agent just does it.

He flagged Apple's App Intents and Siri AI as a genuinely existential threat to apps. The moment someone can say things directly to their phone and have it logged, tracked, and acted on, a whole category of dedicated apps loses its reason to exist. "The second it talks to you back... they’ll be done," he said.

One thing he's learned the hard way, mixing models makes the illusion crack. Routing between Gemini, xAI, and other models for different jobs works functionally, but talking to a system that responds in a different "voice" each time feels incoherent. He's since consolidated around fewer models, partly for consistency and partly because token costs on more expensive models simply didn't scale with how much he was building.

Living specs and giving agents real memory

Harry's current obsession is what he calls a living spec, a file committed to the repo that captures not just what a feature does, but why it changed, what was tried before, and what the edge cases are. Written in something human-readable like MDX, it's meant to be read by product managers and engineering managers alike. Engineers stop hand-editing code and start editing the contract instead, letting the agent write to it and self-evaluate against it.

The catch: it only works if the whole team commits. One person who doesn't update the spec, and it quietly goes stale.

He's paired this with something called Codebase Memory MCP, a local memory graph that replaces an LLM's instinct to grep through everything. On one of his codebases, it took a 440,000-token repo down to roughly 6,000 tokens of effective context, at close to zero cost and millisecond search times. His broader philosophy is build your own harness rather than accepting the defaults.

Taste still has to come from somewhere

When asked whether his shipped products are all vibe-coded, Harry was candid that the early ones were rough, and they've gotten better over time as he's built up a bank of design references.

His tip for anyone chasing better output, spend ten minutes searching design-taste accounts on social media, feed the results into your tool of choice, and ask it to distill a design skill from what you like. But even with this tip, Harry warned us "You'll find quite quickly... people can make slop even when they have all the skill," he added "It's very much a feel."

Harry's advice for builders

  • Ship early: You won't know what a feature actually needs until real users touch it.
  • Write bulletproof specs first: Force the model to write out happy paths and unhappy paths before it writes any code.
  • Use a second, context-free agent to check the first one's work: Keeping it in a separate session with no shared history keeps the review honest and cheap.
  • Learn the fundamentals anyway: Enums, backend security, row-level security, without them, you can't guide a model well, and you won't recognise when it's quietly shipping slop.

From the audience Q&A

Q: On trust, one attendee described burning through budget because an agent "got carried away," and asked how long it takes before you can trust the process on something you only get one shot to ship right?

A: Harry's diagnosis was it's rarely a trust problem, it is in fact an instruction problem. If you don't fully trust the output, make the agent submit a PR you review before it merges, that's your damage control. And keep the checking agent in a separate, context-free session so it isn't just marking its own homework.

Q: Should Product Managers learn to code? Someone asked if Flo requires a certain number of PRs per month from non-engineers.

A: There are no requirements, but plenty of product managers write code anyway, and Flo runs internal courses to help them do it properly. Their pull requests still get reviewed like anyone else's, and often "need a bit of love", not because the code is bad, but because a 15-year-old codebase hides functions that already do what you're about to rebuild. That domain knowledge, Harry said, is one of the few genuinely human parts of the process left.

Q: How do you go about building a first mobile app with no mobile team? A head of engineering in the room, quietly building their company's first Android app solo, asked how to protect whoever inherits it once they move on.

A: Harry's advice cut against instinct and said don't read the code at all. Treat the spec as the real interface, write down every screen, every edge case, every timeout behaviour, and let the agent build against that contract. Rory added the missing piece, build a verification loop you can actually trust, so you're not stuck re-checking every step yourself. "Your best place is captain of the ship," he said, "driving it forward."

Summary

Harry's answer to the glass ceiling question, in the end, wasn't really about ceilings at all. Coding itself may be largely solved, but shipping software, the specs, the review process, the design taste, the judgment calls about what's worth building slowly, very much isn't. The developers who treat themselves as product engineers, not code monkeys, are the ones who'll keep moving up.

Thanks to Harry (Haros Labs, Flo Health) for joining us, and to everyone who came out for the Semaloop Event in London.


Dani·Chief of Staff·Sep 22