zlacker

>>namany+(OP)
It's a tale as old as time that developers, particularly junior developers, are convinced they could "slap together something in one weekend" that would replace expensive SAAS software and "just do the parts of it we actually use". Unfortunately, the same arguments against those devs regular-coding a bespoke replacement apply to them vibe-coding a bespoke replacement: management simply doesn't want to be responsible for it. I didn't understand it before I was in management either, but now that I'm in management I 100% get it.

>>bandra+s01
We are certainly closer now to being able to prototype and go to market faster with a product. In one weekend is a little much but I think its hard to deny that building will continue to expedite. What most developers don't think about is that the marketing, sales, customer service are all non-trivial parts of the business/product and all require legwork that is more than just sitting at an IDE. The nail in the coffin is that the data is a large part of company moats, and new products need time in the market to get that. Migration is also a long process and risky...so to get customers, a newcomer needs to provide way more value than what the incumbent gives.

I imagine you're going to have people trying to automate the whole GTM lifecycle, but eventually the developer that thinks they can bootstrap a one man enterprise without actually doing any kind of social interaction will run into a wall.

>>mym199+j81
> We are certainly closer now to being able to prototype and go to market faster with a product.

What are the higher-order effects when anyone can do this, and *aaS becomes a market for Lemons?

>>overfe+ud1
I think that just because anyone can do it, doesn't mean they will. Lots of people have really great ideas but very few actually commit to execution. Ultimately ROI will go down, deincentivizing the commercialization of that thing someone wanted to bang out in a weekend.

In the very long term, software will become a commodity, as you mentioned. Process and workflow may move into JIT delivery for the need at hand, in theory the data layer will be comprehensive and clean and the days of clicking around a bunch of stuff to fulfill process needs will move into a lower latency activity like...talking to your agent.

I saw a quote today by Brian Eno(1995) that said: "So the question becomes not whether you can do it or not, because any drudge can do it if they're prepared to sit in front of the computer for a few days; the question then is: of all the things you can now do, which do you choose to do?" and it resonated with me a lot.

>>mym199+zm1
> Lots of people have really great ideas but very few actually commit to execution.

This is true when you had to work hard for those ideas. Now you have LLMs. It means more people can sling a lot more crap at walls with fewer barriers to entry.

>>Secret+Xo1
Good execution doesn't get easier with an LLM.

>>bawolf+fx1
No, and I agree with the conservative sentiments here. However, putting together a SaaS alternative that frees up money during a crunch, and now with the pet features your boss has always wanted, is potent indeed.

>>gritsp+xP1
You've hit the nail on the head. Immediate gratification.

AI is like sugar. It tastes nice, gives you energy quickly - what's not to like? The gratification is immediate, and if "today is all that matters" it's brilliant.

The problem with sugar (and AI) is medium term. So sure, that junior dev whipped up the whole framework in ClaudeCode, and it's humming nicely. Junior dev gets credit, and after a couple years moves on somewhere else.

Then something changes. Windows. TLS. Code Signing, whatever. We need to update the program to the change. Just a small tweak. Junior Dev has gone (or is otherwise occupied) so we'll get new-Junior-dev to do it. Is he expected to do the change at the code level? Or at the prompt level? Will ClaudeCode in 2029 be able to maintain ClaudeCode Code from 2026? Or will it want to rewrite everything? Will new-junior-dev have the skillset to prompt as well as first-junior-dev? Was the code good enough that a dev could just "take it over"? Or was it "it works, let's use it" standard?

AI makes everyone look good in the short term. But it worries me for what happens in 5 years, 10 years, and so on. Sugar is great, but you can't live (long term) on sugar. Sometimes you need a proper meal plan.