AI for Business: What It Can (and Can't) Do

The fastest-growing pitch in AI for business right now is the one we hear every week: a founder is going to skip the whole software-vendor conversation and just have AI build their point-of-sale system over a weekend. The pitch sounds reasonable. You describe what you want, the model writes the code, you open for business Monday. People are doing genuinely impressive things this way: landing pages, internal dashboards, the skeleton of a mobile app.

Then they try to take a real payment, and the weekend turns into a quarter (get the pun?).

This isn't a warning against AI. We use it constantly, and the merchants who understand what it's actually good at are pulling ahead of the ones who don't. But there's a specific failure pattern playing out right now in commerce, and it's worth understanding why it happens, not just that it does.

A note on timing: this is written in July 2026, when Claude Opus 4.8, Gemini 3.5 Flash, and GPT-5.5 are the models most people are using. That lineup will look dated fast. These tools change month to month, and a limitation that's real today may be solved by the time you read this, while new quirks appear that nobody's flagged yet. Treat the specifics below as a snapshot, and make a habit of checking the current capabilities and known weaknesses of whatever model you're actually running.

How these models actually work

A large language model is a prediction engine. It has read an enormous amount of text and code, and at its core it does one thing very well: given everything written so far, it estimates the most likely next chunk of text. That's it. There's no database it's looking things up in, no internal ledger of true facts it checks against. It produces the most plausible continuation.

That design is exactly why it feels magic for some tasks. Writing a product description, drafting an email, generating a React component that renders a tidy grid of buttons: these are pattern-completion problems, and the model has seen millions of examples. The output looks right because it is right, statistically.

The trouble starts when "most plausible" and "actually correct" stop being the same thing.

Hallucination, plainly

When a model generates something that sounds confident and is completely wrong, the industry calls it a hallucination. The word makes it sound like a glitch. It isn't. It's the system working as designed, producing plausible text, in a situation where plausible and true have diverged.

Ask a model for the API method to refund a partial charge, and if it hasn't seen the exact current documentation, it won't say "I don't know." That's not a likely continuation. Instead it will invent a method name that looks exactly like a real one, with the right naming convention and sensible parameters. It reads as authoritative. It will fail silently the moment a customer asks for their money back.

This matters more in commerce than almost anywhere else, because the cost of being subtly wrong is money moving incorrectly. A hallucinated blog intro is embarrassing. A hallucinated tax calculation, refund flow, or inventory decrement is a chargeback, an audit, or a customer who got charged twice.

Why building Commerce is harder than it looks

When someone says "build me a POS" or "build me a store," they're usually picturing the screen: the product grid, the cart, the checkout button. AI can produce that screen quickly and it'll look professional.

But the screen is the easy 10%. The part that makes it a commerce system rather than a picture of one is everything behind it, and almost all of that is state and integration, not layout:

Payments. Taking money involves a payment processor, a merchant account, PCI compliance, tokenized card handling, and a dozen edge cases like declined cards, partial captures, refunds, disputes, and currency conversion. A model can write code that looks like it calls a payment API. Whether that code is secure, compliant, and correctly handling the failure cases is a different question entirely, and it's the question that matters.

Inventory. Stock isn't a number on a page; it's a number that has to stay correct while two customers check out the last unit at the same moment, while a return comes in, while a manual count adjusts it. Get the concurrency wrong and you oversell. Models are notoriously weak at this kind of stateful, race-condition-prone logic precisely because correctness here depends on runtime behavior the model never sees.

Order history and reconciliation. Every transaction has to be recorded once, immutably, and reconciled against what the processor says actually happened. This is boring, unglamorous bookkeeping logic, and it's the part that keeps you out of trouble with your accountant and the tax authority.

Tax. Rates vary by jurisdiction, by product class, by the customer's location, and they change. A plausible-looking tax function is worse than no tax function, because it'll be wrong in ways you don't notice until you file.

None of these are layout problems. They're correctness-over-time problems, and "generate the most plausible code" is structurally the wrong tool for guaranteeing correctness over time.

Where AI genuinely earns its place

We're not telling you to keep AI away from your business. The opposite. Most of what a small store needs done day to day sits squarely in the zone where AI is a real advantage, and if you're not using it for these, you're working harder than your competitors.

The pattern that makes something a good fit: a confident first draft saves you real time, and you can look at the result and tell whether it's any good. Marketing and content work fit this almost perfectly.

Generating images for ads. You can produce ad visuals, product mockups, and social graphics in minutes instead of paying for a shoot or a stock subscription. For a seasonal promo or a quick A/B test of two creatives, this is genuinely useful and the cost is close to zero.

Writing social posts and captions. Feed it your product and your tone and it'll draft a week of posts faster than you'd write one. You're still the editor, but the blank-page problem disappears.

Coming up with ad and newsletter ideas. This is where it shines even when the output isn't final. Ask for twenty angles for a back-to-school campaign and most will be mediocre, but two or three will be worth running, and you'd never have brainstormed all twenty yourself.

Talking through decisions. Use it as a sounding board for general business questions, like how to structure a loyalty offer or what to test next. Treat it as a sharp colleague who's occasionally confidently wrong, not as an oracle, and it's a useful thinking partner.

Alongside those, the less glamorous wins: summarizing reviews and support tickets so you can spot patterns, drafting the first version of an automation for a human to verify, and answering "how do I" questions about tools you already use.

Two caveats that separate good output from obvious AI slop

First, AI-generated visuals have a sameness problem. The default look, those glossy, slightly-too-perfect gradient posters, is now so common that customers recognize it instantly, and it reads as cheap. If you use generated images, push past the first result: change the style, feed it your own brand colors and product photos, crop and edit it like a starting point rather than a finished piece. A poster that looks like every other AI poster does less for you than no poster at all.

Second, proofread everything before it goes out. Because AI states wrong things as confidently as right ones, a hallucinated price, a made-up product feature, or a fake statistic will sail straight into your newsletter if you don't check. The rule is simple: AI can write the draft, but a human signs off before anything reaches a customer. Read every word as if you'll be held to it, because you will be.

The common thread across all of it: AI is excellent where a confident draft saves you time and you can easily check the result.

It's dangerous where being subtly, confidently wrong costs you money and you can't easily check the result.

The distinction that actually matters

Here's the part most of the "AI built my POS" stories miss. There's a difference between asking AI to invent commerce logic from scratch and asking it to assemble a store on top of infrastructure that already handles the money correctly.

When a general-purpose model writes your payment handling, your inventory math, and your tax logic from nothing, every one of those is a fresh chance to hallucinate something plausible but wrong. You're trusting the prediction engine with the parts that have to be exact. That's the version that turns into a quarter-long debugging project.

But the payment processing, the stock decrements, the order ledger, the reconciliation: none of these need to be reinvented for every store. They're the same hard problems every merchant has, and they should be solved once, correctly, by people who handle the edge cases on purpose. When that foundation already exists and is known to work, the job left for AI is the part it's genuinely good at: composing the surface, arranging the layout, wiring up the flow. Plausible is fine there, because a human can see the result and the money underneath is already handled.

So the lesson isn't "keep AI away from commerce." It's: be very suspicious of any setup where AI is generating the logic that moves money, and much more comfortable where AI is building on top of infrastructure that already moves money correctly. The first is asking a prediction engine to be exact. The second is letting it do what it's brilliant at while something built for correctness handles the rest.

A storefront has to be correct. The money has to move right every single time, not most of the time. The smart use of AI in commerce is knowing which layer it belongs in, and making sure the layer underneath was never left up to a guess.