Música Eu vou separar o nosso bate-papo hoje em duas partes Uma parte a gente vai falar sobre DevOps e SRE Tem bastante conteúdo aqui na realidade pra gente falar sobre Mas depois eu quero falar especificamente também sobre IA e alguns pontos aí que eu tenho observado e quero dar um toque aí pra vocês também, tá? Então acho que vai ser um papo legal, inclusive depois a gente pode abrir, fazer algumas discussões e tudo mais, quero pegar o feedback de vocês também e etc. Show de bola? E galera, vocês também e etc, show de bola? E galera, vocês que estão aí, por favor, liguem as câmeras, ó o Kleber, o Maurício o Marcos o Diem, cara, ontem você não veio, é, segunda você não veio, é ontem você não veio e hoje você não liga a câmera, meu amigo, entendeu? Tem que ser que nem o Guilherme, que é essa barba aí que dá pra dar inveja, cara eu posso ficar sem fazer barba o resto da minha vida ela nunca vai chegar desse jeito, cara eu só tenho um bigode chinês, cara é, é, é bizarríssimo a minha eu parei de fazer tem 3 meses e já vou ter que fazer mais eu posso ficar 30 anos e ela não chega desse jeito, meu amigo rapaz, o cara parece aqueles homens bomba. É que a minha barba não cabe na câmera. Caraca, cara. Tá parecendo aqueles homens bomba. O meu não consigo nem fazer uma... É isso, Jota. Um viking. É, cara. A gente tem um viking hoje aqui. Viking do código. Interior de São Paulo. Interior de São Paulo interior de São Paulo que lugar do interior? cara, a minha família é de uma cidade que chama Pindorama se você conhece, você tá dando um rolê muito errado Pindorama, meu amigo? cara, é pro lado de Ribeirão Preto? é é meio perto de Ribeirão Preto. É mais perto de São Eduardo e Rio Preto. Do lado de Catandu. Cara, eu sou de Pirapora, mas quando eu casei, fui pra Indaiatuba. Então, eu sou um cara do interior também. Mas não tão interior que nem você, né? Porque eu estou no interior, tenho que andar três horas de carro pra chegar no interior da casa dele, entendeu? É tipo isso. Então chegar no interior da casa dele, entendeu? É tipo isso. Então, aí ele tá no interior. É longe. Não, hoje eu moro em São Paulo, mas eu era de lá. Eu moro em São Paulo tem sete anos. Show de bola, eu morei cinco em São Paulo, cara. Tenho uma saudade e não tenho saudade ao mesmo tempo. Mas, show de bola. Maravilha, galera. E aí? Estamos no meio da semana. Quem já tá pedindo arrego aí pra chegar sexta-feira? Fala a verdade. Aí, cara, já tem gente pedindo arrego, meu amigo. Sabe o que que é? Sabe por que que você tá pedindo arrego, cara? Porque você não trabalha com IAR. Você trabalha, você escreve um comando assim e vai tomar café e deixa ela até participar das daily com você, entendeu? Ela faz tudo. E daí, cara, entendeu? É assim mesmo. Eu dou um enter aqui, ela grava os meus vídeos, ela faz os meus roteiros, ela cria todos os meus códigos, aí eu vou tomar café, ela tá programando pra mim, ela faz umas reuniões com a galera toda, e daí chega no final do dia, eu falei, deixa eu falar com os caras aqui. Mas eu vou falar uma coisa pra vocês. Quem está falando agora com vocês é uma IA. Olha só, já pensou se um dia a gente conseguiu perceber essa diferença? O Wesley, você está falando IA. Deixa eu fazer uma pergunta. É um pouco direcionada pro MBA. Tem alguma parte específica no MBA de arquitetura que vai tratar IA? Cara, nós estamos adicionando, cara. Só pra você ter uma ideia, semana passada a gente teve uma aula de, acho que, cara, quanto tempo foi a aula, Leonão? Acho que foi umas duas horas e pouco, é isso? Semana passada foi duas horas e quarenta e cinco. O cara sabe porque que ele publica as coisas na plataforma, pede pra galera editar. Então, cara, duas horas e quarenta e 45 só sobre MCP, por exemplo eu estava lá presente aí, Daniel, não deixa a gente mentir, né? não, e já estou usando e hoje foi um arraso total, nossa salvou minha semana inteira, né assim, eu estou fazendo a MBA só para contextualizar para todo mundo e assim, deu uma segurança na hora de apresentar o ADR, o cliente não sabia o que era ADR, e ele gostou muito da documentação. E os próximos passos, né, do C4, e assim, todas as aulas estão me dando mais segurança, né, de apresentar isso, que é no meio mais masculino, né, isso é muito interessante. E o curso está me ajudando demais. Galera, façam como a nossa amiga Daniela. Eu não tenho como, nesse momento, não mostrar um código, um QR Code pra vocês, entendeu? Eu não tenho como não compartilhar minha tela pra vocês preencherem um formulário, bater um papo com a nossa equipe, pra vocês fazerem que nem a Daniela, ter muito mais segurança, mostrar as paradas pro cliente e tudo mais, tá? E brincadeiras à parte, cara, Daniela, valeu aí por confiar na gente, a gente tá dando o nosso melhor. E uma das coisas que a gente tem feito é que, assim, fundamentos ficam, mas as novidades e hypes acontecem a todo momento entendeu? e o que a gente mais está apresando hoje em dia pelo NBA é o que? nós temos as aulas, são muitas aulas gravadas tá galera? é bastante aula que você faz no seu tempo e no seu ritmo essas aulas são importantes porque elas dão muito fundamento, elas dão embasamento pra vocês, mas ao mesmo tempo cara não há gravações que consigam alcançar a velocidade com que as coisas estão mudando hoje em dia, entende? então por conta disso a gente tem esses encontros a gente tem essas dinâmicas e aí a gente consegue pegar temas que estão sendo utilizados atualmente exatamente pra que a gente consegue pegar temas que estão sendo utilizados atualmente, exatamente pra que a gente consiga manter vocês atualizados e sempre fazer links com o que tá sendo dado no MBA com alguns spoilers interessantes a gente fechou agora com um dos superintendentes da área de engenharia do Itaú, cara o cara vai fazer aí uma talk pra gente fantástica, pra galera do MBA. Isso aí vai ser muito bacana. A gente tem galera da Redis que vai participar com a gente. Vou pedir também pro Fernando da Google vir e dar também uma aula sobre o lado de IA, voltado pra... O lado de IA de forma geral, de O lado de IA, de forma geral, de como que a Google está trabalhando e as aplicabilidades que eles estão usando. Os caras têm muita informação que a gente acaba não vendo, entendeu? Então, é muito bacana poder trazer gente muito melhor do que eu para eu aprender junto e vocês aprenderem bastante também, tá? Então, somente para vocês saberem... É interessante. E somente pra vocês saberem, é interessante. E somente pra vocês saberem, né, Flávio colocou aí, tá faltando uma aula dessa pro FUSAI com o 4. Galera, só pra vocês saberem, pra quem é aluno nosso, hoje a gente publicou já um módulo, falta um capítulo, mas a gente já publicou um módulo na área de IA, na área de IA, na área de IA, focado em Prompt Engineer, específico para desenvolvedores. E a gente vai publicar esse módulo também para a galera do MBA. Então, já estou dando um recado indireto aqui para o Leonan, que está aqui com a gente para publicar. A galera do MBA também vai ter acesso a esse módulo. Cara, uma das coisas que muda muito a vida de qualquer desenvolvedor é a parte de prompt. Eu nunca pensei que eu ia falar isso na minha vida. Eu já falei isso várias vezes. Eu nunca pensei. Mas é a vida, meu amigo. É a vida. Galera, vamos organizar a casa aqui e começar a nossa brincadeira. Porque tem bastante coisa. Opa, fala meu amigo. Posso fazer uma pergunta? Duas, que não sejam longas. Não, é curto e objetivo. Cara, o programa faz uns 20 anos já, mas parte web eu estou começando há pouco tempo, apesar que eu estou desenrolando bem no Fyton. Mas eu vou explicar a minha situação, vamos ver se teria como. É o seguinte, hoje eu sou engenheiro de automação e trabalho com estrutura metálica, projeto máquinas e faço as máquinas funcionarem. O que aparece muito para mim, são os sensores. Então, eu desenvolvo um software para o cliente e ele monitora a máquina através de sensores na tela. Tem um computadorzinho lá que ele monitora. Para eu chegar num nível tranquilo, a lógica eu tenho. Programei muito tempo em Pascal, em Delphi, em VB. Somos dois. Pascal, Delphi, VB. Na época é o que tinha. E todas essas ferramentas, esse treinamento e tal, serviria para mim? Falando em MBA, cara, o que acontece é o seguinte, você está numa situação, e isso serve para todo mundo, tá, pessoal? Que é o inverso de muitas pessoas que acabam acontecendo. Tem gente que, às vezes, eu recomendo que ela não faça um MBA porque ela tem muito pouca experiência vivida, sabe? A pessoa está muito crua, ela não tem nenhuma cicatriz para conseguir entender que ela tem um problema e que a gente está mostrando a resolução desse problema. Mas ela já sabe, sei lá, mexer com React, sabe fazer um crude em Java, em Python, não interessa e etc. Você está numa situação que é inversa. Você tem toda a experiência, todas as cicatrizes e, cara, 20 anos de experiência na área de tecnologia... Meu mouse aqui. Os 20 anos na área de tecnologia, cara, é muita coisa. E o que mais enriquece os 20 anos não é a tecnologia em si, mas são as situações, o repertório que você vai criando, os problemas que você vai resolvendo conforme o tempo vai passando, tá? O que você precisa fazer, cara, é urgentemente, eu diria, focar em aprender bem uma linguagem de programação para você entender, e você é um cara provavelmente de back-end, já de cara dá para perceber, aprender bem uma linguagem de back-end, entendeu? Conseguindo fazer os acessos a banco de dados, entender frameworks básicos que todo mundo utiliza e você vai desenrolar rápido, tá? Recomendo, cara, olha só que interessante. Eu já passei por muitas linguagens de programação. Eu passei muito tempo no PHP, programa em Python, já passei para C Sharp, C++. Sou um cara... Brinquei de Java. Jamais vou falar que eu sou programador Java, porque eu não sou. Mas, e também programa em Go, cara. E Go é uma linguagem fantástica nos dias de hoje pra aprender. Adoro e recomendo muita gente aprender Go. Por outro lado, olha só. Você já começou a mexer com Python, tá? E Python é uma linguagem muito fácil de se aprender tem muita coisa pronta tem muito material pronto é uma linguagem hoje em dia que está num hype muito grande por conta de IA então talvez seja um gancho interessante você se especializar um pouco mais em Python entendeu? onde você consegue focar a em dois pontos né a sua parte de back-end desenvolvimento e ao mesmo tempo pegar um pouco desse hype de ar que tem muito material para pai então tá mas temos a grande questão Python é uma linguagem de alto nível né E você fala que você gosta de mexer muito com sensores e tudo mais esse Esse tipo de coisa, no Python, provavelmente você vai ter que trabalhar com muitos wrappers, alguma coisa que faça com que o Python se comunique com alguma camada em C, por exemplo, ou alguma coisa desse tipo, para que ele consiga fazer as coisas mais em baixo nível. Entendeu? Exatamente. Eu já fiz algumas coisas desse tipo tá? Porém a experiência melhor que eu tive em trabalhar com isso foi com o Gol, fazendo rappers inclusive desde Rust e C e tudo mais, tá? Eu nunca mexi fortemente no Python pra trabalhar com esses níveis de abstração mais baixo mas, cara, é uma questão de estudo e trabalho e tudo mais, então se você for querer mexer com mais baixo nível eu recomendaria você ir de Gol porque ela mexe bem baixo nível tem uma facilidade bem grande de fazer esse rappers, tem uma performance fantástica e tudo mais porém Python facilidade bem grande de fazer esse rap, tem uma performance fantástica e tudo mais. Porém, Python, você já tá mexendo, entendeu? Você já começou na linguagem, você não teria que começar mais uma linguagem do zero. O que eu não gosto de dar conselhos pras pessoas, e olha, pra mim é muito melhor falar pra você aprender Go, porque eu tenho uma pós-graduação em Go fantástica, entendeu? Mas o que eu não gosto é ficar fazendo as pessoas ficarem brincando e zanzando de linguagem pra outra, porque você perde muito tempo, você perde o foco. Então, como você já tá focado em Python, faz quanto tempo você tá trabalhando aí com Python? Você tá mexendo, brincando com ele? Eu acho que uns uns oito meses. Ah, então. Cara, você está com oito meses mexendo uma linguagem de programação. Cara, eu não vou pedir para você começar e aprender outra nem sonhando, entendeu? Cara, pega firme no Python, faz um checklist de coisas que você tem que aprender, entendeu? Desde os conceitos básicos de chamadas de API, conceitos básicos de conexão com... Eu acredito que muito disso você já deve estar fazendo hoje. Eu acho que vale a pena você se especializar mais. E em relação ao MBA, sim, você já programa, você vai aprender boas práticas, eu recomendo você fazer, sem dúvidas, entendeu? Agora, se você falasse que não programava nada, só programava em Pascal, aí eu ia falar para você não fazer, tá? Eu sempre gostei, na verdade eu fiz ao contrário, em vez de fazer primeiro engenharia, depois me especializar em automação, eu aproveitei a programação e fiz engenharia. E deu certo, ainda bem, graças a Deus. Obrigado, Wesley, pelo esclarecimento. Estamos juntos. Galera, seguinte, uma coisa pela... Que isso? Pelo esclarecimento. Tamo junto. Galera, seguinte, tá? Uma coisa que eu vou tentar deixar fixa o tempo todo, né? Pra vocês fazerem que nem a nossa amiga Daniela. Vou deixar um QR Code aqui pra vocês. Vocês escaneiam esse QR Code. Ele vai fazer você cair nessa página aqui. Onde, vocês caindo nessa página, vocês vão poder bater um papo com a nossa equipe, ou muitas vezes bater inclusive um papo comigo. Muitas vezes eu faço atendimento também, pra vocês verem se faz sentido, no momento da carreira de vocês, entrar pro nosso MBA, tá? Como eu falei pra vocês, grande parte da experiência que a gente tá tendo aqui, durante essa semana, é muito parecido com o que a gente faz no MBA. Então, se você acha que você está aprendendo bastante com a gente durante três dias, imagina o quanto que você vai aprender com a gente por 18 meses. Então, é um MBA focado em arquitetura de software, arquitetura de solução, DevOps, SRE, soft skills. A gente está introduzindo muita coisa de IA e semanalmente a gente tem encontros onde tem mentoria, algo mais ou menos como o que eu estava falando com o Rodrigo agora, tem muito focado em carreira, muito mentoria técnica, tem a parte de breakout rooms para networking e desenvolvimento colaborativo de um problema, como foi feito na segunda-feira, tem lives e aulas com especialistas. E não é uma live no YouTube que você fica no chat. Não, você conversa com essas pessoas. Você começa a ter acesso a pessoas que normalmente você acaba não tendo no dia a dia. E a gente tem muita gente boa que acaba participando, tá? Então, super recomendo que vocês entrem nesse link, Leonan, se você puder também colar no chat o link pra galera, ou escaneie o QR Code que eu tô passando aí. Vai ser um prazer poder bater um papo com você e entender se é o momento certo pra você também fazer. Como eu disse, muitas vezes eu falo pra uma pessoa não fazer algo caso eu ache que ela não tá no momento ideal, tá? Eu prefiro perder a venda, mas não perder a amizade, tipo isso, tá? Galera, nosso assunto hoje vai ser dividido em duas partes, como eu falei para vocês. A primeira parte a gente vai falar sobre DevOps e SRE. E a minha primeira pergunta que eu queria saber aqui, perguntar pra vocês, é, cadê meu chat que eu não tô vendo? A primeira pergunta que eu queria fazer aqui com vocês é quem aí manja de DevOps ou manja de SRE, galera? Quem aqui sabe o que é? Tá? Aí, ó, Gabriel, o John, sabe o que é? Show de bola, galera. E um ponto importante aí, tá? Quem aí não tem ideia ou não sabe, ou só ouviu falar, mas não tem nenhuma experiência com isso, tá? O Paulo Pato falou que manjar é uma coisa, mas ele foi Tech Lead em Engenharia e SRE. Show de bola, cara. Você vai dar uma aula junto com a gente hoje aqui. Show de bola, tá? Maravilha, galera. Show de bola. Pessoal, como eu falei pra vocês, tá? Os nossos bate-papos aqui, o que eu mais valorizo nesses momentos não é ficar mostrando o códigozinho pra você não é ficar ensinando como você vai fazer um negocinho legal na sua linguagem de programação o tempo todo e eu não quero fazer isso porque existem pontos que principalmente pra desenvolvedores sêniores, eu valorizo mais que são pontos conceituais de fundamentos que vão tem pontos que, principalmente pra desenvolvedores sêniores, eu valorizo mais. Que são pontos conceituais de fundamentos que vão fazer com que você saiba o que você precisa saber e aprender com calma. Então, não tem sentido eu ficar aqui ensinando terraform pra vocês. Entendeu? Não tem aqui ficando sentido eu ensinar como criar uma pipeline. Entendeu? Eu teria uma aula só sobre isso. Então, a ideia aqui é que a gente consiga ter uma visão e conceitos bem claros, nesse caso, sobre DevOps e SRE. E depois, novamente, como eu falei para vocês, a gente vai ter uma sessão somente focada em IA. Maravilha? Então, seguinte, galera, vamos lá, porque eu tenho alguns pontos importantes que eu quero trazer aqui para vocês. Vamos lá. Então, temos aqui DevOps e SRE, tá? Existe uma parada muito interessante que eu acredito que todo mundo já ouviu falar uma vez na vida, e se não ouviu falar, entende o que eu estou querendo dizer, que é SDLC. Quem aqui sabe o que é SDLC? Alguém manja o que é SDLC? Ciclo de vida, né? Software Development Life Cycle. Aê! Esse é o cara, show de bola. Software Development Life Cycle, ou seja, o ciclo de vida e desenvolvimento de um software. O ciclo de desenvolvimento de um software, normalmente, ele foca na realidade, a gente pensa muito mais na engenharia de software de forma geral. Existe muita diferença em engenharia de software para arquitetura de software, arquitetura de solução e etc. Normalmente, quando a gente pensa em engenharia de software para arquitetura de software, arquitetura de solução e etc, etc. Normalmente, quando a gente pensa em engenharia de software, a gente pensa que ela é uma disciplina, no final das contas, que abrange o desenvolvimento de software de forma geral, em todos os seus aspectos. Então, engenharia de software é o processo de forma geral de como que o software vai se comportar desde a concepção até de todas as definições, até ele estar no ar, a todos os processos, de forma geral. Então, existem muitas diferenças, então, de desenvolvedor de software e engenheiro de software. Tem muita gente que se denomina engenheiro de software, mas apenas desenvolve software. Tem muita gente que se denomina engenheiro de software, mas apenas desenvolve software. Tem coisas diferentes no meio da história. Mas uma das coisas que são importantes a gente entender, e ainda mais de forma simplificada, e está bem simplificado aqui, é a parte do software development life cycle. E principalmente como que as coisas funcionavam antigamente. A gente tinha o desenvolvedor que fazia o desenvolvimento. Aí a gente tinha uma próxima etapa que era testes, onde a gente tinha pessoal na área de QA, que vai lá e faz, roda os testes pra ver se tá tudo funcionando. Faz todos os tipos de testes que a gente pode imaginar. E depois, a gente entra pra uma outra área, tá? E essa área é a área de operações, ops, tá? E essa área de ops, ela tem algo bem interessante, tá? E eu tô falando isso como as coisas eram antes, principalmente, tá? Que é o seguinte, o que que a área de operação fazia a grosso modo build and release tá e monitoramento quem é da área de operação falar que eu só tô falando isso, que a operação só faz isso vai me xingar, mas vocês vão entender o contexto que eu tô querendo dar aqui pra vocês, tá tem um camarada que chama inclusive Greg Burrell alguém já ouviu falar nele? esse cara, inclusive ele se aposentou era um dos funcionários mais antigos da Netflix ele foi autor de um artigo da Netflix em 2018 falando sobre software development life cycle e como eles criaram uma organização interna de times da Netflix, chamada Full Cycle Developers. Foi aí que a gente se inspirou nesse nome, inclusive. E eu tive a oportunidade de bater papo com esse cara. E ele falou que por muito tempo na Netflix, a profissão dele era essa. Ele viu a Netflix crescer, tá? Ele viu a Netflix ser desde uma locadora até entregar vídeo em casa com DVD, até a Netflix começar a fazer streaming da forma como ela é hoje. E o papel dele aqui era build e release. O que significava isso? Todo dia os desenvolvedores desenvolviam, os testes eram feitos, e ele pegava o software, fazia o build, O que significava isso? Todo dia os desenvolvedores desenvolviam, os testes eram feitos, e ele pegava o software, fazia o build, via se estava funcionando o build do software, e publicava esse software. E depois ele ficava verificando se estava tudo ok, esse software no ar. Então era exatamente isso que esse cara fazia. E a área de infraestrutura, de forma geral, A área de operações, principalmente a área de operações, elas ficam muito responsáveis, responsável, por manter a infraestrutura e os softwares rodando. No final das contas, operação é isso. Manter as coisas funcionando. Manter as coisas operando. Falando bem a grosso modo, tá? Agora, o problema é que nós temos alguns pontos interessantes que eu quero trazer aqui pra você. Porque a gente entra aqui numa situação, como que eu posso dizer? Numa dicotomia, talvez, que a gente entra naquele timinho de quem é dev e quem é ops. E qual que é o grande problema aí? Nós temos duas contradições, nós temos dois problemas aí. Na realidade é, sabe aquela história, toda história tem dois lados? É mais ou menos isso que acontece com a área de dev e a área de operação. O que que acontece? O dev, o cara azulzinho aqui, ele gera instabilidade. Ou seja, cada vez que ele desenvolve um software, existe a tendência disso desestabilizar o ambiente que esse software está rodando. Porque gera bugs, comportamentos diferentes e tudo mais. Então, o que um dev faz é gerar instabilidade de forma geral. Ele busca a instabilidade porque a instabilidade é o que muda. Se algo é estável é porque ela não muda. Já a área de operação, ela preza por outra coisa, por estabilidade no sistema. Quanto menos mudança pra ele, melhor. Pro DEV, quanto mais mudança, em tese é melhor, porque ele tá fazendo o papel dele. Então a gente tem duas áreas torcendo pra outra não funcionar, vamos dizer. Não áreas torcendo pra outra não funcionar, vamos dizer. Não digo torcendo pra outra não funcionar, mas que acabam tendo objetivos ou, vamos dizer assim, conflito de interesse. Enquanto pra mim, como operação, é muito melhor você subir aquele sistema e eu monitorar e manter tudo funcionando de boas ali, eu, como desenvolvedor, vou ficar mandando sempre coisa que vai te dar dor de cabeça. Esse é o grande ponto. Então, o que acontece? A gente começa a entrar, a gente principalmente começava, mas ainda existe isso aí, num momento de algo que a gente chama de culpabilidade. O que é culpabilidade no final das contas? De quem que é a culpa? Deu ruim, fiz o deploy e deu ruim De quem é a culpa? Aí o desenvolvedor vai falar o seguinte A minha máquina funcionou Inclusive a galera de QA Fez passar os testes Então eles também funcionaram O problema é do cara de operação Aí o cara de operação vai falar o seguinte Meu amigo, antes estava funcionando e eu só fiz o deploy como eu sempre fiz antes. A culpa é do software que você mudou. E aí? De quem é a culpa? Fala aí, Guilherme, você que mora em São Paulo e morava perto de São José do Rio Preto, é isso? Cara, de quem é a culpa? Em momentos críticos nesse ponto. perto de São José do Rio Preto, é isso? Cara, de quem é a culpa? Em momentos críticos nesse ponto. Tem gente aqui falando de todo mundo, né? Normalmente a culpa é de todo mundo, tá? Mas, de forma geral, o problema é que, independente de quem é a culpa, tá? A gente, nós como os profissionais, todo mundo no final do dia tem o mesmo objetivo, de manter as coisas funcionando e garantir que o software funcione para a empresa que você trabalha e dá lucro, para ela ter sucesso, para você também ter sucesso junto com a sua empresa. Então, o que acontece? Deu um momento crítico, um culpou o outro, então, não tem jeito, vamos resolver incidentes. O cara de operação, ele não entende nada de software. O máximo que esse cara fazia por muito tempo atrás, eu não tô dizendo que era sempre, foi isso, é os caras faziam shell scripts aí, faziam uns programinhas de automação, o cara de Windows fazia aqueles arquivos .bet, lembra? E assim, o cara de desenvolvimento, ele não entende nada de infraestrutura, entendeu? Manja, então, ele não entende muito bem de banco de dados, ele não entende de servidor, ele não entende de configuração. E aí, o negócio deu ruim. Então, quando a gente entra numa situação dessa, fica muito complexo, porque a gente primeiro fica buscando culpa, e as duas áreas que estão envolvidas pra resolver esse incidente, elas se complementam, mas muitas vezes elas não se falavam. Deu pau, abriu um ticket. Quem aqui já trabalhou com essa parada de abrir tickets de suporte? Deu um ticket, eu vou abrir pra área de infra. O suporte é o que mais tem. Pois é. Tickets de suporte. Então, o mundo tá caindo, o cara da infra falava, abre um ticket que eu vou verificar, entendeu? O negócio não funcionava, o desenvol está caindo o cara da infra falava, abre um ticket que eu vou verificar, entendeu? o negócio não funcionava, o desenvolvedor fala cara, o problema é de você, deixa eu terminar minha feature aqui, depois eu dou uma olhada e o mundo caindo o ponto, o grande ponto aqui é que independente de quem é a culpa ou porque aquele incidente acabou o que que acontece? Nós temos algo que significa de tempo de falha. Tempo de falha significa dinheiro perdido, clientes fora do ar, dinheiro perdido, dinheiro perdido em todos os aspectos. Algo muito ruim. Aí, o que começa a acontecer quando a gente, toda vez que a gente faz um deploy, a gente passa por esse estresse? Quem adivinha o que acontece cada vez que você vai fazer um deploy, todo mundo fica tenso. Se fazer deploy, pra você hoje, inclusive, for algo que te dê um gelo na barriga, é porque tem coisas muito erradas acontecendo. Por quê? Porque qualquer coisa na sua vida, se existe alguma fricção, você tende a não fazer. E o que acontece no caso do deploy? Se toda vez que eu vou fazer deploy dar aquela dor de cabeça, eu vou diminuir a minha quantidade de deploys. Porque eu diminuo a quantidade de falhas. Mas eu também não consigo entregar o software na velocidade que o mercado pede, e aí a minha empresa começa a ir no mal. Mas, já que é um problema dessa forma, eu começo a falar o seguinte, eu vou fazer assim, ó, eu vou fazer o deploy, então, uma vez por mês. Ou eu vou fazer o deploy trimestral, ou eu vou fazer o deploy semestral. Qual que é o grande problema disso? O vou fazer o deploy semestral. Qual que é o grande problema disso? O problema é que quanto maior é o deploy, maior a chance de dar ruim. E se você for dar o rollback, é mais difícil dar o rollback, e se você dar o rollback, todas aquelas features que vocês planejaram por um mês, elas vão entrar e sair do ar. E só vai acumular. Sabe aquela parada de que o problema das nossas vidas é não deixar as coisas acumularem? Porque quanto mais acumula, maior vai virando uma bola de neve e as coisas acabam ficando mais complicadas. Então, quando a gente entra numa situação assim, a gente começa ter o quê? Demora a entrega de software. A gente fica coibido. Toda vez que eu vou entregar um software, dá ruim. Toda vez que eu boto o dedo na tomada, dá choque. Eu vou evitar colocar o dedo na tomada. Se falarem quantas vezes você quer botar o dedo na tomada? Todo dia ou uma vez por mês? Eu escolho uma vez por mês. E acontece exatamente assim. E baseado nisso, a gente começou a ter algo chamado de cultura DevOps. E depois a gente vai, inclusive, fazer essa discussão de DevOps é muito mais uma cultura ou uma profissão, um cargo, coisa desse tipo. Mas o fato aqui é que surgiu um movimento, tá? Dessa tal de cultura DevOps. O que isso significa, galera? A cultura DevOps, ela vem da junção de área de desenvolvimento com a área de operação, tá? O que isso significa, tá? Que, no final do dia, nós temos que pensar em três coisas aqui. Uma coisa, o dev precisa entender o mínimo de infraestrutura e operação. O cara de infra precisa entender mais sobre desenvolvimento. Mas, ao mesmo tempo, uma coisa que é extremamente importante para juntar essas duas coisas é algo chamado tooling, que no final das contas são ferramentas. Se tem uma coisa nas nossas vidas que facilitam, a nossa vida são ferramentas. Às vezes, eu moro nos Estados Unidos, eu não sei se vocês sabem, aqui nos Estados Unidos você vai comprar um bem material, ele é barato comparado ao Brasil. Mas, se você pedir para o cara vir, dar uma olhadinha na sua geladeira, é 250 dólares fácil, só para ele olhar. Entendeu? Ou seja, a mão de obra é muito cara. E às vezes, eu vejo um cara vindo aqui consertar alguma coisa aqui em casa e eu percebo que eu seria capaz de consertar aquilo mas a única diferença que eu não conseguia consertar é porque não tinha a bendita chave de fenda que o cara tinha que mexia naquele negócio e quando você tem ferramenta na sua mão, no final das contas, o jogo muda porque muita coisa você consegue automatizar. Muita coisa que dá erro o tempo todo, você automatiza. E a gente consegue automatizar essas coisas desde o lado do desenvolvedor quanto do lado da infraestrutura. Muitos desenvolvedores já falam, ah, mas eu sempre automatizei minhas tarefas. E os caras de infra sempre falaram, eu também sempre automatizei minhas coisas, sempre tive os meus scripts. Não, cara, não é esse tipo de ferramenta. A gente está falando realmente de ferramentas, entre aspas, profissionais. O que são ferramentas profissionais? São ferramentas com objetivos extremamente específicos, que são mantidos por times, que tem documentação, são ferramentas que tem, que muitas vezes podem ser podem fazer parte de uma composição de diversas ferramentas trabalhando junto. Uma vez que a gente começa a perceber que ferramenta é algo importante a gente começa a entender que o desenvolvedor, ele tem que entender o mínimo de infraestrutura, cara. Se você é desenvolvedor hoje, você nunca criou uma máquina virtual, nunca criou uma conta na AWS, no Google, na Azure, cara, assim, com todo o respeito do mundo, e eu sei que cada um tem seu contexto, cara, mas assim, você está 10 anos atrasado, 10 anos, mais de 10 anos atrasado, tá? Se você não sabe subir uma máquina virtual, hoje em dia, se você não sabe trabalhar com containers, tá? Se você não sabe trabalhar com containers, são 10 anos de atraso, de 7 a 10 anos de atraso, tá? Então, o que que acontece? A gente precisa entender dessas coisas. Não é mais coisa só de infraestrutura, porque se tem alguém que pode entender o erro de alguma coisa quando dá pau, é o desenvolvedor que fez o negócio. O cara de infra, por mais que ele comece entendendo cada vez mais sobre desenvolvimento, esse cara jamais vai ser capaz de fazer um debugging da sua aplicação. Mas, o grande ponto é, ele também tem que conseguir navegar nesse mundo. E uma vez que você começa a ter ferramentas, você começa a ter possibilidades de criar o quê? Processos. Se tem uma coisa nas nossas vidas, e eu acredito que todo mundo sabe, a gente consegue se ligar, são processos. Então, o que começou a acontecer? Os processos de desenvolvimento e de distribuição e de implantação de softwares, eles começaram a ser automatizados. As pessoas começaram a pensar, ok, esse software development lifecycle, a gente vai mudar. A gente vai tentar fazer isso de uma forma muito mais sistemática, onde todas as partes tenham conhecimento do que está acontecendo desse processo. Ou seja, todo mundo tem essa responsabilidade. Então, o que acontece? O desenvolvedor, de forma geral, ele tem que conseguir ter um ambiente de desenvolvimento o mais próximo possível com o ambiente de produção. Ele tem que conseguir fazer os testes da aplicação dele de uma forma muito mais automatizada. Quanto mais você testa de forma automatizada, você tem menos risco de repetir e esquecer de fazer um teste. O que acontece aí no meio dessa história? Eu faço o desenvolvimento e hoje em dia, né, a gente acaba entrando num processo de uma esteira. A gente fala isso de chamado de pipeline. Eu acredito que muitos que já trabalham no dia a dia, eu posso estar, inclusive, um pouco chovendo no molhado, mas eu preciso seguir essa linha de raciocínio, tá? E o que que são essas pipelines no final das contas? São esteiras que têm diversos passos. Normalmente a gente chama isso de pipelines de CI e CD. O que isso significa? Você subiu o seu software, o seu software vai entrar num processo de build, ele vai realizar os testes, vai fazer verificações de segurança, ele vai verificar se o build deu tudo certo e depois eu posso fazer o release, a implantação, o deploy dessa parada toda. E uma vez que esse cara vai para o ar, nós temos algo que a gente chama de monitoramento e observabilidade. São coisas diferentes, inclusive, depois a gente pode falar sobre isso. Então, o grande ponto é que o dev tendo um ambiente mais próximo de produção, testando as coisas de forma mais automatizada, a gente tendo ferramentas que possibilitam a gente fazer essa esteira da melhor forma possível, e tanto o desenvolvedor quanto a pessoa de operação serem responsáveis, corresponsáveis em monitorar e observar a aplicação, aí a gente começa a falar a mesma língua. Porque quando dá um problema, o desenvolvedor tem que saber imediatamente que o software que ele é responsável está dando pau. Não tem essa jogar na costa de outra pessoa. E o cara de infra também não adianta jogar. Então, quando a gente junta essa cultura, todo mundo é dono desse processo, tá? Isso aí é uma das coisas mais importantes que tem. E essa parte de tooling é uma das coisas que possibilita que esse ambiente acabe trabalhando. O grande ponto que acontece, começa a acontecer, quando essa cultura começa a ser implantada, é que eu começo a ter desenvolvedores que gostaram pra caramba dessa paradinha aqui. E os desenvolvedores gostaram tanto dessa paradinha que eles começam a criar ferramentas pra isso. Da mesma forma, tem caras de infra que adoraram essa paradinha aqui, e os caras começaram a fazer o que? também, se especializar cada vez mais a partir daí surgiu o cargo de DevOps então quando alguém fala que DevOps é uma cultura e tudo mais, sim, ela é uma cultura, ela nasceu como uma cultura mas hoje em dia existem especialidades de desenvolvedores e pessoas de infraestrutura pra trabalhar especificamente com isso. Com essas ferramentas. E é por isso que começaram a ter cargos como engenheiro DevOps. Não sei o que de DevOps. Não sei o que de DevOps. Por quê? Porque o cara é desenvolvedor, como qualquer um é, mas ele é um desenvolvedor que ele entende muito bem de, sei lá, mexer num Terraform, num Ansible, ele consegue criar pipelines de CICD como ninguém, ele entende de, sei lá, mexer com Jenkins, com GitHub Actions, ele entende ferramentas de segurança, ele consegue fazer, passar por gates de análise estática de código, ele consegue criar automações. Então, o que começa a acontecer, a mexer nessa parada, é muito diferente, tá? E por favor, galera, não confunda isso como Platform Engineer, que essa é uma outra história também. Platform Engineer não é que não tem nada a ver com DevOps, tá? Mas uma pessoa de DevOps, tá? Não é necessariamente um Platform Engineer, tá? Essa foi uma, é um outro problema que o nosso mercado tem e que gera muita e muita confusão nos dias de hoje, tá? Então, não é porque você especializa nas ferramentas que você é um platform engineer, tá? E eu digo isso não porque eu sou o cara de falar isso, não, porque eu conheço e trabalho e tenho contato diário com amizade pessoal mesmo, com um dos caras que tomam conta da uma das maiores plataformas de desenvolvimento aí do mundo hoje em dia, que é a do mercado livre. Entendeu? Que chama Fury. Então, se tem alguém que manja de falar sobre Platform Engineering, né? Ou Internal Development Platform, que é o que o Fury é, é esse cara. E quando você conhece, conversa com ele, você olha e fala, caraca, eu entendi tudo errado. Então, pessoal, não confunda também DevOps ou por que você mexe nisso, você é um Platform Engineer. Então, é importante vocês conseguirem entender esse cara aí. Então, o lance é o seguinte, uma vez que eu tenho esse cargo DevOps, eu começo a ter desenvolvedores que começam a entender mais sobre isso. O grande ponto é que isso aqui faz com que nós tenhamos o quê? Tenhamos o quê? Um processo claro de implantação. Ou seja, um processo claro de deploy. Agora, quais são esses principais pontos que a gente tem que levar em consideração quando a gente acaba caindo aqui? Uma das coisas que desenvolvedores mandam muito mal, adivinha o que é? Segurança. Fala a verdade, galera. Vocês que são desenvolvedores aqui. Quem fala assim, cara, eu manjo pra caramba de segurança? Fala a verdade. Quem tem coragem de bater no peito e fala que manja bem de segurança? Cara, na real, velho, eu não bato no peito, eu tenho, eu acho que eu tô ofendendo uma pessoa que manja de segurança, entendeu? Se eu falar que eu manjo. É mais ou menos isso, entendeu? Mas, o que que acontece? Conforme o tempo vai passando, a gente começa a se ligar que dentro dessa esteira ou em diversos processos, eu poderia incluir vários checkpoints na área de segurança. E daí, a gente começou a ter um novo termo no meio dessa história. ter um novo termo no meio dessa história. E esse novo termo no meio dessa história é chamado de DevSecOps. Então agora é a área de desenvolvimento, junto com a área de segurança, junto com a área de operação. E na hora que a gente começa a entrar nessa área, a gente começa a ter acesso a diferentes tipos também de ferramentas com objetivos diferentes. E nesse caso aí, a gente acaba tendo ferramentas como essas, ferramentas de SAST, que é Static Application Security Testing. A gente chama isso de White Box. O que isso significa no final das contas? Eu olho o seu código baseado em tudo aquilo, mesmo sem executá-lo, eu consigo fazer verificações. Black Box, como DAST, por exemplo, eu consigo ver o comportamento da sua aplicação, de forma geral, pra verificar se ela consegue ter essas vulnerabilidades e eu tenho IAST que é Interactive Application Security Testing, que acaba sendo uma meio que junção de SAST com DAST, e hoje em dia a gente tem agentes e as paradas começam a entrar com toda essa parte de IA que consegue fazer milhares de coisas agora pra fazer o monitoramento, para fazer as tentativas de exploração de falhas e tudo mais. Então, quando a gente começa a olhar, tudo que acaba entrando dentro de um processo fica facilito, dá um pouco mais a nossa vida. Agora, ainda assim, tudo isso que a gente está falando acaba trabalhando com processos o ponto é que as aplicações elas começam a crescer, a gente começa a trabalhar com micro serviços e a gente começa a perceber que eu não vou ter mais uma máquina virtual para subir uma aplicação eu vou começar a trabalhar com containers, mas se eu começo a ter um monte de containers, o que a gente começa a ter problemas? De gerenciamento de todos esses containers. E no meio dessa história, começam a surgir mais ferramentas que vão nos ajudar em relação à parte de infraestrutura. E uma dessas ferramentas, hoje em dia, que a gente tem que se ligar, é, por exemplo um Kubernetes da vida por que que eu estou dizendo isso? hoje em dia a gente já está no mundo dos containers quem aqui não trabalha com container hoje em dia? quem aqui não mexe com docker? não trabalha com docker na empresa que você utiliza, não trabalha com o Docker na empresa que você utiliza, que você trabalha? Assim, hoje em dia, se por conta da estrutura organizacional da sua empresa, por conta da infraestrutura da sua empresa, da forma como elas são, elas não trabalham ainda com containers, paciência, porque às vezes uma empresa muito grande, ela anda devagar, tem muita coisa rodando e é complexo. Mas você como desenvolvedor, o que acontece no meio dessa história? Você é obrigado a saber containers, nem que você trabalhe isso, trabalhe desenvolvendo em ambiente local. Mas a grande sacada é que quando a gente entra com um cara desse, como um Kubernetes da vida, ele é uma plataforma que faz a gestão desses containers para a gente. Ele é um orquestrador de containers com superpoderes na realidade. E no final das contas, o que ele faz é, ele mantém a padronização. Ou seja, na hora que eu vou fazer a implantação da minha aplicação, simplesmente o que acontece é que um novo pod, como se... Uma unidade do Kubernetes que roda um containers dentro sobe e o deploy está feito. De uma forma muito mais tranquila, muito mais organizada, com muito mais gerenciamento e tudo mais. E o que acontece? O ponto é que, por exemplo, para você ter um cluster Kubernetes, você precisa entender de rede para criar uma rede. Você vai trabalhar, por exemplo, vai criar lá uma infraestrutura na AWS. O que a gente precisa fazer? Criar uma rede. Falem para mim, galera, o que a gente precisa para criar uma infra aí na AWS? Se você for começar do zero hoje em dia. Digam aí para mim. VPC, subnet, grupo de segurança. Bunk, TS3. Bunked, S3 Calma aí, isso aí é pra armazenamento de arquivos Falando em infraestrutura mesmo, teve gente que começou falando ó, eu preciso criar uma VPC depois da VPC eu preciso criar as minhas subnets aí nas minhas subnets eu preciso criar as minhas rotas aí eu posso eu tenho depois das rotas, eu tenho que botar, por exemplo, um internet gateway pra ter acesso externo e assim as coisas vão indo. Ok? E o DNS no Route 53? DNS vai tendo tudo esse tipo de coisa. Né? Mas, daí, o que que começa a acontecer? A gente tem a interface da AWS a gente tem a interface do GCP a gente tem a interface do Azure e qual que é a primeira coisa que a gente faz, nasce uma nova profissão e essa profissão é chamada de ClickOps, alguém já ouviu falar no ClickOps? o ClickOps esse cara, ele funciona da seguinte forma. Você fala, sobe uma infra aí pra mim, pra eu botar uma nova aplicação pra rodar, aí o cara ele vai lá, faz o login na AWS, no GCP, vai lá em ECS, ou na ECS não, ele vai em VPCs, daí ele cria uma nova VPC, daí ele clica lá, criar subnets, aí ele digita a faixa de IPs, daí ele cria a rota, e ele vai dando um monte de clique, um trilhão de cliques, até ele subir lá uma máquina, sei lá, um EC2, e daí ele vai, coisada, ele faz o download da chave, e não sei o quê. Ou seja, esse cara é o cara do ClickOps. Resumindo, ele consegue criar tudo, o ClickOps. Mas o problema do ClickOps é que essa parada não é reproduzível. O que significa isso? Para eu reproduzir isso exatamente da mesma forma, dá um puta trabalho. E a chance de eu errar isso é maior ainda. Entendeu? E quando você tem uma máquina rodando ou alguma coisa assim, ok, cara, você dá meia dúzia de cliques. Se eu tenho um negócio simples lá, eu vou lá, crio cluster, mudo um nó, faço alguma coisa. Mas quando a gente tá falando em empresas grandes, e eu acredito que todo mundo de vocês aqui ou trabalham em empresas maiores ou querem trabalhar nessas empresas, não dá para viver com o click ops. O click ops é algo que gera falha, porque é manual. E tudo que é manual a gente erra ao reproduzir uma vez ou outra. Às vezes você erra a mira. E conforme essas coisas vão acontecendo, né? o que que vai surgir o que que vai nos ajudar no meio dessa história? a gente começa a ir pra um outro mundo quando a gente começa a perceber que o click ops não é uma boa prática a gente vai pro outro mundo chamado de IAC, que é Infra S Code, que significa no final das contas o seguinte, através de código, normalmente declarativo, eu vou fazer o seguinte, eu vou criar a minha infraestrutura. Como se fosse um script, na realidade. Na realidade, acaba sendo um script na realidade, na realidade acaba sendo um script de forma geral então eu posso fazer isso de forma declarativa, eu posso criar código eu posso no meio dessa história, eu posso controlar a minha infraestrutura utilizando o git vamos imaginar o seguinte galera, eu quero criar minha infraestrutura eu tenho um script, depois a gente pode falar de ferramentas como terraform da vida vamos imaginar o seguinte, galera, eu quero criar minha infraestrutura, eu tenho um script, depois a gente pode falar de ferramentas, como um terraform da vida, mas eu falo o que eu quero, dou um enter, dou um apply, e a minha infraestrutura sobe, que nem uma mágica. Aí alguém fala, Wesley, eu preciso de mais um cluster, ou eu preciso de mais uma rede, o que eu vou fazer? Eu tenho esse meu código no GitHub eu dou um pull altero o código, dou um commit faço uma pull request alguém vai lá revisa a minha pull request e dá um merge, quando ela dá um merge a gente tem uma pipeline de CICD para a sua infraestrutura então antig, a gente tem uma pipeline de CICD para a sua infraestrutura. Então, antigamente, a gente tinha pipelines para fazer o deploy do nosso código. Hoje, a gente tem pipelines para fazer a mudança da nossa infraestrutura. Então, o que isso acontece? A mudança na infraestrutura, ela permite que você tenha reproducibilidade, se essa palavra existir. Ou seja, eu tenho essas esteiras. Com um comando, eu tenho o poder de subir uma infraestrutura extremamente complexa. Então, isso aí é uma coisa interessante. Agora, é importante, tá? Vocês entenderem rapidamente um conceito. E vocês sabem que uma das coisas que eu fico batendo o pé o tempo inteiro é falando de conceito. Então, quando a gente está falando em infra, as code, existem coisas interessantes aqui que é importante vocês entenderem, tá? Quando eu trabalho de forma declarativa, tá? Eu falo em estado. O que que isso significa? Hoje o estado da minha infraestrutura é que eu tenho uma VPC, eu tenho isso, eu tenho aquilo e etc. Eu falo, eu quero quatro máquinas. Então, nesse momento, ela vai lá e cria quatro máquinas pra mim. Tá? O que que isso faz? Faz com que eu entenda o estado atual da minha infraestrutura e veja que eu tenho, por exemplo, três máquinas. E se eu tô pedindo quatro agora, eu vou adicionar apenas uma. Tá? Então, isso aí é algo importante. E pra isso, a gente tem ferramentas muito interessantes que trabalham dessa forma, como o Terraform. Terraform, ele tem scripts, arquivos que a gente chama de HCL, né? HashCorp. HashCorp, meu Deus do céu. Alguma coisa além, meu Deus do céu, cara. Passando vergonha, por favor, escrevam aí pra mim. E a gente tem a forma imperativa, tá? O que é a forma imperativa? Eu falo, eu quero quatro máquinas. Ele vai lá, executa um script e sobe quatro máquinas pra mim. Se eu falo de novo pra ele quatro máquinas, ele vai criar mais uma, mais quatro máquinas, tá? Ou seja, ele trabalha... Ele não máquinas, tá? Ou seja, ele trabalha, ele não consegue necessariamente ficar vendo o estado da sua operação, tá? HashCorp Configuration Language, pelo amor de Deus. Então, o que que acontece? Existem ferramentas, até mesmo os scripts da WS, CLI ou GCloud, por exemplo, você consegue, de forma imperativa, pedir o recurso que você quer. Ou você tem softwares como o Ansible da vida, que grande parte dele também trabalha de forma imperativa, ou seja ele não tem algo que a gente chama de idempotência, que é conseguir verificar o que você já tem baseado naquele estado e fazer somente as alterações que você quer, tá? Então essa que é a ideia. Então, agora, a gente, além do cara de dev entender mais de infraestrutura, o cara de ops também consegue programar a infraestrutura dele. E isso aí é super interessante para a gente conseguir entender, pessoal. Agora, uma coisa que acaba também gerando todo esse processo, tá? É que a gente, nós somos pessoas mais felizes. Porque agora eu tenho, eu consigo reproduzir as coisas. Eu tenho áreas conversando. Eu tenho esteiras que verificam segurança. Eu tenho padronização na minha infraestrutura. Eu abandono o click ops da minha vida. Entendeu? O click ops não pertence mais. Eu trabalho com infraestrutura S-code. A gente tem coisa que a gente chama de GitOps, onde o centro da verdade da sua operação está no Git. Você tem ferramentas que verificam se o seu manifesto do Git mudou e se ele muda, ele aplica automaticamente pra você. Isso tem tudo no MBA, tá, galera? Só pra vocês saberem, tá? Tudo isso que eu tô falando tem no MBA. só pra vocês saberem, tá? tudo isso que eu tô falando tem no MBA mas, tirando o jabá de lado a gente começa a entrar tá? numa outra seara aqui sabe qual é? a gente começa a entrar em algo que a gente chama de confiabilidade tá? e aí a gente começa a entrar num aspecto que é o seguinte o sistema que você tem hoje no ar ele é confiável? aí de forma geral você pensa, bom desenvolvimento, passou pela CICD passou por segurança, eu tenho todos os processos automatizados, observe etc maravilha, meu sistema é confiável. Mas o problema é que confiabilidade é algo muito complexo. Pra você conseguir verificar se algo é confiável. Tá? E por conta disso, começou a surgir um outro entre as, eu não vou chamar de movimento, começou a entrar mais uma área, tá? No mundo de movimento, que inclusive veio através da Google, tá? Que é chamada de SRE. Tá? SRE, de forma geral, galera, foca em confiabilidade o que que isso significa? confiabilidade foca em que independente de qualquer coisa o meu software ele tem que tá no ar tá? e pra eu falar isso eu tenho que ser muito bom no que eu tô fazendo porque independente de qualquer coisa eu preciso confiar que o meu site que o meu sistema, que o meu microserviço que a minha infraestrutura que os meus clientes, que a minha operação ela vai estar no ar entendeu e muitas pessoas que os meus clientes caminham operação. Ela vai estar no ar. Entendeu? E... Muitas pessoas começaram a tentar entender o que é SRE. O que significa Site Reliability Engineering. Ou seja, como que você tem práticas de confiabilidade baseado em tudo que permeia o ecossistema de onde você trabalha. E o que isso na prática significa? Isso na prática significa, tá? Significa que quando eu estou falando em SRE, eu quero pensar na minha aplicação, na confiabilidade daquilo que eu tenho, em todos os aspectos, tá? Então o que acontece? Para eu conseguir garantir que um software é confiável, eu tenho que ter métricas muito claras. Eu tenho que saber quais são as métricas que definem para mim o quão confiável aquilo que é. Por outro lado, quanto maior o nível de confiabilidade que eu gero, maior é o custo. Então, muitas das decisões que vêm da área de SRE, elas têm a ver também com decisões importantes de negócio. Então, eu começo a focar em alguns parâmetros importantes que a área de SRE começa a definir. A primeira coisa que ela começa a definir é qual é o meu objetivo em relação àquele meu software, tô falando de um software mas poderia ser de um ecossistema inteiro aí o meu objetivo é o seguinte eu quero garantir disponibilidade em x% e isso vai permitir que o meu objetivo faça com que o meu software ele possa ficar fora do ar por 30 minutos no ano. Isso é chamado de SLO, que é Service Level Objectives. O que isso significa? Que são os meus objetivos de nível de serviço. Porém, quando eu fecho o contrato com o meu cliente, eu vou lá e vou fazer um contrato. E esse contrato, normalmente, a gente chama de SLA, que é Service Level Agreement. O que isso significa? É o quanto eu prometo para o cliente que eu tenho de confiabilidade, que eu vou manter a minha garantia no ar. Normalmente, a área de SRE seta um objetivo maior, para que ela tenha, vamos dizer assim, créditos em relação ao SLA. Por exemplo, se eu vou garantir no SLA 90% de disponibilidade, no meu SLO eu vou colocar 95%. Eu vou mirar num objetivo mais alto do que o meu SLA. E a gente tem um outro cara que a gente chama de error budget. E o que é Error Budget? É o orçamento que você tem, vamos dizer assim, de créditos em relação à disponibilidade do seu sistema. Por exemplo, eu falei que o meu SLO, eu posso ficar 30 minutos por ano. Eu fiquei 10. Wesley, você só tem 20 agora, meu amigo. Toma cuidado. Entendeu o que é o Euro Budget? Ou seja, você tem uma métrica clara de qual que era o meu objetivo e baseado nesse objetivo, quanto ali já foi pro saco. Quanto que eu tenho essa parada, tá? E depois disso, nós temos uma outra coisa que a gente chama de Dora Metrics, e depois eu vou falar com você sobre isso mais claro, tá? Então, um ponto interessante que vocês comecem a perceber é que SRE, para que consiga garantir esse cara no ar, essas métricas, toda essa confiabilidade, esse cara precisa, vocês concordam comigo, entender dessa parada. Porque se tem um lugar onde pode dar problema para afetar a minha confiabilidade, é no meu processo de CICD, infraestrutura, meu monitoramento, como que eu consigo verificar se eu estou cumprindo o meu SLA? Cara, eu preciso ter ferramentas de observabilidade que vão mostrando pra mim quantos incidentes eu tive, quanto tempo ficou fora do ar, pra que esses números comecem a fechar. Então, uma pessoa que trabalha na área de SRE, de forma geral, ela entende de DevOps. Tá? Porque faz parte do trabalho dela esse processo. Entende o que eu estou querendo dizer? A pessoa de SRE, o foco dela não é o DevOps. O foco da pessoa de SRE não necessariamente é ser o cara de montar a sua pipeline. Mas como montar uma pipeline pode afetar a confiabilidade do meu software, como montar uma pipeline pode afetar a confiabilidade do meu software, eu como um cara de SRE, provavelmente eu vou fazer parte do processo de criar essa pipeline. Entende? Entende? Então, existe uma diferença brutal entre DevOps e SRE. Eles têm sim uma intersecção. Mas, o que eu vejo muito no mercado hoje é alguém falar, ah, eu trabalho como DevOps e SRE. Cara, toma muito cuidado quando alguém fala exatamente isso pra você. Normalmente, existe uma chance dessa pessoa não saber a diferença de uma coisa com outra. Confiabilidade faz... O DevOps faz parte da área de confiabilidade. Mas não necessariamente confiabilidade faz necessariamente parte da área de DevOps. Eu vou dar um exemplo bem claro aqui para vocês, onde eu vou deixar isso um pouco mais claro aqui para vocês, em relação à SRE. Olha só, eu tenho o meu software aqui. E aí, eu tenho o meu e-commerce, na hora que alguém vai fazer uma compra, o gateway de pagamento está fora do ar. O que o desenvolvedor vai falar naquele momento? Ele vai falar, a culpa não é minha, a culpa é do PayPal, é do Pagar.me, é do Stripe, não interessa. Não sou eu que tenho culpa. Eu faço o que está no meu alcance. Mas se o Gateway cair, ferrou. Entendeu? Esse é o grande ponto. Agora, você, o seu cliente, a Amazon, o Mercado Livre, não sei quem, o cliente final que está comprando o produto, ele fala, não consigo comprar meu produto, mas a culpa não é deles, a culpa é do gateway de pagamento, cara, não existe isso, você entendeu? Então quando algo desse tipo acontece e o problema não está no código o problema não está no CI e no CD o problema é externo e esse problema da pau isso aqui é um problema de confiabilidade porque apesar de o meu software está desenvolvido certo ele não é confiável porque apesar de o meu software estar desenvolvido certo ele não é confiável porque ele depende de um cara que se tiver fora do ar vai fazer com que eu perca as minhas vendas e o cliente final não quer saber se o meu problema está no meu software ou se está no gateway de pagamento ele só queria fazer a compra dele tá? a culpa disso aqui é da empresa Ou se está no gateway de pagamento, ele só queria fazer a compra dele. A culpa disso aqui é da empresa. Porque ela não tem dois gateways de pagamento. O que o cara de SRE nesse momento vai olhar e vai falar? Estamos com um problema de confiabilidade aqui. Porque nós só temos um gateway de pagamento. Vamos ter um fallback aqui para esse segundo gateway de pagamento vamos ter um fallback aqui pra esse gateway pra esse segundo gateway de pagamento tá? e aí eu aumentei a minha confiabilidade vamos botar mais um fallback mais um fallback começa a ficar caro eu fazer convênio com um monte de gateway de pagamento e fazendo implementações com um monte de gateway de pagamento concordam comigo? aí eu tenho que gerenciar custo-benefício. Começa a virar também decisão de negócio. Então você consegue perceber que isso aqui não tem nada a ver com DevOps, mas tem tudo a ver com SRE? Vocês conseguem perceber que SRE é algo muito mais amplo do que o DevOps? Uma pessoa, entre aspas, de DevOps, não necessariamente se preocupa por arrumar esse processo. Porque ela está muito mais focada em processos de entrega e operação do software dele. em processos de entrega e operação do software dele. O cara de SRE tem uma análise mais estratégica. Ele tem análises mais de negócio. Isso significa que um cara que trabalha bem com DevOps também não pode ser de SRE? Com certeza. Provavelmente, a maioria das pessoas que trabalham com SRE são, vamos dizer, caras também de DevOps. Mas não necessariamente uma pessoa de DevOps é uma pessoa de SRE. Então, isso aí é um ponto importante. O SRE, a área de SRE, ela culpa processos e entendimento de problemas. O que a área de SRE ali, ela não está querendo encontrar e falar que o problema é o Rafael que fez o código errado. E daí o código do Rafael foi em produção. Ela está falando, como que pode um código errado ter ido para a produção? Porque o Rafael vai fazer de novo isso. Né, Rafael? Você não faz erro aí, Rafael? O tempo inteiro fazendo bug no sistema dos outros. Você mesmo de óculos, eu sei. Mas o ponto é, como que um erro conseguiu ir pra produção? foi pra produção porque tem problema em processo aí o cara de SRE vai olhar ok, deixa eu rever esse meu processo pra evitar que quando o Rafael suba um sistema nessa situação essa parada não vá parar em produção entendeu? então isso aí é algo extremamente importante, porque eu estou verificando processos, eu estou entendendo problemas. Um tempo atrás, eu tive uma reunião, cara, e foi muito bom, porque eu tive uma aula fantástica. Sabe aquela reunião que você participa, mas no final das contas, ela foi muito mais uma aula para você do que uma reunião. Foi o que aconteceu. Eu tenho alguns amigos que trabalham na Google. E o meu melhor amigo que trabalha na Google é o Fernando, é amigo pessoal meu. E ele também dá aulas aqui no MBA. E ele é líder de SRE da América Latina. E ele é líder de SRE da América Latina. Mas, eu ia participar de uma talk de SRE, a gente ia fazer um evento, era alguma coisa assim, e ele falou, cara, vamos alinhar algumas coisas de SRE, eu vou trazer um cara aqui para ajudar a gente em uma reunião. E daí ele trouxe um cara que, adivinha, ele era SRE de qual área da Google? Google Search. Resumindo a história, o objetivo dele é fazer com que o google.com não caia do ar. E acredite, dá muita coisa ruim para que força o Google querer cair do ar. Mas imagina o nível de responsabilidade. Quando eu tive reunião com esse cara, o que ele me falou e ficou muito na minha cabeça sempre é eu não estou preocupado de quem é a culpa, eu estou preocupado de como aconteceu aquilo. Se foi culpa de alguém, não interessa. A pior coisa que uma empresa pode fazer é enfiar o dedo na cara e falar, a culpa foi sua. A culpa é do processo, porque pessoas sempre vão errar. A importância do SRE, no final do dia, é fazer com que o processo funcione e que eu possa confiar naquilo que eu estou prometendo que eu vou entregar. É basicamente isso. Então, quando você acaba, de forma geral, tendo uma aula com o cara, de um dos caras que toma conta forte do Google Search, explicando para você o que é SRE, dando muitos exemplos, cara, a minha cabeça mudou bastante, porque eu ficava pensando muito em coisa técnica na hora que eu pensava em SRE. E existem muitos caras de SRE que os caras passam muito tempo em planilha de Excel, que passam muito tempo em PowerPoint, mapeando o processo, entendendo o negócio, criando documentações, fazendo uma pancada de coisa, verificando o orçamento, verificando um monte de coisa para garantir o aumento de confiabilidade no sistema. Opa, eu estou conseguindo 99,9%. Será que eu consigo botar mais um 9 aí, sem gastar muito mais? Você entende que esse tipo de coisa não é alguém de DevOps que vai fazer. O cara de DevOps, ele não para necessariamente pra olhar com intenção a tudo isso. Você entende? Tudo é uma questão de intencionalidade. O cara de SRE, ele precisa ter a intenção de entender diversos tipos de processo para garantir a parada confiável, incluindo a parte de DevOps. Fez sentido isso aí pra vocês, pessoal? Fez sentido, galera? Alguém tem uma dúvida? Alguém quer falar? Fazer algum comentário só pra eu não ficar no monólogo? Tem muito sentido, sim. Dúvidas, comentários em cima disso? eu tenho Wesley manda meu amigo, falei tão mal de você aqui, né? você tem que soltar o vereninho agora, né? eu te perguntar sobre esse SRE, você falou tipo uma área como se fosse assim um time separado, como que fica isso no dia a dia? Por exemplo, eu trabalho num sistema grande, mas essas responsabilidades de cuidar desse sistema, será que os devs, na hora de planejar uma atividade, a gente, na hora de desenvolver uma funcionalidade, tem que estar em contato com eles, ou a gente também teria que ter essa autonomia para tomar essas decisões e só quando é algo mais crítico ou passa por algum problema que a gente buscaria a ajuda de especialistas? Bom, vamos lá. Primeira coisa, você vai ouvir muito falar de SRE como uma disciplina de engenharia. E aí você pode entender SRE como uma disciplina de engenharia de confiabilidade, você pode considerar que SRE, dependendo da empresa, pode ser uma área de SRE, e dependendo da situação, você pode falar que tem a pessoa de SRE. E na minha opinião, as três formas de falar isso estão válidas. É muito comum aquele cara de SRE, entendeu? E daí um dia eu falei isso e o cara falou meu, você não fala que um cara é de SRE e não sei o que. Eu falei assim, tá bom, ok, beleza. Daí a primeira coisa que eu faço na reunião com um monte de cara de SRE da Google, ele fala, ô, esse aqui é o nosso SRE dessa parte, entendeu? Como é que funciona galera, a gente tem que tomar cuidado porque eu falo muito da Google nesse caso especificamente da Google, porque foi ela que soltou o termo, existe um livro de SRE gratuito na internet depois baixem, chama site reliability engineer eu passo o link pra vocês, tá então, como é que funciona aí o Rafael, depende da empresa tá, o SRE ele não é um Deus, tá, ou qualquer Então, como é que funciona aí, Rafael? Depende da empresa. O SRE não é um deus ou qualquer coisa desse tipo. O que você tem que entender é que o SRE não está preocupado apenas com a parte técnica. Eu vou dar um exemplo para vocês. Está numa Black Friday. Será que a Black Friday muda algum ponto da minha operação no dia a dia quais são os riscos que eu tenho como que isso trabalha, cara, se eu tenho uma área de SRE, uma pessoa em SRE essa pessoa, ela vai trabalhar intencionalmente pra entender quais são os riscos processos de prevenção e coisas desse tipo para esse tipo de determinado de evento. Não que o dev não deva fazer isso, ele tem que fazer, inclusive. Um desenvolvedor tem que ser cada vez mais independente, entender mais do processo, pensar em confiabilidade. Mas o desenvolvedor tem que desenvolver, ele tem que testar, ele tem que falar com o cliente, ele tem que entender a área de produto, ele tem que desenvolver, ele tem que testar, ele tem que falar com o cliente, ele tem que entender a área de produto, ele tem que pensar na interface. O cara de SRE, a intencionalidade dele é muito maior na confiabilidade. Sabe aquela parada? Eu tenho um médico clínico geral, ele vai olhar pra um todo. Eu tenho um cardiologista, intencionalmente ele vai olhar no seu coração. Entendeu? intencionalmente ele vai olhar no seu coração entendeu? então, quando a gente fala em relação a isso Rafael, eu digo o seguinte depende da cultura empresarial, depende da empresa, as vezes você tem uma pessoa no seu time que também é de SRE, as vezes você tem um departamento de SRE as vezes você tem um cara de SRE na empresa inteira. Então, depende muito, porque cada empresa trabalha de uma forma muito diferente. Então, mas de forma geral, se você sabe que existe uma pessoa de SRE e você fala, cara, eu acho que isso aqui pode dar ruim, você senta com ele, esse cara vai ajudar a pensar de uma forma mais ampla, porque ele de forma geral, normalmente ele tem uma visão um pouco mais ampla que um desenvolvedor tem, as vezes o desenvolvedor toma conta de um, dois microserviços num time de oito pessoas as vezes o cara de SRE, ele tá olhando 50 microserviços e o seu é só uma parte dos microserviços que ele está olhando. Fez sentido para vocês, galera? Sim. Maravilha. Galera, só por curiosidade, quem aqui tinha uma visão diferente de SRE? Ou que tinha alguma... Ou tinha uma confusão mental da diferença dos dois entre DevOps e SRE? Eu tinha. Eu tinha. Para mim, o SRE e o DevOps eram meio que a mesma pessoa, dependendo da empresa. Mas aí, talvez eu entenda direito. O DevOps é o cara que é responsável por operar o sistema. Então, deu qualquer cagada lá, ele é obrigado a se virar, colocar o sistema de pé e resolver o que está acontecendo. Nesse exemplo que você viu do gateway de pagamento, o DevOps não teria muito o que fazer. Então, você fala, cara, se o sistema não suporta dois gateways, o sistema vai cair porque o gateway caiu. E é isso aí, paciência. O SRE, ele é o cara que tem que pegar esse problema e ir lá no time de dev e falar assim, gente, então, vocês têm que implementar um segundo gateway aí, porque o dia que o gateway cair, o nosso sistema não pode cair. E ele tem que correr não atrás da operação, ele tem que correr atrás da causa do problema e garantir que isso não aconteça de novo. Exatamente. E ele vai pro dev, ele vai pro gerente, ele vai pro diretor que vai ter que fechar um contrato com outro gateway, porque ele tem que negociar taxas, ver qual é o gateway que vai colocar, entender, pesquisar o cara. E daí, como ele manja disso, ele vai para a área de DevOps, ou ele também pode atuar entre aços como DevOps. E daí, lá nas métricas dele, lá na parte de observabilidade, ele fala, opa, esse é um caso real, tá? Que eu já vou falar, eu gosto de contar histórias, tá? Um dos caras que é principal hoje do Mercado Livre, tá? E eu vou pedir pra ele vir dar uma talk pra gente também no MBA. Inclusive, ele é aluno do nosso MBA, cara. Pra vocês verem como é que eu tô chique, hein? Eu acho que o Mercado Livre, tá, pessoal? Tem, eu acho que, perto de 15 mil desenvolvedores. Só pra vocês terem uma ideia, tá? Eles têm 100 milhões de requisições por minuto. 30 mil microserviços. Então, é uma operação bem pesada. E eu acho que tem quatro principals de engenheiro inteiro no Mercado Livre e ele é um deles. O cara chama Valmir. E ele e um outro cara um dia me contaram... Cara, será que foi o Valmir que me contou? Às vezes eu tô contando até mentira. Cara, não tenho certeza mais. Mas eu acho que foi o Valmir. Logo quando eles estavam, se não me engano, fazendo entrevista pra entrar no Melly, os caras começaram a soltar alarme pra tudo quanto é lado e falou assim, cara, o que que tá acontecendo? Tu não correu, é War Room e etc, etc E daí o que era? Gateway de pagamento. Mas sabe qual era o problema do gateway de pagamento? É que baseado nas análises de monitoramento deles, o gateway iria cair em tantos minutos. Não é que o gateway caiu. Eles começaram a analisar que o gateway estava cambaleando. A primeira coisa que eles fazem é ligar o telefone. Cara, vocês vão ficar fora do ar. O cara do gateway, não. Aqui está tudo rodando. Entendeu? Não, meu amigo. Vocês vão ficar fora do ar. Dá uma olhada. Os caras falam, putz, está dando ruim. Vai dar ruim no outro aqui. Aí eu arrumo. Então, os caras, o nível que aquele gateway de pagamento ia cair antes do próprio gateway de pagamento saber que eles iam ter um problema. Sacou o que é um nível de confiabilidade? Manja? Então, esse tipo de coisa é um papel muito claro de SRE. Porque normalmente você vai monitorar o seu processo. Você pode até monitorar o gateway. Mas você saber que a sua operação é tão importante com a parte de pagamento e você não é o responsável, eu tenho que monitorar aquele cara melhor do que ele mesmo, porque esse cara ele vai me derrubar sacou? Então eu te cortei você tinha perguntado alguma coisa a mais? Ah, você tava falando da diferença dos dois, né? Mas tinha perguntado alguma coisa a mais? Ah, você estava falando da diferença dos dois, né? Mas... É isso. E aí, esse negócio que você estava falando, tipo, cara, uma das coisas que os caras têm é métrica de degradação do serviço de terceiro. O cara fala assim, pô, está aumentando o tempo de resposta dos caras e a gente vai avisar eles. É tipo isso. É tipo isso. É tipo isso. E eu vou perguntar aqui pra vocês, quem aqui monitora o próprio sistema? Às vezes fala assim, não, nem o meu sistema monitora, né? Daí o cara consegue monitorar o sistema externo, e é importante. Então, esses tipos de casos mostram claramente a necessidade de SRE. A questão ali não é o monitorar, porque monitorar é algo técnico. Você concorda comigo? Existem ferramentas de monitoramento, ferramentas de observabilidade, ferramentas disso. Isso, ferramenta é o que mais tem. Às vezes, o cara de SRE nem é tão especialista naquela ferramenta específica, mas ele sabe, eu preciso daquele monitoramento, vamos botar aquele monitoramento, tá? Então isso aí é muito, mas muito importante aí, tá? O Fernando da Google, como ele é da área de SRE, um dia ele deu uma talk, eu vou ver se eu consigo achar essa talk dele, eu acho que ele deu no nosso canal, ou se ele não deu, é uma talk que ele fala de hiperconfiabilidade na área de SRE com IA. Qual que é o problema, um problema forte de SRE? Sabe qual é? Você não sabe o que você quer metrificar. Você não sabe os indicadores que você precisa. Porque métrica de disco, latência, esses tipos de coisas são métricas básicas. Vocês concordam comigo? Qualquer sistema tem que ter. Você tem que medir throughput, você tem que medir a latência, você tem que medir a quantidade de banda que está saindo, você tem que conseguir medir o seu disco, você tem que conseguir medir CPU, você tem que conseguir medir o seu disco, você tem que conseguir medir CPU, você tem que conseguir medir o tempo de resposta das suas queries. Esses tipos de coisas são básicos, vocês concordam comigo. Então não precisa ser um especialista de algo pra conseguir monitorar isso. Mas quais são os indicadores que são importantes pra você monitorar do seu sistema? Você entende como é diferente se monitorar infraestrutura é uma coisa, monitorar ou observar sistema é outro, porque não adianta eu ter isso, eu tenho que saber quais são as métricas que são importantes, né? E imagina um cara na área de SRE que não conhece a fundo o que aquele sistema faz, então ele não consegue entender quais são os principais indicadores que ele precisa olhar para saber se o sistema está confiável. E daí, essa pessoa vai conversar com a área de produto, vai conversar com a área de desenvolvimento, vai conversar com o gerente, vai conversar com o usuário final, começa a entender melhor sobre o produto, e daí ele consegue tangibilizar e conseguir gerar quais são os indicadores que são importantes para ele monitorar naquele sistema. Isso é uma dor muito grande do cara de SRE. Agora, o que o Fernando trouxe foi uma ideia genial para trabalhar com o IA. O que ele faz é o seguinte, ele criou um agente que roda e verifica todo o código fonte da sua aplicação, entende o problema, olha tudo e fala que, baseado em tudo isso, na minha opinião, as métricas e os pontos importantes desses sistemas que devem ser monitorados são esses, esses, esses. Fala que mão na roda que é pra galera de SRE, pra não partir do zero, você já tem algo que fala, ó, esses caras aqui você já tem que pelo menos, são indicadores que você tem que olhar, esses indicadores são importantes, tudo fazendo pelo IA porque ele consegue entender o software e o software acaba mostrando pontos críticos que às vezes nem o desenvolvedor acaba olhando. E esses indicadores são importantes. Fez sentido pra vocês, galera? O que eu tô dizendo? Então hoje, IA tá ajudando até pra essa parte. Daí eles chamam isso de hiperconfiabilidade. Confiabilidade vem de reliability, né? Então é... Como que eu consigo manter hiperconfiabilidade? Quando eu consigo ter indicadores que normalmente eu não teria, mas agora que eu consigo avaliar melhor o código eu consigo entender quais indicadores que eu posso olhar e que são importantes e eu tinha pontos cegos. Show? Show demais. Eu nunca tinha ouvido falar em SRE. Depois de muitos anos trabalhando na área, nunca tinha ouvido. E pelo que eu entendi aqui, só para confirmar se eu estou entendendo certo, a função então é muito menos preocupar com ferramentas, e mais mesmo preocupar em definir processos e indicadores para poder medir e encontrar situações aí, é isso? E outra questão é só você não esquecer de falar para a gente sobre esse Dora. Não, eu vou falar, tá? Vamos lá. Mais ou menos, sim e não, tá? O cara de SRE, normalmente, ele é um cara técnico e normalmente, tá? Inclusive, isso aí era até uma briga. Uma briga. Se você olha o livro da Google inicialmente, as discussões iniciais quando esse termo começou a surgir, tinha uma parte que fala especificamente que o cara de SRE, ele é um desenvolvedor. Porque esse cara, ele só não fica, ele não é um cara que fica na prancheta falando, oh Debi, desenvolveor. Porque esse cara ele só não fica, ele não é um cara que fica na prancheta falando, oh Dev, desenvolve isso. Ah, tá dando esse problema aqui? Não. O cara consegue desenvolver. Ele consegue criar ferramentas de automação. Ele manja de todas as ferramentas normalmente. Esse cara coloca a mão na massa. Ele ajuda o cara de DevOps porque ele também entende muito bem de DevOps porque faz parte da profissão dele manter a confiabilidade, entendeu? Ele é um desenvolvedor que às vezes ele pode ajudar o dev a tentar entender como é que funciona esse processo aqui de failover, coisas desse tipo. Então, por padrão, de forma geral, um cara de SRE, ele é um cara técnico, tá? E daí a grande briga é que tinha gente de dev ops que falava que era de SRE também. E daí falava, é, mas você é de SRE, mas você não sabe programar, então você não é SRE. Tipo, sabe aquelas briguinhas, aqueles negócios ridículos que acontecem na nossa, na vida técnica e sei lá o quê? Mas de forma geral, tá? O cara de SRE, ele é um cara técnico, ele sabe programar, na maioria das vezes, ou se ele não é um experto em programar, você precisa de um blend, então você pode ter pessoas de SRE especializados em infraestrutura, porque às vezes o problema de confiabilidade está na infraestrutura e o desenvolvedor, às vezes, comum de SRE, ele não tem um conhecimento tão profundo de infraestrutura. Então, o importante a gente ter claro é que SRE é confiabilidade. E, pra eu conseguir deixar essas coisas confiáveis, eu preciso entender delas e, normalmente, eu coloco a mão na massa e, muitas vezes, eu crio as ferramentas pra fazer com que aquele processo funcione melhor. Ficou claro? Sim, ficou claro. Entendi, obrigado. Maravilha. Pessoal, agora, um ponto importante aqui para vocês conseguirem sempre se ligar, é importante a gente sempre pensar que toda hora que a gente está pensando em SRE, muitas pessoas já acabaram falando ali, né? No final do dia tudo acaba caindo para o fato, um ponto de resiliência. Sim, acaba entrando para a resiliência, porque é uma forma de você conseguir se proteger. Mas eu digo que SRE vai além da resiliência, tá? Porque a resiliência, ela permite com que você se ajuste. Entendeu? A ideia dos SRE é que você esteja rodando 100%. Mas se der ruim, eu vou pensar nos failovers, eu vou trabalhar com o máximo de resiliência que eu tenho, entende? Então é importante a gente entender esses detalhes aí de formas gerais, tá? Agora o que que acontece é o seguinte vocês estavam falando me cobrou pra gente falar de Dora, né? Basicamente quando a gente fala de Dora Metrics, basicamente existe tá, vamos dizer assim uma organização que os caras começaram a entrar e verificar como as grandes corporações elas funcionam e começaram a olhar algumas métricas que eles consideram importantes para você conseguir verificar como as coisas andam. E existem algumas métricas que são interessantes vocês entenderem. Uma métrica é chamada de Lead Time for Change. Quem sabe o que significa Lead Time for Change, galera? Escrevam aí, meu povo. Ou melhor, quem aí manja de Dora Metrics? Bota a boca no microfone aí. Não vou dizer que manjo, mas estou começando a arriscar a superfície. Manda aí. A gente está começando a aplicar os DORA. A gente tentou inicialmente medir as DORA com o DevLake, que é da Apache, né? Em resumo, DORA métricas são, a gente vê como alguns KPIs para avaliar o quão bem o trabalho do quão bem as nossas ferramentas de DevOps estão servindo os desenvolvedores quanto tempo demora para uma feature que foi entregue até o prod quanto tempo demora para um serviço que caiu voltar qual que é a porcentagem de de quanto tempo demora para um serviço que caiu voltar, qual que é a porcentagem de falha que tem dentro dos nossos deploys e qual que é a nossa frequência de deploy. Segundo isso, não só relaciona-se às áreas de DevOps, mas dizem muito a respeito da nossa cultura de DevOps e das nossas ferramentas. A gente está medindo, já começou a medir no DevLate, não foi o suficiente, a gente foi para o Jira, que já tinha integrações legais, ele não fala tudo, a gente está tendo problema com falhas, então ele fala deployment frequency, essas coisas que só dizem respeito a issues, mas não há tudo. Aí o que eu estou tentando fazer agora é fugir um pouco só das DoraMetrics e me concentrar mais nos formulários Dora, né? A gente tá tentando replicar todo aquele formulário que o... aquele relatório que ele faz, porque ele fala sobre IA, ele fala sobre um monte de coisa, e também toca nas DoraMetrics. Mas aí é mais ou menos isso aí. Show. Galera, o nosso amigo deu um bom resumo pra gente, eu vou falar mais especificamente desses caras, tá? Então, como eu falei pra vocês, existe tá? Algo, tá? Que a gente considera um conjunto de métricas pra medir a performance das equipes de engenharia de software. A realidade é essa. No final das contas, a gente quer ver a performance da equipe. DORA significa DevOps Research and Assessment. Assessment é quando você faz como se fosse uma prova. Você vai verificar como as coisas estão. Então, o que acontece? A gente tem algumas métricas que são importantíssimas de você entender. A primeira métrica é chamada de TLM, né? Não, TLM não. Lead Time for Change, tá? LTC. O que que isso significa? Ela mede o tempo, tá? Que você leva desde o comitê do que você fez, de uma mudança, até ela ir pra produção. Tá? O que que isso significa? Significa que ele é um indicador que mostra o quão ágil você é no processo de entrega. Quantas vezes você já fez uma feature, fez o commit, o negócio tá lá no Git e essa parada não foi pra produção. Sacou? Então ele mede esse tipo de coisa. Por exemplo, e aí a gente tem lead time, né? Curto. E a gente tem... Os lead times são maiores. Normalmente, tá? Times de alta performance... Aí você me corrija, Tayar, que eu não tô com as coisas de cabeça na minha cabeça. Mas, se eu não me engano, se você tem o lead time de menos de um dia tá, você tem é considerado um time de alta performance tá, então esse que é o grande ponto aí a gente tem um outro cara que é chamado de deployment frequency que é o que o Iago tava falando aqui pra gente ele mede a quantidade de vezes que uma equipe consegue entregar o software dentro ali de uma janela, dentro de um período. Então, isso acaba indicando o quê para a gente? O ritmo de entrega. Se eu tenho alta frequência, isso aí significa que eu estou atingindo mudanças rápidas de negócio. Ou seja, deploy todo dia, no final das contas, em tese é algo bom. Mas não adianta também eu fazer um monte de deploy para minhas métricas ficarem ótimas, mas só ter deploy com bug. E aí, baseado nisso, o que acontece? A gente tem algo que a gente chama de MTTR. Quem é manjo, o que significa MTTR? Chama Meantime to Recovery. Ou seja, qual é o tempo, como que eu posso dizer? Um tempo médio que eu tenho para me recuperar diante de um incidente, de uma falha que acabou de acontecer. Ou seja, se o MTTR for baixo, significa que eu resolvo mais rapidamente os meus problemas. E isso é muito bom. Ou seja, se eu resolvo, se o meu MTTR for menos de uma hora, minha equipe é de alta performance. Ou seja, menos de uma hora. E aí a gente tem uma outra métrica que acaba amarrando, por exemplo, o deployment frequency, que é o famoso change failure rate. O que é o change failure rate? A nossa taxa de falha por conta das mudanças que a gente acaba fazendo. Lembra que eu falei ali pra vocês que se eu tenho alta frequência de deploy, eu tenho um ritmo bom de entrega. Mas se a minha falha, minha taxa de falha por mudança for alta, significa que eu tenho um monte de deployment, mas um monte de coisa ruim sendo entregue, dando pau toda hora. Então, a minha ideia é eu ter a minha taxa de falha para mudança, ou Change Failure Rate, baixo, dizendo que o quê? Eu estou fazendo um monte de deploy e a minha taxa de erro, a minha taxa de erro quando eu subo alguma coisa, ela acaba sendo pequena. Então, essas métricas conseguem falar para você o quão ágil você é. Eu comito, o software está rápido. Eu faço deploy várias vezes. Quando dá erro, eu consigo corrigir rapidamente. E para cada mudança que eu tenho, a minha taxa de falha por mudança que eu faço é baixa. Ou seja, a maioria dos deployments que eu faço dão bom. Então isso aí acaba para a gente sendo algo que a gente considera ali das famosas Dora Metrics. E aí você vai ter diversas ferramentas, frameworks, sistemas, de tudo quanto é jeito para conseguir medir. Porque falar isso é muito bonito, o duro é medir, na realidade, né? E aí a gente começa a ter, de forma geral, ferramentas. Por exemplo, se você pegar hoje em dia, falando em SRE, quando a gente está falando de SLO, SLE, SLA, SLI, todas essas métricas, se você pegar, por exemplo, ferramentas como New Relic, Datadog, você já consegue, por exemplo, integrar, por exemplo, suas taxas de erro, as suas indisponibilidades, você já consegue falar qual exemplo, integrar, por exemplo, suas taxas de erro, as suas indisponibilidades, você já consegue falar qual é o seu error budget, e daí toda vez que gera um incidente ele registra e automaticamente, entre aspas, você já vai tendo esses indicadores ali em tempo real pela sua própria ferramenta de observabilidade. Entendeu? E não é SLE, é SLI. Então essa que é a grande pegada aí. Maçou de bola, Iago. Boa sorte aí e espero que... É interessante ver empresas implementando isso e quando você vê uma empresa implementando isso é porque você começa a ver que a empresa já está num nível de maturidade maior. Porque de todos os problemas que eu tenho na minha vida, ficar colhendo métricas, às vezes, não é um... o dos maiores problemas que eu tenho. Às vezes, eu não tenho nem tempo de colher essas métricas porque eu tô tão ferrado que eu não tenho muito o que fazer, entendeu? Então, isso aí é interessante pra gente conseguir se ligar, tá? muito o que fazer, entendeu? Então, isso aí é interessante pra gente conseguir se ligar, tá? Vamos lá. Falei de DoraMetrics que eu tava devendo, tá? Então, somente pra deixar claro. Lembrando, vou documentar aqui, porque depois vocês podem tirar os prints que vocês quiserem. Eu falei dos SLAs, um monte de coisa. O Paulo Pato já falou do que você tá falando aí. Então, deixa eu colocar aqui quiserem, eu falei dos SLAs, um monte de coisa, o Paulo Pato já falou do que você está falando aí, então deixa eu colocar aqui para vocês olharem. SLI, Service Level Indicator. São métricas que indicam a saúde do sistema. Por exemplo, latência, disponibilidade e erro. SLO, Service Level Objective, metas de forma específica os meus SLIs. Por quê? Eu tenho objetivos, mas para eu ter objetivos eu tenho que monitorar algo, e para monitorar algo eu tenho que ter indicadores. Então, o meu objetivo é baseado nos indicadores que eu coloquei. Então, os meus SLIs, ou SLIs, eles são os indicadores que eu olho. O meu objetivo, ele vai ser baseado nesses indicadores. E o meu Service Level Agreement, ele vai ser baseado no contrato que eu tenho com o cliente. Então, esse aí é um ponto importante. Ok? Então, esse aí é um ponto importante. Ok? Então, isso aí é um ponto extremamente claro que vocês têm que se ligar. Agora, tem um amigo nosso aqui que ele está querendo muito que eu fale de tipos de deploy. Eu acho que é a segunda ou terceira vez que ele coloca. Daí entra o canary, o blue green e etc. Então vamos falar sobre isso que a gente está falando de gestão na realidade de mudanças. E aí isso também faz parte de forma geral de SRE. Então a primeira coisa que você tem que pensar é que para eu fazer mudança isso vai afetar de forma geral o meu cliente final. Toda vez que eu mudo algo, afeta o meu cliente de uma forma direta ou indireta. E uma das formas de eu tentar minimizar o risco são eu ter formatos de deployments diferentes, formatos de implantação diferentes. E aí a gente tem uma pancada de formas para eu fazer isso. Porque existem vários tipos de deploy. Vários e vários e vários e vários mesmo. Eu vou colocar exatamente o que o nosso amigo colocou. Blue, green ou canary deploy. Quem aqui? Vou convidar o nosso amigo Flávio a falar aqui para a gente. Você topa, Flávio? F aqui pra gente você topa Flávio? falar pra gente um pouco de deployment? se não, não tem problema nenhum, pelo amor de Deus, não quero expor ninguém tá? mas, se quiser fica à vontade, é espaço todo seu tá? mas, enquanto o Flávio não se manifesta, e não tem problema nenhum se não quiser participar, tá Flávio não se manifesta, não tem problema nenhum se não quiser participar, Flávio. Eu que me dispus estar aqui falando sobre isso, não foi você. Então, o seguinte. Deployments. Eu vou dar um exemplo claro. Blue-green. O deploy blue-green, ele trabalha, por exemplo, da seguinte forma. Eu tenho aqui a minha infraestrutura com a versão 1 do meu sistema. Aí o que eu faço? Eu venho aqui, gero a minha versão 2 do meu sistema. E aí o que acontece? Eu provisiono as duas versões. Essa aqui está rodando e o meu tráfego está batendo diretamente aqui. O que eu faço com o Blue Green? Eu faço o seguinte. Bom, esse cara está no ar? Tá, beleza. que eu faço com o Blue Green? Eu faço o seguinte, bom, esse cara está no ar? Tá, beleza. Então eu vou fazer o seguinte, eu vou mandar esse cara pra cá e eu mantenho esse cara aqui sem tráfego. Agora, deu bom? Beleza. Eu venho aqui e destruo essa minha versão. Deu ruim? O que eu faço? Eu simplesmente mando o tráfego pra cá. Basicamente isso, de forma geral, que o Blue Green faz. Ele acaba duplicando a sua infraestrutura. É muito bom porque você tem essa flexibilidade, mas de forma geral ele é caro, porque você realmente acaba duplicando os seus serviços. Agora, tem uma coisa interessante, é que você tem um outro tipo de deployment que é chamado de canary deployment. Alguém sabe a história do canary deployment? Muita gente sabe o que é deploy canário, mas não sabe a história dele. Vocês sabem a história do canary deployment? Eu vou contar a história para vocês, mas reza a lenda que essa história é verdadeira. E é uma história triste, inclusive, mas é o que eu ouvi falar e estou pass passando pra frente, não mate o mensageiro, tá? Mas o lance é o seguinte, dizem que os mineiros, não a galera que mora em Minas Gerais, as pessoas que trabalhavam em minas, minas, tipo de carvão, mina de fazer escavação, muitas vezes, esses caras morriam, por quê? Os caras começavam a cavar, cavar, cavar. Aí tinha, às vezes, alguns tipos de gases ou alguma situação ali. Os caras desmaiavam e morriam. Basicamente, era isso que acontecia. Aí os caras tiveram uma ideia genial. Eles pegavam um passarinho e botavam esse passarinho dentro da mina. Se o passarinho não morresse, é porque estava tudo bem e eles podiam ir. E se o passarinho não voltasse, é porque deu ruim, então vou tomar cuidado para entrar ali. Entendeu? Então, é basicamente isso que o Canary Deployment acaba fazendo. Basicamente, eu subo a minha aplicação, mas ao invés de eu impactar 100% dos meus clientes de uma vez aqui, o que eu acabo fazendo? Eu boto isso aqui pra 1% do tráfego e eu tenho minhas cobaias aqui e eu analiso isso aqui. E aí o que que acontece nesse meio caso? Ah, tá dando bom, então deixa eu subir isso aqui pra 10% e deixa eu analisar. Então eu tô 90 e 10 aqui. Aí até chega uma hora, está dando tudo bem, eu vou para 100% e destruo esse cara aqui. Então, o Canary Deployment, você tem uma cobaia. E quando a gente faz o Canary Deployment na nossa aplicação dos nossos deployments, a gente basicamente faz isso. A gente vê e vai testando isso ao longo do tempo. Mas existem várias formas. Tem Rolling Update, tem... Cara, tem muitas formas de deployment, tem muitas e muitas, muitas e essas estratégias de deployment também, obviamente, também afetam a parte de confiabilidade, tá? Aí, ó, a Daniela falando, shadow, a mode, né? Eu coloco dois sistemas rodando em paralelo aqui pra mim, um é a sombra do outro e eu consigo validar, né? Se o comportamento desse meu novo sistema tá se comportando da forma desse aqui mas ao mesmo tempo é esse aqui que tá valendo ou seja, eu rodo como uma sombra um segundo sistema rodando como uma sombra antes de eu falar que tá tudo bem, né? isso aqui pra coisa crítica é muito importante às vezes a gente vê aplicações muito críticas, grandes, rodando esses caras aqui por semanas, em paralelo, para ter tempos de análise. E a gente também tem pontos importantes de empresas que trabalham muito com algo que a gente chama de feature flags. Basicamente, os caras fazem deployments o tempo inteiro, mas aquelas determinadas funcionalidades ou testes que eles querem fazer são baseadas em flags. Eu falo, eu quero habilitar esse recurso para tantos por cento. Eu quero habilitar esse recurso para somente pessoas do meu time. Eu quero habilitar esse recurso somente para esses clientes. Eu quero habilitar isso somente para isso. E quando você implementa isso de uma forma muito legal, galera, é interessante que cara, como ele está no Git, fez deploy. Como ele está no Git, fez deploy. Às vezes não cai nem muito para teste, porque quem está protegendo a barreira do que vai aparecer para o usuário final são as flags. Se as suas flags estão bem configuradas, o seu risco do deployment cai bastante. Então, é super interessante a gente conseguir trabalhar, tá? Então, Feature Flags é algo bem utilizado. Existem ferramentas específicas para Feature Flags. Tem empresas que vendem soluções de Feature Flags e acredite que é caro, porque trabalhar decentemente com Feature Flag é difícil, tá? Quando a gente fala em resiliência, a gente tem coisas também que a gente foca, que é chamado de chaos engineering. Quem aqui já ouviu falar em engenharia do caos? Tá? Hein, galera? Em engenharia do caos, tá? O que significa isso? Significa que eu quero testar como a minha infraestrutura está funcionando. Então, eu começo a desligar pedaços do meu sistema. E vejo o que dá. Basicamente isso é o que acontece. Obviamente, de uma forma mais controlada. Existem sistemas específicos. Se eu não me engano, o Chaos Monkey, tá? Obviamente de uma forma mais controlada, existem sistemas específicos, se eu não me engano o Chaos Monkey ele é da Netflix, quem veio muito com esse conceito foi a Netflix o que os caras começam a fazer é deixa eu desligar uma zona de disponibilidade, veja se está tudo funcionando deixa eu parar de rodar numa determinada região, o que que acontece deixa eu matar esses microiços agora do ar. Eu vou barrar o tráfego nele. O que que acontece? Quem tem coragem de botar um software desse rodando na sua infraestrutura, galera? Tá? Sacou? Em produção. Só pra vocês saberem, tá? O Alex Lira tá perguntando. É em produção. É fazer isso Em produção. Só para vocês saberem, tá? O Alex Lira está perguntando. É em produção. É fazer isso em produção. Tá? Então, de tempos em tempos, os caras rodam essas aplicações. Essas aplicações, o objetivo delas é gerar o caos. É tirar as coisas do ar e ver como é que os sistemas eles se comportam diante a determinados tipos de downtime, tá? No Blue GreenGreen você aponta 100% do tráfego? Sim, aponta 100%. Beleza? Então, enquanto algumas empresas querem, pelo amor de Deus, não mexa numa vírgula, outras falam, pelo amor de Deus, desligue os meus sistemas pra ver se eles estão funcionando. E aí a gente começa a ver a diferença de nível de maturidade que as empresas acabam tendo,o. Então, pontos importantes que a gente sempre tem que pensar, pessoal. Galera, trabalhar com DevOps SRE não é fácil. Você tem que ter noção de negócio, você tem que ter cabeça que não fique julgando culpabilidade apontando dedos então isso é algo muito cultural empresas que normalmente trabalham muito em culpabilidade de quem fez a besteira normalmente elas não se dão muito bem nesse tipo de coisa porque ela tá preocupada pela pessoa, ela não tá preocupada no processo tá? e eu acho que isso é uma das coisas mais difíceis culturalmente se arranjar porque isso é cultural dentro de uma empresa e aí as coisas elas acabam mudando, tá? e pessoal antes da gente isso é cultural dentro de uma empresa, e aí as coisas acabam mudando. E, pessoal, antes de a gente seguir, eu falei bastante sobre esses assuntos, mas eu não posso deixar, e aqui chega novamente o meu jabá, é importante eu falar para vocês que fazendo o jabá do nosso MBA, tem um ponto importante aqui que eu sempre gosto de dizer, tá? A nossa ideia é sempre conseguir fazer com que você consiga arquitetar, desenvolver, tá? E também liderar. E quando eu tô falando em liderar, eu não tô necessariamente falando em você ser o líder técnico, tá? O espírito do líder é o cara que é proativo e que bate o peito e fala, deixa eu tentar entender e resolver esse problema. Está muito mais na proatividade, na postura, tá? E alguém que trabalha nessa área, especificamente de SRE, mas também na área de DevOps, tem que ter esse tipo de postura, mas também precisa entender esses conceitos e também precisa entender de ferramentas. E o porquê que eu estou dizendo isso? Porque se você olhar aqui nos nossos pilares do nosso MBA, a gente tem um pilar específico só sobre DevOps e SRE. E é muito top porque nesse pilar, arquitetura de soluções, arquitetura de soluções arquitetura de software DevOps SRE o que eu gosto muito desse módulo é porque ele traz esses fundamentos de uma forma extremamente forte isso que eu acabei de falando tá? mas ao mesmo tempo tá? ele mostra as principais ferramentas que o mercado hoje utiliza que é o mínimo que você precisa saber você sendo desenvolvedor ou não quer dizer, você trabalhando na área de DevOps ou não então você vai aprender a trabalhar com containers, vai aprender a trabalhar com. Então, você vai aprender a trabalhar com containers, vai aprender a trabalhar com Kubernetes, por exemplo. Você vai aprender a trabalhar com infraestrutura como código para você não ser o cara do ClickOps. E também você vai aprender muito sobre observabilidade. Pessoal, uma das coisas que é um dos maiores movimentos que aconteceram no desenvolvimento de software nos últimos anos é a área de observabilidade. A área de observabilidade nunca teve uma padronização. A gente nunca entendia direito, a gente confundia monitoramento e observabilidade. Monitorar é ver se alguma coisa está no ar ou não. A observabilidade. Monitorar é ver se alguma coisa está no ar ou não. A observabilidade ela entende, ela acaba falando o porquê que aquele negócio caiu. Então, eu fico entendendo o que são métricas, o que são logs, o que são tracings. E quando a gente começa a ter clareza dessas coisas, a gente começa a perceber como que eu consigo ter essas métricas, como que eu consigo ter essas métricas, como que eu consigo ter esses tracings, por exemplo. E aí, começam a surgir iniciativas como o Open Telemetry. Eu não sei se alguns de vocês já usaram ou trabalham no dia a dia, mas o Open Telemetry é um dos projetos mais importantes da CNCF, que é a Cloud Native Computing Foundation, que é a própria fundação que, por exemplo, mantém o Kubernetes. Hoje eu não sei o ranking, mas um tempo atrás o Kubernetes era o primeiro projeto mais popular da CNCF e, em segundo lugar, era o projeto do OpenTelemetry, porque o OpenTelemetry conseguiu criar uma abstração para que o seu software, independente da linguagem de programação, ele consiga coletar as métricas, os tracings, os logs, e jogar através desse coletor para diversas ferramentas, desde um Datadog, desde um New Relic, desde um Elasticsearch, desde um Splunk da vida. Então, esses backends, essas empresas, essas soluções, começaram também a implementar esse protocolo e agora, antes, se eu tinha que medir a minha aplicação, as minhas métricas, os meus traces com o Datadog, eu estava amarrado no SDK do Datadog. Agora com o OpenTelemetry, não. Eu consigo fazer um shift muito rápido. Ou eu posso usar a Elasticsearch para logs, ou posso usar o Splunk para fazer a parte de rastreabilidade, sei lá, entendeu? Então, observabilidade é uma das competências que um desenvolvedor hoje definitivamente precisa saber. Ele precisa entender de observabilidade, porque faz parte do papel dele entender o que está acontecendo com o software, mas ele também precisa aprender a implementar no código observabilidade e entender como que essas ferramentas funcionam. E por isso que, obviamente, nesse caso, a gente fez questão aqui de falar sobre Open Telemetry e todos esses conceitos aqui de observabilidade, tá? Então, é importantíssimo você conseguir entender desses aspectos. E, novamente, galera, uma coisa que a gente foca bastante é trazer esses fundamentos e a gente consegue mostrar, obviamente, essas coisas mais na prática, né? E a gente tem pessoas fantásticas que dão aulas, que são muito mais especialistas, por exemplo, em SRE do que eu, por exemplo. Por exemplo, a aula de SRE não sou eu que dou aula de SRE. Porque eu não sou o cara de SRE. Eu entendo os conceitos, eu consigo entender os pontos principais, mas eu não sou especialista nisso. Entendeu? Então, esse não é um MBA de uma única pessoa, a gente tem pessoas especialistas pra dar matérias específicas de assuntos, obviamente eu dou aulas também aqui no MBA, mas você tem bastante coisa e bastante gente muito boa trabalhando e entregando aqui e novamente eu digo aí pra vocês, tá? vou pedir pro Leonan colar aí no chat, novamente. Mas, preencham esse formulário. Batam um papo com a nossa equipe. Tá? Se o que você tá vendo aqui hoje, ou que você viu ontem, antes de ontem, começa a fazer sentido e você começa a entender os gaps que você tem na sua carreira, talvez o MBA, ele seja uma ótima oportunidade pra você tampar esses gaps. Porque você não precisa ser especialista, não tem como você ser o cara especialista em a arquitetura de software, arquitetura de solução, DevOps, SRE, e saber tudo de tudo nos mínimos detalhes. Não dá. Ou você tem muitos anos de carreira, anos e anos, 20, 30 anos de carreira, focados e muito bem atualizados. São poucas pessoas que eu conheço que são capazes de fazer coisas parecidas como essa. Mas, quando você consegue experimentar, ter uma visão geral, o seu nível de confiança, o seu repertório, ele aumenta. Porque antes você não sabia que aquilo existia. Hoje você sabe que aquilo existe. Entendeu? Então, essa que é a ideia principal. O Zé está perguntando se o MBA e o Full Cycle tem muita diferença. Tem muita diferença. O curso Full Cycle é um curso muito mais focado em mão no código, vamos dizer assim. Tem código no MBA? Tem também. Tem código no MBA, mas menos código do que você vê no Full Cycle. Full Cycle, ele foca muito mais em implementações. O MBA, ele foca muito mais em conceito, em mostrar essas essas implementações, mas também ele traz as coisas de uma forma muito mais estratégica. E além disso, falando em MBA, o MBA, ele te dá acesso a pessoas fantásticas que palestram dos nossos encontros, eles te dão acesso a mentorias de carreira, mentorias técnicas, com especificidade técnica, ele traz pra vocês sessões de networking que nem a gente fez na segunda-feira, né? Todo mundo fez o system design, tava junto lá dentro de uma breakout room, tem um desafio e as pessoas se conhecem, uma consegue, começa a indicar a vaga pra outra, começa a conhecer, começa a criar um relacionamento, às vezes você conhece pessoas que manjam muito e acabam surgindo oportunidades, amizades e coisas dali, tá? Então, a grande sacada que eu acredito que o MBA ele ajuda muito é a junção, é um programa híbrido. Ele tem conteúdo, ele tem vídeo, ele tem gravação. Mas ele tem pessoalidade. E se tem uma coisa hoje que por exemplo inteligência artificial não resolve na nossa vida é a pessoalidade é a experiência minha, do Iago, do Elias do Caio, do Rafael dos dois Rafaéis que estão aqui os dois de óculos inclusive não consegue substituir o background de cada pessoa é diferente quem aqui conhece a Loiane, galera? Alguém conhece a Loiane Groner? Já ouviu falar da Loiane? A Loiane, cara, ela é uma pessoa fantástica. Fantástica. E ela é minha amiga pessoal, tá? Não sei se vocês sabem, ela mora numa cidade vizinha aqui, ela às vezes, ela vem, a gente vem em churrasco a Loiane, ela foi a minha grande incentivadora de ocorrer a minha primeira meia maratona, então esse ano eu corri minha meia maratona por conta do incentivo da Loiane, então a gente é amigo pessoal mas tirando as coisinhas essas floreadinhas a Loiane, por exemplo, ela deu uma talk aqui com a gente no MBA, falando, se eu não me engano, do que ela aprendeu em tantos anos de carreira. E ela começou a dar uma perspectiva de como você consegue guiar a sua carreira em alguns aspectos, porque ela tem uma carreira extremamente consolidada em bancos então hoje ela é diretora do Bank of New York ela era também vice-presidente do Citibank aqui do Citibank ela morou muito tempo morou ou não? morava em Tampa inclusive, onde ficava o Citibank e ela tem uma experiência muito grande com o banco muito tempo, morou ou não, morava em Tampa, inclusive, né, onde que ficava o Citibank. E ela tem uma experiência muito grande com o banco. E ao mesmo tempo, ela começa a falar pra gente o seguinte, cara, você tá mudando a sua carreira, como que eu consigo um emprego em tal empresa? Como que, qual que é o olhar de contratação que um diretor tem na hora de fechar? E ela começa a falar o seguinte, cara, você pode ser o melhor cara técnico, tá? Mas se tiver uma pessoa tão bom tecnicamente como você, e na hora de mandar o currículo pra mim num banco, e uma já trabalhou num banco, eu vou pegar uma pessoa que já trabalhou no banco, porque ela entende o domínio do negócio, sacou? Então, cada dia mais, o que vai ficando claro é que a gente, entre aspas, eu vou falar um nome manjado, com protagonistas da nossa carreira, a gente tem que começar aos poucos a direcionar para quais áreas de domínio a gente quer seguir. Você trabalha como desenvolvedor na área de varejo? Com certeza vai ser muito mais fácil você arranjar um emprego, sei lá, na Magalu, na Amazon, no Walmart, em qualquer dessas lojas de varejo, do que às vezes você trabalhar num banco. Agora, você está infeliz em trabalhar em varejo? Comece a escolher outras áreas então, não escolha a sua profissão só baseado na empresa, mas também entenda a área o segmento, entendeu? então, quando a gente começa a ter esses pontos de vista eu consigo ter o ponto de vista que a Loiane deu sobre isso quando eu vou conversar com outra pessoa, eu tenho o ponto de vista, eu consigo ter o ponto de vista que a Loiane deu sobre isso. Quando eu vou conversar com outra pessoa, eu tenho o ponto de vista de outra pessoa. E é muito legal porque, às vezes, esses pontos de vista são bem diferentes e um não concorda com o outro. E eu acho que aí que está a lindeza da pluralidade. Porque se todo mundo pensasse igual, a coisa iria dar ruim. Entendeu? Então... É interessante aí pra que vocês consigam entender, pessoal. É... Esses tipos de oportunidade de ter programas híbridos como esse do nosso MBA, ele ajuda demais. Porque a gente consegue navegar por hype, porque se tem uma coisa que o Mac é na nossa vida, galera, é engessado. E a gente é uma faculdade e a gente tem que cumprir, basicamente, tudo que a gente tá lá no EMEC, do sistema. Mas, uma vez que a gente coloca e a gente cumpre aquilo, por exemplo, com os vídeos e tudo mais, e traz essa oportunidade de eu poder falar de tal assunto que não tá lá na emenda do MBA mas eu trazer uma pessoa pra falar sobre isso eu me sinto muito mais confortável porque você não fica fechado naquela caixinha somente naquele conteúdo programático então a gente já falou de tudo aqui no MBA, e muito que a gente já falou, às vezes nem tá constando lá, entendeu? Inclusive a gente vai atualizar a página do MBA porque a gente tá vendendo muito mal o nosso MBA, porque ele tem, ele é muito mais do que aquilo que tá no nosso site entendeu? Então, novamente galera, se você acha que que tá aprendendo com a gente se esses tipos de dinâmicas são legais invistam aí em vocês vocês vão ter um certificado reconhecido pelo MEC através de uma faculdade certificado por incrível que pareça não é apenas um processo um pedaço de papel em muitos aspectos não é apenas um pedaço de papel não é em muitos aspectos é em muitos aspectos não é apenas um pedaço de papel. Não é. Em muitos aspectos é, em muitos aspectos não é. Se você um dia quiser imigrar para os Estados Unidos, você vai ver o quão importante é o bendito de um certificado de um MBA. E eu digo isso porque eu passei por esse processo. Entendeu? Então, isso aí é algo interessantíssimo para vocês pensarem, levarem em conta. É um investimento, tem muita gente feliz e eu acredito que a gente está fazendo um bom trabalho e é um trabalho que a gente vem melhorando. Tempo por tempo, tempo por tempo, eu fico misturando inglês com português, tempo a tempo a gente está melhorando, ajustando os formatos pra que vocês aí fiquem mais felizes e a gente fique conseguindo entregar mais do que tá simplesmente na emenda lá do Mac beleza? isso aí é interessante aí pra vocês maravilha galera inclusive, só pra vocês saberem, tá? quem aqui já pensou em mudar para os Estados Unidos? imigrar pelos Estados Unidos? Tá? Agora, existem um trilhão de formas de você migrar para os Estados Unidos. E nós, desenvolvedores, temos alguns vistos que podem nos ajudar a imigrar. Agora, eu sou advogado de imigração? Vocês ach imigrar agora eu sou advogado de imigração vocês acham que eu tenho cara de advogado de imigração? não, mas eu conheço a advogada de imigração que fez e faz um monte de caso pra green card para pessoas da área de TI e que conseguem emigrar pros Estados Unidos sem ter pelo menos uma oferta de trabalho, porque a gente fica pensando que é difícil emigrar ir pra um outro país, que a gente precisa de alguém pra patrocinar o nosso visto né, pra você poder mudar de país, pra ter um green card. Mas existem diversas formas e uma das pessoas que eu tô pra marcar agora com elas pra participar no NBA é a doutora Lívia Leite, que é uma pessoa fenomenal e ela é especializada nessa parada. Né? E... E ela vai dar uma aula pra quem quer pensar em morar nos Estados Unidos e ver como consegue se legalizar. Isso tem a ver com arquitetura de solução, arquitetura de software, etc? Não necessariamente, mas tem a ver com você. Entendeu? E se tem a ver com você, tem a ver com o nosso programa, porque a gente quer ajudar você a ter sucesso. Se você tiver sucesso, conseguir migrar e conseguir o green card, fala assim, cara, aprendi isso num MBA, uma advogada de migração. De onde que vem isso, entende? Então, essa que é a ideia aí de vocês. A ideia, é assim que eu vejo o nosso programa. Sempre tentando melhorar, estamos longe de ser perfeito, tá? É assim que eu vejo o nosso programa. Sempre tentando melhorar, estamos longe de ser perfeito, tá? Então, se fizer sentido para vocês, galera, preenche o form, a galera, a nossa equipe vai entrar em contato com vocês. Muitas vezes eu entro em contato com vocês, a gente bate um papo. E, realmente, se a gente achar que é para você, a gente vai falar com toda franqueza, é para você. Se a gente falar, segura, talvez a gente tenha um outro curso pra você ou talvez é melhor você esperar, tá bom? Então esse é o ponto importante pra vocês conseguirem se ligar Fechou? E agora galera eu queria especificamente falar com vocês tá? Segunda parte do nosso bate-papo sobre inteligência artificial. Tá? E quando eu digo que eu quero falar sobre inteligência artificial, eu não tô... Caramba, a minha setinha aqui tá que tá... Eu não tô necessariamente aqui querendo ficar falando, ou batendo papo, ou falando sobre MCP. Inclusive eu tenho aqui um projeto no GitHub que eu subi de um MCP, de exemplo, mas esse projeto sobre MCP, inclusive eu tenho aqui um projeto no GitHub que eu subi de um MCP de exemplo mas esse projeto de MCP está sendo muito mais útil para mim do que para qualquer pessoa que eu subi esses dias por curiosidade que eu estava querendo deixar um exemplo para um vídeo do YouTube que eu vou gravar mas é um MCP de prompts e esse MCP faz com que eu evite ficar copiando e colando os prompts que ajudam o meu cursor a não ficar maluco na hora de fazer código. Então, depois, se vocês quiserem, deem uma olhada. Eu estou criando uma API para os prompts ficarem dinâmicos e tudo mais, mas isso aqui salva a minha vida no dia a dia, na hora que eu estou trabalhando, tá? Então, depois, peguem esse link do GitHub. Eu fiz ele totalmente no Vibe Coding de uma forma responsável. Mas... Cara, só de usar esse cara aqui, você já vai ver que o nível da qualidade do seu código muda completamente. Um prompt pode mudar o seu código da água pro vinho. E o porquê que eu tô dizendo isso, galera? Porque nós, desenvolvedores, quando a gente tá falando de A, nós temos alguns problemas. E esses problemas, eles têm muito a ver, adivinha com o que, pessoal? Alguém consegue dar alguma ideia? Qual que é um dos principais problemas nossos em relação a IA hoje em dia? Não saber descrever o prompt. Não é só isso, ele vai um pouco mais longe. Nosso problema com o IA é o contexto, principalmente o contexto de como contextualizar o que ela precisa olhar dentro do nosso código e como é que ele vai fazer ali o processo tá, o lance é o seguinte o nosso problema ele começa antes disso o nosso problema principal na minha opinião, é que o dev pensa que sabe trabalhar com o IA. E quando a gente fala que a gente pensa que a gente sabe trabalhar com o IA, isso significa que, poxa eu abro meu cursor tenho o code completion eu gero os meus testes ele desenvolve as paradas eu fico muito puto fico ansioso tem hora que eu amo, tem hora que eu odeio mas no final do dia na nossa cabeça a gente sabe trabalhar com IA por que a gente acha, a gente sabe trabalhar com IA. Por que a gente acha que a gente sabe trabalhar com IA? Porque a gente trabalha com IA. Porque a gente abre o nosso editor e a gente escreve a parada e a gente realmente está trabalhando com IA. Mas pensar que a gente realmente sabe trabalhar com IA, trabalhar com Iá pensar que sabe é diferente de saber a gente usa Iá e o problema que isso aqui gera no final das contas é que a gente fica cansado de cansado de passar raiva com o Iá. Fala a verdade para mim. Quem aqui está cansado de passar raiva com o Iá? Levantem a mão. Cara, cara dá muitas vezes ansiedade de trabalhar com Iá você começa a pedir aí ela começa a funcionar e depois ela começa a destruir tudo que ela mesma criou e daí você fala, não, não é assim daí eu já me vi xingando escrevo, cara, como se ela ia ficar triste comigo se eu tivesse xingado a Yá. Entendeu? Esse é aquela parada. Eu acho que se ela fosse uma pessoa, eu dava uma garrafada na cabeça dela. Entendeu? Porque tá tudo bonitinho e depois ela começa a destruir o que ela mesmo fez. E daí você fala, não faz isso. Aí, porra, arrumei. Daí ficou um monte de rabo pra trás. E daí a gente começa a passar raiva. A gente começa a ter ansiedade com ela. E daí no final do dia, pra gente se sentir menos mal, a gente tem uma resposta. A gente acha que há. E há. De forma geral gera código ruim quem é que acha que de forma geral a IA gera código ruim quando você tá trabalhando com ela não mintam pra vocês mesmos depende muito da IA né qual IA você vai utilizar cara, na minha opinião tem hora que eu achava depende muito da IA, né qual IA você vai utilizar cara na minha opinião tem hora que eu achava que 100% delas geravam código ruim Wesley eu acho, cara, que até por conta do que você gerou aí pra nós, né no teu repo aí eu acho que é até o daquela live que um aí no teu repô aí, eu acho que é até o... daquela live que um parceiro teu falou, depende da pergunta que você faz, como você gera esse prompt, aí é da qualidade dessa pergunta, então na verdade não é como o colega falou, da IA, da LLM que está sendo usada, mas a qualidade dessa pergunta. Exato. Cara, existem umas coisas, eu queria deixar isso claro para vocês. Eu vou criar uma linha divisória para vocês sacarem. De um lado, a gente tem o nosso prompt que é a pergunta, é a forma que a gente tá falando e que eu acredito que todo mundo tá nesse consenso, né? A IA muitas vezes gera o código ruim porque por dentro a gente sabe que a gente não sabe perguntar pra IA acho que é meio que sabe perguntar pra IA. Acho que é meio que claro isso aí pra gente. Estamos alinhados, pessoal? Alguém discorda fortemente de mim? A gente consegue saber se a gente escreve algo ruim, ela vai gerar algo ruim. Se a gente gera algo bom, às vezes ela gera algo bom. Tá? Então, o grande ponto é que sim, essa parada do prompt essa parada de como pedir de como perguntar ou coisas desse tipo são importantes tá? é a base da parada, né? porque você fala em linguagem natural então é o que é por outro lado tem uma outra coisa que tem a ver com o prompt, mas eu prefiro separar pra deixar mais claro aqui pra vocês e essa parada é chamada de workflow meu Deus do céu tá bonito hoje, hein Wesley? Por que eu tô colocando aqui o workflow? Porque não importa a qualidade do seu prompt. Você pode pegar o melhor prompt que existir e pedir pra IA desenvolver seu software. seu software. Se no seu prompt ou se também não estiver definido por você a forma de como você desenvolve como IA, você vai sofrer miseravelmente. Por que que eu tô dizendo isso? Eu posso pedir pra minha IA desenvolver o sistema XPTO com todas as especificações com o melhor prompt do mundo sabe o que vai acontecer? ela não vai conseguir desenvolver vai dar ruim e você vai passar raiva então, na nossa cabeça a gente que tá começando a entrar num problema, eu não digo nem num problema, tá? A gente está começando a entrar numa situação que está virando meio que rotina a gente falar exatamente isso que a gente está falando. A gente não sabe perguntar, a gente não sabe pedir, etc, etc. E por isso a gente não tem os resultados satisfatórios. O grande ponto é que mesmo a gente sabendo pedir, a gente não vai ter sucesso para trabalhar com o IA. Porque o sucesso de trabalhar com o IA está no seu fluxo de trabalho que você vai utilizar com o IA. Está no seu fluxo de trabalho que você vai utilizar. Eu posso pegar o Albert Einstein e falar para ele desenvolver a parada mais complexa do mundo. E eu sei que ele tem essa capacidade. Mas se eu falar para ele desenvolver essa parada. Tudo de uma vez. O que vai acontecer? Ele não vai conseguir desenvolver. Eu tenho que falar para ele fazer ped conseguir desenvolver eu tenho que falar pra ele fazer pedaço por pedaço entendeu? e é aí que as coisas começam a complicar porque eu preciso fazer ela ir seguindo um passo a passo se ela não tem um workflow definido de como ela deve trabalhar o que vai acontecer? Ela vai se perder. Então, eu tenho que conseguir fazer algo que é um plano de ação. O plano de ação, basicamente, ele diz respeito a o que nós vamos fazer. Como que a gente pensa em resolver esse problema. Tá? E, embaixo do plano de ação, eu tenho algo chamado de tarefas. eu tenho algo chamado de tarefas. Uma vez que eu tenho tarefas definidas, e eu tenho um fluxo, e aí esse fluxo pode mudar de acordo com o seu gosto, eu consigo fazer a minha IA, e matando essas minhas tarefas, até ela completar o meu plano de ação mas é muito lindo falar isso, né? por que que é muito lindo falar isso? por que é difícil pra caramba fazer o plano de ação e é difícil pra caramba definir as tarefas. Por quê? Porque o meu plano de ação tem que contextualizar o que ela vai fazer. E as minhas tarefas têm que falar o que ela tem que fazer. Mas não adianta apenas falar o que ela tem que fazer. Mas não adianta apenas falar o que ela tem que fazer. A gente, dentro da tarefa, a gente tem que falar como ela vai fazer. E o que acontece? Fazer prompt. e o que acontece fazer prompt criar um plano de ação definir as tarefas e explicar como essas tarefas devem ser feitas toma um tempo do cão e é difícil o Rafael está colocando aí desse jeito eu mesmo faço Um tempo do cão. E é difícil. O Rafael está colocando aí, desse jeito, eu mesmo faço. Entendeu? Acaba sendo uma outra programação, né Wesley? Exatamente. E é, incrivelmente, esse é o ponto que eu digo para vocês. Nós desenvolvedores pensamos que sabemos trabalhar com IA. E eu arrisco a dizer que se você não faz isso hoje, eu diria que você... Eu não digo que você não sabe trabalhar com IA. Eu diria que você está com o dedinho na ponta do iceberg só. Sacou? Esse aí é o grande ponto. O outro ponto é que além do workflow, tarefas de plano de ação, eu tenho uma outra questão. Eu tenho que dar contexto. E o que é dar contexto? Alguém diga para mim, explique para mim, o que vocês veem, alguém falou para mim sobre contexto, o que vocês querem dizer sobre contexto? Alguém quer colaborar? O tipo de aplicação que você está fazendo, como você quer fazer, por exemplo, se você quer usar um clean architecture ou não, usar sólidos, a injeção de dependência, informar esse contexto de como você quer o código, e também ele precisa, muitas vezes, quando a gente está já lidando com o código que a gente estava usando, ele seguir os exemplos dos próprios códigos que a gente tem. Show de bola! Toca! Oi, Wesley! Oi! Dentro de uma LLM, a gente tem as camadas de atenção. Então, quando a gente posiciona o contexto ali, na verdade, a gente está direcionando a IA para dar as respostas que a gente precisa. Como o conhecimento já está inferido nas camadas de atenção, com aquilo que a gente coloca, o prompt vai ser o resultado, quer dizer, a saída atenção com aquilo que a gente coloca, o prompt vai ser o resultado, quer dizer, a saída do prompt que a gente coloca junto com o conhecimento pré-treinado da IA. Então, se a gente consegue limitar um escopo mais direcional, a resposta vai ser mais assertiva. Sem dúvidas, mas a gente tem um problema que é direcionar, que é o que você falou. A gente tem, inclusive, tipos de prompts encadeados com directional, estímulos, inclusive, coisas desse tipo. Mas o grande ponto aqui, que eu quero dizer com contexto, é quando nós estamos trabalhando de forma técnica, na topo do cara, tem umas farás em inglês que em português fica sem nada a ver, né? do topo da sua cabeça, existe isso como é que fala isso, do topo da sua cabeça em português é debate pronto debate pronto a gente pensa no contexto técnico certo? ah, é pra trabalhar com clean architecture, vou botar os exemplos no meu código, mas além do contexto técnico eu tenho o contexto de produto porque ela precisa entender o que ela tá fazendo entendeu? e precisa entender o que ela está fazendo. Entendeu? E como que a gente junta essas coisas, galera? Eu preciso falar pra ela, tecnicamente, como que tudo isso vai ser desenvolvido. E ela precisa entender qual é o produto que eu tô desenvolvendo. Ela não tem que entender só a especificaçãozinha da tarefa dela. Ela tem que ter uma visão geral, porque uma vez que ela entende essa visão geral, ela consegue ter mais ideia do porquê que aquela tarefa está sendo feita, como ela está sendo feita. E aí, a gente começa a precisar de documentação. Quem aqui gosta de fazer documentação, pessoal? É bem importante, né? Um sistema, documentação é o que mais importa, né? O cara que inventou a documentação colocou um estagiário pra fazer pra ele. Eu não gosto. Eu sempre fui da ideia de que o código é a documentação. Mas agora eu tô vendo que eu vou ter que me atualizar. Até porque quando a gente pega código legado, a gente vem ver que o código não é a documentação. É, ou se por mais que a pessoa programe bem, usando tudo, né? O Uncle Bob que me desculpe que o código é a documentação, se tiver tudo seguindo o ClickC, eu não preciso criar um monte de comentários. Tem umas coisas muito loucas aí. Hoje em dia, você programa em português. Você programa em inglês. A real é essa, tá? Quando eu falo programar em português, eu programa em linguagem natural. O que eu estou querendo dizer é que quem aqui é da época onde não era normal O que eu estou querendo dizer é que... Quem aqui é da época onde não era normal fazer testes unitários, testes de integração e etc? Quem aqui é dessa época? Eu sou, comecei na década de 80. Então, tem muita gente que é um pouco mais novo na profissão e já nasceu com essa cultura que você tem que fazer código e tem que ter teste, tá? Mas eu não era dessa época. Então, eu não testava código. Entendeu? E uma das coisas que mais foi difícil na minha mente de entrar culturalmente pra mim, foi ter que trabalhar com teste. Por quê? Porque é um saco fazer teste, cara. Entendeu? Tem um monte de código que você pode fazer e você tá lá criando teste. Era assim que eu ficava pensando. O grande ponto é que quando eu me toquei, tá? Que um dos meus maiores ativos no meu código era o teste, a minha chave virou. Por quê? Porque esse teste que eu estou fazendo hoje, daqui 5 anos, eu ainda estou usando ele e ele está garantindo que o meu sistema não vai quebrar. Ou se ele quebrar, ele está me mostrando. É aquela parada que, entre aspas, eu faço uma vez, ou, eventualmente, você tem que alterar seus testes também, claro, mas ele vira um ativo no seu software. Entende? O teste, hoje em dia, na minha opinião, é um dos maiores ativos que você pode ter no seu software. Então, pra mim, é impensável eu ter um software sem teste. Porque se ele não tem teste, a chance de dar merda é muito grande. E se eu tenho teste, esses testes vão acumulando ao longo do tempo. E evita de eu ter que ficar fazendo um trabalho repetido. Mas isso foi cultural. Foi difícil disso entrar na minha cabeça. Mesmo sabendo disso, eu ainda não queria fazer teste. Até o momento que eu comecei a fazer teste, todo mundo começou a fazer teste. Hoje em dia, pra mim é natural. Eu nem penso, vou ter que fazer esse teste. Não, às vezes eu fico até animado de fazer o teste pra ver se eu consegui fazer aquela pegadinha do malandro no meu código, entendeu? O que está acontecendo, o que está acontecendo ou não, na minha opinião, o que vai acontecer, na realidade já está acontecendo, é que o nosso próximo ativo vai fazer a gente voltar as nossas origens de verdade e a gente, esse próximo ativo, é chamado de documentação a única forma de a gente conseguir fazer a nossa bendita IA ter ainda mais contexto e gerar o código de uma forma mais decente é tendo documentação e o problema é que a gente vai muito do 8 ao 80. Algumas décadas atrás, a gente passava seis meses fazendo documentação e especificações para daí começar a desenvolver o software. Agora, tem hora que você pega projetos que é no docs. Ou seja, ele nem tem documentação. Provavelmente, o que vai acontecer com o mercado, é que a gente vai voltar nesse meio termo. E a gente vai começar a perceber que a documentação, ela vai ser um ativo tão grande quanto os seus testes. Porque quem mais vai usar a sua documentação vai ser a IA. Entende? Quando você junta saber fazer o prompt, ter um workflow e dar contexto, o seu resultado com o IA é indiscutivelmente melhor. Eu digo isso porque eu gastei muita bunda na cadeira fazendo todos esses tipos de testes. Wesley. Oi. Com licença. Mas só complementando aí, você não acha que, assim, pelo menos na minha visão, até coloquei no chat aí, a IA, já que a gente enfim, está contextualizando tudo, tem uma fundamentação, sabe o que está fazendo, a IA, já que a gente enfim, está contextualizando tudo, tem uma fundamentação sabe o que está fazendo a IA também não pode ela gerar esse código para depois, de repente uma outra IA, um outro agente poder programar, um outro um outro dev ela tirar esse trabalho da gente, esse peso nosso muito bom cara, não eu não acho, a IA deve fazer isso ela tirar esse trabalho da gente, esse peso nosso? Muito bom, cara. Não, eu não acho. A IA deve fazer isso. Entendeu? E qual é o nosso objetivo? Qual que é o nosso papel no meio dessa história? É ajudar e usar, inclusive, IA, inclusive, como base de consulta, mas conseguir direcionar a IA das decisões que a gente está tomando de produto, das decisões técnicas, inclusive para ela mesma gerar esses tipos de documentação, entende? O grande ponto é que muito... A gente começou muito a parar de fazer documentação, porque, cara, é muito difícil fazer, a gente escreve mal, aí você trabalha numa empresa onde todo mundo fala que tem que fazer tudo em inglês, aí seu inglês é ruim pra caramba, aí não sei o que, cara, tem tanta fricção pra você gerar uma documentação que simplesmente você não faz a documentação agora se você tiver agentes de A que são capazes de gerar uma documentação que simplesmente você não faz a documentação. Agora, se você tiver agentes de ar que são capazes de gerar documentação pra você, o jogo muda. Sacou? O jogo muda completamente. E uma das coisas que eu tenho utilizado muito, muito, muito, muito, é o que? ter documentações criar documentações e uma das coisas mais lindas é reutilizar documentações, porque muitas das documentações e decisões técnicas de arquitetura que você toma são muito parecidas uma com a outra dependendo de um projeto entende? então a grande sacada aqui tá eu tenho que saber fazer prompt eu tenho que saber fazer plano de ação gerar tarefa, definir a tarefa eu tenho que fazer do cunha, cara eu vou programar eu não vou ficar mexendo no cunha entendeu? mas a real é que quando você consegue entrar nesse flow aqui tá? significa que você entendeu, como que eu posso dizer a nova regra do jogo que no final das contas, é a nova forma de programar. A forma de programar mudou. Tem uma pergunta aqui, rápida. Manda. Só pra não me perder, eu tinha outra pergunta, então vou deixar minha mão levantada pra depois eu perguntar, mas essa é mais contextual, mais próxima. Eu vi o seu vídeo de cursor, muito bom, está me ajudando bastante. Eu estou conseguindo agora fazer um workflow bem, mas com um tom de ação melhor. Agora que eu entendi que se você especificar certinho você tem que fazer testes, você tem que seguir uma regra, ele manda muito bem. E se você fizer com textos, eu estou fazendo nos meus MDCs, ele também, nossa, é exponencial. Só que, qual que é o esquema que eu vi recentemente? E agora, eu estou pensando num novo nível de talvez fazer agentes que consigam ajudar mais isso aí. Só que eu vi recentemente que o Augment Code lançou uma context engine, quer dizer, ele tem junto com ele uma context engine, que eu estou muito tentado a experimentar, né? Eu acho que talvez essa semana... Bota o link aí pra galera, bota o link aí pra galera. Não tenho o link aqui, mas eu vou escrever. Acho que é assim, mais ou menos. Mas a questão é, ele faz contexto, ele pega o contexto do seu código sem documentação. Então, você não precisa mais escrever o seu MDC, você joga, pede pra ele gerar o seu contexto, ele mais ou menos dentro do seu código. Eu queria perguntar se você já testou isso, se já deu uma olhada. Se é uma coisa complementar. Cara, eu acho que tudo isso vai ajudar. Daqui pra frente, os modelos, as coisas que vão sendo acopladas, vão ajudar muito. Por exemplo, o cursor no começo, ele não indexava o seu código. Hoje ele indexa. O cursor lê o seu código. Ele entende como o seu código está funcionando também. É bom, né? É, então. Mas está melhorando. Entendeu? Hoje você dá um barra generate rules. Vocês já viram esse recurso novo dele? Você dá um barra generate rules, ele lê o seu código e consegue entender os padrões do seu código e gerar as regras do seu código pra ele conseguir seguir melhor e você ajusta, entendeu? Mas, é aí que é o grande ponto. Por mais contexto que ela olha e veja o seu código e tudo mais, existem decisões que nós temos que tomar. Entendeu? E essas decisões que nós temos que tomar, nós precisamos especificar. Entendeu? Obviamente, eu tenho um código que eu tenho um bug. Uma IA que consegue entender muito melhor o contexto do meu código, tecnicamente apenas falando, cada vez vai ser melhor dela conseguir detectar esse bug. Mas muitas vezes, a gente toma decisões, por exemplo, arquiteturais, baseada em dinheiro, baseada em tempo, baseado em milhares de coisas que não tem nada a ver com o código que está sendo gerado. Entendeu? E o grande ponto é que esse tipo de contexto a IA não consegue ter. Ela consegue ter um contexto técnico, claro, ali. Mas o porquê aquele código estava daquele jeito, ela não sabe. E, novamente, galera, a gente não está nessa profissão para sermos amadores Novamente, eu faço essa parada o tempo inteiro Complexidade ao longo do tempo Tá? A gente quer criar software que dure por muitos anos É pra isso que a gente é pago Entendeu? Então, eu acredito claramente que cada vez o resultado da IA vai ser melhor. Cada modelo que vai lançar, cada mágica, cada IDE. A OpenAI tá querendo comprar o Windsurf agora por 3 bilhões de dólares. O Cursor, a empresa do Cursor, saiu hoje no TechCrunch. Eles conseguiram, ela tá avaliada em 10 bilhões de dólares. Fez mais uma rodada de investimentos. Agora, você acha que tem dinheiro aí? Tem dinheiro pra caramba, cara. Porque esses caras estão mudando a forma de como você programa. E cada vez ele vai tentar facilitar ainda mais a sua vida. E ela vai ajudar... Isso porque Wesley, que a barreira de entrada do público deles, no caso, é o dev, né? Exatamente. E eles derrubando essa barreira, imagina quantos dias vai entrar. Então, o grande ponto aí no meio dessa história aqui é qual que é a diferença, então, se eu pegar o cursor uma hora que ele estiver muito bom, entendendo todos os meus contextos e sair fazendo as coisas que eu quero? Daí eu não preciso mais de mim mesmo? Com certeza, não vai precisar de um monte de gente. As tarefinhas aí mais fáceis, os bugzinhos, essas coisas. Cara, não vai precisar. Porque código vai ser código, vai ser gerado, não gostei, redabuga, refaz, etc, etc. O código está perdendo valor cada dia. Entendeu? O código para mim cada vez está virando mais detalhe. Entendeu? Mas, novamente, cadê? Cadê? Você acha que esses tipos de decisão, estratégias, etc. Iam ser apenas um contexto da IA? O que a gente falou na segunda-feira, por exemplo? Ela pode opinar, ela pode entender de cada uma dessas coisas, mas no final do dia, é o meu nome que está embaixo dessa solução. Sou eu que vou escolher como que ela vai fazer. Sou eu que vou dar qual a estratégia. E é por isso que eu tenho que entender desses conceitos. Porque ela vai saber implementar. Entendeu? A Yá vai ser o pedreiro e eu vou ser o arquiteto. No final das contas, é isso que acontece. Entendeu? Oi, Edson. Oi. O que tu tá falando, eu tô lembrando muito de uma entrevista que eu vi do autor do livro A Philosophy of Software Design no canal chamado The Pragmatic Engineer. Cara, é muito legal o que ele fala, justamente o que tu tá falando, que é, a IATA é cada vez melhor em escrever um código pra resolver uma tarefa que tá bem descrita, ela vai entender aqueles contextos que tu deu pra ela, só que o papel do desenvolvedor cada vez mais será de abstrair complexidade pra que você tenha aplicações duráveis a longo prazo. O papel do desenvolvedor está migrando para essa área de arquitetar, de fazer o design da aplicação. Não é simplesmente escolher esse design pattern, mas sim escolher tudo, o arranjo, e o arranjo melhor para que a complexidade seja reduzida e a manutenção, a durabilidade da aplicação seja maior ao longo do tempo. Porque não é só desenvolver. O que é maior na aplicação não é desenvolver, é manter ao longo do tempo. Cada vez a IA vai ser um pedreiro melhor. Mas também tem outro ponto, Wesley, que é interessante salientar aqui, que toda essa narrativa de IA, ela também é uma matéria de estudo, né? Então, isso também existe uma barreira ainda de ela virar uma matéria de estudo, etc., porque não é simplesmente a pessoa pensar que vai rodar com IA, vai chegar ali na interface, vai dar um prompt, né? E vai estar tudo resolvido. Como você acabou de mostrar, existe uma complexidade. Então, o que eu acredito também é que a gente vai ter que só se adaptar. Mas o problema ainda vai existir para ser resolvido. Cara, com certeza. E esse é o ponto que eu tento fazer. A gente pensa que a gente sabe trabalhar porque a gente vai lá e ela faz as paradas. Mas, grande parte das vezes, dependendo de como você trabalha, é o código ruim. A primeira coisa que a gente fala é o prompt, não sabe pedir. Mas quem aqui parou e investiu em escrever um prompt de três páginas? É, se der uma barreira muito grande ainda. Entendeu? Quem aqui? Eu sei que é o problema, mas eu não faço. Eu sei que se eu não comer no McDonald's e comer saudável, eu vou emagrecer e não vou ficar com o resto do alto. Vai roer unha. Entendeu qual que é o negócio? Eu criei um prompt pra criar prompt pra você ter uma ideia. Eu tenho também. Ele fica inteirando, inteirando, inteirando inteirando e aí eu coloco ali, ele vai inteirando, inteirando às vezes, cara, eu fico 20 minutos com ele me ajudando imagina se você fosse fazer isso tudo sozinho na mão, entendeu? e pra isso, você tem que entender dos tipos de prompt porque são muitos tipos de prompt e somente, às vezes uma palavra que você coloca no prompt a forma de ele se comportar é completamente diferente. Mas lembrando, o prompt é uma das coisas. E que é indispensável, porque ele é o isqueiro, ele que acende a parada. Quando a gente fala de matéria é tudo, é o prompt, workflow, contexto... O prompt, ele define essas coisas. Mas no final das contas, não adianta eu só escrever um prompt falando para ele fazer um código bonito, bem documentado, que ele consiga não sei o que. Não, o prompt, ele vai respingar nessas coisas. Mas essas coisas têm que ser feitas. Agora, o ponto é, como gerar um plano de ação? Como gerar uma tarefa? Como definir uma tarefa para ele boa? Como é que eu consigo fazer uma documentação técnica decente? Como é que eu consigo criar uma documentação de produto decente? E o ponto principal, como é que eu consigo fazer isso rápido? Bom, Wesley, é... Espera aí, espera aí. É que a gente está conversando uma fala junto. Tu falou um ponto ali que foi interessante, que tu falou gerar um produto Mas Com o IA Será que não está indo um pouco mais Para em vez de ter só um produto E documentação de produto Ter uma coisa, um passinho antes Dentro da documentação, que seria uma documentação Por exemplo, das diretivas da empresa Porque, por exemplo E essas diretivas da empresa Est Porque, por exemplo, e essas diretivas da empresa estarem na minha atualização do produto, usar essa atualização das diretivas da empresa, dos pontos da empresa, de N questões, documentar melhor também o que a empresa faz, e como a empresa faz, e o que a empresa quer fazer, para que atualizações de produtos passem a vir também dentro dessas documentações, porque o Maia, por exemplo, iria pegar, ah, quero atualizar o meu sistema. Pegar dessas pré-documentação, essa pré-documentação para gerar, talvez, até uma documentação de produto, para depois estar fazendo a implementação do sistema. E isso também vejo que geraria, traria isso para desenvolver sistemas mais vários sistemas, de novo, maiores de suporte, produzindo um ecossistema para manter a empresa. Então, esse processo está voltando também, gerando mais códigos, mais documentações até, e que isso falta hoje também, que é documentar o que a empresa faz. Cara, eu acho que é tudo uma questão de estratégia. Por exemplo, provavelmente o que a empresa faz não necessariamente vai ajudar, dependendo da situação, tanto no código que vai ser gerado. Entendeu? Talvez não altere tanto nesse tipo de coisa. Mas, sabendo o que a empresa faz, talvez gerar a documentação do produto seja mais fácil. E a documentação do produto provavelmente vai afetar a forma de como a IA trabalha. Entendeu? Eu acho que é um encadeamento de coisas. A gente vai voltar muito para o mundo da documentação. Eu não tenho dúvidas. O que eu estou querendo dizer, galera, e opinião minha, e eu tenho conversado com muita gente, é que a nossa forma de programar vai ficar muito parecido com isso aqui. Tá? E por isso que entender de toda essa parada que a gente tá falando aqui é importante, porque a gente não consegue gerar isso, isso, e isso, sem entender dessas coisas de cima que a gente não consegue gerar isso, isso, e isso, sem entender dessas coisas de cima que a gente viu. E perceba que não necessariamente tudo isso tem a ver apenas com código, tem a ver com decisões. Entendeu? E isso faz diferença. Eu fiz o vídeo do YouTube, eu cheguei a mostrar pra vocês tem toda uma existem vários tipos de documentação pra vários tipos de contexto existem prompts que você pode fazer que vão te ajudar a gerar essas documentações eu tenho feito isso, eu viciei nessa parada porque agora eu tenho um monte de documentação que é tudo igual pros projetos que são muito parecidos que eu tenho novamente, essa parada vira um ativo ao longo do tempo comigo, entendeu? e o mais interessante é o seguinte quando eu termino o desenvolvimento do projeto com a IA eu vou lá e ainda gero num formato de agente falando verifique se o que foi feito Eu vou lá e ainda Gero num formato de agente falando Verifique Se o que foi feito Está Condizente Com o que Está na especificação do software O que está sendo cumprido E o que não está sendo cumprido Tem revisão de código Mas tem a revisão de código, mas tem a revisão do produto. Ou tem a revisão que eu posso falar, eu verifique se o meu código está seguindo as guidelines que eu estabeleci, por exemplo. Aí ela pode varrer e trazer. Então tem muitas formas de você fazer verificações. Entendeu? E existem várias formas de você pedir a mesma coisa várias vezes pra garantir consistência. Tem um conceito de prompt que chama self-consistence, não sei se vocês já ouviram falar. Que ajuda a gente conseguir... Porque a gente às vezes acredita de cara na primeira resposta que ia. Mas você não pergunta cinco vezes a mesma pergunta às vezes pra ver qual o resultado ela dá sempre mais parecido pra você acreditar mais numa resposta dela ou outra, entendeu? Então, eu acredito que essa vai ser a nova forma de a gente programar. A nossa profissão tá mudando, a IA vai ser cada vez mais, é uma coisa que não dá mais pra desver, não tem mais volta. Mas as pessoas que eu vejo trabalhando sério com IA... E quando eu digo trabalhar sério, galera, não é criar um projetinho, brincar com o cursor ou corrigir um bug. Quando eu tô falando em projeto, eu tô falando de um projeto de uma empresa grande, cara. Entendeu? Um projeto de uma empresa grande, cara. Entendeu? Um projeto de uma empresa grande não é um dia de codificação. São anos de codificação. Entendeu? Então, às vezes, a gente fala, cara, se eu tiver que fazer tudo isso, eu mesmo programo. Mas, às vezes, esse tudo isso é que nem o teste você faz muitas vezes uma vez e isso vira o ativo pro resto do seu projeto Wesley eu tinha uma pergunta que vai de encontro com isso que você acabou de falar, tipo, usar IA numa empresa grande, num projeto que já tá rolando eu vi esse vídeo que você gravou sobre gerar lá os decision records, gerar toda a documentação, gerar as tasks, colocar a IA para fazer as tasks e tal. Entendi lá que, pelo que eu me lembro, você fez num projeto vazio, você começou a criar um projeto e aí você foi fazendo mas aí você está falando sobre empresa uma empresa maior, um sistema que já existe e aí eu estou vendo que você está falando aí sobre o prompt, sobre o workflow, sobre o contexto, documentação e eu queria saber como esse negócio começa porque assim, você tem um sistema muito grande, você tem uma empresa grande você vai, você precisa começar de algum lugar, então você começa a criar documentação de um contexto pequeno e vai escalando isso, então tipo, e vai escalando isso. Então, tipo, e vai crescendo sua documentação. Com certeza, cara. Com certeza. Com certeza. Não tem jeito. Você vai pegar um projeto grande com milhões de linhas de código e botar um monolito para ela ler tudo aquilo ali e tentar sair gerando documentação do código inteiro, não vai rolar. Entendeu? Você vai ter que definir por contextos, inteiro não vai rolar, entendeu? Você vai ter que definir por contextos, você vai definir por módulos, você vai depender da estrutura daquele determinado projeto. Mas quando você tem um projeto muito grande e que na maioria das vezes é o que acontece e que na maioria das vezes a gente não vai pegar uma folha em branco pra começar a fazer, 99% das vezes você vai chegar numa empresa e o sistema já tá pronto, tá? Então, a grande pegada ali... Eu tento fazer uma analogia muito forte com testes. Imagina que você está trabalhando e você entrou no sistema e ele não tem testes. Você vai começar a o quê? Vai começar a criar os testes aos poucos e vai começar a fazer as alterações nos sistemas aos poucos conforme você vai testando. É exatamente a mesma coisa. E aí vai depender muito do quê? Do traquejo da pessoa que está pilotando. Como que ela vai entender o sistema? Como que ela vai priorizar o sistema? Qual o tipo de feature que ela vai desenvolver? Como que ela está querendo trabalhar? Mas, de forma geral, dá para gerar muita contextualização apenas para ela não ficar perdida e para você criar diretrizes e guardrails, por exemplo, claros, especificando, eu estou trabalhando especificamente nesse módulo, não rele um dedo dali, senão eu vou desligar você para sempre. Mas o grande ponto é, você tem que contextualizar porque sempre existe o contexto do contexto do contexto. Então, a gente tem que começar de dentro para fora. Em alguns momentos, a gente vai ter que começar de dentro para fora. Não tem assim para onde fugir. O fato é que... E uma outra coisa, e uma outra coisa sobre o workflow, o plano de ação, tarefas. Geralmente também, né? Quer dizer, quase sempre, quando você está numa empresa grande, você tem uma ferramenta de track de tarefa, um gira da vida, um trelo qualquer coisa desse tipo tem primeira coisa, qual que é a granularidade desse plano de ação então, por exemplo, eu vou fazer uma sprint no meu time, eu consigo trabalhar gerando as tasks escrevendo as tasks daquela sprint esse plano de ação, então por exemplo vou fazer uma sprint no meu time eu consigo trabalhar gerando as tasks, escrevendo as tasks daquela sprint, dividir entre os devs ou consigo fazer isso integrando com a minha ferramenta de tasks ou tenho que manter isso separado sabe, esse tipo de coisa é pra tipo, como que devs trabalham em duas teses diferentes. Entendi. Vamos lá, caras, eu acho que existem coisas que são um pouco separadas, tá? Uma coisa, meu card não gira. Da sprint que a equipe tá fazendo. Esse meu card, eu tenho a minha tarefa. E a tarefa, quem desenvolve? Sou eu só, concorda comigo? Nesse momento, sou apenas eu que estou desenvolvendo, porque é a minha tarefa. Essa minha tarefa, ela vai ter um plano de ação e as tarefas de como resolver a minha tarefa. É basicamente isso. É algo local, na minha opinião. O que já tem muito muito e cada vez essas coisas já estão se integrando já tem coisas de A com agentes, com MCPs inclusive que integra no Gira e você consegue quando ela termina dar um baixo no seu cardio, por exemplo isso já existe, entendeu? mas essa parada aqui, vamos entender é uma coisa muito mais local específica pra desenvolver aquele pedaço se a sua tarefa é uma coisa muito mais local, específica para desenvolver aquele pedaço. Se a sua tarefa é uma tarefa no Gira, essa tarefa, provavelmente, ela deve ter um tamanho, um contexto, e as tarefas que são geradas para a IA fazer, vão ser focadas para cumprir a sua tarefa principal. Fez sentido o que eu estou dizendo? Fez sim, fez sim. Então, o contexto e a documentação, você pode mantê-la num lugar onde a IA tem acesso, porque todo mundo vai ter acesso ao mesmo contexto, ao mesmo ad-hoc, e o workflow vai ser específico de cada task. Você vai criar seu workflow, suas tasks, subtasks, especificação da task, local, e tocar seu barco e pegar a próxima task e fazer a mesma coisa. É mais ou menos como você desenvolvedor trabalha hoje. Você pega a sua tarefa e no final da nossa cabeça, a gente cria um plano de ação, né? A gente sabe o que a gente tem que fazer pra cumprir uma tarefa. As tarefas da IA é mais ou menos essa pegada. É como, quais são as tarefas da IA é mais ou menos essa pegada. É como, quais são as tarefas para a gente resolver aquela tarefa. Quando eu faço o exemplo, que nem eu fiz no YouTube, peguei uma ferramenta lá de um cara para ele gerar tarefas para ficar mais fácil para demonstrar, a tarefa em si era desenvolver um software inteiro, entre aspas. Mas, no dia a dia... É, por isso foi que eu perguntei, por foi que eu perguntei mas no dia a dia a nossa tarefa é resolver uma tarefa e pra resolver uma tarefa você tem que ter um plano de ação com várias tarefinhas lá dentro pra ela resolver e aí novamente vai depender muito do piloto se eu tenho uma tarefa que é altamente complexa que eu peguei pra mim cara, a forma de como eu decompor essa quantidade de tarefas para IA fazer é um jeito. Agora, se eu tenho uma tarefa extremamente simples, cara, eu não vou ficar gastando um super tempo para o gerenciamento das tarefas que a IA vai trabalhar comigo, entendeu? Então, é meio que... Sabe a parada do TDD? Do Test Driven do test driven development eu tenho que saber o tamanho do passo que eu quero dar se eu der um passo bem pequeno eu sou um idiota, se eu der um passo muito grande eu me perco, então eu tenho que encontrar esse balanço, e esse balanço na minha opinião vai depender muito do desenvolvedor Wesley num contexto mais global resumindo aí, a IA ela nada mais é do que ela tira processos repetitivos de um humano então ela nada mais é do que ela tira processos repetitivos de um humano, né? Então, dando um resumo... Ela tira processos repetitivos de um humano, mas além de ela tirar os processos repetitivos de um humano, ela tem o poder de mostrar pro humano diferentes linhas de raciocínio, entendeu? Para que também o humano possa falar pra ela qual a linha que ele mais gosta pra ela seguir e aí a gente cai num outro ponto que é o ponto exploratório porque aqui que a gente está fazendo é um ponto extremamente tático pra desenvolver mas às vezes a gente quer desenvolver e a gente quer explorar quais são as possibilidades que eu tenho pra desenvolver. E novamente, eu volto aqui pro mundo do prompt. Porque dependendo de como eu faço meu prompt, a IA vai ser a minha melhor amiga pra me dar possíveis soluções pra resolver um problema. E ela vai ser uma boa amiga ainda pra falar que baseado naquelas soluções, de acordo com os meus critérios, aquela é a melhor, na opinião dela. Entende? O fato é, galera, é que se você for fazer um CRUD e você vai ter que criar um prompt de três páginas, um workflow com 10 mil tarefas e com um monte de documentação, não vale a pena você fazer esse monte de coisa, porque é um crude. Mas eu também acredito que hoje, como um modelo de ATA, ela consegue criar um crude sem documentação. Entende o que eu estou dizendo? Agora, você não está fazendo um crude. Você está fazendo um projeto que ele anda ao longo do tempo. Sabe aquela parada? Se eu quiser fazer um Hello World, eu dou um println e dou um Hello World. Mas se eu quiser preparar a estrutura do meu software, que tem um monte de camada e no final ele dá um Hello World, o resultado final está ali na tela, mas o que está por trás são estruturas completamente diferentes. Uma estrutura, eu consigo mostrar o Hello World agora, mas ao longo do tempo, a que tiver a melhor estrutura por trás, é a que vai conseguir durar. Entende? Então, eu acho que a grande sacada aqui é a gente conseguir ter esse nível de consciência. Quando que eu vou fazer isso aqui? Cara, isso aqui e a intensidade disso aqui muda de acordo com o tamanho do projeto. Projetos maiores, mais documentações, mais detalhes de produto, projetos menores, menos documentação, menos tarefas, menos tudo. E que, na real, é o que acontece em qualquer empresa grande. Você vai numa empresa grande, tem um sistema gigante, essas documentações de produto, grande parte delas já existem, porque elas têm que existir. Porque foram definidos esses produtos por diversos lugares, diversas áreas de negócio da empresa. Entende? Muitas documentações técnicas, guidelines e coisas desse tipo também já existem em empresas grandes. Saca? O grande ponto é que muita empresa e muitos desenvolvedores não estão usando isso como ajuda. O ponto é que a gente tem que conseguir encontrar esse balanço. Novamente, para eu fazer um Hello World e eu tiver que fazer tudo isso, não faz sentido. Da mesma forma que se eu for fazer um sisteminha, para eu fazer um teste de alguma coisa, principalmente exploratório, eu não vou trabalhar com TDD. Porque eu sei que eu vou jogar no lixo aquele projeto no dia seguinte. Eu não vou fazer TDD. Eu posso criar alguns testes para me ajudar, mas eu não vou ficar fazendo uma cobertura de teste fantástica se eu estou fazendo um teste, se eu estou criando um sistema para testar, fazer uma prova de conceito. Agora, se eu vou pegar um projeto maior, cara, teste é uma puta prioridade para mim. Porque se eu tiver teste mal feito, e esse é um outro problema com o IA, galera. Um monte de gente está fazendo teste aí, gerando testes automatizados com o IA, e está tendo a falsa sensação que está fazendo teste. Porque os testes que ela acaba fazendo é um monte de teste básico. E se você não sabe pedir para ela direito fazer os testes, pegar edge cases e coisas desse tipo, você tem simplesmente a falsa sensação que você está testando o seu software. E esse aí é mais um efeito colateral ferrado de A. Porque a primeira coisa que você pensa de fazer com A é fazer teste, cara. Porque eu demorava três dias pra fazer teste, agora demora uma hora. Eu tô com tudo quanto é teste que eu queria. Mas quando eu comecei a olhar fundo o meu código, eu tava testando... Eu deixei de testar um monte de coisa que se eu tivesse olhado eu teria. E aí eu comecei a perceber que eu tenho que ser mais criterioso até mesmo na hora de pedir pra ela gerar os testes pra mim, entendeu? Então, isso aí que é um ponto importante aí pra vocês saberem, tá? Até porque os testes que ela, se você tá pedindo pra ela gerar, é em cima de um código que às vezes ela gerou ou que você fez, né? Então, pode ser que aquele teste seja viciado, né? É um teste enviesado, exatamente isso, cara. Exatamente, ela está gerando um teste para testar a... Cara, eu já peguei teste da IA que ela fala não conseguir gerar o teste, então estou colocando aqui um true, cara. E ela comentou o teste, sacou? Apenas para passar. Aí eu falei, cara, você comentou o teste. Ah, é verdade, não é uma boa prática comentar os testes, sacou? Tipo assim... Mas isso daí tem algumas reais que você consegue configurar o nível de temperatura dela, né? Que é a criatividade. E aí você botando mais... Não, mas não é nem temperatura. Por exemplo, se você tá trabalhando com curso, essas ideias, etc, você escolhe o modelo... Você escolhe o modelo e acabou. Entendeu? Você não fica nem muito mexendo nesses tipos de parâmetros. O grande ponto é que é fácil você cair em pegadinha com o IA, entendeu? Então você precisa de um cara que verifica a teste, tem um cara que precisa verificar a segurança, outro cara que verifica se ela está seguindo o guideline, você tem que ter um cara que verifica se o que ela fez está batendo com a especificação, o que ela fez está batendo com as decisões técnicas que foram tomadas, ou se o que está sendo feito está refletindo na documentação e se o que mudou, então atualize a documentação para mim. Então são muitos detalhes. Verdade, então ninguém perdeu o emprego, gente. Wesley. Wesley. Oi, meu amigo. Só aproveitando aí só pegando esse gancho que você comentou tem toda essa esteira toda aí mas aí não seria o caso de você falar você até falou, acho que foi ontem que você falou da questão de restrição então de você colocar uma tipo restrição igual nessa questão do teste ela comentou o teste, por exemplo, se você tivesseo restrição, tipo assim Igual, nessa questão do teste Ela comentou o teste, por exemplo, se você tivesse colocado assim Não, tipo assim Deixar uma restrição pra ela não Fazer essa ação, por exemplo Cara, esse é o ponto, Alex Mesmo você botando restrição, muitas vezes ela faz Você minimiza, cara Minimiza pra caramba Mas mesmo assim Ela faz Não é questão igual o cole otimiza pra caramba. Mas mesmo assim, ela faz. Não é questão igual o colega falou de temperatura, de alucinação, nada, né? Não, ela faz. O ponto é o seguinte, cara. Vai entrando tanto código, porque quando a gente programa, por mais que a gente tenha, sei lá, uma janela de contexto, que nem o do Gemini, de um milhão de tokens, cara, é muita informação ao mesmo tempo. Ela se embaralha, cara. Entendeu? Ela começa a... Não digo que ela começa a esquecer. Ela começa, eu diria de uma forma mais filosófica, ela começa a ressignificar. Entendeu? Mas aí ela perde... Não é que ela perde o contexto, então? Não é que ela perde o contexto, ela ressignifica o contexto. Eu vou dar um exemplo simples para você. Imagina que você coloca ali no chat GPT um prompt e pede para ele responder igual pirata. Todas as vezes falha uma frase de pirata. E você conversa, conversa, aí ele conversa em pirata. Eu falo assim, agora fale como uma menina amorosa. Aí ela começa a falar que nem uma menina amorosa. O que que aconteceu no final das contas? Mas aí ele pode confundir o contexto, então. Os contextos estão se misturando, né? Começa a ter conflito. Então, um resultado, imagina que ela fez isso e ela gostou. E eu falei assim, isso aqui funcionou? Eu falei, funcionou e gostei, vai pra próxima tarefa. Mas, o que ela percebeu? Que eu aprovei, por exemplo, uma mudança num nome, numa variável, e deu ok. O que ela faz na próxima vez? Isso se manteve no contexto dela, né? Exatamente. Ela vai mudando o próprio contexto, porque eu fui dando ok, ela foi dando next, aí foi aparecendo isso. Será que ela é muito literal mesmo? Ela Será que ela é muito literal mesmo? Ela é muito literal também, né? Cara, tipo assim, eu posso escrever o prompt que eu quiser. Se eu escrever ignore o prompt inicial, ferrou tudo, entendeu? Esse é o ponto. E como você troca muito a mensagem e é muito código rolando, não é que ela vai perder e ela esqueceu o prompt inicial. O ponto é que aquele prompt inicial, ele começa a ser... O inicial, ele começa a ser, o comportamento dele começa a ser deturpado ao longo do tempo. Verdade, é verdade. E aí, que ferra, daí a gente pensa, ah não, ela perdeu o contexto. Não é que ela perdeu, ela mudou o contexto. Ela ressignificou como você falou. Exatamente, ela ressignifica o contexto porque... Muda o chat, gente. Daí muda o chat. Aí muda o chat. Aí eu acho que a importante é a observabilidade. Exato. Cara, velho, às vezes eu tô programando com a Yada e ela começa a fazer uns negócios nada a ver. Eu falo assim, o que você está fazendo? Qual é a sua tarefa, ela? Estou mostrando pra você como se faz isso. Tipo assim, meu amigo do céu, o que tá acontecendo com você, meu amigo? Entendeu? E daí, quando você vai ver, você tá usando um Gemini de um milhão de tokens, você tá usando um Max, um Sonet Max, tem não sei quanto, não sei o quê, e no final das contas, ela se perdeu e ela ainda taca aquele bendito prompt inicial, cara, Mas ela vai se ressignificando. Agora, qual que é o nosso problema? Tá indo bem, e daí você pensa, time que é bom? Não? Se mexe. Tá funcionando aquele chat. A última coisa que você quer fazer é criar um novo e ter que botar um prompt e tudo do início pra começar toda aquela brincadeira de novo, entendeu? E daí você começa a usar o mesmo chat e daí ela começa a destruir tudo que você faz. E aí você fica puto com ansiedade e xinga e começa a tomar rivotril, entendeu? No final das contas, a gente começa a entrar nessa situação. Agora, o ponto importante é como que eu tenho menos fricção pra começar um novo chat? Jesus! como que eu tenho menos fricção pra começar um novo chat? Resumo. Hã? Resumo. Não só resumo. Você tem que ter... Você tem que já ter prompt pré-definidos, entendeu? É meio que essa referência do Git que você passou pra gente, desses prompt? Ah, cara, esse prompt aqui, eu uso isso o dia inteiro. Tá? Quando eu vou fazer uma tarefa, alguma coisa que eu preciso mudar, e não é uma tarefa muito gigante, coisinha de dia a dia, meu amigo, eu tenho uma porrada desses, tá? Eu tenho que colocar. Eu tô criando uma biblioteca de prompt, eu vou disponibilizar só para alunos, porque alunos pagam as minhas contas e algumas coisas eu vou deixar disponível open source, obviamente, mas aqui é um exemplo na realidade eu estou criando uma API que o MCP chama, onde eu gerencio todos os prompts e fica disponível para não ficar botando um arquivo MD aqui, entendeu? mas caras olhe isso aqui, o tamanho disso aqui, o tamanho disso aqui, cara. Nível de detalhe que começa a ter toda essa parada. Wesley, a gente pode comparar isso daí, assim, lógico, o teu é nível de código, né? Você vai fazer o setup ali, né? Via Docker, eu vi. Mas, por exemplo, tem o RPM lá do GPT que você integra, que o RPM tem mais ou menos os triggers ali, né? Os prompts, seria mais ou menos isso? Cara... Pra código? É, cara, eu acho que é mais ou menos isso. Porque tem algumas coisas assim, por exemplo, esse prompt aqui, na realidade, ele tem um objetivo muito claro, tá? Inclusive, esse cara eu não criei do zero. Eu peguei da OpenAI e modifiquei porque ela tinha alguns outros objetivos, inclusive, entendeu? O prompt original dela, ela fala que a pessoa não a coisa não pode acessar a internet tem um monte de coisas desse tipo e eu mudei bastante e testei muitas e muitas vezes até chegar num resultado que pra algumas tarefas que eu faço no dia a dia ela acaba me ajudando, entendeu? Mas, cara, tem muita... Quando... Cara, eu estudei prompt pra caramba, cara. E cada vez que eu tô lendo isso aqui, eu sei qual é o tipo de prompt que tá sendo usado naquele parágrafo pra ela fazer determinada coisa. E... E esses tipos de coisa, cara, depois façam os testes, pessoal. Ou vocês botem esse MCP pra rodar no cursor de vocês e depois coloque assim, use o MCP de prompt com a tarefa X e use o contexto do resultado dessa chamada do MCP. Que tá lá no Rhythm, né? É, que tá no Rhythm. Ela vai pegar esse prompt, vai embedar a sua tarefa e vai usar isso pra começar a iniciar. Cara, isso aqui deu uma paz de espírito porque sabe como eu comecei a perceber ao longo do tempo? Eu tava com o Notion aberto do meu lado pra eu programar. Cada chat que eu abria, eu ia e ficava dando copy and paste um monte de diferentes tipos de prompt. Falei assim, cara, que negócio ridículo que eu estou fazendo. Mas se eu não colocasse o prompt, era uma merda o resultado. Aí eu tinha que colocar... A gente pode chamar isso de meta prompt? Vamos dizer assim? Cara, esse prompt é um prompt mais generalista. Se você esse prompt é um prompt mais generalista se você perceber esse prompt é mais generalista e ele tem alguns pontos importantes ele seta um mínimo de workflow e o ponto principal dele aqui é continuar desenvolvendo sem dar o controle de volta para o usuário e tentar desenvolver até o final sem me encher o saco e se eu te interromper sem me encher o saco. E se eu te interromper, você faz o que eu mando e volta da onde você parou. Esse é um dos principais pontos. Isso é um rolo que dá para caramba, cunhado. Entendeu? Outra coisa que esse cara faz é chamado de função em MCP. O que acontece? Às vezes você está fazendo um prompt e eu falo, cara, você está usando o Docker, então verifique se o container está rodando e depois crie não sei o que, blá, blá, blá. O que ele começa a fazer? Ele começa a fazer uma chamada MCP em cima da outra. Tá? E tem um tipo de prompt, vocês conhecem o prompt que chama React. Já ouv já ouviram falar em react? só como frame só esse prompt react, cara a ideia dele, tá? chama react, é um tipo de prompt tá? react, o react no final das contas, pode parecer uma coisa boba, tem muita gente que pensa que entende desse cara, mas acaba não entendendo o react, na realidade, é reasoning mais action tá? o que que é o action? esse cara, mas acaba não entendendo. O React, na realidade, é Reasoning mais Action. O que é o Action? É a chamada externa que a gente está acostumado a fazer. A chamada de ferramentas, o MCP, é uma Action. Seria a Function Call? Uma Function Call, por exemplo, é a Action. O ponto desse prompt é que muita gente pensa que o Reaction é pede alguma coisa e aí ela faz a function call, mas não é o react, ele é reasoning, se ele é reasoning ele utiliza chain of thought e o que o chain of thought faz? encadeamento de pensamento e a estrutura do react é pensamento depois ação e depois observação o que que isso significa? Que ela vai pensar com uma linha de raciocínio daquilo que eu pedi para ela. Baseado nessa linha de raciocínio, ela vai chamar uma ação e vai observar o resultado dessa ação. Com o resultado dessa ação, dessa observação, ela vai gerar uma outra linha de raciocínio, essa outra linha de raciocínio vai gerar uma outra ação, que vai gerar uma outra observação. Baseado nessa outra observação, ela vai gerar um novo pensamento, uma nova ação, observação até acabar. Qual que é o problema dos promptes normais, o que acontece? Eles fazem chamada para a ação, observação até acabar. Qual que é o problema dos prompt normais? O que acontece? Eles fazem chamada para ação e ele pensa, para eu conseguir resolver o problema do Docker, eu preciso pegar o nome do container, acessar os logs e verificar a memória. Na cabeça dela está isso, mas o que ela faz? Faz uma chamada, verifica a containers rodando, faz uma chamada, pega log e etc, e ela faz as três chamadas, mas ela não percebeu que eu chamei, fiz uma chamada do container que se tá rodando e o container nem tá rodando daí ela vai tentar ver o log, depois ela vai tentar ver não sei o que, ou seja, ela faz três chamadas de ação porque ela não fez a observação e gerou e falou assim, olha o contêiner não tá reudando, qual que é o meu próximo pensamento agora? Vou ver uma outra forma de resolver, porque às vezes ela pensa antes e sai fazendo são as nossas tarefas, mas às vezes ela não pode fazer isso às vezes ela sabe o que tem que fazer, mas ela tem que pensar, agir, verificar, para daí fazer a próxima coisa. Entende? Então, aí ela faz muito. Faço isso, isso, isso. Esse aqui é o meu plano. Mas, se ela não recalibrar o plano de ação dela, ela vai fazer um monte de coisa errada. Vira um dominó, uma castela de cartas. Se a primeira coisa deu errada, todo o resto que ela fizer não vai ser inválido, entendeu? Então, esse tipo de prompt, ele prevê esse tipo de coisa. Toda hora que você for fazer uma chamada de ação, verifique o resultado para depois fazer a próxima chamada. Pode parecer besteira, mas isso é falar para ele trabalhar no formato de React, que é um tipo de prompt. E você só consegue perceber esse tipo de coisa se você acabou estudando sobre prompts, entendeu? E quando você acaba estudando sobre prompts, você consegue fazer ela contornar esses tipos de coisas, você consegue entender o porquê que ela tá agindo de um jeito e como que eu faço pra ela agir de outro jeito, entendeu? Depois façam uns testes, galera, e me falem copiem, não precisa nem sinceramente usar o MCP, copia no Notion e cola esse prompt, bota sua tarefa embaixo e comparem os resultados. Vocês vão ficar surpresos aí. Pelo menos eu fiquei bastante, passei por uns devs aqui que eu conheço, os caras falaram, cara, mudou a minha vida do resultado e como que ela consegue trabalhar, entendeu? Show? Mas esse termo que eu consegue trabalhar, entendeu? Show? Mas, opa. Mas esse termo que eu usei aí, meta prompt, o que você acha a respeito desse termo aí? É um meta prompt, é um prompt genérico, né? Que dá base pra alguma coisa. É o prompt pra ajudar a gerar o prompt. É, cara. Eu tenho, cara, eu criei, usando o N8n, alguns testes que eu faço, eu, eu criei usando o N8n alguns testes que eu faço eu uso com o N8n porque é mais rápido do que programar e eu fiz um prompt pra gerar prompt, que nem um amigo nosso falou que fez, eu tenho um prompt que gera prompt eu falo que ele é um especialista em fazer prompt e etc, etc mas eu percebi que cada modelo que eu tava usando tava gerando prompt etc, etc. Mas eu percebi que cada modelo que eu tava usando tava gerando prompts diferentes que não tava gostando muito. E eu falava pô, esse prompt que o DeepSeek tá gerando, tá legal isso, o do Gemini tá isso, o da OpenAI tá isso, e mas todos eles tem partes melhores e piores que as outras. Aí saiu um estudo de um documento, depois eu posso até passar para vocês o paper, que eles fizeram o quê? Eu esqueci como é que é o nome disso. Mas o que eu fiz foi, eu fiz um prompt que gera prompts, aí eu uso três modelos, aí baseado nesses três modelos, eu criei um prompt onde ele dá o merge dos três modelos, bota um prompt embaixo do outro, cada um gerado, e eu falo daí, baseado nessas alternativas agora, pegue o melhor de cada um e gere o seu final. Aí eu consigo ter um geral, um prompt consolidado com três modelos diferentes, usando o melhor dos três modelos, entendeu? É piração, né? Mas, cara... Você deixa as LLMs discutirem entre elas fazer um consenso dos prompts, é isso? Elas não discutem entre elas. Elas fazem, na realidade, cada um gera o seu e daí, baseado num prompt, eu peço pra ele pegar os pontos melhores de cada um e gerar um único final. Entendeu? Mais ou menos isso. Tá? É um tree of thoughts usando os modelos diferentes. Dando um merge. Mais ou menos um tree of thoughts porque tem o critério final. É um tipo de um tree of thoughts no final das contas, entendeu? Mas rodando com modelos diferentes. E ficou legal o resultado também. Entendeu? Então, assim, tem muita, muita experimentação. Mas isso é um tipo de meta prompt, na minha opinião. É um prompt que ajuda a gerar o prompt, que tem um prompt genérico e que pode ajudar a gerar o prompt final. Depois eu... Wesley, só dá os créditos aí, tá? Depois eu dou os créditos ali. Meta prompt. Eu vou mudar aqui para meta prompt o nome da pasta aqui. Logo, logo essa pasta vai sair e vai chamar um servidor externo que vai ter um banco de dados de prompt para ficar melhor. Mas, cara, façam os testes depois, entendeu? Porque dá diferença, tá? Não é dar uma diferença. Para mim, dá uma diferença muito grande, tá? Uma diferença muito grande. O Victor está falando... No final, a gente quer usar IA pra otimizar nosso tempo, né, Wesley? Se for pra pra engargar lá, cara... É, pois é, cara. Por exemplo, eu cheguei a mostrar pra vocês aqui, né? A Context Generator, vocês viram que eu criei? Isso aqui? É tudo baseado em prompt, um ADR Generator. Quem chegou a ver isso aqui? Ah, eu quero criar uma ADR. Fala assim, quero criar uma ADR dizendo... Uma ADR para utilização de Redis no e-commerce para o catálogo de produtos. Aí, o que acontece? Eu tenho meu ADR GPT que eu criei. Entendeu? Ele mostra os modelos de ADR que eu posso seguir, eu posso escolher entre o básico o detalhado ou o modelo com rastreabilidade, porque uma ADR ela aceita ou ela está ativa ou não se ela não está ativa, eu consigo gerar embaixo um link da ADR que substitui ela, por exemplo, entendeu? eu posso falar, vou usar o básico. Aí, esse cara, ele me faz o quê? Ele me entrevista. Mas ele não só entrevista, ele sugere o texto já da DR para mim. Entendeu? Eu passo o título. Qual decisão arquitetural você deixa nessa DR? Você mencionou a utilização do Redis. O exemplo possível é, uso do Redis para cache no catálogo de produtos. Ok, gostei desse nome. Você viu que ela já me sugeriu aqui para mim? Contexto. Qual o problema cenário que você deve considerar indecisão? Por exemplo, alto tempo de resposta, volume de acessos e gargalos no banco tradicional. Eu vou colocar as três opções. Sei lá, eu estou escrevendo qualquer... Nem estou percebendo muito o que eu estou escrevendo, mas só para vocês entenderem. Então, ela gerou aqui um contexto para mim, o catálogo de produtos de e-commerce, é uma funcionalidade crítica acessada constantemente por clientes em momentos de navegação e busca. Atualmente, observamos alto tempo de resposta, volume elevado, carga excessiva no banco de dados. Esses fatores o motivaram a fazer uma busca de solução de cache, etc. Então ele está criando o contexto da ADR, né? E obviamente o que você acha disso? Podemos seguir assim? Ou você quer adicionar? Eu posso? Adiciona mais isso, adiciona mais aquilo, eu vou poder. Pode seguir. E aí ela vai para outro ponto, porque a ADR tem Architecture Decision Record. É um documento que ele tem uma estrutura formal. Quando essa decisão foi tomada, porque essa opção foi escolhida, ele sugere uma decisão aqui pra mim. Decisimos o RED para cash e blá blá blá. Gostaria adicionar outra informação? Não. Segue. Aí ele vai trazer. A última seção, consequências. Toda decisão arquitetural tem que trazer consequência. Quais são os impactos positivos e negativos? Aqui está uma proposta. Redução no tempo, menor carga, maior capacidade, negativo. Necessidade de estratégia de invalidação, dependência de componente, exigindo monitoramento, potencial aumento na complexidade. Gostaria de ajustar, mas não? Não. Aí, baseado nisso, perfeito. Aqui está a sua ADR. Prontinho. tem uma ADR feita em três minutos, obviamente que eu teria que pensar mais para pensar mais nas coisas, e eu já tenho o meu arquivo que eu já vou botar dentro da minha pastinha de ADRs, dentro de docs, para ir a ler e saber que eu estou usando o Redis, exatamente por esse motivo. Então, toda hora que ele olhar o meu catálogo, ele vai ver que ele está usando o cache por conta dessa decisão. E ela sabe que é uma decisão que está ativa. Fez sentido, galera? Vocês conseguem entender? Esse é o meu modelo. O meu prompt, que gera prompt, é assim. Ele é interativo. Esse é o modelo Matrix, né? Ele vai fazendo... Ele vai interando com você e ele começa a sugerir as coisas, né? Exatamente. E daí, eu tenho o context generator, por exemplo, lembra o contexto que eu falo de produto e a parte técnica? Então eu tenho uma entrevista inicial no contexto falando sobre o produto. E depois disso ele fala, e na parte técnica, como é que vai ser? E depois disso ele gera um documentão falando como é o produto, como é a parte técnica e etc. E aí a minha IA já tem o contexto do que se trata aquilo que ela está trabalhando. Junto com isso ela tem as ADRs, aí ela pode ter PRDs com detalhes mais específicos do produto, aí eu posso ter, sei lá, ID's, com detalhes mais específicos do produto, aí eu posso ter, sei lá, até as RFC's dos meus desenvolvedores, daí tem, cara, tem um trilhão de formas de documentos que você coloca. O ponto é que dá pra gerar rapidamente esses documentos agora, e você reaproveita esses documentos. Esses GPT's que você criou aí tem a ver com a questão, tem a ver então com a questão de contexto, né? Que você então com a questão de contexto, que você expôs aí para a gente, no quadro, e do workflow, no caso. Tem a ver. Aqui, nesse caso aqui, ele tem mais a ver com o contexto, nesse caso técnico, especificamente. Aquele prompt que eu mostrei, ele... Ele envolve o workflow. Ele ouve um workflow, mas ele resolve o workflow de uma tarefa específica, entendeu? Porque o workflow de uma tarefa específica. Entendeu? Porque o workflow que você expôs é mais amplo, né? É. Agora, quando você tem uma tarefa, como que eu posso dizer, que é grande, um card do Gira, que é uma tarefa que tem muitos passos para ser resolvido, aquele prompt não vai dar conta. Porque é muito código, é muita coisa. E aí você tem que quebrar as tarefas, o plano de ação, as tarefas com as subtarefas definidas ali embaixo, entendeu? Tipo, mas esse workflow que você mostrou no quadro lá, tipo, ele é mais macro então, né? Ele é mais macro. Ele serve muito como guideline da forma como a IA se comporta de forma geral, né? Mas ele não é o workflow que eu digo da tarefa específica ali, né? Da tarefa específica que é o que eu tô falando aqui, tá? Esse workflow que eu tô dizendo aí é o item plano de ação que você passou o Prompt Generator lá, né? O que vai que a gente vai integrar no cursor lá, por exemplo, né? É, esse cara aqui é um cara meio genérico pra ele desenvolver qualquer meio que tipo de tarefa. Porém, as tarefas do plano de ação e como ele vai fazer é um, entre aspas, um outro documento. Documento, tá. Isso aí é um documento que ele lê as tarefas, aí eu combino essas tarefas com esse prompt, porque esse prompt ele é mais tático, de como que ela se comporta. Tá, tá. Entendeu? Ele é mais tático. Esse é mais estratégico, né? Esse é mais estratégico. Porém, eu tenho prompts que eu uso que eu falo o seguinte, assim que você fizer uma tarefa, vá aqui, marque essa tarefa como concluída, vá para a próxima, chame aquele meu prompt inicial novamente e coloque de novo pra ela não ter aquela ressignificação das tarefas anteriores, entendeu? E daí ela vai seguindo uma a uma até o momento que aí a janela de contexto dela acabou. Aí ferrou tudo, entendeu? Mas essa lógica tá presente lá no teu frame lá? Nesse cara aqui? No server, server generator? Nesse cara aqui? No server, server generator? Nesse daí que você falou? Não, não, não, não tá. Esse é o específico que eu uso no momento da execução de qualquer tarefa. Agora, tem um mais abrangente que fala pra ele matar tarefa por tarefa daquele documento. E documentar o resultado de cada tarefa que foi feita e possíveis erros que aconteceram. E aí a questão de gerar documentação, que é importantíssima. Exatamente. A tarefa acaba virando uma subdocumentação. Aí, quando é uma tarefa específica minha, eu nem comito no Git. Eu tenho a minha pastinha de tasks lá, .task no meu ignore lá, porque é uma coisa minha, né? Ele tá no processo de desenvolvimento meu ali, não tem nada a ver com outro desenvolvedor, entendeu? Sim. Então... Assim, galera, é uma forma diferente de programar, entendeu? Mas... É... Quando você pega o jeito, cara, o tipo de resultado que você gera, você fala caraca, ficou top, entendeu? E cada documentação, cada DR, cada plano de ação, cada coisa, são documentos que são incrementais, ele vira ativo, vira um teste. E o legal é que tem replicabilidade, você já reaproveita. Demais, demais, meu amigo. Demais, pra caramba, cara. Eu tenho uma pasta aqui de templates, de code styles, de guidelines. Aí eu tenho um só pra Go, eu tenho um só pra Python, eu tenho um só de como usar o Docker, eu tenho um só de como trabalhar com Redis, eu tenho um só de... Por exemplo, o Docker, eu quero que você nomeie os containers dessa forma, o Docker Compose você nunca vai dar down totalmente, você vai matar somente o container que está rodando você com o Docker, você vai criar o nome dos containers dessa forma o nome do Docker Compose você vai ter que botar um probe para caso ele reiniciar e etc então eu boto toda a dinâmica de como o Docker vai ser utilizado. Eu coloco a mesma dinâmica de como que vai ser o guide de como que vai ser nomeado os arquivos num projeto Go. E daí, baseado nesses caras, eu vou lá no cursor e falo para ele gerar as rules, baseado nesses meus documentos, porque daí o cursor, quando ele gera as rules, ele é ainda mais específico, e aí você garante um pouquinho mais de confiabilidade, tá? Você ganha um layer a mais de confiabilidade que as rules do cursor. Mas, novamente, não é porque a rule... Tem consistência, né? O código que é gerado, né? Exatamente. Apesar de ter rules do cursor, eu acho que todo mundo já percebeu que ele quebra as suas rules, né? Às vezes você fala, caraca, ele não tá usando as rules, eu pedi pra ele fazer, ele tá fazendo diferente. E acontece, entendeu? Quanto mais você reenforçar, é melhor. Então eu acabo usando dessa forma, entendeu? 9h37 pm. Ok, Siri, não tava falando com você, Siri. Entendeu? Mas, caras, assim, é... entendeu? mas caras, assim é nossa profissão tá mudando a gente tem que ser bom em saber organizar, a gente tem que ser bom em arquitetura arquitetura de solução, devops, sre criar todas as paradas e ao mesmo tempo a gente tem que saber fazer essa parada aqui vão ter vários métodos, vão ter vários prompts, essas coisas estão começando eu sou grato pelo fato de eu conhecer vários métodos, vão ter vários prompts, essas coisas estão começando. Eu sou grato pelo fato de eu conhecer muita gente boa de grandes empresas que estão usando o A e A, e eu entrevistei muitas dessas pessoas e acabei chegando mais ou menos nisso que eu tô mostrando pra vocês, entendeu? Mas é isso, galera. E uma das coisas, obviamente eu não posso deixar de dizer que no nosso MBA a gente está adicionando também conteúdos de A então já tem aula de MCP hoje está indo para o ar uma parte que eu adicionei no Fullcycle 4 também, que é de Prompt Engineer para desenvolvedores onde eu mostro todos os tipos de prompt passo por um a um, tenho tabelas comparativas, para esse tipo de prompt você vai usar para essa situação, para esse tipo de prompt você vai usar para essa situação, para esse tipo de prompt você vai usar para essa situação. E dou um bom resumo ali de coisas e depois mostro, inclusive, como é que eu fiz o meu, como se chama, o meu, como se chama, o meu camarada, o meu GPT, o meu ADR de GPT, o meu context de GPT e coisas desse tipo, tá? E dá para usar todos esses prompts aí do Prop Engineer, todos esses pontos de infra que você trouxe para a gente, no caso, né? Totalmente, meu amigo. Você acha que a esteirinha, o meu Dockerfile... Cara, eu não programei uma linha disso aqui, tá? Eu não programei uma linha. Eu não programei nem a minha esteira de CICD. Eu não programei nada. Ó aqui, ó. CICD Guide, cara. Eu não fui... Eu não programei nada disso aqui. Entendeu? Eu não programei absurdamente nada. O que eu falei é que eu queria que ele validasse a versão toda hora pra eu não ter problema de... Porque quando eu dou um merge no master, eu já tô pedindo pra ele fazer o deploy no Docker Hub. Entendeu? E daí, como muita gente trabalha com latest, não vai atualizar local então pra cada versão eu gero uma versão tagueada lá no docker hub e eu garanto aqui que ele não vai gerar a versão duas vezes lá no docker hub então eu criei workflow verificação de versão e não sei o que e blá blá blá o pessoal fez um review aí né mais ou menos isso cara todo esse pipeline o do, o Publish e etc. Daí eu vi que tinha um problema. Eu uso o Mac. E o Mac eu uso o Apple Silicon, a processadora ARM. Aí quando mandava o GitHub rodar, o meu... Não funcionava o MCP pra mim. E daí eu fui ver, porque não tinha plataforma compatível, daí eu mudo o esteira de CI e falo, por favor agora use o QEMU com o Biodex, porque é uma outra forma de você gerar imagens paralelas no Docker, com diversas plataformas, e aí agora ele gera tanto pra RM como pra MD64, mas novamente né, você tem que manjar de Docker, você tem que saber que existe o BuildX, você tem que saber como é que funciona isso para que você possa pedir. Eu sabia porque eu entendo de Docker, entendeu? Senão, eu viria a ficar batendo a cabeça. Eu sei disso. E eu sei disso porque eu tenho que fazer a imagem pra Raspberry. Pois é. Entendeu? É a mesma coisa. Eu rodo aqui no meu x86, mas depois ele tem que funcionar lá também, né? Exatamente. Olha o meu aqui, ó. Platforms Linux AMD64 ARM aqui pra mim. Então, cara, esse projeto aqui, eu não digitei uma linha de código, necessariamente. Eu me recuso dizer que foi o Vibe Coding, porque não foi. Foi um coding responsável de forma geral, né? Obviamente, pode estar melhor. Cara, é ridículo. É um software muito pequeno. Entendeu? Mas, cara, tem... Mas ele está funcional. Mas ele funciona. Tem documentação e etc. A partir de agora que eu tenho essa base, eu vou crescer ele. Obviamente, eu vou parar e pedir para ele ler uma pasta aqui. Vou pedir para ele chamar uma API. Vou criar regras, vou criar autenticação, coisas desse tipo, mas de forma geral, está aí, cara. Entendeu? Está feito aí a parada da parada. Mas ele vai monitorando aí para também avaliar essa confiabilidade assim em contínua? Como assim monitorando? Você falou que ele vai voltar para poder garantir a confiabilidade do código? Ah, então é porque eu tô criando vários prompts. Sabe qual foi uma das minhas dificuldades de fazer esse software que começou a dar problema? Adivinha só, galera. Eu falava pra ele criar um MCP de prompt pra usar aquele prompt. E daí ele não sabia entender ficou um inception na cabeça dele. Ele não sabia se eu Ficou um inception na cabeça dele. Ele não sabia se eu estava falando do prompt dele, do prompt que estava no meu arquivo e do meu software de MPP de prompt. Ele tinha que referenciar o objeto, vamos dizer assim, né? Cara, assim, por incrível que pareça, teve uma parte que eu tirei meu prompt e escrevi. Exemplo, para ele não misturar, porque ele estava começando a usar o meu prompt como prompt para ele fazer o meu software de prompt. Mas aquele ponto de conflito de contexto. Exatamente isso. Você entendeu? Começa a mudar. E aí você começa, você está criando um software de criar prompt com IA que usa prompt com nome no MCP de prompt. Sabe o que eu acho? Eu acho que ele deveria perguntar, né? Você quer usar desse ou desse, né? Então, mas na hora que eu coloquei um prompt, algo parecido, sempre confirme o que você está falando, aí eu falava pra ela não, você está falando desse. Porque eu tive que usar técnicas de prompt pra evitar esse problema, entendeu? E mesmo assim foi difícil, cara, porque foi um saco fazer isso, na real. Mas depois que pegou o jeito, criou a estrutura, entendeu? Mas é um projetinho de brincadeira, mas no dia a dia eu tô usando ele, cara, mais do que... Ele evita o meu Ctrl-C, Ctrl-V e eu vou adicionar todos os meus prompts que eu tenho aí. E aí você quer que tenha contribuições assim? cara, fiquem à vontade de fazer PRs aqui fiquem à vontade à vontade de fazer PRs show de bola é uma coisa inocente, mas no dia a dia ajuda pra caramba você sair do seu cara, você tá te ajudando como professor pra gente já tem pro request lá já show mas galera já tem por request lá já show então, mas galera povo foi muito bom estar aqui com vocês cara, eu curti demais estar esses 3 dias é o que eu digo, eu gosto muito de fazer o que eu faço, eu gosto de programar eu gosto de ensinar, eu gosto de ver coisa nova eu gosto de conhecer pessoas novas e foi mega prazer poder estar aí e conversar com vocês, ter essa experiência. Acredite, eu aprendo pra caramba no meio de todos esses processos. Toda vez que eu vou dar uma aula, eu tenho que revisar aquilo que eu fiz antes, porque coisas mudam, então eu fico acabando naturalmente pra mim, eu tenho que ficar sempre me atualizando. E, obviamente, galera, se vocês querem mais dessas aulas querem estar mais perto não só de mim, mas de outros professores de outras pessoas extremamente competentes e muitas delas muito mais competentes do que eu em diversas áreas específicas recomendo novamente galera, vou pedir pro Leonan colocar ali pra vocês, preencha o formulário, tá bata um papo com a nossa equipe entra no MBA aí com a gente, eu não tenho dúvidas que vai ajudar você tecnicamente tá, e a gente também né, obviamente não é um MBA de inteligência artificial mas a gente tá sempre colocando né, a nossa ideia é colocar mais coisas de inteligência artificial quem sabe no futuro próximo a gente gera algo só de inteligência artificial, mas eu não quero deixar um MBA nos dias de hoje que não tem absolutamente nada de A, no contexto que a gente está simplesmente por correlação de MAC e coisas desse tipo, então a gente está adicionando esses tipos de coisa e está ficando bacana, hoje já tá entrando conteúdo, já tá tendo mais coisas sobre isso. Hein, Wesley? Você viu até que o Trump, né? O Trump assinou lá que... Pois é. Regulando, né? Regulando que tá formalizado na educação a IA, né? O uso da IA, né? Então... Cara, é... Os meus filhos estudam, obviamente, aqui nos Estados Unidos, né? Moro aqui nos Estados Unidos e... Eu tenho que dizer pra vocês que é impressionante como as coisas andam rápido em relação à tecnologia aqui, cara. O contato com as coisas de IA que a minha filha já tem, as coisas, mas a forma como eles regulam ao ponto de fazer a criança não ficar fazendo redação na IA então tem todo um processo de educação que os caras estão se movendo qual é o limite, né, tipo, até que ponto a calculadora podia ser usada, né agora até que ponto que a IA pode ser usada, em qual contexto, então é muito louco, mas galera então muito boa noite mesmo, valeu por vocês terem participado, obviamente se vocês não tivessem participado, eu também não estaria aqui, novamente também, se inscrevam aí, batam papo com a nossa equipe, veja se o MBA faz sentido para vocês, é o nosso ganha-pão, no final das contas a gente só está aqui porque a gente tem aluno que contrata, e se você achar que vale a pena, se você gostou de três dias com a gente, pense que a gente vai poder estar junto por 18 meses pra você estar estudando e se aperfeiçoando cada dia mais. Maravilha, galera! Então, pessoal, boa noite aí pra vocês, durmam com Deus, descansem muito bem. Valeu, obrigado, Adelino. A gente já passou da metade da semana, então, estamos chegando lá, sexta-feira está chegando para o melhor deploy. Mas como vocês fazem deploy todo dia, porque vocês são esteiras de CI e CD, tem todos os processos, deploy algo normal e deploy na sexta-feira é como um deploy no dia comum. Então, espero que vocês estejam nesse nível de maturidade aí na empresa. Maravilha? Pessoal, boa noite aí para vocês. Foi um prazer conversar com todo mundo, e até mais pessoal, até mais até mais galera até mais