[AIEWF 预告] 驾驭 Agent 混乱——Solomon Hykes

Everyone, welcome to a latent space learning pod. This is Alessio, partner and CTO at Dazzle, and I'm joined by Mikolaj Swietek, founder of Mole AI. Hello, hello. And today I'm so happy to have Solomon Hykes join us. Solomon, you're most famously the creator of Docker.

Hi, thanks for having me.

You started Dagger 6 years ago, and I think originally it was pitched as some sort of infrastructure-provisioning thing. I'm sorry, I'm probably totally mangling this in front of you. How do you introduce Dagger today?

I think 6 years—yeah, 6 years, I guess, sounds right. Dagger is a workflow engine. It's an automation tool for software teams that want to deliver software faster and more efficiently. It takes all these workflows that are usually semi-automated with artisanal scripts—your builds, your tests, your end-to-end pipelines—and turns them into robust, modular workflows that you can drive with code. It all runs in containers, so it's highly portable and highly isolated.

You can run them locally or in CI, which saves a lot of time. We're an open-source platform, and we've got a very active and engaged open-source community, mostly made up of platform engineers: those systems engineers who design the factory, run it, and enable the developers on the team to be more productive. That's our core community.

I was going to say, just to make that clear, these are both pre-development—spinning up an environment for people—and then also what happens after you're done writing the code and getting it ready for production. Are those basically the 2 entry points?

We started mostly post-development, so anything that happens after you've saved and you're ready to see what happens next: build, test, and take it live. There's that delivery loop, right? We've been focusing on making that delivery loop more efficient because it's really terrible in most places, and there are a lot of inefficiencies that could be cleaned up.

In a lot of ways, it's a cobbler-without-shoes situation. Those platform engineers spend all their energy and significant experience helping developers get the best possible tooling and the best possible experience, but for their own tooling, it's sort of, "Okay, we've got to cobble this together with Bash scripts and YAML." So we've been focusing on post-development.

Although recently, we're getting pulled into the development loop, in part because of this crazy change that's sweeping the whole market: agents.

I think let's run right into that. Obviously, there's a lot more context on Dagger and Docker and what you've done prior, but this is an AI podcast, so why not just go right into it?

A few months ago, you messaged me and said, "I think this is the biggest idea I've had since Docker itself." I thought, "What? Docker is very big." What is your context going into AI builders? In some ways, I've always said that to us dev-tools people, it's just more of the same. Everything that you wanted, you just need 100x more. How did you approach this?

We didn't think of ourselves as an AI company. We got pulled into it by our community and our users, because although Dagger is primarily used to build CI/CD pipelines, historically, we've never thought of ourselves as a CI/CD company. We like to build platforms from first principles and then encourage our community to go and apply them.

What we have is an engine for automating workflows, making them reliable and portable, and giving them very clean environments to run in. The environment is key. Of course, we use containers because that's what we know, and container technology is still underutilized and misunderstood today. It can do so much more.

Our community pulled us into this AI space because of agents. These platform engineers started messing with agent loops. They wanted to insert LLMs into their workflows, and now it's becoming more popular to run agents in the context of your CI to automate more parts of your delivery.

Then they started showing us that everybody wants to use these coding agents now. If you're a developer, increasingly, your job is not going to be to actually develop but to manage and enable these coding agents. We're at the very beginning of this. You've got one agent in your IDE helping you, but now you want more than one, right? You want a team of agents doing the work for you.

That transition from a team of 1 to a team of multiple coders is basically what our community—these platform engineers—deals with. What we're witnessing is developers becoming platform engineers. They have to learn how to enable others to be productive. These others, of course, are AIs.

To do that, they have to give them environments to work in. You can see the problem when you see someone live-streaming their vibe coding. Everyone's vibe coding, but you can only make one set of changes at a time. Everyone's messing with this development environment that really isn't cleanly isolated.

What we're doing is taking this technology that we invented for CI/CD and bringing it into the coding-agents environment, giving your agent a perfectly isolated, reusable, and portable environment. That way, you're not completely locked into one app connected to one model running on one cloud infrastructure provider.

You want the environment where the agent does its work to be decoupled, to be its own thing that you can manage and look at, and then move to another platform if you want. That's sort of what happened with Docker in the previous wave, when everyone was adopting cloud technology. Everyone was building these big platforms, and they had everything, but they were highly fragmented. They tried to cobble everything together like a monolith, so you didn't have this portable environment that you could carry around with you. You were trapped in one big platform.

The same thing is happening now. We want to use our experience from the past to enable this new generation of developers to really unlock the potential of these coding agents. That's what I'm excited about.

I think the scope of what people do for coding agents today is maybe like a single VM, let's call it. Especially the coding agents from the big labs: they don't even have internet access. They have preinstalled libraries, and it's very limited. It could be so much better if there were standards for it.

Obviously, the standard needs to be open source, but there's a question of the design constraints that you're coding for. For example, Gitpod is another developer-environment market participant I've seen. They're saying, "We really need to isolate this kind of almost-mini VPC. You need to get the networking sorted out, and you need storage—everything, right? Just all the fundamental units of compute."

So, I guess, what is the container here? What is that concept here—the unit of isolation?

Actual containers as the base layer. That's my first insight here: you don't have to reinvent the core technology that already exists, but you have to rethink the tooling.

It's frustrating for me because we busted our ass on Docker. We built this whole ecosystem, and we invented the Dockerfile, Docker Compose, the format, and the CLI. Then we messed up on the follow-through. At some point, Docker basically stopped innovating, and I left. The ecosystem continued around containers, but it didn't actually pick up where we left off.

Everything around applying container technology to development stopped. There are still a lot of interesting experiments, but it never had the unity of purpose that this initial movement had. So you have fragmentation. No standard really emerged beyond Dockerfile and Docker Compose. That's it.

All the effort went into infrastructure: Kubernetes, scalable storage, scalable networking. That kept moving a lot. If you go to KubeCon or any of those events, you see all the infrastructure people applying containers to solving that problem. But for development and dev environments, it really hasn't moved that much.

Use containers—that would be my first recommendation. But then, yes, you have to design a solution from first principles. It's a difficult design problem, and I'm very excited because there's an opportunity to go through this design process again from first principles.

I'm aware of Gitpod, of course. There are Dev Containers as a standard in IDEs, and there are a million other products out there, but none of them have convinced the majority of humans to develop in them and with their tools. It's very fragmented. In fact, most people still don't develop in a container. They just develop on their laptop. That's a failure of tooling.

I think it's anyone's game how to apply container technology to the perfect developer experience. But the criteria are that it has to be well isolated. You should be able to have a bunch of agents working in parallel, and they shouldn't mess up each other's work. It has to be portable. It should not be locked to a model or a cloud provider, and it should also not be locked to an IDE.

That’s crazy. If you think a whole team is going to standardize on the same IDE forever, you’re deluded. It should be fully observable. You should be able to see everything that happens in that environment end to end, everything from what the model’s doing and thinking and saying all the way to what tools are actually running and what the state of the environment is. You should be able to see everything in one place.

You need strong multiplayer elements. You need agents and humans to both be able to interact with that environment, so that you can tell an agent, “Do this.” And when the agent says, “I did it,” you can go and verify: “Okay, did you do it? Give me the keyboard for a second.” You need all those things.

Right now, I’m not seeing us heading in that direction. I’m seeing us heading in the direction of highly integrated, very vertical, end-to-end monoliths. I don’t want to name names, but it’s definitely a market trend. If you’re selling an IDE right now and people are asking for more customization for the coding agent’s environment, you’re going to add some proprietary way to customize the environment. You’re going to add your own observability solution. And when people ask for a way to have the agent work in the background, you’re going to add your own hosting solution to run the agent in the background. That’s a monolith. That’s what fragmentation looks like.

And that’s exactly what we were up against in the early days of cloud that led to the creation of Docker, right? So we’re going to need some sort of a standard—not on everything, just on the environment, right? Just that little piece that connects all the other pieces. It’s not the most powerful piece, but it’s the linchpin that connects everything else. The environment in which the agent does work—that should be independent.

What do you think are the biggest limitations to this? I use Docker to develop, and I force the coding agent in the IDE to run commands in the Docker environment. I would say, if I had to give feedback on it, one, the agent cannot make changes while inside the container and propagate them back to the Dockerfile and Docker Compose. So it kind of spends all the cycles, and then all the work is lost. And there’s no AI-native interface; I’m basically just doing Docker Compose exec and running the command in the container instead of having a more native way to do it. How do you think about that changing with the new Dagger approach?

I mean, you just got to rethink it. Dockerfile was something we designed as a stopgap prototype, thinking, “Oh, we’ll clean this up later,” in 2013. It’s been more than 10 years. Compose was a clone of a clone that we acquired into the team and stitched on top, and as soon as we launched it, you have to understand, there was so much excitement and demand. People didn’t want it to move. You would build platforms on top and then you’d be like, “Don’t change the syntax.”

And so that stuff has been frozen in time. I commend Docker for maintaining it and keeping it alive and just doing the hard work of maintaining it, but it’s not agent-native. It never will be. You just got to go through a good engineering and design process of understanding how people develop with agents, understanding what’s the best UX that they need, and trying to design that on top of technology and components that are as standard as possible.

You don’t want to reinvent the wheel where it’s not necessary, but we’ve got a bunch of standards to work with. We’ve got the container tech—I mean, it’s there; it’s universal. We’ve got Git. We’ve got the LLM, the OpenAI API spec, right, and its derivatives. And now we’ve got MCP. So that’s a pretty good set of standards. We can work with that. But yeah, it’s got to be a new UX, in my opinion.

And, I mean, not to plug Dagger, but obviously Dagger is our vehicle for going through this design process. So if you want to see my particular opinions and how things should be designed and how to balance, for example, simplicity versus modularity, then in my case, look at Dagger.

But yeah, it’s normal that you can’t just tape existing tools as is onto new workflows and hope it’ll be perfect. That’s totally normal.

Something I bring up in my work history a lot—and I think you know I’ve also worked in workflow orchestration and Temporal—is this migration of, let’s say, a custom language like a Dockerfile or an AWS Step Functions-type thing into a more programming-language-based approach, like TypeScript or Go. That is the exact same journey I took.

Yeah, I mean, it’s really hard to find the right balance. I think of it as LEGO, because it’s a hard problem to solve these workflows and these environments: no 2 workflows are the same, and no 2 development environments are the same. It’s like factory design. Every great product has its own factory that’s unique. No one goes and buys a factory at the factory store. You design it and build it alongside your products. And that’s what these things are; it’s like a factory.

And it’s really hard to provide tooling for that space, because if you make it too complicated and too customizable for no reason, then you’re wasting people’s time. They just say, “I buy this; I’m just going to do everything myself from scratch.” But if you try to streamline and simplify too much, then you’re restricting choice and it becomes useless. Like, “Well, this doesn’t fit in my factory because my factory uses this system and I can’t reconfigure it.” So it’s a really hard area of design and engineering.

And to me, the GOAT in this space is LEGO—the actual LEGO. It’s used as an analogy so much that it loses its meaning, but if you really think about what LEGO really is, it was in reality very difficult to design and engineer the LEGO brick because it had to be just right. And it’s designed as 1 component, but it’s designed with a much larger system in mind, right? So there are these 2 layers of design. That’s what’s so hard. And that’s why LEGO is genius and has stood the test of time.

That’s what everyone in this space should be trying to do: build a better LEGO system that is worth adopting. It’s expensive to adopt a new standard in your stack. It’s one more of everything to worry about, right? So it’s got to justify the cost by actually saving you something—effort, money, whatever. That’s what LEGO does. I like to play with LEGO because I can assemble things quickly, et cetera. So yeah, that’s the challenge.

In the case of Temporal, I think these systems are very well positioned for running agentic systems, right? An agent always has some sort of loop that’s triggered by events. It’s asynchronous. You have to run that somewhere.

Yeah, I would say Temporal’s focused more on runtime applications, and other systems are more focused on CI/CD. Honestly, you could use one for the other.

Yeah, but they’re converging, because your CI/CD will soon be nothing more than runtime infrastructure for your workflows. And all those workflows will become agentic, right? It’s going to be either workflows running LLMs, LLMs running workflows, all the way down. And CI is also events, a job dispatcher, and compute.

So I think these things will converge, with coding agents being the domain of application where everything meets, right? Because when you’re running a coding agent, you’re running an agent, so it’s a runtime problem, but it’s a very specific area of application. It’s not real time. You don’t have to worry about voice and video and things like that. You worry a lot about artifacts that are being produced and whether they’re repeatable. Can I trace how they were created? Is this binary created by an agent, by a model that went rogue? Things like that.

One element that I see a lot in these kinds of applications—we talked about Bolt.new, and there’s this whole universe of, let’s call it, ephemeral apps: vibe-coded apps, single-use apps, just because it’s so easy to create an app now that you think, “I just—it doesn’t matter.”

The speed and the setup and teardown are pretty significant, and then obviously resource usage and cost. These are all things that I’m hearing the founders in these companies trying to solve for, and all finding the current set of tools lacking, because we just don’t have the ability to subdivide things that small or that cheaply. We can’t start things up that fast. But users always want this. That’s why they’re doing the shortcuts. That’s why they’re not using containers, because they’re like, “I don’t know how to do this with containers.”

Yeah, and there’s a lot of duct tape. I mean, if you want to use containers yourself, you have to duct-tape a bunch of tools together. And it’s not just containers; it’s also file system isolation. Everyone’s playing with Git worktrees to try and get multiple instances of the agent working in parallel. That’s the same problem, right? It’s not just containers. It’s something container-based: containers for isolated execution, worktrees for isolated files, and it all kind of—you have to connect it together somehow.

I do think I’m seeing a lot of vendors, of course, thinking about that and trying to find the right solution for their customers.

I think one mistake everyone's making—again, I'm making a historical parallel with the rise of PaaS—is that everyone had this idea: only you can do this. Hopefully I'm not the only one left, but I think it's becoming very apparent, very quickly, that when someone who sells a commercial cloud product—a cloud-centric product in the AI space, where it's hosted—they're hosting your stuff, right? You log in, and they have your data, they have your traces, they run the model or proxy to a model, whatever.

Every solution they come up with will be very infrastructure-centric, right? They're going to think of another hosted feature, another hosted service. So when they think about environments, they think, "How can I run these VMs on my infrastructure as fast and cheaply as possible? My scale is going to be X, I have this many customers, the pricing is X." That's excellent, but developers also want to run stuff themselves locally, and they don't really want that to be an afterthought.

Right now, it is an afterthought. It's the same mistake CI/CD vendors made. CI/CD has no good local story. There are some open-source projects that try to simulate GitHub Actions locally, and it must be a nightmare to maintain those projects because compatibility is so hard.

My point is just that local execution isn't everything, but it's a good test. Whatever solution you're imagining, does it support local execution? Will developers be able to run it locally and enjoy it? If the answer is no, you're solving part of the problem, but you're not fully solving the problem of standardizing dev environments for coding agents.

It's not going to stand the test of time because it cannot be ubiquitous. It'll be a great commercial solution, and you'll make lots of money with it, but it's not going to be ubiquitous.

So I'm going to ask a really hard question, maybe, but what does it take for one of the big clouds or big labs to adopt Dagger?

Yeah. For example, I've had this exact same call, same problems, with the Microsoft team. They're pushing Dev Containers. Obviously, Dev Containers aren't enough, but whatever—they want to build around it. They want to extend it.

I'm like, "Okay, but everyone's working on their thing. When do we get some consolidation in the space?"

Well, who knows? Honestly, everyone should just give it their best shot and design the best possible solution. With open source, to some degree—it depends on the area or domain—but for this problem, scale doesn't really help as much.

If you're going for foundational models, to take the extreme example, sure, let the best design win. But I know who—I know the 10 names of who's going to win, if you know what I'm saying. It's going to be one of those 10. Startups don't really stand a chance.

This is very different because it's not about scale. It's about developer experience and designing the interfaces in a way that actually helps people be more productive. There's a lot of leverage for small teams to just design the best possible solution. Then you have to convince others to adopt it and build on it, so community and ecosystem are extremely important.

If you're large, like Microsoft, you have an advantage there, obviously. There's a Microsoft ecosystem, and it's massive. But you still need to have a solution, right?

We're talking to Microsoft. We're talking to a whole bunch of people, but for this particular problem that we're targeting—standardizing the dev environments for agents—you don't really need permission as a startup. You just go ahead and do it and build momentum, because there's less gatekeeping, I would say.

Yeah, awesome. I think the other thing that comes to mind sometimes is that there are different layers in infrastructure. I think you're very focused on—I don't know how to put it—virtual hardware. Is that a term that resonates?

Virtualization?

No, when I look at what I can do with Dagger, it doesn't, for example, have auth or billing. The higher level is still infrastructure.

Yeah, yeah, yeah. That's what you're describing as a consequence of the Lego approach. We're focusing on the platform problem: how do you create a modular system that can run anywhere, connect to anything, and allow you to compose the ideal environment and the ideal workflow? It could be ubiquitous because it can be integrated into pretty much any existing system.

In order to do that, you can't go ahead and design a complete end-to-end solution, right? That's the price to pay. Dagger will always be a component of a bigger platform. It will never be the complete end-to-end platform, because in order to do that, you have to force your customer to adopt your authentication, your UI, your storage, your networking, et cetera.

We're doing the opposite. We're telling these platform teams, "Hey, we will adapt to the stack that you have."

For example, we started this conversation with CI/CD because that's our traditional use case. Dagger makes your CI/CD better, but it does not actually replace your legacy CI platform. It runs on top of it, and it allows you to simplify it and turn it into basically dumb runner infrastructure. But it's still important infrastructure.

We don't seek to replace what you have. We try to integrate with it and make the overall system better. As a result, it's just a different shape of a product, right? We definitely don't solve auth. You've got to pick up others to help solve auth, but whatever you do, we'll integrate with it.

Yeah. Cool. I think that's plenty for an intro to where Dagger's at and the pull that you guys are seeing. I'm looking forward to your talk, to be honest. I haven't seen a good Solomon Hykes AI talk.

Well, I don't know if anyone has.

Yeah, hopefully we'll see one next week.

Yeah, I know. Feel free to lean on me to prep and all that, but—

Thank you. I'm excited. When I saw the workshop submission come in, you guys had a really good "Let's build coding agents" session, with all the infrastructure pieces. That really tied it together for me. I thought, "Okay, this is where Dagger's going. This is how, ultimately, I need the LLMs to start generating their own infrastructure—generative infrastructure, almost."

I feel like that's prone to a lot of spend.

Yeah, but it's going to happen. The environment is a good way to ask, "Okay, how much control and how much freedom do I really want to give this agent?" We're past the stage where these things are just running wild on the internet, so why not? But giving them my AWS account and letting them go nuts is tricky.

Depending on how things go, there's a 50% chance that for my keynote, there will be some brand-new, original stuff to show and talk about that isn't out yet—in addition to what we're showing in the workshop and everything. It depends on whether it's ready in time, but we may have even more fresh stuff to talk about.

All right. We'll let you get back to it. Thanks so much for your time.

Thank you.

Yeah, thanks, guys. I'll see you next week.