GPT-5 and GPT-5-Codex are already not clever enough for anything interesting.
I'm half way through writing a typescript to native code translator (via .Net) compiling a large enough subset of current code with a lot of help from GPT5 and Codex CLI. It has completely blown me away.
I'd like to give you a concrete example which stood out (from by now, dozens). I wanted d.ts files from the .Net Standard Libs. One immediately obvious problem is that .Net would allow classes/interfaces to be redefined if the generic type arity is different. For example, there can be SomeClass<int> and SomeClass<int, int> which are completely separate. TypeScript of course, wouldn't allow this - you can have one with all types defined, but it'd obviously be a mess.
I was stuck with (quite ugly): const users = new List_1<User>(...); instead of const users = new List<User>(...);
So GPT comes up with this:
declare const __unspecified: unique symbol;
type __ = typeof __unspecified;
// Your arity-anchored delegates exist elsewhere:
// import("internal/System").Action_0
// import("internal/System").Action_1<T1>
// import("internal/System").Action_2<T1, T2>
// import("internal/System").Action_3<T1, T2, T3>
// ... up to 17
export type Action<
T1 = __, T2 = __, T3 = __, // ... continue through T17 = __
> =
[T1] extends [__] ? import("internal/System").Action_0 :
[T2] extends [__] ? import("internal/System").Action_1<T1> :
[T3] extends [__] ? import("internal/System").Action_2<T1, T2> :
/* next lines follow the same pattern … */
import("internal/System").Action_3<T1, T2, T3>;
const a: Action<number> = (n) => {}; // OK (void)
const f: Func<number, string> = (s) => 20; // OK (string -> number)
Are you saying ternary chains using sentinels for arity inference is pretty common? I would disagree.
> since it’s the main control flow
Perhaps you're saying ternery chains are common in TS code? That's a very different thing though - the code above is not for runtime behavior.
Why would Range need a sentinel?
My point is that using a sentinel to bridge TypeScript's lack of generic arity-based specialization is a non-trivial problem. After you mentioned it, I looked for examples on Google and couldn't find anything that matches precisely.
I'm not claiming humans can't solve this, or that gpt5 invented something fundamentally new. My original point was about productivity at scale. Having a model apply the right solution across dozens of similar problems, rather than me manually figuring out each one.
It is just poor at designing a generic solution despite repeated requests to follow the design of existing alternatives (present in the same repro). It tended to plug holes in a broken architecture it came up with on its own instead of redesigning or trying to simplify its code to be able to keep it in its own head. TBH I suspect this might be limited purely by context length.
It produced fine(-ish) initial bits so a few tests would pass, but it dug itself a hole of introducing provenance and could not keep track of it properly. You can see it: https://github.com/lostmsu/ILGPU/tree/Vulkan-GPT-5-Stuck
TBH2: this was a huge request. But also there are already other backends it could just mirror.