The Changelog: Software Development, Open Source - Automation at the speed of Swamp (Friends)

Episode Date: May 13, 2026

This week I'm talking with Adam Jacob, founder of System Initiative and creator of Swamp, about what happens when AI agents change the entire shape of software development. We discuss how he went from an 18-person team down to five and shipped Swamp 900 times in four weeks, why he brought User Acceptance Testing (UAT) testing back from the 90s, why software architecture (and domain-driven design) suddenly matters more than knowing how to write code, the live demo where I pointed Swamp at my Proxmox box and watched it write its own automation (blew my mind!!), and why he'll never accept a pull request to Swamp, ever.

What's up, friends, Adam here. This is the change law today. I'm bringing a good friend of mine, Adam Jacob back on the show, a good friend and a fellow AI maximalist. The world has changed, and Adam knows it, and so do why. And we're talking about that change here in this podcast. His super, very cool, awesome project called Swamp.

And wow, it is mind-blowing. A massive thank you to our friends and our partners at fly.io. Learn more. at fly.io. Okay, let's do this. Well, friends, this episode is brought to you by our friends at coder.com secure environments where developers and agents work in parallel. And I'm joined by Nikki Pike, field CTO for Coder.

Nikki, what is the field CTO? So I get that question a lot and it's, you know, half the people understand it, half the people don't. So a field CTO, I describe it very simply as we're dev rel for the C's. So we provide a bridge between the customer voice, between the C-suite and the managers and the leadership teams of our customers back into our product. And then we go through and we help enable our teams to have the same message to make sure that the message is correct and that we're building on something that people actually want, not just something that we think they want. Okay, so we're taking the laptop away from the developer. Not really, though. We're putting them in a cloud development environment, a secure environment where they can work with their agents in parallel.

These are blessed environments. what's wrong with the laptop? The laptop is the trap here. And not only because the fact that it could be stolen, you could lose it, it breaks, and you're out of work while you're waiting for a new one, but there's also just the consistency that you got there. We all know developers.

Developers are going to be looking for some of the latest and greatest, and if you're not really controlling how they get out there, that's where you get this. It works on my machine. It doesn't work in production. It doesn't work anywhere else because you don't have that consistency. You don't have that ability to really standardize what that environment looks like. And this is a problem not only for new people coming,

in, you know, the onboarding statement is the average, I think, is like four to five weeks for a new employee to really get their local laptops set up and ready to start doing their first time of code. And, you know, the time to first commit is a metric that almost everybody knows. And the reason they can't do that is because there's a lot of tribal knowledge out there. They got to go talk to other developers. What are we using? Where do we get our dependencies? Are we getting them from public?

Are we getting them from private repositories? But there's also the security and the supply chain aspect of this. When you have local machines out there, look at like the shy Hulud, you know, that very, that that went out not long ago. This was a compromise of the MPM public repositories. They went and downloaded things. MPM did what it did. Next thing you know, you're compromised. But when you use something like what we're doing with cloud development environments, then you can mandate and you can put restrictions on there to say, hey, you can only go get your packages from our private repo. Those packages are expected to have been thoroughly vetted. We know that they're clean. Now, does this

stop everything like Shai Halud? No. If that compromised package gets into your private repo, you can still have that, but it really reduces the surface area of the attack. And it also reduces the blast area of the compromise should it happen. Because if your laptop gets compromised and you have to kill the laptop for whatever reason, that's weeks out of work while you're either fixing that or you're getting a new laptop in. The cloud development environments allows you to kill that, start back up fresh, and you're back and running in five minutes. You don't have to wait all that time. Well, friends, the first step is to go to coder.com install coder, self-hosted environments, for your teams to enjoy, to standardize around, and it's open source, so you can try it out today.

Once again, coder.com. Well, friends, we're back. It's been so long, Adam. I missed you. I missed you, too. You know, we were just in this pre-call and saying that feels disingenuous, but just no, it's not disingenuous. We're just talking like friends do before the record button gets pressed, but I really did. It doesn't feel disingenuous at all.

Well, thank you. We're actual friends. I know we are, man. I was actually thinking about this because we kind of cross paths unexpectedly when you were keynoting, I believe, Oskine. And as part of our relationship with OzCon, which is defunct. Because Oskine's defunct.

That's right. One of the things they have us do was happily talk to you. And since then, we've become friends. And I'm so thankful for that, really. I really am thankful for the way that paths cross in this industry. Yeah. It's so wild. Yeah.

And that like, you never know where people will reappear. Yeah. You know? And under what context, those relationships will matter. And yeah, I feel like a thing that I have learned, I've learned both, that, you know, you should, if you like people, then you should, you know, do your best to be friends. Because, you know, whatever, you only get a limited number in life and you should like try to make that number higher is usually a good idea. And then, you know, but the other side is you don't know where those people will reemerge or how your paths will cross in the future. And more than once in my career, there's been like really happy serendipity, you know, around just like someone you know has moved on or they moved to a different thing.

and now you're reacquainting each other in a different way or in a different shape or you can help each other in ways that didn't exist before. And I love that part of the industry. Like, you know, I love that there's that there's just people I've known sometimes for a long time or sometimes not for very long that, like, you know, they just, you know they're going to show up again. And you just don't know. You just don't know exactly how.

I love that about this. How or where, yeah. And in what context, you know, like, I love when folks show up back in my life that either I can help them or they can help them. or they can help me, which is always a good thing. Like, I love helping people. It's one of my favorite things to do in life is just to be a helper to folks. I'm the hype man.

I'm the encourager. I'm the you can do it guy. You know, I'm that guy on Happy Gilmore, right? Yeah, yeah, totally. Cooler than that guy, hopefully. Definitely, definitely cooler. Yeah. In spirit, you know, you can do it.

Yeah. Which is kind of cool. Yeah, for sure. For sure. What a place to be at, though. I mean, I like, I know the last time we talked about, AI in your infrastructure, but did you imagine we'd be here this short of time later? Like, I feel like the game has totally changed.

It totally did change. Right? I mean, like, it was changing then, and it was like if you were in the AI game, then you were almost in crazy land. Yeah. Some would say agent psychosis even. Yeah, yeah, yeah. And then if you were even a version of a maximalist on AI, you were definitely crazy. You're definitely crazy. Right. But how do you feel about that now? Yeah, not anymore. Yeah. Not at all, right? Yeah, I mean, I'm bad at time as a just thing to know about me since we're friends. Like I'll get just like times and dates and, you know, like I double check my daughter's birthday, even though I know her birthday.

You know, just because like I might could mess it up, you know? Right. Like I'm just bad at it. But I feel like, you know, the last eight months, six, eight months maybe in AI in particular for software development really changed the shape of what was possible. And it kind of happened to everyone who was working in that zone sort of all at once. You know, like when I talk to my friends who are like high up at Google or high up at Microsoft or who are running startups or who are, you know, running big teams or who are running small teams, you know, everybody who was really paying attention and doing that work, like there's, there was like a tangible change in the outcomes and a tangible change in our ability to start to articulate. sort of what a working architecture is. You know, when you think about how are we going to use these tools to create software

and to get better and to like move the industry forward in a meaningful way that's not just, you know, the robots are coming to get us and they're going to take all our jerbs and it's all going to end. You know, like, like that happened. And, you know, it's not evenly distributed. Most people haven't experienced it. I think it's, I think the repercussions are terrifying and wild. and I like talk about them to anyone who listen to me like all the time partly because I'm trying to like process my own feelings a little yeah you know because I'm like oh no like I don't know if you know what's happening but like oh no you know like it's gonna it's gonna be bad you know and but good good bad you know good bad and a lot of change good bad change yeah and that's all really happened in the last little bit here and then I think now we're entering an era

where you, you know, back then, I think there were like two camps who couldn't talk to each other very well. You know, like the AI is stupid and everybody who's talking about it is a dumb dumb. And they're telling, you know, whatever, they're telling lies or they're saying it because their investors are making them or whatever the reason is. Yeah, it's a bolt on. It's just a, they have to because it's a probability machine. They don't have choices, whatever. And then there were people who were using it. And they were having trouble talking to each other because people using it were like,

this is good for me. It's helping. You know, I'm using Claude code or whatever and it's like, and I'm more productive or it's better. And they were struggling to talk to each other. And now we have a third camp that's struggling to talk to each other, which is the version that's using AI to build the software that builds the software that

they're trying to build. And that third camp where it's like, I'm building the machine with AI to build the software that is the thing I'm trying to do. That camp can't talk to either of the other. two either. You know? Why is that? Because it's wildly divergent. Like the experience you have doing it is different. The answers to problems are different. How you feel about the work is different emotionally. You know, like it is wild how different it is. And so like if you go from like camp one

and you're talking to like a camp three person, you're still talking to that person like they are a hype machine dumb dumb. You know, you're like, and they're not. They're actually doing something with their hands. They have an actual experience

that they've experienced directly that is working. That's crazy great. That's like an order of magnitude minimum better than what you're doing by hand. And you just can't talk about it. You know, you're like,

no, it's so different. And they're like, I don't understand. And then when you try to explain it, they just look at you like you're a crazy person. And I think, I think it probably goes a little both ways. That it's just like, oh, nope, you've either had that experience or you haven't.

And if you've had it, you can talk about it with other people who've had it. But, you know, if you haven't had that experience, then it's like, you know, it's how I imagine it was like, I don't know what it was like when radio happened. But I bet it was weird for somebody to be like, no, there was a little box and the baseball game came out of it. And they were like, what do you mean the baseball game came out of a little box? Or the president started talking to me. Yeah, I heard. what do you mean you heard Winston Churchill? You know what I mean?

Like how did you hear Winston Churchill? You know? And like I think it's kind of like, I don't know, because obviously I'm not that old. But like, you know, it's like that. And I think it's, and it's getting worse because the people who are building systems to build the system,

you know, people who are building the software to build the software are accelerating at a nonlinear rate. So like they're currently in order of magnitude different than we used to be even six months ago. And what they're doing with those tools is creating what will be another, at least order of magnitude, maybe more jump in difference.

And they're just going to accelerate the weird. You know? Like the inability to communicate is just going to get worse. Yeah, we thought there was an abstraction before. You know, I'm trying to say, like, the abstraction now is both understanding AI, understanding how to use the tooling around it, building the machine to build,

the machine. Yeah. And like some of, like you said, some of those problems are like largely personal and hard. They're like the way I'm solving my problems and building my machine is not the same way you're building your machine. And it shouldn't be at this stage because we actually don't know yet how to do like what the right best thing is. Like we kind of have to figure it out together.

So like it's a little early to be like, oh, I'm building the AI development loop GitHub replacement. Like I think there's going to be one. But like I don't think you know. I don't think we know what that is yet. And so, like, I think you just got to, you know, we got to run it. We got this transitional period where we'll keep using the old tooling or what was the old tooling. And I wonder if the new tooling will come so fast when it arrives, but it'll still be a slow burn because you still have the non-max test.

Those folks who are just like, you know what, I let AI write some of my code. Yeah, yeah, yeah. I have no idea how, you know, like I talk to my friends who run, you know, like 100, 200, a thousand, software developer organizations. I got nothing. You know, like when we talked to like, what should they do and how are they going to move through this? And I'm like, I don't know.

Because like, I don't know how you, I have a like, you know, system initiatives. That's interesting. One thing we did was shrink because the product we had built just failed to find product market fit. And I just needed to face up to that. And so that we went from, from, you know, 18 to 5. And that was, that was painful. and then we decided to take what we had learned

and go build this thing called Swamp, which is very cool. I'm sure we'll talk more about Swamp. But like, you know, that team, we decided we were going to build it as maximalists. We were like, hey, we're just going to do this as if that's just our position. And it turned and it's wild, crazy,

the rate of speed that we're operating. I mean, bananas, the rate of speed we're operating at, the kinds of solutions were coming up to solve problems that would have been, you know, our ability to, to estimate how long something takes or what its risk is, is completely decimated. You know, refactors or architecture changes

that would have taken months are happening in hours. It's all on the table, right? Like, whatever direction it has to go is on the table. But I couldn't tell you, but like, I, you know, I don't know. Is that risky or not risky? I don't think it used to be risky. I mean, I think it's risky if you got,

if you're established, but if you're building the next thing, no. Even on my little software that's like, you know, swamps only four weeks old, it does so much. It moves so fast. And like, and it's so fun. And like your emotional ability to process like, hey, I'm a software engineer.

You know, I've been doing some variation of that my whole life. I know what it feels like to end my day having done a good job as a software engineer. Not anymore. Not anymore. I don't know. Like if I had a hard, what's a hard day at work look like when what I would I'm doing is telling agents to do the work for me and then the system is assembling it. Like there is a delta between a good and a bad day still, but I couldn't tell you what it is.

And I could before, you know, because I had this accumulation of days and experience in time where I was like, oh, yeah, I know that it's a bad day because that bug, I didn't fix the bug. Or, you know, it was a bad day because I, well, whatever. But I don't have it anymore. And so like your ability to even like emotionally regulate yourself, much less a team. where every single person on the team is also going through this dramatic change and how they work and how they think about their job and how they relate to the thing that they do with their hands.

And, you know, like, it's crazy. And we're more productive than the 18 of us ever were by a huge, by like a real margin. And that's not because I had schmooks before. They were incredible software developers. You know, it's just because we built the machine, to build the machine. We use those tools in a particular way.

And suddenly this acceleration happens. And that's why when you talk about it to people who are like, I fire out Claude Code and it does some stuff for me. And it's like, yeah, yeah, we're not the same. You know, like we're not doing the same thing at all. And, you know, yes, there's Claude Code involved. You know? But that's about where the comparison ends.

Anyway, it's wild. And like all the repercussions for everything are maddening. And if you just hang out and think about them, you just sort of spiral into this loop of like, well, I don't know, like, what's it mean for business and what's it mean for developer tooling and what's it mean for open source and what's it mean for SaaS companies and what's it mean for, you know, and it's all, you know, because if you're a systems theory person, like when a key constraint of a system changes as dramatically as this one does, if suddenly you can go from where the one of the key constraints was, can you just write the code

and that constraint is eliminated or in this case is just so dramatically accelerated, it means that the entire rest of the system's design is wrong. You know, it'd be like, it'd be like if, if suddenly the water pressure in your house went up by an order of magnitude, but what happened is every pipe in the house would burst. Yeah.

You know? And that's exactly what's happening to us now. We're seeing that. We're seeing that with like code review, code quality, like those are the main gates, getting, getting whatever it is.

is to production faster. Well, now the gate is production and observability. All those things are just blowing apart. That's filling all the pressure. Right. Those are the corner pipes in our house, so to speak. Yeah, yeah. Those are the ones getting busted.

Yeah. And then, like, everyone who, me included, who was building software to solve very real problems before this moment is wrong. Yeah, because I mean, the entire industry is wrong. A GUI, right? Right. Just it didn't matter what we assumed. It doesn't matter.

The odds that whatever problem you were solving. Some of the APAS could have been right though, right? I mean, even though I'm assuming this, but. If that's true, dumb luck. Okay. Dumb luck. Because like the actual shape of the problem, like, let's use like observability, monitor. Right.

Okay. In a world where I can produce at even a one order of magnitude change. Okay. But we, but let's assume if we. We can get to the one order, which I think is easy. We're already there. We don't know what we'll do how high the ceiling goes once we start producing new things with that capability, right? Which likely leads to further jumps.

So, yeah, metrics collection. What's that even mean? Which metrics do I care about? How do I expose them to people? Right now, I build Grafana dashboards. You know what I mean? So that people can look at them. but if I'm moving at this rate of speed, I can't look at them.

Not really. Not in any meaningful way. So why do I want one? Yeah. And the answer is, well, eventually I want to be able to see the metric or I need a dashboard. But like I still want them, but not like I did before, before I needed them as an operational certainty. Now it's like, well, I don't know. Will I want that?

My agent will want it? What form will the agent want it in? You know, how quickly will my agent be able to do that? And so, like, yeah, the incumbents have working technology. That's amazing. But they were all building it for a world where the person they were serving was operating in a world that moved at what now looks like horses and buggies. Yeah. And, like, I mean, the wheel survives.

Seats survive. You know? The chassis survives. everything else about that mode of transportation did not survive the shift to cars. None of it. You know? I don't know, man. Roads.

Roads survived. They sure did, yeah. Silicon survived. I don't know. But even roads got different. You know, we were like, oh, better pave all the roads because cars get stuck in the mud and can't have an ox. I don't know.

See what I mean? I spin out. This is what's happening to me now. Yeah. Don't worry about that. It's okay. I'm tracking with you, though. There's a couple things I put up in.

in, and I hate that phrase. I don't put pin in things technically. It's okay. I rambled because I, it's very, I'm clearly pent up about it. You know, like it's a problem. This is your release, Adam. Just imagine that this is as crass as I can be, but not be crass. Okay, this is your release moment, my friend. Yeah, this is us. We're here. We're here at the, put it all out there. Yeah. So you can't advise your friend with 100 to 1,000 engineers, because obvious, but you can't advise on 4 to 10 because now you're 5. You went from 18. to five. Congratulations.

I'm sorry. I'm not sure which one because maybe the future is amazing. Both are real. Both are real, obviously. What does it mean to be a team of five? What does it look like, I suppose,

on the daily, if you can describe, because it probably changes tomorrow to be an AI maximalist team. Yes, I mean, yeah. So we're, so we're, So the first thing you can't do is ask anyone to block on anyone else. Everyone free, autonomous. Yeah, they kind of have to be because the rate at which they can work is so high that if they have to slow down to check in, then actually it feels terrible.

Yeah, so no stand-ups, obviously. I mean, you do in the morning. You synchronize. So like we synchronize together in the morning. Then we talk about what we need to do. And then people just sort of go off and do it. Now, meanwhile, there's a bunch of work that's coming in from like early users of swamp that are like posting features or issues.

And so like we're fixing those as we go. The process tends to look like we talk to each other about what we think needs to change, come up with a plan, write that down. then someone takes it and starts working with an agent to actually turn it into an implementation plan. Then that plan gets reviewed by maybe multiple rounds of different adversarial agents for different purposes. So things like architecture, you know, like the software is architected in a particular way, uses this pattern, review this plan to make sure that it's not violating those architecture principles. Or like Swamp Club is the first website I've ever shipped that gets 100% Lighthouse School.

It gets 100% SEO and 100% usability, like accessibility. Congratulations. That's amazing. Don't congratulate me. I install the skill. I built an adversary. You're the owner. I mean, all it, we built an adversary that says make sure that we do this in an accessible

way. And then it looks at everything and does. And so, you know, like tab completion works everywhere in a way that's sick. And it would work for a screen reader and all that stuff. SEO coverage. We talked about that. So that sort of refines the plan before you even get to the part

where you ask the agent to build anything. Then you ask the agent to go build. It largely does that autonomously. You know, we're watching it only to sort of correct as it goes. And we're usually doing more than one at a time because once you get to that phase, you might as well go back.

You're going to wait. To the planning phase. To do its thing, yeah. Yeah. So you're usually spinning more of those plates at once. Two to three, maybe five. Five. Yeah, five feels like a lot to me still.

But Paul Stack, who works for me, right, routinely has five. Yeah. So, you know. I've had like six or seven at once. And it's until you get into a good stream. And it's not like prompt and prey. It's organized. And I think if I didn't have some of the machinery I built to get organized, I would be one.

It has to be pretty organized. Sometimes I like to do this one just to get back to like old me. If it's hard. I just got to focus. You know, I'm still thinking. about. 100% on this. Yeah.

Let's get over this big hump. I'm going to totally focus on this major feature. So then what else happens? So then there's tons of testing that's within the agent's control. So then that produces a pull request. So then that pull request gets adversarially reviewed as code across the same sort of axes that the plan did, you know, but just with a different agent. And now it has the context of the implementation, not just the plan.

And then if those agents find blocking issues, they reply being like, hey, this is a blocking bug. You got to go fix it. Then you just tell the agent, go look at the poll request, see what their review comments were. So the agents are commenting in the actual PR on GitHub? Yeah, like a person would. They're just doing the code review.

They're like, yeah, dog. This didn't match your, this didn't match your architecture. And then- Do those agents have accounts on GitHub then? Nah. They're just like running out of CI. They're just running out of actions, you know? Gotcha.

Actions. Gotcha. And then, yeah, so at that point, it merges. So assuming that the robots think it's good, it just auto merges. So no human review required. If the robots think it's good, it's good. And then we run UAT tests, which this is a thing that we used to do back in the 90s, user acceptance testing, where you would have like teams of QA engineers,

and they'd have like binders. And every time you were going to release the software, their job was to go through the binder, page one, and like try every feature, you know? And if they found a bug, then they would file a bug and it would go back to engineering and then it would all start again, you know? And so like, you're basic, and we did that because there was a separation of concerns. For a long time, people were like, you could never ship software where the same people review the software that do the other thing. That morphed into four-eyed compliance, by the way. But like, you know, conceptually, that's what we used to do.

So we're doing that again because you need to have a test suite that's outside the agent's control that defines what the acceptable outcome is and isn't. So it can't just break, you know, authentication or login or, you know, when a feature is stable. And there's some rules for that. Yeah. Like UAT testing is only, you're only allowed to do it from the outside in. You can never, you can't, the less you know about the internals, the better in UAT testing. So it's not allowed to know the internals, for example. But you just have a big test suite whose job is to exercise the software that the agent can't change.

And then if it finds a problem, then it files a new issue that's high priority that goes. goes back to the top and then you stop shipping to production. So nothing ships until the UAT test pass again. And then, you know, once the UAT test pass again, then it comes back and you're shipping to production again. And I think we've shipped, I don't know, we have shipped 900 times more in four weeks. Yeah.

What does that, how fast is that loop then from implementation plan on through UAT and passing a failing. Pretty fast, you know? Same day, same hour in some cases? Yeah, same minutes. Same minutes, really, in minutes. Minutes, yeah, yeah, yeah. Is that individually, like you add them and then someone else would have the same,

their same flow into UAT from implementation of UAT? Yeah, yeah, yeah, yeah. So it's an individual exploration. Totally. That your feature gets blocked, not the entire product. Nope, the whole product would get blocked. Yeah, if UAT fails, the whole thing stops. Just that, like it used to do in the 90s.

Yeah, you fail UAT. The CDs do not get burned. What made you bring back UAT? What was this idea? How did you get there? You're like, man, I lived in the 90s. That ship software then.

Okay, UAT. Yeah. Or did you just like, did you have to like go back to the RFC for that thing? Did you pull out the coffers? No, man, I worked then. I'm old. I worked then.

That was me. Yeah. I was there. No, it's because you needed, like anybody who's worked with agents knows that they'll, they'll change the tests to match their desire. So if a test is failing and it can't figure it out long enough, it'll be like, fuck it, I'll just disable this test or I'll make the,

I'll change the shape of the test so that the failing condition is now correct. And like they do that all the time. I'm not having that experience. Oh, you will. And you kind of want them to do that because the truth is the tests are there for them, not for you, at that level. You know, like I don't understand the code anyway at beyond the level of the architecture. I understand the architecture, but I don't understand the implementation, really.

I couldn't because I can basically rewrite the entire program every day if I wanted to. So, like, instead, the test exists for the agent to keep itself coherent and to keep itself honest. But then that means I need another set of things that are outside of that agent's context where that barrier is absolutely immovable, where its job is to make sure that what the agent didn't, that the agent didn't do something crazy in the loop where I'm not looking. and that's what QA used to do. That's literally what UAT used to be. It would be like engineers would work, work, work, work, work. They'd go, we think this work is complete.

They'd pass it, they'd hand it off to QA. They'd take their hands off the keyboard. QA would go look at it. They'd be like, okay, how do we feel about it? QA'd be like, oh, I feel bad. I found a bug. They'd file a bug. It would go back to engineering.

Engineering fixes the bugs. But the only thing you were allowed to do in that period was fix bugs. You weren't allowed to write features. You weren't allowed to do anything. You were just, the only thing you could do was fix bugs. because eventually it had to go, you know, on a CD that was going to get burned. And once you started burning that CD from the factory, you know, that's it. Can't be in a recalls, man.

You weren't getting any software updates. You weren't getting over-the-air patches, you know? And so, like, that's, that was the situation we were in. I'm like, oh, I got all these agents and they're doing stuff on their own and they're crazy. And so how do I make sure that those crazy agents don't do something wrong? And the answer is UAT. I use more agents, you know? More agents is like the answer to basically everything.

Take me into your implementation plan. How nuanced is that implementation plan? How do you get to what exactly is it? What does it describe? And how does it keep an agent or you and the agent on track? Yeah. I'm going to answer a little obliquely. Because you can't share?

No. Because I'm not sure how to describe it. I see. Okay. I think for a long time, a lot of software developers learned how to be software engineers from the bottom up. They started attacking code. And they still, there's a, there's a, it's, you've been able to be a good engineer in our

industry by being one of those people. There's, I've hired them. There's many that I really respect where their first move is always to just, they go straight to that code and they kick the crap out of it until it, until it like comes into a shape that makes sense that they like. And that's how they program. That's essentially dead in the era of agents. because you can't understand the bottom.

Like the bottom is moving too quickly for you to attack it with a machete. You know what I mean? Yeah. So instead, it's all about software architecture coming down. It's do you understand how the components of the system are supposed to fit together? And can you describe those components to the agent in a way that allows the agent to make the implementation have the behavior you desire? And that is very strange because most software engineers have spent most of our career making fun of architects. You know, if you're a software architect, you need like one for every hundred software engineers.

Suddenly, that's like the main thing you need. So when you look at our plans, the best ones are the ones that start with an outcome. So they say, hey, we're trying to solve this problem. And then they use the architecture, the language of software architecture, to specify how the existing system should change in order to accommodate it. So, you know, you have to do a little less of that when you're like, make this button be greener. or, you know, move this left to the right. But when you're like, no, I need to add an anti-corruption layer

between these two different bounded contexts. Or like recently, I had to describe how we had made a relationship where the authentication layer was separate from how the rest of what we had done was. And we basically said that we were a follower of the authentication layer. And that was a mistake. It turns out I needed to consume the authentication layer. I needed to be an implementation detail of my one bounded context. And so I had to refactor it by saying what we said was a different bounded context is now an implementation detail of this other one.

And I want to completely, I want it to sweep it under the rug with anti-corruption layers. And I had to say it that way to the agent because that's also how I told the agent to work. I gave it examples of the software architecture I was looking for. And I was like, here's how this works. And it already has read the domain driven design books. It knows what to do. And so if I use that combination of that architecture language and the outcomes I'm looking for in the larger system, it does a great job of generating code that fits to that paradigm in a way that no human would ever be willing to do. Like, it's so fucking annoying to write code that way as a human being.

But the agent's happy to do it. And so you wind up with this like really clean, supple, easy to maintain code that like you don't want to write, but you can read it if you needed to. and you understand the architecture. And so the plan phases look like a combination of those two things. It's the high level, here's what we want to do. And then it's the low level like this is the architecture by which to accomplish it. How often are you also writing, and I think the word has been thrown around a lot, behavioral-driven design, spectraven design, which I think is like a glorified prompt.

I'm talking about like true specs, like an RFC-219 compliant type of true spec. Are you doing those? Design documents? sometimes design documents, but not, they don't live forever, and I'm definitely not writing pure specs. Okay. Well, you're not, though. But you're not using them at all? The agents not really either.

No? Nah. Like, I mean, the plan, does that like rinse of the plan mode, it looks a lot like writing a spec about how you're going to implement it. But no, it's not starting with a here's my software spec. Now, Ralph Wiggum loop my way to. Yeah, I'm not even talking about that either. Not where it's more so that whenever it has to go off track. or it has to do code review.

Yeah. It knows. In my particular case, I've written this DNS server called DNS whole. And, you know, it's a lot of it's over my head in some cases, but some of it's like rate in my wheelhouse. But it literally has to adhere to RFCs that are, you know, internet. I would feed it. I would feed it that all day. Right.

All day. In those cases, for sure, for sure. But what about even like authentication? Like, we want to authenticate a certain way. Would you not specify it with a spec? Oh, yeah. I specified. I was going to use the Better Off library.

Okay. And I was like, you're going to only use Better Off and you'll never end like. And architecturally, I said, better off is its own bounded context. And I want, I want to be a strict follower of that model. So whatever they say, that's what I want. So wherever, wherever my. My domain conflicts with their model. Their model wins, and mine is subservient.

That was a mistake architecturally. And so I had to architecturally describe how I wanted it to be different, which was, I need you to go make all these models. And, like, you know, now I actually want to flip it around where my concept of a user is more important than their concept of a user, for example. That's an architecture change, you know. But software developers wouldn't have talked about it that way historically. Historically, you'd have just done it, right?

You'd have been like, oh, I'm going to refactor to blah, blah, blah, blah. And you talked about the implementation details of your refactor. But I don't know the implementation details. Neither do you, because they're happening too fast. Because any individual software developer could be pumping out 50,000 lines of code a day. We could just rewrite the whole thing every day if we knew what to do. Yeah. And we knew what to say.

And so the only thing you can be the only sure handhold is the architecture. The architecture doesn't change that fast, right? The implementation does, but the architecture doesn't. And so you can guide it through the architecture. maybe we need some more context around swamp and what you're actually building so I can understand what challenges you're navigating like I can read your homepage I can do all that and I have yeah have I had done the curl install no I have not Adam I wasn't sure I should do it on my machine or not I was kind of scared I was we used to be friends we used to we came into this show pals but now you know

let's do parentheses yet you broke my heart Adam It broke my heart. Yeah. We'll have to do a plot again whenever I've actually tried it. Because things are moving so fast, time is very hard. Time is very hard. For real. Time is super hard, okay?

Yeah, so Swamp, let's get into Swamp by talking through this. We were just on this tangent about software architecture and sort of how to prompt, how the system builds the system. So, you know, my whole career has been building, I build automation. That's what I do. And a thing that's true is the velocity of, engineering causes co-committant increases and the velocity of operations always. So there's never been an increase in software development velocity that wasn't also accompanied by a

increase in operational velocity. Before these changes happened, our ability to operate those systems could barely keep up with the leading edge of software development. I mean barely. We were hanging on by our fingertips. Like if you were the most peak performance team of software developers, the operational concerns often dragged you down. But if you like got everything right and it was all perfectly aligned, you could hang on. You know, you could not, ops could not be the bottleneck.

But you had to be, you had to be doing it, you know, like it had to be designed. It had to be, you had to come correct. Okay. No way. No way. Those techniques survive an order of magnitude increase in volume. None, none. They will blow immediately because they could barely keep up with what we were doing before.

It was already slow compared to. It was already bad. Towards versus hair in a way. It was already tough. Triple hair, 10x hair. Yeah. If you got everything just so, you could do it. But you mess one thing up and you were cooked, you know?

So we had built system initiative. I've been trying for six years to figure out how to solve that. problem. I'd come up with some really smart things. The last iteration, which was, uh, which used the models we had built to build agents had a problem, which was that it was tied to the same sort of underlying infrastructure we had used to try to solve this like visual composing composition problem, you know? And it just was too weird, you know? Like when people touched it, even though it could do wild things with the agents, they were like, yeah, but it's just too weird, you know? Like, it's just, just two for a left center. Yeah. I,

I feel that in some things. Like you can just have the most next revolutionary thing. It could be the most amazing thing. But it's just like, it's just too different. It just wasn't quite right. It just wasn't right. And so with Swamp, we had a couple of revel, we had a chance for a couple of revelations. So one was we had discovered the beginnings of this like we should be building a system to build the system.

You know, we should be building using AI to build the systems that let us build software at this right. And if that's, if that's true, which it is, that that's what we have to be doing now. The question is, how do you do that for infrastructure? Because all the tools we had to build and manage infrastructure were the worst interfaces for that problem. Like they're just not, they can't keep up, they're not good enough. It's too complicated. And so what Swamp does is it gives the LLM an architecture

in the same way that like domain driven design is an architecture to let it think about building reusable automation. So it thinks about it in terms of reuseable. models that have inputs and definitions and typed interfaces and methods that they can run, which then do things, and they produce data, which has different attributes, like maybe it's a resource that you can serialize, maybe it's just pure data that you can track, it has lifetimes, you can track multiples of them, and then you can put those models together into reusable workflows that do things for you. And then Swamp is an implementation and a description of that

architecture. It says, hey, here's how you put things together. Here's agent, how you drive Swamp to do it. And so, you know, one of the first things we did was one of the people on the team, Nick Steinmates, has a big, he like collects anime for his friends on a big media server so they can all like watch anime on Discord when it comes out in Japan. And so he rebuilt the scraper in Swamp by just telling Swamp, hey, I need to go scrape all these torrent sites and if I download all the anime for all the episodes of the shows that I want. Or he runs, his friends show up and ask him to run like Minecraft servers with all the mods.

And so he just replaced all those workflows. And what's cool about it is that Swamp writes itself. So in every other age of automation, you would have had to wait. How long would you have had to wait for somebody to build like the ProxMox API support in order to do it? And in Swamp, you don't wait at all. Like we told it how to do it.

And he said he wanted to use proxmox. And so Swamp just wrote itself. It was like, great. Here's where I would put the part where I boot a server and proxmox. And then it would just go, it just goes and does it. Another good example was someone was working on their, that bad Wi-Fi connectivity in their house upstairs. And so they told Swamp to connect to all their Wi-Fi gear

and do the analysis of the signal strength for every device that was connected and then make a recommendation based on the gear they already owned to tell him what gear to buy to fix his Wi-Fi problem. And so it just wrote the automation to connect to those devices, to grab the data, to store it, then do the analysis, then tell them the result. And it just wrote itself. Like the automation just did what it needed to do.

Because you kind of gave it tools, right? We give it certain tools that can, tools that can write and do different things. I'm giving it building blocks, you know? Hands and feel almost. Here's eyes. Here's hands. Yeah, and here's how you use them. Another thing that I did the other day was while I was shipping other features,

I built, I rebuilt configuration management inside a swamp. So it does like, you know, SSH-based operating system configuration management. And it has a bunch of, you know, item potent, convergent config management primitives. And so now, whenever you want to do something in an operating system, you can just install that extension and reuse my models to do it. And so it'll be like, oh, I already know how to install packages on Ubuntu. I'll just go grab that extension and I will use that to rebuild this workflow. And what's cool about it is that because we've separated like the information historically,

you would have had to have known like what's the right shape of the data. You know, how do we share those things or how do my methods work? And in Swamp, you don't. You can just be like the methods produce data and then you can query the data with the LLM and then you can use that to feed back into the workflow and sort of around and around it goes. So you wind up with this huge, this library of repeatable workflows. And we have people using it to like manage like a big production metrics gathering infrastructure. We have people doing like cloud provisioning is great with it, especially once you then have to go do like day two things.

So yeah, that's swamp. It's basically reusable automation at the speed of agents. Okay. It's so fun. It is so fun. And then it writes itself. And there's like a lead like, you know, we have leaderboards. You get special points.

As you use swamp, it keeps track of your utilization and it gives you points and then it will reward you with levels. You know, like tears. Get out of here. When you start, you're a swamp baby. But you know, you might get to Merk Lurker. But there's like, we're not going to tell you what the tiers are. They're all secret. So like the first person to hit each tier gets points.

Yeah, but they're like the first two. Okay. That's table stakes then. Too easy. Yeah, yeah. Would you consider this harness? Would you say that this, what you've built, is a harness? This word gets thrown out around a lot.

It's like, I'm building a harness for AI. I mean, I don't know. I think what I'm building is reusable automation. And what AI, what everyone who is building these software factories that we're talking about now, using the system to build the system, what all of you are going to need is the ability to then build and manage the infrastructure that runs that stuff. And it has to be able to be produced and managed. at the same speed that you can produce and manage the software you want to get into the world. And that's what Swamp is. Swamp is that thing. It's the thing that makes that possible.

Who's it for? I mean, it's for anyone who has to build reusable workflows to get their software into the world or to do or to or to solve any sort of what we would have considered historically operational problems. Because what it does, right, if you think about the difference between like a software development problem and operational problem. Operational problems usually look like workflows. They look like when X happens, do Y. Or I need to do X to change Y. And so that's what Swamp is.

That's Swamp's Sweet Spot, right? It's like, yep, it knows how to, it will write itself to turn itself into reusable automation that your team can use. And then it'll integrate that in a way that, like, nothing has ever been able to do. Can you talk through how it uses or how it would, that for proxmox? That example that you mentioned. How does that give me an example of like what actually happens when you request this request?

Yeah. So you so it would build an extension. It would be like it would be called of Swamp. We would call it Adam slash proxmox. Okay. And then you would have said, I want to create new proxmox VMs. And it would create a definition of a proxmox VM. And you'd probably say to it things like, hey, I want.

you know, memory or CPU, but even if you didn't, it would just infer because it knows ProxMox pretty well. You know, like not Swamp, just clawed,

you know? Codex knows how to use ProxMox. So like, it would just sort of create you a model. And then it would write the typescript code that is the method itself. It would be like, hey,

in order to start a VM and ProxMox, I should call these commands. And it would probably default to using the CLI, unless you told it to use like a library. And then, Then it would have defined a typed interface to ProxMox. It would say, when I want to create a VM, the arguments I want to pass are like, you know, the CPU number, how much memory I want, the operating system image, you know, those things. And then those inputs become definitions in models.

So there's a file in your Swamp repo, which is like a GitHub repo, that is defined in YAML, and it would be a model. And it would say its type is ProxMox server. and it would define those inputs for you. And then it would have a method on it called create. And you could either call the create method directly on that model, and it would just go do it. Or you could call it in a workflow, right? That would say, well, I want to create that VM.

And then once it's up, I want to use Adams config management extensions to install Minecraft on it and then bring it up for my buddies. And then I want to analyze whatever. I want to make sure that it's healthy. And it would either grab extensions that already exists or it would write net new ones and it would finish that workflow. Hmm. It's kind of hard to even imagine that world, really, you know?

Yeah. Because you don't have to wait for ProxMox to finish their API better. I mean, I suppose you do. There is enough documentation around it. Yeah, there's enough. It's fine. I've hit some issues with this myself. I try to automate ProxMux.

quite a bit, hit some issues with Cloudonit and some other issues with other things. And so I've got a seemingly considering what you've done, a pretty rudimentary go CLA that does what I needed to do to automate ProxMMM instances. And my agents know how to use that CLI really, really well. So for me to spin up or destroy a ProxMXVM is like pretty easy. Just like saying give me. And give me, give me, I need, I need. And that's to quote a fun movie.

And if you had done that with Swamp, you would never have had to write that bespoke Go program. It would have just written you primitives and then use those primitives in a reusable workflow. And then as you went to extend it, and this is where it really kicks in. Like automation, it's cool when you write a program. Anything can just write a script to do it. What makes automation automation is that the model layers are reusable. So that moment where you're like, I created this VM. Okay.

Great. That's awesome. How do I know so I can get back to it later? What if later on you want to write automation that says upgrade all of the VMs that are on an old version of Ubuntu? How do you write that? And in Swamp, it's trivial because you would have just taken the data when you created it and stored it as data in the swamp. And then later, your other workflow would have looked at that data and been like, oh, I know what the ProxMox VMs are that Adam has. I'll just grab that data.

Oh, I don't have enough. I need the memory. Great. I'll use the first piece of that data, the ID of that thing in ProxMox. And then I will write a thing that goes and gets it. it and then I will write out that data and then I can use it to do the next thing. And like, so like that. Yeah.

And that evolutionary nature of it that says, I don't need to know what the model that I don't need to know what you want to do up front. I need to give the LLM the architecture, the shape that says, hey, to make this into reusable automation, think in terms of models, think in terms of data persistence, think in terms of workflows, think in terms of the relationships in between. them think in terms of inputs. And then I provide tools to make those things get validated across the line. So like, you know, did you write a model that is correct?

Call swamp model validate. It'll tell you. You know, it'll look at how you define the model and whether the inputs are right or wrong. And so now the VM doesn't hallucinate when it creates its own models because it can just validate that the things it makes up are right or wrong, you know, on and on. Yeah. Yeah. It's so cool.

So a little bit into the weeds here, but does that run on the, the actual ProxMux host, or does it call the API from a machine that has SSH? How does that work? Runs from wherever you want it to run. So you can run it, like, just literally go on to ProxMox, do your curl command to install. Yeah, man, do whatever you want it to do.

Okay. Swamp will just write itself. Just tell what you want, and Swamp will write itself and turn it into reusable automation for you, because it knows how, because we gave it the architecture for reusable automation. Is there a...

Yeah, this is a insane, really. Is there a world explored so far in a world unexplored? And what is that world unexplored? Oh, there's so many unexplored worlds. Yeah, like tech definitions and workflows. Oh, I mean, like, yeah, there's so many extensions that we can build. So that's one part. I mean, another is, you know, what's the right ways to collaborate over time, you know, beyond like we share to get repository so we can do it. There's, you know, there's all kinds of stuff like that that is sort have still unexplored. But that core thesis that says, hey, if we're going to build automation at this new rate of

speed, you have to be able to automate anything you can think of and you have to turn it into reusable automation. I can't know in advance what it was and the agent must be able to assemble it so that in the end what you get is reusable workflows all the time. And that's what Swamp does. And that, I think, points to the future of how we're going to rethink a lot of different systems because we now have this capability in the agent to be able to to do the right thing in a bespoke way.

I don't need to know exactly how your proxmoc setup works in your home lab. You know. So you can just tell the agent that's how it works. And so if you're like, hey, what I want you to do is SSAGN, go ahead, do that. We had somebody else who used Swamp to try to set up a, he was trying to run like a 10-year-old version of MacOS 10 on a QE movie. instance on a Linux box. And it failed. But, you know, putting Swamp in the debugging loop meant that it got as far as it could possibly go until Swamp was like, hey, the problem is

you're missing your driver. There's no display driver here that could ever work. So that's why it turns on and you get text and then when we turn on, we try to get you the actual UI, it crashes. And, you know, I didn't know that you could use Swamp to do that. But Sergey knew, you know, because he asked Swamp to do it. And then Swamp did it because what he wanted was a reusable way to boot OS10 machines

from a decade ago. So he told Swamp to go make him one. And it tried as hard as it could. And like, you know, then told him it couldn't be done. And why? Sick. Well, friend, you know, I'm a big fan of Tailskill. And you know what? I could not do anything. I'm serious. Anything without my tailnet.

I'm here with my good friend, Alex Kretschmar, from Tailscale. Alex, how do you describe tailscale versus a VPN? How do you describe tailscale to someone who's not in the know? Well, the biggest difference between tailscale and a traditional VPN is how the traffic flows. When you look at a traditional VPN, the traffic flows through a central hub and then out to your client devices on the back end. With tail scale, every device makes a connection directly to every other device. And that means effectively you're cutting out the middleman and you get much better performance as a consequence.

And so that mesh network that you've built, you've got to have a way to control how the data flows between different devices. Because you don't have that central choke point anymore, we have a thing called access policies, which allow you to granularly define using ACLs and grant policies, which nodes are allowed to talk specifically to which other nodes, on which protocols, on which ports, and which users are allowed to even connect to different things all over the tailscale-encrypted tunnels, which underneath use the wireguard technology. Yeah, it's not my land, it's my tan, my tailscale area network. But your word for it is tailnet, right?

The tail net is the word that we invented to call the logical grouping of devices that form your tail scale network. Much like you might have a land of devices or something like that at home. Effectively, the tail net, we call it something different because those devices can transcend physical locations. So you can have a server in the cloud, talking to your phone on the bus, talking to your server in, I don't know, the basement of your mum's house across the other side of the ocean. And that tailnet is a flat network that only you can connect to and access. So that's why we call it a different name from anything else is because it's location independent and you can connect to it anywhere. Well, friends, check out taelscale at taelscale.com.

Totally free for your home lab. And, of course, paid for your teams, pro and enterprise. But literally, I could not do anything I'm doing in my home lab, in my dev lab, without tailscale connectivity. I'm out and about. I'm here, I'm there, I'm everywhere, and I've got to access my home lab, my dev lab resources,

and tail scale is how I do it personally, and you should too. Once again, check it out, taelscale.com. Why the name's swamp, Adam? Oh, because it is the initials of the five people who built it. Well, that makes sense.

That's how you work. That's how you roll, right? Yeah, it's Steinmates, Watson, Adam, Mehear, and Paul. Nice. It's a throwback to the roots, I suppose? Or is that just your way? I mean, it's just, I tried to make it a code name. I was like, we should definitely pick a name that we won't keep that isn't what we want.

And then we named it Swamp. And then it turned out that Swamp was kind of awesome. And the more we played with it, the more we liked it. And I think the, you know, like if you go to Swamp Club, you'll kind of see why we like it. The website is swamp. dot club, by the way, in case you're listening and you're trying to figure out how you can get some swamp. Oh, yeah, we should just say a long time ago. Yeah, go to, go to swamp. And like, you'll see the aesthetic of swamp club is fun. You know, it's like a cyberpunk swamp thing. And, you know,

you're like murk lurkers and the directory where your data lives is dot swamp. Because like, you know, the agents are off doing what they do. And like, there's got to be some joy for the humans, you know, like, what are we doing with our time while it's writing all this reusable workflow magic, you know? Like, like, like, I want to be, I want to be leveling up my, my swamp club leaderboard, you know what I'm saying? Now, how does that happen? What do you do to level up your swamp? You just, you just, you just use swamp. So basically we, if you sign up to swamp club, then we will, so like, we're taking some telemetry that's anonymous. And if you authenticate, then we take that telemetry and we use it to give you a score.

So we just track everything you do. And then over time, all the different ways you can use swamp like publishing extensions and people using them and all that stuff will increase your score. So like, but we're not going to tell you exactly how we're going to, and we reserve the right to change it season over season. So there'll be different seasons of swamp. So if you like sign up for swamp now, you're in season zero, you know, you're an OG swamper for life.

And we'll give you like a little badge. tells you you're an OG swamper, you know. Season zero, I like that. Season zero is swamp, you know, because it's fun. Because it is fun. It seems fun. It is. It's so fun.

Give me some marching orders then. Let's say, done with this call. Now, mind you, I've got some travel this Thursday, so it'll be challenging to find this time without all my infinite time. But it's cool. The agents do it for you. Yeah. Yeah, but I mean, I like, you know, so part of this Adam is like, I know they'll do it for me, but I kind of want to watch them do some of these things.

I want to learn alone with them in a way. Yeah, I get it. I do. You know, so while I want to like just have my agents always be busy, I kind of don't, you know, I kind of want to babysit a little bit because I'm kind of want to still enjoy making software. Well, I can. You know what I mean? I do know.

It's a struggle. I'm definitely making, I'm making software at an incredible rate. I'm still making software. It feels very much of a piece. But yeah, what are your marching orders? I mean... Well, I have a proxmocks box, so let's just stay there. What would I...

How would I use Swamp to play with that ability? It's really, really straightforward. You're going to go to the website. It goes Swamp Club. You'll install the binary. Start install. Yep, you'll curl bash it. Then you're going to make a directory called whatever.

Adam plays with Swamp. Adam Proxmock. You're going to type Swamp, Repo. Init, which turns that empty directory into a swamp repository, sets up a couple things for Claude, puts some skills in there. Then you're going to type Claude, and then you're going to say the first thing you wanted to do. So you're going to be like, maybe it will be...

Only Cloud or Codex. You pick. Pick? Okay, cool. Yeah. When you run repo in it, you could decide. I'm a Claudeman myself, but, you know, you do you. Should I dash, dash dangerously skip permissions, or should I just...

I wouldn't, you know, because I like, you know, but you could. I'm a big plan. I'm a plan mode guy myself. So if it was me, I would put it into plan mode. And then I would say, using Swamp, go look at my ProxMox server at this IP address and build an inventory of all the VMs that I'm running. And hit enter. and what it will do is write you an extension to go talk to proxmox,

and then it will build a method on a model that it will build a model of proxmox. It'll build a method called probably something like list or inventory. And then it will use the proxmox CLI to go get that list and grab all the data and store it as a data structure inside Swamp. And then you'll say something like, you know, show me all the, not tell me what's in there, you know? And it'll go look at the data and it'll tell you, here's the list of all the proxmocks things you have.

And then, you know, you'll ask it to do something else. You'll be like, go create me a new one and that looks like the other one. And it'll, it would do the same. It would write you a method. It would look at the data, you know? And like, you just start telling it what you want to do. So a good way to start would be think about that Go program you wrote and just ask it to do what the Go program does and watch it build it out of reusable building blocks.

like it'll just start building new models and then those models build on themselves. So, you know, if you, if you go look at the, that's, that's it. Like there is no step two to swamp. That's like you download swamp, you initialize a repo, you tell it what you want and it just goes and does it. You know? And like, you know, we have people publishing, somebody published this morning, like support for managing GitHub repos and running security scans. somebody else is doing Talos, Kubernetes management and provisioning, Honeycomb, S3, ubiquity, DigitalOcean, Hetsner, like, config management.

Like all those things are, you know, those are all the existing extensions. So then you can start exploring the universe of like what are the published extensions that Swamp. So things Swamp can already do that already have these reusable models already built in. Then you can use those. So maybe you want to do something like, inspect all of my proxmock servers, figure out a plan to move them into Hezner, because what you care about is EU data sovereignty. And it would literally build you a workflow to do that.

And it could do things like backup the server, you know, then upload the ISO to Hezner. Like it configure all that stuff out. Because it's built for general purpose automation, not for like cloud automation or CICD automation or whatever. It's built to solve whatever the automation task is that's in front of you. I'm watching it do his thing. Oh, you're doing it right now?

Of course. Amazing. Yeah. I'm saying, yeah. So just asked me if I wanted to use the extension search prox. It's actually searching proxmuffs, I guess, to find this stuff. Yeah, because there is a proxmox one already. Yeah, it's going to use key proxmocks, which already knows how to manage the fleet lifecycle.

Yeah. That's interesting. Yeah, it's going to call Sync Fleet probably. Let's see here. I'm going to share it with you. and maybe we can actually capture this on part of the pod. Swamp extension install. Keeb.

Who's this person, Keeb? Who's Keeb? Keeb is one of the people who built Swamp, next time mates. I would trust. I would trust Keeb ProxMox. Sweet, here we go. We're trusting them.

Uh-oh. It's going to figure it out. That's okay. It's going to figure it out. Swamp extension. Yeah, be like, yes, yes, yes. Go ahead. Fine.

Yes. Yes. So, like, one of the things we're tracking, for example, is we now got, telemetry that told us it hallucinated that command. So like, we're making a list. And so, like, one of the things we do is just add commands for everything it hallucinates

so that they just work. Do you know what I mean? I do. Yeah. Telemetry. Beautiful. Great. Hold. Exit code again. Let's see. Okay, that's unknown model. Oh, Keeb's models are a little built wrong. That's fine. For the audio listeners, we have something on video later.

Yeah. We may map around this. For the audio folks, it's less tantalizing. Yeah, I mean, what Swamps's doing now is like it's searching. Yeah, narrate. And so one of the things you have to do to connect to ProxMox is you need credentials. And so it's going to go build a local encryption vault to store your ProxMox secret. And then it's going to off to the server. So you probably didn't have your credentials set up. And so now it's telling you to like, hey, put your credentials in this vault

so that then we can use them as reusable inputs to the automation. And then once it's done that, it would go and finish the rest of the process, right? Yeah. It's asking these questions right now. That's what this is doing? Yeah. Right now the output is like, hey, in order to do this, I need to know, like, how are you going to connect to ProxMox? I think it's about endurance.

Is the node. Yeah. See what happens here. We're just prompting and wishing at this point, praying. Yeah. We're just sort of saying. Good. Node is endurance.

Gotcha. Sweet. Have you stored your credentials yet? The answer is not. So, yeah, it's going to want you to go ahead and do that. Maybe pop a terminal we can't see. Get yourself up. Yeah, maybe pop a terminal.

If you know your prox, mox, user name and password. I do know these things, yes. And where would I put this at? In the same, where would I store it at? Yeah, so you're going to, the repo knows how to store them. It'll basically encrypt them for you. So the commands that's telling you to run are the right ones.

I'm going to put it back into this LM. I secure. No, don't put them, don't put them into the LLM. Okay, what's the expectation? I'm trying to ask you. Yeah, you'll open a terminal window, and then you'll run Swamp Vault, put PXM Secrets, then the value.

It actually told you what command to run up above. Yep. Oh, I did, yeah, okay. All righty. I'll do this then in a separate terminal. Do you have to be in that directory? Or does it, doesn't matter where I'm at? Yep, you want to be in that directory.

In the direction of my project. Yeah, wherever you swap repo and it did. Okay. Dope. Enter value for? Yeah, it's probably ask. you to put in the actual username and the actual password. That's the key.

ProxMox user is the key and it's asking you to paste in the values. Yeah. Hoping and pasting. Now what do I do? If I say the vaults, okay, yes, they're stored. Let's dice the roll. Let's see if I know what I'm doing here, y'all. Do I know my actual user pass?

We're going to find out. If you're going to find out, it's going to debug that for you. Uh-oh. I see root. Oh, gosh, did I mess it up? it's fine. The vault expression is going to take care of it. It's going to just write it as an expression.

It's fine. Yeah. The agent knows you messed it up. And what it's going to do is edit the model so that it works anyway. It's like, oh, you forgot to say what the mechanism was and a proxmox use your name. So that's right. Do you want this? Yes, sure.

Let's see. Yeah. Yes again. Let's just let it roll. Yeah, for sure. Let it roll. So what it's doing now is writing reusable models that understand how to call into proxmox. and then now it's validating that that model is correct,

that you used it right. Okay, let's see if the off is correct. And now it's actually running off. So what it just did was run off independently. Authenticated. And it worked. And so now it's going to sync all your VMs. So say yes.

Gosh, this might be revealing, y'all. Okay. I might blur this out. It's like looking at my gutchy drawer, man. Yeah, exactly. Do you what gutchies are, Adam? No. What's a gutchie?

Gutsis are underwear. Ah, I see. Yeah, I know. I mean, I don't mean to be in your underwear drawer. Yeah, well, I mean, do you have a nothing drawer in your house? I don't know, maybe. I got a drawer that has a ton of stuff in there. Yeah, nothing drawer is the drawer that has nothing in particular in it.

Yeah, these are some stock VMs, okay. Yeah, what you got up top, though. Look at that. Oh, oh, oh, oh, oh. There are my homies. There's my home. And what's worth noting here is that like, while you did install this VM, like, well, you did install an extension, You didn't have to if you hadn't.

It would have just written it for you. Yeah. So like, you know, but now you could ask it to do something. Like, is there one you want to clean up? Is there one that shouldn't be there? Let's see. Like, I guess this one's probably dead potentially. This is definitely dead.

Okay, so tell it to delete. Tell it to remove Fedora Bootsie builder for you. Let's see what they say. If get rid of translates to destroy this. Absolutely. It'll be enough. Swamp model method run PXM. Dash fleet look up.

Okay. So now it's looking up the data about that particular VM. So it's making sure it has the latest information about that VM. Again, that's all just stuff that Swamp knows how to do from the architecture and the shape of the model. Oh, yeah. VMID 105 currently stop. This will. Yeah.

This is just true. We're going to cancel it. That's scary. Let's delete it. We don't need this thing. Let's see what happens here. Gosh, I don't know. I'm trusting you so much right now.

You should. Yeah. It's going to delete it. It's going to delete it. That's what's going to happen. Swap model run, delete. This is the thing it made on the fly. Yeah. PXM fleet. Yeah. And now it's going to delete it. PXM fleet is the definition of your particular ProxMox model, of your particular ProxMox server, which now it's issuing a delete command to in order to remove Fedora Bootsie Builder.

And the reason that's reusable, now type, make me a workflow that would delete any instance I asked for. You want me to tell that? Yeah, say write me a workflow that would delete any instance I asked for and tell it not to run it. But don't bother this. But don't run it. Just tell me. Just tell me what it would do. Just tell me.

This is fun. And so what it's going to do now is write a workflow that will take as an input argument, a name of a node, right? And then it's going to, and now you'll have a reusable workflow that anybody who had access to your swamp repo, you could be like, hey, just run the delete workflow. and that is the command. Oh, sweet. So if you think about this as like deploying my stuff to production, you know? Could I then tell it like, hey, I don't like this command?

Could you make it nicer? Sure. Yeah, sure. Use an adversary to be like, hey, what could I do to improve the user experience? What it does? Oth job reauthenticates with ProxMox to get a fresh ticket. Toten expire, okay, and then delete job.

Waits for the Oth to succeed, then deletes the named VM. There I go. What about creation? VM creation. Go ahead. Tell it to create one. Yeah. Create.

Create. Any instance, or I guess maybe in this VM, VM. Yeah, sure. Just tell me. Sweet. Let's try it again. Yeah. Or, you know, even more crazy.

It'd be like reboot. You know? Don't do that, man. I'll lose you. But you're in the box. I'm in a VM right now. I'm in a VM right now. You'd run it like this.

Okay, sweet. But yeah, so what it would do, so what it told you it would do is a good one. So because it's creating reusable models, it can set defaults for those values. So it would be like, hey, by default, we'll set it up so it has, you know, 2 giga RAM, 2 cores, 32 giga disk on local LVM

and a bridge network, all very sane defaults, right? Right. And then you could override those defaults, right? When you run the workflow. It actually didn't write it. So this is how it look. Yeah, we told it not to write it. Yes, I do.

And how, well, yes, but how can I choose my distro? Great question. It's going to build you a model. Yeah, but check out how you're swamping. Like, it doesn't know how to find ISO images. So it's going to figure out. It's going to learn. It's going to learn.

And it's going to write the extension for you. And then it's going to do it. And this is what I'm talking about, right? Think about how hard that is to do. So you must play the swamp all day long then. You're like just... It's so hard to stop playing with Swamp. Family is like, Adam, what are you doing up there or over there or wherever you're?

Like, for me, I'm up. I'm in the upstairs. Building Swamp is really fun, but using Swamp is even more fun. Okay. Want me to add a clone method. He's like, how about we clone one? That's a reasonable choice. Yeah.

Good question. Current stage. Use create as is with PXC if you have a server. Otherwise, we could clone an existing one. I see. But you have, okay, this is an older template. I think this is kind of a dead thing. I just haven't killed it.

Yeah, but like, that's crazy that it did that. Do you see what I mean? Yeah, I suppose. Like, hey, for the people listening, it looked at his existing old, he had a running system that looked like it was booted from a template. And therefore, it was like, hey, bro, I think what you want is to use a template. And then you could just create more of them, which is a very reasonable assumption, you know? Or you could clone an existing name or, you know, like it's giving you choices.

And this is, this is, this is this is this is this is the. swamp experience. You know, like, it's like, now that it knows how to do it, because it has access to that data from the inventory, it could just use it as context, look at the list of VMs you had, use that to make an inference leap to say, hey, I bet what you want to do is run a template. This is what I mean when I say people who have seen that can't talk to people who are just like write in their code by hand. You know what I mean?

Because they're like, well, what'd you do? And you're like, I just told it to like, write me a workflow to reboot Proctbox. And they're like, I know. So you wrote a script? And you're like, no. No. No, I really did it. I really didn't. It didn't feel like that at all.

I just kind of wished and it did it. I just, yeah, I just sort of talked to it. And then it did what I wanted. And like, you've kind of rendered my CLI useless in a way. Yeah. In a way. There's still some things it does that I'm sure, based on what I've seen, that Swamp could do fairly easily. And it's built on my own terms, it seems.

Yeah, it's going to do exactly what you wanted to do. Yes. And then if it doesn't, it'll just extend itself to, to do what you want. So like, like if like we're going to publish a bunch of models for all the cloud providers, right? Oh,

which will be really convenient so you don't have to write them and get coverage real fast. But if we like missed a thing or there's something you want to do differently, like it'll just extend it'll write an extension of the extension. You know, it'll be like, oh, I'll just add this on to the EC2 models. So now your EC2 model can do this.

Adam, this is a mind F. Okay. Yeah. But it's awesome, right? It's super cool. It is super cool.

And like, When you think about what it means for the future of how we build automation, like what it means is just really simply that like, we're not going to be the bottleneck anymore. Like you can absolutely say, like, hey, build me a system that works the way I want it to work, and Swamp will do it. And it doesn't matter how weird it is or how non-standard it is or how you set it up. Like it'll just, it'll write the code it needs to write.

It'll discover the data. It needs to discover. and then use that information to solve your problem, which is precisely what operations people have always done. And just like when we're writing code, it doesn't take the operations person out of it. If you don't know what ProxMox is, if you don't know what creating a VM is,

you wouldn't, it would still say to you, do you want a pixie booted or use a template? And you'd be like, I don't know. You know, like if you don't know what pixie booting is, like you could ask it to explain, you know, and that'd be helpful. But like, you still have to know what you want. But the layer that you know what you want is the architecture layer.

You know, it's, it's, I know the shape of how I want these things to come together. I'm not sure how to feel about what I've seen here. You feel good about it. I'm very excited, but I'm also like, what can't it build? What can't it do? I don't know. I mean, given infinite ability to extend it, you know, if the extension doesn't exist, then obviously you have to probably create the extension.

Or can it just like say. It does that for you. So. So if it. extension doesn't exist. If it doesn't mean about Proxmunks at all, I didn't know that Zeb created the extension. Yeah. It would have just made it on its own.

Yeah. Yeah. No way. Absolutely. Yeah. Yeah. So I could do that demo again, just like we did, which I'm not going to do it. Okay.

But I could have. And I should have no. Don't use his stuff. Make a new one. Okay. Make a new world. It's like, okay. Okay.

Fine. It would just do it for you. Yes. How long would it take? minutes. Two minutes? Nothing. How did you do this?

An absolutely de minimis amount of time. How did you do this, Adam? And what have you done to the world? Okay. I, what we took the... I see you dancing over there. You're getting excited a little back and forth motion. I'm stoked.

You're so pumped, okay. How did you do this? And what is it going to do the world? It's going to make the world awesomer. Okay. I love software. And I don't know what it means that we can now produce software in this way and at this rate. But I know it's going to mean more incredibly cool software.

That's what I know. Yes. And so I'm here for it. You know? Okay. What I wrote down at the very top of the show before you even said that, this is my brain. Yeah. Is more and better.

Yeah. More and better. More software and better. It's going to be more and better. I was telling my wife from the way to dinner the day, I was like, babe, you have to understand that this is how I, my audience knows that, like, I usually say, Babe is the first thing I say when I dress for my wife. Never her first name. It's always Babe because I love her to death. And I'm like, man, what you don't have to, what you understand is, is that all the software we use now is

now, it's going to get better. Yeah. It's just going to get more of it and better. Yeah. Because you can now cover a wider surface with SDKs even. Will that even matter? I don't know. Or. As an example, like, you just do it. more and do better software less bugs less buggy software or or you'll just build the things you want all the time and like just in time software for everyone like me i don't know i don't know because it's it's really hard to see it is very hard to see beyond one order of magnitude impact yeah and so like you know so like you're the question of like well what can't swamp automate and the answer is nothing Swamp can automate anything.

And it's like, we can't just do anything. Like, historically, that would have been like a really dumb answer. But it's really true because it's like, no, it can just extend itself.

So if it's a thing that you can, it will. And then it's like, okay, if that's true, and it can do it in minutes, mostly, which it will.

And then when it gets it wrong, it debugs itself. So you just sit there and watch it, go through the loop of being like, oh, imagine work, I'll try this. And like,

you know, eventually it works itself out. And like, the side effect of that is that if there's a time where software doesn't work for you the way you want it to work, the delta between you doing it the way you want versus the way that the upstream told you to do it is now zero. And even like the counter arguments that people make now where it's like, well, now you have to maintain it and deploy it. And I'm like, well, but if deploying it just looks like telling swamp, you know, if you're just like, deploy it.

Like, I don't know, man. That seems fine. Seems fine. Seems okay. Like, I don't know that I care, you know? And when you think of, I just don't know that I care. I know why I used to care. You know, I know why I used to care.

I used to care. It made sense to care. Because you had, well, you had to have your own personal certainty to have your confidence because it was your name and that's why you had to care and now I suppose whenever you know something else can move at such a faster pace and potentially dramatically better in almost all cases and yeah and be very specific to what you need and like okay so today that would be that still feels like a very strange move but will it tomorrow I don't know you know and like it opens the door to wild things.

Like, what's an operating system look like that's designed like swamp? Foof. Get out of here, Adam. Right? What's a, what's a... I don't even know. I don't either. But, but, but you're thinking about it now. And like, well, I just, I think about like, what, what kind of interface

does the future human want to use? Yeah. You know what I mean? Like, that might even matter. Like, would we even care about the operating system? Like, sure, there's something there, but like, do I care anymore? because I'm so distracted away that the agent will care. The agent will care, yeah. And the human will care someone, some human being will care about the architecture. Oof, man.

The same way that we care about architecture and houses and, you know, like we will care about, that is still a skill that will not be removed. You know, you still have to know how to describe how software systems work and how to build them and like all that stuff. But like, you know, people are afraid about how do we train new engineers. I don't know how many like new grad engineers you've trained, but I've trained dozens probably. And like, you know, they all come out of school and they know how to program, but they don't know how to program together on a team.

And, you know, like they learn over time sort of how all that stuff comes together. Now I kind of just have to teach those people architecture. And like if you go to my shelf back here and we grab the like domain driven design book, like the reason it's frustrating is because. he also has to explain how to implement those patterns to you as an engineer. But if I don't have to explain how the patterns are implemented, I just have to explain why you would choose one or the other and what their operational semantics are,

I bet I could train you to build software that understands how to implement those architecture patterns and you would be able to build reliable software systems today. That's bananas. That is bananas. I mean, that's almost the same as like, you know, when you're choosing your name, stack and you're agentic, you're an agentic developer, all you're using is AI, but you don't really

know, you know why you would choose Rust, you know why you would choose Go, you know why you would maybe choose Bun as an example, like as a directional thing, you know, because whatever. Right. And if you know those different things, you can choose the right path, but you don't have to know all the details of what makes Bun, Bun, or why you would choose that over a different paradigm. I have a friend in his spare time that is just rewriting Postgres and Zig for fun. For fun. Just running it in a loop, being like use the spec for Postgres and the test suite. And just I want you to rewrite the whole of Postgres and Zig.

And I want 100% compatibility. And it's, you know, he's going to be done in a month or two. Just for fun. I like that. Yeah, just because he can. Yeah, this is a bananas kind of world. We're living in, man. Yeah, yeah.

And like, but that's why I'm so stoked about Swamp. Because Swamp, like, what I love, I love the operational pieces of that puzzle. And so Swamp is us being like, great, yeah. Like, I don't want to wait. I want to lead. I want to figure that out. I want to like, great, how do we, what does it look like to build automation in an age where agents can build anything for you as essentially at speed?

And the answer is, I got to be able to build automation for you at speed, you know? Is Swamp-like, not so much I want to say this, but like an open-claw type of scenario where you can just say infinite ability with what you can do with it in a way where people kind of like wish their life into open-claw or nanoclaw or what you know. I mean, you certainly could certainly could, you know, like you could absolutely put a little agent loop around it and be like, you know, giving OpenClaw access to swamp, it would automate, you know, what would it automate for you? The answer is a lot. You know? It's a lot. What is the most, I guess, out there thing that I could ask it to do in terms of, is it only infrastructure setup? What are some things that might be, you know, centered and maybe you left the center a little bit?

Yeah, I mean, I found the, like, Wi-Fi use case to be so out there. Like, imagine telling Terraform to solve your Wi-Fi coverage problem. you know like that's just that's just not a thing you would ever do right and and you can imagine writing a program for yourself to do it

but like but the person who did that they have a reusable piece of automation they could hand you right now where you could install the extension and run debug my Wi-Fi and it would just do what he did and it would just work

that is that's crazy in the world of automation like this. And then once that's true, like here's another example. It turns out that once you try to make it work as well as it could for agents, the way that we've thought about the language by which you define things is wrong. So here's a good example. Traditional configuration management, right? Puppet, chef. You build like resources that describe the state of a thing you want to have work on a server. So you're like, make sure this package is installed or whatever, right? But it thinks about each of those things as a separate declaration.

And one pattern that exists in Swamp is what we call the factory pattern, where you can define a model that then generates lots of possible things like a factory. And a side effect is if you use my configuration management extension that's on Swamp, which covers what the top 33 most used models are in there, because I have been just running it in a loop of like analyze people's configuration. management and tell me which models are missing. But it lets you do things like say, what are all the packages, what are all the servers with this package installed on them?

And it will just do that for you without having to write any code. It'll just run the model because all the data is already in there and you can just look at it. Do you know what I mean? And then it stores it over time. So you could be like, you could be like, what were all the package, what did the package installation list look like on this server on Tuesday? day. And that's not functionality I had to know in advance. I just built into Swamp that it records the data for longer because agents need it for context. So, so like, like that whole, so the most interesting things you can do are the ones where you smush it together where you're like, you know, I want to use this config management thing, but I need to SSH into a server. So go build me five servers and it'll go bespokely build you some servers and then build its own inventory and then wire that into the SSH model that I built to get you to config management.

and then use John's like VM inventory harvester to tell me what, I don't know. Like those things are wild in the world of automation because typically you've been siloed into like, well, this is my infrastructure automation, and this is my monitoring automation, and this is my deployment automation. And by pulling it down to this primitive architecture,

it turns out all those things are always mush together in workflows in the end. And so that's what Swamp does. So like, I'm really excited to start, building the like the like higher up the stack workflows that are just like look at this source code analyze it i want you to deploy it over here i want it to look like this and then it'll just it'll just do it yeah learn how to deploy on this other cloud because this club upset me because they were down again yeah or one of the people they got bombed adam they got this data center

got bombed they got bombed one of the people who's most excited about swamp works uh does a lot of data sovereignty for sweden absolutely so he's like currently running around going to folks in Sweden being like, this is it. We're going to use this thing to like get sovereignty. Yeah. So I could be able to say, look at this software.

Look at this. You know, pick your stack, whatever. Look at this software and I want to deploy it to render. I want to deploy it to fly or, you know what? I've actually personally,

I don't, I don't deploy to AWS because I'm just not a, that's not where I play. I play in some of the more public clouds. I suppose, the developer-friendly ones, you know? Yeah. Because their docs are kind of terrible and their UI is kind of suck. But if Swamp can diminish all that to a question or look at the code base, deploy to EC2.

I deployed my application to DigitalOcean. I want to move it to metal VMs in Hetzner in Austria. And before you do that, set those VMs up. Yeah. And build, I don't even think you'd have to go that far. I think it would know to do that. It would know. I think it would set it.

I think it would know that it should figure that out. Yeah. Yeah, I suppose. Almost surely. I'd be surprised if it didn't. But yeah, the more, look, the more specific your prompt to the better the outcome. Right. You know, we talk.

And so like we're talking about all the wild things you get from a single line, which is true. But like, yeah, of course, the more specific you are about like, make me a model that does X or a workflow that does Y or, you know, the more you use the language of swamp to describe it, the better the outcomes will be for you. Yeah. Just like they are with software architecture. How do you deal with, I mean, I don't think, I'm going to say this in a way that may sound as a pejorative, but it's not.

How do you go from toy to production? Like, this seems in kind of toy land, how do you make people believe this is production land? Yeah. I mean, the first piece there is there is a set of people for whom swamp will be many steps too far. you know, like if you're in the first category of people who can't talk to the third, you're going to look at Swamp and be like, like, you're just your head will spin around and you'll be like, I don't know, I don't get any of this. If you're in the second or third case, though, where you're building a factory,

like the reverse question is actually more important. How would you possibly operationalize anything else? Like, forget about Swamp. Well, you pretty much render my CLI useless. I mean, I'm going to play with it. It's going to be better. Like, this is already kind of better. And it's going to be the same across like your deployment workflow.

It's going to be the same across your development workflow, how you deploy to production, how you keep things in sync across multiple servers. Like, think about it. The way you used to keep multiple environments in sync was by writing, was by writing code that tried to abstract it all into variables and then use that to push through your Terraform code so that you could run it from multiple environments with modularization. In Swamp, you could just tell it, go look at environment A and B, tell me what's different, and write a workflow to fix them.

Right. Like, which one do you want to maintain? You know, like, which one's crazy? And so, like, the truth is that the operational dynamics of running workflows, that's all you've ever really done. And so how you're going to trust it in production is the workflows are going to work. the data is going to work. It's all very transparent because it turns out agents like it when it's transparent.

They like it when they can pop the hood and see what the details are. So you can pop the hood and you can see what all the details are. There's no secrets here. And then it's going to scale up. And like we got to figure out you can't go from like zero to a thousand overnight. But like we'll continually work to scale it up to be like, okay, now when you're working together with Swamp on Teams, how do we make that better? And how do we make it better when your team is really big?

And how do you, you know, you just keep, you just keep improving. Where are you at right now with this, with that problem, those problems? I would say we're in like, it's like alpha, you know? It's like we're going to do our best to keep it backward compatible and not eat all your data. And, you know, but like, it's an early, it's, it's early day still. Well, I think it's pretty wild to just essentially ask this magic box to just, here's my IP to my prox box. and I mean, I'm kind of flabbergasted about that.

I really am. I mean, of course, my Sitch key got it in, and I gave it my user pass, and that it did that. Yeah, but what's cool about it? Yeah, I mean, that's not a lot of credentials. That's a lot of credentials that give something, but then it just sort of like sleuthed the system.

Yeah, the first thing you did with it was generate new credentials for you so that it was using an API key you could revoke. Is that right? I didn't even notice that. Yeah. Yes. Because that's the right thing to do. And the person who wrote the ProxMox thing was like, oh, don't use my user credentials to do that.

Like, give me a shorter lived credential. Yeah. That's why your token gets revoked. Oh, that's why I was saying that. Yeah. Okay. I'm catching up. I'm catching up because it's going to read.

Yeah, it's going to reuse that authorization token for you. And like, think about that in terms of back to your question of how does this go to production? Like, how doesn't it? like when you compare the transparency of how's it what's it going to do it's like oh man what it's going to do is off to proxmox get a token then use that token compared to well somebody at some point built some stuff in vault then they stored it then i went and set up another system that takes it as an environment variable and get hub actions and you know like break down that whole

fragile ass system or you know ask swamp to write a workflow move on with your life you know where are those tokens stored i and do you you know Bonnie Chan's instead of Prostomax, like where you would like go and provision that so I can go and see like, no, this is the token, no idea. I have no idea.

I've never actually created a token. I've just used my user and pass to get there. I mean, I actually was, uh, you know, my stage key being in place. Yeah,

maybe it uses a long, maybe what it's doing is storing the user token and the user token has an expiry. I don't know. But I think it creates a token for you. That's interesting though. But yeah. And like what Swamp does is encrypt that stuff with a key,

you know, for you. Mm-hmm. And then, yeah. Okay, Adam. Swamp. Super fine. How have you thought about money yet?

Do you care about money? I know you care about money, but like, how is this a business? I mean, considering your history and where you've been and then, you know, the product, product, not market fit, you know, how do you? No, product market for, yeah, lack of product market fit for system initiative. Rest in peace. Yeah. Yeah.

How do you think about money now? Are you thinking about money at all? Are you just like, you know, that's going to get solved? I'm thinking about I'm going to solve this problem and when I solve this problem and you love it if those two things happen then money will happen to

and the software is open source it's a GPLV3'd like you know like I'm going to make money on it and what matters is solving the problem which is how do you build automation at the speed with which you can now build

software and if I solve that problem for you today in the era where we're all figuring out how to build our software factories. You're going to use that. You're going to use Swamp to build that factory. And we are going to have a relationship and that relationship will eventually lead to me getting paid. But step one, you know, in a gold rush sells shovels. Hey, friends. I'm here with Dan Mangus, co-founder and CEO of RWX.

Dan, what makes RWX and the way you're doing CI so different and interesting to our audience? Obviously, we're talking to you because we want to promote what we're doing. We want more engineers to become aware of what we're doing at RWX. But I think the thing that's interesting to me is that RWX is really kind of the first major evolution and CI and the approach for CI. And this is just highly relevant with agentic-driven coding. You know, CI has largely been the same since the advent of the practice. But these platforms were created when being able to run code in the cloud was really valuable.

The fact that you could spin up virtual machines, it would run some automation on a Git push, was really impactful for engineering teams trying to build good developer processes and tools. But that's kind of the extent. What we've done at RWX is we've taken state-of-the-art techniques used in build systems at organizations like Google and meta. Google has their internal build system blaze

and inspired the open source Basel tool. But every engineering team I've talked to that wants to adopt Basel who just found it extraordinarily difficult to use and configure. You have to have a dead source. education team to build and maintain the rules. It's hard to extend it to work with different types of languages and frameworks that engineering teams are looking to adopt.

So it's been too prohibitive to actually adopt those technologies. But the ideas behind Basel are really impactful. They're similar to a lot of the ideas behind Nix. I would say NICS is kind of very similar, you know, in the difficulty to adopt. And effectively what we've done at RWS is we've taken those techniques and we've made it very easy for engineers or agents to actually adopt and utilize those. which namely are the automatic content-based caching and the graph-based task execution,

which means that RWX eliminates all redundancy. Whereas other platforms are having to run the same setup steps, on the same jobs, in every virtual machine that's spinning up, RWX can run the setup once on one machine and then fan out accordingly based on just your dependency graph. So effectively with RWX, you never have to think about parallelization at all. On other platforms, it's always like, well, do I add this onto the existing job?

Do I make a new job for it? But then I have to duplicate all that setup. With RWX, you justify the tasks that you want to run in the dependencies between it. And we will run it with maximum parallelization based on your dependency graph. Well, friends, a good next step is to go to RWX.com. Learn more. Check out CI in a whole new way. Once again, RWX.com.

What part of the life cycle of software gets compressed and collapsed? as a result of Swamp. You're thinking about this more than I am, so I'm just like, I'm curious what you see that. Like, we've got a lot of compression happening and just straight up, you know, gone. It's just not there anymore because AI has compressed so many steps from like, you used to have to do this whole circle. Now you just like, straight to be. I don't know. I think, like, I could just be wrong.

You know what I mean? Like, it's, I think it's one of those questions that, maybe just beyond your ability to see yet. But what will happen is a radical simplification of the stack in general. So today, in order to manage your application in the large or even in the medium, you have to pick a bunch of software whose only real purpose in life is to make it easy for you as a person to relate to it. It's not actually to do the work.

it's an abstraction for you to make it easier for you to understand how to do the thing you want to do. Right. And most of those things might not be necessary anymore. You know? Like if I can just tell Swamp to automate something at random and it will do it, when's the moment where what I want is a much more operationally complex thing in the middle? I believe that one exists, but I don't think it's where it used to be.

You know? I don't think it's like, you know, when do I want to? go, and if you think about this in terms of like the neoclouds, they actually kind of pointed a finger at this, where like those data centers they're building for inference and for LLM use, fast networks, raw compute, fast disks. That's it. Fast compute, fast networks, fast disk. They want as little software as possible in those data centers. They're running almost nothing except operating systems on networks, big flat networks. And if you try to imagine managing that with the old tools, you're like,

but if you imagine managing it with something like Swamp, you're like, yeah, okay, like, sure, give me the raw data about every VM in the data center. It's all I care about. I mean, it's all agents care about, yeah. And every workflow that's running across it. And if I want to rebalance the workflow, just write me a workload. I don't need Kubernetes to go into a controller. I'll just ask Swamp to rebalance the workloads.

And it can go grab all the data. and then do the analysis and then do it. And I don't know that that's what happens. And it's not what I'm trying to do. But like, you know, because like if Kubernetes, I don't care. I build general purpose automation. Do what you like. But like, ultimately, there's something in that like, does this layer exist

because it's good for a person? Or does it exist because we need it? And if it exists solely because it's good for people and not because we need it, I think you're going to see agents collapse it into basically nothing. Yeah, that's hard to hear and fun to hear at the exact. Oh, it hurts my heart.

Oh, it hurts my heart. My whole career building, trying to make that easier for people operationally. It kills me that that's true, but I think it's true. Yeah. And there's plenty of people who disagree with me. There's so many people who disagree with me, man.

Because even, it's like sub-preservation in the way you want to disbelieve, you want to not believe, and you want to fight back because you're like, that cannot be true until you see it be true for you. And then you build things. And then you can't unsee it. You can't imagine building one thing at a time. Now you actually have to be building five different things at once. So back to Swamp.

Do you believe you could be automating six workflows at once with Swamp? I think you do. Because it just wasn't that much cognitive overhead. Yeah. Like you used it for two minutes and like, you know, okay. like once you learned to trust it and you knew, yeah, okay, I know what a workflow and a model is and vaults and I know how that, like, once you trusted the architecture,

you just start letting it rip. And once you start letting it rip, like, you're like, well, I could do that, I could do that, I could do whatever. You know, oh, I need to build a new, I need a new dashboard because my boss asked me one that pulls from a GitHub spreadsheet, cross correlates it with the real inventory in AWS, then, you know, builds me a website.

Fine. You can just tell Swamp to do all that. for you and it would. You know? Fine. It's fine. And it would have a repeatable one and you could just run it over and over again. You know, you could just be like, do it again, boss, you know?

Do it again. You want to see it again? Sure. Here we go. Do it again? Let's do it again. It's fun trick. You know? And like I, the repercussions across the board are just they're so massive. And you know, Swamp is the place where I can be the most effective because it's the

place I understand the best. But the actual repercussions industry-wise, employment, what our jobs look like, what it feels like every day, what we can build, how we build it, what services we use,

like all that stuff is going to change. And I don't know, I don't know how it'll change. I know it will. And, you know, we can prognosticate about how, but the only thing I'm certain of is it's going to change

and change very rapidly in a way that will be excruciatingly uncomfortable while it's happening. Like, so uncomfortable while it's happening. Yeah, that's kind of where we're at. Like, there's a lot of uncomfortability, you know, two Thursdays ago on that last,

but yeah, two days ago we had Black Thursday for Block. You know, it was like 4,000 people let go, blamed on AI, you know? Yeah. Wasn't really AI. Oh, I love that, though. This is great. Did you like that?

Like, all the people reacting to it being like, it wasn't really AI. They just over-hired. And I'm like, okay, man, fine. You realize it doesn't matter. It was both. It can be both. But if it wasn't, but if it wasn't for the AI,

if it wasn't for the fact for what we have just been talking about on this podcast, he wouldn't have had to do it. Even if you believe it was cynical, which I do not. Like if you believe that he was sitting around being like, ha ha, now is finally the time that I can fire everyone to make up for the, you know, my overhiring problems. I don't know why I gave him an accent like that. But like, you know what I mean?

Like it's, but like even if that's what you believe is that he's like a cartoon villain. Like, no, no. He's not a cartoon villain. And like the justification for him. He might be far removed from how he thinks, but he's pretty methodical in how he thinks. Sure.

And like, and what's clear, he's seen what we've seen. He knows what we know. And like, maybe probably more. And so if you know that, like I promise you it's going to be a lot harder to turn that ship with those 4,000 people there than without them.

I still don't know how he turns it with six. You mean like blocks going down turn it? Or do you mean, what are you saying? No, I mean, everyone has to change. We all have to adapt. And, you know, humans are the hardest part of any part of this puzzle. It's never the technology.

It's always people. And so, and it's hard to move that many people. Some people don't want to move. Some people don't believe you. Some people, they're mad because that's not their job or they got a better performance review last quarter. Or like, there's a million people reasons why I don't like it. So, like, even if you take the cynical side, it was still AI that did that. And when you look at the people who have to think about what I have to do for my business in order to navigate a change of this magnitude, which we have never seen, there's never been a change of this magnitude in our industry.

It was always slower. Everyone I've lived through was slower by a huge pace. The cloud is nothing compared to what's we're doing right now. What's about to happen? Nothing. So like, the idea that it's not because of AI, it's because of AI. And like, yes, maybe they also overhired. And like, it is absolutely because of AI.

Because the changes in those systems and the changes in how we work, like there's no difference between four people and 10,000. And, you know, hopefully you're going to leave here having played with Swamp and you're going to be like, who, I got to play with Swamp some more. And it's going to continue to change your mind about what's possible in that layer of the stack. And once that happens, suddenly you're going to start to empathize with Jack. You're going to be like, oh, no. What do I do? And, you know, like, I wind up on the optimistic end of that circle, which is that once we figure it out, what we're going to learn is you still need a bunch of people who know.

how to build software. You need people who know how to do engineering. You need people who understand how distributed systems function. You need people who know just a different way. Express, but they have to do it differently. And that learning process of figuring out how to do it differently, some people will will thrive in that change. And some people won't. And if you don't, then you might still have a job, but it'll be after the dust settles. It'll be after, you know, it might be years before those skills become easily retransferable. Because you'll have to like get all the way through the denial and all the way through the suffering. And then, and then the rest of the industry has to do the work to be able to communicate it clearly,

which we cannot do right now. And and and and, you know, anyone who will listen to me, I'm like the Pied Piper over here just being like, you got, you have to change now. Because, yeah, it's going to be, it's going to be, it's going to be rough. And it's going to get rougher. Play your flute, man. Say it. Say what you want to say. right now. What's the drop dead way you can say what you want to say? Yeah, I think every single engineer, yeah, every engineer and software

developer who wants to feel better about what's about to happen, the only way to do it is to start building software in this new way. And you probably can't do that at your job. Like, you probably have to start doing it on your own time because your jobs are all too slow. They're all too concerned.

by nature, they should be, right? Like, it'd be, like, there's this would all, doing this wrong would also break, you know, if you work at a bank, like, you might have a minute, but not too long, you know? And, yeah, I think you got to start playing with these tools. You've got to start figuring out how to build systems that write the software that writes the software. You got to start thinking about how the world's going to look in this new age. And you got to start rewiring your brain.

And, you know, especially if you were a software developer who, You know, be honest with yourself. If you're the kind that attacked code from the bottom up, you know, you looked at the source code, you read it, you beat on it, you hacked on it. You were, you know, you were a high velocity software developer, but not a good architect. You've got to slow down and become a good architect because that way of learning is now a dead end. And that's a real bummer. You know, that's like a hard, that's a hard road to hoe. But I, you know, I would say that's well of the majority of all software engineers ever were that.

were roughly that person or learned roughly that way. And they all have to change. Your marching orders is for every developer to reorient themselves around agentic building. That's no other way around it. Yeah, you don't have a choice. The only choice is whether you're going to do it now or you're going to do it later. And if in the middle is a bloodbath, yeah?

Because the impacts on business and industry and valuations and monetization and revenue and on and on and on are all very, very difficult. then you want to be on the, you want to do everything in your power to be the one that when people look around and go, who is, who are we going to trust to build this new world? You want to be the one who's raising your hand

being like, I know what to do. You know, I have already, you know, I already, I already know what this looks like. You do not want to be the person that's like, what? No,

that's silly. You couldn't possibly move that fast in our industry, you know, that you not want to be on that. side of that puzzle. And like, you know, it's a bummer because everything we knew about about how to work in this way and how to relate to each other in this way and how to judge each other in terms of our career arcs and capacity, it's all out the window. And that is just such a bitter pill. You know, that's such a hard thing to swallow. But you just got to swallow it. Like you just got to

get past that as quickly as possible and get down to the brass tax truth, which is it's better. to build software this way. It's like more fun. It's orders of magnitude faster. The things you can build are absolutely wild. To not be building them is just an absolute sadness. Like it also sucks that this thing that we love to do, that we had built all this expertise around and had learned to love in a particular shape is no longer the way that we're going to do that moving forward outside of small isolated pockets. And yeah, my my truth is you got to get over it. like you just got to you got to feel your feelings cry about it complain to your spouse you know Adam's got to be like babe

babe I think software development's dead you know she knows I mean I mean you just she's she's well aware of of you just got to do it and I've been telling you know I don't think software development is dead like I know this sounds harsh but like I really don't I really think what's going to happen is we're going to need more software developers we need more engineers not less but it's definitely not dead it's just changingly different dead, like some parts of it are dead or dying.

And that's what happens with a tree when it grows, right? When a tree grows, you have to chop off limbs to enable new growth or new direction. And in between, there's going to be this trough where we have to learn how to do it. And if you, and the best way to survive that trough is to be one of the people who learns how to do it first. Absolutely. And, you know, you don't want to be last. You don't want to be the last one who learns how to do this. You know?

Yeah. No safety there. Yeah, for sure. Oh, okay. That makes some clear sense then. Don't sleep on this. Obviously, go do that. In the meantime, let's say for those who are like, you know what, Adam, I'm drinking the Kool-Aid, man.

Listen, I got it by the gallons and I am, I'm peeing every two seconds. That's how much I'm drinking. Kind of thing. Like, what do they do? I mean, they may already know. No, but like, even when you've built here and the level of automation, because like, you've got software that can move so fast. Now, if Swamp keeps going the right way, you can automate so much. Yeah, you'll use Swamp to build the automation that runs those software factories.

You'll, you know, in terms of career arc, so you should do that self-servingly. Like, you should give Swamp a try and help us build it because it's the thing that's going to unlock that for you. I think another, the other is most of us scoffed at software architecture. You know, we just didn't actually, we didn't learn software architecture. We learned how to be software developers and then we became engineers. And we sort of learned it through attrition. And you got to go back and learn that as a discipline that you can use to communicate clearly. So, you know.

You have recommendations at books, talks. Yeah, I would domain driven design. He's getting books. See, you can smell that you won't like it. Like, here's a textbook. This one's implementing domain-driven design by Von Vernon. This one is domain-driven design by Eric Evans. These are both, they're heavy books, you know?

They're like filled with vocabulary and complexity and diagrams and stuff that you don't want to, you know, diagrams you don't want to read. And now you have to. Read those two books for sure. Yeah. And if it's not domain-driven design, you could probably pick another architecture style that you understand or know, but you better know because it's sort of now critical to expressing how software will work in the future is being able to both express, use this architecture philosophy to the LLM so that the code that it generates is code you can understand from an architectural, structural point of view. and so that you can say to it, make a change that looks like this because of this architecture change, this architecture principle, being able to express that transition as a thing that software architects can do that most software engineers cannot, right? And that's why it's a job still.

When you go to a bank and someone's a software architect, they can describe how the bank systems connect together, and then they can also tell you how they would transition to change from one shape to another in a way that a software developer cannot do, you know? And you got to be able to do that now. And we always made fun of those guys because they were all pedantic and annoying and were the ones who wrote the software. But it turns out they were right all along. We just needed an all of them to do it for you. So that would be, that'd be one.

And then the other is, is the answer to most of your problems, the first answer to the problems you encounter should be, can I use more agents to solve this problem? So, you know, anywhere where you're tempted to have the answer be, this is where the agent part ends, you, that's probably wrong. You know? Like, I was pretty sure that it was, that humans owned planning until we started adding more adversaries into the system. And now it turns out that if I have a good enough adversary that understands my architecture stance, then I can be pretty bad.

I can be pretty sloppy at the plan inputs. And it will turn it into reasonable design because it understands how to argue with itself to get the architecture that I asked it to express. you know, more LL-L-L-S. Is some of that stuff secret sauce, or how do you categorize these adversaries and what you've learned about, architecting the adversaries? All that stuff's going to be secret sauce for a while, you know, because we're trying to figure out how to do it. I don't think I'm the only one using those techniques. But, like, you know, I don't know how those things will show up over time.

I really don't. They will. But, yeah, right now they're just part of how we build swamp. So you can't really see them if you're not building the swamp, you know? on the inside, yeah. Yeah. Open to contributions or just open source? Open source, but only open to contributions in the shape of you can file issues or bugs.

But no one who doesn't, no one can ever accept contributions ever again if they're going to work at this rate of speed and they want to maintain supply chain security. your agent can write code at a rate that no human can review and I can't trust that every agent will catch the security problems that you inject. And so the only answer is I have to tightly control the inputs to the agents in the first place. So no, you will never, and Swamp will never accept a pull request from anyone ever. What you can do is send me an issue. You can say, hey, I need this feature.

And then what I will do is read what you asked me to do and be like, did you ask me to mine Bitcoin for you? You know, did you ask me to do some nefarious stuff? Because I can do, I can rock that at the level of us, you telling me what you want. I can, I can understand if that's nefarious. But I can't understand it at the level of you sent me a 5,000 line pull request. Did I make sure that you didn't send all the data to someone I didn't want you to send it to? So, yeah, it's open source, but it's not open for contributions at all. It's completely closed.

and the way you contribute is you file an issue. And when we get around, when we then work that issue with our agents, when we commit the code, I put you on as a co-author. Nice. But I don't accept your, I will never accept a line of code from anyone ever. That's dead for you. Is it dead for others? Should it be dead for others? Yeah, it will have to be dead.

Not yet. But yes, it's, it's going to have to be true for everyone. And I think we should have a long conversation. I don't know yet. I want to very much have the conversation about like what that means for open source. I believe that my hope is that what it means is there's more free software in the world actually because agents need it. And then our values, which often get dropped from the conversation around open source,

that we can talk about what our shared values are together. And we can figure out how to keep those values in through this transition. because I think they're more important now than they were before. I don't know exactly how that looks, you know? I don't know exactly how those values get reframed, but it feels like they need to be, and like it's time to do that. That's one of the reasons Swamp is AGPL'd,

because I think the future actually has more free software in it, not less, because of agents, and the need to both build derivatives and have that code be open so that your agent can learn from it so that you can solve your problems so that it can enjoy, gender human freedom in the way that free software wants you to do. But I don't know how that ends yet.

And I haven't really gotten all the way to a manifesto or whatever. But what is very clear to me is that the middle ground is death. So like, you know, just being like I take pull requests and it's okay if you use an LLM to shoot 5,000 lines of code at me at random. Like that's just like being stuck in high surf, you know? Like it's if you survive, it's unpleasant at best, you know? And once you realize that the software factories of the future, the software writes itself, you know, like humans are guiding it. But ultimately, the software is being written by the software that writes the software and not by you.

Then the only boundary of trust I have is the inputs of a human being at the very top of the funnel. And that's just how it is. Yeah. Do you mind going one layer deeper? Do you have enough time for one layer deeper? Are we getting close on time? Yeah, man, we can go one layer deeper. The layer I want to go deeper is maybe,

and maybe it's not, maybe it's just sort of backtracking in a way, but you mentioned the friend with 100 to 1,000 engineers. And I just think like, if that's the truth, which I'm feeling that truth as well, but I'm a team of one. So my feedback loop is very tight because I'm a singular individual.

Yeah, yeah, yeah. And the way I coordinate and talk to the world is through podcasting and other means. Yeah. So in this moment, I'm having some realizations that are already true in me, but becoming more true because they're verbalized. And also, you concur, even though you're not trying to concur. Is this, is that I think, like, small teams. Like, I just wonder how is, how do you even have more than four or five?

Like, I can't, it's hard for me to even think about building software with more than one person. I, that's true today. I just, I bring it back to, I don't know what the software looks like that you can build with this capability. So like right now, what we're learning is that you can write software using this capability. Great. What happens when the software, when I can write software using this capability that could then write software at an even greater rate of speed collaboratively? Nobody knows, but our ability to find out is so high that I have no doubt that we will. Does that make sense?

Like just the sheer number of shots on goals and the sheer amount of possibility, like, you know, when do you, how many software developers will you need? I don't know. But if software can happen at this rate, we already saw this in the world where because software was more fungible

than the real world, we moved as much as possible into software and out of hardware because software is so much easier to change. But now I can change software to custom fit at will, you know? You wrote a proxmox workflow while we were chatting, you know? And it like would have cut that from whole cloth for you. So what does that mean for how much software needs to be created and how it will get built? You know, how many people

can work on one problem at once? I don't know. But my guess is that they're going to want more software. I don't think it leads to less software. You know, I think it leads to more software, because software becomes even more valuable and even more mutable in this world than it was before, which means the people that you need in order to keep up with that, you still need people who can understand it and put it together and do those things. Will we get to some moment where you don't need people anymore? I don't know. Not with this, not that I've seen so far.

But that doesn't mean, I don't know. I don't mean no people. I just mean less. So I juxtapose 100 engineering team to 1,000. down to four or five or ten like what I think on on on a current the hardest thing here is just dealing with the existence of your current software which was almost surely built wrong for this era you know like like like swamp if you look at its source code it's very architecturally driven it's very like it looks like it was architected by somebody who was trying to do domain driven design. Your code base does not look like that, even if you had someone that was trying to do domain-driven design. Because it's annoying to write code that works in that way. It just sucks to do.

And so you don't. And so your actual code base is this mismash of different people's taste and styles, and it evolved over time. And it's this like Rube Goldberg thing. And so trying to bring this tooling into that code base, what is the architecture? That every pattern under the sun probably exists in a large. codebase, all of them. Which one should it choose? How does it know? How would you guide it? How would the people who have to work on it agree? Like, I do not know. And so, will you be able to get this level of velocity on code bases that already exist? I don't know. I really don't. Maybe.

I know you can get it on ones that didn't. I know that if you start from scratch this way, it totally works. And if I know the specification of what it is that you do, I could just do it. So if I wanted to rebuild GitHub this way, I could. And the only thing between me and doing it is tokens. You know what I mean? And then I would have a machine that builds GitHub,

and then I would be able to out innovate GitHub on GitHub. Because catching up would be pretty fast, right? And yes, data gravity. Yes, domain expertise. But like how many of us are domain experts with GitHub? More than a few. More than a few. Or at least expert enough that they could get you the core of the loop. And GitLab had to hire a lot of software development. So I don't know. My guess is that it expands because I don't think we're just going to use it to rewrite GitHub. I think we're going to use it to transcend those things.

And I don't know what that looks like yet, and I don't know what it means to have a lot of people working on them. But what kind of software systems are possible now that if you had a thousand engineers working on that software factory, what would that software factory be capable of? I don't know. But I bet it's crazy. You know? Yeah.

Yeah. That's kind of where I've been camped out. That's why I take the positive case. Well, you have to. You have to be on the positive side. I do agree with you on more software. I think that software gets more and better. I do think that everyone needs to have a reckoning with themselves. That's going to go like this. You know? And in this, we're like here and the roller coaster ends like somewhere down there. And then, you know. Below the screen even. Yeah. Uh-huh. It's going to be bad, bad in the middle. And I don't know. I wish it wasn't. Like I wish I knew how to. avoid that. You got predictions on bad bad, bad? I mean, what is bad bad bad? When you say bad bad bad, what is bad bad, Adam?

I mean, whatever, 4,000 people getting laid off from Block, that's bad. That is bad. I mean, that's like one of the biggest layouts we've had in Silicon Valley, if not the biggest, right? Like, one of the biggest. I think about the transition out of the first era of the web and the dot-com explosion. and you know I worked for a company that had a market cap bigger than Microsoft that that didn't have a product you could explain and we laid off thousands I laid off thousands of people and like I was the operational end of their layoffs but I was in the room you know and like those was awful this is going to be like that only worse because the institutions that are doing it remain it's not like you know in that story, like those layoffs happened because what was happening was the company I worked for was a sham. And so when you got laid off from the company you worked for that was a sham,

you were like, well, you know, say la vie. That was weird, you know, but you like went on with your life. But like when you get laid off from Block and Block keeps blocking, and not only do they keep going, they accelerate, how's that going to make you feel up? Same day. Yeah. Yeah. How's that going to make you feel. And then how is an industry do we reckon with the fact that we need those people? Like, we're going to need them. But right now, we don't know what to do with them. Because there's this big transition that has to happen. So yeah, I don't know, I don't have a prediction deeper than fear, really. That's like, okay, like, it's going to, I feel like it could be, it's going to get heavy because once, like, if we can see it on this podcast and I can experience it

as directly as I have, and you did just a minute ago when you used swamp, the barrier to understanding it is dropping quickly. And that means that at the level of an executive or a business person, being late to the correction is terrible. So, you know, it's better to be early to the correction. It's better to cut once, not twice, you know? Like all that stuff's just true. And it's not true because they're mean. It's true because it's true because it's actually good for business. It's not good for people. It's good for business.

It makes me sound like an asshole. But like, you know what I mean? Like it's, they do that because it works. Not because they don't, you know? And not because it doesn't. And yeah, I just, that's why the advice I give to everyone is the advice that I gave earlier. Like you just, you got to figure out how to be on the right side of it. So when people are looking around and going, who are the ones who are going to most

help us make this transition, you got to be the indispensable one in making that transition. You got to be the one that's most stoked to make that leap and build that new machine. And like, it's going to feel bad because you're going to have peers. I have peers, friends, people have known for a long time who like are, I think, a little disgusted with me. You know, like, I think they're a little. Because what you built? No, because I'm because of what I'm saying. Oh, yeah.

Well, because they disagree. But yes, okay. You know? So my thought there is, and maybe this is not exactly, it is to go away from the Silicon Valley world of building software, go out further into the field, so to speak. Yeah. And build software for folks who didn't typically have someone building software for them

because they're using a SaaS or they're using, and I'm not saying to kill a bunch of SaaS out there, but there's a lot of businesses built on the backs of several SaaS that are essentially rent for a database route. and very simple when you can actually potentially gain some equity in that company and build some cool custom-grown software that's built for them and aligns their brand and their interest. I think all that's going to be real.

It is real. That's the stuff that gives me hope across the horn for that. It's also the thing that makes me think that it's going to get bad first because to get to that part of the story, everyone involved has to know how to do the work. they have to know how to get those outcomes to be good. Like all the unknowns that are happening right now on the frontier, all those things need to not be frontier for that story to be true.

And so we've seen the frontier. We know it's a tsunami. The tsunami itself is a tsunami of productivity that could very well create a biblical flood. What happens when the floodwaters recede, which they will do? I don't know. because I don't know how high the water line's going to go. But if you made me, but if you pushed me to the wall and you were like,

you have to say, I would just say higher than you want it to. Yeah. Over your head for sure. Not just you, over everyone's head. You know, over the head of everyone who works in software.

For sure. That feels obvious at this point. How far and how quickly, I don't know. know. I don't know. Far. Fast. Far fast. And then, you know, but like, is it survivable? Yeah. Yeah. Yeah. Yes. Can you thrive? Absolutely. You know, like the opportunities for thriving. You know, like a giant biblical wipeout actually, you know, once the flood's over. Like, lots of opportunity, you know? Yeah. Got a whole world to rebuild. Like so fun and interesting.

interesting. And like, you know, in the middle, in the middle it's going to be rough, you know, for software people. Yeah, I feel like now's more important to like understand the full stack. And I don't mean like full stack front end, but I mean like build something from zero idea to actually deploy it, maybe even with swamp. Yeah, definitely with swamp. Definitely with swamp. But see that full story arc from, no idea to an idea from literally zero and beyond one. Yeah. Yeah. Because if you didn't do that before, understanding the full arc, like I was talking somebody recently, and I'm like, I don't understand a developer in these days that doesn't have prox, moks, or a home lab, or Incas, or a, you know, a slew of VMs in their

home network and they're not playing with something. I can't understand that person for the reasons why you said what you said. I didn't articulate it the same way you did, but that's the reason I feel that is because I agree with and think what you're seeing is true. Yeah. And I already feel that in my bones. I just didn't articulate it the same way you did

because you have to reinvest in the way you're building software in a way that you've never done before because we're literally reinventing the operating system for which we've built software on as we speak. We're inventing everything. Everything's on the table. And the upside. with that. So like the closest to this that I have lived through was the era and I didn't know because

I was too young to know that this was happening but like, you know, the era that we got everybody on the internet went from nobody on the internet to everybody on the internet in what, eight years. From like zero to or almost zero to everyone was like an eight year span, six year span, something like that. And one thing that was true is if you knew how to use a modem at the beginning of that curve, like if you knew how to set up a bulletin board, at the beginning of that curve, your career was set for the rest of your life. That's true for every single person I know. I don't know a single person who ran a bulletin board back then, who didn't wind up with a job building the internet that then has been their career pretty much for the rest of their lives. And, you know, this is the same.

Are you going to figure it out and be on that early edge of being the person who, when everybody's looking around going, who's going to build me my software factory and how do I build a system that builds a system? Like, it's even more out of reach now than it was before. People keep talking about how, like, how it's going to lower the barrier and, you know, people will build software and like, no, they won't. No, they won't. Not, not yet.

Not in the, not when it's hard. Not without learning some software, engineering, some architecture. So they're going to look around and wonder who those people are. And if you're there, like, there's work. Yeah. You know? Yeah. One shotting something is, is, I mean, you can do it.

Well, but it's like my, but not really. One of a friend of mine who does, who does PR has been building software to help with that. And it's been very cool. And he doesn't know what to do. He doesn't know why the thing starts to suck. He just knows it's not good. And so he just keeps telling the LLM to make it better. Like, make this part not be so sucky.

and it doesn't know how to do that. You know what I mean? Because he can't express how the software is wrong. And he can't express what the transition would be to go from the wrong software that does the sucky thing to the right shape of software that does the right thing. And, you know, he was never able to express it as code, but he definitely can't express it by just shouting at the LLM

that the thing is wrong. Do you know what I mean? That it made an error. Yeah. And he's got to say, gotten further, you know, he has like a working program that does what he wants it to do, which is amazing. But he's not going to get to the end in a way that's satisfying until he hires a software developer

to figure out how to look at the architecture of this terrible thing that he's wrought and build it with a little bit of craft and care. And like, that's the future of our engine, of our people. And our people, you know, that's how they're going to go. But in between, there's going to be a lot of people that like fold their arms and are like, you know, those people are going to lose their jobs, you know? Yeah. And that's a real bummer because they're good people who I like, and I wish they didn't, you know?

I like your leaderboard Adam. You're not at the top. I'm not. That's kind of cool in a way. Number seven, if you're Adam on there. I assume you're Adam on there. Why would you not be Adam on there? The only special thing I get is that you should sign up right now.

Dude, I'm going to hit this leaderboard. Trust me. You're going to start seeing Adam's neck on this leaderboard soon, okay? Yeah. If you don't think so, then we'll, I mean, I got to beat 14 people to get there. It's pretty going to be pretty easy, okay? I mean, a lot of those people have, a lot of those people have no points. So.

Yeah. I'm going to be up there with you all here shortly because I'm already, I've already got ideas from my little fun here on the pod. Yeah. And I can't believe you've built what you built. I'm so proud of you. Hey, thanks. For, you know, getting through the lull, man. You know, it's, it, uh, we didn't talk about the sadness and we don't have to

of not achieving the, the mountaintop. But sometimes, yeah. That could have been the price necessary to pay to get to, to swamp. Yeah. You have to recognize that the, um, like, in those decisions, I'm always the one with the most privilege and the least risk. So like, I have like emotional. risk and a lot of those things. But like there's people who I really, who I'd loved who I'd worked

with for a long time, who I just, I couldn't keep working with, even though I loved them and wanted to work with them. And because I just, I couldn't lead them to a product that worked. And that, it's worse for them than it is for me. Do you know what I mean? Whatever emotional tax I have to pay to deal with the fact that I couldn't lead them to that place. Like, it's not as bad as not having your job anymore, you know, at this moment in history. And so like, I really, yeah, it was, that was sad and hard and I don't recommend it. And also I would rather, I want to go, you know, if I need to do that, I want to go through it as the most in the best way possible. I want to take care of those people and the best way I can take care of them. I want to, you know, which I feel like we did. I hope they feel

that way. And if they don't, that's fine too. I'm sorry. I shouldn't say that even because whatever. It's complicated. But, yeah, you know. I understand your perspective. You have good intentions. You have goodwill for folks. And sometimes it doesn't translate to that. Yeah. And as much as, and like, you know, Swamp, though, you know, turned out, we learned a lot. And that led us to be able to build Swamp and watching Swamp do what Swamp does. Like, I believe in the future of, like, Swamp is the future of how you're going to write that automation.

And it is early. But it's early and right. It's not early and wrong. You know what I mean? And you can tell the difference. I've got a project that I'm working on right now. that needs automation, and I was actually having a conversation with, obviously, my LLM about, you know, to what level we could go and how we could architect it. And I can already see how this changes the entire game for what I was trying to do.

And that's kind of interesting now, because if Swamp is a critical component to this thing I build, well, there you go. There's the, there's the toll book for you. That's what I'm saying. I just need to sell you shovels. I'm going to help you build the thing you want to build. I'm going to be fair and kind. And, you know, like, there's plenty of business to go around if I solve those problems, which is what I'm going to do.

So, yeah, I'm just going to focus on solving that problem for people. And then, you know, come hang out in Discord and tell me where it needs to improve. And then watch what happened, watch the speed with which we will implement your feature suggestions. It's sick. It's sick. You'll show up. You'll be like, you'll be like, I need X. We'll be like, X looks good.

then I'll post a plan. You can go read. Then I'll implement it and close the PR. We've done in a couple minutes. Wow. Yeah. Because the magic software factory takes care of it, you know? The magic software factor.

You've heard of here first. Swamp.com. If you're not there and you haven't curled swamp onto your system and did what we did here on the pod. Well, you're not a friend of Adams. You're not a friend of mine. I'm just kidding. You're friends.

Get to it. What are you waiting for? Swamp that club. I'm telling you, this is insane. This is insane. It's all I'm saying. Adam, love you to pieces, man. You're my favorite, man.

It's good to see you again. It's good to see you. So much fun to pod with you. And I'm thankful for you, man. Always. I'm thankful for you too. Thanks, friend. Peace.

All right, friends, this show's done. Thank you for tuning in. Adam Jacob is one of my dear friends. One of my favorite human beings here on planet Earth. It's kind of wild because I don't think we've actually met in person. What a strange world. But Adam took us deep into the crypt, the secrets, the deep mind he has around the change we're all experiencing with AI taking over our entire stack and totally disrupting things. I don't know about you all, but I am building software to build software.

Gosh, it is so cool what we can do right now. I can't believe it. I really can't believe it, y'all. Hope you enjoy this show with Adam Jacob. I know I did. Check out Swamp if you haven't yet. Swamp. dot club, the coolest thing ever.

And look at their repo. Lots of cool stuff they're doing in their codebase that you can learn from. I know I'm peeking at it. All right, this show's done. Thank you again for tuning in. We will see you so soon.