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 :)

The folks submitting papers to SIGPLAN and PLDI seem to be the opinion use of AI technology in compilers will only increase merging both approaches, of natural language as frontend, and backends.

I think many that don't follow compilers haven't yet grasp how much there is already there, from machine learning based optimisation passes, JIT compiler heuristics, and so on, which never have been deterministic to start with.

I can see how LLMs may make compiler development seem futile when it comes to optimizing the local graph structure (ie kernel-sized chunks of the computation).

But optimizing the global structure -- things like defining the boundaries between kernels, the lifetimes of allocations (or when/how to reuse buffers), and scheduling/parallelizing operations -- seems inextricably tied to the type of traditional program analysis used by compilers.

Even tiling/layout decisions, which you mentioned can be optimized by hand or by an LLM in the context of a single kernel, must be optimized in the broader context of the computation to minimize copies/relayouts between kernels.

I think part of the problem is that massive models make the compiler problem much less interesting, since global program optimization reduces to local kernel-level optimization.

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.

Feels like a sort of pollution.

Why? That is its intent - unlike an IDE, it is intended to work autonomously and only get back to you after it has prepared the full changeset - which at that point you'd review via a PR. Where's the pollution in that?

The hundreds of thousands of commits?

Commits are pollution? Are you concerned that we'll run out of SHA-1 digests?

Lmarena isn't that useful anymore lol

I actually agree with that, but it's generally better than other scores. Also, the quote is like a year old at this point.

In practice you have to evaluate the models yourself for any non-trivial task.

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?

Plandex can tentatively apply the changes in order to execute commands (tests, builds, or whatever), then commit if they succeed or roll back if they fail.