„Ich glaube, ich muss mich erst mal hinlegen.“

• Eindruck nach dem Ausprobieren der Make-Real-Demo von TLDraw
• Ein Tool, das mithilfe von AI Zeichnungen in funktionsfähige Software umwandelt
  • Nutzt OpenAI's GPT-4V, um Vektorgrafiken in HTML/TailWind CSS und Javascript umzuwandeln

[GN⁺]

Hacker-News-Meinungen

• Steve von tldraw hier. Sorry, das ist ein Spielzeugprojekt mit miserablen Sicherheitsmustern. Wenn ihr es lokal ausführen oder den Source ansehen wollt, findet ihr ihn hier: https://github.com/tldraw/draw-a-ui
  Weitere Beispiele gibt es unter https://twitter.com/tldraw. Fragen zu tldraw oder diesem Projekt kann ich beantworten. Das ist nichts, was irgendjemandem die Arbeit wegnimmt, aber es macht wirklich Spaß, damit herumzuspielen; ein komplexeres Beispiel gibt es hier: https://twitter.com/tldraw/status/1725083976392437894

  • Das solltet ihr sofort launchen. Das ist wirklich ein geniales Produkt; nehmt 5 $ pro Monat und lasst die Nutzer ihren eigenen OpenAI-Key mitbringen.
    Es gibt auch einen Lizenzserver, den ich gerade unter MIT-Lizenz veröffentlicht habe. Er ist in Elixir geschrieben und betreibt https://go.robocoder.app. Wenn ihr Hilfe beim Einrichten braucht, könnt ihr euch melden: https://github.com/emcmanus/robocoder-server/
  • Steve, wohin soll ich das Geld schicken? Spaß beiseite: Das ist ziemlich überzeugend. Es mag ein Spielzeug sein, aber alle haben gerade viel Freude daran.
  • Tolles Projekt, Glückwunsch zum Launch. Ich habe meinen OpenAI-Key eingegeben und bekam den Fehler „you exceeded your current quota, check billing“. Ich fragte mich, ob ein OpenAI-Pro-Abo für 20 $ im Monat ausreicht oder ob zusätzliche Berechtigungen nötig sind.
    Die Antwort habe ich im GitHub-README gefunden. Dort steht, dass man für die Nutzung des eigenen API-Keys Zugriff auf usage tier 1 braucht und den aktuellen Tier sowie die Möglichkeit zum Hochstufen in den OpenAI-Einstellungen prüfen soll.
  • Dieses Flowchart-Beispiel trifft wirklich den Kern und sollte bei solchen Tools als First-Class-Konzept behandelt werden. Es beginnt, einem Griffe an die Hand zu geben, mit denen man nicht nur Spielzeug, sondern etwas Nützliches bauen kann.
  • Das letzte Beispiel ist interessant, und es ist erstaunlich, dass man auf diese Weise Feedback geben kann. Ich frage mich, was tatsächlich als Eingabe übergeben wird, wenn man die generierte App zusammen mit Text auswählt. Bekommt es den zuvor generierten Code zusammen mit dem neuen Text?

• Der System-Prompt im Repository lautet so:

  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.  
  

  Ich bin mir nicht ganz sicher, warum hier „creative license“ erwähnt wird. Der User-Prompt lautet bei jeder Generierung wie folgt:

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

  https://github.com/tldraw/draw-a-ui/blob/8a889bf36afc06fbb0c...
  Es wirkt simpel genug, einfach einen Screenshot eines normalen tldraw-Canvas zu machen und ihn zusammen mit diesem Prompt an die API zu übergeben, um das „privat“ laufen zu lassen.

  • „creative license“ bedeutet im normalen Englisch sich nicht zu sehr um die Einschränkungen zu kümmern und nach bestem Gefühl vorzugehen. Mit Softwarelizenzen scheint das nichts zu tun zu haben.

• Ich habe eine Vorlage aus einer Facebook-Interviewfrage eingegeben. Sie bestand aus zwei Checklisten und zwei Buttons, mit denen man markierte Einträge hin- und herschiebt, und das hat es korrekt umgesetzt: https://gist.github.com/milesrichardson/2a2f77d4bfb19c3b28dc...

  • Ich hatte keine Ahnung, dass toList.appendChild(item.closest('li')); das Element verschiebt. Man lernt jeden Tag etwas dazu.
  • Ich habe es mit einem Screenreader geprüft: Beim Drücken des Buttons wird überhaupt nichts angesagt. Das ist ein Problem. Es sollte etwas wie „Checkbox B moved to the left“ sagen.
    Ohne irgendeine Ansage weiß der Nutzer nicht, ob beim Drücken des Buttons tatsächlich etwas passiert ist. Testseite: https://output.jsbin.com/jixoqur/quiet

• Solche aktuellen Demos zeigen einerseits, wie beeindruckend die jüngsten Fortschritte bei Machine Learning/KI sind, und andererseits, wie viele sich wiederholende und wenig kreative Arbeiten Millionen von Entwicklern weltweit immer wieder neu implementieren.
  Die meisten UI-Screens lassen sich mit ein oder zwei Absätzen präzise beschreiben; daher ist es auch nicht überraschend, dass sie sich in einem relativ kleinen Embedding-Vektor ziemlich detailliert darstellen lassen.

  • Der großen Richtung stimme ich zu, aber wichtig ist auch, dass die meisten dieser Demos sorgfältig kuratierte Beispiele sind. Wenn man in sozialen Medien nur virale Demos sieht, denkt man leicht, KI sei auch bei komplexen Aufgaben viel weiter, als sie tatsächlich ist.
    Besonders anfällig dafür sind nichttechnische Rollen, die KI in der echten Arbeit noch nicht intensiv eingesetzt haben. Leute, die es im Alltag erleben, sehen es meist differenzierter. Es ist enorm nützlich, macht aber auch viele Fehler, und um Ergebnisse auf Produktionsniveau zu bekommen, muss man sorgfältig nacharbeiten. Auch als KI-Optimist: Der Wert ist real, und beeindruckende Demos zeigen, wohin die Reise geht, aber es wird dauern, bis die durchschnittlichen Ergebnisse die überzogenen Erwartungen einholen.
  • Viele Arten, Software-Ideen auszudrücken, sind ebenfalls sehr ineffizient. Der wirklich interessante Teil, also die Entropie, ist sehr klein.
    In dieser Demo sind es buchstäblich zwei Slider, die zwei CSS-Eigenschaften anpassen; die Informationsmenge in der UI-Spezifikation ist also nicht groß. Mit einer geeigneten UI-Spezifikationssprache wären das drei Zeilen Code gewesen. Die Schwierigkeit entsteht dadurch, dass man Web-UI-Boilerplate verwalten muss.
  • Das bringt gut auf den Punkt, warum mir der B2C-KI-Hype auf Basis von Hunderten „Hello World“-Demos unangenehm war. Diese Stimmung von „Oh mein Gott, Programmieren ist tot!“.
    Seltsam ist, dass HN bei klassischen No-Code-Plattformen Skalierungs- und Wartungsgrenzen sofort erkennt, aber sobald KI dazukommt, wirken diese Probleme plötzlich gelöst und man müsse sich keine Sorgen mehr um die Blackbox-Spaghetti machen, die ausgespuckt werden.
  • Das zeigt nur, wie dumm unser Software-Stack ist. Alles läuft nach dem Motto: „Vielleicht willst du ja dies und das und außerdem noch 300 nutzlose Details anpassen.“
    Was man eigentlich wollte, war die Trennung von Funktion und Darstellung. Zufälligerweise war genau das das reine HTML-Web von 1996. Irgendetwas ist auf unvorstellbar dumme Weise furchtbar schiefgelaufen, und niemand ist besser geworden. Stattdessen blieben Dinge wie Schatteneffekte und verschachtelte Flexbox übrig.
  • Dass sich wiederholende und wenig kreative Arbeit immer wieder neu implementiert wird, ist nicht nur ein Entwicklerproblem. Von Dateneingabe über Buchhaltung bis hin zu kreativen Tätigkeiten trifft das auf den Großteil der Büroarbeit zu.
    Ein erheblicher Teil der Büroarbeit besteht darin, immer wieder dasselbe zu tun, und oft wiederholen verschiedene Menschen in unterschiedlichen Unternehmen im Wesentlichen dieselben Aufgaben.

• Das wirkt wie ein Tool, das UI-Designer und vielleicht Product Owner klug und kompetent aussehen lässt. Die eigentliche Arbeit wird aber wie bisher bei den Programmierern landen.
  Ein UI-Designer kann vielleicht eine „Demo“ liefern, aber wie soll diese Grundfunktion mit dem Rest der App verbunden werden? Wird sie nicht.

  • Das wird sicher zu angenehmen und produktiven Gesprächen führen wie: „Aber da drüben funktioniert es doch schon! Warum dauert es so lange, das in die App einzubauen? Können Sie es nicht einfach herunterladen?“
    Schon vor GPT gab es das Argument, dass sehr frühe Prototypen oder Mockups optisch genauso unfertig aussehen sollten, wie es ihrem internen Funktionsumfang entspricht. Hübsche, oberflächlich „funktionierende“ reine UI-Prototypen erzeugen selbst bei klarer Erklärung unrealistische Erwartungen und erhöhen die Wahrscheinlichkeit von Proto-duction, also dass der Prototyp direkt zur Produktion wird.
  • Ich mag es nicht, wenn Designer in Figma eine UI zeigen, die wie ein fertiges Produkt aussieht. Für Führungskräfte sieht das wie ein fertiges Produkt aus, und dadurch schleichen sich unrealistische Erwartungen in einen UI-Designprozess ein, der eigentlich iterativ sein sollte.
    Ich habe mehrfach Projekte gesehen, in denen wegen der Einschränkungen eines von irgendeiner Führungskraft freigegebenen Figma-Designs ein miserables Systemdesign an die Engineers weitergereicht wurde. Natürlich haben solche Organisationen noch größere Probleme, aber leicht erstellbare High-Fidelity-Mockups haben diese Probleme stärker verschärft als Wireframes.
  • Die Methode ist einfach. Man gibt GPT-4 einen neuen Prompt: "Thanks. Please connect it to the rest of this code:"
    Wenn man es dazu bringen will, es besser zu machen, hängt man noch "it's very important for my career" dran.

• Entwickler, die Demos bauen, in denen Boxen vergrößert und gedreht werden, stehen jetzt offenbar kurz davor, ihre Jobs zu verlieren.

  • Das gilt nur für diejenigen, die nicht einmal Slider ausrichten können.

• Während wir mit einem Kunden besprachen, wie wir unsere Software in dessen Kundensoftware integrieren, schickte der Kunde einen Screenshot des Hauptformulars.
  Ich habe diesen Screenshot in ChatGPT geladen und gesagt: „Erstelle mir ein React-Formular in diesem Stil mit Bootstrap.“ Nach ein paar Anpassungen habe ich meine Software angebunden, und ein paar Stunden später war der Kunde erstaunt über den Proof of Concept, in dem das System so schnell integriert war. Wenn ich bei der Webentwicklung CSS-Layoutprobleme habe, lade ich oft einen Screenshot in ChatGPT hoch und frage nach einer Lösung; die Demo aus dem Tweet wirkt ziemlich ähnlich.

  • Eine einfache Formularseite zu erstellen, war schon immer simpel. Erstaunlich ist, dass wir nach etwa 25 Jahren Webentwicklung immer noch neue Web-Frameworks bauen und das Ganze komplizierter machen, als es sein müsste.
    Es kamen immer wieder Frameworks, die für ausgefallene Use Cases hervorragend sind, für häufige und grundlegende Aufgaben aber überdimensioniert. Es gab gelegentlich Ausnahmen, aber die meisten Webentwickler mögen so etwas nicht. Im Lebenslauf sieht es auch nicht toll aus, und ehrlich gesagt: Wer möchte schon seine ganze Karriere lang nur Webformulare bauen?
  • Beim ersten Mal wird der Kunde von der Geschwindigkeit beeindruckt sein. Beim zweiten Mal wird er diese Geschwindigkeit erwarten. Beim dritten Mal wird er wütend sein, dass der Zeitplan explodiert ist, wenn die Anforderungen so groß geworden sind, dass ChatGPT sie nicht mehr bewältigen kann.
  • Wenn man mit dem Kunden per E-Mail oder Chat gesprochen hat, kann man sich vorstellen, dass der Kunde ebenfalls ChatGPT fragt, wie er dir die Anforderungen am besten übermitteln soll.
    Am Ende sind es Schildkröten auf Schildkröten :+)
  • Vielleicht wollte der Kunde aber auch nicht, dass seine Daten ChatGPT offengelegt werden.
  • Einen Screenshot eines CSS-Layoutproblems in ChatGPT hochzuladen, um es zu beheben, ist eine elegante Idee, auf die ich nicht gekommen war. Normalerweise kenne ich mich mit CSS gut genug aus, um es in den Developer Tools zu beheben und die Styles in den Code zu übertragen, aber das sollte man sich merken.
    Beim Coding habe ich ChatGPT häufiger verwendet, um Daten schnell mit Kommandozeilen-Pipes oder Bash-Skripten zu verarbeiten, als für Code selbst. Wenn man Befehlsausgaben gibt und Bash für die gewünschte Formatierung, Zusammenfassung, Sortierung oder Extraktion anfordert, werden auch Dinge einfach, die man sonst nicht ausprobiert hätte, etwa Debugging oder Hypothesenchecks. Man könnte es auch manuell machen, aber das ist langsam, und um Optionen und Argumente zu erinnern, braucht man Suche oder Manpages. Für Code nutze ich hauptsächlich GH Copilot.

• Man kann mich gern einen Skeptiker nennen, aber ich glaube nicht an die Zukunft von No-Code-Lösungen. Man muss Buttons auf kleinen Geräteauflösungen ausrichten, Abstände lassen, damit es auch in anderen Sprachen gut aussieht, und es gibt ständig weitere Anforderungen.
  Bestenfalls wird es einem ermöglichen, Apps mit einer stärker abstrahierten Sprache schneller zu bauen. Das funktioniert bei extrem grundlegenden und verbreiteten Dingen wie Tic-Tac-Toe, passt aber nicht zu originären Arbeiten.

  • Das große Problem bei LLM-basiertem No-Code ist, dass die Ausgabe nichtdeterministisch ist und man am Ende nur das Ergebnis selbst in die Versionsverwaltung aufnehmen kann.
    Man stelle sich vor, Dutzende Leute mit ein bisschen technischem Wissen machen Skizzen und drücken auf „Mach das wirklich“, um Features hinzuzufügen. Jeder erzeugt Hunderte Zeilen Code. Am Ende des Tages muss irgendjemand dieses Ergebnis verstehen, aber weil die Ausgabe nichtdeterministisch ist, bleibt uns nur genau das.
  • Es ist ähnlich wie Auto-Tune. Handwerker, die sauber singen können, werden weiterhin Interessantes schaffen.
    Gleichzeitig werden neue Leute, die nicht gelernt haben oder nicht lernen wollten, sauber zu singen, mit viel weniger Aufwand völlig neue Musikgenres und Mainstream-Pop schaffen. Auch die Handwerker werden es gelegentlich nutzen, um Teile ihres Workflows zu verstärken, die Qualität zu erhöhen und schneller zu werden.
  • Viele dieser Demos versuchen nicht wirklich, einen reinen No-Code-Ansatz durchzudrücken, sondern zeigen eher, dass man fast sofort ein funktionierendes Wireframe erstellen kann.
    Tools wie Canva und Figma werden solche Funktionen vermutlich offensiv integrieren und damit High-Fidelity-Wireframes und Demos deutlich verbessern.
  • Mein erster Instinkt war derselbe. Customizing und Integration werden ein kompletter Albtraum. Für Prototyping ist es allerdings großartig.
  • Entweder werden LLMs/AI perfekt, oder wir werden anfangen, Code und Frameworks zu verwenden, die LLMs/AI viel einfacher nutzen können.

• Squarespace, Wix und ähnliche Anbieter haben bereits das untere Marktsegment übernommen; andernfalls hätte es Outsourcing nach Indien getan.
  Das ist die natürliche Weiterentwicklung desselben Konzepts. Wenn ich Produktmanager eines Website-Builders wäre, würde ich mich sofort auf eine solche AI-Builder-Integration stürzen. Für kaum definierte, komplexe Geschäftsaufgaben wird das nie funktionieren, aber einen Kostenrechner für ein Fotografie-Geschäft wird es wohl gut bauen können.

  • Die meisten kleinen und mittleren Unternehmen haben noch keine App oder Website, oder wenn doch, ist sie oft nutzlos. Der Raum für Nischenmärkte und gute Tools ist riesig.
  • Es wirkt nützlich als Tool zum Erstellen von interaktiven Demos und Prototypen, mit denen man Ideen schnell iterieren kann. So bleibt die Feedback-Schleife mit Kunden kurz und Missverständnisse werden reduziert. Figma könnte so etwas zum Beispiel umsetzen.
  • Ich verstehe nicht, warum man glaubt, das funktioniere nur für triviale Aufgaben. Das grenzt an Verleugnung.
    Software für Business-Process-Workflows ist ziemlich beliebt. Es gibt viele Apps, in denen Leute per Drag-and-drop oder mit interaktiven Widget-Editoren Ähnliches tun, und sie können auch komplexe Formulare, Parent-Child-Beziehungen und Zustandsübergänge abbilden. Mit etwas wie GPT Vision kann man das Drag-and-drop von Widgets überspringen und freiere Zeichenwerkzeuge oder handgezeichnete Skizzen verwenden. Das heute populärste Beispiel ist vermutlich Notion, und deutlich ältere, komplexere Beispiele gab es schon lange davor.

• Ich fühle mich jetzt alt. Schon vor Jahrzehnten konnte man das mit VB oder Delphi gefühlt fast genauso schnell machen. Nur war das Ergebnis etwas deterministischer, statt dass das Tool aus Label-Namen etwas ableitete.
  Wir hatten so etwas bereits, und wir haben vergessen, dass es auch ging, ohne alles in den Browser zu zwängen und die enorme Rechenleistung generativer AI-Modelle zu nutzen. Ich fühle mich wie ein alter Mann, der Wolken anschreit.

  • Ähnlicher Gedanke. Etwas provokanter gesagt: Wenn Leute zeigen, wie sie mit AI Figma in HTML verwandeln, sage ich: „Schon mal von Dreamweaver gehört?“
    Natürlich war Dreamweaver-Code hässlich und praktisch unbrauchbar, und AI-generierter Code ist manchmal gar nicht so schlecht. Trotzdem waren wir dem heutigen Stand meiner Meinung nach schon ziemlich nahe.
  • Das ist kein Problem des Browsers, sondern eine Frage, wie meinungsstark das Design des Frameworks ist.
    VB war ein sehr meinungsstarkes Tool und erzeugte nur native UIs im Windows-Stil. Man hat in VB keine beliebigen Mockups von Designern mit vollständig individuellem Look-and-feel pixelgenau nachgebaut. Heute ist die GUI der meisten Produkte Teil der Marke. Ob gut oder schlecht: Jedes Unternehmen will einen eigenen Look-and-feel und eigenes UI-Verhalten. Deshalb müssen die Tools dafür deutlich komplexer sein. Man kann VB auch im Browser nachbauen, und viele haben tatsächlich etwas Ähnliches gebaut, aber weil Unternehmen keine langweiligen, generischen UIs wollen, wird es in der Produktentwicklung kaum genutzt.
  • Ich verstehe den Punkt, aber er gilt nur für die einfachsten Beispiele. Dieses Tool kann mehrere Dinge. Wenn man sich den Thread weiter ansieht, implementiert es auch Tic-Tac-Toe.
    Im Grunde funktioniert es so, dass ein Screenshot eines Diagramms an GPT-4 geschickt wird mit der Bitte: „Implementiere das.“
  • Vor langer Zeit gab es auf der Grafik-Ausstellung der Comdex ein frisches Betriebssystem, das als nächster Schritt vorgestellt wurde. Irgendein riesiger Nerd zog mit der Maus Dinge hin und her und „bewies“, dass man kein Programmierer sein müsse, um Anwendungen zu bauen.
    Zehn Jahre später geisterte ein bis zwei Jahre lang etwas namens Visix Vibe herum, das dasselbe für Java bot, damals eine noch relativ neue Sprache. Alle paar Jahre, etwa alle 4–5 oder 10 Jahre, will irgendjemand sämtliche Komplexität verschwinden lassen. Am Ende bauen sie aber ein Betriebssystem.
  • Mit den großen nativen UI-Toolkits kann man so etwas immer noch sehen. Es ist vielleicht nicht ganz so schnell wie RAD, aber alle möglichen Elemente und Interaktionen, die im Web individuelles und meist fragiles JavaScript erfordern, bekommt man dort „gratis“.
    Und sie funktionieren tatsächlich richtig, interagieren mit dem restlichen Toolkit wie erwartet, und Internationalisierung sowie Barrierefreiheit funktionieren konsistent gut. Es gibt keinen Grund, warum HTML nicht von Haus aus deutlich mehr leisten könnte; das würde jedes Jahr enorm viel Entwicklerzeit und Nutzerfrust sparen. Es wird nur nicht gemacht.