I thought the recommendation was to not plan for scalability but rewrite every time your user base grows tenfold. I'm only half-joking here :-)

This makes sense in a way; why design for potential future growth in an environment of fast-paced technological and business development, bringing greater risk?

It seems the problem is the solution, and vice versa.

We had DRY for a long time. Now it's sloppy wet

Data correctness. You can purge and re-prompt your codebase any time. You can't your data.

This is something I've been thinking about more and more. Since Opus 5.5 came out, I feel we've crested the hill and the answer for "who's going to maintain this slop going forward" is obvious - the LLMs will. Whether or not its slop, is extensible, maintainable, or forward looking almost doesn't matter anymore. Does it solve the problem today? If so ship it, and use the agents to solve the future problems. I am not quite sure this is a good idea, but assuming LLM progress doesn't stop means its probably the bet I would take.

I watch a YouTuber who is homesteading and builds everything. Often times I see him doing things in ways I know will break or fail eventually, but it doesn't matter because he is there and will fix it when it does. You could argue this is a waste of energy, and for a human it might be. For an LLM however I do not think it is.

Why would it not be a waste of energy for an LLM? It must still be a waste, but perhaps the cost of the waste is so low that it’s much easier to justify

Yes, the cost of fixing it when the actual problem arises is IMO lower than the cost of spending energy and human time up front to make it maintainable and extensible. I know it sounds crazy when I write it out like that, but this is something I've been thinking a lot about recently. Agentic coding is a paradigm shift and we have to rethink a lot about what use to make sense.

I know it’s kind of a hot take and it might also be hazardous to my career if I’m right, but I kind of agree. If you create a code base that has some significant flaws, and a bug or change request arises later, it is definitely possible that “Super Fable” or GPT-7 Multiverse or whatever can, for $500 of tokens or whatever, perform a refactor of all the related modules, and create and thoroughly test all the necessary data migrations, as a prerequisite to fixing the bug.

I also think that if we’re being completely fair here, we have to acknowledge that most codebases that are more than a couple of years old are giant piles of tech debt already even with 100% human code. At least in all of my jobs, none of which were FAANG, nor run by extremely elite engineers. YMMV.

I (slightly joking) think this is amenable to zero-one-many. The first time your user base grows tenfold, rewrite. The second time, you need to rewrite again to plan for arbitrary scaling!

This is just correct engineering practice.

"Oh no! We're making so much money off the massive number of customers we have that we need to redesign our system!"

Most companies never make it to that stage.

Get there to that point, don't fall victim to second system syndrome and spend 3 years on the rewrite, and you'll be fine.

There's been some discussion around Shopify (and others) move from React Native to purely native and that leading some people to conclude that LLMs have effectively killed RN. Which has always seemed silly to me for 2 reasons: First, Shopify almost certainly has on staff (or access to) actual native devs to steer that ship that a small/medium-sized company may not have. But more importantly, it's not the "Translate this RN app into native" that's the trouble. It's the hundreds and thousands of additional iterations you'll have to do on top to maintain and build out that product.

It's hard keeping separate code bases with separate languages in tandem, and while LLMs definitely aid in that area, I can't imagine it's a free lunch.

The other part that seemed short-sighted to me was the realities of modern app store reviews. Apple and Google are only getting slower as vibe-coded apps flood their marketplaces with submissions. Maybe Shopify has a special relationship that gets them faster reviews, I don't know. But if not, the ability to put out updates, rollbacks, and hotfixes without being gatekept is a critical feature. Especially with today's security landscape. React Native now seems more compelling than ever before.

From what I heard, updates for many established developers, even individuals, go through within a few hours.

I'd also love the ability to take back control over my rollouts, but with Apple's recent crackdown on remote controlled feature flags in response to fraudulent nudification apps, I'd be very careful about this.

Rumors say Apple now uses heuristics to detect feature flags in the binary. While that's not directly relevant to remotely delivered JS, I fear that bypassing App Review in this way could become a quick ticket to account termination.

It’s probably only a year or two out that Apple will inform us that “for security reasons,” they’ll only accept App Store submissions in the form of an XCode project, i.e. as source only. (What are developers going to do? NOT be on the iPhone?)

I'd have original Slopus 5 rename my variables and replace all comments with inline 'docs' for my existing 500k LOC code base.

Good luck with parsing that one, Apple.

I'm joking, but in seriousness, I'm not sure they would gain much from that which they couldn't already analyze from the binary.

Yeah, I have an app with ~150 users, and Play Store updates slowed down to about a week for a moment, but lately they have been going out within the hour.

I've heard those reports, but it's absolutely insane. Having feature flags is table stakes on mobile. And being able to put out security or bugfix updates rapidly is the killer feature of React Native. The current ToS say you need store review for feature changes, and that's fine. But OTA updates and feature flag changes for bugfixes, phased rollouts, A/B testing, and security patches are critical.

Just last week we saw a critical CVE in BetterAuth integrations for mobile app sessions. Being able to put out a patch without being gatekept on review is just so important in a world where crazy security vulnerabilities are being disclosed daily.

What makes you think you can circumvent the App Store to update React Native apps?

For Google, the Play Device and Network Abuse Policy calls out exceptions for code running in a VM or interpreter[0]. For Apple, App Store Review Guideline 2.5.2[1] and Section 3.3.2 of the Apple Developer Program License Agreement[2].

[0]: https://support.google.com/googleplay/android-developer/answ...

[1]: https://developer.apple.com/app-store/review/guidelines/

[2]: https://www.sec.gov/Archives/edgar/data/1581760/000119312522...

How is RN speeding up your app store review time?

You can set up your app to do over-the-air updates. This can be as simple as shipping an updated JS bundle or delivering just patch diffs for it to apply. So long as your code changes are JS-only and don't involve any native code, you can push an update.

People are already used to being able to do things like phased rollouts, automatic rollbacks, and hotfix deployments for webapps and API services. OTA updates let you do something similar for mobile.

It's against the ToS from the stores to do this for notable feature changes that impact what the user sees, but for things like fixing crashes, bugs, or applying security updates, it's a game-changer.

We moved one of our apps away from RN to SwiftUI and Android (Jetpack Compose). The binaries are way smaller, and the apps work beautifully.

So I don't see any reason to stick to RN, when we can just use any OS native APIs to our heart's content and our apps automatically feel more native.

> So I don't see any reason to stick to RN

For the exact same reasons you chose in it the first place: experience with React to build a single codebase for different platforms.

If AI allows you to build your native apps and keep 2 different, growing code bases in parity without needing native dev experience, then use AI. But my point of the original comment is that those decisions are different at smaller companies than Shopify. There is no free lunch.

I am saying that my repo now has iOS and Android folders, and when I request a new feature, Claude builds it in both languages and tests in both simulators.

And that can work for a company of any size.

You're still stuck in this loop of humans reviewing and maintaining code. It's over. They will go native and abstractions like RN will die.

This is it. Most people (including myself occasionally) are having trouble letting go of the old world. It's not about writing code that's easy for you, the engineer, to maintain anymore. Our context window is small. Things need to be easy to read and well organized for us to work with. LLMs will write the code in a way that's efficient for them. If it's easy for an agent to jump in and make a change without doing a ton of investigation first, it's maintainable code.

Abstractions are for humans.

> Abstractions are for humans.

I disagree with this. The mistake rate goes up rapidly as context grows. Current frontier models get noticeably more stupid at context sizes of only 100k tokens or so, and inference becomes slower as the context grows, leading to more rework and more token usage.

I foresee a trend of having _smaller_ code units, more modularity, more abstraction, because agent work on smaller units leads to smaller contexts and a better chance of the agent getting the change right first time. Or a higher likelihood of a lower skill, lower cost model getting the change right.

I agree completely. That doesn't require abstractions though. All that can be done with native code. In fact, the abstractions often grow the context window if you need to debug any mildly complex issue.

> Current frontier models get noticeably more stupid at context sizes of only 100k tokens or so

It may be domain/task/prompting dependent etc, but my experience is different. I haven't subjectively felt any degradation up to like 500-600k tokens with current Opus/Fable models. After which I usually do a manual hand-off to a fresh session anyway. I don't use context compaction though.

I think it probably is domain related. My main work for agents at the moment is on improving a crufty human-written JIT recompiler, and the number of mistakes and oversights even the very best models make is substantial. I would say maybe 50% of turns are correct semantically and don't regress performance, and that's after writing a lot of documentation, a lot of tests, and splitting up the codebase into smaller modules with well defined interfaces to reduce context size for any one change.

The first attempts I made to one shot improvements to the recompiler before doing the refactoring and test framework were basically all wrong and introduced lots of bugs, a per turn success rate in the single digit percentages. Each of the non-functional changes I made improved the performance substantially as you might expect. The real eye opener though was the refactoring into smaller units - that bumped up the success rate much more than I was expecting.

Don't get me wrong, the success rate of human changes is abysmal on these tasks, which is why the recompiler was in such a sorry state already. There are edge cases and gotchas everywhere. Opus, Astra and Gemini 4 all reason for hours on individual changes, and lesser models can churn for much longer and still fail.

Interestingly the code itself isn't really all that big - about 45000 lines of C all told.

[delayed]

That's called reality, anyone that throws their product to LLMs to design, code and review will end up with a pile of slop garbage pretty quickly

While this unattended example is impressive, this is why you need to guide things more closely and make sure the design is itself scalable and maintainable. Otherwise you can get wad-o-slop.

Same thing happens in many cases with junior or mid-tier programmers slung at a project without supervision.

> While this unattended example is impressive, this is why you need to guide things more closely and make sure the design is itself scalable and maintainable. Otherwise you can get wad-o-slop.

Indeed, I'm curious how much better/worse one human with "one agent" could do that same functionality in a OS from scratch. Last time I did this exercise, I took Cursor's shitty attempt from "millions of lines of source code" to about ~20K (https://emsh.cat/en/one-human-one-agent-one-browser/), and seemingly one of my conclusions still hold true ~1 year later:

> One human using one agent seems far more effective than one human using thousands of agents