Você ainda usa IA como ferramenta ou já evoluiu para Squads Cognitivos?

Seja muito bem-vindo a mais um episódio do VibraCast, esse espaço que chama para conversar líderes de tecnologia, executivos, CTOs, CIOs, que são as pessoas que estão tomando as decisões mais difíceis nesse momento revolucionário do mercado de tecnologia que a gente está passando com a entrada da IA.

Eu sou o Leandro Oliveira, sou seu host e anfitrião aqui nesse podcast, sou também CEO e cofundador da Vibra. Nós somos uma consultoria que ajuda as empresas a repensar os seus processos de desenvolvimento de software, trazendo a IA como pilar fundamental. Não é a gente trazer a IA como uma ferramenta, mas sim repensar um novo fluxo de trabalho, onde a gente integra humanos e agentes de IA.

A intenção nossa é ajudar as empresas a reduzir o ciclo de desenvolvimento em até 85%, justamente onde a gente tem uma nova forma, o modo operantes, de executar software nesse novo momento que a gente está vivendo no mercado. Hoje a gente vai discutir sobre um tema muito relevante que eu e o meu convidado estamos vivendo na prática, que é ajudar as empresas justamente a passar por esse processo de transformação de seus modelos de desenvolvimento tradicionais para o modelo de squads cognitivos, que é exatamente essa nova metodologia que nós lançamos no mercado.

E a gente vai começar trazendo os desafios, dificuldades, dores, do ponto de vista de quem está liderando e tomando as decisões dentro das empresas. Seja o CTO, o CIO, o executivo, o diretor de tecnologia, o head de tecnologia, que precisa justificar para o board como é que ele vai ter ROI nessa estruturação, nessa transformação e também ajudar o time a conseguir passar por esse processo, que envolve impacto em processo, em cultura, em nova forma de trabalho.

e bagunça um pouco o dia a dia. Hoje, para falar comigo sobre esse tema, estou aqui com o Everton Bernardes, que é o nosso CTO aqui na Vibra. O Everton já atua há mais de 15 anos com o desenvolvimento de software, liderando essa técnica construção de produtos digitais. Além de CTO da Vibra, ele também é CEO da ForCódigo, contribuindo para a evolução de modelos de delivery mais aderentes à nova realidade de regiões de software.

Ao longo da sua trajetória, liderou projetos em diferentes contextos de negócio, com foco em estruturar soluções, escalar produtos e tornar os processos de desenvolvimento mais eficientes e sustentáveis. Obrigado.

Hoje tem atuado de forma direta na aplicação prática do modelo de squads cognitivo, integrando humanos, experientes e agentes de IA e um fluxo de engenharia orientados a velocidade, qualidade e previsibilidade. Não deixando de lado governança e segurança, que são super importantes nesse momento, onde a gente fala de estruturar um processo dentro de sistemas que já estão rodando, código legado.

Bom, Everton, fica à vontade para se apresentar, meu querido. Leandro, obrigado pelo convite. É um prazer estar aqui para falar um pouco do que a gente tem visto na prática, essa transformação do mercado através da IA. E estou muito empolgado aqui poder compartilhar isso com o pessoal e contribuir para essa transformação em mais empresas. Maravilha, meu querido. Obrigado por aceitar o nosso convite aqui.

E Everton, vamos discutir um pouquinho da prática, do que a gente está fazendo no dia a dia. Eu separei algumas perguntas aqui para guiar a nossa conversa, mas vamos trocando essa ideia, vamos fluindo. É bastante conhecimento que a gente já tem de enfrentar isso, de ajudar os nossos clientes a implantar esse modelo. Então vou começar com uma aqui. Quando você apresenta o Squad Cognitivo, falando do ponto de vista mais técnico, para o CTO, pela primeira vez, qual é a reação que você costuma haver dessa liderança?

O primeiro ponto, quando a gente apresenta, primeiro parece ser bom demais, né? Então é algo que a gente tem, inclusive, trabalhado nas demonstrações a ponto de levar efetivamente a mudança que a gente pode trazer na cadeia como um todo.

Então, essa apresentação, esse primeiro contato do CTO, normalmente o CTO já tem essa visão estratégica de que a IA pode transformar o negócio dele. Mas quando a gente traz resultados como 70% de redução do time dentro do ciclo de desenvolvimento de software, é muita coisa. Quando a gente olha para o benchmark de algumas outras ferramentas, de ferramentas que estão aplicadas ao processo, a gente começa a perceber que 70% é muita coisa.

E realmente essas ferramentas não chegam a uma otimização de 70% em geração de código. Por quê? O ciclo de desenvolvimento é muito mais do que o desenvolvimento de código em si. Então a gente está falando desde entender o contexto na camada de negócio.

prototipação, análise técnica da solução, desenvolvimento em si, code review como um todo e aplicação de QA, documentação e então entrega de valor para o cliente final. Então esse ciclo é o que a gente tem otimizado e garantido essa expressividade dos números dentro do processo como um todo.

E essa é a primeira quebra de paradigma que a gente traz para que o CTO possa entender exatamente o que a gente está fazendo. Quando ele olha o que o mercado está fazendo com base em codificação, os números são diferentes. Por quê? Existem gargalos novos que muitas empresas estão esbarrando.

Um deles é o próprio Code Review, a própria qualidade do desenvolvimento que tem barrado o código de chegar em produção. Com esse ciclo que a gente tem aplicado dentro das empresas, a gente tem pensado no processo como um todo e não necessariamente no processo existente da empresa.

Então a gente fala que a gente está colocando basicamente ao redor da IA o novo processo. E não colocando IA dentro do processo existente para apenas adaptar ele. Então não é uma adaptação, é realmente uma nova forma de ver esse desenvolvimento de software como um todo. Sim.

É uma coisa que eu e o Everton, geralmente a gente vai junto nas conversas e passa por essas inseguranças, vamos dizer assim, que a gente escuta tanto do CTO quanto do CEO, principalmente do CTO que tem que depois justificar lá no board o porquê fazer um investimento de transformação e não só adotar uma ferramenta ou botar um agente no processo.

E aí eu acho que nessa conversa a gente também consegue mapear ali a maturidade que a empresa tem em relação ao uso ou não de IA, o quanto que o hype afetou ou não a organização, para eles entenderem que de fato é algo um pouco mais profundo que tem que ser feito.

Bom, eu tenho bastante perguntinha aqui, então eu vou seguir aqui para a gente poder aproveitar bem esse tempo aqui com o Everton. Vamos pensar agora aqui direto nas objeções que são mais comuns que a gente escuta do pessoal, essas inseguranças. O meu código legado tem mais de uma década, a gente vai dar conta.

Como você responde a isso? Como é que a gente consegue deixar esse CTO, que geralmente são produtos que tem bastante tempo de mercado, que não podem ter falhas, que a gente não pode deixar IA lá alucinar e bagunçar tudo ou direcionar IA para fazer alguma coisa nova, vai lá e mexe no que está funcionando, depois gera uma outra dor de cabeça.

Ainda mais que a gente lida com empresas que têm softwares com um nível de exigência de qualidade muito alto no mercado. Se der um problema lá, inclusive, às vezes pode acontecer até um processo judicial, algum acionamento um pouco mais difícil. Como é que você vê? E pensando justamente nessa questão do legado, como é que a IA pode ser usada?

para contribuir. Muito bom, muito bom. Um ponto que eu sempre trago do legado é que o legado, ele também vem acompanhado de conhecimento que se perde ao longo do tempo. Então, aquele desenvolvedor que saiu da empresa há 10 anos, mas ele levou 20 anos de conhecimento dentro do sistema legado.

E isso tem sido um gargalo de crescimento para as empresas. A cada desenvolvedor que sai da empresa, ela passa por um período de...

buscar conhecimento novamente sobre a própria aplicação e não consegue acelerar efetivamente. Ou seja, mesmo que a empresa esteja ganhando tração naquele produto, existe esse gap conhecido no mercado.

Hoje com o IA, independente se eu estou falando de uma aplicação nova, uma aplicação com microserviço, uma aplicação legada, monolítica enorme, a gente consegue extrair esse conhecimento. Eu gosto de falar que o maior conhecimento para esse processo, para o contexto está dentro de casa, que é o nosso próprio Git. Dentro do próprio Git, a gente consegue ter os padrões de commit, a gente consegue...

entender funcionalidades que foram publicadas ao longo do tempo. E aí que está o nosso ouro, né? De a gente conseguir extrair tudo isso e transformar em contexto para que a IA possa gerar código com o padrão que a nossa equipe gera. Claro, se a equipe está gerando com um bom padrão, né? Então não vamos replicar padrões errados também.

Mas efetivamente é ali que a gente consegue extrair esse conhecimento, seja para uma aplicação legada de muitos anos ou trazendo para uma nova aplicação com ciclos de desenvolvimento contínuo. Então no legado eu tenho histórico. Isso é bom porque a gente começa no ponto zero com muito contexto.

Na aplicação nova, eu tenho que desenvolver os ciclos. É como aprender a andar de bicicleta. No momento que tu aprende a andar de bicicleta, tu começa com as rodinhas, depois tu vai tirando a rodinha, aí tu cai, aí tu levanta, tenta andar sem a mão, aí tu cai de novo, aí tu já sabe que não pode mais tirar a mão.

Então esse processo do aprendizado ali da IA como um todo, para esse ciclo de desenvolvimento, basicamente é um processo semelhante. A gente erra uma vez, entende que o código foi para um padrão que não deveria e a gente retorna para o padrão que deveria funcionar.

O que eu vejo é que muita gente esbarra nesses primeiros problemas, até porque começa a fazer o processo, ou melhor, não dá nem a chamar de processo, né? Começa a fazer de forma desestruturada e não chega a ter essa melhoria contínua para poder chegar nos resultados que efetivamente a IA pode entregar.

Já disse que não funciona. Exatamente. Não tem uma insistência. A IA está aloprando. Alucinando, tem que ter os problemas de correção. Até essa próxima pergunta que ela encaixa nisso. Quem responde quando a gente erra? Como fica a cadeia de responsabilidade técnica e jurídica num squad onde parte da produção vem com a IA? Até antes de te passar a palavra.

Hoje de manhã a gente estava discutindo isso na CTO Real, que é a comunidade que inclusive o Everton faz parte. Eu lancei ano passado uma comunidade chamada CTO Real focada em reunir líderes de tecnologia para poder discutir, abrir conversas entre pares, aquelas discussões que às vezes não cabem no LinkedIn e que não tem aquele espaço para o pessoal poder tomar um cafezinho com pares. Então esse espaço é muito para isso. E o pessoal estava questionando essa questão da... Putz, se eu tenho lá um código longo e aí eu sou um programador raiz...

Aí bota a IA, ela vai dar problema, depois eu vou virar babá de agente e ter que corrigir isso, né? Como é que você vê isso? Quem responde quando a gente erra? Muito bom. Quem responde é quem continua, quem já responde hoje no processo, né? Então, o humano, ele é o centro do processo, apesar de a gente estar falando que ele tem que estar em torno da IA. Por quê?

A IA está sendo regulada pelo humano. Então, quando eu digo que em cada ciclo a IA está aprendendo, eu estou dizendo que o humano deu um feedback dizendo que aquele ponto está ruim. Então, ou seja, não é a própria IA que está trazendo isso.

Eu vejo muito o pessoal colocando dentro do processo, o processo de code review automatizado. Então, eu tenho aqui o meu copilot dentro do processo de code review. Quando tu olha o copilot, ele está lá entendendo a sintaxe do negócio. Então, basicamente, ele entende o padrão do que foi comitado.

mas ele não está muito preocupado com qual era a funcionalidade que estava sendo criada. Então, ou seja, aquele contexto acaba se perdendo. Então, ou seja, o humano é o responsável por esse processo, então ele é o responsável por passar em cada etapa, então ele dá o aval de cada etapa. No momento que uma funcionalidade está pronta para o planejamento, significa que o humano deu esse aval.

Ontem mesmo, em uma das minhas esteiras ali, eu peguei para revisar umas tarefas, então eu lá com o meu celular revisando tarefa no Gira, e basicamente eu vi que um dos itens não fazia sentido e estava lá no roadmap. Esse item, basicamente, da forma como foi definido ali, ele simplesmente quebraria a autenticação em outro sistema que faz parte do ecossistema da empresa.

Então, esse tipo de situação, provavelmente eu não pegaria se eu não estivesse utilizando IA dentro desse processo, porque a funcionalidade já estava no ponto de planejamento. Quando ela está no ponto de planejamento, eu já sei o que ela vai implementar. Eu sei efetivamente o código que ela entende.

que é o código assertivo para chegar naquele resultado que eu preciso. Então, ou seja, antes de eu repassar para a minha equipe executar, eu consigo fazer essa validação rápida. É claro, aqui eu tenho muitas squads, então eu não consigo regular todas elas, mas a gente tem dentro do processo pessoas responsáveis para fazer isso.

algumas squads que são menores a gente utiliza o próprio tech lead como responsável do processo como um todo, entrou um item dentro dessa esteira, o tech lead é o responsável por levar até o final claro dependendo da etapa, ele vai ativar uma pessoa ou outra para poder chegar nesse resultado

Só que a gente tem outras esteiras extremamente complexas, que são áreas inteiras que estão responsáveis por uma etapa. E aí, claro, cada etapa tem seu responsável e os seus portões de acesso, onde a gente coloca guardrails para garantir que vai ser aprovado pelo humano e só então a IA vai executar.

Acho que aí é a questão que a gente vem falando sobre a mudança do papel das pessoas no processo. E uma coisa que eu fiquei pensando essa semana sobre algumas discussões que a gente estava tendo sobre a questão de cultura. Acho que nesse processo onde a gente tem ali o desenvolvedor deixando de codar e passando para um outro papel, vamos dizer assim, no processo.

é importante, já que a gente está falando para as lideranças entenderem que é papel das lideranças prepararem essas pessoas para essa mudança de postura. Que nem a gente tem, às vezes, dentro do ambiente organizacional, a questão de eu elevar uma pessoa que está lá no operacional para uma liderança, para uma questão de posição onde eu vou direcionar e não fazer.

Acho que esse processo que a gente faz com os devs é muito nessa linha. A gente tira do fazer o código para eu orquestrar os agentes a fazer. Então, de certa forma, é uma posição de liderança, só que uma liderança de agentes. Se eu não preparar essa pessoa para ter uma maturidade de gestão, um olhar quanto a isso, de que agora o meu papel é controlar o processo, o resultado desse processo e não executar o processo...

É muito difícil de que quem vai passar por isso entender, que ele tem que mudar esse ponto de vista. E aí acontecem as reclamações. Mas eu sou um cara que gosta de criar código, agora estou tendo que ser babá de agentes. Então acho que esse é um ponto que realmente impacta e que faz parte da liderança poder preparar o seu time para conseguir desempenhar nesse cenário.

Everton, vamos para a próxima aqui. Agora é onde a gente mais escuta aqui dos CEOs, CTOs, o ROI. Que métricas de ROI você considera que são honestas? E quais são vaidade pura nesse momento do hype atrapalhando um pouco disso? Por que medir linhas de código geradas ou percentual de PRs com IA pode enganar o board? Ótimo, ótimo.

Um ponto que a gente percebeu durante a utilização de IA, seja o desenvolvedor lá programando com GPT, com cursor, com end-surf, ele vai gerar mais linhas de código. Então o primeiro ponto de erro de quem gera código com GPT é que ele vai gerar muita coisa duplicada.

Apesar de que alguns desenvolvedores dizem Ah, eu boto no GPT para unificar a função. É duplicação de código na maioria das vezes. Então, ou seja, se a gente for para uma linha de entender quanto que o Leandro está gerando de linhas de código e quanto que eu estou gerando dentro daquela mesma equipe, eu não vou conseguir entender o desempenho dos dois.

Quando eu passo a olhar MR, então MR, PR, por request, basicamente eu consigo entender o quanto de entrega efetiva o Leandro e o Everton estão fazendo. Só que aí entra também a questão de que durante esse período...

houveram muito mais MRs e PRs abertos ao longo do ciclo da IA como um todo ali até o momento. Por quê? Antes o pessoal simplesmente não fazia. Então, ou seja, o commit era muito direto.

Hoje, com a IA, já tem o benefício de alguns pontos que eram um pouco burocráticos dentro do processo de desenvolvimento de software, o pessoal está fazendo de forma mais natural. Por quê? Porque se popularizou muito quando eles vão ver um vídeo de alguém ensinando a trabalhar com um cursor, um end-suff, a pessoa já vai falar, ah, aqui vocês podem pedir para comitar.

ele vai comitar com um padrão de PR. E tudo isso está levando os desenvolvedores a criarem mais PRs. Só que não necessariamente esse PR está atingindo o objetivo estratégico da organização como um todo. E é aí que a gente tem que ter essa...

mudança de visão. A gente não pode olhar para essas duas métricas como sendo métricas de crescimento dentro da organização. Exemplo, numa squad que eu coloquei em um mês de execução, eu aumentei em 28 vezes o número de PRs. 28 vezes a gente está falando de um número estratosférico aí, né? Então, claro, quando eu olho para esse número então

que era o tradicional, que eu levava isso com o cliente, já não faz mais sentido hoje. Por quê? Agora, nessa squad que eu citei, eu estou com pessoas da camada de negócio trazendo feedbacks, que são feedbacks extremamente...

importantes para UX, para uso final, só que isso não vai fazer o cliente ir para o mercado antes. O que vai fazer o cliente ir para o mercado antes é que siga o planejamento que foi estipulado junto com o cliente de caminho crítico para o seu sistema, do que ele precisa para colocar em produção e objetivos que a gente já definiu como marco desde o início. Então, ou seja, aumentei em 28 vezes.

Também aumentei esses comites e essa publicação dentro das tarefas do caminho crítico. Mas olhando esse ciclo por completo, a gente vai ficar em torno dos 50% a 70% que eu tinha citado anteriormente. E não em 28 vezes.

Que aí é um número absurdo. Quando a gente começa a olhar isso, a gente olha um dado enganoso. Quando a gente olha para o usuário final que está recebendo aquela funcionalidade e um tempo que ele não receberia antes, aí sim é onde a gente consegue ter essa métrica da forma correta. Ou seja, antecipação de mercado. É isso que a gente tem entregado para o cliente, diminuindo esse ciclo de desenvolvimento como um todo.

acelerar na direção errada, essa métrica não vai mudar. Se eu estiver indo na direção errada, a outra vai mudar, mas vai mudar para mais. E é isso que a gente tem focado e trabalhado estrategicamente junto com os clientes para sempre focar no que ele precisa e não efetivamente em tudo que a própria Squad quer. Sim. A gente teve recentemente a ida para Marte. Para Marte. Meu Deus, eu estou avançando no tempo.

Para a lua, né? E aí eu faço uma analogia nessa questão da aceleração com a IA. Com essa questão do foguete, né? Não é mais problema a velocidade do foguete sair da Terra e para o espaço. Vai ter velocidade para você chegar. Mas se eu erro um grau de ângulo, eu já saio da rota e vou para outro lugar completamente diferente.

É muito mais intenso essa estruturação de base, de direcionamento para onde eu quero chegar, do resultado que eu quero atingir, do que se eu vou ser rápido ou não nessa saída aqui do foguete. Então, acho que esse é um ponto que é importante do pessoal pensar. E quando a gente fala de ROI, complementando o que você trouxe, como eu converso muito com o pessoal de negócio, mais a nível diretoria, CEOs, para mim tem dois pontos que são fundamentais. E eu acho que casa com o conteúdo que você fez até essa semana falando sobre...

Por que a gente faz as coisas lineares, considerando que a gente tem um novo contexto e a gente pode repensar o processo e paralisar algumas coisas. E aí, são duas métricas, para mim, de ROE de impacto claro, para nível de negócio e organização. Um deles é o ciclo de desenvolvimento que encurta. Então, esse é o cycle time, que a gente sabe. Então, o que demorava antes, meses, a gente consegue encurtar para semanas. Então, isso já está claro.

mas o segundo é o Go to Marketing, antecipação de mercado, você comentou. Por quê? O Go to Marketing agora, antes ele dependia do quê? Putz, para eu lançar esse produto no mercado, eu preciso esperar todo esse tempo de desenvolvimento e aí eu começo as minhas ações de... começar a preparar minhas ações de marketing, de vendas, fazer o meu setup ali para daí ir para o Go Live, vamos dizer assim. Agora esse grande processo que antes demorava muito, ele está super curto.

E às vezes ele é tão curto que eu preciso paralelizar a minha preparação de marketing, de vendas para ir para o mercado, porque não é mais o problema agora. Eu posso fazer as duas coisas em paralelo. Porque quando eu chegar no momento que eu quero lançar, o software já vai estar pronto. Então, muda a forma de pensar no lançamento de produtos, no lançamento de novas releases para o mercado, go to marketing absurdamente com a IA.

Então, eu acho que a questão que o pessoal está tendo dificuldade de entender é eu não posso mais usar padrões, processos e modo operandes que eu usava antes nesse novo contexto. Porque senão eu sempre vou chegar nos meus problemas ou dizer que a IA não funciona ou dá problema, enfim. Quando eu repenso e penso, entendo isso e repenso os meus processos organizacionais, inclusive de lançamento de produtos e novas versões.

a gente tem coisas que a gente tem visto nos nossos clientes, que estão conseguindo em paralelo e preparando lançamentos, já fazendo convenções de venda, já assinando contratos comerciais, enquanto as entregas de software já estão acontecendo, demonstrações já estão sendo feitas, e no dia de lançamento, de fato, oficial, o produto está redondo, 100% pronto para ir para o mercado com qualidade. Então, acho que esse é um ponto bem interessante.

Vamos lá, próxima. Existe um momento em que, para adotar um squad cognitivo, vira decisão... Desculpa, deixa eu reformular a pergunta. Existe um momento em que parar de adotar o squad cognitivo vira uma decisão racional, ou seja, quando o ROI não fecha e não faz mais sentido seguir com o squad.

Então, esse eu tenho um caso prático, né? De um caminho inverso que eu segui. Eu não vi esse tipo de situação, né? É claro, se a gente tem um contrato também, pensando no modelo tradicional, e a gente está antecipando para o cliente...

meses de mercado. Então eu acho que ao invés de a gente olhar para o processo e dizer que esse processo não faz sentido para aquele cliente, a gente olha para o contrato e muda a forma de trabalhar com o cliente como um todo. Então eu até já tinha comentado em alguns casos.

sobre um cliente específico que não fez sentido mais esse tipo de contrato tradicional, onde eu levei para o contrato de squad cognitivo com uma esteira automatizada. E a mesma equipe que atendia anteriormente esse cliente...

hoje está atendendo o cliente com uma qualidade muito maior, porque consegue passar de forma redonda em todos os processos, e atende um outro cliente também no mesmo modelo. Então, ou seja, aqui eu consegui, primeiro, elevar a qualidade, que é onde eu consigo justificar para o meu cliente por que ele vai estar pagando mais.

Ou seja, eleva a qualidade e entrega mais rápido. Do outro lado, eu consigo, com a mesma equipe, atacar múltiplas frentes. E isso muito pelo padrão do processo. A gente está falando aqui de uma equipe mudando de contexto ao longo da semana.

Então, eu não estou falando mudando de contexto de um produto A para o produto B da empresa. Eu estou falando de trabalhar com gestão de projeto e trabalhar com construção civil. Eu estou falando de contexto totalmente diferente e que a mesma equipe...

Faz isso de forma natural. Se tiver outro trabalho que essa equipe precisa utilizar, exemplo, é muito comum em grandes empresas ter devs emprestados. Como que eu empresto um dev para outro time se ele precisa entender o contexto?

Na verdade, o que ele precisa é conhecer o processo como um todo e o contexto é carregado para que seja utilizado para que ele consiga performar o quanto antes. A gente viu isso na prática com diversos clientes, desenvolvedor entrando num processo extremamente complexo e fazendo uma entrega de 30 dias em menos de 2. Então, ou seja, basicamente tudo isso se deve à questão de a gente usar a IA.

para trazer esse contexto para o Dev e quase um per-program, né? Aquele desenvolvedor de 25 anos que está ali do teu lado, se tu está na dúvida, tu pergunta para ele. E se ele está na dúvida, ele busca. Eu acho que esse é o ponto, né? A IA não está ali para trazer apenas o contexto estático, mas ela tem a capacidade de buscar dentro do meu ecossistema da própria empresa ou APIs externas, aquilo que eu estou buscando.

Ela trouxe para mim, eu valido a informação. Ou seja, a informação está chegando muito antes. Sim. Acho que, por enquanto, como você falou, a gente não viu nenhum cenário que precisou reverter para o modelo tradicional. Mas acho que uma coisa que a gente aprendeu na nossa jornada de adoção da IA, que já veio há bastante tempo, desde 2023 a gente está fazendo isso, é que adaptação é regra. A gente tem muita imprevisibilidade em relação à evolução da IA. Toda semana a gente vê uma notícia nova, um impacto diferente no mercado, do...

uma surpresa, uma mudança. Então a gente não tem como saber se isso vai ser uma linearidade e se esse modelo vai funcionar eterno. O que a gente sabe é que o modelo tradicional é obsoleto. Isso é fato. E aí uma evolução para o modelo cognitivo tem que ter apresentado resultados consistentes com estabilidade. Se daqui a pouco surgir uma nova variável, provavelmente a gente vai ter que considerar ela de novo no jogo e repensar o processo. Então acho que faz parte. Não é uma coisa escrita em pedra.

Sobre dependência de fornecedor, como você arquiteta para poder trocar de modelo cloud ou deep seek, seja mudança de configuração e não restrita de algo do squad inteiro. Essa é a questão de a gente não ficar preso. O pessoal fala muito disso. A metodologia do squad cognitivo precisa usar cloud, muito caro, aquela coisa. Como é que você vê esse ponto?

Muito bom até pelo contexto das últimas semanas. Então o Cloud tentou lá bloquear o Cloud Code para o plano PRO dos novos entrantes. Então a gente acaba ficando refém do que o fornecedor está trazendo para a gente naquele momento.

Nesse sentido, a gente tem estruturado não focado no fornecedor em si, mas nas metodologias que esses fornecedores usam para chegar no melhor resultado possível. Exemplo, a gente utiliza múltiplos agentes, mas múltiplos agentes podem ser usados no Cloud Code, podem ser usados em ferramentas abertas.

Pode ser usado no Cloud Code com modelos abertos. Então, ou seja, basicamente a gente não está muito focado em dizer não, tu tem que fazer uma certificação do Cloud Code. Amanhã é cursor para todo mundo. O EndSurf tem que botar um despertador e já te acorda para iniciar o dia com um bom dia. Não, nada disso a gente tem colocado como regra do processo.

A regra do processo é estruturar essa infra para que a IA possa entender o contexto e performar com a melhor ferramenta do mercado naquele momento. Então, basicamente, a gente traz isso para dentro de uma orquestração.

E essa orquestração pode usar tanto um modelo dentro de casa, onde eu tenho lá o meu servidor rodando um modelo específico que eu replico para os meus devs. Eu poderia estar rodando com um modelo como o GLM Minimax direto na nuvem deles.

Ou eu posso ir para um cloud, windsurf, cursor, como preferir. Basicamente, a gente não se preocupa muito com aquele fornecedor. A gente não tenta ganhar desconto em cada fornecedor. A gente se preocupa em cada passo que a gente dá junto com o cliente. Se aquela metodologia vai conseguir escalar.

com um novo modelo e com uma nova ferramenta. Quando eu falo de contexto, basicamente eu estou falando de um contexto, seja de arquivos ou de RAG, que eu possa utilizar independente do que a gente tem hoje. Ah, vai surgir uma nova ferramenta que vai ler isso melhor. Ok, como que eu estou organizado para receber essa nova ferramenta?

Então a gente tem desde empresas que têm documentação do PO, documentação técnica e documentação de marketing, a empresas que têm comite escrito ajuste. Então, ou seja, tudo isso a gente tem que transformar em contexto e é o que a gente tem feito.

e transformando em contexto estruturado para que do dia zero tu já tenha uma geração que faça sentido, né? Porque essa também é uma resistência dos desenvolvedores, né? No sentido de ter a primeira geração do código e começar os questionamentos, né? A IA não está legal, a IA está colocando um monte de coisa aqui que não deveria. Sem esse contexto, ela vai fazer. Porque tudo que ela conhece é o que ela está vendo do código.

E o que ela está vendo do código, muitas vezes o padrão não está de acordo. E aí entra aquele dev, aquele dev que gosta de codar, aquele dev resistente e o novo papel dele. Que a gente falou um pouco agora. Basicamente esse dev...

É o que a gente deve reposicionar para esse papel de criar padrões. Quanto mais técnico deve, mais ele consegue entrar nesses padrões e definir para onde ela deve ir. E claro, ao longo do tempo, isso vai se tornando natural e ele vai elevando o nível também.

Ou seja, ele não vai regredir por não estar programando. Pelo contrário, ele vai estar programando na criação de padrões, dando feedback de code review e elevando o nível de desenvolvimento dele, porque ele vai cada vez buscar padrões com uma melhor escala, com uma melhor estrutura para poder ter novos resultados. O exemplo, quando a gente começa a colocar o ciclo de desenvolvimento com o Squared Cognitivo...

o pessoal começa a acender aquele alerta, né? Pô, eu poderia colocar um Sonar Cube aqui, né? Já é um ponto que o pessoal não via antes. Não é que não via, era muito trabalho. Não tinha tempo, né? Exatamente. E não é muito trabalho colocar o Sonar Cube.

O trabalho é que isso aumenta o ciclo de desenvolvimento porque tu tem que seguir aquelas regras que tu está impondo no teu portão de qualidade. E quando a gente traz isso de forma nativa, essas conclusões elas são...

automáticas. O dev começa a trazer, poxa, agora faz sentido eu fazer isso. O teste automatizado. O teste automatizado, por muito tempo, ele foi deixado de lado em muitas squads. Se tu for perguntar para todas as startups aí que tu conhece, boa parte não faz teste automatizado. Por quê? Ela antes, realmente, tirava um percentual ali dentro do ciclo de desenvolvimento.

Esse percentual entra naquela questão de antecipação de mercado. Ou seja, eu posso chegar um mês antes, ou eu posso fazer teste automatizado e chegar com mais qualidade. Então, existem os dois caminhos, mas é uma decisão que você tem que estar tomando quando você está na direção técnica de uma startup a todo momento.

Então, em alguns momentos, tu vai optar pela qualidade e em outros momentos, tu vai optar pela velocidade para que tu possa ganhar mercado. Agora, a gente tem a opção de trazer isso de forma nativa dentro do ciclo e conseguir avançar nas duas frentes. É mais uma escolha, né? Exatamente. Acho que tem dois pontos que você falou aqui. Um deles que eu faço um paralelo que deixa mais claro para o pessoal, ainda mais quem é mais de negócio, vendas, não é tanto de técnico.

O que a gente leva de Squad Cognitivo é parecido com o que uma metodologia como Receita Previsível faz na área comercial. É a metodologia. Não é que a Receita Previsível precisa trabalhar com um CRM em específico. Um Salesforce, um Pipedrive, seja o qual for. O Squad Cognitivo é a mesma questão. É uma metodologia de trabalho. É uma forma diferente de você trabalhar.

Que traz mais eficiência e ganho no processo e você pode ajustar para cada uma das ferramentas. E outro ponto é essa questão que você falou sobre o desenvolvedor, a questão da IA. O pessoal fala assim, a IA errou, a IA está fazendo bagunça. Não é a IA, cara. É o humano que está direcionando a IA ou o processo que foi feito pelo humano que está errado. Então, a IA, nesse escopo aqui, é uma ferramenta. Ela não é uma inteligência autônoma como a gente, vamos dizer assim.

Então ela vai seguir o direcionamento que o humano der e a premissa do processo que ela precisa respeitar. Então se a IA está errando, é o humano que está errando. Então acho que a gente tem que parar de ficar delegando a responsabilidade e não querendo assumir a nossa.

Exatamente, até um ponto que eu estava comentando da postagem que eu fiz essa semana, um ponto que eu trouxe lá, apesar de eu falar que o processo está em volta da IA, eu coloco o humano acima da IA. Por quê? Significa que em cada etapa que a IA está aplicada...

O humano está ali não só para trazer a supervisão, mas para ele usar ela para o desenvolvimento contínuo dentro daquele processo como um todo. Então, no modo tradicional, a gente olha os nossos gargalos dentro do processo e, periodicamente, a gente dá aquele próximo passo para melhorar aquele processo como um todo.

Hoje a IA olha isso de forma nativa. Ou seja, em cada etapa que eu tenho a IA aplicada, eu consigo ter o meu feedback de erro. Exemplo, se eu estou gerando um código com IA e quando o meu desenvolvedor pega para finalizar esse código, eu tenho 5 commits do desenvolvedor? Espera aí, então onde que ela errou? Ela errou em 4 commits.

basicamente nesses quatro commits é onde eu tenho o conhecimento que eu tenho que retornar para ela para dizer que não está afinado o suficiente para que o código possa ser gerado de forma mais rápida. Uma coisa que a gente começa a fazer quando o CTO tem dúvida lá na primeira apresentação, que foi a nossa primeira pergunta hoje

demonstrar esse fluxo na prática. Então muitas vezes quando a gente está nessa demonstração, eu faço uma funcionalidade junto com o cliente e essa funcionalidade nem sempre ela acerta direto. Eu trago normalmente com uma granularidade específica que caiba também num desenvolvimento ali dentro de uma apresentação.

E muitas vezes eu tenho que fazer um refinamento. E esse refinamento, às vezes, é colocar um toe tip, alguma coisa nesse sentido. Não é que eu vou pegar lá, vou abrir o meu VS Code, o meu IntiSurf e vou sair codando. Não, eu consigo fazer essa alteração até mesmo pelo meu sistema de gestão. Porque lá ele já tem o link de preview do meu sistema, do meu sistema eu já consigo visualizar o que foi aplicado, consigo ver e fazer um code review.

E se tiver maior complexidade, simplesmente eu coloco lá na etapa que o meu Tech Lead assume. Então, independente da Squad que eu tenho hoje, se eu quiser intervir e colocar qualquer item lá, basicamente eu coloco o item, eu verifico se o planejamento está de acordo e o meu Tech Lead vai levar isso até o final e provavelmente final do dia ou amanhã já estaria em produção, mesmo que eu não prossiga dentro daquele processo como um todo.

Então, ou seja, aí a gente ganha autonomia também para trazer coisas dentro desse processo de desenvolvimento, né? Às vezes ideias de negócio, às vezes pontos de segurança ou pontos muito técnicos.

Que a própria equipe está focada hoje no roadmap de desenvolvimento, naquele objetivo estratégico que eu citei, e não está vendo no dia a dia. Antes, o que acontecia? A gente deixava no roadmap lá engavetado de meses, e quando chegava nesse item, ele já não fazia mais sentido. Hoje a gente tem a capacidade de atacar esses itens de uma forma natural.

E não é algo que vai trazer um gap operacional dentro da nossa squad. E também não vai trazer um problema de qualidade dentro do produto. Por quê? Eu estou falando de pessoas específicas que podem intervir dentro do processo. Que isso também é importante, né? Quem que pode...

evoluir em cada etapa desse processo. Se a gente falar que o estagiário, ele pode criar o seu item e levar pra produção, a gente tem um problema. Nada contra o estagiário, mas ele não conhece a complexidade toda dentro da tua cadeia pra poder fazer esse tipo de coisa. E por isso que, quanto maior a complexidade,

maior a cadeia de pessoas até chegar na produção, não diminuindo a complexidade da cadeia como um todo, a complexidade, qualidade, digamos assim, mas abstraindo a complexidade de quem está vendo de fora. Não necessariamente eu vou entrar mais no código e identificar linha a linha, mas eu vou olhar o code review e vou entender que ele botou um SQL Inject, por exemplo. Por quê? Na hora que eu jogar para a etapa de code review,

eu já vou receber esse feedback, eu já vou olhar. Se eu não receber esse feedback, também é papel do humano olhar o code review. A questão é que hoje ele vai olhar um code review pós-code review de IA, conhecendo o contexto como um todo daquela funcionalidade e fechando o code review com os novos padrões que tem que ser aplicado.

Cara, eu acho que esse é o ponto de quebra na cabeça da galera, que é mudar o modo operandis do paradigma de trabalho que ele tinha que ir antes. Ele tinha que abrir o capô e mexer no código. Putz, se eu não sei o que está no código, que a gente escuta muito dos desenvolvedores, como é que eu vou saber o que código que a IA gerou? Com um processo redefinido, como a gente está falando, o código cognitivo, a gente cria uma nova camada de abstração que permite a visibilidade do que a gente precisa, controlar no processo, que não pode sair da nossa alçada, vamos dizer assim.

E conseguir agir, sem precisar entrar num nível que a gente precisava entrar antes. Mas como o pessoal está habituado a trabalhar nesse contexto, de abrir o capô e mexer, sujar a mão, quando entra aqui o pessoal fica inseguro até. Tipo, pô, mas como é que eu vou... Quer que nem chegar um mecânico e falar, tu vai corrigir o motor olhando nessa tela, entendeu? E não lá abrindo, né? Então, tipo, pô, é difícil para a galera conceber, né?

Mais um ponto, cara, que você trouxe aqui que eu acho que é uma ficha que está começando a cair para algumas empresas. Inclusive, essa semana mesmo teve uma nova empresa que procurou a gente e me trouxe o seguinte questionamento. Olha, eu preciso fazer algumas entregas, mas eu tenho um contexto extremamente volátil. Ou seja, eu não tenho um cenário de um escopo bem fechado.

é possível? Você acabou de falar que é. Então a gente começa a entrar num cenário onde a gente começa a ter a possibilidade de trabalhar com escopos não fechados. E isso não ser um problema no desenvolvimento do software, como sempre foi. Ah, não, para eu poder fazer um projeto preciso ter o escopo super fechado. Depois começa aquele bate-volta, aquela briga entre quem está desenvolvendo e quem está mudando de escopo. Começam a se desfazer essas dores, essas dificuldades que a gente tinha devido ao processo tradicional de antes.

Então realmente é uma desconstrução. E eu sei que é um processo inclusive de adaptação de quem trabalha com desenvolvimento do software que não vai ser rápido. A gente está no início dessa curva e dessa jornada. Por isso às vezes quando a gente fala do que a gente está fazendo, do que a gente vê acontecendo, dos resultados que as empresas conseguem fazer, parece meio assim, não, isso aí ainda é futuro, ainda não existe. Mas existe, é só você debruçar um pouco mais em cima de processo e querer entender que há uma evolução acontecendo.

Everton, cara, sensacional, está sendo esse papo aqui, mas a gente vai ter que encerrar a última pergunta aqui, focando nas lideranças. Daqui a 24 meses, qual é a empresa de software que vai estar em desvantagem competitiva real? A que adotou o Squatch Cognitivo cedo demais e errou? Ou a que esperou para ver as outras adotarem primeiro?

Essa pergunta é muito boa, Leandro. É aquele ponto de a gente, muitas vezes, não querer dar o próximo passo. Eu gosto de trazer um paralelo sempre, né? E eu vejo isso um paralelo com um carro elétrico.

Então, basicamente, eu posso estar na dúvida se eu vou conseguir alcançar aquele ponto específico porque o carro elétrico tocar a bateria num ponto que é uma desconfiança, que talvez não chegue. Porém, se eu não der o próximo passo, se eu não for até lá, eu já sei que eu vou parar aqui. Então, meu carro vai ficar para trás.

então, ou seja, de qualquer jeito se eu não der o primeiro passo, meu carro vai ficar para trás, eu tenho duas opções achar um ponto seguro então, ou seja, com a IA a gente tem que achar um ponto seguro, a gente não precisa mirar nos 70%, mas se eu conseguir otimizar 10% e conseguir reduzir meus custos de operação conseguir ter uma eficiência operacional eu já consigo estar junto com o meu concorrente ali então

se eu conseguir chegar no 40%, 50%, eu já ultrapassei meu concorrente. Então, o que eu quero dizer é, meu carro acabou, bateria no meio do caminho. Beleza, mas eu estou no meio do caminho, meu concorrente está lá atrás ainda. Se eu estiver junto com ele, eu ainda consigo recuperar, é só aumentar a eficiência, eu ainda posso...

arriscar um pouco mais pra chegar no 70%, digamos assim. Mas se eu ficar pra trás ali, simplesmente eu vou ter que achar outro caminho e esse outro caminho pode ser tarde demais.

Então, tarde demais porque eu posso estar com um produto no mercado que meu concorrente vai conseguir colocar pela metade do preço, com evoluções técnicas que eu não vou conseguir acompanhar. E esse é o perigo hoje. Então, um exemplo, antes a gente tratava o reconhecimento de imagens como algo...

é extremamente difícil de fazer. Hoje existem ferramentas que a gente coloca uma funcionalidade dentro do nosso software que está cobrando um token extremamente barato e eu consigo já entregar valor para o meu cliente. Então, esse tipo de tecnologia...

a gente consegue estar aplicando e trazendo inovação para o cliente no dia a dia, pensando nesse modelo. Porque o dev não está mais focado em codificar, ele está focado em entregar valor. O que ele achava impossível antes, agora é possível. O impossível não era impossível tecnicamente, era impossível por tempo de execução. Ele não tinha tempo para parar e colocar uma funcionalidade.

que agregaria muito valor para aquele cliente final, que era uma inovação, mas que levaria seis meses para desenvolver. Hoje, funcionalidades de seis meses estão sendo tiradas do papel muito rápido. A validação dessas funcionalidades tem sido mais rápida. Então, a experimentação como um todo.

E muitas empresas que antes tinham perdido esse DNA de inovação, acabaram retomando, porque optaram por um modelo como o Squared Cognitivo. Sim. Eu tenho falado para alguns diretores sobre a questão que a gente está numa corrida.

Você entendendo isso ou não, mas a gente está numa corrida. Então agora é uma questão de quem vai entender isso e aceitar e querer correr mais rápido que o concorrente ou não. Mas que essa corrida está acontecendo é inevitável. Então ninguém mais tem 12 meses para lançar um produto, uma nova versão. Seis meses, inclusive, já é um tempo demais para o contexto que a gente está vendo agora. A gente está vendo projetos que demoravam, entregas que demoravam.

Teve uma que a gente trabalhou que estava engavetada no cliente por dois anos. Em dois meses, a gente fez aquela grande release e saiu do papel. Aquele grande marco, vamos dizer assim, do produto e saiu do papel. Então, eu acho que é uma questão de quanto você está disposto a...

deixar de lado as tuas inseguranças, os medos, os receios do novo e dar um passo. Como você falou, se eu ficar onde eu estou, eu já sei o resultado que eu vou ter, que é o processo tradicional ou alguns ganhos pontuais. Se eu arriscar, vamos dizer assim, se eu quero reduzir de 12 meses para 3, é um tiro alto.

Mas se por acaso der um problema e eu sair de 12 para 6, já deu metade, já foi um ganho de 50%. É melhor eu tentar fazer isso do que eu ficar parado e ter que desenvolver em 12 enquanto o meu concorrente está entregando interesse e assinando contratos que deveriam ser meus. Então acho que é isso. Everton, muito obrigado pelo papo, cara. Foi muito bom. Foi uma aula e uma troca que a gente conseguiu ter muito bacana. Acho que espero que você que tenha acompanhado a gente até aqui tenha conseguido aproveitar essa discussão. Everton, quer deixar uma mensagem final para o pessoal?

Sim, gostaria de deixar uma mensagem. Primeiro, agradecer pelo convite, mas o que eu queria trazer é muito associado a essa última pergunta. Então, dê o seu primeiro passo com relação à utilização da IA, a utilização da IA dentro de um processo estruturado, eu acho que isso é importante.

Como eu falei ali do carro elétrico anteriormente, basicamente eu estava falando que a gente poderia ir dali para frente. Se a gente trouxer um processo não estruturado e só colocar IA, a gente também pode regredir. A gente também pode colocar dentro do código coisas que vão diminuir a qualidade dentro do nosso produto. Ou seja...

Estruturem um processo e coloquem a IA dentro desse processo. Esse processo, ele é melhor do que apenas dar ferramentas para o desenvolvedor. E eu vejo muita empresa fazendo isso hoje e isso acaba virando um caos de longo prazo, né? Então, estruture o processo, traga os guardrails e...

Entregas estratégicas para que realmente a IA, mesmo de forma inicial, ela já se pague para que vocês possam entender o quanto um processo como o Squared Cognitivo, com um contexto estruturado, trabalhando de ponta a ponta, podem mudar realmente os ponteiros da organização.

Maravilha, muito bom. Bom, é esse tipo de papo que a gente tem aqui no VibraCast. Realmente conversas profundas que você possa levar aprendizado para aplicar hoje na tua organização e de quem está fazendo o ponteiro e a coisa acontecer no dia a dia do mercado. Acompanhe a gente aí nas redes sociais, no YouTube, VibraCast, no Spotify. Também acesse o nosso site vibra.com.br para entender um pouco do trabalho que a gente está fazendo nesse cenário de squads cognitivos. Eu espero você aqui no próximo episódio. Até mais.