AI won't save a product that was never composable
Most product teams shipping AI right now are following roughly the same playbook. A chat sidebar. A summariser. A copilot panel that can answer questions about whatever's on screen. Each release gets a launch post. Each one tests reasonably well in isolation. And yet, a year in, something is off. The product feels louder, not better. Customers use the AI features once or twice and go back to doing things the old way. The team keeps shipping. The needle doesn't move.
This is not an unusual story. It's close to the median story. And the diagnosis most teams reach for, that the prompts need tuning or the model needs upgrading or the UX needs another pass, is almost always wrong. The problem is further upstream, and it's structural. The product wasn't built to be recomposed. AI can only ever sit on top of it. And AI on top of a rigid product is a feature, not a transformation.
AI won't save a product that was never composable.
What composable actually means
A composable product is one whose core capabilities exist as small, reusable pieces that can be assembled in different ways depending on context. Call them primitives. A primitive is something the rest of the product is built out of, not something the product has. A block of text in Notion is a primitive. A page is an assembly of blocks. A database view is another assembly. The product is not the pages, the product is the primitives and the rules by which they compose.
This distinction sounds small and it isn't. When AI arrives at a composable product, it has something to work with. It can rearrange the primitives, suggest new compositions, surface the right ones at the right moment. The primitive layer is the surface that AI reasons over. Without that layer, AI has nowhere to stand. It can describe what it sees on the screen, it can generate new content to add to the screen, but it can't change what the product fundamentally is, because the product is the screen, and the screen is frozen.
Why most products aren't built this way
Because, for most of the history of software, they didn't need to be. The consumer of software was a human, the human needed a screen, and the screen was the deliverable. Design teams produced screens. Product teams scoped features to screens. Engineering teams built screens. The entire operating model of product development, from research through launch, treated the application as the unit of work.
Inside that model, primitives happened, but they were an implementation detail. Components got reused when convenient, rebuilt when not. A button here, a button there, slightly different, both fine. Design systems emerged as a partial response to this, but they mostly worked at the visual layer. Two buttons that looked the same could still behave completely differently, because the primitive was the picture of the button, not the button itself. The real composability, where capabilities and behaviours are genuinely reusable across contexts, rarely made it past the pitch deck.
This was fine. The cost of this approach was duplication and inconsistency, and those are annoying but survivable. The product still worked. Users still got value. Nobody was grading the architecture.
AI grades the architecture.
The shift
When the consumer of software is no longer only a human, everything downstream of that assumption becomes negotiable. An agent doesn't need a screen the same way a person does. It needs to know what the product can do, what state things are in, and what actions are available in this moment. The screen, for the agent, is an artefact it either reads or renders, not an input it authors. The agent wants primitives.
Products built on primitives can serve this without rebuilding. The same capabilities that compose into screens for humans can compose into operations for agents, views for different contexts, or outputs that didn't exist a year ago. Notion absorbed AI by changing how its existing primitives compose, not by becoming a different product. Figma absorbed AI by treating the canvas and its objects as the primitive layer the model operates on. Linear's issue is a primitive that views, automations, and now agents all compose around. None of these teams had to rewrite their product to let AI in. They had to reconfigure.
Products built as collections of applications face a different situation. The primitive layer isn't there. The product is the screens, and the screens were never designed to be recomposed by anything other than the humans who authored them. When AI arrives, there's nothing for it to reason over except the surface. And reasoning over the surface produces the chat sidebar, the summariser, the copilot panel. Features, not transformation.
The approach problem
None of this is a tooling argument. It's not about Figma versus code, or design systems versus ad-hoc. It's about how design and product management approach the problem in the first place.
In an application-centric approach, the question is "what should this screen do?" The primitive, if it emerges at all, emerges as a byproduct of the screen. In a platform-centric approach, the question is "what is the capability, where else does it belong, and what's the minimum primitive that expresses it?" The screen becomes an output of that question rather than the starting point.
The pattern inside an application-centric product review is familiar. A team walks through a feature, the flows, the edge cases, the visual treatments. It's detailed and thoughtful work. And somewhere in the middle someone asks, "what's the primitive underneath this?" and the room goes quiet. Not because the team is inexperienced. Because the question is outside the frame they were given. They were asked to design a feature. They designed a feature. The question about the primitive layer belongs to someone else, somewhere else, and in most organisations that someone doesn't exist.
This is the trap. Not the tooling. Not the team's talent. The frame.
The uncomfortable part
If a product has been built application by application for years, the primitive layer underneath doesn't exist. You can't retrofit composability. You can only build it, which means that underneath whatever exists today, a real primitive layer has to be constructed, and the applications above it have to eventually become consumers of that layer rather than islands. The surface can survive the transition. The architecture cannot.
The objection writes itself. We can't rewrite the product. We have customers, deadlines, commitments. And the answer is that nobody's asking anyone to rewrite the product this quarter. The answer is that the work starts now and takes years, and the teams that start now will have something to show in two years while the teams that keep shipping application-shaped features will have a pile of AI bolt-ons and a product that still doesn't feel transformed.
The real cost of waiting is that every feature shipped in the application-centric mode during that wait is debt. It's work that has to be unpicked or migrated when the primitive layer eventually gets built. Shipping faster in the old model is shipping more debt, not more product.
What this means in practice
For designers, before you design a screen, ask what capability sits underneath it, where else that capability appears in the product, and whether it already exists as a primitive somewhere. If it doesn't, the screen isn't the deliverable. The primitive is, and the screen is one way of rendering it.
For product managers, before you scope a feature to an application, ask whether the underlying capability belongs in the platform layer. If it does, the feature is a surface on top of a primitive, and the primitive is the actual scope. Planning in applications is planning in surfaces. Planning in primitives is planning in product.
For design and product leaders, look at how your teams are organised. If each team owns an application, the primitive layer belongs to nobody, and nobody will build it. Teams organised around primitives produce composable products. Teams organised around applications produce applications.
For executives, the question is not what your AI strategy is. The question is whether your product is a platform of primitives that applications render, or a collection of applications that AI can only be bolted onto. If you don't know, that's your answer. If you know and it's the latter, the work to change that starts now, and every quarter you delay it gets more expensive.
The fork
There's a moment coming, for many products, where the gap between the composable and the non-composable stops being subtle. Customers will feel it. The products that absorb AI by recomposing will feel alive, responsive, increasingly capable in ways that weren't announced. The products that absorb AI by bolting it on will feel the same as they did before, with more sidebars.
The gap won't be closed by better prompts or better models. It will only be closed by the slow, structural work of building the primitive layer that should have been there the whole time.
AI won't save a product that was never composable.
Julian Oczkowski is a designer with 29 years of experience, former contractor for Adobe, IBM, and Danone, and the creator of the AI For Work YouTube channel. He publishes weekly tests of AI tools for designers, product managers, and engineers.
YouTube: https://www.youtube.com/@aiforwork_app
LinkedIn: https://www.linkedin.com/in/julianoczkowski
GitHub: https://github.com/julianoczkowski
Top comments (0)