Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Speed of Prototyping in the Age of AI

darylcecile.net

Post reply on HN
Print view View original

51–60 of 119 posts

Re: The Speed of Prototyping in the Age of AI

#51

Post by cryo32 »

anssip wrote: post #33

AI makes it possible to ship a lot of junk really fast

Well the worst thing is it allows you to make a really convincing pile of junk and get people to pay for it. Then you can worry about the details when you have your first paying customers.

That's where everyone is overconfident. And that's where mature companies like ours are starting to get customers come back again after jumping ship for some vibe coded startup and getting screwed.

LLMs, minimum advantages aside, are merely amplifiers for the worst characteristics of the human race.

Re: The Speed of Prototyping in the Age of AI

#52

Post by rffaaa »

rossjudson wrote: post #8

I'm truly hopeful that AI will open a new of prototyping. Back in the day, prototyping was how you figured out what to build, you'd very deliberately toss the entire first (or second!) version, and you'd plan to do that. High quality ensued. Usually ;)

I think this is nonsense.

Prototyping already existed - how do you think the iPhone came into existence?

Re: The Speed of Prototyping in the Age of AI

#54

Post by simonw »

kadhirvelm wrote: post #35
simonw wrote: post #26

Earlier quoted context omitted.

I've started making most of my prototypes single HTML documents with inline CSS and JavaScript, because a single file is a lot easier to store somewhere and share and will probably keep on working forever (browsers are really good at backwards compatibility). I chuck some of them on my public tools.simonwillison.net collection, others in their own GitHub repos with GitHub Pages enabled, and some I just share in a Gis…

The single file is interesting, we’ve been observing something similar too. Do you have a specific prompt that you load in by default to make this work? Are these react files, or just pure HTML/JS/CSS? Aka do you compile it via Esbuild or webpack or something, or are you asking the model to generate something that works out of the box? We’ve been seeing Claude artifacts sometimes come out as JSX or TSX

Here are the custom instructions I mostly use:

  Never use React in artifacts - always
  plain HTML and vanilla JavaScript and CSS
  with minimal dependencies.

  CSS should be indented with two spaces
  and should start like this:

  ```
  
  * {
    box-sizing: border-box;
  }
  ```
  Inputs and textareas should be font size
  16px. Font should always prefer
  Helvetica.

  JavaScript should be two space indents
  and start like this:
  ```
  
  // code in here should not be indented at
  the first level
  ```
  Prefer Sentence case for headings.
I've been using those for a couple of years, there's a good chance they're not necessary against more recent models. I've found that just saying "use Vanilla JavaScript" is enough to skip React / other build steps.

I avoid any build steps because those make it harder to copy and paste code in and out of LLMs.

Re: The Speed of Prototyping in the Age of AI

#55

Post by righthand »

snoman wrote: post #25
righthand wrote: post #9

Earlier quoted context omitted.

But “are you really moving at speed after you generate the majority of your application?” is my other point. If you were to start working somewhere with an existing product the changes you would apply are more than likely incremental. What is the advantage of using LLMs to change 1-10 lines of code on average? How do you measure the ROI for that? What did the time savings gain you? A quicker release date? How can you…

Considering that engineer never reliably estimated anything beyond a few days remotely accurately before… but now they can…

Can they? Or are they just estimating the time it takes to generate a working prototype?

Re: The Speed of Prototyping in the Age of AI

#56

Post by dakolli »

jfim wrote: post #39
baisampayans wrote: post #27

While the speed of prototyping and even shipping to production has increased, I have been asking myself at what cost? I see a lot of garbage being shipped. Not because the code quality is bad, because execution has become cheap now. Ideas even though crap, are getting prototyped. Things which look effective on the surface, but has real UX problems in the underneath, are getting prioritised because someone in the room…

Prototypes aren't only for UX though, sometimes they're for exploring whether something is technically possible, or what are the unknown unknowns in a particular area. For example, for personal projects, I've been wondering if it's possible to automatically create RSS feeds for pages that don't have them (yes), what are the challenges when building an archive-style page dumping system (need to dump CSSOM alongside ge…

Why wouldn't you use Archive Box?

https://github.com/archivebox/archivebox

Re: The Speed of Prototyping in the Age of AI

#57

Post by tptacek »

godelski wrote: post #47
tptacek wrote: post #41

Earlier quoted context omitted.

Can you help me understand what the "cost" of other people producing garbage is? Prototypes are generally shop jigs. You'd feel weird gold-plating a stop block.

> the "cost" of other people producing garbage is? Sure can! It's a well known phenomena, won the researchers a Nobel, and explains a lot of the American economy and "lack of taste". The Market of Lemons[0]. Lemon Markets really require one important thing: at time of purchase , the average consumer is unable to differentiate the quality of the product. Consumers are "rational"[1], so with "all other things being equ…

The premise here is that people are selling these prototypes, and they are being bought. I mean, fine, that's bad, but when we discuss "prototypes", I assume uninformed cash transactions are off the table.

Re: The Speed of Prototyping in the Age of AI

#58

Post by hankbond »

kadhirvelm wrote: post #35
simonw wrote: post #26

Earlier quoted context omitted.

I've started making most of my prototypes single HTML documents with inline CSS and JavaScript, because a single file is a lot easier to store somewhere and share and will probably keep on working forever (browsers are really good at backwards compatibility). I chuck some of them on my public tools.simonwillison.net collection, others in their own GitHub repos with GitHub Pages enabled, and some I just share in a Gis…

The single file is interesting, we’ve been observing something similar too. Do you have a specific prompt that you load in by default to make this work? Are these react files, or just pure HTML/JS/CSS? Aka do you compile it via Esbuild or webpack or something, or are you asking the model to generate something that works out of the box? We’ve been seeing Claude artifacts sometimes come out as JSX or TSX

I have been doing the same thing, creating small one file "apps". The problem that I have currently is that I often want my Agent to be able to present me with something like a report on a code change, have me mark it up (comments, choices), and then present those interactions back to the model.

I'm experimenting with different ways to standardize some aspect of this process in a lightweight way so an Agent and I can "communicate with each other over rendered html".

A simple script or cli the agent can run to to serve an html app, act as a sink for interactions (can just submit a button+form to the runner port), and then close the page when done can work.

A little farther out in this direction would be something like a persistent client+server via web or electron. It's always on and you iterate in a loop, streaming diffs/file edits back and forth to each other.

A little farther out and you can load extensions that contain templates to generate the html, custom server code to serve htmx interactivity, and agent functionality.

Just two days ago I started on this idea https://github.com/hank-bond/uix

I was working on two ideas

1. "highlight a web page a-la obsidian web clipper and then intake that information into a personal wiki of concepts" (my third prototype in a row of this concept)

2. "visualize the code review process and organize discussion in a non-linear branching conversation"

And I realized both of them are basically chat pane on the left, agent with custom tools, and html "app" pane on the right to support interactivity.

The project as of this comment doesn't have any functionality yet its basically just the panes and a simple agent messaging channel, but if you (or anyone) are interested in the idea comment here and I will reach out when its a bit farther along and actually useful for building things.

Likewise please share your experiences with this concept, I would love to learn what others are doing with this type of workflow!

Re: The Speed of Prototyping in the Age of AI

#59

Post by j45 »

rossjudson wrote: post #8

I'm truly hopeful that AI will open a new of prototyping. Back in the day, prototyping was how you figured out what to build, you'd very deliberately toss the entire first (or second!) version, and you'd plan to do that. High quality ensued. Usually ;)

Now it's possible to toss many more. :)

Re: The Speed of Prototyping in the Age of AI

#60

Post by thankyoufriend »

whstl wrote: post #29
bluefirebrand wrote: post #13

Earlier quoted context omitted.

Most places I've worked, devs were basically afraid to prototype Either you would get chastised for wasting time with prototypes, or worse, your prototype would end up in production I think the software industry really needs a cultural reset to embrace slower and deliberate development to build quality, but unfortunately AI has us racing recklessly in the wrong direction I am so tired of it. Are there any companies o…

I understand both sides. Quality must come from engineering. If you’re depending on a product manager to ask you that you can improve the quality of the code, you already lost. So it requires soft skills, proper framing and ability to iterate quickly on quality-related tasks without leaving junk and multiple-versions behind. But I completely understand push back for “doing improvements developers want to do”: A lot o…

I think there's an argument that it could be cheaper and better for morale to let employees upskill while working on the thing that makes money.
Post reply on HN