1049: WTF is a Software Factory?

Scott and Wes talk with Adam Jacob about software factories: what they actually are, why they’re unique to each team, and how to build trust in agent-generated code. They dig into Swamp Club, black box testing, domain driven design, adversarial review for accessibility, and whether unit tests still earn their keep. Show Notes 00:00 Welcome to Syntax! 01:10 What Is Swamp Club and Adam Jacob’s Background 02:37 Scott’s Personal Automations: Cleaning Folders and Filing Sentry Bugs 03:28 Where Does This Fit If You Already Run Claude Code? 07:22 Brought to you by Sentry.io 07:46 Swapping Models and APIs: Flipping the Agent Loop Inside Out 09:40 Pricing and Bringing Your Own Inference 10:18 What Is a Software Factory, Really? 14:50 Shipping 2,500 PRs a Month: Trust, Automation, and Black Box Testing 16:55 Software Factory or Slop Factory? A Perception Problem 19:06 How Big Companies Can Start: Give Five People Permission to Break the Rules 24:16 Who Has Actually Pulled This Off So Far? 25:54 What Do You Do With 10,500 Engineers? 28:56 The Vibe Coded Adobe Suite: When Does This Stop? 30:24 Personal Software: What If Software Got Smaller, Not Bigger? 33:51 Testing With AI: Black Box, Integration, and Deleting Your Unit Tests 39:03 How Do You Validate Trust in a Factory? 39:30 Domain Driven Design Gives Your Agent a Vocabulary 43:12 Adversarial Review: Accessibility, Lighthouse, and Fixing the Machine 46:17 Why Skills Alone Aren’t Enough 49:00 Figuring It Out Together: Engineers, Not the Labs, Know Their Systems 53:53 Sick Picks + Shameless Plugs Sick Picks Adam: Dell XPS-14 running Linux with Omachy, Lorna Shore Shameless Plugs Adam: Swamp Club, Swamp Club Discord Hit us up on Socials! Syntax: X Instagram Tiktok LinkedIn Threads Wes: X Instagram Tiktok LinkedIn Threads Scott: X Instagram Tiktok LinkedIn Threads Randy: X Instagram YouTube Threads

Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.

• 0:00Speaker 00

  And if you go ask the people in the labs, you're like, hey, do you know how to do this? They don't. They don't know. They're not better at it than we are because we're the ones who actually know how our own systems work and they don't. How do product people feel about that? The answer is bad. They feel bad about it because their job is to tell engineers what to do and to be ahead of them. And you can't stay ahead of them because now they can produce outcomes at such a fast rate that you couldn't possibly keep up. That personalization layer is the sort of interesting newest frontier where it's like, ooh, what if software got smaller, not bigger?

• 0:35Scott Tolinski?

  Welcome to Syntax. Today, we're going to be talking with Adam Jacob, the CEO of Swamp Club, all about software factories. Software factories, it's a hot-button topic, things that people either get a lot of stuff wrong with and/or maybe that just feels like a giant mystery to them. Like, how could a software factory even exist? I've used AI models and, well, I just prompt my way into getting something. Well, we're going to dispel some of those myths. We're going to dive in and we're going to understand all about what software factories are and how to use them. Adam, welcome to Syntax.

• 1:09Speaker 00

  Hey, thanks. Stoked to be here.

• 1:11Scott Tolinski?

  So, Adam, you are the CEO of Swamp Club. Would you mind giving us a little quick run-through about what Swamp Club is, but then also what your background is?

• 1:21Speaker 00

  Yeah, for sure. Yeah, Swamp Club is basically a way to build AI agents with determinism and some structure that sort of allows you to sit underneath those agents and describe, hey, here's what it is that I want to do. And then Swamp Club knows how to take what you're asking it to do and then break it down into modular automation. So it knows how to basically turn those things into components that have typed inputs and outputs. It knows how to then like wire those together into workflows. It knows how to refactor them. And when you ask it to do wacky things like integrate with arbitrary APIs or internal stuff, it'll just figure out how to like hit that API and do the right thing. And it has all the things that you need in order to build these sort of systems quickly.

• 2:06Speaker 00

  So it has like shared memory that gets stored in a big data lake and you can query it and all of those sorts of things. So people use it to do all kinds of useful stuff. So people use it to like run their production infrastructure or they use it to do like wet lab science and control robot arms. Or they like, I use it to read my email. Like, people do all kinds of stuff with it because what it's designed to do is basically take whatever it is that you need AI to do and turn that into deterministic processes that work all the time.

• 2:37Scott Tolinski?

  Yeah. Man, I've been doing a lot with this specifically. So even just give the audience some more examples too about what I've been doing personally because I use Swamp. I have automations that like keep my pie and its extensions up to date. I have automations that check my folder structure for my sites folder. I don't know about you, Wes, but my sites folder turns into a graveyard of just like making projects in different places. And this will, using Jev, it classifies things and puts things in the right location.

• 3:06Wes Bos?

  Oh, that's cool.

• 3:07Scott Tolinski?

  Yeah. Well, cleans up work trees for me, cleans up old Rust builds that are just taking up space. I got so many of these things that I've been... Oh, I have one that I've mentioned before on the show where it's pulling in Sentry bugs, cataloging them into issues and tasks, completing them and then creating PRs for me. So that's some of the stuff I'm using it for.

• 3:30Wes Bos?

  I don't get it just yet. I know Scott's been talking about it and I know that it's for automations, but like maybe you can just describe, and like people are probably listening right now, like being like, should I turn this off? I'm not quite sure if I understand. Like, where does this fit alongside somebody who is already running Claude Code or Codex or any of these things?

• 3:49Speaker 00

  Yeah, totally. So if you think about like the experience you have when you use Claude Code, right? So let's say you, let's use, let's use Scott's like cleaning up folders example, right?

• 3:58Wes Bos?

  Yeah.

• 3:58Speaker 00

  So if you just fire up Claude and you're like, hey Claude, clean up my sites folder. Here's the instructions. It will do something, right? And maybe it'll do what you want it to do and maybe it won't. And then Scott will write a skill. He'll be like, I know, here's the way I want you to always clean up my folder. And so he writes a skill and he's like, hey, here's the list of instructions about how to always like clean up my sites folder. And what's happening is he's basically spending Frontier Intelligence tokens, he's like burning tokens, so that Claude can from scratch reinvent that for loop over and over and over again, right? And so what Swamp does is take that same prompt, hey, I want to clean up my sites folder. Here's the list of my criteria. Maybe use Jev to classify it.

• 4:41Speaker 00

  And what it then does is take that intent, take that prompt and turn it in to modular automation on your behalf. So it knows how to like then take that and be like, ha, okay, great. I'm going to maybe start by building a model that has inputs. Then the input might be, what's the sites folder I'm cleaning up? And then maybe it takes an array of the criteria that he wants to measure it by, right? And then it's going to figure out how to actually go look at the sites folder. It's going to write all the code that actually does that. It's going to wire it together so you can call it. And then it's going to store a bunch of data about what it actually did. It's going to be like, hey, what was the classification result I got back from Jev, right? And it stores that as information, which then is queryable for other steps in the workflow. So it knows how to take that intent and turn it into working code.

• 5:24Speaker 00

  The result is, he's not burning Frontier Intelligence tokens every time he runs it and it runs the same way every time, right? Which is the most annoying thing about AI, actually, that like it was really smart and it did the thing I wanted and now, you know, I want it to do it more often. And so the way that I make it do it more often is I just, I go to the newest model and I pay more money, you know? I'm like, ah, if I run that skill with Fable, you know, it works most of the time. You know, it moved from working 80% of the time to working 90% of the time. And if you use Swamp, it'll just work 100% of the time.

• 5:56Wes Bos?

  Okay. So you're taking, and this is something I see all the time, is that like, instead of, I do it myself. Instead of like going and having a script written

• 6:07Speaker 00

  Yes.

• 6:07Wes Bos?

  for, for doing this task that I do every single day, I will simply just ask the model to do it for me and burn tokens on it. So you are, we can still describe what we want it done in natural language, but then it then turns that into a, something that you can run with just like a regular script?

• 6:29Speaker 00

  Yeah, you're going to take that thing and you're going to tack the word "with Swamp" on the end of it. And then what Swamp is going to do is break that down into modular automation for you. So like if you were to write that script yourself, right? You can totally just be like, write a Python script, you know? And it'll write you one. And then you have new interesting questions. How does that get refactored? How does it grow over time if it needs to, right? How does that, maybe he goes from having his site folder need to figure out how, how to classify itself to the automation that deploys his sites folders when they change.

• 7:03Wes Bos?

  Okay.

• 7:03Speaker 00

  And all of those things can be connected models. And it's sort of building you this web of automation that's already modularized, that knows how to factor itself, that knows how to work in this context and provides all the things you'll need as it grows. So you start out building these tiny little agents just for yourself, but over time you wind up building bigger and bigger behaviors.

• 7:22Scott Tolinski?

  And if you want to see all of the errors in your application, you'll want to check out Sentry at sentry.io/synthesis. You don't want a production application out there that, well, you have no visibility into in case something is blowing up and you might not even know it. So head on over to sentry.io/synthesis. Again, we've been using this tool for a long time and it totally rules. All right.

• 7:46Wes Bos?

  The other thing about like using an AI model to run these types of stuff is that you can just feed it stuff, like data that is messy or like not, not perfect or not implemented in a specific way, you know? Like I might, I might have done something with a one API and I want to do the exact same thing with a totally different API that, that looks different and authenticates different and all of that type of stuff. And that's what, that's what I love about AI because I could just say, hey, run it with this one and it'll figure out how to do that. Can it, is it like, can it heal itself or like?

• 8:18Speaker 00

  Yeah.

• 8:19Wes Bos?

  Go out to a model?

• 8:20Speaker 00

  Yeah, yeah, yeah. And it's roughly the same loop, right? So if you think about it, like what Swamp is doing is building you, is building an internal component that understands what that thing is inside the context of the job. So if you think about it as, I have a step, let's, let's use Jev as an example because OpenAI announced the other day that they're launching a decisions API that will be roughly Jev, right?

• 8:43Wes Bos?

  Yeah.

• 8:44Speaker 00

  Or Cloudflare already launched one, right? So let's say that Scott wants to shift to try one of those models. Because he's using Swamp, all he has to do is say, hey, make that a configurable option of that, of that component. And then what it will do is go refactor that one component to support multiple APIs, probably with an input option that's like use Jev, right? And so now like that step or use Cloudflare's version of the decisions API, right? And so what's happening is you've sort of reversed the loop where instead of going from the, from letting the LLM be the thing that's running the outer loop, you say, hey, the LLM is now calling in to a deterministic loop. And then that loop is calling out to intelligence when it needs it, right? And it's getting structured inputs and outputs.

• 9:27Speaker 00

  So because we've factored it so that the outputs are standardized, right? He knows what the decisions he needs to make are about that sites directory. Now he can plug and swap them and it spends less tokens and less effort in order to do it. Does that make sense?

• 9:40Wes Bos?

  Yeah, yeah. So Swamp Club is...

• 9:45Wes Bos?

  Like it's a paid thing, right? We should, we should say that you sign up for it and you pay per user per month.

• 9:51Speaker 00

  Yep.

• 9:52Wes Bos?

  And then do you provide the inference or does it work with our own inference?

• 9:56Speaker 00

  Yeah, you bring your own inference to the party. So like it's underneath whatever agent you're running, whatever harness you want to run, whatever models you want to use, like it plugs into those things and provides this behavior.

• 10:07Wes Bos?

  Beautiful.

• 10:07Scott Tolinski?

  Yeah. And you don't need to pay to use Swamp, Wes.

• 10:11Speaker 00

  You do in the end.

• 10:13Scott Tolinski?

  But not like just for experimenting with it for building your automations. Yeah, totally. Cool. So let's actually talk about software factories as a concept because people often talk about software factories. And I see a lot of the dialogue is always kind of all over the place on this, like you still need to babysit these things. A software factory is just producing slop or whatever. Can you dive into what a software factory is, Adam? And just to like clear the air for people who might not have a good understanding.

• 10:44Speaker 00

  Yeah, for sure. I mean, if you don't have a good understanding of it, like let's just lead with some empathy. I think that's like broadly shared across industry, you know? So like, I think if you asked, if we had five people on this podcast, they would give you five different answers about like what they think software factories are, which is part of why it's such a frustrating topic. My answer and sort of the growing answer of our community is that, you know, if you think about your traditional SDLC, so if you think about everything you do to figure out like what goes into the product, how do you break that work down? How do you then use that work as a team sort of and flow through that process all the way through to production? When we talk about a software factory, what we're saying is that as much of that loop as possible, in the end, probably all of that loop, other than inputs and outputs

• 11:29Speaker 00

  and maybe some spots in the middle are things that agents handle for you. So when you think about like, how am I thinking about putting work into the system? And then how does the system keep itself stable? How do we produce good code? How do we produce code that makes sense for the system? How do we make sure it's aligned to the architecture? How do we make sure that it doesn't regress and it continues to work the way it's supposed to? All of that stuff is the stuff of software factories, right?

• 11:56Scott Tolinski?

  Yeah.

• 11:56Speaker 00

  And so you can think of it as, as a replacement. If you think of your SDLC, you're taking as much of that as possible and you're turning that into a behavior that an agent is running on your behalf. And there's lots of different styles of doing that work because it depends pretty tightly on what the application you're building is, right? So like what it is that you're trying to make the factory produce is, is a very important piece of the shape and the details of the factory, right? So no two factories are the same, which is part of why it's confusing. And then the, the other piece of it is that sometimes the inputs look different depending on the team. So some people are starting those factories like all the way at the very beginning where they're just, you know, putting in a bunch of tickets and they're like, run these tickets

• 12:40Speaker 00

  to completion, you know, like a queue that's just getting, having a robot sort of minted out. Other people like us, we're a little more careful about what the inputs are, right? Where we keep a much smaller backlog or none. And what we're doing is, is standardizing the process by which the software gets produced. But that's, those are what software factories are.

• 13:00Scott Tolinski?

  Yeah, I think a lost on people in this conversation is often that a software factory, like you mentioned, is, is not just like a singular way of building a software factory for everyone, right? Like you, the way you see it is, software factories are individual to the project, the team and how, how they work, right?

• 13:24Speaker 00

  Yeah, absolutely. Because if you think about software development, just think about engineering, like the reason that any given product is good, the reason that any given piece of software is good is because of the decisions that are being made about how that software works, about how it comes together, about its internal architecture, about how it looks and feels to the end user. Like all of those choices, that is what makes your product good. That's what makes any piece of software good. And it's, and our designs are unique, right? Like the way that we think about those products and the way we think about what they do, they are by nature, unique to the people who are building it. And so when we start building software factories, what we're doing is we're trying to encode as much of that behavior and as much of that knowledge as possible into the system so

• 14:08Speaker 00

  that we can go faster from intent to outcome, right? And that the, and that the factory is the thing that's responsible for the output in the middle, right? And that's why the factory is bigger than just like, here's how I prompt Claude. You know what I mean? That's why it's not just, here's my, you know, here's my bag of skills and I do my best, you know? Because that structure is what's helping to inform the full shape of, of that factory to make it safe to say, hey, here's what I want the product to do and be, and then trust that the system will align the internals to the right outcome. And so it's always unique to the product you're building because the internals are unique. Does that make sense?

• 14:46Scott Tolinski?

  Yeah. Yeah, totally. And in, in that same regard, there's a post from Potato on Twitter. I don't, do you see, she did a video and a post about shipping 2,500 PRs last month for Grok. And she talked a lot about trust and automations being a part of it. Like, how do you trust the output of your agents? And then how do you verify that trust, et cetera? So I mean, that sounds to me a lot like a software factory is that, do you think that that fits into that same realm?

• 15:20Speaker 00

  Yeah, it feels like it to me, right? So like in our own experience, the, like, one of the things we have started doing in, with Swamp that I stopped doing, I don't know, 1999, 2000 era, was building like really big, comprehensive, black box acceptance testing suites. And, you know, we stopped doing that in the continuous delivery kind of era because it slows everything down. Like if you have a big acceptance testing suite that had to be written by hand by every engineer who was ever putting in a feature to the product, right? You were just like tripling the amount of effort that every engineer had to do. Everything took longer for what felt like marginal gain. Once you have a factory that's, that's responsible for aligning the software to, from intent

• 16:05Speaker 00

  to outcome, like what happens if it breaks the product? You know, what happens if that contract gets broken and you're not looking? And so the answer to that is black box testing, right? I need to go from the outside in to understand like, hey, does the product still work? You know, is it still doing everything you said it was supposed to do? Because no human was involved in this middle process. And so, and even when we were involved in the middle process, it's not like we avoided regressions, right? Like we ship regressions all the time. But in order to get to the level of trust that you need for the factory to actually accelerate the team, you know, like you got to build those things. Yeah, it sounds like a factory to me because you're talking about those, those, those elements of like, of trust, of repeatable automation, right? Like, how do I get the system to behave the same way every time as we go through this

• 16:50Speaker 00

  process, regardless of who the engineer or the product person is that's putting in the inputs, right?

• 16:55Scott Tolinski?

  Yeah. It's one of those things with software factories. I like, wonder if it's just like a straight up perception and marketing issue around the term, because I think if you ask most developers and you were to say, let's add some more deterministic systems for validating that trust. Or let's say, we want to standardize the process for something that happens over and over again. I think most people would agree with that being something that they needed. But in the same regard, a lot of people might look at a software factory as just being like a slop factory, right?

• 17:30Speaker 00

  Yeah. Well, because if you're not using these techniques, then you're, and you haven't changed your SDLC, it's awful. Like if the way your team is working right now is like, I've got 10 software developers and we're doing, you know, Scrum, and we have the same set of meetings we had last year or the year before, and we're doing the exact same work, only now we're firing thousand line PRs that were written with Claude that no one understood, that are poorly aligned to the outcome. And it's our job to like, deal with it. And all we've done is just cranked up the velocity because we can wrap out the code faster. Like, that's like being stuck in the worst part of the ocean when you're surfing, you know? It's like big wave surfing and it's like you just, you can never get past the breakers. Like it's just going to constantly murder you.

• 18:14Speaker 00

  And so like, the way out of that process, paradoxically, is more AI, not less. It's more, more automation, more structure, more having, having more of the system get designed. And that's why it becomes a systems design problem, right? Like, I didn't come up with the software factory word, but it is what people are calling it. You know, like I helped come up with like DevOps, for example, and I have regrets about how that word went out into the world. And like, I'm sure the software factory people probably have some regrets.

• 18:42Scott Tolinski?

  Yeah.

• 18:43Speaker 00

  About how that metaphor has taken hold. But like, you know, ultimately that process is the critical piece. And so of course it feels like a slop factory because your lived experience for the most part is that it is a slop factory. And so if somebody comes and says to you, hey, I have this technique that's going to make the slop factory go even faster. Are you in? You're like, absolutely not, you know? Like the thing that's killing me, I do not want more of it, you know?

• 19:07Wes Bos?

  I have a question about, like specifically companies that have lots of engineers and are sort of like looking at, like, how do we tackle this, right? You, like, you just gave an example of like 10 engineers, but I think about like, I remember hearing a stat that like LinkedIn has like 300 engineers committing CSS every single day, you know? Like just the scale of some of these things is like, what would you recommend to a company that has hundreds, thousands of engineers of like, like, how do you re-architect? How do you even start to change how you work with this type of stuff?

• 19:44Speaker 00

  Yeah, man, that's a good question. And I sort of believe that there's two emerging frontiers happening in AI. So like one frontier is the labs and all the things that they're doing. The other frontier is, is the answers to these questions, you know? Like, how do we as, as regular mortals, you know, like receiving the LLMs, figure out how we're going to build working systems that can still work, you know, first in the small and then in the large? I think the, the true answer here is that there's very, very few people, maybe none, but very few, who I think have figured out how to do that organizationally. The reason is that is less about technology. I'll get to that in a second about how, how I think I would run a project to try to make that transition.

• 20:27Speaker 00

  But the hardest part is that that transition sort of breaks everything about your existing work process, about the points of control, right? If you're a product person and you have a bunch of engineers who have a trustworthy software factory, they're, they could implement whatever they want to implement, they could refactor whatever they want to refactor, they could, they could ship whatever feature comes to mind without having to ask you questions and, and without having to need your permission. And so like, how do product people feel about that? The answer is bad. They feel bad about it because their job is to tell engineers what to do and to be ahead of them. And you can't stay ahead of them because now they can produce outcomes at such a fast rate that you couldn't possibly keep up. And so now your job is to look at it exclusively from the end.

• 21:12Speaker 00

  Your job is to like, review the outcomes of your engineering teams, try to align them to the theme, and then, and then, because it's, the cost of rework is so low, if you don't like it, you can change it. That is such a weird organizational pivot, that very few people have figured out, how do I restructure my organization in order to get these gains? One thing we learned from the last of these movements, which was sort of digital transformation, the cloud, all of those things, is that the first move is always the same, which is, you need to have a small team of people who experience what life is like on the other side. So instead of saying, how do I transform, you know, my 60,000 software engineers to use software factories, and thinking of it in the large, which is an intractable hard

• 21:55Speaker 00

  problem, what you need instead is to find five, and say, okay, you five, take this slice of a real problem that exists inside our environment, and I give you permission, and only you, to just break all of the rules about how we do everything. Like, you're allowed to break all the rules about how the org's structure works, and about how we plan work, and all of that stuff. And your only job is to figure out what it feels like to build a software factory end to end, that you trust, and that ships at this rate of speed, and that produces reliable output. And once you have one of those things, what happens is, those five people now understand both, what it feels like to work in your current environment,

• 22:35Speaker 00

  and what it feels like to work in the new, right? The lean manufacturing talks about those moments as kaikaku, right? It's a, it's a moment where some technology has come in, and it's forever changes the nature of the factory. And therefore, what we must do is redesign the entire factory around that new technology, because it's, it's now somehow dramatically altered the bottlenecks in the system. So, what you do is you take a small set of people, you get those people to know what it feels like, then those people's job is to then figure out how to translate that into the org ever larger. Now, the org problem with that, where that usually goes to die, is you have like, a VP or a director,

• 23:18Speaker 00

  who doesn't like the answer. And so, and so what happens then is they start to water it down, and we wind up back in the tough surf zone, you know, of like, hey, now, now we're all sort of drowning. The advantage you have in this moment, if you're in large organizations, is the vast majority of them have a mandate now to alter in this way. So, what that team needs to do, once they get assembled, is strike while the iron is hot, and show working proof in code. The more you get mired into the philosophical argument, about like, well, is it, is this good or bad for the org? Is it good or bad for the shape? The worse things will be. But the more what you do is show working software, and get working engineers to try it, you know, like, one of the great outcomes of working

• 24:02Speaker 00

  this way, is that everybody gets to be more creative. And so, people tend to love it, actually, when they get to the other side, even though, in the middle, they're like, ooh, I don't know how I feel about it, because, you know, because I really loved being a programmer, the way I was a programmer two years ago, you know?

• 24:16Wes Bos?

  Have you seen any large companies that have like, at least started to take this on, or switched how?

• 24:24Speaker 00

  I've seen people who have started. I have seen no one who has finished.

• 24:28Wes Bos?

  Okay.

• 24:28Speaker 00

  And, that's, you know, and I think that's true, even amongst my peers, you know, like, there was an era, it's slowing down now, but I would say, six months ago, I was averaging three calls a week, from friends, who, you know, my company was failing at that moment, six or eight months ago. So I was in the, I was in the position of having to wrestle with this, but not having customers, or, you know, not having any of those things sitting on top of me. And all my friends who did, have real orgs and real customers, like, we were just calling each other, and talking about the existential crisis we were all feeling. And I would say that, like, you know, largely, we're still in the phase where, where everybody is trying to figure this out, and we're now starting to communicate

• 25:11Speaker 00

  with each other about what works and what doesn't, which is eventually going to lead us down a path of like, being able to explain to each other how this thing works, and getting clear about what the right techniques are. But we're in the discovering right techniques phase. We're not in the, this is a solved problem, and people know how to do it, and you're just not paying attention hard enough, or whatever. Like, we're not in the, we're not in the phase where we all know what this is, or even that, that we've had enough experimentation to know what works. Does that make sense?

• 25:40Wes Bos?

  Yeah. And I, and I, I feel like you have such a good, like, your thumb on this type of stuff, because I'm just, I keep thinking about big companies like LinkedIn, and, yeah, once they get this, something like this in place, what do they do with, I just looked it up, they have 10,500 engineers. And, and this might not be a question people like to ask, but what do they do with 10,500 engineers? Do they start, can they possibly make something that, now that they're, everybody's running 10 times faster, can we possibly make something that is, that needs this many people? Or, or do we just have less engineers?

• 26:24Speaker 00

  I, I don't, I don't know. Nobody knows. And, here's my guess, my belief, is that, is that the answer is yes, they can. What we don't know, is what that is yet. Because, because what happens when you get this increase, like, what happens when a system changes that dramatically, when that order of magnitude jump occurs, everything breaks. And so, the question of like, sitting from where we are now, saying, well, what could those 10,000 engineers at LinkedIn possibly do to LinkedIn?

• 26:52Wes Bos?

  Yeah.

• 26:53Speaker 00

  And my answer is, a lot. There's a lot I don't like about LinkedIn.

• 26:56Wes Bos?

  Yeah, get rid of the bots, I guess.

• 26:58Speaker 00

  Yeah, there's a lot they don't like about LinkedIn, you know?

• 27:01Wes Bos?

  Yeah.

• 27:01Speaker 00

  And, and I bet that once they fix those things, like, we'll, we'll find yet more things, that we can imagine doing with LinkedIn, and we will want them to do it, and they will want to do it. And so, like, you know, the history of automation broadly, in, in, I don't know, the last thousand years, regardless of whether it was, was digital or not, has always been that it opens up the capacity. Everybody has this conversation that says, well, that'll be the end of whatever that job is, you know? And the result is actually just that that job changes, and we do more of it. Because, it has to be capped by demand, otherwise. And so far, we have not found what the demand is for software, what the

• 27:42Speaker 00

  demand cap is. And, given that software is infinite, right, that given enough compute and power, we get to continue to make it, and it's not like a resource that, that, that is finite. It's not like, by LinkedIn shipping 10,000 more times, there's less LinkedIn to go around, you know? Or like, you get to ship less often, because you took all the trees. Like, I don't know what the cap is on human software creativity. It seems like it's just getting weirder and faster, and that it will just continue to get weirder, and continue to get faster. And, and more and more of the system will have to adapt to the fact that that's true. So like, you know, I don't know where it leads LinkedIn,

• 28:23Speaker 00

  but it leads LinkedIn probably to some wild places. Because, everything that you couldn't do, because you didn't have capacity, or because you didn't have the ability, all of that is now swept away. I have no idea what the limitations are practically, of what you could build at this point. Maybe they're infinite, you know? Like, you could decide to build a new operating system to run LinkedIn tomorrow, and I bet you'd be, have a prototype done in a week.

• 28:50Wes Bos?

  Yeah.

• 28:50Speaker 00

  I bet you could probably replatform it in two.

• 28:54Wes Bos?

  Mm-hmm.

• 28:54Speaker 00

  That's insane.

• 28:56Wes Bos?

  It's insane, yeah. We're just sitting here right now, and we're looking at this like, vibe-coded Adobe Suite that came out, and it's, it's better than GIMP, which has been around for 28 years. It's way better than GIMP.

• 29:07Speaker 00

  Way better.

• 29:08Wes Bos?

  We're just sitting there being like, I, I had this feeling like a week ago, and I have a feeling again? Like, when is this gonna stop?

• 29:17Speaker 00

  The answer, the answer is never. What's interesting about it is, what nobody has done yet, is made me a better one.

• 29:23Wes Bos?

  Yeah.

• 29:24Speaker 00

  Like, why, like, is that still the right shape? What they did with it is be like, hey, let's go rebuild the Adobe Creative Suite. That's cool, because the Adobe Creative Suite was cool, and because I didn't have access to it, and because, you know, whatever, that was complicated. But what's gonna be cooler, is when, what happens is, you start thinking about like, well, is that still the way I want it to work?

• 29:45Wes Bos?

  Yeah.

• 29:45Speaker 00

  Is that still the way I want to think about this problem? I don't think it is.

• 29:48Wes Bos?

  No, rarely ever is a better, faster version of the exact same thing, the answer to, to what the next version of something is.

• 29:57Speaker 00

  Yeah, exactly. And so if you think about this move, and the software factories, as a creative outlet, that's the thing that's exciting. What's exciting is, hey, when you get to the other side, and we stop being like, hey, isn't it great that AI can make pictures? Or isn't it great that it could rebuild the Adobe Creative Suite in a week, by throwing tokens at it? And you're like, yeah, yeah, yeah, all of that's great. Now tell me what the new, what's the new thing? Like, what's the, what is it you'll build that never, nobody ever got to do? So like, a good example inside Swamp, is I have a partner who, we've worked together for more than a decade now, and we have this spreadsheet we've been carting around, that's how we do all of the like, mundane business reconciliation stuff, you know, like bookings, and revenue projections, and that kind of stuff, right?

• 30:41Speaker 00

  That you just, it's just stuff you gotta do in startup land. And, you know, I built him an application with a little software factory, that does the projections, and that knows how to extend itself. And now what he does, is use Claude, as not a software developer, to, to extend that thing, across all these different systems that we use, right? It's like talking to NetSuite, and it's hitting the CRM, and he's like, pulling in all of the like, bookings to actuals, and building the UI exactly the way he wants it. And then we're gonna use that to report to my board. And that seems small, but that piece of software is the best thing he's ever touched in his life. He couldn't be more stoked. Now, I don't know that he could hand it to y'all and be like, hey, do you want to use my software projection thing? Because it's like tied to

• 31:25Speaker 00

  Swamp Club, you know, like it works. It's tied to our choices. And I think that that personalization layer is the sort of interesting newest frontier where it's like, ooh, what if software got smaller, not bigger?

• 31:37Scott Tolinski?

  Yeah.

• 31:37Speaker 00

  What if it was, you know?

• 31:39Scott Tolinski?

  I've been building so much personal software in the past, I mean, the past six months, but in specifically the past like two months, the amount of little things that it's like, ooh, this fits my needs so specifically. And I can just, and it is, it's perfect for me. I did, I did a whole agentic to do system that I have with a hardware device and people are asking me to, you know, open source it or make it available. And it's like, yeah, I could, but this is so specific to my needs.

• 32:10Speaker 00

  Yeah.

• 32:11Scott Tolinski?

  And it's the perfect thing for me. Yeah. It's, it's just weird. It's wild.

• 32:17Speaker 00

  Yeah. And not to loop it back to Swamp, but I will for a hot second.

• 32:20Scott Tolinski?

  Yeah.

• 32:20Speaker 00

  That's why what we build are primitives. That's like when we describe it, often we describe it as like a platform of primitives that you need in order to build this sort of stuff faster. And like, what is the platform of primitives that we need to build those personal applications? What would the Adobe Creative Suite look like if it was built on, on some kind of flexible foundation that made those things make sense? And software factories are an example of how we align software to that shape, right? Swamp, for example, ships a software factory, kind of in one version of the world inside of it that knows how to break down tasks into automation problems for you. So you don't have to think about it and you just think about the intent. What's that look like for Adobe? What's it

• 33:03Speaker 00

  look like for Riverside? You know, like, I don't know, but I want to see it and it's going to be weird. And I'm, I'm into it.

• 33:11Scott Tolinski?

  Yeah. Yeah. It's so funny. As you're talking, I just think about all the stuff I'm currently using these automations for and just like, I have a, an automation for editing my wife's podcast. It now uses Cloud MCP. It uses Python. It determines who's talking via the frequency of their voice. And then transcripts pulls out the ums and ahs of repeatable automation. I just run it all the time, right? And that's like something that I'd be doing by hand in a linear video editor for eternity for me. I've been doing that for so long. And the fact that like that shape now has changed for me is been in a repeatable pattern has been so good. One thing I'm really curious on your thoughts

• 33:53Scott Tolinski?

  on specifically is that conversation around like, considering your background and everything, testing in general, right? We hear all the time about AI is just going to write the worst tests. They're just going to slop out some tests. The test passing now becomes unnecessary or anything like that. Like, what are your thoughts on like AI writing tests, test suites? And in general, in this, this current age of things?

• 34:17Speaker 00

  Yeah. I think black box testing, which is basically taking your product as it would be deployed or as it would be used. So no internal knowledge of the system at all. That just, how do I confirm that the features of the product work the way they are supposed to work? Those tests, when they're outside the context of the agent that does the software development, right? So they're outside the context of an agent that's trying to change the software in some way, super valuable, right? Because especially when you get to the refactoring part of the loop, which is still here in this world, right? It's not like, it's not like AI makes it so you don't have to refactor. What changes is that you learn to refactor because you experience bugs over and over again in the same part

• 35:00Speaker 00

  of the product. And therefore you learn that you need to refactor instead of sort of coming up to that knowledge through the code base, you know, by, by trying to edit it and realizing it's brittle. So those black box tests, I think incredibly valuable in this era in a way that they were not necessarily viable in the previous. I talked about that a minute ago. I think then you start to shift backwards and be like, well, how valuable are integration tests? And it's like, well, probably still relatively valuable, right? Because knowing that all the different parts work together can maybe catch those bugs sooner. You know, historically, integration tests also co-commitment with the source code. So AI is going to be able to change the integration test in order to prove that the internals work. That's

• 35:43Speaker 00

  probably still useful, right? Because it's going to catch regressions earlier. And then you get down to like unit testing. And I've probably skipped some steps. Like there's somebody who's really great at software testing. That's like either my vocabulary or there's more zones of, of testing that I'm missing. But, you know, for most of us, you back down to unit tests. I think there's an open question about whether unit tests provide much value at this point. And I think the open question there is that we're not often seeing AI write code that is functionally incorrect. And if we're not looking at the internals, then the unit testing isn't really helping me align myself to the two higher

• 36:27Speaker 00

  code quality standards, right? Whereas that loop of thinking through the test, like if you ever did test driven development and you wrote the unit test before you actually wrote the code, there was a real interesting loop that happened there between you thinking about the outcome of that one method and then you implementing the method. That loop, I think AI does not need. There was a good article that got posted on, on the ThoughtWorks blog about basically them going back and doing some research to see if they asked agents to do test driven development, if it improved or hurt the outcomes. And it hurt the outcomes in the end. It was just, it was worse than, than not doing it at all. So like, is that test suite useful or not? I think is an open question. My guess is

• 37:10Speaker 00

  it's more useful in some languages than others. For example, TypeScript, still very useful because that fast feedback loop of the types being caught, Rust is the same, right? Like Rust is a glorious language for refactoring because the type system is so good that it catches a lot of those issues. That's a lot of the issues we used to catch with unit tests in languages that don't have strong types. So, you know, maybe I still want unit tests if I'm writing in, in languages that don't have strong type systems, but I don't care in languages that do. And this is one of those places where I think we just have to do more experimentation together. We're not quite at the part where we're ready to delete all of our unit tests in, in Swamp, but we're not far. So I would say that like,

• 37:55Speaker 00

  it wouldn't surprise me if, if Paul Stack, who is the product owner and an engineering leader at Swamp Club, just deleted all the unit tests as an experiment in the next couple of weeks. That wouldn't, it wouldn't freak me out, which is a strange thing to say.

• 38:10Scott Tolinski?

  Yeah.

• 38:11Speaker 00

  If you'd asked me as a CTO for the last 15 years that one of my engineers wanted to delete all the unit tests, I'd be like, yeah, no, we're not doing that. But now I'm like, I don't know, could be fine. We know worst case scenario, you'll ask an agent to rewrite all the unit tests and it'll have them again.

• 38:25Scott Tolinski?

  Yeah, right. Get them out, get them back in, look at them again.

• 38:28Speaker 00

  Who cares?

• 38:28Scott Tolinski?

  Yeah.

• 38:29Speaker 00

  You know, we can literally run a test to measure and see what the performance is and see if we get more or less regressions. And I think, I think as an industry, that's precisely what we're going to do. Black box tests for sure. Super valuable. If you don't have them and you're heading towards software factories, that's probably the single most important thing you can start to do first is just build a black box testing suite so that it's safe to refactor. And then that means it's also safe to build the factory and you can sort of work backwards from there.

• 38:56Scott Tolinski?

  Yeah. Yeah. It all makes so much sense to me, given where things are at right now in my personal experience. I guess in general, like how, how do you, in a factory, how do you validate that trust in a more deterministic way? I know it's different for every language and every system.

• 39:15Speaker 00

  Yeah.

• 39:16Scott Tolinski?

  But like, what are the like, high level concepts that people should be thinking about when they're thinking about like, like making sure that their output is any good?

• 39:24Speaker 00

  All right. So black box testing is one. So I won't harp on it anymore, but that's, that's, that's a big one. Another is, for most of my career, we've made fun of software architects. So if you think about people who had that job title and they worked in like a bank, most engineers were like wah wah wah, you know, like architecture, astronauting, you know, all of that stuff. The thing about software architecture is that it gives you a vocabulary. For a fixed set of patterns that if you use those patterns, results in code that is supple to requirements. Supple to requirements just means is easy to change as we learn more things about how the about the domain we're working in. You know, so as I learn more about the problem, I learn more about how I want the software to work.

• 40:08Speaker 00

  Is it easy for me to change the software so it works the way that I want it to now that I've learned more? Right? That software architecture historically has been a thing that emerges for teams. So when we talk about the architecture of the software, usually what we mean is engineers wrote the software and they put some architecture in, you know, like they built, they, they, they decided the shape of the house as they built the house. And then backwards, they describe it to each other as if they had architected it, you know, as if I had from on high, put all the blocks in place. Now what happens is you actually are building it from up on high.

• 40:43Scott Tolinski?

  Yeah.

• 40:44Speaker 00

  Yeah. Like you actually are saying, hey, I want a house. And then the question of how should the house be constructed? What is its software architecture is a question the agent must fill in. Yeah. And left to its own devices, let's just say it's bad at it. And the reason is that what it tends to do is pick whatever it feels like in the moment is the right thing. And so part of why you see this pattern of like, I built a big thing and I just vibed it and then it fell over is because there is no consistent architecture, right? The software it generated was not supple to requirements. It breaks, it's brittle. And that's why every time you add new features, it gets worse. So in software factory land, the other thing you have to do is commit to a software architecture.

• 41:26Speaker 00

  And so if you don't have one, I would recommend domain driven design because what it gives you is it was really rich vocabulary, which an agent already understands. Like your agents already read the book about domain driven design. So if you say, I feel like this program needs an anti-corruption layer between these two components. The agent knows precisely what you mean. And if that architecture is also expressed in a skill that says, here is an example of an anti-corruption layer in my code base in my language, it will mimic that pattern. It will look for other examples of anti-corruption layers. If you are listening and you're like, what is an anti-corruption layer? It's just if you have two APIs and you want the right-hand side to be able to change,

• 42:11Speaker 00

  to not have to worry about the left-hand side changing, you build an anti-corruption layer in the middle that says, hey, I will translate between the left-hand side and the right-hand side so that the right-hand side doesn't need to care if the left-hand side changes. Right? The fact that I can say that sentence and every domain driven design person listening to this podcast nodded their head, knew exactly what I meant. That's the difference between software architecture and not software architecture. Right? And so that it turns out is critical to being able to trust the system because the, the, you have to be able to express that architecture from on high. So write a software architecture skill and then have all the code that gets generated be reviewed against that skill. Right?

• 42:53Speaker 00

  So whenever code comes out, you say, hey, is this thing architecturally aligned to my principles, you know? And those principles will be unique to the application. They'll be unique to the language, they'll be unique to your domain. Right? All of that stuff. But that process, we've seen really consistently return good results. Then adversarial review for other non-architecture requirements. So for example, let's say you ship a SaaS service and you want to be WCAG double or triple A compliant for accessibility. What you should do is write a skill or find one that already exists that describes those standards. And those skills can get really lean because like, if you just ask an agent right now,

• 43:38Speaker 00

  like what are the standards? It does a pretty reasonable job of telling you the standard. But like, if you have specifics you want to make sure are always true. For example, never allow two colors to be too close together in hue on a webpage. Right? Which, you know, no engineer ever thought about. You encode that now and now you make it so any change that goes through the system always gets evaluated against accessibility requirements. And if it fails, then go back and redo the work. Right? And then every time you find a new seam in the product where it fails to meet the outcomes that you're looking for, you go back as an engineer and you tweak the factory. Right? You don't say, you don't go back and be like, ah, the AI robots are dumb.

• 44:21Speaker 00

  You go, how do I change this factory so that this whole class of error gets caught more often?

• 44:27Scott Tolinski?

  Yeah.

• 44:28Speaker 00

  And it won't be caught all of the time. Right? It'll be caught, you know, some larger percentage than it was before. And then you tweak. So another, and then the technology will change and you'll change again. So for example, in that accessibility requirement, if you didn't change any forward-facing code, I shouldn't need to run the accessibility tests or the accessibility adversary. And so I can use a model like Jev to be like, hey, here's the change I made. Here's the list of criteria by which I judge quality. Which are the things that I need to use based on the nature of the change at hand? And suddenly you've got this really adaptive system that you couldn't think of before. And the reason I say it is because what I want to put in your brain is that that's engineering.

• 45:11Speaker 00

  Like what you're doing is engineering the system whose job is to build the program you want on the other side.

• 45:18Scott Tolinski?

  Yeah.

• 45:19Speaker 00

  And, you know, that move is weird because you've stopped building the thing you wanted and you've started building the machine that builds the thing you wanted. And, but you're still engineering. And so back to Wes's question earlier about like, hey, what do all those engineers do? Man, there's a lot of engineering that can happen in like, how do I build the machine that builds the machine? It's just moved to this other level. And so that loop of iteration, I think those are the core things that we, that I think everybody could do, that they should just do right now, which is like, software architecture skills, especially in the green field, but also in the brown. Like you probably do have a software architecture that you've defined. And so if you can write that software architecture and its vocabulary down, then suddenly you'll

• 46:01Speaker 00

  see that you can align the system to that architecture and to that behavior in a way you couldn't before, if you do it consistently. And then work on the machine every time you get, you find classifications of errors that you want to have be better. The answer is always go back, fix the machine, make the machine better.

• 46:17Scott Tolinski?

  Yeah. I could hear, I'm glad you, you talked to just even just said, you know, make a skill for it in that regard. Cause I could imagine people in the comments might be saying like, why not just do skills for everything here? And I know you touched on it before, at the very beginning, but it, this isn't like replacing skills. This isn't replay, it's augmenting, right? It's additive.

• 46:37Speaker 00

  Yeah. Yeah. I think the, the way I think about that evolution is at the beginning of this era, we all looked at what was happening with LLMs and we were just like, they're going to get smarter and smarter. And so we're just going to keep throwing more and more stuff at it and the god machine will sort it out. And what we've learned is that that is, A, it doesn't sort it out all the time in ways that are reliable or good. B, it's also very expensive. Right? Like it just costs a lot of money to just throw it at it. And so what we need to do is have skills that describe the things where what we're doing is applying judgment, or what we're doing is applying taste, or what we're doing is applying reasoning to the problem. And of course, what we need is to apply the right context, the right time to get the

• 47:21Speaker 00

  right outcome of that piece of the process. But we have to think of it as a piece of a process, as a piece of the system. And once we start to think about that intelligence as a piece of the system, now we can start to build a factory that's reliable. Right? Because as an engineer, I can ask, well, what are the inputs to that piece of judgment I need? You know? What are the, what are the outputs of that judgment? What are the outputs of that reasoning? And then how do I measure whether those outputs are right or wrong? And so a good example there is do they meet the standards for accessibility? That's essentially writing a test suite that describes accessibility. It happens to be a test suite that isn't always right. It applies, you know, it applies judgment based on my skill, but it's also an order of magnitude better than anything you've ever had before. Right?

• 48:06Speaker 00

  Swamp's the first thing I've ever shipped that has 100% lighthouse score. Whoever got 100% lighthouse score? You know? But Swamp does. And it's because I have an adversarial skill that says, don't ever let it drop. And so it doesn't.

• 48:21Scott Tolinski?

  Yeah. Totally. Yeah. Man, it all makes so much sense. And I think if people could just look at it like this, they would, they would really just understand that the, yeah, the, the software factory, again, it doesn't just exist to throw out as much code as possible into the world. It's there as guidelines to output good code or code that works.

• 48:44Speaker 00

  Yeah. You want to build good products. You want to build great things. Like it can't just be volume. Volume does not necessarily equate to good outcomes.

• 48:51Scott Tolinski?

  Yeah.

• 48:52Speaker 00

  And man, volume can build some sick outcomes.

• 48:55Scott Tolinski?

  Yeah.

• 48:56Speaker 00

  You know? Like, like once you have it, it can also be sick. And I, I just, I feel like it's really important that like where we are as an industry right now is that this is all new. And for most of us, we have requirements, you know, like I'm blessed to have like, I run my own company and I start my own startups and I get to like, that means I get to go swim in these waters and I get to focus on these problems and I get to hang out with you and I get to talk to all these people. And so like, that part of my job is to gather that information and figure out how to distill it for other people and then try to build products that are good. That's great. But that works because what happens is we get together and have this conversation. Like it doesn't work because I'm smart.

• 49:38Speaker 00

  It works because we are smart, because you went and built some stuff, because Wes was like, hey, man, I, what, what happens when I build this thing in Python and it gets a little better? And I'm like, yeah, what if it was like this? And he's like, oh, I like that, but what if it was also like this? And like that conversation in the large, that's how we discover all of these patterns. And so if you're like, you're new in the industry, you don't know that that's true because everything we, that came about that way, you didn't experience it already. Like you don't remember that the internet wasn't a thing until we made it a thing. And we made all these decisions that you live with now as if they were inevitable, but they weren't. They were just us talking to each other, figuring it out. And that's exactly the phase that we're in now. And because the labs are so big and because the technology is so strange and they've

• 50:23Speaker 00

  framed it in this weird way, we sort of, we sort of freaked ourselves out from just hanging out as engineers and being like, yeah, yeah, but what if we built it differently? Or what if we did this? Or what if we experimented that way? And like, we're entering this phase of sharing that information with each other. That is, that's what's driving this forward. Like everything I've said about software factories, I know that because I've been sitting in a discord with dozens of other people building software factories and we're telling each other what works and what doesn't. You know? We're like, oh, I tried that and it worked. Oh, I tried this and it didn't. You know, we did this and it was awful. And like, the more we do that, the more we figure this out and the faster we get out of that nasty surf zone, you know?

• 51:02Scott Tolinski?

  Yeah. Man, Adam, you explain things so well. I don't have any more questions on the list, Wes. Do you have anything that you didn't get to?

• 51:09Wes Bos?

  No, man. It's an excellent interview. I appreciate you coming on.

• 51:14Speaker 00

  It's my pleasure. Anytime. And like I said, it really is true that like, like we, what you're doing is a great service. Like, not because you had me on the podcast or whatever, but because like-

• 51:24Scott Tolinski?

  Well, yes, it is. We are awesome. Yes.

• 51:26Speaker 00

  You are awesome. But, but-

• 51:29Wes Bos?

  Yeah.

• 51:29Speaker 00

  Because you are serving your community. And because like, this conversation of like, how do we do this? And how do we learn from it? And how does that move? Like, that is the place we need to get to. Like, there's a bit of power seeding that happened where, as engineers, we were like, oh, I don't know. I guess I'm a slave to Claude. You know, I guess, I guess I'm just, I guess I just push prompts now. And it's like, no, absolutely not. And, and if you go ask the people in the labs, you're like, hey, do you know how to do this? They don't. They don't know. They're not better at it than we are. Because we're the ones who actually know how our own systems work, and they don't. And no amount of having been the people that came up with AI makes it so you know how LinkedIn works.

• 52:09Wes Bos?

  Yeah.

• 52:10Speaker 00

  Or how JP Morgan Chase works, or how Swamp Club works. And like, you know, like, we're the ones who know. So, we gotta go do that shit.

• 52:18Wes Bos?

  You look at these labs, and they're just throwing products at the wall because they have unlimited tokens and limited engineering and limited money, and they still don't know what the, the product is for a lot of these things. You know, they certainly hit it with coding, but you can see them with the, the personal agents right now. They're just trying to figure it out. And it's not the software engineering that's the, the hard part right now. It's just trying to figure out what it is.

• 52:44Speaker 00

  Yeah. And that's a, that is a gift to software engineers everywhere. Like, that has always been the truth. You know, like, if you raise venture capital money, you always will get asked, like, why isn't Google just doing it? Or why doesn't Facebook just do it? And it's like, well, I don't know, man. Because they could do anything they wanted. So if what they want to do is destroy me, they will. You know? If they turn their, you know, if they turn the evil eye of Sauron on Swamp Club, and they're like, that Adam guy's got it. What I want is, I want what he's got. Like, they'll just take it. Because what do I got?

• 53:12Speaker 00

  But what I do have is this. Like, I can do this. I can come and be with you, and I can figure out what that practical outcome is. And doing that is the way you find great products. And it's, and it's also the way that good engineers engineer. And like, I think that is actually the golden age of what's possible for us in this whole thing. And it's why the software factory thing is interesting, because it helps move us more toward how do I engineer in this era? Because it's so fun to be an engineer. It was always fun. And it's still super fun to be an engineer in this era, when what you're doing is adjusting to the constraints of the era. Do you know what I mean? When, when you're not stuck.

• 53:49Scott Tolinski?

  Yeah. Man, you explain things so well. Thanks so much, Adam. The next part of the show is the sick picks and shameless plugs. A sick pick is just anything that you're enjoying in life right now. Something that gives you joy. Could be literally anything, media or physical. Do you have anything that is bringing you joy in life right now?

• 54:08Speaker 00

  Oh, yeah. What's bringing me joy in life right now? Yeah, okay, I have two things. So, I switched to a Dell XPS 14, one of the newer ones with the Panther Lake in it, running Linux.

• 54:23Scott Tolinski?

  Yeah.

• 54:23Speaker 00

  And everything just works. And that's bringing me, like, real great joy.

• 54:28Scott Tolinski?

  Really?

• 54:29Wes Bos?

  Is it this one?

• 54:30Speaker 00

  Yeah, yeah, it's exactly that one.

• 54:32Wes Bos?

  Are you, what do you, what Linux distro are you running on it?

• 54:34Speaker 00

  I'm running Lomachi on it.

• 54:35Wes Bos?

  All right.

• 54:36Speaker 00

  And, uh, which was very close to the Arch Linux I was already running. I was running Arch and Hyperland and all those things anyway. And it's like, that has become incredibly more polished, in a way that is a delight. And also points the finger at this sort of new future of like, you know, popping up a Claude and telling it to fix my laptop. That's a delight.

• 54:59Speaker 00

  I think the, um, the other is, I love heavy metal. And like, you know, abrasive, annoying heavy metal. And I would say that like,

• 55:09Speaker 00

  I've, I've once again been enjoying Lorna Shore. So there's something about-

• 55:14Wes Bos?

  Oh, Lorna Shore is awesome.

• 55:15Speaker 00

  I sort of slept on the latest Lorna Shore record. And had a transcendent moment on the airplane the other day, where I was like, oh, no, this record was great. And I just wasn't in the right headspace to hear it.

• 55:26Scott Tolinski?

  Okay, I don't know Lorna Shore. I gotta get on this. So I will put this on later. Cool. And, and for shameless plugs, is there anything you want people to check out of your work?

• 55:36Speaker 00

  Yeah, I mean, you should come check out Swamp Club. And you should for sure join the Discord. Like, you know, if you've heard this conversation, and what sounds good is being in a room filled with like-minded people who are building stuff. Like, that Swamp Discord is filled with people who are trying to figure out how to build stuff in this way. And they're just constantly sharing with each other what's going on. And it's super fun. So, those are the two things I would plug. Like, obviously, you should come and check out Swamp Club. But you should also come hang out on the Swamp Discord, because hiding inside there is actually the magic of whether you wind up using Swamp or you wind up not using Swamp. Like, what you need is those people around you, helping you figure out how to navigate this world in a way that is, is moving forward.

• 56:20Scott Tolinski?

  I gotta say, I've been a part of a lot of Discord channels. I probably am in like 100 right now, and I should clean this up. And the Swamp Discord is the only one I really hang out in. Some Discords are like, they have all these weird internal systems of how conversation needs to be had, or there's too many messages flying in, or people are just coming in for here or there, or whatever. The Swamp Discord is the one I get the, consistently the most value out of and feel like the conversations there. Like, if I, if I have a question about, like, for instance, I just posted on there, like, how are people here using Jeff right now? That's like the one place I feel like I'm gonna get the most value out of my answers. So I hang out there all the time.

• 57:05Scott Tolinski?

  If you're like, yeah, if you don't want another Discord channel or whatever, I get it. But this one is, is really a great place to hang out on this type of stuff. So, a lot of really smart people with good opinions. Cool. Well, that's all I got. Wes, you got anything else?

• 57:18Wes Bos?

  That's it. Thanks so much for coming on, and thank you, everybody, for tuning in. Thank you.

• 57:23Scott Tolinski?

  Later.