I had a working nutrition application built in Angular. Then I decided to build a native iPhone version in Swift with a coding agent. The product already existed, so I could spend my time deciding how it should work on the phone instead of explaining the whole idea from scratch.
That experience has changed how I think about technology choices. A language I would once have treated as a substantial investment in learning became something I could work with while building. I still had to understand the software and judge the result, but the cost of attempting the move was much lower.
Shopify has now published two articles about moving its mobile apps from React Native back to native development. They give a much larger example of a change I have been seeing in my own work: when implementation becomes easier to move between technologies, we should reconsider how we hire engineers and how many people a project actually needs.
A working application gives the agent something to follow
With Nutrition AI, I started the move from the Angular progressive web app, a website designed to work like an installed app, to native iOS in Swift when OpenAI's GPT-5.6 Sol became available. I have continued that work with GPT-6 Astra.
The advantage was having a working codebase. I could point the agent at an existing feature, inspect how it behaved, and use that as the starting point for the iOS implementation. The earlier work had already resolved many questions about what the product was supposed to do.
There is a big difference between asking an agent to invent a nutrition app and asking it to reproduce a known workflow in another environment. In the first case, it has to fill gaps in the product idea. In the second, we can compare its decisions with something that runs.
For a food diary, for example, a screen showing the day's entries only tells part of the story. A useful comparison would also check what happens when an entry changes, how totals are recalculated, and which day receives an item around midnight. Those are concrete questions a reference implementation helps us answer. They are also better acceptance criteria than whether the new screen looks convincing.
I had already used a simpler version of this approach when rebuilding my wife's veterinary website. The old site supplied the structure and content. With a mobile application, the reference can reach much further into behavior and business rules.
An existing competitor helps too. You can study a product's public workflows, understand the interaction, and build your own implementation around a similar need. That gives you a much clearer starting point than an empty document. But observing a competitor gives you less information than owning a working codebase: the screen does not reveal all the rules, integrations, or operational problems behind it. Recreating visible functionality also does not give you the competitor's customers or distribution.
Shopify changed the calculation for native development
In Native is now the future of mobile at Shopify, published on September 10, 2026, Shopify explains that React Native had served it well. Coding agents then reduced the effort of implementing features separately in Swift and Kotlin enough to reopen the decision. Its experiments used one platform's implementation as a reference for the other, with shared specifications and checks to keep behavior aligned.
Shopify also describes why a single large rewrite prompt was inadequate. Its Helix workflow breaks work into small checkpoints, with behavioral tests, visual comparison, code review, and human approval. The architecture is being adapted so agents can exercise business logic quickly without relying on slow simulator interactions. That is evidence for investing in the development environment alongside the model. Shopify's architecture and migration approach.
The companion article, Migrating Shop app from React Native to native, makes the scale concrete. One engineer spent a week on an iOS proof of concept. It demonstrated feasibility, but was not ready for production. The full migration reached the app stores in 12 weeks, with six core engineers and feature teams joining to validate their areas.
Shopify reports startup-time reductions of 23% on iOS and 50% on Android. These are results from its migration, rather than a general promise about every native rewrite. The team also built tooling to compare running behavior and analytics events, and explicitly says native expertise remained essential. Generated code could meet feature requirements while creating architectural or performance problems. Shop's results and lessons.
For me, those accounts support a specific conclusion: the economics of changing technologies deserve a fresh look. They also show how much engineering sits behind a successful migration.
The language becomes easier to change
When I say the programming language matters less now, I mean that my existing language knowledge is becoming less of a limit on what I can attempt.
A coding agent can help me read unfamiliar code, explain a platform convention, implement a first version, and revise it against feedback. I can investigate an option by building a small part of it. That changes both learning and decision-making: I get to test an assumption before committing to a large project around it.
The language and platform still affect the result. An iPhone app has its own navigation expectations, lifecycle, permissions, and background behavior. Swift and Kotlin implementations need to fit their platforms. Translating an Angular component line by line would preserve the wrong things if the goal is a good native application.
The same reasoning applies to heavy refactoring. Agents can help carry a structural change across many files, but someone must decide which responsibilities belong together and prove that the behavior survived. An old implementation is a useful reference, including for discovering mistakes we should deliberately leave behind.
I can now see a much more practical route to maintaining both a Swift and a Kotlin client for a product like mine. The iOS work makes that a credible next experiment. The shared asset would be the product definition, backend contracts, and expected behavior; each client would express those in its own environment.
There is still a cost to supporting two applications. Every subsequent feature needs a decision about both, and both need release and regression checks. A successful experiment should therefore measure the next change as well as the initial port. Sometimes keeping the current stack will still be the better use of money.
Hire engineers who can cross the boundary
This is why I think hiring framed around “senior Angular developer” or “senior React developer” can miss the person a company actually needs. Framework experience is useful evidence, but a narrow keyword filter can exclude an engineer who understands the product and could become productive in that stack quickly.
I would put more weight on how someone investigates a system. Can they trace a user action through the frontend and backend? Can they explain where a business rule belongs, recognize unnecessary coupling, and choose a test that would catch a plausible mistake? When they encounter an unfamiliar environment, do they know how to learn enough to challenge the agent's output?
I would also want to see how they organize AI-assisted work. That includes giving the agent access to relevant context, making builds reproducible, dividing changes into reviewable pieces, and keeping feedback close to implementation. The ability to generate a lot of code is a weak hiring signal on its own.
A useful interview could involve a small existing application and a change that crosses its layers. Let the candidate use an agent. Watch which questions they ask before editing, what they inspect, and how they decide the result is correct. A polished demo with unexplained decisions should count for less than a modest change the candidate can defend.
For a role whose main difficulty is deep platform behavior, I would still hire for that depth. But for many business applications, I would prefer broad engineering judgment with demonstrated learning ability over years in one framework treated as the main qualification.
More projects can fit a team of one
In my own coding, I can now move between architecture, backend implementation, interface work, and verification with much less friction. I can produce and inspect substantial changes myself. The useful gain is how quickly I can turn an idea into something I can evaluate, then carry the accepted version through the system.
That makes me expect more software projects to start with one experienced engineer, supported by agents, and add people when a specific need justifies it.
The communication advantage is substantial. A business owner can explain a problem directly to the person making the technical decisions. That person can build a working version, show it, and adjust it without passing the request through several separate interpretations. A smaller delivery structure can preserve more of the original intent.
I previously wrote that AI-native delivery is a team sport. The responsibilities described there still apply: someone needs to understand the customer, shape the product, make design decisions, and assess quality. On a bounded project, one engineer can cover more of those responsibilities with AI assistance and direct access to the business owner. The functions remain even when they do not each need a dedicated employee.
Shopify's experience is useful context here, but it does not establish that a solo developer can replace a large product organization. My prediction concerns a growing range of smaller projects where one person can understand the whole system and keep up with its support needs.
The constraint becomes attention. An engineer who generates more changes than they can properly review has exceeded their useful capacity. Several simultaneous clients, urgent production incidents, or a product requiring continuous specialist work can justify a larger team regardless of how quickly agents write code.
Internal software can be simpler and still be good
Consider an internal approval tool or a customer portal for a small B2B company. It may need clear forms, reliable permissions, a useful search, and an export that matches the business process. It may have little need for custom animation or an elaborate visual identity.
That is a strong setting for a senior engineer working directly with the people who use it. A familiar interface and a deliberately narrow scope can deliver real value quickly. This follows the argument I made in AI Is Unbundling SaaS: more tailored workflows become worth building when the cost of trying them falls.
For that kind of tool, a plain interface can be excellent for its purpose. An approval tool that silently loses a request is poor software, however modest its audience. Internal and B2B systems can also carry critical business operations. I would spend less on unnecessary scope and decoration, while retaining the reliability the workflow needs.
The buyer should also be able to continue without the original developer. Source code, deployment access, basic documentation, and a workable handover matter especially when one person holds most of the context. Paying for occasional specialist review or backup support can be a sensible part of a small delivery arrangement.
Software buyers should question the size of the proposal
I expect this to put pressure on software pricing, particularly where estimates still assume separate specialists for every layer of an ordinary business application.
A solo engineer has fewer organizational costs to recover. Direct communication can also reduce paid coordination time. An agency's management layers, sales costs, and margins need to earn their place in the proposal through something the buyer values, such as continuity, specialist depth, or support capacity. A large supplier is not automatically overpriced, but its size is no longer a sufficient explanation for the bill.
My preference would be to start with a small paid piece of the real workflow. Agree what it must do, let the engineer deliver it through to a usable environment, and assess the result with the people who will use it. That reveals more about the proposed working relationship than a staffing chart or a promise about AI productivity.
For suitable projects, I think the team of one will become a much more serious alternative. The engineer still needs range, judgment, and enough discipline to maintain what they build. AI makes that range easier to exercise across technologies. Buyers should increasingly be able to choose the person who can own the outcome, without treating the language of the existing application as a permanent boundary.