I’ve found that LLMs will frequently do extremely silly things that no person would do to make typescript code pass the typechecker.
I’ve found that LLMs will frequently do extremely silly things that no person would do to make typescript code pass the typechecker.
I've noticed this too, but not necessarily type checkers, but more with linters. And can't really figure out if there's even a way to solve it.
If you set up restrictive linters and don't explicitly prohibit agents from adding inline allows, most LOC will be allow comments.
Based on this learning, I've decided to prohibit any inline allows. And then agents started doing very questionable things to satisfy clippy.
Recent example:
- Claude set up a test support module so that it could reuse things. Since this was not used in all tests, rust complained about dead_code. Instead of making it work, claude decided to remove test support module and just... blow up each test.
If you enable thinking summaries, you'll always see agent saying something like: "I need to be pragmatic", which is the right choice 50% of the time.
You need to very specific and also question the output if it does something insane
This decade’s version of “works on my box”
I've found it's less about specificity and more about removing the # of critical assumptions it needs to make. Being too specific can be a hindrance in it's own regard.
And that's also a decent barometer for what it's good at. The more amount of critical assumptions AI needs to make, the less likely it is to make good ones.
For instance, when building a heat map, I don't have to get specific at all because the amount of consequential assumptions it needs to make is slim. I don't care or can change the colors, or the label placement.
I caught it using Parameters<typeof otherfn>[2] the other day. It wanted to avoid importing a type, so it did this nonsense. (I might have the syntax slightly wrong here, I'm writing from memory.)
But it's not all bad news. TIL about Parameters<T>.
Yeah, I've found LLMs cannot write good Typescript code period. The good news is that they are excellent at some other languages.
I can't agree here. https://pelorus-nav.com/ (one of my side projects) is 95-98% written by Claude Opus 4.6, all in very nice typescript which I carefully review and correct, and use good prompting and context hygiene to ensure it doesn't take shortcuts. It's taken a month or so but so worth it. And my packing list app packzen.org is also pretty decent typescript all through.
> which I carefully review and correct
So you do agree? If you are having to review and correct then it's not really the LLM writing it anymore. I have little doubt that you can write good Typescript, but that's not what I said. I said LLMs cannot write good Typescript and it seems you agree given your purported actions towards it. Which is quite unlike some other languages where LLMs write good code all the time — no hand holding necessary.
I think it can write working TypeScript code, and it can write good TypeScript code if it is guided by a knowledgable programmer. It requires actually reviewing all the code and giving pointed feedback though (which at that point is only slightly more efficient than just writing it yourself).
> It requires actually reviewing all the code and giving pointed feedback though
Exactly. You can write good Typescript, no doubt, but LLMs cannot. This is not like some other languages where LLM generated code is actually consistently good without needing to become the author.