Olá, eu me chamo Pedro Lopes, eu sou diretor de produto na Allom Future Studios, que é uma divisão do Grupo Allom, e vim contar um pouco sobre a minha experiência com um produto específico, a Lumina, usando algumas ferramentas de aplicação, principalmente o Cloud Code e o Codex. Eu espero poder agregar ao trabalho de vocês, ajudando a entender como isso pode apoiar uma pessoa de produto.
Quando pensamos no trabalho cotidiano de uma diretoria de produto, ou de qualquer pessoa de produto, estamos lá para unir pontas. Em essência, tratamos de estratégia, entendemos as dores das pessoas clientes, das pessoas usuárias da nossa plataforma e das partes interessadas (stakeholders). Passamos o dia articulando forças. Costumamos brincar que, muitas vezes, a pessoa gerente de produto (PM, gerente de produto) não precisa saber fazer tudo, mas precisa saber conversar com quem sabe fazer. Conversamos com a pessoa de design, com a pessoa usuária para entender a dor, com a parte interessada para compreender a necessidade da empresa, com a pessoa desenvolvedora de software para entender como resolver o problema. São muitas frentes, conversas e negociações; para que tudo funcione, é essencial orquestrar, negociar e dialogar bem.
Vamos a um exemplo de tarefa. Precisamos entender uma funcionalidade de trial (período de avaliação) da plataforma: quantas pessoas usuárias ativam o trial, quantas de fato utilizam e acham interessante, quantas podemos converter. Tradicionalmente, ligaríamos para a pessoa de BI (Business Intelligence), pediríamos um e-mail, aguardaríamos um relatório, entenderíamos por que um acesso não ocorreu, mandaríamos mensagem para a pessoa de tecnologia para mapear o fluxo do trial — para onde vai, por que não vem — e a decisão se postergaria.
Outro caso: surge a necessidade de uma nova tela porque as pessoas usuárias não encontram um recurso em determinado local da plataforma. O caminho usual seria pedir o desenho da tela, marcar reunião, discutir design por uma hora, conversar com a área de negócio para alinhar a direção, passar uma semana planejando e, depois, descobrir que não era exatamente aquilo; voltamos, ajustamos, percebemos que faltou um botão, que havia um fluxo não mapeado, conversamos com engenharia e assim por diante. Essa é a rotina comum de uma pessoa de produto: amarrar pontas o tempo todo.
Como diretoria, estamos muito conectados às decisões e à estratégia. O dia a dia de execução, em geral, é delegado, e vemos muitas pessoas de estratégia subutilizando o potencial da IA. Já ouvimos repetidas vezes: “Não precisamos de IA, não temos tantos e-mails; não analisamos tantos contratos, isso é mais operacional.” A pessoa de estratégia, em geral, está em conversas de alto nível para entender mercado e necessidades da empresa. Para nós, houve um divisor de águas quando entendemos que a IA poderia ser parceira: ajudar a preparar discussões antes de chegar a uma diretoria executiva (C-level) ou a outra diretoria, levando o tema mais estruturado, já debatido com um “par” de alto nível — no caso, a IA.
Como isso é possível? Imaginem ter à frente uma ferramenta que conhece o projeto, o código a fundo, os comportamentos da plataforma e do produto, como funciona, como a pessoa usuária se comporta, quais fluxos aprecia, o que está e o que não está funcionando. Imaginem uma estrategista ao nosso lado que, às vezes, faz o papel de pessoa de dados, de tecnologia, de design, e que acessa informações em tempo real para trazer relatórios e novidades. Quando percebemos que poderíamos usar a IA para conversas estratégicas profundas — sobre como o produto funciona, o que está errado, quais dados embasam decisões, se devemos mudar ou não, como o mercado pode estar enxergando, como outras pessoas estão lidando com isso lá fora — tudo ao mesmo tempo, entendemos que a IA, muito além de resumir e-mails ou traduzir textos, deve ser nossa parceira de estratégia.
É importante reforçar que tudo isso é muito novo. Há seis meses, estávamos lidando com outros problemas: agenda mais engessada, múltiplas conversas que precisavam acontecer, sem dados à mão, sem design validado, sem clareza total do funcionamento da plataforma. Não há atraso se vocês ainda não vivem produto dessa forma. Dá tempo; basta entender o que está por trás.
Temos certeza de que vocês, interessades em tecnologia, produto, IA e engenharia, já abriram o ChatGPT, já testaram o Gemini — usamos com frequência o Gemini no Android, por exemplo. E talvez perguntem: “Não sentimos toda essa potência; a IA não parece tudo isso; se perguntamos o clima de hoje à noite, às vezes erra; se perguntamos quanto é 2 + 2, pode errar.” A IA vai muito além. Estamos discutindo ferramentas de IA generativa, conversacional — e o produto com o qual trabalhamos, a Lumina, também segue esse paradigma. Acabamos entendendo que IA é necessariamente uma conversa: pedimos uma tarefa e ela executa. Porém, quando falamos das grandes ferramentas de IA conversacionais, como o Cloud Code e o Codex, vamos um passo além. Elas conversam, mas com muito contexto. Por quê? Porque estão ligadas ao código: conseguem enxergar o produto por dentro, estão no repositório. Isso faz toda a diferença.
Quando abrimos um conversacional genérico, como o Gemini ou o ChatGPT gratuito, frequentemente sem pagamento e sem contexto, por que a IA parece mais “limitada”? Porque está começando do zero. Por isso se falou tanto em engenharia de prompt (instrução): é preciso saber o que e como pedir. Aos poucos, percebemos que isso não é tudo — e talvez nem seja a parte mais importante. O essencial é ter contexto prévio. Quando conversamos com o Cloud Code e com o Codex, eles já têm todo o código, sabem exatamente quais são os PRs (pull requests), as issues (tarefas) abertas, por que cada item foi pensado, qual o comportamento de cada parte, conhecem a documentação do produto em profundidade. Também contam com memória configurada para trabalho, muito mais potente. O chat conversacional genérico tem memória? Tem, mas aqui falamos de projeto: uma IA preparada para trabalho. Essa é a grande diferença.
Convidamos vocês que nunca usaram IA em nível profissional de trabalho a experimentar, para entender a diferença. Uma analogia útil é pensar no Codex e no Cloud Code como pessoas do time de programação com quem conversamos, porque estão “dentro” do código. Não é alguém fora da sala; é alguém dentro da sala, trabalhando no projeto conosco. Por isso o resultado é diferente.
O primeiro ponto é a fonte de dados. Sempre trabalhamos dentro do Grupo Alura e, dentro da Alura, por exemplo, lidamos com milhares de pessoas usuárias. Todas as vezes que precisávamos cruzar dados — dado A com dado B, comparar relatórios, tirar uma dúvida — pedíamos para alguém do time de BI (Business Intelligence) bater as informações. Precisávamos envolver o time de dados para montar a query (consulta) correta e definir como fazer a análise. Às vezes, o número chegava e olhávamos com suspeita, voltávamos para revisão, e isso levava tempo — naturalmente, porque há fila. Alguns times têm pessoa própria de BI, outros consomem o BI corporativo. Fato é: tomar decisão com dados sempre foi demorado; a dificuldade era minerar e encontrar os dados certos.
Hoje, o nosso Cloud Code tem acesso ao banco de dados com uma credencial de read-only (somente leitura). Isso resolve uma preocupação recorrente de desenvolvimento: dar acesso direto ao banco para produto pode gerar problemas — já erramos, inclusive dentro da Lumina. Com acesso somente à leitura, buscamos apenas o que está lá, sem inserir nada. Com o banco de dados disponível o tempo inteiro, usamos a ferramenta de IA (Cloud Code) como essa pessoa de BI, que entende o que precisamos. É claro que quem domina profundamente a semântica do banco vai mais fundo. Mas, no dia a dia, para decisões pequenas e médias, conseguimos ter rapidamente os dados que corroboram uma hipótese — ou a derrubam de imediato.
Ao falarmos dessas ferramentas, em geral, elas oferecem a funcionalidade de habilidades, frequentemente nomeadas como skills (habilidades). No caso do Cloud Code, adota-se o termo skills. Uma skill é um roteiro do que a IA deve fazer: um processo já validado, com um passo a passo específico a ser seguido, que colocamos por escrito em um texto. Em geral, utilizamos um arquivo no formato Markdown (linguagem de marcação), com extensão .md.
Dentro desse arquivo, descrevemos o roteiro completo da tarefa, do início ao fim: como deve começar, como será o meio do processo e qual é o output (saída) esperado. Hoje, mantemos diversas skills no Cloud Code. Por exemplo, a skill de engajamento. Já debatemos exaustivamente com o Cloud Code o que entendemos por engajamento, o que esperamos de uma pessoa usuária da Lumina, quais são os pontos de atenção, os KPIs (indicadores-chave de desempenho) e as métricas que acompanhamos. Assim, quando sabemos que solicitaremos sempre o mesmo relatório, variando apenas o período (por exemplo, “últimos 30 dias”, com comparativo), estruturamos tudo como um roteiro. Quando abrimos um chat (bate-papo) e executamos a skill de engajamento, o Cloud Code sabe exatamente o que fazer. A execução leva aproximadamente 5 minutos para reunir todos os dados, o que é aceitável, pois realizamos outras atividades nesse intervalo. Para processos bem definidos, é altamente recomendável usar essa funcionalidade de skills (ou o nome equivalente na ferramenta em uso).
Outro exemplo de skill muito utilizada é a de feedbacks (retornos). Na Lumina, há uma área para envio de feedbacks, estruturada de forma que se registra qual foi o chat, qual o report (relatório) da pessoa usuária e a possibilidade de anexar uma captura de tela para contextualizar uma solicitação ou relatar um possível erro. Em geral, trabalhamos mais com a parte de feedbacks. O que essa skill faz? Ela já conhece nosso modo de trabalhar produto. O Cloud Code sabe que somos de produto. Executamos essa skill periodicamente, neste caso de maneira manual, por preferência. O Cloud Code segue um roteiro de como acessar, onde localizar as informações e o que fazer com elas. Se encontrar, por exemplo, 10 feedbacks de pessoas usuárias, ele não simplesmente os apresenta na íntegra (isso poderíamos ver diretamente na página). Em vez disso, tenta condensá-los e relacioná-los: “O feedback 2 e o 8 se conectam; tratam da mesma funcionalidade que poderíamos priorizar.” Ou: “Este aqui não parece ter relação com uma nova feature (funcionalidade); aparenta ser um problema de compreensão do uso da plataforma. O melhor é enviar um e-mail oferecendo ajuda.” Assim, já filtramos o que não deve avançar. O Cloud Code ou o Codex fazem essa varredura e indicam o melhor próximo passo. Fica nítido quando há uma dor recorrente: “Entre 50 feedbacks, vários apontam para este ponto. Vamos atuar?” Quando confirmamos que sim, o sistema já sabe o que fazer: inicia o trabalho no código e retorna uma proposta de solução. Ao definirmos qual feedback será priorizado, o Cloud Code entende exatamente como nosso código funciona e quais são as opções para resolver aquela dor de pessoa usuária.
Outro uso recorrente em produto é validar hipóteses muito mais rápido, por exemplo, com um protótipo clicável. Até cerca de um ano atrás, antes do Lovable, isso seria quase inviável sem um time de tecnologia altamente dedicado, com capacidade ociosa. Em geral, ficávamos apenas no design de UX e em wireframes: uma sequência de imagens em que, ao clicar, o Figma alterna entre telas. Isso mudou. As ferramentas evoluíram; o Figma, por exemplo, melhorou a navegação entre páginas. Com IA, conseguimos gerar hoje um protótipo de solução dentro do nosso projeto — e aqui está a diferença. Quando propomos “vamos criar uma nova página XPTO”, estando dentro do nosso repositório, a IA conhece nosso design system (sistema de design), como cores e fontes utilizadas na plataforma da Lumina, e entende o comportamento esperado. Ela antecipa, por exemplo: “Se incluir um botão X, não funcionará porque essa função não existe no código; será preciso abrir uma solicitação para criar essa funcionalidade.” Ou: “Se incluirmos tal componente, não funcionará”, “Se adotarmos tal abordagem, o resultado pode melhorar.” Trata-se da camada estratégica a que sempre nos referimos.
Não se limita a apontar o que não funciona. Diversas vezes, pedimos a opção A por parecer suficiente, e o próprio Cloud Code sugere dar “um passo a mais”: “Já há algo pronto no código; podemos incluir no MVP (produto mínimo viável). Esse recurso adicional deixará a solução mais completa.” Utilizamos muito essa capacidade. Em minutos, o sistema cria uma página HTML e o código associado. Ainda não conectado ao banco de dados, mas suficiente para enxergar rapidamente layout, posicionamento de botões e fluxo de navegação. Assim, quando levamos uma proposta ao time de engenharia, apresentamos à diretoria ou testamos com pessoas usuárias, já temos algo quase imediato para avaliação. Para chegar a um bom protótipo, falamos de 30 a 60 minutos de interação com o Cloud Code; o mesmo trabalho, por um caminho tradicional, poderia levar pelo menos duas semanas.
Eu sou uma pessoa de produto e não tenho formação prévia em programação. Este conteúdo parte do ponto de vista de quem discute funcionalidades sem conhecer o que está no back-end. Hoje, contamos com um parceiro de trabalho que traduz nossa intenção, conhece nossos limites de compreensão e explica, em linguagem de produto, o que a plataforma é capaz ou não de fazer, quais caminhos podemos seguir e por que, às vezes, o benchmark (referência comparativa) que estamos estudando faz diferente — e o que há por trás disso.
Em diversas ocasiões, passamos uma semana planejando uma feature e um novo fluxo, para então, em reunião com a liderança técnica (tech lead), ouvir: “Isso não é viável” ou “Isso não cabe na sprint (ciclo de desenvolvimento); a sprint já está cheia.” Agora, quando envolvemos alguém de tecnologia, já sabemos o esforço estimado e o necessário para acontecer. Chegamos com os cards (cartões) prontos: “Esta tarefa é demorada; dividimos em cinco partes.” E o conteúdo de cada card não é apenas uma descrição de produto: além da descrição funcional, já há uma descrição técnica — que linhas precisam ser alteradas, em que trecho do código, etc. Fica praticamente pronto para uma pessoa desenvolvedora assumir ou, no caso da Lumina (tema para outro vídeo), para a própria IA programar.
Isso também nos permite programar mesmo sem sermos pessoas programadoras. Em pequenas mudanças — por exemplo, não temos acesso de escrita ao banco de dados, mas podemos abrir PRs (pull requests) diretamente no repositório. Assim, qualquer alteração simples e segura — trocar o texto de um aviso, tornar um warning (aviso) mais amigável, ajustar a cor de um botão — não precisa competir com prioridades críticas na sprint nem depender de design. Nós mesmas fazemos a mudança e já contamos com uma skill fornecida pela equipe de tecnologia para conduzir o deploy (implantação), fazer commit com segurança e executar os testes necessários. Em síntese, trabalhamos com código sem nunca termos feito um curso formal de programação.
Recapitulando os pontos práticos para utilizar tudo isso: primeiro, é preciso ter uma conta do Cloud Code ou do Codex, o que implica custos adicionais. Essas ferramentas não funcionam em contas gratuitas com uso limitado; é necessário adquirir a ferramenta e instalá-la no seu desktop (computador), pois o diferencial é rodar localmente, não na nuvem. É recomendável ter uma máquina razoável — nada extremo como um i7 com 16 GB de RAM, mas também não algo muito lento.
Além disso, é preciso acesso ao repositório do projeto, ainda que inicialmente apenas para observação. No nosso caso, temos acesso ao GitHub, criamos a pasta local e configuramos o ambiente local dentro do Cloud Code — é isso que viabiliza toda a “mágica” descrita. Por fim, como já comentamos, é valioso ter acesso em read-only (somente leitura) ao banco de dados, para conhecer as pessoas usuárias e os dados existentes. Defendemos fortemente o acesso em read-only nesse contexto, pois um erro no banco pode comprometer o produto.
Eu compartilhei muitos pontos aqui. No próximo vídeo, vou mostrar o meu Cloud Code, o Codex aberto, para você entender como trabalhamos na prática: o que aconteceu de verdade, erros e tropeços ao longo do caminho. Se você quer usar dessa forma e está em dúvida por onde começar, siga estes requisitos e detalhes que comentamos. Vamos em frente e nos vemos no próximo vídeo. ��
Chegou a hora de vermos na prática algumas das ideias apresentadas anteriormente. Esperamos trazer mais clareza sobre os processos discutidos no primeiro vídeo.
Antes de mais nada, vamos apresentar rapidamente o que é a Lumina. Vamos colocar na tela para acompanhar. A Lumina é uma plataforma conversacional. Ela oferece um ambiente ao qual já estamos acostumados: um chat para fazer perguntas, anexar arquivos, enviar um prompt (comando) por áudio, entre outras possibilidades. A diferença é que se trata de uma ferramenta voltada ao trabalho. Ela está configurada para entender como trabalhamos, identificar os resultados de que precisamos e entregar artefatos estruturados, como relatórios e documentos prontos para uso no dia a dia.
A base da plataforma é a estrutura de agentes. Vamos mostrar como chegamos a essa arquitetura. Esses agentes foram concebidos com o conhecimento do nosso time, tanto de tecnologia quanto de ensino do Grupo Alan, que acumula mais de 20 anos atuando em negócios e ministrando aulas sobre business (negócios). Assim, quando criamos uma pessoa especialista em clientes para ajudar alguém colaborador da empresa a trabalhar com o relacionamento com clientes, incorporamos um repertório que não se encontra em ferramentas mais genéricas, pensadas para qualquer uso e não necessariamente para um ambiente de trabalho.
Há diversos especialistas (agentes) e conexões com ferramentas que trazem boa parte do contexto comentado anteriormente. Mesmo uma pessoa usuária sem familiaridade com código consegue integrar com ferramentas como o Outlook, o Gmail, a agenda e o Slack, a fim de obter percepções rapidamente. Como comentamos, a boa IA é aquela que possui seu contexto.
Vamos a um exemplo simples do que significa ser uma ferramenta orientada ao trabalho. Construímos um prompt (comando) simples; a IA já conhece nosso perfil e nossa área de atuação. Anexamos um arquivo de demonstração (uma planilha simulando pessoas estudantes do primeiro trimestre) para análise. Ao entregar os resultados, a IA antecipa o que precisamos, já gera gráficos e, quando apresenta uma análise ou relatório, disponibiliza tudo em formato editável, pronto para download e uso em uma reunião. Neste exemplo, solicitamos um documento, mas poderíamos ter pedido uma apresentação em PowerPoint, uma imagem ou outro formato.
Observe que o resultado gerado pela ferramenta é mais interessante para o trabalho. Para quem está acostumado com o uso do modelo da Anthropic, o modo de código do modelo, o Claude Code, por exemplo, costuma ter dificuldade em construir esse tipo de artefato colaborativo. Aqui, conseguimos trabalhar junto com a IA: ela gera o conteúdo e podemos editar à vontade, com as edições preservadas.
Trata-se de uma solução multimodelo, com diversos modelos rodando por trás, além de uma área de acompanhamento para pessoas gestoras. Vale a pena conhecer mais; se desejar, envie uma mensagem para nós e contamos mais sobre a Lumina.
Agora, vamos observar como trabalhamos com o Claude Code dentro da Lumina. Vamos abrir alguns chats reais. Isso significa que será possível perceber alguns caminhos tortuosos, pois, quando trabalhamos, eventualmente vamos por diferentes direções; não é um ambiente totalmente controlado. Pode haver dados sensíveis; vamos solicitar ao time de edição que aplique blur, pois não faz sentido exibir esse tipo de informação.
Vamos a um exemplo de dúvida. Sabíamos que havia um problema na plataforma, mas não exatamente qual era o escopo e quem estava sendo impactado. O prompt (comando) foi o seguinte: quando fazemos upload de arquivo na Lumina, existe um limite de tamanho. Esse limite decide se o documento inteiro será passado no prompt (comando) ou se a funcionalidade de RAG (Geração Aumentada por Recuperação) será ativada. Você não precisa entrar nos detalhes técnicos; o ponto é que existe um comportamento na plataforma que queríamos entender a fundo. Em conversas anteriores, o Claude Code já havia sugerido que aumentássemos substancialmente esse limite, pois a maioria das pessoas imagina que terá o documento completo à disposição para consulta ao fazer uma pergunta. Do ponto de vista técnico, RAG (Geração Aumentada por Recuperação) não é o mesmo que enviar o documento completo. A pergunta foi: qual seria o limite ideal hoje? Como medir isso? Solicitamos que a IA analisasse o comportamento das pessoas usuárias nos últimos 15 dias, em chats ou agentes aos quais foram adicionadas grandes quantidades de arquivos, direcionando onde encontrar as conversas e os dados. Pedimos que detectasse padrões, verificasse se havia expectativa de comportamento de documento completo ou se o RAG (Geração Aumentada por Recuperação) atendeu às necessidades, e que sugerisse um limite a partir dos dados encontrados.
Essa é uma conversa estratégica, do tipo que teríamos com uma pessoa colega de trabalho, algo que discutiríamos com o time de engenharia e que provavelmente levaria semanas para amadurecer. O Claude Code tem a característica de exibir o que está fazendo e para onde está indo; o Codex é um pouco diferente.
Em seguida, a IA entregou um relatório com todas as ideias: o limite atual, a janela de contexto, a volumetria dos últimos 15 dias, quantos arquivos foram processados, qual porcentagem caiu em RAG (Geração Aumentada por Recuperação) — por exemplo, 31% —, o peso disso e o comportamento geral. Trouxe uma análise substancial, consultando nosso banco de dados, pois a ferramenta tem essa capacidade.
A resposta direta à pergunta foi: o limite ideal hoje seria de 100 mil tokens (unidades de texto), variando porque há limitações diferentes entre modelos (por exemplo, 64 mil no Claude, 120 mil no Gemini, entre outros), em comparação com o limite então vigente de 12,8 mil. Ou seja, o limite vigente era cerca de dez vezes menor do que a recomendação.
Com isso, seguimos em frente: solicitamos a criação de uma issue (chamado) com todos os detalhes da análise — ou seja, um card (cartão) — e pedimos para apagar o conteúdo em SQL (linguagem de consulta estruturada) usado na apuração, pois não seria armazenado. Ao finalizar, a IA foi instruída a enviar uma mensagem no Slack, no canal Devs, pedindo que alguém revisasse a issue (chamado), explicando em uma linha do que se tratava. Isso economiza tempo: em vez de redigir manualmente um resumo de toda a análise, a própria IA sintetiza e encaminha a mensagem.
Mesmo assim, percebemos em conversas subsequentes que havia mais pontos a avaliar. Então pedimos uma simulação de custo: com base no uso dos últimos 30 dias, quanto mais caro teria ficado o gasto mensal se já tivéssemos alterado o teto do RAG (Geração Aumentada por Recuperação)? A IA apresentou uma análise abrangente, indicando que, no fim, a variação seria mínima. Solicitamos que respondesse ao time com essa análise e incluísse os dados na issue (chamado). A automação registrou tudo no GitHub.
Surgiu a pergunta: não haveria um meio-termo? Sair de 12,8 mil direto para 100 mil poderia causar receio no time de pessoas desenvolvedoras. Solicitamos, então, uma proposta conservadora. A análise indicou que, se adotássemos 32 mil, já haveria uma melhora significativa. Assim, tomamos uma decisão rápida, com embasamento em dados, e fomos conversar com o time de tecnologia com clareza. Como bônus, o card (cartão) estava pronto com tudo o que deveria ser feito; uma pessoa desenvolvedora já a par da conversa poderia assumir a issue (chamado) e implementar usando o Claude Code, fazendo apenas os ajustes finais e aprovando o resultado.
O próximo caso é sobre uma skill (habilidade). No vídeo anterior, mencionamos a skill (habilidade) chamada “Feedback Triage” (triagem de feedback). Ela foi montada em conjunto com o Claude Code. Fomos especificando o que queríamos e pedimos para a IA montar a skill (habilidade) com base nisso. Ao abrir um chat e simplesmente invocar a skill (habilidade), sem texto adicional, ela já sabe exatamente o que fazer. A solução busca os dados; em um momento, teve dificuldade para encontrar o banco de dados, mas, depois, conseguiu e identificou, por exemplo, 18 feedbacks pendentes no banco, ainda sem resposta. Detectou inclusive um bug disfarçado de percepção.
Por conter muitos e-mails, aplicamos blur para não expor pessoas usuárias. A skill (habilidade) indica, por exemplo, pedidos de conexão com o Azure, com o GitHub, com o Alura BI, sobre vozes representativas e sobre a criação de toda a estrutura de projetos utilizando determinada ferramenta da Microsoft. Ela cria cases (casos) para elucidar por que as pessoas estão fazendo esses pedidos e aponta situações em que já existe a funcionalidade: em vez de item de backlog (fila de pendências) de engenharia, trata-se de um gap (lacuna) de comunicação, ou seja, um problema de produto e de UX (experiência de pessoa usuária), pois as funcionalidades existem, mas não estão sendo encontradas. Em seguida, classifica casos de média prioridade, prováveis descartes (por exemplo, quando os conectores já funcionam como esperado) e faz uma leitura geral: conectores dominam os pedidos, indicando uma dor na plataforma — há desejo de conectar mais ferramentas. Esse trecho é de um período anterior; hoje, já evoluímos em muitos desses pontos.
Na sequência, pedimos para olhar as issues (chamados) já criadas no projeto da Lumina, pois várias conexões solicitadas já estavam no nosso backlog (fila de pendências). A skill (habilidade) verificou e, por exemplo, detectou que determinado item (como “FIG”) já tinha um pedido aberto, dispensando a criação de novo card (cartão). Em cerca de 10 minutos de conversa, saímos com quatro cards (cartões) claros do que deveria ser feito de imediato; o time sabe por onde começar, e seguimos com tranquilidade.
Essa skill (habilidade) tem um ponto interessante para quem faz gestão da Lumina: existe um painel administrativo no qual visualizamos os feedbacks, com status como “em triagem” ou “finalizado”. Esses status podem ser atualizados via banco de dados, mas, como não temos permissão de escrita, a skill (habilidade) foi programada para, ao terminar o trabalho, abrir o navegador, acessar a Lumina na página “feedbacks”, abrir cada item, marcar “descartado” ou “finalizado”, indicar se virou issue (chamado), colar o link do card (cartão) e salvar. Em outras palavras, uma tarefa manual é automatizada via o navegador interno controlado pelo Claude Code. Há vários outros exemplos desse tipo de automação, o que demonstra o potencial de uma skill (habilidade): invocamos uma palavra e todo o fluxo é executado.
Para quem não está acostumado com o conceito de skill (habilidade), vamos mostrar como montamos uma, em um diálogo conversacional com o próprio Claude Code. No caso, localizamos outra skill (habilidade) já construída, sobre engajamento, que gera um relatório de uso da Lumina.
Como criamos essa skill (habilidade)? A ideia é conversacional. Nós, como pessoas de produto, sabemos quais são os termos e objetivos de produto; quem traduz isso em SQL (linguagem de consulta estruturada) e em queries (consultas) é a IA. O pedido foi: montar uma skill (habilidade) de acompanhamento do comportamento e engajamento das pessoas usuárias da Lumina em geral. Faz sentido usar uma skill (habilidade) porque sempre analisamos os mesmos pontos e depois pedimos comparativos entre períodos. Solicitamos que a IA avaliasse se essa é a melhor abordagem, descrevemos o que estávamos pensando e pedimos que debatesse, sugerindo ideias antes de criar a skill (habilidade).
Isso é importante: devemos deixar claro para a IA que estamos abertos à discussão. Caso contrário, muitas vezes ela apenas concorda (“nossa, como você é inteligente, Pedro; vamos fazer tudo isso”), sem crítica, porque não dissemos que poderia questionar.
Especificações:
Sobre agentes, queremos ver métricas análogas; sobre projetos, os KPIs de agentes, mas considerando a funcionalidade de projetos; sobre conexões, a quantidade de pessoas usuárias conectadas a cada ferramenta (número absoluto e porcentagem). Em resumo, o relatório atende exatamente ao que queremos porque combinamos nosso conhecimento de produto com a inteligência da IA. Se não soubermos o que queremos, o resultado não corresponderá às necessidades.
Tudo deve ser consultado em banco de dados em read-only (somente leitura). Se algo não puder ser extraído, a IA deve indicar. Também pedimos sugestões de métricas que não tenhamos considerado, abrindo espaço para a IA participar estrategicamente.
A IA validou a skill (habilidade) e rebateu pontos, como a definição de “licença vigente” (“tenha cuidado, será que essa é a leitura desejada?”), indo ponto a ponto. É comum, para quem está acostumado com chats mais “abertos”, estranhar respostas tão densas e extensas — mas é justamente esse nível de profundidade que buscamos para apoiar decisões de produto e engenharia.
Nós já estamos acostumados a ter conversas longas com a IA — frequentemente de 30 a 40 minutos — porque interagimos com um parceiro estratégico. Não se trata de pedir “faça uma imagem para um convite de aniversário” (uma atividade de 2 minutos), e sim de conduzir um trabalho estruturado. É importante nos acostumarmos ao fato de que uma IA realmente inteligente pode demorar para responder. Esse é o primeiro ponto.
Também é importante mantermos várias atividades em paralelo, para não ficarmos parados aguardando a IA. A conversa será longa, pois precisaremos ler tudo. Se não lermos, teremos problemas. Fazemos parte do ciclo, porque a estratégia é de ida e volta.
Para exemplificar a dimensão dessa troca, fomos respondendo ponto a ponto. Antes de montar a nossa skill (habilidade), a IA apontou cinco decisões que precisávamos tomar como pessoas de produto: exclusão das pessoas testadoras, manejo de lista de e-mail frágil, status de ativo, captura por instantâneo no fim do período ou por janela móvel, entre outras. Respondemos a todas. Seguindo nessa conversa, a IA criou a skill (habilidade) e, depois, abriu uma issue (tarefa) para publicá-la. Esse tema da publicação é assunto para outro momento, mas a skill (habilidade), inicialmente, estava apenas no nosso computador (local). Como fazemos parte do projeto, faz sentido que a skill (habilidade) seja acessível para toda a equipe que trabalha na Lumina. Por isso, criamos um PR (Pull Request) para publicar no código. Quando o PR (Pull Request) for aprovado e a issue (tarefa) concluída, a skill (habilidade) passará a residir no código no GitHub, disponível para todas as pessoas no repositório.
Queremos mostrar outro caso, que não difere muito do que já discutimos, mas traz outro exemplo. Agora, estamos no código. Usamos duas ferramentas na equipe — como “Palmeiras e Corinthians” —, aproveitando as vantagens de cada uma, para tudo funcionar bem. Ainda estamos nos adaptando, mais acostumados com o Claude Code, e gostando muito. Este caso é recente, aconteceu nesta semana.
Precisávamos facilitar a criação de uma dashboard (painel) de visualização dentro da Lumina. Observamos que muitas pessoas usuárias pedem uma análise, mas não querem a análise plotada em documento ou planilha. Elas desejam uma visualização atraente. Frequentemente pedem um HTML (HTML) — “faça uma página de dashboard (painel) bonita para nós”. Isso consome muitos recursos. A Lumina sabe fazer, mas leva tempo, gasta muitos tokens (unidades de processamento) e, em geral, a pessoa usuária fica desconfortável com a espera. Além disso, nem sempre é exatamente o que ela precisava, e acabamos gastando dinheiro desnecessariamente, pois muitas vezes a necessidade é apenas ter algo visual agradável, não necessariamente um código completo para uso externo.
Formulamos o pedido, inclusive com erros de português, para mostrar a robustez da IA: queríamos saber, nos últimos 30 dias, quantas pessoas usuárias solicitaram a visualização de um chat em formato de dashboard (painel) — ou usando termos como dashboard (painel) interativa, dashboard (painel) em HTML (HTML), algo nessa linha — e quantas dashboards (painéis) foram, de fato, geradas pela Lumina. Também pedimos para verificar similaridade entre os resultados: se existe um padrão de construção de dashboards (painéis) e se, ao entender que precisa construir uma dashboard (painel), o sistema gera algo recorrente.
O Claude Code tende a ir direto à resposta. Ele analisou os 30 dias e relatou: três pessoas usuárias distintas; nove dessas solicitações receberam pelo menos um artefato de dashboard (painel); a Lumina concluiu 40 artefatos e 16 iniciativas de dashboard (painel); e apresentou o código correspondente. São achados que não conseguiríamos levantar com facilidade manualmente. O Claude Code também explicou a técnica utilizada para validarmos se os achados e a identificação de pessoas usuárias estavam corretos.
Perguntamos o padrão de construção: cabeçalho, filtros no topo, cartões com indicadores principais, de dois a quatro gráficos. Confirmado o padrão, avaliamos a possibilidade de automatização, exatamente o que estávamos buscando. O Claude Code apontou 87% de recorrência, com duas famílias técnicas dominantes — uma discussão técnica extensa.
Perguntamos ao “Codex”: o que ele sugeria para termos uma experiência mais estruturada? Apresentamos nossa ideia: criar uma tool (ferramenta) de dashboard (painel) de visualização de dados para economizar tempo e tokens (unidades de processamento) das pessoas usuárias, padronizando elementos, de modo que, na geração por conversa, pouco código precisasse ser escrito na hora. O “Codex” respondeu que fazia sentido, mas recomendou não apenas criar uma tool (ferramenta), e sim um novo artefato nativo chamado dashboard (painel). Em seguida, detalhou a arquitetura proposta.
Para ilustrar o contraste entre a ideia inicial (tool) e o encaminhamento final (artefato nativo), um rascunho de tipo para a “tool” poderia ser algo assim:
type ToolDashboard = {
id: string;
// ...
}
Para tornar essa ideia concreta, dá para modelar a arquitetura desse novo artefato como uma especificação de dashboard, contemplando título, modelo (template), fontes de dados, filtros e widgets (KPIs e gráficos), assim:
type DashboardSpec = {
version: 1;
title: string;
template: 'executive' | 'operational' | 'exploratory';
sources: DashboardDataSource;
filters: DashboardFilter[];
widgets: DashboardWidget[];
}
A partir desse esqueleto, podemos acomodar múltiplas fontes e já esclarecer o conjunto inicial de widgets contemplados na arquitetura:
type DashboardSpec = {
version: 1;
title: string;
template: "executive" | "operational" | "exploratory";
sources: DashboardDataSource[];
filters: DashboardFilter[];
widgets: DashboardWidget[];
};
// Widgets inicialmente:
// - KPI
// - Tabela/Ranking
// - Insight textual
// - Separador ou título de seção
Como pessoas de produto, entendemos partes e questionamos outras, debatendo ponto a ponto. Onde foi necessário, pedimos esclarecimentos. Houve uma provocação útil: “vamos fazer direito e algo melhor”. Diante disso, levantamos preocupações: seria possível gerar edições da dashboard (painel), alterando, adicionando ou excluindo alguns KPIs? Poderíamos solicitar quantas métricas quisermos, ou haveria limite? Conseguiríamos editar o artefato sem ter de regenerar tudo, evitando alucinações? Isso é importante. Também é essencial podermos seguir conversando com a IA sobre os resultados exibidos na dashboard (painel), ou seja, que o chat reconheça a dashboard (painel) gerada como fonte de conhecimento. Essa possibilidade já existia na arquitetura — discutimos isso recentemente com o Claude Code —, pois o sistema enxerga o último artefato gerado e mantém esse contexto.
Para viabilizar edições incrementais e controle de aparência, prevemos operações de manipulação do artefato:
addWidget
updateWidget
removeWidget
addFilter
updateFilter
removeFilter
updateTheme
Como representação bruta dessas ações antes de serem consumidas pela função de atualização, o vídeo mostrou objetos nesse formato:
{ action: "removeWidget", widgetId: `api-enum` }
{ action: "addWidget", widget: ... }
{ action: "updateWidget", widget: ... }
{ action: "addFilter", filter: ... }
{ action: "updateTheme", theme: ... }
Agora que listamos as operações, vale ilustrar como elas poderiam ser executadas por uma função de atualização, cobrindo remoção, adição e alteração de widgets:
updateDashboard({
action: 'removeWidget', widgetId: 'kpi-churn'
});
Esse primeiro exemplo remove um KPI específico (identificado por widgetId). Em seguida, adicionamos um novo KPI de MRR:
updateDashboard({
action: 'addWidget',
type: 'kpi',
title: 'MRR',
metric: { operation: 'sum', field: 'mrr' }
});
E, por fim, atualizamos o tipo de gráfico de um widget já existente para “area”:
updateDashboard({
action: 'updateWidget',
widgetId: 'revenue-chart',
changes: { chartType: 'area' }
});
Essas chamadas exemplificam o fluxo incremental de edição citado acima: ao invés de regenerar tudo, alteramos apenas o que é necessário, preservando contexto e evitando alucinações.
Percebamos: não se trata de “entregar a tarefa e deixar a IA decidir”. Precisamos discutir, validar e perguntar “tem certeza?”, “isso funciona?”. Gostamos desse comparativo: uma tarefa que tomaria 40 horas no “mundo antigo”, algumas pessoas dizem que agora se faz em 4 minutos. Nossa proposta é reconhecer que nem é 40 horas nem 4 minutos; é cerca de 40 minutos a 1 hora. O ganho é enorme, mas não é instantâneo. Se deixarmos tudo por conta da IA, haverá problemas. O ideal é tratá-la como parceira estratégica.
O assistente detalhou passo a passo para nos tranquilizar quanto ao que estava sendo considerado. Fizemos a revisão completa no final. Sempre pedimos um “double check”: revisar tudo o que foi proposto, confirmar a viabilidade, gastar tempo analisando o nosso código e validando o que já existe e o que falta. Recebemos um fluxo explicando como seria a implementação, para entendermos claramente.
Para dar suporte à implementação e evolução futura, detalhamos os tipos de widgets e filtros, com propriedades úteis para layout e posicionamento:
type DashboardSpec = {
version: 1;
title: string;
template: "executive" | "operational" | "exploratory";
sources: DashboardDataSource[];
filters: DashboardFilter[];
widgets: DashboardWidget[];
};
type DashboardWidget = {
id: string; // autogerado
type: "kpi" | "chart" | "table" | "text" | "divider";
title: string;
width: number;
height: number;
position: number;
// ... propriedades específicas de cada tipo
};
type DashboardFilter = {
id: string; // autogerado
type: "date" | "enum" | "text" | "boolean";
field: string;
label: string;
// ... propriedades específicas de cada tipo
};
Como o version da especificação é explícito, também prevemos um ponto de extensão para migrações futuras, mantendo o parser preparado para versões novas:
parseDashboard(content) {
if (content.version === 1) {
return parseDashboardV1(content);
}
// ... migrações para versões futuras
}
Dado o padrão de construção confirmado — filtros no topo, cartões de KPIs e gráficos —, um exemplo de criação de dashboard executiva focada em “Receita” poderia ser instanciado assim, refletindo exatamente os elementos discutidos:
Antes de chegar ao exemplo final, um rascunho inicial de chamada (mínimo viável) pode aparecer assim, alinhando títulos, template, fontes, filtros e os primeiros widgets:
createDashboard() {
title: "Receita",
template: "executive",
sources: [ ... ],
filters: { businessUnit: "month" },
widgets: [
{
type: "kpi",
title: "Receita",
metric: { operation: "sum", field: "revenue" },
format: "currency"
},
{
type: "chart",
chartType: "line",
dimension: "month",
metric: { operation: "sum", field: "revenue" }
}
]
}
Em seguida, consolidamos a instância no formato final, com filtros e widgets conforme o padrão definido:
createDashboard({
title: "Receita",
template: "executive",
sources: [...],
filters: ["businessUnit", "month"],
widgets: [
{
type: "kpi",
title: "Receita",
metric: { operation: "sum", field: "revenue" },
format: "currency"
},
{
type: "chart",
chartType: "line",
title: "Receita",
metric: { operation: "sum", field: "revenue" }
}
]
})
Como variação desse formato final, também é possível manter o padrão de filtros e deixar a dimensão do gráfico explicitamente declarada:
createDashboard({
title: "Receita",
template: "executive",
sources: [ ... ],
filters: ["businessUnit", "month"],
widgets: [
{
type: "kpi",
title: "Receita",
metric: { operation: "sum", field: "revenue" },
format: "currency"
},
{
type: "chart",
chartType: "line",
dimension: "month",
metric: { operation: "sum", field: "revenue" }
}
]
})
Essa variação explicita a dimensão “month” no widget de gráfico, reforçando o padrão de construção com filtros no topo, KPIs destacados e tendência temporal logo abaixo.
Para complementar, aqui está uma variação concreta em que a fonte de dados financeira é explicitamente definida. Isso ajuda a deixar claro como referenciar origens específicas no ato da criação:
createDashboard({
title: "Receita",
template: "executive",
sources: ["financial"],
filters: ["businessUnit", "month"],
widgets: [
{
type: "kpi",
title: "Receita",
metric: { operation: "sum", field: "revenue" },
format: "currency"
},
{
type: "chart",
chartType: "line",
dimension: "month",
metric: { operation: "sum", field: "revenue" }
}
]
})
Como outra variação prática, no vídeo também apareceu uma criação com fonte identificada e filtros em snake_case, útil para quando os identificadores vêm diretamente do banco de dados:
createDashboard({
title: "Receita",
template: "executive",
sources: [{ id: "db_vendas" }],
filters: ["business_unit", "month"],
widgets: [
{
type: "kpi",
title: "Receita",
metric: { operation: "sum", field: "revenue" },
format: "currency"
},
{
type: "chart",
chartType: "line",
title: "Receita",
metric: { operation: "sum", field: "revenue" },
}
]
})
Essa chamada exemplifica a mesma estrutura didática mostrada acima, apenas especificando a origem de dados “db_vendas” e variando a convenção de nomes dos filtros.
Esse exemplo ilustra como os filtros são declarados e como os widgets representam tanto o cartão de KPI principal quanto um gráfico de tendência, reduzindo o esforço de geração “na hora” e padronizando o resultado. Em um cartão de KPI, o payload típico exibido para a pessoa usuária pode ser algo como:
{ "title": "Receita", "value": 1250000 }
Para configurar as métricas de forma padronizada, adotamos operações e cláusulas comuns em agregações e consultas:
sum
distinctCount
min / max
ratio
groupBy
orderBy
limit
E a configuração mínima de uma métrica segue este formato:
{
"field": "revenue",
"operation": "sum"
}
Como variação equivalente ao formato mínimo, o snippet também apareceu incluindo o título da métrica, útil quando se deseja carregar metadados junto da definição:
{
"title": "Receita",
"operation": "sum",
"field": "revenue"
}
Chegando ao final, reforçamos: não sabemos se vamos codificar essa solução — provavelmente não. Solicitamos a documentação completa, em detalhes, do que foi discutido, em uma issue (tarefa), um card (cartão) no GitHub. Consideramos que outra pessoa desenvolvedora executará a implementação; por isso, pedimos um plano muito específico, com comportamento esperado, passos de execução etc. E foi o que o assistente fez: entregou a issue (tarefa) no GitHub, com toda a documentação do discutido, parâmetros, necessidades e o que precisa ser alterado no código para viabilizar. Agora, uma pessoa desenvolvedora utilizará o Claude Code e o “Codex” para transformar isso em realidade.
Mais um caso, mais complexo (sem entrar em todos os detalhes): na primeira parte, mencionamos nossos agentes — especialistas prontos, construídos com a nossa inteligência, para auxiliar pessoas usuárias nas tarefas do dia a dia do negócio. Houve um plano de reestruturação. Muita coisa mudou. Saímos de diversos especialistas para poucos especialistas. Em vez de 55 agentes, cada um com uma tarefa muito específica, decidimos criar apenas 12 a 15 agentes mais versáteis, aproveitando que a IA hoje é mais inteligente. Isso torna o uso mais claro: em vez de procurar entre 55 opções, a pessoa usuária pensa “é um problema de marketing?” e recorre ao agente de marketing.
Esse plano foi criado com o Claude Code, após dias de discussão: estruturação, benchmark (referência comparativa), busca na web (web), entre outras etapas. Registramos tudo na memória. Por isso, iniciamos esse trecho perguntando: “lembra que ficamos de pensar no design da página de especialistas?” Porque o plano de criar os novos especialistas foi executado, mas a página ainda não havia sido mexida. O back-end já estava pronto; faltava a página de especialistas que daria destaque aos novos 12 agentes principais. Pedimos para recuperar essa memória e começar a discussão.
O assistente buscou na memória e localizou a página atual. Como já havia contexto salvo, retomou conversas anteriores: queríamos mudar o modelo mental da página — de um catálogo para um hall (saguão) —, e havia decisões a tomar: manter os especialistas antigos na página? Deixá-los recolhidos? Colocar atrás de um link visível? Como destacar a vitrine dos novos agentes?
Expressamos nossa maior preocupação: ainda não tínhamos certeza da qualidade do resultado dos novos especialistas, pois estávamos testando. Já fizemos testes próprios, mas queríamos observação das pessoas usuárias. Não queríamos frustração. Se recolhêssemos os antigos imediatamente, isso poderia ser um problema. O assistente entendeu a “dor”, abandonou algumas opções e propôs outras. Em determinado momento, sugeriu já fazer um eval (avaliação) dos agentes. Explicamos que não era o objetivo daquela conversa; já havia uma issue (tarefa) aberta sobre isso, e pedimos para consultar lá. Reforçamos o registro de em que ponto do projeto estávamos na memória.
Após discussões (inclusive momentos de desalinhamento), chegamos à decisão de como deveria ser a nova página. Com os pontos definidos, pedimos que o assistente montasse a maquete do estágio C (havia as opções A, B e C; escolhemos C). O assistente já tinha em memória uma orientação nossa: sempre que terminarmos de desenhar uma funcionalidade, queremos uma maquete ou queremos entrar em “modo protótipo”. Quando usamos essas palavras, o assistente entende que deve desenhar uma página o mais próxima possível da página atual e do resultado final, para podermos navegar.
Solicitamos a maquete. O Claude Code processou por um tempo e entregou um protótipo. Abrimos no navegador para facilitar o entendimento. Não estava 100% pixel perfect (preciso em pixels) — era um protótipo rápido —, mas já respeitava o nosso design system (sistema de design) e o funcionamento da página. Comparamos com a versão atual para ver a proximidade.
O assistente montou a maquete completa do estágio C, e, para comparação, mostrou o estágio A (com tudo fechado) e o estágio C (com tudo aberto). Perguntou se os agentes antigos deveriam aparecer e se a cor escolhida era a desejada. Seguimos iterando: o primeiro design não ficou chamativo; pedimos outra ideia; depois, um conceito em formato de cartão; surgiu o modo escuro; pedimos para intensificar o azul de fundo, buscando mais destaque. Chegamos a uma composição que nos agradou. Os elementos eram interativos — ao clicar, aparecia uma descrição, como na página real. O assistente demonstra entender, pelo código, o funcionamento concreto da página.
Com isso, concordamos com o direcionamento, entendendo o que funcionaria e o que não funcionaria. Em seguida, criamos a issue (tarefa) e discutimos com o assistente o detalhamento (um cartão ou mais cartões etc.). Do protótipo ao “valendo”, a diferença não foi grande: os mesmos elementos, praticamente como estavam. Como pessoas de produto, conseguimos decidir rapidamente. O que tomaria uma ou duas semanas de alinhamento com o time de design, agora se resolve em, no máximo, um dia — e segue para desenvolvimento. Se quiséssemos, poderíamos também codificar (temos permissão), já que estava tudo detalhado, mas cada empresa tem seu processo.
O mais importante: ter um protótipo navegável fez toda a diferença para entendermos o comportamento dos cartões, os tamanhos reais, o que ficaria recolhido ou não, a cor ideal. Ganhamos muito tempo com isso.
Esses são alguns exemplos práticos de como usamos IA. Existem centenas de outros. Estamos entusiasmados com essa forma de trabalhar, especialmente porque, até seis meses atrás, havia receio de “sair do fluxo” ao delegar à IA e de ela tomar decisões no nosso lugar — qual seria o nosso papel como pessoas de produto ou como liderança? Usando o Claude Code — gradualmente e com bastante experimentação, pois não é uma ferramenta trivial no começo —, percebemos que o Claude Code (ou qualquer outra ferramenta de IA) não está aqui para substituir, e sim para potencializar.
Claro, há fluxos que podem ser automatizados e alguns trabalhos podem desaparecer. Mas, falando do presente e do futuro que acreditamos, trata-se de ferramentas que amplificam o trabalho: o que levava dez, agora leva um. Fica muito mais fácil paralelizar, conduzir várias frentes ao mesmo tempo, experimentar, validar com a pessoa usuária, ter visibilidade do que acontece na plataforma e, principalmente, aprender. Muitos conceitos que abordamos — tool (ferramenta), artefato, como funciona o repositório — não vieram de um curso formal de programação; aprendemos conversando com o Claude Code, perguntando “qual é o sentido disso?”, “por que acontece assim?”, “explique para uma pessoa de produto como isso funciona por baixo dos panos”.
Usamos o Claude Code como parceiro estratégico, como professor, como pessoa designer, como liderança técnica — sem negar o papel de cada profissional. Continuamos contando com a pessoa de BI, a pessoa designer, a pessoa programadora e a pessoa de marketing. A diferença é que, quando chegamos para conversar, chegamos como “ciborgues”: falamos a língua da pessoa de marketing e a língua da pessoa de programação.
Então era isso que eu queria trazer para vocês. Espero que tenha sido proveitoso. Me procurem nas redes para trocarmos mais ideias e para eu saber como vocês vão usar a partir de agora. Não deixem de conhecer essas ferramentas — elas realmente vão mudar o seu trabalho. Até mais!
O curso Case Lumina - AI Product Builder possui 56 minutos de vídeos, em um total de 5 atividades. Gostou? Conheça nossos outros cursos de IA para Produto & Negócio em Inteligência Artificial, ou leia nossos artigos de Inteligência Artificial.
Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:
O Plano Plus evoluiu: agora com Luri para impulsionar sua carreira com os melhores cursos e acesso à maior comunidade tech.
2 anos de Alura
Matricule-se no plano PLUS 24 e garanta:
Jornada de estudos progressiva que te guia desde os fundamentos até a atuação prática. Você acompanha sua evolução, entende os próximos passos e se aprofunda nos conteúdos com quem é referência no mercado.
Back-end, Dados, Front-end, DevOps, Mobile, Gestão & Negócios, UX & Design, Cibersegurança, Cloud, Inteligência Artificial
Formações com mais de 1500 cursos atualizados e novos lançamentos semanais, em Programação, Inteligência Artificial, Front-end, UX & Design, Data Science, Mobile, DevOps e Inovação & Gestão.
A cada curso ou formação concluído, um novo certificado para turbinar seu currículo e LinkedIn.
Acesso à inteligência artificial da Alura.
No Discord, você participa de eventos exclusivos, pode tirar dúvidas em estudos colaborativos e ainda conta com mentorias em grupo com especialistas de diversas áreas.
Catálogo de tecnologia para quem é da área de Marketing
Faça parte da maior comunidade Dev do país e crie conexões com mais de 120 mil pessoas no Discord.
Acesso ilimitado ao catálogo de Imersões da Alura para praticar conhecimentos em diferentes áreas.
Explore um universo de possibilidades na palma da sua mão. Baixe as aulas para assistir offline, onde e quando quiser.
20% de desconto na Pós Tech
Luri Vision chegou no Plano Pro: a IA da Alura que enxerga suas dúvidas, acelera seu aprendizado e conta também com o Alura Língua que prepara você para competir no mercado internacional.
2 anos de Alura
Todos os benefícios do PLUS 24 e mais vantagens exclusivas:
Acesso ao catálogo da Casa do Código e leitura dentro da plataforma
Chat, busca, exercícios abertos, revisão de aula, geração de legenda para certificado.
Modo entrevista - Pratique situações reais e evolua com feedback personalizado
Envie imagens para a Luri e ela te ajuda a solucionar problemas, identificar erros, esclarecer gráficos, analisar design e muito mais.
Aprenda um novo idioma e expanda seus horizontes profissionais. Cursos de Inglês, Espanhol e Inglês para Devs, 100% focado em tecnologia.
Para quem quer atingir seus objetivos mais rápido: Luri Vision ilimitado, vagas de emprego exclusivas e mentorias para acelerar cada etapa da jornada.
2 anos de Alura
Todos os benefícios do PRO 24 e mais vantagens exclusivas:
Lives CareerUp: eventos exclusivos com foco em empregabilidade e carreira
Mentorias de carreira: 2 encontros individuais com mentores do Talent Lab
Conecte-se ao mercado com mentoria individual personalizada, vagas exclusivas e networking estratégico que impulsionam sua carreira tech para o próximo nível.
