00:00:00Existe uma camada no antigo processo de construção que não existe mais.
00:00:03E a maioria das equipes ainda não descobriu pelo que substituí-la, então continuam
00:00:06seguindo o modelo antigo por força do hábito.
00:00:08Esta semana, Jenny Wen publicou uma entrevista no podcast do Lenny.
00:00:11Ela é a chefe de design do Claude na Anthropic e, antes disso, foi diretora de design
00:00:16no Figma.
00:00:17No episódio, ela falou sobre como o processo de design morreu e o que está ocupando
00:00:21o seu lugar.
00:00:22Então, vamos analisar o que mudou, o porquê, e depois percorrer o processo exato
00:00:26que o substituiu.
00:00:27Para entender o que o substituiu, você precisa entender por que ele existia.
00:00:31No processo antigo, primeiro você definia os requisitos, depois um designer os levava para o
00:00:35Figma e criava um mock-up de como o aplicativo deveria ser.
00:00:38Aquele arquivo do Figma era o documento de entrega entre o que alguém queria e o que era construído.
00:00:43Um engenheiro front-end então converteria esse arquivo em código.
00:00:46Enquanto isso, o engenheiro back-end construía em paralelo, pois uma especificação de API era definida
00:00:51antecipadamente, permitindo que ambos os lados avançassem ao mesmo tempo e tudo se conectasse no final.
00:00:55Jenny descreve isso como um processo que os designers tratavam como um ritual.
00:00:58Esse era o padrão em toda a indústria.
00:01:00A maioria das pessoas, ao explicar por que isso está mudando, esquece o motivo de sua existência original.
00:01:05Simon Willison, um desenvolvedor que escreve um dos blogs técnicos mais lidos do
00:01:09setor, resumiu a palestra de Jenny em Berlim em janeiro e adicionou o insight que a fala dela sugere,
00:01:14mas não diz diretamente.
00:01:16Construir com IA reduz significativamente o custo de construir a coisa errada.
00:01:19Antes da IA, uma direção falha significava meses de tempo de engenharia desperdiçados.
00:01:23Um pequeno erro no front-end significava 10 vezes mais trabalho durante a implementação.
00:01:27Por isso, as equipes justificavam cada etapa.
00:01:28A pesquisa, as personas, as jornadas do usuário, os wireframes, o documento de especificação.
00:01:33Tudo isso era uma proteção contra construir a coisa errada em escala.
00:01:36Então, o que realmente mudou no processo?
00:01:38A velocidade da engenharia mudou primeiro.
00:01:40E mudou mais rápido do que a maioria das pessoas conseguiu processar.
00:01:42Jenny disse que, há alguns anos, 60% a 70% do seu tempo como designer era gasto criando mocks e protótipos.
00:01:48Agora, são 30% a 40%.
00:01:49Ela não decidiu trabalhar de forma diferente.
00:01:51Os engenheiros ao seu redor começaram a rodar múltiplos agentes em paralelo e, de repente,
00:01:55o gargalo não era mais a engenharia.
00:01:58A engenharia mudou primeiro e o design foi forçado a acompanhar.
00:02:00Os cronogramas de visão também mudaram.
00:02:02O design costumava produzir visões para daqui a 2 ou 5 anos.
00:02:04Agora a tecnologia avança tão rápido que um escopo realista é de 3 a 6 meses.
00:02:09E não é necessariamente mais uma apresentação de slides.
00:02:11É um protótipo que aponta uma direção para as pessoas.
00:02:13O mesmo aconteceu com a etapa de tradução.
00:02:15Quando um agente pode pegar um documento de requisitos e construir uma interface funcional, não há
00:02:19camada de tradução.
00:02:20O agente escreve o código.
00:02:22Não há arquivo do Figma para traduzir porque nunca chega a existir um arquivo do Figma.
00:02:25Além disso, se você está gostando do conteúdo, considere clicar no botão de hype, pois isso nos ajuda
00:02:29a criar mais conteúdos como este e a alcançar mais pessoas.
00:02:33Quando pegamos trabalhos de clientes, esta é exatamente a mudança que tivemos que fazer.
00:02:36O processo de design mudou, mas a parte que não mudou foram os requisitos.
00:02:40Requisitos ruins desperdiçam toda a construção.
00:02:42E a maioria das equipes pula direto para a especificação.
00:02:44Essa é a ordem errada.
00:02:45Ao construir um protótipo, você não precisa de uma stack tecnológica ou especificação de API.
00:02:48Você precisa saber o suficiente para construir algo que tenha a aparência e a sensação do produto real,
00:02:52para que possa apresentá-lo a alguém e obter um sim ou um não.
00:02:56Portanto, antes de tocar no protótipo, comece pelos atores.
00:02:58Um ator é uma pessoa que interage com o sistema.
00:03:01Uma pessoa específica com um objetivo específico.
00:03:03Pois quem o utiliza determina o que o sistema precisa fazer.
00:03:06Se você tem alguém que envia conteúdo e alguém que o aprova, são duas
00:03:10interfaces diferentes com duas telas iniciais diferentes.
00:03:12Em seguida, veja onde as visualizações se dividem.
00:03:13Na maioria dos produtos, em algum ponto, dois atores diferentes acessam a mesma URL e veem coisas
00:03:18completamente diferentes.
00:03:19Um administrador vê um painel de gerenciamento.
00:03:21Um usuário comum vê seu dashboard.
00:03:22A última coisa são as restrições.
00:03:24Não diga ao agente quais ferramentas usar.
00:03:26Diga o que ele não pode fazer e quanto não pode custar.
00:03:28Isso também tornará as decisões técnicas muito mais fáceis futuramente.
00:03:32Nós implementamos todas essas regras específicas neste prompt de criação de PRD, que basicamente
00:03:37funciona como seu entrevistador de PRD, fazendo uma série de
00:03:42perguntas diferentes seguindo as regras.
00:03:44E, no final, você terá um arquivo markdown de PRD, que será usado nas etapas
00:03:48posteriores do processo.
00:03:49Esse arquivo PRD é a base sobre a qual todo o resto é construído.
00:03:52O próximo passo é transformá-lo na estrutura para o front-end.
00:03:55Para isso, usamos este prompt de camada, que basicamente diz ao agente para olhar o PRD e
00:04:00gerar duas coisas (lembrando que não é um PRD completo com todos os requisitos técnicos).
00:04:04Ele pede para produzir as páginas e os modais que farão parte do seu protótipo e,
00:04:08em seguida, os fluxos de usuário.
00:04:09Obviamente, páginas e modais são importantes para a estrutura, para que tudo o que o agente
00:04:14precisa implementar no front-end seja planejado com antecedência.
00:04:17Temos falado constantemente sobre planejar antes de agir e por que isso é tão importante para
00:04:21o agente e a janela de contexto, então não precisamos nos aprofundar nisso.
00:04:24Mas, com os fluxos de usuário, é fundamental definir as ações de cada ator.
00:04:28Já que estamos focando nos próprios atores e não nas funcionalidades, é importante
00:04:32definir os fluxos de usuário para que o agente possa implementar os estados de interação
00:04:36e a navegação adequada para o protótipo completo da UI.
00:04:40Assim, terminamos com dois arquivos onde o architecture.md contém as páginas, os modais e os fluxos
00:04:45que discutimos.
00:04:46Depois disso, pedimos para instalar um app Next.js, que é a stack tecnológica que
00:04:50normalmente usamos: Next.js com Supabase.
00:04:53E foi isto que ele criou.
00:04:55No geral, o design parece ótimo, mas há um motivo específico para isso.
00:04:58Além disso, não foi mencionado antes, mas o projeto era uma plataforma comunitária com canais,
00:05:03produtos e cursos.
00:05:04Existem basicamente dois atores: o membro e o criador, onde o criador
00:05:08tem todas as funcionalidades administrativas, como criar um canal, adicionar um produto
00:05:12ou fazer upload de um curso, além de visualizar diferentes estatísticas.
00:05:15Em nossa opinião, para o primeiro protótipo criado, o design ficou excelente.
00:05:19Mas a UX não está tão boa, pois normalmente não queremos um dashboard assim.
00:05:23E este é exatamente o ponto.
00:05:24Esse tipo de correção costumava levar dias; aqui, leva minutos.
00:05:27Porque a IA pode fazer essas modificações muito, muito rapidamente.
00:05:30E como não há back-end aqui, ela também não precisa lidar com toda aquela complexidade extra,
00:05:34é apenas o protótipo do front-end.
00:05:36Normalmente, a IA não cria sites e interfaces tão bonitos assim.
00:05:40E a razão pela qual este ficou bom é porque usamos esta habilidade de front-end de propósito geral
00:05:44que a Anthropic disponibilizou em um de seus blogs.
00:05:46Recomendamos fortemente o uso disso antes de implementar sua UI.
00:05:50Basta salvá-la como um comando de atalho ou uma habilidade para que seu agente possa usá-la.
00:05:53Agora, se você estiver trabalhando para um cliente, tudo o que precisa fazer é mostrar este protótipo,
00:05:57que é totalmente funcional em termos de recursos com dados fictícios, já que não vamos
00:06:01mexer com banco de dados agora.
00:06:02Você mostra isso ao seu cliente, obtém a aprovação e, se não, faz as alterações e então
00:06:06prossegue com o restante da construção.
00:06:08Essas listas de tarefas são uma das razões pelas quais agora podemos pedir a esses agentes para criarem
00:06:12protótipos totalmente funcionais.
00:06:14É por causa dessas listas de tarefas, da persistência das tarefas e porque tudo
00:06:17está estruturado.
00:06:18É por isso que criar aquele arquivo architecture.md foi tão importante, pois permite que o
00:06:23agente crie uma lista de tarefas perfeitamente otimizada para não alucinar.
00:06:28Depois disso, passamos para a implementação do back-end.
00:06:30Geralmente, há duas coisas que você pode fazer.
00:06:32Você pode manter o Next.js, deixar o front-end separado nele e implementar o
00:06:36back-end como um serviço Python separado.
00:06:39Mas isso depende do tipo de aplicação com a qual você está trabalhando.
00:06:42Para a maioria dos projetos que vocês provavelmente construirão, o Next.js será suficiente.
00:06:46Você precisa especificamente de um back-end Python separado quando necessita de bibliotecas extensas
00:06:50que não estão disponíveis no Next.js ou se precisar de uma orquestração séria de jobs em segundo plano
00:06:55para otimizar seu site ou suas funções.
00:06:57Nesse caso, você pode precisar de um back-end separado.
00:06:59Caso contrário, o back-end do Next.js é praticamente tudo o que você vai precisar.
00:07:03Antes de tocarmos no back-end, precisamos saber o que o front-end realmente precisa dele.
00:07:07Então, fizemos o agente analisar o código do front-end, o PRD e o arquivo de arquitetura e escrever
00:07:11uma especificação de API.
00:07:12Depois disso, pedimos para usar os três documentos para criar o esquema completo do Supabase, pois
00:07:17estamos usando Supabase com Next.js no front-end.
00:07:20Basicamente, ele precisa criar os esquemas que abrigarão os dados do app.
00:07:25Normalmente, se você pedir ao seu agente, ele dirá para você ir lá, pegar suas chaves de API
00:07:28do banco de dados e colar manualmente consultas SQL para criar as tabelas.
00:07:33Mas, em vez disso, você deveria usar o MCP do Supabase.
00:07:36Sempre tente usar um MCP para qualquer serviço com o qual esteja trabalhando, pois isso automatiza
00:07:40muita coisa.
00:07:41Por exemplo, nem precisamos olhar para os projetos aqui.
00:07:43Ele criou automaticamente o projeto, executou as consultas para o esquema e rodou automaticamente
00:07:48as migrações.
00:07:49Então, basicamente, não tivemos que fazer nada.
00:07:51Após o banco de dados ter sido configurado, você conectará o front-end ao banco de dados.
00:07:55Aqui, novamente, há uma distinção clara.
00:07:57Você não precisa conectar o back-end ao banco de dados porque ele já está integrado
00:08:00ao front-end.
00:08:01O front-end fala diretamente com o banco de dados, tornando a integração e a complexidade geral
00:08:06muito mais simples.
00:08:07Atualmente, somos parceiros da Warp neste vídeo, e eles lançaram recentemente o OZ, que
00:08:11é uma plataforma de orquestração para diferentes agentes na nuvem.
00:08:14Esses agentes na nuvem são úteis para tarefas que você quer apenas delegar sabendo que
00:08:19o agente será capaz de concluir por conta própria.
00:08:21Até agora, o agente tinha conectado o front-end ao banco de dados e o app estava basicamente
00:08:26funcionando de acordo com isso.
00:08:27Mas para adicionar coisas como processamento de pagamentos, novas notificações, rate limiting ou analytics
00:08:32no site, precisamos de uma camada de API de back-end dedicada para integrar tudo isso.
00:08:37Para isso, criamos um ambiente usando o OZ e rodamos um agente de nuvem, pedindo para ele construir
00:08:41essa camada de back-end dedicada.
00:08:43E após cerca de 15 minutos, a tarefa foi concluída e tudo estava pronto.
00:08:47Para tornar isso funcional e começar a aceitar usuários, tudo o que restava agora era
00:08:51apenas a autenticação do Google, integração com Stripe e alguns pequenos detalhes que precisávamos ajustar.
00:08:56Agora você viu o processo completo e os prompts estiveram ali na tela.
00:09:00Mas se você quiser todos esses prompts como um fluxo de trabalho passo a passo para seguir em
00:09:04seus próprios projetos, estamos colocando isso no AI Labs Pro.
00:09:06Para quem não sabe, é a nossa comunidade onde você recebe templates prontos para usar que pode
00:09:10aplicar diretamente em seus projetos, tanto para este vídeo quanto para os anteriores.
00:09:14Se você encontrou valor no que fazemos e quer apoiar o canal, esta é a melhor maneira
00:09:18de fazer isso.
00:09:19O link está na descrição.
00:09:20Isso nos traz ao final deste vídeo.
00:09:22Se você quiser apoiar o canal e nos ajudar a continuar fazendo vídeos como este, você pode
00:09:26fazer isso usando o botão "Valeu demais" abaixo.
00:09:28Como sempre, obrigado por assistir e vejo você no próximo.