Claude Code already does this, you can access it with /resume, /rewind and /fork. I'd imagine building a version that saves in the repo instead of in the home folder would take very minimal effort.
I'm using it on a large set of existing codebases full of extremely ugly legacy code, weird build systems, tons of business logic and shipping directly to prod at neckbreaking growth over the last two years, and it's delivering the same type of value that Karpathy writes about.
If you watch the demo video you can see how they would get this: the model is not aggressive enough. While it doesn't cut you off, which is nice, it also always waits an uncanny amount of time to chime in.
I hate to be the first one commenting to say this, but here it goes: the flashy LLM writing style, "Apple Event Dialect" in the README and in this comment is very recognizable and also quite irritating. If this is supposed to be boring then just state the facts and the benchmarks to prove them.
Nobody has to do anything, least of all massive corporations with country-sized revenues. It's /always/ a choice to comply or to put up a fight and deal with the consequences.
I can transfer money from Europe to Brazil in seconds with Wise. I press the button and the money is nearly instantly available in the Brazilian account via PIX. The same in the reverse direction is possible but only if you have a more modern bank in Europe, eg. N26 or Revolut.
This is a weakness of the Python typing system and not necessarily of individual typecheckers. Pyright has a policy of only implementing what's standardized, and the Python type system is simply inadequate to annotate most real world Python code out there. It's been years now and something as basic as properly typing kwargs is still not supported.
Ty could solve this if they rebel and decide to ignore the Python typing standards, which I honestly would appreciate, but if they take the sensible approach and follow the standards, it won't change anything.
Have you profiled the build? Is most of it spent in the compiler?
A more practical point is that the main competitor is C++, a language notorious for long compilation times, so not-ultra-fast compile times might not be the highest priority for people working on rustc.