ep19 - Design & Código: Quebrando os silos na construção de produtos

Oi pessoal, bem-vindos ao Design da Liderança. Mais uma semana falando de assuntos super interessantes por aqui e hoje o meu convidado especial é o Renato Holanda. Renato, seja muito bem-vindo a esse espaço, fica super à vontade para se apresentar, fala um pouquinho de você e vai na frente.

Boa, obrigado Carol, obrigado pelo convite. Primeiramente, acho que esse é o primeiro podcast que eu tô participando, eu nunca participei disso. Assim, então tô um pouco nervoso, mas bom, sou o Renato, sou desenvolvedor front-end e já atuei na parte de liderança. Falando um pouco do Renato fora do profissional, sou cearense, moro em São Paulo há 10 anos e eu sempre trabalhei com front web. Vim para São Paulo inclusive numa oportunidade para trabalhar aqui Eu sempre gostei muito também de estudar essa parte de design, então nunca fui preso simplesmente ao código.

Tô ali acompanhando questões de design e usabilidade para poder entregar melhor o que eu faço.

Mais uma vez, seja muito bem-vindo. E bom, eu queria muito trazer alguém de engenharia para conversar, porque eu acho que tem uma treta aí que todo mundo fica falando, que existe uma rixa de design e engenharia, que é muito mentira. Na realidade, a gente tem que estar cada vez mais próximo. E queria começar puxando esse papo, falando um pouquinho sobre e pedindo para você também colocar sua visão, assim, como que você tá vendo a relação hoje de design com engenharia?

O que que você vê de pontos de comunicação, coisas que poderiam melhorar? Traz um pouco do seu ponto de vista aí como engenheiro.

Boa! Eu já começo dizendo que eu discordo também, tá? Eu sempre estranhei de fato isso nas empresas que eu chegava. E que eu notava um certo gap ali entre design e desenvolvedores, eu sempre ficava me perguntando o porquê. Porque no meu ponto de vista não é um trabalho que cada um entrega o seu, é uma entrega em conjunto sempre. E no final quem ganha com isso é o cliente. Então não tem por que eu ficar brigando por uma entrega de— vamos supor, eu sou design, eu tenho que estar brigando pelo design que eu quero final.

E eu sou dev, eu tenho que ficar brigando pela facilidade que eu vou ter de implementar. Isso não deveria existir, deveria sempre convergir. E nas empresas que eu passei, já tive sim alguns probleminhas com designs, mas quando os pontos que eu tive sempre foram em relações a Eu tenho um design system, eu tenho já alguns componentes feitos, e por que que eu não tô utilizando eles? Ah, por que que eu não tô— vou fazer uma tela de teste, por que que eu não tô utilizando o que eu já tenho pronto?

Por que que eu vou criar um novo componente para um teste? Tudo bem, tem casos que vai fazer sentido, mas eu acho que esse exercício é para ser feito sempre, sempre pesar o quanto vale a gente fazer algo novo versus o que vale a gente reaproveitar o que já tá feito. E muitas vezes até esbarra na questão da usabilidade, como eu comecei falando, que eu gosto muito de estudar, porque quando você olha questões visuais que vai mudar muito a forma que o usuário lê o seu layout, e que sim, de fato, se você usar o que já tá pronto, muda completamente a interação do usuário com aquele sistema.

E uma vez que a gente utiliza o que já tá pronto, Isso vai dar outra vida para a entrega. Então, quando a gente pesa isso, eu sinto que tem os dois lados. Literalmente, tem o dev querendo implementar aquele componente que já está pronto, porque para ele vai ser a entrega muito mais rápida. E também tem um designer lutando ali pelo que ele acredita de entrega final. E aí eu sinto que o gap começa aí, tentar entender um pouquinho cada um do lado do outro para poder chegar num denominador comum.

Muitas empresas acontece disso, de ficar nesse, não, eu quero isso daqui, não, mas esse daqui já dá problema, não, mas eu quero isso daqui, e fica nesse embate e não converge, sabe?

Sim, todos os lugares que eu trabalhei, assim, desde que comecei a lidar com engenharia, eu tinha duas preocupações enquanto designer. Que a primeira era um pouco essa sua motivação de entender visibilidade, a minha era de entender do código. E aí eu acho que tem também um pouco dessa problemática da Richa, que é: o designer precisa codar? Ele precisa saber tudo sobre código? Eu não acho que tem que saber tudo. Na realidade, eu acho que a gente tem que entender a lógica de como funciona, porque até para fazer direcionamento como esse que você falou, de tipo: ah, esse componente já existe, isso vai facilitar o desenvolvimento.

Esse, isso aqui é um legado, vai demorar mais tempo para eu implementar, ou isso aqui é uma coisa muito nova e vai precisar de um discovery no passo da engenharia. Eu acho que compreender esse tipo de coisa ajuda também na relação. E uma coisa que eu ia comentar, que sempre fiz, foi tentar envolver a engenharia no momento da pesquisa. Eu acho que também fica muito mais fácil para vocês entenderem, é a minha percepção, quando vocês entenderem as motivações do porquê que aquilo está sendo feito.

Quando vem só um negócio desenhado, quadradão, você fica assim meio pego com as calças na mão, tá? Por que que isso é relevante? Eu quero fazer mais rápido porque o business tá me esfremendo. Então por que que eu preciso brigar com isso junto com você, né? Como que você vê assim essa relação? O que que tem funcionado em termos de troca com designers do momento que você entra para você conseguir entender esse passo a passo?

Boa. Eu sou suspeito para falar exatamente desse ponto de pesquisa, porque eu gosto de participar disso. E eu sei que não é todo mundo que gosta ali de entender, ah, como é que foi feito o teste com usuário, como é que não foi, essas coisas. Tem pessoa que prefere ir já a partir do momento que você já fez o discovery e vai começar a de fato montar a tela. Só que eu gosto de participar disso Porque ele vai trazer muito mais insumos para mim, até na hora de ponderar isso do código.

Vamos supor, para eu entregar um componente que já tá pronto, eu vou levar 2, 3 dias. Ah, para fazer um componente novo, eu vou levar, sei lá, uma semana, duas semanas. Então, quando você olha para isso, faz muita diferença você ter entendido a motivação ali por trás. Eu sei que na maioria das vezes o designer ele vai trazer ali o resultado da pesquisa, mas para mim é diferente você só ver os resultados versus você participar do que foi perguntado, sabe?

Por exemplo, aqui no iFood eu já participei de algumas entrevistas direto com cliente, que eu participei de fato, eu fiz perguntas para o cliente. E não foi algo que era só design perguntando. E se complementa porque são visões diferentes. E tem um ponto crucial para mim que eu sinto que é diferencial olhando por parte do desenvolvedor, porque eu acredito que o designer ele já vem com isso, digamos assim, naturalmente. Aí das pessoas darem a opinião delas como usuário.

Tem sistemas que eu uso assim, eu falo, gente, não é possível que o dev que entregou isso daqui ele gostou dessa usabilidade, sabe? Então eu fico pensando, gente, dê a opinião de vocês, sabe? Tipo, ah, eu não gostei da forma que essa informação ficou disposta, ah, eu não gostei desse botão aqui, sabe? Um teste muito besta que eu faço Vou abrir a tela no mobile, uso com uma mão só. Onde o meu dedão alcança, o que é que eu consigo, o que é que eu vou precisar fazer ali?

Ah, eu vou precisar sempre estar com as duas mãos? Não vou, sabe? É uma questão besta que quando você começa a fazer, exercitar isso, você vai vendo, não, isso aqui faz sentido, isso aqui deveria ser assim, isso aqui hoje tá errado, então assim, a gente vai ter que fazer um novo.

Sabe?

E aí você começa a ter mais entendimento. E teve um ponto ali que você comentou, que foi a questão de que você sentia necessidade de entender um pouco mais da lógica. Eu não diria nem da lógica, eu acho que eu diria do que envolve eu desenvolver um componente novo. Então, com o exemplo do projeto que eu trabalho hoje, Eu tenho que estar pronto e se eu vou codar e criar um componente novo, eu tenho que não só criar o código desse componente, como eu tenho que criar os casos de teste desse componente, como eu tenho que gerar a versão dele para o Storybook, gerar as histórias dele lá no Storybook.

Então não foi simplesmente codar o componente e entreguei, eu tenho mais coisas além disso. E uma das coisas que eu reforço muito é questão de reuso, entender. Beleza, a gente tá fazendo esse novo componente, mas a gente já tem alguma visão do reuso desse componente? Tipo, esse componente vai atender somente esse cenário ou ele pode atender a mais? Exemplo bem besta foi que a gente tava fazendo uma tela onde tinha cards com informações, tipo um dashboard com informações de operações.

E o design só tinha colocado, é, o card, ele tem um título, valor numérico grande no meio, e no rodapé ele tinha uma informação complementar. E no primeiro momento o design fez só ele vermelho ou verde, essa informação complementar. E aí uma das coisas que eu levei para design foi, tá, mas vamos pensar até em reuso desse componente. Eu sei que a gente não tem isso agora, mas no código isso vai mudar pouca coisa para eu implementar.

Então eu consigo, quer que eu já deixe disponível aqui o texto auxiliar amarelo, uma cor neutra, quer que eu disponibilize aqui sem essa informação embaixo, quer que eu disponibilize com ou sem o chip. Para ter já esses cenários montados, porque quando vier novos casos de uso eu não preciso voltar no código e incrementar. Eu já estressei alguns cenários que são possíveis, eu não tô viajando, eu não tô inventando cenário, sabe?

Então essa hora do desenvolvimento vai impedir que lá na frente eu queira criar um novo componente só porque o componente que tem Ainda tá faltando 2, 3 cenários, sabe?

Super interessante você falar isso. Eu, a gente, esse podcast tá sendo gravado num momento específico, semanas atrás desse momento, o CDO da Nubank fez uma pergunta no LinkedIn falando sobre como que as pessoas medem produtividade de design. E eu achei uma pergunta super interessante e eu rodei a IA nos comentários para poder pegar, tipo assim, highlights, porque um monte de gente comentou. E uma das coisas que eu achei muito legal na ponderação que foi trazido é que a galera entende como produtividade o não gasto de energia à toa.

Então, o quanto que design conseguiu olhar para um serviço, para um design system, e evitar que o negócio perdesse dinheiro fazendo alguma coisa. E eu acho que nesse ponto é um trabalho muito conexão de engenharia com design, porque eu acho que não é uma responsabilidade só do designer ser essa voz, esse embaixador dessa preocupação, né? Eu acho que os engenheiros também têm que trazer isso, porque no fim do dia isso é uma preocupação, essa coisa de espírito de dono é um pouco isso, né?

De, cara, quanto de dinheiro a gente vai jogar fora se eu construir uma coisa agora que atende a 2 cenários, eu posso construir uma resiliência eficiente que atende a 50. Apesar de não ser uma métrica que a gente consiga acompanhar diretamente, que vai lá bater diretamente no ROI da vida, a gente está se preocupando com investimento de tempo, dedicação da pessoa ali naquele momento. Muito interessante você trazer isso, porque eu acho que é uma responsabilidade compartilhada, é algo que tem que ser visto e todo mundo tem que ter essa visão crítica quando está sendo discutida alguma coisa.

Para você não ficar produzindo lixo, porque você acaba gerando um troço que você tem que derrubar depois para fazer de novo, né?

Perfeitamente. Quando— até agora eu vou te fazer uma pergunta também, Carol. Eu tenho um pensamento que eu queria saber se você já passou por isso, se você em algum momento sentiu isso, que é o quê? Muitas vezes eu acho, eu sinto que é como se quando o design chega com uma coisa pronta e eu começo a meio que podar algumas coisas ou meio que mudar o rumo, eu sinto que eu tô meio que julgando o trabalho do designer. Eu sei que, claro, tipo, no ambiente corporativo isso não deveria ser um pensamento, mas obviamente somos pessoas e sim, eu sou uma pessoa que me preocupo com o que a outra pessoa também vai sentir com isso.

Algumas vezes eu sinto que design, ele sente mais valor na entrega quando ele cria algo do que quando ele junta peças que já existem e faz essa entrega. Para ti, teve esse sentimento em algum momento? Esse sentimento é um pensamento válido, digamos assim? Chegar à conclusão?

Eu acho que você toca numa ferida real quando você fala sobre isso. Eu acho que a sistematização, na verdade tem dois assuntos atrelados a essa pergunta. O primeiro é, eu acho que tem um ponto muito importante sobre amadurecimento emocional de você entender que você não é o seu trabalho. Então o que eu vou construir precisa estar aberto o suficiente para outras pessoas criticarem, porque no fim do dia o somatório da visão técnica de um PM, um engenheiro e de um designer é que faz um trabalho relevante até de outras áreas, né, que estão envolvidas ali naquela entrega também.

Então, eu acho que isso precisa ser trabalhado para que a pessoa não entenda que aquilo está sendo uma crítica direta a ela, mas sim é uma construção em conjunto. E eu acho que tem um outro ponto que é a sistematização de design, ela ajuda muito a você ganhar escala na empresa. Quanto mais o designer consegue fazer com que as telas saiam de uma maneira mais fluida, mais tempo ele tem para olhar para a inovação, para pesquisa, Mapeamento de novas oportunidades.

Então é uma coisa super positiva, mas construir do zero traz um pouco daquela sensação da arte, sabe? De você ter algo que é seu, com a sua cara. Só que a gente tem que parar de trazer isso, porque no fim do dia aquela tela aí que está sendo construída vai ter sempre a sistematização do branding da empresa, do direcionamento técnico de um grupo de design que está definindo aquilo em conjunto. Mais uma vez, é um apego que está muito mais relacionado ao seu ego do que se é algo que tem a sua cara, a sua assinatura ali, sabe?

Então acho que para um designer que está fazendo um projeto que é artístico, que é um site que vai ser uma landing page ali e que vai ganhar um prêmio, é uma coisa. Agora, outro completamente diferente é estar no dia a dia ali, que você está muito mais focado em assertividade, numa entrega que faça sentido para o negócio. Então eu realmente vejo uma diferença, mas acho que tá muito atrelado a esses pontos assim de melhoria, sabe? O que que você tem visto quanto a isso? Qual sua visão como engenheiro?

Assim, do meu lado como engenheiro, uma das coisas que eu tenho dificuldade assim de ponderar exatamente nesse aspecto do design veio com uma coisa nova, E eu tenho uma pronta que muita pode até tipo não ser, não vai trazer a mesma experiência do que foi desenhado, mas uma coisa que me faz pesar muito é o objetivo final daquela entrega. Porque se eu tenho uma entrega que ela tá com prazo curto, se eu tenho uma entrega que ela é um teste para mim raros são cenários onde para um teste eu preciso fazer algo novo, porque afinal para teste a gente tem que fazer o mais rápido que conseguir para ter mais dados e em cima disso fazer de fato, digamos assim, a melhor proposta, sabe?

E aí quando eu olho para essa parte de pesar isso é que eu vou e consigo contrargumentar melhor com design, mas ainda assim às vezes fico com um sentimento de que tá, de que o design pode não tá gostando ali de tá capando a ideia deles. Porém, dependendo do que você trabalha, por exemplo, ah, se você trabalha num sistema interno, no sistema logado e tudo mais, infelizmente eu acho que Esses sistemas não têm tantas aberturas para essa parte de criação, a não ser que você queira redesenhar o componente que tem lá.

Eu acho que tem uma base argumentativa muito boa, né? Tipo assim, cara, eu tenho essa métrica, tenho esse ponto do usuário, porque também não dá para virar tudo de cabeça para baixo e tá tudo bem, né?

Perfeito. Quando, por exemplo, vou dar um exemplo simples aqui no sistema que eu trabalho hoje. Existem duas listagens, dois layouts de listagem, mas ambas são para listar pedidos. Na minha cabeça, deveria a gente estar pensando numa listagem única, um visual único. Tudo bem que umas têm informações antes de separar o pedido, a outra tem informações quando eu termino a separação daquele pedido. E eu acredito como dev, como amante ali de design, digamos assim, que dá para chegar no meio termo e ter uma lista com visual único.

E aí eu acho que é nessas horas que vem a oportunidade de criar algo do zero de fato. No restante eu vou ter que— formulários, botões, dashboards, esses eu não tenho muito espaço para criar. E aí é nesse momento que eu vejo também que O designer, ele precisa entender qual é o objetivo que ele quer de trabalho para saber se cabe a ele querer ficar criando coisas ou se tudo bem para ele replicar e pensar em pontos melhores com o que já tem, sabe?

Eu acho que esse trade-off só fica claro se o designer está envolvido no negócio e está entendendo as motivações do porquê que ele está fazendo o que ele está fazendo. Eu vejo que muita gente fala isso, né? Ah, na hora que vou fazer portfólio para poder entrar para uma empresa, eu devo colocar as telas que eu desenhei? E eu sempre falo que cada vez mais, até com o advento da IA, o que as empresas vão dar relevância vai ser a cabeça do designer e não só o que ele produz enquanto tela no fim do dia.

Porque é o que a gente falou, a tela tem a sistematização, tem as regras de negócio, tem muitas camadas que fazem você acabar sendo direcionado a usar coisas que já existem. Só que a maneira com que você defende o seu ponto, como você vai guiar essa tomada de decisão, isso é que para mim é a assinatura do designer. Se você for trabalhar com designer que tem essa pegada, que tem essa visão crítica, você provavelmente vai querer trabalhar com ele em todos os outros trabalhos, porque você sabe que ele é o cara que vai conseguir te dar clareza e te guiar a entender o porquê das decisões dele.

É muito ruim quando você trabalha com alguém que desenha algo e você questiona e a pessoa não sabe te dizer o motivo e aí entra na parte de negociação, né? Então ela não só não sabe negociar como ela também não tem insumo e aí o que acaba ganhando é muito mais a função, é muito mais a facilidade da velocidade do negócio aqui, né? Então eu vejo isso como um ponto assim bem relevante para a estrutura de atuação de design hoje, né?

E aí até puxar uma outra pergunta para você, que eu acho que falando assim das fases do processo, acho que tem uma preocupação muito grande hoje também com documentação. Eu vejo que o trabalho de design e engenharia rola muito junto durante o processo, mas tem momento que se separa. Então designer ele vai olhar para uma outra demanda Mas a engenharia continua olhando aquela tela. Eu vejo muita gente falando assim, ai, os engenheiros toda hora ficam me mandando mensagem, toda hora ficam me perguntando o que foi que eu desenhei, como é que aquilo funciona.

Eu falo, uai, mas é culpa tua, quer dizer que a tua documentação não tá falando por si mesma, sabe? Eu acredito muito nisso. Aí queria ouvir o teu lado da história. Qual que é a tua visão sobre esse momento em que os caminhos se divergem?

Boa. Acho que essa questão da documentação Ela esbarra perfeitamente com tudo que a gente já conversou até aqui. A gente, meu ponto de vista, quando a gente fala de documentação, a gente só precisa dela quando eu tô fazendo algo novo. Se eu tô entregando uma tela onde ela tá usando todos os componentes do Design System, uma vez que eu combinar todos eles dentro daquela página, vai ficar com o layout que você desenhou. Pode ter um ajuste ou outro ali de meia página, esse tipo de coisa, mas na maioria dos cenários não vai precisar de uma documentação mais trabalhada.

Tem um ponto que eu até vou trazer aqui que aconteceu comigo aqui no iFood, que foi: eu recebi algumas telas um tempo atrás e essas telas, elas eram telas novas E elas não estavam, não vieram com a documentação, dada a celeridade que foi de processo. Não foi nada do tipo, não era o design que não documentou, não, não era, era a celeridade mesmo que a gente tava em desenvolvimento. E foi meio a toque de caixa e a gente acabou recebendo as artes já.

Algumas coisas que eu identifiquei olhando para as telas, eu identifiquei alguns padrões E eu já levei esses padrões para o código. Só que aí entra um ponto de muita atenção e cuidado. Eu estava documentando isso do lado do código, do lado design não tinha essa documentação. E eu fui perceber isso quando vieram 3 telas. Nessas 3 telas vieram pontos novos, digamos assim, no visual. Quando veio a 4ª tela, aí eu cheguei para o design e falei, peraí, tu me mandou essas 3 aqui, dessas 3 eu entendi que aqui tem um título, um subtítulo, um menu lateral.

Uma área de ações aqui no rodapé e eu defini esses padrões aqui no código. Então se a gente for replicar essa página aqui, criar outra página com esse mesmo layout, ela já está pronta. Eu mando o título, mando as ações na direita e já falei, tá isso aqui, isso aqui está documentado do seu lado? Aí ele, não, preciso documentar. E aí foi que as entregas pararam de vir com esse extra. Documentou do lado dele. Então o layout básico teve a documentação feita, e a partir daí, quando ele tinha um ponto novo, aí ele já me sinalizava: eu sei que isso daqui não tem no nosso base, mas eu vou precisar dessa informação aqui.

Aí a gente ia lá e codava essa parte nova. Esse ponto que eu fiz de deduzir um padrão com base em 3 telas que eu tinha recebido, foi bom para o lado do desenvolvedor. O processo não foi, porque enquanto não tem a documentação dos dois lados, então não vai convergir. E aí, olhando também para o ponto que você trouxe da documentação do lado de design para o dev começar a codar, Essa para mim só faz sentido quando eu tô trazendo algo novo.

Eu não preciso em toda tela dizer que o espaçamento interno do conteúdo é 20 pixels se eu tenho um layout base já documentado no Design System. Uma vez que eu usar ele, ele já vai aplicar esse espaçamento. Mesma coisa, acredito que no Figma é assim, né? Uma vez que eu puxo o componente, ele já tem aquelas propriedades, herdou, aplicou, e é isso. Então eu não preciso dessa documentação. Quando a gente fala da documentação em si de uma coisa nova, acho que a gente tem dois pontos.

Um, quando a gente tem um design system, que aí uma vez que a gente usa as variáveis ali de design system, de espaçamento, de cor, os tokens, uma vez que a gente usou os tokens ali, fica tranquila essa implementação. Uma vez que não tem, aí sim eu vou precisar de uma documentação bem mais detalhada, onde fale cada pixel, cada tamanho. Para poder sair o resultado igual. E aí vem um ponto extra que foge da pergunta, que algumas vezes, algumas vezes eu já trabalhei com alguns designers que ele não acompanhava a entrega, ou ele confiava simplesmente no print que eu tinha mandado.

Como também eu já trabalhei com designers que ele acessava quando eu dizia que tava em produção, ele ia lá, acessava e dizia passamento aqui tá diferente do que eu desenhei. E aí você ir lá ajustava, mas de fato tem esse ponto também.

Ai, nossa, quanto designer adoro a ideia de um sandbox para não precisar ir para produção e você poder ver com antecedência. Sempre gostei muito de fazer QA, porque eu acho que essa parte de qualidade, de você acompanhar a qualidade da entrega do desenvolvimento também é super importante, porque é isso, a gente tá trabalhando em conjunto. Então eu posso falhar em algo que você vai ver, como por exemplo isso que você falou, né, do padrão que não foi visto pelo designer.

Assim como enquanto você tá acordando tem um monte de outras coisas para fazer, passa uma coisa desapercebida, né? Ter muitos olhos ali durante o processo é super relevante. E eu que sou dinossáurica nessa visão das ferramentas, O Figma, eu acho que ele foi construído muito nessa lógica do desenvolvimento de você conseguir carregar a documentação. Inicialmente você faz esse investimento de trabalhar bastante tendo que conectar a documentação ao componente, mas depois de um tempo você ganha espaço com isso que você falou, tipo, eu puxo e já uso, né?

Deixa eu fazer uma pergunta derradeira para você, para a gente começar a finalizar aqui o episódio. Inteligência artificial vai tirar o nosso emprego? Designers têm que codar? A gente precisa ficar preocupado? Para um TI existe um desespero também.

A pergunta de milhões, viu, Carol? Mas vamos lá, pensamento do Renato, pessoa física, não ligada a empresa nem nada. A IA, ela veio fazer uma nova revolução industrial. Então a nossa forma de trabalhar, acredito que sim, ela vai mudar e vai mudar bastante. Eu não acredito que o emprego design vai morrer. Por quê? Porque a IA não cria, ela copia. A partir disso, a questão do toque humano ali sempre vai existir no final. O que eu vejo que aí atrás É muita, muita celeridade.

E até um ponto que eu, nos meus pensamentos, eu fico matutando é o quanto essa celeridade vai, até onde ela vai ser saudável ou não pra gente. Uma questão das telas, questão de redes sociais, questões de celular. Você hoje tá sempre conectado, você hoje se sente nu quando o seu celular descarrega, sabe? Você sente meio que perdido, você não vai num aniversário se não tiver no Waze ou não tiver conseguido pedir um Uber, sabe? Então a IA ela vem aumentar mais ainda essa dependência.

E tem pontos que tem uma amiga minha que fala que ela tá pedindo para IA olhar o WhatsApp dela, ver as conversas que estão pendentes, quais são os assuntos. Daí eu fiquei, gente, para mim isso é muito Black Mirror, sabe? E aí, trazendo para nossa realidade de dev, design, dev hoje já mudou muito a experiência de desenvolvimento, muito. Dito para ela um pouco do que eu quero, muitas vezes ela já me entrega o código pronto. Poucas vezes eu tenho que fazer pequenos ajustes no que ela entregou, mas já tá com uma precisão assim absurda.

Acredito que vai morrer o emprego dev? Não, não vai, porque tem outras coisas que com a IA hoje é arriscado de se fazer, é cuidadoso, que o olho humano ali tá acompanhando e tá fazendo e tudo mais. Mas ela veio literalmente mudar totalmente a nossa forma de trabalhar, sabe?

Isso de fato concordo 100% com você. E tem um ponto para mim sobre isso de que a IA vai substituir a gente, é que eu acho que quando a gente fala que uma inteligência que se embasa na reformulação daquilo que já existe vai tomar o nosso lugar, significa que a gente está simplificando o nosso lugar num nível tão superficial a ponto da gente achar que a gente é substituível, sabe? Então, para mim, falar que o designer vai perder o emprego ou que o desenvolvedor vai perder o emprego é você dizer que tudo isso que a gente conversou até agora sobre documentação, adaptabilidade, visão de negócio, senso crítico, tudo isso uma máquina conseguiria reproduzir e talvez ela consiga otimizar coisas que a gente não consegue, que a gente não tem esse poder todo de processamento como você falou, mas eu vejo que é um poder de processamento muito direcionado.

Nós enquanto seres humanos a gente consegue criar relações, correlações entre diferentes que às vezes parecem que não tem, o padrão que você pegou na tela ali, né? Que às vezes parece que não tem essa correlação, mas a gente consegue criar essas conexões. Eu acho que isso para mim é o essencial, é onde mora a criatividade, sabe? Então tô muito na sua também, acredito muito nisso que você falou.

Boa! E tem mais um ponto que eu lembrei aqui, isso é um ponto de preocupação real meu, que é com pessoas que estão entrando na área agora, tipo Quando eu olho para um Deve Júnior, a principal preocupação que eu tenho é o quanto ele vai de fato aprender e absorver. Porque conseguir fazer as coisas, ele vai conseguir fazer numa velocidade assim que eu que tô na área desde 2009 não conseguia fazer 10% do que ele faz hoje em dia. Isso até comparando no mesmo nível, eu, juninho lá em 2009, verso uma pessoa que é júnior hoje, dada a quantidade de recursos e facilidade e tudo mais.

Porém, hoje a IA ela te entrega tudo de bandeja de uma forma que se você não tem a preocupação genuína de ler o que ela te explicou ali, de absorver o que ela, o que ela atuou de fato, a gente vai literalmente emburrecer ele. A palavra certa é essa. A gente vai ter muitas coisas, mas que no primeiro problema a gente não vai saber resolver. E aí isso eu acredito que se aplica todas as áreas que se possam usar o IA. A gente tem que tomar esse cuidado, a gente tem que ter esse autocuidado de aprender de fato, porque se você for só fazendo, beleza, você cresce na carreira, mas você não vai estar aprendendo, você vai estar dependente sempre da IA.

Agora, até que eu brinco, tipo, gente, como é que seria metade de algumas coisas se a IA parou hoje, sabe? Se dá uma panezinha lá no ChatGPT, eu tenho certeza metade de uma galera aí para de trabalhar.

Sim, como já deu, né, há um tempo atrás, caiu vários serviços e a galera ficou tipo postando meme dizendo que não tinha o que fazer no trabalho. Por isso é isso. E muito bem, muito bem colocado esse ponto. Achei muito cirúrgico, que acho que quem tá chegando agora tem dois trabalhos, que é aprender a trabalhar com a IA como suporte e não se deixar terceirizar 100%, né? Que a gente que não trabalhava com a IA, a gente tá aprendendo a lidar com ela como um suporte de trabalho no dia a dia.

Para quem tá começando agora, o trabalho da pessoa é aquilo. Então, como que eu trabalho o suporte de uma coisa que é o todo do que eu tô fazendo, né? Muita loucura, realmente.

Perfeitamente. E é isso, acho que para a gente que não tinha, a gente tem até uma certa dualidade ali de tipo, tá, até que ponto eu uso, até que ponto eu faço. Eu penso que até para o lado de vocês, design, que é mais criação ainda, digamos assim, é muito mais receio, sabe? Você tipo, o sentimento é: eu tô capando minha criação para poder botar para máquina criar por mim. Então tem que ter muito cuidado nisso. Eu hoje até tenho certa dificuldade se alguém chega para mim e fala: eu tô querendo ir para TI, o que que eu estudo?

O que que eu digo para essa pessoa? Sabe por quê? Você diz: cara, com ChatGPT tu vai aprender. Mas tu tem que absorver o que ele tá te falando. Eu sei que muita coisa, eu uso IA pra muita coisa hoje, mas eu uso pra coisas que eu iria perguntar pra outras pessoas. E aí entra até um papo mais filosófico, que aí é papo pra mesa de bar, que eu fico pensando, o botar IA também pode tá cortando esse repasse de conhecimento entre as pessoas.

Porque um dia desse eu me peguei pesquisando qual era o modelo da palheta do limpa-vítreo do meu carro. Porque eu queria trocar, que tava fazendo barulho, e eu fui pesquisar lá com a IA. E era o tipo de coisa que a gente perguntaria a quem? Nos nossos pais, tio, alguém que entende mais de carro e tudo mais, sabe? Não, tava lá na IA perguntando isso. Mais complexo.

Nossa, total. A gente pode fazer um episódio só falando sobre isso, mas tem um episódio aqui da série, inclusive eu conversei com o Bruno Nobre, a gente falou um pouco isso sobre como a IA ela ataca diretamente a cultura que é passada de forma oral. E é um pouco isso assim, o conhecimento que é adquirido por outras pessoas e você troca através dessa conversa, a tendência é que ela mire muito isso. Entre você perguntar para um amigo e esperar um dia inteiro o SLA do seu amigo para ele responder e você perguntar para a IA e ela em segundos te devolver, é muito mais rápido, né?

Você fica muito mais confortável. Mas o papo tá muito bom, mas a gente vai precisar encerrar. Queria agradecer mais uma vez a sua vinda aqui. Sua presença foi muito boa, o papo foi muito bom. Acho que esse episódio vai ser maravilhoso e convite aberto para voltar muito mais vezes. Vou deixar aberto aí para você se despedir e a gente fechar.

Bom, tá ótimo. Eu que agradeço, Carol. A conversinha também gostei muito. Como eu disse, acho que abre alguns pontos aí que a gente vai conversando, acaba dando vontade de conversar muito mais. Foi bem legal experiência. E também estou aberto, tiver novos assuntos aí, achar que me cabe na conversa, pode me incluir. E muito obrigado.

Fechado então, gente. Até semana que vem, vejo vocês. E fiquem ligados para a próxima, liguem o sininho, ativem as notificações para ficar por dentro das novidades por aqui. Tchau, tchau!