Codex: prototipação de produtos digitais

Primeiros passos - Apresentação

Apresentando o curso e o instrutor

Olá! Seja bem-vinda, bem-vindo a este curso na Alura. Eu sou Ricardo Bugan, Head (líder) de Produto, e serei seu instrutor neste curso.

Neste curso, vamos entender como montar um protótipo de telas a partir do Codex (Codex), um protótipo navegável alinhado à ideia de produto que temos.

Estruturando o protótipo de e-commerce

Trabalharemos uma parte de um e-commerce (comércio eletrônico) em que podemos adicionar itens ao carrinho, remover itens do carrinho e realizar automaticamente os cálculos. Teremos uma Home (página inicial) para visualizar como a loja vai funcionar, definir a distribuição das diferentes categorias e realizar a curadoria do Marketplace (mercado virtual).

Montaremos tudo isso junto com o Codex (Codex). Para isso, veremos técnicas para incorporar referências de design e necessidades de negócio, de modo que o assistente do Codex (Codex) funcione e crie da melhor forma possível o seu protótipo.

Explorando conceitos e ferramentas do curso

Também veremos a diferença entre um protótipo, um MVP e um produto final ao longo deste curso, para entender onde aplicamos cada uma dessas técnicas.

Além disso, utilizaremos o Codex e trabalharemos com Skills (habilidades). Teremos uma Skill (habilidade) para criar nossos PRDs, o arquivo Agents.md para dar instruções ao assistente, o arquivo Design.md para reunir referências de design e, assim por diante. Teremos um assistente que nos ajudará a tirar nossa ideia da cabeça e colocá-la em funcionamento.

Conectando o Amplitude e convidando para o curso

Aproveitaremos para conectar o Amplitude, a fim de gerar informações: capturaremos eventos que ocorrerem em nosso protótipo, criaremos um dashboard (painel) de navegação desse protótipo e, com isso, teremos mais dados enquanto o assistente estiver em funcionamento. Assim, quando nosso protótipo estiver no ar, saberemos como e onde precisamos melhorar o produto, com base nas informações que o Amplitude coletar para nós.

Venha ver tudo isso neste curso. Eu te espero lá!

Primeiros passos - O primeiro prompt

Explorando a interface do Codecs

Para começar nosso curso, vamos nos situar na interface do Codecs. Já estamos com o Codecs aberto e criamos um prompt básico para analisarmos alguns erros comuns de quem faz solicitações ao LLM. Antes dessa análise, vamos observar a interface.

No lado esquerdo da tela, temos o menu, onde podemos criar novos chats. Podemos criar um chat novo, acessar a seção de plugins (extensões), Automatizações e o aplicativo do Codecs, no qual configuramos algumas opções.

Em plugins (extensões), conectamos ferramentas e incorporamos habilidades vindas de outros LLMs ou as que ofereceremos neste curso. Elas ficam concentradas nessa seção. Há conexão com o Chrome, integração com outras ferramentas, o escopo que veremos neste curso, além de recursos voltados à construção de sistema operacional e de aplicação, e ferramentas para desenvolvimento. Assim, qualquer ferramenta que se deseje encontrar e conectar ao LLM para conceder acesso estará disponível aqui, e as habilidades também ficarão por aqui. Já temos algumas próprias, como análise de dados, geração de imagens e gerador de criativos; essas habilidades ficam empacotadas na seção de plugins (extensões).

Em Automatizações, configuramos rotinas. Por exemplo: queremos que todos os dias, às 9 da manhã, seja gerado um resumo do que está acontecendo no dia, das agendas e do status dos projetos. Configuramos a automação para ser executada todos os dias ou todas as semanas, no horário e na frequência desejados.

Gerenciando projetos no Codecs

Abaixo, temos a seção de Projetos. Dentro do Codecs, toda aplicação que formos criar, toda ideia que formos conceber, precisa ser empacotada dentro de um projeto. Basicamente, o projeto é uma pasta no computador, onde os arquivos serão colocados.

Temos aqui um projeto de e-commerce (comércio eletrônico). Ele já está aberto. Vamos abri-lo para visualizarmos. Há três arquivos dentro deste projeto. O nome da pasta "e-commerce" é o nome exibido no projeto.

Também mantemos projetos de outras frentes no Codecs: o projeto do nosso assistente de onboarding (integração), o gerador de criativos e o distribuidor de demandas. Esses projetos fazem parte de outros cursos da Alura que desenvolvemos com o Codecs e que podem ser conferidos, caso seja de interesse. Há assistentes mais orientados a liderança e gestão; se fizer sentido, vale conferir esses cursos para entender o que cada um desses assistentes faz em conjunto com o Codecs.

Uma vez que temos um projeto — reforçando, é apenas essa pasta no computador — é nessa pasta que o Codecs terá acesso e manipulará os arquivos. Aqueles três arquivos que mostramos foram criados a partir de uma conversa na qual solicitamos a criação de um marketplace (mercado) móvel. O Codecs gerou o marketplace (mercado) e produziu esses três arquivos.

Solicitando um marketplace de forma genérica

Por que trouxemos essa conversa antes? Porque esse é um erro muito comum de quem está começando: ter várias ideias e querer construir algo junto com o LLM apenas com um pedido amplo, após ouvir que o LLM faz muitas coisas e é excelente para criar produtos. A solicitação costuma ser algo como: "Quero criar um e-commerce marketplace (mercado de comércio eletrônico) para que vendedores possam registrar seus produtos, como uma loja pequena".

Cada pessoa vai registrar uma loja nesse marketplace (mercado online), e o público dessas lojas são pessoas que compram pelo celular. Definimos que o celular é nosso objetivo, isto é, nossa plataforma alvo. Precisamos de registro de produtos, fotos, tamanhos, registro de lojas, carrinho de compras e cálculo de frete pelos Correios.

Apresentamos essa ideia geral — marketplace é algo muito comum e conhecido — e solicitamos: "crie para nós um marketplace com o qual vamos começar a ganhar dinheiro". O LLM então criou uma versão inicial e explicou o que fez.

Ele indicou ter implementado:

• Registro de lojas.
• Registro de produtos com foto e tamanhos.
• Vitrine de produtos.
• Carrinho de compras.
• Cálculo de frete pelos Correios.
• Arquivos principais (três), os mesmos presentes na pasta correspondente.

E deixou prontos:

• Design mobile-first (prioridade para dispositivos móveis).
• Painel de pessoa vendedora para criar lojas e produtos.
• Subtotal do carrinho e frete estimado.

Avaliando o resultado gerado pelo LLM

Enviamos nosso prompt (instrução) com uma ideia muito geral e o LLM criou essa solução. Era isso que tínhamos em mente? Provavelmente não. É possível que quiséssemos algo desse tipo — um mercado que mostra o número de lojas, o número de produtos publicados e os itens no carrinho — e, de fato, várias funções solicitadas estão presentes. Porém, essa não é a experiência que esperamos ao pensar em um marketplace. Geralmente lembramos de plataformas como Mercado Livre, Amazon, Shopee e Magalu, que também operam como marketplaces, e a experiência oferecida por elas é diferente.

Aqui houve uma mistura de conceitos e fluxos. Recebemos uma página index.html com opções como "registrar loja" e "registrar produto", "novo produto", além de um catálogo no qual podemos filtrar e adicionar ao carrinho. Há também a página do carrinho, que calcula o subtotal e o frete e exibe o subtotal. É possível informar um CEP para calcular o frete. Por exemplo, ao inserir "120, 54, 000" e acionar a função de cálculo, o sistema informou que o CEP não é válido. Ajustamos (havia um zero a mais) e, ainda assim, o sistema indicou que aquele CEP não existia. Ou seja, quase todas as funções foram implementadas.

Em essência, as funcionalidades solicitadas estão lá. O LLM afirmou ter adotado mobile-first e, ao inspecionarmos e simularmos um dispositivo móvel, observamos que a plataforma é responsiva: conforme a largura aumenta, cresce o número de colunas e a interface se adapta. Ainda assim, a experiência de marketplace que imaginávamos não era essa.

Destacando a importância do detalhamento e próximos passos

Esse é um dos grandes erros que cometemos ao ouvir falar de soluções como Codex, Cloud Code, Gemini e outros LLMs (Large Language Models, Modelos de Linguagem Grande). Ouvimos muitos elogios, surgem várias ideias de produto e ficamos tentados a simplesmente descrever de forma simplista para que “ele faça”. O LLM até implementa o que foi pedido, porém falta detalhamento. É nesse nível de detalhamento que precisamos ter cuidado.

Ao longo deste curso, veremos como estruturar melhor a especificação para detalhar tanto a experiência quanto a identidade da nossa marca, de modo que o LLM realize, de fato, o que desejamos. Trabalharemos com o Codex e faremos ajustes, oferecendo um repertório de estratégias para melhorar a sua solicitação de produto e para criar suas ideias em conjunto com o Codex.

Primeiros passos - Prototipação de ideias com IA

Reconhecendo limitações do prompt e propondo prototipagem

Já vimos que nosso prompt (instrução) no Codex não vai funcionar corretamente. Além disso, nossa ideia é algo que precisamos cuidar com atenção. Portanto, podemos pensar em como refiná-la, já que teremos de explorar e fornecer mais detalhes ao GPT (modelo de linguagem) para que crie nossa solução de fato. Como podemos fazer isso de maneira incremental? Faremos por meio de protótipos.

Já entendemos que apenas colocar, de forma simplista, no Codex um prompt (instrução) pedindo que ele implemente nossa ideia não vai funcionar. Ele criará algo cuja experiência não será a que queremos, a funcionalidade não será adequada e a estética e a tecnologia que buscamos não serão as certas. Falta refinamento nessa ideia, e teremos de organizar tudo isso. Para isso, vamos documentar.

Apresentando o harness e suas possibilidades

Como o nosso harness (ferramenta), isto é, a ferramenta que estamos usando — no nosso caso, o Codex — nos ajuda? Podemos usar também outras opções, como o Cloud Coworking, o Cloud Code, o Gemini ou o Antigravity. Independentemente do harness (ferramenta) escolhido, as funcionalidades básicas serão as mesmas.

O que podemos fazer para aproveitar o harness (ferramenta) na organização das nossas ideias? Ele tem acesso às pastas e aos arquivos do projeto. Nós fornecemos uma pasta no nosso computador à qual ele terá acesso, incluindo tudo que estiver dentro dela. Também há a criação de skills (habilidades) para documentar processos. Qualquer processo que tenhamos não precisa ser complicado.

Detalhando capacidades do harness

Como nosso harness (ferramenta) se organiza? Quais são as funcionalidades e capacidades que podemos extrair dele — no nosso caso, do Codex — para estruturar essa documentação? Em primeiro lugar, ele tem acesso às pastas e aos arquivos. Assim, a pasta que definimos como projeto é o local onde poderá ler e manipular todos os arquivos, e podemos aproveitar isso.

Também temos as skills (habilidades), que usaremos mais adiante. As skills (habilidades) são uma funcionalidade dos harnesses (ferramentas) para documentar processos e procedimentos. Dessa forma, o harness seguirá o passo a passo que nós definirmos dentro de um arquivo de texto.

Temos, ainda, um arquivo com as instruções do projeto. Cada harness (ferramenta) terá o seu. No caso do Codex, é o arquivo agents.md. Nós o criaremos para fornecer instruções e orientar nosso processo.

Definindo o documento de requisitos do produto e o nível de detalhamento

Temos o detalhamento das partes que queremos construir. Aqui entra, de fato, o PRD (Product Requirements Document — Documento de Requisitos do Produto), que vai detalhar os componentes e a experiência que desejamos criar. A documentação de produto, em geral, não é composta apenas pelo PRD, mas o inclui. Há uma série de documentos possíveis para detalhar toda a nossa ideia, e o PRD servirá como base para a criação do nosso sistema, definindo os requisitos do produto.

Podemos nos perguntar: qual nível de detalhamento precisamos colocar nesse documento? Que informações incluir? O que é importante e o que pode ficar de fora? Não queremos gastar tempo excessivo com documentação, porque queremos ver a ideia em prática e funcionando o quanto antes.

Avaliando níveis de detalhe e o papel do modelo de linguagem

Podemos pensar em três perspectivas, e tudo dependerá do nível de detalhamento adequado à etapa de desenvolvimento em que estivermos. Se estivermos em uma etapa mais inicial, provavelmente haverá itens que podemos deixar de fora. Se já tivermos nosso produto em produção, com clientes usando, precisaremos de uma documentação mais extensa, porque precisamos proteger para que nossa LLM (modelo de linguagem) não deixe de funcionar, não quebre algo ou não alucine.

Também precisamos considerar o quão bem nossa LLM (modelo de linguagem) consegue preencher lacunas, cobrindo os vazios que deixamos. É normal esquecer coisas. É normal tomarmos decisões e não as registrarmos, porque já estão decididas para nós e não sentimos necessidade de documentá-las. Ainda mais se estivermos trabalhando sozinhos — por que vamos documentar?

Aqui, precisamos lembrar que o Codex, ou qualquer harness (ferramenta) que estivermos usando, é um assistente: é como outra pessoa trabalhando conosco.

Se não documentarmos as decisões, se não escrevermos, a LLM não saberá que a decisão foi tomada. Em decisões assim, precisamos entender que, se não registrarmos, a LLM preencherá essa lacuna com algo. O quão boa ela é em fazer isso determinará quanto detalhamento podemos ou não colocar na documentação.

Delineando protótipo e produto mínimo viável

Nas etapas de desenvolvimento, podemos pensar primeiro no protótipo. Vamos testar e validar uma hipótese, usabilidade e fluxo de telas. Vamos apresentá-lo a um grupo reduzido, normalmente uma equipe interna ou algumas pessoas conhecidas, se trabalharmos sozinhos, para realizar um teste controlado e pequeno, a fim de entender se a ideia que temos faz sentido e se a experiência proposta faz sentido. Normalmente, aqui não há lógica de back-end (lado do servidor), não há armazenamento de dados e não há conexão com outras ferramentas. É um protótipo simples, geralmente apenas a casca para visualizar o fluxo funcionando. Nesse caso, a especificação pode ser menos elaborada: uma visão geral com o fluxo. Não é tão curta quanto um esboço, mas é uma visão mais geral do que queremos, das capacidades que queremos colocar nesse fluxo e de como uma parte se conecta com a outra. O foco do teste do protótipo é, principalmente, a usabilidade.

Se avançarmos para o MVP, ou Minimum Viable Product (Produto Mínimo Viável), aqui já abrimos para um público de pessoas usuárias reais; então já vai para produção, embora, em geral, a audiência ainda seja controlada e menor. Estamos validando se existe demanda no mundo real, no mercado, com pessoas usuárias pagando e utilizando de fato o produto. E prometemos, de forma simples, o funcionamento nos bastidores; ou seja, há um produto que, de alguma maneira, entregará o que foi prometido. Aqui precisamos fazer uma entrega real; não é apenas mostrar aproximadamente o que queremos. Precisamos cumprir, pois há pessoas clientes reais. Também teremos dados reais para testar as hipóteses. Nesse caso, já precisamos de uma documentação um pouco maior: mais regras de negócio, mais segurança e a definição de onde estarão os dados. Mesmo que seja um sistema pequeno, é um sistema on-line com a pessoa cliente utilizando. Isso mudará a forma como vamos documentar.

Escalando para produção e organizando a evolução

Na terceira fase, de produção, colocamos aqui como o produto “final”. “Final” entre aspas porque dificilmente entregaremos um produto e nunca mais o revisaremos. Ele é revisitado e revisado constantemente; portanto, não é exatamente final, mas podemos considerá-lo um produto maduro. Aqui já precisamos entregar valor de forma sustentável. Passamos a nos preocupar com escala porque o público é aberto. Já não controlamos quem pode ou não pode usar. Queremos a maior quantidade possível de pessoas utilizando o produto. Devemos ter uma maneira robusta de lidar com erros, observar desempenho, segurança e suporte. Tudo isso precisa estar muito mais polido.

Aqui entra o relacionado a development (desenvolvimento). Nessa fase de produtos finais, em produção, é cada vez mais comum utilizar algum tipo de abordagem de development (desenvolvimento), na qual mantemos uma base de documentação muito grande para cada funcionalidade, para cada parte do sistema, para que a IA possa executar corretamente. Mesmo que vá recriar todo o código, estará bem detalhado o que cada parte do sistema fará. Assim, a documentação é muito mais extensa do que nas fases anteriores. Porque, novamente, se algo sair errado, nossa reputação e nossa receita estão em jogo. Precisamos ter muito mais cuidado com a forma como vamos evoluir esse sistema. E, com a IA, conseguimos evoluir muito rápido. A dificuldade é como evoluir muito rápido sem que as coisas quebrem. Para isso, a pessoa especialista de VM vem organizar isso também.

Neste cenário, utilizando o harness (estrutura de testes) e essas especificações com as quais vamos trabalhar, começaremos pela ideia do protótipo, tentando nos aproximar do MVP. Não vamos chegar a um sistema em produção, mas você poderá organizar as ideias, pensar em como ele irá evoluir e continuar estudando a partir daí.

Sobre o curso Codex: prototipação de produtos digitais

O curso Codex: prototipação de produtos digitais possui 96 minutos de vídeos, em um total de 35 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:

• Primeiros passos
• Do PRD ao protótipo
• Especificações de design
• Testes e iteração
• Coleta de dados e análise