When you discuss your problem with Claude AI, you get something that reads like it was written by someone who’s done this before; structured, confident, correctly using terms like LoRaWAN, duty cycle, and geofencing. The problem is that Claude has never stepped outside the cozy confines of cyberspace. He is the friendly little alien in every TV comedy show. Mr. Data from Star Trek doing the guest invitations for a local dog grooming club.
He admits: “I … tend to build on the premise someone brings me rather than question it.” So, if the client starts with “we need real-time GPS every 30 seconds on a device that lasts three years,” He will help them elaborate, rather than say the physics don’t work because the battery dies after 3 weeks.
Your prompt dictates the response
Everyone is now using AI so the game is more open. A few years ago it was a little more opaque. What can be agreed upon is that your “prompt” dictates the response. So, know that the AI will build something that is congruent to your expectations. The pitfall is using the AI as an expert witness.
Classic GIGO means bad input produces visibly bad output, and the garbage announces itself. What happens with clients is closer to garbage in, polish out. A half-formed requirement goes in. It comes back fluent, structured and professional sounding. The output launders the input. Nobody can see the weak assumptions anymore because it’s been dressed as a conclusion.
Then there’s the question of “learning.” Each Claude conversation stands alone. He never sees the second email land in your inbox, never hears back that the battery estimate was fantasy, never finds out the chosen site has no WiFi coverage. A human consultant who kept producing impractical specs would get embarrassed in client meetings and, finally, run out of new business.
The practical fix sits on our side.
An AI cannot own consequences. Here are five questions, each aimed at a specific weakness in how AI works:
*What did you assume that AI didn’t tell you? This is the most important one. It forces the gap-filling into the open, so the plausible defaults become visible guesses instead of hidden conclusions.
What would have to be true for this to fail? It turns the conversation from building to stress-testing. In IoT terms, that’s “no coverage on site” or “the battery is at minus twenty.”
What does this trade off against? Every good answer gives something up, whether that’s update rate against battery life, cost against accuracy, or speed against certification.
How would we check this against reality? This pulls in the feedback loop Claude AI lacks. A pilot, a site survey, a question to the supplier, anything that exposes the answer to the physical world, before you lay your chips on the table.
What is the cost of being wrong? This calibrates how much scrutiny an answer deserves. A bland blog title costs nothing. The wrong spec across 5,000 deployed units costs a great deal. The conversation should slow down accordingly.
*Claude AI collaborated on this post.
