Criando um jogo de digitação ao vivo com Claude Code

Pessoal, então tô aguardando chegar mais gente aqui, mas já vou começando a traduzir um pouquinho o que que a gente vai fazer hoje, né? A ideia aqui é desenvolver hoje um jogo ao vivo, tá? A gente vai utilizar o Cloud Code como ferramenta de desenvolvimento aí, principalmente assim com o modelo Opus 4.5, provavelmente. Hoje saiu o Opus 4.6. ele não sei se ele vai estar liberado para mim até na hora que a gente for implementar daqui a pouquinho. Então, ah, vou aproveitar para falar um pouquinho também do processo que eu utilizo, como que eu construo

os meus agentes, né? ser bem divertido. Esse processo todo não é um processo tão rápido, afinal de Contas, é um jogo e a gente quer fazer ele bem feito. Então, imagino que a gente vai levar por volta de 1 hora e meia mais ou menos para ter o jogo funcionando. Talvez a gente leve mais tempo, quem acompanha até o final para estudar bem o processo, como que é feito. a gente vai utilizar um processo de desenvolvimento, uma metodologia, né, que chama spec Driven Development. Eu tenho ela Incorporada nos meus agentes. Então, vocês vão ver isso

na prática. a gente vai começar trabalhando uma especificação, pensando como que vai ser esse jogo e depois implementando ele para ver na prática rodando. Então, eh, a live que eu tô fazendo, se vocês eh puderem mandar algumas mensagens no chat, eu também vou conseguir acompanhar o que que vocês estão mandando, Responder perguntas. Talvez eu posso mostrar alguma coisa. Ó, eu tô vendo que tá que tá funcionando o chat, então perfeito. E bom, já tem aqui. Acho que a gente pode ir começando, né? Coisa pra gente se familiarizar, que ferramentas eu vou usar hoje aqui, tá?

Eu tô usando o antigravity. Lá peca. Só um minutinho. Olá. Agora sim, né? Eh, vamos lá. Eu tô vendo, já tem algumas pessoas aqui na live. Ah, a gente vai começar daqui a pouquinho. O objetivo de hoje vai ser implementar um jogo de digitação, estilo BK Type. Eu posso most vou mostrar daqui a pouquinho como que é essa ferramenta. Mas, ah, Para quem para quem já precisou em algum momento eh se adaptar a um teclado novo, por exemplo, ah, eu comprei um teclado em inglês, eu tô acostumado com teclado BNT em português. É, às vezes

é um é um saco a se adaptar ao teclado, né? Então existem sites com ferramentas para testar eh para treinar a digitação. Então, só que a gente vai fazer uma versão bem mais legal disso. A gente vai fazer uma forma gamificada. Então, o jogo, a gente vai pensar juntos Aqui como que vai ser esse jogo. E a ideia é desenvolver ele usando uma metodologia que chama Speck Driving Development. Então, eu tenho ela integrada já nos agentes de desenvolvimento que eu uso aqui com o cloud code. E a gente vai acompanhar então todo o processo. A

gente vai começar com uma fase de especificação e depois desenvolvimento. E aí a gente vai ver Como que esse processo de especificação, de pensar na solução antes, vai aumentar absurdamente a qualidade da saída do desenvolvimento dos dos agentes, tá? Quanto tempo que vai levar esse processo todo? Eu acredito que por volta de 1 hora e meia mais ou menos, a gente tem tudo funcionando. Pode ser que leve mais tempo por conta de eu fazer algumas pausas para explicar o processo, como Funciona, bonitinho. Então, principalmente assim, como que funciona o a metodologia do do Spect development

e como que isso tá incorporado nos agentes, né? Então vamos lá pra gente se familiarizar um pouquinho com as ferramentas que eu tô usando. Eu tentar aquiando a como IDE, né, como casca aqui o Antigravity do Google. Então é, é também para quem não testou ainda, é um fork do Vest Code, semelhante ao que o curso é também, né? Ah, e o Insurf. Então, o antigravity por padel, ele vai ter aqui o chat de agente dele, mas a gente não vai usar esse chat de agente. Vou fazer o seguinte, vou abrir aqui o cloud code,

tá? Aí eu vou fechar gravity. Então eu tô usando o antigravity, como muita gente faz usando O curso e outras ferramentas como uma casca porque ele vai gerar auto complete outras funcionalidades. Então ele dá o ambiente DIDE, mas para o desenvolvimento vou usar a extensão aqui do cloud code, tá? é possível instalar ela ah aqui peloões do antigravity ou do Vcode, né? Ou também ao abrir Loud code no terminal é possível usar o comando barra ID para integrar ele e aí Ele vai sugerir a instalação da extensão aqui, tá? Então isso aqui que a gente

vai usar basicamente de ferramenta. E quanto aos agentes, eu tenho atualmente eles configurados como skills instalados através de um plugin. Então, ah, depois eu vou entrar em em um pouquinho mais em detalhes como que funciona isso, né? Se vocês tiverem algum eh vocês tiverem algum Eh alguma pergunta também, vocês podem ir mandando, tá? Eu acredito que o áudio deve ter melhorado bastante agora. Então, vamos lá. Primeira coisa que a gente vai Opa, obrigado. É bom. Obrigado, Luciano, por avisar, tá? Eh, faz uma diferença enorme. Segu, mas vocês estavam ouvindo, conseguiram ouvir mais ou menos a

Explicação, né? Imagina até aqui. Então, vamos lá. Eu tenho aqui um um o antigravity aberto num repositório, tá num branch vazio. E eu vou vou fechar o cloud code aqui para ele não não incomodar a gente. E a gente vai começar o processo eh com um prompt pedindo para começar um processo de especificação. Então o que que acontece? Contexto pelo agente é tudo, né? Ah, o agente não vai conseguir desenvolver um ou a gente não vai conseguir desenvolver um um software de qualidade com um pumpt ruim. Isso a gente já sabe. Agora o quanto o

quanto contexto a gente precisa dar de antemão. Eu preciso montar um prompt gigantesco com pensando em todos os detalhes por conta própria. A princípio, Eh, não. Então, o as ferramentas como o antigravity, o cursor, normalmente eles têm um modo de planejamento e tem um modo fest que é tipo um modo de desenvolvimento, que é pegar e baixar a cabeça e desenvolver. E o modo planning costuma ser para dar tempo pra gente pensar passo a passo, discutir um pouco a solução, montar um plano de ação e uma lista de tarefas. Só que isso é tudo transitório,

vive dentro do contexto dessa conversa. Então assim, Se eu começar uma conversa nova, aquele contexto não vai eh ser aproveitado pro resto do desenvolvimento. Então, por isso a gente vai utilizar uma estratégia diferente. Eu vou começar aqui ah mostrando para vocês primeiro como que é o o site de referência, tá? como que funciona uma aplicação dessas ah de treinamento de de digitação, né, para você acostumar com teclado novo. Então, por exemplo, Esse site aqui que é o Monk Type, ele tem ah exercícios de digitação. A gente pode colocar com tempo para ver o quanto rápido

a gente tá. Eh, dá para configurar por palavras inteiras. Então, se eu começar a digitar aqui, ele vai contando até 50 palavras, né? Se eu voltar e colocar por tempo, ele vai colocar, por exemplo, eu coloco 30 15 segundos, ele vai ver quanto eu consigo digitar em 15 segundos, né? Então, por exemplo, aqui ele tá eh rasteando. Quando der 15 segundos, ele vai dar um score e aí ele vai dizer quantas palavras por segundo, por exemplo, eu consigo digitar e dar um score todo bonitinho. Agora, então assim, isso aqui vai ser a base que a

gente Isso aqui vai ser a base que que a gente vai eh tá implementando. Só que a ideia é fazer Isso aqui num formato de jogo. Então eu gostaria que vocês mandassem aí no chat algumas ideias de como que a gente pode transformar isso num jogo, tá? estilo de jogo. Você pode, se vai ser um jogo tipo de corrida, onde que a navezinha vai andar mais rápido a quando a gente digita mais rápido, ou se vai ser meio que um, não sei, um shooter tipo, ah, estilo uma versão mais simples de Doom, onde o que

vai atirando nos inimigos quando a gente digita alguma Coisa nesse sentido. Ah, enfim, aí a imaginação é o limite. Então se vocês puderem mandar qualquer coisa que que surgir de ideia aí no chat, a gente vai vou tá considerando, tá? Aí enquanto não chegam as aí se vocês v passando aqui, é o rabo da gata, tá? Aqui, deixa eu mostrar ela aqui, ó. Aqui a Perphon, não é Perphony, ela sempre participa, tá? É qualquer evento online ou coisa que tiver, ela participa E eventualmente pode vir o outro gato ainda que é o Hércules. Então é

um pouco difícil de evitar. ela vai querer fazer companhia pra gente aqui. Primeira coisa que eu vou pegar de referência aqui também é o próprio um print do site, tá? Vou tirar um pente do site aqui e eu vou eh também pegar um um print da página de resultados, que daí a gente pode colocar estatística no nosso jogo também. A gente pode inventar o que quiser, né? Aqui eu vou pegar essa tela aqui também. estatística. Eu tenho isso aqui também vai gerar um, acho que um conceito legal. Ó, o Guilherme mandou aí uma sugestão de

fazer um jogo de corrida pixel artiga, eu acho que é uma boa, uma boa ideia pra gente seguir, tá? Que que eu vou fazer, então? Eh, eu vou começar o PT dizendo o seguinte, Eh, eu vou vou colocar aqui no caso a nossa intenção, tá? O o importante nesse momento é a intenção, porque daí o o agente através da skill de planejamento, ele vai rodar todo um processo eh de enriquecimento primeiro do contexto. Então assim, em vez de a gente dar o contexto todo pronto, na forma de um prompt super gigante, a gente dá ferramentas

para a gente conseguir por conta própria, enriquecer. Então ele tem Ferramentas de pesquisa, onde no caso ele vai usar o perplexity research. tá, que é tipo a pesquisa profunda. H, aí ele também vai poder fazer pesquisas online, ler documentação e tudo mais, ver boas práticas. E aí depois com base nesse contexto ele vai fazer algumas perguntas para entender o em que direção que a gente quer ir, como que a gente quer lidar com alguns problemas técnicos, fazer um um consenso Com simulando como se fossem várias discutindo a solução. Então a gente vai ver na prática

como que vai funcionar isso. O Volnei mandou aí também um uma ideia aí que ganhando premios quando tá conseguindo digitar na velocidade exigida. Então você tipo colocar um alvo, um uma meta, né, de velocidade e daí ganhar prêmio, sei lá, pode acumular algum tipo de prêmio ali. Então vamos começar assim, ó. Eu vou especificamente dizer que que a Gente vai especificar. E aí assim, por que que eu tô usando o verbo especificar aqui? É pro a gente saber que a gente tá lidando com uma especificação e consequentemente ele vai saber qual skill carregar, tá? sem

eu precisar explicitamente dizer use a skill tal. Às vezes é necessário, mas normalmente eu não precisa. Então assim, ó, vamos especificar um jogo de digitação estilo Monk type, tá? Ah, temos imagens de referência da tela do app e da tela de estatística. Aí eu vou colar aquelas duas imagens ali para ele ter de referência. ele vai conseguir ler essas imagens e também usar como contexto, inclusive eh de disposição visual dos elementos, mas também do que que envolve tudo essa Aplicação. Então, a gente vai colocar o seguinte, ah, o estilo do jogo ser ou o gênero,

né? Então, o gênero do jogo ser a corrida. Ah, talvez com eu vou colocar, o Guilherme sugeriu pixel art, mas eu vou pedir para ele fazer um cyberpunk pixel art, tá? Eh, pixel art com estética Cyberpunk. Aí vou colocar também a sugestão do Volnei aqui de ganhando prêmios, né? Ah, Vamos incorporar, vamos disponibilizar um tipo de jogo. Ó, Cris mandou um abraço. Vamos lá. Ah, vamos disponibilizar um tipo de jogo. Ah, outro abço, Cris. Ah, um tipo um modo de jogo, né? um modo de jogo em que o usuário coloca eh ganha melhor, vamos colocar

assim assim, ó. Eh, quando o usuário bate a meta de velocidade, Ele ganha eh prêmios na forma, eu vou vou inventar alguma coisa que tá de boost de velocidade. Faz sentido, né? um um de velocidade, ah, como um turbo. Aí, ah, alguns detalhes técnicos que a gente já tá pensando aqui. Vou colocar que a princípio vai ser uma aplicação, é, vai rodar no browser e vai rodar usar a biblioteca biblioteca 3 js para que é uma biblioteca para fazer aplicações Gráficas, né, em JavaScript. Deixa eu ver se precisa de mais alguma coisa. Princípio acho que

não precisa de backend. Colocar aqui a princípio. Não precisa, não precisa de back end. Isso pode ser colocado numa fase dois, né? Não precisa de back end. Bom, acho que é o o suficiente para começar. Então eu vou mandar esse pt aqui. A princípio ele deve carregar a skill de Aqui, ó. Ele carregou a skill do meu plugin, que é o spec úter. Então essa essa skill spec, cara, é um um uma skill bem extensa. Ela tem ela, depois eu vou mostrar um pouquinho, ela comprime todo um processo de desenvolvimento. Então assim, com base na

com base no que que é skills, como que ele tem que proceder, ele já começou um planejamento aqui que ele tem várias fases para seguir, para planejar essa aplicação para ela dar certo. Então, Primeira fase é uma fase de pesquisa. Então, carregar o repositório, ah, fazer pesquisas externas e é uma fase de licitação. O que que é uma fase de licitação? ele vai ver questões assim, tipo critérios não definidos, né, coisas que precisam ser eh decisões que precisam ser tomadas e vai pedir pra gente, né, pro humano que tá tomando as decisões. Afinal de contas,

senão a gente não tá fazendo um processo de vibe coding aqui, né? é um processo de Engenharia. Então, na sequência, ele vai escrever os requisitos, conforme ele entendeu, requisitos funcionais, não funcionais no formato ears, que é um formato simplificado, tipo, é bem parecido com testes de end to end, então uma linguagem tipo quando tal coisa acontecer, então tal coisa deve eh ser verdade, né? E depois ele vai passar para uma etapa de Desenho do sistema e eu e decisões com análise de tradeofice, tipo tradeofice, a análise de tradeof é tipo assim, a gente tem várias

bibliotecas possíveis de usar ou estratégias de arquitetura e a gente precisa comparar entre elas, ver os pos e contas e tomar uma decisão. Normalmente isso aqui é resulta então numa decisão de arquitetura que é uma DR. Então isso tudo vai ser documentado eh automaticamente também. Então ele vai gear tesques depois e aí no final das Contas a gente tem que decidir se começa ou não. E aí a gente troca de agente para uma skill de desenvolvimento que daí sabe pegar esse material e explorar. Então, a primeira coisa que ele foi fazer aqui, seguindo aquela lógica,

é explorar a estrutura do repositório. O que que ele viu aqui? Que não tem nada, né? Então isso aqui, primeira coisa que ele fez, ah, vou explorar aqui o que que tem e tal, tem nada. Aí ele fez uma pesquisa usando o Perplexity. Perplexity, para quem não conhece, deveria conhecer, eu super recomendo, é uma ferramenta de pesquisa. Deixa eu entrar no site deles aqui. Perplex é uma ferramenta de pesquisa que é aumentada por IA, então eles competem diretamente com o Google. E a gente pode pesquisar aqui a tanto uma pesquisa mais rápida quanto uma pesquisa

profunda. A pesquisa profunda é para construir relatórios e coisas assim. Então, eh, quando a gente Quer, sei lá, eh, pedir pra gente acessar, por exemplo, uns 100 links, eh, fazer uma ou umas 10 ou 15 pesquisas sobre um tema para dar montar um relatório e entender como que é o contexto daquilo. Isso também é útil pra gente entender, por exemplo, como qual é o estado da arte ou qual que é a forma idiomática de programar alguma coisa, um sistema de autenticação, qualquer coisa assim. E essa ferramenta aqui é o que ele vai Usar lá para

fazer a pesquisa. Então aqui, bom, ele chegou agora numa etapa de perguntar. Deixa eu ver uma coisa. Se eu fechar aqui, ele interrompeu, mas aí eu já vou pedir para ele continuar. Vamos seguir aqui. Então, ele fez uma pesquisa e sobre como construir um, tipo, se tem ah guias práticos de como construir jogos pixel articypando 3JS. E aí veio um relatório aqui, deixa eu ver se eu consigo colocar ele Word Wrap. Dá de ver aqui, ó. Esse aqui é o resultado da pesquisa que ele fez através da ferramenta do perplex. Então isso aqui tudo tem

aqui questão de controle de frame, como que vai fazer isso em JavaScript e tudo mais e todos os links que foram usados de referência. Então isso aqui pro agente vai ser super super eh útil para embasar as decisões de como que vai ser feito isso. É bem diferente de a gente pegar e pedir assim, ó, chegar para agente e Dizer: "Me faz um jogo". ele vai pegar e vai ah tomar decisões localmente com base no que ele aprendeu no treinamento, mas não necessariamente ele vai ter o contexto certo para tomar boas decisões. Então aqui ele

tem contexto atualizado e boas referências. Aí então ele dá uma olhada se tem coisas no histórico do Git e tudo mais, porque tá tá vazio aqui, né? E aí no final ele tá usando uma outra Ferramenta que é o o sequential thinking. Esse sequential thinking é um uma ferramenta MCP absurdamente útil para potencializar os agentes. Ele permite, ele faz mais ou menos aquele padrão que é o encadeamento de pensamento, né, o chain of thought, só que na forma de uma de uma ferramenta que ele pode usar. Então quando ele faz aqui, ele pensa assim: "Olha,

eu tenho um monte de coisas para pensar. Eh, eu tenho isso, isso, isso, isso para Resolver. Eh, quanta, tipo, quantos pensamentos eu vou precisar, vamos dizer assim? quantas reflexões ou quantas coisas eu tenho para refletir e quais são. Então essa ferramenta vai meio que criar um plano e ele vai seguir esse plano. Nesse caso, é uma coisa simples. Ele ele pensou um é uma coisinha aqui e aí ele vai chegar para essa etapa de licitação. Então eu posso dizer assim, ó, continue com a etapa De licitação. Estou pronto para responder ao longo do processo aqui,

tá? Se vocês tiverem eh dúvidas ou curiosidades, vão mandando aí no chat que eu vou aproveitando para responder. Então, no caso aqui, ele ele mandou três perguntas pra gente. Primeira coisa, a parte visual e mecânica. Como a corrida se conecta visualmente com a digitação? O carro Anda conforme digita, tipo, a velocidade dele é igual ao palavras por minuto, né? Então, se eu tô digitando 30 palavras por minuto, vai ser tipo 30, sei lá, milhas por hora, alguma coisa assim, 30 km/h. E como que é a perspectiva visual? Então, ele colocou assim, ó, pode ser um

side scrolling ou pode ser uma perspectiva pseudo 3D. Então, um pseudo 3D seria tipo um hold. Eh, se a gente olhar um desses, por exemplo, out run, Deixa eu ver. Isso aí é um jogo tipo assim, né? Ah, poderia ser algo nesse sentido, tipo outdo. Legal. Aí, só que pixel art, né? Eh, a outra, então, visão tipo Stelda se aproximando. Sprites pixel art. 3D com js e top down. Não, eu acho que essa opção aqui do 3D vai ser mais legal. Aí, qual que é o escopo? Vamos lá. A gente pode aproveitar aqui para dar.

A gente não precisa escolher Necessariamente as opções. A gente pode colocar outro e colocar uma resposta livre se a gente não concordar com nenhuma das sugestões, né? Então, ah, é um typing teste geral com skin, com skin de corrida ou tem progressão campanha? Não, eu acho que não precisa ter campanha, basta ser um typing test. Aí ele tá perguntando se é focado num teclado específico aqui, que é, eu acho Que é porque em outro branch, eu já implementei um uma coisa parecida para teste, mas não vai ser para teclados comuns. Então é um typing teste

corrida casual, então tipo um monk type com visual de corrida. OK? Corrida com progressão ou híbrido? Não, isso aí é um typing test mesmo. Perfeito. Aproveitando aqui, o Vnei perguntou assim, ó: "O agentes foram construídos por você ou está utilizando de alguma empresa, principalmente na Questão de processo de desenvolvimento dees de arquitetura e etc? Esses agentes foram desenvolvidos por mim." Então, eh, só respondendo aqui a pergunta do Volnei, eu vou constantemente refinando esses agentes e aí quando eu faço as eh, consultoria ou eh workshops de treinamento corporativo nas empresas, eu integro junto os agentes que

vão ser incorporados daí nas empresas aqui da Região, principalmente onde que eu tenho feito consultoria, mas geralmente eles recebem a última versão que eu tinha naquele momento. Mas eu tô sempre evoluindo eles. Então eu tinha antes só na forma make de um comando. Então é um agente incorporado todo num comando. E hoje eu tenho ele na forma de um plugin com uma série de skills. Então ele tem essas skills p pack review development, onde que eu eu tô refinando cada vez mais. A última Coisa, por exemplo, que eu incorporei aqui no na skill de especificação

é um uma skill extra para paralelização de tarefas. Então ele tem script para pegar a sequência de tarefas eh que foi que vai ser gerada. A gente vai ver daqui a pouquinho a as dependências entre essas tarefas. Então, através dos requisitos funcionais, não funcionais e tal, a gente consegue montar um grafo e ver a árvore de dependências dessas tarefas e Ver o que que pode e o que que não pode ser paralelizado. Então, e aí ele coloca um, constó aí eh abaixo da lista de tarefas, uma sequência de ondas como sugestão para agente de desenvolvimento.

Se ele tiver capacidade, por exemplo, o modelo do Opos tem capacidade de de controlar subagentes. Então ele pode decidir, por exemplo, pegar duas ou três ou quatro tarefas e eh criar agentes ah subagentes para lidar Com elas em paralelo, para diminuir o tempo total e não fazer tudo sequencialmente, né? Então, esse tipo de de mudança, à medida que eu vou vendo o que que funciona, o que que não funciona, eu tô cada vez mais eh evoluindo esses esses agentes. Então, assim, quanto a stack técnica, ele tá perguntando assim, vai ser React com RTF, que daí

seria o tre fiber O stand. Cara, eu acho que não. Eu acho que vai aumentar muita latência do processo. Ah, 3JS vanila e HTML. Trjs por per handerem. HTML com overlay. Eu acho que vai ser melhor fazer um vanila, mas Talvez estende uma boa biblioteca para eh mas eu não lembro se, por exemplo, nesse caso aqui, eu não lembro se uso stand a gente pode usar para salvar estado fora do ecossistema do do React, né? dúvidas normais que podem acontecer aqui quando não é a nossa stack principal, né? Então vou colocar assim, a princípio seria

a opção dois, que seria 3S vanila mais HTML. Ah, com os stands E genciamento de estado, na verdade não, né? Eu acho que ele ele é só para ambiente React mesmo. Vamos pela opção do do React. Nesse caso aqui, eu acho que vai funcionar bem. Eu não lembro de ter usado o Tree Fiber, mas eu acho que eu já vi vídeo dele e é bom. Então vamos lá. Quanta a aí assim padrões de arquitetura e tal, né, que talvez é um uma curiosidade. Eh, Hoje a gente não opina muito sobre eh ou tentando forçar numa

direção que seja uma preferência de design, né, como ah, por exemplo, vai ser clean architecture ou vai ser um com vertical slicing ou qual que vai ser a arquitetura, né? Eh, aí isso fica muito, acho que a critério do desenvolvedor. E normalmente quando tu for usar isso num num ambiente empresarial, onde que tem a já tem os sistemas em andamento, então Não tem tanta escolha sobre a arquitetura, tem que trabalhar com o que já tem ali, né? Mas vamos lá. Quais idiomas de palavra que o jogo deve suportar? Cara, português e inglês, tá ótimo. Português,

na verdade, não, só português. Eu vou colocar só português aí. Vamos lá. Turbo. Sobre a dinâmica do turbo, o que define a velocidade? Então, é qual é o efeito mecânico? Meta dinâmica baseada em WPM médio. Vamos ver. A meta é o WPM médio recente do jogador, mais uma margem, tipo, tu estaria sempre correndo para aumentar tua velocidade. Faz sentido. Então, a bater ganha turbo, daí partículas, blur, carro acelera, feito visual estético ou meta fixa por faixa. Então, quando tu atinge uma faixa, tipo 30, 50, 70, cada faixa faz um turbo diferente. Eu gostei mais dessa

opção aqui, eu acho. E o turbo por a coácia. Quando Ah, esse aqui também é legal. Quando tiver acertando tudo, ganha turbo. Olha, eu acho bom. Vou nessa opção aqui do do turbo por aqui pista neon, carro pixel MVP em xuto ou pista, pédios, tudo não. Acho que não precise de pédios por enquanto. A gente pode adicionar eles depois. Ah, vamos. ou minimalista, não, vamos nessa pista neon, tá? Então assim, com essa primeira fase De licitação aqui concluída, ele pode vir ainda a perguntar mais coisas no meio do processo, tá? Porque o cada portão desse

dessas fases aqui, ele tem que atingir um percentual de certeza ou reduzir a incerteza. Então, se restam dúvidas ou coisas mal especificadas, ele dever perguntar para só então seguir. Então, nesse caso, ele tá criando agora uma pastinha aqui para criar os artefatos da especificação. E é importante que eles fiquem ah dentro da Pasta do repositório, porque daí eles são tanto versionados. E aí uma coisa muito importante é quando a gente trabalha com spec driven development, a especificação é, vamos dizer assim, a fonte da verdade da do desenvolvimento daquela feature, mas ela ela serve tanto para

alinhar o mano com agente, porque esses agentes aqui hoje eu tô usando ele aqui na IDE, mas nada impede que um agente esteja rodando, por exemplo, num Num ambiente produtivo, pegando ando tarefas do giro e implementando elas e gerando por request assincamente. Se eu tiver múltiplos agentes, o que acontece? Eles tendem a divergir no entendimento do que que do que que a gente tá constituindo. Quando a gente centraliza a especificação, a gente alinha todos eles. Então é uma forma de alinhamento de agentes, ter os o os documentos da especificação dentro do Repositório. Aham. Ele tá

demorando um pouquinho aqui, mas Ahã. Aproveitando, deixa eu mostrar aqui o modelo. Eu tô, ó, inclusive eu nem tinha visto. Tô usando o Opos 4.6. Ele foi lançado hoje à tarde. Até então tava usando o 4.5, né? Ah, mas ótimo. Excelente. Então, eh, o que que acontece? Ele, primeira coisa, ele vai fazendo um registro aqui das decisões Até aqui, tá? Então, deixa eu fechar aqui. Vamos colocar grande. Ah, ele documenta o que que ele encontrou quando ele fez a pesquisa. Ah, quanto aos tópicos, né? o que que ele perguntou, então, e o que que a

gente respondeu, ou seja, toda aquela lógica, aquele processo de descoberta tá documentado até agora aqui no no arquivo de decisões. Aí ele criou o arquivo dos requisitos, tá? Esse aqui ele Foi inicialmente inspirado no na versão que a ferramenta Kir da AWS faz. É uma outra ideia que tem spec Driving Development implementado eh nativamente, mas é um processo bem diferente desse que eu tenho aqui, né? Então aqui ele colocou contexto de negócio. No caso assim, aqui é um jogo, né? Mas assim, eh, a gente tá chamando de keyboard rider, ele já pegou o nome aqui

pelo nome do repositório, né? Então, é um jogo de pética de digitação No Bellser com estética Cyberpunk e tudo mais bonitinho. Quem são os atores? É o jogador, a princípio, esse aqui é o ator que tá envolvido. Eh, restrições, né? Bells é only, não vai ter back end. Persistência no local storage, stack. princípio, isso aqui, React, React fibers, o stand. E aí vem os requisitos funcionais. Então assim, teste de digitação por tempo Crítico. Quando os jogadores selecionam o modo de tempo e começar a digitar, o sistema vai iniciar um um timer de countdown e apresentar

palavras eletórios em português. A gente pode, por exemplo, pensar assim: "Ah, não gostei dessa ideia de ser em palavras aleatórias. Talvez eu queira ter um, sei lá, uma lista de lições onde que pode selecionar uma lição. Então eu poderia pedir pra gente dizer: "Olha, não gostei, quero que mude esse Requisito, né? Ah, exibição de WPM de, no caso, a velocidade em tempo real, exibição de aquácia em tempo real, validação de caracter por caracter. Perfeito. Para ele podermos ter a corzinha vermelha quando a gente erra. Movimento do carro proporcional ao WPM. Então, quando enquanto o jogador

está digitando, o sistema vai mover o carro na pista pseudo 3D com velocidade proporcional ao WPM atual o do jogador. Visualização pseudo do 3D da pista. Sistema de turbo. E aí, o sistema de turbo é de acordo com a corácia. Tela de estatística pós teste, gráfico WPM, seleção de modo de tempo, reinício rápido. Porque da onde que ele tirou esses requisitos aqui, a gente não pediu reinício rápido, mas lá no Monk type que a gente tirou o print, ele viu que tinha um botãozinho de de repeat aqui. Então assim, ele enfeiu corretamente que dá para

a qualquer momento começar de novo. Aí é feitao de velocidade, vai fazer um blur nas laterais da pista. Quero ver ele conseguir implementar isso aqui bonito. Mas vamos ver. Tem efeito de bloom, que é um tipo um brilho, indicador visual de erro, texto rolante. Então assim, quando a gente tiver implementando uma feature real assim do de sistema, o qual que é a ideia? O desenvolvedor que tiver pego essa tarefa, ele vai usar como insumo para tipo essa parte de especificação o A o contexto que ele tem até ali. Então, de conversa do time e aí

mais que nunca é importante gravar as conversas e ter a transcrição, porque a transcrição em forma também, tipo, é um insumo valioso pra gente aqui na hora da especificação também o conteúdo do card. Então, por exemplo, se os cards estão no GIA, tem servidor MCP que consegue usar o JQL lá do G, fazer consulta, encontrar o card correto, pegar o o conteúdo lá e e ler a especificação, Né, diretamente de lá. Então aquilo ali vai ser a informação importante, transcrições vão ser informação importante e mais qualquer outra informação que o que a gente tiver à

mão no momento. Então assim, esse processo aqui é um processo meio de conversa, né? Eh, ele acabou de terminar o ORS, então assim, os requisitos funcionais, aí tem os não funcionais. Ele segue esse padrão. Eu esqueci o que que significa siglo aqui, Mas até vamos ver aqui rapidinho que faz tempo que eu implementei isso. H, o que significa a sigla que as no contexto de ah requisitos não funcionais? quality attribute scenarios. Então são cenários de atributo de qualidade, OK? Esse é o padrão que tá implementado aqui. Aí ele tem ah requisito de latência de key

stroke, então Ele tem que ser rápido a digitação do teclado, frame rate estável, tempo de carregamento não é para demorar muito, responsabilidade em desktop, persistência dos dados, enfim. Ah, todos esses requisitos aqui a gente não vai ficar vendo todos assim com com detalhe, mas a ideia é que essa especificação pode ser o primeiro por request do do processo de desenvolvimento, porque a partir do momento que ela tá pronta, é um agente Que vai desenvolver e ele vai desenvolver rapidamente. Então, vale mais a pena colocar bastante esforço do time em revisar bem a especificação, porque a

especificação passa a ser praticamente quase mais importante do que o próprio código, né? Então beleza, vamos dizer que os requisitos estão legais, mas eu só não gostei de um deles. Eu vou pedir para ele ir ajustando enquanto a gente eh continua vendo o resto dos artefatos Ali. Então, o que que era que eu não tinha achado interessante? Testitação por tempo. Palavras, Ah, sim, palavras aleatórias, né? Eh, vou colocar assim, ó. as palavras eh que aparecem não devem ser aleatórios. Eh, vou colocar aqui requisito um. Eh, melhor que sejam carregadas de um, Colocar assim, repositório de

exemplos. O e pode ser estático. Beleza? Então eu vou mandar esse aqui. Ele vai fazer os ajustes necessários na especificação enquanto isso. Aí vamos dar uma olhada no que que tem no diagrama, no documento de design, né? Então aqui ele começa fazendo diagramas C4, nível 1, 2 e 3, tá? Então, primeiro, nível um, contexto, jogador, digita palavras. O System Boundary dele aqui é Um jogo que roda no navegador, mas que vai est justamente usando o local storage do browser, API de web áudio API para usar o o áudio no browser e renderização via webs através

daquelas bibliotecas ali do R3F. Aí tem a questão aqui dos contextos. Ele link com os requisitos que geraram esse esse diagrama. Contexto nível dois. Então aqui já vai entrando pel diagrama de conttainers. A gente vai ver que aqui tem o tem um um Motor de digitação que é o typing engine, tem a cena de corrida, sistema de áudio, geredor de palavras, a questão de gerenciamento de estado usando o stand. Ah, e uma camada de UI que tem os Ruds, a visão do teclado, essas coisas, né? Ah, diagrama TR. Então, aqui já é um diagrama de

componentes para cada parte aqui do sistema. Acho que não vamos ficar olhando muito em detalhe. Ah, o deployment ou então um diagrama de Deploy. Nesse caso aqui é uma aplicação simples, talvez nem precisaria, né? Mas ah, então então por isso que no caso ele disse assim, ó, como é um MVP, não precisa de um diagrama de deploy, mas se fosse uma aplicação eh produtiva, ele ia colocar também diagrama de deploy, porque daí é importante para ver como que vai encaixar nos ambientes e tal. E também os agentes ficam cientes já na hora de levantar as

tarefas, Eh, que precisa ter as coisas configuradas, variáve de ambiente, eh, e tudo mais, né? Aí, diagramas de sequência. E aqui é importante porque tem tanto para cenários de sucesso como para cenários de falha. Então, ah, para cada um dos fluxos aqui, isso vai fazer também com que o cenários de falha sejam previstos na hora de prever as tarefas que os agentes têm que fazer para implementar essa aplicação, Né? Vamos ver aqui. Aí, eh, uma coisa que eu adicionei recentemente também é quando é uma aplicação visual, ele faz já aproveita para fazer um mocap em

Ask Art do das telas pra gente ter uma ideia de como que ele tá pensando a aplicação. Então, assim, a tela principal dá de ver que tem a pista aqui, que é uma pista meio em 3D com o carro speedlines. aqui embaixo a o texto para digitar e aqui o Velocímetro e tudo mais bonitinho. Aí a tela de resultados, como que ele tá pensando? E aí assim decisões técnicas que a gente tomou. Então ele foi registrando aqui, olha, algumas coisas inclusive ele mesmo tomou de decisão. A gente pode pedir para mudar. Ele diz: "Olha, o

Canva dessa parte 3D é 40, 50% superior da tela. Então o jogo 3D vai aparecer aqui em cima e aqui embaixo essas outras partes de digitação. Então não vai ser um overlay por cima de Um cenário todo 3D. Nesse caso aqui, a gente podia pedir para ele, não, eu quero que seja tudo dentro do contêiner 3D, mas acho que não tem necessidade. Aí ele disse que a técnica para fazer o pseudo 3D, a estedas gerada com planos segmentos que se afasta em perspectiva. Então eu imagino que são vários, ah, que são tipo vários planos assim

em em sequência que se movem e vão aparecendo ou vão sendo realocados, né? Squel contínuo proporcional WPM, câmera Fixa atrás do carro, leva inclinação para baixo. Para mim tá excelente assim, do jeito que tá. A gente pode ver aqui no requirements também se ele mudou aquele requisito um que eu pedi para ele mudar antes. Então, ó, palavras carregadas de um repositório estático e exemplos em português. Perfeito. Então, a gente já viu aqui o arquivo de Requirements, o arquivo de design e agora a gente vai ver também as tasks, né? Como é que ele planeja então

implementar isso? Porque a implementação vai ser feita por outro agente ou outros agentes, né? Então ele pensou em 12 tesques, né? Ah, e aí a estratégia de decomposição dessa dessa aplicação é é via vertical slicing. Aí a no caso ele vai fazer uma parte com motor, cena, a parte de UI e dados. Aí outra parte do Word Generator, outra parte da cena. Então, como elas são independentes, elas podem ser paralelizadas. Essa é a lógica que ele tá seguindo. Então, ele ele o que que tem aqui como lista de tarefas? Setup do projeto médio, todas com

uma estimativa de complexidade e de risco. Risco é tipo efeitos colaterais que pode gerar na aplicação ou coisa assim. Nesse caso, com uma aplicação nova vai ser baixo. E A complexidade poderia ser usada para selecionar qual modelo a gente utiliza. Complexidade baixa poderia rodar com um modelo mais barato, não precisaria de um por exemplo, né? Então quais são os passos para implementar isso? criar um projeto white, instalar as dependências, configurar a estrutura de pasta, configurar o typescript em strict mode, configurar o lint preacheter e tudo mais bonitinho para um projeto novo com essas características. Dois,

o core do motor De digitação já é uma uma de alta complexidade. Ele vai implementar handler para digitação, validador de caracteres, calculador de velocidade e essas coisas todas. Aqui a gente vê também os cartéis de aceite que estão sendo considerados nessa tarefa e quais são os requisitos funcionais e não funcionais que geraram essa tarefa. Então, a partir daqui a gente pode consultar, mas no caso o agente consegue voltar lá na nos Requisitos e entender o que que o que que impacta tudo aquilo, né? E qual que é a intenção que a gente tá eh tentando

resolver aqui? Aí a gente tem ah a questão do repositório de texto em português. Ah, criar um repositório estático injons. Perfeito. Implementar um text provider. Tem a questão da cena, tem a questão do carro em pixel art, que isso é bem importante, A parte do display why da digitação, como que vai ser bonitinha o a parte de mostrar as métricas em tempo real, efeitos de velocidade, turbo, tudo bonitinho. Então assim, a gente e aqui no final ele tem daí as dependências das tarefas. E com base nesse grafo de dependências aqui, a gente consegue o quê?

Agrupar as tarefas em ondas, onde que as tarefas dentro da onda, algumas Delas podem ser paralelizadas. Então assim, tudo depende do setup, então não tem como paralelizar aqui. Essa estimativa de duas horas é uma estimativa não de quanto o agente vai levar, mas de quanto que um humano levaria. para implement para fazer às vezes o setup, achei que é razoável que um setup de uma aplicação nova se gaste uma ou duas horas, né? Ah, então assim, essas estimativas aqui são Usadas também para infra. Aí quanto tempo que a gente consegue economizar ou qual percentual de

tempo que a gente conseguiria economizar paralelizando tarefas entre diferentes agentes. Então, nesse caso, o que que ele tá dizendo? Olha, tarefa 2, 3 e 4 e 11 podem ser executada em paralelo. Então, todas essas ali e depois integração. Aí quando eu terminar essa onda um, tá tudo OK, a gente junta todas as peças. Então ele coloca aqui essas Tarefas aqui dependem da quatro, a 5 e a 12 dependem da 2. Todas as da onda do podem rodar em paralelo entre si. Perfeito. Então isso aqui vai dar uma agilidade enorme. Então o caminho é o crítico

e o o secundário. Então esse aqui é é a ideia o que o plano que o agente de desenvolvimento vai tá implementando. Por fim, daí vamos começar a implementação, mas se a gente voltar no arquivo de Decisões, a gente vai ver que tem bem mais coisas lá. Agora ele registrou aqui o progresso ah a ao longo daqueles portões, que são as fases obrigatórias que ele tem que passar para elevar a confiança até acima de 90%. Ou seja, ele não pode ficar com muita dúvida. alguma alguma dúvida sempre existe, mas assim, as principais dúvidas foram sanadas

o suficiente pra gente conseguir seguir. Então ele tem ali aqueles registros iniciais que a gente já tinha visto das Perguntas da licitação. E aí vem também uma parte legal, eh, ADRs automáticas a partir de todas as decisões que a gente tomou junto com o agente aqui. Então, por exemplo, a decisão de usar o React Fiber, então, quais são o os drivers da decisão, quais são as opções que a gente considerou? O que que foi escolhido, justificativas? Ah, às vezes a gente não colocou uma justificativa implicitamente, mas para cada uma delas existe uma justificativa Para aquela

eh para aquela opção, né? Além disso, as opções elas vieram quando elas foram apresentadas ou a gente fez uma análise de tradeof usando um padrão que chama Atan Light, tá? Que é um é um padrão de indústria para análise de tradeoff, onde que ele elenca vários critérios. Então assim, produtividade, daí assim cada coisa vai ter os critérios próprios, né? Nesse caso aqui, como a gente tava falando de Eh da arquitetura do jogo para React com TD, tem essas esses aqui são critérios importantes, né? Eh, produtividade, performance, efeitos visuais. Então, assim, das opções, cada um tem

um score, né? Então, eh, ah, o uso stand vai ser o RF3D vai ser melhor para produtividade, mas não é o melhor para performance. O melhor para performance seria fazer um JavaScript. JavaScript puro. No entanto, quando a gente soma todos os scores, o que que a Gente chega? O que tem maior pontuação ao longo dos vários critérios é o uso stand. Então, por isso que ele apareceu lá como recomendado antes. Então, é uma forma legal de ah de a gente ter automaticamente, mesmo que a gente não tenha pensado em algum aspecto, a gente vai estar

pensando. Se a gente tiver sugestões na hora de de entrar com o prompt da especificação, a gente pode também trazer algumas alternativas e ele vai igualmente Ponderar e pesquisar sobre elas para conseguir já automaticamente essa análise de tradeoff. Então, riscos de mitigação, tudo mais. E aí cada aí depois disso ele fez um processo de consenso, tá? Isso aqui é uma das fases lá do que o agente rodou, é gerar um fazer uma discussão de diferentes pontos de vista. Então ele ele ele pode fazer isso usando sugentes ou simulando, tipo gerando respostas sobre diferentes perspectivas, Adotando

personas diferentes. Então, por exemplo, nesse caso aqui, ele tem uma persona que é o o pragmático, o outfeccionista e o o que é o motivador. Ah, o advocate é aquele que geralmente questiona, né? Então o pragmático disse o seguinte: "Olha, arquitetura clara com separação de engines, cenas e UI, tec bem suportada, ecossistema rico, tudo mais Que preocupações do pegmático. O sprite art precisa ser criado, obtido risco de bloqueio criativo. Pseudo, 3D, hold, handring é o componente mais complexo e incerto, tá? Então, talvez a gente pode até ajudar ele com essa questão. Eu vou fazer o

seguinte, se ele tá preocupado com isso, eu vou pegar, a gente vem aqui no Gemini, vamos pedir para ele criar um carrinho askart aqui. Então assim, ó, crie um Carro para jogo de corrida. De corrida. Askarte. Não é pixel art. Pixel art no estilo do top gear disess. Acho que isso vai ser bom. Aí eu vou pegar essa imagem e vou dar de contexto para ele se verar para usar ali. Pode ser que ele precise fazer algum tratamento. Pode. Aí uma questão que a gente pode colocar pra gente Rodar, tá? perfeccione. E aí ele colocou

recomendações, começar a tesque 4, eu cedo para validar a viabilidade visual. Confiança mais 2%, ou seja, com isso aqui ele ganhou mais 2% de confiança daquele que ele tem que atingir aqueles 90% lá, né? Ah, o perfeccionista é um pouco mais eh negativo, né? Então ele veio aqui com olha, precisa pesquisar melhor técnicas de pseudo 3D. estilo out run mais profundamente Durante a implementação. Então, considerar sempre em adaptativo. E aí aquele disse: "Olha, isso aqui é uma dúvida para depois." E o Advocate disse: "Olha, essa mecânica é bem massa e tal, isso aqui tá votando

a favor, né?" Mas ainda assim ele tem que tá, ele tá dizendo, "Olha, pode faltar justo, mas pode ser meio chato esse jogo só assim desse jeito, porque ele não tem progressão." OK. No final, que que acontece? que eles chegaram no score, a Gente isso foi comunicado durante aquele processo, a gente aprovou, tudo OK. E a gente tem também o esse esse aqui é como se fosse um diário do agente. É o o onde que ele registra todas as sessões do que que ele foi fazendo. E isso aqui é importante porque quando a gente tem

múltiplos agentes implementando juntos, a gente sabe qual agente implementou, qual coisa, em que ordem, o que e também ele vai colocar aqui quais foram as dificuldades encontradas e tudo mais. Ou Seja, todo o processo é autodocumentado. Eu acho que tá bem legal aqui. Vamos ver. Não, mas a gente quer perspectiva. Deixa eu colocar para ele assim, ó. Perspectiva de trás. De trás. Ah, levemente inclinada. OK. Perfeito. Vou fazer o seguinte. Gostei do plano. Eu vou dizer assim: pode Comentar. Ai ai. Beleza, a gente tem essa versão versionada. Depois a gente pode trabalhar um pouco mais

no plano. Agora a gente começa então o desenvolvimento. Então o desenvolvimento ele vai começar, a gente pode pedir para eles, por exemplo, começar pela onda um, né? Então vou colocar assim, ó. Implement a a wave um da spec. Só tenho uma spec aqui, mas eu costumo copiar o caminho relativo porque Daí ele acha mais rápido. Dois spec tal. Eu vou colocar assim, ó. Use skill de Ah, é o nome da skill, tá? só para garantir que ele vai carregar ela. Então, beleza. Aí o agente de desenvolvimento, ele sabe lidar com isso aqui. Ele também tem

um processo de desenvolvimento próprio. Então, o que que vai ter nesse nessa skill de agente aqui? Ele tá Dizendo: "Olha, você é um um dev sior 10x, né? Então assim, colocar lá em lá em cima a régua." E aí ele tem que completar a implementação das tarefas selecionadas até o comit, seguindo alguns gates de qualidade e processo de TDD. Eh, no caso é que quanto eh mais a gente vai delegando pelos agentes, mais importante é hã que a gente tenha sinais rápidos de que as coisas não que as coisas estão funcionando. Então, assim, o TDD,

por Mais que às vezes quando a gente implementa manualmente, ele colocava o o Cristí, ele vai lembrar disso. a gente colocava muito mais ênfase em testes de integração, né, e deixava testes de de unidade de geramento só para componentes de domínio, coisa assim. Colocava ênfase dos testes de integração, ah, em casos de uso, quando a aplicação eh usa clean architecture, por exemplo, né? Mas com agentes, como a gente tá delegando, Eh, é bem mais fácil eles se perderem no meio da implementação, principalmente se tiver mais de um agente envolvido ao mesmo tempo ou quando for

fazer merge de várias coisas e tal. Então, é bem mais ah a gente consegue ter muito mais confiança seguindo um processo de TDD e tendo teste para tudo. Então, se tiver alguma coisa quebrando ou a gente vai conseguir já identificar aquilo e vai corrigir, né? Então, o que que tem de importante nesse Cara, né? Eh, ele tá dizendo: "Olha, você é um um dev sior e evangelista de TDD". Isso aqui é importante para ele adicionar essa persona, né? que ele vai sempre eh ele não vai não vai eh chutar coisa, ele vai implementar as coisas

com base em teste e vai implementar os testes primeiro. E aí eh o TDD é mandatório, então ele tem que primeiro escrever os testes ah falhando antes de código de produção. Então, normalmente os agentes, Quando a gente pedia, se fosse um ano, voltasse no tempo, um ano até as e a gente fosse implementar eh qualquer coisa com o agente pedisse para ele fazer TDD, geralmente eles implementavam os testes depois, né? Eh, fazer uns testes depois. E assim ele vai seguir bonitinho o processo, vai fazer um um processo incremental. Eh, o coisas que ele deve que

ele não deve fazer estão especificadas aqui. Então, assim, ele tem que seguir estritamente os portões, tipo, eh, na sequência correta, manter o progresso dele, eh, no agent progress. Sempre que ele terminar uma tarefa, ele também vai marcar o xizinho. Aqui na tarefa aqui no tes ele vai marcar o xizinho pra gente saber o que ele já fez. Tem a questão de como das ferramentas que ele vai ter acesso para usado durante o Desenvolvimento. Nesse caso aqui ele não usa aquela pesquisa profunda, ele usa uma pesquisa mais rasa, mas ele ainda tem acesso a ferramentas de

pesquisa durante o desenvolvimento. Ferramenta também de automação de browser, que é para rodar com o eh Dev Tools, para fazer testes visuais. E aí tem os portões que ele tem que que ele tem que checar. Então, eh, dependência, ver se tá tudo selecionado, tudo pronto para começar. Questão de Testes, sempre fazer o head, depois o green refector, documentar, fazer testes visuais quando possível e no final comitar, mas ele não, ele vai pedir permissão para comitar antes de sair implementando, tá? Então, ah, aí tem mais umas aí tem aquele, eh, essa é uma descrição alto nível

e depois tem uma descrição, eh, mais aprofundada de cada um desses dessas etapas, né, inclusive com exemplos e Tudo mais, que fazer, o que não fazer, é um documento um pouco mais extenso. Então ele carregando essa essa skill, ele vai dizer: "Não, beleza, eu vou implementar seguindo esse padrão". Então ele começou entendendo aqui eh lendo a spec, as tarefas, os requisitos do design. Ah, aí ele viu se já tinha um arquivo package de Jon, foi começar a implementar. Beleza, não tem Que uma lista de tarefas. Olha, a primeira coisa que eu tenho que fazer é

o setup aqui. Depois eu posso ir seguindo com as outras coisas, né? Então, setup. Aí ele, olha. Ah, ah, eu pedi para ele criar o wave um, né? Mas eu acho que no documento ele tava mencionando o wave zero. É, eu pedi para ele fazer a um. Então ele dizer, olha, antes da uma, tem que fazer a zero. Então vou fazer a zero. Ah, então ele começou a criar aqui o a Estrutura de pastas. Ele já criou um começo da aplicação. Dá para ver aqui no pack de Jon que ele já instalou as dependências que

precisava. Então foi seguindo o desenvolvimento aqui de algumas coisas já, né? E deu interrompida aqui, provavelmente porque a gatinha tá aqui do lado, ela apertou algum botão. Eu vou dizer aqui, continue. Quiserem, Enquanto isso aproveitar para mandar mais pergunta aí no no chat. Pessoal, manda bala, tá? que daí essa parte aqui a gente vai meio que acompanhar como que o o a gente tá desenvolvendo, dá feedback para ele e e testando como que vai ficando a aplicação aí. Aí normalmente é assim que que uma onda fica pronta, eu gosto de pegar e rodar a aplicação

para dar uma olhadinha como que ela tá Para só depois eh daí sim comitar e seguir pra próxima. normalmente numa sessão nova com contexto zerado, então h acaba eh a gente tem tendo mais performance dos agentes do que continuar uma única sessão, porque à medida que ele vai enchendo o contexto, o contexto da sessão aqui, a gente vai chegando meio que nos limites de como que o de o quanto que o agente consegue Se goar na memória e ele começa a ficar começa a esquecer do do que tava no começo da conversa, coisa assim. Então

assim, o opus 4.5 ele tem recurso de compactação de de contexto. Então, quando ele vê que tá muito cheio, ele compacta, cria um resumo e a gente consegue seguir. Mas eu só uso esse recurso até terminar a onda atual. Quando vou começar uma onda nova, eu prefiro muito mais pegar, começar uma Sessão nova, zerada e implementar, pedir para ele invocar de novo a a skill e aí eh sair para aí sim começar um desenvolvimento com o contexto zado, né? Aí se ele precisar descobrir e ler como que tá o estado das coisas, muito, muito do

que já foi feito pelos outros agentes vai est registrado aqui no agent progress. Então ele vai saber mais ou menos o que que já foi feito, né, até ali. Vamos lá. O Cris mandou uma pergunta. Essa skill seria um subproduto de um dos agentes que tu criou para ti ou é um agente em si do que tu criou? Isso é uma boa pergunta, porque a gente pode eh obter o mesmo comportamento de várias formas, né? Por exemplo, se eu pegar o o texto da skill e colocar ele num comando, e aí assim todas essas ferramentas

elas suportam comandos e a Gente também pode criar comandos personalizados, né? Por exemplo, nesse caso aqui, eu tenho alguns comandos aqui, por exemplo, o comando dev spec, né? Mas eles são de um de uma outra ferramenta ali. Mas eu posso ter comandos dentro eh comandos personalizados e ele vai funcionar de boa. Ele vai adotar, vai conseguir adotar aquela, aquele comportamento, se incorporar meio que aquela persona vai funcionar bonitinho. Quando a gente Eh coloca isso como um agente, a gente consegue, nós podemos eh definir também algumas características desse agente. Então, assim, qual modelo que vai est

rodando, por exemplo, a gente pode criar a regra que o especificação sempre vai ser feita pelo Opus 4.6 de agora em diante, mas que desenvolvimento pode ser com o sonet, certo? Então vai ser, vai ter esses metadados a mais no, no agente que não tinha num comando, Mas se eu rodar o comando com o mesmo modelo, eu vou ter um eh um resultado similar. Então assim, quando, por exemplo, eu chego num cliente e eles utilizam alguma outra ferramenta, pode ser, sei lá, alguma ferramenta que é uma ferramenta mais nova e não tem todo todas as

os recursos ainda implementados, então suporta comandos, mas ainda não suporta agentes personalizados. Nesse caso, uma forma de ter o mesmo comportamento é utilizando Através de um comando. É o que eu fiz em muitos clientes já. Aí a gente tem a opção então de criar agentes ou subagentes também. Aí os subagentes são ah agentes que podem ser invocados pelo agente principal, que é esse aqui, e ele pode invocar sobre agentes que têm eh personalidades próprias, né? também é uma forma dele dar e e meio que separar um pouquinho o contexto, porque daí o um vai ser

o orquestreador principal que o orquestreador e ah, eu Vou fazer uma especificação, vai ser um agente com um contexto próprio de especificação. Só que como é um processo interativo, esse aqui não faz muito sentido ser um suaggente. Subgente faz sentido quando a gente quer algo que seja autônomo. Nesse caso aqui, ele é semiautôno, porque eu eu peço, o processo eh define que ele tem que eh explicitamente pedir eh pedir opinião humana em algumas Situações, né? Porque é importante ter o humano no loop até pra gente saber o que está acontecendo e não não vier uma

caixa preta que ele projeta. Aí quanta colocar isso como uma skill. Isso foi uma mudança recente que eu fiz, tá? Então eu peguei aqueles comandos que eu usava para incorporar persona nos agentes e transformei em skill. Por quê? Com o skill, eu consigo também incorporar scripts junto, tá? Para que Esse cinco foi a gata aqui que digitou. Eh, então assim, eu consigo através de uma skill eh incorporar scripts junto que a gente pode táar rodando. E no caso para ficar um pouco mais poderoso ainda, eu coloquei isso tudo numa estrutura de plugin. Posso até mostrar

um pouquinho por cima aqui como que isso é institutado, Mas estui de plugin permite daí que eu tenha scripts, comandos, eh hooks, do que que roda antes de commit, o que que roda antes de uma invocação de skill, posso colocar outros skills. Então, eh, nesse plugin eu tenho essas skills dev spec, mas elas são apenas algumas skills que o a gente tem em acesso. Quando a gente tiver trabalhando numa atividade de design, ele tem uma de front end, tem uma skill de hardening que é pré a Para rodar antes de abrir um por request. Então,

quando a gente pede para ele rodar um por request, ele vai fazer um processo de hardening e rodar ferramentas de segurança, gitaks, essas coisas, questões de ah tinha requis que a gente não tá atendendo, enfim, tudo isso também a gente pode usar skill de hard. Aí tem a questão de paralelização que ele vai rodar algoritmos para pegar aquelas tarefas e entender como quebrar Elas em ondas de desenvolvimento paralelizáveis e por aí vai. Então, eh, essa estrutura aqui acaba sendo bem mais poderosa, também facilita a instalação e distribuição na máquina ou na empresa, tá? Então, são

coisas bem poderosas. Isso aqui é a gatinha digitando aqui, ó. Tô tentando manter ela quietinha. Então, o que que ele tá dizendo aqui pra gente? Olha, tivemos progresso, o motor tá pronto. Ah, ou Não, ele tá dizendo que tá em progresso e os agentes estão trabalhando. Então, vou pedir para ele que eu confirme ou verifique como estão. Opa, ninguém cá, ó. tá digitando os enter aqui, atrapalhando um pouco. Então, mas ele entendeu a lógica ali, então ele tá consultando os agentes. Pra gente ver aqui no no histórico o que que ele pensou, tá com com

base naquilo lá. Olha, todos os testes da TF1 estão rodando, então, a da que é da onda zero. Então, eu posso começar rodando quatro agentes, quatro suagentes em paralelo, um para cada coisa. Então ele, quando ele lança essa tesque, ele tá lançando um subagente com instruções para ele de como que ele tem que implementar. Então ele tá dizendo, olha, você vai implementar a TESC 2, o projeto é esse aqui. Ele tá dando um contexto para esse subagente Conseguir implementar essa parte. Quais são os requisitos, o que que ele tem que implementar, mais ou menos o

a estrutura, critéri aceite. E o que que é importante? Ele vai fazer isso para cada um dos sobreagentes que tão que foram disparados ali. E aí, só que daí como ele disparou esses agentes, eles podem levar tempo, um tempo para implementar, ele de tempo em tempo tem que eh consultar como que eles estão. às vezes Acontece, e aí isso é muito mais uma questão da forma como o cloud code é implementado, de ele dizer: "Olha, estou implementando, depois eu checo, só que ele não checa sozinho, então a gente tem que vir lá de vez em

quando e diz: "Olha, dá uma olhada lá se já terminou". Isso é uma coisa que eu tô tentando incentivar e modificar um pouquinho os pumps para incentivar ele a ficar meio que num loop testando de tempo em tempo até Enquanto mais uma coisa que não resolvi 100% ainda. Então ele disse: "Olha, eh, o dois já criou tudo isso aqui. O T está quase terminando. O qu tá verificando agora os tipos. todos em estágio avançado, então tão quase lá. Quando quando terminar assim, daqui a pouquinho a gente já pode eh vou dizer assim, ó, verifique novamente

Enquanto enquanto ele termina aqui. Se vocês tiverem mais dúvidas, curiosidade, agora que eu mostrei um pouquinho da estrutura ali, talvez já tenha surgido mais alguma coisa. Ó, aparentemente todos eles terminaram com sucesso agora. Então, que que ele tá dizendo? Olha, todos eles terminaram, mas tem um conflito porque o ou a gente isso acontece quando a gente começa a paralelizar. Então é meio que um tradeof que a gente tem que acabar lidando. Se a Gente fizesse sequencialmente demora um pouco mais, mas a gente não vai cometer esse tipo de erros, então tem menos retrabalho. Então não

tenho ainda uma métrica de quanto eh de quanto mais rápido de fato tá quando isso acontece, que não é sempre. né? Mas eh vamos lá. Então agora ele conseguiu resolver aquela questão que tinha overlap de testes e ele tá registrando agora no tesk. Se a Gente olhar aqui no git, que que mudou no tasks? Cadê o tesks? N aqui que que mudou? Ele marcou para completado. Ele marcou aqui quantas estão pendentes, quantas estão completados e atualizou, ó, completadas essas tarefas aqui. Aí ele também tá a princípio vai registrar o o progresso aqui no agent progress.

E aí, a assim que ele terminar isso aqui, a Gente pode testar e comitar. Ó, o V comentou aqui: "O fato de poder paralelizar é muito bom, mas como você contela qual agente atende, qual requisito ou cloud determina isso?" É uma boa pergunta nesse caso. Eh, vamos voltar lá no arquivo de tesques, né? Ah, quando ele determinou aqui o quais tarefas podem ser paralelizadas e tudo mais, ele não, Basicamente é um layout de execução, certo? Eh, a gente não controla qual agente é o subagente. Quem toma essa decisão é o Cloud, no caso aqui o

o Opus rodando no rodando aqui com o cloud code, né? Então ele que com base nessa descrição de waves consegue, ele vai fazer um plano de como que ele vai fazer aquilo. Eu poderia, por exemplo, decidir, olha, eu prefiro fazer tudo eu mesmo aqui em Sequência, mas a forma como eu estuei a geração das tarefas incentiva ele a buscar eh rodar em paralelo comagentes para otimizar o tempo geral de integra, né? Mas quem toma essa decisão, ou seja, algoritmicamente eu já é isso aqui, né? Tem scripts lá, tem scripts eh para criar esses grafos, implementar

e montar essa estrutura lá na skill, mas na hora de executar, quem toma decisão é o agente principal aqui, que no caso é o Opus. Aí, beleza, né? Ó, vamos vamos tentar fazer o seguinte, já que ele tá eh já que ele terminou aqui uma versão, vamos ver se pelo menos compila, né? É para tá compilando, né? Ah, diz ele aqui que compilou com o TSC, então quer dizer que se eu instalar tudo aqui e rodar PNP build, deveria funcionar. Importante, o cloud normalmente quando ele roda os comandos aqui, ele roda num sandbox, Então ele

não tá rodando na minha máquina, ele tá rodando num sandbox que roda Linux. Então às vezes quando a gente trabalha em ambiente Windows, tem alguma coisinha que pode mudar, mas normalmente dá certo. Então eh acredito que se eu rodar a aplicação aqui, alguma coisa no mínimo a gente já tem, ó. Comece a digitar, mas é só um layout básico, não tem ainda uma aplicação rodando aqui. Perfeito. Então, eh, OK. Eu vou pegar aqui, vamos pegar uma imagem Top Gear SNES. pegar uma imagem de um carro do Tapig Gear e vamos colocar esse carro aqui. Vou

pegar esse aqui e vou pedir para ele colocar um fundo fundo. Deixa eu colocar aqui assim, ó. Salve a imagem numa pasta de resources. Para usar como eh carro pixel art, será necessário remover o fundo. Eh, você tem medic à disposição. Eu não sei se ele vai conseguir fazer isso, tá? É só para pensar, porque senão depois a gente eu peço para ele gerar um, mas se ele conseguir usar esse carrinho aqui, vai ser legal. Então eu vou deixar ele Rodando aqui. Vamos ver esse médio aqui é uma ferramenta de celar que eu tenho para

edição de imagem, tipo um Photoshop via linha de comando. Então se ele conseguir fazer isso aqui é legal porque a gente consegue usar depois esse carrinho do Top Gear no jogo. Então eh tá rodando. E aqui eu vou dizer para ele pode comitar. O legal de normalmente quando eles comitam, bom, se bem que aqui ele não colocou, né? Mas a gente pode criar uma Regra depois para ele e sempre comitar usando eh git conventions, né? Inclusive eu não coloquei isso na skill, mas a gente porque isso muda muito de empresa para empresa, qual que é

o padrão? Então, normalmente é uma regra do repositório. OK. Ele vai fazer o commit aqui. Vou pegar um segundo agente aqui e a gente Pode ir, acredito, para onda dois, né? Então vamos lá. a wave 2 eh que deve masc é essa daqui. Vocês podem ver que eu tô rodando com o modo bypass permissions, que é aquele que ele não pede, é, ele não pede permissão para fazer as coisas, porque nesse processo aqui com essa skill, eu confio e e o modelo do Opus é, eu confio bastante nele, pele não fazer besteira. Eu não rodava

com Nesse modo até o Cloud 4. Então na época no no começo do ano passado, quando eu tinha o Cloud Son 3.7 7. Hum. Não era uma boa ideia rodar com bypass ativado, porque a tendência dele fazer besteira era grande, principalmente quando eu começava dar erro, o modelo começava a ficar desesperado, ele tinha uma crise existencial e começava a pagar coisa e refazer, então já mais retalho. Então tá, enquanto ele vai implementando aí vamos seguir, vamos ver o que que o Chris mandou de pergunta. Então, é possível ter algo próximo disso, exclusivamente com os agentes

nativos do Google Antigaravity. Digo, trabalhar no formato spec Driven. Se sim, já experimentou. E os resultados? Olha, H, sim. naquele formato que eu comentei antes, assim, porque o o daí o o que que tu faz pro agente padrão do antigravity eh Incorporar esse processo de spec driven? Tu precisa ter um comando que explica, como que eu vou dizer assim, um um comando cujo conteúdo é a descrição de todo o processo de especificação que ele precisa fazer. Isso pode ser um comando tipo barra spec ou barra arquiteto ou alguma coisa assim. E aí esse comando delineia

todo o processo que tem que ser seguido, tá? E aí, dependendo do modelo, É modelos, é bem baratinhos, tipo o Haiku 4.5 ali do Cloud, ele não consegue seguir. Ah, se tentar rodar esse processo com ele, ele não dá conta, então ele começa a cometer erros e tudo mais, porque é um um modelo menor, né? Ele não não é tipo, é é um processo muito complexo para ele conseguir seguir com qualidade, então tem que ser um modelo mais caro. Agora, através de um comando, tu consegue rodar em qualquer ferramenta, tá? Em qualquer ideia. Eu Usava

a mesma abordagem no augment, no antigravity, no com o cloud no começo, até antes de transformar em skills e tal. E no cursor todos eles funcionam. esse eh esse processo, inclusive eh mostrei aqui no repositório. Hoje eu tenho esse plugin aqui, certo? Que eu mostrei para vocês, mas a versão original dele não é plugin. A versão original deles é um comandos, tá? em comandos com mais ou menos o mesmo conteúdo. Então eu Fui refinando ao longo do tempo, pegando inspiração de vários lugares, ideias de como melhorar o processo, muito teste, ah, feedback de clientes e

tudo mais para ir refinando. E muitas vezes esses processos são meio que processo da da empresa que tu trabalha tem coisas específicas que tu vai querer adaptar, né? Eh, mas tu consegue pegar o todo o processo e ah incorporar ele aí num comando. Então, o que que aconte? Que que ele tá fazendo agora? Ele viu, opa, tem um monte de coisa que dá para paralizar. Ele começou aqui, ó, agente quatro, um agente, outro agente, outro agente, um monte de agentes em paralelo. E agora ele tá deixando eles trabalhar. Enquanto eles trabalham um pouquinho, deixa eu

fazer um desenho aqui no Scal Draw para mostrar um negócio para vocês. Imagina o seguinte, a gente tem o processo, Ah, vamos dizer assim, o processo de desenvolvimento. Vou colocar aqui o processo de especificação, certo? E aí a gente tem o processo de desenvolvimento. Dier, eu tô separando isso aqui porque muitas vezes isso vai acontecer em momentos diferentes. No processo de especificação, essa primeira fase aqui pode muito bem assim no eu acho que um fluxo legal para Trabalhar com agentes é gerar um por request, tá? Então o resultado disso aqui seria um pull request, porque

é importante que o time avalie e refine esse essa especificação, dê feedback e tudo mais. Quando a especificação tá realmente redonda, aí a gente tá pronto para delegar para um agente de desenvolvimento, tá? E aí depois do desenvolvimento a gente vai ter um novo por request. Então assim, seria um um processo um pouquinho diferente. Eh, ah, mas eu tenho mais e mais coisas que mais tipo mais processo que antes? Depende. Muitas vezes esse desenvolvimento aqui, quando as ferramentas tiverem bem ah bem calibradas, principalmente pra realidade da empresa, o repositório, os repositórios, por exemplo, estão super

bem contextualizados com regras e tudo mais, esse desenvolvimento aqui, ele pode muito bem a gente conseguir fazer o One shot até talvez autonom rodando em pipeline ou coisa assim, com um gatilho, tipo, ah, Veio, foi aprovado esse por request. Fez merge na fez um um merge na main. Beleza. A ferramenta pode identificar que tem uma spec nova e subir um branch, colocar agente para rodar naquele branch automaticamente e já abriu outro por request automático. Por request, primeiro code review via Agentes também. E aí os humanos só dão OK no final. Então, é um é uma

forma, mas essa eh essa etapa aqui de abrir um por request para especificação é cada vez mais importante à medida que a gente vai incorporando mais e mais agentes no processo de desenvolvimento. E aí vamos só voltar aqui ver assim o cheque os agentes. Enquanto isso, eh, aí deixa eu ver uma coisa aqui. A gente tem um processo, eu coloquei ele como vertical, Porque todas as atividades que a gente vai fazer aqui durante a especificação são abordadas por, pode ser um comando de especificação ou pode ser uma skill de especificação, certo? Mas a gente também

pode ter uma série de skills, por exemplo, que são ortogonais, que eh a gente pode usar em todos os casos. Então, um exemplo, eh, por exemplo, Front skill, tá? Então, aqui o que que pode ter no frontic skill? Eh, boas práticas, hã, guia de layout, eh, comportamento, enfim, um monte de coisas sobre eh front change, a questão de skill, eh, de testes, por exemplo, posso ter uma skill de testes de mutação, cara. Eh, se fizer sentido projeto também, Como implementar e tudo mais. Essas skills que elas são ortogonais, elas podem ser usadas em qualquer momento

por qualquer um desses agentes, só que talvez de formas diferentes. Por exemplo, eh, o agente de especificação vai vai ver, opa, eu tô planejando a UI de um produto, ele vou carregar a skill de front end. lá dentro vai ter informação dele de como especificar certos requisitos não funcionais, por exemplo, Na especificação já o de desenvolvimento vai conseguir usar essa mesma skill, muito provavelmente para eh implementar eh seguindo aqueles padrões, né? Então, se eu colocar na prática, voltar aqui, então, eh, algumas delas já estão prontas. Algumas delas estão em andamento e depois falta integral. Então

ele tá fazendo aquele processo de compactação Que eu comentei. Eh, quando o contexto começa a se aproximar muito do limite do modelo, ele faz um processo de compactação, onde que ele pega toda essa conversa aqui, ele vai fazer um resumo. Nesse resumo, ele vai colocar, por exemplo, assim, ó, qual que é o objetivo e qual que é o estado atual das coisas para poder daí continuar a conversa como se fosse, tipo, da forma mais natural possível. Mas a partir do momento que ele compacta, aqui ele tem um resumo da Compactação. Eh, mas a partir do

momento que ele compacta, esse é isso aqui que ele enxerga daqui para baixo. A gente, como nós como usuários, a gente consegue ver o resto da conversa, mas ele já não enxerga mais daqui para cima, ele enxerga daqui para baixo, né? Então isso impacta um pouco. Então assim, não é legal pegar e continuar outras ondas a partir daqui. Vou só deixar ele terminar a onda que já tava Implementando. Então assim, ele terminou, aí ele vai checar o estado agora se tem alguma coisa para arrumar. E daí a gente pode completar a segunda onda e partir

pra terceira onda que tem essa parte das métricas. É, e tela de resultado, mas eu acredito que talvez até já tenha alguma coisa jogável aqui nesse ponto da onda do Aí a gente já vai descobrir. quiserem aproveitar também para mandar Mais curiosidades ou ou dica, podem mandar aí no chat, tá? Ah, esse processo todo que eu tô mostrando para vocês, a gente pode ver que eu já tenho 327 pass e testes, né, no projeto. Aí a gente nem chegou a olhar os testes, né? Será que a gente precisa ficar tão de olho? Eh, assim, a

minha opinião é que cada vez menos a gente vai ficar de olho no Código, tá? Eh, é importante sim de vez em quando dar uma olhada, talvez isso, principalmente no momento do code review, dá uma boa olhada no que que foi implementado e tal, mas cada vez mais e assim isso é uma tendência de mercado, a especificação ficar no centro, até porque quando o processo de desenvolvimento da empresa todo começa a ser automatizado, a gente tem um montão de agente rodando, A coisa vai ficar tão rápido é que não tem como a gente ficar acompanhando

a quantidade de código que é a gera. não vai ter tempo hábil para acompanhar o código, mas a gente consegue acompanhar a especificação. Então, se a especificação captura bem a intenção do que que tá sendo desenvolvida, eh, a gente mantém, acho que um assim uma boa ideia de para onde as coisas estão indo, mas a tendência é no futuro vai ter Tanto código sendo gerado por IA, que a gente não vai dar conta de eh em continuar conhecendo o código. eh no nível de detalhe que a gente conhecia antes. Aí é o o Robson comentou

ali no no chat que se vai ficar, né? Eu vou deixar Aberto depois essa essa gravação lá no canal aí vai ficar disponível. Eh, posso aproveitar também para comentar, né, que esses esse processo todo e mais um bom tanto de coisa, eu disponibilizo também como eh treinamento, né? Então, eu já fiz no ano passado alguns workshops onde que a gente passa por esse processo aqui. Era uma versão assim um pouco eh não tão madura quanto a gente tem agora no começo de 2026, né? Mas eu pretendo Fazer novamente esse ano alguns workshops abertos ao público,

né? Então vai ter um gratuito e depois um um mais aprofundado pago. E eu também tenho treinamento que são para as empresas. E aí esses treinamentos, a eu tenho um miniurso que a empresa recebe umas duas semanas antes para anvelar todo mundo. E aí tem um dia de workshop bem legal assim com dinâmicas de prototipação e tudo mais, colocando Isso aqui na prática na realidade da empresa. Então, criando protótipos e saindo já às vezes com coisas engatilhadas dali do do treinamento. Então, eh, se vocês conhecerem alguém que tem um, assim, necessidade de ou tá com

dificuldade de adotar a no trabalho, vocês podem aproveitar para eh tá indicando meu trabalho. Aí, vamos ver que o Volnei comentou também que na criação de agentes ou em Consultorias, todas essas skills podem levar em consideração linguagem, decisões de arquitetura, tecnologia, softwares a serem utilizados, etc. são levados em conta. Sim, quando eh eu tenho o agente básico e aí nos processos de consulta aí a gente refina eles pra realidade de cada empresa. Então, por exemplo, a as skills, por exemplo, quando é uma skill de desenvolvimento e a empresa trabalha com uma linguagem de Programação que

não é muito bem dominada por agentes, por exemplo, ah, uma versão antiga de C++ ou alguma coisa assim, a gente pode eh embutir na skill um LSP da linguagem, que é um um servidor de linguagem, ah, por exemplo, daquela versão de ser mais e com isso fazer o agente saber trabalhar e ter feedback em tempo em tempo real do código que ele tá desenvolvendo. Então isso é uma possibilidade hoje em dia. Eh, assim, Cada empresa vai precisar às vezes de ferramentas, eu construir servidores MCP próprios pra realidade da empresa, né? Eh, exemplo, tem empresas que

trabalham ainda com aplicações de desktop. Quando a gente faz teste de com a gente, normalmente a gente usa em aplicação de browser, normalmente a gente usa algum tipo de de ferramenta de controle de browser, como o playrite ou dev tools. Agora, quando é pra Desktop, a princípio de meu conhecimento, não tem de mercado um servidor MCP pronto, mas tu pode construir um próprio que roda ferramentas como o apion, por exemplo, para controlar o aplicativo desktop e fazer e simular as mesmas operações, tipo dia print screen, abrir tela, clicar em coisa, ler conteúdo em um aplicativo

desktop. Então sempre tem essa necessidade, a gente constrói junto ferramentas assim para adaptar pra Realidade da empresa, né? Mas em cada empresa, no fim das contas, vai ter meio que um assim um conjunto de ferramentas e assim envolve a forma como constrói contexto, então forme talvez a forma como se disponibiliza contexto naquela etapa de especificação vai ser um pouco único de cada empresa. Aqui eu tenho, por exemplo, ele vai fazer pesquisa externa com perplex, mas às vezes tem outros sistemas dentro da empresa que precisam ser Contextualizados. a gente pode ter o cenário em que ah

ou o sistema não tinha documentação e a gente precisa primeiro passar a a criar a documentação, eh, fazer tipo uma engenharia reversa do sistema para gerar a documentação do que não tinha, inferir regras de negócio de legado. Cada cada caso vai ser um caso, né? Eh, ó, a Wave 2 diz ali que tá concluída, então vamos dar uma olhada como que está até agora Esse amigo aí. Ei, ó. Bom, parece que tá ficando. Agora vou vou vou digitar bem devagarinho. Podia tá tudo errado, tá? Beleza, ele vamos ver aqui. Eh, ele não tá desacelerando muito,

né? Ah, bom, depois de um tempo ele parou. É porque talvez porque deu o tempo. Deixa eu colocar, deixa eu dar um F5 aqui. Vou colocar 15 segundos e vamos Lá. Olha só, a pista sumiu, né? Acabei de ver aqui. A gente pode dizer para ele. Sociedade moderna, as pessoas. Tá. Então eu vou colocar aqui a pista sumiu depois de um. Pera aí. Pista antes. Pista depois. tirar esses dois, esses dois prints aqui, mandar pra gente eh fazer assim, ó. Pode comitar e na sequência corrija esse bug. Ah, depois de alguns segundos, a pista está

sumindo. Colocar a foto que tinha pista e a foto que não tinha pista. Eh, deixa eu ver. Vem mandou mais uma pergunta aí, ó. É possível também ter skill de segurança da informação, como por exemplo, sistema bancário, financeiro, ou melhor ter skills existentes. Pera aí, ou melhor, os skills existentes poderem ser constituídos com essa Preocupação? E sim, ah, as duas coisas são possíveis. Ah, o que que eu tenho trabalhado aqui, tá? Então, deixa eu voltar lá pro plugin. Hoje eu tenho uma skill sepai para isso. Então, uma que eu chamo de hardening. Então, o hardening

vai ter algumas questões. É, ele vai olhar questões de segurança, tipo análise de dependências e se tem e bibliotecas que precisam ser atualizadas, vazamento secret, SAST, a integridade aí, algumas questões de qualidade, tipo integridade dos testes, tá tudo passando, tá tudo bonitinho, qualidade do código, rodolint, tudo bonito, e a formato de commit e do branch. Então, daí tem exemplos para várias linguagens aqui, mas aí pode ser adaptado, por exemplo, para com exemplos específicos da linguagem que tu trabalha, né? Mas a ideia é que ele seja meio que genérico com os princípios de do que que

tu Deveria checar sempre antes de abrir um por request. Então, eh, um pouco assim nessa linha, eh, quanto a colocar direto no agente, o problema é a gente, é causar uma sobrecarga cognitiva no modelo. Então, ah, como assim uma sobrecarga cognitiva? Imagina o seguinte, você vai nem começou a atividade ainda e aí tu chega com um arquivo de 2000 linhas com todos os detalhes que tu tem que seguir e tal e Tu nem começou ainda. Aí depois tu tem que lembrar de todos esses detalhes e conseguir executar em cima deles. Qual que é a probabilidade

de o processo ser eh executado pela metade ou ficar algum detalhe faltando ou por aí vai, né? é alta. Então assim, eh isso pode acontecer por uma série de motivos, né? Pode ser que o contexto do agente tá enchendo e aí ele começa a degradar performance. Pode ser que o modelo simplesmente não é tão bom Em seguir instituições, né? Um exemplo disso é o os modelos da linha GPT 5, né? do cinco em diante, eles são os melhores de todos em termos de seguir regras a risca. Então, se tu colocar um algoritmo para ele seguir

assim, ó, o passo a passo do processo, ele segue impecavelmente, mas ele não é necessariamente o melhor modelo para programação. Aí o opos já é o oposto, ele é excelente para programação e ele é bem Versátil, então ele tem um raciocínio bom, consegue tomar boas decisões, mas ele não é tão bom quanto o GPT5 para seguir instituições a risca. Então assim, apesar de ter o processo aqui definido, se eu começo a colocar detalhes demais nesses processos, ele começa em algum momento a gente vai se perder e alguma coisa vai ficar pelo meio do caminho, né?

Então essa é uma outra eh uma outra questão que pode acontecer. Eh, então assim, eu tento, eu tenho definido um budget de tokens até onde que eu tô disposto a gastar token carregando aquela skill pro processo, certo? Que no meu caso ali é mais ou menos 10.000 tokens, tá? Então assim, se o contexto é 200.000 tokens, eu tô gastando 5% só para carregar a skill. Mas eu tô considerando que esses 5% são eh valiosos porque eles vão trazer todas essas boas práticas, né? Aí Eh se eu provavelmente assim eu preciso já desde o começo tratar

isso ou basta depois eu fazer mais uma sessão com a gente e usar uma outra skill, por exemplo, de hardening ou segurança para fazer uma checagem. Isso pode ser feito automaticamente também no por request, rodando em pipeline. Eh, pode ser aberto um por request de correção dessas questões já automaticamente, enfim, inúmeras formas que pode Acontecer, né? Vamos ver se resolveu a questão aqui. Ah, continua com Deixa eu, deixa eu ver se é a cash. Olha, parece que não tá mais sumindo a esteada. Só que eu não vi blur, né? Eu não sei se é para

ter implementado o blur aqui, mas eu não vi o blur ainda. Mas eu vou dizer assim, ó. Pode comitar a correção. E aí eu vou começar uma sessão nova, vou pedir para ele Implementar e depois se tiver detalhes faltando, vou a gente dá feedback daí pro agente ali. Vamos pra próxima onda que é a onda três, né? E é ah, o sistema de turbo, essas coisas que eu acho que o blur é no sistema de turbo, né? Então vamos lá. Você já implementou ali implementar wave 3 Da spec board rider. Não, mas eu nem vou

dizer para ele usar a skill. Vamos ver se ele carrega bonitinho aqui. Aí vocês podem ver que assim, ah, depois da especificação, os meus promps parece que ficaram preguiçosos, porque eu só digo assim: "Ah, agora implementa a onda tal, agora implementa a onda tal". Eh, a gente pode dar quanto contexto quiser Pro agente, mas como o processo de execução já tá embarcado ali na skill, acaba não sendo tão necessário, a menos que a gente quer que ele aja diferente por algum motivo, né? Ou quiser dar um detalhe, tipo assim, ah, implementa a onda três, mas

deixa a tarefa oito por último, porque, sei lá, não não é tão importante, né? Então, a o pting aqui dessa parte acaba sendo um Pouco mais simples. É mais a questão de a gente acompanhar e entender ah se a o a forma como que o modelo tá seguindo tá fazendo sentido. Nem sempre vocês vão estar usando talvez o Opus. Aí eu não sei, depende muito do plano. O Opus consome bastante crédito, né? Inclusive, vamos ver que se quanto crédito que eu tenho ainda aqui, ó. Cloud, eh, ele tem janelas de 5 horas de uso, né?

Então, eu posso bater o rate limite desse momento aqui. Então, ele tá Dizendo aqui, olha, para essa sessão, eu tô com 64% e eu só usei o Opos desde o começo. Eu tô com que Ah, mas que plano que você tá usando, Diego? que eu tô usando o plano de $ cloud code atualmente. Eh, porque pro meu nível de uso normalmente é suficiente para uma sessão. Raramente eu bato os 100% numa janela de 5 horas. Quando acontece é quando eu tô fazendo muita coisa, eu Tô querendo rodar dois processos desse em paralelo, trabalhando em coisas

separadas, por exemplo, coisa assim. E daí realmente eu tô abusando, vamos dizer assim, dos limites, né? Mas eh normalmente dá para trabalhar com o Opus o o dia todo tranquilamente, se tiver seguindo nesse processo aqui a de spec driving com os agentes do jeito que eu tô trabalhando hoje. Então, eh, Acho que funciona bem. Quero aproveitar, alguém tem, quer aproveitar mais uma, mandar mais alguma dúvida, porque daí eu posso ir respondendo aqui enquanto ele implementa essa fase, essa onda três e a gente vê depois o essa parte das métricas e tudo bonitinho. Aí mandem aí.

Eh, interessante também mencionar, né? Eh, aqui eu tô trabalhando com o cloud code No na extensão, mas eu poderia estar trabalhando com o mesmo processo aqui pelo terminal. Acontece que eu gosto dessa interface, né? Mas eu também posso configurar um processo semelhante, vamos supor que a empresa não queira contratar o cloud code, né, por algum motivo ou para economizar em questão de token, né, tem empresas que vão preferir, por exemplo, contratar eh ou definir um budget para de tokens Pro time e utilizar Open Houter, por exemplo. Aí, não sei se todo mundo conhece, mas Open

é uma plataforma de roteamento de modelos de LLM. Então, tu tem uma IP aqui do do Open Houter, eh, tu tem praticamente todos os modelos aqui. Então, ah, eu quero usar o Opus 4. Tem, quero usar um modelo opence como o Kim 2.5 que saiu agora é semana passada. Tenho ou outro modelo Open Search, que é O GLM 4.7. Esses dois são os dois melhores modelos open para programação hoje em dia. Tenho quero geminar e três flash, por exemplo. Eu quero ter eh acesso a todos esses modelos do para usar no dia a dia. Com

o cloud code sem fazer gambiarra, não tem. Ele ele tem um a gente cai num cenário de loquin nos modelos de Anteopic, né, que é são esses modelos aqui, né, Son, o Haiku e o Opus, Basicamente. Então assim, ah, eu quero ter liberdade de escolha de modelos, porque a gente pode vir a escolher um modelo mais barato. Por exemplo, eu quero pegar o GLM 4.7 7 e eu quero poder, por exemplo, eh, escolher o provedor de inferência, que é a empresa que roda o modelo, né, com base em alguma prioridade. Por exemplo, eu quero priorizar

triput, quantos tokens por segundo vai vir? Porque isso vai afetar a velocidade do Meu time. Então, eu quero a velocidade mais alta possível. Que que eu posso fazer? Eu posso configurar uma política no Open Houter para ele priorizar velocidade. Então, se eu priorizar o TPUT, o que que vai acontecer? Tem um um uma empresa de inferência que é CBAS que eles têm um triput absurdo, porque eles não usam GPUs da Nvidia para fazer inferência, eles têm chipes gigantes próprios feitos Sob medida pré inferência de LLM. Cara, é um pouco mais caro do que outros modelos.

A gente pode ver que o mesmo modelo servido por outros provedores às vezes tem preços aqui, ó, 45 centavos de dólar por milhão de tokens de entrada, dois de saída, mas não tem cash. Isso quer dizer que todos o todos os tokens de entrada, inclusive aqueles que forem repetidos entre uma sessão e outra, nunca vão ter cash, não vão ter desconto. Alguns têm desconto naquilo que cai em cash, então a 60, mas tudo aquilo que for repetido, desconto. Alguns tm cash, alguns não tm cash, alguns tm promoção. Tu pode priorizar velocidade, tu pode priorizar, eu

quero mais barato. Aí mesmo sabendo que às vezes o mais barato não é necessariamente melhor, ou eu quero usar eh latência. E aí é o tempo, é o tempo de resposta que leva até ele começar a Responder, né? e enfim, eh, todos esses a gente e aí se você quiser eu configurar essas políticas aí você pode usar outras ferramentas, como por exemplo o Open Code. Aí o Open Code ele vai ser muito semelhante em termos de capacidade, né? a instrumentação dele é bem semelhante ao que o Cloud Code FS, só que com um nível de

personalização bem alto e podendo conectar com qualquer Provedor. Inclusive ele permite fazer login com as contas de assinatura que tu tem. Se tu tem, por exemplo, a assinatura do chat GPT, tu pode fazer o login da Openi. Aqui, ele vai abrir a telinha do navegador para te logar com o login da Openi. E tu pode usar aqueles recursos, ah, de assinatura de 20, de 50. aqui. Aí eu tenho hã o danop que não funciona isso porque eles são concorrentes, então eles deixaram de for propósito, mas tu pode Configurar também aqui um uma chave do um

login do Open Houter, configurar a política lá e todos os modelos que tu tiver disponível no Open Houter vão estar disponíveis aqui através do operador aqui do Openouter. Então aqui tu tem um monte de liberdade de modelos para escolher, inclusive os promocionais que estão gratuitos, né? Às vezes aparece, por exemplo, algum alguma empresa vai eh tá testando um modelo novo, tipo, ah, eles lançam o modelo com Codome, daí ele é um modelo stealth e deixam gratuito para pegar, para coletar dados. Então você pode usar gratuitamente, às vezes põe uma semana, duas, um modelo ou pode

escolher um modelo que tá e com bom custo benefício naquele mês. Então isso é possível de fazer com Open Code. E da mesma forma que eu comentei da P, eu configurar skills sub agentes, inclusive as skills do cloud hoje elas são eh compatíveis entre si com outras Ferramentas, porque o modelo de skills eh vê opence e gente skills. Isso vi opence. Então, começou com a com anteop lançando no cloud code e depois veio padarce. Então, todas essas ferramentas aqui hoje são compatíveis com skill. Se você implementar a skill uma vez, tu pode usar ela independente

da ferramenta que o pessoal tá usando na empresa. Ah, aqui a gente usa H code, não faz mal. a Mesma, a mesma skill que funciona no Rod, se ela tiver implementada de acordo com a spec, vai funcionar também no cloud, vai funcionar no Codex do Peni, vai funcionar no cursor, enfim. Eh, aí é legal que tu tem essa portabilidade, vamos dizer assim, né, das skills. Fechar aqui, ó. Ele tá terminando aqui aqui a quase terminando a parte Final. Aí o Cris mandou uma pergunta aqui. Como você planeja o uso dos tokens, no caso o budget

por feature do projeto ou por projeto? Tem como dimensionar com base na demanda de antemão? de antemão. Acho difícil, porque a menos que tiver um um processo muito rígido, né? Ah, por exemplo, tu tu teria que contabilizar, por exemplo, quanto que tu vai Se permitir colocar de contexto inicial nesse para gerar esse processo de especificação aqui. Então, por exemplo, se tu pegar a transcrição de uma reunião do time de uma hora de duração, facilmente tu vai chegar com um contexto de 50.000 1000 tokens, se for uma hora de transcrição de pessoa conversando. Então, tu já

foi um monte de token só ali. Aí tu tem talvez uma etapa de Pesquisa que tu pode deixar desligar isso se tu não quiser para ser mais previsível, mas quando for quando for fazer vai ter é um processo dinâmico que acontece, certo? Então assim, eh, prever de antemão, eu imagino que a partir do momento que tu tiver um histórico. E aí eu acho que assim, antes de começar a rodar o processo, não tem como, mas depois se tu tiver um Histórico, tu pode provavelmente conseguir chegar na conclusão de que no geral a gente utiliza até,

tipo, em média 5 milhões de tokens por feature, alguma coisa do tipo, né? Mas até tu começar a rodar esse processo e sentir, eu acho que não tem como, não tem como ter que fazer uma um processo de discovery antes e testes para chegar nessa conclusão. Vamos ver. Deve est quase quase Eh terminando aqui. Deixa eu matar esse cara aqui. Ol, ele tá vendo agora se ele tá conseguindo rodar. Mas a princípio agora a gente já tem 400 testes, tudo compilando bonitinho. Vamos ver nós aqui se esse rodo da gente pode até dizer para ele,

olha, tá funcionando. Eh, OK. Ah, como ó, agora tem a velocidade ali, ó. essencial para o desenvolvimento de qualquer cedade moderna. Pessoas precisam, meu Deus, trocar informações de maneiraar. Olha só, temos métricas. Olha, ficou bonito isso aqui. Ai, aí tem até um um negocinho de configuração aqui, ó. Sons. Pessoal, sabe o que eu não sei agora? Deixa eu ver se tem som aqui. [música] Ei, eu não ouvi nenhum som. Ele tem o objetivo pro turbo. Eu vou colocar menos aqui para eu conseguir fazer mais fácil. Vou pra próxima. A comunicação é essencial para o desenvolvimento.

Eu não vi turbo e sumiu. Nó tá com uns Bugzinhos aqui ainda, mas estamos seguindo. Ó, o quem que fácil ficou ficou massa. Olha. Inclusive, esse carrinho aqui, ele desenhou com pixel art conta própria, né? Eh, vamos ver que que deu o tempo. Tem a estatística e a gente pode até colocar o feedback aqui que a estrada sumiu por algum motivo, né? E eu não tô vendo o blur. Então vou fazer assim, ó. Eh, a ele tá tentando testar aqui, tá? Ele abriu o navegador para testar e aí só que ele não consegue digitar rápido,

né? Ele digitou o A. Aí depois agora eu vou apertar espaço, depois eu vou digitar comunicação. Eh, bom, funciona, né? Ele viu que abriu a aplicação e tal, então, OK. Eu vou dizer para ele aqui, ó. pode comitar. E na sequência, Eh, temos alguns bugs para corrigir. Para ir finalizando aqui, eh, a estrada sumiu de novo. Colocar aqui. Não vemos blur. A estrada sumiu de novo. É, não vimos blur durante a o turbo. OK. Eh, estamos numa live importante funcionar. Ai, ai. Foi hoje que saiu o Opus 4. Foi. Não, mas fez um som antes,

não foi o som do aqui do do teste do Windows. Ah, é. E também não parece está funcionando os sons. A pé ele aí. Bom, acho que daqui a pouquinho a gente já tá encaminhando pro final da live. Eh, quiserem aproveitar para mandar mais algumas perguntas. Eh, o O Opus 4.6 tá, Luciana, ele saiu agora ali pelas 4 da tarde, eu vi, tá? Foi hoje à tarde. E aparentemente eles lançaram mais coisas também que eu não cheguei a ter tempo de ver ainda que eu tava me preparando aqui. Mas o Sonet 5 deve est saindo

por volta dessa semana. E acho que também vai ser assim um ganho de performance eh bem grande aí. Daqui a pouquinho deve ter. É, o 5.3 também saiu. Geralmente isso acontece a porque como estão todos competindo essas empresas de A, né, eles acabam lançando quando eh esperando alguém lançar alguma coisa e já tem engatilhado algo para meio que tentar fazer um contra-ataque, né? Então assim, ah, lançaram o o Opus 4.3, vamos lançar o o GPT 5.3 no mesmo dia ou alguma ferramenta para tentar tirar a atenção do concorrente, né? Então, geralmente quando tem o Lançamento

é festa para quem gosta de acompanhar a novidade, né? Aí, eh, tem o app do Codex também que saiu essa semana ali, que é um, ah, que também parece que tá ficando bem legal com gerenciamento multiagente e tudo mais, né? Vamos ver o que que ele disse aqui quanto ao áudio. Bug um. Ah. Ah, Ele deveria, OK, então ele deveria ficar jogando para cima. O turbo tá faltando componente e o áudio, hum, ele chegou a implementar, mas faltou fazer as chamadas, então realmente tinha alguns bugs. Aí beleza. Tem um outro agente que eu tô trabalhando

para refinar, que é para fazer às vezes de um agente de um agente De qualidade. Então, como que funciona esse cara? Com base na especificação e nos requisitos, ele vai saber o que que precisa ser testado. Então ele começa construindo um plano de testes e depois tendo ferramentas para implementar eh implementar esses testes, sendo seja via testes end to end, ah, ou outras ferramentas que tiver disposição para checar e garantir que tudo que saiu Do processo de desenvolvimento tá redondo. Então isso é uma questão que eu tô trabalhando também para incorporar de forma mais natural

dentro do processo aqui. Aí, mas acho que é isso. Então, ele tá corrigindo aqui essas questões. Acho que ele tá abrindo aqui para ver se vai tá bem devagar. Vamos, vamos rodar mais uma vez aqui para ver como Que ficou. Ele tá rodando ainda aqui. Ah, agora tem som. Vocês estão ouvindo? Colocar aqui para 30. [música] >> [música] >> Tá, só não vi o blur, [risadas] mas isso é um um detalhe ainda. Mas talvez ele tá arrumando ainda e deveria ficar borrado. Mas até até um efeito neon aqui. Acabei de ver aqui, ó. Eu não

tinha visto que tinha um neon aqui, ó. É bom, mas eu acho que eu que eu tinha planejado para live de hoje para mostrar aqui para vocês, é, eh, ah, isso aqui a gente tem praticamente pronto o jogo, né? Eu acho que talvez tinha uma fase quatro aqui que é para salvar persistência histórico, tipo um ranking, mas acho que não é tão crítico assim. O jogo já tá funcionando. E acho que deu para mostrar como que a Gente trabalha com Spect Driving Development, tem diferentes ferramentas, é possível construir os próprios. E como eu tinha comentado,

eu tenho esse eu também como serviço de consultoria e treinamentos, né? Ah, para as empresas que estão buscando trazer esse conhecimento para dentro. Então, se vocês tiverem também a indicações, podem podem me indicar aí que a gente tem que espalhar isso, acho, né? É um processo. Eu gostaria também de pedir para vocês, se vocês puderem mandar aí no chat, o que que vocês acharam, tá, desse processo, se vocês acham que é promissor, se gostariam de aplicar e testar aí na realidade de vocês. Acho que eu vou gostar de ver o que que vocês têm, a

qual a opinião de vocês sobre isso. Enquanto isso, então vou pedir para ele aqui, ó, só para finalizar aqui, ó, Commit e ehemente a última tarefa. É, ó, o V mandou mandou mensagem aí que foi muito massa mesmo. Vamos conversar com certeza, Vi. Eh, ô Cris, ó, já tô com várias abas. Quebasse o resto dos meus preconceitos. [risadas] Eu falei para ti com isso, que e não ia Doar isso aí, tá? Se tu tivesse me convidado para ir na tua casa aí, a gente já tinha matado isso bem mais cedo. Ai, ai. Mas vamos chegar

lá. É, geralmente quando eu mostro esse processo assim para quando eu chego num é bem comum chegar nas empresas e a postura da empresa é assim, A gente a gente contatou o cursor aqui Para todo mundo. A gente espera agora que eles desenvolvam mais rápido, né? Entreguem mais. A gente vai passar a cobrar mais a partir de agora. E e cara, é não é só assim, né? Tô só vai chegar até um certo ponto. Sem metodologia não tem como. Acho que essa é a conclusão. Sem metodologia não tem como tu ter um ganho real. de

assim, tu não vai tá fazendo engenharia de software de verdade, Assim, é bem mais complicado. Então, e a gente tem que fugir sim do vibe coding porque o não gera resultados legais, né? Então assim, sendo spec driven development ou uma outra metodologia, importante é ter um processo bem estruturado, com certeza para usar o futuro depende assim, eh, depende de repensar processos, tá? Então, repensar processos é o mais importante. Não adianta, não vai, a gente não vai Conseguir continuar trabalhando num modelo clássico que a gente trabalhava. Assim, a pressão para automatizar as coisas e para acelerar

vai ser cada vez maior. E aí essa pressão vem de vários eh de vários lados, né, de dentro da própria empresa que quer acelear. E eh às vezes é tô aí querendo resultados mais rápidos, mas também da competição do mercado, porque enquanto enquanto a empresa tá desenvolvendo ali às vezes do Mesmo jeito que já fazia há 10 anos, o a startup aqui do vizinho ou às vezes assim, ó, empresas, a gente vai ver começar a ver cada vez mais empresas de uma pessoa só ou pequenos times, o cara voando, né? Então assim, necessariamente todo mundo

vai ter que rever seus processos de desenvolvimento e para conseguir acompanhar a velocidade como que as coisas estão mudando. Não tem muito como escapar. Então, estamos quase chegando no finalzinho da implementação aqui, onde que a gente vai ter eh onde que a gente vai ter daí essa parte de persistência também no jogo. Então, vamos lá. O Cris mandou mais uma pergunta no finalzinho aqui, mas surgiu agora. Como tu lida com um projeto que já tem bastante coisa e precisa injetar esse processo? Muda algo? Porque aqui o rep estava vazio nesse exemplo. É claro que eu

comecei esse um projeto vazio Aqui pra gente não ter o overhead e ter que explicar uma base de código que talvez não é relevante pra maioria. Aí o que que acontece quando a gente trabalha com brownfield, né, que é eh sistemas que estão em produção, rodando e tal. Então eu tenho clientes que t esse cenário, sistema antigo, sistema legado, sistema, é, sei lá, repositório com 15 milhões de linha de código. Então, o que que é importante eh de ver nesses Casos? O agente, imagina assim, se a gente começa com o agente padrão, uma ferramenta qualquer,

cursor ou cloud code e chega com a especificação tipo da tarefa como ela tá no gir, normalmente elas não estão especificadas com contexto suficiente para um agente conseguir entender o que que ele vai tá lidando e qual é o contexto histórico daquele sistema e tudo mais. Então, na hora do Desenvolvimento, a consequência disso vai ser um desenvolvimento assim, ah, com alguns chutes, vamos dizer assim, porque ele vai, ele não tem formação suficiente. Aí tu pode colocar uma uma parte de descoberta dinâmica, que é, por exemplo, ele é, tá? toda vez que tu começar uma sessão

nova, eh, passar a fazer uma pesquisa no código do repositório, por exemplo, é o Que ele faria por padrão, né, para tentar entender o que que tem a ver, mas ele vai procurar por palavra-chave e tal, não vai conseguindo muitas vezes coletar o contexto necessário. Então, tu precisa dar uma mão para agente eh, vamos dizer assim, apontar ele na direção certa, né? Eh, esse apontar ele na direção certa normalmente é através de documentação e Através de regras. Então, eh, no cloud code, por exemplo, a gente pode criar uma pasta ponto cloud na raiz do projeto,

colocar aqui na raiz do projeto e aqui a gente colocar uma pastinha de regras e criar uma regra, por exemplo, de como trabalhar eh a camada de aplica ou domínio, por exemplo, posso colocar domain MD. E aí eu posso dizer para eles ah inventar uma, Definir a regra de como que tá estruturado a camada de domínio dentro do meu sistema. E sempre que ele tiver implementando novas entidades ou coisa assim, ele tem que trabalhar de uma certa forma. Eh, as telas, como que são feitas as telas, como que são feitos os codes, como que são

feitos relatórios. Isso tudo pode ser documentado na forma de regras ou até comandos. Você pode criar um comando, por exemplo, que Automatiza e descreve todo o processo de criar uma tela nova, de modo que tu roda o comando com mais alguns algumas informações, tipo, ah, eu quero uma tela nova com eh tipo comando seja barra new e new screen. E aí o prompt seria, quero uma tela nova com é esses três campos aqui e uma listagem com filtros, tal e tal e tal, certo? E se tiver bem descrito, ele vai conseguir eh trabalhar dentro daquele

teu sistema Tranquilamente. Essas regras elas podem ser geradas eh meio que retroativamente. Tu pode pegar e gear elas a partir, tipo, inferindo essas regras a partir do que já existe. Tem um monte de técnicas que dá para usar, mas no geral, eh, para brown field é isso. Tu vai precisar primeiro instrumentar o teu, enriquecer o teu repositório de forma que o agente saiba navegar lá. Porque quando tu tiver um, por exemplo, um um estagiário, entendo no teu time ou um Dev Júnior, qualquer pessoa nova, e fizer um processo de onboarding, pensa toda aquela informação que

o que o usuário teria que a pessoa teria que aprender no onboarding e na experiência do dia a dia de como funciona, onde estão as coisas, quais são as convenções, isso tudo tem a cada sessão tem que est disponível pra gente. Então isso é que tu tem que pensar em colocar No contexto. E não precisa ser eh pap assim, pô, ah, carrega esse readm de 10.000 linhas de código, de 10.000 linhas de texto aqui com com todos os detalhes. Pode ser um processo de descoberta progressiva, tá? Então, por exemplo, tu pode ter no RIDM indicação

assim: "Olha, eh, na pasta tal tem a documentação de como que funciona a camada de aplicação do back end. Na pasta tal tem a parte que explica como que a gente e trabalha com Migrations aqui no projeto e assim vai. Então, isso aí é mais ou menos nessa linha que você trabalha em repositórios. Ah, em aplicações eh que já estão em produção rodando. Opa, temos um bugzinho de compilação aqui. Pegar isso aqui e passar para ele. Já vai arrumar. Respondido. Espero que tenha respondido, Cris. Ah, só deixar ele terminar aqui essa a correção desse bugzinho

aqui e já vamos ver se tem a última tarefa. E a gente fechou a feature, né? Eh, ah, mas e aí se a gente quisesse uma fase dois, só para assim imaginar o que que aconteceria, né? a gente ia novamente criar uma sessão pedindo, olha, vamos especificar agora uma nova fase do projeto que a gente vai adicionar, por exemplo, Eh um sistema de níveis, ah, nível um, nível dois, e vai progredindo, tocando cenários diferentes. Beleza? Como que eu faria isso aqui? Eu ia pedir, passar esses requisitos e fazer uma nova spec aqui na pasta specs,

ele aparecer uma nova specta do dia e o nome da spec ea passar por todo aquele processo de novo, pesquisa, entender como como que tá a implementação atual, como que se implementa a progressão de nível, licitação, perguntar, desenhar uma Solução técnica, dar feedback e terar em cima disso tudo, planejar essas atividades e depois desenvolver. Então, seria esse o processo para depois ir faseando ou implementando novas features ou novos épicos, né? É isso. Estamos quase finalizando aqui. Se quiser me mandar mais alguma pergunta, eu tenho uma última ainda que eu posso responder que vai dar tempo,

eu acho. E aparentemente ele conseguiu Arrumar os bugs de compilação. a gente rodar novamente aqui. Ver, rodar uma vez aqui para ver se ele [música] [música] certo. Vai ter um histórico aqui, ó. 8 minutos atrás. E agora? Então agora tem histórico do dá para fazer um ranking depois daí para evoluir a aplicação em outras direções. Se eu desligar o som, ele não faz Barulho. Funciona. É isso. Temos som, temos tudo funcionando bonitinho. Deixa eu ver se colocar bem pouquinho aqui. Try. [música] Sei. Acho que temos um bem legal aqui já. Então é isso, nenhuma pergunta

nova. Eu acho que até aparentemente mais alguém aqui na A agora no finalzinho, mas acho que pelo que a gente tinha hoje é isso aqui tá de de bom tamanho. Eu fiquei bem feliz com esse resultado. Eu já implementei a, eu já tinha implementado uma, um, duas versões desse jogo aqui de keyboard rider, é, totalmente diferentes, tá? Uma versão é de navinha no espaço e uma versão em 3D. Então, uma versão 2D e uma versão realmente 3D. E aí, Eh, e uma mais parecida com esse monk type aqui. Então, essa daqui ficou, acho que uma

das mais legais deles. Então, isso, pessoal, boa noite e eh bem possivelmente a gente vai ter outras lives aí vindo no futuro. Então, boa noite. E acho que uma última coisa que eu gostei de dizer para vocês é busquem dar um acho que estudar esse processo spec driven e tentar aplicar que a gente vai conversando. Não.