Agora eu projeto mais com Claude do que com Figma
(blog.janestreet.com)- Em vez de escrever documentos de especificação e fazer mockups no Figma, houve uma mudança para um fluxo de design em que as ideias são transformadas diretamente em funcionalidades protótipo que realmente funcionam
- No passado, havia ceticismo em relação a LLMs como Copilot, Cursor e Gemini, mas após entrar na Jane Street ficou claro que o suporte de IA é essencial
- O Claude permite iteração gratuita e ilimitada, então mesmo mudando de ideia 50 vezes ele possibilita melhorias detalhadas como ajustes no botão Submit, atalhos de teclado e textos sem reclamar
- Designers também podem, como engenheiros, criar por conta própria uma prova de conceito funcional (POC) para que outras pessoas a experimentem e avaliem
- Ao concentrar todo o esforço no próprio entregável real, isso leva a um novo modelo de colaboração que elimina tarefas intermediárias e acessórias
Da descrença em LLMs à mudança de postura
- Durante muito tempo houve ceticismo em relação a LLMs, e toda vez que eram usados o resultado era decepcionante
- No ano passado, ao tentar modificar um jogo feito pessoalmente, foram testados Copilot e Cursor, mas nenhum dos dois conseguiu gerar mudanças funcionais
- No emprego anterior, foi usado o Gemini para criar esboços de product brief e wireframes, mas tudo foi descartado
- As áreas em que LLMs foram testados eram justamente aquelas em que já havia domínio, e os resultados eram piores do que fazer diretamente
- Depois de entrar na Jane Street no verão passado, ficou evidente que o suporte de IA era indispensável
- Porque havia muitas áreas novas e ainda pouco dominadas, como OCaml e Bonsai
- A maior surpresa foi a mudança no fluxo de trabalho de design, justamente a área em que havia mais domínio
Fluxo de trabalho centrado em protótipos
- Em vez de documentos de especificação, mockups no Figma, textos de proposta e revisões de implementação com desenvolvedores, a abordagem passou a ser construir diretamente funcionalidades protótipo que executam exatamente o comportamento pretendido
-
Fluxo de trabalho real
- Escrever o problema e a proposta em texto
- Abrir o editor, rodar build, servidor e Claude, e usar a descrição escrita como prompt
- Fazer primeiro a funcionalidade básica funcionar para provar a viabilidade
- Iterar o quanto for necessário
- Enviar as mudanças para o ambiente de desenvolvimento e coletar opiniões dos usuários
- Submeter uma feature (equivalente a um pull request na empresa) com a aparência e o comportamento pretendidos
- Um protótipo dentro da base de código real foi melhor do que mockups e documentos em quase todos os aspectos
Caso do protótipo de entrada JSQL
- Recentemente foi criado um protótipo que adiciona prompting com LLM à entrada JSQL
- JSQL é um dialeto interno de SQL usado em ferramentas para vários tipos de usuários
- O protótipo realmente funcionava, e foi usado, testado e incorporado ao dia a dia por alguns dias
- O Claude permite iteração gratuita e ilimitada, então não se importa se na 50ª vez houver mudança de ideia ou pedido de pequenos ajustes
- Refinar o botão Submit, adicionar atalhos de teclado, ajustar textos, mexer no prompt, adicionar mensagens de confirmação generativas
- Melhorias que, no emprego anterior, teriam exigido dias ou semanas de vai e vem entre engenharia e design, ou talvez nem acontecessem
- Todo o esforço vai para melhorar o entregável real, e não para tarefas acessórias como criar componentes no Figma ou formatar documentos
Como esse fluxo se consolidou
- Levou tempo para chegar a essa forma de trabalhar
- No início, a IA era usada apenas para tarefas pequenas, como corrigir pequenos defeitos de UX
- Para ideias maiores, ainda se recorria a Figma e documentos, e tentar com Claude levava ao fracasso
- Nos últimos dois meses, as situações em que se recorria ao Figma diminuíram drasticamente
- Combinando melhorias dos modelos, aumento de habilidade pessoal e escolha adequada de escopo, a IA passou a funcionar também em trabalhos maiores
- Além dos prompts para JSQL, houve vários protótipos voltados ao usuário, ao modelo de dados e a mudanças em bibliotecas, alguns com diffs de mais de 2000 linhas
- Em alguns casos, o design era feito no Figma e depois o protótipo interativo era implementado; em outros, alguns apps novos pularam completamente o Figma e iteraram o design visual com Claude desde o início
O poder que isso dá aos designers
- Engenheiros podem ter uma ideia e criar diretamente uma prova de conceito funcional, mas designers normalmente precisam convencer outras pessoas
- Uma ideia como prompting direto de LLM dentro da entrada JSQL pode nem ter viabilidade clara no início, então pedir para outra pessoa prototipá-la pode ser desperdício de tempo
- Também pode ser uma proposta que não atende claramente a uma necessidade do usuário
- Ao implementar a ideia de fato com Claude, fica muito mais fácil para outras pessoas testarem e avaliarem diretamente
O desafio da forma de revisão
- A desvantagem é que os revisores acabam recebendo uma funcionalidade já pronta
- Surge a dúvida se eles passam a apenas revisar o código, sem poder contribuir para a própria funcionalidade
- Isso é semelhante ao que acontece em design quando se recebe um wireframe detalhado do PM com o pedido de apenas “deixar bonito”
- A proposta deve ser o mais clara e completa possível, mas a expectativa é que colegas engenheiros também iterem junto no espaço de design, como fariam com um mockup no Figma
-
A solução atual
- A saída tem sido encarar a feature de forma diferente e incluir uma orientação curta na descrição
- O protótipo é um documento de proposta vivo, o código é descartável, e o papel do revisor é dar feedback sobre design e experiência do usuário
- No fim, o revisor assume a ideia e a implementa em uma feature separada, usando o protótipo como referência, mas possuindo diretamente o código de produção
- Ainda se está buscando entender o que faz sentido e o que parece uma boa solução
Preocupações e uma tensão familiar
- Existe o receio de que projetar com Claude leve a sair de um pensamento flexível e criativo e ficar preso a um pensamento iterativo limitado ao que se acredita que Claude consegue produzir
- Isso pode funcionar bem para ferramentas maduras com mudanças incrementais, mas ao lidar com algo novo pode fazer boas ideias passarem despercebidas
- Essa é uma tensão conhecida, ligada ao debate de 2011 sobre “designers devem escrever código?”
- Os críticos argumentavam que, ao começar a programar, fica mais difícil fazer grandes mudanças nas ideias
- Ainda assim, como sempre houve gosto tanto por criar sites quanto por programar, o código continuou presente
- Quando frameworks frontend como React se tornaram comuns e o desenvolvimento ficou mais complexo, a escolha foi pela especialização
- Projetos pessoais ainda são feitos em React, o que ajuda na comunicação com desenvolvedores
- A maior parte do tempo de trabalho era dedicada a Figma e documentação
- Se a entrada na Jane Street tivesse acontecido antes dos LLMs, provavelmente haveria um mergulho ainda mais profundo no Figma
- Havia alguma experiência com JavaScript, mas OCaml e Bonsai eram completamente novos, o que faria a contribuição técnica parecer fora de alcance
- Em vez disso, foi possível voltar a construir o entregável real, e retornar a esse meio pareceu empolgante, além de ampliar muito a sensação de liberdade para tentar qualquer coisa
1 comentários
Comentários do Hacker News
A área de negócios já costuma trazer requisitos na forma da solução que eles mesmos imaginaram, e geralmente é algo tipo uma máquina de Rube Goldberg, então é preciso fazer engenharia reversa na conversa para chegar ao requisito real
Daqui para frente, parece que vão trazer soluções já “prontas” e “funcionando”, e estarão menos abertos à ideia de olhar o design e a arquitetura de forma ampla
Vai virar algo como: “é só fazer assim, ué. Já está quase pronto, por que precisamos de X semanas de trabalho?”
A desvantagem é que a área de negócios não entende por que não dá para simplesmente colocar aquele app em produção do jeito que está
A pressão de “dá para ir mais rápido com IA” aumenta, e no fim isso provavelmente vai depender da dinâmica saudável da organização
A vantagem é que a ideia já foi validada de forma muito mais completa do que num rabisco de guardanapo
O Claude provavelmente já perguntou sobre casos de borda e decisões de design, e em algum momento devem até ter dito explicitamente algo como “não se preocupe com isso, só assuma” ou “usei algumas vezes e essa interação não ficou boa, faz de outro jeito”
Agora a pressão de “qual é o problema? é só colocar em produção” é forte, burra e desmoralizante, então é quase uma perda líquida, mas quando isso estabilizar pode acabar sendo um ganho líquido para projetos futuros
E esses ajustes pequenos são coisas como o layout quebrar se o navegador não tiver exatamente 1920 px de largura, filtros e ordenação falharem de vez em quando, ou novos valores não serem atualizados corretamente no app depois de certas ações
Independentemente do problema, a área de negócios acha que já fez 95% do trabalho e presume de antemão que “um desenvolvedor experiente resolve isso rapidinho”
As pessoas se acostumam com o resultado que já têm e passam a aceitar com mais dificuldade as mudanças feitas numa nova mixagem profissional
Existem PMs, CSMs e TAMs que têm faro para traduzir o problema do cliente em funcionalidades de produto com boa usabilidade, mas quando se pula a definição do problema e se faz outra área funcional construir a solução, isso geralmente vira uma catástrofe que desperdiça muita engenharia e outros recursos
Quando alguém chega com uma solução pronta, há um grande risco de só descobrir, depois de meses construindo software operável, que o cliente odeia aquilo, que não resolve o problema ou que criou problemas novos
Não onde trabalho hoje, mas em um lugar onde trabalhei antes, e foi para produção mesmo com perda de dados e problemas de segurança
Pelo que sei, a Jane Street é investidora da Anthropic, então é bom levar isso em conta
Também tem o fato de que, em julho de 2025, a SEBI, reguladora do mercado de capitais da Índia, alegou que a Jane Street fez manipulação de mercado usando várias entidades e a proibiu de acessar o mercado
Cofres enormes devem precisar de muitos dashboards
Aqui, o designer parece estar seguindo uma abordagem errada e caindo numa espécie de admiração por engenharia, querendo tornar o protótipo o mais profundo e realista possível
Mas essa não é a parte mais importante do trabalho de design
O mais importante é garantir que a coisa certa esteja sendo construída
Perguntas como “por que precisamos de uma caixa de entrada JSQL? o que a pessoa realmente quer? que outras formas existem?” muitas vezes são resolvidas melhor com esboços em papel e caneta, reuniões, observação e discussão
Isso é melhor do que afunilar cedo demais para um design específico e entrar em discussões do tipo se o botão fica à esquerda ou à direita, ou como exatamente o LLM deve se comportar
Embora, claro, talvez seja exatamente isso que eles queiram que você pense
Às vezes dá para ver isso
No estado atual, os LLMs não conseguem enxergar além da repetição, então eu é que preciso pensar fora da caixa e dizer “e se olhássemos por este ângulo?”, e só então de repente aparece uma nova forma de design
Às vezes é preciso fazer um fluxograma para tentar fazer o LLM enxergar além da etapa em que ele está
Quando dizem que “o Claude me deu iteração grátis e ilimitada, sem se importar se eu mudasse de ideia pela 50ª vez ou pedisse pequenos ajustes”, isso quer dizer que a pessoa não paga pelo Claude?
Estúdios pequenos de design também funcionam de forma parecida, e muitas vezes não cobram por hora como desenvolvedores
Respondi honestamente que sou realmente ruim em design e também tenho dificuldade para extrapolar sistemas de design
É muito difícil chegar a um ponto que pareça aceitável e, no processo, quase sempre acabo piorando tudo
A designer da entrevista levou isso para o lado pessoal e começou a me pressionar
Já aconteceu algo parecido antes
Designers odiavam as perguntas constantes sobre como as coisas deveriam parecer e queriam uma entrega única, como se depois da passagem de bastão o assunto estivesse encerrado
Em agências de marketing e publicidade eu também tinha que brigar repetidamente para conseguir exemplos de como coisas não cobertas na especificação de design deveriam parecer
Não estou dizendo que eu estava certo, mas isso é um grande calcanhar de Aquiles para mim
Então, quando ouço “grátis, iteração ilimitada, sem se importar”, penso antes em tempo e paciência do que em dinheiro
O Bolt que eu uso para prototipagem não fica irritado
Talvez ele não produza o melhor design possível, mas é muito melhor do que eu conseguiria fazer, e no fim dá para passar para um designer de verdade deixar melhor
Até lá, não preciso me preocupar em irritar ninguém
Tenho usado o Claude Design no front-end
O visual e a sensação do resultado são bons o bastante, mas os designs frequentemente parecem parecidos entre si e, em geral, seguem padrões batidos da web moderna
Fico curioso se alguém já tentou fazer experiências criativas fora do convencional com isso
Já investi cerca de 3 semanas até agora e ainda não está concluído, mas dá para pegar a ideia
Assim como existia boilerplate de SaaS na última década, também existe boilerplate de LLM treinado na internet
Mesmo assim, se você meter a mão o suficiente, ainda dá para fazer qualquer coisa
É interessante como ele acerta quando você dá requisitos, e faz escolhas seguras quando você não dá direção
Se você vai avaliar a estética da saída e a experiência do usuário/conteúdo, mas quase não dá prompts voltados à estética, vai acabar recebendo só os padrões seguros
Ele faz bem designs com cara de cópia de bootstrap/tailwind, mas é preciso empurrar conscientemente para além disso
Em páginas web simples, comecei a colocar o estilo visual como único foco das iterações iniciais
Basta instruir de forma específica para que não pareça algo padronizado e dar exemplos do estilo de site que você quer
Se você insistir um pouco, ele parece um pouco mais criativo, mas isso exige trabalho de prompt
Ele me foi recomendado por designers muito respeitados e experientes, e eles agora fazem protótipos quase inteiramente no Claude e, se gostarem, refinam no Figma
Pedir uma UI genérica sem um prompt de estilo detalhado e receber um design genérico é algo totalmente esperado
A vantagem aqui é o designer aprender a programar
Sempre achei estranho que designers moldassem software sem saber como software é feito
Para constar, eu também sou designer
Só que projetar em código é uma abordagem technology-first
Se o objetivo do design é moldar o resultado para os propósitos humanos, também dá para argumentar que é melhor não começar pelas regras rígidas do código
Não por causa de resultados bonitos, mas para empurrar o pensamento adiante ainda é difícil superar caneta e papel
Agora que dá para programar praticamente por voz, estou voltando para vibe coding e para criar produtos, e está sendo ótimo
Meu chefe ainda está entendendo essa nova situação, mas a antiga separação de papéis parece estar começando a morrer
Acho que estar na interseção é a melhor posição agora
Sinto que minha vida inteira me preparou para este momento
Para designers, deve ser parecido com um Figma em que você olha o resultado e faz ajustes por linguagem em vez de um editor visual
Minha esposa trabalha como gerente de produto em uma FAANG, e a equipe dela depende fortemente de vibe coding com IA para criar pedaços de software que antes fariam em Word ou Excel
Eles não estão aprendendo a programar e não olham para o código nem por um segundo
A abordagem de que “o protótipo é um documento vivo de proposta, o código pode ser descartado, e o trabalho do revisor é dar feedback sobre o design e a experiência do usuário
No fim, o revisor assume a ideia e a implementa como uma funcionalidade separada, usando o protótipo como referência, mas sendo dono do código de produção” resolve um problema que eu tinha em todos os POCs
É uma forma muito boa de trabalhar
Ao lidar com uma questão específica de um produto específico, é fácil chamar isso de “documento de proposta”
Mas ainda existem muitos designers usando Figma para definir e manter design systems em produtos e plataformas inteiras, e, nesse caso, o Figma é a fonte da verdade
Nossa equipe também trabalha assim, e eu sou engenheiro de front-end; sinceramente, sinto muita falta do jeito antigo
Como especificações escritas foram substituídas por protótipos funcionais, agora existe uma carga cognitiva extra de ter que ler o código e decidir quais mudanças eram intencionais e quais ruídos devem ser descartados
Tenho que receber um PR gerado e decidir se faço as alterações necessárias ou se reconstruo tudo do zero, e há atrito em qualquer um dos caminhos
Já aconteceu de serem geradas várias mudanças não intencionais, e depois que eu perdi tempo reimplementando e migrando tudo, mais tarde veio um “ah, desculpa, isso não era para mudar”
Entendo o ponto de dar autonomia, mas isso tirou parte da diversão que eu sentia no trabalho antigo e transformou em dor de cabeça
O pessoal de design e produto faz vibe design/coding de recursos ou experiências com Claude e cria protótipos rapidamente, levando isso para clientes com o mínimo de tempo de engenharia para obter feedback
Isso é excelente
Mas talvez surpreenda que, no geral, isso não tenha ajudado muito a lançar mais rápido
Acho que o motivo é que perdemos pensamento no processo
Uma parte nada pequena do raciocínio agora foi terceirizada para o modelo de linguagem
Ele tapa os buracos do prompt e preenche comportamentos não especificados com alucinações
Coisas em que antes se parava para pensar “isso não encaixa muito bem”, “como vou transmitir essa ideia”, “o que acontece neste caso” desapareceram, e agora esses detalhes ficam para depois de já ter sido construído
Claro, dá para melhorar o processo e refletir sobre como aproveitar melhor essa técnica nova, mas se é melhor do que antes, não sei
Está entrando em declínio
Agora o pessoal de back-end também faz front-end
Essa é a ilusão
Você fica olhando assembly gerado por compilador? Não fica
Então por que está olhando para este código?
Nós apenas elevamos a camada de abstração
Eu também uso bastante essa mesma abordagem
Mesmo antes da IA, eu já fazia isso manualmente
Primeiro eu sentava com o usuário só com caneta e papel; depois criava rapidamente um POC ou demo de frontend, deixava o usuário mexer e então ajustava até funcionar do jeito que ele queria
Para mim, criar em código uma demo rápida de frontend, sem qualidade de produção, muitas vezes já era mais rápido do que construir interações precisas no Figma
Como era possível ter interação completa, eu conseguia capturar muito mais casos de borda da experiência do usuário
Agora, com o Claude Code, ficou mais rápido criar protótipos descartáveis, mas a diferença não é tão enorme assim
Como 80% do trabalho é discutir com o usuário e pensar em como aquilo deve funcionar, o Claude basicamente corta pela metade os 20% restantes em comparação com eu mesmo fazer tudo rapidamente
A primeira versão sai mais rápido, mas as iterações ficam mais lentas quando eu ainda não entendi tudo completamente
Edwin, que bom ver você publicando por aqui
Lembro de termos participado juntos de um hackathon por volta de 2012/2013
A capacidade de chegar mais rápido a um protótipo funcional é algo muito poderoso, mesmo que exista a tentação de simplesmente colocar no ar ideias ainda inacabadas
Requisitos de design e experiência do usuário ganham muito quando é possível ir além de storyboards e wireframes e realmente tocar e vivenciar o fluxo