AI時代下的行動開發

Hacker News·4 個月前

擁有十五年經驗的行動工程師 JP Simard 對當前行動開發的現況感到興奮，他認為 AI 在將意圖轉化為可執行軟體方面，尤其是在跨平台情境下，顯著加快了開發速度。

JP Simard — Mobile Engineer

Jan 2nd, 2026

     | Comments
    
    | RSS Feed

Mobile Development in the Age of AI

After working in mobile engineering for about a decade and a half, across
multiple eras of iOS and Android tooling, languages, and architectural
approaches, I’ve never been more excited about the landscape than I am right
now.

When I started making apps in 2011, it was thrilling to go from an idea to
something you could physically touch and hold in your hand within hours. Today,
that same feeling exists—but the iteration cycles are now an order of magnitude
faster.

The fundamentals haven’t changed. What has changed is the speed at which
intent turns into working software.

Translation Is (Basically) a Solved Problem

A lot of where AI applications go wrong today comes from anthropomorphizing
models and ascribing to them a kind of human-style intelligence. As
Andrej Karpathy puts it: “We’re summoning ghosts, not
building animals.”

But one category of tasks these LLM “ghosts” excel at is translation.

That’s obvious when translating natural language like English to French, but
it’s equally true for:

See this example
where Simon Willison ported JustHTML from Python to JavaScript with Codex CLI
and GPT-5.2 in 4.5 hours.

If you operate in an environment where your web app, iOS app, and Android app
are separate codebases with baseline functional parity, AI fundamentally changes
the economics of one codebase for each platform.

Instead of rewriting features, you’re translating intent.

A web PR becomes a reference implementation. Existing mobile code becomes
executable context. Asking an agent to “take a first pass at implementing this
natively” is now a normal—and productive—workflow, especially for apps with
large CRUD-style surface areas and well-defined business logic.

Context Beats Code

Simon Willison has written about context engineering:
“the art of providing all the context for the task to be plausibly solvable by
the LLM.” The limiting factor in AI-assisted development isn’t the model itself,
but how clearly the problem is framed.

That aligns closely with what actually matters in software engineering:

These are platform-agnostic, one-time costs. Once you’ve paid them, the knowledge
transfers cleanly across platforms.

This is also where the distinction between process-driven and
outcome-driven engineers becomes important. As
Ben Werdmuller put it, we’re
likely to see a real split between people who are outcome-driven and excited to
test their work with users faster, and people who are process-driven and derive
meaning primarily from the engineering itself.

LLMs disproportionately benefit outcome-driven engineers—those who know what
“good” looks like and can steer toward it. The tools reward clarity of intent,
not ceremony.

What Mobile Development Actually Looks Like Now

In practice, most of the code I’ve written over the past twelve months hasn’t
been typed directly into Xcode or Android Studio.

A common setup today looks like this:

With a modest amount of investment, the need for an IDE as a primary input tool
almost disappears. The more you can hoist your compiler and language server out
of the IDE and into terminal-ready commands, the more you can augment the
capabilities of your coding agent.

Native Platforms Pair Well With AI, Despite Training Gaps

A fair concern is that frontier models still have less deep knowledge of
iOS- and Android-specific APIs than they do of web or Python ecosystems.

Matt Gallagher recently wrote about the state of Swift and iOS
knowledge in frontier models at the end of 2025. He notes that “most LLMs are
trained on data that is 2+ years old, and their Swift style often feels older
still.”

The conclusion isn’t that models are perfect, but that modern native platforms
provide strong constraints:

These constraints matter more than raw training data volume. What matters day to
day isn’t whether an LLM can one-shot a perfect solution, but whether it can
iterate quickly with tight feedback. Strong typing in Swift, Kotlin, and
TypeScript helps enormously here.

I don’t know about you, but I don’t typically write perfect code on the first try
either.

A Brief Note on React Native

It’s absolutely possible to build excellent mobile apps using React Native or
fully native stacks.

What’s often underestimated is the organizational overhead and depth of
expertise required to do React Native well at scale. Teams that succeed tend to
invest heavily in platform infrastructure, tooling, and internal knowledge.
Shopify is a well-known example of what “doing it right” looks like.

AI shifts this tradeoff. When translation becomes cheap, the value of
lowest-common-denominator abstractions drops. Platform-idiomatic code no longer
implies slower delivery.

Side note: this is a large part of why Ramp’s mobile engineering team is much
leaner than people expect given the breadth of the apps’ capabilities.

The Centaur Model, Applied

This way of working maps closely to what Cory Doctorow calls the
Centaur model. In automation theory, “a centaur” is a person
assisted by a machine.

Humans and machines work together, each focused on what they do best:

AI doesn’t remove the need for software engineers. It removes the least
interesting parts of the job and sharpens the most important ones.

Why This Reinforces Native Teams

With AI-assisted translation:

This is exactly how we’re working today—and why Ramp is hiring iOS engineers
and Android engineers.

If you care about building platform-idiomatic mobile apps, moving quickly
without sacrificing quality, and spending more time on judgment than
boilerplate, this is a particularly good moment to be doing native mobile
engineering.

Closing

The tools changed.
The job didn’t.

If anything, it got more interesting.

Posted by JP Simard
on

Jan 2nd, 2026
in

ai, development, mobile, product