ezyang

One of the reasons why I have been thinking and writing this topic is because there is indeed a malaise among the team, which is along the lines of "AI agents are blowing up coding everywhere, what place does a compiler have in this brave new world?" If compilers truly are pointless, then I would like to update on this and save people time and grief!

But I also don't think compilers are pointless. In this post, which looks at the maximalist AI situation, the compiler resurrects itself as the verifier: the two types of systems do very similar things! You can also defend compilers on more banal grounds: not everyone has a ton of kernel engineers to hand optimize your kernels; token efficient ways of getting good baselines is useful; there's more to ML than transformer models and compiler leverage is really useful there. There's also a historical point which is that torch.compile... by all objective metrics, has really been quite successful!

I do agree it's hard to tell the future. These days, I ask myself, "Do I think this is likely to happen in six months." I don't think compilers die in six months. Ask me again in six months :)

I just want to point out that Opus 4.5 actually knows this trick and will write the code to decode the IDs if it is working with GitHub's API lol

The happy path way of getting code out of Codex is a PR. This is emphatically not true for Cursor.

Lmarena isn't that useful anymore lol

I quite liked this article, actually, and I'm quite an MCP stan. These all seem like legitimate problems that the burgeoning ecosystem needs to figure out. Some of them will be logically solved inside the MCP spec, but I also think some won't.

I mean, obviously you want to run the local CI in some isolated way. But it's not such a bad idea for many projects.

At PyTorch, we have the reverse problem, it's basically infeasible to run the CI locally, you really do need the cloud setup to cover all of the operating system / hardware configurations, and the parallelization in cloud also saves you loads of time.

No, in fact, codemcp can be thought of as a fancier version of the official filesystem MCP that Anthropic released. It's 100% MCP.

One thing I'll say, is that if I was going to make people pay API costs (like cline/claude code) I probably wouldn't actually make an MCP. The MCP box is pretty limiting, and I'm only willing to pay the cost because that's how I get onto flat pricing structure.

I definitely agree that for current models, the problem is finding where the LLM has comparative advantage. Usually it's something like (1) something boring, (2) something where you don't have any of the low level syntax or domain knowledge, or (3) you are on manager schedule and you need to delegate actual coding.

One problem with keeping the changes separate is the LLM usually wants to test the code with the incremental new changes. So you need a working tree that has all the new changes. But then... why not use the real one?

So I have liked the Claude Pro style rate limiting over credits that refresh monthly but mostly because I only get snatches of 1-2 hours while I am on baby leave so I never actually get rate limited. As for learnings, I put a lot of them in my AI Blindspots blog, cuz I did most of codemcp's dev with LLMs

The thing is that, as many junior engineers can attest, randomly blundering around can still give you something useful! So you definitely can get value out of AI coding with the current generation of models.

I have used Cursor and my own MCP codemcp. Cursor has a lot of nice QoL that you can't get from an MCP package; the TAB is really good for traditional coding. Haven't used copilot so I don't have a comparison there. Definitely use agent mode.