Don't Add AI to Your Products. Rethink Them from Scratch.

I’ve thought about this several times in the last few months, with a slight uneasiness. I’ve spent twenty years building digital products, long enough to remember well what it was like when Web 2.0 felt like the answer to everything, and long enough to have lived through the mobile revolution from the inside, with that “OK, something is really shifting here” feeling.

With AI the same thing is happening. And yet, looking around, I see many companies reacting as if it were just another update. An add-on. A plugin.

Maybe that’s the problem.

The “let’s add a bit of AI” trap

By now it’s almost a reflex. A chatbot in customer service. A generated summary in the dashboard. A copilot in a sidebar. A “smarter” search.

These are useful things, really. I don’t want to play the purist who dismisses everything that works. But I wonder if they aren’t also, at the same time, deeply conservative. Like putting an electric motor on a horse-drawn carriage and calling it a revolution. The carriage stays a carriage—only what pulls it changes.

I’ve seen this dynamic before. In 2007 it was called “mobile”.

When the iPhone exploded, plenty of companies took their desktop sites and “adapted” them. Responsive, smaller buttons, reordered columns, hamburger menu, done. Technically correct. Strategically… almost irrelevant.

Because the winners weren’t those who adapted the old to the new—they were those who rethought everything.

Uber isn’t a taxi website made responsive. It’s a product that without GPS, always-on connectivity, and a device in your pocket would have made no sense.

Instagram isn’t a smaller Flickr. It’s a visual language born for mobile, designed to be used with one hand, while you walk.

WhatsApp isn’t email on a smartphone. It’s communication redesigned around an assumption: the device is personal, always with you, always connected.

None of these products would have been born from the “let’s fix what we have” mindset. They were born from a different question.

The right question

The question isn’t: how do I add AI to my product?

The question is: if I were designing this product today, knowing half the interactions will flow through AI agents, how would it be different?

It looks like a nuance, but it isn’t.

For twenty years we designed software starting from an almost invisible assumption: a human sits in front of a screen and interacts with a graphical interface. Click, scroll, fill fields.

That assumption won’t disappear, but it will stop being the only one. And when it stops being the only one, many choices that looked “natural” suddenly become arbitrary.

Think how many daily actions we do inside digital products that, with the right APIs and the right permissions, an agent could do for us. Book a restaurant. Compare quotes. Fill a form. Move an appointment. Analyse a report. Order groceries. Pay a bill.

It isn’t science fiction. Language models, today, can already manage complex flows. The bottleneck often isn’t the AI. It’s the way products are built.

A lot of software was designed to be looked at and clicked. Not to be understood and orchestrated.

That difference, I think, is enormous.

From interfaces to contracts

Here it gets concrete.

For years the “product” was the interface. The UI was the product. Everything else—backend, APIs, database—was infrastructure in service of the screens. Designers drawing screens, developers implementing them, product managers measuring conversions on buttons.

In the paradigm coming into view, the product becomes the contract.

Clear APIs. Structured documentation. Coherent data schemas. Capabilities exposed in semantically rich ways. Errors that explain what happened and what to do. Stable contracts.

The graphical interface doesn’t disappear, but its role changes. It becomes a client of the product, not the product. One client among many.

And, paradoxically, this is good news. Because an API designed to be consumed by AI agents forces you to write good software. It forces you to be clear. Coherent. Reliable. Composable.

AI isn’t lowering the bar. It’s raising it.

From features to capabilities

There’s a mindset shift that touches the heart of product management.

The traditional mindset is feature-driven. Add feature X. Need five screens, three endpoints, two tables. Wireframe, user story, acceptance criteria. And then a flow that’s almost always linear: the user lands at A, clicks B, fills in C, gets D.

The AI-native mindset, by contrast, tends to be capability-driven.

You don’t design a path. You design a building block. A capability that can be orchestrated by anyone: a human via GUI, an agent via API, another system via webhook. And often it’ll be combined with other blocks in ways you hadn’t anticipated.

It’s more powerful, but also harder. It requires thinking in terms of contracts, invariants, preconditions and postconditions. It requires more mature engineering.

And here, I’ll admit, I get a little excited. Because it’s as if the pressure of AI finally makes inevitable the best practices many engineers have repeated for years, often into the void.

The paradox of openness

There’s another aspect I find counter-intuitive.

For years the dominant model was lock-in. Closed data, hard exports, walled gardens. “That’s how we defend the competitive advantage.”

In a world of AI agents, closure risks becoming a handicap.

An agent works better with services that collaborate. That expose structured data. That have documented APIs. That allow interoperability. If a service is opaque and hard to integrate, the agent will tend to bypass it and pick more composable alternatives.

And here there’s a beautiful, almost poetic paradox: to keep users, you have to leave them free to leave.

This also shifts the playing field for small companies. Because on openness, on API quality, on documentation, on contract cleanliness, an agile SME can compete. Sometimes it can even do better than a giant full of legacy.

Compliance as superpower

This part is close to me, because it’s the ground I find myself on every day.

GDPR, AI Act, Cyber Resilience Act, Product Liability Directive, European Accessibility Act. They’re often experienced as a cost. A nuisance. A tax on doing business.

I, more and more, see them differently.

In an ecosystem mediated by AI agents, trust becomes a computational resource. It’s not just marketing. It’s an input to decisions.

If an agent has to choose between two similar services, it’ll tend to prefer the verifiable one. The one with a transparent SBOM. Complete audit trail. Documented privacy by design. Compliance declared and demonstrable.

In this sense, compliance stops being only a cost to bear and becomes a quality signal readable by machines. A competitive differentiator.

I realise it almost sounds odd to put it that way, but I believe it’s true: compliance can become a superpower.

And maybe Europe, with all its bureaucracy that makes plenty of people sigh, is building a terrain where trust is computable. If you can turn it into architecture, it isn’t a brake. It’s an advantage.

Where this becomes concrete

I could leave it here, on the level of ideas. But it wouldn’t be honest, because for me this transition is concrete, daily.

When we migrate a product, we aren’t just “modernising the stack”. We’re preparing a service for a future where agents will interact with these systems as much as humans do.

When we build an SBOM platform to manage software dependencies, we aren’t just doing compliance. We’re creating a layer of verifiable trust.

When we move the centre of gravity toward spec-driven development, where the spec is the primary product and the code is a derived artefact, it isn’t only a methodology. It’s a way of working in which AI can be a real partner, not a gadget.

At some point you notice everything holds together. Clean architecture, rigorous documentation, compliance by design, API-first, specs as the primary object. They’re faces of the same idea.

In the world coming, clarity is power.

The real risk

The biggest risk today isn’t doing “the wrong things” with AI.

It’s doing the right things, but in the old paradigm.

It’s adding a chatbot instead of rethinking the architecture of the interaction. Putting AI suggestions in an interface that maybe shouldn’t exist in that form. Using AI to write code faster without asking whether we should write clearer specs.

I know it’s a strong position. And I also know that many companies are getting real results by adding AI to existing products. I’m not saying it’s all wrong.

I’m saying it’s insufficient. That it risks being yesterday’s game with today’s pieces.

A love letter to technology that helps

I’ll close on a personal note, because for me this conversation isn’t only strategy.

I love technology when it helps. When it makes accessible what was exclusive. When it simplifies what was complicated. When it frees time for what really matters.

When I think about AI in digital products I don’t think—or at least not only—about chatbots answering on someone’s behalf. I think about an elderly person who can interact with public administration through an agent that understands and translates bureaucracy. About a small entrepreneur managing compliance without an army of consultants because the software supports them natively. About a doctor who can stay with the patient while the documentation is handled better. About a student with a disability who finds a truly accessible experience, not a tick in an Excel sheet.

To get there, though, “adding AI” isn’t enough. You have to rethink products around a world where humans and agents coexist.

It isn’t easy. It requires putting back into question assumptions we took for granted. It requires new skills and a certain humility. It requires the most uncomfortable question of all: if I were starting from zero today, would I do it like this?

But it’s a beautiful challenge. The kind that makes you want to roll up your sleeves.

Because on the other side, perhaps, lies more useful, more accessible, more reliable software. And, in a meaningful sense, more human.

The author

Andrea MargiovanniCraft

I have been writing software long enough to consider it a craft, not a pipeline. I care about the difference between a technical choice and a default inherited without measuring its cost.

See the guide →