I attended this year’s LLVM Dev Meeting, and the talks kept returning to the same problem: accelerator code is multiplying faster than the shared tooling around it. Agentic development was, as Tuesday’s keynote put it, the elephant in the room. Teams can rapidly generate code to optimize for specific devices, and that speed can make architecture feel disposable. While the current pace pulls teams toward one-off solutions, durable software infrastructure still depends on shared standards, tools, and abstractions. Communities like LLVM will need to work through this tension in the coming years to continue building infrastructure that lasts. The recent proliferation of Domain-Specific Languages (DSLs) is a symptom of this tension, and one that presents a significant opportunity for MAX and Mojo.
Maintaining open source software projects in the agentic era
Kristof Beyls’s keynote asked what agentic engineering means for the future of compilers. Drawing on the System 1 and System 2 distinction from Daniel Kahneman’s Thinking, Fast and Slow, Kristof compared agents to System 1 thinking: fast, intuitive, and prolific. Compilers, in his comparison, are System 2: slow, deliberate, and rule-bound. From that view, agents don’t make compilers less relevant. They make the deliberate, verifiable layer more important, because fast code generation is only useful if something dependable stands behind it.
Kristof’s exploration of the question also revealed a lot about the future of open source software projects. Kristof argued that durable open source projects depend on three things: communicating intent, maintaining cognition, and supporting contributors. If contributions are to maintain the architectural vision and standard of quality that the core maintainers expect, projects need to document and share that intent more deliberately.
Traditionally, contributors internalized a project’s architecture and standards organically by submitting and revising issues, proposals, and pull requests. Kristof emphasized the ongoing importance of “contributor poker”: betting that a new contributor will be a valuable addition to the project even if their first PR requires maintainer effort to land. If agents are taking the productive friction out of this process, it must be reinforced with communication (and better validation of submissions). The audience was more skeptical that contributor cognition is compatible with agentic contributions, citing “drive-by” PRs and a lack of communication from new contributors (Zig has banned AI contributions for this very reason). One key step to investing in contributors in the agentic era is keeping a project comprehensible to humans even as it scales, to discourage eager contributors from surrendering their thinking to the agent.
Reducing duplicative work
Wednesday’s keynote (from Google’s Nick Desaulniers, Anshul Nigham, and Jordan Rupprecht) focused on the opportunities and challenges of maintaining a tip-of-tree fork of LLVM. One finding stood out: delaying an update causes more delays as breaking changes compound. The maintainers found that teams were applying LLVM and MLIR updates independently across the same monorepo, duplicating maintenance work. The speakers’ solution was better shared tooling to allow for more efficient and coordinated efforts. These conclusions echoed the key points of the previous day’s keynote. One-off band-aid solutions are easier than ever, but drifting from shared architecture and tooling across teams duplicates effort and leaves code that is harder to understand and maintain.
Velocity through DSLs
New accelerator generations keep arriving while earlier ones stay in service, so the working assumption is that new hardware must run alongside existing hardware instead of replacing it. NVIDIA’s Rajat Bajpai presented on updating interfaces so developers can use new hardware features while preserving backwards compatibility. In hallway conversations, engineers described the same tension from the other side: how to write readable, accelerator-specific code while supporting multiple architectures. The most common answer seems to be creating more and more Domain-Specific Languages (DSLs).
Maksim Levental, Guray Ozen, and Amir Mohammad Tavakkoli’s talk on NVIDIA’s BaseDSL project demonstrated that teams are looking to create new DSLs more efficiently. BaseDSL is a platform for building custom Python DSLs on top of MLIR through a series of plugins, which reduces duplicated effort as teams spin up their own. Even with a shared framework, teams still end up with incompatible DSLs and no shared tooling, and every one of them has to be maintained. BaseDSL is internal to NVIDIA for now, but audience questions about open-sourcing suggest the wider community wants an easier way to create DSLs.
Yet the spread of DSLs conflicts with the principles established by the keynotes. Kristof argued that durable projects need shared intent and human-readable abstractions. Google’s keynote showed the costs of duplicative maintenance. A growing set of DSLs pulls teams in the other direction. Each DSL provides essential optimization, but together they multiply what has to be understood, documented, and maintained. The alternative path forward is a language like Mojo that enables shared abstractions and tooling across accelerators without compromising on performance.
The (not actually) unique opportunity Mojo presents
This year, Modular led a day-long pre-conference workshop on Mojo and MAX. At the end of the workshop, I was thinking that Mojo’s opportunity to create a shared ecosystem across diverse teams and hardware was unique. Chris Lattner pointed out to me that Mojo is in the same situation MLIR was in eight years ago.
At that point Chris was at Google, supporting AI compiler development for five different chips, each with its own stack. Each team was building its own SSA-based optimizers, with no way to share architecture or tooling. MLIR solved this by unifying the implementation details of these compilers in a single standard. Teams could work at a higher level of abstraction and interoperate much more efficiently.
Mojo provides a unifying layer the same way MLIR does, one level up the stack. It is a full language that lowers through MLIR, so it builds on the infrastructure LLVM contributors already know. The problems DSLs are solving call for a high degree of developer control and performance across diverse accelerators, and Mojo is designed around those requirements, with readable syntax and powerful metaprogramming. [For more context on how Mojo compares to DSLs like Triton, see Fabio’s series on Structured Mojo Kernels.]
MAX layers on Mojo to complete the unification. MAX provides accelerator support with Mojo as the programming interface. Hardware support is built once in MAX and optimized through a single language, instead of being rebuilt with each team’s DSL and stack. A unified MAX and Mojo ecosystem also enables the collaboration that keeps large projects aligned to an architectural vision. The Modular hardware alliance is advancing this effort by coordinating patterns for hardware bring-up. The alliance applies the LLVM model to AI compute: a software layer built in common across hardware vendors, with conformance testing to keep the ecosystem compatible.
Building a community
After Kristof’s keynote, an audience member (and LLVM maintainer) lined up for the Q&A and described feeling frustrated and discouraged by fielding a massive volume of drive-by AI-generated PRs, with no human developer willing to take feedback and see them through. Agreement and empathy were visible across the room. The problem isn’t limited to external contributions to open source. Maintaining critical software in the agentic era will take shared tooling, standards, and abstractions. It will also take a community willing to invest human time in collaborating, developing a shared vision, and mentoring new contributors. I see these practices emerging in the Mojo community, supported by resources like the Mojo contributor guide and the Modular AI Tool Use Policy (inspired by the LLVM AI Tool Use Policy). I left this year’s LLVM Dev Meeting convinced that this kind of community is still possible.
