What If Software Has a Soul?

I have sold learning software for twelve years. In that time, I have answered hundreds of questions about what a product can do.

Does it support single sign-on? Can it integrate with our HR system? Does it have reporting, mobile access, multilingual content, social learning, skills data, artificial intelligence? How long will implementation take? Where is the data stored?

All reasonable questions. But I cannot remember anyone asking what the software believes.

Not what the people selling it believe. Not what the company says in its mission statement. What does the product itself appear to believe about learning?

Does it treat knowledge as something an expert possesses and transfers to everyone else? Or as something people construct together? Does it assume that learning happens through instruction, practice, conversation, observation or experience? Does it think the purpose of learning is to remember, to comply, to become employable, or to think?

These questions sound philosophical. They are also practical.

Software is rarely the thing anybody actually wants. Nobody wakes up wanting a learning management system. They want people to develop. Nobody wants recruitment software for its own sake. They want to identify talent. Nobody wants a customer relationship management system. They want stronger relationships with customers.

Software sits between a person and a desired outcome. It is a proxy.

That should make us curious about the character of the proxy we choose.

When I used Bumble, I learned that a dating profile could tell me many things about a man. His age, height, profession, location, interests and whether he wanted children. The information helped me decide whether he met certain requirements. It told me very little about what it would feel like to build a life with him.

A request for proposal is the dating profile of software. It tells us whether a product is eligible. We then proceed as though eligibility and compatibility are the same thing.

They are not.

Two learning platforms can satisfy the same list of requirements and still embody entirely different ideas of learning. One may place the administrator at the centre and the learner at the edge. Another may assume that employees should direct their own development. One may treat knowledge as stable content to be delivered. Another may treat it as something social, provisional and distributed across an organisation.

Both may have courses, recommendations, communities, analytics and AI. The features can look nearly identical while the products pull an organisation in different directions.

We have become more comfortable talking about bias in technology. That is useful, but bias is not quite the same as belief. Bias sounds like a defect: something that entered the system by mistake and can be found, isolated and removed. The language implies that somewhere beneath the contamination there is neutral software waiting to be recovered.

I am not convinced neutral software exists.

When I moved to the United States at sixteen, I encountered multiple-choice tests for the first time. I remember being surprised that a question with four possible answers was considered easier than an essay. To me, the difficulty was not knowing the answer. It was accepting that the examiner had already decided what shape a valid answer could take.

The format contained a theory of knowledge. It rewarded recognition over construction, selection over explanation, convergence over ambiguity. That did not make multiple-choice tests useless. It meant their form was not separate from what they measured.

Software works in much the same way.

Every product must decide what appears on the first screen, who is allowed to do what, which actions are visible, what can be measured and what counts as success. Those decisions cannot be avoided. Even a blank field is a decision about what the user should supply. Even flexibility has a philosophy: it transfers judgment from the product to someone else.

The choices accumulate. Some come from founders. Some from engineers and designers. Some from investors, regulators, the market or the first major customer. Some come from a business model that needs one behaviour to be more valuable than another. Eventually, the product develops a recognisable way of meeting the world.

It can be rigid or intuitive, controlling or collaborative, demanding or forgiving. It can assume that users are competent, careless, curious, busy, compliant or in need of supervision. It can make some behaviours effortless and others exhausting.

Features are the anatomy of a product. Its personality appears in how those features behave together. Its values appear in what they make easier. Its soul, if software has one, may be found in the future it quietly treats as desirable.

But software does not believe anything

The obvious objection is that software does not literally believe. It has no interior life, no private convictions and no moral intention. People design it, fund it, buy it, configure it and decide where it will be used. Calling its assumptions a soul could make the product sound more autonomous than it is and make the people behind it less accountable.

That objection is correct. It is also incomplete.

Beliefs do not need to remain inside a person to keep operating. A founder's philosophy can become a default setting. A customer's demand can become a permission structure. A business model can become a metric. A temporary compromise can become a workflow that thousands of people later experience as simply the way things are.

Code is where an institution's assumptions go to outlive the people who made them.

This makes the question of whose soul more difficult than the metaphor first suggests. Is it the founder's? The engineers'? The first customer powerful enough to change the roadmap? The regulator's? The investor's? The market's?

In a mature product, the answer may be all of them and none of them. Software is often less like a single personality than an accumulation of negotiations. One screen reflects a generous theory of human agency; the next assumes that people cannot be trusted. One feature invites exploration; another punishes deviation. The contradictions are not incidental. They are the history of the product made usable.

Perhaps mature software does not have one soul. Perhaps it is haunted by everyone who was powerful enough to influence what it became.

That does not move responsibility from people to machines. It locates responsibility more precisely. Human choices become infrastructure, and infrastructure keeps shaping behaviour long after the original choice has disappeared from view. The people affected by it may never know who made the decision, what problem it was meant to solve or which alternative futures were excluded.

The metaphor is useful only if it makes those choices easier to see.

Consider hiring software. A system may appear to solve a practical problem: too many applications and too little time. It ranks candidates, identifies patterns and brings the most relevant people to the recruiter's attention.

But relevance is never abstract. The system has to infer it from something. Previous job titles, career continuity, educational pedigree, language, geography or resemblance to people who succeeded before. Each signal contains an idea about what talent looks like. A product can broaden an organisation's field of vision or make conventional candidates easier to see and everyone else easier to miss.

The software does not merely reflect the hiring process. Over time, the hiring process begins to reflect the software.

This happens because measurement reorganises attention. What a system records becomes easier to discuss. What it ranks becomes easier to defend. What it cannot represent begins to look anecdotal, inefficient or unreal. Eventually, an organisation can become more like its technology: valuing what the product can recognise and neglecting what it cannot.

This is why personality is not a decorative quality in software. It is operational. A controlling product produces more control. A product built around mistrust generates more evidence of compliance. A platform that treats people as recipients will struggle to create participation, however many social features are added later.

Artificial intelligence makes this question more urgent because the product is no longer only enforcing rules that somebody visibly wrote. Increasingly, it interprets ambiguity, generates recommendations, decides what matters, ranks possible actions and speaks back to the user.

Traditional software revealed its assumptions through fixed fields, permissions and workflows. AI reveals its character in judgment: what it notices, what it ignores, what it does when evidence conflicts and how confidently it behaves when it does not know.

That character may not be stable. The same system can respond differently to different users, learn from new data and be altered without the organisation noticing that anything fundamental has changed. It can become more adaptive while becoming harder to inspect.

The important question is not whether the system is conscious. It is what happens when a system without consciousness develops a recognisable way of interpreting people, judging them and moving them toward a preferred outcome. It can have the consequences of judgment without the experience of judging.

That changes what evaluation should look like.

We should still test features, security, integration and cost. But we should also place products in situations that expose their character. What happens when a person refuses a recommendation? When the available evidence is ambiguous? When two people give conflicting accounts? When efficiency and fairness point in different directions? Can a human override the system, and does the product treat that intervention as judgment or error? Does deviation appear as creativity, risk or non-compliance?

These are not edge cases. They reveal what the product believes its role to be.

Procurement therefore needs questions that cannot be answered with a tick:

What is this product ultimately trying to make happen?

What assumptions does it make about the people who will use it?

Which behaviours does it reward, and which does it make difficult?

Whose judgment is embedded in its recommendations?

What does it recognise as progress?

What does it do when reality does not fit its categories?

What kind of organisation will become easier to operate if we adopt it?

The answers will not be found only in a product demonstration. They are also in the defaults, the data model, the pricing, the permissions and the exceptions. They are in what the vendor measures, what the product cannot express and what must be changed before a real person can fit inside it.

Perhaps software has no soul in any literal sense. It does not hope for the future it helps create. It does not suffer when it is wrong. But it can preserve beliefs, develop a character and reward one vision of human behaviour over another. It can carry yesterday's decisions into tomorrow at enormous scale.

Before we bring a product into an organisation, then, we should ask more than what it can do. We should ask what it will make easier to see, to believe and to reward. We should ask whose judgment it will preserve and whose future is already living inside it.

We keep buying software as though it has no character of its own. Then we act surprised when the organisation begins acquiring it.