Software Was First. Expertise Is Next.

Every organization has someone who just knows how things work.

Maybe it's Sally in accounting. She's been there for fifteen years, understands how operations affect the books, knows which exceptions actually matter, and can spot a problem three departments away before anyone else realizes something is wrong.

She's not necessarily the most senior person in the company. But when something unusual happens, everyone knows who to call.

Now imagine asking Sally what she does all day. You'd probably hear about reports, reconciliations, approvals, and the occasional fire she has to put out.

If you're looking for AI opportunities, those workflows seem like obvious candidates. Automate the reports, reconcile the numbers, reduce interruptions, and give Sally back a few hours every week.

That's a perfectly reasonable place to start. But we're missing something much more valuable.

The Value Isn't in the Workflow

What makes Sally exceptional isn't her ability to reconcile accounts. It's the knowledge she's accumulated about how the business operates and, more importantly, how different parts of the business affect one another.

She understands accounting and operations. She knows where they intersect, which rules can bend, which ones cannot, and what usually happens when someone makes an innocent-looking change upstream.

Some of that knowledge is documented. Most of it isn't.

We've spent decades building software to support people like Sally. Dashboards, reporting tools, workflow engines, and increasingly sophisticated automation. Yet the thing that makes them valuable often remains outside those systems entirely.

It lives in their judgment.

The bigger opportunity is capturing that judgment, not simply automating the tasks around it.

What Are We Actually Trying to Improve?

Suppose a business believes it could increase revenue by 5% if it could eliminate a particularly painful operational process.

The obvious response is to automate it. Study the steps, map the workflow, identify integrations, and build something that moves information through the business more efficiently.

But what if that process exists because three departments interpret the same information differently?

What if one experienced employee has spent years translating between them?

What if the real constraint isn't the process at all, but the organization's inability to consistently apply knowledge that only a handful of people possess?

Now we're solving a different problem.

We could automate the repetitive work so Sally can spend more time improving operations. We could capture the reasoning she applies to exceptions so less experienced employees can handle more complicated situations. Or we could discover that her understanding of accounting and operations could support an entirely new service the business couldn't previously offer.

Those are very different opportunities, and they require different systems.

The common thread is finding where human knowledge creates value and making more of that value available.

Software Is Becoming Cheap Enough to Ask Bigger Questions

We're moving beyond using AI to help engineers write code. Increasingly, we're building systems capable of performing substantial portions of software development autonomously, from implementation and testing to debugging, review, and architectural exploration.

I've spent much of this year experimenting with that transition. Building software factories, pushing their manufacturing capacity, discovering their constraints, and learning how to relieve bottlenecks as the systems take on more responsibility.

And somewhere along the way, my perspective shifted.

I started out asking how much software we could manufacture. I'm increasingly interested in what becomes worth manufacturing when software itself becomes dramatically cheaper.

Think about that specialized system a small organization could never justify building. The internal capability that previously required an entire engineering team. The unusual combination of business rules, expertise, and judgment that doesn't fit into any existing SaaS product.

What happens when we can afford to build those things?

Of course, inexpensive implementation doesn't make the entire problem inexpensive. Understanding the business, capturing knowledge, establishing correctness, and integrating into real operations remain difficult.

But those challenges are exactly where the opportunity is moving.

And we've tried something like this before.

Expert systems in the 1980s promised to capture specialist knowledge and make it available through software. They demonstrated real value, but three persistent problems limited their reach. Encoding expertise was expensive. Maintaining that knowledge as circumstances changed was difficult. And discovering where the system's reasoning failed often required substantial expert effort.

What's changing now is the economics of all three.

Software factories can dramatically reduce implementation costs and make continuous adaptation more practical. Modern AI systems can help extract knowledge from examples, documents, conversations, and observed decisions. And rapid development and evaluation cycles make it possible to put working systems in front of experts far earlier.

An expert may struggle to explain every rule they apply, but showing them a concrete result often reveals missing context, exceptions, and assumptions.

Their corrections become part of the knowledge capture process.

This doesn't eliminate the need for careful validation. It changes how quickly we can discover what we don't yet understand.

The Software Isn't the Valuable Part

Return to Sally.

Imagine spending time understanding how she actually makes decisions. Examining real cases, capturing exceptions, identifying the information she relies on, and establishing how she recognizes a good outcome.

Then imagine manufacturing a system capable of applying some of that expertise consistently.

It might contain traditional software, deterministic rules, language models, simulations, or autonomous agents. Probably some combination of them.

The achievement is taking knowledge that was previously difficult to distribute and turning it into something the organization can reliably use.

That capability could handle routine decisions, help junior employees tackle more difficult problems, or let Sally apply her expertise across ten times as many situations without personally intervening in every one.

It might even reveal an entirely new business opportunity.

And Sally has a stake in how this happens. Done well, her expertise can reach further than she ever could alone, while giving her more opportunity to shape how the business operates. But capturing knowledge also changes who controls it and how it gets used.

The strongest systems will be developed with the expert, not simply built around them.

This isn't automating what Sally does. It's making what Sally knows executable.

That distinction changes the question we should be asking.

Instead of starting with "What workflows should we automate?", start with:

What does your organization know how to do exceptionally well that it cannot easily replicate?

Sometimes the answer will be a workflow. Sometimes an expert's judgment, an unusual intersection of disciplines, or decades of accumulated institutional experience.

Sometimes the answer might be something nobody has thought to turn into a system before.

Making Human Knowledge Executable

I've been thinking about this through the lens of software manufacturing, but software engineering is simply the first domain where I could prove something much larger.

We're entering a period where enormous portions of human knowledge can increasingly be expressed as goals, constraints, decisions, evaluations, and executable systems.

Not everything can be captured cleanly. Some expertise is contextual, some knowledge is tacit, and some decisions involve human relationships and values that resist formalization.

And making something executable certainly doesn't make it correct.

But look at the direction we're heading.

We can increasingly capture expertise, encode how it gets applied, manufacture systems around that knowledge, and evaluate whether those systems produce useful outcomes.

The implications extend far beyond software engineering. Manufacturing, finance, medicine, construction, logistics, scientific discovery, and almost every other knowledge-intensive field have capabilities that remain constrained by the people who possess them.

The economics of software changed first. The economics of expertise are next.

I've started calling this making human knowledge executable.

Over the next three to five years, I believe some of the most interesting opportunities will come from discovering things organizations have known how to do for decades but never had the means to scale.

How much extraordinary value is hiding in plain sight inside our organizations, waiting to become executable?