Claude Code + Spacesheep: How I Stay in the Loop

Author: James Briggs · Watch on YouTube

Video authored by the channel shown, not by IANIA; all rights belong to the creator. Transcript and summary generated automatically; the original-language content is preserved.

Original language: English

Original video: Claude Code + Spacesheep: How I Stay in the Loop · Channel: James Briggs · 18:27 · Watch on YouTube

Topics: AI agents, Claude Code, Software engineering with AI, Local and open-source models

Summary

James Briggs discusses how engineers can stay informed about code increasingly produced with AI, arguing for visual, interactive documentation that helps them understand codebases at a higher level. He demonstrates using Spaceship with Claude to inspect Semantic Router, plan a local decision-model feature, and review implementation details and benchmarks. The process includes asking questions, comparing design options, and recording decisions, code examples, and results in visual documents. He emphasizes that this is an evolving workflow and that careful iteration remains important for understanding what is being built.

Key points

The rapid pace of AI-assisted engineering makes it harder for developers to track what is built and continue learning about it.
Visual, dynamic, interactive documentation can help engineers understand codebases without inspecting every line.
The speaker uses Spaceship alongside Claude to plan and explore a Semantic Router feature.
The demonstration focuses on adding a local alternative to Jev decision-making support.
Claude helps explain existing decision-indexer and router structures, including relevant methods and data flow.
The speaker uses follow-up questions to examine architectural choices, such as how decision models should integrate with the library.
The discussion identifies Glyner 2.5 as an option after clarifying that the Glyner decision model cannot run locally.
Review documents can capture design decisions, code changes, model details, and benchmark results.
The speaker stresses that more experiments, iteration, and review are needed before deciding a feature is ready.

Chapters

Start	Chapter	Summary
00:00	Staying in the loop as engineering changes	The speaker describes the challenge of keeping up with AI-generated code and introduces interactive visual documentation as a way to understand projects.
03:20	Planning a local decision-model feature	He introduces the Semantic Router feature he will build and sets up Spaceship and Claude to examine the existing code.
06:02	Exploring the current router and design options	The speaker reviews the router’s decision flow, asks about architectural alternatives, and considers local model options.
11:29	Choosing Glyner and building the feature	After clarifying the model options, he selects Glyner 2.5 and describes moving from planning toward implementation.
13:36	Reviewing decisions, code, and benchmarks	He walks through a review document containing design decisions, code examples, model details, and preliminary performance results.
16:50	Iteration and the evolving engineering workflow	The speaker reflects on the importance of further testing and iteration, and on finding ways to keep learning as development practices evolve.

Quotes

that is the question that I have at the top of mind at the moment. — 00:36

I mean visual, dynamic, interactive documentation — 01:08

Claude actually has context as to what this is going to be used for — 05:31

you should very deeply understand what you’re building. — 09:52

I don’t have all the answers. — 17:24

Concepts and entities

Spacesheep, Claude Code, Semantic Router, GLiNER 2.5, Fastino, Jev, MCP, Decision Router, Linear, Jira

Full transcript (original language)

00:00 Engineering has changed a lot in just the last couple of years, even even few months. Now, that could be super exciting. The pace of which we can build stuff now and the crazy crazy things that can just come out of our minds is practically limitless. And that’s exciting. The problem is how do we as engineers keep track of what is built? How do we continue learning about what is built?

00:36 And that is the question that I have at the top of mind at the moment. And it’s something that I haven’t figured out, but I have some pretty good processes that allow me to continue learning and do so quickly, whilst also understanding what I’m building. Of course, we won’t be able to understand deeply our code bases as if we are seeing every single line of code, but maybe we can actually understand them better at a

01:08 more holistic, higher level. And I I do think that is genuinely possible. Now, one of the components that I think are essential in my continued learning and understanding of AI-generated code is kind of documentation, but documentation not the boring, horrible documentation. I mean visual, dynamic, interactive documentation, roadmaps that integrate with existing tools for project management like

01:40 linear, Jira, and so on. I need interactive PR reviews, all of this stuff. And I’m a very visual person, so I want to be very visual. And that is what I’ve been using Spaceship for. So, it Spaceship is hard to describe because it does a lot of things. I have seen people use Spaceship, for example, this. It’s a game. It’s just It’s a 3D in-browser game. This is also built in Spaceship. There’s something to do with

02:13 chip design, I believe. And it’s this interactive visual that allows you to explore a chip design. I don’t understand this, but someone does. And then we come to the sort of thing that I use Spaceship for. And I’m still exploring. I’m still learning how to how to really use it and what I can use it for. But, what I like to do is I start with my planning and I go through multiple iterations and explore different options and discuss with AI

02:44 agents plugged in Spaceship different ideas, explore different different components of code. But, what I like to do is start with that initial discussion, understand something conceptually, then build out a plan. This is a smallish plan for Semantic Router that I have been putting together. And what I’m wanting to do here is make Semantic Router faster, give Semantic Router more extensibility and reliability. And I want it to be able to integrate with

03:20 decision models. So, I have a a rough plan here. This is quickly thrown together. And then, what I want to do for the rest of this video is actually take you through using Spaceship and actually building a new feature for Semantic Router. So, what we are going to focus on to keep us within the Jev sphere, is we’re going to actually implement a local alternative for Jev within Semantic Router. So, let me let me take

03:53 you through what that looks like. So, we’re going to jump straight into Claude here. And what I’m going to do is first make sure the MCP is set up for spaceship, which does need the authentication, so I’ll quickly do this. Okay, and that is now authenticated. And I’m going to start this planning process. So, the first thing to understand is what do we currently have in semantic router. So, we do have what is called a decision indexer. So, decision indexer is the the class that

04:26 we’re going to be using here for building our new local decision-making component using a local Jev. So, the first thing is understanding the structure of that, because that is what we are going to be subclassing and and using as we are uh developing our our local Jev. So, to quickly go through what I’m requesting here. I’m obviously wanting the stock to be interactive and visual. I want to transmit as much information as quickly

04:57 and smoothly as possible for me. I do this is something I I always request. I I do want code snippets for the most critical components. I want those to be explained so I can get a feeling of the actual code base without necessarily looking directly at it. I want to include the structure of important methods, and this is important. I could have I could have ended here, right? I could have just included this first little bit here, but I want Claude here to understand why I’m requesting this information, so that

05:31 Claude actually has context as to what this is going to be used for, because then of course Claude will tailor this for what we are wanting to do. So, I specify we’re developing this local Jev support class. Okay, we have the first document, so I’m going to go ahead and open that. Okay, and from this I get this document overview document here. Which explains everything I need. Right, so I have my decision router methods here. So also Claude is also pointing out where I think where things I will probably need

06:02 to uh tweak some things. So here it’s suggesting that I basically just take decision router and swap out one method in there, which is this one here. Now I do have questions. Is that really what I want to do? So I can ask. So I can discuss this directly with the built-in agent, so spaceship. And I would just say here is this the right option? With the index router, we attach encoders from different providers. Why

06:33 not do the same for decision models? And honestly, with the structure, I’m not entirely sure which what what the right answer is. I could see us going down the encoder route, or maybe we do kind of just have a decision router per decision model. I’m just I’m not entirely sure about that. So I want to see what comes back from this. >> [snorts] >> And whilst they’re running, we can continue uh reading through this. So yeah, let’s go through and have a good

07:08 little look at this part. So this is the input that we would typically have. So we have our router, and we we call it with something, right? A query. And to get from our input query to the choice, like the decision that has been made, there are obviously a few steps. And that is what is being outlined here. So we are calling the method, that’s what we’re doing here, calling the router. Uh in there we have our query, and then that is going to run. Actually,

07:39 it’s going to run the the async um code. But it’s going to it’s going to run it uh synchronously. So, let’s uh keep going. Then, we go to a core these to the async core line. So, set two, and it’s just one line uh which is basically just going straight to scores here. So, this here is our actual you know, scoring logic. In here, we have the ask a async ask method, which is producing our our chosen route. And, if we want to

08:13 understand what is in ask, I can come over here. So, this is where we would actually be with Jev. This is where we’re calling Jev. So, you can see that we have the client session here. That is made generic. It doesn’t have to be for Jev, but it does expect a Jev-like structure here. So, this component in particular will definitely be changed. The structure of that will be will need to be tweaked. So, you see that we have the state, which is a obviously the Jev thing uh describing your current

08:44 your current state, current environment. You have the model, which with Jev would be the the Jev model. And then, we have our questions, which can be a a list of queries. Okay? So, this is going to be the bit that I think will need changing. The rest, probably not. So, for local Jev, we replace this. Same arguments, same return shape. Now, it’s also correctly identifying that there are different types here, decision types. We have choice, null, and score. We do follow Jev for the

09:18 naming conventions there, as they seem to be the most popular. So, we have choice, null, and score. So, within the choose step, we are ranking by the score. Uh here, we’re saying So, we have we can have different thresholds for each route. Uh we do maintain that ability here. And here we are returning a either a root choice or a list of root choices. So, that’s a a nice little visual demonstration of our logic and we can we

09:52 can use that to really test what we currently have. We can continue trying to understand this uh more deeply and I think that this is actually if you’re building this and you’re sort of exploring something, you should very deeply understand what you’re building. Um so, I would recommend you doing this yourself, not not in this video, but doing this yourself. You should be going through like getting these sort of visuals I think are very useful. At least for me, you know, everyone is everyone is of course different. So, that’s great. Let’s continue working towards actually developing this

10:23 feature. So, what I would do from here is say, “Okay, I would want to understand what are the options with the local Jeff models?” So, from here I’d say I would probably actually want some live experiments to be run. Um but we don’t have a lot of time, so I’m going to go with I I already know which one I would actually like to be implemented first, which is the um kind of like the preferred model. I think we might be able to find it directly. So, we can see here

10:53 Jeff is number one. Glide, which is from this is the Glide and decision model from Fastino. This is open source. So, this this counts. This is something we can use. I think many of these may also be open source. I don’t know all of them. But, let’s get started with with the Glide. So, I’m going to ask for a a few alternatives to how we might be able to implement this because I I do want to explore a few options and decide on which one I think will work best or integrate best with the semantic router library. So, I’ll

11:29 let that run. So, one thing that I actually did not know is that the Glyner decision model is not uh we can’t run locally. It’s It’s not open source, which I actually thought that Glyner was was this model here. Which we can use this. I think Glyner 2.5 side is completely fine. So, we will go with that. Okay, so let’s do Glyner and I I also want to make sure it’s considering our input here. So,

12:00 and for the build we need to consider Okay, so I’ll ask it to update the document for us. We can start reading through. So, outlining the the key first thing that we learned, which is Glyner doesn’t run locally. We have Glyner 2.5 side. That’s great. Happy with that. Uh we have the model outline here 340 340 million parameters. That is It’s pretty good. We can definitely use that. Um

12:31 well, I think like all reasonable consumer hardware that’s completely fine. The approach here is torch. We need torch transformers and peft. Okay, fine. That’s all coming through the Glyner 2 local uh library there. We already said that okay, Glyner is what I want to go with. And we do have more details there. Right, and I would we’ll go through not in this video. Okay, so I’m going to say it. Um let’s let’s call it. So, what I would do very often is we would

13:05 do a few experiments. We would have a spike just to say okay, is this something that we can actually do? Um and then maybe run some experiments on that, you know, different options to see what the best result will get us. For this, I don’t think we necessarily need to do that, but it’s definitely something that I would recommend doing. Uh when especially if you’re using spaCy, being able to visualize the results from those is super super useful when you’re considering different options. But yeah, let’s I I will let it go and build that and we’ll we’ll move on to the next phase, which is

13:36 reviewing. Okay, so I’ve been through I did a couple more items that I will actually go through the agent in another iteration, but for now I want to go through the full just get straight to the review step. But of course this is a compressed version, but we have a rough outline of what the these sort of review documents can look like. And again, this is the sort of thing where I’m still testing things out and then and tweaking. But we have some of the decisions that I wanted in there

14:10 already. So you can see that we have different sub classes here. So we have the Glyna two decision model, which is our local one. So that’s that’s good. We have few examples. So after for the local is going to look like this. After for Let’s see before actually. So before we just had decision router. That was going straight to type safe with Jev latest. And that is what it looks like. [clears throat] Now, the the type safe router for Jev looks different. So we actually have the

14:43 model coming through there, which is type safe decision model. And that is passed as a model into our decision router. So already a substantial change. We have this is something I really like to do. I like to have a like a timeline of decisions being made. Generally this is this is pretty short one. So here we just have the initial explainer. Why not attach decision models the way that we attach the encoders? That decision was made. Promise model packages decision models.

15:14 And as we go through those iterations, so I already showed you that there were quite a few other comments beyond, you know, which we’re without which we’re going to cover in this video, this will this will grow and you will see a pretty significant number of decisions being made as long as you are correctly kind of going back and forth with with your agent, which I would naturally just recommend you do. And then here we have the actual code. This is something that I do really like to do and I find it very useful. So, decision routes is something that has changed. So, you you can actually see that here. But, you can see very easily very

15:47 quickly it’s quite easy to run through this and see the code. You can see the decisions that have been made also for the Glycine 2 uh code base here. So, you can see all the the special tokens that Glycine uses. That is definitely worth going through as well. I would do it later. And we also have benchmark as well. Um It’s kind of outside the main code base. So, it’s something that I would probably pay less attention to, but I I will be sort of questioning and and going through. Uh we have some metrics as well here.

16:19 So, I did ask for NPS earlier. And we can see here um it’s it’s pretty fast. So, we one can use NPS with the Glycine 2.5 model. And it when we do the the average of P50 here is 21.1 uh milliseconds, which is pretty cool. Some good results here. Uh but there are definitely there are other benchmarks that need running before I can say this is a something that’s good to to go ahead with. And of course just going through the review more detail, having a bit of that that

16:50 back and forth cuz this this really covers the main components of that development process where you’re trying to just remain more in the loop and and understand what is going on. Of course, what you are not seeing in this video, and I I think it’s super important, is iterating, seeing what maybe you don’t like, maybe we could test a few options here. And that’s something that I think is very important and and you should really be doing. But, this does at least give those main steps, at least as they are so far um for me. But, yeah, that is that is

17:24 everything for this video. As I said, I’m I’m very focused and interested at the moment on you know, where where are we going as developers and what is the what are the methods we can use in order to remain sharp and remain and make sure we’re still learning and you know, keep a grip on understanding our our code bases for as long as is possible. I think Spaceship Earth is one component, not the only component. There there is much more to it and I I will be

17:55 exploring that in in future videos, different components [music] and you know, different approaches to the development process. And as I said, I don’t have all the answers. This stuff is all evolving [music] very quickly. Um the way that I work with all this stuff is evolving very quickly as well. >> [music] >> So, that’s it for this video. I I’d love to hear how you’re changing your approach to engineering. Yeah, I’ll leave it at that for now. Thank you very much for watching and I will [music] see you again in the next one. Bye.

18:27 >> [music]