We Spent 20 Years Learning Software. Now Software Needs to Learn Us.

Every business I have worked in reshaped itself around the software it bought. Not once, not deliberately, and never as a decision anyone wrote down. It happened one small concession at a time.

The CRM wanted a company name on every contact, so we started inventing company names for individuals. The project tool assumed work moved in sprints, so we started calling things sprints. The invoicing system could not handle a deposit, so we built a spreadsheet next to it, and then someone had to own the spreadsheet, and then that person left.

None of these were software problems, exactly. They were shape problems. The software had a shape, the business had a shape, and the business is the one that bent.

We got very good at bending

Twenty years of this made us skilled at something strange. We learned where the buttons were. We learned which fields were lies we agreed to tell. We learned the workarounds so thoroughly that we stopped experiencing them as workarounds — they became the job.

Ask anyone who has run a small business what their systems are and you will get a tour of that bending. This tool for that, exported here, pasted there, and a person in the middle whose real job title is translator.

We did not buy software to run our businesses. We reorganised our businesses so software could run.

That was a rational trade when software could not do anything else. A form is a cheap way to make a computer understand a customer. Fields are cheap. Structure is cheap. Judgment was the expensive part, so we supplied it ourselves, in the gaps, forever.

What actually changed

The interesting thing about the current moment is not that AI can write. It is that judgment got cheap.

A system can now read a messy email and understand that Karen from Tuesday is the same Karen who called about the quote, without anyone defining a field for it. It can look at a half-finished job and work out what happens next. It can absorb the exception instead of rejecting it.

Once a system can hold ambiguity, the reason to force the business into a rigid shape disappears. And that reason was the only thing holding the arrangement up.

Business-shaped software

So the direction reverses. Instead of a business learning the software, the software learns the business — how this particular operation actually works, what its exceptions are, who does what on a Thursday, which rules are real and which are habits nobody has questioned.

I have started calling this business-shaped software, because every other name for it sounds like a product category and this is not one. It is a relationship change.

It has consequences that are not obvious yet:

• Fewer screens. A lot of interface exists purely to collect structure the machine could not infer. If it can infer it, the screen is overhead.
• Fewer integrations. Most integration work is translating one rigid shape into another. Two flexible systems need much less glue.
• Different skill. The valuable person stops being the one who knows the tool and becomes the one who can say precisely what should happen.

The part I am less sure about

I am building inside this rather than predicting it, which means I keep running into the places it does not work yet.

Systems that can absorb ambiguity also absorb your mistakes without complaining. I have had an API return success and quietly do nothing at all, and everything downstream looked perfectly healthy. When software was rigid, it broke loudly. Flexible software fails politely, which is much worse.

So the honest version of this is not software is about to understand you. It is: software can now bend, and we have not yet learned how much to let it, or how to tell when it has bent somewhere it should not have.

That is the thing worth documenting. Not the promise. The transition, from inside it, while it is still awkward.