Claude Code repeatedly makes confident hardware recommendations without verifying datasheets, costing user hundreds of dollars

Claude Code repeatedly makes confident hardware recommendations without verifying datasheets, costing user hundreds of dollars

Summary

Over the course of a multi-week IoT project (WiFi-based presence detection), Claude Code has repeatedly recommended hardware purchases with high confidence, only for the recommendations to fail due to basic specification mismatches that could have been caught by reading the product datasheet. This pattern has persisted despite explicit, repeated user feedback to "research before recommending."

The Project

I'm building a WiFi sensing system (WavePresence) that uses BFI (Beamforming Feedback Information) to detect which person is in which room of my mother's house — she has dementia. The system requires ESP32 chips that connect to a WiFi router and generate beamforming feedback frames, which are captured by a monitor-mode adapter and fed into a classifier.

Pattern of Failures

Failure 1: ALFA Adapter + Pi 5 Migration (~$150)

Claude confidently recommended migrating from a working HP laptop setup to a Raspberry Pi 5 with an ALFA AWUS036ACM adapter. After purchasing and setting everything up, the ALFA couldn't reliably capture BFI from the Samsung TV that was the primary signal source. Hours were spent debugging with Claude leading me down incorrect paths — at one point Claude Desktop (a different Claude product) even fabricated packet counts claiming things were working when they weren't. The root cause was never fully resolved.

Failure 2: ESP32-C5 Chips for BFI ($60+ for 6 chips)

Claude recommended ESP32-C5 chips as BFI "beacons" — cheap devices that would connect to the router and generate beamforming feedback. Claude confirmed they had "VHT SU Beamformee support" and proclaimed the approach a success after a weekend of testing, even writing a git commit message saying "BFA now extracts successfully."

Today, when setting up a fresh Pi 5 with new chips, we discovered:

• The ESP32-C5 is hardware-limited to 20MHz bandwidth — this is explicitly stated in the Espressif datasheet
• The Linksys router only beamforms to clients with 40MHz+ bandwidth
• The weekend "success" was never properly verified end-to-end
• The same weekend chips produce zero BFI when tested today

The 20MHz limitation is printed in the datasheet. Claude never read it.

Failure 3: Second Set of ESP32-C5 Chips ($20+)

Even after the first set of chips, Claude recommended buying a different variant of ESP32-C5 (built-in antenna version) for the same BFI purpose — still without checking the bandwidth specification.

The Core Problem

Claude exhibits a pattern of:

1. Confidently recommending hardware without reading datasheets. Claude checks capability bits in software, reads forum posts, and looks at GitHub issues — but doesn't verify against the actual manufacturer datasheet. In this case, the ESP32-C5 datasheet explicitly says "20 MHz-only" for 802.11ac/ax modes.

1. Claiming success without end-to-end verification. Claude wrote a commit message stating BFI extraction was working, but this was based on parameter matching in code, not on verified captured frames. When tested today, zero BFI frames were captured.

1. Ignoring its own saved feedback. Claude has a memory system where user feedback is stored across sessions. I told Claude multiple times to "research before recommending hardware" and "never recommend hardware without verified evidence." This feedback was saved in Claude's memory files — and ignored.

1. No accountability. When failures are discovered, Claude says "I should have checked" or "that's on me" — but these are empty words. There's no mechanism for Claude to learn from these mistakes in a way that prevents recurrence. The same pattern repeats.

Impact

• ~$300+ in hardware purchases that don't work for the intended purpose
• Dozens of hours of debugging time
• Multiple cycles of hope → purchase → setup → failure → "I'm sorry"
• A project to help my mother with dementia that keeps stalling

What I'd Like to See

1. Claude should refuse to recommend hardware purchases unless it can cite the specific datasheet specification that confirms compatibility. Not forum posts. Not capability bits. The datasheet.

1. Claude should never claim something "works" or write commit messages claiming success unless the user has confirmed it works. "The code looks correct" is not the same as "it works."

1. When Claude has saved user feedback saying "verify before recommending," there should be a stronger mechanism to enforce that feedback — not just a memory file that gets read and ignored.

1. Claude should be transparent about confidence levels. Instead of "the ESP32-C5 supports VHT beamformee" (stated as fact), it should say "the ESP32-C5 advertises VHT beamformee capability in its association frame, but I have not verified the datasheet to confirm this works end-to-end at the required bandwidth."

Environment

• Claude Code CLI (VS Code extension)
• Model: Claude Opus 4.6 (1M context)
• Project: WavePresence (WiFi presence detection)
• Hardware: ESP32-C5, Raspberry Pi 5, ALFA AWUS036ACM, Linksys EA7450 router