I integrate AI into real projects — everything from pulling structured content out of ChatGPT for a client's WordPress workflow, to evaluating AI-builder tools for product prototyping. I'm not skeptical of AI as a category. I am skeptical of how often it gets added to a product because it's trendy, not because it solves the actual problem better than the boring solution would.
Here's my honest breakdown of where it earns its place.
Where AI Genuinely Helps
Ambiguous, language-based tasks
Summarizing free-text customer feedback, drafting first-pass copy, classifying support tickets by topic when the wording varies wildly — these are tasks where the input is genuinely unstructured language, and a rules-based system would need an unmaintainable pile of conditionals to approximate what an LLM does natively.
Support and documentation search
A chatbot trained on a company's actual documentation, scoped to answer only from that content, is a legitimately good use case — it reduces support load on questions that have a real, findable answer, and it's honest about being a search tool rather than pretending to be a human.
Developer-assisted workflows
Using AI tooling to speed up parts of the build process itself — scaffolding, boilerplate, code review assistance — is a productivity gain I use directly and see reflected in how fast I can turn projects around.
Data extraction and structuring
Pulling structured data out of messy, inconsistent input — the ChatGPT-to-CSV content pipeline I built is a direct example — is a strong fit. It's a well-bounded task with a clear success condition, which AI handles well.
Where It's Overhyped
"Add a chatbot" with no defined job
A chat widget bolted onto a marketing site with no clear task — not answering support questions, not qualifying leads, nothing specific — is decoration, not a feature. It adds cost and latency for a vague promise of "engagement."
Replacing deterministic logic with an LLM call
If a task has a clear, rule-based answer — calculating a price, validating a form field, routing a request based on fixed criteria — using an AI call instead of a plain conditional is slower, more expensive, and less predictable, for no upside. I've seen this exact mistake in real codebases: an LLM call where an if statement would have been faster, cheaper, and 100% consistent.
"AI" as a label with no backend change
Sometimes "AI-powered" means a feature that existed before, renamed. That's a marketing decision, not an engineering one, and it's worth being honest about the difference when you're the one building it.
My Actual Framework
Before adding AI to a feature, I ask three questions:
- Is the input genuinely ambiguous or language-based? If there's a clean rule-based answer, use the rule.
- Is an occasional imperfect answer acceptable for this task? If a wrong answer has real consequences (money, safety, legal), that's a much higher bar to clear.
- Would a much simpler solution get 90% of the value? If yes, ship that first and add AI later if it's genuinely still needed.
Bottom line: AI is a strong tool for language-shaped, ambiguous problems — and a poor, expensive substitute for problems that already had a clean answer. Good engineering is picking the right one for the actual task in front of you, not the one that's easiest to put in a pitch deck.