You can today develop a mobile app with 20 screens without ever reviewing any of the code generated.
If you test each feature and have it iterate on your feedback, you can build a decent product in this way.
Does it write too much code? Perhaps. Could I bring those 100k lines through code review in a team where some members nitpick? No.
That does not change the fact that it works, and that you do not need to read the code even today.
Unless progress slows down dramatically and soon, it seems rather likely that most of us will not be reading code in the near future. Their marketing is not wrong.
Unless the app is released and running on user’s device, your “it works” is on the level of hackathon’s demo. Being on prod has always been the true testing ground of code.
It seems like when people are talking about production level quality and how the AI. should be helping them there, plenty of people comes up with their “it works on my machine” anecdotes.
Honestly, things have really changed in the past 6 months. Opus 4.5 got most of the way there, and Fable can now literally one-shot your run off the mill CRUD app.
I use a few of them daily. While there are still bugs, there are significantly less than there used to be back when everything was being maintained in my spare time.
Still not Netflix/Google standard yet, but definitely better than the average side project or pre-AI Bangalore special.
That is true, I was mostly speaking about a supposed need to review the code.
My effort instead goes to manual QA testing, providing feedback and preferences, and asking questions.
The limitation here is mostly that the model does not know what looks and feels good.
With improvements to the vision capabilities and a better understanding of motion, or what looks appealing to humans, the implementation could probably happen much more autonomously.
> That is true, I was mostly speaking about a supposed need to review the code.
Until you go to prod, you can believe a lot of things about the state of your code. Reviewing code is not merely about “Does this things work”. Testing and linting do cover most of that. Reviewing is mostly about: Will this design cover the current set of constraints (some may be conformance) and can it evolve? Are the assumptions correct? Is the security layer good enough?…
The user interface part of the code is only one single component out of many.
Even though a lot of mobile app are just presentation layer for a backend service, there are indeed a few stuff that warrants carefulness.
Like any data saved offline. Any update to that offline format means a migration plan unless it’s just a cache for the online data. Then if you support something like multiple organization, you don’t want user data to jump the separation between those siloes. And finally, if you you data that are created locally, or present data that are transformed locally using some feature, you have to be sure you’re not corrupting it or open some side vulnerabilities (think about the clickable vulnerability in messaging apps).
UX and UI can be designed using a prototyping tool coupled with user feedbacks. And with the wealth of components in the mobile SDK and the UI toolkit ability to create custom widgets, it’s very easy to implement the final version of that design. Most of the delicate work is presenting the correct information and that each interaction proceeds well.
Regarding clickable vulnerabilities in messaging apps, are you referring to the exploits that were enabled by vulnerabilities in system media parser and browser components?
This has essentially no practical relevance to app implementation.
What we are left with is not corrupting user data, particularly during migrations on app updates.
Compared to the attack surface of a backend service that handles user data, this is trivial.
We agree that the delicate work is presentation and interactions working well on device.
In my opinion this is best supported by extensive manual QA and user testing, rather than code review.
This is what unlocks tremendous productivity for mobile app development with AI.
I really hope vibe coded apps have to be labeled as such so I can make sure to avoid using them. As a customer, I have zero interest in using something that was made with little care or expertise.
If you test each feature and have it iterate on your feedback, you can build a decent product in this way.
Does it write too much code? Perhaps. Could I bring those 100k lines through code review in a team where some members nitpick? No.
That does not change the fact that it works, and that you do not need to read the code even today.
Unless progress slows down dramatically and soon, it seems rather likely that most of us will not be reading code in the near future. Their marketing is not wrong.