gitgud

That is a typo sorry (half-baked) reminds me of a bakery!

Well since nobody is suggesting it, then I will.

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

I gave it a shot 4 months ago. 150k GitHub stars, it must be worth trying at least right?!… turned out to be some of the buggiest and clunkiest software I’ve ever used…

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

My initial thoughts are Cursor is already generalised to build all software, and Games are just a subset of all software. So it’s probably good enough.

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!

Same legal system, but an OpenAI enterprise contract is not the same as a ChatGPT pro subscription... The terms of service agreement would be quite different

If you have an enterprise contract with them, the legal protections for the consumer is much higher… is what I’ve been told anyway

Pure vibe-coding isn’t that satisfying (as you’ve discovered) the problem is you’re constantly reviewing its huge output, and it probably goes wild in directions making assumptions.

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.

> The difference doesn’t matter until it does, and then it’s infuriating to work out what’s going on.

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

I love this choice. As I began reading, it was immediately clear that it was deliberately written by the author, not AI marketing slop

> They're at 93.91% uptime over the past 90 days, according to https://mrshu.github.io/github-statuses/ , and that doesn't even include today's outage yet.

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 assume they signal what menu item does what, to make it less confusing on different screen sizes.

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

Good UX abstractions out perform bad ones, which means they endure, are copied, and eventually become the implied standard UX… some examples of this are; the hamburger menu, tiny icons and auto-scroll for streaming text

So no human in the loop then? Sounds like a recipe for tech debt…

> Mainframes survive, but serving a much tinier portion of the market than they used to.

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

So at that tiny 500kb size I imagine it could be compiled to web assembly, and run entirely in the browser right?

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

This is one of the reasons why native proprietary coding agent runners like claude-code, codex, grok-build etc are so dangerous for privacy… you just don’t know what “secret sauce” they’ll add in the next update…

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…

Not allowing full screen is the most insane thing for a “chat app ported from the web”… the browser probably has a better experience now…

> Kirsten: All of this, to me, illustrates how quickly things are moving. I mean, when you really think about it, the whole tokenmaxxxing thing has become a thing, peaked, and now is seen disfavorably, within six months

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

Article and this post seems to be AI generated… but this is a good quote

> 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

> I realize I don’t have much knowledge about the best way to architect applications

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

> we need to stop filming people, and we need a societal norm that treats a violation of this ban on par with spitting someone in the face.

Agreed. Filming strangers in public is making everyone scared to have fun trying anything new, as they’re afraid of online mockery…

I started believing at 4 years old when going to a christian school, then stopped believing a few years later when I realised I couldn’t see any proof of any god watching, planning or influencing the world in any way at all…

Finding bugs in PR’s are exactly what GitHub copilot, GitHub cursor bot and tonnes of other PR bots already do…

What does the AS stand for?

A polite fyi, when skim reading this, it looked like it said AssNotes…

Well damn, start the countdown till the inevitable exploit of this.

I’m thinking maybe 1 or 2 weeks from now…

It's cheap to change code, it doesn't mean you have to add more of it...

Considering they’ve become a 1 trillion USD company, they’re truely moving fast and breaking things…

> I’m a new solo dev with almost no audience. If a large org or a well-known developer sees the idea and ships a similar implementation, they can get more attention immediately than I can get in months. And in the end I get nothing for open-sourcing my project.

This has always been a fear of open source development… but in reality it’s over exaggerated, thousands of FOSS ideas are posted every day…

My advice would be to treat posting your project like a launch, and get all the readme’s, docs etc ready before posting, so it has the best chance of growing an audience, which seems to be your goal.

But if you really don’t want other people to recycle your idea, then open source is not for you…

> Putting this here in the hope that someone at Anthropic reads it.

Needs more sensationalism to get their attention, like “Tell HN: Claude won’t implement this basic feature!” /s

I don’t think they “got lucky”. nextjs is an old project now, and for a long time it was the simplest framework to run a React website.

This is why most open source landing pages used nextjs, and if most FOSS landing pages use it, then most LLM’s have been trained on it, which means LLM’s are more familiar with that framework and choose it

There must be a term for this kind of LLM driven adoption flywheel…