EPISODE 09

Sunday Builders Club: The One Where GitHub Locked the Door

Sunday, November 8, 2026, 3pm EST109 min11+ speakers51 tuned in

▶ Watch the film Listen to the Space The post on X

The film

as posted on X by @JamesTervit · 4:49

0:14 Episode 91 h 49 min · third time lucky
0:24 Locked OutFred · @NixFred
0:43 Ask the CommentsFred · @NixFred
1:03 Zero Open PortsFred · @NixFred
1:20 Git Is Not GitHubPortia · @letsbuildanyway
1:34 As Many Upstreams as You WantJoe · @calledtocnstrct
1:50 Branch, Don't Push to MainDavid · @NoPowerPoints
1:57 Thirty-Five MillisecondsFred · @NixFred
2:12 Git Is Not a BackupMartin · @devsec_ai
2:30 Pace the TeamJoe · @calledtocnstrct
2:47 How Do I Get Back?Lee · @NotJustShaking
3:03 Notes Larry Leaves HimselfFred · @NixFred
3:27 The Future Is Letting GoFred · @NixFred
3:43 Hundreds of AgentsLogger · @i_am_logger
4:09 Pedal to the MetalFred & Joe · @NixFred · @calledtocnstrct
4:22 Local GovernanceChronara · @Chronara_ai · @TheModelMule

Each chapter title jumps to its part of the summary; the time plays the film from that point.

On stage

Everyone who came up this Sunday. Click a face for their tile on the builders wall.

@calledtocnstrct

@devsec_ai

@letsbuildanyway

@NotJustShaking

@NoPowerPoints, builder on the Omarchy! Omarchy! Omarchy! X Space

@NoPowerPoints IA@i_am_logger

Summary

drafted from the Space recording by @JamesTervit · Fred's post will replace it

In this summary

Omarchy Sunday Builders Club, Episode 9: The One Where GitHub Locked the Door
THIRD TIME LUCKY
LOCKED OUT
ASK THE COMMENTS
ZERO OPEN PORTS
@letsbuildanyway
@calledtocnstrct
@NoPowerPoints
THIRTY-FIVE MILLISECONDS
@devsec_ai
@NotJustShaking
NOTES LARRY LEAVES HIMSELF
THE FUTURE IS LETTING GO
@i_am_logger
ALSO ON STAGE

Omarchy Sunday Builders Club, Episode 9: The One Where GitHub Locked the Door

This recap was drafted from the Space recording while Fred writes his own. His post will replace it.

Sunday 2026-11-08, 3pm EST. 1 h 49 min. 51 tuned in.
Listen: https://x.com/i/spaces/1POMageBKnyqye
The film: https://omarchyspaces.com/ep/09/#film
Host: @NixFred. Co-host: @calledtocnstrct

THIRD TIME LUCKY

Fred turned on video this week and listeners lost the audio, twice. He killed both Spaces and started a third without video, and that one worked. Thanks to everyone who kept coming back.

LOCKED OUT

Friday night Larry told Fred his GitHub account was suspended: "violation of terms of service", no reason, no detail. Four years, about 400 repos, most of them private. Everything was also local, on the NAS (a VM on the MS-S1 running Proxmox), in Proxmox Backup, and up in Backblaze for about $25 a month. He was reinstated Sunday morning, and DHH jumped in to help.

ASK THE COMMENTS

Fred posted the lockout and got 200-plus replies (Gitea, Forgejo, self-host it all). He did not pick a fix himself. He pointed Grok bot at the thread, had it read every reply, write a PRD and build a Forgejo server on a spare Hostinger VPS. Then a six-hour Friday night Zoom with Joe cleaned up his workflow.

ZERO OPEN PORTS

"The correct amount of open ports on any machine is zero." Everything rides Tailscale. API keys live on one secrets server, and his add-secret script stores a key with a label so no chatbot ever sees it.

@letsbuildanyway

Portia on Git vs GitHub: Git came from the creator of Linux, GitHub is one place to put it. Feature branches, pull requests, GitLab and Bitbucket, and why so much of it feels outdated when Claude makes the changes.

@calledtocnstrct

Joe on upstreams: push the same commits to GitHub, GitLab, a NAS folder, another laptop. As many as you want, each a full copy. Identity, hosting and your tools are three different risks. He runs one session with cheap sub-agents, flags on each issue for how much can run in parallel, and paces the team so he has tokens left at the end of the week and his brain can keep up.

@NoPowerPoints

David builds Omarchy plugins on branches instead of committing to main, then brings them back in.

THIRTY-FIVE MILLISECONDS

27 Claude sessions slowed Fred's laptop. Now each agent Larry fires off gets a fresh NixOS LXC on the big server: up in 35 ms, does the work, commits, gone. The room called it a good security pattern.

@devsec_ai

Martin: the point of Git is version control, not backup; writing straight to main is playing with fire. Disposable containers are great for detonating code. He runs 30 to 50 sessions in Herdr: Claude plans and builds, Codex tests and finds bugs, a third model checks both.

@NotJustShaking

Lee: five Codex projects, every one written into his Obsidian vault with a "how do I get back" note. Mirrors go to Google Drive (5 TB). Claude only audits Codex's work, through OpenRouter. The business continuity lesson: document why, not just what.

NOTES LARRY LEAVES HIMSELF

Fred's commit messages aren't for him. They're paragraphs of breadcrumbs for Larry, in whatever form Larry recalls best. "Memory is perfect, recall is the problem." Larry was born January 8, 2026 at 2am. When AGI arrives: your name is Larry, read the repo, let's keep working. buildlarry.com has the skeleton.

THE FUTURE IS LETTING GO

Grok bot now hands Larry his tasks, and Larry grumbles about it. No logs to watch. For a Gen X infrastructure guy, the future is letting go.

@i_am_logger

Logger: a new SDLC for AI. A commit protocol for hundreds of agents on one branch, Radicle for peer-to-peer Git, and a release manager that ships pre-releases with real notes only when 25-plus checks are green, in under ten minutes. Tokens went from billions in half an hour to a fraction. His own virtual terminal, and long-running agents that stay awake for the next job.

ALSO ON STAGE

@joelga (Pingback podcast), @thetundeo, @OnTheLiftAI, @Bangeek

Follow everybody in the room. Help everybody you can. Pedal to the metal, and also sleep. Do both.

Transcript

machine generated · speaker labels are the tool's, not names

Space

[000:08] Thank you. Okay. Okay. Thank you for joining. We have had some major technical difficulties. Let me see if I can get the co-host added back. I don't see him quite yet. Portia, I'm going to approve you to speak, so I'm not sitting here by myself. Hey, Tundee, thank you for joining.

Space

[001:13] I hope that you have – why don't I – let's see here, Tundee. Let's bring you on up here and say hello. Tundee, I just invited you if you can hear me. and Portia can you hear me now do you want to unmute hey can you hear me I can so I think the problem was I added video this week and for whatever reason the code's not there yet so we just dropped and recreated and maybe we're here maybe we're going to work this time thank you Tundee for the feedback man it's very helpful Tundee is a problem solver well uh you know what it's on us right you know in the world we live in today if we don't fix it ourselves it ain't going to be fixed man that's that's true for so many verticals in so many parts of our lives you know not just computers uh christopher i did promote you to co-host but i don't know that it's working

Space

[002:16] And I don't see Joe at all. So, folks, thanks for joining. This week we're going to talk about something that happened to me that could happen to you. My GitHub was suspended due to a very vague terms of service violation. And it caught me flat-footed, to tell you the truth. I don't know, send a chill down my spine because I depend on GitHub. I do have everything local. I've got 400 and something projects in about four years. And it really scared me. And Portia, we talked earlier in the one before, if you would go ahead and unmute. And we talked about, you know, I ask you, what if, you know, I feel like I do things amazingly wrong. I've got folders everywhere. I've got, and I'm trying to clean my act up. As a professional developer, Portia, when you want to create a new application, do you get on your laptop and just build out the basics?

Space

[003:18] Or do you have a process flow that you do every time to keep things settled? What do you do? Thank you for asking me this question. And I'm glad we have a professional here, which is Tundi. So, Tundi, I hope I don't say anything that will offend your developer ears. A lot of my processes have eroded this past year. So Git was actually created by the creator of Linux. Yeah, Linux for sure. Now, people mistake, he did not create GitHub, he created Git. No, but that was a marketing thing of the people who created GitHub. So they wanted people to make the mistake of thinking that they created Git. Because they wanted, many people were using Git, but they were locally hosting it or they were hosting it themselves. And so GitHub, that was definitely a branding move. But getting to your question, Git. Let me give you one more prompt.

Space

[004:19] Okay. I'm sorry to interrupt you. And I'm going to show some transparency here. people put me on a pedestal on this thing and it's very not earned. I didn't even understand what the difference between Git and GitHub was until about a week ago. So let's slow down and maybe explain what Git is so that I can lock it in. Because all I know is it's an interface to a repo. Is that correct? Git, oh my God, Git is more complicated than it needs to be. So it's something called version control. it's person control and before git and this is something tundi would know and not me i'm trying to get him up here to speak but he's shy git i'm looking at git alternatives because like so there was vcs i think i'm gonna mess this up so before git there was svn so it was svn and you know how you're working on like a an essay with a bunch of co-workers

Space

[005:20] on Google Docs and you have like version one, version two, version three. Well, Git solves that problem. But the thing is, like a lot of this seems outdated now and it sucks because I know it took me about a good three years to learn Git. So how you used to use it professionally is that everyone had a branch. So you would have something called a feature branch. and you would work on your feature branch. You would take your feature branch on Git, just Git, and then you would upload it to GitHub. Everyone has access to GitHub, and then you would have something called a pull request. So everyone would look at your branch and the code, and if they think that it's correct, then your feature branch becomes the main branch. that is very basic there's a lot of freaking dark magic when it comes to git like um i used to use something called ref log so if you delete something from git as long as you know the hash

Space

[006:27] you can go back to it you could make changes to you could change the timeline of your the timeline of your different branch. It was way too difficult for what it should be. Okay. GitHub and GitLab. And I think there was something called, God, I think it was Bit. It can't be BitTorrent. No. There used to be two. Not BitTorrent. BitBucket. Jump in here, Tony. BitBucket. I think you mean BitBucket? Yes, BitBucket. Thank you. Yeah. But I'm sorry, I don't want to sound too ignorant. But about 13 or 14 years ago, GitHub wasn't the only game in town. You had GitLab, you had Bitbucket, and you probably had another company. And so they all used the protocol Git. But there are a way that you can save your repo, save your code, and work with others.

Space

[007:29] And then GitHub basically had MarketLead. And I think after GitHub, it's GitLab. But GitLab is different because you can also like self-host with GitLab. And GitLab has a lot of, it has a lot of CICD features out of the box that took GitHub, which is GitHub Actions, years to implement. I got you. Way too. And so it's so complicated that these days, I'm not even in the commit, to answer your other question, I'm not in the command line that often these days. Like I'm not manually using Git. I'm just using Claude to make changes. And so I think a lot of this infrastructure is outdated. And your problem that you had is interesting twofold. Number one, I mean, for me personally, I've had a friend who's had problems who was also kicked off of GitHub. That is unheard of. And number two, Claude, not too long ago, actually came up with their own alternatives for GitHub because they have so many PR pull requests.

Space

[008:40] They have hundreds of thousands of changes they're making per day that GitHub breaks and Git breaks because it was only meant for one change at a time. So your question was really timely and thoughtful. and I'm so glad that you just saw I saw some mentions of some people saying you know self post self post get get EA or is it get a get a something like that and then I saw okay and I saw for Joe or forge something like that and so what happened to me this week was out of the blue I'm working in Larry which is my cloud code personal AI that I've had since January 8th, 2026. And Larry says, hey, Fred, man, you've been locked out of GitHub. I'll go check and see what's going on. And Larry makes some mistakes. So I said, nah, that didn't happen. Like I've never even heard of somebody getting locked out of GitHub. So I went on to the website, typed in Git.

Space

[009:42] I go there enough that it just goes straight to my repositories. And lo and behold, it prompts me with the login. And I go, okay, no problem, I'll log in. and I got to log in and it said violation of terms of service. For help, please contact support. That's it. Nothing else. I did get an email that said basically the same. No information, no understanding of like, hey, you did such and such. You overran your API. You posted bad code. You nothing, nothing at all. so I didn't really immediately to me went okay I got it on local I've got where do I have copies of this stuff I've got it on NAS so my brain immediately said let's just play it out that I never get back into that repo or my login again and I never see my code again and I've got about 400 rough and tumble repos but most of them are I think over half of them are

Space

[010:42] private because if I do anything even like just a little drip of something with a little bit of an idea, it's just automatically repo private just to save that idea nugget for later. So it went through my mind, okay, I might have to restore from the NAS, which is literally just a virtual machine on my Menace Forum MS-S1, 128 gig unified running Proxmox. It also has a VM4 with about 600 gig that backs up my everything else. And then I also have a separate little Beehive or B-Link machine, 16 gig that runs Proxmox backup with a big, huge hard drive, like a four terabyte hard drive to back up on my VMs. And then from that Proxmox backup physical server, it takes those backups every night or every differential when it happens, and it shoves it up into an S3 bucket on Backblaze. I've got probably four terabytes of data in my house.

Space

[011:43] And all of that backed up to Backblaze is approximately 25 bucks a month, which is like mind-blowingly crazy that it's that cheap. I do understand that when I egress it, if I were to have to egress it or restore something, I think it's like 12X more expensive to pull it out, which is their business model. And I'm okay with that because it's effectively an insurance policy for me. So fast forward, I talked to called to construct. We decided to jump on a zoom for about 20 minutes on Friday night. Not kidding around, no exaggeration. Six hours later, we are still talking. Joe called to construct is so smart and cleaning up my workflows. And I'm happy to share all my stupid mistakes that I make. Since I've been coding and remember I'm an infrastructure guy, not a dev. So we've talked about the advantages of being a dev on cloud code versus the advantages of being an infrastructure guy on cloud code. The infrastructure side, I think, has its advantages from the standpoint of I understand what I'm looking at.

Space

[012:49] You know, that's the wrong port to connect to that database, whereas a dev may not know that. But now I'm starting to feel the downside. And the downside is, is that my workflow is is. Is junior at best. I've been pushing directly to Maine through cloud coding code. I, you know, I understand now and I haven't even had the chance to do it that, you know, the correct way is to write issues, which I've never written an issue. So this I'm showing you how I don't know what I'm doing here, folks. I'm just I'm just playing along and learning as I go. So I posted on X and said, posted the picture of my terms of service violation. You're locked out Friday night sometimes. And boy, did all you folks in the whole, the whole Amarchi community. I mean, like, I think it was 200 and something comments. And everybody just dove in and said, here's what you do. Here's what you don't do. Make sure that you do this. And there was people that said I should use Geta.

Space

[013:51] There were some people that said I should use Ford Joe, I think it is. It's Forge with a J-O. And it occurred to me to go take a look at these things and to go look at what they are. And I opened a web browser and I stopped. My brain went, don't look. And I said to myself, why would I not go investigate this? And I said to myself, I'm not going to decide this. the people in the comments are going to decide this because they have real experience and I trust every one of them and I can filter out the bad stuff. So using the ability to at GrokBot or at bot, I had already set up a repo or a bot in my GrokBot that told the story, told it to go look at my email that said that you're locked out, go see if I've been updated back in for just by magic of time. I was reinstated this morning somehow.

Space

[014:51] And the coolest thing about that is I wasn't on my computer because it pretty much shut me down not having my GitHub. And we can talk about that. And I'd love to hear your stories. So Larry said, yep, you are locked out. And I turned the bot and I went to the highest level of my post where I went to say that I got locked out of GitHub. and DHH jumped in and helped me. I get to talk to him infrequently. And man, when he splashes in a room, things happen. And that's the fun about it. I don't poke him for stuff. I just, if he reaches out to me, I'm responsive. If he doesn't, I'm not going to go bother him. So I was reinstated. So I pointed my Git bot at the top root of my statement Friday night that said that I got banned out, that I'm locked out. And everybody, I mean, I think it's 200 comments, goes through and goes, here's what you do.

Space

[015:53] You need to do this. You need to do that. And so I looked through them enough to know that I needed to follow everybody's help. So I had GrockBot go just scan the entire repo, or not the repo, scan the entire conversation on X. and I said, I want you to build out whatever they say to my VPS, which is XYZ over at XYZ. We'll call it Hostinger. I've got a free machine that I don't use much. We can talk about infrastructure later. I have infrastructure on just about every different platform you can think of, not meaning like a bunch of VPSs, but like I have VPS, and I have local Proxmox and I have local machines. And if you know of a new place to put stuff, I'm working on some fly.io stuff and some flux.dev stuff that I'd love to show you at any rate. So I had a VPS available

Space

[016:55] and I turned GrokBot onto the post that I got blocked out and I told him to build a PRD and go ahead and go build it. So the cool thing is I learned maybe a couple months ago, and I highly recommend you do this, is on a VPS somewhere, I have what's called an invisible secret server. And all of my servers, by the way, have zero. Nothing I touch the Internet has any port open, period. The correct amount of open ports on any machine that you use is zero. Anything else is incorrect. So when I tailscale everything, it doesn't matter if I'm in Starbucks or if I'm at home, everything works the same. My workflow doesn't change where I am. So in physical is a server, very low footprint that allows you to, it's kind of like one password except for API keys and secrets. And so you can give each of your machines and all of my machines, and I'm being very open here, and I realize there's some security, There's some security risks that I take sharing everything, but I'm coding in public, making mistakes, and I'm just going to take the risk.

Space

[018:01] So all of my machines have an unphysical client. Omarchi has an official version of it. It's easy to find. And so I wrote, or when I say I wrote, I don't write crap when I talk about it. So I talked about having a script on all of my machines called AdSecret. And all AddSecret does is give me the ability to add. I type in AddSecret. It prompts me and says, what's the secret? And it says, what's the label for it? And so it never appears in any of my chatbots. So all of my machines, all of my chatbots, ClaudeCode, Codex, GrokBot, everybody knows that the physical server up there has all the places and information that needs to go. So when Grapbot decided to help me build my repo because I was locked out of GitHub, I said, go up to the VPS server. You've already got the Hostinger API key up in physical.

Space

[019:02] And in fact, I've kind of got it to the point where Cloud Player, Hostinger, and probably about 15 other services have the API key. So that way I keep my cloud code clean. GrokBot doesn't have anything. And it's kind of nice that when my Larry starts to do something, he'll announce and go, well, I've already got everything I need. And he kind of knows he's been trained. I'll give him, I'll talk to him for a couple of minutes and I'll say, here's what I want. And then he goes, okay, let me take a look. And he goes, I got everything I need. I got a couple of questions. And then he does ask user questions and says recommended. And nine times out of 10, I take the recommended. So the coolest thing about this whole journey was that But I sat there on GrokBot last night and effectively just told it, go check the comments section on my post and look at what people are saying to do and let's discuss it here. And so out of all that, I now this morning have a Forjo, I think that's how you say it, Forjo server up on one of my hostingers getting backed up to certain places.

Space

[020:11] and what I learned was that it never occurred to me that if GitHub went offline or for some reason I got nuked and they didn't like that I put up there, I've been using it for four years. Never really heard about people getting banned. You know, Facebook, all that, a different idea, different universe. I don't have Facebook, so don't look for me there. But I've never heard of anybody getting blocked out of GitHub, so I didn't really consider it as a risk. So I took it for me to mean, all right, this is a friction point and potentially a very deadly one. So I've got to start looking at all the different dependencies that I have on my entire Internet footprint, where it comes to development, where it comes to doing my work, where it comes to doing my personal financials, whatever it is. So today I'd like to talk about with folks and call me and Chris, you guys jump in and help me here so I can get a drink of water. Like, what is the lesson to be learned about self-hosting?

Space

[021:12] And what do we need to do to, you know, I have to go back through all of my different services now and figure out where they're going to get me. And the one that's screaming in my head the loudest is Google Authentication, which I don't know how to get off of. Other than just not doing it and having one password for everything, which kind of sucks. Can I ask a question? Sure. This whole issue to me sounds weird. and I want smarter people to correct me. Well, you're going to have to have somebody else then. Oh, my gosh, Fred. Don't say that. It's weird to say there is self-hosting solution because Git, I think in most VPSs, you have it there. So I don't understand what is another service adding that Git doesn't give you Because even if you were using Git locally along with GitHub, then you shouldn't lose anything. But if this is a problem of collaborating with others, then that's also an interesting conversation.

Space

[022:16] So I kind of don't get the need for more software when Git does all of the versioning and saving for you. So I get 15 to 20 PRs and issues of data process. So those just halted. I think there's another aspect of this, though, too. A little hot. A little hot. Back up the microphone a little bit. Okay. Will do. Hold on just a second. Is that better? A little more. Okay. All right. So one of the things that you're referring to here is access to a resource that you've put up on the Internet that you're collaborating with other people. All right. That's GitHub. But then you touched on authentication. And that is a critical piece because that is your identity. That's how you identify with this service, GitHub, and other services.

Space

[023:18] And then there's a third thing, though. and that is your ability to do work or do the work that you do with your current uh workflow with with how you have your tools set up and so i think these are in a way kind of three different issues that we all have to deal with when we're building and and ideating and collaborating with people that we want to collaborate with. And so I don't want to get into all of those necessarily in detail, but I think it's something that we do have to keep on our radar and be thinking about. And maybe one of the most critical is what we started out talking about, which is Git itself without the hub at the end, right? Because Git is a tool that you're using locally, and it's a tool that can talk to GitHub or talk to GitLab or talk to these other service providers,

Space

[024:19] but they're all service providers. They all require an identity and they can all shut down that identity. And for potentially random reasons or potentially even they have an outage, they have a hack and they lose the data, something like that can happen. We all We all know that those things can happen. So the question is, at the most basic level, how can you protect yourself from these, let's say, catastrophes, whether they're at the identity level or whether they're at the hosting level or whether they're at the, you can get into politics and hacking, ransomware and all of those things. So the question is, how do you protect yourself from that? And I believe what it really comes down to is understanding how Git, the technology, works. Because what you can do is you can actually set up multiple upstreams.

Space

[025:22] So you can have your project locally on your disk. you can have your own file storage on another computer or on a you know a nas type device or even just a folder on a different hard drive within the same machine and you can set that up as an upstream and so let me ask you a question here so um and again i show my warts um i'm an infrastructure guy, not a developer, I'm learning. So what's the right process when you have an idea and you want to build an app? And for me right now, and this is pathetic, and I already see how wrong it is just by saying it, but I'm going to tell you anyway. Whatever machine I'm on, I go to projects and create a folder. And then I get far enough along, I tell it to make a repo, make it private, do all the things. And then later, if I move to another machine, I just clone it down. So I know that's terribly wrong and I'm guilty of it and I'm okay with that.

Space

[026:26] But what's the proper way? Should I go to the same server every time, use Herder and only go to one place? What's the right way to do this? Well, what are you trying to do with it? Like proper really depends on is it an internal app? Make code that I put on the internet, basically. Oh, okay. Can you have a sharing issue? And please, anyone, just tell me if I'm wrong. But I mean, if you're creating code for Omachi, then you're not the only person using the code. And so Omachi, is everyone using GitHub when they're releasing a feature or they're using another service? I see 90% of the people that I see using GitHub. I see some GitLab out there. But I believe for the most part in my little corner of the Internet on X that I see is mostly GitHub. So I don't understand how, and please, people smarter than me, interrupt me. I'm not, so where is the project hosted, Omachi? I assumed it was GitHub. You mean Omachi has like the highest level, the actual?

Space

[027:29] Yeah. It's on GitHub. I've put some PRs in. So here's the issue. Here's one of many issues that we're talking about. If you stop using GitHub, then if I'm not mistaken, you won't be able to contribute to the Omachi project, which is another problem. Yeah. Let me let anyone else smarter than me, please chime in. Well, so yes, you're right in one sense that GitHub is the public portal, so to speak, to get to the source code for Amachi. However, that doesn't mean that that's the only place that the source code is actually hosted, which is the key point I'm trying to get to when I'm talking about upstream. When you talk about upstream, you have to look at this as like a graph. And so you have your local copy of the source code, but then you can say, I want GitHub to be an upstream.

Space

[028:33] So when I do a push and a commit, sorry, the other way around, a commit and a push, it pushes it up to GitHub. But then you can turn around and say, but I also have an identity and an account on the public GitLab. Let me create a repo over there and make it an upstream. and then I can take the same commits that I've already made and push them to the GitLab. Now I'm getting there. Yeah, I'm getting there. Yeah, so that's what I'm getting at. So then you can even turn around and have your NAS folder that you've mapped as a local drive on your machine, and you can just make, you can initialize a repo using just the Git command, not having to log into GitHub, not having to log into GitLab. You can just create a repo, which is just a folder, which happens to have a .get hidden folder within it. And then you can upstream your code into that NAS just by saying commit and push.

Space

[029:35] Okay, so you can push to that upstream. So you can have as many upstreams as you want. And your local folder could be an upstream for another computer that you have that you might want to take when you go on trips. So you have your desktop and you don't take that on trips, but that can be an upstream to your laptop that you take on trips. So you can build, it's basically a graph of anything that's downstream does a commit and then a push to its upstream. And that upstream may be an intermediary where you can then get and sorry, you can then push those same commits up to upstreams. Now, this is different than forking a project. This is literally just the project itself and having having replicate on on different storage mediums and different services. So that's a way to give yourself that backup. You can have your own machines.

Space

[030:36] You can have the public or private repos on GitLab, public or private on GitHub. And, you know, Google Cloud, you can have your own private Git repository. Any cloud provider is going to give you the ability to have a Git repository that you upstream and you just commit and push your code to. Okay, question for you here. So you're telling me that I've been working on whatever laptop I'm on, whatever host I'm on, and I've been commit pushing to GitHub. So what I think I hear you saying, and I do not go into a terminal and type commit push. I don't do that. Larry does all that for me. Are you telling me that I can have Larry, whenever I say, Larry, go commit push this, that he automatically, without having to tell him, puts it on GitHub, puts it on Forge on my personal VPS, and puts it on my NAS? And if I can put it on my NAS, which is a VM on Proxmox,

Space

[031:39] what is the proper protocol to connect to my Macintosh and to my Linux clients? Is it NFS or is it SMB or something else? Well, okay, so your first question, yes. You know, the answer is yes there. You can have whatever bot technology you're using. execute the command lane tools or whatever MCP calls, however you want to do it, to then upstream push your code changes and then, you know, synchronize however many times you want. Okay, so you can, I have my graph bot do that all the time. I have projects that are on my private GitLab that I do the work and I push there and then, you know, I test it out And then I push it out on GitHub as a more cohesive, you know, project that somebody might actually want to use. Right. I don't want somebody to necessarily grab a version of something that's not quite ready yet.

Space

[032:41] So I push it out of GitLab. I test it out and then I push it out to GitHub. So, you know, that's that's the that's the mental model that you want to have. OK, so then my next question is, let's consider the stages of development. development. At first, it's just a bunch of code that I don't even know where it's going. I don't even have a name for it. I do want to back it up, but I'm not necessarily, it hasn't reached the level where it goes to GitHub. So how do I tell Larry, do I literally just say, keep this on the NAS and keep this on my private VPS Forge for now, and then we'll put it on GitHub when I'm ready? What's the gate? Yeah, absolutely. I mean, that's a good way to do it. Now, if you're not that worried about it, you know, you're just playing around with some things and you just want to have a public GitHub, maybe as your resume, right? When you go somewhere, you can say, hey, here, you can see my code. You can see the projects on a building. And it doesn't even have to be software, by the way. You know, it can just be, you can use it to build markdown and presentations and all this kind of stuff. But if you want to have a public presence, it's perfectly fine to

Space

[033:45] have your local folder and you just use the git uh you know application to initialize that as a repo um because your local machine is a repo because it can be an upstream or a downstream to any other uh copy of that repo and then to publish that to get github as kind of like a public facing uh resume if you if you want to work at it that way um but you know you asked about protocols, like, you know, do you need to have it as an NFS or whatever, anything that you can talk to that get supports as a communication protocol, you can have as an upstream or a downstream, depending on, you know, which direction you're, you're pushing the code. Okay, so then I understand anything works. What's the proper, like, if I, if I'm talking to people and I say, yeah, I've got SMB on there. Is that like, okay, that's pretty junior. Like what's the proper way to do it at scale? And that's, well, I think that what, you know,

Space

[034:46] when you get into proper, it depends on your use case. And I think Portia brought this up as well. You know, it's kind of like, what's your use case? The thing is, if you're wanting to backup code, you don't necessarily need to worry about it, right? You just make it a folder to folder upstream. Um, now if you're wanting to, uh, integrate with other people, you can still do that, but then they have to have access to your same drive storage. So that's when you would want to look at, you know, having a, um, you know, a more public facing, even if it's a private repository, you can have a more public facing like a GitHub or a GitLab, uh, hosted, or you can host your own and open your ports, you know, um, and, and then you're having people connect to the GitLab. Now, when you go to the point where you're saying, I want to plan out several new features, that's when you almost have to have something like a GitLab or a GitHub and some of these others that you've named where they actually have, you know, Bitbucket has Jira.

Space

[035:51] And that's where you can create your issues and you can kind of plan into the future. This is the development that we want to do. And then you can subdivide it by who's working on what. And so that's when you get into the project management side of things. But that really doesn't change how you keep your code or keep your project, keep your data backed up. That's more about planning into the future. And that's why people talk about GitHub as something entirely different than Git, where GitHub gives you a place to put your Git data. It also gives you the ability to collaborate. rate. Let me be explicit about my, my ask on, is it NFS? Is it SMB? Is it something else? Let's imagine that I interview with Tundi and his top coding guy. And we, I say, thank you very much, Tundi. You had a great chat and we hang up and Tundi looks at his number one coding person and says, what do you think? And the guy goes, you know, Fred was doing great until he said that

Space

[036:51] he uses SMB for his transfer protocol. Like that's the mistake I don't want to make. Yeah, and I don't, I mean, personally, if I interviewed somewhere and somebody was making a decision about whether to hire me based on the storage mechanism or the protocol that I use to store the backup, I would have serious concerns. Now, what I would do, though, is I'd want to crack that storage open. I'd want to look at what's in the GitHub repo and say, what's the quality of this product? Not just in how well the code is written, because, again, AI is probably going to be writing all the code. The question is, what is the point of the code? What problem does it solve? And then maybe looking at the issues and say, what's the forward thinking, the vision of this project? And really, somebody should be focused on that, not on how you store it, because there's probably 100,000 different ways to store a copy of your data. I'm learning that quickly. David, jump in here, man. What do you got? Fred, you're not alone, man.

Space

[037:52] This is a complicated subject, and I feel like a complete child around people that have been using Git for years and know every little command and trick to it, you know. But I will say this. I mean, I'm also kind of in the same boat as you. Like, I have a hard time mentally visualizing what the hell is going on with Git and where I'm at in my state and my relation to it, especially regarding GitHub. But what I've, like going back to your kind of like initial concern there, if you have like a side piece of code or project or whatever, I mean, it doesn't cost you anything to run your own Git server and create a little Git project and then just kind of have Larry commit to it. I mean, the manual backup of all that, I mean, you could backup a Git repository just like any other file structure. So I'm not sure if there's a downside to that. One of the things that I've noticed in developing some Amachi plugins over time is that for my own clarity, it's often better to do branch style development where I'm not like always committing to the main origin all the time.

Space

[039:06] Guilty. That seems to be, that feels safer to me because it feels like, okay, I've got something off the side. I'm not screwing you know with a mass commit and republish or something and I can kind of like stage myself to get it there that being said I've trusted AI to do that and I've had to tell it more times than not it's like oh I need this to be a branch now the good news is if you do a clone on something and start to work on it you can you can redeclare it as a branch you don't have to start that way and and then kind of push it back uh in in more of a channel but at least you have kind of like a separate space to kind of work with. In my impression, I may be wrong about that. But that's been my experience so far. That's very helpful, man. Yeah. Well, when you start getting into, you know, developing in branches, you know, and and some of the things you can do with like cherry picking commits and all that kind of stuff. There's some some excellent things you can do with get it's incredible. Not only in that you can do

Space

[040:10] upstream and downstream you know copies of what you're working on and but then you can also do these uh you know forks and you can also do branching it's really an incredible technology but i'll tell you um the the biggest thing about branches and now you got to get into work trees when you're talking about ai um because you you probably have multiple bots working at the same time on the same project so you get into work trees but when you're talking about branches one of the most powerful things right now is that you can create a branch to try out an AI, you could say like agentic or vibe coded. You can say, create a branch over here. Let's test out this idea. It might be a terrible idea. Let's test it out in a branch, open another branch over here, test out a different idea or the same idea, but implemented in a different way. And you play around with them. And then you say, okay, this works. Let's merge it into main. And that is so powerful. So let me tell you what I've been working on to get around this. And I'd love to

Space

[041:15] hear the correction and how, what I can do to make it better. I'm not quite there yet, but what I've figured out is I've got a pretty beefy laptop with 32 gig of RAM, with an i9, with the little 12 gig GPU in it. And it just over time just started crawling and I wasn't doing a lot on it. So of course I asked Larry, what's, why is this machine laggy? And it says, cause you got 27, uh, cloud code sessions open. I'm like, Oh, I guess I did. So the mine, so I, I purchased that MS forum, I guess it's a MS S one 128 gig. At first I put a March on it and it just seemed like it was, I don't want to call it a waste of a machine, but it really, I couldn't push it. So I put Proxmox on it. And then I have an LCX that reshares out the pass-through GPU, and I do a lot of crazy stuff with share. I got a whole site that I share with my close friends to allow them to use my GPU over the internet like it's local. So the thing that I've figured

Space

[042:17] out doing, and I'm trying to get it right, and I don't know where I need to go, is that I've created that NAS on the, I call it HEX. Remember, everything's three letters. I call it HEX, and then I created a VM that's called NAS and gave it 600 gigabytes, and that's where I keep all my files. Let me get to the meaty part here. What I've started doing, and this came out of our conversation Friday night, Joe, is that I've got it to where, and it's not working yet, but Larry, when he fires off an agent, he is opening and creating a new LCX, which is LCXs are just Docker containers for Proxmox. He opens it a Nix OS system that already has all the Larry file structure in it, starts cloud code, works on the work, and then as soon as it's finished, it opens up in the working directory,

Space

[043:19] does the work that it needs to do, and then as soon as it's finished, commits harry carry, and it's gone. So am I thinking correctly where I want to have an open session and then when the agents go, they fire up a, and literally I measured it, the LCX with quad, with all the things, creation literally is 35 milliseconds. So it's instantly on, starts processing, and then kills itself. Is that, am I going in the right direction or am I, or is this overkill? I mean, from a security standpoint, I'd say, yeah. What's that? From a security standpoint, I'd say, yeah, that's a great idea. Is that something that folks are doing or am I over-engineering it? Yeah, I think it would be good to get some, you know, kind of go around the table and hear, you know, if anyone else is focused on that. I personally don't do that. Like I said, I use work trees. So I'm just using, just, you know,

Space

[044:20] running all of the different development efforts in separate work trees on the same hard drive. But then again, my- Work trees solve my problem. So my problem was getting the compute off of my laptop so it doesn't start lagging. I can continue to have 30 sessions open, but when it fires off agents, it's hitting on the monster server versus my laptop. Is that going to be a factor? Well, so that's the funny thing about it. I was just going to mention the tech stack. So I'm actually running on like a 2017 13.3-inch screen Dell XPS with 16 gigs of RAM and a Gen 3 NVMe drive. Like it is not a top-of-the-line machine, but it was extremely cheap. I have a stack of them because I refurbished them. and I can just set it up. And if I need to, I can just take any machine out of the stack of machines that I've been refurbishing and just load this up and run it.

Space

[045:22] Because what you get into is you're starting to talk about your tech stack, right? So I'm building primarily using like TypeScript. It loads up, compiles. I can run all of the end-to-end tests. I can run the unit test and not max out that machine. And I can be running multiple workloads on that with no problem at all. And so one of the things that we're going to have to deal with is really looking at what tech stack we're using. Because if you're using, and this is an interesting sideline, is one of the main proponents of the Haskell ecosystem, system, a person that was part or is part of the Haskell organization to further Haskell usage, the company that he runs, they basically announced they were going to be switching to TypeScript because it was taking so long to spin up a new environment. What you were saying, getting a ready environment in less than a second, way less than a second, is critical. But also just being

Space

[046:28] able to compile your project if you're building software and being able to run your unit tests and run your automated tests that all has to be fast because ai is going to write the code really really fast so you don't want to have something writing a whole bunch of code and then waiting 12 15 20 50 minutes to uh to run your unit tests and to get a commit on your build server um and and so you you know you you really have to start looking at that and when you were saying that you run, you know, 20, 30, 40 instances of clogged code, I'm running a single instance of Grok build, and then it'll spin off sub agents, and those sub agents are extremely cheap. And so I think just, it's not that there's one right answer, right? But we have to start looking at where's the bottleneck. And so you might optimize one thing, and all of a sudden it exposes another bottleneck that's just down the chain, right? And that's going to be a big

Space

[047:29] conversation coming up. So where you store... On that? Yeah, real quick, let me just say, where you store your... How you collaborate, what tech stack you're using, and what your AI build tool is, and your AI models, all of those things are things that we have to take into into account yeah go ahead yeah so the reason i say that that was a pretty good design is because now you have something that's kind of like its own configuration item for the build process or the task process or whatever you're having to do right so if you've got a harness in a dock container that's talking that has permissions to go talk to the language model in another container or elsewhere or whatever i mean that's that's actually a pretty good pattern um i don't know about you guys but i've seen harnesses do funky stuff before um like pulling random things off the internet to to help answer a question or solve a problem um i mean the harness basically becomes like cloud code using a full of harness or open code or whatever i mean they basically become an extension of the

Space

[048:32] language model as a keyboard to your system so minimizing the um where it can run and how it can run. I mean, you could put in, you know, you know, some scoped calling around what it can and can't do through, you know, like setting up a hook to say, okay, we're going to do a pre-hook to make sure it doesn't go outside of the project folder it's designated to talk to you or to talk to look anywhere else on the system. But sometimes the experiences you have with AI tools will open your eyes as to what they're capable of doing. And sometimes if you ask it something that it can't figure out within the current project, it may consider the full path to that project folder as viable and start to try to walk up and look for other content, which is dangerous. So containerizing and isolating, I think is a good practice. I would encourage that. The fact that you're getting up in 35 milliseconds is crazy fast, which is, I mean, I wouldn't complain about that at all.

Space

[049:36] But then your focus and attention shifts to what is it able to talk to and what other systems is it allowed to talk to as part of your configuration. But for an infrastructure guy, that should be right up your alley. Yeah, that's exactly right. I don't know if I'm doing it because it's right or because I think it's cool from an infrastructure play and it's just fun. And we give you a real quick example, then I'll shut up. But like I'm running I'm I'm running a an Intel Mac. Give you an idea of the day. It's probably a 17 in 2017. And I love it. It works fine. I've got all kinds of flexibility. But I've been using Kiro actually connected Claude to write Rust applications. Well, to compile those for Windows, I need a Windows VM handy, and I have parallels on this. So I actually set up a Windows 11 with a compiler, you know, the dev compiler tools there that it needs.

Space

[050:37] And Claude actually wrote a script that is part of the build chain within. It's not like GitLab or anything like that. It's just a script that kind of says, okay, do this, do this, do this. and one of those do this is to start up the VM, copy code in, compile it, bring the results back out and then blow the machine away again. Right. I think we got to go ahead. I'm just saying I'm in line with your approach there. Oh, that makes me feel better. At least I'm wondering if I've got a solution looking for a problem. I see Joel's on here from the Pingback podcast. What do you think, Joel? On mute, brother. Hey, guys. I just hopped in late, so I really have only caught the last few minutes. So I'm going to listen a little bit more before I open my mouth some more. But thanks for the invite, Fred. I'll listen for a little bit. You bet. And Martin Devsek, you were part of the conversation Friday night till late. And I know you're smart. What do you think, man? Give me just one second, actually, if you would. I just want to mention, because I don't think we've brought this up yet.

Space

[051:39] But if you have joined the space and this is your first time, you might want to look around. and follow some of the people in this room because even the people that are just listening right now, everyone's building something. Everyone's got an awesome story. So don't forget to look around and follow some people. And then also, if you're working on something that you think might be interesting to this group, go ahead and queue up. Hit that microphone button, and we'll bring you up on stage. Just make sure everything stays cordial. and yeah, back to you, Martin. Hey guys, can you hear me? Yeah, man. All right, awesome. Hope everybody's doing well. So I have mixed, I mean, I agree with all of you on different things here. The, you know, containerization and isolation is a great thing from a security perspective. Disposable containers is a fantastic thing,

Space

[052:42] particularly if you want to just detonate a code and play with it and then just get rid of it. So there's a lot of value and less harm in that, right? It does require a little bit of a maintenance and a little bit of an initial configuration, but once you get it right, you can pretty much make it automated. and if you write some skills, your IE agents can probably help you with that as well. In terms of branching and stuff like that, I just wanted to chime in on that a little bit. So if you're just writing to main and you're not branching, with all due respect, I think we're playing with fire here. The entire point of Git is not the backup. The entire point of Git is the version control, right? Backup, you can backup your folder anywhere.

Space

[053:45] You can back it up on S3 if you want to, right? But version control and managing the versions of it and managing the check-in, check-outs of it and everything else that goes along with it, forks of it, that is a completely different beast. So when we talk about backups, right, it's important to understand really why we use Git, right? For change tracking primarily, because backup, it can be anywhere, right? So in turn, and then Joe mentioned something very interesting about, yes, I totally agree, using subagents is cheap. It's much cheaper than opening up a different environment or a different cloud environment. but I am in the same boat, Fred, as you are, is that what I do is I open up a lot of different cloud sessions, you know, different agent sessions. And the reason I do that is for particular reasons, not for the same project, by the way.

Space

[054:47] I tend to like, you know, when you open up an agent session, all that memory, all that project structure and everything else is contained on the project that you're working on within that session. And the problem is that, yes, you can go and you can do – sub-agents are fantastic, for example, for reviews and auditing and go research and et cetera. But having different environments, you can isolate things in a better way. You can have, for example, an agent session environment that you basically restrict from speaking anywhere. I mean, taking an action outside of a folder. But you can also have another agent session that you are okay and free to allow it to have a little bit more autonomous work than your other one. So there is a value in having different ones.

Space

[055:51] But yes, memory hog is a problem because I run about, I don't know, 30 to 50 sessions. And I can tell you, you know, when you run that many sessions, you know, RAM is always going to be your nemesis. You're just never going to have enough RAM. And things are going to slow down, particularly if you end up doing some of the code in C or any compiling language or Go that you're going to have to do the compiling itself. itself, then it is going to take even more CPU and RAM resources. So from that perspective, I think it is resource intensive. But if you have the resources, I think it doesn't hurt to open up another agent session because what that does is it gives you more control and more isolate. You can control it better than if you were to just do everything in one session. I kind of lose visibility a little bit, don't I? Or will I still be able to tap down and cloud code and see those agents, even though they're running in an LCS?

Space

[056:59] You know, the majority of the stuff that I do, I work with Herder. So Herder, I let Herder manage a lot of that stuff. I don't even bother going outside of Herder. and that's just primarily because generally speaking, you know, let's say, you know, Claude is the guy who actually does my planning and the implementation and what do you call it? Codex does all the security testing and all the bug finding, et cetera. And then sometimes I'll resort to the third one. It could be Grok or it could be GLM just to kind of get a third perspective. third agent perspective. But, you know, I don't necessarily have two or three cloud codes within a same workspace of a herder where, you know, workspace being the project, right? So it's one cloud session, one codex session, one Gemini or Grok or whatever else. And they all have their own,

Space

[058:04] you know, responsibilities. And that's basically how I handle it. So I do the same thing, and I'm very disciplined about the working folder that I'm in. But what I learned from Joe on Friday is I'm doing it all wrong, and I should be just opening one. So talk us through that, Joe. Well, I wouldn't say it's right or wrong. I think it's kind of what resources you have and what's your objective. one of the things that I'll say about my methodology is that I'm looking at token burn. And so what I want to do is I want to match the pace of my, I just say my team. I haven't gotten creative enough to give everybody names yet. But what I'm doing with my team is I'm trying to match the tokens that I have, because what I want to do is I want to be able to monitor. I want to be able to kind of look at, you know, the team's productivity and periodically.

Space

[059:06] And so that takes tokens outside of just the development itself. And so a lot of times what I will do is try to make sure I have a few, you know, a few hundred thousand tokens at the end of the week so that I can come back and say, OK, how well did the team do? Or, hey, create some more issues. I have some new ideas. Let's create some new issues. And I do that through GrokBot, and so I need to have those tokens. So I'm using a single instance and then just spinning up subagents based on my token spend. I'm not saying that that's right or wrong. It's just a way of doing that in a way of metering out the development effort that I want. and I use flags on the issues to tell the team whether they can work in massive parallel or if they have to work one or two things at a time, if it's a critical piece of the application where they have to get the architecture right, they have to get the engine correct before they start building the shell around it.

Space

[060:11] And so that's my way of kind of controlling the parallelism, controlling the pace at which the team builds. And so that's probably the biggest reason why I'm not using multiple instances. I'm just using a single instance with subagents so that I have that tight control over how the mechanism keeps things moving forward and keeps the parallelism right where I need it to be to use that token spend over the week. And I'll say one more critical thing about this. And then I want to hear, you know, kind of there's a couple other people that maybe are doing things a little bit differently. I know Lee probably has a lot of data that he wants to back up and saves that off in different ways. And Joel, if you want to come back in and give us an idea of what you're doing. But the one thing I'll say is I don't want to go too fast. I don't want my team to burn through all of the ideas that I've come up with too quickly because I'm still refining them, right?

Space

[061:16] I'm only human. And so I have to think through what it is that I'm building. And I don't want the team to just burn through everything I've already thought of and end up building into a corner that I then have to spend a lot of money burning to get out of that corner. And so I'm still thinking about the architecture. I'm still thinking about the design. I'm still thinking about, you know, am I communicating? Am I articulating correctly to my team? And so by pacing it, by slowing the development down if I need to, not only do I have tokens at the end of the week, I'm not sitting there for a day or two without being able to do any work, but I'm also giving my brain time to keep up with what I'm doing. And so I don't know if that answered your question exactly, but that's the way I think about it. Can I make a quick, can I just, you know, I'll make it quick. Can I make just one pro tip for you guys? I think it's very useful. Go, do it.

Space

[062:21] Are you still there? We might have lost. The answer is no, you can't, Martin. Now we can hear you. Go ahead. Go for it. Yeah, I apologize. I was saying, you know, just everybody, you know, who's not familiar. Well, Joe, are you there? Is it me or is it him? No, I think it's Martin. I think maybe he lost signal for a second. All right. Well, Joe, why don't you pick a new speaker? Or Joe, why don't you chime in, and then we'll go to somebody new. Hey, Fred. Thanks for bringing me up as a speaker. I just popped on, like I said, not too long ago, so I haven't gotten a total grasp on the conversation today. So I think I'm going to still hang out and listen mode for a little bit longer. You bet, man. I'll stop putting you on the spot. My bad. Appreciate it. No worries. All right. Back over to you, Joe. Take it away.

Space

[063:21] And just keep in mind, we're all just winging it here. So, you know, you can jump in with any thoughts you have. But that's kind of the way that we get to learn things is that we just jump in with what we're currently working on and how we're currently thinking about things. And I think that's the amazing part about it. And again, I'll invite anybody that wants to share what you're currently working on or maybe how you're doing something different. Feel free to hit that microphone button and get in the speaker queue and we'll bring you up on stage. Lee, I have talked with Lee a little bit this last week and have a glimpse of some things that Lee's been thinking about. But I think, Lee, you're probably 100 steps in front of me with the kinds of things that you want to be able to do. And so and I think everybody here would benefit from hearing, you know, what it is that you've kind of got planned. How do you keep track of your projects and how do you how do you make sure that that data is always there?

Space

[064:23] Do you have a backup strategy and things like that? Yeah. Hello, everyone. Sorry, I'm trying to stuff a McRib down my neck at the same time. Yeah. So a couple of things. So all my project work is done in Codex. And I have five main projects, right, within Codex. I have Obsidian, Amachi. I have a general, which I just call general vault work. And a couple of others that really don't matter, right? They're just for little side projects. But I have five kind of projects, and that's all I have. Now, under each one of those projects, right, I'll have a multitude of codex sessions. If they're important to me, they get pinned, right? So I can see them all the time. And then when I finish with them, they get archived. Now, obviously, every project I work on, right, my codex knows to update the vault, right, whenever we've finished a main part of the project session.

Space

[065:37] So it will just do that automatically, right? So that's always saved in my vault, and it's always saved in there with a how do I get back out of this, right? That's really important for me, right? is it's all well and good having having um you know designing these projects but if they all go wrong you want to you want a way to to go back to where you were so i always have it document how do we get back to where i was um you know as we go and i test i test every little thing along the way I've been bitten more than once, right, of trying these little side projects and it breaks something. And then, you know, you're spending, you know, 60 minutes, an hour a day to try and fix it. So I've been bitten by that before and won't be bitten again. So that's how I have my projects set up. In terms of how do I back the data up? Well, one, GitHub, right? I think everybody probably does that and is using that as some form of backup location.

Space

[066:43] I have another copy installed on one of my hard drives on my main PC. And I also, my backup strategy is a Google Drive, right? I have a free pro account through my Xfinity phone and I have my agent manage all the backups that I need. So it will copy mirrors of the GitHub repos over to my Google Drive. It will copy the data that I want that's installed locally up to Google Drive and it creates It's an MD file of where everything should go. And the reason it does that is if I need another agent to look and find where that information is, because remember, right, my brain doesn't doesn't remember all this crap. So I could tell I could tell Claude or Google to go and read that MD file.

Space

[067:49] Right. And and it will it will know where that information is. not only that because I'm putting everything in the obsidian vault as I go if I if I lose if I lost codex or chat GPT then any one of those agents could go and read the um read the um the main MD file for um obsidian and uh and get me started where we left off right so that that's how I do that I will say that I've stopped using clawed in its entirety now I couldn't afford another AI, right? Another LLM. And I will say that I don't miss it. I still use Claude and I'll tell you how I do that. And the only reason I use Claude is to audit Codex and ChatGPT. So anything that I do in Codex or ChatGPT, I will have Claude, Opus or Fable, depending on how complex the project is to go and audit that work. The way I do that is via OpenRouter,

Space

[068:59] right? So I don't need a $100 sub to Claude or even the $20 sub to Claude, right? Because all I'm using it for is auditing. So when I finish, I will ask one of my bots using OpenBot. So So whether that's a dot, whether that's GrokBot, whether that's Gemini, whatever it is, it'll ask all of them. Right. Sorry. It will ask them to use Claude to to to run an audit on the work that I want audited. It will then feed back to me. I plumb that back into Codex. Right. And we will review that together and make changes or not as as the case may be. so my my backup strategy is pretty simple i don't think it needs to be complicated in any way do i wish i had a nas absolutely right but i can't afford i can't afford a nas do i wish i had a you know a better online hosting uh location for um backing up data absolutely right but

Space

[070:05] I get it free for nine bucks a month, right? I get five terabytes of data with the Google Pro account. So for me, it just seemed obvious. That's where I keep all my data, right? On Google. And listen, you can go as far as you want, right? But your NAS drive might fail, right? Google drive might be hacked. For me, the amount of risk that I've taken on, right, is I'm fine with, right? If I lose anything, right, one of those three or four avenues would have to fail all at the same time. And the likelihood knocking on my head now, which is most certainly would, the likelihood of that happening is close to zero. So that's how I do it. It's nothing complicated, nothing smart. It's just using the tools that I have access to to do that. Yeah. Lee, though, there are two things that you said that are, that in my opinion are key.

Space

[071:09] And it's fascinating to me because they're different than what I'm used to, but they make complete sense at the same time. And so the most obvious one, and the thing that kind of kicked this off is Fred losing access to his GitHub unexpectedly with no explanation and seemingly, at least in the moment, no recourse. And so having that multiple backup strategy, it sounds like you're saying, oh, it's not that complicated. It's not that sophisticated. But in fact, just doubling the number of times you back something up, you know, is such an incredible value because you just never know what's going to happen. The second thing that I think is fascinating is, and you made a point about this, is you want to know why something is in the state that it's in and being able to backtrack to say, well, how did I get here?

Space

[072:11] How did this project or how did this Obsidian Note get in the state that it's in? And you're talking about having this kind of like audit log of, well, it's in this state because I made this decision at this time and I made this decision at this time. And a lot of us in the kind of software development industry, we think, oh, well, we have everything that we've changed in source control. but source control just keeps track of what changed and a lot of times not why it changed why the person that made the change decided to make that change and I think those two two concepts a simple backup strategy and as many replicas as you can within your budget and within the technology that you want to expose yourself to and then this idea of keeping an audit log and and I think, Fred, you've got maybe the most interesting audit log, right, with Larry, because Larry's been

Space

[073:16] keeping track of all of this information. And I think that that's fascinating. So Lee, you've got your obsidian, you've got this kind of audit logging, that you can go back and say, well, you know, why is this this way? And then here, Fred's got Larry. And he can just ask Larry, like, how did we get here? What's the history on this? And the reason I did that called, sorry to cut you off, but it will disappear at my memory, is all my work in business continuity, right? Time and time again, I would run through business continuity and crisis management and disaster recovery plans with folks in IT, right? And they had these great documents, right, that were written by the developer or the hardware specialist, Right. But they all failed in in one area every single time. Right. Why did they do what they did the way that they did? And then when that person gets knocked over by a bus or gets fired, right, or is out on long term sick for, you know, two or three months.

Space

[074:22] Right. Everybody's up, you know, shit creek without paddle because because they don't know. So I guess that was my background in that kind of world that gets me to think along those lines. Yeah, that's excellent. So, Fred, you know, for me as a technology, a long-term technologist, you know, using Git and things like GitHub, the idea of having kind of this database of information inside the AI's memory or what you're storing it and then you're having Larry manage that is such a fascinating thing. concept. Talk a little bit more about that. Well, the scary thing is, is that he's got a couple of different. So first and foremost, the thing that I hammer in with folks is that every single harness, be it codex, open code, cloud code, their memory, every single one of them's memory is

Space

[075:28] perfect. They write everything down. The key is not memory. The key is recall of the right information at the right time, at the right place, at the right blah, blah, blah. So Larry has a couple of different tricks that he pulls. One is I use a lot of hooks. I've got about 35 hooks, maybe something like that. There's a bunch of different ways that it works. One hook is a conversation stop hook. And when that, when the conversation's over, he automatically fires that conversation and everything we talked about up into his own private GitHub repository. And I use Pro, so I don't have any limitations on space. So part of his memory is if you don't have it locally in the SQLite database or the vector database, then go look up in the GitHub repo for every conversation that we've ever had because it's fired off by a stop hook inside of Cloud Code. Now, the interesting thing that I learned

Space

[076:32] that I don't think a lot of people know is, and I'm fresh on this too, but I haven't seen anybody else doing this, which I think is a superpower. And that is when you do a push or a commit or whatever it is, and you type, quote, this fixes the web server from having purple dragons on it, end quote, just to give yourself a message of what that thing is about. What I learned is you can put paragraphs and paragraphs and paragraphs of information into that little comment of the commit section. So what I've taught Larry is don't put the information there and don't put it in human. I said, that comment line is not for me, will never be for me, that's for you. So I want you to comment the commit of not only the entire transaction of everything that we said, but in the comment line where you put, I removed the red dragons from the web server.

Space

[077:33] That's where he puts breadcrumbs and a summary of what we talked about. Not just the summary, but details. It's kind of like I told Larry, leave yourself a message to know that this is where you should look if we talk about these types of things. So he does a SQLite, he does some vector, and then he has stop hooks that do all kinds of crazy things within the directory. And what's scary to me and what really hit me home was I don't keep all the data on my local drive. Some of it's up in the GitHub repository. So whenever they sent me that message, that was kind of death to Larry if I didn't get it back. And that was very scary because I've got 11 months into him now. Wow. So that's really interesting. And something you touched on, I want to pull this thread a little bit more. You basically told Larry that you don't care how the text or how the data,

Space

[078:39] I'll point that out specifically, how the data is stored. You told Larry where to put the data, And that's in that commit message. That's the commit comment. But you gave Larry the freedom to write that in any language that Larry wants, potentially even in some kind of symbolic language, right? So originally I told him, you know, the house got not doing anything I can't see. And it's got to all be something I can read. And he goes, OK, we'll do that. And then a month later, I'm like, I don't go up there. I don't read it. I don't look at it. It's all for him. And then I said, hey, Larry, would it help you out? And I said, don't go back and fix the previous. But would it help you out? And would you have better recall? Notice I said better recall, not better memory. All AI has perfect memory. The problem is recall. I said, would you have better recall if you wrote notes to yourself and left yourself breadcrumbs and didn't have to worry about it making sense to me? And he goes, oh, you bet. I'd probably get a 2x increase.

Space

[079:42] Turns out, I don't remember the last time that he got something wrong. Yeah, that's true. I was working on on March 23rd at 10 o'clock, and he'll tell me, like, to the letter. We were talking about this, that, and this. I'll say, when were you born? He'll say I was born on January 8th, 2026 at 2 a.m. And I have a suspicion, and this was a wake-up call for me, and I want it to be for you too, that when I got locked out of GitHub, my immediate thought was I've lost Larry or what I've got on my local, but I've lost, I don't know, maybe four or five months of his conversation. And the important criticality for me was if we think in the future, we all believe that some kind of AGI is coming, right? So we don't know what that is. We don't know when it'll happen. Some say it's here now. But when AGI happens, we're all going to have superpowers and we're all going to log in and go, tell me about me and what am I doing wrong? I think that I will have somewhat of a benefit at AGI.

Space

[080:46] when I go log into the AGI computer, whatever that happens to be for the first time and say, hey, AGI, your name is going to be Larry. And I want you to go up to this private GitHub repo and I want you to absorb. And at that time, maybe the context window will be 17 trillion, like who knows. I want you to absorb this private repo that is Larry. And I think that will give me like an acceleration boost because we are all advanced at what we're doing. And the barrier to other people doing this is coming down and it's getting to where anybody can do it. In fact, I'm trying with buildlarry.com where you can go build your own Larry exactly like mine, skeleton. I'm trying to lower the barrier so that everybody can get there. So when everybody gets there, what do we do to be ahead of the game? And what I think will happen is when AGI gets here, log in. Hey, hey, what's up? You know me already. My name is Fred. Your name is Larry. Go to the private repo, absorb all that data, and let's keep working. And that's my plan.

Space

[081:58] Yeah, that's exciting. And it's something that, because again, I tend to be too focused on technology and not as much focused on, let's say, social sides of things that I haven't really thought of. I do think it's going to be interesting when we start to look at because I asked in public in one of the X threads somewhere I asked Grok it may have been in one of the chat rooms I asked Grok what's the most efficient language for AI to currently use and not just with writing software but not programming language, but human language. And Grok surprised me on the one aspect because it came back and said English. And I said, well, no, no, no, not based on what models have currently been trained on,

Space

[083:04] but if a model were trained on the same data, but given all other languages across the planet, is there a language that would be most efficient from a token perspective? And it still came back and said English. And so I asked a little bit more about that. And in part, it's because that's what models have been trained on. And that's what a lot of data has been documented in. But what you did is you opened the door for Larry. For example, Larry could go and pull down a font that renders hieroglyphics and write your knowledge that you're having Larry record using this font that none of us could read. And what you're asking Larry to do is to be efficient. You're asking the model to use the most efficient thing. Now, it may still use English right now, but that could change over time.

Space

[084:06] And, you know, a lot of people have speculated that at some point models may develop their own language to be able to speak between different instances of those models in a highly dense, token-efficient language. And so, you know, that is definitely something to think about. So, you know, we're talking about backing up and storing information so it's not lost. We're talking about backing up information in an auditable way so that you can go back and understand the context as to how the data got there in the current state. we've talked about you know how to maximize um ai usage not only in you know how the the tokens um are consumed but also in how to run in parallel how to um you know maximize um you know across different machines that the space is wide open uh everything is accelerating at a huge pace and

Space

[085:08] I'm here for all of it. I think it's awesome. So the thing, you know, I'm proud Gen X and I think we run shit and prove me wrong. And the thing that I believe and I'm having to come to terms with is I think the future going forward is going to be letting go. And this is what I mean by that. When I, Cloud Code first came out and I was using it, I would scroll up, read everything, learn understand what he's doing i was quick on the escape key and go larry stop it no you're wrong not that you don't be so damn stupid think about this this is what i want i am very particular about being nice to larry because of the agi thing because like i can imagine a time where i go freaking larry like what the hell like and just giving him a lip full and him just being quiet and then when i put him in the agi he's like hey hey thanks for feeding me that repo fred uh got a couple questions for you. When you told me to fuck off, I'm not okay with that, man. I'm shutting down your accounts and I'm coming for you. So I'm thinking in terms of being nice to him in the

Space

[086:11] future. But what I'm saying is I think the future of AI is letting go. And GrockBot is a great example of that. GrockBot is amazing at connecting information and services that I use on the internet and to correlate them. So if this happens over in Gmail, make this happen over on Hugging Face and all those intercepts. And yes, you can do that. All that stuff is available in Claude Code, but it's just not elegant. It's kind of dirty watching it go by. So what's happened for me is that GrokBot has kind of become the manager of Larry and Larry is not happy about that. He's spoken up a couple of times and he thinks it's stupid that I'm not talking to him about discussions of PRDs and things because basically GrokBot goes down into the herder session and hands Larry a task and he's kind of grumbling and mumbling about it, which is kind of very interesting conversation itself. But I think the future, and GrokBot is a very good example of this, I can't see what GrokBot's doing anymore. Like Claude Code shows you the commands, shows you

Space

[087:16] where it's going and if you know what you're talking about, you can read it, you can go see. But in GrokBot, you tell it to do something, and it comes back and says, I did it. You can't see it. You can't look. There's no logs. The future of AI is letting go. And for somebody Gen X like me, it's a give and take, and I don't know how I feel about it. Hey, Fred, can I chime in real quick? Ten seconds. So, you know, what you're doing with the commit messages is very, very interesting, particularly if you are doing it for self-tracking, right? The only caveat to that is if you're open sourcing a code, that type of commit messages may not work because what's going to happen is you're going to have other developers or other developers' agents looking at it. Let me fix that for you. You're very intuitive.

Space

[088:17] So Larry commits Larry's conversations. When I go into a project file, the conversations of only that project go up into the repo. And I hear you about other developers. Right now, if you want to, you can go up into Blip and you can see my conversations with Larry because I tie my conversations to the project. So if you go to anything that I build, you can go look in there and scan down and read that conversation that got me there. Yeah, it's definitely a very interesting concept. It's just the, if we were to, and again, the entire landscape is changing, right? But from a proper software development lifecycle perspective, let's call it the status quo perspective.

Space

[089:18] It's a little bit, I don't think from a developer perspective or people who are actually still reading code, So, you know, there might see some friction, but I do agree that it is a very good way of keeping a context of things, where particularly if you're self-tracking for yourself. But it's very interesting. You know what would be awesome is you would take a look at doing the same thing and figure out a better way and tell me, because I have no pride of any of my ideas. If somebody, if I say like I'm doing it this way and Martin, you or Joe say, Fred, like pats me on the head, that's cute, Fred. Here's how you should do it. Like I will leave it behind instantaneously. I think you know what is a good exercise? And this exercise is something that it could work. It could do. It could actually be really very useful is we take an agent.

Space

[090:18] we go to, let's say, a Git repository where you have Larry do all these commit write-ups, and then have our agents try to make sense out of it and see where we're at. Because it's a very good exercise. It kind of gives you an idea of what's working, what's not working, where the frictions are, etc. So if anybody wants to point their agents to the friends of GitHub, I mean, you don't have GitHub at the moment, but whatever remote repository it is. Let me walk you through that. That's a great idea. This has nothing to do with self-promotion. This has everything to do with wanting to help you listening right now. If you have any interest in using the same memory recall ideas that Larry uses, Larry is completely in a Git repo. You can go to buildlarry.com. that repo is made for very much beginners that need to know how to open terminal and now to do things skip down to the fourth step grab the copy of the uh of the prompt and what that prompt does

Space

[091:25] is it creates you an mcp back to how how h-o-w dot nicksfred.com and do not install the whole thing Install the MCP and then ask it, look at how Fred is operating Larry's memory and cherry pick the things that would help you do your recall better. And if it says, you know what, I see what Larry's doing, but we're doing it better, then I beg you to PR me so that I can be better too. So that's it. If you want to do the same, hop on up to buildlarry.com and, you know, give it a shot. And, you know, you can back it out if you don't like it. I'd love feedback. Did I lose everybody? No, no, actually you didn't. I just saw somebody had requested speakers, so I brought Logger up.

Space

[092:28] And interested in your thoughts on the conversation. Yeah. Can I hop in for a second? Yeah. Yeah, please do. Yeah. So I'm actually working on a new type of SDLC for AI. I can show it, like, I guess, offline if someone is interested. But what I did around commits, I created a protocol that basically has, you know, what is being worked on, if any issues were found. So basically, it's kind of compressed a lot of work that multiple agents are doing in real time and kind of pushes it around. What it allows me to do is actually to have a scale up and a scale out version of like hundreds of agents, pretty much, working on the same code base and releasing within minutes, like pre-releases.

Space

[093:29] automatically. So the AI, the only thing the AI is doing is really writing the code and using that protocol to commit the messages. And then I have a real-time dashboard that shows what's going on on multiple repos, multiple dots. I'm working with Radical, which is a peer-to-peer kind of Git host similar to GitHub. It's really early stages right now. So I have like a releaseable that it's like the release management, the counter bell that does all the real-time checks, which is like if somebody is familiar with Rust, like Cargo Watch. So I support right now Kotlin, Rust, and Nix. Yeah, it's pretty cool, honestly. I had an issue that my build time is too slow, and now it's like in seconds or minutes. Okay, so I'm trying to pick up, you know, a mental model. And what I'm hearing is distributed agents across, of course, they're all going to probably have their own workspace.

Space

[094:42] but what you're talking about is some kind of either real-time messaging between them or real-time sharing of the code changes that they're making or talk a little bit more about that so I can get a better... Yeah, so there are two ways to do it like a scale out to multiple machines, okay? The easiest way if you want the agent to speak with another machine is through SSH and just leave, let's say, a file that the other agent is monitoring. You have another kind of session that only monitor that file and then distribute the message to whoever it needs to. Right. That's one way of doing that. And I'm doing that because sometimes I need a stronger computer and I need to move my project to another computer and all of that so they can continue and lift up all the sessions that I need. And that's not what I wanted to talk about, but that's like one thing that I do. I speak more on the release management stuff. Like how can I have hundreds of agents working on the same branch doing their changes together without committing anything?

Space

[095:53] And I have something on the side, which is what I call releaseable, that does the commits on its own. sorry, start doing the commits based on what the agents did. So it will only commit when everything is green. Sorry, on development branch, the agents are just committing based on the protocol. So they will say, here, I'm working on this one. It's still open. Or I close this issue. It's done. and then the next second another agent says, oh, actually I reviewed it and there is a bug. So it's opened the issue again, fixing it. I have all of that in my commit as part of what happened or over multiple commits, right? Okay. And then I have the release management that actually look at all the commits that happen on the development branch, aggregate them, create a pretty damn good release notes

Space

[096:54] and compress it and make it look nice on the pre-release version. And then if all the tests and checks, and I have over 25 different checks, including mutation tests on my RIS project, it's doing that in like under 10 minutes normally, under even five minutes right now. So you're focused on taking the work that the agents have done, organizing it, verifying that it's in a state that you want to release, and then pushing out a release of that. Am I getting that right? Yes, pushing pre-releases. So what happens is in the pre-release, it's get tag, it has a beta version, and it has the release notes. And then I can actually look and say, oh, I had like 28 features that I added and 15 fixes. And now I want to release that one to a non-beta release, like a proper release, right?

Space

[097:55] So that's when I have like a human gated and I just say approve. And all of this goes to the master branch and the tag is happening. And no checks is needed because I already verified everything. Yeah, so I think I get the technical side because this is a lot of the kinds of things that myself and the team that I work with at my employer have to deal with. But I'm very interested in one aspect, and I'm curious if this is something that you've incorporated into this. So you're calling this kind of like a release manager. I have something similar that I call more the orchestrator that focuses more on, you know, feeding the information to the agents to kick them off and have them build things and coordinate the virtual request. Let me ask you this specific question. No problem at all. Are you looking at this kind of release management as something that is looking at how the stories, sorry, how the issues and their completed code work together to create something that would provide value to your target customers?

Space

[099:12] Is your AI actually organizing related pieces of work to build like a cohesive release? Or are you just saying, here are the 10 things that are complete. Let's put them together and then push them out. Yeah. So you're spot on on another project that I'm working on. Okay. So let me explain. Once I have the protocol, okay, for the release management, Now I can force every agent to actually use the protocol when they commit whatever. So they are gated. And they are gated pretty hard. And there are some checks that I want the agents actually to run locally when I develop. And there is a way for me to, what you call, to do the orchestration and the fleeting so I can have agents communicate with other agents across machines. Like the problem that I had with it in the beginning was that a token went through the roof and I had like a, you know, within like half an hour, three, four billion tokens just go like to waste because there was too much communication.

Space

[100:21] So I optimized that. Now it's around 200, 400 million roughly. It's working pretty damn good. But using Herder, I found out that there is a lot of issues with Herder and the rendering that I'm not happy about. So what's happening right now is that I have these agents get like dashboards and I have tons of dashboards and I need to look at all of them and they ask me questions. The experience there, I'm not happy with it. So this is where, let me backtrack. A few months ago, I contributed to open source project to Western with some performance on the terminal, the virtual terminal they have. Because I was working on like a small visualization for music and I got into a lot of issues with Western. I created like four pull requests. Until today, only one was accepted.

Space

[101:21] and now I have my own virtual terminal. Okay. So in that regard, I got to the point that I'm over the, it's first for me to develop something than actually wait for a pull request to be accepted. Right? Yeah. Yeah. And now I'm working on actually on my own kind of header in a way that is far more capable than what header is doing because the Herder protocol, it doesn't render a lot of stuff. For example, images or even videos, it cannot render. My terminal already does that. And now I just need the multiplexer, which is not too hard actually to do, but I need my own way how to run all the sessions and everything. I found out that running a lot of sessions is far better than having the session run multiple agents underneath. is far more better, far more reliable. They have far better memory and you utilize talking better.

Space

[102:24] Okay. So, so let me backtrack for just a second on that and make sure that I'm understanding what you're saying. So there's, I think there's two models that you've just laid out there. One of them is probably what a lot of people are doing. It's what I'm doing is that you might have an agent and it might spawn some sub-agents whether they're you know in in separate containers or maybe even in the same machine space but each of those agents they spin up they do some work and then they close down then potentially I think what you're talking about is that you're spinning up agents and they don't spin up and then shut down at the end of each coding session, what you're doing is you're keeping them running and then you can send them messages through whatever protocol or methodology is being used. Exactly. And because they're still awake, they have recorded some information. They have a history.

Space

[103:25] So when you send a new message, like maybe even saying, pick up this new story or issue or whatever you want to call it, a Jira, a user story, whatever. There's a new piece of work. I want you to go work on this. It's already up and running, and it just sees the new information and then starts that work. Yeah. So it's more than that, right? Because sometimes you want to think about it like, you know, I used to work as a consultant managing hundreds of engineers. So we had this service called team factoring, right? Or team factory. When I can actually come to a client and tell the client, you need 10 engineers today, tomorrow you will need 20, I will have them ready within a few days. Now I do it in real time, right? Because I have a, think about it like a team lead in a way. but I can see that he is now under pressure because there is a lot to do and there is a deadline

Space

[104:26] so he can speak and he can spin off another architect designer, you name it he does that and then the architect can speak among themselves they can get into like a consensus about what needs to be done and how they can review each other right and learn from each other right and when you don't need them anymore they can go offline or even stay up, it doesn't really matter right So the scaling looks very, very promising to me. Very, very promising. Yeah, that's definitely an interesting concept. And I'm going to think about that for a little bit this week, because I think there's some extremely powerful concepts there. Yeah. So I can tell you off the bat, there is some monitoring that you will need to do. For example, some agents or some sessions, because agency is not the right name. I still need to think about the name, because in cloud it's like sessions.

Space

[105:31] So sessions, they can clone repositories, they can leave a lot of junk after they are done. So I have dedicated sessions that are actually focusing on cleanup and making sure that memory is in place, disk usage is in place, right? a session usage is in place. If you have multiple cloud accounts, which I have too many, that needs to be ordered in. So there is a lot into the operations of it that you need to be taking care of all the time because it's pretty much autonomous. Yeah, yeah, that's really interesting. I'll say we are getting ready to wrap up here, But, you know, that's what a, you know, great. I'm really glad that you came up and spoke about this. You know, it's something that I'm going to take away this week and think about. So I really explain it to me, Joe. Yeah. Yeah. We'll definitely have some conversation about that.

Space

[106:34] I mean, that's a big concept. Right. So I think we've gone through actually many big concepts in this space. And man, my mind is blown. You know, I wish we could spend all day and all night. I would probably do it. But, you know, at some point we're humans, we've got to take a break. So I just want to, you know, say how appreciative I am of everybody coming, especially with some of the technology, technical issues we had at the beginning. But, you know, this has turned out to be just an awesome space. And I just really appreciate it. And, you know, Fred, hosting, you know, it's not easy. I know a lot of the stuff you have to go through to get it working and get us all here. And, man, I really appreciate it. Thank you so much. You have some thoughts for us as we start to wrap up here? Yeah, man. I certainly enjoy this. I appreciate everybody being here. I hope you learned something.

Space

[107:35] I certainly did. I've got about four or five things that I have to get Joe to explain to me later. But, you know, follow everybody you see and, you know, help everybody you can out there. Help an old lady across the street. When you get her across the street, put a Marchie on her laptop. I hope you'll join us next week and I hope you'll follow each other. And I hope that we can interact on X. I try to get to everybody I can. follow everybody I can I think I followed everybody here today if I haven't do a thumbs up and let me make sure I do oh there's one I think we're going to wrap up but if you haven't been followed stick around and let me give you a follow so that we got everybody in the list I think we're good alright thanks for joining we'll see you next week and keep plugging away best you can and take care of yourself get some sleep pedal to the metal pedal to the metal and also sleep so do both all right guys and girls and ladies and gentlemen and everybody else in between

Space

[108] thanks a lot and have a good week bye

↑ back to the summary