[wongarsu]

> No, a non-engineer can't just spin up the next great app. Even with the newest models and a great prompting/testing system, I don't think you can just spit out high quality, maintainable, reliable code

I think most engineers vastly overestimate how important high quality, maintainable, reliable code is to product success. Yes, you need an experienced engineer to steer Claude into making good high-quality code. But your customer doesn't see your code, they don't see how many servers you need or how often an on-call engineer is woken up. They just see how well the app meets their needs

I predict we will see a lot of domain experts without engineering background spin up incredibly successful apps. Just like the Tea app many of them will crash and burn from poor engineering. But there will also be enough people who've grown wise to this and after reaching some success with their app spend the resources to have others mitigate all the unknown-to-them issues

[tonyarkles]

> I predict we will see a lot of domain experts without engineering background spin up incredibly successful apps. Just like the Tea app many of them will crash and burn from poor engineering.

This rollercoaster is going to be wild to ride over the next decade. I've done a few experiments where I've intentionally "vibe coded" either a few features for an existing project of mine or for a few completely clean-sheet ideas.

I completely agree with you. There are going to be a lot of domain experts who do successfully spin stuff up.

> But there will also be enough people who've grown wise to this and after reaching some success with their app spend the resources to have others mitigate all the unknown-to-them issues

Here's the part that shocked me when I tried this... it did not take long for the no-engineering-guidance codebases to turn into complete disasters. Like... in an afternoon I had a pretty functional application that filled a gap for me. It was also... I don't think it'd remain even remotely maintainable for more than a week based on the direction it was going.

We live in interesting times.

[ramathornn]

> I think most engineers vastly overestimate how important high quality, maintainable, reliable code is to product success.

I agree, the only thing I can’t get past is the black box approach. For the majority of business stakeholders, they can’t/ don’t want to read the code that Opus, or any other agent produces. It will most likely work, but if it doesn’t, they have to rely on the agent to find & patch.

I’m with you though, it’s getting incredibly good at doing that, but that concept of “It works but I don’t know why” seems very dangerous at scale.

That last mile for apps isn’t trivial imo; to take them from “it’s cool and does exactly what I want”, to a scenario where all employees at our company can use it.

But who knows I might just be a naive dev lol, this stuff is changing too quickly.

[aleph_minus_one]

> I think most engineers vastly overestimate how important high quality, maintainable, reliable code is to product success.

Rather: Many software developers overestimate how important high quality, maintainable, reliable code is to initial product success.

Once the product is highly successful, a high quality, maintainable, reliable code pays huge dividends - and I have a strong feeling that most business people vastly underestimate this dividend.

[esseph]

Vibecoding to production and $1mil ARR (random number) now proves out the application basics and market value which pays for it to be redone correctly :)

[Ntrails]

There won't be a re-do, there will be a feature request pipeline. Correct is a term of art and unlikely to come into it. If you start losing customers because of reliability, they'll ask Claude to fix it. If that doesn't work you're gonna be in trouble, because you won't have people.

[esseph]

Maybe I should have left a /s ...

[BobbyJo]

> I think most engineers vastly overestimate how important high quality, maintainable, reliable code is to product success. Yes, you need an experienced engineer to steer Claude into making good high-quality code. But your customer doesn't see your code, they don't see how many servers you need or how often an on-call engineer is woken up. They just see how well the app meets their needs

Your customers definitely see the quality of code, just by proxy. When features take forever to ship, and things fall over all the time, those are code quality and design problems.

Honestly, code quality is somewhat more important right now, because use common and clear patterns will help AI make better changes, and using a more resilient architecture will you hand more off without worry things will fall over.

[Tanjreeve]

Customers do see poor performance, long outages and slow releases of new features though. "Customers don't see the code" isn't a new insight.