Hello, hello. Hey, Scott, good to see you. Hey, good to see you. How are things? Busy, busy, busy. But good. I've been playing with Purser's new CLI Agent plus GPT-5 today. Oh, yeah. So far, it seems pretty solid. Really? Plus, they're subsidizing it right now, right? So it's free at the moment.

But it seems to be doing as good or better than AMP code, which I had been using, which is paper token, which is so it adds up a lot. So it's not as steerable, I think. Like, they don't have the nice, like, app mentioned feature working in their CLI and other things, but it seems to be doing pretty good.

We'll see how it does when they actually start counting tokens and how the costs measure up. Yeah. I saw. Did I see it in the latent space discord? Oh, I saw somebody. I think it was Kieran Klassen from every created a sub agent that uses the cursor CLI for cloud code.

So you can actually use GPT-5 in cloud code. I'm sure Anthropic loves that. If anyone tried Zen MCP, I found that really useful for using O3 before this, and you can use GPT-5 via the API as well. I just haven't had a chance to see what that's like. Well, I'm excited for this presentation, Scott, because I think, you know, as Manuel is talking about, none of the tools, the coding tools and the models, like their boats are small and constantly being one ups.

But where we will have enduring gains is where we learn how to use them all better. And so that's I hope what you're going to be teaching us today. Yeah, I hope I hope that's what you all I hope that comes through. I mean, it is very fluid and, you know, it's actually something Manuel and I have talked about a few times of just like, you know, while these techniques might not like you pick up these techniques based on the limitations of the models at the time.

And even if you don't necessarily need them anymore, you can you have that tool in your toolbox for, you know, when some kind of situation arises. So at the very least, if we're already moved on from document based by coding systems into sub agents and GPT-5, hopefully there's a nugget in here.

I personally find using like I've been using coding agents now, particularly amp a lot, and I find the document based workflow is still high value, especially for more complex things. So, you know, we're in an existing system. We're not vibe coding something from scratch. There are, you know, substantial, you're changing your refactoring your things like that, like, use the agent to build a document, review it, critique it, fix it, then have the agent build it.

But like that document still is sort of a key grounding loop. Yeah. Yeah, my systems kind of I'll walk through what I talked about in the post, and then we kind of like where I've gone, but it's definitely changed, changed a bit and gotten a little. A little bit, a little bit less systematic as different things have come up.

So, I think that's a good thing. I think that's a good thing. I think that's a good thing. I think that's a good thing. I think that's a good thing. I think that's a good thing. I think that's a good thing. I think that's a good thing. I think that's a good thing.

I think that's a good thing. I think that's a good thing. I think that's a good thing. I think that's a good thing. I think that's a good thing. I think that's a good thing. I think that's a good thing. I think that's a good thing. I think that's a good thing.

I think that's a good thing. I think that's a good thing. I think that's a good thing. I think that's a good thing. I think that's a good thing. I think that's a good thing. I think that's a good thing. I think that's a good thing. I think that's a good thing.

I think that's a good thing. I think that's a good thing. I think that's a good thing. I think that's a good thing. I think that's a good thing. I think that's a good thing. I think that's a good thing. So, I think that's a good thing. I think that's a good thing.

I think that's a good thing. I think that's a good thing. I think that's a good thing. I think that's a good thing. I think that's a good thing. I think that's a good thing. All right. Yeah, why don't you go ahead? I'll go off camera. Do you want me to watch the comments or you got it?

Let's see. Yeah, pop in if I seem to miss anything. I guess we can jump in. We'll have that for text size. Looks readable here. All right. Cool. Yeah. Thanks, everybody. And thanks for letting me come share. Yeah, so this is a, you know, going to be talking about document based vibe coding systems.

This all kind of came about as I was working on, we actually kind of been trying to challenge myself working with agents to use programming languages and tooling that I don't know so I won't jump in and like edit the code. And so this was for an app that was built in Tori using Rust and TypeScript in both languages.

I don't really, I absolutely don't know anything about Rust, but I haven't really touched TypeScript. And so basically had had one of the, one of the reasoning models create and an architecture file. and, you know, like K-Ball and I were talking about in the beginning. It was, you know, build out, build out a, an architecture doc, refine it, ask questions.

My primary language, Ruby. Um, a lot of those stuff that I'm building is in Ruby, but, um, you know, it's, it's hard to, it's hard to have like really strong opinions about AI generated code. And, uh, when you do, you end up, you know, not really liking what it, uh, gives you.

So, um, but yeah, so this, I mean, basically kept it at a, kept it, kept it at a really high level. Um, kept it at a really high level. Just like, what are these, what are these pieces? Um, I didn't really know the libraries or anything, but, um, you know, it gave me a architecture diagram, all this stuff.

And then what I set up with cloud code was basically here is the, here's the architecture file. Um, we're going to work together where you're going to tell me what you plan to do. And, um, then you're going to do it. Then you're going to tell me what you did and, um, and then tell me what in the app to actually change.

Um, we're going to work through stories. So I had it go through the architecture diagram, figure out, um, you know, three, three project phases, break that down into roughly, uh, you know, I think I said 15 minute, uh, actually, let's see if it's in here. Um, yeah. Uh, it came back with some of these phases around like estimated timeline, six to eight weeks with dedicated development.

Um, which obviously wasn't true. Um, and, uh, let's see here. Uh, let's see here. And also kind of peeking at the chat. Um, sorry. And, um, yeah, basically broke things out into stories, create a project plan documents for those. It came up with three. And as you can see, if you can see some of the texts on the left here, there's a bunch of other plan files that I've used.

Um, and then as we were going through, if there are anything that you, anything that you run into that, you need to, that we don't want to keep going over. Or like we end up, you know, bug fixing store that in the technical considerations, markdown file and, um, you know, load that.

And so since we were doing like, you know, three phases of like 40 user stories each, we were going to, uh, start and stop sessions all the time. Um, you know, if it, you have to compress context, uh, it forgets all of the roles and process you set up.

And, um, you know, you end up getting a whole bunch of junk in your context. So my process was very much, uh, you do a story and, uh, and kill it, make a commit, push it up. Um, Oh, interesting. Um, but yeah, and then I can, I can jump over to the pair programming dot markdown and, um, or actually, sorry.

Um, but yeah. And then when I would start a session, I would basically say, read cloud dot markdown, follow the steps for quick start a new session. And, um, and then tell me the, tell me the plan for the next story. And it would, you know, read all these files and, uh, and go through.

And so pair programming dot markdown is, um, you know, pick up the next story. Uh, you know, create a plan, implement the plan, testing and verification, and then human verification. So summarize what was implemented. This, what, uh, should be visible and, um, you know, provide specific testing steps for the human.

Um, yes, we will. I will definitely, uh, go through a process of just kind of like, kind of setting the stage here. Um, so yeah, um, there's the, the pair programming. And then one other thing that, that did end up happening in the, uh, the technical considerations ended up getting really long.

And so I ended up not having enough context to do, uh, do an entire story. So had Claude break this down into a technical considerations folder where it could look up different things and have a reference for, for anything that we might run into. Um, because it does tend to, um, you know, once, once you find it make, uh, you know, a, a, once it does something wrong, you'll find that it'll do that thing wrong over and over.

Um, and so having, having these, uh, these technical considerations docs, uh, helped a lot. Um, but before we jump into the process, are there any questions of what I kind of just showed here? And I can show, um, it actually in action. How much of this is project specific versus you carry over from project to project?

Um, so this one was particularly, this one was the first one. So it was very project specific. Um, so if you see the pair programming dot markdown, uh, you know, outlines the pair programming workflow for protocol. Um, there's, there's no Kali, there's PN, PM build and no bundle. Um, I've started to use this.

Um, I've started to, you know, when I start a new session or start a new project, I'll say to the Claude code, look at the, look at the pair programming doc in this folder or this file and, uh, adapt it for this project. Um, but yeah, I guess I'd say, you know, the structure is common across project, but like the details, I'll usually have Claude jump in and change.

So like the, the, the, the handful of documents to start things out. Um, man, well, how do you clean up the CF markdown files? I, uh, you'll see, as I switch around different projects, I kind of don't. Um, I had, I did see that there was a new feature with Claude code recently where you can add additional, uh, you can add additional kind of like permanent working directories.

And so whenever I find the time, I'm gonna try to, uh, you know, set it up to be my, uh, obsidian directories. And so have it like right there and, uh, write and read from the obsidian directory for the project, but I haven't done that yet. And I just have a mess of files in, uh, in all different places.

Like, uh, sometimes it'll, it decided to put them in tech docs in this project and docs in this other project. It decided to use two different folders. Um, but I've better, I've generally just been pretty hands-off letting it do what it wants. And like the parts where I've designed where I want to, I want to review, I'll get an extra kind of time to, to look at it, but, um, not really, not really being very strict about any of that.

Yikes. How much, how much did you write or come up with versus how much was go set it up like this? Uh, almost all of it was go set it up like this, Claude. I think I wrote a handful of sentences of like what I wanted, then it would edit the doc.

And then I would do a quick skim and say, uh, you know, uh, let it go. And if it, um, you know, if anything went wrong, I'd say, you know, this, this sucks or like, this doesn't work. Uh, update the doc, update this doc, the doc with this new thing that we know now.

Uh, the architecture decisions were mostly Claude. Um, I would usually, usually kind of let Claude do the first pass. And then once we try to start doing, once we start running into issues, jump in and be like, yeah, it probably needs to go this other way. Oh, instruction architecture.

Uh, the instruction architecture, meaning. Yeah. Uh, basically what I'm getting at is, um, uh, so you have like your pair programming, your technical considerations, et cetera, et cetera. Were those things were like those kinds of documents. Um, did you decide, like, I think this is the way that the agent should be instructed.

So I think we should make a technical considerations, a browser architecture, blah, blah, blah. And then, Hey, Claude, go, go do it like this. Or did you say, Hey, like Claude, I think this, this project is going to need some structure of how the instructions are formatted. Um, what do you think we should do?

Um, what do you think we should do also go do it? Got it. Yeah, it was, it was mostly me on like the architecting the different docs, uh, mostly because it was, you know, the way I was thinking about it, where this is where the architecture lives. This is the process I want to do.

These are the stories. Um, and I think, I think in my mind, I have this vision of like those being somewhere else and not in markdown files. Like maybe the stories are in some project management tool. Um, maybe the pair programming is baked into an agent at some point.

Okay. So kind of like modeling it off of like, this is how I would normally build software. So I'd probably have this in a project management tool. So Claude's probably gonna need this. So I should make this doc for him kind of kind of thought process. Right. Right. And then as I'm, as I'm kind of prompting being able to, you know, as I'm thinking about it, like this thing is here, go look there.

Um, and it was really just really just like kind of ergonomics for me as I was prompting. Cool. Good influence. Cool. Uh, any other questions before we jump into, um, a couple of demos. All right. Um, so let's see. So let's see. So I guess for the high level, the process that I kind of use, I use, uh, T mocks.

And I usually, this is something I've been doing for a long time. Uh, is each session is tied to a project. And then each project has, uh, I dunno, are they tabs or windows? Um, first tab is cloud code. Second, second tab is Vim. And then what I've been doing is basically I'll switch between, uh, different projects that I'm working on.

So here, and I've got this gonna be doing this update to, um, the library that I work on called sub layer and, um, change things around. So let's say, um, actually, I don't even know if I have the pair programming thing set up in this one, but, um, I've got this generator update doc that has a plan around, uh, how to, how to change this interface from this thing.

And it's like, um, LLM output adapter, and then change it to just generates and then use kind of object literals to, um, define the output. And, um, and, um, let's say, check out, um, update dot MD and, um, up with a list of stories to, uh, change, to make this update.

And, um, um, make sure the stories are about, uh, a few hours in length and, I don't know, um, make sure there's something. Um, for the user to test at each end of each story. Um, and then write that to, um, um, and then, you know, just let that go and switch over to another project.

Like, let's see, we can go to, um, there's this game that we're working on called, uh, the 12th of state. That's kind of like a, a programming game that uses MCP for input. Um, yeah, this comes from a lot of, uh, a lot of years of just, uh, you know, doing the same process over and over.

I don't, uh, let's see. So let's see what we were gonna do. Um, can you create a plan for, um, actually, let's just go ahead and do, um, say. So that's usually, I'd usually just like kind of ad lib here. I don't have, I could probably set up a hook for this, but I've just been like throwing in all the steps for new sessions, new session.

Quick start here. Give me the plan and let that go. And it'll come up with some kind of plan. We're back here. Still going. Um, also got another project that's in, um, Swift, another language that I'm not super familiar with. Okay. And this one is, um, Um, Okay. So we've got planned for the next story.

Demos chapter structure is the first pending story in phase three. Um, create the foundation design tutorial friendly location progression. And so kind of the way that I've designed this is that I'm not really looking too much at the docs, more just that there is a doc. Um, and then before it doesn't even work, I'll get a chance to, uh, to kind of check it out.

And so this one, I think we're actually, um, Yeah. Uh, check out what we have built already for the first room before, uh, make sure the plan. So kind of having these, having these checks in here that, you know, even if the docs aren't exactly right, I've got a chance to kind of like jump in and, and guide it into the right spot.

So there's usually the plan beforehand. It'll do the work. It'll tell me what it did. And sometimes it'll tell me what it did and tell me what to check. Sometimes I'll see what it did and be like, no, that's not right. Do it a different way. And, um, you know, also be able to check the app, be like, this is, this thing is not in the right spot or, um, you know, it's almost there.

But when I click this button, nothing happens. Um, okay, so revised plan, original story, acceptance. Okay. So it actually, it looks like that story was already finished. Uh, uh, uh, that system implementation. And, uh, we'll come back to that one back here. Okay. Created generator update stories.markdown with 14 user stories.

Looks like the first four stories are integrating the literal gem. Um, and yeah, I guess another thing to call out here. I've had a bunch of converse or a bunch of questions about, do you, what, what format do you have the stories in? Is it like given when, then, or as a developer?

And I haven't really kept a tight leash on that either. Uh, just let it do whatever it came up with. Um, and so. Good. Uh, yeah. How do you mentally deal with the context switching? Uh, funny you ask. I'm trying to figure that out too. Um, it is kind of wild, but I mean, the, the thing that.

Yeah, the, the, the thing that helps with the context switching is, um, is having it prompt me each time of like, here's what I did. Uh, 40 years of unmedicated ADHD. That can be it too. Um, kind of performance enhanced a little bit. Um, let's see. Yeah. I'm just gonna turn that on.

Um, but yeah, the, the thing is it'll, it'll tell me what it did. And so that's kind of, if I'm ever like, I'm not sure. That's usually, uh, a guide for me to, um, add that into the docs of like, I didn't know. Um, you know, didn't know what we were doing.

Oh no. Yeah. Sure. Uh, next time. Give me additional context. Yeah. Uh, okay. Ball. That's, that's kind of where my mind has been of just like, how can I have, how can I have AI prep me for the context? Cause I'm gonna keep context switching. Like that's not gonna, that's not gonna go away.

Do I find it enjoyable? Um, yeah, I haven't tried vibe Kanban or Kanban yet. Um, I'm trying to build, trying to build something myself to help feed the context to me as I switch. Um, but I guess if that doesn't work out, I can always, always jump over to that.

Um, and how are you all doing with the context switching I'm doing? I should have, should have asked that. Um, and this one's writing the CSS. Um, I mean, I feel like I can only handle like two threads at once. Really realistically, like I can, I I've tried to do more things at a time and have it going.

And I, it only works for relatively trivial types of stuff. Um, I suppose as the agents continue to get better and I require less actually looking in on it. Um, that may change, but I also find if you're not careful, the, uh, like these tools make everything faster. So if it starts going in the wrong direction, like if you're not careful, it goes really far in the wrong direction and you get a ton of slop or code debt.

Um, yeah. Um, that's, that's, I think another thing of, you know, keeping these, uh, these changes scope small so that if it does go off the rails, uh, it's, it hasn't gone that far. Um, and I'll usually story by story, make a commit. And so I've found that, you know, if I need to just like wipe what it did, uh, it's no big deal.

Um, yeah, the smaller, smaller changes, uh, I've found help that. And then I actually, I guess that kind of helps the context switching too. Um, you know, cause there's not, not as much to, uh, much to do there. Um, and yeah, like Manuel says, I think a lot of these apps are scoped enough in my head, uh, that I can con or they're, they're, they're scoped small enough that they're not, you know, massive projects.

Um, I think, and, and the other thing that I've found helpful is that they're pretty separate projects, right? Like there's a, a Mac OS app, uh, a game and a gem that I'm doing here. And there's not, I don't have to spend much time thinking about like, does this change?

step on the toes of another change in this existing app. It's all just like, kind of like a single thread in, uh, in a single app. Um, but. Um, but. - Yeah. But. Yeah, I don't know. Is there anything that anybody would like me to try? Any other questions?

Brad, how do you, you said 15, 30 minute chunks. It's really kind of just, I guess, like Claude, you know, I guess, I think I probably should have said, you know, half a day or one point story. But like, I think each time I do it, I change it up to try to get Claude to scope them correctly.

I've tried something like, it needs to be, it needs to be big enough that it needs to be big enough that there's something for me to actually test. Because like, if I try to say, if I, if I don't add that in there, it usually does something like this where, and I think I even added it in here and like added the gem.

Like go check and see if the gem's installed, which like isn't super helpful. Um, or it's like not, not a big enough change to like really do anything with. Um, but if I don't give it that like guideline of keep it small, it ends up being something really big, like KBAL said, and like changed hundreds of files.

And I, you know, don't, don't have my head around what, what it actually, what it actually did. And by the time it's doing a whole bunch of different things, it's usually wrong. So kind of like scoping it. Um, yeah, basically trying to find that right scope where it's not too big that what's the, there's some, some measurement that's like the chance of AI being wrong.

increases by the cube, by the square, the cube of the number of tokens that are output. So like trying to, trying to thread that line of like, it's not wrong. It's not like extremely wrong, but also big enough that, uh, you know, it's a meaningful chunk of work. What does wrong mean in that frame?

Uh, I mean, wrong is in like, you know, it doesn't work or. Or it's, you know, yeah, basically, basically that it doesn't work or, um, or something. Yeah, but I mean, I guess, I guess if you think about it, like if I prompted, I could get, I could get a hundred percent correctness or accuracy if I wanted Claude to just write one line at a time.

And then I, I'm kind of not as confident if I had to do like a million lines and like, so there's some sweet spot in there that, uh, it'll, you know, give me a meaningful chunk of work and speed me up and not, uh, not cause me more pain.

Um, how do I see this in a team context? Uh, you know, I think I actually, I said this to somebody the other day, I think teams probably end up looking like. I read this book once about test kitchens for Michelin star restaurants and like that whole, this whole idea of like, everybody has their, um, everybody has their role.

They're the, they're a, they're a master at their craft and they're all working in the same theme, but like everybody has their, their things they're working on. Um, and so I think like, uh, you know, project level separation, uh, is so much easier than trying to coordinate between even two people, uh, because you're moving so fast.

Um, I don't like, I don't even do, I don't even do two Claude codes in the same project because, uh, there's just too much, too much chaos that could go on too much overlap, which maybe that says something about the architectures of the things I'm working on. Um, but, uh, uh, it's just never worked for me.

Um, I haven't tried sub-agents yet. I've been planning to, um, but maybe, maybe in a couple, couple of weeks, I'll write up something about, about trying them or try to write some of my own. Uh, I still feel like coding to you. Uh. Uh, kind of, it's, it's definitely a lot more, even though it's not exactly right, I think like at some point, if you just kind of like, you're looking at features, you're guessing like how they might be built and talking about it like that.

Um, it ends up being a little bit more on the, you know, kind of architect is the wrong word. I don't know. Coding is like, we don't really have the words for the, for right now. Um, it's not exactly coding. It's not exactly architecting, but it's kind of like, you know, like inventing or materializing some piece and then fitting it in and seeing if it fits and then like changing it if it doesn't fit.

Um, and kind of like, kind of like coding or creating in that way. Um, but without code, like I hardly, I hardly ever look at code. I don't think I've, I don't think I've really opened Vim to look at code more than a few hours over the last month.

Uh, it's mostly been looking at, uh, looking at markdown files. Um. Yeah. Spec first workflow. Um, yeah, actually, I guess the speaking of the spec first workflow and, uh, conversations that Manuel, you and I have had about like, uh, TDD. Um, I haven't really been doing much TDD and mostly just been letting it, uh, letting it go.

And then, uh, afterwards, if there's something that's like this, this thing has stopped changing and this thing needs a little bit more, or this thing has stopped changing or this thing is giving us a lot of problems. Um, that's when I'll break something out as like a module and then have it get, you know, either be a library or, uh, something off to the side and be like, give this a hundred percent test coverage.

And that piece will stop being a problem. It'll get out of context and I can either have a cloud code running on that library or, um, you know, just never have to worry about it again. Um, use this flow and Brownfield code bases, um, kind of, I've, I've started adding it.

So it's not exactly, um, not exactly Brownfield unless I think in the way that you're, uh, you're mentioning cable, but, um, like APM, I originally started with the flow of. Uh, you know, having a, a cloud chat up and kind of doing it by hand because I was like, well, I should learn how to learn how to do swift.

And, and then that quickly shifted to, um, you know, there's all these changes I need to make. I should have, uh, AI write out the list of changes and then actually just do the list of changes. And so it was, it was hand coded at first and then have switched over to vibe coding it.

Um, I have actually, the one thing that I've done in, along that in some, some code bases I'm unfamiliar with is actually have it go through and be like, this is a library we want to use. How do these things work here? This is a library we want to use.

Here's an example app of using that library. Um, write out a doc of how these pieces fit together and how this works. Take that doc over to APM. and say, here's a generic doc of how to use this library adapted for our, you look through the code base and adapt it for our use case.

Um, and so that, that ended up working really well. Um, but yeah, I think, I think brownfield code bases, I think the only, the only thing limiting brownfield code bases, uh, would be, uh, getting everybody on board. You know, I think, you know, you kind of need everybody on the team to turn the keys on AI at once, because like, if, if one person is and one person or, and the other people on the team aren't, you're going to get a lot of people really pissed off at like, why, why do I have to review all of these AI slot PRs?

And not this person made a, made a math and made like 20 PRs today. I'm going to use AI to help me review. Uh, I'm going to use AI to help me review these PRs and make these comments and call these things out. Like if you, if you do want to have like multiple people, it's about everybody's using AI to augment them for, augment themselves for all the steps of the process.

But if you have a holdout, like either everybody's going to hate the person using AI or, um, I mean, that's just what's going to happen. Oh, so yeah, I guess I wasn't kind of showing the screen. So, um, yeah, a lot of this is, so I'll have in, let's see, and like protocolle is a Tori app, which uses, um, what's it called?

The byte Vite, V-I-T-E, um, and so all the changes, uh, it's recompiled, it's changes and it, it updates live. Um, and so you, you basically see it as it goes, you can do it for, for React apps as well. The Swift app is a bit of a pain in the ass to see it, uh, in that, like I have to build and, uh, sometimes it doesn't actually build the app.

And so there's build errors and I have to kind of go back, but, um, Um, and yeah, I'm using, using the things that I'm creating all the time. Um, but yeah, Tess, Tess is generous. Um, yeah, yeah. Cause I've seen the same thing, just the, the traditional engineering background, the, the whole, the whole idea of, uh, you know, what does this do?

Like, why is there all this extra code? Like, yeah, don't worry about it. It doesn't even get called. Um, that, that definitely offends a lot of sensibilities. Um, we can jump into something else if anybody's interested or invite some more people up to chat. Have you tried actually using this in a team context at all, or is it still all just for solo projects primarily?

It's yeah, it's basically just me right now. Um, I haven't really had a chance to try it with, in a team context. I think everybody would have a very bad time. I think that, yeah, there are very few teams I think that can actually the, uh, you know, handle the, the code volume at this point.

So I think that's an interesting problem to solve. Right, right. Yeah. I don't know. Um, I think a lot of, a lot of spots in, in a team aren't, aren't prepared for this. this, you know, small, small startups where you've got one or two people. I think that'll, that'll be painful.

Uh, or I guess if you have two, two or more people, it'd be very painful, but like, you know, if somebody, somebody were to adopt this and like, you know, a big enterprise. Like you've got, you've got the teams of dozens of people that are, uh, you know, used to making monthly or quarterly releases that now all of that work is done in a day.

You've got the, you've got the product teams that are used to like planning out quarter by quarter. You've got the, you know, and the, the teams up and up of like planning the year and all of those things that like all of that got compressed. So, I mean, imagine, imagine being a VP of a department and you've got, you know, 10, uh, 10 projects and you're, you know, you're in the planning meetings.

You're in the, the meetings of like what all changed and now that's, uh, you know, now the, the quarterly, the contents of the quarterly review are now happening weekly. Uh, that's, I think a lot of people are in for a lot of, a lot of pain. Well, yeah, I, I think that's kind of why my, my outlook is that, uh, you know, the, the six to eight person startup is, is, should be able to beat out for like a hundred person enterprise, uh, in terms of like velocity and product quality at this point, in my opinion.

Yeah. Yeah, definitely. But it's still hard to coordinate the six to eight. So, you know, yeah, I, I, I, I'm sorry. Oh, no, you're good. I was just going to read the question in case you hadn't caught it, but it looks like you. Oh, got it. Uh, how much has changed since a month or so when you published?

Um, so yeah, about a month or so, it was definitely that, that much more structured. I've, um, I've shifted to having it be a little bit more ad hoc. Um, like, uh, like, I don't know if you, the, the, when I was showing those, like to the docs directory and the tech docs directory, um, that became a little bit more ad hoc.

Um, um, I've also stopped doing, um, so that first project that was like three phases, I've stopped having so many phases up front. Like even the, the, the game that I was showing you had six phases and like, by the time we got to the third, it was like, none of this makes sense anymore.

So we need to change. So I've started to do, you know, much more, much closer to like, here's almost like epic level rather than doing multiple epics up front. Uh, custom tools. No, not, I mean, I've started to work on, started to work on a product for the context switching.

Like KBall said, that has been the biggest problem was, uh, you know, what I was showing you, you know, switching between sessions. But a lot of times I was finding myself going back to a session or forgetting that I had kicked a session off and, um, coming back and being like, ah, shit, that, that agent has just been sitting there idle.

That I could have been, uh, it could have been moving. So, um, working on it, working on something to help me, uh, you know, switch between projects and try to, try to get above the like three to four projects that I've been able to handle. Uh, I'd like to, like to try to get to like 10 or 15 projects in parallel.

Um, Brad has his hand up. Yeah, I was just gonna ask on that, on that last point. Like, how do you start a new project if it's a little bit more ambiguous? So you're not really sure you don't have a specific plan of the different phases? Like, are you sitting down with Claude to write the initial scope and to plan out the phases?

Yeah, I'll usually, um, I'll switch between, I actually have been started to do Grok, Claude, and I guess it was ChatGPT the last time. I'll just have like a paragraph of like, this is the project I want to build, create me a design doc or create me a comprehensive design doc.

And then look kind of like skim through all three of them and see which one seems the most reasonable. And then throw that into Claude and be like, here's the design doc, here's the project, uh, break this out into, break this out into user stories. Um, I had one, I dropped it in chat here, um, did, did you, um, uh, uh, other than the context switching tool, have you made any like major changes to your Vim, like configuration or plugin setup or, um, or any like TMUX add ons or, or anything that's like not, or any, any workflow changes other than sometimes I tab over to the other terminal and ask Claude a thing.

Um, not really, I mean, the, the biggest change to my, my Vim workflow is that I don't really use Vim anymore. Um, um, um, um, um, um, um, I have been starting to explore like kind of tools to help switch between these TMUX sessions. So, uh, uh, ways to kind of integrate into, uh, other Mac apps.

So like I mentioned, like switching, if I could have project name, you know, terminal window and all of that be something deterministic that I can throw into an app or even an MCP. I can have that switching a lot. I'm thinking it can have that switching a lot easier.

Uh, but I haven't dug into, uh, building any kind of like custom TMUX plugins. Yeah, that's, that's kind of the direction that I've been heading with it where it's like, I don't, um, I, I, I spend less time in Neobim, but I'm also trying to like hack Neobim into like a command center more so than a text editor at this point.

Um, with like, yeah, there's like, I have like an MCP manager plug in in there and then like a few different, uh, coding agents and then pod code windows can pop up in there and stuff like that. But yeah, they really haven't like dialed it in to, to figure it out.

Yeah. Yeah. But the more I learn about these, the less time I spend in the ID. So. Yeah. That's what, uh, you know, I was having a conversation with somebody recently that like. Uh, almost makes sense to like, one of the things we were building, thinking about it, like, uh, an IDE for IDEs or like, you know, an I, I, D, E, E.

Um, that like being able to switch between all of those different projects is the new, uh, like development environment. Right. Hmm. What do you, yeah. What do you mean by that? Like an I, I, I, I, D, E. Just like you, you want something that can handle. Terminal that can like quickly move you across the file system and see what the terminal is doing in there.

And then. Um, am I missing something else for this sort of coordination machine that we imagine here? Yeah. Yeah. I guess like you're thinking about like an IDE as a, uh, like as a tool to help you, uh, develop a single product that like the, the like next abstraction layer layer is like an, an IDE for, uh, coordinating and like working on.

Uh, you know, working on the products from another level up. Um, got it. So it's like, I have cursor and windsurf and, uh, you know, amp and cloud code all running and I need something to sort of help me supervise all of those things going at the same time.

Kind of deal. Right. Right. And you might be using, you know, you might be using client for something or, you know, something in VS code, other cursor that like, it doesn't be in the same way that you might use, you know, um, you know. Um, the of M for, uh, all different types of languages or different types of files.

This is more, uh, you know, all different types of projects. Right. And right now, the main thing that I'm using all of those for is for the, the, the, the, the subscription to number of tokens. I'm allowed to have ratio for each, uh, each with each of the platforms being on sale.

So it's like, that's, I, I do actually use four different IDEs, but only because like one's charging me 10 bucks a month and has, uh, you know, 500 cascade requests. And then Cursor's got the subscription that I got on the cheap. So yeah, it's seems like a generally valuable thing.

Yeah. Yeah. That's incredible. Oh yeah. Uh, good question from flow. I think, uh, do you, are you making use of like work trees at all? Or, or you don't use multiple cloud codes at the same time. You just do one, right? I don't use multiple cloud codes in the same project.

Um, I just use a single one in each project. Okay. Yeah. The for, for multi-boxing clock code, my, I like, there's something there around work trees. I haven't figured out exactly what it is yet, but, um, uh, that can sort of help keep things more sane. Yeah. Yeah. I guess maybe like thinking about that, I think the other thing that's kept me from using work trees is, you know, these are all kind of smaller projects, newer projects.

And so they don't have huge backlogs. And so maybe I need to create a, a cloud code. That's like a more of a product manager and kelp helps like build out my backlogs for me. Uh, cause like, that's usually the, the like first step is like build this backlog out and then it just turns through it.

Yeah. I'm finding that's, that's kind of the direction I'm finding like the slash agents command pushing me in where it's like, okay, I kinda want one guy that only has tools to run tests. And all it does is run tests and then yell at the other ones when they're messing something up.

Well, and then I want one that, that has maximally clear context to only write code that is specifically instructed to write the code that it's writing. And then I want one that only does the searching of the code base and composes the context for the next one. And yada, yada, yada, yada.

Yeah. Yeah. Yeah. I'll have to give that a shot. I've been, been meaning to, but it's heaven. Yeah. Well, anything else for me? Yeah. Do you want to, do you want to do a, do a quick, uh, protocolli, uh, uh, plug while we have the last couple minutes here, since I don't hear any, or I don't see any other questions coming through.

Um, yeah, so protocolli, that was one of the, that was kind of like what kicked all of this off. It's, uh, it's a tool to help you actually, I guess I can share it. Uh, let's bring it up here. It's a tool to help you, uh, explore, uh, MCP servers.

So we're building in another product we're building called APM, which is kind of like that command center. Uh, we're integrating a lot of, uh, MCP servers and using MCP servers as, um, as like a plugin system. So I needed something to help me test MCP and, um, you know, see what was working, test the tool calls before building it into the app and like doing, going through all that hassle.

So kind of thinking, thinking about this as like a desktop version of postman, uh, for specifically for MCP. Um, but it's also been really interesting to see stuff like, uh, like jumping into Claude, uh, Claude code and looking at their MCP server and seeing the way that they have like the tools described, like, and, and how they've changed over time.

Uh, so like task is just massive bash, um, got, uh, it's not connected. Um, okay. Yeah. So I've been testing out an APMs MCP server here. Um, let's see. Uh, yeah, this was all, all vibe coded. Um, fancy and clean. I really, really, my instructions to Claude were, uh, make it look like a professional desktop app.

Um, and it, it did so many things that are just like not expected. I mean, it gave theme switching. Um, we also have, uh, added high contrast mode, um, font size switching. Uh, it created a, um, an, an intro tour, uh, to walk through all the features. Um, and.

Well, you didn't ask it to create the, the intro flow just did it. It, it, it showed up in one of the stories and I was like, yeah, go ahead and go ahead and give it a shot. Um, but the details, I didn't really. Didn't really dig into any of the details beyond.

Yeah. Beyond that. Uh, there was the, the thing that tour did have trouble with was, um, yeah, it actually still has trouble getting the, you know, getting the placement of the modal windows. Um, yeah, this was like, usually, usually for a V one of a product that I was building for myself, I wouldn't put a tour in, but it was, it was so painless that.

You know, just went okay with it. Same with same with theme switching. Like, uh, it's usually kind of overkill for V one. All right. Thank you so much, Scott. Um, we are about at time. Uh, we have a speaker for, for next week. We're back to Claude code and sub agents.

Um, I think, uh, I'm blanking on his name now, but the guy who kicked off the conversation there that went for however many messages is going to come back and present. Um, so definitely come back for that. If you are working on Oliver. Yes. Thank you. Flo. Um, if you're working on something you want to share, if you have a cool experiment, you want to share, do sign up in the discord.

You just have to talk to the AI in action bot. Um, and it will get you signed up. Um, and the thing that we've been coming to that I think is great is like, it doesn't have to be useful. It doesn't have to be polished. It just has to be interesting because, uh, you know, we're, we're here to learn together.

So thank you all. Thank you, especially Scott. And we'll see you next week. Yeah. Thank you all. See ya. Thank you.