How can you go the opposite direction? Instead of using LLMs to produce more code, can you produce less, maybe higher abstraction code?

There is extraordinary in the ordinary.

I guess I'm thinking where is the "fail fast" that is fast enough, but also not quitting too early?

And I have to say that no one tries to build a failed business. Founders can be really earnest about their intentions, work harder when they see the cracks, but often it just doesn't work, they don't find the right way before it's too late.

Maybe just before the end someone tries to siphon the funds into private account or assets into their next venture, but you tend to get caught doing so.

But everyone makes mistakes and bad deals in product development or they go out of business.

You could write more code, but you also could abstract code more if you know what/how/why.

This same idea abstracts to business, you can perform more service or you can try to provide more value with same amount of work.

Any decision maker can be cyberbullied/threatened/bribed into submission, LLMs can even try to create movements of real people to push the narrative. They can have unlimited time to produce content, send messages, really wear the target down.

Only defense is to have consensus decision making & deliberate process. Basically make it too difficult, expensive to affect all/majority decision makers.

Maybe you have to accept that communities are here and now, but they can dissolve at any time.

Even if you can achieve awesome things with LLMs you give up the control over tiny details, it's just faster to generate and regenerate until it fits the spec.

But you never quite know how long it takes or how much you have to shave that square peg.

Customers don't care if Sharepoint uses LLM, they just want to share ideas, files, reports, pages, etc. If LLM makes it easier, great! If some other product makes it easier, great!

It's not about the product it's about the results.

When you sell a service, it's opaque, customer don't really care how it is produced. They want things done for them.

AI isn't killing SaaS, it's shifting it to second S.

Customers don't care how the service is implemented, they care about it's quality, availability, price, etc.

Service providers do care about the first S, software makes servicing so much more scalable. You define the service once and then enable it to happen again and again.

Operational excellence survives, no matter the origin.

However I don't still believe in vibecoding full programs. There are too many layers in software systems, even when the program core is fully verified, the programmer must know about the other layers.

You are Android app developer, you need to know what phones people commonly use, what kind of performance they have, how the apps are deployed through Google App Store, how to manage wide variety of app versions, how to manage issues when storage is low, network is offline, battery is low and CPU is in lower power state.

In what application would you load all users into memory from database and then filter them with TypeScript functions? And that is the problem with the otherwise sound idea "Functional core, imperative shell". The shell penetrates the core.

Maybe some filters don't match the way database is laid out, what if you have a lot of users, how do you deal with email batching and error handing?

So you have to write the functional core with the side effect context in mind, for example using query builder or DSL that matches the database conventions. Then weave it with the intricacies of your email sender logic, maybe you want iterator over the right size batches of emails to send at once, can it send multiple batches in parallel?