Live data from Hacker News

The Speed of Prototyping in the Age of AI

darylcecile.net

111–119 of 119 posts

Re: The Speed of Prototyping in the Age of AI

#111
The approach I've been trying to use at work is making heavy use of AI for the generation of experimental prototypes, but with little intention of keeping all that code verbatim. I can get something to the demo stage much more quickly than before, allowing me to show it to coworkers and users to get feedback on random possibilities. From there, I make a case to properly delegate time for "doing it the right way" as a slotted piece of work. That's resulted in a number of high-impact features being added to our app in the last few months, that in the past would have taken much longer or never came to fruition.

I'm using this specifically in the context of concepts/features that are hard to explain/sell without some working visual or prototype, but which aren't immediately evident needs or features requested by our users. Some of them go nowhere, but I think the net result is an increased ability for me to get my experiments from the "lab" to production.

Re: The Speed of Prototyping in the Age of AI

#112
There definitely is the danger of a lot of garbage being shipped, but with both the models getting better and better, and more tools and ways of working being discovered, I believe the quality of what is being outputted is going up as well. Right now, a tool like claude code is more like a junior dev. you really need to steer it well, and know what you are doing, to make sure it doesn't output slop. but with the ability to create agents that work together, implementing design agents, coding agents, review agents, even a non-technical person will be able to design a workflow that spits out quality code, and I think that time isn't far away.

Re: The Speed of Prototyping in the Age of AI

#113
post #65

Earlier quoted context omitted.

The same thing happened when figma made it easier make prototypes that looked real and people stopped doing low fidelity mockups. Everyone understands that a wireframe isn’t done yet and it’s easy to change at that phase.

This I believe is lowkey one of the core ways design broke at tech companies. There are other big ones, design (really product) is broke deeply, but once mockups became easy we stopped having discussions about information architecture and UX. We're talking about whether we think this looks nicer in blue or green. Happened before Figma, but Figma really grew it. The designers that tried to hold onto wireframes (or wen…

I'll offer a different perspective on this: for years we (product/c-suite people) constantly got push back that giving a goal was no longer enough, we had to articulate the path to the goal in excruciating detail.

If I need to think about the solution that hard, I may just as well take it all the way, remove the middleman and get some efficiency back.

There's still a way out of this mess though. All it takes is for folks to take shared ownership for hitting the goal and bring their expertise to the table to help draw the path to the goal.

Re: The Speed of Prototyping in the Age of AI

#114
post #65

Earlier quoted context omitted.

The same thing happened when figma made it easier make prototypes that looked real and people stopped doing low fidelity mockups. Everyone understands that a wireframe isn’t done yet and it’s easy to change at that phase.

This I believe is lowkey one of the core ways design broke at tech companies. There are other big ones, design (really product) is broke deeply, but once mockups became easy we stopped having discussions about information architecture and UX. We're talking about whether we think this looks nicer in blue or green. Happened before Figma, but Figma really grew it. The designers that tried to hold onto wireframes (or wen…

which is why I advocate for fat marker mockups [0].

very low fidelity - but describe ux flows.

[0]: https://basecamp.com/shapeup/1.3-chapter-04

Re: The Speed of Prototyping in the Age of AI

#115
post #113
post #65

Earlier quoted context omitted.

This I believe is lowkey one of the core ways design broke at tech companies. There are other big ones, design (really product) is broke deeply, but once mockups became easy we stopped having discussions about information architecture and UX. We're talking about whether we think this looks nicer in blue or green. Happened before Figma, but Figma really grew it. The designers that tried to hold onto wireframes (or wen…

I'll offer a different perspective on this: for years we (product/c-suite people) constantly got push back that giving a goal was no longer enough, we had to articulate the path to the goal in excruciating detail. If I need to think about the solution that hard, I may just as well take it all the way, remove the middleman and get some efficiency back. There's still a way out of this mess though. All it takes is for f…

I'd ground what I say in sharing your assessment of the observations or insight, but with a different takeaway.

  If I need to think about the solution that hard, I may just as well take it all the way, remove the middleman and get some efficiency back.
Totally. And the takeaway is that we by and large should be doing this much more. That's what's needed from leaders. More vision, less delegation of vision. The stronger the vision, the less need for delegation anyway. There's something to be said about the difference between big picture and small picture, but at this point it's relatively intuitive that the big picture divorced from the small makes for worse big pictures. I'm not talking about how handing the big picture to the middle person tends to create interpretation/translation errors as well as execution errors to the extent the subordinate is less capable. Those factors are prominent and _in addition_ to the issue that the big picture is a worse big picture when these duties get stretched across two (or more) people. And thus, we should own these duties "vertically" and if needed reduce duties "horizontally".

Leaders (and companies) should be doing less horizontally. It runs the normal risk of stretching to thin, but their tenth and eleventh ideas are also filtered towards worse. Perhaps more fundamentally, the bar for adding a product/project should be higher. When the leader can "just" add another leader to take on the work—particularly one by nature with less power, ability, autonomy, and perhaps accountability—it's getting set up for a lower chance of success. In order: (1) the project probably shouldn't start at all; (2) if "started" at all, it shouldn't really look like starting, it should be a person validating for the leader who will then start it (many product teams pretend this is what they're doing); (3) if started, it makes quite a bit more sense for the higher (and likely more capable, but especially more empowered) leader to take on that project and hand the existing, stable, better trodded project where the team has institutional knowledge and support to the other leader.

In practice, sharing ownership is superficial, whether between leaders at different levels or between project team members. Why share? Own it or have someone else own it. Or if there isn't trust in the other person, cut it. If the leader doesn't have the time/interest and doesn't think they have someone capable of doing it, it should be as much a sign as a low quality idea.

It's not hard to find problems with middle managers—many are with the sorting that picks them, many are with the conditions of the middle. Structures and strategies to remove them, as you suggest, are a great idea. The main way is for the leaders, when faced with the scenario of "if I need to think hard", to not come away with "let's do it, but not me." We should be default no. Green lighting some work to validate it to a Yes works, but these are tasks such that the leader knows what kind of validation is needed—and is assigned to a person with those skills. An engineer, marketer, business analyst, user researcher, data scientist is going to validate things that a PM or a director have less or no training in. Leaders tend to appoint the latter though, sometimes for empire-building reasons, but I think more basically out of fear of control and legibility. Those are counter productive reasons if understandable.

Re: The Speed of Prototyping in the Age of AI

#116

There definitely is the danger of a lot of garbage being shipped, but with both the models getting better and better, and more tools and ways of working being discovered, I believe the quality of what is being outputted is going up as well. Right now, a tool like claude code is more like a junior dev. you really need to steer it well, and know what you are doing, to make sure it doesn't output slop. but with the abil…

Are the models really getting better and better? They tell us they are but I haven't noticed much difference in the last year or two.

Re: The Speed of Prototyping in the Age of AI

#117

Earlier quoted context omitted.

> I gave the example of Apple and Google for a good reason. Because these big companies are selling products that don't even exist yet. I guess I'm curious what you mean by this, I don't particularly see either of those companies doing this, certainly not in the way this article describes, and not really in any way that's impacted substantially by AI. What "product that doesn't exist" is Apple selling? Google? Who is…

> What "product that doesn't exist" is Apple selling? Google? Who is paying for it? >>> My Google Pixel phone still can't schedule a haircut for me or book a reservation at a restaurant, despite multiple promises This example has been in how many Android announcements? 8 years ago: https://m.youtube.com/watch?v=D5VN56jQMWM You're telling me you haven't seen the same promise for 8 years?

This, does exist though: https://share.google/i89jxAZzBzJJBpOyR. Like I know someone who answers phones are a salon and gets annoyed when people use this thing.

Re: The Speed of Prototyping in the Age of AI

#118
post #56
post #39

Earlier quoted context omitted.

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

Mostly because I only need to get a site into an RSS feed, I don't need a massive archival solution to do that.

Re: The Speed of Prototyping in the Age of AI

#119
post #116

There definitely is the danger of a lot of garbage being shipped, but with both the models getting better and better, and more tools and ways of working being discovered, I believe the quality of what is being outputted is going up as well. Right now, a tool like claude code is more like a junior dev. you really need to steer it well, and know what you are doing, to make sure it doesn't output slop. but with the abil…

Are the models really getting better and better? They tell us they are but I haven't noticed much difference in the last year or two.

It goes a bit up and down, compared to two years ago, in my feeling, both anthropic and open ai coding models have made massive jumps. In between big releases I do feel the quality of the models varies over time. 2 years ago I got annoyed with the models being crappy autocompletes, right now I'm just managing them more rather than coding myself
Post reply on HN