There's a machinist in Ohio who just spent two weeks learning to build software with Claude. He didn't study computer science. He never learned to whiteboard algorithms. But he understands something no bootcamp graduate does: what happens when a CNC machine's tolerance drifts by three-thousandths of an inch.

He knows which problems cost his shop $50,000 a year because he's lived them. He knows why the scheduling software his shop bought never worked—because the vendor didn't understand that setup time varies by operator skill, not just by part. He knows the questions to ask because he's been asking them for twenty years.

The coder who wants to build manufacturing software needs months to understand these problems. The machinist who learns to code is already there.

This is the inversion nobody saw coming: as AI democratizes technical ability, domain expertise becomes the moat.

The Old Equation

The old software economy was simple: builders were rare, so technical skill commanded a premium.

Want to automate your business? Hire developers. Want a custom solution for your industry? Commission a software company. Want to integrate your systems? Bring in consultants. At every step, the bottleneck was finding people who could write code.

This created a power imbalance. The people who understood the problems—the operators, the frontline workers, the industry veterans—had to explain those problems to people who could build solutions. Translation layers stacked up. Context was lost. What got built was often a shadow of what was needed.

The person who understood the problem was separate from the person who could solve it.

The New Equation

AI is collapsing this separation.

It's not that coding is easy now—it's that coding is accessible. A domain expert with Claude can build working software in weeks. Not enterprise-grade systems (yet), but functional tools that solve real problems. The gap between "understanding the problem" and "shipping a solution" has compressed dramatically.

This changes who can build. More importantly, it changes who should build.

Consider the economics of software creation. Before AI-assisted development, building software for a 50-person machine shop wasn't worth the investment. The market was too small. The development costs too high. No software company was going to build a scheduling tool specifically for fab shops that accounts for operator skill variation.

Now the machinist can build it himself. And his version will be better—not because he's a better programmer, but because he understands the problem at a depth no outside developer could match.

Domain Knowledge Doesn't Scale—That's the Point

Here's the counterintuitive advantage: domain expertise is hard to acquire quickly.

You can learn to prompt an LLM in a weekend. You can get competent with AI-assisted coding in a month. But understanding why a particular manufacturing process works the way it does? Knowing which compliance requirements actually matter and which are theater? Recognizing when a customer's stated problem isn't their real problem? That takes years.

This is exactly what makes domain expertise defensible.

Technical skills are being commoditized by AI. Everyone with an internet connection now has access to a coding assistant that never sleeps. The bar for "can you build software" is dropping rapidly.

But the bar for "do you understand this industry" stays the same. You still need to work the floor, talk to customers, make the mistakes, and learn from them. There's no AI shortcut to twenty years of manufacturing experience.

Diffusion is the strategy—bringing AI capabilities to industries that haven't adopted them. But diffusion requires domain expertise. The AI labs can build the most powerful models in the world, but they're not going to understand the specific workflow problems of a machine shop in Ohio. That understanding lives in the people who do the work.

The Expertise Arbitrage

There's an arbitrage opportunity right now for domain experts who learn to build.

Think about your industry. What problems has everyone accepted as unsolvable? What frustrations have become so normalized that people stopped complaining about them? What workflows are still done on paper or in spreadsheets because "that's how we've always done it"?

These are the problems worth solving now. Not because they're technically hard—they usually aren't. But because they require understanding that outsiders don't have.

The machinist building scheduling software has an unfair advantage. He's not competing with software companies who have better engineers. He's competing with software companies who don't understand his customers. That's a winnable fight.

The same applies to any industry where domain knowledge is deep and outsiders struggle to understand the nuances:

• Healthcare administration, where compliance and workflow interact in ways that surprise everyone
• Construction management, where the gap between the plan and the field is measured in expensive change orders
• Professional services, where client relationships and deliverable quality are harder to systematize than they appear
• Specialty manufacturing, where tribal knowledge determines who makes money and who doesn't

In each case, the domain expert who learns to leverage AI has an advantage that pure technologists can't easily replicate.

What This Means for Technologists

If you're a developer without deep domain expertise, this isn't a reason to panic. It's a reason to reorient.

The question to ask: whose problems do you understand deeply? What industry, what customer segment, what type of business have you spent enough time with that you actually get it?

Generic technical skill is becoming less valuable. Technical skill applied to a specific domain—where you understand not just how to build but what to build—is becoming more valuable. The full-stack builder who can operate across product, design, and engineering still needs to focus that capability somewhere.

The smartest move for technologists right now is getting closer to specific customers and industries. Not just building what they ask for, but understanding why they need it. Accumulating domain knowledge alongside technical knowledge. Because the combination—deep domain expertise plus AI-augmented building capability—is rare and valuable.

The Uncomfortable Implication

There's an uncomfortable implication here for the tech industry.

For decades, technologists have been the gatekeepers of what gets built. Want software? Talk to us. We'll translate your needs into code. We'll charge accordingly for that translation service.

That gatekeeping function is eroding. Domain experts don't need translators anymore. They can learn enough technical skill, augmented by AI, to build their own solutions. The translation layer is collapsing.

This doesn't mean developers become obsolete. Complex systems still require real engineering expertise. Platform infrastructure, security, scalability—these remain technical domains where deep expertise matters.

But the "I know how to code and you don't" advantage is diminishing. The new advantage is "I understand this problem deeply AND I can build solutions for it."

The Pure Inference View

This is why we build FabWise. Not because we're smarter than other software companies. Because we're closer to the problems.

We talk to machine shop owners. We understand why existing scheduling software doesn't work for them. We know the questions to ask because we've learned from the people living the problems.

AI makes the building faster. But the domain understanding makes the building worthwhile.

The opportunity right now isn't in building better AI. It's in applying existing AI to domains that haven't been served yet. And the people best positioned to do that aren't the ones with the most technical skill—they're the ones with the deepest domain understanding.

Your Domain Is Your Moat

If you're reading this with twenty years of experience in some industry that most people don't think about, you have something valuable.

Not just experience. A competitive advantage that's hard to replicate.

The technical skills to build software are now accessible to anyone willing to learn. But the understanding of what to build—the nuanced knowledge of what problems matter, what solutions will actually work, what customers actually need—that still requires time in the arena.

Your domain is your moat. The question is whether you'll learn to leverage it.

AI didn't make domain expertise less important. It made domain expertise the main thing that matters.