I was having this exact thought after I overheard a conversation on a train, where two developers were discussing the quality of TypeScript being generated by Claude Code, and how they were getting closer and closer to having all of the architectural requirements, test cases, etc. in place to be able to one-shot correct and functional TypeScript.
But if you're going to be relying on the LLM to do all the final-stage implementation work, and you've already got all the guardrails in place to ensure that the final output is performant, secure, correct, etc., then why would you still target TypeScript, which is entirely a kludge to shoehorn type safety into JS for the benefit of human programmers?
But then why target JS, if it's just going to sit on top of a complex runtime like Node? Why not just target the language the runtime interpreter itself is written in, and just output clean C? But then C needs to be compiled down to assembly anyway, so why not skip that step and just output assembly?
LLMs still have a lot of pitfalls and risk factors, and will always need human oversight, but in this case, what's on the horizon is something that can eventually eliminate all the intermediary bloat that only exists to optimize the development process when human programmers are doing all the grunt work. Eventually, we might be able to do away with the tradeoff between development velocity and runtime performance.
It depends on what software you’re building. The npm ecosystem is huge, hosting is easy, etc. Sure C can do it but it will take longer.
> why would you still target TypeScript, which is entirely a kludge to shoehorn type safety into JS for the benefit of human programmers?
To help the hapless humans who have to fix it, silly!
One obvious reason to have an LLM output a high level language even if you are never going to read the code is because it will require fewer output tokens and therefore be cheaper.