The issue I always had with Typescript, was that LLM's like to find the easiest way to get a job done on a micro level (they seem to like to find the hardest design patterns to implement on the macro level tho, but language agnostic). What this means for Typescript, is unless you place guardrails everywhere, they'll cast their way out of a compiler problem with as any, or as unknown and then casting later. You either end up with readability issues, or runtime issues leaking out.

Might be a skill issue, but I got frustrated with it on new projects constantly.

I haven't seen that too much, but I do have guardrails. I use Deno and run 'deno lint' as part of the build. It doesn't allow 'any'.

Also, I tend to ask planning questions, like "how would you implement this" and "what would the API changes be?" I'm picky about API's. Lately I've been using Deno workspaces (multi-package repos) and tell it when to make a new package or a new entrypoint. Maybe that helps?

If I just ask for features and don't look at the code, it will definitely make a mess, though. (A working mess, but it takes a while to refactor my way out.)

They're improving but you definitely need both a strong AGENTS.md and also usually many LLM passes (one for implementing a feature, another one for code quality, large passes every now and then for major refactors, etc).

That's not really a typescript thing though, just an LLM thing.