Blog - nuwacom

The End of Software You Have to Obey

As we just launched nuwacom Apps, our code-generation solution for enterprise software. In this piece, our founder & CEO, Christophe Folschette, shares the underlying vision that is driving us. He argues why he's convinced that software ought to become malleable - and why well-designed harness layers will unlock the future of enterprise applications.

We just launched Apps in nuwacom - a way for teams to build their own business software in natural language, without requiring developers. But there is significantly more behind this launch than your average feature release. That is what I want to talk about today.

In essence, I think enterprise software at large is headed in a new direction. That is why I am stepping back from our product for a moment and trying to draw the bigger picture. What I am observing, I believe, are the early stages of a tectonic shift in the software market. And we intend to be active contributors in making it happen.

Let me start with a confession from twenty years in this industry.

The software always won

When we built Talkwalker (my former startup that I sold a couple of years ago), we sold enterprise software to over 3,000 of the largest brands in the world. I am proud of what we built. But I also watched, again and again, a pattern that anyone who has sold or bought enterprise software will recognize instantly.

A customer would come to us with a process. Their process - shaped by their market, their history, the particular way their teams had learned to work. And somewhere in the implementation, a negotiation would begin. Not over price. Over shape. The software could do many things, but all-too-often not their way. Thus, the process bent. In one case, the customer dropped a step because the system had no way of handling it. In another instance, a team invented a spreadsheet to create the report that Talkwalker couldn't build natively. And often, workarounds became a habit, and the habit became "just how we do it here."

The software always won. The humans, who understood their own work better than any vendor possibly could, adapted themselves to the tool. That's by design. Traditionally, if you sold software, it had to be "good enough" for a large number of customers, not a bespoke solution for every team.

But multiply that across every system a company runs - the CRM, the ticketing tool, the HR platform, the analytics suite - and you arrive at the defining tax of modern enterprise work: organizations spend enormous energy conforming to their software instead of the other way around.

By and large, we accepted this because there was no alternative. Custom software meant developers, budgets, roadmaps, and a maintenance burden that never ended. So we bought, and we bent.

That era is ending. Not because software companies are getting better at predicting what their customers need, but because, for the first time, software is becoming something we can reshape ourselves.

A word for what's happening: malleable software

The most useful term I have found for this shift comes from outside the enterprise world. Researchers and designers in the "tools for thought" community have been developing the idea of malleable software - software that end users, not just developers, can reshape, extend, and reconfigure to fit how they actually work.

Geoffrey Litt captured the turning point in his 2023 essay, Malleable software in the age of LLMs. His argument was simple and, I think, correct: large language models are the missing enabling technology. Once a machine can turn natural-language intent into working code, the bottleneck that kept software creation locked behind professional developers dissolves. Litt foresaw a world of one-off tools, in-house builds replacing off-the-shelf SaaS, and software shaped at the point of use.

By 2025, the idea had matured into a manifesto from Ink & Switch, which framed it beautifully: "The original promise of personal computing was a new kind of clay. Instead, we got appliances: built far away, sealed, unchangeable." Their vision is software users can reshape with minimal friction, where "modification becomes routine, not exceptional." Simon Willison called it a "delightful manifesto," and the metaphor that stuck with me most from that community is this: we should be building tools, not appliances - i.e. a kitchen knife, not an avocado slicer.

For anyone who has spent their career inside locked-down enterprise systems, this hits with real force. The idea is not to speed up software development. It is to enable a different relationship with software - one where the tool finally yields to the work.

The honest gap in the dream

That's the point where I want to be careful, because this is where the genuinely interesting problem lives - and where I think a lot of the current enthusiasm in the malleable software community gets ahead of itself.

Generating code is not the same as delivering malleable software. The malleable-software thinkers know this; it is, to their credit, in the fine print of their own work. The open questions they keep returning to are the hard ones: How do AI-generated tools compose with one another? How do they share data without spawning a new mess of disconnected silos? Litt himself, now a design engineer at Notion, has pushed back on the assumption that malleable means disposable. His analogy is a home you arrange over time:

"And so I think of it much more as kind of crafting an environment over time that’s actually more stable and predictable, not only for myself, but also for my team. Having shared environments that we all work in together that are predictable is also really important, right?"

But there's a word in there that is critical: team. Because that's where the consumer framing and the enterprise reality part ways.

When an individual builds a throwaway tool for themselves, the questions of knowledge, permissions, and governance barely register. When an organization does it, those questions are essential. A prompt-to-app tool that produces a slick interface but cannot see your company's data, does not respect who is allowed to see what, and has no governed place to live, has not solved the enterprise problem. It has created a new one: thousands of ungoverned little apps, each a fresh silo, each a fresh liability. For a consumer, that is freedom. For a regulated enterprise, it is a nightmare.

So the real question is not "can AI write the app?". The answer to that is, increasingly, yes, it can. The real question is: what does the app stand on?

Harness is king

The AI engineering community has converged on a useful term for this. When they build agents, they talk about the harness - everything wrapped around the raw model that makes it actually capable. The model is the intelligence; the harness is the context it can understand, the tools it can use, the actions it is permitted to take, the memory it carries, the environment it runs in. As OpenAI's teams have put it, from the agent's point of view, anything it cannot access in context effectively does not exist. The harness is becoming, in their words, the operating system around the model.

I want to borrow that term and lift it out of the engineering domain, because it is exactly what business software has been missing.

For a business user building their own tool, the harness is mission-critical. It contains the company's knowledge, its data sources, the permissions that govern who sees what, and the processes that define how work actually flows. An app generated without that harness is a clever orphan. An app generated within it is something else entirely — a tool that knows where it is, what it is allowed to touch, and how to act consistently inside the organization that created it.

This is precisely what an AI operating system is for. The harness layer is the foundation that makes generated software both relevant and trustworthy enough to work in a professional setting. Knowledge, connectors to existing systems, defined skills, and an inherited permission model are not the supporting cast. In the enterprise, they are essential.

What this means for the SaaS question

This reframing also cuts through a debate that has become unhelpfully binary. You will have seen the headlines. Klarna shut down more than 1,000 SaaS tools - Salesforce and Workday among them - to unify its knowledge into a custom AI stack. Satya Nadella has argued that traditional business applications are essentially "CRUD databases with business logic" whose logic is migrating to the AI layer. IDC predicts that by 2028 pure seat-based pricing will be obsolete, and that the interface of the future will not be the SaaS dashboard but an orchestration layer sitting above it.

It is tempting to read all of this as "SaaS is dead." I don't believe that, and I think the lazy version of this take is wrong. Systems of record with deep data and decades of hardened logic are not going to vanish, and enterprises should be skeptical of anyone who tells them to rip everything out. The CIO writers who note that "the death of enterprise software may be greatly exaggerated" are right too.

The truth is more interesting than either extreme. AI will not cause a world with no SaaS. But it opens the door to software that fits - at scale. The path that, I believe, can actually lead business users to the promised land of malleable software and tailormade tools needs to be grounded in reality.

And in said reality it's a fact that most enterprises have an elaborate software stack and data architecture. No solution will just replace those. Instead, the legacy architecture must be a block on which the people in the organization can build. That is, they need to be able to create a layer above their existing systems where the work actually happens, shaped by the people doing it.

In practical terms: your CRM stays. But the bespoke tool your customer-success team needs, the one no vendor will ever build because the market of one is too small to be worth it, finally becomes something that your team can have. Build-versus-buy stops being a capital-expenditure decision made once a year and becomes a Tuesday-afternoon decision made by the person with the problem. Because just building it is suddenly a feasible and fast option.

Where we are actually heading

So here is the trend line I see, drawn through twenty years of selling software and a few years of watching the dynamic I outlined in the opening paragraphs reverse.

Software is becoming clay again. But in the enterprise market, clay alone is not enough - you need a kiln, a workshop, and rules. The companies that win the next decade will not be the ones that generate the most apps the fastest. They will be the ones whose generated software stands on a real harness: connected to their knowledge, governed by their permissions, composable with everything else they run, and native to an environment that understands the organization rather than sitting outside it.

That is the conviction behind what we just shipped. nuwacom Apps is our first concrete step toward it - not an app factory, but business software born inside the AI operating system that already knows the company. It is the beginning of the answer to the question that the malleable-software pioneers have been honest enough to keep asking.

Software made us adapt for a long time. I spent a good part of my career on the selling side of that bargain. I find it genuinely exciting that we now get to build the other side - the one where the tools finally bend to the people.

If you, too, are wrestling with these questions, I would like to hear how you are thinking about them. And if you want to see what this looks like in practice, read the launch announcement or come build something with us.