upvote
How are you evaluating the Android build if you don’t use Android and you don’t know Kotlin?
reply
We have people on the team that are android users. I just meant that I don't want to evaluate whether it feels "native" as I personally am not an Android user.
reply
You just install it on your phone and use the app.

Maintainability concerns are entirely overblown by people who don't use agentic AI to develop large mobile apps, but anyway give their opinion as if they had that experience.

I put in a few hundred hours, and I reached the same conclusion as Shopify. With reviews from other models and then a manual QA pass the result is fully usable.

reply
I work as a professional app developer. And I find this take to be naive.

Most of the time when I review code from AI, there is always something to improve.

It’s either a maintenance issue. e.g., Opus recommended and implemented a fix for a database corruption crash. This was ~400 lines of code with many moving parts. I reviewed, and found out Android Room library already handles this recovery case, and all I needed was a 10 liner PR that catches this exception and ignores it.

The maintenance is not only the burden on the human and LLM. With too many moving parts, it becomes harder and harder to build and verify the correctness of future features. Yes you can write test for this and that, but it didn’t need to exist in the first place.

The second problem is correctness issues. Especially the edge cases. You cannot just manually test out a race condition on a phone! Sometimes it happens! Sometimes it doesn’t! If it leads to a visible signal like a crash, then yes, you can try to reproduce it. But there are a lot of these that are “silent” and would just lead to bad experiences.

We already had a software quality crisis! And I think such views only exacerbate the situation! Quality matters!

And this is not an anti-AI stance. I vibe code personal projects where I don’t even look at the code. But when I use AI as a professional engineer, I act like a professional. Because these products do have an impact on people’s lives.

reply
deleted
reply
All true (and thanks for posting a concrete example rather than "LLMS suck"). But my take is that none of this is much different than before times when I had teams of developers creating applications. They would often make similar mistakes which I would either need to catch or which would flush out in the field. Where it seems that LLMs are not excellent is where the person driving it is also the senior domain expert so can immediately spot pitfalls. But typically using humans to develop software this was really not often the case. Those people get promoted so they're no longer cutting the code. Under that scenario (replacing subordinate humans) I find the current models are either on-par or somewhat better (specifically because the models can also act like a peer senior dev, discussing approach options etc).
reply
I agree with you! And I’m not trying to romanticize the past! Humans/me wrote slop too.

I think we are over-indexing on speed of delivery. I think this is a mistake. The alpha is in speed and quality.

Currently, my experience is that human + AI can write software faster and with better quality than either party can do alone.

reply
> It’s either a maintenance issue. e.g., Opus recommended and implemented a fix for a database corruption crash. This was ~400 lines of code with many moving parts. I reviewed, and found out Android Room library already handles this recovery case, and all I needed was a 10 liner PR that catches this exception and ignores it.

I understand this, but I just can't bring myself to care. I've been doing professional software work for almost two decades. These sorts of improvements/time savers are great without AI. With AI? Whatever. It's fine.

When the underlying lib has an issue, it'll be quicker to debug with the whole thing in context.

reply
So exactly what value are you adding, then?
reply
I take the specifications from the customer and type them into the AI
reply
You do realize that letting the LLM produce more output means that maintenance will be more expensive? I can easily see a world where claude and gpt are producing more tokens to sell you more tokens.
reply
This is not as obvious as many naively believe.

It depends on how hard to maintain the code added is, how likely it needs to change in the future, and most importantly on the cost.

If reviewing and manually improving the code takes hours, the cost may already be in the thousands.

That buys you a lot of AI usage, roughly a few months of continuous work.

You have to balance this with the chance that the suboptimal code the AI generated is actually fine and maintainable enough, and also the chance that during further work on that code a model might implement the same optimization on its own.

reply
Just the other day I burned through my 5h quota twice in a row because I had opus spawn a review session on a medium sized PR and I don't know what happened but I told it to summarize to me and it said it spent 100M tokens throughout 50 subagent sessions.

And more recently its been recommending that i install this new browser called Aside. I did, and it almost felt like I was installing malware so I Uninstalled it fairly quickly (it also was not a great browser)

I feel like theres collusion somewhere.

reply
yea man they are trying to nickle and dime you
reply
The models will only get better and inference cost will go down.

I don’t see any reason to think the same thing that happens with all tech won’t happen here.

reply
Enshittification and profit maximalization is around the corner looking for you.
reply
So you don't use agentic AI to develop a large mobile app and you think my take is naive?

I also used to work full time as a Android developer for five years, and I'm pretty sure I know better than you about the quality of my app that I work on everyday.

reply
No where did I say we don’t do agentic dev!

Years of experience doesn’t mean much! I will challenge you on ideas. And the idea you are sharing is dangerous and unprofessional.

Especially at scale. e.g., we process more than 3.5 billion orders annually! This is serious business. Edge cases are common.

reply
Same result here just using plain Opus 4.8+. I had a web ap with a PWA approach. Now I have an iOS app written in Swift/SwiftUI and an Android app in Kotlin in the appstores. I do not know how to code a single line of Swift or Kotlin. You just test the app and iterate with the AI over it until it is stable and does what it should.
reply
> I do not know how to code a single line of Swift or Kotlin

sounds like your app is nothing serious

reply
> You just install it on your phone and use the app.

Some people on the cybersecurity side are starting to cry....

reply
I have been getting these comments often here, including concerns about my non existent backend's security.

Last time, when I pointed out that the attack surface for mobile apps is typically very small, some users started to talk about zero day vulnerabilities in the OS's media handling, as if it was a concern for my app implementation.

I found the concerns again wildly overblown.

reply
You sound like a person who's never had their app pen tested. The attack surface is anything but small if you're working with any kind of sensitive data.
reply
But what if someone discovers a iOS 0day worth several million dollars and burns it to compromise your app specifically? /s
reply
Are there cybersecurity concerns in the frontend? I would have thought you have to assume the client is untrusted and only do security work on the backend
reply
1. Not storing secrets properly or using hardcoded secrets

2. Wild use of webviews/iframes sometimes easily propagates as XSS in phones

3. Incorrect client-side OAuth 2.0 configuration e.g. with schema-based redirect URLs.

4. Not supporting high-enough API versions, which may prevent some OS-related weaknesses

5. The list is actually very long. Just few top of my mind.

reply
My favourite is a logout button with a logout API that fails. (Not a huge pratical concern, I admit, because it's a local attack.) Nobody ever notices because it still shows the logout screen, which hides the API error toast (if errors were even displayed). The still valid refresh token stays in sessionStorage (or even localStorage) while the app displays "logged out". (Bonus points if you cleared the access token in the error handler but not the refresh token, and on page reload you ask the user to log in again despite having a valid token.)

Or a login form that gets hidden after login, but clears the username and password only when you click "login back in". (Bonus points if the backend also enforces a 5min session timeout "for security".)

reply
Storing private secrets in your public client is easy to avoid for anyone halfway competent. We are all professionals here.

Turn on the secrets scan in GitLab, and put in your release checklist to have the AI audit the usage of secrets in your app, and this is basically guaranteed not to occur.

I doubt current models even make such a mistake in the first place, and particularly so if you use reviews at all.

WebViews are not an inherent problem, it's the system browser embedded in your app.

Where it gets tricky is if your use case involves authentication in the browser. Together with the authentication in your app this is the one area where you need to focus on security.

The case where a SDK update is needed to prevent weaknesses of the OS seems rather unlikely.

reply
Doing anything right on web is 10x harder and more complex. The problem is the browser, once you use it to deliver anything you have to buy into all of it’s bullshit. CORS, XSS, headers, caching. All that just goes away (outside your backend API, if you even need one) when you ship a native app
reply
Fantastic answer thank you
reply
Nailed it. Assume your client is compromised and/or malicious regardless of how it was built.
reply
If your clients are compromised then what's even the point of backend security. Users will login and do legitimate actions while their compromised client does whatever behind their back, while still looking normal. And the backend can't tell the difference.
reply
This is the most naive take on security ever. For the backend, you assume your client is compromised, but you still don't want to allow your client to be compromised.
reply
They better start a proper hydration regime because they'll be crying a lot.
reply
Why? The api has to be secure. Mobile os keeps the app safe. Where is the attack surface?
reply
You don’t believe how often people leave secrets in the app or use webviews and iframes badly, misconfigure OAuth in client side and so on. There are many issues where secure API does not help.
reply
> You just install it on your phone and use the app.

OP says they don't have an android phone...

reply
No, they said they don't use android so don't know the native UX. You can test your app on the platform and confirm that the functionality all works, but how well it adheres to the platform's design language is subjective and hard to say if you aren't used to the platform.
reply
Android studio has a emulator
reply
I used the emulator - but just like I can use an iOS app for 30 seconds and tell you whether it feels native or not, I can't do the same for Android, since I'm not a daily user of Android phones.

And in the past, I didn't care because when I was manually building the app, I would just do my best with react native. But now that I can actually sweat the details (with the help of agents), I do want to hear from android users and use as many OS-native APIs and features.

reply
I missed that.

I'd order a cheap Android phone to have a device in hand instead of working only with the simulator.

reply
Others on our team use Android phones. So when I said that we spent the next few days actually polishing it, that's where others came in, providing feedback when they used it.

I could only sweat the details on liquid glass, etc because I'm a daily iOS user.

reply
That's a recipe for regressions as the amount of surface you have to cover with "just...use the app" gets bigger and bigger.

You can write more automation to test it. But that's also how you end up with ever-growing test run times.

There are much better ways that aren't just "throw out the LLM" either. You just need to be more focused on throughput. Requiring manual validation can pretty rapidly require more hours than just sanity-checking code by hand, even (and I'm not advocating that for every use case, either.)

I can't afford manual QA passes if I'm gonna go as quickly as I want to.

reply
I am using Gemini as well as Opus on a somewhat small project in React Native and I can not imagine this thing being able to build the whole thing on its own without it being a dumbpster fire.

Can you share some details of how you work? What models? What harness?

reply
We use CC with Fable(Opus before that) continuously on a rather large project, everything is tested, we maintain high verified test coverage, we ship features x10 faster than when we started(pre Claude-everything era 2-3 years ago). I never worked with RN before and I ship features now. LLMs allowed us to find issues within RN itself, that thanks to some patches, improved lower end Android experience by a lot. We just use all the Claude defaults with claude.md that evolved over last year.
reply
I use Codex and Claude Code desktop apps. I generally use only the SOTA, now Astra and Fable 5.1, Opus 5 when Fable runs out.

I don't know if Gemini is suitable.

I had few issues with my native iOS app, the results are just decent after a few iterations, the models do what I ask them to do. Where do you see the problem?

The LOC for my app is now at almost 200k + 110k lines of test code.

reply
what in the gobbledygook is this
reply
"the models do what I ask them to do"

what the fuck are you talking about

reply
can't believe what has become of this profession
reply
> Opus
reply
> Are there cybersecurity concerns in the frontend? I would have thought you have to assume the client is untrusted and only do security work on the backend.

I hate software engineering now.

reply
Damn, we really gotta get rid of the vibe coders. Bad things are on the horizon if we keep encouraging these naive habits.
reply
How do you propose getting "rid" of "Vibe coders" (which I'm assuming you're pooling me into?)
reply
Severe financial liability for security breaches, severe enough that, for instance, companies which leak 1m+ user data are driven to bankruptcy

[yes, this would also get rid of the previous generation of 1000-JS-lego vibers]

reply
Yes, what type of "engineering" is this? "I click the button and I see if it works or not" holy shit.
reply
> You just install it on your phone and use the app.

That‘s how you check functionality but that’s not how you get the bugs in the code.

reply
That's the part covered by the other model's review. That together with manually verifying the functionality results in output that works.
reply
If you don’t know the language you can’t evaluate if the models really found bugs.

That’s like translating a text to another language without knowing the language

reply
This is wildly overblown. I've been working with agents for a good while, read tens of thousands of generated Python and the language factor is actually the part they get right that humans don't.
reply
Do you know Python?

What do you think has more training data Python or Kotlin?

reply
Remember the first step to fixing any problem is admitting you have a problem.

If you are blind, you cant see anything wrong, if you are deaf uou cant hear anything is wrong.

reply
Seriously! What a bonkers thing to claim. "I had codex use maestro so I assume it made Android work well and idiomatically".

It's a fine project to do but clearly they put zero value on being familiar with the project's codebase/stack and ecosystem, which makes me feel fear in my heart when I imagine the first "production is down" page coming in. I already hated mobile because it's so much harder to maintain than web (and I don't do any spyware or IAP so no benefits for me there); this yolo approach would give me constant dread.

It shows that at least some software development is moving away from code and to product management instead. I'm not passing judgement on that; I actually think that's great for a lot of software. It is interesting to see the shift happening though and will be fun to see if the general quality of software noticeably changes over the next few years.

reply
> It's a fine project to do but clearly they put zero value on being familiar with the project's codebase/stack and ecosystem,

As much as I dislike it, I think that's the future of _all_ non-critical software (think social media, crms, CI, food delivery etc). Leadership in many companies is explicitly asking employees to have multiple agents running through the day and that will lead to this.

Read this for example: https://www.uber.com/in/en/blog/efficient-software-factory/ . A very useful system, I am sure. But when you have AI at every layer from code to review to triaging, rest assured AI is the only know who knows your system. And you better hope it's not telling you that something is load bearing during an incident.

reply
I answered elsewhere that I don’t personally use Android phones but we have people on our team that do. Which is why I don’t want to personally claim that it feels native.

But yes we are having real Android users test it.

So it’s quite the contrary. I care MORE what real users say. I can only guarantee that the app does things when I tap. So I’m not trusting the agent on UX, only on functionality. But whether it feels native, I am relying on those users in our team.

reply
That's much better than my original, perhaps unfair, read. Thanks for the additional info.

I still would feel scared operating an established product off a newly changed stack the team isn't familiar with though.

reply
> this yolo approach would give me constant dread.

When you’re completely ignorant, there’s nothing to be afraid of.

reply
I wrote every single line of the react native app we ported, and maintained it for 9 years. So suffice to say, I'm familiar with the code.

But I am going to always prioritize the user experience over a developer (like myself)'s need for satisfaction to see code. And a pure native app is _always_ going to behave better than react native.

This gives me a chance to do that.

reply
> And a pure native app is _always_ going to behave better than react native.

Maybe iOS is better about consistency, but I've used enough horribly made Android apps that I would not expect one that's vibe coded to behave better than a professionally made react native version.

reply
I would if it were based on the RN version. RN is kind of okay on iOS, but really shitty on Android. Would be difficult to be _worse_.

That said, I do recommend reading the code the LLM produces whether you understand the language or not. What better time to learn?

reply
Maybe. Android might still be a mess, fair point.
reply
>So suffice to say, I'm familiar with the code.

You are familiar with the React Native code, you are not familiar with the Swift or Kotlin code, and likely nobody on your team is, since the AI wrote all of it for you.

reply
First “production is down” page means you just tell codex production is down and to fix it.
reply
Presumably a sarcastic post, but this is actually going to be how things are done soon. I had a box that OOMed and needed to be rebooted every few weeks. It was a disaster recovery standby box so figuring out what was going on never rose to the top of my priority list. So I asked Claude to dig into it (proxying the commands it wanted to run through me) and in an hour it had diagnosed the problem, fixed it, and taught me a bunch about memory usage in our system on modern kernels.
reply
Not sarcastic. I have a moderately successful app and I haven’t once looked at the code (though I am capable, so far atleast). The only time I open Xcode is if I have to modify signing certificates. I did set up a slack workflow with a “fix it” button that basically tells Codex to fix the issue, run comprehensive tests, manually UI test for that particular issue with computer use and then deploy it.
reply
Equal parts very cool and very scary to me
reply
It is. For my day job, I’m a software engineering director and I probably won’t have a job in under five years. For low to medium complexity apps, even Codex before Astra was capable of doing it completely by itself from scratch. For testing I would bring up the app after each atomic change and then manually try it out. I also use my own app heavily multiple times a day and I have found dozens of issues but I just ask Codex to fix it on the spot.
reply
ITT: people dealing with realities.

Remember Chinese accounts on US Facebook say data centers are bad.

reply
React native is an obstacle compared to what clear Swift/Kotlin code may produce. Swift is very powerful and Kotlin, in all honesty, is the first reasonable and very useful thing to come to the JRE ecosystem (save for Scala, which is, well, quite complex still).

Myself turned some python code to Swift, and keep doing so, without trouble or pressure. Of course, I've been doing fair amount of systems programming for 20 years now, so not sure what to advice newcomers. But this approach to dev DOES work for me very well.

reply
Sounds like the advice to newcomers is to not worry about trying to learn a programming language. There already is an llm to program for you, and do it better than you could, so just learn how to talk.
reply
Once you understand how to write a program get someone else to write it - Perlis.

[1] Epigrams in Programming:

https://engineering.yale.edu/academic-study/departments/comp...

reply
And people say AI isn't taking SWE jobs...
reply
While I mostly agree with you, this is the kind of thing that might not have been done if the AI couldn't do the heavy lifting.

They had previously chosen React Native because it was easier for programmers to keep it updated, since it was really just 1 codebase. With AI, those same programmers can do the more difficult version, keeping the native apps updated separately.

So did it kill a job, or did it make it possible for the existing programmers to do it better?

It's the kind of thing that is really hard to determine in general, but here, it really does sound like they only made the change because it became possible with existing resources. They would not have done it otherwise.

reply
That's an example of AI growing the sector that can lead to more jobs. Because suddenly a lot of tasks that weren't economically viable are now going to be in demand. Custom software for small businesses, platform specific optimized code instead of cross platform software, etc...
reply
This is a type of project that likely wouldn't have been done before AI
reply
Of course it would. Supply and demand. Some companies would decide not to bother. Others would decide it was worthwhile. The limited pool of supply (app developers) would be distributed across demand.
reply
>> Some companies would decide not to bother. Others would decide it was worthwhile.

The parent's point is that AI lowers the cost/benefit ratio drastically, by reducing the cost. So companies that would have shied away from projects like this pre-AI are now pulling the trigger without much hesitation.

reply
And what a lot of people seem to miss is that with AI, there is going to be (already is?) orders of magnitude more software in this world. I'm sure a lot of jobs will be eliminated, but new jobs will be created as well. Hopefully enough to balance things out, but we'll see.
reply
> The parent's point is that AI lowers the cost/benefit ratio drastically, by reducing the cost.

…as long as Claude is still subsidized…

reply
[dead]
reply
> Some companies would decide not to bother

Sounds like you agree

reply
I agree that AI is suppressing developer wage growth and taking real jobs. The opposite argument is being made elsewhere in the thread, and I think that argument is wrong.
reply
This app has 15/20 screens, an app this small wouldn't employ many people to begin with. Before there was one guy (op) maintaining it in react native and now he maintains it native. I don't see much change tbh.
reply
The optimistic outlook:

Just like this has made Web devs into Mobile devs, so could Mobile devs leverage AI to work in Web shops.

I'm not an optimist but there could be an increase of available apps being created which would still keep people employed. Theoretically the cost of creating an iOS app for a company without an engineering team dropped from several hundreds of thousand to a few thousand or hundreds, which could be paid out to a freelancer with AI. More people would go into freelancing for industries which were not contemplated before due to cost.

But I'm not an optimist.

reply
This is an incredibly boring task. Nothing new, just rewrite everything to just see it all rewritten again in 1 year. Perfect for LLMs and something humans shouldn't do.
reply
While I agree with that statement -- that is also a lot of jobs. We have a lot of humans -- not every single developer sits in the innovation seat. The fewer the jobs available the less employable humans.

I think that rewrite - if AI enabled - owes its thanks to the legion of individuals who put their code up on the internet in the first place.

Weird times.

reply
Unfortunately theres no thanks to the suppliers of training data. US courts made sure there’s no recompense for them, and likely never will be.

Seems similar to eminent domain, but without limitations.

reply
> This is an incredibly boring task.

We all want super exciting jobs. But plenty have boring jobs like this. Between not having a job or having a boring job that pays well, the choice is obvious for many of us.

reply
Are you defending doing boring work?

I personally never minded doing migrations. I guess I don't really have to anymore though. Weird.

reply
The problem is that in many companies doing migrations would be the only job, thus now there is none.
reply
deleted
reply
This is just not true. In the olden times (pre-claude) devs were constantly asking to do full rewrites of legacy code. This kind of project is exactly the kind of work I've trained for and have loved to do for the last 15 years as a mobile dev.
reply
It ported overnight. I don't think it would create from scratch without a lot of hand holding.
reply
This does seem like the kind of task LLM's are ideal for. Just like that port of Bun from one language to another.
reply
Previous company I worked for would have (and did) hire dedicated swift/java mobile developers to build and maintain ios and android native versions (largely porting functionality from an existing web application)

Not anymore.

reply
What's more likely (as others have said) is that the other thousand companies that can't afford to have dedicated staff would've just used React Native. So no jobs were lost, they weren't there in the first place. The places that have dedicated Swift/Java devs can now be more ambitious in what they build.
reply
That's fairly rare. Most companies would use a compatibility layer instead.
reply
Really? I’ve worked with plenty of companies that had separate native iOS & Android teams. I don’t know any that use a compatibility layer. Unless by compatibility layer, you mean a web view.
reply
deleted
reply
Congratulations, you now have 2 codebases to maintain.
reply
I assume having Kotlin and Jetpack Compose makes it much easier than it was back around 2020?
reply
React native is broadly an inferior option.

LLMs made it way worse https://ashishb.net/tech/react-native/

reply
this is from 2021....
reply
and still accurate in its conclusion, probably moreso today
reply
So now you have two vibe coded applications you don’t understand. I’m not an advocate of making “job security” decisions but this definitely goes to red flag territory. Was it your job to maintain the RN codebase or do you have other functions there as well? I’m not sure I would keep a native noob on a vibed native codebase. What is your take?
reply
And there's no proprietary IP in your company's app that you don't mind being sucked up into the training data?
reply
> there's no proprietary IP in your company's app

For most app that concept is "gone".

People routinely decompile and recompose existing binaries, and if you use "obfuscation" in your app it's still a small bump.

In today's age, IP is no longer a tangible concept that gives any advantages in software. What differentiates two businesses isn't their IP, it's their relationships and their moat.

Most vendors that had protected proprietary IP are now irrelevant within their vertical. What saves them are the protection provided by patents, which is public.

reply
Are you saying you don’t trust ZDR claims from inference providers?

They don’t care about your code. There’s more and better data on the public web.

reply
Isn't ZDR only the case if you "opt out" through a setting? Lots of opportunities to make a mistake here, or for the LLM provider to play games. You could be unaware of the setting. The provider could reset the setting upon subscription lapse/renewal, application update, model release, etc. A developer could accidentally use their personal subscription (w/ setting on) on a work codebase.

Also what's the timing on this setting's effectiveness? What if before you knew to "opt out" you used the agent for a refactor and your entire repo got sucked up in inference? But then you opt out the next day? Is it too late?

reply
That’s the case with a personal subscription directly with OpenAI or Anthropic, but enterprise customers are opt-in, AFAIK.

And there are solutions around it from other providers and model routers. OpenRouter lets you explicitly say on a per-request basis you don’t want to be routed to a provider that trains on your input, for example.

reply
The mistakes you describe are only possible if the company doesn’t really think there’s proprietary IP in the codebase.

If a company really believed there’s valuable IP in code, there would at a minimum, ban laptops or ban code on laptops[0], provide and maintain a centrally managed LLM gateway[1] that handles authentication, billing and model choice, have MDM to prevent you from using your own Claude login, etc.

[0]: For example when I worked at Google, the proprietary google3 codebase cannot exist on laptops because there are no tools to download it to your laptop.

[1]: For example Claude code supports having a gateway: https://code.claude.com/docs/en/llm-gateway-connect

reply
I'd wager many software startups out there would consider their code valuable IP (even if in the AI era it's not), and don't have these types of IT controls in place. Startups I worked at gave you an email account, github access to their private repos, and that was that.

Heck, you don't even need to mix up a personal and business AI subscription. For the vast majority of folks one day their IDE "updated" and a bunch of AI features suddenly became available. Free, no sub needed. A dev starts using them (because, why not?) and lo and behold the company's code got shipped out in an inference call and is now scheduled to be in the next training run. Oops.

reply
You are merely describing companies that aspire to consider their code valuable IP, not companies that actually do so.

IDE updated? It’s the company IT’s job to perform testing before distributing those updates. And also their job to use whatever managed settings to disable those unmanaged AI features.

reply
How's that any different from, say, Windows updating and backing up the company's code to OneDrive?

Actions speak louder than words. If the company doesn't even supply and require work devices, they don't effectively consider their code to be valuable IP.

reply
Is Microsoft mining their customers' backup files looking for source code to ingest into their model training pipeline?

Of course the company can still consider their code to be valuable IP.

reply
You should educate yourself about AWS Bedrock and Azure Foundry.
reply
The value of most companies/apps are in the relationship with the customers, so it's the database, not the code.
reply
Definitely agree. Most developers could build a basic Twitter or Facebook clone. The hard part is getting the users, content, and relationships that make the product worth coming back to.
reply
As other have mentioned, the code isn't the valuable part. But also there are alternatives now to these LLM providers.
reply
Frankly there’s more likely to be proprietary IP in the server side code than in mobile apps.
reply
True, but shops are exposing everything to Claude or Open AI. It's akin to outsourcing all manufacturing to subcontractors in China. That was cheaper, but extremely short-sighted. Now so many products have cheap Chinese knock-offs that are nearly the same as the originals because the subcontractors made both.
reply
Codex with what model?
reply
I think probably GPT 5.5, or 5.6 Sol - it was ~ 2 months ago.

Each time I get access to a new model, I do two things on all our active codebases:

- Security review of all the code and vulnerabilities (new models will find new stuff)

- Code review of test suite quality, and idiomatic patterns/code for the language of that codebase.

And in the case of swift and kotlin, it's even more important that an agent helps me with the code quality since I don't know what "idiomatic" swift or kotlin looks like, the way I do with JS, Elixir, C#, Ruby, etc.

reply
This has been my conclusion as well. Agentic workflows drops the effort level in keeping two native code bases in sync.
reply
Same conclusion here. My current preferred setup is native for iOS and Android with common core in rust exposed through uniffi
reply
I was surprised by your comments and then you do Rust to be called via Java or Kotlin and Swift?

What does your app do?

reply
Yes uniffi created swift and kotlin bindings. The app I did with this is just a sudoku game https://www.puzzlesight.com . Before AI I would have reached for something like Flutter to avoid doing all work twice but with AI doing two apps makes more sense.
reply
Okay, makes sense, the whole thing looks and screams vibe coded. On a beefy machine, navigating between your website pages takes 2-3 seconds. So still a long way to go with AI.
reply
Next up, designing an even higher level language which will be used by LLMs to compile to high level languages like kotlin or swift. Just store instructions for LLMs in repos.
reply
I hate to break it to you, but we already have it: it's called PHP
reply
[flagged]
reply