> LLMs are pretty good at picking up the style in your repo. So keeping it clean and organized already helps.
At least in my experience, they are good at imitating a "visually" similar style, but they'll hide a lot of coupling that is easy to miss, since they don't understand the concepts they're imitating.
They think "Clean Code" means splitting into tiny functions, rather than cohesive functions. The Uncle Bob style of "Clean Code" is horrifying
They're also very trigger-happy to add methods to interfaces (or contracts), that leak implementation detail, or for testing, which means they are testing implementation rather than behavior
They could've come out and said "Hey, due to increased demands, we're reducing the limit", but instead they chose to do a rug-pull, in the guise of "off-hour" limit increase, while absolutely butchering the limit in both peak, and non-peak hours.
Additionally, they chose to gaslight the users, wait until people make a lot of noise, "investigate", and reach the conclusion that the same users that have been using their tools, with the same exact models and the same exact workflows for months, suddenly can't approximate / estimate their own usage compared to previous months.
Such a bad business etiquette, but nothing unexpected.
Maybe, I do suspect _some_ parts are codegen or source map artifacts.
But if you take a look at the other file, for example `useTypeahead` you'd see, even if there are a few code-gen / source-map artifacts, you still see the core logic, and behavior, is just a big bowl of soup
Funny how before the announcement, people who were experiencing this were being gaslighted on different platforms, to think they have a "skill" issue using Claude Code
Additionally, this was practically predicted and expected by so many people, the second the off-hours increase was announced.
I personally don't mind React, but I do acknowledge, after using it for a couple of years, that it seems to be a magnet for issues.
It's the kind of framework, where if you're not writing properly, mostly like [Thinking in React](https://react.dev/learn/thinking-in-react) (with some caveat for niche performance optimizations), you're going to have a rough time, and you're going to make life miserable for anyone that does know what they're doing
It has a weird learning curve, where you can ship something somewhat working, fairly fast, but to write it properly, with no bugs, you need to understand a lot of niche React-specific things, and their solutions (and those solutions are never useEffect https://react.dev/learn/you-might-not-need-an-effect).
At that point, I wouldn't recommend it to anyone who isn't already experienced with React. It's been an uphill battle, trying to work with anyone that is using React, without understanding how to write properly.
I was looking at the Meet repository as an example, people literally don't know how to write React, without drowning in `useEffect`, `eslint-disable`, `any`. React has it's issues (and a ton of them), but writing code like this, I expect it to end up exactly like Microsoft Teams quality wise.
Honestly, at that point, it's indistinguishable from LLM slop
I'm not sure if React Native is much different from React itself, but a few things that made me give a side eye, when looking at this write up:
1. The instant 5 levels of providers (and additional one later) seems excessive.
2. The usage of useAnimatedReaction which seems almost like a "useEffect" kind of hook, which was sprinkled in almost every code block.
3. The imperative size calculations, does React Native not support any responsive like constructs? I recall solving the same problem by separating "history" and "tail" and having a "grower" component, without having to use any JS (purely html & css), albeit it being web and not native.
4. Personally, when I see something like the scroll code, where you have to call scroll, wait a frame, call scroll again, set a timeout, scroll again- I would have raised my eyebrows about the architecture / code flow way before that.
5. the amount of "floating" hook calls like useKeyboardAwareMessageList()
useScrollMessageListFromComposerSizeUpdates()
useUpdateLastMessageIndex()
that don't return anything, always makes me raise an eyebrow, usually in React Web codebases, where the users just spam useEffects and effect chains.
Not sure if it's just my ignorance in React Native, but if I had seen the equivalent in a React Web app, I would've been baffled
I’ve been using jj for a few months now and still love its workflow, but I keep running into the same problem you mentioned. The advantages of jj far outweigh this issue, so I’d really like to figure out a clean way to avoid these conflicts.