Claude Code + Spacesheep: como continuo por dentro do processo

Autoria: James Briggs · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Claude Code + Spacesheep: How I Stay in the Loop · Canal: James Briggs · 18:27 · Assistir no YouTube

Tópicos: Agentes de IA, Claude Code, Engenharia de software com IA, Modelos locais e open source

Resumo

James Briggs apresenta o Spacesheep como uma ferramenta para criar documentação visual e interativa que o ajuda a acompanhar o código gerado por IA. No vídeo, ele usa agentes de IA para explorar o Semantic Router, entender sua estrutura e planejar a implementação de uma alternativa local para tomada de decisões. O exemplo passa pela escolha do GLiNER 2.5 e pela revisão de mudanças, decisões de implementação e métricas. O objetivo é mostrar um processo que ajude desenvolvedores a aprender e manter uma compreensão mais ampla das bases de código.

Pontos-chave

O ritmo acelerado do desenvolvimento com IA torna importante encontrar maneiras de acompanhar e compreender o código produzido.
O Spacesheep permite criar documentação visual, interativa e dinâmica, além de roadmaps e materiais de revisão.
O apresentador usa diagramas, trechos de código e explicações para compreender a estrutura do Semantic Router antes de implementar mudanças.
A conversa com o agente ajuda a explorar alternativas de arquitetura e a registrar as decisões tomadas.
O exemplo de implementação é uma alternativa local para tomada de decisões no Semantic Router.
O GLiNER 2.5 é escolhido como modelo local para o exemplo, após esclarecer que outra opção considerada não podia ser executada localmente.
A revisão reúne subclasses, exemplos de uso, histórico de decisões, código e resultados de benchmark.
O apresentador ressalta que experimentos, iterações e revisão cuidadosa continuam importantes; o Spacesheep é apenas uma parte do processo.

Capítulos

Início	Capítulo	Resumo
00:00	Como acompanhar o código gerado por IA	O apresentador explica o desafio de continuar aprendendo e entendendo bases de código à medida que o desenvolvimento acelera.
03:20	Planejamento visual no Spacesheep	Ele apresenta o plano para adicionar uma alternativa local de tomada de decisões ao Semantic Router e começa a analisar sua estrutura com Claude.
06:02	Exploração da arquitetura e das opções	O apresentador examina o fluxo de decisões existente, discute alternativas de arquitetura e escolhe o GLiNER 2.5 para a implementação local.
10:23	Escolha do modelo e início da implementação	Ele esclarece quais opções podem ser executadas localmente, atualiza o documento de planejamento e encaminha a implementação.
13:36	Revisão, decisões e métricas	O apresentador percorre o material de revisão, incluindo exemplos de uso, decisões de arquitetura, código e resultados de benchmark, e reflete sobre como permanecer envolvido no processo.

Citações

Talvez possamos entendê-las melhor de forma mais ampla, em um nível mais alto. — 00:36

Quero que Claude entenda por que estou pedindo essas informações. — 04:57

Se você está construindo algo e explorando uma ideia, deveria entender muito bem o que está construindo. — 09:52

Quais métodos podemos usar para continuar afiados e garantir que seguimos aprendendo? — 17:24

Conceitos e entidades

Spacesheep (ferramenta): Ferramenta usada para criar documentação visual e interativa e para colaborar com agentes durante o planejamento e a revisão.
Claude Code (ferramenta): Ambiente em que o apresentador inicia o planejamento e conversa com um agente de IA.
Semantic Router (repo): Projeto cuja estrutura o apresentador analisa e ao qual pretende adicionar uma opção local de tomada de decisões.
GLiNER 2.5 (modelo): Modelo escolhido no vídeo para a implementação local discutida no Semantic Router.
Fastino (empresa): Empresa associada no vídeo a um modelo de decisão chamado Glide.
Jev (conceito): Referência usada no vídeo para descrever o modelo de decisão cuja estrutura serve de base para a alternativa local.
MCP (conceito): Integração que o apresentador configura para conectar o Claude ao Spacesheep.
Decision Router (conceito): Componente discutido no vídeo para encaminhar consultas e selecionar rotas com base em decisões e pontuações.
Linear (ferramenta): Ferramenta de gerenciamento de projetos citada como exemplo de integração possível para roadmaps.
Jira (ferramenta): Ferramenta de gerenciamento de projetos citada como exemplo de integração possível para roadmaps.

Tradução completa (pt-BR)

00:00 A engenharia mudou muito só nos últimos dois anos, até mesmo nos últimos meses. Isso pode ser muito empolgante. O ritmo em que conseguimos construir coisas agora e as coisas malucas que podem simplesmente surgir da nossa cabeça são praticamente ilimitados. E isso é empolgante. O problema é: como nós, engenheiros, acompanhamos o que está sendo construído? Como continuamos aprendendo sobre o que está sendo construído?

00:36 E essa é a pergunta que está no topo da minha mente no momento. É algo que ainda não consegui descobrir, mas tenho alguns processos muito bons que me permitem continuar aprendendo e fazer isso rapidamente, ao mesmo tempo que entendo o que estou construindo. Claro, não vamos conseguir entender profundamente nossas bases de código como se estivéssemos vendo cada linha de código, mas talvez possamos entendê-las melhor em um nível

01:08 mais holístico e elevado. E eu realmente acho que isso é possível. Um dos componentes que considero essenciais para continuar aprendendo e entendendo o código gerado por IA é algo como documentação, mas não aquela documentação chata e horrível. Quero dizer documentação visual, dinâmica e interativa, roadmaps que se integram às ferramentas existentes de gerenciamento de projetos, como

01:40 Linear, Jira e assim por diante. Preciso de revisões interativas de PR, de tudo isso. E sou uma pessoa muito visual, então quero que tudo seja bem visual. E é para isso que tenho usado Spaceship. É difícil descrever Spaceship, porque ele faz muitas coisas. Já vi pessoas usarem Spaceship, por exemplo, para isto. É um jogo. É só um jogo 3D no navegador. Isto também foi criado no Spaceship. Tem algo a ver com

02:13 design de chips, acredito. É um visual interativo que permite explorar um design de chip. Eu não entendo disso, mas alguém entende. E então chegamos ao tipo de coisa para a qual eu uso Spaceship. Ainda estou explorando. Ainda estou aprendendo a usá-lo de verdade e para que posso usá-lo. O que gosto de fazer é começar com meu planejamento, passar por várias iterações, explorar opções diferentes e discutir com agentes de IA

02:44 conectados ao Spaceship ideias diferentes e explorar componentes de código diferentes. Mas o que gosto de fazer é começar com essa discussão inicial, entender algo conceitualmente e então elaborar um plano. Este é um plano relativamente pequeno para Semantic Router que venho preparando. O que quero fazer aqui é deixar Semantic Router mais rápido, dar mais extensibilidade e confiabilidade a Semantic Router. E quero que ele consiga se integrar a

03:20 decision models. Então, tenho aqui um plano preliminar. Foi montado rapidamente. E, no restante deste vídeo, quero mostrar como usar Spaceship e realmente construir um novo recurso para Semantic Router. Para nos manter dentro da esfera do Jev, vamos implementar uma alternativa local ao Jev dentro de Semantic Router. Então, deixa eu mostrar

03:53 como isso funciona. Vamos direto para o Claude aqui. Primeiro, vou verificar se o MCP está configurado para o Spaceship, o que exige autenticação. Vou fazer isso rapidinho. Certo, agora está autenticado. E vou começar esse processo de planejamento. A primeira coisa a entender é o que temos atualmente no semantic router. Temos algo chamado decision indexer. Decision indexer é a classe que

04:26 vamos usar aqui para criar nosso novo componente local de tomada de decisões usando um Jev local. Então, primeiro precisamos entender a estrutura dele, porque é essa estrutura que vamos estender por subclasse e usar enquanto desenvolvemos nosso Jev local. Para explicar rapidamente o que estou pedindo aqui: obviamente, quero que o documento seja interativo e visual. Quero transmitir o máximo de informação possível para mim, com rapidez

04:57 e fluidez. Isso é algo que sempre peço. Quero trechos de código dos componentes mais críticos. Quero que eles sejam explicados para eu ter uma noção da base de código sem necessariamente olhar diretamente para ela. Quero incluir a estrutura dos métodos importantes, e isso é importante. Eu poderia ter parado aqui, certo? Poderia ter incluído só este primeiro trechinho, mas quero que Claude entenda por que estou pedindo essas informações, para que

05:31 Claude realmente tenha contexto sobre para que isso será usado, porque assim, claro, Claude vai adaptar tudo ao que queremos fazer. Então, especifico que estamos desenvolvendo esta classe de suporte a Jev local. Certo, temos o primeiro documento, então vou abri-lo. Certo, com isso, recebo este documento de visão geral. Ele explica tudo o que preciso. Certo, aqui estão meus métodos de decision router. Claude também está indicando onde acha que provavelmente vou precisar

06:02 ajustar algumas coisas. Aqui, está sugerindo que eu simplesmente use decision router e troque um método nele, que é este aqui. Mas tenho dúvidas. Será que é mesmo isso que quero fazer? Posso perguntar. Posso discutir isso diretamente com o agent integrado, o Spaceship. Eu poderia dizer: “Esta é a opção certa? Com o index router, anexamos encoders de diferentes provedores. Por que

06:33 não fazer o mesmo com decision models?” E, sinceramente, considerando a estrutura, não tenho certeza de qual é a resposta certa. Consigo imaginar que seguiríamos o caminho dos encoders, ou talvez simplesmente tivéssemos um decision router para cada decision model. Só não tenho certeza disso. Quero ver o que essa resposta traz. >> [fungada] >> Enquanto isso está sendo processado, podemos continuar lendo. Então, vamos dar uma boa

07:08 olhada nesta parte. Esta é a entrada que normalmente teríamos. Temos nosso router e o chamamos com alguma coisa, certo? Uma consulta. E, para ir da consulta de entrada até a escolha, ou seja, a decisão tomada, há obviamente algumas etapas. É isso que está sendo descrito aqui. Estamos chamando o método; é isso que fazemos aqui, chamando o router. Dentro dele, temos nossa consulta, e então isso vai ser executado. Na verdade,

07:39 vai executar o código assíncrono. Mas vai executá-lo de forma síncrona. Então, vamos continuar. Depois, chegamos à linha do núcleo assíncrono. Então, etapa dois: é só uma linha que basicamente vai direto para scores. Aqui está nossa lógica de pontuação propriamente dita. Temos o método ask assíncrono, que produz a rota escolhida. E, se quisermos

08:13 entender o que há em ask, posso vir até aqui. É aqui que estaríamos de fato com Jev. É aqui que chamamos Jev. Dá para ver que temos a sessão do cliente aqui. Ela é genérica. Não precisa ser para Jev, mas espera uma estrutura parecida com a do Jev aqui. Este componente, em particular, com certeza vai mudar. A estrutura dele vai precisar ser ajustada. Dá para ver que temos o estado, que obviamente é a parte do Jev que descreve seu estado atual,

08:44 seu ambiente atual. Temos o modelo, que, no caso do Jev, seria o modelo do Jev. E então temos nossas perguntas, que podem ser uma lista de consultas. Certo? Acho que esta é a parte que vai precisar mudar. O restante, provavelmente não. Para o Jev local, substituímos isto. Os mesmos argumentos, o mesmo formato de retorno. Ele também está identificando corretamente que há diferentes tipos aqui, os tipos de decisão. Temos choice, null e score. Seguimos o Jev quanto às

09:18 convenções de nomenclatura, pois parecem ser as mais populares. Temos choice, null e score. Na etapa choose, classificamos pela pontuação. Aqui, estamos dizendo que podemos ter limites diferentes para cada rota. Mantemos essa possibilidade aqui. E aqui retornamos uma escolha de rota ou uma lista de escolhas de rota. Então, esta é uma bela demonstração visual da nossa lógica, e podemos…

09:52 podemos usar isso para testar de verdade o que temos atualmente. Podemos continuar tentando entender isso mais a fundo e acho que, na verdade, se você está criando isso e explorando alguma coisa, deve entender muito bem o que está construindo. Então, eu recomendaria que você fizesse isso por conta própria — não neste vídeo, mas que fizesse isso você mesmo. Acho que vale muito a pena obter esse tipo de visualização. Pelo menos para mim; você sabe, cada pessoa é diferente, é claro. Então, ótimo. Vamos continuar trabalhando para desenvolver esse recurso de verdade.

10:23 Então, o que eu faria daqui em diante seria dizer: “Certo, quero entender quais são as opções com os modelos locais Jeff”. A partir daqui, eu provavelmente pediria para fazer alguns experimentos ao vivo. Mas não temos muito tempo, então vou seguir com o que já sei: qual eu gostaria que fosse implementado primeiro, que é mais ou menos o modelo preferido. Acho que talvez consigamos encontrá-lo diretamente. Então, podemos ver aqui…

10:53 Jeff está em primeiro lugar. Glide, que vem da Fastino — este é o Glide e o decision model da Fastino. É open source, então serve. É algo que podemos usar. Acho que muitos desses também podem ser open source. Não conheço todos. Mas vamos começar com o Glide. Vou pedir algumas alternativas de como poderíamos implementar isso, porque quero explorar algumas opções e decidir qual acho que vai funcionar melhor ou se integrar melhor à biblioteca semantic router. Então, vou…

11:29 deixar isso rodar. Uma coisa que eu não sabia é que o Glyner decision model não pode ser executado localmente. Não é open source, e eu achei que o Glyner fosse este modelo aqui. Podemos usar este. Acho que o Glyner 2.5 side serve perfeitamente. Então, vamos usar esse. Certo, vamos usar o Glyner. Também quero garantir que ele esteja considerando nossa entrada aqui. Então…

12:00 E, para a implementação, precisamos considerar… Certo, vou pedir que ele atualize o documento para nós. Podemos começar a ler. Vamos destacar a primeira coisa importante que aprendemos: o Glyner não roda localmente. Temos o Glyner 2.5 side. Ótimo, estou satisfeito com isso. Temos aqui o resumo do modelo: 340, 340 milhões de parâmetros. É bem bom. Com certeza podemos usar. Então…

12:31 Bem, acho que isso serve perfeitamente para qualquer hardware de consumo razoável. A abordagem aqui usa torch. Precisamos de torch, transformers e peft. Certo, tudo bem. Isso vem da biblioteca Glyner 2 local. Já dissemos que quero usar o Glyner. E temos mais detalhes aqui. Certo, e eu vou… não vamos passar por isso neste vídeo. Então, vou dizer… Vamos chamar isso de… O que eu faria com frequência é…

13:05 fazer alguns experimentos. Faríamos um spike só para descobrir: certo, será que isso é algo que realmente conseguimos fazer? E então talvez executar alguns experimentos com diferentes opções para ver qual resultado seria o melhor. Neste caso, não acho que necessariamente precisamos fazer isso, mas com certeza recomendo. Especialmente quando você está usando spaCy, poder visualizar os resultados é extremamente útil ao considerar diferentes opções. Mas, enfim, vou deixar que ele faça isso e vamos passar para a próxima etapa, que é…

13:36 a revisão. Certo, passei por isso e fiz mais alguns itens, que vou analisar com o agent em outra iteração. Mas, por enquanto, quero passar direto para a etapa de revisão. Claro que esta é uma versão condensada, mas temos um esboço geral de como esses documentos de revisão podem ser. E, de novo, este é o tipo de coisa em que ainda estou testando e ajustando. Mas já temos algumas das decisões que eu queria incluir…

14:10 desde o início. Dá para ver que temos subclasses diferentes aqui. Temos o Glyna two decision model, que é o nosso modelo local. Então, isso é bom. Temos alguns exemplos. Para o caso local, vai ficar assim. Para… Vamos ver como era antes. Antes, tínhamos apenas o decision router. Ele ia direto para o type safe com o Jev latest. E é assim que ficava. [limpa a garganta] Agora, o type safe router para o Jev é diferente. Então, temos…

14:43 o modelo aparecendo aqui, que é o type safe decision model. Ele é passado como modelo para o nosso decision router. Então, já é uma mudança substancial. Isso é algo que eu gosto muito de fazer: ter uma linha do tempo das decisões tomadas. Em geral, esta é bem curta. Aqui, temos apenas a explicação inicial: por que não anexar decision models da mesma forma que anexamos os encoders? Essa decisão foi tomada. Promise model packages decision models.

15:14 E, conforme avançamos nessas iterações, como já mostrei, houve vários outros comentários além dos que vamos abordar neste vídeo. Isso vai crescer, e você verá um número bem significativo de decisões sendo tomadas, desde que você vá e volte com o agent da maneira certa, o que eu naturalmente recomendo fazer. E aqui temos o código propriamente dito. É algo que gosto muito de fazer e considero muito útil. Então, decision routes é algo que mudou. Dá para ver isso aqui. Mas é muito fácil…

15:47 ver rapidamente o código. Também dá para ver as decisões que foram tomadas para a base de código do Glycine 2. Aqui, é possível ver todos os tokens especiais que o Glycine usa. Também vale a pena analisar isso. Eu faria isso depois. Também temos o benchmark. Ele fica meio fora da base de código principal, então provavelmente daria menos atenção a isso, mas vou fazer perguntas e analisar. Também temos algumas métricas aqui.

16:19 Então, pedi NPS antes. E podemos ver aqui que é bem rápido. Dá para usar NPS com o modelo Glycine 2.5. E a média do P50 aqui é de 21,1 milissegundos, o que é bem legal. Temos bons resultados aqui. Mas ainda há outros benchmarks que precisam ser executados antes de eu poder dizer que vale a pena seguir com isso. E, claro, analisar a revisão com mais detalhes e ter um pouco dessa…

16:50 troca de ideias, porque isso cobre os principais componentes do processo de desenvolvimento em que você está tentando se manter mais por dentro e entender o que está acontecendo. Claro, o que vocês não estão vendo neste vídeo — e acho isso muito importante — é a iteração: perceber o que talvez não agrada você e talvez testar algumas opções aqui. Acho isso muito importante e você realmente deveria fazer isso. Mas, pelo menos, isso mostra as etapas principais, ao menos até agora, no meu caso. Mas, enfim, isso é…

17:24 tudo para este vídeo. Como eu disse, no momento estou muito focado e interessado em saber para onde nós, desenvolvedores, estamos indo e quais métodos podemos usar para nos manter afiados, continuar aprendendo e garantir que ainda entendemos nossas bases de código pelo maior tempo possível. Acho que Spaceship Earth é um componente, não o único. Há muito mais envolvido, e eu…

17:55 explorando isso em vídeos futuros, diferentes componentes [música] e, sabe, diferentes abordagens para o processo de desenvolvimento. E, como eu disse, não tenho todas as respostas. Tudo isso está evoluindo [música] muito rapidamente. A maneira como trabalho com tudo isso também está evoluindo muito rapidamente. >> [música] >> Então, é isso neste vídeo. Eu adoraria saber como você está mudando sua abordagem de engenharia. É, vou ficando por aqui por enquanto. Muito obrigado por assistir e nos vemos [música] no próximo vídeo. Tchau.

18:27 >> [música]

Transcrição original

[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]