Hacker News Reader

Comment by user43928 | Hacker News Reader

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.

View on HN

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.

I use the app every day and I am confident in the quality.

I will launch it by the end of August. After ~4 months of hard work.

If it’s 4 months of hard work, then it’s not like you’re blindly doing it as the top commenter mentioned.

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.

In the context of a mobile app the user interface is the main part.

Testing and linting often do not cover whether things work or provide decent UX. The 'security layer' is almost irrelevant here.

Do you do mobile app development? I would guess not.

Then you would have guessed wrong.

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.

I was not talking about a backend service here.

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.

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.

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 think that the app I am working on suffers from little care or expertise, you would be mistaken.

It works far better than the competition.

Reply on news.ycombinator.com