Yes, AI can build your mobile app. It can also lose you three months and a customer database.
Both of those sentences are true, and which one you end up living depends almost entirely on what kind of app you are building. That is the part the demos leave out. A tool that produces a working screen in ninety seconds is genuinely impressive. It is also being sold to people who are about to handle payments, medical records, or fifty thousand user accounts.
So this is an honest answer rather than a sales pitch. We use AI coding tools at Duple IT Solutions every day. We also spend a fair amount of time repairing apps that were built entirely with them. Here is what the evidence says, what these tools do well, where they fall apart, and how to decide which side of the line your project sits on.
The short answer
AI is very good at producing code that runs. It is unreliable at producing code that is safe, maintainable, and correct under conditions nobody demonstrated.
For a prototype, that distinction does not matter. For anything with real users and real consequences, it is the whole game.
What the research actually shows
Most articles on this topic quote one study and stop. The full picture is more interesting, and more useful.
In 2025, the research group METR ran a randomised controlled trial with experienced open-source developers working on their own repositories. Before starting, the developers predicted AI would make them about 24% faster. Afterwards, they said it had made them roughly 20% faster. The measured result was the opposite: tasks took 19% longer.
What almost nobody reports is what happened next. METR ran a second, larger study through late 2025 with 57 developers across 143 repositories. That one showed a modest speedup rather than a slowdown. But the researchers then published something unusual: they said their own data was unreliable and they were redesigning the experiment.
The reason is worth sitting with. So many developers now refuse to work without AI that they were declining to join the study, or quietly withholding the tasks they most wanted AI for. Between 30% and 50% of participants admitted to holding tasks back. The people getting the biggest gains had selected themselves out of the measurement.
The finding that has held up across every round is the perception gap. Developers consistently feel faster than the clock says they are. Code generation is visible and fast; the review, debugging, and rework it creates are spread out and easy to forget. If you are budgeting a project on how fast the first version appeared, you are budgeting on the wrong half of the work.
What AI coding genuinely gets right
This is not a piece arguing that AI code generation is overhyped. In the right slots it is excellent, and refusing to use it is now a competitive disadvantage.
It is strongest wherever the answer is well-established and the pattern has been written ten thousand times before. Screen scaffolding, form layouts, CRUD operations, API wiring, converting a design into components. Work that is tedious rather than difficult.
It is also very good at tasks that are hard to start but easy to check. Writing tests for code that already exists. Mechanical refactors. Documentation. Explaining an unfamiliar codebase to a developer who has just joined. In these cases you can verify the output quickly, which is what makes the speed genuinely useful.
The Stack Overflow 2025 developer survey found 84% of developers now use or plan to use these tools. That number is not going backwards. The question was never whether to use AI. It is which parts of the job you hand over.
Where it goes wrong
The failure mode is specific, and it is not what people expect. AI rarely produces code that is obviously broken. It produces code that looks right, compiles, passes a casual review, and is wrong in a way you find out about later.
The same Stack Overflow survey captured this precisely. The single biggest frustration, reported by 66% of developers, was AI solutions that are almost right but not quite. Trust in AI accuracy fell to 29% that year, with more developers actively distrusting output than trusting it. Adoption went up. Confidence went down.
Security is where “almost right” becomes expensive. Veracode tested over 100 language models across 80 security-sensitive coding tasks. Nearly half of all generated samples failed. When the researchers repeated the exercise in early 2026, the pass rate had barely moved despite a year of newer, larger models.
The pattern behind those numbers is consistent. These models optimise for code that works, not code that is safe. Given a choice between a secure implementation and a simpler one that still demos correctly, they frequently pick the simpler one. So you get a login screen that accepts a password and no rate limiting behind it. A database that returns the right record and no row-level access control. An API key sitting in client-side code because that was the fastest way to make the call succeed.
None of this shows up in a demo. All of it shows up in an audit, or a breach.
The mobile problems the demos skip
Everything above applies to software generally. Mobile adds its own layer, and this is where AI app builders struggle most, because a phone is a hostile environment in ways a browser is not.
An app has to survive losing connectivity mid-action and reconciling that state later. It has to run on a four-year-old Android device with 3GB of RAM, not just the simulator. It has to handle permission prompts, background limits, battery constraints, and an operating system that will kill it without warning. It has to pass a human store review that checks privacy manifests, data disclosures, and account deletion flows.
These are not exotic edge cases. They are the standard requirements of shipping to a store, and they are almost entirely absent from what a prompt produces. The generated app is a demo of the happy path. The remaining work is not glamorous, it rarely gets recorded in a launch video, and it routinely takes longer than the part that was automated.
So who should build with AI?
The useful question is not whether AI can write the code. It is what happens when the code is wrong.
If a bug means a colleague is mildly annoyed, build it with AI and ship it this week. Internal dashboards, throwaway prototypes, tools that validate an idea before you commit real money. Vibe coding is a completely reasonable strategy here, and hiring an agency for it would be a waste of your budget.
If a bug means churn, refunds, and rework, use AI heavily but keep humans on authentication, data modelling, and payments. Get a security review before launch rather than after.
If a bug means a regulator, a breach notification, or removal from the store, the code is human-led and AI accelerates the parts that are safe to accelerate. That is not conservatism. It is a rational response to a 45% security failure rate.
How we actually use AI at Duple IT Solutions
We are an AI development agency, so it would be strange to argue against these tools. We do not. We use them across most projects, with rules about where.
AI writes our scaffolding, our boilerplate, and a good share of our tests. It does not make architecture decisions, and it does not get the last word on anything touching auth, payments, or personal data. Every generated block gets reviewed by someone who could have written it themselves, because that is the only kind of review that catches an “almost right” bug.
The honest summary: AI has meaningfully changed how fast we produce the first version. It has not changed how long it takes to make something safe to launch. Clients who understand that distinction get realistic timelines. Clients who have been sold a 10x productivity story get disappointed by everyone, including us.
The cost of getting this wrong
The pattern we see most often is a founder who built an MVP with an AI app builder, got real traction, and then discovered they could not extend it. The data model does not support the next feature. There are no tests. Nobody can explain why a particular function exists. Rebuilding from scratch is cheaper than untangling it.
That rebuild usually costs more than doing it properly the first time, and it arrives at the worst possible moment, right when growth demands new features. The AI-built version was not a waste, though. It proved the idea was worth building. The mistake was treating a validation tool as a foundation.
If you are at that point now, a codebase audit before you commit to the next round of features is a genuinely cheap decision. It usually takes a few days and tells you whether you are extending or restarting.
Talk to us about your app
Duple IT Solutions builds mobile and custom software for clients across the US, UK, Canada, and Australia. If you have an AI-generated prototype and you are not sure whether it can carry real users, we will look at it and give you a straight answer, including “this is fine, keep going” when that is the right one.
Frequently Asked Questions
Frequently Asked Questions
It can build something that runs. Whether it can build something you can launch depends on the stakes. For prototypes and internal tools, yes. For an app handling payments, health data, or personal information, the generated code is a starting point rather than a product.
Often not. Veracode’s testing found roughly 45% of AI-generated samples failed standard security tests, and the rate did not improve meaningfully with newer models. The common gaps are missing access control, absent rate limiting, and credentials left in client-side code.
It is replacing a portion of the work rather than the role. The typing has been automated; the judgement has not. Deciding what to build, how to structure it, and whether the output is actually correct is still the job, and it now takes up a larger share of it.
For validating an idea, yes, and it is often the smart choice. The risk is treating that MVP as the foundation for everything after. Plan for a rewrite, or get the architecture reviewed before you build the second layer on top.
An audit is typically a few days of work. A full rebuild depends on how much survives, but expect it to cost more than building it properly would have. The earlier you check, the smaller the gap.
Need help with this?
We help businesses implement what we write about. Book a free call to discuss your specific situation.
