I think you should read it again and rethink this response.

I read them again, and my response remains the same. None of what you say matches my actual experience using these tools.

I have repeatedly noted security as a topic where care must be taken, it must be hands-on, and you should not rely on black box thinking for anything important.

And nowhere did I argue otherwise. However, if your input text boxes are a security concern then you might want to step back and think hard about the design of your app.

noted that common design patterns regarding state will inevitably means these components will not be things you can treat like black boxes, you will need to maintain them.

I don't know what design patterns you use, but I'd rethink them, because you absolutely can create self contained components. Any component library is a testament to that.

I noted that others needing to read your code will need to have semantically named content to more easily understand it and that the writing portion of simple components is much less important (and time-sucking) than making a coherent and intentional design.

This is based on an assumption you've made that code generated with LLMs will be difficult to understand. This is not my experience at all.

I critiqued the idea of these LLMs producing idiomatic code, a claim you introduced, and you got confused about the topic, treating my challenge about newer idioms as a suggestion to follow fads as if it were silly for these LLMs to… produce idiomatic code. I explicitly noted inconsistencies like this.

I'm not confused about anything here. I simply rejected your claim and you got upset about it.

You largely ignored these responses or seemingly misunderstood them, responding in ways that made no technical sense. I attempted to clarify, giving you many opportunities to recognize where we agree or reframe your responses.

No, I understood them fine and I addressed them repeatedly in this thread. What it comes down to is that none of your claims match with my actual usage of these tools.

Then you went meta and suggested this discussion was pointless. Now we are here, with you insisting you’ve responded to all of my germane points (you absolutely have not) and then repeating your original position for no reason.

I suggested this discussion was pointless because we just keep going in circles here, but evidently you find this to be a meaningful use of your time.

If you’d like we can revisit all of them. Every point misunderstood, every technical error, every point ignored.

I understood your points perfectly, I simply disagree with them based on my experience. That's all I can tell you.

No, you were not clear in what you meant, you were actually incorrect in your statements re: purity regarding functional programming.

If it's not clear to you that I was talking about shared mutable state after I repeatedly said then I really don't know what else to say.

If the nature of calls and design in a React application are just implementation details then why are you talking about them so much?

What I said repeatedly is that you can limit scope of your components within the application, which makes it possible to reason about them in isolation. Then you can focus on the API level of each component when considering the flow of logic within the application. This is really a fundamental aspect of how you structure large applications in a maintainable way.

The whole discussion is about the fact that if you structure your app properly, you can use LLM code in a way where the scope is limited which makes it easy to reason about them.

You’re saying semantically incorrect things.

Seems to me that we're just talking past each other here and you're not even putting a minimum effort into trying to understand what I'm actually saying.

JS has no concept of data ownership or when variables go in and out of scope (except for the GC). I have no idea what you’re talking about. These are not correct or meaningful statements, though I’m sure they mean something to you.

Js doesn't have to have a concept of data ownership. You as a developer absolutely should have one though. I've already pointed out how using an immutable data structure library is a great way to limit scope. The fact that you're struggling to understand such basic things is frankly concerning.

They prevent your components from being pure… You are objectively wrong in how you described this strategy.

See, this is what I mean we're going in circles. What did I say the main problem with side effects was, and what types of side effects did I say were problematic?

Yes, what did I say about those things? What was my meaning? I was fairly explicit when I introduced those terms. That you have forgotten or did not try to understand in the first place is not a counterpoint.

You made statements that have absolutely no relation to any code I've ever generated using LLMs.

If you will recall, I brought up dependency injection as something that LLMs will not produce by default as it is a design question (aside from existing patterns from boilerplate).

And I've repeatedly said that I don't need LLMs to do any design for me. This is precisely the problem with this whole discussion. You make a straw man and then demand that we argue about it.

If you will recall, I brought up Memoization with regards to you saying the LLMs produce idiomatic code.

Again, I do not need LLM to choose when to memoize anything. I'm perfectly capable of making that decision myself. This is not a problem I need it to solve for me.

You not running into them, to me, just suggests that you don’t use these kinda of things at all because your projects are very simple and not much design goes into them.

I'm not running into them because I'm making these decisions myself. In fact, I even explained how I sketch out the scaffolding for the LLM to fill in. I make all the design and architecture decisions in the code base.

But “I haven’t run into these problems” isn’t meaningful without acknowledging what those problems are

I haven't run into these problems because of the way I use the tool, not because my projects are so simple that these design decisions don't need to be made. I've explained this repeatedly to you.

As I explained, they are all problematic, just some are often outaide our control.

If you have problems like different components showing different state, then that's very much a sign of poor up front design.

And you’d be wrong about that.

If you have a component that modifies shared state outside it's scope that's coupling by the very definition. You evidently have a personal definition of what the word modular means.

The programmatic nature of these components as having side effects is the same as for components fetching state from the web. The difference is in what you have control over.

What you care about as a developer first and foremost is the state of the data in your app. If you manage state in a sane way, then most of your problems go away.

You seem to be inventing reasons to be dismissive ad hoc

Ah yes, you can't tell me whether you've actually used the tools you're heatedly arguing about for "infosec reasons". It's obvious that you have not used these tools with a serious intent of learning and understanding them.

Either you’re doing a full review of the code or you aren’t.

If you rely solely on visual review of code to determine that your production system works then you're not working on a serious system. Meanwhile, as I've explained, I use LLMs to fill in function signatures, and I read them one function at a time as I make and test them.

If your approach to using LLMs is to let them generate a bunch of code and then try to read and understand it all at once then I can see why you have a bad time.

Tests are maybe the worst application of LLMs. Tests are where you, the designer, get to specify how your application is supposed to behave.

I'm not sure how these things are contradictory in your mind. I know what I want in my tests, doesn't mean I can't have the LLM do the manual effort of writing things and then tweak the tests as I need to. I find any code I don't have to write to be tedious. Some of us get into programming because we like to automate things.

Not a single one of these 4 paragraphs points out an error in my thinking re: LLMs.

As I said earlier, this is a tool that works for me, if you can't figure out how to use if effectively that's your problem. Do what works for you, I'm not here to tell you how to live.