"Acho que preciso ir me deitar um pouco."

• Impressões após testar a demo do Make Real, da TLDraw
• Ferramenta que usa IA para transformar desenhos em software funcional
  • Usa o GPT-4V da OpenAI para converter imagens vetoriais em HTML/TailWind CSS e Javascript

[GN⁺]

Opiniões no Hacker News

• Aqui é o Steve, da tldraw. Desculpem, isto é um projeto de brinquedo com padrões de segurança péssimos. Se quiserem rodar localmente ou ver o código-fonte, está aqui: https://github.com/tldraw/draw-a-ui
  Outros exemplos podem ser vistos em https://twitter.com/tldraw. Posso responder perguntas sobre a tldraw ou este projeto. Não é algo que vá tirar o trabalho de alguém, mas é muito divertido de brincar, e há um exemplo mais complexo aqui: https://twitter.com/tldraw/status/1725083976392437894

  • Vocês precisam lançar isso imediatamente. É um produto brilhante de verdade; cobrem US$ 5 por mês e façam o usuário trazer a própria chave da OpenAI
    Também tenho um servidor de licenças que acabei de publicar sob licença MIT. Foi escrito em Elixir e roda https://go.robocoder.app. Se precisar de ajuda para configurar, pode entrar em contato: https://github.com/emcmanus/robocoder-server/
  • Steve, para onde mando o dinheiro? Brincadeiras à parte, é algo bem convincente. Pode ser um brinquedo, mas todo mundo está se divertindo desse jeito
  • Projeto legal, parabéns pelo lançamento. Coloquei minha chave da OpenAI e recebi o erro "you exceeded your current quota, check billing". Fiquei na dúvida se uma assinatura OpenAI Pro de US$ 20 por mês bastaria ou se seria necessária alguma permissão adicional
    Encontrei a resposta no README do GitHub. Ele diz que “para usar sua própria chave de API, você precisa ter acesso ao usage tier 1; confira seu tier atual e como aumentá-lo nas configurações da OpenAI”
  • Aquele exemplo de fluxograma é realmente o ponto principal, e acho que deveria ser tratado como um conceito de primeira classe nesse tipo de ferramenta. Ele começa a oferecer alças que permitem criar algo útil, não só um brinquedo
  • O último exemplo é divertido, e é surpreendente que seja possível dar feedback desse jeito. Fico curioso sobre o que ele recebe como entrada real quando se seleciona o app gerado junto com o texto. Ele recebe o código gerado anteriormente junto com o novo texto?

• O prompt de sistema no repositório é este:

  You are an expert tailwind developer. A user will provide you with a  
  low-fidelity wireframe of an application and you will return  
  a single html file that uses tailwind to create the website.  
  They may also provide you with the html of a previous design that they want you to iterate from.  
  Carry out any changes they request from you.  
  In the wireframe, the previous design's html will appear as a white rectangle.  
  Use creative license to make the application more fleshed out.  
  if you need to insert an image, use a colored fill rectangle as a placeholder. Respond only with the html file.  
  

  Não sei bem por que "creative license" é mencionado aqui. Para cada geração, o prompt do usuário é o seguinte:

  [IMAGE_LINK]  
  Turn this into a single html file using tailwind.  
  

  https://github.com/tldraw/draw-a-ui/blob/8a889bf36afc06fbb0c...
  Parece simples o bastante para também rodar “em privado” tirando uma captura de tela de um canvas comum da tldraw e passando para a API junto com esse prompt

  • "creative license", em inglês comum, significa não se preocupar demais com as restrições e fazer o que parecer melhor. Não parece ter relação com licença de software

• Testei com um modelo vindo de uma pergunta de entrevista do Facebook. Eram duas listas de checkboxes e dois botões para mover os itens marcados de uma para a outra, e ele conseguiu fazer direito: https://gist.github.com/milesrichardson/2a2f77d4bfb19c3b28dc...

  • Eu não fazia ideia de que toList.appendChild(item.closest('li')); movia o item. Aprende-se uma coisa nova todo dia
  • Verifiquei com um leitor de tela e, ao pressionar o botão, nada é anunciado. Isso é um problema. Ele deveria dizer algo como “Checkbox B moved to the left”
    Sem qualquer anúncio, o usuário não consegue saber se algo realmente aconteceu ao apertar o botão. Página de teste: https://output.jsbin.com/jixoqur/quiet

• Essas demos recentes mostram ao mesmo tempo o quanto os avanços recentes em machine learning/IA são impressionantes e o quanto milhões de desenvolvedores no mundo inteiro continuam reimplementando trabalhos repetitivos e pouco criativos.
  Como a maioria das telas de UI pode ser descrita com precisão em um ou dois parágrafos, também não é surpreendente que elas possam ser representadas com bastante detalhe dentro de um vetor de embedding relativamente pequeno.

  • Concordo com a direção geral, mas também é importante lembrar que a maioria dessas demos é composta por casos cuidadosamente selecionados. Se você só vê demos virais nas redes sociais, acaba achando que a IA está muito mais avançada em tarefas complexas do que realmente está.
    Profissionais não técnicos que ainda não usaram IA de forma intensa no trabalho são especialmente vulneráveis a isso. Quem vive isso no campo costuma enxergar de forma mais nuanceada. É extremamente útil, mas também erra bastante, e para obter resultados em nível de produção é preciso ajustar com cuidado. Mesmo como otimista em relação à IA, acho que o valor é real e as demos impressionantes mostram para onde estamos indo, mas ainda vai levar tempo até o resultado médio alcançar as expectativas infladas.
  • Muitas formas de expressar ideias de software também são muito ineficientes. A parte realmente interessante, ou seja, a entropia, é muito pequena.
    Nesta demo, são literalmente dois sliders ajustando duas propriedades CSS, então não há muita informação na especificação da UI. Se existisse uma linguagem adequada de especificação de UI, seriam três linhas de código. A dificuldade vem de ter que gerenciar o boilerplate de UI web.
  • Isso expressa bem por que o hype de IA B2C construído sobre centenas de demos do tipo “Hello World” me incomodava. É aquela vibe de “meu Deus, a programação morreu!”.
    O estranho é que, no HN, quando se fala de plataformas no-code tradicionais, as pessoas percebem facilmente os limites de escalabilidade e manutenção, mas quando entra IA parece que esses problemas de repente são resolvidos e não é mais preciso se preocupar com o espaguete cuspido por uma caixa-preta.
  • Isso só revela o quanto nossa stack de software é idiota. Tudo funciona na base de “talvez você queira customizar isso, aquilo e mais 300 detalhes inúteis”.
    O que se queria de fato era separar funcionalidade e apresentação. Por coincidência, a web de HTML puro de 1996 era exatamente assim. Algo deu terrivelmente errado de uma forma absurdamente idiota, e ninguém melhorou. Em vez disso, ficamos com coisas como efeitos de sombra e flexbox interno.
  • O fato de trabalhos repetitivos e pouco criativos serem reimplementados o tempo todo não é um problema exclusivo dos desenvolvedores. Da entrada de dados à contabilidade e ao trabalho criativo, isso se aplica à maior parte do trabalho de escritório.
    Uma parte considerável do trabalho de escritório consiste em repetir as mesmas coisas, e muitas vezes pessoas diferentes, em empresas diferentes, repetem tarefas essencialmente iguais.

• Isso parece uma ferramenta que faz designers de UI, e talvez product owners, parecerem inteligentes e competentes. Mas o trabalho de verdade vai continuar indo para os programadores, como hoje.
  O designer de UI pode entregar uma “demo”, mas como essa funcionalidade básica vai se conectar ao restante do app? Não vai.

  • Isso certamente vai levar a conversas divertidas e produtivas do tipo: “Mas já está funcionando ali! Por que demora tanto para colocar no app? Não dá só para baixar?”.
    Mesmo antes do GPT, já havia o argumento de que protótipos muito iniciais ou mockups deveriam parecer visualmente pouco acabados, proporcionalmente ao nível de funcionalidade interna. Protótipos só de UI bonitos e aparentemente “funcionais” criam expectativas irreais mesmo quando explicados claramente, e aumentam a chance de proto-duction, quando o protótipo vira produção do jeito que está.
  • Odeio quando designers mostram no Figma uma UI que parece produto finalizado. Aos olhos dos executivos, parece um produto pronto, e expectativas irreais entram em um processo de design de UI que deveria ser iterativo.
    Já vi várias vezes projetos em que um design do Figma aprovado por algum executivo impôs restrições que empurraram uma arquitetura de sistema horrível para os engenheiros. Claro que organizações assim têm problemas maiores, mas mockups de alta fidelidade fáceis de fazer pioraram esse tipo de problema em comparação com wireframes.
  • O método é simples. Basta dar um novo prompt ao GPT-4: "Thanks. Please connect it to the rest of this code:"
    Se quiser que ele faça melhor, é só acrescentar "it's very important for my career".

• Desenvolvedores que fazem demos para aumentar e girar caixas agora estão prestes a perder o emprego.

  • Só aqueles que nem conseguem alinhar sliders.

• Enquanto discutíamos com um cliente como integrar nosso software ao software dele, o cliente nos enviou um screenshot do formulário principal.
  Coloquei esse screenshot no ChatGPT e pedi: “crie um formulário React desse tipo usando Bootstrap”. Depois de alguns ajustes, conectei meu software, e algumas horas depois o cliente ficou surpreso ao ver uma prova de conceito com o sistema integrado tão rapidamente. Quando tenho problemas de layout CSS em desenvolvimento web, costumo subir um screenshot para o ChatGPT e perguntar como resolver; a demo do tweet parece bem parecida.

  • Criar uma página de formulário básica sempre foi simples. O surpreendente é que, depois de cerca de 25 anos de desenvolvimento web, continuamos criando novos frameworks web e tornando isso mais complexo do que precisava ser.
    Continuaram surgindo frameworks excelentes para casos de uso sofisticados, mas exagerados para tarefas comuns e básicas. Houve exceções de vez em quando, mas a maioria dos desenvolvedores web não gosta muito delas. Também não ficam impressionantes no currículo e, sinceramente, quem quer passar a carreira inteira fazendo formulários web?
  • Na primeira vez, o cliente vai se impressionar com a velocidade. Na segunda, vai esperar essa velocidade. Na terceira, quando os requisitos crescerem além do que o ChatGPT consegue lidar, vai ficar irritado dizendo que o cronograma explodiu.
  • Se a conversa com o cliente foi por e-mail ou chat, dá para imaginar que o cliente também esteja perguntando ao ChatGPT qual é a melhor forma de transmitir os requisitos a você.
    No fim, são tartarugas sobre tartarugas :+)
  • Mas talvez o cliente não quisesse que seus dados fossem expostos ao ChatGPT.
  • Subir um screenshot de um problema de layout CSS no ChatGPT para corrigir é uma ideia elegante em que eu não tinha pensado. Normalmente mexo em CSS o suficiente para corrigir nas ferramentas de desenvolvedor e depois passar o estilo para o código, mas vale lembrar.
    Para programação, usei mais o ChatGPT para processar dados rapidamente com pipes de linha de comando ou scripts Bash do que para código em si. Se você fornece a saída de um comando e pede Bash para formatar, agrupar, ordenar ou extrair no formato desejado, fica mais fácil fazer coisas que normalmente não faria, como depuração ou verificação de hipóteses. Daria para fazer manualmente, mas é lento, e para lembrar opções e argumentos seria preciso pesquisar ou consultar páginas man. Para código, uso principalmente o GH Copilot.

• Podem me chamar de cético, mas não acredito no futuro das soluções no-code. É preciso alinhar botões em resoluções de dispositivos pequenos, deixar margens para que fique bom em outros idiomas, e sempre há outros requisitos
  No máximo, isso vai permitir criar apps mais rápido usando uma linguagem mais abstrata. Funciona para coisas extremamente básicas e comuns, como jogo da velha, mas não serve para trabalhos originais

  • Um grande problema do no-code baseado em LLM é que a saída é não determinística, então, no fim, só dá para colocar o próprio resultado no controle de versão
    Imagine dezenas de pessoas com um pouco de conhecimento técnico fazendo esboços e clicando em “faça de verdade” para adicionar funcionalidades. Cada uma gera centenas de linhas de código. No fim do dia, alguém precisa entender esse resultado, mas, como a saída é não determinística, é só isso que resta para nós
  • É parecido com o Auto-Tune. Artesãos que sabem cantar afinado continuarão criando coisas interessantes
    Ao mesmo tempo, pessoas novas que não aprenderam, ou não quiseram aprender, a cantar afinado criarão gêneros musicais totalmente novos e pop de massa com muito menos esforço. Os artesãos também o usarão ocasionalmente para reforçar alguns fluxos de trabalho, melhorar o acabamento e ganhar velocidade
  • Muitas dessas demos parecem menos uma tentativa de levar adiante uma abordagem puramente no-code e mais uma forma de mostrar que é possível criar quase imediatamente um wireframe funcional
    Ferramentas como Canva e Figma provavelmente vão adotar esse tipo de recurso de forma agressiva e melhorar bastante wireframes de alta fidelidade e demos
  • Minha intuição inicial também foi essa. Customização e integração serão um verdadeiro pesadelo. Mas é excelente para prototipagem
  • Ou LLMs/IA se tornarão perfeitos, ou começaremos a usar código e frameworks que LLMs/IA consigam usar com muito mais facilidade

• Squarespace, Wix etc. já tomaram a parte inferior do mercado; se não fossem eles, o outsourcing para a Índia teria tomado
  Isto é uma evolução natural do mesmo conceito. Se eu fosse gerente de produto de um construtor de sites, correria imediatamente atrás dessa integração de builders com IA. Isso jamais funcionará para trabalhos de negócio complexos e mal definidos, mas deve conseguir fazer bem algo como uma calculadora de custos para um negócio de fotografia

  • A maioria das pequenas e médias empresas ainda não tem app ou site, ou, quando tem, muitas vezes é inútil. Há um espaço enorme para nichos de mercado e boas ferramentas
  • Parece útil como ferramenta para criar demos interativas e protótipos que permitam iterar ideias rapidamente. Dá para manter curto o ciclo de feedback com clientes e reduzir mal-entendidos. Por exemplo, imagino que o Figma poderia implementar algo assim
  • Não sei por que acham que isso só serve para tarefas triviais. Isso beira a negação
    Software de workflow para processos de negócios é bastante popular. Há muitos apps em que as pessoas fazem coisas parecidas com drag-and-drop ou editores de widgets interativos, e que conseguem lidar com formulários complexos, relações pai-filho e transições de estado. Usando algo como GPT Vision, dá para pular o drag-and-drop de widgets e usar ferramentas de desenho mais livres ou esboços feitos à mão. O exemplo mais popular hoje talvez seja o Notion, e há exemplos bem mais complexos que existem há muito mais tempo

• Agora me sinto velho. Décadas atrás, acho que já dava para fazer quase isso na mesma velocidade com VB ou Delphi. Só que o resultado era um pouco mais determinístico, em vez de a ferramenta inferir a partir do nome dos labels
  Nós já tínhamos esse tipo de coisa, mas esquecemos que dava para fazê-la sem enfiar tudo no navegador e sem usar a computação enorme dos modelos de IA generativa. Sinto-me como um velho gritando para as nuvens

  • Penso de forma parecida. Para ser um pouco mais provocador: quando vejo pessoas mostrando IA transformando Figma em HTML, digo: “vocês já ouviram falar do Dreamweaver?”
    Claro que o código do Dreamweaver era feio e praticamente inutilizável, enquanto o código gerado por IA às vezes não é tão ruim. Ainda assim, parece que já tínhamos chegado bem perto do ponto em que estamos hoje
  • Isso não é um problema do navegador, mas de quão opinativo é o design do framework
    VB era uma ferramenta muito opinativa e só criava UIs no estilo nativo do Windows. Ninguém pegava um mockup arbitrário trazido por um designer, com look and feel totalmente customizado, e o replicava pixel a pixel no VB. Hoje, a GUI da maioria dos produtos faz parte da marca. Para o bem ou para o mal, toda empresa quer um look and feel e comportamentos de UI distintos. Por isso, as ferramentas para criar isso precisam ser muito mais complexas. Dá para recriar o VB no navegador, e muita gente de fato fez coisas parecidas, mas isso não é muito usado no desenvolvimento de produtos porque as empresas não querem UIs entediantes e genéricas
  • Entendo o ponto, mas ele só se aplica aos exemplos mais simples. Esta ferramenta consegue fazer várias coisas. Se você olhar mais a thread, ela também implementa jogo da velha
    Basicamente, funciona enviando uma captura de tela de um diagrama para o GPT-4 e dizendo “implemente isto”
  • Muito tempo atrás, no pavilhão de gráficos da Comdex, havia um sistema operacional novinho que era apresentado como o próximo passo. Um nerd gigantesco arrastava coisas com o mouse, “provando” que não era preciso ser programador para criar uma aplicação
    Dez anos depois, havia algo chamado Visix Vibe, que circulou por um ou dois anos oferecendo a mesma coisa para Java, que na época era uma linguagem relativamente nova. A cada poucos anos, mais ou menos a cada 4 ou 5 anos, ou 10, alguém quer fazer toda a complexidade desaparecer. Mas, no fim, eles acabam criando um sistema operacional
  • Ainda dá para ver isso usando os principais toolkits de UI nativos. Talvez não seja tão rápido quanto RAD, mas na web todo tipo de elemento e interação que exige JavaScript customizado e geralmente instável vem “de graça”
    E, de fato, funciona corretamente, interage com o restante do toolkit da forma esperada, e internacionalização e acessibilidade também funcionam bem de modo consistente. Não há motivo para o HTML não fazer muito mais coisas só com o que vem por padrão, e isso economizaria uma quantidade enorme de tempo de desenvolvedores e frustração de usuários todos os anos. Mas simplesmente não fazemos isso