[skipants]

I’m 20 minutes into the video and it does seem mostly basic and agreeable.

Two arguments from Ng that really stuck out that is really tripping my skepticism alarm are:

1) He mentions how fast prototyping has begun because generating a simple app has become easier with AI. This, to me, has always been quick and never the bottleneck for any company I’ve been at, including startups. Validating an idea was simple enough via wireframing. I can maybe see it for selling an idea where you need some amount of fidelity yo impress potential investors… but I would hope places like YC can see the tech behind the idea without seeing the tech itself. Or at least can ignore low fidelity if a prototype shows the meat of the product.

2) Ng talks about how everyone in his company codes, from the front desk to the executives. The “everyone should code” idea has been done and shown to fail for the past 15 years. In fact I’ve seen it be more damaging than helpful because it gave people false confidence that they could tell engineers how to do their job rather than a more empathetic understanding.

[marcosdumay]

On point 1, it's worse than that. Adding detail and veracity to a prototype is well known to bring negative value.

Prototypes must be exactly a sketchy as the ideas they represent, otherwise they mislead people into thinking the software is built and your ideas can't be changed.

[macNchz]

I’ve always said this as well, having done lots and lots of early stage building and prototyping, and suffering plenty of proto-duction foibles, however my view has shifted on this a lot in the last year or so.

With current models I’m able to throw together fully working web app prototypes so quickly and iterate often-sweeping UI and architectural changes so readily that I’m finding it has changed my whole workflow. The idea of trying to keep things low-fidelity at the start is predicated on the understanding that changes later in the process are much more difficult or expensive, which I think is increasingly no longer the case in many circumstances. Having a completely working prototype and then totally changing how it works in just a few sentences is really quite something.

The key to sustainability in this pattern, in my opinion, is not letting the AI dictate project structure or get too far ahead of your own understanding/oversight of the general architecture. That’s a balancing act to be sure, since purely vibe-coding is awfully tempting, but it’s still far too easy to wind up with a big ball of wax that neither human nor AI can further improve.

[NotMichaelBay]

I don't think this reasoning holds up anymore now that somewhat polished prototypes are so cheap to create and change. Maybe not everyone is aware of that yet but eventually it will be common knowledge.

[torginus]

The “everyone should code” idea has been done and shown to fail for the past 15 years - I pretty much completely agree, and this idea shows the outsized importance on programming as some kind of inherently superior activity, and bringing the ability to program to the masses as some kind of ultimate good.

If you've worked long enough and had interacted with people with varied skillsets, people who don't code aren't only there for show, in fact, depending on the type of company you work at, their jobs might be genuinely more important for the company's success than yours.

[zikzak]

I spent a very frustrating 20 minutes with someone this week (a nice person I like, which is why I spent this time) explaining that the Python code chatgpt had provided them would just copy files from one folder to another and was no different from using Windows drag and drop copy.

It would not do any of the things they thought (lots of parsing and file renaming that it took a while for them to articulate). We also discussed how the corporate IT would not be installing a Python interpreter on their computer. Oh what's that? Let me explain. And so on.

ChatGPT didn't help, in this situation, as it turned out.

[mteoharov]

At my company everybody codes, including PMs and business people. It can definitely be damaging done in the long run without any supervision from an actual programmer. This is why we assign an engineer to review every PR of a vibe coded project and they don’t really need all of the context to detect bs approaches that will surely fail.

About prototyping - its much faster and i dont know how anyone can argue this. PMs can get a full blown prototype for an MVP working in a day with AI assistance. Sure - they will be thrown in the trash after the demo, but they carry out their purpose of proving a concept. The code is janky but it works for its purpose.

[sensanaty]

Good lord I think I'd rather eat a shotgun than be forced to review a billion garbage PRs made by PMs and other non-technical colleagues. It's bad enough reviewing PRs backenders write for FE features badly with AI (and vice versa), I cannot even imagine the pits of hell this crap is like.

What happens when inevitably the PR/code is horrid? Do they just keep prompting and pushing out slop that some poor overworked dev is now forced to sit through lest he get PIP'd for not being brainwashed by LLMs yet?

[willahmad]

> This is why we assign an engineer to review every PR of a vibe coded project and they don’t really need all of the context to detect bs approaches that will surely fail.

I see this trend in many companies as well, just curious, how do you make sure engineering time is not wasted reviewing so many PRs? Because, some of them will be good, you only need couple of your bets to take off, some definitely bad

[mteoharov]

Its commonly understood that whoever is reviewing the PR shouldn't concern themselves with all of the project’s context (business or any other).

It really takes a glance at the PR to see what the author wanted to create and you can pick up on bad directions the AI took and so you just help the person navigate these choices.

Of course if the project has to actually grow into a product at some point you would have to rewrite good chunks of it.

[apwell23]

even prototyping hasn't become "fast" because you cannot purely vibecode even a prototype.