Go full native for each platform. React Native and Flutter are great (I’ve used them both), but there’s several reasons not to choose them anymore

1. Complexity - you’re adding another layer between your app and the device, debugging, compilation, device quirks all become much more annoying

2. AI coding makes it easier - This works both ways, flutter and react native become easier to develop, but so does native development

3. Support is always better on native - consider any issue you have building an iOS app, now add in React issues and then React native issues and then a bunch of other framework version issues… it’s generally better support if you use the tools the platform expect you to use

4. Code reuse is not as big of a deal as you think - trying to share UI code across android, iOS, web ends up making all platforms you build for worse, as bugs and performance issues go to all platforms… if you have a simply designed app, then a native experience is always preferable by users

The idea of “your own agent instance that you can link to anything” has merit, but it was just so annoying to configure and actually quite expensive when linked to OpenAI (a few dollars a day to do nothing) also seemed to be a never ending stream of happy-baked vibe-coded features being merged… the whole project just gave me the ick

Also point 3 “No money in gaming” is probably the main factor. There is orders of magnitude less money in gaming, than in SAAS. Think of how much money businesses pay for even basic software.

I’d also say performance is so critical and specific to every game, that getting AI to manage & architect it is fairly difficult (slop kills performance). This is nowhere near as big of a concern for most SAAS (slop friendly)

Even with all these reasons, I still think it’s worth trying to build!

It’s much more fulfilling to give the LLM guardrails by engineering the solution.

This means coming up with the high level architecture, dependencies, breaking down the system into deliverable chunks, and implementing those chunks. The LLM can help in all those steps of the process. And it will be much easier to review and keep an understanding of the code.

I love this quote, reminds me how annoying it can be when something isn’t reproducible locally… only in production…

I don’t love GitHub, but that number is a little misleading… That’s the intersection uptime of all GitHub services, most of which I (and most users) do not care about; code spaces, copilot, packages etc…

When you take out those uptimes, it becomes a lot higher. I’ll admit there seems to be a lot more incidents than usual though…

I.e. Large displays get “icon + label”, whereas small displays just get “icon”

I would argue mainframes rebranded to "cloud" which is ubiquitous and more people interact with this computer than any other type of device... only difference is that it's a browser instead of a terminal

Couldn’t find a link, is that hard to do?

It’s much safer to use something like opencode and use models via their API… however, the tradeoff is that it will never perform as well as it does in their native agent runners…

Pretty sure from inception the phrase “tokenmaxxing” was never seen in a positive light…

> AI coding assistants hallucinate package names. They confidently suggest npm install some-plausible-sounding-package for packages that do not exist. Attackers monitor those hallucinations and register the names - a technique now called slopsquatting

Slopsquatting is a hilarious name for this

There is no “best way”, it always depends on what you are building.

The main advice I would give is to always remember that there’s trade-off’s in every architectural choice…

I guess some general tenants might be… “great architectural solutions…”

- Allow new features to be added, without much complexity

- Have reliable and clear abstraction layers

- Allow tests and typing to validate it’s correctness

- Manage clearly understood limitations, rather than implicit surprise limitations