Astra + Jev + DS V4.1 Flash: configuração de worker super-rápida, superbarata e de ponta

Autoria: AICodeKing · 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: Astra + Jev + DS V4.1 Flash: SUPER FAST, SUPER CHEAP & SOTA WORKER Setup! · Canal: AICodeKing · 13:56 · Assistir no YouTube

Tópicos: Agentes de IA, Engenharia de software com IA, Ferramentas de desenvolvimento com IA, Inferência e otimização de modelos, Modelos de IA

Resumo

O vídeo demonstra como configurar no Bamboo um modelo arquiteto para planejar e revisar o trabalho, enquanto modelos mais acessíveis executam tarefas específicas em paralelo. Jev é apresentado como um complemento opcional para sugerir workers, recuperar contexto e avaliar evidências de mudanças e testes. A demonstração cria um jogo de Campo Minado e percorre a delegação, a revisão de diffs, os testes automatizados e a verificação no navegador. O apresentador recomenda medir o custo total da execução, pois modelos mais baratos ou chamadas adicionais não garantem economia.

Pontos-chave

O modelo arquiteto divide o objetivo em tarefas, coordena os workers e revisa os resultados.
Workers com responsabilidades e arquivos bem definidos podem implementar partes independentes em paralelo.
No exemplo, Codex é usado como arquiteto e OpenCode com DeepSeek como worker; a configuração demonstrada usa até três workers simultâneos.
Jev pode ajudar com sugestões de workers, busca de contexto e avaliações das evidências, mas é opcional.
A revisão com Jev não executa testes: ela avalia as evidências disponíveis e pode apontar alegações sem suporte.
Os testes no navegador devem ser combinados com testes do engine e inspeção do gameplay; uma página correta não comprova toda a lógica do jogo.
O custo deve incluir workers, arquiteto, novas tentativas, assinatura do Bamboo e uso de Jev ou do modelo auxiliar de navegador.
A abordagem é mais adequada a tarefas que podem ser divididas; tarefas simples podem não justificar vários workers e ciclos de revisão.

Capítulos

Início	Capítulo	Resumo
00:02	Visão geral da equipe de arquiteto e workers	O apresentador explica a proposta de delegar tarefas rotineiras a modelos mais acessíveis e apresenta o Bamboo e o papel opcional de Jev.
03:08	Configuração de modelos e criação da equipe	O vídeo mostra como conectar modelos, habilitar os recursos opcionais de Jev e configurar o arquiteto e os workers no Bamboo.
06:11	Delegação e acompanhamento do desenvolvimento	A equipe recebe a tarefa de criar um jogo de Campo Minado, divide o trabalho entre engine e interface e acompanha atribuições, checkpoints e contexto.
09:17	Revisão de mudanças e testes no navegador	O apresentador revisa diffs e evidências, testa a aplicação em um navegador e explica como encaminhar problemas para correções focadas.
12:24	Como avaliar a economia e a configuração	O vídeo recomenda comparar o custo completo da execução e destaca que adicionar modelos ou workers não garante economia de tempo ou dinheiro.

Citações

Não acho que todas as partes de um projeto precisem do seu modelo mais caro. — 00:02

Um worker mais barato pode cuidar da implementação enquanto o arquiteto se concentra na coordenação e na revisão. — 02:05

Quero ver o diff e o resultado real dos testes, não apenas um parágrafo confiante dizendo que está tudo pronto. — 09:17

Agente concluído significa que o agente de navegador informou que terminou. Verificações aprovadas significa que aquelas afirmações específicas passaram. — 10:50

O preço mais baixo por token não significa necessariamente a tarefa concluída mais barata. — 12:55

Conceitos e entidades

Bamboo (ferramenta): Ferramenta de desenvolvimento que reúne a configuração de equipes de agentes, conversas, navegador e revisão de mudanças.
Jev (ferramenta): Assistente opcional que faz julgamentos focados, como sugerir workers, recuperar trechos de contexto e avaliar evidências.
Astra (modelo): Modelo citado como opção para atuar como arquiteto e como parte da configuração descrita em uma publicação do Reddit.
DeepSeek V4.1 Flash (modelo): Modelo apresentado como opção de worker para implementar tarefas a um custo potencialmente menor.
Codex (ferramenta): Ferramenta escolhida na demonstração para executar o papel de arquiteto.
OpenCode (ferramenta): Ferramenta usada para conectar e executar os modelos escolhidos para os workers.
TypeSafe (empresa): Empresa associada ao decision model do Jev e ao serviço de API mencionado na configuração.

Tradução completa (pt-BR)

00:02 [música] Oi, bem-vindos a mais um vídeo. Se você usa um modelo de programação caro, boa parte do seu uso pode acabar indo para tarefas bem comuns: ler arquivos, escrever código repetitivo, corrigir imports e fazer pequenas alterações. Não acho que todas as partes de um projeto precisem do seu modelo mais caro. Hoje, quero mostrar uma configuração de arquiteto e workers em uma ferramenta chamada Bamboo. Um modelo mais poderoso planeja o projeto e revisa o resultado, enquanto modelos mais acessíveis cuidam das tarefas individuais. E vamos

00:33 adicionar Jev para ajudar em algumas decisões ao longo do processo, incluindo escolher workers, conferir alterações e testar o app no navegador. A ideia vem de uma publicação no Reddit em que alguém combinou Astra com 8 subagents DeepSeek 4.1. A pessoa relatou gastar 94 centavos com os workers, enquanto Astra usou cerca de 10% do limite semanal da assinatura. Esses são os números que ela informou. A configuração inteira não custou 94 centavos, e precisamos medir nossa própria execução. A explicação ampliada usa MCP para conectar DeepSeek ao Codex, com o Codex liderando o desenvolvimento e revisando os workers. Vou deixar o link abaixo. Estou usando Bamboo

01:04 porque a configuração de equipe já vem integrada e quero escolher os modelos e acompanhar o trabalho deles por uma interface. Jev é uma adição opcional a esse workflow. Você pode executar equipes no Bamboo e revisar suas alterações sem uma chave de API do Jev. Vou mostrar onde essa assistência extra se encaixa, para que você possa decidir quais partes são úteis para você. Então, vamos direto ao assunto. Primeiro, dê uma olhada no espaço de trabalho. Muitas ferramentas de programação oferecem essa janela escura e sem graça, e tudo bem, mas gosto dos fundos com paisagens e dos painéis translúcidos daqui. Fica bem menos monótono passar horas olhando para as respostas dos agents. Você pode mudar o papel de parede, ajustar a visibilidade e

01:35 adicionar desfoque. Gosto de ter a paisagem ali, mas ainda quero conseguir ler o texto. Você pode reduzir a intensidade o quanto quiser. O Bamboo custa US$ 20 por mês; as assinaturas dos modelos e o uso da API são cobrados separadamente. Ele também ainda está em alpha. Então, sim, é mais uma assinatura, e ainda haverá alguns problemas. O que me interessa é ter os controles da equipe, as conversas, o navegador e as alterações juntos em um espaço de trabalho agradável de usar. Agora, o arquiteto acompanha o objetivo geral. Ele decide o que

02:05 precisa ser construído, divide o trabalho em tarefas e verifica se as partes se encaixam. Os workers executam essas tarefas com arquivos claramente atribuídos e uma descrição clara do resultado esperado. Jev tem um papel menor. É o decision model da TypeSafe. Ele pode analisar as informações fornecidas e fazer uma avaliação específica, como indicar qual worker configurado é adequado para uma tarefa ou se as evidências sustentam uma afirmação de conclusão. Os modelos de programação continuam planejando, escrevendo código e corrigindo problemas. A possível economia vem da divisão sensata do trabalho. Um

02:37 worker mais barato pode cuidar da implementação enquanto o arquiteto se concentra na coordenação e na revisão. Jev nos dá outra maneira de fazer verificações direcionadas, mas cada chamada extra tem um custo, então vamos usá-lo seletivamente. Primeiro, instale e ative o Bamboo usando o download e a licença da sua conta no site. Estou mostrando aqui a versão para macOS. Você também precisará ter suas ferramentas de programação escolhidas instaladas e com a sessão iniciada. A assinatura do Bamboo não inclui acesso aos modelos pagos deles. Neste exemplo, estou usando Codex como arquiteto e Open Code para os workers. Você também pode escolher entre outras conexões compatíveis

03:08 incluindo Claude Code, Kimi Code e GLM por meio do Claude Code. Os modelos disponíveis dependem do harness e da conta que você conectou. Para usar DeepSeek pelo Open Code, abra primeiro o Open Code. Use /connect. Escolha DeepSeek e insira a chave do provedor na solicitação de conexão. Depois, use /models para ver o que está disponível. Use o modelo que aparece na sua conta. Esse workflow não depende da versão exata da publicação no Reddit. De volta ao Bamboo, abra Settings e depois Agents. Encontre os modelos do Open Code. Clique em Choose Models. Selecione as

03:38 opções que você quer e salve. Elas ficarão disponíveis no menu suspenso principal de modelos e nos seletores da equipe. Se você só vir a opção padrão, atualize o catálogo depois de conectar seu provedor e escolha um modelo específico. Já que estamos em Settings, vamos configurar a parte opcional do Jev. Em Agents, abra Setup Jev e ative Decision Assistance. Adicione sua chave de API da TypeSafe e salve. Isso basta para as sugestões de workers, a consulta de contexto e as verificações de revisão. Esses recursos não precisam de um ambiente de execução de navegador nem de outro modelo de texto. O teste no navegador tem uma opção própria, chamada Let Your Agents Test Their Apps. Para essa parte, ative a opção.

04:09 Adicione também a chave de API do modelo de texto e clique novamente em Save Settings. Depois, instale o ambiente de execução do Jev pelo botão e confira a configuração. Para a instalação, você precisará do Chrome e do gerenciador de pacotes UV ou do Python versão 3.12 ou mais recente. O modelo auxiliar do navegador pode ser configurado separadamente. Se você quiser apenas os recursos de decisão, deixe o teste no navegador desativado e pule essa configuração adicional. As duas partes começam desativadas, e seu workflow normal de programação continua sem elas. As informações usadas em uma verificação solicitada do Jev são enviadas à TypeSafe

04:39 e a entrada de texto no navegador pode usar o provedor auxiliar configurado. Os relatórios ficam no seu dispositivo. Portanto, essa é uma conexão adicional com um provedor, com uso cobrado separadamente, e você controla se quer ativá-la. Agora, abra um projeto e crie uma nova tarefa. O Bamboo usa o projeto ativo mais recente, mas confira o nome e altere-o se necessário. Na caixa de mensagem, clique em Team para abrir o painel compacto de arquiteto e workers. Escolha Codex e seu modelo de planejamento para o arquiteto. Se Astra estiver disponível, você pode usá-lo para seguir a ideia da publicação no Reddit ou escolher outro modelo em que confie para esse projeto. Defina

05:10 o nível de raciocínio, quando houver suporte. Eu não colocaria automaticamente todos os agents na configuração mais alta. Para os workers, selecione Open Code e o modelo DeepSeek que você adicionou. Vamos criar dois perfis chamados Logic e Interface. Eles podem usar o mesmo modelo ou modelos diferentes. Os nomes descrevem as funções que pretendemos atribuir a eles. Ainda precisaremos fornecer as tarefas propriamente ditas. De uma só vez, o Bamboo aceita atualmente até três tarefas simultâneas para workers. Então, esta é uma equipe menor do que os oito agents da publicação. Em Run Limits and Context,

05:40 você também pode limitar as tarefas e as rodadas do arquiteto, além de controlar quanto da saída dos workers é resumida. Esses são limites do workflow, não um orçamento máximo em dólares. Salve essa combinação como um perfil chamado Budget Coding. Depois, aplique-o com Save Setup. A configuração fica salva, e os perfis permitem trocar de equipe sem selecionar todos os modelos novamente. Este é o primeiro ponto em que podemos experimentar o Jev. Vamos também fornecer à revisão algumas regras concretas nas ações da tarefa. Abra Jev Assistance e depois Project Rules. Vou salvar duas regras. O mecanismo do jogo não deve

06:11 ler nem modificar a interface do navegador, e as alterações nas regras do jogo devem incluir testes significativos para o comportamento afetado. Salvar essas regras não chama um modelo. Vamos conferi-las com as alterações salvas mais tarde. Também vou incluí-las na solicitação da tarefa, para que os workers saibam o que se espera antes de começar a programar. Agora, vamos criar o jogo Campo Minado. Ele permite separar bem as regras do jogo e o trabalho na interface, e podemos testar o comportamento em vez de avaliar apenas uma captura de tela. Vou dar esta solicitação ao arquiteto: crie um jogo de Campo Minado para navegador com níveis de dificuldade

06:42 um cronômetro, bandeiras, primeiro clique seguro, controles de teclado e melhores tempos salvos. Defina primeiro a interface do mecanismo e a responsabilidade pelos arquivos. Atribua o mecanismo e seus testes ao perfil Logic, e o layout e os controles ao perfil Interface. Execute os trabalhos independentes em paralelo. Peça atualizações e que indiquem os bloqueios. Depois, revise e integre os resultados. Também vou incluir as regras do projeto e uma instrução breve. Se as ferramentas estiverem disponíveis, use-as seletivamente para sugerir workers e verificar as alterações salvas. Use trechos de contexto relevantes quando necessário. Trate os resultados como recomendações.

07:13 Continue normalmente se Jev não estiver disponível e verifique o jogo com testes reais. O prompt completo, incluindo as verificações no navegador, estará no link abaixo. Então, vamos enviá-lo e ver como o trabalho é dividido. Primeiro, observe se o arquiteto realmente delega. Queremos tarefas separadas e uma interface acordada. O mecanismo do jogo precisa expor o estado do tabuleiro e as ações do jogo, e o worker da interface precisa saber como usá-los. Caso contrário, os dois workers podem produzir código razoável que não se encaixa. A equipe usa um checkout compartilhado, com escopos de arquivos declarados que podem se sobrepor, o que ajuda a coordenar as edições, mas limites sensatos ainda são importantes. Dois agents não devem ambos

07:44 reescrevendo a mesma página porque cada um recebeu a instrução de criar o jogo inteiro. Abra o architect e os workers à direita da conversa. Você pode ver as atribuições e o status. Depois, clique em um worker para ler a resposta, a atividade das ferramentas e o checkpoint mais recente. A conversa principal continua organizada, enquanto o trabalho detalhado permanece disponível. Os workers também podem se comunicar com o architect e com os colegas de equipe. Se a interface precisar de uma resposta diferente do engine, ela pode levantar essa questão, e o architect pode coordenar a mudança. Um checkpoint registra o progresso, os próximos passos e

08:15 os bloqueios, o que é útil quando uma tarefa leva várias rodadas. Aqui está outro ponto em que Jev se encaixa. Suponha que tenhamos discutido o contrato do engine e agora precisemos encontrar esse acordo. No Jev assistance, abra find context e pergunte qual contrato combinamos entre o engine e a interface. Confira os trechos e depois faça a busca. Ele retorna trechos originais relevantes da conversa recente sobre a tarefa. Isso não reescreve o histórico nem faz uma busca em todos os arquivos ou em todas as transcrições dos workers. Se o acordo estiver fora dessa janela recente, abra a conversa original do worker. Gosto disso como uma forma direcionada de

08:46 recuperar uma decisão anterior. Os checkpoints normais e o histórico da conversa continuam fazendo o trabalho principal de manter coerente uma tarefa mais longa. Não estamos fazendo o agent depender de Jev para se lembrar de tudo. Bamboo pode trazer o architect de volta quando os colegas de equipe enviarem mensagens ou quando os resultados dos workers estiverem prontos para revisão. Você também tem controles para pausar, retomar e parar. Se o mesmo bloqueio continuar aparecendo, verifique o que está acontecendo antes de gastar mais em outra rodada. Quando um worker terminar, abra as alterações salvas. É aqui que quero ver o diff e a saída real dos testes

09:17 e não apenas um parágrafo confiante dizendo que tudo está pronto. No próprio worker ou no diff salvo dele, clique em review with Jev. Peça para avaliar se as evidências disponíveis cobrem o comportamento solicitado e apontar o que falta verificar. A prévia das evidências mostra o que será avaliado antes de você executar a revisão. O relatório pode sinalizar afirmações sem respaldo ou incertezas. Por exemplo, se um worker disser que os melhores tempos são salvos, mas não houver um teste relevante nem evidências do navegador, isso precisa ser investigado. A verificação não executa o teste em si, e eu manteria o

09:48 architect responsável por decidir o que fazer em seguida. Revise aqui um worker que já terminou. Se você revisar uma tarefa enquanto os agents ainda estiverem trabalhando, o trabalho ativo será indicado como não resolvido. Isso faz sentido, e não há motivo para continuar chamando o verificador até ele concordar que terminou. Em seguida, confira as alterações salvas em relação às regras do projeto. Queremos saber se o engine continuou separado do código do navegador e se as regras alteradas têm testes significativos. Essas são avaliações no nível dos arquivos sobre o patch salvo. Portanto, abra o diff do código-fonte quando algo for sinalizado. Use report in prompt para adicionar o resultado ao seu rascunho.

10:20 Você pode pedir ao architect que investigue uma constatação e dê ao worker relevante uma tarefa de acompanhamento específica. Nada é enviado só porque você abriu o relatório. Agora, vamos testar o app de verdade. Peça ao architect para iniciar a prévia local. Depois, abra-a no painel do navegador do Bamboo e na lista de servidores locais, com a integração opcional com o navegador ativada. Clique em test with Jev. Dê a ele um fluxo específico. Comece um jogo. Revele uma célula. Coloque e remova uma bandeira. Reinicie e mude a dificuldade. Termine na tela do jogo e relate qualquer interação que falhe. Jev controla uma sessão separada do Chrome, então não usa suas abas pessoais do navegador nem os cookies de sessões iniciadas.

10:50 Para esta demonstração, o prompt de criação pede o título “Campo Minado” e rótulos visíveis para dificuldade e novo jogo. Podemos usar o título e o texto visível como verificações finais independentes. Depois, acompanhe as ações sendo registradas no relatório e inspecione a captura de tela. Há uma distinção importante no resultado. Agent finished significa que o agent do navegador informou que terminou. Checks passed significa que aquelas afirmações específicas foram aprovadas. Um título de página correto não prova que a colocação das minas ou a lógica do cronômetro estejam corretas. Portanto, mantenha os testes do engine e também inspecione o jogo. Você também pode

11:21 pedir ao architect que execute esses testes no navegador usando as ferramentas dele. Diga para esperar pelos relatórios, ler as verificações que falharam e inspecionar as capturas de tela antes de encerrar a rodada. Assim, ele pode usar os resultados na revisão sem que você precise copiar cada ação no navegador para a conversa. Faça uma segunda verificação com a predefinição para dispositivos móveis para analisar o layout mais estreito. Eu ainda testaria manualmente os controles do teclado e verificaria se os melhores tempos salvos continuam lá depois de recarregar a página. A automação do navegador pode ficar presa em interações sem suporte, e quero que essas limitações sejam relatadas em vez de contabilizadas como sucesso. Se o cronômetro continuar

11:51 rodando depois de mudar a dificuldade, por exemplo, passe esse comportamento exato para o architect. Ele pode atribuir uma correção específica, executar novamente os testes afetados e repetir esse fluxo no navegador. Quando houver novas evidências para avaliar, você pode conferir novamente o diff salvo revisado com Jev. Esse é o ciclo que buscamos: atribuições claras, implementação, evidências úteis e uma correção específica quando algo dá errado. Jev ajuda em pontos selecionados, enquanto o architect e os workers continuam desenvolvendo. Sem uma chave de API do Jev, você pode seguir o mesmo processo usando as conversas normais com os workers, diffs, testes e o painel do navegador.

12:24 Você também pode ativar apenas a assistência à tomada de decisões e continuar testando a interface por conta própria. Não é necessário adicionar outro serviço de modelo só para usar o recurso de equipe. Agora, sobre como manter os custos baixos. Comece com um trabalho que possa realmente ser dividido. Dois componentes independentes podem justificar uma equipe. Uma alteração de uma linha provavelmente não precisa de dois workers e várias rodadas de revisão. Mantenha a atribuição específica e os checkpoints concisos. Se um modelo mais barato ficar travado repetidamente, um worker mais potente talvez conclua o trabalho por um custo total menor. O menor preço por token não necessariamente resulta na

12:55 tarefa concluída mais barata. Inclua os retries do architect e dos workers, a assinatura do Bamboo e qualquer uso do Jev ou de ferramentas auxiliares do navegador ao comparar os custos. Eu usaria as verificações extras quando elas evitassem investigações repetitivas. Depois, meça a execução completa. Adicionar outro modelo não economiza tokens nem tempo automaticamente. Você ainda pode usar a abordagem com MCP da publicação, se preferir montar sua própria configuração. O que me agrada aqui é selecionar a equipe em um só lugar, acompanhar o progresso e revisar o trabalho em uma interface que tem uma aparência e um funcionamento muito melhores do que os de

13:25 mais uma janela de programação simples. Ainda custa US$ 20 por mês e continua em alpha, mas o workflow com architect e workers já vem integrado. É fácil reutilizar os perfis, e Jev oferece algumas verificações opcionais interessantes para complementar tudo isso. Você pode começar com os modelos que já usa e adicionar os componentes extras apenas quando forem úteis. No geral, é bem legal. Enfim, me conte o que achou nos comentários. Se [música] você gostou deste vídeo, considere fazer uma doação pela opção Super Thanks ou se tornar membro clicando no botão de adesão. [música] Além disso, curta este vídeo e inscreva-se no meu canal. Até o próximo.

13:56 Até lá, tchau.

Transcrição original

[00:02] [music] Hi, welcome to another video. So, if you’re using an expensive coding model, a lot of your usage can go into pretty ordinary work. Reading files, writing repetitive code, fixing imports, and making small changes. I don’t think every part of a project needs your most expensive model. Today, I want to show you an architect and worker setup in a tool called Bamboo. A stronger model plans the project and reviews the result while more affordable models handle the individual assignments. And we’re going

[00:33] to add Jev to help with a few decisions along the way, including choosing workers, checking changes, and testing the app in a browser. The idea comes from a Reddit post where someone paired Astra with 8 DeepSeek 4.1 sub agents. They reported spending 94 cents on the workers while Astra used about 10% of their weekly subscription allowance. Those are their figures. The entire setup didn’t cost 94 cents and we need to measure our own run. Their expanded explanation uses MCP to connect DeepSseek to Codeex with Codeex leading development and reviewing the workers. I’ll link that below. I’m using Bamboo

[01:04] because the team setup is builtin and I want to choose the models and follow their work through an interface. Jev is an optional addition to that workflow. You can use Bambood run teams and review your changes without a Jev API key. I’ll show where the extra assistance fits so you can decide which parts are useful to you. So, let’s get right into it. First, just look at the workspace. A lot of coding tools give you this dark, plain window, and that’s fine, but I like the nature backgrounds and translucent panels here. It feels a lot less dull when you’re spending hours looking at agent responses. You can change the wallpaper, adjust its visibility, and

[01:35] add blur. I like having the scenery there, but I still want the text to be readable. You can tone it down as much as you want. Bamboo is $20 a month with model subscriptions and API usage build separately. It’s also still in alpha. So yes, it’s another subscription and there will be rough edges. What interests me is having the team controls, conversations, browser, and changes together in a workspace that feels good to use. Now the architect keeps track of the overall objective. It decides what

[02:05] needs to be built, breaks that into assignments, and checks whether the pieces fit together. The workers implement those assignments with clear file ownership and a clear description of the expected result. Jev has a smaller role. It’s type- safe’s decision model. It can look at supplied information and make a focused judgment such as which configured worker fits an assignment or whether the evidence supports a completion claim. The coding models still plan, write code, and fix problems. The potential saving comes from dividing the work sensibly. A

[02:37] cheaper worker can handle implementation while the architect concentrates on coordination and review. Jev gives us another way to handle focus checks, but every extra call has a cost, so we’ll use it selectively. First, install and activate Bamboo using the download and license from your website account. I’m showing the Mac OS version here. You’ll also need your chosen coding tools installed and signed in. The Bamboo subscription doesn’t include access to their paid models. For this example, I’m using Codeex for the architect and Open Code for the workers. You can also choose from other supported connections

[03:08] including claude code, Kimmy code, and GLM through claude code. The models available depend on the harness and account you’ve connected. For DeepS through open code, open open code first. Use /connect. Choose DeepSeek and enter your provider key in the connection prompt. Then use /models to see what’s available. Use the actual model listed in your account. This workflow doesn’t depend on the exact version in the Reddit post. Back in Bambood, open settings, then agents. Find open code models. Click choose models. Select the

[03:38] entries you want and save them. These become available in the main model dropdown and the team selectors. If you only see default, refresh the catalog after connecting your provider and choose an explicit model. Now, while we’re in settings, let’s set up the optional Jev part. Under agents, open setup Jev and enable decision assistance. Add your Typesafe API key and save. That’s enough for the worker suggestions, context lookup, and review checks. They don’t need a browser runtime or another text model. Browser testing has its own switch labeled let

[04:09] your agents test their apps. For that part, enable the switch. Add the text model API key as well and click save settings again. Then install the Jev runtime using the button and check the setup. You’ll need Chrome and either the UV package manager or Python version 3.12 or newer available for the installation. The browser helper model can be configured separately. If you only want the decision features, leave browser testing off and skip that extra setup. Both parts start disabled and your normal coding workflow continues without them. The information used for a requested Jev check goes to type safe

[04:39] and browser text entry can use the configured helper provider. Reports stay on your device. So this is an additional provider connection with separate usage and you control whether to enable it. Now open a project and create a new task. Bamboo uses your last active project, but check the name and change it if needed. In the message box, click team to open the compact architect and workers panel. Choose codeex and your planning model for the architect. If Astra is available, you can use it to follow the Reddit idea or choose another model you trust for this project. Set

[05:10] the reasoning effort where supported. I wouldn’t automatically put every agent on its highest setting. For the workers, select open code and the deepseek model you added. Let’s create two profiles called logic and interface. They can use the same model or different ones. The names describe the roles we intend to give them. We’ll still need to provide the actual assignments set at once to two. Bambood currently supports up to three simultaneous worker assignments. So this is a smaller team than the eight agents in the post. Under run limits and

[05:40] context, you can also limit assignments and architect rounds and control how much worker output is summarized. Those are workflow limits, not a hard dollar budget. Save this combination as a profile called budget coding. Then apply it with save setup. The setup is remembered and profiles let you switch teams without selecting all the models again. This is our first place to try Jev. Let’s also give the review a couple of concrete rules from task actions. Open Jev assistance then project rules. I’ll save two. The game engine must not

[06:11] read or modify the browser interface and changes to game rules must include meaningful tests for the affected behavior. Saving those rules doesn’t call a model. We’ll check them against saved changes later. I’ll include them in the task request as well, so the workers know the expectations before they start coding. Now, let’s build the mind sweeper game. It has a useful split between game rules and interface work, and we can test the behavior instead of judging only a screenshot. I’ll give the architect this request. Build a browserbased minder game with difficulty

[06:42] levels, a timer, flags, a safe first click, keyboard controls, and saved best times. Define the engine interface and file ownership first. Assign the engine and its tests to logic and the layout and controls to interface. Run independent work in parallel. Ask for checkpoints and blockers. Then review and integrate the results. I’m also adding the project rules and a short instruction. If the tools are available, use them selectively for worker suggestions and checking saved changes. Use relevant context excerpts when needed. Treat the results as advice.

[07:13] Continue normally if Jev is unavailable and verify the game with actual tests. The complete prompt will be linked below including the browser checks. So let’s send it and see how the work gets divided. First watch whether the architect actually delegates. We want separate assignments with an agreed interface. The game engine needs to expose the board state and game actions and the interface worker needs to know how to use them. Otherwise, both workers can produce reasonable code that doesn’t fit together. The team uses a shared checkout overlapping declared file scopes weight which helps coordinate edits, but sensible boundaries still matter. Two agents shouldn’t both be

[07:44] rewriting the same page because they were each told to build the entire game. Open architect and workers on the right of the conversation. You can see the assignments and status. Then click a worker to read its response tool activity and latest checkpoint. The main conversation stays manageable while the detailed work remains available. Workers can also communicate with the architect and teammates. If the interface needs a different engine response, it can raise that issue and the architect can coordinate the change. A checkpoint records progress, next steps, and

[08:15] blockers, which is useful when a task takes several rounds. Here’s another place Jev fits. Suppose we’ve discussed the engine contract and now need to find that agreement. In Jev assistance, open find context and ask what contract we agreed on between the engine and interface. Preview the excerpts, then run the lookup. It returns relevant original text from the recent task conversation. This doesn’t rewrite the history and it isn’t a search across every file or every worker transcript. If the agreement is outside that recent window, open the original worker conversation. I like this as a focused

[08:46] way to retrieve an earlier decision. The normal checkpoints and conversation history still do the main job of keeping a longer task coherent. We aren’t making the agent depend on Jev remembering everything. Bamboo can bring the architect back when teammates send messages or when worker results are ready for review. You also have pause, resume, and stop controls. If the same blocker keeps returning, check what’s happening before spending more on another round. Once a worker settles, open its saved changes. This is where I want to see the diff and the actual test

[09:17] output, not just a confident paragraph saying everything is done. From that worker or from its saved diff, click review with Jev. Ask it to assess whether the available evidence covers the requested behavior and point out missing verification. Preview evidence shows what will be assessed before you run it. The report can flag unsupported claims or uncertainty. For example, if a worker says best times persist, but there’s no relevant test or browser evidence, that’s something to investigate. The check doesn’t run the test itself, and I would keep the

[09:48] architect responsible for deciding what to do next. Review a settled worker here. If you review a task while agents are still running, active work will be called out as unresolved. That makes sense and there’s no reason to keep calling the checker until it agrees to finish. Then check the saved changes against our project rules. We want to know whether the engine stayed separate from browser code and whether the changed rules have meaningful tests. These are file level judgments about the saved patch. So open the source diff when something gets flagged. Use report in prompt adds the result to your draft.

[10:20] You can ask the architect to investigate a finding and give the relevant worker a focused follow-up. Nothing gets sent just because you open the report. Now, let’s test the actual app. Ask the architect to start the local preview. Then, open it from Bambood’s browser panel and its list of local servers with the optional browser integration enabled. Click test with Jev. Give it a specific journey. Start a game. Reveal a cell. Place and remove a flag. Restart and change the difficulty. Finish on the game screen and report any interaction that fails. Jev drives a separate Chrome session, so it isn’t using your personal

[10:50] browser tabs or signed in cookies. For this demo, the build prompt asks for the title, mind sweeper, and visible labels for difficulty and new game. We can use the title and visible text as independent final checks. Then watch the actions stream into the report and inspect the screenshot. There’s an important distinction in the result. Agent finished means the browser agent reported that it finished. Checks passed means those specific assertions passed. A correct page title doesn’t prove that the mind placement or timer logic is correct. So keep the engine tests and inspect the gameplay, too. You can also

[11:21] ask the architect to run these browser tests through its tools. Tell it to wait for the reports, read any failed checks, and inspect the screenshots before ending the turn. That lets it use the findings in the review without you copying every browser action into the conversation. Run a second check with the mobile preset to look at the narrower layout. I would still test the keyboard controls manually and verify saved best times across a reload. Browser automation can get stuck on unsupported interactions and I want those limitations reported rather than counted as success. If the timer keeps

[11:51] running after changing difficulty, for example, give that exact behavior back to the architect. It can assign a focused fix, rerun the affected tests, and repeat that browser journey. You can check the revised saved diff with Jev again when there’s new evidence to assess. That’s the loop we’re aiming for. Clear assignments, implementation, useful evidence, and a focused fix when something is wrong. Jev helps at selected points while the architect and workers continue doing the development. Without a Jeff key, you can follow the same process using the normal worker conversations, diffs, tests, and browser

[12:24] panel. You can also enable only decision assistance and keep testing the interface yourself. There’s no requirement to add another model service just to use the team feature. Now about keeping this economical. Start with work that can actually be separated. Two independent components can justify a team. A oneline change probably doesn’t need two workers and several review rounds. Keep the assignment specific and the checkpoints concise. If a cheaper model repeatedly gets stuck, a stronger worker might finish the job for less overall. The cheapest token price doesn’t necessarily give you the

[12:55] cheapest completed task. include the architect workers retries, bambooed subscription, and any jev or browser helper usage when comparing costs. I would use the extra checks where they save repetitive investigation. Then measure the complete run. Adding another model doesn’t automatically save tokens or time. You can still use the MCP approach from the post if you prefer putting together your own setup. What appeals to me here is selecting the team in one place, following its progress, and reviewing the work in an interface that looks and feels much better than

[13:25] another plain coding window. It is still $20 a month, and it’s still alpha, but the architect and worker workflow is builtin. The profiles are easy to reuse, and Jev adds some interesting optional checks around it. You can start with your existing models and add the extra pieces only when they help. Overall, it’s pretty cool. Anyway, let me know your thoughts in the comments. If [music] you like this video, consider donating through the super thanks option or becoming a member by clicking the join button. [music] Also, give this video a thumbs up and subscribe to my channel. I’ll see you in the next one.

[13:56] Until then, bye.