# AI Maximalism: Rebuilding Software Factories with Swamp

**Podcast:** The Changelog: Software Development, Open Source
**Published:** 2026-05-13

## Transcript

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 I.
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.
Nicky, what is a 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 DevRel for the C-suite.
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 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 Shai Halud, you know, that virus that went out not long ago.
This was a compromise of the NPM public repositories.
They went and downloaded things.
NPM 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 know it's not disingenuous.
We're just talking like friends do before the record button gets pressed.
But I really didn't.
It doesn't feel disingenuous at all.
Well, thank you.
We're actual friends.
I know we are, man.
I really, I was actually thinking about this because we kind of crossed paths unexpectedly when you were keynoting, I believe, OSCON.
And as part of our relationship with OSCON, which is defunct.
Because OzCon's defunct.
That's right.
One of the things they had us do is 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.
It's so wild.
Yeah, and 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, 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, the, but the other side is you don't know where, where those people will reemerge.
or, or how your paths will cross in the future.
And, 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, and now you're, 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, you know, 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, when folks show up back in my life that either I 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, it's 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.
But totally cooler than that guy, hopefully.
Definitely, definitely cooler.
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 know the last time we talked about AI and 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.
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'm, I'll get just like times and dates and.
You know, like, like I double checked my daughter's birthday, even though I know her birthday, you know, just cause 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, 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 on small teams, you know, everybody who is 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, to create software and to get better and to like move the industry forward in a, 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 gerbs 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.
Um, I think it's, I think the repercussions are terrifying and wild and, uh, And I like talk about them to anyone who listened to me like all the time, partly because I'm trying to like process my own feelings.
A little.
Yeah.
You know, cause I'm like, like, I don't know if you know what's happening, but like, Oh no, you know, like it's going to, it's going to 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 dum-dum.
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 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.
I'm using Cloud Code or whatever, 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.
dumbed up.
You know, you're like, and they're not, they're, 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 it, I think it probably goes a little both ways that it's just like, Oh no, 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 imagined 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 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 an 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.
And I'm trying to say like the abstraction now is is both understanding.
AI, understanding how to use the tooling around it, building the machine that builds the machine.
And like you said, some of those problems are largely personal and hard.
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 what the right best thing is.
We kind of have to figure it out together.
So it's a little early to be like, oh, I'm building the AI development loop.
GitHub replacement.
I think there's going to be one, but I don't think we know what that is yet.
And so I think you just got to run it.
We've 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, it'll still be a slow burn.
Because you still have the non-Maximus, those folks who are just like, you know what?
I'll let AI write some of my code.
Yeah, yeah, yeah.
I have no idea how I talked to my friends who run 100, 200, 1,000 software developer organizations.
I got nothing.
When we talked to what should they do and how are they going to move through this, I'm like, I don't know.
Because I don't know how you...
I have a system initiative.
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 we went from...
from, you know, 18 to five.
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 in, 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 we're coming up with to solve problems that would have been, you know, our ability to like 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's risky.
Like 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, Swamp's 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, like, like if, if I had a hard, what's a, what's a hard day at work look like when what 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, I, because I had this accumulation of days and experience and 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, you know, 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 like dramatic change in 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 schmucks before they were incredible software developers.
You know, it's, it's just because we built the machine to build the machine.
Uh, 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 up cloud code and it does some stuff for me.
And it's like, yeah, yeah, we're not the same.
No, like we're not doing the same thing at all.
And.
Yes, there's clogged code involved, but that's about where the comparison ends.
Anyway, it's wild.
And 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, 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 law?
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 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, what would happen 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, right?
We're seeing that with like code review, code quality.
Like those are the main gates.
Getting whatever it is to production faster.
Well, now the gate is production and observability.
All those things are just blowing apart at the seams.
That's filling all the pressure.
Right.
Those are the corner pipes in our house, so to speak.
Yeah, 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.
The entire industry is wrong.
A GUI, right?
It just didn't matter what we assumed.
It doesn't matter.
The odds that whatever problem you were solving.
Well, I mean, some of the APs 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, 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 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.
I mean, and, 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.
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 a pin in, and I hate that phrase.
I don't put pin in things technically.
It's okay.
I rambled because 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 bar.
Put it all out there.
Yeah.
So you can't advise your friend with a hundred to a thousand engineers, because obvious, but you can't advise on four to 10 because now you're five.
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 it?
Because it probably changes tomorrow to be an AI maximalist team.
What is that?
Yeah, so the first thing you can't do is ask anyone to block on anyone else.
So like autonomous.
Yeah.
They kind of have to be because the rate at which they can work is so high that if they have to, if they have to slow down to check in, then actually it feels terrible.
So no standups, obviously you can, I mean, you do in the morning you, 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 early users of Swamp that are posting features or issues.
And so 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 score.
It gets 100% SEO and 100% usability, like accessibility.
Congratulations.
That's amazing.
Don't congratulate me.
I installed a skill.
You're the owner.
I mean, 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've talked about that.
So like.
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.
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 to the planning phase.
You gotta wait on everything to do its thing, yeah.
Yeah, so you're usually spinning more of those plates at once.
Two to three, maybe five.
Yeah, five feels like a lot to me still, but Paul Stack, who works for me, routinely has five.
I've had like six or seven at once, and it's until you get into a good stream.
It's not like prompt and pray.
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 old me.
If it's hard, I just got to focus.
I'm still thinking about repercussions.
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.
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 pull 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 architecture.
Do those agents have Do they have accounts on GitHub?
Nah, they're just running out of CI.
They're just running out of actions.
Gotcha.
Actions.
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.
Um, 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 page 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, um, your 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 like break, you know, authentication or login or, you know, when a feature is stable and there's some rules for that.
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 back to the top and then you stop shipping to production.
So nothing ships until the UAT tests pass again.
And then, you know, once the UAT tests pass again, then it comes back and you're shipping to production again.
And I think we've shipped I don't know.
I bet we've shipped Swamp 900 times more in four weeks.
How fast is that loop then from implementation plan on through UAT and passing a failing?
Pretty fast.
Same day, same hour in some cases?
Yeah, same minutes.
Same minutes?
Really, in minutes.
Minutes, yeah.
Is that individually?
Like you, Adam, and then someone else would have their same flow into UAT from implementation to UAT?
Yeah, yeah, yeah.
So it's an individual exploration 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 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.
I shipped software then.
Okay, UAT.
Or did you have to 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 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 change the shape of the test so that the failing condition is now correct.
And they do that all the time.
I'm going to have 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.
I don't understand the code anyway 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 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 would 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 do the recalls, man.
Yeah, you weren't getting any software updates.
You weren't getting over the air patches, you know?
And so like, 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.
More agents is 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, you know, 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 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?
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.
It 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, spec-driven design, which I think is like a glorified prompt.
I'm talking about like true specs, like an RFC 2.1.1.9 compliant type of true spec.
I'm writing design documents, sometimes design documents, but they don't live forever, and I'm definitely not writing pure specs.
Okay.
Well, you're not, though.
You're not using them at all?
The agent's not really either.
No?
Nah.
I mean, the plan, that 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 the price.
Yeah, I'm not even talking about that either.
More so that whenever it has to go off track or it has to do code review, it knows.
In my particular case, I've written this this DNS server called DNS Hole.
And a lot of it's over my head in some cases, but some of it's right in my wheelhouse.
But it literally has to adhere to RFCs that are internet.
I would feed it that all day.
Right.
All day.
In those cases, for sure.
But what about even authentication?
We want to authenticate a certain way.
Would you not?
Would you not specify 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 to be a strict follower of that model.
So whatever they say, that's what I want.
So wherever 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 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.
But software developers wouldn't have talked about it that way historically.
Historically, you'd have just done it.
You'd have been like, oh, I'm going to refactor to blah, 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, 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.
I can read your homepage.
I can do all that.
And I have.
Have I done the curl install?
No, I have not, Adam.
I wasn't sure if I should do it on my machine or not.
I was kind of scared.
We used to be friends.
We came into this show, pals.
Let's do parentheses yet.
You broke my heart, Adam.
You 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 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-committance increases in the velocity of operations always.
So there's never been an increase in software development velocity that wasn't also accompanied by an 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.
And it was already slow compared to, it was already slow.
It was already versus hair in a way.
Ah, it was already triple hair, 10 X hair.
Yeah.
If you got everything just so you could do it, but if it, but you mess one thing up and you were cooked, you know?
So.
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 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 visual composing composition problem.
And it just was too weird.
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 whatever.
It's just too far left center.
Yeah.
I feel that on some things.
Like you can just have the most next revolutionary thing.
It can be the most amazing thing, but it's just like, it's just too different.
It just wasn't quite where I'm at.
It just wasn't right.
And, 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 rate.
And 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 reusable 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 one of the first things we did was one of the people on the team, Mixed Eye Mates, 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 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 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 results.
And it just wrote itself.
Like the automation just did what it needed to do.
Because you kind of gave it tools, right?
You're giving it certain tools that can write and do different things.
I'm giving it building blocks.
You know?
Here's the model.
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 rebuilt configuration management inside of Swamp.
So it does like...
you know, SSH-based operating system configuration management.
And it has a bunch of, you know, idempotent, 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, 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.
Gosh.
It's so fun.
It is so fun.
And then it writes itself.
And then it writes itself.
And there's like a lead, like, you know, we have leaderboards.
You get for what?
Special points.
As you use Swamp.
It keeps track of your utilization and it gives you points and then we reward you with levels, you know, like tiers.
Get out of here.
When you start, you're a swamp baby.
But, you know, you might get to Merc 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 a harness?
Would you say that what you've built is a harness?
This word gets thrown out 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, this 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 a speed, 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, you know?
Like, 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 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, it will write itself to turn itself into reusable automation that your team can use.
And then it will 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 do 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.
So it would build an extension.
It would be like, it would be called of Swamp.
We would call it Atom slash Proxmox.
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 Claude, 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 in 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 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 um that would say well i want to create that vm and then once it's up i want to use adam's 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 exist, or it would write net new ones, and it would finish that workflow.
It's kind of hard to even imagine that world, really.
Yeah.
Because you don't have to wait for Proxmox to finish their API better.
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've tried to automate Proxmox quite a bit.
Hit some issues with CloudInit and some other issues with other things.
And so I've got a seemingly, considering what you've done, a pretty rudimentary Go CLI that does what I needed to do to automate Proxmox VM instances.
And my agents know how to use that CLI really, really well.
So for me to spin up or destroy a Proxmox VM is like...
Pretty easy.
Just like saying, give me.
And give me, 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 used 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, and then I will write out that data, and then I can use it to do the next thing.
It's like breadcrumbs and blues.
Yeah, and that evolutionary nature of it that says, I don't need to know what the model, 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.
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 actual Proxmox host or does it call the API from a machine that has SSH?
Like, how does that work?
Runs from wherever you want it to run.
So you can run it like, just literally go onto Proxmox, do your curl command to install.
Yeah, man, do whatever you want it to do.
Okay.
Swamp will just write itself.
Just tell it 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, this is insane, really.
Is there a world explored so far and 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, 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 of still unexplored.
But the, 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 do the right thing in a bespoke way.
I don't need to know exactly how your Proxmox 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 SSHN, 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 Mac OS X on a QEMU 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 OS X 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, friends, you know, I'm a big fan of Tailscale.
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 TailScale, every device makes a connection directly to every other device.
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 LAN, it's my TAN, my Tailscale Area Network.
But your word for it is Tailnet, right?
The Tailnet is the word that we invented to call the logical grouping of devices that form your Tailscale network.
Much like you might have a LAN of devices or something like that at home, effectively the Tailnet, 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 mom'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 Tailscale at tailscale.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 tail scale 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.
Tailscale.com.
Why the name 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, Mehir, and Paul.
Nice.
It's a throwback to the roots, I suppose?
Or is that just your way?
I mean, I tried to make it a codename.
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 if you go to Swamp Club, you'll kind of see why.
We like it.
The website is swamp.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 have said a long time ago.
Yeah.
Go to, go to swamp.club 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 merc lurkers and the directory where your data lives is dot swamp.
Cause like, you know, the agents are off doing what they do and like, there's gotta 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 I want to be website.
I want to be level.
I want to, 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 club?
You just, 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.
But we're not going to tell you exactly how.
And we reserve the right to change it season over season.
So there'll be different seasons of Swamp.
So if you sign up for Swamp now, you're in season zero.
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 swamp, you know, cause it's fun.
Cause 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 got some travel this Thursday, so it will be challenging to find this time without all my infinite time, but it's cool.
The agents do it for you.
Yeah, but I mean, 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 along with them in a way.
Yeah, I get it.
I do.
You know, so, you know, 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 kind of want to still enjoy making software while 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, what are your marching orders?
I mean, well, I have a prox box 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.
Yep.
You'll curl bash it.
Then you're going to.
Make a directory called whatever.
Adam plays with swamp.
Adam proxmox.
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 want it to do.
So you're going to be like, maybe it will be.
Only Claude or Codex?
You pick.
Pick?
Okay, cool.
Yeah.
When you run repo init, you could decide.
I'm a clogged man myself, but you do you.
Should I dash dash dangerously skip permissions or should I just not?
I wouldn't, 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 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, now 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 Proxmox 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 that looks like the other one.
And it would do the same.
It would write you a method.
It would look at the data.
You know, and like you just 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, Hetzner, 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 Proxmox servers, figure out a plan to move them into Hetzner, 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 Hetzner, like it can figure all that stuff out.
Because it's built for general purpose automation, not for 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 its thing.
Oh, you're doing it right now?
Of course.
Amazing.
I'm saying yes.
It just asked me if I wanted to use the extension search proxy.
It's actually searching proxy, I guess, to find this stuff.
Yeah, because there is a proxy proxy one already.
Yeah, it's going to use Keeb Proxmox, 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.
Yeah.
Who's this person, Keeb?
Who's Keeb?
Keeb is one of the people who built Swamp, Nick Steinmates.
I would say yes.
I would trust Keeb Proxmox, yeah.
Sweet.
Here we go.
We're trusting him.
Uh-oh.
It's going to figure itself out.
That's okay.
It's going to figure it out.
Swamp extension.
Be like, yes, yes, yes.
Go ahead.
Fine.
Yes.
Yes.
And so one of the things we're tracking, for example, is we now got telemetry that told us it hallucinated that command.
So we're making a list.
And so 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, but 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 Swamp's doing now is like, it's searching.
Yeah, there we go.
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 auth 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 me these questions right now?
Is that 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 called endurance is the node.
Yeah.
Let's see what happens here.
We're just prompting and wishing at this point.
Praying.
Yeah, you're just sort of saying.
Good.
Notice endurance.
Gotcha.
Sweet.
Have you stored your credentials yet?
The answer is not.
No, I guess I haven't.
It's going to want you to go ahead and do that.
Maybe pop a terminal we can't see.
Get yourself out.
Yeah, maybe pop a terminal we can't see.
If you know your Proxmox username 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 the repo knows how to store them.
It'll basically encrypt them for you.
So the commands it's telling you to run are the right ones.
I'm going to put it back into this LLM.
No, don't put them into the LLM.
Okay, what's the expectation I'm trying to ask you?
Yeah, you'll look in the terminal window, and then you'll run swamp vault put pxmsecrets, then the value.
It actually told you what command to run.
It did, huh?
Up above.
Oh, it did, yeah, okay.
Alrighty, I'll do this then in a separate terminal.
Do I have to be in that directory?
Or does it matter where I'm at?
Yep, you want to be in that directory.
Wherever you use swamp repo and knitted.
Okay, dope.
Yeah, it's probably asking 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.
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 don't, 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 in a Proxmox username.
So that's right.
Do you want this?
Yes, sure.
Let's see.
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 auth is correct.
And now it's actually running off.
So what it just did was run off independently.
Authenticated.
And it worked.
Look at that.
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 Gucci drawer, man.
Yeah, exactly.
You know what Gucci's are, Adam?
No.
What's a Gucci?
Gucci's are underwear.
Ah, I see.
Yeah, I know.
I mean, I don't mean to be in your underwear drawer.
Yeah.
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.
They're my homies.
And what's worth noting here is that while you did install this VM, while 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.
I guess this one's probably dead, potentially.
This is definitely dead.
Okay, so tell it to delete.
Tell it to remove Fedora Bootsy 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 lookup.
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 stopped.
This will...
Yeah.
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.
That's what's going to happen.
Swamp 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 Bootsy Builder.
Right?
Done.
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 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?
And it would make it nicer.
Yeah, sure.
Use an adversary to be like, hey, what could I do to improve the user experience?
What it does.
Auth job re-authenticates with Proxmox to get a fresh ticket.
Totens expire.
Okay.
And then delete job.
Waits for the auth to succeed, then deletes the named VM.
There you go.
What about creation?
VM creation?
Go ahead.
Tell it to create one.
Yeah.
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 a server over there, man.
I'm in a VM right now.
I'm in a VM.
You'd run it like this.
Okay, sweet.
But yeah, so like.
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'd be like, hey, by default, we'll set it up so it has, you know, two giga RAM, two 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.
It just said this is how it looked.
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 swapping.
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 want to play with 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.
Use create as is with PXE 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.
But like, that's crazy that it did that.
Do you see what I mean?
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 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 writing their code by hand.
You know what I mean?
Cause they're like, well, what'd you do?
And you're like, I just told it to like write me a workflow to reboot Procbox.
And they're like, I know.
So you wrote a script and you're like, no, no, I really did it.
I really didn't.
It didn't feel like that at all.
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 I've built it on my own terms, it seems.
Yeah, it's going to do exactly what you want it to do.
Yes.
And then if it doesn't, it'll just extend itself to do what you want.
So like, we're going to publish a bunch of models for all the cloud providers, right?
Which will be really convenient so you don't have to write them and get coverage real fast.
But if we missed a thing or there's something you want to do differently, it'll write an extension of the extension.
You know, it'll be like, oh, I'll just add this on to the EC2 model.
So now your EC2 model can do this.
This is a mind F, Adam.
This is a mind F.
Okay.
Yeah.
But it's awesome, right?
It's super cool, man.
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 it doesn't, 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 to pixie boot it or use a template?
And you'd be like, yeah, I don't know.
You know, like if you don't know what pixie booting is, like you could, 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.
I'm very excited, but I'm, I'm also like, What can't it build?
What can't it do?
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 if the extension doesn't exist, if it doesn't know anything about Proxbox 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.
So I could do that demo again, just like we did, which I'm not going to do it.
And just never, and tell him not to install the extension.
Don't use his stuff.
Make a new one, okay?
Make a new world.
It's like, 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.
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 to the world?
It's going to make the world awesomer because I love software and I don't know what it means that we can now produce software at this, 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 something that's in my brain, is more and better.
Yeah.
More and better.
More software and better software.
It's going to be more and better.
I was telling my wife on the way to dinner the other day, I was like, babe, you have to understand that this is how my audience knows that I usually say babe is the first thing I say when I dress with my wife.
Never her first name.
It's always babe because I love her to death.
And I'm like, What you understand is that all the software we use now is going to get better.
It's just going to get more of it and better because you can now cover a wider surface with SDKs even.
Will that even matter?
I don't know.
But as an example, you just do more and do better software, less bugs, less buggy software.
Or you'll just build the things you want all the time.
Like just-in-time software for everyone?
Mate, I don't know.
I don't know because 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 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 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, that didn't work.
I'll try this.
And like, you know, eventually it, it works itself out.
And like the, the side effect of that is 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 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, well, 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.
Cause you had, well, you had to have your own personal certainty to have your own 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 I'm yeah.
And be very specific to what you need and like, okay, so.
Today, that still feels like a very strange move.
But will it tomorrow?
I don't know.
And it opens the door to wild things.
What's an operating system look like that's designed like swamp?
Get out of here, Adam.
I don't even know.
I don't either.
But you're thinking about it now.
I think about what kind of interface.
does the future human want to use?
Yeah.
You know what I mean?
Like, cause that might not even matter.
Like, will 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.
Oh man.
Okay.
The same way that we care about architecture and houses and you know, like we will care about, we, that is still a skill that will not be removed.
You still have to know how to describe how software systems work and how to build them and all that stuff.
But people are afraid about how do we train new engineers.
I don't know how many new grad engineers you've trained, but I've trained dozens probably.
And 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 they learn over time 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 next 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.
And you may still, 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 cause 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, 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 essentially at speed?
And the answer is, I've got to be able to build automation for you at speed.
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 which you can do with it in a way where...
People kind of like wish their life into OpenClaw or NanoClaw.
I mean, you 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?
No, the out there things would be centered and maybe you've left the center a little bit.
Yeah.
I mean, I found the like Wi-Fi use case to be so out there.
Like, like imagine telling Terraform to solve your Wi-Fi coverage problem.
You know?
Yeah.
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 the, 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 wifi.
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, and then once that's true, like here's another example.
It turns out that once you, 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 config 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, what did the package installation list look like on this server on Tuesday?
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 smoosh 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 a 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 mushed 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 do it.
Yeah, learn how to deploy on this other cloud because this cloud upset me because they were down again.
They got bombed, Adam.
They got this data center.
They got bombed.
One of the people who's most excited about Swampworks does a lot of data sovereignty for Sweden.
Absolutely.
So he's currently running around going to folks in Sweden being like, this is it.
We're going to use this thing to get sovereignty.
Yeah.
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 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 stuck.
But if Swamp can...
You know, 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, look, the more specific your prompt, the better the outcome.
Right.
And so we're talking about all the wild things you get from a single line, which is true.
But yeah, of course, the more specific you are about make me a model that does X or a workflow that does Y, 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, like forget about Swamp.
If I'm building pretty much render my CLI useless.
I mean, I, yeah, but I'm going to play with it and it's going to be better.
Like this is already kind of better.
And it's going to be the same across 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.
Think about it.
The way you used to keep multiple environments in sync 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, you know, 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 early days still.
Well, I think it's pretty wild to just essentially ask this magic box to just, here's my IP to my Proxmox box.
I mean, I'm kind of flabbergasted about it.
I really am.
I mean, of course, my SH key got it in, and I gave it my user pass, and 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 sleuthed the system.
Yeah, the first thing it 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 moves so fast.
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?
And 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 GitHub 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.
Where are those tokens stored?
Do you know Bonnie Chan's inside of Proxmox?
Where you would go and provision that so I can go and see this is the token?
No, I have no idea.
I've never actually created a token.
I've just used my user in past to get there.
I actually was my SH key being replaced.
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.
And like what Swamp does is encrypt that stuff with a key, you know, for you.
And then, yeah.
Okay, Adam.
Swamp.
Super fun.
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, not market fit, you know, how do you?
No, product market fit.
Yeah.
Lack of product market fit for system initiative.
Rest in peace.
Yeah.
Yeah.
How do you, 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 it.
Probably get solved.
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 too.
And, uh, the software is open source.
It's a GPL V3.
Uh, 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.
And, but step one, you know, in a gold rush, sell 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 is so different and interesting to our audience.
You know, 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 in 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 that 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, inspired the open source Bazel tool.
But every engineering team I've talked to that wants to adopt Bazel has just found it extraordinarily difficult to use and configure.
You have to have a dedicated engineering 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 Bazel are really impactful.
They're similar to a lot of the ideas behind Nix.
I would say Nix is kind of very similar.
you know, and the difficulty to adopt.
And effectively what we've done in RWX 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.
You know, whereas other platforms are having to run the same setup steps on the same jobs in every, you know, 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.
You know, 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 just define the tasks that you want to run and 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.
We've got a lot of compression happening and just straight up gone.
It's just not there anymore because AI has compressed so many steps.
You used to have to do this whole circle, now you're just straight to B.
I don't know.
I think I could just be wrong.
You know what I mean?
I think it's one of those questions that may be 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, the Neo clouds, they actually kind of pointed a hand, a finger at this where like those data centers they're building for, for inference and for, uh, 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, ugh.
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.
That's all agents care about.
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 same time.
Oh, it hurts my heart.
Oh, it hurts my heart.
Well, like my whole career building.
I'm 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 it's like self-preservation in a 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 you're like.
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.
You used it for two minutes.
And once you learned to trust it and you knew, yeah, okay, I know what a workflow and a model is and vaults.
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.
Cause 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, 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.
Okay, here we go.
You want to do it again?
Let's do it again.
It's a fun trick, you know?
And like, 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-wide, 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, it's a lot of uncomfortability, you know, Two Thursdays ago, we had Black Thursday for Block.
It was like 4,000 people let go, blamed on AI.
It wasn't really AI.
Oh, I love that though.
This is great.
Like all the people reacting to it being like, it wasn't really AI, they just overhired.
And I'm like, okay, man, fine.
You realize it doesn't matter.
It was both.
It can be both.
It was, but if it wasn't, but if, 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 over hiring 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's a pretty thoughtful person.
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.
Maybe more.
Maybe, maybe probably more.
Probably a lot 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 they don't like it.
So like even if even if you take the cynical side, it was still AI that did that.
And 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 we're doing right now.
What's about to happen?
Nothing.
So like, 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, whoo, 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, I, I, 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 how to 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, you know, 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 get, it's going to get rougher.
Play your flute, man.
Say, say what you want to say right now.
What's the, what's the, 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 at on your own time because your jobs are all too slow.
They're all too conservative 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 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 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.
That's a hard road to hoe.
But I would say that's well of the majority of all software engineers ever.
We're 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.
Like 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, 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 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 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 do not want to be on that side of that puzzle.
And like, you know, it's a bummer because everything we knew, 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.
That's such a hard thing to swallow.
But you just got to swallow it.
You just got to get past that as quickly as possible and get down to the brass tacks truth, which is it's better to build software this way.
It's 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 truth is you got to get over it.
Like you just 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, you just got to, she knows.
I mean, she's, she's well aware of, of, uh, you just got to do it.
I've been telling her since last.
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're going to need more engineers, not less.
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 to 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 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.
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'm peeing every two seconds.
That's how much I'm drinking.
What do they do?
I mean, they may already know, but given what you've built here and the level of automation, because 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.
Great.
In terms of career arc, so you should do that self-servingly.
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 the other is...
Most of us scoffed at software architecture.
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.
Any recommendation of that?
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 Vaughn 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 is 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.
You just needed an LLM to do it for you.
So that would 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 anywhere where you're tempted to have the answer be, this is where the agent part ends, that's probably wrong.
You know, like, like I was pretty sure that it wasn't 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 LLs.
Is some of that stuff secret sauce or?
How would 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 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 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 grok 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 Ben and 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.
Is this a manifesto?
Not yet, but yes, 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 engender 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, 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?
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 back.
backtracking in a way, but you mentioned the friend with a hundred to a thousand 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, my, 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 it's, 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, 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 juxtapose a hundred engineering team to a thousand.
Yeah.
down to four or five or 10?
I think 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 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 mismatch 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 code base.
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.
You know, and GitLab had to hire a lot of software developers.
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.
It's going to go like this.
We're like here, and the roller coaster ends somewhere down there.
Below the screen even.
It's going to be bad, bad in the middle.
I don't know.
I wish it wasn't.
I wish I knew how to avoid that.
You got predictions on bad, bad?
I mean, what is bad, bad?
When you say 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 layoffs 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 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, that 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, 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 lovey.
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?
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 use 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.
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, we do that cause it works not cause they don't, you know, and not cause it doesn't.
And, 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, 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 I've 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 that's obvious.
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 go 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 row 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, their interest.
I think all that's going to be real.
And 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, you know, 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.
All the unknowns that are happening right now on the frontier, all those things need to not be frontiery 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 waterline is going to go.
But if you made me, but if you, 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.
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 floods over like lots of opportunity, you know, yeah.
Got a whole world to rebuild like so fun and 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 is more important to understand the full stack.
And I don't mean full stack front end, but I mean 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 to somebody recently and, and I'm like, I don't understand a developer in these days that doesn't have prox mox or a home lab or Incas or a V, 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 saying is true.
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 reinventing everything.
Everything's on the table.
And the upside of 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.
Yeah.
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, 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, you know?
Yeah.
One shotting something is, is, I mean, you can do it.
Well, but it's like my, but not one of a friend of mine who does, uh, 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 it doesn't, he doesn't, 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 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 like 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, of our people and our people, you know, that's how they're going to go.
But, 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 Stack on this leaderboard soon, okay?
Yeah, for sure.
If you don't think so, then we'll, I mean.
I got to beat 14 people to get there.
It's going to be pretty easy.
I mean, a lot of those people have no points.
Yeah, I'm going to be up there with you all here shortly because 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 getting through the lull, man.
We didn't talk about the sadness, and we don't have to.
of not achieving the mountaintop.
But sometimes that could have been the price necessary to pay to get to Swamp.
Yeah.
You have to recognize that in those decisions, I'm always the one with the most privilege and the least risk.
So I have emotional risk and a lot of those things.
But there's people who I loved, who I'd worked with for a long time, who I just 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 works 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, 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 in 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, you know.
I understand your perspective.
You have good intentions.
You have good will 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 toll booth 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.
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 the speed with which we will implement your feature suggestions.
It's sick.
It's sick.
You'll show up.
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'll be done in a couple minutes.
Wow.
Yeah.
Because the Magic Software Factory takes care of it, you know?
The Magic Software Factory.
You've heard of it here first.
Swamp.club.
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 Adam's.
You're not a friend of mine.
I'm just kidding.
You're friends.
Get to it.
What are you waiting for?
Swamp.club.
I'm telling you, this is insane.
This is insane.
That's all I can say.
Adam, I love you to pieces, man.
You're my favorite, man.
You too.
It's good to see you again.
It's good to see you, too.
So much fun to pod with you, and I'm thankful for you, man.
Yeah, 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 could do right now.
I can't believe it.
I really can't believe it, y'all.
Hope you enjoyed this show with Adam Jacob.
I know I did.
Check out Swamp if you haven't yet.
Swamp.club.
The coolest thing ever.
And look at their repo.
Lots of cool stuff they're doing in their code base 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.