🎯 Por que assistir — o ROI
Assista a isto se você precisa de um mapa claro para proteger seus sistemas da degradação de código gerado por IA e garantir a escalabilidade e manutenibilidade futura. Este vídeo é o mapa para líderes que lutam com a dívida técnica oculta que impede a inovação e o onboarding de talentos sênior.
🌳 Ideia Central — a tese
A ideia de sustentação é que a higiene arquitetural proativa, focada em princípios de modularidade e desacoplamento, é um imperativo estratégico para combater a crescente maré de código genérico e de baixa qualidade gerado por IA, gerando sistemas corporativos duradouros. Ignorar isso leva a sistemas não confiáveis e estagnados.
⏳ Principais Momentos — a evidência
Responsabilidade do Módulo
conceito de módulo. O módulo é uma peça do código com uma responsabilidade clara. Se você consegue descrever o que ela faz em uma frase sem usar i, é um bom módulo.
Módulos com responsabilidade única minimizam o acoplamento do sistema. Ao isolar a lógica e evitar a inclusão de conjunções (como “e”) na descrição do componente, o arquiteto de software cria um design limpo que reduz drasticamente a complexidade cognitiva necessária para manutenção e futuras Revisões de Arquitetura.
Contrato da Interface
o segundo conceito aqui é interface, é o contrato público, é o que o chamador precisa entregar para poder utilizar, é o que o resto do mundo enxerga e usa sem precisar saber como funciona por dentro
A Interface atua como uma fronteira de abstração e isolamento. Ao expor apenas o necessário e ocultar detalhes de implementação, ela protege o restante da base de código contra alterações internas do componente, permitindo que times colaborem de forma paralela e sem atrito sob um contrato estável.
Profundidade de Módulos
depth, é o quanto comportamento o módulo esconde atrás de uma interface pequena
A Profundidade de Módulo (depth) é a medida de sua eficiência arquitetural. Módulos “profundos” encapsulam alta complexidade funcional sob uma interface extremamente enxuta, maximizando a alavancagem técnica e protegendo o ecossistema de software de vazamentos de abstração comuns em códigos gerados sem governança.
Pontos de Encaixe
Seam. Que que é esse Seam, cara? é o ponto de encaixe que deixa trocar a peça sem mexer no resto.
Os seams (pontos de encaixe) são fundamentais para a manutenibilidade de longo prazo. Eles fornecem a flexibilidade necessária para alterar integrações ou componentes de infraestrutura (como gateways de pagamento ou bancos de dados) sem a necessidade de realizar refatorações massivas ou de alto risco no núcleo da aplicação.
Implementação por Adapters
adapter, é uma peça concreta que se encaixa no Seam.
O uso de Adapters permite plugar implementações concretas a uma interface abstrata predefinida. Essa separação garante que os detalhes específicos de uma API externa fiquem restritos ao adaptador, impedindo o acoplamento do sistema a fornecedores específicos e facilitando a simulação de comportamento em testes de integração.
Alavancagem de Módulos
o leverage, que é o o que o chamador ganha por usar o módulo.
O leverage (alavancagem) quantifica o retorno sobre o investimento arquitetural. Um módulo de alto leverage executa tarefas complexas (como validações, pesquisas com sinônimos e checagem de estoque) a partir de uma chamada simples, poupando esforço de engenharia do desenvolvedor e garantindo uniformidade em processos de negócios repetitivos.
Localidade de Alterações
o locality que o mantenedor ganha por concentrar o trabalho num lugar só.
A localidade de alteração (locality) garante que a correção de bugs ou a adição de pequenas melhorias exija a edição de um único arquivo ou módulo. Isso evita o espalhamento de lógica pelo sistema, o que comumente resulta em alterações em cascata indesejadas e dificulta a implementação de rotinas de observabilidade consistentes.
Perigo dos Hotspots
o hotspot. Esse cara aqui é o arquivo onde toda a dor mora. Então é um sintoma de shallow disfarçado
Hotspots representam arquivos de alta complexidade com alterações frequentes e muitas responsabilidades misturadas. Eles sinalizam falhas latentes de arquitetura onde a modularidade falhou, agindo como verdadeiras armadilhas para o time de engenharia e exigindo imediata priorização de refatoração para evitar falhas em produção.
Teste de Deletabilidade
delete test que é se você apagar o não precisa apagar esse módulo, não.
O teste de deletabilidade (delete test) avalia se um módulo é realmente necessário. Se a remoção de um módulo permite reescrever sua funcionalidade em poucas linhas em outro lugar sem quebrar o sistema, significa que ele é um módulo raso (shallow) e descartável, que apenas adiciona ruído e aumenta o custo total de propriedade do código.
💡 Conclusões — e daí?
- Esgotamento da Reserva de Código Humano: A proliferação descontrolada de códigos sintéticos gerados por inteligência artificial está poluindo a base de conhecimento global, levando LLMs a convergirem para soluções médias e a ignorarem cenários complexos de concorrência e condições de corrida.
- Higiene Arquitetural como Filtro Contra Lixo Sintético: A proliferação de ciclos de retroalimentação de erros exige que líderes técnicos estabeleçam rigorosos processos de revisões de arquitetura, garantindo a consistência sistêmica antes que códigos gerados por IA cheguem aos servidores de produção.
- Modularidade como Redutor de Complexidade Cognitiva: O design de módulos profundos com interfaces estáveis garante que equipes internas possam escalar o desenvolvimento do produto de forma paralela. Isso acelera o onboarding de novos talentos e protege a escalabilidade da base de código.
- Isolamento de Acoplamento por Seams e Adapters: A separação entre contratos abstratos (seams) e implementações de infraestrutura concretas (Adapters) blinda o ecossistema interno de oscilações e quebras de fornecedores externos, simplificando manutenções e testes sob carga.
🏢 Casos de Uso — onde aplicar
Em uma reunião de planejamento estratégico de produto, um Chief Product Officer (CPO) apresenta uma nova funcionalidade que requer a integração de um novo provedor de dados externo. O time de engenharia sênior, munido dos conceitos de seam e adapter do vídeo, analisa a arquitetura existente. Eles identificam que, devido a uma decisão arquitetural anterior (ou sorte), o sistema possui um seam bem definido para provedores externos. Em vez de uma refatoração de semanas, o time estima que a integração do novo provedor de dados será um adapter simples, reduzindo o tempo de desenvolvimento de meses para semanas. O CPO aprova, com base na confiança da agilidade demonstrada pela arquitetura, permitindo o lançamento antecipado da funcionalidade e capturando uma vantagem competitiva no mercado.
🚧 Limitações — onde não aplicar
A abordagem proposta no vídeo, embora ideal para robustez e escalabilidade de longo prazo, pode falhar ou ser prejudicial em uma startup em fase inicial de validação de produto (MVP) com recursos financeiros e tempo extremamente limitados. Nesses cenários, a premissa oculta do vídeo de que há tempo e capacidade para investir em arquitetura ‘correta’ do zero ou para refatorar profundamente é irreal. Uma startup focada em MVP precisa de velocidade máxima para validar hipóteses de mercado. Priorizar módulos profundos (deep), seams e adapters pode atrasar o lançamento, esgotar o capital e levar ao fracasso do negócio antes mesmo que haja um produto para escalar, tornando a dívida técnica uma preocupação secundária à sobrevivência.
🏃 Na Prática — como agir
Regras de decisão:
- Se você não consegue descrever a responsabilidade de um módulo em uma frase sem usar “e”, então ele faz coisas demais — divida-o.
- Se a base passa a receber cada vez mais código gerado por IA, então torne revisões de arquitetura obrigatórias antes de produção — são o filtro contra o “lixo sintético”.
- Se um serviço externo é crítico e caro de substituir, então isole-o atrás de um seam + adapter para blindar o sistema de quebras de fornecedor.
- Se precisa priorizar refatoração com tempo limitado, então ataque primeiro os hotspots (alto churn no Git × tamanho), não o que apenas “parece feio”.
- Se está em MVP/startup ainda validando o mercado, então NÃO persiga a arquitetura “correta do zero” — nessa fase, velocidade de validação vence dívida técnica.
Trade-off — higiene arquitetural vs. velocidade:
| Contexto | O que priorizar |
|---|---|
| MVP / pré-PMF, capital e tempo escassos | Velocidade de validação; dívida técnica é secundária |
| Produto em escala, times paralelos | Higiene: módulos profundos, seams/adapters, revisões |
Checklist de higiene arquitetural (rodar com o time):
- Mapear os módulos principais e descrever cada um em uma frase; se exigir “e”, divida.
- Identificar os 3 maiores hotspots (churn no Git × linhas) e priorizá-los no backlog técnico.
- Avaliar o acoplamento escolhendo um serviço externo crítico e medindo o esforço de trocá-lo (revela ausência de seams).
- Testar a deletabilidade de componentes secundários, removendo o que pode ser integrado sem perda de legibilidade.
📜 Transcrição
Introdução de Review de Arquitetura
0:00 · Já tem as estimativas rolando que a reserva de dados humanos, aquele código raiz bem arquitetado de quem entende de verdade do negócio, essa fonte já está secando. Com a internet inundada de vibe coding e código gerado por IA, separar o que é genuíno, que foi realmente codado do que é sintético, já começou a virar o inferno. E a degradação, ela não acontece do dia pra noite. E as pesquisas já mostram que o primeiro sintoma da IA já é esquecer a cauda de distribuição, ou seja, aqueles cenários raros e complexos e bugs difíceis de resolver.
0:32 · Sabe aquela solução genial de um bug bizarro que um dia alguém resolveu num problema de concorrência do back end ou algum truque fino de otimização? Isso é o que vai subir primeiro. O modelo ele começa a convergir para apenas aquele código médio e genérico e as respostas vão ficando repetitivas, os erros repetitivos, os loops vão ficando padronizados e parece que o modelo emborreceu. Já tem consultorias grandes projetando que nos próximos anos as empresas vão começar a desconfiar dos próprios sistemas. Imagina este caos.
1:02 · Uma ferramenta de A gera uma lógica, uma outra ferramenta de A consome essa lógica. começa a ter aquele loop de retroalimentação de erros e lixo sintético rodando em produção. E a solução para isso é realmente você conseguir entender um pouco mais de arquitetura e da infraestrutura do seu sistema, sempre melhorá-lo antes de colocar ele em produção.
1:21 · Eu tenho certeza que você tem um plano que quando você está desenvolvendo o seu sistema, se caso ele escalar, você vai passar isso para um time tech, você vai chamar um desenvolvedor para te ajudar para poder manter esse sistema no ar que agora está com produto validado. Mas eu sinto lhe dizer que se o seu código não foi refaturado e não foi construído com uma arquitetura correta, não temtec no mundo que vai conseguir entender o seu sistema e conseguir trabalho em cima do seu código.
1:49 · Então, até para que você consiga pensar nisso no futuro e trazer um time para dentro do seu sistema e do seu negócio, você precisa do mínimo trabalhar de forma correta. E hoje eu vou te passar aqui um workflow e um pipeline de como que você consegue trabalhar a arquitetura do seu sistema.
2:05 · Vou mostrar aqui para vocês alguns conceitos de arquitetura. Alguns conceitos são um pouco mais avançados, mas eu acredito que você vai entender perfeitamente e isso vai começar a te dar uma luz ali para você melhorar o seu código, deixar ele um pouco mais legível de uma forma que você consiga realmente escalar a sua aplicação. Meu nome é Breno, eu sou fundador da Lion Lab, comunidade de inteligência artificial, sou diretor de uma empresa de tecnologia e hoje tô aqui para passar o conhecimento para vocês. Então já deixa o like aí no vídeo, segue o canal, é muito importante pra gente continuar o nosso trabalho.
2:35 · O link da comunidade tá disponível na descrição desse vídeo. Si você quiser aprender mais sobre desenvolvimento de aplicações utilizando inteligência artificial, venha compartilhar o seu conhecimento com a gente e nós também vamos compartilhar com vocês, beleza? Então, bora pro vídeo. Preparei uma aulinha aqui pra gente não perder o costume.
Os conceitos de Arquitetura de Sistemas
2:52 · Eu vou dar alguns conceitos aqui para vocês. É, e depois que a gente trabalhar esses conceitos aqui, nós vamos trabalhar ali umas skills, um workflow que eu tenho aqui, eu vou rodar ele dentro do Lion Claw, que é o sistema que a gente tem aqui na comunidade, mas eu vou liberar aqui na descrição desse vídeo workflow, o mesmo que você pode rodar aí na sua IDE, vai funcionar. Beleza?
3:10 · Isso aqui, antes da gente começar, só para vocês entenderem, é algo que vai deixar o seu código mais legível. É algo que quando você for chegar lá pro pro time técnico, que você já escalou, que você pretende ali chamar o desenvolvedor, pelo menos esse cara ele vai conseguir entender o seu código, ele vai olhar para aquilo ali e ele vai conseguir ter ali um onboarding dentro da sua empresa muito mais fácil do que se você deixar aquele código gigantesco ali daí aquela aquele código macarronada.
3:39 · Então, é muito importante que você já comece a trabalhar isso o quanto antes, é, para que você não se enrole depois, eh, e tem ali um sistema que funciona, mas quem olha pro código ali não faz ideia de como que as coisas foram construídas.
3:53 · Eh, e aí isso aí vai te complicar muito lá na frente. Beleza? Então, vamos pro primeiro conceito aqui. É o conceito de módulo. O módulo é uma peça do código com uma responsabilidade clara. Se você consegue descrever o que ela faz em uma frase sem usar i, é um bom módulo.
4:11 · Então, cara, temos aqui o email validator. Que que esse cara ele valida e-mail? É só isso. Ele tem aqui esse arquivo aqui, ele valida e-mails. Agora a IA ela cria é esses módulos. É, coloca lá, não, esse cara aqui vai validar e-mail, valida CPF também, consulta receita é e valida data de nascimento, tudo dentro de um arquivo. Só esse cara faz um monte de coisas. Isso é péssimo, porque se você tiver algum problema e precisar refaturar isso lá na frente, eh, você vai se esbarrar num monte de regras, né? A Ia vai esbarrar num monte de regras e você acaba que tem que alterar muita coisa.
4:43 · Então, é importante que vocês entendam que eh isso aqui é algo que a gente tá fazendo aqui, que pode ser a nível de eh cosmético eh no seu código, mas é extremamente importante porque você vai ter que refaturar o seu código em algum momento, principalmente quando o avião estiver andando, né, quando você já tiver com clientes. E isso aqui vai fazer muita diferença lá na frente, beleza?
5:03 · E aí aqui o segundo conceito aqui é interface, é o contrato público, é o que o chamador precisa entregar para poder utilizar, é o que o resto do mundo enxerga e usa sem precisar saber como funciona por dentro. E aí você vai entender por esse exemplo aqui. Imagina que você tem aqui, é, muita gente acha que interface é o só front end ali, mas não é interface, é é a forma como isso tudo se apresenta eh pro usuário e como você mexe com isso dentro do seu sistema.
5:33 · Omplificando, imagine que você entra ali e numa tela de cadastro e tem ali vários passos que você precisa cadastrar, nome, e-mail, CPF e tal, aquela lista gigantesca ali, talvez um checkout do e-commerce que você tem que preencher tudo, formação de cartão, beleza? E aí imagina que tem uma outra interface aqui que você simplesmente aperta um botão lá assim, entra no goov.br, br, aperta esse botão aqui, já tá autenticado ali dentro da sua mar, entrou. Você nem sabe o que que aconteceu, a complexidade ali, você não sabe o que aconteceu por trás.
6:02 · Você só apertou esse botão aqui e você e teve o mesmo resultado de um cara que tava preenchendo todas essas coisas aqui.
6:11 · Então aí isso é a parte da interface, né? É o que o chamador aqui precisa entregar para poder utilizar e é e aquele aquela ferramenta, aquele, enfim, aquela aquela parte do código, beleza?
6:23 · Então, estamos claro que com interface.
6:25 · E aqui o próximo é depth, é o quanto comportamento o módulo esconde atrás de uma interface pequena. E aí imagina que você tá abrindo uma conta lá no seu banco, é, e aí você chega lá e simplesmente entrega sua identidade. E aí o gerente volta aqui, cara, conta aberta, tá showzão, parabéns. E aí no outro lado você, sei lá, aquela, vai abrir a conta lá na Caixa Econômica.
6:48 · Você chega lá, o cara te dá um livro lá para você preencher 15 campos. Quando você abre uma conta, só entregando a identidade ali, é o que a gente chama de deep. E quando você precisa ali preencher todo aquele rolê, você entende exatamente o que que precisa para poder abrir uma conta. A gente chama de shallow. Beleza? Então pensa que aqui nem sempre o deep é 100% certo e nem sempre o shallow é 100% errado. Na grande maioria das vezes até é, tá?
7:11 · Então, pensa comigo, quando você tem o deep ali, eh, pensa que o gerente ele pegou a sua identidade, ele foi lá dentro, ele fez todo o rolê que ele precisava lá e voltou com a conta aberta. Ó, parabéns, sua conta tá aberta. Então, você não sabe o que que o gerente fez. Você não faz a menor ideia do que que o gerente fez, mas tudo se resolveu. Então, você tem uma interface pequena que é o entregar identidade. O comportamento por trás, ele é um comportamento grande, né?
7:38 · Então, o quanto de comportamento o módulo escondeu aqui toda essa parte de de abertura de conta, quando eu vou lá na Caixa Econômica e o cara me entrega todo o os papéis, tudo que eu tenho que preencher ali, eu praticamente sei tudo.
7:49 · Ah, beleza. Para abrir uma conta, cara, até data de nascimento aqui, nome da minha mãe, pai, avó, tudo que eu preciso aqui, entendi. Ou seja, você tem uma interface grande e um módulo grande por trás, porque o fato de eu ter que preencher todos aqueles dados ali não tirou também o fato de que o gerente tem que ir lá, tem que colocar todos esses dados lá para poder voltar com a conta aberta. Beleza? Eu tô tentando dar uns exemplos aqui o mais didático possível.
8:14 · Espero que eu esteja conseguindo passar isso aqui para vocês, porque é importante vocês entenderem isso, tá? Aí nós temos aqui o Seam. Que que é esse Seam, cara? é o ponto de encaixe que deixa trocar a peça sem mexer no resto.
8:27 · Esse aqui é um dos mais importantes para mim, é quando você tá trabalhando é com arquitetura é de soluções, que é, cara, imagina que você tem aqui um um app payment provider aqui, uma parte ali de de pagamentos, né, de um e-commerce. Então, você pode trocar o stripe por Pagar.me em uma linha. Aí a grande maioria das vezes, isso aqui, cara, acontece com IR assim muito, tá?
8:51 · Eh, eh, ela cria ali, por exemplo, ah, eu quero integrar com a Stripe aí, cara, ela cria lá Stripe, Service e beleza. E já coloca um monte de complexidade ali dentro do código e fica tudo amarrado na Stripe. Se amanhã a Stripe quebra ou simplesmente você fala assim, cara, apagar-me aqui agora chegou aqui com a metade do preço para utilizar o serviço 50 vezes melhor, você fala: “Hum, eu vou ter que refatorar o meu código inteiro ali porque tá completamente amarrado”.
9:18 · Então, o que que é o lance? é você ter esse cara aqui no meio que é o SIM, é você tem o app, tem o SIM e tem a stripe. Então, si você simplesmente construir isso aqui de forma correta, esses dois caras aqui, quando você tem a Stripe aqui, você simplesmente cria um outro service aqui da Pagar.me e toda essa parte aqui de trás do código já vai funcionar perfeitamente. Isso aqui, cara, o desenvolvedor, ele realmente ele pensa dessa forma, e ele consegue preparar o código dessa forma e e a IA ela não quer saber disso.
9:49 · Aí ela quer te entregar um app funcionando. Isso aqui, galera, é sem aqui com a Stripe e dessa forma que eu tô falando para vocês que criou ali um arquivo só para Stripe ali, hard code, não tá errado, vai funcionar o seu sistema, mas se você precisar mudar, você vai ter que fazer uma refatoração muito gigante, colocando ali o o seu time técnico que você quer colocar lá numa grande enrascada. Beleza? O próximo passo aqui é o adapter, é uma peça concreta que se encaixa no Seam.
10:21 · Então, é justamente esse cara que eu acabei de falar. Então, pensa que aqui a gente tem aqui um payment provider. Aqui temos essa camada que é a parte de serviço, que vai fazer o a parte de pagamento ali, eh, vai que que vai deixar o pedido como concluído, como pago, vai levar ali as informações lá pro banco de dados, se pagou o cartão de crédito, pagou o cartão de débito, enfim, vai fazer a mágica acontecer. E esse carinha aqui, ó, eles são aqui os adapters. Se você tem mais de um, é porque realmente você tem um sim real.
10:56 · É, si você tem só um, você tem um sim hipotético, mas você vai conseguir acoplar outros carinhas aqui de maneira muito fácil. Isso vale para n outros serviços que você deve ter aí no seu sistema. Hoje o seu sistema é, ele tá modulado para receber isso. Se você precisar trocar uma peça, você tem que sair refatorando 15, 20 arquivos. É isso que você tem que pensar, eh, para poder escalar isso no futuro, tá? E aí nós temos aqui o próximo é o leverage, que é o o que o chamador ganha por usar o módulo.
11:28 · Então, vamos imaginar que você tem ali um serviço que chama search products. Então, você ali pesquisa ali para um tênis e aí ele já vem com acento, com sinônimo, com estoque, com relevância. Ou seja, eu pesquisei tênis ali, tudo errado, sem acento. Eh, e aí o módulo ele trouxe para mim, ele colocou o acento, ele já buscou um sinônimo de de do tênis, ele já deu uma olhada no estoque, ele já deu uma olhada no relevante. Então, o que que o chamador que fez essa chamada, o search products aqui, ganhou é com esse módulo.
11:57 · Isso é o leverage, é a camada que realmente dá relevância pro módulo e faz total sentido. Beleza? E o outro aqui nós temos o locality que o mantenedor ganha por concentrar o trabalho num lugar só.
12:12 · Então imagine que lembra lá em cima que eu falei para vocês que o email validator ele valida e-mails. É só isso que ele faz. Eh, pode ter alguma outra coisa a ver com e-mails ali, a forma, sei lá, às vezes guarda algum dado encriptado, enfim, alguma coisa decidir, mas que tem a ver ali e com aquele módulo. Se você coloca isso tudo separado dentro do seu sistema, quando dá um problema, você só precisa validar naquele único arquivo. Então, vamos imaginar que você tenha lá o serviço de frete lá que tá naquele arquivo.
12:42 · Cara, se você deu um bug no frete, você vai mexer nesse único arquivo e você já vai consertar o sistema inteiro. Agora, o que a IA geralmente faz é ela cria ali e o a parte de frete ali e aí ela aqui o arquivo X aqui chama ele, esse outro arquivo aqui também chama, esse outro cara aqui também chama e aqui também chama duas vezes. Enfim. E aí, para você corrigir um bug aqui, você tem que mexer aqui, você tem que mexer aqui, você tem que mexer aqui.
13:13 · No mínimo você tem que olhar em todos esses arquivos aqui para ter certeza que você não vai sair quebrando em cascata o seu sistema.
13:20 · Então, quanto mais for clean essa parte, e eu falo pr vocês, não é fácil isso, dentre desenvolvedor sênor hoje, é, consegue fazer isso de uma maneira fácil, mas hoje com a IA que escreve código muito mais rápido, o cara que conhece esses conceitos aqui, ele vai conseguir separar o sistema dele de uma forma melhor. Porque entenda que mesmo o alguém conhecendo todos esses conceitos aqui, não quer dizer que o desenvolvedor ultra fodão snior lá saia desenvolvendo, cumprindo exatamente isso aqui. É, o desenvolvedor ele tem demanda para cumprir, ele tem demanda de cliente, ele tem um backlog para desenvolver.
13:53 · Então não é toda hora que o cara poderia ficar refatorando o sistema. E quando você tá refaturando um sistema que está em produção, isso já gera uma responsabilidade 50 vezes maior do que um sistema que ainda tá em testes ainda, que você pode começar correto. E aí o desenvolvedor com esse tanto de demanda e backlog sem a para ele conseguir refatorar esse código inteiro aqui, o cara leva 8 meses e que correndo o risco de quebrar o sistema inteiro e precisa fazer uma migração de dados de cliente antigo pro novo. É algo bem custoso de se fazer. Beleza?
14:24 · E aí depois nós temos aqui o hotspot. Esse cara aqui é o arquivo onde toda a dor mora. Então é um sintoma de shallow disfarçado de di.
14:34 · Então imagina que tem aquele servicinho lá, o OrderService.js.
14:38 · Aquele carinha aqui que tem 80 commits por mês naquele arquivo. Ele tem umas seis responsabilidades empilhadas. É aquele negócio, o cara faz ali valida e-mail, salva hash senha, é valida CPF, enfim, ele faz aquele monte de coisas ali, aquele arquivo de 6.000 linhas.
14:54 · Com certeza vai ter muito arquivo desse no seu sistema. É, e esses arquivos são geralmente os mais problemáticos, porque você tem que mexer, você vai ter que entrar nessa caixa preta, né? quando tem ali aquele arquivo que é um arquivo muito grande ou vários arquivos muito grandes com muitas regras eh e muita eh coxa de retalho ali, eh você tem que abrir essa caixa preta. Então esses caras aqui são os hotspots aqui que você tem que começar por eles. Beleza? E aqui temos o último aqui que é o delete test que é se você apagar o não precisa apagar esse módulo, não.
15:25 · Mas se você olha pro código e fala: “Cara, esse módulo aqui de e-mail, se eu apagar ele, é o que que acontece? Eu eu consigo eh simplesmente fazer ali a validação do e-mail aqui por essa linha aqui, escrever uma linha de código, eu consigo resolver tudo isso aqui em vez de eu ter esse arquivo aqui. Se você consegue, é porque esse módulo ele nem precisava existir, Shellow, você pode deletar ele sem dó. Tem um módulo ruim. Se você deletar aqui um search products e sai quebrando tudo que você fez, é porque realmente esse módulo fazia sentido e ele tem que continuar.
15:56 · Então é apenas um exercício mental. E veja que você sabendo isso aqui não vai melhorar a performance do seu código. É, não vai fazer seu código, seu seu sistema dar mais rápido, não vai fazer seu sistema ficar mais bonito, não vai mudar nada.
16:11 · Você tá mudando a arquitetura dele para que você consiga ter agilidade até para poder desenvolver mais features no futuro e conseguir escalar o seu sistema. Beleza? E aí aqui eu trouxe aqui um pipeline aqui de seis fases, eh, pra gente poder conseguir trabalhar isso, né, de uma maneira um pouco mais fácil. Eu precisava explicar o conceito para vocês, senão eh, não adianta ali, vocês vão ficar vendo um monte de coisa na tela ali sem entender nada. Eh, e aí eu vou rodar isso aqui junto com vocês enquanto eu explico aqui essas fases.
O Pipeline de Review de Arquitetura de Sistemas
16:40 · Então, eu vou começar a rodar isso aqui ali e no Lion primeiro, que é o sistema aqui que a gente tem na comunidade, tem um chat, tem sub agentes, enfim, já falei várias vezes aqui desse sistema.
16:49 · Eh, enfim, hoje o objetivo aqui é a gente mostrar esse pipeline de arquitetura. E aí eu vou rodar ele num sistema aqui que eu acabei de construir.
16:56 · Eu tava testando uma outra feature aqui que é uma feature agora de eh você consegue construir o fronte aqui, enfim, eh começa a partida, enfim, uma partida de xadrez aqui eu desenvolvi e passei por todo o pipeline aqui cima de desenvolvimento e entregamos essa solução aqui. E eu acabei de entregar isso e agora a gente vai rodar aqui esse arquitecture review e esse review de arquitetura em cima e do que eu acabei de desenvolver. Então, cara, eu passei por todas as fases aqui, é, cara, todo o BRD, spec, é tudo bonitinho, cara.
17:25 · Realmente de comandos corretos. Mesmo assim, com certeza alguma coisa de arquitetura a gente vai poder melhorar.
17:31 · E aí vamos rodar ele aqui. Eu vou rodar um pipeline. Nós vamos rodar esse pipeline de arquitetura aqui. Então, vamos colocar aqui chess arc, colher a pasta dele. E aqui a gente já vai rodar o pipeline completo. E aí ele já vai começar a rodar aqui, mas eu vou explicar para vocês exatamente o que esse cara faz. A primeira coisa que ele vai fazer aqui, ó, é o zoom out, que é um mapa amplo, né? Vai pegar todos os módulos, os domínios, os hotspots, a linguagem, né? como que você chama cada parte ali do seu sistema para que você consiga de fato entender o seu código.
17:59 · E aí na fase dois aqui nós vamos trabalhar aqui esse improve codebase architecture.
18:06 · Vamos melhorar a arquitetura que é nós vamos aqui enumerar alguns candidatos que a gente precisa aprofundar, eh porque sempre tem alguma coisa que você pode refaturar no seu código. É, e aí ele vem aqui com o grilling embutido, que é um agente ali vai realmente te provocar ali, é, e entender o que que de fato a gente precisa fazer e como podemos melhorar ali e aquele candidato que foi escolhido. Na fase três aqui nós vamos ter aqui o diagnóstico, né, que é um loop disciplinado de bug e um feedback ali de loop com a causa raiz.
18:38 · Então, é o diagnóstico ali que nós vamos ter daquele candidato que foi escolhido.
18:43 · Então, tem vários módulos ali no seu sistema. ali você vai escolher algum ali que você quer trabalhar. Eh, e esse cara aqui vai dar o diagnóstico aqui e nós vamos entender a causa raiz do que que precisa ser melhorado. E aí depois vem a fase quatro aqui, que é uma entrevista aqui com a gente ali, ele vem pergunta a pergunta, ele pressiona ali o plano sobre fogo para realmente a gente tomar essas decisões e entender perfeitamente o que que a gente precisa para poder melhorar e o nosso sistema. Beleza?
19:08 · E a fase cinco aqui é a fase de decisões, que são todas as decisões que foram tomadas pra gente poder refaturar o código. E a fase seis, a gente parte ali, eh, paraa spec, eh, para poder desenvolver e mexer nesse código, né?
19:23 · Gerar aqui uma um spec que seja implementável, beleza? E aí aqui dentro do Lion e nós vamos ter todos esses processos aqui até o desenvolvimento aqui. Esse sistema aqui é o sistema que é liberado aqui na comunidade. Todo mês aqui a gente melhora ele, a gente vai desenvolvendo juntos aqui. E essa parte de arquitetura aqui foi algo que a gente entregou recente, é que a gente vai melhorando aqui o código. Ele hoje ele roda em cima do SDK do cloud, mas você consegue colocar aqui o Codex também para poder rodar. Eh, e o agente aqui ele vai mapear tudo.
19:54 · E nós vamos seguir aqui todos esses passos aqui, ó.
19:58 · Mapeamento, o target, o diagnóstico, o decide aqui e aqui nós vamos partir aqui. Spec, validação, enreit, o planejamento das sprints e depois nós vamos pro código, pro desenvolvimento, para poder melhorar. Aqui nós vamos rodar aqui em cima desse sistema eh de xadrez aqui que a gente acabou de desenvolver. plataforma simples aqui.
20:19 · Vou vou dar aqui para vocês, só para vocês terem uma ideia de como que ficou este desenvolvimento aqui. Beleza?
20:24 · Consegui entrar aqui. Então, enfim, aqui, cara, super simples. Eu fiz isso aqui pra gente poder validar eh uma parte de front end ali. A gente colocou o open design agora aqui dentro do Lion Claw. Então, quanto tá rodando aqui, eh, essa parte aqui foi uma parte mais custosa de colocar aqui dentro para você poder conversar ali. Então, enfim, eh, você desenha aqui o fronte antes de de ir pro desenvolvimento. Eh, enfim, a gente colocou isso aqui e aí, cara, ele desenvolveu aqui a risca o que precisa.
20:51 · Basicamente, você escolhe aqui fácil, médio, difícil, você joga aqui contra o IAI. E, cara, parece que ele desenvolveu super bem. Aqui tem um bugzinho aqui ou outro aqui, ó, que aqui ficou meio zoada essa parte aqui. É um da aqui, enfim.
21:04 · Vou ter que corrigir isso aqui depois, mas o que a gente vai mexer aqui não é não é na parte de funcionamento.
21:09 · Funcionamento ele tá funcionando aqui.
21:11 · Testamos, ó. Eu jogo aqui, ele joga lá, enfim, consigo aqui mexer meu bispo, tudo beleza? E ele joga lá, já matou meu bispo aqui. Enfim, tá tudo funcionando legal. Se eu abandonar a partida, é tudo que eu coloquei aqui, ó, classificação, cara, show de bola. Bele, e aí agora nós vamos começar a auditar esse cara aqui.
21:29 · Então, aqui, ó, ele já pegou aqui todo o vocabulário, ó. user, session, chess ID, mat, ele colocou aqui todo o vocabulário desse domínio, né, que é o ch aqui que a gente criou. Aqui tem o diagrama de nove camadas, ó, os 19 módulos que a gente tem, né? Então aqui tem front end shell, front end aqui o adapter, a o autenticação da UI, o app navegator, play. Aqui a gente tem aqui o main process, né? Tem a orquestração, o game.
O review de arquitetura dentro do LionClaw
21:58 · Temos aqui o data persistem, que é o banco de dados. Nesse caso aqui tá rolando o SQLite. Eh, temos o Stockfish adapter, que ele que é uma integração externa, que o que a gente usa ali como motor, é, do nosso do jogo de xadrez. E temos aqui uma uma infra shared aqui, né? Uma infra que tá dividida, beleza? É, e aqui tudo tem as explicações exatamente o que que faz, enfim, você consegue entender tudo. Aqui embaixo tem a explicação aqui do que que faz cada uma das coisas, do que que cada módulo faz, do que que cada processo do backend faz.
22:27 · Ou seja, eu eu puxo a capivara aqui eh do meu sistema e e ele entende perfeitamente. Domínio do xadrez, os fluxos principais, os hotspots que são a partida tabuleiro, match orquestration, Stockfish adapter, a persistência e o ranking. Isso aqui é o zoom out, que é aquela primeira ali que eu mostrei para vocês, que é a primeira fase aqui, é essa parte que a gente tá rodando aqui. Beleza?
22:58 · E aí, só para vocês ficarem tranquilos aí, se você não tem acesso aqui ao LionClaw, você não é da comunidade, é, cara, tudo isso aqui, ó, tem aqui dentro dessas skills aqui, ó, que é o review workflow skills. Vou deixar aqui na descrição desse vídeo. Então, você entra aqui.
23:16 · Aqui tem as skills, ó. diagnóstico, grillb, improve code base to respect.
23:21 · Vai ter um readm aqui que basta você mandar o seu agente ler esse readm aqui, esse workflow, eh, e ele já vai entender exatamente, ele vai entender tudo que ele precisa para poder rodar é essa skill aqui dentro do seu código. Então, basta você colocar isso aqui dentro da pasta do seu sistema, rodar, vai funcionar perfeitamente. Eu vou mostrar no Lck, é um pouco mais visual ali pra gente poder mostrar isso aqui para vocês, beleza?
23:44 · Então aqui agora ele tá rodando o target, então ele vai validar tudo e ele vai me apresentar aqui os candidatos que a gente pode mexer eh para poder melhorar a arquitetura e eu vou escolher um deles. Obviamente ele vai e eh tentar me sugerir qual que ele acha que a gente tem que mexer. Como é um sistema muito pequeno aqui, que acabamos de construir aqui, não tem nada de muita complexidade, é vai ter vai ser fácil aqui de escolher alguma coisa. É, e aqui ele já tá, ó, gerando aqui os candidatos, ó. Gerou.
24:08 · Deixa eu até tirar minha carinha de cá. vai ficar meio pequeno aqui para vocês aqui sem o zoom it aqui hoje porque eu tô no Linux, mas enfim. Então temos aqui snapshot de met ativo e aqui ó comit de turno e finalização atômica. Então o que que ele tá me falando aqui que o Mat Service valida turno, aplica o lance do usuário, chama o Stockfish, aplica o lance do motor, persiste dois movimentos e atualiza o fen, finaliza o match e aplica o delta rank. Ou seja, um esse cara aqui, o match service, ele faz um monte de coisas.
O Target e escolha de candidatos para a refatoração de Arquitetura
24:38 · Então o que que é a direção? aprofundar o módulo de comite de turno e finalização dentro do domínio do Mat responsável por persistir o lance. Aí atualizaram o Mat Currence, ou seja, ele já me deu aqui mais ou menos o que que a gente precisa fazer. E é importante a gente já trabalhar isso agora, é porque depois de acordo com que o meu jogo aqui de xadrez ele vai evoluindo, o quanto mais separado eu conseguir trabalhar, vai ser melhor. E dando um outro exemplo aqui para vocês, veja que aqui dentro do Lion Clos aqui, tem todos esses tipos de pipelines aqui.
25:10 · E quando eu fui construindo isso aqui, eu tô tem até esse 2.0 aqui que tá em beta. Quando eu fui construindo isso aqui, eh, eu simplesmente fui fazendo ali os pipelines ali à torta direito.
25:21 · Quando eu fui perceber, tinha um arquivo que era o arquivo principal dos pipelines ali, o arquivo tinha 5.000 linhas, ele cuidava de tudo. Então se aquele arquivo ali, toda vez que eu tinha que mexer em alguma coisa, criar um pipeline novo, é esse arquivo ele tava envolvido e eu tinha que refatorar e testar tudo de novo, porque qualquer coisa poderia quebrar um outro pipeline que já existia. Então isso aqui é um grande refaturação que eu tive que fazer e para poder principalmente separar esse arquivo e e garantir que nada disso e iria quebrar.
25:49 · E o que eu ganhei é que eu hoje eu consigo construir um pipe eh muito fácil, eh porque eu tenho eh cada um com as suas responsabilidades ali e o meu harness aqui vai funcionar perfeitamente. Basta eu ter a ideia de pipe, eu consigo implementar muito mais rápido, porque o meu código ele não tá todo emaranhado, não tá aquela coxa de retalhos. Beleza? Aí, isso eu tô tentando passar para vocês, para você o mais didático possível, porque isso aqui realmente não é algo tão, não é algo simples de entender.
26:16 · Eh, principalmente se você não for um cara técnico, quando for um desenvolvedor, com certeza, tô falando aqui, o cara tá entendendo legal. Agora, quando não é um cara técnico, tem que entender isso, porque de acordo com que você vai subir nesse código lixo que você tá fazendo aí lá pro KitHub e mais treinamentos estão sendo feitos e todo mundo subindo código lixo, o mesmo código de a, é, cara, os modelos eles vão ficando cada vez piores, eles não vão conseguindo nem chegar nesse nível aqui, eh, em algum dia aí para poder fazer esse tipo de review de arquitetura. Beleza? Então, vou seguir o jogo aqui e vou escolher esse cara.
26:47 · Vamos escolher esse comite de turno aqui. O próximo passo aqui vai vir o Grill Mia. Esse cara aqui vai vir para cima é e ele vai me fazer diversas perguntas aqui. Eu vou responder todas elas. É, e ele vai realmente me provocar aqui pra gente poder é resolver da melhor forma possível como que a gente pode melhorar e essa arquitetura aqui e ficar algo um pouco mais clean, beleza?
27:09 · E quanto mais você faz isso, mesmo diminuindo ali o tamanho, eh, eh, mesmo aumentando um pouco talvez o tamanho dos a quantidade de arquivos, mas diminuindo a complexidade, qualquer um que pegar o seu sistema, ele vai conseguir ali e andar ali dentro do seu sistema e vai conseguir entender o código. É, e isso é muito relevante, porque você nem sempre vai ficar sozinho aí, é o Vibe Coder sozinho em casa aí no domingo à noite.
O diagnostico do problema e as evidencias da Causa Raiz
27:34 · É, se o seu sistema escalar, você vai precisar de uma equipe. equipe, ela vai precisar entender o que que o seu sistema faz. Então, é importante e que você dê muita atenção eh para esse tipo de review de arquitetura. Beleza? Aqui ele já rodou o diagnóstico, ó. Módulo que deveria concentrar o comite atômico de turno e finalização está dissolvido entre mat service, repositórios rasos e leaderboard service. O sim de indepotência está no lugar errado.
27:56 · O leaderboard service conhece a regra de delta único, mas declara que o chamador deve garantir uma chamada única dentro da transação. Isso reduz o locality, o leverage, porque o Ply e o Fen, resultado terminal e Delta ranking só podem ser exercitados pelo fluxo largo, não por uma interface profunda de commit. Então, cara, é, ele me entrega aqui todas as evidências aqui, porque o por do que que ele acabou de me falar, é, me fala que quais são os Sims atuais.
28:27 · Aqui, cara, deve estar muito pequeno, realmente não consigo fazer o zoom aqui, peço desculpas. Eh, e aqui eu tenho Sims ausentes, né, que estão aqui desse lado aqui. Então ele me entrega aqui o diagnóstico, a causa raiz. E agora nós vamos pro decide aqui que o agente ele vai me sa batatinar aqui, ó. E aí ele já começou, ó. A responsabilidade do comitização atômica deve virar um módulo profundo dentro do domínio mat chamado por submit e finest.
28:50 · Aí ele me dá as condições e opções consideradas. módulo interno de méd para comite finalização, eh, ou reforçar aqui os depositórios e métodos condicionais ou concentrar de potência. E ele sempre me dá a sugestão.
29:04 · Minha recomendação é a pelo delete test que a gente falou no delete test, essa transição é uma responsabilidade real do domínio de Match e não do adapter SQL, nem do ranking. Isso aumenta o locality e o resultado de Delta única e cria leverage para testar o commit finalização sem atravessar o Stockfish.
29:22 · Ou seja, eu tô tô separando o Stockfish ali, que é realmente muito importante. E aí eu vou trocar ideia aqui com ele, eh, e daqui a pouco eu volto aqui, eh, com as decisões que foram geradas pra gente poder gerar especificação técnica. E aqui, ó, ele já terminou, é, como o sistema muito pequeno, foi muita muito poucas decisões aqui, ó. A decisão é o módulo de comite de met, guarda otimista ali no comit, o ranking no mesmo comit e entrada validada para comit.
O Grill-me e as decisões tomadas para refatoração
29:47 · Aí, cara, talvez tá fazendo tanto sentido aqui para você, mas, cara, ele explica perfeitamente aqui eh o que que cada um faz aqui de novo. Peço desculpas aqui para eu não tá podendo conseguir dar o zoom aqui. Inclusive, cara, por favor, coloquem nos comentários se vocês têm alguma ferramenta que tem que seja muito parecida com o Zoit, que funciona para Linux e eu aceito. Beleza? Eh, e aí, cara, ele me deu tudo bonitinho aqui, todas as quatro decisões. E aqui a gente já vai direto paraa spec, eh, gerar spec aqui.
30:15 · Aí, cara, ele já entra aqui, eh, totalmente aqui num âmbito eh que o Lion Club já faz, né, o pipeline, vai spec, vai validação da spec, vai pro enriquecimento da spec, aí depois vem ali o planejamento das sprints e aí desenvolvimento e e validação ali testes. É, a partir daqui acho que não preciso mais mostrar pra vocês, senão esse vídeo vai ficar muito grande. Mas o meu ponto aqui é é esse essas skills aqui é esse pipeline, ele ele puxa a capivara do seu código ali e ele vai te dar várias opções para você poder ir melhorando.
30:46 · Não é que ele vai resolver todo o problema do seu código é em uma vez só, mas você tem que ir trabalhando com o tempo. É, isso vai facilitar a sua vida lá na frente. Quando você tiver implantando outras features, outras funcionalidades, vai facilitar muito a sua vida se você não tiver aquele código ali, é, que tá cheio de coxa, que é aquela coxa de retalhos ali, tá emaranhado tudo ali. Você mexe aqui numa parte da tela home e quebra o sistema lá no no checkout pro usuário fazer o pagamento. É, isso vai ajudar bastante vocês aí, beleza?
31:16 · Então, só para reforçar aqui, você tem esse workflow aqui que eu vou liberar. Isso aqui ele vai funcionar perfeito. Basta você falar: “Cara, tem uma pasta aqui, review workflow skills, eh, dá uma lida no Reid e no Workflow. Você pode pedir pro seu agente da IDE, ele vai olhar ali o workflow perfeitamente, eh, e vai conseguir seguir exatamente esses espaços. O ganho que você vai ter, ele é futuro. É principalmente quando você vai entregar isso ali para um desenvolvedor que vai te ajudar ali a escalar o negócio. Para esse cara poder entender o seu código. Se você já crescer de forma correta, eu garanto para você que você vai ter um ganho de performance e um ganho de nível de entrega de novas funcionalidades no seu sistema, muito mais rápido e com muito menos chance do seu código quebrar. Beleza? Um forte abraço a todos e até mais.