Bad B2B software should be one of the first casualties of AI.

Outside of frontier research, this is one of the clearest tests I have for whether we are actually using this technology well.

Enterprise software has historically been expensive to build, slow to change, unpleasant to use, and remarkably bad at changing how organizations actually work. AI should attack almost every constraint that created that reality.

So the question I have my eye on is simple:

When do we start seeing less garbage enterprise software?

I think we are closer than we were a few years ago. But not because coding models are getting better.

The bigger change will happen when we stop assuming that the hard part of building software is solving technical problems.

It isn't.

The hard part is having enough judgment to know what a better way of working actually looks like.

That distinction matters because a lot of enterprise software is built by people who are hired precisely because they are good at solving problems.

They can enter an unfamiliar organization, understand a complicated brief, turn requirements into architecture, choose technologies, integrate systems and ship something that works.

That is a valuable skill.

It is not the same thing as knowing what a good product should be.

Problem-solving ability can get you to a solution.

Product judgment tells you whether the solution is any good.

And enterprise software has historically blurred those two abilities together.

A team gathers requirements. Someone turns those requirements into features. Engineers implement them. The software passes testing. The project gets delivered.

Everybody involved can be competent.

The resulting product can still be terrible.

Because good software is not simply a technically correct collection of features.

It expresses a point of view about how work should happen.

Think about a CRM.

It is easy to describe one as a collection of objects and features.

Contacts. Companies. Leads. Deals. Pipelines. Stages. Activities. Reports.

But those objects only exist because somebody made a much more consequential set of decisions underneath them.

What information should a salesperson capture?

What deserves to become part of the permanent commercial record?

How should a company relate to the people inside it?

What should management be able to see?

What should a salesperson have to update manually?

What should happen automatically?

What deserves their attention today?

What does progress look like?

The features are the visible consequence of those decisions.

The decisions are the product.

This is why using enterprise software is a much more intimate relationship than we usually acknowledge.

When you introduce software into an organization, you are effectively borrowing somebody else's judgment about how part of your company should work.

Their assumptions start shaping your behaviour.

They decide what gets recorded.

What gets surfaced.

What gets measured.

What gets automated.

What requires approval.

What interrupts someone.

What disappears into the background.

Before AI, those decisions mostly shaped the environment in which people performed their work.

Now the software can increasingly participate in the work itself.

That makes the quality of the judgment behind it far more important.

If AI condenses a ten-step process into three, somebody has made a decision about which seven steps no longer deserve to exist.

If an agent prepares work for an employee, somebody has decided which information the model should see, what it is trusted to infer, how accurate the result must be and what the employee is expected to verify.

If software begins making decisions autonomously, somebody has decided where human judgment is valuable and where it is expendable.

Those aren't implementation details.

They are decisions about how the organization should operate.

And this is why I think the current obsession with AI automation is too narrow.

Automation should be one tool in designing a software experience.

It should not be the objective.

The objective is a better way of working.

If you automate half of someone's job and replace it with the responsibility of checking unreliable AI output all day, you have not necessarily improved their work.

If you produce ten times more information but make it harder to know what deserves attention, you have not necessarily improved their work.

If you save thirty minutes producing a report but make the organization slightly worse at thinking about the information inside it, you may have destroyed more value than you created.

The interesting question is not:

What can AI do?

It is:

What should this team be doing differently once the software exists?

Should better decisions be made?

Should important information reach someone earlier?

Should a project manager spend less time maintaining records?

Should experienced employees spend more of their day exercising judgment?

Should mistakes become easier to detect?

Should the system quietly maintain itself from work that is already happening?

Should something that currently requires five screens disappear entirely?

Those are product questions.

And there is a frustrating answer to almost every one of them.

It depends.

What should be automated?

It depends.

What deserves a notification?

It depends.

What should appear on a dashboard?

It depends.

What information should AI be allowed to act on?

It depends.

Because there is no universal way that people work.

A civil engineering company building bridges in Australia may be solving substantially the same commercial and engineering problems as one operating in the Middle East.

The surrounding reality can still be completely different.

One team may rely heavily on formal email, Word documents, SharePoint, structured approvals and carefully maintained correspondence.

Another may coordinate far more work through WhatsApp, phone calls, personal relationships and informal escalation.

You can give both organizations the same technical capability.

You should not necessarily give them the same software experience.

Problems can be universal. The right software rarely is.

This is where judgment comes from.

Not from being clever enough to invent an answer.

And not from asking an AI system to deep research an industry and generate a list of best practices.

You earn judgment by getting close enough to the work that generic answers stop being useful.

You learn how the process actually happens, rather than how the SOP says it happens.

You find out where the experienced people spend their attention.

You notice which mistakes recur.

You understand why the ugly workaround everyone complains about still exists.

You distinguish between a cultural constraint, a technical constraint, a commercial constraint and a regulatory one.

You learn which parts of the work people hate because they add no value, and which tedious-looking parts quietly contain enormous amounts of human judgment.

Eventually you know enough to have opinions.

This workflow should be automated.

That one should not.

This person needs a dashboard.

That person needs one number.

This information should interrupt someone immediately.

That information can wait until Friday.

The AI can draft this.

It should never approve that.

The user does not need another feature here.

They need the entire step removed.

Those are opinions.

But they are opinions you have earned.

That is the difference between taste and arbitrary preference.

Taste is not magic.

It is what happens when accumulated exposure becomes judgment, and judgment becomes a willingness to make decisions.

This is also why I think AI creates such an interesting opportunity for enterprise software.

The previous era rewarded broad technical problem-solving because implementation itself was difficult and expensive.

A huge amount of value came simply from being able to make the system work.

That is changing.

Code is becoming cheaper.

Technical knowledge is becoming easier to access.

Features that once required serious engineering effort can increasingly be prototyped in days.

Which means the question shifts.

Not:

Can you build it?

But:

Do you know what deserves to be built?

The organizations and software teams that can answer that question well will be able to create experiences that would previously have been too expensive, too specific or too difficult to justify.

They can build around the actual way a team works.

They can remove workflows instead of digitizing them.

They can make software adapt to the organization instead of forcing the organization to adapt to another generic system.

They can use AI to increase the amount of judgment humans bring to their jobs rather than gradually removing it.

And they can keep changing the software as their understanding improves.

That is the future of enterprise software I am excited about.

Not more AI features.

Not another assistant in the corner of an existing product.

Not automating every task somebody can draw a box around.

Better software experiences, built by people who know enough about the work to have a real point of view about how it should happen.

If you are responsible for introducing software into an organization, there is a simple way to test whether you have earned that point of view yet.

Before talking about features, answer these questions:

1. Outcome: What should people actually be doing differently?

2. Attention: Where does human judgment create disproportionate value?

3. Aptitude: What kind of work comes naturally to the people using the system?

4. Information: What information do they need to perform that work well?

5. Friction: What part of the current experience genuinely adds no value?

6. Risk: Which mistakes are tolerable, and which are unacceptable?

7. Behaviour: How do these people naturally communicate, decide, review and escalate?

8. Control: What should software do itself, what should it recommend, and what should remain entirely human?

9. Evidence: What behaviour will tell you that the new experience actually improved the work?

If you cannot answer them, go find the answers.

Spend time with the people doing the work.

Watch what happens.

Understand the exceptions.

Then make decisions.

Because the rarest outcome in enterprise technology is not successfully deploying software.

It is watching people willingly change how they work because what you built is genuinely better.

When that starts happening more often, I will believe we are finally using AI to fix enterprise software rather than simply producing more of it.