people who know how to formulate the problem already rule the world. AI will just be a catalyst.

If you have good market fit it means you were lucky or you knew which problem your potential customers had.

I believe the presentation/analytics layer has become malleable, possibly parts of the business logic layer - you still need a higher % of trustworthiness than LLMs can provide for parts of the business and data layers.

Code has never been the bottleneck once you’re out of the CRUD boilerplate phase.

People are still mentally locked in to the world where code was expensive. Code now is extremely cheap. And if it is cheap, then it makes sense that every customer gets their own.

Before - we built factories to give people heavy machinery. Now, we run a 3d printer.

Everyday I thank SV product-led growth cargo cults for telling, sometimes even forcing our competition to not go there.

People keep saying things like this, but what's an actual example of a viable product created that way? Talk is cheap, I want to see it.

good luck replicate this on financial,health,military,cyber etc field

lmao

malleable software? what a joke

As much as I want to believe the opposite to be true as a “power user”, good tools often force you to adopt better practices, not the other way around.

But (and I'll copy & paste a comment I wrote a few days ago) I disagree. This existed way before LLM. Open source alternatives to most products are already available. And install them and deploy them is much easier than do it with LLMs, and you get updates, etc.

People don't want the responsability to keep them updated, secured, deployed, etc. Paying a small amount will always be more convenient than to maintain it yourself. The issue was never coding it.

Also training new people is annoying when things change too often; people can already use Jira/Linear/Monday/whatever , they don't want some completely flexible thing that is malleable.

Also, people are not all perfectionists with long term goals and visions. People who 'change' some part of their work flow that helps them NOW; they won't care about speed, scaling, deployment etc, so they will do something to make their work easier and then leave it there and possibly ignore it forever to rot. Which might have all kinds of fun implications.

I guess when we have AGI with a few 10 million+ context window for cheap, it will be different but the current llms would just leave a massive amount of rot all over the place, quickly forgotten and not usable by anyone but the original creator.

IME: LLMs don't "thrive" in messy open-ended spaces. They handle spaces like that better than traditional code, and traditional code handles structured spaces a lot better, but LLMs still do perform better in structured spaces than unstructured ones. Giving them lists of tools, schemas for data, consistent examples, etc always produces better results than not doing this.

The correlate thesis you have to make is: Do humans work better in unstructured spaces. This can be true for highly creative and individual work, but generally (and especially in the enterprise SaaS world) the opposite is true. The Structure is how you keep the users of the product aligned on one pattern of usage. E.g. giving people the ability to just create whatever ticket fields they want in Linear ends up being useless because you'll end up with 10 fields that do similar things; the friction structure introduces is necessary because while it can cost a few seconds up-front as users learn how things are done, it saves time down the line as your organizational tools (filtering, dashboards, reports, etc) are aligned on the structure.

Its also 100% the case that oftentimes companies buy SaaS tools not to solve their problems, but to help them better structure the problems they have so they're even solvable at all. Think about Sentry: The end-goal of Sentry is to solve issues in web applications, for sure. But that's not why people buy it. I could do that without Sentry; but Sentry adds structure to the errors, it adds deterministic workflows to the errors, and it provides excellent SDKs to report them. Sentry's value isn't actually in the end-goal; its value is in the structure it adds every step before the end-goal. Accelerating the inputs by adding formality to them ends up accelerating the end-goal.

Maybe we're in some kind of local-optimal, where all project management software has coalesced around a few user journeys, and there's some better approach out there to be discovered.. But I don't see why an accounting software company, games studio, or vehicle manufacturer, would dedicate even 1% of its resources into crafting a malleable bespoke project management software toolkit.

It goes against the concept of comparative advantage, and I can't think of any successful enterprise that's bet against comparative advantage and won.

But yeah, the demand for webhooks, integration options, embedding's will win IMO. I imagine more demand for API-first products.

IME getting LLMs to write flexible code is not easy and one of my biggest turnoffs for coding agents. The code they tend to produce is usually more standardized and lacking of context. It'll "work" but that doesn't mean it "works".

And I think almost everyone is aware of malleable software, it isn't very niche. If you took a programming class your teachers probably told you to write functions and make them small and self contained. A lot like the Unix Philosophy[0].

One thing I find different about this style is that it tends to shift time away from writing lines of code to planning. Which, again, the planning part is what the LLMs tend to be weak at[1]. You can't plan everything but a benefit of flexible code is that you can adapt to new challenges and requirements. It's a good style because a constant in software development is that the requirements by the end of the project (does it end?) are going to be different from those you started with. If your code is inflexible then you have to hack around your existing code. But if it is flexible you add the new routines and leverage existing ones as much as possible. But for that to happen the existing routines should be decently singular in purpose. Function call overhead tends not to be the bottleneck but if the profiler says they are then yeah, fuse functions as need.

[0] https://en.wikipedia.org/wiki/Unix_philosophy

[1] I find their strengths are in writing generic routines, helping narrow in on fuzzy or difficult to describe things that are hard to google, helping you get up to speed on a novel codebase, ditto for a library or language, or simply just throw away code. But not for things where foresight is necessary. But yes great when your job is to glue things together. It's just that if you're doing a lot of gluing there's probably a better way

The parts of SAP that's composable workflow stuff? Doubt it, because the types of ABAP workflows in SAP that might be "malleable" are the sort of stuff that often legally requires correctness and reproducibility - kinda the exact opposite of a good LLM use-case.

And as much as I'd like to actually own my software, SaaS is preferable for major corporations for lots of legal and accounting reasons like easier revenue recognition. They're going to keep pushing it because it makes all the parts of being a software company that don't include writing the actual software easier.

Even a visual tool like blender should expose their full GUI as a text API. It needs a bit of adapting, specifically for domain-specific structs (which should be retrievable via calls like 'select-bb' or 'select-coordinates'), but after that's done it's a game changer.

That class of software has a lot of proprietary GUI's that look slick and people are familiar with, but who cares about familiar in a world where the other software lets me point my LLM at its help file and build me whatever gui/tui/script/voice integration I can think of.

None of this makes any sense. Do you know how computers work?

This "AI" summer has turned into a drug fueled orgy of magical thinking. I am at my tether's end. I need to leave this industry to preserve my sanity at this point.

When it resonates with customers, it feels great.

Customizable SaaS is really just a side effect of the deeper need for control, because with control you can execute better. And when that lines up with capital, market fit, and a clear purpose, it creates more than efficiency, it creates meaning.

The companies that never settle, always chasing new patterns, usually end up with customers who don't enjoy them and employees who don't enjoy the software either.

Defining a bespoke system config was always something that never had the time, desire, or deep familiarity with various config formats to do. With Claude Code or ChatGPT can now generate Wezterm/tmux/neovim/etc config files and get exactly what I want not knowing a single thing about specific config file formats.

* https://dotfiles.github.io

But quite honestly, the SaaS world is also due a culling - i'd argue if the software you work on as a SaaS business is replaceable by a malleable piece of AI software, you're closer to Pets.Com than a suitable business model.

For anything more than single use there is a bit of a risk of it turning into a mess that collapses under it's own weight. A bit like a couple bad decisions at the start of a coding project comes back to haunt you later. So I struggle to see this replacing core infrastructure of anything in long run.

Malleability is opposed to institution. When everything is hyper malleable everybody will need to be trained and change management will take up a large proportion of time.

The main reason why a lot of people go with Jira is not quality of the software - but the institutional buy-in. Employees, current and prospect, know how to work with the tool.

The greater change is likely labor disruption.

Malleability / flexibility can introduce unreliability.

We need to get over a hump, where software becomes more humanlike, but just like with good engineers over time we can probably arrive at a place where we can trust our new malleable solutions just like a new colleague turning out to be great.

Isn't the exact opposite of what AI is good at? That sounds like a great way to get tons of hallucinations. Every "how to AI good" guide I read is all about providing it with ample structure and narrow instructions.

When you find a rigid workflow that is both widely applicable and useful, that's how the most valuable companies are made. Those workflows can scale up with little intervention giving them incredibly high yield.

I think the new challenge is introducing flexibility in a controlled manner so we can minimize the added inconsistency needed to achieve broader goals. That way the workflow can find the right balance between robustness and flexiblity for the task at hand.

SaaS is a business model while malleable vs. rigid is a property of the software itself.

It's a gigantic grift.

I wasn't talking about two instances for scaling smartness, I meant applying two instances to different problems. That very much scales.

> This doesn't follow. After all, humans are as smart as humans ...

In the hypothetical case of humans capable of producing the one true AI system (real AI or AGI or however its called, because marketing has taken the previous term), then this system is capable of producing another system by definition. Humans are capable of following Moores law, so this system will as well. So this chain of system will explore the set of all possible intelligent systems restricted only by resources. It isn't bound by inner problems like "(good nutrition, education, etc)", because it is a mathematical model, its physical representation does only matter as so far as it needs to exist in this hypothetical case.

> AI is a black box

In this case, the black box "humans" was able to produce another thing reproducing their intelligence. So we have understood ourselves better than we currently do.

Note, that every intelligent system is completely able to be simulated by a large enough non intelligent statistical system, so intelligence isn't inferable from a set of inputs -> outputs. It's really the same as with consciousness.

> And why wouldn't we hit some sort of technical roadblock? Can we expect to see a 5000km/h car?

Yes. We are capable of accelerating "objects" to 0.99..c. It's not impossible for us to accelerate a "car" to nearly light speed, we "just" need enough energy (meaning matter as energy).

> technical roadblock at (arbitrarily) 1.5x human intelligence

I wrote "until the limit of information density". Whatever this may be.

I intended to point out, why a system "equivalent to human" is actually equivalent to "digital super intelligence meaning 'smarter than all humans put together'".

---

You don't need to tell me you don't think this system will exist. I think this will end the same as the attempts to build a machine creating energy. My personal understanding is this: A system (humans) can never completely "understand" itself, because it's "information size" is as large as itself, but to contain something, it needs to be larger then this. In addition that "understanding" needs to be also included in its "information size" so the size to understand has at least doubled then. This means that the largest system capable of "understanding" itself has the size of 0.

In other words understanding something means knowing the whole thing and abstracting to a higher level then the abstractness of the system to be understood. But when the system tries to understand itself, it's always looking for yet another higher abstraction to infinity, as each abstraction it finds is not yet enough.

This idea comes from the fact, that you can't prove that every implementation of a mathematical model has some behaviour, without formalizing every possible model, in other words inventing another higher model, in other words abstracting.

Says who?

> Given enough resources, we can have enough particle generators as there are particles in a car.

Given by whom? I said in practice—you can't just assume limitless resources.

> Except when the 300IQ thing is found by chance. When the system is reproducible and you aren't bound by resources, then a small chance means nothing.

We're bound by resources! Highly so! Stop trying to turn practical questions about what humans can actually accomplish into infinite-monkey-infinite-typewriter thought experiments.

> We don't think other humans are intelligent solely by their behaviour

I wouldn't say that, haha

> It's not about encoding the result of having understood. It's about the process of understanding itself.

A process can be encoded into data. Let's assume it takes X gigabytes to encode comprehension of how a hard drive array works. Since data storage does not grow significantly more complex with size (only physically larger), it stands to reason that an X-GB hard drive array can handily store the process for its own comprehension.