Building with AI, Pragmatically

There's a pattern I keep seeing. A company gets excited about AI, hires a consultant or fires up a proof-of-concept, and three months later they have a demo that works in a meeting room but not in production.

The problem isn't the technology. The problem is starting with the technology.

Start with the problem, not the solution

Every successful AI project I've been part of started the same way: someone had a specific, painful, repeated problem. Not "we should use AI" but "our editors spend four hours a day searching for related articles" or "our brokers manually compile property flyers for every listing."

The AI part came later. Sometimes it wasn't even AI — sometimes a well-structured database query or a simple automation solved 80% of the problem.

The 80% rule

Before building anything with a language model, I ask: can we solve 80% of this with conventional software? If yes, build that first. See what's left. Then decide if the remaining 20% justifies the complexity of AI.

This isn't anti-AI. It's pro-results.

What "production-ready" actually means

A demo that works on curated examples is not a product. Production-ready AI means:

• Handling edge cases gracefully
• Failing safely when the model is uncertain
• Being maintainable by someone who didn't build it
• Costing a predictable amount per month
• Actually being used by the people it was built for

That last one is the hardest. You can build a brilliant system that nobody opens because it doesn't fit into their existing workflow.

The builder's advantage

I think product managers who can also build have a real advantage here. Not because the coding is hard — with modern tools and AI assistance, the technical barrier is lower than ever. But because understanding both the problem and the implementation means you can make better trade-offs, faster.

You don't need to choose between thinking and doing. The best products come from people who do both.