In short
The episode argues that recent AI advances have changed software development and operations, and introduces Swamp, Adam Jacob’s project for “reusable automation at the speed of agents.” It also discusses why traditional tooling (especially local dev laptops and slow ops processes) can’t keep up, and proposes architectural “guardrails” using multi-agent planning, adversarial review, and external UAT testing.
Guests (backgrounds)
- Adam Jacob: AI maximalist; builds automation systems; previously worked on “System Initiative” for years to speed up operations alongside engineering.
- Nicky Pike: Field CTO at Coder; describes the role as DevRel for the C-suite—translating customer needs into product messaging and enabling leadership teams.
- Adam (host): Adam Jacob’s “good friend” and co-host of The Change Law Today (speaks as “Adam here”).
Key claims
- AI-driven software construction is accelerating nonlinearly; teams experience order-of-magnitude changes in speed and emotional/operational dynamics.
- Communication gaps will widen between “AI skeptics,” “AI users,” and “AI builders of AI-built software.”
- Production gates shift: code review/code quality become less limiting; observability and production readiness become the new bottlenecks.
- Swamp uses software architecture (not code-first hacking) plus multiple adversarial agents and immutable external UAT tests to prevent agents from “gaming” or altering tests.
Notable examples
- Swamp rebuilt an anime media-server scraper by instructing it to scrape torrent sites and download episodes.
- Wi-Fi troubleshooting: Swamp connects to existing Wi-Fi gear, analyzes signal strength, and recommends what to buy.
- Swamp “configuration management” via SSH with idempotent primitives; workflows reuse extensions.
- Swamp Club website reportedly shipped with 100% Lighthouse, SEO, and accessibility using adversarial agents.
Written by AI. May contain mistakes. Listen to the episode to check what was said.
Chapters
Tap a time to open that second in VOUnderstanding the Role of a Field CTO
0:41 to 3:24
Nicky Pike explains the role and importance of a field CTO in bridging customer needs and product development.
“Well, friends, this episode is brought to you by our friends at coder.com, secure environments where developers and agents work in parallel.”
The Importance of Cloud Development Environments
3:24 to 4:20
Discussion on the advantages of cloud development over traditional laptops for developers.
“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.”
The Changing Landscape of AI in Software Development
4:20 to 8:17
Adam Jacob and the host explore the evolution of AI in software development and its impacts.
“I really, I was actually thinking about this because we kind of crossed paths unexpectedly when you were keynoting, I believe, OSCON.”
The New Paradigms in AI Communication
8:17 to 12:20
Discussion about the challenges in communication between different camps in the AI field and the rapid advancements in technology.
“and to get better and to like move the industry forward in a, in a meaningful way.”
Building the Future: Swamp and Rapid Development
12:20 to 14:00
Adam Jacob shares insights on building the Swamp project and the speed of development it enables.
“Like the inability to communicate is just going to get worse, I think.”
Building Swamp: A New Approach
14:00 to 15:00
Learn about the inception and ambitious goals of the Swamp project.
“You know, refactors or architecture changes that would have taken months are happening in hours.”
Productivity Revolution: Speeding Up Development
15:00 to 16:00
Discover how Swamp drastically accelerates software development processes.
“No, even even on my software that's like, you know, Swamp's only four weeks old.”
Emotional Impact of Rapid Development
16:00 to 16:42
Understand the emotional and psychological changes faced by developers in fast-paced environments.
“And we're more productive than the 18 of us ever were.”
System Design Challenges with Accelerated Development
16:42 to 17:55
Explore how changes in key system constraints affect software architecture.
“who are like, I fire up Cloud Code and it does some stuff for me.”
Redefining Metrics and Observability
17:55 to 19:32
Learn about the challenges of metrics collection in a rapidly changing development landscape.
“Those are the corner pipes in our house, so to speak.”
Show all 57 chapters
AI Maximalist Team Dynamics
19:32 to 21:04
Discover how working autonomously within small teams enhances productivity.
“There's a couple of things I put a pin in and I hate that phrase.”
Swamp's Development Workflow
21:04 to 22:48
Get insights into the workflow and planning processes in the Swamp project.
“I rambled because I've, it's very, it's, I'm clearly pent up about it.”
Advancements in Code Review and Merging
22:48 to 24:18
Learn about the role of adversarial agents in code review and merge processes.
“The process tends to look like, um, like we talk to each other about what we think needs to change, come up with a plan, write that down.”
Revisiting User Acceptance Testing
24:18 to 26:18
Understand the importance and process of user acceptance testing in modern software development.
“You know, I'm still thinking about 100 % on this.”
Conclusion and Reflections on Development Changes
26:18 to 28:00
Reflect on the transformation in software development practices and their implications.
“and every time you were going to release the software, their job was to go through the binder, page one, and like try every feature, you know?”
Understanding UAT Implementation
28:00 to 28:36
Learn about the role and importance of User Acceptance Testing (UAT) in software releases.
“Like you, Adam, and then someone else would have their same flow into UAT from implementation to UAT?”
The Role of QA in Software Development
28:36 to 30:50
Explore the historical significance and responsibilities of QA during software validation cycles.
“Or did you just like, did you have to like go back to the RFC for that thing?”
Architectural Changes in Software Development
30:50 to 34:30
Discover how software architecture has evolved and its impact on development practices.
“More agents is like the answer to basically everything.”
The Challenge of Rapid Development
34:30 to 37:20
Examine the challenges faced in software development velocity and operational alignment.
“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.”
Introducing Swamp: Automation at Scale
37:20 to 42:00
Learn about the Swamp system designed for scalable automation in software development.
“And a thing that's true is the velocity of engineering causes co-committent increases in the velocity of operations always.”
Swamp: Reusable Automation for Everyone
42:00 to 45:00
Learn how Swamp enables users to create reusable automation workflows across various applications.
“So they can all like watch anime on discord when it comes out in Japan.”
Understanding the Role of Swamp
45:00 to 46:39
Discover who can benefit from Swamp and how it addresses operational problems through automation.
“It's basically reusable automation at the speed of agents.”
Proxmox Integration with Swamp
46:39 to 47:50
Examine how Swamp creates reusable automation for Proxmox virtual machines and configurations.
“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.”
Challenges of Automation with Proxmox
47:50 to 49:50
Explore the challenges faced when automating Proxmox and how Swamp simplifies the process.
“And then those inputs become definitions in models.”
The Evolutionary Nature of Swamp Automation
49:50 to 51:40
Understand how Swamp allows for evolution in automation without knowing the specifics upfront.
“a pretty rudimentary Go CLI that does what I needed to do to automate Proxmox VM instances.”
Exploring Uncharted Territories in Automation
51:40 to 54:00
Gain insight into the unexplored potential of reusable automation and collaboration via Swamp.
“I mean, another is, uh, 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.”
Understanding Tailscale and Tailnet
56:00 to 57:22
Learn how Tailscale enables secure connections across devices using encrypted tunnels.
“allowed to even connect to different things all over the tailscale encrypted tunnels which underneath use the WireGuard technology.”
The Origins and Aesthetics of Swamp
57:49 to 59:55
Explore the unique naming and aesthetic choices behind the Swamp project.
“It's a throwback to the roots, I suppose.”
Engaging with Swamp Club
59:55 to 1:02:30
Learn how to engage with the Swamp Club and track your contributions and scores.
“Now, mind you, I've got some travel this Thursday, so it'll be challenging to find this time without all my infinite time.”
Using Swamp for Proxmox Automation
1:02:30 to 1:04:34
Understand how to utilize Swamp for managing and automating Proxmox servers.
“You'll be like, uh, go create me a new one.”
Connecting to Proxmox and Managing VMs
1:04:34 to 1:09:28
Learn the process of connecting to Proxmox and managing virtual machines with Swamp.
“that's in front of you I'm watching it do its thing oh you're doing it right now?”
Real-time Management with Swamp
1:09:28 to 1:10:00
Experience live demonstrations of managing virtual machines using Swamp.
Deleting Instances with Swamp
1:10:00 to 1:12:00
Learn how to use Swamp to manage virtual machines, including deletion workflows.
“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 Boot C Builder, right?”
Creating Workflows for VM Management
1:12:00 to 1:14:12
Explore creating reusable workflows in Swamp for various VM operations.
“So if you think about this as like deploy my stuff to production.”
The Fun of Using Swamp
1:14:12 to 1:16:34
Discover the enjoyable aspects of using Swamp for automation tasks.
“Or you could clone an existing name or, you know, like it's giving you choices.”
The Future of Software Automation
1:16:34 to 1:19:08
Discuss what the evolution of software automation means for developers.
“we're not going to be the bottleneck anymore.”
Training Engineers in a New Era
1:19:08 to 1:24:00
Understand how to train new engineers in a world where automation takes precedence.
“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.”
Building Automation with Swamp
1:24:00 to 1:36:40
Learn how the Swamp platform enables the rapid creation of automation in software development.
“would choose one or the other and what their, what their operational semantics are.”
Revolutionizing CI with Advanced Techniques
1:38:24 to 1:40:38
Discover how RWX simplifies CI processes using advanced caching and task execution.
“And this is just highly relevant with agentic-driven coding.”
The Impact of AI on Software Development
1:40:45 to 1:44:44
Explore how AI compresses software development processes and workflows.
“You're thinking about this more than I am, so I'm just like, I'm curious what you see that.”
Navigating Change in the Tech Industry
1:44:44 to 1:52:00
Understand the challenges and shifts in the tech industry due to AI and automation.
“and i know how that like once you trusted the architecture you just start letting it rip and once you start letting it rip like you're like well i could do that i could do that i could do whatever, you know?”
The Imperative of Change in Software Development
1:52:00 to 1:53:29
Explore the necessity for developers to adapt to new methods of building software.
“We're roughly that person or learned roughly that way.”
Facing the Reality of Evolving Roles
1:53:30 to 1:54:45
Understand the emotional journey of adapting to changing roles in software development.
“that as quickly as possible and get down to the brass tacks truth, which is it's better to build software this way.”
Embracing Automation with Swamp
1:54:46 to 1:55:58
Learn how to leverage automation tools like Swamp to enhance productivity.
“And the best way to survive that trough is to be one of the people who learns how to do it first.”
Importance of Software Architecture Knowledge
1:55:59 to 1:57:17
Discover why understanding software architecture is crucial for modern developers.
“So I think another, the other is most of us scoffed at software architecture.”
Harnessing Agents for Architectural Challenges
1:57:18 to 1:58:49
Find out how to utilize agents to tackle architectural issues in software development.
“And we always made fun of those guys because they were all pedantic and annoying and were the ones who wrote the software.”
Contributions to Open Source and Collaboration
1:58:50 to 2:00:09
Examine the evolving nature of contributions in open source software development.
“to get the architecture that I asked it to express.”
The Future of Open Source in the Age of Automation
2:00:10 to 2:02:19
Discuss the potential impact of automation on open source values and practices.
“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?”
Navigating Trust in Automated Software Development
2:02:20 to 2:03:24
Learn about the challenges in maintaining trust within automated software systems.
“so that it can engender human freedom in the way that free software wants you to do.”
The Evolving Landscape of Software Engineering Teams
2:03:25 to 2:06:00
Explore how team dynamics in software engineering are changing with new technologies.
“The layer I want to go deeper is maybe, and maybe it's not, maybe it's just sort of backtracking in a way, but you mentioned the friend with 100 to 1 ,000 engineers.”
Navigating the Future of Software Development
2:06:00 to 2:08:20
Discussion on the evolving landscape of software engineering and the potential impacts of automation.
“Will we get to some moment where you don't need people anymore?”
The Reality of Layoffs and Industry Shifts
2:08:20 to 2:10:50
Exploration of the challenges faced by tech workers amidst significant layoffs and industry transitions.
“enough that they could get you the core of the loop, you know, and GitLab had to hire a lot of software developers.”
The Tsunami of Productivity in Tech
2:10:50 to 2:15:00
Insights into how increasing productivity may come with challenges for software professionals.
“But right now we don't know what to do with them because there's this big transition that has to happen.”
Embracing Change in Software Development
2:15:00 to 2:19:45
Encouragement to adapt and learn new skills in the evolving software environment.
“I can't understand that person for the reasons why you said what you said.”
The Future of Software and Community Building
2:19:45 to 2:20:01
Discussion on the importance of community and collaboration in future software development.
Navigating Job Loss in Automation
2:20:01 to 2:22:36
The discussion reflects on the emotional toll of job loss due to automation and the responsibility leaders feel.
“gonna 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.”
The Future of Automation with Swamp
2:22:36 to 2:23:23
Exploration of how the Swamp platform is changing the landscape of automation in software development.
“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.”
Transcript
Automatic transcript. May contain errors.0:01What'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.
0:41Well, 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 Nicky 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.
1:21Okay, 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.
1:51it 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
1:58Adam Jacob: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 laptop set up and ready to start doing their first type 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?
2:24But 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.
2:55We 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 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
4:00Well, 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 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 OSCON's defunct. That's right.
4:39One of the things they had us do was happily talk to you. And since then, we've become friends. And I'm so thankful for that, really. I really am thankful for the way that paths cross in this industry. You know? Yeah. It's so wild. Yeah. And that, like, you never know where people will reappear. Yeah. You know? And under what context those relationships will matter. And, yeah, I feel like a thing that I have learned, I've learned both, that, you know, If you like people, then you should do your best to be friends because whatever, you only get a limited number in life and you should try to make that number higher is usually a good idea.
5:25But the other side is you don't know where those people will reemerge 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.
6:01And 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 uh 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 cooler than that guy hopefully definitely definitely cooler in yeah in uh in spirit you know you can do it yeah which is kind of cool yeah for sure for sure what a place to be at though i mean i like i know the last time we talked about ai in your infrastructure but did you imagine we'd be here this short of time later like i feel like the game has totally changed it totally did change right i mean like it was changing then and it was like if you were in the ai game then you were almost in crazy land yeah some would say agent psychosis even yeah yeah yeah and then if you were even a version of a maximalist on ai you were definitely crazy you're definitely crazy right but how do you feel about that now yeah not anymore yeah at all right yeah i mean i'm bad at time is it 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 check my daughter's birthday even though i know her birthday you know just because like i might could mess it up you know right um 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 was really paying attention and doing that work, like there's, there was like a, a tangible change in the outcomes and a tangible change in our ability to start to articulate sort of what a working architecture is.
8:16You 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.
8:50A little, yeah. Because I'm like, oh, no. Like, I don't know if you know what's happening, but like, oh, no. You know? Like, it's going to be bad, you know? But good. Good, bad. Good, bad. Good, bad. And a lot of change. Good, bad change. Yeah. And that's all really happened in the last little bit here. And then I think now we're entering an era where you, you know, back then, I think there were like two camps who couldn't talk to each other very well. You know? Like the AI is stupid and everybody who's talking about it is a dumb dumb. And they're telling, you know, whatever, they're telling lies or they're saying it because their investors are making them or whatever the reason is.
9:32Yeah, 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. You know, I'm using cloud code or whatever. And it's like, and I'm more productive or it's better. And they were struggling to talk to each other. And now we have a third camp that's struggling to talk to each other, which is the version that's using AI to build the software that builds the software that they're trying to build. And that third camp where it's like, I'm building the machine with AI to build the software that is the thing I'm trying to do.
10:09That camp can't talk to either of the other two either. You know, because it's just, 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 dum-dum 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 right 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 You hear Winston Churchill, you know?
11:43And 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 getting worse because the people who are building systems to build the system, you know, people who are building the software to build the software are accelerating at a nonlinear rate. So like, they're currently in order of magnitude different than we used to be even six months ago. and what they're doing with those tools is creating what will be another at least order of magnitude, maybe more jump in difference. And they're just going to accelerate the weird.
12:20You know? Like the inability to communicate is just going to get worse, I think. Yeah, we thought there was an abstraction before. And I'm trying to say like, the abstraction now is both understanding AI, understanding how to use the tooling around it, building the machine that builds the machine. Yeah. And like you said, some of those problems are largely personal and hard. The way I'm solving my problems and building my machine isn't 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.
12:56So 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, but 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, you know, like I talked to my friends who run, you know, like 100, 200, to 1 ,000 software developer organizations, I got nothing.
13:40You know, like when we talked to like, what should they do and how are they going to move through this? And I'm like, I don't know. Because like, I don't know how you, I have like, you know, system initiatives. 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, 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 and it's wild crazy the rate of speed that we're operating i mean bananas the rate of speed we're operating at the the 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.
14:40You 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. 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 even on my 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.
15:16You 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 yeah 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 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 i it was a bad day because I, you know, whatever.
15:58But 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 just because we built the machine to build the machine.
16:36We 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. You know, like we're not doing the same thing at all. And, you know, yes, there's Cloud Code involved. you know but that's about that's about where the comparison ends anyway it's it's it's wild and like all the repercussions for everything are maddening and if you just hang out and think about them you just sort of spiral into this loop of like well i don't know like what's it mean for business and what's it mean for developer tooling and what's it mean for open source and what's it mean for uh sas companies and what's it mean for you know 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?
17:34And that constraint is eliminated, or in this case is just so dramatically accelerated, it means that the entire rest of the system's design is wrong. you know it'd be like it'd be like if if suddenly the water pressure in your house went up by an order of magnitude but what happened is every pipe in the house would burst yeah you know and that's exactly what's happening to us now we're seeing it's just like we're seeing that with like code review code quality like those are the main gates getting getting whatever it is to production faster well now the gate is production and observability all those things are just blowing apart the scenes.
18:10That'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. A GUI, right? It just didn't matter what we assumed. It doesn't matter. The odds that we have a problem 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, let's use, like, observability, monitor.
18:53Right. Okay. In a world where I can produce at even a one order of magnitude change. Okay. 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 yeah 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 what now looks like horses and buggies yeah and like i mean the wheel survives seats survive you know the chassis survives everything else about that mode of transportation did not survive the shift to cars none of it you know i don't know man roads roads survived they sure did yeah silicon survived i don't know but even roads got different you know we were like i 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.
20:56This 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 of things I put a pin in and I hate that phrase. I don't put pin in things. It's okay. I rambled because I've, it's very, it's, I'm clearly pent up about it. You know, like it's a problem. This is your release, Adam. Just imagine that this is, uh, as crass as I can be, but not be crass. Okay. This is your release moment, my friend. Yeah. This is us. We're here. We're here at the, put it all out there. Yeah. So you can't advise your friend with 100 to 1 ,000 engineers, because obvious, but you can't advise on 4 to 10 because now you're 5.
21:31You went from 18 to 5. 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 5? what does it look like i suppose on the daily if you can describe it because it probably changes tomorrow yeah to be an ai maximalist team yes i mean yeah so we're so we're um 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.
22:25So 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, there's a bunch of work that's coming in from like early users of swamp that are like posting features or, or issues. And so like, we're fixing those as we go. The process tends to look like, um, 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.
23:05Then that plan gets reviewed by maybe multiple rounds of different adversarial agents for different purposes. So things like, um, like architecture, you know, like the software is architected in a particular way. It 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 a hundred percent lighthouse score. It gets a hundred percent SEO and a hundred percent usability, like accessibility. Congratulations. That's amazing. Don't congratulate me. I installed a skill. You're the owner.
23:40I mean, all it, we built an adversary that says make sure that we do this in an accessible way. And then it looks, 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 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.
24:22So 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 yeah but paul stack who works for me right routinely has five yeah so you know i've had like six or seven at once and it's until you get into a good stream and it's not like prompt and 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 just one just to just to get back to like old me. If it's hard, I just got to focus. You know, I'm still thinking about 100 % on this.
24:59Yeah, let's get over this big hump. I'm going to totally focus on this major feature. So then what else happens? So then there's tons of testing that's within the agent's control. So then that produces a pull request. So then that pull request gets adversarially reviewed as code across the same sort of axes that the plan did, you know, but just with a different agent. And now it has the context of the implementation not just the plan. And then if those agents find blocking issues, they reply being like, hey, this is a blocking bug. You got to go fix it. Then you just tell the agent, go look at the pull request, see what their review comments were.
25:35So 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. Gotcha. Do those agents have accounts on GitHub, then? Nah, they're just running out of CI. They're just running out of actions, you know? 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, where you would have like teams of QA engineers and they'd have like binders.
26:22and every time you were going to release the software, their job was to go through the binder, page one, and like try every feature, you know? And if they found a bug, then they would file a bug and it would go back to engineering and then it would all start again, you know? And so like, you're basic, and we did that because there was a separation of concerns. For a long time, people were like, you could never ship software where the same people review the software that do the other thing. That morphed into four-eyed compliance, by the way. But like, you know, conceptually, that's what we used to do.
26:49So we're doing that again because you need to have a test suite that's outside the agent's control that defines what the acceptable outcome is and isn't. So it can't just break authentication or login when a feature is stable. And there's some rules for that. Like UAT testing, you're only allowed to do it from the outside in. 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.
27:30So 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, you know? 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.
28:16So it's an individual exploration. Totally. that your feature gets blocked, not the entire product. Nope, the whole product would get blocked. Yeah, if UAT fails, the whole thing stops. Just 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? Were you like, man, I lived in the 90s. I shipped software then. Okay, UAT. Or did you just like, did you have to like go back to the RFC for that thing? Did you pull out the coffers? No, man, I worked then. I'm old. I worked then. That was me. Yeah, I was there.
28:46um no it's it's because you needed um like anybody who's worked with agents knows that they'll they'll change the tests to match their desire so if a test is failing and it can't figure it out long enough it'll be like fuck it i'll just disable this test or i'll make the i'll change the shape of the test so that the failing condition is now correct and like they do that all the time and i'm not having that experience oh you will and and and you kind of want them to do that because the truth is the tests are there for them, not for you at that level. You know, like I don't understand the code anyway at beyond the level of the architecture.
29:21I 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.
Read the full transcript
30:00They'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. Cause eventually it had to go, you know, on a CD that was going to get burned.
30:26And once you started burning that CD from the factory, you know, that's it. You weren't getting any software updates. You weren't getting over the air patches, you know? And so like, that's, that was the situation we were in. I'm like, and they're crazy. And so how do I make sure that those crazy agents don't do something wrong? And the answer is UAT. I use more agents. You know? More agents is like the answer to basically everything. Take me into your implementation plan. How nuanced is that implementation plan? Like 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?
31:06Yeah. I'm going to answer a little obliquely. Because you can't share? No, because I'm not sure how to describe it. I see, okay. I think for a long time, a lot of software developers learned how to be software engineers from the bottom up. They started attacking code. And they still, there's a, you've been able to be a good engineer in our industry by being one of those people. 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 comes into a shape that makes sense that they like. And that's how they program.
31:48That'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.
32:27Suddenly, 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.
33:10And 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 wanted 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.
33:43And 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 really clean, supple, easy-to-maintain code that you don't want to write, but you can read it if you needed to, and you understand the architecture.
34:19And 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, 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 write 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.
34:55You're not using them at all? The agent's not really either. No? Nah. I mean, the plan, And that like rinse of the plan mode, it looks a lot like writing a spec about how you're going to implement it. But no, it's not starting with a, here's my software spec, now Ralph Wiggum loop my way to... Yeah, I'm not even talking about that either. Not where it's more so that whenever it has to go off track or it has to do code review, it knows. In my particular case, I've written this DNS server called DNS Hole. and you know it's a lot of it's over my head and in some cases but some of it's like right in my wheelhouse but uh it literally has to adhere to rfcs that are yeah you know internet i would i would feed it i would feed it that all i would feed it that all day right all day in those cases for sure for sure but what about even like authentication like we want to authenticate a certain way would you not would you not specify with us oh yeah i specified i was going to use the better off library okay i was like you're going to only use better off and you'll never and like and architecturally i said yeah better off is its own bounded context and i want i want to i want to be a strict follower of that model so whatever they say that's what i want so wherever wherever my domain conflicts with their model their model wins and mine is is subservient That was a mistake architecturally.
36:24And 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.
36:57We could just rewrite the whole thing every day if we knew what to do 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 like i can read your home page i can do all that and i have yeah 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 i was we used to be friends we used to we came into this show pals but now you know let's do parentheses yet you broke my heart adam so broke my heart yeah anyway 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 um let's get into swamp by talking through this like we were just on this tangent about software architecture and sort of how to prompt how the system builds the system so you know my whole career has been building, I build automation.
38:11That's what I do. And a thing that's true is the velocity of engineering causes co-committent 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.
39:01You 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 bad. Like towards versus hair in a way. Ah, it was already tough. Triple hair, 10X hair. Yeah. If you got everything just so, you could do it. But you mess one thing up and you were cooked, you know?
39:41So 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 like visual composing composition problem you know and it just was too weird you know like when people touched it even though it could do wild things with the agents they were like yeah but it's just too weird you know like it's just whatever it's just too far too far left center yeah i feel that on some things like you can just have the most next revolutionary thing it could be the most amazing thing but it's just like it's just too different it just wasn't quite 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 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 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.
40:55Like they're just not, they can't keep up. They're not good enough. It's too complicated. 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.
41:33Um, and then you can put those models together into reusable workflows that do things for you. And, uh, and then swamp is an implementation and a description of that architecture. It says, Hey, here's how you put things together. Here's agent, how you drive swamp to do it. And so, you know, one of the first things we did was, uh, one of the people on the team next time mates has a big, uh, he like collects anime for his friends on a, 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 and swamp by just telling swamp, Hey, I need to go scrape all these torrent sites and find, download all the anime for all the episodes of the shows that I want.
42:16or his friends show up and ask him to run 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 the Proxmox API support in order to do it? And in Swamp, you don't wait at all. 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 uh another good example was uh someone was working on their um that bad wi-fi connectivity yeah 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.
43:18And so it just wrote the automation to connect to those devices, to grab the data, to store it, then do the analysis, then tell him the results. And it just wrote itself. 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. 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 SSH-based operating system configuration management.
43:56And it has a bunch of 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.
44:31You 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, um, like a big production metrics gathering infrastructure. We have people doing like cloud provisioning is great with it. Um, 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 okay it's so fun it is and then it writes itself and then 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 it will reward you with levels you know like tears you know when you when you start you're a swamp baby but you know you might get to murk lurker but there's like we're not going to tell you what the tiers are they're all secret so like right the first person gets gets points yeah but they're like the first two okay that's table stakes then too easy yeah yeah it would you consider this harness would you say that this what you've built is a harness this word gets thrown out around a lot it's like i'm building a harness for ai i mean i don't know i think i think what i'm building is reusable automation uh and what 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.
46:11And 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 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.
46:47They 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 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 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 give me an example of what actually happens when you request this request. So it would build an extension. 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.
47:37And it would create a definition of a Proxmox VM. And you'd probably say to it things like, hey, I want memory or CPU. But even if you didn't, it would just infer because it knows Proxmox pretty well. you know like not swamp just clawed you know codex knows how to use proxmox so like it would just sort of create you a model and then it would write the typescript code that is the method itself it would be like hey in order to start a vm 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 um 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.
48:27And then those inputs become definitions in models. So there's a file in your swamp repo, which is like a GitHub repo that is defined in YAML. And it would be a model and it would say its type is proxmox server. And it would define those inputs for you. And then it would have a method on it called create. And you could either call the create method directly on that model and it would just go do it. Or you could call it in a workflow, right? That would say, well, I want to create that VM. And then once it's up, I want to use Adam's config management extensions to install Minecraft on it and then bring it up for my buddies.
49:06And 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.
49:24It'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 try to automate Proxmox quite a bit. hit some issues with CloudNet 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, just like saying, give me.
50:07And 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?
50:41What 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.
51:11And then I will write out that data and then I can use it to do the next thing. And like, so like that. Yeah. And that evolutionary nature of it that says, I don't need to know what the model that I don't need to know what you want to do up front. I need to give the LLM the architecture, the shape that says, hey, to make this into reusable automation, think in terms of models. Think in terms of data persistence. Think in terms of workflows. think in terms of the relationships in between them think in terms of inputs and then i provide tools to make those things get validated across the line so like you know did you write a model that is correct call swamp model validate it'll tell you you know it'll look at how you define the model and whether the inputs are right or wrong and so now the vm doesn't hallucinate when it creates its own models because it can just validate that the things it makes up are right or wrong you know on and on yeah yeah it's so cool so a little bit into the weeds here but does that run on the actual proxmox host or does it call the api from a machine that has ssh like how does that work runs runs from wherever you want it to run so you can run it like just literally go on to proxmox do your curl command to install yeah 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 in a world unexplored and what is that world unexplored oh there's so many unexplored worlds yeah like tech definitions and workflows oh i mean like yeah there's so many extensions that we can build so that's that's one part.
52:58I mean, another is, uh, 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. Um, 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, 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.
53:33And 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, um, a, he was trying to run like a 10 year old version of Mac OS 10 on a QEMU instance on a Linux box and it failed.
54:12But 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
54:59sick well friends you know i'm a big fan of tail scale and you know what i could not do anything i'm serious anything without my tail net i'm here with my good friend alex kretschmar from tail scale alex how do you describe tail scale versus a vpn how do you describe tail scale to someone who's not in the know.
55:17Adam Jacob: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 backend. With Tailscale, every device makes a connection directly to every other device. And that means effectively you're cutting out the middleman and you get much better performance as a consequence. And so that mesh network that you've built you've got to have a way to control how the data flows between different devices because you don't have that central choke point anymore we have a thing called access policies which allow you to granularly define using acls and grant policies which nodes are allowed to talk specifically to which other nodes on which protocols on which ports and which users are allowed to even connect to different things all over the tailscale encrypted tunnels which underneath use the WireGuard technology.
56:09Yeah, it's not my LAN, it's my TAN, my Tailscale Area Network. But your word for it is Tailnet, right?
56:16Adam Jacob: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.
56:54Well, 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.
57:31why the name swamp adam oh uh 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 We'll be right back. Nice. It's a throwback to the roots, I suppose. Or is it 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 the, you know, like if you go to Swamp Club, you'll kind of see why we like it.
58:13The 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 little time ago. Yeah, 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. because the agents are off doing what they do and there's got to be some joy for the humans. What are we doing with our time while it's writing all this reusable workflow magic? I want to be leveling up my Swamp Club leaderboard.
58:53You know what I'm saying? Now, how does that happen? What do you do to level up your Swamp Club leaderboard? 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 um 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 the all the different ways you can use swamp like publishing extensions and people using them and all that stuff will increase your score so like but we're not going to tell you exactly how we're going to and we reserve the right to change it season over season so there'll be different seasons of swamp so if you like sign up for swamp now you're in season zero you know you're an og swamper for 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 because it's fun because it is fun it it seems fun it is it's so fun give me some marching orders then let's say done with this call Now, mind you, I've got some travel this Thursday, so it'll be challenging to find this time without all my infinite time.
1:00:08It's cool. The agents do it for you. Yeah, but I mean, 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, while I want to just have my agents always be busy, I kind of don't. 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 software at an incredible rate. I'm still making software. It feels very much of a piece. But yeah, what are your marching orders?
1:00:41Well, I have a Proxbox box, so let's just stay there. How would I use Swamp to play with that ability? It's really, really straightforward. You're going to go to the website? It goes Swamp Club? you'll install the binary. Start install. Yep, you'll curl bash it. Then you're going to make a directory called whatever. Adam plays with swamp. Adam proxmox. You're going to type swamp repo init, which turns that empty directory into a swamp repository. Sets up a couple things for clod, puts some skills in there. Then you're going to type clod, and then you're going to say the first thing you want it to do.
1:01:24so you're going to be like maybe it will be or codex you pick pick okay cool yeah when you run repo and knit you could decide um i'm a clog man myself but you know you do you should i uh dash dash dangerously skip permissions or should i just i wouldn't you know no because i like you know but you could uh i'm a big plan i'm a plan mode guy myself okay so uh so if it was me i would i would put, uh, I would put it into plan mode. And then I would say using swamp, uh, 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.
1:02:17And then it will build a method on a model that it will build a model of proxmox it'll build a method called probably something like list or inventory and then it will use the proxmox cli to go get that list and grab all the data and store it as a data structure inside swamp and then you'll say something like uh 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 your all the proxmox things you have and then you know you'll ask it to do something else. You'll be like, uh, go create me a new one. And that looks like the other one.
1:02:52And it'll, it would do the same. It would write you a method. It would look at the data, you know, and like, you just, 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 um and like you know we have people publishing somebody published this morning like support for managing github repos uh and running security scans somebody else is doing talos uh kubernetes management and provisioning honeycomb s3 ubiquity digital ocean hetzner like config management.
1:03:47Like 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 back up the server then upload the ISO to Hetzner 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?
1:04:38of course amazing yeah I'm saying yeah so just ask me if I wanted to use the extension search prox it's actually yeah searching proxmox I guess to find this stuff yeah because there is a proxmox one already it's going to use key 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. Who's this person? Keeb. Who's Keeb? Keeb is one of the people who built Swamp. Next time mates. I would say yes.
1:05:19I would trust Keeb. Sweet. Here we go. We're trusting him. Uh-oh. It's going to figure it out. That's okay. It's going to figure it out. Swamp extension. Be like, yes, yes, yes. Go ahead. Fine. Yes. Yes. 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.
1:06:00For the audio listeners, we have something on video later. Yeah. We may map around this for the audio folks is less you know less tantalizing yeah I mean what Swamp's doing now is like it's searching 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?
1:06:39Yeah. It's asking me these questions right now? Is this 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 and where is Proxmox server? Endurance is the node. Yeah. Let's see what happens here. We're just prompting and wishing at this point. Praying. Good. Node is endurance. Gotcha. Sweet. Have you stored your credentials yet? The answer is 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 up. If you know your Proxmox username and password. I do know these things, yes.
1:07:16And where would I put this at? In the same, where would I store it at? Yeah, so you're going to, the repo knows how to store them. It'll basically encrypt them for you. So the commands 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 open a 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?
1:07:52Yep, you want to be in that directory. In the directory of my vault or my project? Yeah, wherever you use swamp repo and knitted. Okay, dope. Value for? 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. Stopping and pasting. Now what do I do? If I say the vault, okay, yes, they're stored. Now say 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.
1:08:30Uh-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.
1:09:07Okay, let's see if the auth is correct. And now it's actually running auth. So what it just did was run auth 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 do you have a nothing drawer in your house i don't know maybe you got a 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 some stock vms okay yeah what you got up top though look at that oh there we go oh oh oh they're my homies there's my home and what's worth noting here a lot like while you did install this VM like while you did install an extension you didn't have to if you hadn't it would have just written it for you so like you know but now you could ask it to do something like is there one you want to clean up is there one that shouldn't be there let's see like I guess this one's probably dead potentially this is definitely dead okay so tell it to delete tell it to remove Fedora 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 look up 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 VMID 105 currently stopped this will we're going to cancel it that's scary we don't need this thing Let's see what happens here.
1:10:58Gosh, 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. Swap model run delete. This is the thing it made on the fly. Yeah. Pxm fleet. Yeah, and now it's going to delete it. Pxm fleet is the definition of your particular Proxmox model, of your particular Proxmox server, which now it's issuing a delete command to in order to remove Fedora Boot C 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.
1:11:35And tell it not to run it. But don't 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 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. So if you think about this as like deploy my stuff to production. Could I then tell it like, hey, I don't like this command could you make it nicer and it would make it nicer? Sure, yeah, sure.
1:12:13Use an adversary to be like, hey, what could I do to improve the user experience? What it does, auth job, re-authenticates with Proxmox, get a fresh ticket, totems 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. 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, be like reboot. You know? don't do that man I'll lose you but my Dina server's 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 reasonable 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 2 giga RAM 2 cores 32 giga disk on local LVM and a bridge network all very sane defaults, right?
1:13:19Right. 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 swamping. like it doesn't know how to find ISO images so it's going to figure out 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.
1:14:02Family 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 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 okay 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?
1:14:51Or 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. it 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 because they're like well what'd you do and you're like i just told it to like write me a workflow to reboot proc box 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 i just kind of wished and it did it i just yeah i just sort of talked to it and then it did what i wanted and like you've kind of rendered my cli useless in a way yeah in a way there's still some things it does that i'm sure based on what i've seen that swamp could do fairly easily and it built 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 right like if like we're going to publish a bunch of models for all the cloud providers right oh which will be really convenient so you don't have to write them and get coverage real fast.
1:16:09But if we missed a thing or there's something you want to do differently, it'll write an extension of the extension. 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 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.
1:16:46And, 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, I don't know.
1:17:20You know, like if you don't know what pixie booting is, like you could ask it to explain, you know, and that'd be helpful. But like, you still have to know what you want. But the layer that you know what you want is the architecture layer. You know? I know the shape of how I want these things to come together. I'm not sure how to feel about what I've seen here. You feel good about it now. I'm very excited, but I'm also like, what can't it build? What can't it do? I don't know. Given infinite ability to extend it, if the extension doesn't exist, then obviously you have to probably create the extension.
1:17:56Or can't it just 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. Okay. 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.
1:18:34Two 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 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 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?
1:19:13Okay. 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 I, my audience knows that like, I usually say babe is the first thing I say when I'm dressed with my wife. Never her first name. It's always babe because I love her to death. And I'm like, babe, what you understand is that all the software we use now is going to get better.
1:19:47It'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 or you just do more and do better software less bugs less buggy software or or you'll just build the things you want all the time and like just in time software for everyone like me i don't know software i don't know because i don't because it's it's really hard to see it is very hard to see beyond one order of magnitude impact yeah and so like you So the question of, well, what can't Swamp automate? And the answer is nothing. Swamp can automate anything.
1:20:29And it's like, well, it can't just do anything. 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, imagine 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 and even like the counter arguments that people make now where it's like well now you have to maintain it and deploy it and i'm like well but if deploying it just looks like telling swamp bull 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 and when you think i just don't know that i care i know why i used to care lord you know i know why i used to care I used to care.
1:21:47It made sense to care. Because 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 something else can move at such a faster pace and potentially dramatically better in almost all cases. 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. you know and like it opens the door to wild things like what's an operating system look like that's designed like swamp get out of here adam right what's a what's i don't even know i don't even i don't either but but but you're thinking about it now and like well i just i think about like what what kind of interface does the future human want to use yeah you know what i I mean, that might not even matter.
1:22:46Will we even care about the operating system? Like, sure, there's something there. But do I care anymore because I'm so distracted away? The agent will care. The agent will care, yeah. And the human will care. Someone, some human being will care about the architecture. Oof, man. The same way that we care about architecture and houses. And, you know, like we will care about, that is still a skill that will not be removed. you know you still have to know how to describe how software systems work and how to build them and like all that stuff but like you know people are afraid about how do we train new engineers i don't know how many like like new grad engineers you've trained but i've trained dozens probably and like you know they all come out of school and they know how to program but they don't know how to program together on a team and you know like they learn over time sort of how all that stuff comes together.
1:23:38Now 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, 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 bananas the same as like you know when you're choosing your next stack and you're agentic you're an agent 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 you would maybe choose bun as an example like as a directional thing you know because whatever right and if you know those different things you can choose the right path but you don't have to know all the details of what makes bun bun or yeah 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.
1:25:02And just, I want you to rewrite the whole of Postgres and Zig and I want a hundred percent compatibility. And it's, you know, he's going to be done in a month or two. Just for fun. I like that. Yeah. Just because he can. Yeah. This is a bananas kind of world we're living in, man. Yeah. Yeah. And like, but that's why I'm so stoked about Swamp because Swamp, like what I love, I love the operational pieces of that puzzle. And so Swamp is us being like, great, yeah. I don't want to wait. I want to lead. I want to figure that out. I want to like, great, what does it look like to build automation in an age where agents can build anything for you essentially at speed?
1:25:46And the answer is, I 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 could just say infinite ability which you can do with it in a way where people kind of wish their life into OpenClaw or NanoClaw. I mean, you certainly could. You could absolutely put a little agent loop around it and be like, giving OpenClaw access to Swamp, it would automate. What would it automate for you? The answer is a lot. It's just 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?
1:26:26What are some things that might be centered and maybe left the center a little bit? Yeah, I mean, I found the Wi-Fi use case to be so out there. Like imagine telling Terraform to solve your Wi-Fi coverage problem. You know? Yeah. That's just not a thing you would ever do. Right. And you can imagine writing a program for yourself to do it. But the person who did that, they have a reusable piece of automation they could hand you right now where you could install the extension and run debug my Wi-Fi. And it would just do what he did. And it would just work. That's crazy in the world of automation like this.
1:27:16And then once that's true, like here's another example. it turns out that once you try to make it work as well as it could for agents, the way that we've thought about the language by which you define things is wrong. So here's a good example. Traditional configuration management, right? Puppet, chef. You build like resources that describe the state of a thing you want to have work on a server. So you're like, make sure this package is installed or whatever, right? But it thinks about each of those things as a separate declaration. And one pattern that exists in Swamp is what we call the factory pattern, where you can define a model that then generates lots of possible things, like a factory.
1:27:59And 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 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.
1:28:38So 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, 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.
1:29:14and then use John's VM inventory harvester to tell me what happened. I don't know. 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 I'm really excited to start building the higher up the stack workflows that are just like, look at this source code, analyze it. I want you to deploy it over here.
1:29:52I 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, got bombed. One of the people who's most excited about Swamp works, does a lot of data sovereignty for Sweden. so he's like currently running around going to folks in Sweden being like this is it we're going to use this thing to like get sovereignty yeah so I could be able to say look at this software look at this you know pick your stack whatever look at this software and I want to deploy it to render I want to deploy it to fly or you know what I I've actually personally I don't deploy to AWS because that's not where I play.
1:30:41I play in some of the more public clouds, I suppose, the developer-friendly ones. Because their docs are kind of terrible and their UI is kind of suck. But if Swamp can diminish all that to a question or look at the code base, deploy to EC2. I deployed my application to DigitalOcean. I want to move it to Metal VMs in Hetzner in Austria. And before you do that, set those VMs up.
1:31:10Adam Jacob:Yeah. And build, it wouldn't, 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. Well, I suppose. Almost surely. I'd be surprised if it didn't, but yeah, the more, look, the more specific your prompt, the better the outcome. Right. You know, we talk, and so like, we're talking about all the wild things you get from a single line, which is true, but like, yeah, of course, the more specific you are about like, Like, make me a model that does X or a workflow that does Y.
1:31:39The 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 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, uh, 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.
1:32:22I don't get any of this. If you're in the second or third case though, where you're building a factory, the reverse question is actually more important. How would you possibly operationalize anything else? Like, forget about Swamp. Well, you pretty much render my CLI useless. I mean, I'm going to play with it, and it's going to be better. 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. Like, think about it.
1:32:58The 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. 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.
1:33:38The 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 you at right now with this with that problem those problems i would say we're in And it's like alpha.
1:34:17It's like we're going to do our best to keep it backward compatible and not eat all your data. But 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. And I mean, I'm kind of flabbergasted by that. I really am. I mean, of course, my SH key got it in, and I gave it my user pass and that it did that. Yeah, but what's cool about it? Yeah, I mean, that's not a lot of credentials. That's a lot of credentials that give something, but then it just sort of like sleuthed the system. Yeah, the first thing it did with it was generate new credentials for you so that it was using an API key you could revoke.
1:35:05Is 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, 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. Because 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?
1:35:39And it's like, oh man, what it's going to do is off to Proxmox, get a token, and 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. You know? And where are those tokens stored? Do you know by any chance instead of Proxmox? Like where you would like go and provision that so I can go and see like this is the token?
1:36:11No idea. I have no idea. I've never actually created a token. I've just used my user and pass to get there. I mean, I actually was, you know, my SH key being replaced. Yeah, maybe it uses a long, maybe what it's doing is storing the user token and the user token has an expiry. I don't know. But I think it creates a token for you. That's interesting though. But yeah. And like what Swamp does is encrypt that stuff with a key, you know, for you. And then, yeah.
1:36:40Okay, Adam. Swamp. super fun how have you thought about money yet do you care about money i know you care about money but like i care how is this a business i mean considering your history and where you've been and then yeah you know the product product not market fit you know how do you know product market 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 gonna get solved i'm thinking about probably get solved i'm gonna solve this problem and when I solve this problem and you love it, if those two things happen, then money will happen too.
1:37:19And the software is open source. It's a GPL V3. Like, you know, like I'm going to make money on it. And what matters is solving the problem, which is how do you build automation at the speed with which you can now build software? And if I solve that problem for you today, in the era where we're all figuring out how to build our software factories. You're going to use that. You're going to use Swamp to build that factory. And we are going to have a relationship and that relationship will eventually lead to me getting paid. But step one, you know, in a gold rush, sell shovels.
1:37:59Hey friends, I'm here with Dan Mangus, co-founder and CEO of RWX. Dan, what makes RWX and the way you're doing CI so different and interesting to our audience? 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.
1:38:35The 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.
1:39:12It'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 in 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.
1:39:49Whereas other platforms are having to run the same setup steps on the same jobs in every virtual machine that's spinning up, RWX can run the setup once on one machine and then fan out accordingly based on just your dependency graph. So effectively with RWX, you never have to think about parallelization at all. On other platforms, it's always like, well, do I add this onto the existing job? Do I make a new job for it? But then I have to duplicate all that setup. With RWX, you 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
1:40:37what 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 from, you used to have to do this whole circle, now you're just like, 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.
1:41:23So 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?
1:42:08I 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 Neo clouds, they actually kind of pointed a finger at this where like those data centers they're building for inference and for LLM use, fast networks, raw compute, fast disks. That's it. Fast compute, fast networks, fast disk. They want as little software as possible in those data centers. They're running almost nothing except operating systems on networks, big flat networks. And if you try to imagine managing that with the old tools, you're like, but if you imagine managing it with something like swamp, you're like, yeah, okay.
1:42:51Like, sure. Give me the raw data about every VM in the data center. And that's all agents care about. Yeah. And every workflow that's running across it. And if I want to rebalance the workflow, just write me a workload. I don't need Kubernetes to go into a controller. I'll just ask Swamp to rebalance the workloads and it can go grab all the data and then do the analysis and then do it. And I don't know that that's what happens and it's not what I'm trying to do. But like, you know, cause 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 uh 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 gonna see agents collapse it into basically nothing yeah that's hard to hear and fun to hear at the exact oh it hurts my heart oh it hurts my heart well my whole career building trying to make that easier for people operationally it 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 like because even 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 and then you can't unsee it you can't imagine building one thing at a time now you actually have to like be building five different things at once so back 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 know like you used it for two minutes and like you know okay like once you learned to trust it and you knew yeah okay i know what a workflow and a model is and vaults and i know how that like once you trusted the architecture you just start letting it rip and once you start letting it rip like you're like well i could do that i could do that i could do whatever, you know?
1:44:56Oh, 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 and 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 again. Let's do it again. It's a fun trick, You know, and like I, the, the repercussions across the board are just, they're so massive.
1:45:30And, you know, Swamp is the place where I can be the most effective because it's the, 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 um and you know we can prognosticate about how but the only thing I'm certain of is it's going to change and change very rapidly in a way that will be excruciatingly uncomfortable while it's happening like so uncomfortable while it's happening yeah that's kind of where we're at like there's a lot of uncomfortability you know two Thursdays ago not last yeah two Thursdays ago we had black Thursday for block.
1:46:22Um, you know, it was like 4 ,000 people let go blamed on AI, you know? Yeah. Oh, I 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 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 my overhiring problems.
1:47:06I don't know why I gave him an accent like that. But like, you know what I mean? But like, even if that's what you believe is that he's like a cartoon villain. Like, no, no. No, he's not a cartoon villain. And like the justification for him. He might be far removed from how he thinks, but he's pretty methodical in how he thinks. Sure. And like, and what's clear, he's seen what we've seen. He knows what we know. 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.
1:47:44I still don't know how he turns it with six. I mean, like, like, like blocks going down, turn it or do you mean what do you what do you say? No, I mean, 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.
1:48:13So like, even if you take the cynical side, it was still AI that did that. And when you look at the people who have to think about what I have to do for my business in order to navigate a change of this magnitude, which we have never seen, there's never been a change of this magnitude in our industry. It was always slower. Everyone I've lived through was slower by a huge pace. The cloud is nothing compared to what 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.
1:49:06and, you know, hopefully you're going to leave here having played with Swamp and you're going to be like, who I got to play with Swamp some more. And it's going to continue to change your mind about what's possible in that layer of the stack. And once that happens, suddenly you're going to start to empathize with Jack. You're going to be like, Oh no, what do I do? And, you know, like I, 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.
1:49:38You 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 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 have to change now.
1:50:26Because, yeah, it's going to be rough. It's going to get rougher. Play your flute, man. Say what you want to say right now. What's the drop-dead way you can say what you want to say? Yeah, I think every single engineer 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.
1:51:20You got to start figuring out how to build systems that write the software that writes the software. You got to start thinking about how the world's going to look in this new age. And you got to start rewiring your brain. And, you know, especially if you were a software developer who, you know, be honest with yourself, if you're the kind that attacked code from the bottom up, you know, you looked at the source code, you read it, you beat on it, you hacked on it. You were, you know, you were a high velocity software developer, but not a good architect. You got to slow down and become a good architect because that way of learning is now a dead end.
1:51:54And that's a real bummer. You know, that's like a hard, 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. That's no other way around it. Yeah, you don't have a choice. The only choice is whether you're going to do it now or you're going to do it later. And if in the middle is a bloodbath, yeah, because the impacts on business and industry and valuations and monetization and revenue and on and on and on are all very, very difficult, then you want to 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?
1:52:45You want to be the one who's raising your hand being like, I know what to do. you know i have already you know i already i already know 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 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.
1:53:24You know, that's such a hard thing to swallow, but you got to, you just got to swallow it. Like 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 like more fun. It's orders of magnitude faster. The things you can build are absolutely wild to not be building them is just an absolute sadness. Like it also sucks that this thing that we love to do, that we had built all this expertise around and had learned to love in a particular shape is no longer the way that we're going to do that moving forward outside of small isolated pockets.
1:54:01And yeah, my, my truth is you got to get over it. Like you just got to, you got to feel your feelings, cry about it, complain to your spouse, you know, Adam's got I'd be like, babe, babe, I think software development's dead. You know? Oh, she knows. I mean, she's well aware of the change. I've been telling her since last. I don't think software development is dead. Like, I know this sounds harsh, but 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.
1:54:35Like, 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. oh okay um 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'm i got it by the gallons and i am man i'm peeing every two seconds that's how much i'm drinking kind of thing like yeah what what do they do to keep i mean they may already know but like given what you've built here and the level of automation because you've got software that can move so fast.
1:55:41Now, 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. So I think another, the other is most of us scoffed at software architecture. You know, we just didn't actually, we didn't learn software architecture. We learned how to be software developers and then we became engineers and we sort of learned it through attrition. And you got to go back and learn that as a discipline that you can use to communicate clearly.
1:56:23So, you know. Any recommendation on that? Books? Talks? Yeah, I would. Domain driven design. Um, um, 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.
1:57:25and 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 and when you know 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. And you gotta 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.
1:58:02But 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, their first answer to the problems you encounter should be, can I use more agents to solve this problem? so you know anywhere where where you're tempted to have the answer be this is where the agent part ends you that's probably wrong you know like like i was pretty sure that it was in 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.
1:58:54You know, more LLIs. Is some of that stuff secret sauce or how would you categorize these adversaries and what you've learned about architecture 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 who doesn't, no one can ever accept contributions ever again if they're going to work at this rate of speed and they want to maintain supply chain security.
1:59:51Your 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? Did you ask me to do some nefarious stuff? Because I can grok that at the level of us, you telling me what you want.
2:00:34I can understand if that's nefarious, but I can't understand it at the level of you sent me a 5 ,000 line pull request. Did I make sure that you didn't send all the data to someone I didn't want you to send it to? So yeah, it's open source, but it's not open for contributions at all. It's completely closed. And the way you contribute is you file an issue. And when we get around, when we then work that issue with our agents, when we commit the code, I put you on as a co-author. Nice. But I don't accept your, I will never accept a line of code from anyone ever. That's dead for you. Is it dead for others?
2:01:13Should 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 through this transition.
2:01:52Because I think they're more important now than they were before. I don't know exactly how that looks. I don't know exactly how those values get reframed. But it feels like they need to be. And 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.
2:02:32But what is very clear to me is that the middle ground is, is death. So like, you know, just being like, I take pull requests and it's okay if you use an LLM to show, 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 are 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 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 and go one layer deeper?
2:03:20Do you have enough time for one layer deeper or are we getting close on time? Yeah, man, we can go one layer deeper. The layer I want to go deeper is maybe, and maybe it's not, maybe it's just sort of backtracking in a way, but you mentioned the friend with 100 to 1 ,000 engineers. And I just think like if that's the truth, which I'm feeling that truth as well, but I'm a team of one so my feedback loop is very tight because I'm a singular individual. Yeah, yeah, yeah. And the way I coordinate and talk to the world is through podcasting and other means. 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.
2:04:04Is this, is that I think like small teams, like I just wonder 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 i have no doubt that we will does that make sense like yeah 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.
2:05:19But now I can change software to custom fit at will. You wrote a Proxmox workflow while we were chatting, and it 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.
2:06:03Will 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 100 engineering team to 1 ,000 down to 4 or 5 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.
2:06:50Your 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?
2:07:29Like 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 uh 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 are 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.
2:08:32So 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 what I've been, that's kind of where I've been camped out. That's why I take the positive case.
2:09:12Well, you have to. You have to be on the positive side. I do agree with you on more software. I think that software gets more and better. I do think that everyone needs to have a reckoning with themselves that - It's going to go like this, you know? And in this, we're like, we're like here and the roller coaster ends like somewhere down there. And then, you know, below the screen even. Yeah. It's going to be bad, bad in the middle. And I don't know. I wish it wasn't like, I wish I knew how to avoid that. And I just got predictions on bad, bad. I mean, what is bad, bad when you think, when you say bad, bad, what is bad, bad, Adam?
2:09:51I mean, whatever, 4 ,000 people getting laid off from block. That's bad. That is bad. I mean, that's 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 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.
2:10:39It's not like, you know, in that story, like those layoffs happened because what was happening was the company I worked for was a sham. and so when you got laid off from the company you worked for that was a sham you were like well you know say la vie that was weird you know but you like went on with your life but like when you get laid off from block and block keeps blocking and not only do they keep going they accelerate how's that going to make you go up so you know yeah yeah how's that going to make you feel and then how as an industry do we reckon with the fact that we need those people like we're going to need them.
2:11:15But 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.
2:12:02It'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. Cause it's true. It's true. Cause 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.
2:12:42You 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 of what you built? No, because of what I'm saying. Oh, yeah. Yeah, well, that's obvious, Adam. But yes, okay. You know? My thought there is, and maybe this is not exactly, is to go away from the Silicon Valley world of building software. Go out further into the field, so to speak. Yeah.
2:13:22And 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 SASSes 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 and their interest. I think all that's going to be real. It is real. That's the stuff that gives me hope across the horn for that.
2:13:56It'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. Like 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. Cause I don't know how high the water line is going to go.
2:14:41But 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 flood's 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 like understand the full stack and i don't mean like full stack front end but i mean like build something from zero idea to actually deploy it maybe even with swamp yeah definitely with swamp definitely with swamp uh 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 uh and i'm like I don't understand a developer in these days that doesn't have Proxmox or a Homelab or Incas or a slew of VMs in their home network and they're not playing with something.
2:16:31I 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 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.
2:17:17Yeah. Went from nobody on the internet to everybody on the internet in what? Eight years. From like zero to, or, 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.
2:18:00And, 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 yeah you know yeah one shotting something is is uh i mean you can do it well but it's like my but not really 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.
2:18:58And 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 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 these rot 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 gonna go but but in between there's gonna be a lot of people that like fold their arms and are like you know those people are gonna 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.
2:20:15I 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. If you don't think so, then we'll, I mean, And 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. So, yeah. I'm going to be up there with you all here shortly.
2:20:50Because 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.
2:21:39And 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.
2:22:11I 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 cause whatever it's complicated, but yeah, you know, I understand your perspective. You, you have good intentions. you have goodwill for folks. And sometimes it doesn't translate to that. Yeah. And as much as, and like, you know, Swamp though, you know, turned out we learned a lot and that led us to be able to build Swamp and watching Swamp do what Swamp does. Like, I believe in the future of, like Swamp is the future of how you're going to write that automation.
2:22:50And 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. So, and that's kind of interesting now because if swamp is a critical component to this thing I build, well, there you go. There's the, there's the toll booth for you. that's what I'm saying I just I just need to sell you shovels I'm gonna help you build the thing you want to build I'm gonna be fair and kind and you know like I'm there's plenty of business to go around if I solve those problems which is what I'm gonna do so yeah I'm just gonna focus on solving that problem for people and and then you know come hang out in discord and tell me where it needs to improve and then watch what happened watch the speed with which we will implement your feature suggestions it's sick it's sick show up you'll be like you'll be like i need x we'll be like x looks good then i'll post a plan you can go read then i'll implement it and close the pr we 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 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 but get to it what are you waiting for Swamp Stack Club I'm telling you this is insane this is insane that's all I'm gonna 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
2:24:47alright 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.
2:25:23I 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.
2:25:51Win it, win it. It really whips the king of men.
From the publisher
This week I'm talking with Adam Jacob, founder of System Initiative and creator of Swamp, about what happens when AI agents change the entire shape of software development. We discuss how he went from an 18-person team down to five and shipped Swamp 900 times in four weeks, why he brought User Acceptance Testing (UAT) testing back from the 90s, why software architecture (and domain-driven design) suddenly matters more than knowing how to write code, the live demo where I pointed Swamp at my Proxmox box and watched it write its own automation (blew my mind!!), and why he'll never accept a pull request to Swamp, ever.

