#245 - Futuro da Engenharia de Software com IA com Rodrigo Moreira

Hoje eu vou conversar com o Rodrigo Moreira, ele é VP de Engenharia na Vitex. Tudo bem, Rodrigo? Obrigado por aceitar o convite. Tudo bom, Edu. Eu que agradeço. Obrigadão, hein? Imagina. E antes da gente começar aqui, né, conversar sobre inteligência artificial futuro, né, da engenharia de software, enfim, vamos ver se a gente faz algumas previsões aqui, talvez daqui a uns 2, 3, 5 anos a gente olha pra trás e vê que a gente acertou, né?

Antes da gente chegar lá, eu queria pedir pra você contar um pouquinho sobre você, pra galera te conhecer um pouquinho melhor.

Beleza. Bom, rapidamente, eu tenho em torno de 25 anos na profissão de engenharia, e nesses 25 anos, geralmente eu divido em duas grandes partes. Uma parte que eu fui desenvolvedor de software, então atuando, desenvolvendo mesmo, então isso durou em torno de uns 10, 11 anos.

Aí depois eu migrei para a área de gestão e estou na área de gestão já faz uns 16 anos. Então aí eu parei um pouco de desenvolver no dia a dia, eu ainda faço um pouco de código e tal, mas parei no dia a dia e me dediquei à área de gestão.

Na maior parte das vezes trabalhei, sempre trabalhei em empresa de tecnologia, na área de engenharia. Por uns 3, 4 anos eu fui atuar numa área mais operacional, na área de negócio, para conseguir ter algumas outras habilidades que dentro da engenharia eu não ia conseguir ter. Mas depois eu não resisti e voltei para a engenharia. Então, sou formado em engenharia elétrica.

e tenho pós-graduação em engenharia de software, mestrado em engenharia da computação, passei um pouquinho a vida acadêmica também, dei um pouquinho de aula em universidade, em ciência da computação, em pós-graduação de gestão de projetos, gestão estratégica, e acho que é mais ou menos isso, de uma maneira muito rápida.

Boa, legal. E tem atuado agora como executivo de tecnologia. Tem quanto tempo, mais ou menos, trabalhando nessa posição? Tá. Como VP, faz uns seis meses eu fui recentemente promovido a VP. Antes eu estava como diretor sênior de engenharia. E aí, em direção de empresa de tecnologia, já faz aí uns...

Uns sete anos, mais ou menos. Ah, legal. Já é um tempo bem interessante. Bom, vamos lá para o nosso papo, porque imagino que a galera que está acompanhando a gente aqui está bem interessada no assunto. É um assunto que fala pouco, a gente está falando pouco desse assunto.

Pois é, acho que está todo mundo fazendo previsões aí e tal, e é interessante, acho que é super interessante, né, ouvir de alguém experiente no mercado, que provavelmente já passou por muitas mudanças ao longo desse tempo, como é que você enxerga também essa grande mudança que tem acontecido ultimamente. E a primeira pergunta que eu queria te fazer é muito, ela está muito voltada para alguns, de um lado, né, alguns estudos que eu tenho visto, eu não lembro exatamente das fontes, eu não lembro se é...

se é do DX, enfim, eu não lembro muito bem, mas eu sei que eu vi alguns estudos apontando para empresas onde tiveram uma melhoria, eu vou dizer, entre aspas, marginal do lente de produtividade dos engenheiros, alguma coisa em torno de 10%, mais ou menos nessa faixa. Por um lado, a gente vê relatos assim, por outro, a gente vê pessoas que dizem que são capazes de entregar produtos que levariam meses.

em algumas semanas, em alguns dias, talvez. Então, eu queria entender um pouquinho da tua visão, olhando para o que você já viu até agora, seja na própria Vitex, onde você está, ou em outras empresas, enfim, relatos de outras pessoas. Como você imagina que o desenvolvimento do software, de fato, vai se tornar daqui a um tempo médio, longo prazo? Se ele vai realmente ser substancialmente mais eficiente do que é hoje? Então, talvez algumas ordens de grandeza acima?

Ou se a mudança, talvez, não vai ser tão grande assim? A mudança vai para um lado diferente? Enfim, tem que entender um pouquinho como é que você enxerga esse ponto.

Boa. Olha, a resposta direta é que sim, eu acho que vai melhorar substancialmente a produtividade. Talvez algumas empresas ainda não estejam, podem não estar medindo, talvez da forma mais adequada. Então eu não acho que o ganho está só na hora de gerar o código. Então esse ganho...

o cerne do trabalho não está mais só em gerar código. Eu acho que o ganho real vai ser quando a gente conseguir acelerar o ciclo como um todo. Então, desde a identificação do problema, articulação desse problema, como que a gente faz a especificação, como a gente faz o desenvolvimento do código, como a gente valida, como que a gente põe esse código em produção. E eu acredito que em todas essas etapas, a...

as AI, a Generative AI, os AI Assistants, conseguem nos ajudar bastante. E eu já tenho visto, eu também tenho estudado bastante, a gente tem feito muita coisa dentro da BTEC, e a gente vem percebendo ganhos reais de produtividade, só que depende muito do que você está desenvolvendo também. Então, por exemplo, se você está corrigindo um bug,

você tem um ganho de produtividade tal. Se você está construindo uma feature mais complexa, talvez o ganho de produtividade seja um pouco menor. Se você está trabalhando em alguma iniciativa onde ela tem um padrão, então algum trabalho de migração de A para B, onde você tem um padrão muito bem...

definido como que você faz essa migração, a gente tem ganhos de produtividade de 70%, 80%. Então, eu acredito que depende muito do que você está construindo, da complexidade que você está construindo. Então, esse ganho de produtividade, ele não é fixo. Então, ele é variável dependendo do que você está desenvolvendo.

com certeza vai deixar muito mais eficiente o nosso trabalho, sim. Isso é o que eu venho observando. Quando você falou ali sobre a gente usar IA no processo como um todo, então desde a descoberta até a entrega, talvez até manutenção em produção, manutenção dos sistemas em produção, de fato, a parte de SRE e tal, eu fiquei pensando aqui comigo, beleza, o que que...

tese a IA não seria capaz de fazer nesse meio do caminho, né? Porque em tese, se ela consegue coletar insumos dos usuários, enfim, e ela pensa em como ela pode desenvolver aquilo, levanta alternativas e tal, até eventualmente implementar o código e ver como ele... Deployar e ver como funciona a produção, onde que exatamente o ser humano entraria nesse loop, entendeu? Eu queria entender um pouquinho a tua visão, né? Como que você imagina que os seres humanos aí... Vou até tirar o desenvolvedor...

Aqui, pensando mais no time como um todo, onde que o time entra, de fato, nesse ciclo, nesse novo ciclo, para que ele consiga, vamos dizer assim, fazer um bom trabalho, dado que boa parte a IA já consegue fazer. Boa. Olha, o que eu vou responder é muito baseado na informação que a gente tem hoje. Por que eu falo isso? Sempre quando eu estou conversando sobre isso. Amanhã...

já está surgindo uma nova ferramenta, um modelo novo de LLM, que já faz mais coisas do que faz hoje. Então, é muito focado na informação que a gente tem hoje, a minha resposta. Porque daqui dois meses, tudo que eu falei aqui pode ter mudado completamente. A gente está vendo essa velocidade absurda como as coisas estão evoluindo. Isso é só para a galera brifada, quem estiver acompanhando a gente. Essa gravação está sendo feita no dia 23 de abril de 2026. Boa.

Então, baseado nas informações que a gente tem hoje, onde que eu vejo a pessoa, alguém do time, estar envolvido no processo como um todo? Eu acho que hoje, lá no upstream que a gente fala, então ali na hora de definir o problema que a gente vai estar desenvolvendo, vai estar solucionando. Então, hoje...

essa etapa ainda não está automatizada com AI. Então, ainda existe a pessoa tem que conversar com os clientes, tem que entender as dores, tem que entender dessas dores quais vão gerar mais impacto para o negócio. Então, todo esse entendimento e articulação desse entendimento, eu acho que é uma parte onde o humano ainda está muito envolvido. É lógico que, uma vez ele articulando esse problema,

E enquanto ele está fazendo isso, ele pode estar usando AI para ajudar ele a articular isso de uma melhor maneira, de uma maneira mais adequada. Então, ele pode pegar essas informações dos clientes, colocar numa ferramenta de AI, falar, olha, está aqui as informações que eu coletei, me dá aqui em sites que talvez eu não esteja vendo, tem algum blind spot aqui.

Tem algumas perguntas adicionais, algo a mais que eu tenho que conversar com os clientes. Então, assim, até nesse processo, você pode usar AI. Só que ainda assim, o grande input desta etapa, para mim, ainda é o ser humano. Então, do entendimento do problema, a articulação do problema, e a gente ver se aquilo ali é uma coisa que vai gerar impacto para o negócio. Então, essa é uma parte que eu ainda acho que não está resolvida com o GNI. Então, o ser humano ali está muito envolvido nessa parte.

A outra parte ainda é pegar esse entendimento e dar uma refinada nesse entendimento para aí depois você passar para a GNI, fazer o código. Então a gente sabe que hoje, com as informações de hoje, as LLMs de hoje, você tem que passar o contexto muito bem definido, um contexto enxuto, conciso, pragmático.

para que aí o resultado seja melhor. Então, você hoje, e a gente vem fazendo vários estudos e fazendo vários projetos, e a gente vem tendo os dados reais sobre isso, que se você tenta colocar um projeto que é muito complexo, muito grande, com muito contexto, e simplesmente achar que ele vai gerar o código para você...

A gente não está tendo um bom resultado com isso. Quando que a gente está tendo um bom resultado? Quando a gente pega esse problema, a gente divide esse problema em partes menores e a gente implementa essas partes menores e depois todas essas partes juntas geram o todo. Então, isso sim, a gente está vendo excelentes resultados com a LLM. Então, também tem a parte ali do ser humano conseguir pegar esse problema.

e dividir ele em problemas menores. E aí você executar esse problema menor um de cada vez.

Então essa é uma outra parte onde o ser humano ainda está muito envolvido. E aí depois, a outra parte é de validação. Então uma vez que o código é gerado, o ser humano ainda está no loop de verificar se aquele código é um código de boa qualidade. E tem várias maneiras de você checar que um código é de boa qualidade. Você pode usar AI ali também para fazer code review, uma primeira revisão de código.

Só que você tem que entrar ali para ver como está a questão de segurança. Você pode usar AI para gerar testes unitários, end-to-end, de integração e etc. Mas ainda é humano ali orquestrando tudo isso. Existem frentes para automatizar essa etapa de verificação de qualidade também. Só que ela não está ainda tão madura assim. Ou a gente ainda não confia tanto nessa etapa, a gente ainda precisa do ser humano estar ali. Até porque...

Depois, quando esse código vai para a produção, existe toda uma questão de manutenção. Pode ter bugs, podem ocorrer incidentes. E depois, quem que vai resolver esses incidentes? Quem vai, de fato, achar o bug e corrigir o bug? O ser humano que vai ali investigar, ver log, ver trace, ver o que está acontecendo para conseguir resolver o problema. A gente também tem iniciativas de...

dos agents, AI agents, também ajudando a gente a identificar causa raiz. Só que ainda também não está 100% resolvido. Então, ajuda a gente a dar insights de onde pode estar, mas ainda o ser humano que ainda precisa da manutenção. Isso falando de hoje. Eu acredito que mais para frente, várias dessas etapas, a gente vai conseguir resolver com AI também. É que hoje ainda não está resolvido. Então, de uma maneira...

resumida, eu vejo que o ser humano entra muito no upstream, ali na definição do problema, quebra do problema. Depois, AI faz boa parte desse trabalho de geração de código. Depois, o ser humano volta ali na parte de validação, verificação, para conhecer do que está sendo gerado, garantir a qualidade e aquilo vai para a produção.

Teve uma postagem recente do Uncle Bob, se eu não me engano. Tem muita coisa que eu discordo dele, mas sobre esse ponto que ele colocou recentemente, eu imagino que, eventualmente, a gente vai caminhar nessa direção. Ele basicamente fala o seguinte, eu vou resumir aqui. Eu vou botar também o link aqui da postagem dele, acho que viralizou um pouco também, eu vou botar o link aqui nas notas do podcast desse episódio.

E basicamente ele fala que ele já não está olhando mais para o que a IA está fazendo. Então, uma prática muito comum ainda dos engenheiros com o IA é de revisar todo o código que ela produz para garantir que ele está, enfim, está na direção correta, está seguindo as diretrizes corretas, por aí vai. Porque a gente tem que pensar que tudo que a IA produz é probabilístico, não é determinístico. Então, não é que necessariamente a gente dê uma direção que ela necessariamente vai seguir.

E basicamente o que ele fala, o que o Uncle Bob fala, é que ele já não está olhando mais, não está mais fazendo revisão. O que ele tenta garantir é que os testes, as verificações, estão corretas e que isso vai garantir que o resultado final, enfim, traga o resultado que ele está buscando, no final das contas. Até que ponto você imagina que a gente realmente vai caminhar nessa direção, a gente vai parar eventualmente de fazer revisão do código, a gente não vai ter mais condições...

ela produz tanto código tão rápido que talvez o tempo que o engenheiro vai gastar com isso já não vai valer mais tanto a pena. Então eu queria entender um pouquinho a tua visão se realmente a gente pode caminhar nessa direção ou talvez não, a gente ainda vai precisar de algum guardrail ali um pouco mais próximo. Eu concordo que nós vamos nessa direção, a gente está indo nessa direção, exatamente nessa direção. O que acontece é que a gente está indo de uma maneira cautelosa, porque a gente tem sistemas em produção, atendendo...

4 mil clientes espalhados em 43 países, e a gente não pode simplesmente fechar o olho para o que está sendo gerado e colocar aquilo em produção. Isso seria irresponsabilidade da nossa parte. Porém, nós estamos trabalhando em várias iniciativas vendo como que a gente pode cada vez mais...

garantir que o software é de qualidade sem a gente precisar ficar revisando linha a linha. Exatamente aí onde a gente quer chegar. Tanto é que a gente vem tentando dividir aqui, até inclusive...

a gente separa, por exemplo, features que são mais complexas e aí a gente tem alguns critérios para definir o que são features mais complexas. A gente segue um processo onde a gente tem o humano um pouco mais presente no loop. E a gente tem iniciativas que são mais simples.

Onde o processo que a gente está seguindo de geração de código e tudo, ele é um processo muito mais light, onde o humano entra muito menos no loop. E aí, fazendo esses experimentos, a gente vai vendo até onde as LLMs, os AI Assistants, conseguem evoluir o quanto que a gente está conseguindo.

gerar de teste, porque agora a gente pode fazer o verdadeiro TDD, o Test Driven Development. Então, a gente faz o TDD lá no início, escreve todos os testes antes de gerar qualquer código, aí depois você pede para o AI Assistant vir implementando, passando nos testes. Então, tem a etapa inicial, depois no final dá para você fazer teste unitário, teste de integração, end-to-end.

todo tipo de teste. Então, você vai criando os guardrails. Então, não é só teste que a gente usa eventualmente para garantir qualidade. E aí a gente vai...

Um passinho de cada vez. Então, conseguimos tirar o humano do loop para as iniciativas mais simples? Conseguimos. Beleza, vamos aumentar um pouquinho a complexidade. Está dando o mesmo resultado? Será que a gente tem que ajustar alguma coisa nesse processo? Algum guardrail? E a gente vai indo dessa forma até em algum momento.

a gente já está com o humano muito menos no loop de verificação e mais, realmente, mais na parte do problema, na definição do problema. Então, eu concordo com o Encomob, eu acho que essa é a direção mesmo que a gente está indo, até porque, se a gente não for nessa linha, a gente não vai escalar. Então, você mesmo comentou, aí vai gerar muito código, e se o humano for querer revisar linha a linha,

a gente vai ser o bottleneck, vai ser o gargalo. E aí a produtividade não vai vir, porque a produtividade precisa ser no fluxo como um todo. Se você tiver um gargalo, a sua produtividade é limitada pelo seu gargalo. Então a gente tem que trabalhar de forma a eliminar os gargalos. E é isso que a gente está fazendo. A gente está começando pela parte de geração de código, garantindo que a parte de geração de código está sendo gerada.

Aí depois, a gente já está fazendo isso agora, que é a parte de validação e verificação. Então, quanto mais a gente automatiza ali, e depois a gente vai para o upstream também. Como que a gente gera especificações mais rápido também. Aí com isso, eu acredito que a gente vai compreender o fluxo como um todo, e aí a gente vai ter a real, o real ganho de produtividade.

E, assim, durante muito tempo, engenheiros, né, ou pessoas que estavam começando na área, focaram na parte técnica ali, afinal de contas elas tinham que escrever, de fato, código, criar as tecnologias manualmente, né, boa parte delas manualmente. O uso de algumas ferramentas ali, mas via de regra manualmente. E com essa vinda da popularização de uso de LLMs e tal para produzir código...

provavelmente a gente vai ver aí muitas mudanças no que a gente espera dos engenheiros de fato. Você já comentou um pouco ali sobre supervisionar, enfim, dar as instruções corretas e tal. Então, eu queria entender um pouquinho melhor contigo como que engenheiros de fato, ou quais habilidades os engenheiros vão precisar desenvolver. Porque, assim, vai sobrar tempo agora para eles olharem para outras coisas, para usarem outras alavancas aí para conseguirem gerar um melhor resultado como profissional ali. Não digo nem como engenheiro, mas como profissional.

é que trabalha com tecnologia. Então, tem que entender um pouquinho quais habilidades são essas que você imagina que engenheiros agora vão ter que passar a desenvolver, caso contrário, eles não vão conseguir mais trabalhar na área. Boa. As habilidades até que eu vou falar aqui, são habilidades que eu já considerava importantes para o pessoal da engenharia. Porém, talvez elas não fossem super relevantes.

porque boa parte do tempo da pessoa ali da engenharia era dentro do código. E, de qualquer forma, agora que o código está sendo resolvido, essas outras habilidades que já eram importantes antigamente, só que agora elas vão se tornar muito relevantes, porque se você não tiver, você não vai conseguir.

porque o código já está resolvido. Então, se o código está resolvido, você vai ter que ter as outras habilidades, elas vão se tornar mais relevantes. Quais são elas, na minha visão? Bom, a primeira delas é curiosidade. Então, para mim, toda pessoa da engenharia, da área técnica, tem que ser uma pessoa curiosa, porque muita coisa surge, é tecnologia nova. Então, se você não tem curiosidade para aprender essas...

coisas novas, eu acho que já é complicado. Então a primeira delas é curiosidade. A segunda é o conhecimento sistêmico. Então é ver o todo, não ver só alguma coisa muito específica, é conseguir também ver o todo. É lógico que você também vai ter que descer no específico, mas você vai ter que conhecer o todo. E muito similar a esse do conhecimento sistêmico, o que eu falo é o conhecimento de domínio.

Então, a pessoa de desenvolvimento, a pessoa de engenharia, ela tem que conhecer o produto que ela está trabalhando. Então, isso não é mais uma particularidade da pessoa de design ou da pessoa de produto. É da pessoa de engenharia. A pessoa de engenharia tem que conhecer o domínio. Porque é através do conhecimento do domínio que ela vai conseguir gerar especificações melhores para a AI gerar o código. Então, tem que ter o conhecimento de domínio.

tem que ter adaptabilidade.

então a pessoa tem que conseguir se adaptar. Então a gente está mudando de paradigma, está mudando muito rápido. Então diferentemente, a gente já passou por várias mudanças de paradigma no mundo de desenvolvimento. Desde a época que tinha o hardware que você tinha que escrever em linguagem de máquina, assembly, depois C, C++, Java, linguagem procedural, orientação objeto, funcional. Então várias camadas de abstração, mudanças de paradigma ao longo dos anos. É...

só que nunca foi tão rápido. Então, hoje, a mudança de paradigma para a AI está sendo muito rápida. Então, as pessoas têm que conseguir se adaptar a essa velocidade. E acho que uma característica que hoje é muito essencial é a escrita. Porque como que você passa os comandos para uma LLM? Através de linguagem natural.

E a gente sabe que escrever não é uma coisa... Escrever de forma clara, precisa, concisa, pragmática, não é uma habilidade tão simples assim. Então, acho que as pessoas agora têm que saber realmente escrever. Porque se elas não conseguirem articular o que elas pensam, o que elas querem...

em palavras que sejam muito claras e concisas, a LLM não vai gerar o que você está esperando. Então, acho que escrever é uma habilidade essencial que as pessoas vão precisar ter agora. Eu acho que eu diria que são essas.

fundamento, eu acho que não dá para você fugir dos fundamentos, então quem está fazendo engenharia da computação, ciência da computação, tem que conhecer os fundamentos, tem que entender dos algoritmos, tem que entender como é que funcionam os sistemas, porque isso vai te dar base para entender AI, como AI funciona, como que ela gera e etc. Sem os fundamentos, eu acho que fica muito difícil. Então, se você olhar para tudo que eu falei, nada é novo.

são habilidades que já estavam aí, só que agora elas vão se tornar realmente imprescindíveis da pessoa desenvolver. Você falou sobre escrever, eu lembrei que no primeiro processo seletivo que eu participei para uma vaga de programador, eu fiz uma redação, que eles pediam na época, uma redação. Talvez a gente volte a fazer esse tipo de coisa.

Mas aí um ponto que você comentou que eu queria talvez até aprofundar um pouco mais é assim, dado que engenheiros vão precisar ter um contato mais forte ali com o produto que eles estão desenvolvendo e tal, um conhecimento maior sobre o produto, até que ponto você vê uma intersecção maior no futuro próximo de engenheiros e pessoas de produto? Como que a gente consegue diferenciar esses dois papéis ali no futuro próximo com o uso de IA? Esse é um bom ponto, tá?

eu acredito que agora a sobreposição vai aumentar. Uma vez que a pessoa da engenharia está saindo de fazer código, existe a tendência dela ir para o upstream. Quando eu falo upstream, eu quero dizer que está indo lá para a parte de especificação, entendimento do problema. Então, antes de a gente ter a revolução de AI, de ENAI,

a pessoa de engenharia estava muito focada na parte técnica, na parte de escrever código, validação de código. Então, ficava boa parte do tempo nessa etapa. Uma vez que essa etapa for resolvida, está sendo resolvida, existe a tendência natural da pessoa de engenharia ir para o upstream. E aí, ela indo para o upstream, ela está mais se aproximando da pessoa de produto ou da pessoa de design. Então,

esses papéis, eles vão ter que aprender a reaprender a trabalhar junto ali. Então, eu não sei ainda o que vai acontecer, mas o que eu sei é o pessoal da engenharia vai para o upstream. Isso é fato.

Então, talvez tenha uma intersecção muito maior entre esses papéis. E até em cima disso, eu queria entender um pouquinho como você enxerga o possível futuro no desenvolvimento de produtos. Porque pensando em, entre aspas, boas práticas atuais, ou até agora, pelo menos, a gente tinha ali times, geralmente com...

um product manager, isso pensando no time que tem algum front-end. Um product manager, um designer, quatro, cinco, seis engenheiros ali no time. É uma formação bem comum. Só que se a gente tem engenheiros que estão produzindo muito mais ou fazendo muito mais entregas, porque está muito mais fácil escrever código, será que até essa formação do time, essa estrutura, ela tende a mudar também? Como é que você enxerga aí essa possibilidade?

Eu acredito que sim. Eu acho que essa estrutura do time vai ser muito mais dinâmica, baseado no problema que você quer resolver. Então, eu acho que por um tempo essa estrutura tradicional vai continuar existindo, porque a gente ainda está aprendendo, a gente está se adaptando.

Mas em algum momento eu acho que isso vai mudar. E eu vou até tentar ir mais além do que eu estou imaginando aqui, que é o seguinte. A gente está fazendo alguns testes já, que a gente está chamando de squads agênticas.

O que é essa squad agêntica? Você tem agents, cada agent tem um perfil. Então você tem um agent que tem um perfil mais de produto, o agent que tem um perfil mais de design, um agent que tem um perfil mais de engineering manager, você tem agents com chapéu de front-end, agents com chapéu de back-end, você tem um agent de quality assurance, então você tem essa squad agêntica.

que esses agents se conversam, e aí você tem o ser humano ali em cima disso, passando qual é o desafio que essa squad agêntica tem que resolver. E aí eu acho que é uma ou duas pessoas ali em cima, passando a definição do problema, e essa squad agêntica vai se resolver e vai te entregar o software.

A gente está fazendo experimentos disso, já fizemos algumas provas de conceito, para coisa simples, está funcionando muito bem, pega um bug, alguma coisa pequena, a gente joga nessa squad agêntica e ela consegue gerar o PR. Então, uma vez isso, se a gente conseguir escalar isso, e a gente está fazendo vários experimentos aqui, é...

eu acho que essa estrutura de time vai mudar bastante. Então, eventualmente, você pode ter um time muito mais enxuto, composto por uma squad agêntica. Então, de vez da gente ter cinco, seis pessoas, você tem três pessoas e mais a squad agêntica para resolver um determinado tipo de problema. Para outros tipos de problema, talvez só a squad agêntica. Para outros tipos de problema, talvez mais pessoas humanas ali e menos a squad agêntica.

Então acho que vai depender muito do problema que a gente vai querer resolver. Mas definitivamente essa estrutura atual que a gente está acostumado, para mim ela vai...

vai sofrer bastante alteração daqui para frente. Talvez seja muito uma questão de, conforme, muito puxando o que você comentou sobre o gargalo, conforme as empresas forem identificando gargalos ali, naturalmente elas já vão gravitando, vamos mudar isso, vamos mudar aquilo, é bem capaz, eu também imagino muito isso, que as empresas vão acabar convergindo para um formato que o uso de A vai...

acabar mostrando que tem maior potencial ali, né, de gerar resultados. Então, essa formação tradicional aí deve mudar um bocado, eu que imagino que vai acontecer também. Mas nesse formato que você comentou, né, de squads agênticas, enfim, eu imagino que essas pessoas vão precisar ter um conhecimento um pouco mais abrangente do que elas têm hoje. Então, são profissionais diferentes do que a gente vê hoje no team. Então, talvez hoje a gente tenha uma especialização muito grande.

A gente vai ter pessoas ali, talvez, que consigam olhar mais para os lados, entender. Talvez uma pessoa que entende tanto a parte técnica, de arquitetura, enfim, consegue tomar decisões técnicas, mas também que entenda um pouco de negócio, tomar decisões.

consiga entender bem o feedback de cliente, de usuário, enfim, consiga talvez fazer eventualmente uma análise de mercado, alguma coisa nesse sentido, para que no final das contas ela consiga operar bem aquele time que está abaixo dela, para não ficar naquela dependência de não precisa de um especialista nisso ou naquilo. Então, um time pequenininho, chuta com pessoas com conhecimento um pouco mais abrangente, ou não necessariamente.

Eu acredito que sim, mas tem uma das coisas que a gente não conversou aqui ainda, mas que ela é fundamental para tudo isso funcionar também.

é você ter a parte de contexto, de knowledge, né? O knowledge management, ele tem que estar conectado a essas suas ferramentas de AI. Então, o que eu quero dizer com isso? Tentar pegar todo esse conhecimento que você comentou, em termos de conhecimento do negócio específico, conhecimento de arquitetura, padrões de arquitetura. Toda empresa, não sei se é toda empresa, mas algumas empresas que eu conheço.

elas têm lá o que a gente chama de golden paths. Então, assim, olha, a gente tem uma forma aqui de construir nossos serviços. Nós temos padrões para construir nosso serviço. A gente tem padrão para isso, padrão para aquilo. Esses padrões, eles têm que estar conectados nas ferramentas de AI. De forma que...

Você não precisa ter pessoas que conheçam tudo, então essas duas pessoas têm que conhecer tudo para essa squad agêntica funcionar bem. Não, essas pessoas precisam ter bastante conhecimento, claro, mas boa parte do conhecimento a gente quer ter algum lugar centralizado, muito organizado, e que isso seja exportado via skills, via MCP, a forma que for conectado a sua squad agêntica, de forma que ela consiga ter acesso a esse knowledge.

Então você não precisa fazer com que toda a sua equipe, vamos supor, você tem uma equipe de seis, sete pessoas, agora você vai trabalhar uma equipe mais enxuta, e essas pessoas que são da equipe mais enxuta ter todo o conhecimento das outras oito. Não, a gente vai tentar pegar esse knowledge e colocar ele numa base de conhecimento onde ela fique disponível para a G&A usar também. Então, e para mim, essa parte é uma parte fundamental para tudo isso funcionar.

que é esse knowledge do conhecimento de negócio da sua empresa, ele tem que ser acessível pela GNI, para ela conseguir usar aquilo no desenvolvimento. E aí o legal disso, que eu vejo que, indo para o lado técnico,

Antes de JNI, a gente sempre, o pessoal da engenharia sempre sofreu uma pressão por entrega. Tem que entregar mais, tem que entregar rápido, o cliente não consegue esperar, tem que já soltar uma versão. E com isso a gente sempre lançou software com débito técnico. É muito difícil um software ser lançado que não tenha débito técnico. Não existe isso. Por quê? Porque você não conseguia gerar todo o código.

desde o início, para atender aquela deadline. Então você gerava com débito técnico, na esperança que algum dia você fosse tratando esse débito técnico ao longo do tempo. O que eu acho legal agora, é que a gente tem a oportunidade de gerar código desde o primeiro dia que você vai fazer a entrega, sem débito técnico. Por quê? Porque a G&I vai gerar o código.

E aí se você conecta com os seus padrões, com o seu Golden Path, ela já nasce do zero, já nasce sem débito técnico. Então, poxa, eu vou lançar o software com menos do que 80% de cobertura de teste? Não, não precisa. Aí gera todos os testes. Ah, eu vou gerar...

o meu software aqui sem ter toda a parte de observabilidade resolvida. Só vou deixar a parte de observabilidade realmente necessária. Não precisa. GNI vai gerar, gera com toda a observabilidade que você quiser. Então, para mim, isso é um dos grandes ganhos que a gente vai ter agora, que é conseguir lançar software sem débito técnico. Acho que esse é um sonho de qualquer pessoa de desenvolvimento, porque boa parte do desenvolvimento é um dos grandes ganhos.

uma vez que você lança o produto, é manutenção. E ninguém gosta. Lógico, tem pessoas que gostam muito de fazer manutenção, mas tem muita gente que não gosta de fazer manutenção. Então, talvez a gente tenha a oportunidade agora de sempre estar trabalhando com coisa nova, com feature nova.

Tem até uma postagem que o Thiago Guizzi fez. O Thiago Guizzi já foi diretor no Nubank, trabalhou na Apple também como gerente. Ah, eu conheço, conheço, conheço. Gente finíssima. E eu ainda quero conversar com ele sobre isso, mas basicamente ele falou que a gente está caminhando na direção da gente ter times com backlog zero. Isso fora, obviamente, novas funcionalidades, mas times com backlog zero sem problemas e tal. Eu não sei se a gente chega nesse nível, mas eu acho que a gente tem a possibilidade...

Até especialmente em sistemas novos e tal, onde a gente já vai fazer tudo em tese, pelo menos da maneira mais adequada possível. Porque o custo de entregar código é o custo, enfim, dos tokens que a gente está consumindo ali na ponta. Então, vamos ver se a gente vai caminhar nessa direção. Mas, assim, outro ponto que eu queria entender de você...

é um negócio que pode ser que mude bastante. Eu queria entender também o que você tem visto, o que você imagina para o futuro de pessoas que estão em posição de liderança. Então seja um tech lead que está ali com o time, um engineering manager, um gerente ali do time. O que eventualmente muda para essas pessoas? Será que elas vão continuar sendo necessárias para o time? Ou não? O time já vai conseguir se virar por conta própria sem necessidade de ter um gerente ali ajudando no dia a dia?

Enfim, queria entender como você enxerga essas posições de liderança mais próximas da equipe.

eu enxergo assim pelo contrário sobre a equipe não depender, eu acho que agora o papel da liderança está se tornando muito relevante porque agora você não vai mais gerenciar só a entrega de ser humano você vai ter que otimizar agora a entrega de ser humano junto com agents então vai mudar bastante como fazer isso, então eu acho que o papel do líder Obrigado

ele acaba agora voltando a ser mais técnico. Apesar que isso acho que depende muito de empresa para empresa. Então, tem empresas onde a liderança de engenharia é uma liderança mais do ponto de vista de gestão de pessoas.

Tem empresa que a liderança é uma liderança mais técnica. Tem empresa que são as duas coisas. Então, por exemplo, aqui na VTECs a gente valoriza o gerente de pessoas e técnico. Então, dificilmente, acho que você não vai encontrar nenhum manager, engineer manager na VTECs que não é técnico.

Então todos são muito técnicos, tem que conhecer da plataforma, tem que entender muito bem o sistema que gerencia, e além disso tem que gerenciar as pessoas. Então é os dois papéis. E agora tem que gerenciar também o trabalho gerado por agents. Isso daí vai envolver, define muito bem os guardrails, vai ter que garantir muito bem as especificações que entram para serem geradas de forma automática.

tem que ajustar o processo para realmente medir o impacto, medir produtividade. Então, assim, como que a gente vai medir impacto? Como que a gente vai medir, de fato, produtividade? A gente vai ter que reinventar os nossos processos de desenvolvimento. A gente já está fazendo isso. A gente já está tendo que fazer isso. Vai ter que conhecer da parte de arquitetura. Então, assim,

Para os engineers managers, que já são técnicos, eu acho que a adaptação vai ser um pouco menor. Para aqueles engineers managers, que são muito focados em gestão de pessoas, e eles deixam essa parte mais para as pessoas, empresas que têm o papel de tech lead, a gente não tem esse papel aqui, esse papel é do engineer manager também. Então, eu acho que depende muito... É muito...

Das empresas, como que essas empresas, o papel do engineer manager nas empresas. Eu acho que aqui na VTECS, no caso específico da VTECS, essa adaptação vai ser um pouco menos dolorosa, porque o pessoal já é muito técnico. Mas de qualquer forma, vai mudar muita coisa. Como que a gente gerencia essa squad agêntica? Quem que vai definir os papéis desses agents? Porque assim, a squad agêntica, tudo bem, mas você tem que ir lá configurar esses agents.

Quem que vai fazer isso? Então eu acho que o papel da liderança vai ser muito relevante por muito tempo ainda. Então quem que vai ajudar os times a passar por essa transição? É o líder. Quem vai fazer com que os times adotem esses novos processos?

esse novo paradigma, eu acho que isso cai muito na liderança. Lógico que cada pessoa individualmente vai ter que passar essa barreira, mas o líder é uma das pessoas responsáveis para ajudar o time a superar isso. Então, eu acho que vai mudar o papel um pouco, vai se tornar um pouco mais técnico e...

E eu acho que vai ter gente que vai sofrer mais e tem gente que vai sofrer menos. Imaginando aqui que tem um líder que está acompanhando a gente aqui e que eventualmente não é tão técnico assim, até tem um background, mas enfim, não é tão técnico assim. Você acha que vale a pena esse líder talvez investir em se tornar um técnico melhor, em aprender mais sobre IA, mais sobre talvez arquitetura ali para eventualmente se dar melhor no mercado daqui a um, dois, três anos? Ou você acha que não necessariamente depende muito de empresa para empresa?

Olha, o que eu vou falar aqui é muita opinião pessoal, nesse caso. Eu acredito que sim. Vai ter que saber operar ferramentas de AI, operar agents. E eu acho muito difícil fazer isso sem ter conhecimento técnico.

principalmente hoje, lembrando sempre que a gente está usando informações que a gente sabe hoje. Então, a gente sabe hoje, não é apertar um botão e o negócio sai. Então, vai desde você baixar lá a ferramenta IDE, a IDE que você usa, conectar com o AI Assistant que você usa, fazer as configurações. Então, assim, entender o que é um repositório, o que é um GitHub.

É lógico que um engineer manager sabe o que é isso. Mas vai lá, fazer PR, revisar PR, configurar ferramenta, gerar código, seguir lá. O que a gente vem usando muito é o que a gente chama de Spec Driven Development. Agora, vai ter que executar o Spec Driven Development, vai ter que fazer provas de conceito. Porque as pessoas que não são de engenharia estão fazendo isso. Como que a pessoa que é da engenharia não vai fazer?

tem que fazer. Então, se essa pessoa está muito focada só na gestão de pessoas, eu acho que ela está com um risco, na minha visão. Então, ela tem que ser mais técnica, inclusive, por exemplo, eu hoje estou numa posição um pouco mais executiva, VP de engenharia, eu estou fazendo isso.

Eu tenho aqui minhas ideias, tenho duas, trabalho com duas, inclusive até para ficar vendo qual gera um resultado, qual que gera outro. Então tudo que os times aqui estão desenvolvendo, estão se propondo, eu estou junto lá, testando, vendo, estudando bastante, porque eu também preciso direcionar. E eu não consigo direcionar se eu mesmo não estou fazendo também.

porque eu falo que eu não gosto de ser papagaio de pirata, ficar repetindo o que eu fico ouvindo. Não, eu tenho muita responsabilidade no que eu estou fazendo, então eu quero executar para ter de fato a minha opinião baseada no que eu estou fazendo, e aí com isso eu consigo direcionar melhor a equipe. Então eu acredito que toda pessoa que está na liderança, seja ela engineer, manager nível 1, nível 1000,

vai ter que fazer. Inclusive, o nosso CEO está fazendo. E eu acho que não é a particularidade do nosso CEO. Deve ter vários CEOs, e tem porque eu venho ouvindo, instalando as ferramentas, fazendo, desenvolvendo e testando.

Eu acho que definitivamente sim, tem que ir atrás disso de alguma forma. E um ponto que você comentou ali no começo do nosso papo foi sobre esse aumento potencial, aumento substancial de eficiência para os engenheiros.

ou não engenheiros, mas para entregas de maneira geral, para desenvolvimento de produtos, entregas novas, funcionalidades e tal. Daí eu queria entender um pouquinho a tua visão sobre a demanda por engenheiros no mercado, porque assim, imagino que a gente possa eventualmente ir para duas direções assumindo que, de fato, a produtividade aumente.

bastante. Uma delas é as empresas vão querer menos engenheiros, porque elas vão conseguir produzir o mesmo com menos engenheiros, então talvez a demanda não seja mais tão grande. Ou, por outro lado, não, a demanda vai continuar sendo a mesma, talvez até maior, porque com mais engenheiros a gente consegue produzir ainda mais, fazer ainda mais entregas. Então, para qual lado você imagina que a gente pode estar caminhando aí nos próximos meses, talvez anos? Olha, essa é uma boa pergunta, essa é de difícil...

resposta, eu não tenho bola de cristal e eu acho super arriscado nos tempos de hoje a gente fazer qualquer tipo de previsão, mas tomando como e eu sei também que usar dados do passado para prever o futuro não dá certo também, mas vamos lá, a gente olhando um pouco outras mudanças de paradigma que a gente é...

a gente já passou, seja no desenvolvimento de software, seja mudança de paradigma em qualquer tipo de tecnologia, em qualquer área, eu vejo que a gente sempre está tendo demanda de novos profissionais. Porque o que acontece? E aí vou trazer para o mundo de software aqui, de GNI. Se a gente está diminuindo o custo, então vamos falar um pouco mais claro, então vamos falar um pouco mais claro, então vamos falar um pouco mais claro, então vamos falar um pouco mais claro, então vamos falar um pouco mais claro, então vamos falar um pouco mais claro, vamos falar um pouco mais claro, vamos falar um pouco mais claro, vamos falar um pouco mais claro,

de gerar software, imaginando que a gente está diminuindo o custo mesmo, então assim, beleza, a gente sabe que tem, a gente vai pagar os tokens e etc, etc, mas partindo do pressuposto, da premissa que o valor que a gente está gerando para o negócio é maior que o custo, isso já faz o negócio ser viável. Beleza, sendo viável,

e a gente está reduzindo o tempo de desenvolvimento, e com isso a gente vai ganhar produtividade, a gente vai ter vários outros problemas que a gente vai querer resolver com software. Então talvez tenham muitos problemas hoje que a gente ainda não está resolvendo com software, porque é caro fazer. E uma vez que a gente está fazendo com que esse desenvolvimento seja mais barato,

Eu acho que a gente vai querer resolver mais problemas com software. Se a gente vai querer resolver mais problemas com software, a gente vai precisar de ter mais, a gente vai demandar mais pessoas para resolver esses problemas. Mas por mais que uma parte da etapa, partes da etapa são feitas por AI, você ainda vai precisar das pessoas para definir os problemas ainda, colocar esse problema na esteira de AI para...

para ser desenvolvido, e depois esse código, de uma certa forma, também vai ter manutenção, de uma forma ou de outra, ainda vai ter um pouco de manutenção. Então, eu acredito que existe uma linha minha de pensamento onde vai acontecer isso, então a gente vai ter mais demandas, só que o profissional é um pouco diferente do que ele é hoje. Então, ele não vai ser a mesma pessoa de engenharia, é uma pessoa diferente da engenharia.

É uma pessoa daquela que a gente estava falando agora há pouco, que tem que saber articular o problema, tem que identificar o problema, tem que ver qual problema gera mais valor, tem que escrever bem. Então, tem que ter conhecimento de domínio. Então, é um profissional um pouco diferente. Mas acho que a demanda, seguindo nessa linha, ela vai aumentar. E seguindo numa linha onde o que eu acho que a gente vai diminuir um pouco de oportunidade? Para aquela pessoa engenheira mediana.

é aquela pessoa engenheira que só faz código. Essa parte realmente vai diminuir a demanda. Essa para mim eu não tenho dúvida. Então, se a pessoa de desenvolvimento só faz código e não faz outra etapa, essa eu acho que vai diminuir bastante a oportunidade. Agora, as pessoas engenheiras que são...

conhecem de arquitetura, sabem escrever muito bem, conhecem identificar problema, mastigar problema, refinar problema, sabem o que gera impacto, do que não gera impacto. Eu acho que esse profissional ainda vai ser muito valioso por muito tempo. Então eu diria que não acho que vai diminuir demanda por bom profissional, agora o profissional mediano ali, esse vai diminuir. Essa é a minha opinião.

Você comentou um negócio que talvez eu até coloco aqui como um princípio, que é as empresas vão continuar contratando desde que seja rentável para elas continuar contratando. Pensa, sei lá, vamos dizer uma consultoria. Ela vai contratar consultores enquanto aqueles consultores forem... Tô sendo...

Receita para a empresa, né? Obviamente, se ela tiver projetos ali e tal, então, quanto for rentável, ela vai contratando gente. A gente pode, talvez, olhar da mesma forma para engenheiros. Enquanto esses engenheiros estiverem dando retorno positivo para a empresa, ela vai contratando, vai chegar uma hora, que, obviamente, isso sempre acontece.

a segunda lei dos retornos decrescentes, que chega um momento que já não tem mais retorno nenhum. O retorno marginal é muito baixo, talvez não valha mais a pena. Então, vai parar aí. Agora, se isso vai acontecer com maior demanda, com menor demanda, talvez seja um pouco difícil de prever, talvez só o movimento do mercado vai dizer mesmo como que a coisa vai se dar.

Total, total. E vão surgir novos problemas para serem resolvidos. Então assim, antigamente não tinham essas empresas, ou tinham essas empresas de AI, que elas existem já há alguns anos, bons anos, só que agora vai ter muito mais profissional para continuar desenvolvendo essas ferramentas.

Eu acho que é difícil dizer que vai acabar o trabalho, etc. Eu estou na linha que eu não quero acreditar nisso, entendeu? Eu quero acreditar que vai ter muita demanda, vai ter muito problema para a gente resolver, e o que está mudando é a forma que a gente resolve esses problemas.

É o meio do que a gente resolve. Então é nisso que eu estou trabalhando e acreditando. Todo mundo quer se sentir mais produtivo, eu acho, na minha visão. Então todo profissional quer se sentir mais produtivo. E agora a gente está tendo uma tecnologia na nossa mão que faz a gente produzir por 30, vamos dizer assim. Então, poxa, quem está...

trabalhando com AI, e eu estou falando isso porque eu estou trabalhando, eu sei, eu estou conseguindo enxergar isso, e eu estou me sentindo muito mais produtivo do que antes. E para mim dá um sentimento de satisfação enorme. Poxa, eu chego e falo, hoje eu fiz tanta coisa que eu faria, varia uma semana e estou fazendo em um dia. Então assim, isso me dá uma satisfação de eu conseguir entregar mais coisas, coisas mais complexas.

E eu acho que todo profissional se sente mais satisfeito quando é mais produtivo. E um ponto aí que eu ainda tenho uma interrogação muito grande para mim, eu não consigo responder bem essa pergunta, eu queria entender muito a tua visão, que é sobre os engenheiros, os novos engenheiros, os engenheiros juniors, que estão chegando no mercado agora. Porque assim, durante muito tempo...

Como que engenheiros se desenvolviam, cresciam na carreira e tal. Então, eles codificavam bastante, lidavam com vários problemas diferentes e tal. Aí tinham que aprender um monte de arquitetura, sistemas distribuídos e tal. E iam se desenvolvendo e crescendo na carreira. Só que agora, boa parte, pelo menos da produção do código, da criação das soluções ali, ela está sendo, entre aspas, automática, obviamente, dado um contexto ali que engenheiro ainda precisa dar.

Nesse sentido, como que talvez engenheiros júnior, quem está chegando no mercado agora, como é que essas pessoas vão de fato se encaixar, elas vão ter dificuldades, você consegue enxergar a dificuldade? Porque tem mudado bastante o jeito como engenheiros têm feito o trabalho. Então, o que a gente pode esperar?

para essas pessoas que estão em posição inicial, eventualmente até para empresas. Vamos imaginar que a gente tem alguém aqui de uma empresa que quer contratar júnior. Beleza, o que essas empresas podem cobrar dessas pessoas no início para que, de fato, elas aprendam, sejam produtivas, minimamente produtivas e estejam ali se desenvolvendo na carreira?

Boa. Eu acho que a resposta vai muito ao encontro do que a gente estava falando sobre as características de uma pessoa da engenharia precisa ter, porque eu acho que essas características não mudam muito na senioridade. A pessoa júnior vai precisar continuar tendo uma boa base de computação.

Então, não vejo como essa pessoa júnior não vai ter a boa base de computação. E essa boa base de computação, uma das maneiras tradicionais de você ter essa base é você ir fazendo uma universidade de ciência da computação, engenharia da computação, engenharia elétrica, ou seja, a engenharia que for ali, que tenha especialização em desenvolvimento de software. Então, precisa ter a base de computação. Para mim é...

Não tem como não ter isso. Ela tem que ser curiosa, tem que ter adaptabilidade, ela tem que ter capacidade de pegar um problema e decompor esse problema. Ela tem que saber escrever bem. Ela vai ter que usar AI com olho crítico. E não só AI, eu acho que as pessoas de engenharia têm que ter um olhar muito crítico sobre tudo. Então, ela tem que...

ela tinha esse olhar crítico de código gerado por ser humano, ela tem que ter olhar crítico de código gerado por AI. Então, ela tem que estar questionando a AI. Então, tem que ter esse olhar crítico. Ela tem que saber verificar resultado, validar resultado, se aquilo que está saindo era o esperado, se não era o esperado. Aí, uma característica que eu acho que talvez agora é o que esteja mudando.

É a velocidade de aprender. Porque antes, a pessoa júnior, quando ela entrava, ela tinha mais tempo para aprender tudo isso.

Então, por quê? Você vai entrar num projeto, aí vai ter uma etapa de discovery do projeto, você vai ter que aprender lá quais as tecnologias que você vai usar, tinha a fase de especificação de requisitos, validação dos requisitos, depois refinamento dos requisitos, aí você ia fazer um high-level design, low-level design, aí depois que você ia começar a implementar, isso levava alguns meses.

E aí com isso a pessoa júnior, ela tinha esse tempo para ir aprendendo. Aí para mim o grande problema é que agora você não tem mais esse tempo. Então esse tempo ele está fazendo assim. E aí que eu acho que a grande problemática. E aí que eu acho que entra a velocidade de aprender. Velocidade de aprender, capacidade de reter esse aprendizado.

Só que ela também pode se alavancar de AI para isso. Então antigamente, por exemplo, na minha época, quando eu era desenvolvedor lá em 2000, 1998, 94, 95, naquela época eu tinha livro, então eu tinha aqui atrás de livro, eu tenho até meus livros, está tudo aqui, os livros de algoritmo, livro de C, de C++.

e aí você não encontrava, aí você tinha que ir em fóruns, nem tinha stack overflow naquela época, depois que começou a surgir. Então eu lembro que na época o Linux nem rodava em laptop, para rodar em laptop você tinha que baixar o código, compilar o driver para o seu laptop, aí a placa de vídeo não funcionava direito. Então assim, a dificuldade era gigantesca para você conseguir o conhecimento.

Agora você tem as EAs. Então tudo que você quer saber, você pergunta para a EA e ela vai te responder. E aí você pode ir questionando e criar seus planos de estudo. Então assim, também é mais rápido para você obter informação. Então as ferramentas também te ajudam, apesar dessa velocidade que você está perdendo, você não tem mais o tempo necessário que tinha antes para aprender, mas agora você também tem ferramenta para acelerar seu aprendizado.

Mas eu acho que essa é uma parte ainda que... Vamos ver como que as pessoas júniores vão se comportar aí. Mas eu acho que essa era uma característica de ser observada. Se a pessoa tem capacidade de aprender rápido. Porque é um requisito agora. Você não tem mais meses para aprender. Eu acho que é isso. Então, ainda é uma...

É uma resposta não definitiva, são pensamentos, é um pensamento inacabado ainda que eu tenho sobre esse ponto, mas eu diria que é isso, é adaptabilidade, curiosidade, olhar com olhar crítico e capacidade de aprender rápido. Eu acho que isso é o que vai ajudar as pessoas júnior a... Ah, e conhecimento base de computação.

Eu acho que isso vai ajudar as pessoas júnior a tentar passar esse desafio aí.

Eu acho que esse episódio que a gente está gravando é desafiador no sentido de que boa parte é previsão. A gente já consegue falar um pouco sobre o que tem acontecido agora, mas boa parte é previsão do que vem acontecer. Vamos ver se a gente acerta alguma coisa, se a gente acerta a maioria, a minoria, enfim. A gente volta aqui pra ver depois o que aconteceu. E pra gente finalizar o episódio, eu queria pedir pra você passar uma mensagem final aí pra quem estiver acompanhando a gente.

O que esperar aí dos próximos passos? O que você recomenda? Talvez algum conselho que você dá pra quem está acompanhando a gente aqui?

Boa. É, conselho é complicado, né? Bom, o que que eu diria? Eu acho que assim, eu acho que as pessoas elas têm que engajar no que está acontecendo. Engaja, vai pra cima, vai estudar ali, vai entender. Eu acho que tem...

lógico, você tem que ter um certo ceticismo, mas um ceticismo que é sadio, não é o ceticismo que você vai rejeitar de forma superficial. Não é isso, é um cético que... Meu, deixa eu experimentar, deixa eu ver onde está funcionando, onde não está funcionando, aí onde não está funcionando, o que eu posso fazer para funcionar? Ou seja, esse olhar crítico. Mas...

E vai tentar...

Usar um pouco da ferramenta para você construir a sua opinião. Então, de vez a gente ficar pegando... Eu acho super válido a gente estudar, pegar a opinião das outras pessoas, das outras pessoas que estão estudando, mas você tem que usar essas informações, você mesmo tem que testar para você criar a sua opinião. Então, acho que essa é uma coisa que eu acho muito importante. Então, além de você estudar, pegar todos os inputs, vai você mesmo testar.

as ferramentas, para você construir a sua opinião. Eu acho que isso é extremamente relevante fazer. É o que eu tenho feito, então eu não estou sugerindo algo que eu não estou fazendo, eu estou sugerindo exatamente o que eu estou fazendo. Eu vejo, eu estou ouvindo podcast todo dia, estou lendo artigo todo dia, estou conversando com várias pessoas todo dia e eu estou testando as ferramentas eu mesmo todo dia, para eu conseguir dar a minha opinião. E E aí

Eu sei que tem muito potencial. A minha opinião é que tem muito potencial essas ferramentas. Então, eu acho que as pessoas têm que engajar e testar. E aí depois a gente vê o que acontece. Mas primeiro tem que engajar. Se você não engajar, não dá para ver o que vai acontecer depois. Então, eu diria isso. Engajem, pessoal. Engajem, porque tem potencial. E aí depois a gente vê no que vai dar.

talvez nesse momento pareça até bonitinho falar mal, falar que é hype e tal, eu não sei se eu recomendo esse caminho não, de você só, enfim, se deslocar e continuar fazendo tudo do mesmo jeito que você fazia antes, talvez seja um pouco perigoso. Eu acho que isso é perigoso em qualquer fase da sua vida, em qualquer fase, qualquer carreira, qualquer... Você sempre tem que estar tentando fazer melhor ali o que você faz, de forma mais otimizada, mais eficiente, gerando mais valor.

Eu acho que tem que ter sempre esse modelo mental. Bom, e para quem quiser conversar contigo, Rodrigo, continuar a conversa aí, por onde que a pessoa pode conversar contigo? E também se você tiver alguma mensagem, algum jabá que você queira fazer, pode ficar à vontade.

Não, não quero fazer nenhum jabá, não. Pessoal que querem conversar comigo, tem o LinkedIn, tá? Então depois, Edu, se você quiser passar lá o LinkedIn, quando você for fazer a publicação, fica à vontade. E aí, através do LinkedIn, o pessoal me chama ali, a gente pode bater papo, aí eu passo o WhatsApp, a gente conversa. Eu estou muito interessado. Eu já fiz algumas publicações no LinkedIn, falando quem quisesse conversar sobre o tema para conversar, porque eu quero...

Eu quero tentar tirar um pouco de ruído, porque como é uma coisa que está na hype mesmo, muita gente falando e etc., tem muito ruído. E como que eu acho que é legal tirar o ruído? É quando você está falando com as pessoas que de fato estão fazendo. Não é só publicação. Não, deixa eu conversar com quem está fazendo. Me conta o desafio ali. Qual é a pedra que você está quebrando por dia?

porque eu sei que na hora que a gente sai desse mundo mais visionário e a gente vai pra execução onde as coisas acontecem de verdade, não é tão lindo assim, tem vários detalhes, vários e eu tô querendo conversar com as pessoas que estão implementando pra

conhecer todos esses detalhes, porque dentro aqui da VTEC eu tenho acesso a vários detalhes do nosso segmento, o que a gente está fazendo, mas eu quero conversar com pessoas de outros segmentos que estão com outros desafios, até para ver como que eu posso pegar esses aprendizados e trazer para cá também, para construir aqui um...

um processo de desenvolvimento de software mais eficiente, que gere mais impacto. Então, eu estou super afim de fazer essas conversas e podem me procurar. Com certeza, eu vou reservar um tempo para aprender um pouquinho e compartilhar também um pouco do que eu estou fazendo.

O link para o teu LinkedIn, Rodrigo, vai estar aqui nas notas do podcast, na descrição do vídeo. Bom, Rodrigo, muito obrigado por você ter, de novo, você ter aceitado a participar. Foi um prazer conversar contigo, cara. Um abraço e até a próxima. Obrigado, Edu. Um abração para você também. Foi um prazer.