For most of my career I thought software engineering was about writing software.
I don’t think that anymore.
Not because software is disappearing.
Quite the opposite.
We’re about to build more software than at any point in history.
I just don’t think applications will be the primary unit anymore.
I think behaviours will.
That sounds like a ridiculous statement.
A few months ago I would have dismissed it myself.
Then I started building Vork.
Not as another AI application.
As an experiment.
What happens if you stop thinking about applications altogether?
What happens if you only think about behaviours?
The answer surprised me.
For decades software has been organised around applications.
CRM.
Accounting.
Helpdesk.
Email.
Project management.
Each application owns its own little world.
Its own user interface.
Its own workflows.
Its own permissions.
Its own database.
We’ve become so accustomed to this model that we rarely question it.
We simply ask:
“What application do we need?”
AI hasn’t changed that.
Most companies are still asking exactly the same question.
They’re just adding AI to the application afterwards.
An AI assistant.
An AI chat window.
An AI feature.
Useful?
Absolutely.
Transformational?
I’m no longer convinced.
The more I worked with AI, the more I realised I wasn’t interested in making applications smarter.
I was becoming interested in making applications disappear.
That sounds far more controversial than it actually is.
Take something simple.
A customer sends an email asking for a quotation.
Today that probably means opening a CRM.
Searching for the customer.
Opening another screen.
Finding previous orders.
Opening a pricing tool.
Generating a document.
Emailing it.
Lots of software.
Lots of screens.
Lots of clicking.
But what if the software wasn’t the important part?
What if the important part was simply the behaviour?
Find customer.
Retrieve history.
Calculate pricing.
Generate proposal.
Ask for approval.
Send email.
The behaviour hasn’t changed.
Only the implementation has.
That’s when something clicked.
Applications aren’t the behaviour.
They’re one implementation of the behaviour.
And implementations change.
Today your customers might live in MongoDB.
Tomorrow Salesforce.
Next year something else entirely.
The behaviour doesn’t care.
It simply asks:
“Find the customer.”
How that happens becomes somebody else’s concern.
This is where I think software engineering begins to change.
Not disappear.
Change.
We’ve spent decades learning how to engineer code.
Version control.
Unit testing.
Continuous integration.
Static analysis.
Security scanning.
Code review.
Deployment.
Observability.
All brilliant.
All necessary.
But behaviours deserve exactly the same discipline.
If behaviours become the new unit of software, then we need to learn how to engineer them.
Not just write them.
Engineer them.
That means asking entirely new questions.
How do we test a behaviour?
How do we approve it?
How do we observe it?
How do we audit it?
How do we know it behaved correctly?
How do we prove that six months after it executed?
Those aren’t AI questions.
They’re engineering questions.
People often ask me what a behaviour actually is.
I’ve been thinking about that a lot recently.
I think it’s remarkably simple.
A behaviour is the transformation of information from one state into another.
Nothing more.
Nothing less.
An enquiry becomes a customer.
A customer becomes a quotation.
A quotation becomes an order.
An order becomes an invoice.
Every organisation is simply transforming information all day long.
Applications have hidden those transformations behind user interfaces.
AI gives us the opportunity to expose them again.
Of course behaviours don’t perform work themselves.
They express intent.
The actual work happens through primitives.
Read a file.
Write a file.
Execute a command.
Connect over SSH.
Send an email.
Query MongoDB.
Schedule a meeting.
Primitives are deliberately small.
Deliberately focused.
Deliberately boring.
The behaviour decides what should happen.
The primitive knows how to do it.
Neither knows about the other.
That’s an important separation.
In fact, I’ve started using a simple rule.
Primitives end when they become complex enough to deserve a behaviour.
It feels obvious once you say it.
Rather like saying a function should do one thing.
Simple rules often become the foundations of engineering disciplines.
This is why I don’t believe the future is about writing fewer programs.
It’s about writing fewer applications.
Those are not the same thing.
Applications bundle hundreds of behaviours together.
Behaviours allow those capabilities to evolve independently.
One organisation may approve quotations.
Another may require two approvals.
A third may ask AI to draft everything before a human decides.
The behaviour changes.
The primitives remain.
Notice I keep saying “human decides.”
That’s deliberate.
One of the things that worries me most about current AI discussions is the assumption that the objective is to remove humans from the process.
I don’t think that’s engineering.
Engineering has never been about removing accountability.
It’s about making systems predictable.
The tests don’t deploy software.
People do.
The tests provide confidence.
People accept responsibility.
Behaviour Engineering shouldn’t be any different.
AI proposes.
Behaviours execute.
Humans remain accountable.
Not because AI is incapable.
Because organisations require responsibility.
Over the last few weeks I’ve found myself saying something I never expected to hear.
If someone asks me how to build a capability inside Vork…
I don’t want Java.
I don’t want plugins.
I don’t want scripting.
I want better primitives.
Six months ago I’d have thought that sounded absurd.
Today it feels inevitable.
The second behaviours escape into arbitrary code, we’ve simply recreated another application framework.
That’s not the future I’m interested in building.
I’m sure we’ll get plenty of things wrong.
Behaviour Engineering probably isn’t finished.
It has barely begun.
We’ll discover better testing models.
Better governance.
Better approval workflows.
Better observability.
The discipline will evolve.
Every engineering discipline does.
I don’t know whether Behaviour Engineering is the name the industry will eventually choose.
Names are the least interesting part of any new idea.
What matters is recognising that something has changed.
For decades software engineering has been about engineering applications.
I think the next decade will be about engineering behaviours.
The engineers won’t disappear.
They’ll simply engineer something different.
And perhaps, years from now, we’ll look back at this moment and realise software engineering never ended at all.
It simply moved one level higher.