Lee Painter Music for the Soul. Code for the Bowl.
14 July 2026 / Code

MCP Isn’t the Future of Software Engineering

Everyone seems excited about MCP.

For good reason.

It’s an elegant idea.

A standard way for AI to discover and interact with software.

If every application exposed an MCP endpoint, an AI agent could connect to GitHub today, Salesforce tomorrow and Zendesk the day after without anyone writing another integration.

That’s genuinely useful.

I think every serious software platform should probably support it.

But I also think we’re celebrating the wrong thing.

MCP solves interoperability.

It doesn’t solve software engineering.

Those are very different problems.


For the last few weeks I’ve been working on Vork.

People naturally ask whether it will support MCP.

The answer is yes.

Of course it should.

MCP is another primitive.

Just like HTTP.

Just like SSH.

Just like SMTP.

Protocols matter.

But protocols aren’t architecture.

That’s where I think the conversation is currently going wrong.


Imagine Salesforce exposes an MCP server.

Fantastic.

Now an AI can create customers.

Read opportunities.

Update tickets.

Generate reports.

But stop for a second.

What actually changed?

Salesforce still exists.

The data model still exists.

The workflows still exist.

The licensing still exists.

The application still exists.

We’ve simply changed who is pressing the buttons.

Instead of a human clicking through a user interface…

…an AI calls an MCP endpoint.

That’s progress.

But it isn’t a new way of building software.

It’s a new way of consuming existing software.


Behaviour Engineering starts somewhere completely different.

It asks an uncomfortable question.

Why does that application exist at all?

Take CRM.

Today the answer is obvious.

Humans need somewhere to record customers.

Search for them.

Edit them.

Generate reports.

Navigate screens.

Click buttons.

But what happens when humans stop being the primary users?

Do we still need the application?

Or do we simply need the behaviour?


Imagine a behaviour called:

Prepare Customer Quote

It doesn’t know about Salesforce.

It doesn’t know about MongoDB.

It doesn’t know about REST APIs.

It knows it needs to:

Find the customer.

Retrieve previous orders.

Calculate pricing.

Generate a proposal.

Ask for approval.

Send it.

Those are behaviours.

Not screens.

Not applications.

Not workflows trapped inside a CRM.

Tomorrow that customer information could live somewhere completely different.

The behaviour doesn’t change.

Only the primitive does.


That’s why I’m increasingly convinced that applications are becoming implementation details.

Not because AI replaces them.

Because behaviours outlive them.

Applications come and go.

Protocols evolve.

Databases get replaced.

Companies migrate from Salesforce to Dynamics.

From GitHub to GitLab.

From one cloud provider to another.

The behaviour remains.


This is where I think MCP fits.

It’s an excellent protocol.

One that Vork will almost certainly support.

Because talking to existing software is essential.

Businesses aren’t going to throw away decades of investment overnight.

But I don’t think it’s the destination.

It’s the bridge.

The bridge between the software we built for humans…

…and the behaviours we’ll build for organisations.


The real question isn’t:

“How do we let AI talk to software?”

It’s:

“How much of today’s software only exists because humans needed graphical interfaces?”

That’s a much harder question.

It’s also a much more interesting one.

Because if the answer is “most of it”…

…then software engineering is about to become something very different.

Not because of AI.

Not because of MCP.

Because we’re finally starting to separate behaviours from applications.