XP 2026 no Brasil: um relato sobre uma das mais importantes conferências de métodos ágeis, Graziela Simone Tonin (Insper)

A gente vai precisar trazer à tona discussões como ética e como habilidades básicas, skill básicas, que é pensamento crítico. Complementando, criar modelos de IA bons para me substituir, digamos assim, custa. Primeiro assim, primeiro tem que ser alguém que saiba criar, né, que tenha conhecimento, que não é trivial.

Então, pessoal, boa tarde, boa noite. Estamos aqui gravando durante uma aula daqui do Programa de Pós-Graduação em Computação Aplicada da UTFPR Curitiba. Estamos com a professora doutora Graziella Simone Tonin, professora do INSPEER, organizadora, né, com toda uma comissão, claro, mas eu acho que era a pessoa que mais aparecia na organização do XP 2026, que é um dos principais maiores eventos de métodos ágeis no mundo, que aconteceu em São Paulo.

É como eu, curiosidade, né, doutor em computação pela USP São Paulo, lá no Instituto de Matemática e Estatística. Isso, doutorado bem depois que eu, mas no mesmo local. E curiosamente também lá no Instituto de Matemática e Estatística esse ano vai acontecer o CBSoft, né, que é o Congresso Brasileiro de Software. Aí eu tava vendo o LinkedIn Mestrado em Ciência da Computação pela Universidade Federal de Pernambuco, é também onde eu fiz o meu mestrado.

E aí a outra curiosidade é, fez graduação em Ciência da Computação na Universidade Regional Integrada do Alto Uruguai e das Missões, a URI. Não fiz minha graduação lá, mas o meu colega de sala, coordenador aqui do PPGCA, professor Daniel Pigato, disse assim, eu acho que eu postei alguma coisa, acho que eu postei a divulgação do XP 2026 vocês. Aí ele escreveu assim, ó: Graziella foi minha veterana em Erasim, fez TCC com o mesmo orientador que eu.

Então muitas boas coincidências, né? Trabalha com ciência, tecnologia, inovação, educação, empreendedorismo, faz parte do grupo Mulheres no Brasil, uma série de coisas. Eu tava até falando para os alunos antes, pois só falar aqui da sua carreira daria para passar várias horas, né?

Obrigada, professor Adolfo, pelo convite. Uma honra tá aqui com vocês, né? Uma correria aí final de semestre. Acho todo professor tá equilibrando os pratos aí, né, entre entregar também. A gente ainda tá fechando a XP, né? Tem toda a parte financeira, toda a parte de organização. Mas muito bom tá aqui com vocês hoje. Então a ideia é trazer alguns insights. É importante dizer que esses insights são a minha visão, né? Pode ser que até o próprio autor discorde de alguns insights que eu traga aqui, mas obviamente que tem o meu viés e trazer algumas reflexões.

Pois é, eu abro aqui para a gente discutir também, porque acho que a XP teve algumas coisas, embora obviamente, como a gente colocou, ela aconteceu aqui no Insper, então como chair local e general co-chair, obviamente que eu não consegui acompanhar todas as discussões e dificilmente conseguia ficar nas discussões todo tempo, né? Mas a ideia é trazer alguns dos principais insights. É importante destacar que a gente já tá com os proceedings na Springer, e a gente preza por ser público, né?

Então a gente investe um valor maior com a Springer para que todo mundo possa acessar. Então você pode baixar ele, que ele é gratuito. Lá tem alguns dos principais insights da parte científica, né, principalmente, obviamente, a parte do mercado A gente não tem tanta, tanta documentação, enfim, não tá documentado, só alguns highlights lá. Eu vou dar um share aqui nos meus slides, deixa só, deixa eu ver se tá funcionando aqui, tá.

Então, só o professor já falou, o tema desse ano, acho que quando a gente parou para pensar no que que a gente queria abordar, né, o ágil ele tem sido muito questionado. Né? Então a gente viu estudos e discussões acaloradas de que o ágil tem que criar um novo método. Então tem gente que acha que a gente tem que criar um novo método, ágil já cumpriu seu papel, foi obsoleto. Tem gente que diz que nunca funcionou, tem gente que fala que não, que a gente só precisa se adaptar.

E isso alinhado ao poder dessa era, né, nova era, que era de que talvez a gente na prática não consiga prever muito o futuro, né? A gente tem muita previsão assim, mas eu brinco que é premonição, porque ninguém viveu uma era como na época do computador. A gente falava, né, que todo mundo ia ter seu desktop e acabou que todo mundo passou a ter seu smartphone. A gente não conseguiu de fato prever isso e outras mudanças nas grandes eras aí da humanidade.

Eu acho que a gente tá muito longe de conseguir prever o que vai acontecer, porque na minha opinião a gente não sabe muito como moldar os modelos de negócio para essa era, porque a gente não tem tanta capacidade estimativa, pelo menos não agora, e não da forma que muita gente vem fazendo. Mas quando a gente discutiu que tema a gente traria para o Brasil, acho que a gente tinha alguma certeza. Então a gente queria trazer algumas discussões sobre impacto, né?

E a gente queria sair um pouco dessa discussão de funciona, não funciona, tem que criar um novo método, não. Para além disso, expandir os novos horizontes e entender como que a gente, usando todo o poder que a gente tem de conhecimento nas áreas de computação, seja usando IA como ferramenta, seja usando computação ou tecnologia como ferramenta, ou de fato um conhecimento que a gente aplica, que é poderoso, né, um conhecimento poderoso que a gente pudesse discutir em como aplicá-lo para desenvolver ou criar um futuro, moldar aí um futuro mais sustentável, mais inclusivo.

Dito isso, a XP, né, aqui não tá todo mundo do Steering Committee, até faço parte agora, mas XP ela tá sempre, a curadoria dela é do Comitê Mundial. Essas são algumas das pessoas que estavam no Brasil além de mim, que faço parte agora. Professor Eduardo Guerra também entrou, e a gente faz parte nos próximos 3 anos, e ela tá sempre é sob essa curadoria. Então a gente tem regras, etc. e tal. E agradecer mais uma vez os nossos hosts parceiros, né, e os sponsors que são essenciais aí para trazer essa conferência.

Como o professor falou, é a primeira vez que ela vem para o Brasil, pela vez que ela vem para o Sul Global. Então, em 26 anos, a gente fez todo um esforço aí durante 2 anos para conseguir de fato trazer ela para o Brasil. E aí conseguiu reunir uma galera muito legal, a maioria das pessoas estão aqui nessa foto, de mais de 22 países. E eu não podia deixar de agradecer imensamente ao time de voluntários, né? Acho que um grande ganho da comunidade ágil é que pessoas incríveis se propõem a voluntariar, que têm muita experiência, que estão no mercado há muitos anos, de muitos lugares do mundo, E esse espírito de comunidade do ágil, eu acho que é algo fundamental para sustentar e levar os modelos de negócio do futuro.

Nosso time de voluntários foi sensacional. E aí, alguns dos países, então tivemos pessoas de mais de 20 países discutindo. Aí tentei fazer uma nuvem de palavra aí para trazer um pouco os temas que a gente mais abordou na conferência. Então, obviamente que o ágil, ele Ele prevalece, mas obviamente que, incluindo LLM, né, eu acho que essa discussão ela pairou em todas as sessões sobre algumas perspectivas. O pessoal tá falando, discutindo o impacto disso, os riscos disso, como usar isso de uma forma melhor em diferentes níveis, não só em termos ágeis, mas um pouco entrando também engenharia de software, em design, em experiência de usuário.

Mas destacando muito essa, como a gente drive essa colaboração, né, humano. E teve grandes discussões também sobre o trabalho híbrido. A gente vê, viu ou tem visto grandes movimentos de empresas que eram totalmente híbridas, agora são, eram totalmente remotas, agora passaram para o híbrido ou 100% presencial, né. No Brasil a gente teve vários casos recentes assim dessa mudança de grandes instituições aí, né, que tem times, muitos times, muitas pessoas nos times de TI.

Mas também a gente discutiu a parte de sustentabilidade, a parte de experimentação, como é que a gente usa isso também na pesquisa, a parte de UX, como já falei, user stories, aí discutiu retrospectiva, discutiu alguns desses artefatos. E obviamente uma área que é muito a minha área, a parte de gestão de dívida técnica, como a gente vai lidar com isso, aí quais são os trade-offs disso. Eu vou tentar discorrer um pouco sobre esses tópicos.

Então, se eu pudesse, na minha visão, resumir em 4 grandes tópicos a conferência, eu depois de algumas interações eu entenderia que eu acho que essa colaboração com inteligência artificial, a gente precisa entender, a gente precisa aprender a criar guardrails, a gente precisa, é inevitável a gente usar, acho que todo mundo já tá usando, os estudos mostram isso, mas tenho certeza que vocês no dia a dia de vocês já veem isso, acho que isso é inevitável, assim, eu não conheço ninguém que não usa alguma IA generativa.

No dia a dia do seu trabalho, seja uma pessoa extremamente técnica ou não da nossa área e de outras áreas. Então ela é uma ferramenta que faz parte da cocriação, e até se a gente analisar alguns estudos recentes, ela é o próprio piloto da história, né? Então quando a gente delega para o IA fazer a tarefa. E aí a parte de engenharia de software, né, a parte de experimentação, de teste, de evoluir, de arquitetura, né? É como a gente olha para isso, e talvez essa área assuma um novo protagonismo no processo de desenvolvimento de software.

Vou discutir um pouquinho sobre isso. É como a gente escala. A gente tem vários frameworks, a gente também tem frameworks ágeis como SAFe, várias discussões que ele é muito burocrático, que ele até, ele é bem robusto, mas assim né, na prática ninguém entende direito como implementar ele ou consegue de fato implementá-lo, porque aí gera muita burocracia, enfim. E aí acaba pegando atalhos. E obviamente é como que os estudos mostram aí se o trabalho híbrido faz sentido, não faz sentido, versus a versão do mercado.

E o outro é um pouco que acho que a gente é uma discussão constante pelo menos desde que eu me conheço, estudo a área de ágil, é que a cultura, no final do dia, cultura e mindset são utilizadas muito, palavras muito utilizadas nessa trajetória, mas que mais do que nunca talvez fique evidente o valor dessas áreas, né? E a importância dessas áreas para a gente gerar inovação, como entregar valor de fato para o cliente, como um dos nossos princípios sugere.

Então, até o Carole, o keynote do Carole, ele traz muito isso, mas isso foi muito discutido em outras salas, né, em outras sessões, que em tese eu sei que aqui também a gente tem que considerar, né, se é uma das discussões que o júnior, do sênior, mas vamos considerar que uma pessoa que que eu saiba usar sem olhar muito para o impacto agora disso, né? Mas a gente ganha velocidade. Eu acho que isso meio que é um consenso, assim, a gente ganha velocidade quando a gente usa IA para codificação.

E os modelos têm ficado cada vez melhor, né? Assim, a evolução dos modelos para codificação, ela é mensurável, ela é visível, e é E ela cada vez é mais eficiente, é melhor, não tem como não dizer isso. Então a gente tem excelentes modelos que codam para gente, obviamente que tem várias premissas aí, desde que a gente use eles de forma correta, desde que a gente valida essa decisão para não injetar problemas no software. Enfim, tem vários pontos que a gente tem que discutir aí, mas a gente ganha velocidade.

E isso faz com que talvez outras áreas, como Product Discovery, né, que o cara olha aí, especialista em Inception e N livros nessas áreas, ele fala, olha, talvez é uma coisa que a gente que ganha mais peso é, bom, eu ganho velocidade, mas eu preciso investir um tempo para entender se a direção, né, se no Product Discovery, se a direção é certa. Então Eu posso de fato ter um ganho aí, acelerar minha produção, mas eu posso simplesmente tá construindo um monte de produto MVP ou colocando teste em produção errada de forma rápida, né?

Então, se eu tô enchendo de vida técnica, eu tô imputando um monte de vulnerabilidades, né, sem nenhuma proteção, e eu só tô piorando, por exemplo, a qualidade do software ou mesmo a qualidade do produto com maior rapidez. Então a gente deveria, ao invés de focar em métricas de velocidade, né, a gente olhar mais e investir mais tempo nessa parte de discovery e validação de produto. E aí sim, com talvez as nossas histórias mais claras, os que devem ser prioridades mais claras, A gente entrega super rápido.

A gente, obviamente, a parte de discovery— tem um outro ponto aqui também que é importante, que a parte de discovery ela ganha uma capacidade de teste absurda, né? Então eu consigo validar hipótese, ideias de forma muito mais rápida, criando protótipos levemente funcionais, até funcionais, mas criando protótipos para validação, seja protótipo de baixa ou alta fidelidade. De forma super rápida e consigo mudar isso rapidamente, testar e validar com meu cliente, ok?

Isso é muito bom. Então essa parte do produto discovery, ela ganha também com o uso de inteligência artificial e a generativa. Mas a gente não deveria, como muitas vezes a gente fez no software, pular essa etapa, e deveria de fato então investir um tempo e esforço para validar muito bem essa etapa usando as N metodologias que a gente tem, como por exemplo de Stanford Design Think, para depois de fato usar esse poder aí, rapidez para desenvolver software.

Então isso eu acho que foi um grande consenso assim, falou, gente, a gente precisa, quando a gente olha para o ciclo de desenvolvimento software hoje, a gente precisa investir mais tempo e esforço em algumas áreas. É porque obviamente aí, principalmente nesse caso aí, a generativa ela vai facilitar nossa vida em outras áreas, acelerar essa entrega. Mas por isso inclusive que a nossa responsabilidade aumenta, por exemplo, no processo aí de identificar, testar, experimentar e entender o que que a gente de fato precisa transformar em produto.

Há um outro ponto, é E para além dessa área aqui da ponta, né, de que até a Daniela Deming também, e eu abordo aqui em algum ponto, ela fala do valor de habilidades inerentemente humanas como empatia, que já tá lá no processo de design thinking, por exemplo, mas de entender, de conectar com a pessoa, com o contexto, com o ambiente, e rapidamente fazer aquela leitura para entender qual a melhor ou qual a primeira dor que a gente tem que identificar e qual a melhor solução para aquela dor, dado aquele contexto, em cenários incertos, etc. e tal.

Outras partes também ganham destaque, que é a parte de arquitetura. Então, mais do que nunca, a gente tem um poder ainda maior de tomar decisões mais acertadas. Isso quer dizer discutir um pouco mais, pensar um pouco mais e entender também, dominar esse conhecimento, obviamente, de que modelo, de que arquitetura faz sentido para aquele modelo de negócio, para aquele cenário e para aquele produto. E aí ela pode muito me ajudar não só para novos produtos, mas sim monolitos, código legado.

Então é, quantas vezes eu dei consultoria numa empresa onde a gente fala assim, ninguém toca, né? Não, ninguém toca assim. A gente vai isolar essa parte do cálculo, sei lá, contábil, financeiro aqui, porque é muito importante. Sim, impossível, ninguém toca, porque É aquele artigo do Joe, né, o código espaguete, o Big Ball of Mud. Tem aquele código espaguete assim, uma parte crucial do sistema, a gente isolava e até refatorava outras partes, mas era impossível.

Aí ela nos traz uma oportunidade, a gente tem boas perspectivas e boas evidências já de que em código legado ela consegue nos ajudar a mapear melhor toda essa gambiarra, essas dependências de software, e trazer evidências para que a gente consiga tomar melhores decisões, cogitar. É, eu não tô vendo vocês, eu ouvi um barulhinho, tá, pessoal?

Ah não, foi só eu que coloquei o link do Big Ball of Mud.

Ah, good, obrigada. Não, é só porque aí vocês podem abrir o microfone e me interromper, né? Porque no Meet acaba que eu só vejo meu slide aqui, tá bom? Mas fiquem à vontade. E aí a gente consegue talvez tomar uma melhor decisão estratégica e viabilizar uma decisão estratégica numa mudança arquitetural de um monolito que não era cogitável. Porque a gente não conseguia nem mapear as dependências. Quissá entender se alterasse aquela simples variável, quanto quebraria desse código, desse produto, né, em produção.

Então a IA nos dá um poder enorme nesse sentido. Obviamente que um outro ponto que vem à tona é isso, assim, a decisão ainda precisa ser— não dá para dizer assim, aí, ah, Analisa esse monolito aí, né, faz um refactor e sobe em produção, e tudo certo. A gente não tem condições de fazer isso sobre N perspectivas. E obviamente a gente tem a responsabilidade, e essa responsabilidade é humana, né, de, com base nesse contexto, vai ter investimento, vai ter tipo de arquitetura que pode— será que é um— será que transformar esse monolito em microserviço é a melhor solução?

Será que é mesmo só refatorar É estruturar melhor e talvez daqui em algumas partes transformar em microserviço, outras não. E obviamente é a questão ética, né? Porque no final do dia a gente tá em modelos de negócio que, por exemplo, teve vários casos que discutiram sobre a saúde, né? Que a gente não pode que o risco ali é o risco à vida, né? Então vou refatorar lá um exame de imagem, por exemplo, importante, e isso afetar a identificação ou não de uma doença grave como câncer, etc. e tal.

Então, no final do dia, a responsabilidade nossa enquanto tomador de decisão, ela tem aumentado devido à dependência dos modelos de negócio nas tomadas de decisões das diferentes áreas que impactam diretamente a nossa vida sobre ele, perspectiva serem, terem como base ou como parte importante no processo lá daquela área de negócio tecnologia ou decisões guiadas por tecnologia, né, independente das tecnologias. Então isso aumenta a nossa responsabilidade e isso é prova que assim, olha, aí a poda não substitui sobre muita perspectiva, assim, muitas áreas, mas é crucial ainda que essa decisão de contexto, decisão ética, ela é uma decisão humana ainda.

E fora isso, tem outras coisas bem mais simples e triviais, mas que importam. Por exemplo, bom, o meu time não tem condições de absorver esse reféctil, e o meu time precisa aprender tecnicamente Cobol para mexer nesse refactoring. Então assim, tem que planejar isso, tem que reestruturar isso por N perspectivas. Então tem N outras variáveis do dia a dia que só a gente que tá dentro daquele contexto consegue mapear e decidir a melhor, e tomar a melhor decisão.

Então nessa geração de visão, de cenário, esse mapeamento de dependência, aclopamento, em monolitos, né? Aí pode assim, eu acho que trazer muito mais tranquilidade para as nossas decisões e permitir que a gente tome decisões muito mais assertivas, até do ponto de vista também financeiro, né? E como a gente vai evoluir e melhorar isso. Mas essas decisões ainda são nossas. E aí é que tava muito também no talk da Daniela Demian, que era uma das keynotes, mas que apareceu em vários exemplos de casos de uso de tecnologia com LLMs, etc. e tal.

E eu nem vou lembrar a história toda, mas a Daniela Deming, ela conta a história que ela vai lá numa, acho que era uma comunidade indígena, e começa a falar essas coisas de empatia. E aí tem uma foto, os alunos assim olhando para ela e falando assim, cara, O que que essa mulher tá falando? Essas coisas estranhas, não quero interagir com ela. Mas no final eles fazem um projeto bem legal e chegam lá a solução para uma comunidade.

Mas isso depois eu posso até procurar, ela deve ter essa história em algum lugar mapeada. A empatia é uma habilidade nossa, de algumas pessoas não tanto, tô brincando, né? Mas assim, a empatia é uma habilidade nossa, essa capacidade de conexão de entender que aquele cliente com aquele perfil deseja receber aquela solução naquele momento, daquela forma, que naquele time do negócio de investimento não dá para colocar tudo aquilo que a gente deseja de um produto, mas se resolver aquele problema com custo menor, com framework diferente, integrando com os outros 50 sistemas que eu tenho integrado, mais meus parceiros, pode trazer melhor valor para aquele negócio, tá?

E aí ela traz também, obviamente, isso, que se a gente investir tempo, a gente talvez possa investir mais tempo em resolver problemas que realmente importam, seja um problema focado no resultado financeiro, seja um problema focado em transformar uma comunidade, um meio social. E isso a IA não faz direito, pelo menos não por enquanto, né? Não posso dizer que não vai fazer sempre, mas obviamente a gente é muito melhor quando a gente quer nessas conexões identificar a dor do usuário, identificar contexto, identificar essas características, lidar com cenários incertos e tomar essa decisão de forma mais eficaz.

O Guerra é uma das pessoas que traz, né, que trouxe essa parte de engenharia da hipótese. Então quando a gente tá trabalhando muito com incerteza ou com cenários complexos, ou até o desafio do legado, ele não é só um monolito, né, mas é esse amonto de esse monte de infraestrutura, de diferentes softwares conectados, transacionando informação e dados, que a gente tem que fazer ter performance e segurança, né, que é um grande desafio hoje em dia da nossa área.

Como é que a gente faz isso? Então ele defende a ideia que a gente aprenda também e use também na área de arquitetura dessas decisões de design, no caso de arquitetura, né, de software, que a gente crie hipóteses e teste rapidamente, como todo ciclo ágil já do manifesto já sugeria, né? Então a gente fazer experimentos rápidos para validar qual a melhor decisão de arquitetura, né, de design. A gente usa esse termo em inglês, mas não no sentido de UX/UI, no sentido da arquitetura de software.

Então como que a gente consegue fazer pequenos, testar hipóteses rapidamente, que é um pouco que vem das evidências científicas, em pequenos experimentos de arquitetura, 3 dias, 4 dias, antes de definir qual o melhor modelo. Porque os modelos arquiteturais também são vários agora. Hoje a gente vê vários casos no Brasil onde fintechs, por exemplo, modernizaram toda arquitetura, saindo do monolito e migrando muito para microserviço, mas não só para microserviço.

Então, como a gente toma essa decisão mais acertada dado um contexto? E aí tem várias sugestões lá do Guerra. Depois eu compartilho todos esses materiais aí com vocês, ou peço para ele, se eu não tiver também esses materiais, porque a gente não gravou as palestras e não tem acesso a alguns conteúdos diretamente, mas provavelmente eles têm alguns estudos sobre. É um outro, uma outra discussão que tava latente também, como os pequenos experimentos, como é que a gente tá usando para retrospectiva, como é que a gente tá usando para user stories, para refinar backlogs.

E uma evidência positiva é que a gente tem muito backlog gigante. Historicamente, assim, com história que tu já nem sabe mais se virou duas outras histórias, se foi entregue, se não foi entregue, enfim. E isso, principalmente em times grandes, em projetos de longo prazo, era um desafio para os POs, né? Como gerir esse backlog, tá sempre atualizado, organizado, tá claro essas evidências, se foi priorizado aquele requisito ou não.

Então a IA tem ajudado muito esse processo, principalmente aí o produto Tiauna, nessa organização e priorização de backlog, né, para refinar e para automatizar essa organização. Então é algo que se você tiver uma história bem definida, bem estruturada, e obviamente queria seja um prompt, seja um agente bem com restrições bem claras, com comandos claros e bem estruturado, você consegue usar assim e ganhar muito tempo para definir os seus stories, para refinar backlog.

E aí tem aquele trade-off assim, quando eu tô discutindo requisito Talvez aí é muito melhor para mapear texto. Tudo que a gente falou, tudo que a gente discutiu numa reunião, ela vai mapear isso muito melhor. Mas não necessariamente ela vai criar user stories melhores, ela vai criar requisitos mais claros ou melhor definidos, ela vai registrar melhor a informação do que a gente. E aí, obviamente, que tem um processo nessa interação bem importante, que é que é a revisão de user stories criadas pelo PO.

Então tem uns casos que o pessoal tem usado para criar user stories e que ganha velocidade, mas no final, até porque ainda existe muita alucinação, né, isso às vezes você acha que ficou novo, uma versão do modelo vai diminuir, mas não necessariamente, né. A gente tá vendo que não é bem assim, depende de N fatores, e muitos a gente não tem controle, apenas como usuário, né? É preciso que tenha no final assim, para que a escrita dessa— não, a gente não vai substituir os POs, né?

Para que a escrita dessas stories, para que o PO ganhe velocidade, para que elas sejam melhor refinadas, de fato precisa uma revisão do PO aí. Até porque ainda existe muita alucinação. E aí, obviamente que ainda há uma desconfiança, né, é grande assim. Então você fica preocupado enquanto PO e membro de um time em simplesmente acatar ou implementar aquele requisito se ele for gerado única e exclusivamente, se não teve a supervisão de um especialista da área que tá entendendo aquele contexto, aquele negócio, aquele produto.

Um outro aspecto que foi muito discutido sobre muitas camadas, tá, são políticas. E aí é uma evidência clara, assim, a gente precisa ter políticas, a gente ter políticas de uso de IA claras, importante. Mas existem estudos que já mostram que políticas corporativas muito restritivas básica, e que elas, né, assim, se cria tanto, tanta barreira para o uso da IA, ou tanta burocracia, que o que que acontece? Você empurra o desenvolvedor, empurra, né, mas acaba incentivando as pessoas usarem isso de forma clandestina.

Então, porque assim, as pessoas da área de TI usam IA, ponto. Já assuma isso. Acho que vai ser difícil você encontrar um ser humano, independente da do momento, o ciclo de desenvolvimento de software, quem não usará IA? Fato. Criar políticas que guiem, que deixem claro o que pode não ser feito, até para ter alguma capacidade de responsabilização em caso de uso não ético, etc. e tal, é importante. Mas se você criar muita barreira, única coisa que acontece é: bom, então não vou usar IA da empresa, eu vou usar o meu IA.

Ou se você, se você não cria um ambiente seguro, isso foi um ponto também, Eu falo assim, cara, se eu usar a da empresa, tenho medo, não me sinto seguro, porque se der qualquer coisa errada— todo mundo tá aprendendo os boundaries disso, né? Mas se der qualquer coisa errada, eu vou ser responsabilizada. Então, como eu não tenho um ambiente psicologicamente mesmo seguro para trabalhar, para testar e para errar, eu vou usar ela clandestina, eu vou usar a minha IA que eu vou pagar, que eu vou criar, o que eu vou pegar de qualquer outra forma.

E aí vem um pouco essa importância ou essa consciência de que tá um pouco também diretamente conectado com cultura, que o ambiente, né, que a gente queria para ter times que possam testar, entender a melhor forma de usar, e importa, importa muito. Então o que a gente chama de um termo que eles usam é uma governança inteligente. Então a governança inteligente é uma governança onde você cria um ambiente diferente. De teste e aprendizado, como o Ágio na Prática sempre sugeriu.

Aprende com ele, vai criando guard-rails claros desses boundaries. É o que que eu posso fazer, o que eu não posso nessa situação, o que é recomendado, o que não é, para que você possa evoluindo o uso de IA de uma forma mais eficiente e também para ganhar mais produtividade, mais velocidade. É, e obviamente que toda discussão, por exemplo, em termos da burocracia ou não, do quão robusto e eficiente é um SAFE, né, o framework como SAFE, é que escalar não é trivial, né.

Existem muitas tensões entre aquela velha discussão entre autonomia versus alinhamento, e aí aquela justificativa de que autonomia demais em alguns casos também não funciona, e aí você volta para microgestão e volta para decisões top-down, que também não é uma solução. A gente já sabe que não funciona, mas que é usado como desculpa para dizer que não, em detrimento disso eu preciso usar isso, dado que aquilo não funcionou. E isso é um problema do ágil.

Então a gente tá sempre buscando esse balance entre autonomia de tomar decisão sobre N camadas versus seguir atingindo um objetivo, uma meta alinhada com a estratégia do negócio. E isso assim, acho que eu vi várias discussões também, é um trade-off assim. Não tem uma fórmula mágica para mim entender naquele cenário, naquele time, naquela empresa, o quanto eu consigo, né? Não tem uma meta que eu vou aplicar essa fórmula E eu sei que esse time eu posso dar mais ou menos autonomia, porque isso assim depende de vários fatores.

Uma é o time.

Então você tem times com maior maturidade, que as pessoas trabalham muito bem juntas, que talvez pode ter mais autonomia. Mas obviamente que isso jamais significa não estar alinhado, e você precisa ter líderes, né, que tragam esse alinhamento. Com o negócio, é que deixem claro quais as metas da empresa, qual a meta do teu time, aonde você precisa chegar. Mas isso, só que é importante não confundir, que eu vejo isso muito ser confundido no mercado, com enrijecer para uma versão anterior, que é decisão top-down, microgestão.

Então isso nada tem a ver, isso é muito mais uma questão de comunicação, colaboração e alinhamento dado aquele contexto. Então você tem que estar sempre, e até uma discussão bem interessante dessa, desse tópico, foi que a gente tinha vários profissionais e pesquisadores sêniores e consultores independentes dos Estados Unidos, da Alemanha, que alguns foram propulsores aí do Manifesto Ágil e acompanham, né, todo esse ciclo que mudou aí de desenvolvimento de software, né, e todas essas mudanças ao longo dos anos.

E aí uma coisa que todos são unânimes e destacam é assim, olha, a gente desenvolve software, dá trabalho e exige que a gente esteja sempre revendo as nossas certezas, nossas decisões. E nesse caso, em qual contexto, em que time você vai ter um time mais autônomo? Talvez no mesmo projeto, eu trouxe um time que não dá para ter tanta autonomia. Você tem áreas de negócio que tem mais risco, outras áreas de negócio que tem menos risco.

Então você tem que ter mais cuidado, menos cuidado, mais impacto, menos impacto. Aí você vai precisar sempre rever esse equilíbrio. Assim, é um, faz parte do processo desenvolvimento de software, faz parte da nossa vida é fazer essa gestão e definir esses equilíbrios e revendo esses acordos ao longo da jornada. Não tem muito o que fazer assim, a gente precisa estar sempre revendo esses acordos, dado como cenário muda, os contextos, etc. e tal.

E aí a gente fala muito, né, em— eu queria trazer 3 pontos do mindset ágil que eu vi o pessoal destacar, que eu gostei muito, porque a gente sempre discute mindset ágil, tem livro que auxilia, enfim. Mas alguns pontos importantes, acho que é: a gente pode assumir que a gente tem um mindset ágil quando a gente tem um ambiente e é adaptado, ambiente onde feedback contínuo é uma regra. Mas é isso. Se você tiver no ambiente que feedback é disfarçado de agressão, né, de comunicação violenta, não é sobre isso que estamos falando.

No ambiente onde é possível, eu estou aberta a receber feedback, mas eu também dou feedback. Essa gente tem essa cultura de foco na melhoria contínua baseado por dados e não é pessoal. Obviamente, quando a gente tá falando que a gente tem um modelo mundial, de um cenário mundial de muito mais incertezas, colaboração, o valor da colaboração é evidente cada vez mais. Então eu preciso que não só entre equipes, eu acho que isso já tá assim superado, né?

Não existe entregar software sozinho. Sim, eu posso fazer um aplicativo qualquer sozinho, mas eu não consigo escalar o negócio, ter produtos, ter serviço, entregar software trabalhando sozinho. Para isso eu preciso saber colaborar com as pessoas, me comunicar e ter essa habilidade de trabalho em equipe. E um outro fator que eles destacaram muito é a tolerância à ambiguidade. Então, que eles consideram que se a pessoa que tem essas 3 competências, ela consegue, ou ela tá alinhada aí mais ao mindset ágil.

E aí é um outro fator que é bem importante. Acho que mais do que nunca na história a gente tem um amount aí, né? A gente tem um, esqueci a tradução, mas a gente tem um monte de dados, uma gama absurda de dados para tomar decisão. Não é inteligente a gente ignorar isso. Então, e com, e a gente com técnicas, e a gente consegue bem organizado, com obviamente tendo que estruturar esses dados, mas a gente consegue combinar diferentes tipos de dados e isso nos permite tomar decisão on time, né, numa velocidade como nunca, combinando informações diversas e captadas de diversos lugares, de diversos tipos, que nos ajudem a tomar decisões melhores.

Então não tem por que a gente ignorar decisão de produto, decisão de software, decisão de arquitetura, então decisão sobre desenvolvimento de software que não seja guiada e baseada em dados. É crucial que a gente tenha esse centro de inteligências, que não necessariamente é um centro de inteligência ou está centralizado, mas que nos permitam insights on time para tomar melhores decisões. E quem souber usar isso de forma mais estratégica certamente tá muito à frente no mercado.

E aí, falando um pouquinho agora do, da minha área, né, especificamente uma das minhas áreas, mas minha área main aí que é de vida técnica, a gente ficou muitas horas discutindo sobre como a gente usa, né. E aí muitos cases mundiais, teve um workshop só sobre isso, depois a gente se reuniu numa sala com vários especialistas do mundo E a gente até vai produzir um trabalho bem legal porque a gente começou a expandir uma discussão e quando vi a gente tava com 3 paredes assim dos impactos e como a gente pode mapear, das camadas, da onde que a gente tem que olhar.

Então mais do que nunca eu acho que tem um valor percebido de fazer gestão de dívida técnica. Legal. E o mundo hoje E o uso de IA em desenvolvimento de software, ele tem, em termos de dívida técnica, tem dois trade-offs importantes, que um é a inserção de dívida técnica pelo uso indiscriminado de IA. Então você vê vários projetos open source que o pessoal tirou do ar e fechou. Por quê? Porque era inviável revisar código ruim plotado lá, né, imputado lá, implementado, e que subiram por decisões, apenas uso de IA indiscriminado.

E no dia a dia a gente tem visto a injeção de vulnerabilidades, a violação então de segurança, o aumento da complexidade É, sob muitas perspectivas, o uso indiscriminado de IA tem escalado numa velocidade não conhecida antes a inserção do indivíduo, a técnica em código. Isso é um fato, a gente já tem várias evidências. Por outro lado, é como no caso da arquitetura, IA me permite ser mapeado de uma forma mais eficiente alguns tipos de dívida técnica.

E também aí começam a surgir outros tipos de dívida técnica, que eu não vou entrar na discussão aqui, mas tem o social debt, enfim, n outros tipos de dívida técnica que passam a ser oriundos devido ao uso de IA. Então a gente insere mais dívida técnica em muitos contextos, a gente coloca em risco numa velocidade absurda, por exemplo, segurança, é daquele produto, e a gente cria novos tipos de dívida técnica. Isso tá posto. Por outro lado, é importante, até por isso que a gente evolua rapidamente ferramentas de gestão de dívida técnica que nos auxiliem primeiro identificar e mapear essas dívidas técnicas.

Esse lastro, mapeamento desse lastro, é super importante. Depois, se esse pipeline de desenvolvimento, DevOps, ele tiver automatizado, eu consigo começar talvez de uma forma mais eficiente mapear o impacto da dívida técnica, a causa raiz e o impacto. Hoje é muito difícil a gente conseguir mapear impacto de dívida técnica em termos de negócio. A gente sabe que tem um impacto impacto. Esse impacto, sob alguma perspectiva, ele se torna visível porque pode reduzir performance, tem uma insatisfação final lá do cliente, eu não consigo entregar aquele valor que eu prometi.

Mas de fato falar que aquele, que aquela vulnerabilidade, que eu, aquela complexidade, aquela gambi da gambiarra que a Grazi injetou com IA resultou naquele impacto é muito difícil de mapear. Talvez, mas a gente precisa evoluir ainda as ferramentas. Então, o que que a gente tem hoje? As ferramentas trazem melhores insights sobre onde temos dívidas técnicas e qual é a área do meu produto que ela tá mais sobrecarregada com dívida técnica.

Isso já tá muito bom, mas obviamente esse mapeamento do impacto ainda ele não é tão eficiente. Então a gente precisa evoluir e talvez treinar bons agentes que nos ajudem a ficar o tempo inteiro mapeando e monitorando a inserção de dívidas técnicas e criando aí guardrails que nos permite, que nos garantam que não vamos subir código em produção se não tiver aqueles níveis de qualidade de software. E isso é um ponto legal, é que talvez ao invés de apenas garantir algumas métricas estáticas como cobertura de teste, que em muitos casos garantem muito, mas não diz nada, né, cobertura total, mas não funciona, né?

Todas as nossas gambes têm cobertura garantida. A gente tem muitos casos reais assim. A gente tem a oportunidade de, de fato, tem sites valiosos que me garantam qualidade de produto, que me garantam que aquele valor que eu quero entregar não seja entregue. Mas acho que a gente tem bastante para evoluir nessa área, e a gente tem bastante preocupação com a velocidade com que a gente tem inserido, gambiarra com o uso indiscriminado de LLMs, tá?

Então, por mais que os modelos tenham evoluído, não necessariamente o conhecimento humano ou comprometimento humano com o uso disso tem acompanhada essa evolução. A gente tem muito estudo aqui, muito teste para fazer. E aí, uma, já indo para o final, uma conclusão que a gente chega, eu, na minha opinião, duas grandes conclusões, é três, que uma eu falo que enfim engenharia de software venceu, né? A gente por muito tempo reduziu o desenvolvimento de software codificar ou implementar linha de códigos.

Isso já era um erro posto, fato, mas a gente reduziu isso muito a isso. E mais do que nunca, digitar aquela linha de código, implementar aquela linha de código, as IAs vão fazer, ou já fazem, de forma mais eficiente e mais rápida do que a gente, e nem linguagem, né, no mesmo tempo. Então, se uma linguagem é futebol para mim, mas Entender onde precisa mudar, como precisa mudar, definir esse planejamento de forma estratégica. Como é que eu vou estruturar essa arquitetura para que não tenha, para que eu ganhe performance, para que eu consiga evoluir esse software mais rapidamente, para que eu não permita violações de segurança?

Provavelmente a gente vai ter que investir mais tempo nessas áreas. Então, áreas que eram experiência de usuário, discovery de produto, com habilidades como entender esse contexto, pensamento crítico, pensamento analítico. Então essas áreas obviamente elas se tornam mais latentes e importantes e com valor maior na tomada de decisão. O outro ponto é liderança, né? O papel efetivo da não liderança ou da liderança, o impacto fica cada vez mais evidente.

Porque quando a gente decide que a gente não vai voltar para o modelo tradicional, que é top-down, microgestão, porque definitivamente se ele não funcionava no modelo passado, que a gente tinha muito mais previsibilidade, imagina agora que é um modelo extremamente incerto, que muda rapidamente em um ambiente cada vez mais complexo e que exige mais personalização em muitos casos, né, com muito mais poder quando a gente considera o uso de IA.

Então esse ambiente ele exige um líder que saiba guiar as pessoas por um caminho, alinhar as pessoas em uma direção e permitir então que elas de fato tenham o seu nível de autonomia em termos de decidir como elas vão trabalhar, discutir, experimentar qual a melhor arquitetura Qual a melhor ferramenta, talvez qual a melhor linguagem, qual o melhor modelo a ser implementado naquele produto ou serviço, que ela possa usar, né, essa prototipação rápida e validar com o cliente, mas ter acesso ao cliente para validar, ter acesso e discussão com as áreas de negócios, ter que rodar com outras áreas.

Então o papel do líder, ele muda drasticamente, ou pelo menos fica muito mais visível o impacto de uma liderança ruim, de uma liderança eficiente. E aí muitos dos líderes, eles precisam se reinventar sobre muitas perspectivas. E uma conclusão é: a gente entende que o ágil, ele vai precisar ser transversal. Então não faz mais sentido. Acho que eu lembro que sempre que eu tentava implementar ágil em umas empresas, tu implementava aqui no teu mundinho da tech, né, o time de tech.

Aí vinha uns tsunamis das outras áreas. Então comercial vendia mais do que podia, o suporte passava pelos 5 níveis de suporte, mas na verdade o único nível que funcionava era lá do engenheiro sênior, né, vinha parar aqui no time de tech. Então assim, as outras áreas, quando elas tomavam decisões erradas, não importava o quanto tu organizava o teu time de tech, assim, era uma avalanche. Assim, por mais que tu ia criando guardrails para segurar um pouco a pressão, é todo o resto que não funcionava, falta de comunicação, decisão transparente.

Era impossível não ser afetado, porque é um ecossistema, né? Todo mundo entrega um produto, é um negócio, e as coisas estão conectadas. Então, cada vez mais a gente precisa que as outras áreas entendam isso e sigam esses princípios e valores. E aí tem um ponto que até ano passado, ano passado, ano passado, o Kent Beck veio aqui no Insper, ele veio para o Brasil para atender uma grande empresa, e Eu convidei ele para vir aqui, infelizmente ele aceitou.

Ele passou umas 3 horas, acho, conversando com os alunos. E ele, nessa fala, ele traz um pouco isso, né, que mais do que nunca a gente entende que os nossos valores do manifesto, né, e o valor desses princípios e do próprio, dos valores do manifesto, ele é evidente. Assim, a gente precisa focar no que importa, na entrega desse valor, nas relações humanas, em ter lideranças que tenham esse papel de líder servidor e que guiem os times, né, que tragam essa visão estratégica, que guiem os times, que permitam esse ambiente de trabalho seguro, para que não exista inovação no ambiente que você não possa testar, você não possa experimentar.

Então testar rápido, usar o AI também para isso, permitir que as pessoas cocriem, né, e cocriem essas políticas de uso de IA, experimentem. Poxa, será que eu posso? Até onde eu posso ir usando IA? Até onde que eu tô violando? Até onde que eu não tô? A gente tem que aprender. Tem coisas que são óbvias. Obviamente você não vai pegar meus dados lá do banco de dados, vai jogar e vai pedir para plotar um gráfico, né? Você não vai pegar todos os seus clientes, vai colocar numa IA aberta, jogar e falar assim, olha, me dá uns gráficos aí que eu vou analisar os dados de todo o financeiro da empresa aí essa semana.

Você não vai fazer essas coisas absurdas. A gente já tem uma boa visão do que é certo e errado. Eu acho que não, uns limites assim extremos, mas a gente precisa co-criar, entender como a gente vai usar IA para desenvolver software de uma maneira segura. E isso, e para isso a gente precisa seguir o que o ágil já, já sugeria, né, a partir do seu manifesto. Obviamente que a forma a gente vai ter que ir ajustando. Então, como lá no modelo tradicional você não pegava o PMBOK e implementava lá os, né, todos os níveis desse MMI, outros níveis para certificação, você nem deveria colocar aí colocava quem queria, é todos aqueles 1.200 documentos lá que eles sugeriam, e monitoramento, não sei quantas métricas.

O ágil nunca disse que você deveria usar Scrum puro, Squad puro, né? Então você vê que se você analisa os relatórios, sempre práticas combinadas, mas seguir as práticas, né? Práticas combinadas em modelos híbridos são muito eficientes para depender do contexto, a depender do time, e Empresas com um bom nível de maturidade seguem esses modelos combinando práticas e técnicas. O que a gente não pode é retomar um modelo go horse, ao caos, porque caos é caos, não é, não segue nenhum processo, nenhum indicador, nenhum planejamento.

Então, obviamente que a gente precisa ter processo, a gente precisa ter planejamento, mas acima de tudo a gente precisa ter ambientes seguros onde a gente consiga de fato experimentar rápido Usar nas etapas que for possível LLMs e entender quais são os limites, né, os limites éticos, legais do uso dessas LLMs e de outras, e as, para potencializar nossa entrega, o nosso valor, e para melhorar também o monitoramento de segurança, de gestão de vida técnica e outras métricas que a gente precisa para entregar um software com qualidade.

Que seja mais fácil de manter e evoluir ao longo do tempo. Mas acho que essa, essas seriam as 3 mensagens principais assim que eu levo da XP. E a Yuta, eu não consegui assistir todo esse, essa palestra, mas Yuta Einstein, ela tem vários artigos sobre. E eu até vou fazer, eu fiz algumas entrevistas, eu não coloquei no ar ainda por falta de tempo de editar. Eu fiz algumas entrevistas com algumas pessoas sobre esses temas. Eu vou lançar esses meio que videocast, podcast.

E a Dayuta, eu combinei de fazer online com ela. Eu quero que ela fale justamente sobre esse tema, né? Ela tem se tornado uma das grandes pensadoras mundiais sobre sustentabilidade quando a gente fala de tecnologia, de ágil. Ela tem criado alguns frameworks nessa linha. E ela, e essa palestra dela foi com certeza assim, senão eu arriscaria dizer, senão a mais debatida, né, mas que gerou um impacto enorme em toda audiência. E ela traz toda a reflexão sobre o uso de tokens, sobre impacto no meio ambiente, né, o quanto ela faz o cálculo exato.

Eu não tenho isso agora, mas depois vou discutir com ela, eu trago para vocês o quanto os memes que a gente gera impactam diretamente o meio ambiente. Assim, isso é absurdo. Quissá todo o resto do uso de LLMs no dia a dia. Então ela, ela traz a reflexão que no final do dia a gente não pode esquecer da importância de ser sustentável. E a gente sabe que o custo não só econômico é altíssimo, mas o custo em termos de água para resfriamento, né, e n outros fatores é altíssimo para uso e evolução dos modelos.

Então, uso consciente dele para gerar de fato prosperidade ou gerar benefícios econômicos que gerem melhoria de vida e prosperidade, que respeitem o meio ambiente e que tragam E que reduzam as desigualdades, né? Então, quando a gente fala em termos de igualdade, muitos estudos mostram que, aliás, os trabalhos que serão substituídos por IA majoritariamente são hoje feitos por mulheres. Porque são vários trabalhos é que podem ser automatizados.

Adicionalmente, que os modelos, vieses, algoritmos replicam vieses que a gente já tem. E aí tem até um estudo, né, no LinkedIn, por exemplo, as mulheres eram expostas, menos expostas a vagas que tinham excelentes salários, salários em tech.

Por quê?

Porque quem procurava mais esses salários, essas áreas, quem trabalha mais nessas áreas são pessoas do gênero masculino. E aí obviamente apareciam mais essas vagas para pessoas do gênero masculino. Então a gente era menos exposta a essas oportunidades. Pessoas negras, de vários algoritmos de reconhecimento facial que não reconheciam pessoas negras. As pessoas não conseguiam ter acesso aos lugares, né? A gente tem vários casos com vários problemas disso.

Eu vivi um caso de um amigo que quando implantaram em um lugar o reconhecimento facial, simplesmente ele não conseguia, né? Cadastrava e recadastrava e ele não. Toda vez ele precisava recadastrar a foto para conseguir acessar aquele lugar. Então vi isso acontecendo no dia a dia, dias atrás, sabe? Assim, vivi isso na prática, tem estudos que provam. A gente tem lugares que a gente não tem ainda acesso à internet. Então assim, quem acessa IA?

E aí essas desigualdades vão aumentar, porque uma pessoa com IA vai ter muito mais poder de uma pessoa que, quiçá, acessou a internet, quiçá conhece IA. Então assim, a gente tem vários problemas de equidade que a gente também não pode ignorar. E fora a parte da experiência do usuário, de você não conseguir ter um produto que atenda aquelas necessidades porque a gente não tem pessoas de diferentes raças, diferentes culturas necessariamente.

Por exemplo, não tem mulheres criando esses algoritmos, desenvolvendo essas soluções tão poderosas como algoritmos de IA generativa. Que tem um poder enorme, mas que tem um viés. Não tem aquele, não tem aquela pessoa com aquelas características também implementando aqueles algoritmos. Então a gente tem vários desafios sobre equidade, sobre sustentabilidade. E no final, né, tem um amigo nosso que ele fala assim: quem que precisa do meio ambiente para sobreviver?

A gente precisa do meio ambiente ou meio ambiente precisa da gente, né? Então, no final do dia, eu acho que a gente, nessa corrida da automação, da decisão guiada por máquina, a gente precisa lembrar que o replace ali, o human replace, a gente tá nessa categoria, né? Então é importante ver isso com muita parcimônia, com muita responsabilidade, com muita ética. Pessoal, essa era um pouco assim, alguns highlights, né? A gente discutiu muita coisa, foi muito legal, e eu conseguiria ficar aqui algumas horas discutindo com vocês cada um desses tópicos, né?

Mas abro agora para vocês trazerem percepções de vocês, insights, como é que vocês estão vendo isso também no mercado. Eu não sei quanto tempo a gente tem, né?

A aula mesmo vai até 17:50. Eu sempre tenho que fazer essa conta mentalmente.

8:20.

É 8:20.

Então é 20:20.

A gente tem um tempo aí, tem bastante tempo. É, eu ia falar exatamente isso. Quem quisesse fazer perguntas, levantasse a mão, e aí eu vou chamando na ordem que tiver aqui. Então, começando por você, Everton.

Boa noite. Posso chamar de professor? Eu posso, né, professor? Pode. Boa noite, professora, tudo bem? Meu nome é Everton. Eu vou entrar um pouco na área que a professora é especialista, então, porque é uma dúvida que eu tenho, essa área aí de dívida técnica. A gente sabe que no mundo corporativo, não todas as empresas, mas a maioria das empresas, só se pensa em trazer a dívida técnica para ser implementada a partir do momento que ela gera um custo financeiro para a empresa.

Enquanto ela não tá gerando prejuízo, essa dívida técnica vai ficando lá no roadmap e não sai de lá, né? Então, e daí, como até tava lendo uns artigos que falam um pouquinho, que a professora falou ali sobre a IA que tá gerando essas dívidas técnicas e tudo mais. Então a minha preocupação é: a IA tá gerando um monte de dívida técnica, mas a gente não ataca essas dívidas técnicas para realmente diminuí-las. Ali e tudo mais. Então, como que a professora vê isso assim?

Em que ótica a professora enxerga isso? E como a gente poderia, como profissionais no dia a dia, tentar, vamos dizer assim, trazer essa visão de realmente é importante a gente atacar essas dívidas técnicas, sabe? Eu quero só Só para complementar, uma última perguntinha rapidinho, que é de uma pesquisa que eu tô fazendo também referente aqui a métodos ágeis. Se vocês acabaram discutindo alguma coisa sobre a comunicação assíncrona em equipes que estão home office mesmo, né, então ali tudo mais, porque esse também é o que eu vejo, acho que é um grande desafio atualmente para o ágil, apesar de várias empresas ter voltado para o híbrido presencial, mas tem muita empresa ainda que trabalha no home office.

E eu vejo como um grande desafio aí para parte da metodologia ágil no exato momento, sabe?

Teve, depois eu até olho bem direitinho o artigo, mas se eu não me engano teve uma discussão que o pessoal, vou começar pelo fim, depois eu volto para a dívida técnica, mas que o pessoal é meio que chegava à conclusão que por causa desses desafios da comunicação assíncrona, que era uma política flexível de trabalho, né? Assim, eles têm um termo lá em inglês que eu não lembro agora, e que era assim: eles entendiam que, por exemplo, se você precisasse discutir arquitetura ou planejar como é que você ia, quais histórias tu ia priorizar naquele produto, mesmo descobre de produto, essas partes que exigem mais interação no momento, né, em determinados momentos do desenvolvimento, Talvez valesse ir 3 dias para o escritório, sabe, ou voltar a fazer alguns momentos de interação nessa parte de brainstorm, definição de prioridade, fechar escopo, definição arquitetural.

Até pensando nessas, no que o Guerra falou de teste de hipóteses para arquitetura, fazer isso presencial. E aí, definido isso, o resto do trabalho poder ser remoto. Então agora a gente vai ficar 3 meses remoto porque a gente já validou essas prioridades. Obviamente que tem que sempre vai ter os ciclos de feedback, seja usando Scrum ou não, né, como sprint ou reuniões de planejamento, porque se usar Kanban, entrega contínua. Mas um desses trabalhos, eles meio que chegaram nessa conclusão assim, que eles entendiam que precisava ter alguns momentos presenciais, principalmente para tomada de decisão, principalmente Porque essas etapas ganham um poder maior, mas talvez uma importância maior agora para não escalar o BO depois com mais velocidade.

Mas eu posso trazer o estudo para ti para ter todos os detalhes, porque eu não parei nessa discussão. Então teve alguma discussão dessa comunicação. Eu tô pensando aqui se tem mais algum outro ponto que eu vi. Do assíncrono. Se eu não me engano, teve um outro, uma outra questão que é: nesses casos, definição de papéis, responsabilidades, liderança pesa ainda melhor, mas não melhor, porque são eles que drivam o que precisa ser entregue, onde e quando, tá?

Mas isso que eu lembro de como melhorar esses desafios do A5, tá? Mas só isso. Depois eu vejo se tem mais alguma coisa, eu te envio. Indo para a dívida técnica, esse é sempre um desafio assim. Qualidade sempre foi um desafio. Investir tempo em qualidade sempre foi um desafio. Antigamente, a melhor estratégia que eu vi acontecer era transformar o impacto, a dor passada em relatórios em linguagem de negócio, para dizer: olha, o futuro vai se replicar de novo se a gente não parar investir em qualidade.

Mas em geral, o melhor argumento era dor passada traduzida numa linguagem de negócio, falando assim: olha, você viu o impacto? Você viu a AWS parada? Não falei isso, né? A tarde inteira por um erro. De código, né? É um custo básico assim. Então assim, a gente sempre tem essas histórias, né, em projeto, sempre tem um dia DWS, um dia DA, né, de colocar que aconteceu, que teve um impacto revelador. A esperança, mas eu não sei se eu diria que já ocorre, a esperança com IA e um pouco com essa mudança de perspectiva do que inclui entregar software, do processo de desenvolvimento de software, é que fica mais evidente agora e mais consciente a todos os níveis, inclusive as tomadas de decisão, que tu vai acelerar.

Eu não queria usar esse termo, mas tu vai acelerar. Tô procurando um termo melhor aqui, né? Tu vai acelerar a produção de coisas ruins se tu não parar para pagar de via técnica. É inevitável, assim, é inevitável. Eu arriscaria dizer que a gente vai ter num curto prazo muito problema visível como esse de empresas que tu não imaginaria. Assim, para, você tá vendo, e não é a única, né? Assim, tu tá vendo muita empresa grande tendo impacto, casos reais que até dá para tentar usar no trabalho para justificar.

Fala assim, cara, como é que isso passa lá? Isso é falta de controle, de gestão, de qualidade em geral. Pode ser dívida técnica ou não. Como é que isso passa? Então assim, imagine a empresa que nem tem nenhum controle, não investe nisso. Eu acho que a gente vai ter cada vez mais casos com impactos reais e às vezes impactos gigantes em termos de vai afetar a vida, vai afetar um avião, vai afetar áreas importantes do meio por acelerar código ruim, gambiarra com uso de IA.

Acho isso inevitável. Usaria esses exemplos para falar assim, olha, a gente quer ir por esse caminho, a gente não quer. Mas eu acho que, então, eu acho que tudo isso no médio prazo vai contribuir para que a gente valorize mais planejar um pouco mais, pensar mais e reservar tempo para boas práticas, seja para refactoring, seja para repensar uma arquitetura, seja para melhorar. Mas o tempo do mundo é o tempo do mundo, né? Tempo do mercado é o tempo do mercado.

Então É muito difícil prever isso assim. Eu tento ser muito cautelosa, né? Tem tanta gente ruim prevendo absurdos e coisas que não, você não, na prática ninguém sabe o que vai acontecer. Que eu arriscaria dizer é que no curto prazo a gente vai continuar na mesma luta, sabe? De task, tira task, bota task no backlog, brigando para colocar lá um tempinho em qualidade. Não vejo isso mudar. Espero que as ferramentas evoluam rapidamente, porque tem um ponto: a gente não vai conseguir— eu, Grazi, pequena, média empresa, eu sou dependente de outras ferramentas para me ajudar a mapear isso.

Não tenho tempo para ficar criando agentes, para investir tempo em criar meu próprio plugin de mapeamento de qualidade de software. Algumas empresas vão conseguir, alguns times, mas a gente tá tão sobrecarregado que eu preciso que essas ferramentas, e open de preferência, evoluam a certo ponto para que eu consiga trazer evidências melhor desse impacto na linguagem de negócio. Acho que se eu conseguir ter um mapeamento, meu sonho é que, poxa, eu pego um Sonar Cube, que ele já melhorou bastante, embora eu não use tanto no dia a dia, mas eu meio que tô sempre acompanhando, né?

Eu consigo mapear rapidamente aqui aquela parte do software que eu vou mexer, tem um impacto que é uma parte importante para o nosso negócio, Tá super lotada de dívida técnica. E aí é tentar negociar com os gestores. Mas aí tem um ponto que é o papel da liderança. Se a tua liderança, seja liderança, porque aí depende quantas camadas abaixo tu tá da tomador de decisão, né? Mas se a tua liderança técnica, se o teu gestor de projetos, a pessoa que tem poder para negociar isso numa reunião de priorização de negócio, de tomada de decisão, seja com C-level, né?

Porque aí depende muito de quantas camadas tem aí, não tiver a capacidade de negociar isso e de não é brigar, mas de realmente se impor e mostrar a importância disso, também não sei se vai adiantar, entendeu? Porque assim, os devs, os engenheiros de software, as engenheiras de software, elas já estão conscientes dessa dor. O pessoal de QA, de teste, whatever, já sabe a importância de olhar para isso e de gerir qualidade de software.

Então, tipo, é tentar converter convertido. O que a gente precisa é tentar mapear melhor esse impacto, evidência numa linguagem de negócio, e melhorar essa consciência de negócio. Mas se quem tá acima de ti não tiver uma capacidade de E nem uma sensibilidade primeiro de lutar por isso, e uma capacidade de negociar isso é muito difícil priorizar. Essa é a minha visão. Então a minha estratégia nas empresas que eu implementei acho era primeiro mapear a dor passada, do tipo assim, sabe aquele dia que o suporte nível 3 parou e tal?

Aquilo foi uma dívida técnica, a gente precisa, porque teu principal cliente ligou e você veio lá estressado, veio com a gente. Então esse dia é, se a gente for, se a gente for mexer nessa parte do monolito, por exemplo, que tem bastante dívida técnica, que tem bastante dependência, a gente precisa ter uma gestão de tempo ali para talvez na sprint anterior, por exemplo, na release anterior, investir um tempo de melhoria, de pagamento dessas dívidas técnicas.

E aí eu colocava sempre 30%, era um número que eu sempre usei. Para qualidade, não só de dívida técnica, porque a gente tem outros problemas, né? Não dá para considerar a métrica de dívida técnica. A gente também não pode dizer que dívida técnica são todos os problemas de qualidade. A gente tem outros problemas de qualidade que não são dívidas técnicas e que também precisam ser endereçados, né? E aí usava assim, pelo menos 30% das sprints que eu conseguia negociar, que sei lá, não caiu em produção, que urgente virava super urgente, né?

Que aí você tem que resolver, não tem muito o que fazer. Para melhorar isso. E certamente não faz mais sentido hoje, tá? Não faz mais sentido, é muito forte, mas tem um time dedicado só para qualidade. Eu acho que a qualidade, ela precisa estar na cultura de cada time e na responsabilização de cada time. Que era um modelo que se via muito, se investia muito às vezes, mas não, na minha experiência, ele não retornava o que precisava assim, não resolve o problema.

Então agora a Cristina.

Professora Graziella, primeiro Parabéns aí pela apresentação, obrigada aí pela sua aula, né? É muito interessante todos os pontos. Eu tenho umas perguntas para fazer, mas só aproveitar aí esse último tema da qualidade, né? Eu não sou da computação, sou da engenharia de produção, né? E eu já trabalhei em qualidade de sistemas industriais, no caso, né? E a gente tinha esse problema também, né? O time da qualidade é era o time que ninguém queria ver, né, que a gente era os chatos da empresa.

Ninguém queria nossa presença lá, né, sabia que era problema. E mas o que a gente fazia é que, eu não sei, no caso da indústria, né, da ponta industrial, ela, a gente tinha vários clientes internos, né. Então como tinha uma saída de um setor que era entrada para outro, então a gente conseguia quantificar, a gente convertava tudo em dinheiro, né, que era o que as pessoas, a língua que todo mundo entende é dinheiro, né. Então é um material, uma matéria-prima que ficou parada em algum lugar, aquilo é custo, né.

Então a gente ficava, ó, por tanto tempo ficou parado, tanto de recurso. Agora não, eu acho que essa lógica não funciona muito para software, né. Mas era assim que a gente conseguia falar que uma área tinha que ser, tinha que melhorar os índices ou não.

Mas você sabe que, só me permita um adendo, a gente faz isso mal. Minha percepção, a gente, a gente é otimista, então a gente faz rapidinho. E todo mundo acha também que o nosso trabalho é rapidinho, né? Que pior é que às vezes fala assim, não é rapidinho, dou um jeito. Aí você vai ver, é um monstro Frankenstein lá que você tá fazendo não sei quantas horas para resolver o problema. A gente precisa quantificar melhor para o nosso trabalho.

Isso envolve um pouco essa conscientização que software não é sentar e digitar uma linha de código, ou agora pedir para AI conversar com essa linha de código. Tem um processo de pensar, de entender o contexto, né? 60% do tempo— tinha uma pesquisa, tem uma pesquisa da Microsoft que acho que é do ano passado, 60% do tempo dos desenvolvedores da Microsoft era entendendo de código legado para depois alterar. Isso é custo e a gente não precifica isso muitas vezes.

E a gente, quando a gente vai lá puxar nossa tarefinha do backlog, que que tá? 60% do tempo daquela tarefa para pensar, 30% para ver se tem dívida técnica, não sei o que lá, você entende? E aí a gente estaria precificando. Eu acho que a gente tem muito aprender sobre isso, tá? Então talvez eu não conheço, mas modelos usados na produção possam nos ajudar a entender assim cada variável desse custo, porque a gente subestima isso.

E isso é um ponto importante, tá? A gente não faz direito. E aí é a nossa meia-culpa aqui, sabe? Então parece que é fácil, só que não é.

No industrial não era também. Renan, você quer comentar sobre isso ou é sobre outro?

Não, não, é outro tópico.

Pode continuar. Então deixa eu fazer aqui as minhas perguntas sobre a sua palestra. Você falou, né, da, assim, dessa questão do uso exagerado, né, da IA generativa. E aí eu Eu queria saber se o pessoal chegou a discutir, que eu tenho ouvido muito, e não no contexto de software, mas de empresas da área jurídica, da área econômica, que tem preferido pagar uma IA, né, um LLM, do que contratar um analista júnior, né? E porque aí ela dá uma resposta superior ao analista júnior.

Que tá no início da carreira não tem todo esse contexto, né, toda essa bagagem, essa experiência. Então ele não— e assim, né, a princípio pode ser uma economia para empresa, né. Agora, eu sou, eu também sou servidora pública, né, trabalho com políticas públicas. Então, mas a longo prazo, a médio e longo prazo, a gente tá criando problema muito grande, porque o como que você vai treinar as pessoas, né? Como que uma pessoa se torna sênior se nunca tem sido júnior, né?

Então você cria aí um problema social complicado. Isso tem acontecido, eu não sei se isso foi, chegou a ser discutido em algum ponto, ou se o pessoal teve alguma percepção dessa questão de usar LLMs como analista júnior.

Foi muito. Eu não acompanhei todas, eu acompanhei mais discussões de corredor sobre isso, mas eu até tô em vários debates que tem um executivo que ele reúne alguns executivos aqui em São Paulo. A gente se reuniu quarta-feira passada, eu acho, semana passada, que traz um pouco também essas discussões. Mas o que eu tenho acompanhado é assim, isso é um baita dilema, porque isso é um fato. As empresas estão falando assim, cara, não preciso mais do dev júnior, do analista júnior, whatever júnior, porque se eu treinar direitinho aqui minha IA, ela não reclama, traz um resultado melhor.

Todas aquelas discussões, o que de uma perspectiva inicial parece que é uma verdade. Tá sendo bem pragmática assim. O modelo é bem treinado, ele pode ser melhor que a nossa versão júnior. Só que por outro lado, eu não conheço, pelo menos até eu não tenho esse chip implantado, não faço parte de nenhum outro experimento, mas hoje eu não conheço o modelo de evolução de conhecimento e experiência humano que seja que não seja embasado em experiência.

Então, como tu dá esse salto de não temos júnior e temos um pleno e um sênior é uma grande incógnita, e que todo mundo tem meio que se perguntado. Mas a triste realidade é que eu tô vendo muitos gestores tomar a decisão de substituir E aí a gente vê, tem uma pesquisa, depois eu procuro e coloco aqui, eu não lembro o nome dela, mas que reduz drasticamente. Isso é uma pesquisa recente, o contratação de júniores, dev júniores no mundo.

Fato. Só que é isso, isso a gente vai ter que entender esse impacto, porque por outro lado você vê um movimento mundial de executivos sêniores aposentados sendo chamado de volta Para as empresas, por N razões. Mas resumindo, né, a gente não tem segurança dos novinhos lá tomando decisão porque não tem bagagem, não tem repertório, não tem experiência, não tem maturidade, N outros fatores que a experiência nos ajuda a desenvolver.

Então a minha aposta, mas realmente é uma aposta, é muito limitada, né, baseado nisso, é que É, não vai resolver. Essas pessoas vão ter que voltar porque você não vai conseguir. Aí você fala assim, não, mas se eu pegar, se eu pegar uma IA bem treinada e colocar dentro do lado de um júnior, a minha aposta é que talvez eu possa acelerar o desenvolvimento desse júnior se ele for comprometido intelectualmente. E aí eu gosto disso, comprometido intelectualmente, senão ele vai emburrecer, que a pesquisa do Emet lá usa, né, delega para a gente.

A gente usa o termo terminal burro, né, na computação, que é você passa o poder de decisão e de pensamento para IA, e aí você assume que é uma verdade, sem pensamento crítico, analítico, capacidade de analisar isso. Aí faz essas besteiras, derruba, né, empresa grande fica fora do ar o dia todo. Então Eu acho que isso não se sustenta, tá? É, pelo menos assim, eu acho que tem um potencial de aí ajudar o júnior, mas eu acho também que sozinha a IA não salva esse gap, você entende?

Assim, ela pode acelerar o meu conhecimento, ela pode me trazer um pouco mais de repertório, mas isso fica no raso porque eu não entendo. Pensa assim, ó, Eu sempre falo, né, que médico tu vai escolher para operar teu joelho? Teu coração vai um pouquinho mais arriscado. O médico que estudou, que fez residência, ou que aprendeu com a IA e já foi logo ali 5 anos? 12 para 5, sou médico em metade do tempo. Você tem 2 médicos, tem umas 2 salas de cirurgia com 2 estilos.

Eu escolho o médico que obviamente saiba usar um robô com cirurgia menos invasiva, mas que tenha 12 anos de experiência. Então a gente não deveria, talvez a gente não consiga ter a consciência, mas a gente, software em muitas áreas, tem mais poder de impacto na vida e no cotidiano das pessoas que o médico. É que ele não é tão evidente. Então eu não colocaria um robô tomar essa decisão, até porque a gente ainda tem muitos problemas nesses robôs.

Mas no curto prazo tem muita empresa tomando essa decisão. Então eu não sei quanto tempo elas conseguem se sustentar por esse caminho, mas eu acho que vai ter que ser revisto sobre alguma proporção.

A minha percepção, né, enquanto servidora pública, que isso vai cair para o setor público resolver. Mas por isso que eu tô perguntando assim as opiniões que Por exemplo, uma ideia, né, é que hoje a gente tem os bolsistas, né, que fazem pesquisa. Então os júniores vão ter que ser sustentados por algum subsídio aí, alguma bolsa, até eles ganharem mais experiência, né. Então você não, não apenas até eles aprenderem. E essa questão dos júniores usarem IA para aprender é o mesmo dilema do uso da IA na educação, né.

Como é que você deixa alguém usar IA sem ter o contexto? Então, que é assim, uma coisa você saber o que que é, o que a IA deveria fazer, né? Aí depois você revisa tudo, você sabe que, como que ela, qual seria a resposta correta, né? Ela fez mais rápida, mas você sabe qual a resposta correta. Aí outra, e eu tive uma da educação aí, para quem não sabe qual a resposta correta, como que ela vai revisar, né?

Então é, eu faço vários testes. Logo que saiu os primeiros modelos de generativa mais acessíveis, Eu fazia uma brincadeira no primeiro semestre com os alunos, que era, eles tinham que copiar a página do Google. Aí eles tinham que copiar a página do Google e era assim, eles contra professora, né? Eu brincava do 7 a 1 lá. Aí tava ficando assim, tava ruim, mas tava bom. E aí em algum momento, dado momento, eles falam assim, mas se tu liberar a IA, dá certo.

Aí piorou muito, eles não conseguiram, virou uma gambiarra assim, ó. E aí destruiu um pouco do simples que eles tinham acertado, né? E aí eu brinquei, né, uma velhinha 71, vocês em IA. Mas por que que eu faço esses experimentos? Aí a gente fez, por exemplo, esse semestre prototipação em Figma mesmo, usando Figma só com prompt e seguindo um protótipo. Primeiro criar um protótipo pensando, desenhando nas paredes que a gente tem na sala de baixa fidelidade, depois pensando num de alta fidelidade, e aí sim melhorando, tentando usar IA e prompt, e fazendo direto com Então a gente teve vários softwares iguais assim.

De cara ele não é feio, a interface é legal, os elementos estão alinhados, mas assim todos com cara de IA. E softwares muito bons que resolviam o problema daquele contexto específico, daquele time. Então eu tento, por exemplo, mostrar para eles essa diferença visual entre você saber, você seguir heurísticas de usabilidade, você pensar, você aprender, você seguir um padrão e gerar um IA a partir desse padrão, né, fazendo o produto Discovery, aplicando, etc. e tal.

Nesse caso, você simplesmente gerar baseado no whatever, que no final fica evidente um trabalho excelente, um trabalho ruim. Mas é muito difícil. Eu acho que a área da educação tem um desafio enorme e O que eu percebi assim, eu não conseguia cumprir com os objetivos da disciplina porque aí leva tempo para você fazer essas reflexões, para você gerar com, depois gerar sem. E antes eu fazia só o modelo, agora tem que fazer os dois, tem que comparar, tem que discutir para fazer sentido, enfim.

E aí eu precisava talvez de 3, sabe, de 2 disciplinas para conseguir cobrir da forma que eu gostaria tudo assim, aplicando e não aplicando, trazendo reflexão. Então assim, a gente tem um baita desafio. E como a gente vai conseguir criar essa conscientização? Mas uma coisa que é posta é: a gente vai precisar trazer à tona discussões como ética e como habilidades básicas, skill básicas, que é pensamento crítico. E assim, não tem como exercitar isso não trazendo isso em modelos práticos, em exemplos, em projetos, interação com a indústria também, né, para trazer reais e mostrar o impacto de quando a gente não usa isso, enfim, para trazer essa consciência.

Mas esse é um momento extremamente desafiador, eu acho, para a formação de futuros colaboradores aí para o mercado. E interessante essa sua visão, sabe, de que talvez hoje para a gente fazer ciência-base é muito escola pública, né, investimento público, né. Então Todo mundo tá aplaudindo a professora Tatiana, é da UFRJ, mas todo mundo fala assim: não, porque essas coisas que ninguém, que não servem para nada. Eu falo: vocês sabiam que ela ficou anos estudando essas coisas que não servem para nada, né?

Para aí a gente ter um futuro Prêmio Nobel e uma descoberta desse tamanho. Então a gente precisa refletir assim, a gente precisa ter um balance entre coisas que são aplicadas para o mercado, que é importante usar aplicar conhecimento científico para resolver problema do mercado. Mas ciência base, você vai ficar anos escovando o bicho para chegar a grandes descobertas, como agora também. Eu li que no Congresso de Medicina Internacional a gente tem um primeiro remédio que aumenta muito as chances dos cânceres mais agressivos, que é o câncer pancreático.

Isso é ciência, né? Isso é tecnologia aplicada, isso é inovação. Então Tem uma questão cultural aí que é uma barreira, eu acho, sabe? E como a gente vai contornar isso ou resolver isso? Eu não diria que não vai ter que ter também esse tipo de investimento assim, não sei, sabe? Assim, eu acho que a gente tem testado, experimentado, mas é um um cenário muito incerto ainda, como a gente de fato vai conseguir endereçar.

Professor, desculpa, Renan, só para mim colocar referente a esse assunto. Eu acho que, na minha opinião, essa parte da não contratação dos júniores pela substituição pela IA é temporário, tá? Porque as empresas estão fazendo isso com o intuito de economizar, só que vai chegar um momento que eles vão verificar que o barato saiu caro, porque eles economizaram, vai sair muito mais caro o fato de não ter profissionais para assumir plenos, sêniores, né, e tal.

Eu não sei quanto tempo isso possa levar, mas eu acredito que vai chegar essa consciência de, pô, a gente economizou aqui, mas agora a gente tem um prejuízo muito maior é por essa falta de formação e tal. E daí as coisas vão começar a mudar, pelo menos é a minha visão. Não dá para adivinhar o futuro, mas pelo menos a minha visão, acho que você é otimista. Eu acredito nisso, entendeu? Porque vai chegar o momento que as empresas vão começar a tomar prejuízo por não ter esses profissionais, entendeu? E o prejuízo vai ser muito grande. Então daí vai começar de volta a mudança.

E aí, até porque também eu concordo contigo. E complementando, é criar modelos de IAs bons para me substituir, digamos assim, custa. Primeiro assim, primeiro tem que ser alguém que sabe criar, né, que tenha conhecimento, que não é trivial, certo? Certo. Segundo, tem um custo disso. Então, se eu substituir todo mundo, vamos supor que eu acertei, que eu consegui criar bons modelos que substituam, sei lá, meu time inteiro, o quão é viável isso no longo prazo, entende?

Por causa do custo mesmo, que ele não é baixo. E a gente tem outras limitações. Depois tem toda a discussão da limitação de hardware, que a gente nem entrou nela ainda assim, né? Mas é outro café aí que a gente tem, outro chimarrão que a gente tem que tomar. Mas eu acho que assim, deve Eu também sou otimista então, né? Não queria, o professor falou assim, mas eu acho que na curva ali da esquina é, o pessoal vai ter que voltar a contratar, até porque custa muito barato.

E aí, adicionando também essa visão otimista, né, outra questão é um ponto que o professor Adolfo também já comentou, né, que a bolha da IA, né? Hoje as IA generativas não são lucrativas ainda. Né? E quando as empresas resolveram começar a cobrar, né, o quanto ela de fato custa, então aí que a conta desequilibra mais ainda também.

Então barato pode ser barato. Começaram já assim um novo invento, né? O Copilot da Microsoft começou a cobrar por token e não por assinatura. Enfim, eu só complementando você, Cristina, que você falou lá a questão, acho que se encaixa nos valores ágeis, né? Indivíduos interações mais que processos e ferramentas, né? Quando a pessoa prefere contratar, entre aspas, uma ferramenta, comprar uma ferramenta, assinar uma ferramenta, até um indivíduo, né, que vai aprender, que vai evoluir, tá indo contra um dos valores lá dos métodos ágeis. Mas passar a palavra para o Renan.

Depois eu tinha, se der tempo, queria fazer mais duas perguntinhas, mas eu povo ficar monopolizando.

Obrigado, pessoal. Professora, são duas perguntas. Em um slide que a senhora colocou ali, fez referência às políticas, né, das empresas serem muito restritivas e tudo mais. Eu pergunto se a senhora vê que isso seria devido ao medo das empresas, especialmente com dados sensíveis, dados sigilosos, propriedade industrial e tá jogando isso dentro das ferramentas sem ter uma certeza de como esses dados vão ser tratados.

É, eu nem vou entrar na parte da regulamentação, né? A gente vai ter altos debates, que eu tenho colegas contra e a favor assim da IA como geral assim no Brasil, mas eu acho que a gente precisa ter políticas. Até porque eu parto do— eu tenho uma frase que eu gosto muito de falar, que é: o óbvio ele precisa ser desenhado. Assim, se tu não tem política, assim, é óbvio que eu não deveria colocar dados sensíveis numa IA qualquer. Assim, em geral, se tu tem uma IA corporativa, tem um limite ali.

Talvez assim uma amostra de alguma coisa anonimizada tu possa usar para trabalhar, etc. e tal, né, que é isso que a gente tem que aprender. Porque eu não tô expondo a informação, enfim, e essa aí ela tem, tá toda protegida por algumas regras aí desse contrato de enterprise. Mas partindo do princípio que o óbvio precisa ser dito, a gente precisa ter uma política e dizer assim, olha, você, se você expor um dado de um cliente importante, você vai ser coautora aí com a empresa se ela for processada, né?

Então, você, eu acho que isso precisa existir assim, essas regras, essas regras básicas, elas precisam ser claras, porque às vezes tem até uma pessoa meio desavisada assim, sabe, meio perdida, vai lá e faz assim, ou até inexperiente assim. Eu acho que até um Um erro grotesco, fácil de uma pessoa inexperiente cometer, porque essa geração ela é tão digitalizada que talvez assim analisar dado para mim é jogar na IA e pedir uma— é o que eu sei, é como eu fui criada, você entende?

Assim é meu dia a dia, não sei o que que é outro tipo. Existe outro tipo de análise, né? Existe um tipo de interface onde eu posso interagir, analisar um dado. Enfim, eu acho que é um pouco também da do mundo. A gente nasce nesse mundo hoje e vive isso como uma verdade. Eu acho que tem que ter algumas políticas. Acho, até ontem eu tava na Tolkien Nation aqui com uma professora de direito e ela trazia muito esses riscos. Acho que do ponto de vista legal Essas políticas protegem muito pouco, mas elas protegem.

Mas os riscos, assim, é quase impossível da gente mapear todos os riscos que eu, de o poder que eu tenho de gerar problema com o uso de IA, né? Só se tu mapear só, pensa assim, então, desenvolvedor de software, tu tem acesso ao código, só vulnerabilidade de segurança que podem injetar, nem sei se eu consigo listar todas elas, quiçá mapear e ter política para proteger. Então eu, eu entendo, as empresas não sabem muito o que fazer, então algumas injetam muito as políticas para tentar controlar.

Mas você vê que os estudos mostram que a gente faz, a gente usa clandestinamente, que assim, eu tenho meu cloud lá, eu uso ele porque eu não vou não usar. E aí entra naquela parte de letramento, que é, a gente precisa criar, que a cultura, no final do dia, a gente precisa investir em cultura que traga essa consciência para as pessoas, que faça esse letramento se a pessoa não tem, tá desalfabetizada, etc. e tal. É porque no final do dia eu não consigo ter total controle sobre isso.

Então a política, ela, eu acho que até para tu falar para o teu cliente, sabe, pensa que eu vou ter o meu cliente é um hospital, dado super importante, ou uma fintech, até para esse cliente confiar que eu tenho rigor em termos de compliance, legal, etc. e tal. Eu preciso dizer que eu tenho uma política. Só que se essa política for indiscriminadamente de monitoramento, ela falha por princípio assim, principalmente nessas áreas que até o pessoal tava brincando, né?

Na Índia tentaram regulamentar o Bitcoin, eles saíram da Índia, não tem como rastrear, né? É descentralizado. Então é um pouco isso, né? Se tentar falar assim, não use, não vai funcionar. Mas eu teria algumas políticas desses casos que a gente já sabe que não pode assim, mas tentaria criar mais bons exemplos de como usar, como usar eticamente, pegar profissionais sêniores que eu tenho, sabe, e que estão usando como um, de fato, uma ferramenta, um copiloto ali na, um copiloto, não necessariamente do copiloto, né, mas um copiloto na programação para falar assim, olha, gente, eu usei nesse caso, respeitei essas regras e funcionou.

Eu sou muito esse caminho mais, é que é criar essa cultura de o pessoal ser guiado por IA. Eu tenho dois alunos hoje que eles passaram no processo agora de verão E aí o pessoal cobrava muito, só assim, eles tinham medo de falar que eles iam usar IA, né? Jovens assim, só assim, professora, a gente não sabia se falava que usar IA ou não. E aí eles cobravam muito, mas vocês não tem tempo, não dá para contratar outro dev, não dá para aumentar o time.

Eles estavam forçando para ver como é que eles iam usar IA. Daí eles entenderam, eles falam assim, não, a gente fez um teste lá com a professora, entendeu que dá para usar, mas tem alguns casos aí até os dois foram aprovados. Eles falaram, acho que isso ajudou a gente a ser aprovado. Porque no final do dia, quando eu vou contratar um profissional, eu acho que a gente também vai impactar esse modelo de contratação. Eu preciso entender se eu posso confiar minimamente na ética daquela pessoa.

Isso é um princípio, né, gente? Não é uma habilidade. E aí assim, a gente tem outros desafios também, mas acho que é um Algo que talvez as graduações vão precisar endereçar nas formações, por enquanto pelo menos.

Não, perfeito, agradeço, professora. Eu tinha uma segunda dúvida, acho que essa é mais tranquila. A gente falou um pouquinho sobre dívida técnica e queria, em termos da professora, se ela vê como uma alternativa, falando especificamente de documentação de software, né, que a gente sabe que hoje tem uma certa carência por documentação. Se aí você vê aí como uma alternativa para diminuir essa dívida documentação, pensando em gerar documentação a partir do código-fonte, de alguma coisa já pronta, né?

Se tu for pleno ou sênior, perfeito, perfeito. Ela gera uma documentação muito boa, muito boa. Assim, o português melhor que o meu, definitivamente. Uma estrutura e uma sugestão muito boa. Você precisa fazer pequenos ajustes, mas sempre tem o dia que ela alucina, aquele, aquela parte do software que ela não é adequada, e que se você repetir e aceitar esse tipo de documentação, vira dívida técnica. Você entende? Então assim, se o profissional é comprometido, tem esse conhecimento de entender o que é um bom comentário, o mau comentário, eu acho que ela é maravilhosa porque ela acelera muito isso e ela me dá uma estrutura assim.

Vários testes que a gente fez, ela me dá um comentário muito bom, muito claro, sabe? Assim, quando eu falo que ela tem um português, não é só gramaticalmente falando, assim, a clareza da informação que ela me traz é muito melhor do que eu sozinha pensando e talvez com menos né, muito mais sucinto, muito mais claro e super rápido. Se eu fiz uma função clara, se eu usei nomes claros para as variáveis, enfim, se eu seguir boas práticas de código, o depara é, eu achei fenomenal assim, me surpreendeu como eu comecei a testar.

Mas acho que tem essas ressalvas, depende da pessoa que tá ali aceitando aqueles comentários, da revisão dessa pessoa ainda de fazer esses pequenos ajustes E obviamente mudar quando ela alucinar ou a explicação for muito diferente do que o deve. Mas eu acho que esse, por exemplo, é um ganho claro.

Perfeito, obrigado, professora.

Nada, obrigado. É, o Francisco escreveu: empresas terceirizadas que faturam por contagem de ponto, faturam, né, cobram por contagem de pontos de função, contribuem para dívida técnica? Você pode falar um pouco sobre isso?

Então, eu sempre tive talvez uma limitação de conseguir entender eficiência de pontos de função. Assim, eu teria inúmeras críticas a esse modelo, mas eu sei que por questões de exigência de contratos, né, a depender do fornecedor, você precisa usar essa métrica. E na minha opinião, eu acho que é um daqueles modelos que a gente faz consegue e gera dívida técnica. Assim, a gente faz o que precisa existir. Era como quando a gente ia implementar, sei lá, eu lembro da gente implementar, trabalhava em Recife como gestora de projeto, e implementar o primeiro nível de CMMI lá, ou DMPS-BR, né, que era uma versão brasileira meio que lá, o nível equivalente.

Aí tinha lá um monte de métrica, aí se colocava lá um monte de documentação métrica para dizer que eu cumpria. Eu usava como gestora de projeto aqueles documentos, pô, ficava desatualizado, ficava. Nem tempo de atualizar tudo que eu tinha. E aí eu usava muito mais para gerir o ágil, porque na época lá em Recife eles já eram, usavam muito, eram referência lá, o Porto Digital, nisso. E para mim era muito mais eficiente. Mas o contrato exigia algumas coisas assim, a gente tinha que fazer.

Eu não consigo, de novo, no modelo atual com tanta incerteza, a gente precisa agir rápido, mudar rápido. Isso pode ser, pode ser que alguém me prove o contrário, mas eu não consigo ver ganho desses modelos. E acho que isso contribui para inserir problemas como dívida técnica e outros, tá? Eu acho que ele é ineficiente sobre muitas perspectivas, muitas mesmo assim. Acho que na precificação não faz sentido, Acho que a gente não tem como garantir o que a gente tenta se propor a garantir. Enfim, acho que tem várias vulnerabilidades esse modelo.

Muito bom. Então deixa eu fazer algumas perguntas. Eu sei que a Cristina tem mais duas, né? Então uma pergunta que eu anotei tanta coisa aqui, mas Primeiro, achei interessante que o Eduardo Guerra tava lá, né? Ele já esteve no podcast lá no Fronteiras da Engenharia de Software. A primeira dúvida é sobre a questão se foi totalmente por acaso, se foi bom, se foi ruim, porque foi o XP 2026 numa semana e na semana seguinte o X 2026.

Eu sei que não são exatamente as mesmas comunidades, eu sei que até o XP me parece ser mais assim, o mercado tá mais dentro, né, e o Ixi é maior. Mas como é que foi isso aí? Como é que você descobriu, opa, o XP vai ser uma semana e o Ixi na outra semana?

Isso até foi desafiador para gente, porque, mas isso foi uma sugestão do Steering Committee e da comunidade europeia, que é comunidade extremamente participante e forte, é uma audiência super que prevalece na XP, né? E aí eles comentaram, quando a gente foi para Zúrich, foi a edição— Zúrich não, foi na Suíça, não foi em Zúrich, mas foi na Suíça, edição de 2025. Eles comentaram, poxa, não poderia ser próximo ao ICSI que a gente já iria?

E tinha uma outra conferência também da nossa área Tem um recorte aí da nossa área em algum lugar, só a gente afasta todas, já sai e fica um mês, né, fazendo. E São Paulo e Rio é perto, seria bom. A gente achou uma boa e fez, mas acho que são trade-offs. Então assim, o XP ele tem esse propósito, que até o pessoal que veio para XP, depois eu fui para o, eu não fui no Ixi, mas eu fui encontrar a Caroline, ela me ligou que foi minha coorientadora, dos que é uma das referências de vida técnica, né, foi a coorientadora doutorado.

A gente é super amigo, era família, tava no Rio, a gente foi para o Rio para ver ele, acabou encontrando várias pessoas lá. Tem uma coisa do pessoal que tava na XP e foi para lá, né, até pessoas que vieram, um grupo de alemães que veio pela primeira vez para XP e foi para o IXE, falou assim, nossa, como é diferente, né, porque o FAESP, ele tem esse propósito, você consegue conversar com todas as pessoas. Então assim, você tá ali naquela imersão e esse networking que tu desenvolve é muito riquíssimo, porque você acessa as pessoas e as pessoas ficam ali.

Então o pesquisador sênior, ele tá ali acessível no café, tá nas discussões, sabe? Você tá, eu tava falando sobre de Vila Técnica e algumas das principais referências estavam lá discutindo contigo. Então as trocas são muito ricas, muito ricas. É uma característica. E obviamente tem essa imersão com a indústria. Então tinha o vice-presidente da ThoughtWorks, é, de Londres, que é um brasileiro também, mas tava aqui. O diretor da Google, né.

Então assim, tinha um monte de gente muito forte da indústria também, muito experiente, né. Então XP é uma comunidade mais fechada, muito experiente. Então a gente tem poucas pessoas que não são sêniores lá do mundo todo com essa conexão de indústria e pesquisa. É, o ICSI é um monstro, né? O ICSI, eu lembro que uma vez eu fui na Filadélfia, eu queria encontrar a Mary Shaw, eu fiquei 5 dias perseguindo a Mary Shaw até que eu consegui tirar uma foto com ela, sabe?

Assim, é muito grande, você não, difícil você achar as pessoas, tem muito, é assim, Conferência fenomenal, não tem nenhum, né, não é um demérito, são características diferentes. Então a gente fez. E aí é um trade-off, Adolfo, porque a gente no XP fez um esforço enorme para reduzir os custos, que foi um challenge para a gente equilibrar esse caixa depois, né. Mas a gente trouxe, talvez quando tu vai no exterior é 1.200 euros, francos, whatever, quase R$10.000 ali muitas vezes, né.

A gente reduziu para R$700 no Brasil, lá em Compra, para viabilizar. Só que imagina assim, para o mercado eu acho que fica viável. Para academia, um professor que foi para o Wix, como é que ele vai priorizar as duas, né? Então vários colegas falaram assim, poxa, ainda se fosse no outro mês ou daqui 2 meses, talvez eu conseguiria pegar uma verba, né, até me recuperar, se eu mesma pagasse. Então eu acho que acaba tendo um impacto, né?

A gente fez muito um esforço para priorizar a comunidade brasileira porque a gente faz muita coisa boa e a gente queria mostrar isso para o mundo. A comunidade europeia já vem em peso, né? Estados Unidos veio, Europa veio, vários outros lugares de pronto. Eles sempre vão, eles vieram, mantiveram essa tradição. Mas acho que se não tivesse sido tivesse sido perto do ICSI, o trade-off é que a gente teria mais, mais pessoas no Brasil teriam acessado, sabe?

Mas essa é a minha percepção assim, acho que não dá. E ainda tem assim hospedagem em São Paulo é caro, né? Não é trivial para a gente sustentar duas semanas viajando e pagando caro uma conferência, né? Então, porque ele cumpriu o aspecto de quem veio, muita gente muita gente do exterior, isso facilitou, e eles foram todos para o ICSI. Mas talvez tenha impactado, assim, é uma reflexão que eu tenho feito, né, o acesso à comunidade brasileira, principalmente científica.

Certo.

E aí outra pergunta rápida: como é que foi a questão da comunicação do XP 2023? 2016, que eu vi que eu não lembro se tinha no Instagram. Eu sei que acompanhava no LinkedIn e foi ótima. Quem vocês contrataram? Empresa? Como é que foi feito aquilo?

Não, a gente, a versão da Suíça, então a gente tinha várias experiências. A versão da Suíça tinha uma empresa que dava um suporte, foi muito eficiente. A gente pensou assim, não, É um custo a mais. Então os influencers somos nós, né? Mas a gente conseguiu o apoio de alunos, da professora Sabrina da PUC-POA, um aluno do IME também. Então a gente foi dividindo os sharing. Então a gente tinha para web, para mídias sociais. Então tentou dividir um pouco o esforço porque todo mundo tem muita coisa para fazer.

E através disso tentou ir direcionando esse planejamento da comunicação. Mas eu poderia ter compartilhado várias coisas que podem ser melhores, que eu até compartilhei agora com o pessoal de Tampere, sabe, para a gente ser mais eficiente e tal. E até brinquei com o pessoal, olha, pode já colocar aí no futuro, no futuro que eu preciso dar uma descansada, uma próxima vinda ao Brasil, que agora eu sei fazer muito melhor, né. Mas é sempre assim, né.

A segunda vez vai fazer muito melhor. Então, e também a gente entendeu que o one-to-one, que a nossa rede, assim, o nosso nome de cada pessoa que tava envolvida, né, cada chair, que o chair tem um peso muito grande. Então quando eu mandava para pessoa, a pessoa falava, poxa, vou considerar. Senão às vezes era mais uma propaganda, né, porque também a gente hoje é muito bombardeado. É, mas a gente usou essa estratégia. Eram alunos de doutorado do IME e da PUC-POA, com apoio nosso dessas comunicações, ou até acesso tipo a grupos que a gente tá de pesquisa, né, o grupo da SBC, de outros grupos.

No one-to-one a gente viu também que teve uma conversão boa em termos de registro, a pessoa submeter trabalho quando a gente confiava diretamente. Que é um, que no final do dia são muitas mensagens que você precisa enviar, né?

É verdade. Cristina, você quer fazer mais uma pergunta e depois eu faço uma para terminar?

Eu vou falar aqui as duas. A professora Scott, que ela vai falar, não tem a ver com aquela questão da governança, da governança, né, da uma política inteligente das próprias empresas. Como que fica se ela conhece algum caso? Você conhece, professora, algum caso de accountability, boas práticas, né? Então, uma vez que você tem aquela política, como que você garante que aquela política tá sendo de fato seguida, né? E a segunda pergunta é que você falou do impacto social, né?

É uma frente que eu tô tentando abrir também. Que é o impacto social do uso das tecnologias, né? No caso de cidades inteligentes, tem vários estudos que mostram, né, que o avanço das cidades inteligentes tá aumentando a desigualdade, né, a iniquidade.

Por quê?

Por causa dos idosos, daqueles que não têm acesso à internet e tudo mais. E no caso da IA, eu também fico assim, como não sei se você conhece alguns indicadores coisas que possam também acompanhar essa evolução, né? Porque, como você mesmo colocou, a gente precisa de dados para poder justificar mudanças na política. E aí eu tô envolvida numa política chamada Plano Brasileiro de Inteligência Artificial, que é o PBI. E o slogan do PBI é IA para o bem de todos.

E aí, como é que a gente garante que é para o bem de todos mesmo, ou se a gente tá e tal, se a gente tiver aumentando a desigualdade, na verdade, enfim, a gente precisa rever algumas coisas, né? E hoje isso, a gente tem muito mais indicadores de os tradicionais, né, de uso, de adoção, né? Mas a questão dos impactos sociais e ambientais ainda tá um pouco iniciantes, né? Você tiver alguma?

Tá muito legal. Bom, eu vou deixar essa, é difícil Começar pela outra, que é a governança. Então, a governança, a gente tem muitos bons exemplos de como fazer isso. Eu vou dar um exemplo bem rápido aqui que a gente usa no Insper. No Insper, quando começou esse boom de proíbe, não proíbe, o que que o professor faz, não faz, incentiva o professor a não usar, não usar, a gente criar um comitê de IA. E uma coisa que funcionou muito bem e que não é uma novidade assim, que grandes universidades lá fora já seguiam, e a gente tava monitorando essas boas práticas, é comunidades de prática.

Então as comunidades de prática, a gente acelerou essa troca tanto dos meus desafios e falar assim, poxa, gente, sabe, os alunos, acho que fizeram essa prova, eles tiraram 10 porque eles usaram IA. Eu não consigo nem saber como é que eu começo a mapear, o que que eu volto para o papel, não volto para o papel. Enfim, todos aqueles dilemas do professor. Então eu conseguia compartilhar, entender como os meus colegas estavam lidando, e até ver se a percepção era a mesma.

Então vamos migrar para o papel, por exemplo. Mas também conseguia ver que um colega tinha uma prática bem legal, que embora uma área uma coisa totalmente diferente eu podia aplicar na minha. Então a gente começou a criar essas comunidades de práticas para compartilhar cases e boas práticas dos colegas, mas também para compartilhar dilemas e entender como a gente drivava essas discussões e decisões. E a gente, e a partir dessa imersão, a gente via o que podia ser uma diretriz institucional sem tentar engessar, porque a gente tem economia, tem computação, Nossa, o mundo é sob muita perspectiva diferente.

E aí faz, bom, isso aqui talvez faz sentido ser uma diretriz geral, né, uma diretriz institucional. Isso funcionou muito bem. Isso é uma prática mundial que universidades todas usaram, que eu conheço assim, universidades top tier. E aí, mas tem muita coisa já saindo. Depois você me mandar, eu eu posso buscar, que se eu não me engano até a gente tem um repositório dessas boas práticas aqui, que a gente tá sempre, tem um time que tá sempre monitorando e tal.

Eu posso compartilhar contigo e também posso compartilhar ali na comunidade e pedir, com certeza o pessoal tem. Quanto ao outro de impacto, eu acho que Tem muitos desafios, mas vejo, vejo algumas evoluções em termos de métricas para mensurar, algumas clarezas. Acho que a gente tem boas métricas hoje que podem nos ajudar a mensurar, mas a gente precisa começar a coletar esse dado. A gente não coleta esse dado. Acho que a gente tem um desafio que é o gap do dado.

Desse impacto. E para isso você precisa olhar para essas vulnerabilidades. Eu acho que a gente tem a métrica, em alguns casos a gente até tem o dado assim, mas esse dado ele tá desorganizado, ele não tá categorizado, ele não tá sendo olhado, né? Ele tá lá meio que existente, mas ele precisa ser melhor talvez estruturado ou até considerado e melhor mensurado, se eu conseguir planejar antes, né, de pegar o dado. Então Eu acho que a gente tem evoluído, mas eu acompanharia a Jutta nessa área.

Ela tem discutido muito, Jutta Einstein, ela tem publicado muito. E em algum momento eu posso até criar uma ponte para você conversar com ela, porque ela é uma super renomada assim, né, na Europa, uma consultora muitos anos, uma alemã respeitadíssima. E ela é tem olhado para isso faz um tempo e ela tá na indústria, tá? Então acho que ela, ela tem assim, vai ter cases reais muito bons e muito claros para você replicar. No Brasil, eu, que envolve tecnologia, eu não sei, mas vamos conversar também.

Não sei assim de pronto, não tô acompanhando, tá? Mas deixa eu até anotar aqui, deixa eu só copiar teu email aqui para garantir que eu fico com ele. Mas, por exemplo, o Insper tem um centro de sustentabilidade que também tem alguns pesquisadores. O professor Gustavo Macedo é uma referência. Eu vi que agora ele foi lá para Londres estudar esses aspectos. Eu posso também fazer essa conexão, ele é super acessível. E tem um projeto que eu tô submetendo agora com pesquisadores do mundo inteiro, que é para a gente mensurar como a gente usa, resumindo, né, IA estrategicamente em comunidade empreendedora de comunidades vulneráveis.

Então, se tu tiver interesse também em contribuir com esse estudo, a gente pode. É um projeto que a gente tá desenhando ainda, tem gente que vai estudar a Índia, assim, um estudo bem grande. Tem um pesquisador, o Isla de Londres, também que olha um pouco sobre essas perspectivas. E a gente pode conversar, mas, por exemplo, eu vejo estudos surgindo para mensurar isso tanto cientificamente quanto em termos de mercado, até para sustentar teses de investimento, etc. e tal.

Mas acho que ainda a gente olhou pouco para isso, sabe? Agora a gente precisa considerar mais isso, mas tem, tem as barreiras que investimentos em sustentabilidade existem, né? Assim, comumente tem, que não são triviais.

É porque a gente puder conversar um pouco mais sobre isso. Isso eu agradeço. Obrigada.

Perfeito, muito bom. Então vamos nos encaminhando ao final. Só queria dar umas palavras finais assim, várias coisas aqui que eu poderia ter perguntado ainda, envolvimento que você tem aí com empreendedorismo, questões de mulheres na computação. Eu vi até que você fez parte de um grupo chamado Emílias, que eu provavelmente não tem nada a ver com a Emília Monteiro Lobato, né? Mas o que o nosso aqui na Alta FPR tem a ver com a Emília do Monteiro Lobato.

Legal.

Não sei se é tão uma boa referência, né, que o Monteiro Lobato, enfim, foi meio cancelado nos últimos anos. Mas enfim, a gente não, a gente só usa a bonequinha mesmo como exemplo. Você falou que você não conhece pessoas da computação que não usam IA. Eu conheço várias, talvez seja minha bolha, né? Recentemente até teve uma entrevista do criador de Zig, que é uma linguagem de programação. Ele disse que é um projeto open source.

Ele disse que no projeto dele, se a pessoa disse que usou IA, ele não aceita o pull request, né? E eu entrevistei ano passado o Brujo Benavides, Mackenzie Morgan, são duas pessoas desenvolvedoras Erlang que dizem não usam IA. Eu conheço várias outras assim de redes sociais. E aí eu também fico assim meio, os alunos sabem aqui, mas me viram falar aqui em outros momentos, quando o pessoal fica falando assim ética, sustentabilidade e LLM tudo na mesma, tudo junto, eu fico pensando, como assim sustentabilidade com LLM?

Tá gastando um monte de energia, tão construindo data center no mundo todo, qual é sustentabilidade? As empresas que tinham, ah não, daqui a não sei quantos anos vamos ser carbono zero. Eu ouvi isso hoje no podcast, que eles tinham uma promessa de ser carbono zero e não sei quantos anos eles cancelaram essas promessas, né, porque eles sabem que não tem como prometer isso, porque enfim. E também essa questão da ética, o que mais me preocupa na verdade na questão ética não é nem tanto a questão da ética no uso da IA, que claro é uma questão importante, né, questão de, opa, uma coisa é o aluno usar o aluno ou profissional para, pensando assim, aluno, né, que é o nosso contexto, para fazer o exercício.

Outra coisa é para ele interagir com LLM para ser ajudado para resolver o exercício. Mas o que me preocupa mais com a questão, na questão ética, é a questão, por exemplo, dados roubados, né, que eles simplesmente pegaram tudo que tava no GitHub, na internet, arte e tudo mais. Tem a questão dos trabalhadores de dados que ficam em algum lugar do mundo. Agora tem até vários nos Estados Unidos. Saiu recentemente um vídeo no canal da Karen Hall, quer dizer, o vídeo é da Karen Hall, mas o canal não é dela, que é autora do livro Império da IA.

Por sinal, até acabou de ser lançado, acho que dia 30 de maio, em português, o livro Império da IA.

Legal, não sabia.

Boa! Vendeu muito lá em inglês, né? Empire of AI. E agora lançaram, é só a terceira língua, até onde eu sei, que ela divulga nas redes sociais, é só a terceira língua ter a tradução. A primeira, não, é a segunda língua ter tradução. A primeira foi inglês, depois espanhol, e agora português brasileiro. E você falou da Carolyn Simon, no canal do Fronteiras de Engenheiro de Software a gente fez uma live com a Carolyn.

Ai, que legal! Essa eu não vi. Eu já vejo, eu já acompanho algumas, sempre que eu posso eu vou ouvindo. Mas essa eu não vi.

É que essa não foi exatamente do Fronteiras, foi lá do, como é que fala, Escola de Estudos Experimentais em Engenharia de Software, nome longo. Foi um evento dentro do ICSI que tinha uma parte online antes, uma parte online depois. A palestra dela foi já depois do ICSI, foi bem legal. Ela é uma lenda, né, em estudos qualitativos aí, super influente na na engenharia de software. E aí eu queria fazer para você uma pergunta. A gente nem tinha combinado isso, mas eu acho que diante de tudo que você falou, você está mais do que preparada para responder isso, que é uma pergunta que a gente faz no podcast, no Fronteiras da Engenharia de Software.

Eu gosto sempre de lembrar as pessoas que não é, não espera que a pessoa preveja o futuro, até porque é impossível, né? Eu gostei que você usou a palavra premonição, né? Né, mas que você, alguma coisa que você acha que vai acontecer, o que você gostaria que acontecesse na nossa área. Então, para você, Graziella, qual é a próxima fronteira da engenharia de software?

Deixa eu abrir a minha aqui. Não, tô brincando. É a próxima, a próxima fronteira E eu assim, eu tenho pensado muito sobre o futuro, mas eu acho que a gente vai mudar completamente a forma de fazer software, completamente assim, ao ponto de, né, a gente fala assim, poxa, pensa um dia se eu falasse Se usasse linguagem natural para criar um produto. Hoje a gente chegou nesse, que eu acho fenomenal acompanhar essa mudança, né? Chegou nesse momento que a gente pode usar a linguagem natural.

Então eu acho que o grande desafio da engenharia de software é garantir Eu não sei se é prepotente isso, mas é garantir que— e eu acho que a gente, esse vai ser um pouco o nosso poder, mas o nosso desafio também, que é garantir que os produtos e serviços futuros impactem positivamente no mundo. E o meu desejo é que a gente use todo esse conhecimento poderosíssimo que a gente tem para construir um mundo mais equitativo, assim, que essa linguagem natural ela tenha também um tom feminino.

Acho que aí, se eu olhar para, se eu chegar no meu 150 anos, né, a ciência tem que evoluir aí, né? 150 anos e olhar para que eu tô, né, tem que ser Tem que ser pragmática aí. E eu olhar e ver que a gente mudou isso, né, que a gente não tem mais, que alguém olhe para mim, que uma guriazinha lá fala assim, cara, por que tu falava nisso? Porque tem um tal que deu aqui de 2500, de 1500, que você falava desses assuntos, nada a ver isso assim.

Se hoje a gente faz sabe, que cria o meu produto, meu software, é simples, é fácil, a gente conseguiu equilibrar muito impacto no mundo de forma, né, que isso pareça inconcebível assim. Aí eu posso dizer que a minha missão ela foi cumprida. Eu acho que a gente na área de engenharia de software, que é a parte que vai pensar, estruturar e também garantir um pouco essa o impacto e a qualidade, tem um baita poder em drivar isso. Muito bom, bem preparados.

Muito bom, muito obrigado, Graziella. Este é um episódio da Rede Emílias de Podcasts, que é uma iniciativa dedicada à divulgação de conteúdos relevantes nas áreas de tecnologia, ciência da computação e engenharia de software, com foco especial na diversidade e inclusão. Esta rede abrange 5 podcasts distintos, cada um com seu propósito único, com audiência dedicada, e esses podcasts fazem parte das atividades de divulgação científica e extensão do Programa de Pós-Graduação em Computação Aplicada, PPGCA, da Universidade Tecnológica Federal do Paraná, UTFPR, no campus Curitiba.

Esta rede está associada ao programa de extensão Emílias Armação em Bits. O coordenador da rede Emílias de Podcast é o professor Adolfo Neto, sou eu, e a coordenadora do programa de extensão Emílias Armação em Bits é a professora Maria Cláudia Emmer. Estamos nas redes sociais, principalmente nos perfis pessoais. Eu estou no Blue Sky, em @adolfoNT.github.io. Estou também no LinkedIn, Adolfo NT. O Emílias tem um perfil no Instagram, emilias_otfr.

E o Fronteiras tem também um perfil no Instagram, FronteirasES. São as redes que a gente procura mais atualizadas. Mas claro, se você não quer nos seguir em nenhuma rede social, você pode simplesmente nos seguir nos aplicativos de podcasts como Pocket Casts, Apple Podcasts, Spotify. É só procurar pelo nome do podcast e clicar em seguir. Ou no YouTube, onde também nós publicamos nossos episódios. De novo, é só procurar pelo nome do podcast e seguir o canal.

Só não no caso do do Emílias, que no caso do Emílias Podcast Mulheres na Computação você tem que seguir o canal do Emílias Armação em Bits. É isso, pessoal, até o próximo episódio da Rede Emílias de Podcasts.