It’s super annoying and incredibly verbose; and half the text is nonsense. Send me your prompt, I can run it through AI myself if I want!

I really need to get around to seeing if socket.dev produces less noise.

The debate over “queries” vs “operations” vs “documents” is separate; but you’re persisting a document (containing at least one operation which may or may not be a query, plus any of their required fragments); thus “queries” is a misnomer & “operation” limits to docs with exact one op unnecessarily

Persisted documents: send identifier rather than entire document (network optimisation)

Automatic persisted queries: ad-hoc persisted documents via optimistic runtime negotiation

Trusted documents: persisted documents used as an allowlist, where persistence signifies trust (security & speed)

Matt Mahoney has been discussing "generic fragments" where the generics are part of the operation document rather than the schema itself, I don't recall if he gave a talk about it this year but it was certainly something we discussed during the unconference. This might address your needs?

Connection wanting to be a generic is well understood; but I don't quite follow your errorable response - is there a particular reason that's not a union or interface? e.g. `union CreatePuzzleResult = CreatePuzzlePayload | ErrorResult`

Would love to hear more! Could you maybe scratch out a gist or similar with what you envision the final schema and the client queries looking like? Generics risk significant complexity, so we need solid use cases to both help justify it and also guide its design.

That very closely aligns with my experience 👍

complex task I spend more time reviewing their code and checking it's right than I would have spent just writing it myself. That said, they're often great at then writing the test suite for the functionality :D

challenging their solutions typically get further and further from the ideal. If all you need is batch work that a junior could do then yeah they're a massive time saver, but if you're doing something innovative/complex, their results are frequently wrong in the most subtle of ways. I find for many

Right! What I mean by them being "terrible at code" is that they don't _understand_ what they're doing, they struggle with a-typical requirements. Like with a junior dev: they can string a bunch of docs/StackOverflow/etc together to produce something that seems to work, but the moment it gets

machine. Rather than having it mod my code directly, I prefer to have it generate a codemod that I can review, and then I run the codemod against my code.

Great for prototyping though, because prototyping is mostly autocomplete from READMEs/docs, and that’s where LLM’s shine. (v0 is great for UI!)

still useful in helping to shape the solution. Given the kind of code I’ve seen it produce, I’m loathe to hook it up to anything where `node --watch` or similar might actually execute the code and cause devastation, in a similar way that I wouldn’t allow a junior programmer to write code on my

Yeah, I use them heavily because they are useful for the drudgery. But you can never trust it, and once you get into complex areas (e.g. building fan-out with async iterables) it makes a hell of a lot of mistakes that are subtle to spot/track down. I throw away more code samples than I use, but it’s

ChatGPT gives me the best results in general, its tools are more reliable and claude and llama seem to go off the rails pretty quickly and immediately backpedal the moment you challenge them. I’ve not managed to run the 70b params llama, I don’t have enough VRAM or patience 🤣

In my experience it sucks at JS, but yeah I bet it nails the basics. Handling multi-consumer async iterables though and it's a) introducing race conditions, and b) telling me that my code has race conditions when it definitely doesn't 🙄

The worst thing is how confident it sounds.