Comment by daitangio

Back in the day, if you went to a website you could always tell who wrote their HTML by hand and who used a tool like GruntPage, Dreamweaver, etc. even without looking at the META tags. The by-hand stuff was like a polished jewel that had only as much layout, styling, and markup as needed to get the desired effect. The proprietary web editor stuff was encrusted with extraneous tags and vendor-specific extensions (like mso: attributes and styles in GruntPage).

Then as now, if you let the machine do the thinking for you, the result was a steaming mess. Up to you if that was accessible (and for many, it was).

Where's the part where it's different from the existing market?

This was said about large frameworks like electron on the desktop, but outside of some specific technical niches it literally doesn’t matter to end users.

A beautiful vision.

If the vision were true, we should see it happen with normal goods too. Quality physical goods do not beat the shit goods in the market : crap furniture is the canonical example (with blog articles discussing the issue).

Software (and movies) is free for subsequent copies, so at first sight you might think software is completely different from physical goods.

However for most factory produced goods, designing and building the factory is the major cost. The marginal cost of producing each copy of an item might be reasonably low (highly dependent on raw materials and labor costs?).

Many expensive physical goods are dominated by the initial design costs, so an expensive Maserati might be complete shit (bought for image status or Veblen reasons, not because it is high quality). There's a reason why the best products are often midrange. The per unit 2..n reproduction cost of cheap physical goods is always low almost by definition.

Some parts of iPhone software are high quality (e.g. the security is astounding). Some parts are bad. Apple monetisation adds non-optional features that have negative value to me: however those features have positive value to Apple.

yeah this is it ...

90%+ is a stretch. Anecdotally I have cleaned up a vibe coded PR and removed at least half of the code. The thing with the LLM is that often they will make some decision up front that has downstream ramifications for how the entire project's code is structured. I don't think I've seen an LLM re-visit it's assumptions, instead they code around them.

In the case I saw, it was rust code and the LLM typed some argument as a Arc<Mutex<_>> when it absolutely did not need to, which caused the entire PR to inflate. The vibe coder apparently didn't catch this and just kept it vibing... Technically the code did what it needed to do but was super inefficient.

It would have been easy for me to just accept the PR. It technically worked. But it was garbage.

I've never seen 8000 -> 40, but I have done ~10 kLoC -> ~600.

Aggggressively "You can write Java in any language" style JavaScript (`Factory`, `Strategy`, etc) plus a whole mini state machine framework that was replaceable with judicious use of iterators.

(This was at Google, and I suspected it was a promo project gone metastatic.)

The original used a Shlemiel the painter algorithm, a whole bunch of "enterprise" coding patterns, and its own implementations of a bunch of things we already had. Including domain objects, which meant that a whole bunch of excess glue code was needed to interface with the rest of the system.

I guess it depends on how much you like things like well-obfuscated smoke tests and mocks that don't accurately simulate relevant parts of the behavior of the module they're mocking.