Conceptual compression in the age of coding agents

I remember coming across DHH's conceptual compression idea, which Rails builds on, and thinking: this is amazing. The whole idea behind it is that complexity, like the one that comes with building a web application, is conceptually compressed by a convenient abstraction, so you don't need to interface with a piece of complexity unless you really need to.

Lately, complexity is something I've been thinking about in the context of coding agents, and in particular the complexities of Bazel. Bazel is a genuinely powerful build system, and teams that master it get a lot out of it. It has also long been discussed for how much it costs to adopt and maintain. At many organizations the story goes like this: one person becomes enthusiastic about it, gets the buy in from a manager or leadership, and then becomes the adopter, the maintainer, and the expert all at once. The person everyone goes to with Bazel questions. But people come and go from organizations, so sooner or later that person leaves. This is the classic bus factor problem, and when it shows up, some organizations revert the fork back to the native ecosystem because the cost of carrying it alone becomes unbearable.

The nature of Bazel hasn't changed, but I believe coding agents have introduced a more dynamic version of DHH's conceptual compression. Now the agents are the ones compressing the complexity for you, and they do it dynamically. If there's something to understand about the complexities of a tool like Bazel, the agent can understand it for you, so you can do what you need, or get an answer to what you want, without navigating all the nitty gritty details yourself. I believe this makes Bazel more approachable for more organizations. At the same time, the costs are not gone. They are just more approachable through delegation.

At Tuist we are preparing for that future, if it happens, a future where more companies adopt Bazel because complexities are dynamically compressed and organizations are less hesitant to reach for tools like it. But we are also exploring what other futures might be possible. A few leaders are already talking about a future where AI writes binary code directly. If you think about it, programming languages are themselves abstractions for humans, so the idea is not that crazy, though I believe that one is still too far away.

One of the futures we picture is closer: build systems catching up and bringing Bazel-like capabilities without asking you to leave the ecosystem you already work in. I don't think this future is absurd. It's the reason we did a soft fork with generated Xcode projects, so teams didn't have to move away from that primitive. In the same spirit, I've been tinkering with Build. Think of it as Bazel capabilities, like remote caching and execution, brought to your project without asking you to fork the way you declare your projects, or how your IDEs (if you still use them) integrate with them. The cost of adopting and maintaining a Bazel setup has come down, but so has the cost of building and maintaining an interpretation layer that runs at runtime, unlike Bazel, which codifies all of this in opinionated rules.

So far the results are quite promising. I was able to go from Xcode projects and workspaces to a remotely cacheable execution by pointing once directly at an Xcode workspace. Isn't that beautiful? I really like the moment our industry is going through, because it's a perfect time to question the paradigms we have adopted. Bazel, GraphQL, and many others were born inside companies solving problems at a scale most of us will never face. That does not make them bad. It makes them a specific answer to a specific context, and it is worth remembering that you are not Google, at least not yet. My attempt with Once is to bring something more accessible, where agents still do the work and complexities are still compressed, just differently.