When to use AI, and when to use conventional code.

Every week, someone who runs a real business (a publisher, a property operator, a grocer) asks me some version of the same question. "Should we be using AI for this?" Usually they're asking because a vendor just promised them that AI will cut a line item in half, or a board member read an article, or a competitor posted something on LinkedIn.

The honest answer is boring: it depends on what "this" is. And the difference between "this works" and "this is a $40,000 mistake" comes down to a handful of distinctions most sales decks won't draw for you. Let me draw them.

The core distinction

Conventional code is a ledger. You tell it the rules. It follows them exactly, every time, forever. If the tax rate is 8.45%, it is 8.45%. If the order total is wrong on Tuesday, it was also wrong on Monday, and we can prove it. Code is deterministic: same input in, same output out.

AI, specifically the large language models behind most of what's being sold right now, is a very well-read intern. It has read roughly everything. It can write decently, summarize passably, and guess what you probably meant. It is also probabilistic: same input in, slightly different output out. It will occasionally make things up with real confidence. That's not a bug; that's how it works.

Code is for tasks where "exactly right" matters. AI is for tasks where "roughly right, faster" is the win.

If you hold that sentence in your head, 80% of the decisions get easy.

The two-minute test

Before you pay anyone to build anything, ask the problem three questions:

1. Does this task have a right answer? (A tax calculation, a payroll total, a compliance check, an inventory count.)
2. Does it need to behave the same way every time? (An invoice, a booking flow, a permissions rule.)
3. Would you be comfortable showing its output in court, or to the IRS, or to your insurer?

If you answered yes to any of those, that's conventional code. Full stop. No AI. Rules don't tolerate creative interpretation.

Now ask:

1. Is the task messy, open-ended, or language-heavy? (Triaging a support inbox, drafting a first-pass reply, summarizing a 40-page PDF.)
2. Would a smart intern do a passable job at it, if they had no judgment of consequences?
3. Will a human always check the output before anything irreversible happens?

If yes, that's a good AI job. Probably worth the money. Probably not magic, but probably worth it.

A real example I keep seeing

A client wanted to use AI to "automate" a pricing workflow: watch competitor prices, decide when to re-price, and then update the store. Sounds like exactly the sort of thing AI is for, right?

It isn't. The job has three parts:

1. Watch competitor prices. This is a scraper. It's code. It runs on a schedule, it writes numbers to a table, and it sends an alert when something moves. AI doesn't help here; it just adds cost and variance.
2. Decide when to re-price. This is a rule. You, the owner, have opinions about it. "If competitor price drops more than 5% and our margin is still > 20%, flag it." That's code too, because you want the same rule applied the same way on Tuesday that you wanted on Monday.
3. Write the headline and description for the updated product page. Now we're talking. Generating a fresh 40-word description that matches your brand voice? That's exactly the kind of messy, language-heavy, "passable first draft" task AI is legitimately good at.

In other words: the right system here is 90% boring code and 10% AI, with a human approving the AI's suggestion before it goes live. That's the pattern almost every good "AI-powered" tool I've built follows. The AI is a small, well-behaved component inside a larger deterministic system.

Conventional code collects the inputs, conventional code enforces the rules, AI does the one soft-edged thing in the middle, and a human confirms before anything irreversible happens.

Four questions your vendor should answer plainly

If someone is selling you an AI feature, you should be able to ask and get a straight answer to each of these. If they hedge, walk.

1. "What happens when the AI is wrong?"

There is no AI system that is right 100% of the time. The good ones have been designed around that fact. Ask: what is the worst-case output, and who catches it before it matters? If the answer is "the customer will probably catch it," that's a no.

2. "What's the deterministic fallback?"

Good AI features degrade gracefully. If the model is down, slow, or hallucinating, the system should fall back to the boring code path. Ask to see what that looks like. If there isn't one, you're buying a single point of failure.

3. "Where does the training / usage data go?"

If your documents, customer emails, or financials are being sent to a third-party AI provider, you need to know which provider, under what terms, and whether your data is used to train future models. For many owner-operated businesses, especially in healthcare, finance, or anything touching minors, this is the whole question.

4. "Can I replace the AI piece later without rebuilding everything?"

Models change every six months. Prices change. Providers get acquired. A well-built system treats the AI as a swappable component: call it through a thin layer, keep your prompts in a file you can read, and don't bake it into your core data model. This is the same "handoff-ready" discipline I apply to everything else.

Where AI actually earns its keep (for most small businesses)

In my practice, the AI features that have paid off most reliably for owner-operated businesses are the unglamorous ones:

• Inbox triage. Routing inbound email into "needs a person," "auto-reply is fine," "appears to be spam." Saves real hours per week. Mistakes are cheap because a human still opens the bucket.
• Document extraction. Pulling structured data out of messy PDFs (vendor invoices, inspection reports, contracts) into a spreadsheet or database. Much cheaper than a data-entry person, and the human just spot-checks.
• First-pass copywriting. Ad variations, product descriptions, FAQ drafts. Never the final version. Always a starting point that saves 30 minutes of staring at a blank page.
• Internal Q&A. "Hey, what's our policy on X?" run against your own documents. Great for onboarding new staff. Always cite the source document.

Notice what's missing from that list: anything that touches money, any customer-facing decision without review, and anything that needs to be reproducible six months from now.

The uncomfortable truth

Most of the "AI-first" products being pitched to small and mid-sized businesses right now are doing something a well-written script could do for a fraction of the cost. The AI is there because it's easy to sell, not because it's the right tool.

On the other side, some operators are dismissing AI entirely because they've been burned, or because it offended their aesthetic sensibilities. That's also a mistake. Used narrowly and honestly, AI is a genuinely useful addition to the toolkit. Mostly it's just another tool, with a particular shape of job it does well.

Good engineering is knowing which tool fits the job. That was true before AI. It's especially true now.

A short checklist to take to your next vendor conversation

1. Ask them to describe the feature without using the word "AI." If they can't, it probably isn't one.
2. Ask where the AI fits in the overall system. Look for the answer to be "in one specific place."
3. Ask what happens when it's wrong.
4. Ask what the deterministic fallback is.
5. Ask where the data goes, and get the answer in writing.
6. Ask if you can swap out the AI provider later without rewriting the product.
7. Ask for the human-in-the-loop checkpoint. If there isn't one, find out why.

If all seven get a clean answer, you're probably in good hands. If any of them get a vague one, you've found the leak before it happens.

Field notes

The best systems I build are mostly boring. A small amount of AI, used deliberately, inside a large amount of plain code that behaves the same way on the worst day of the year as it does on the best one. That's not a hot take. It's just the job.

R.P.