Building a smart fan with nothing but a chat window and an idea

01 — The idea

It started with a simple question

The premise was straightforward: build a fan that automatically adjusts its speed based on heart rate. Work harder, get more cooling. Rest, and it quiets down. A genuinely useful training tool — responsive, automatic, and personal.

The person asking had some Arduino tinkering experience and a Garmin chest strap they'd been using for years. They didn't know what it transmitted. They didn't have a parts list. They didn't have a circuit. They had an idea and a chat window.

That single constraint — safety — shaped every decision that followed. It's a good example of how stating your requirements upfront changes the entire design space. No mains voltage. No AC control. All decisions pushed toward low-voltage DC electronics that a first-time builder could safely assemble.

02 — Discovery

The real value was in the questions

Before any parts were selected, the conversation surface four constraints that fundamentally shaped the build: experience level, use case, heart rate source, and priorities. These weren't checkbox questions — each answer cascaded into real decisions.

The most consequential discovery: the user's existing Garmin chest strap — model HRM-SS — turned out to be ANT+ only, with no Bluetooth at all. A newer Garmin HRM would have been a natural upgrade choice, but research revealed the HRM Pro Plus had recently been discontinued. The recommendation landed on a Polar H10 instead — better battery life (400 hours), superior open-water swimming performance for a triathlete, and no dependency on the Garmin ecosystem.

The fan choice evolved through several iterations: a 120mm Noctua, then two 120mm fans in parallel, then the realisation that a single 200mm Noctua NF-A20 gives 86 CFM of wide, quiet airflow — better for full-body cooling from a training distance — at nearly the same price.

03 — The review

An AI reviewing its own recommendations

One of the more interesting moments in the project was when the conversation shifted to a review mode — delegating the parts list to three parallel "agents" with different remits: parts accuracy, pricing and sourcing, and safety. This isn't a feature of the tool so much as a prompting technique, but the effect was genuinely useful.

The net result: a parts list that's technically sounder and ~$8 cheaper than the original, with a safety improvement built in. This kind of adversarial self-review — deliberately asking "what's wrong with this?" — is underused as a prompting pattern.

04 — Final parts

The full build, locked in

After the review, the parts list settled at nine components, all available in Toronto or via Amazon.ca with 1–2 day delivery.

05 — The code

From BPM to fan speed in ~100 lines

The sketch connects to the Polar H10 over BLE, subscribes to heart rate notifications, parses the BPM from the raw packet, and maps it to a PWM duty cycle. The fan curves are configurable at the top of the file — three constants you change to tune the feel of the system.

Heart rate → PWM mapping (core logic)

// User-configurable: adjust these for your fitness level
const int HR_MIN      = 60;   // BPM → fan starts
const int HR_MAX      = 160;  // BPM → full speed
const int FAN_MIN_PWM = 60;   // minimum PWM when fan is on

int bpmToPWM(int bpm) {
  if (bpm <= HR_MIN) return 0;              // fan off at rest
  if (bpm >= HR_MAX) return 255;            // full blast at max effort
  float ratio = (float)(bpm - HR_MIN)
              / (float)(HR_MAX - HR_MIN);
  return (int)(FAN_MIN_PWM + ratio * (255 - FAN_MIN_PWM));
}

One known issue was identified during generation and flagged explicitly for the next phase: analogWrite() on the SAMD21 defaults to ~730Hz. The Noctua fan expects 25kHz. This requires configuring a hardware timer directly — something that needs a compiler to validate. That's the handoff point to Claude Code.

06 — The tools

Three tools, one project, no overlap

One of the more instructive aspects of this project is how naturally the three Anthropic tools divide the work — not by design, but because they're genuinely optimised for different things.

The key insight is that these tools share no live memory between them — but they share a filesystem. The handoff brief produced in this conversation is a markdown file. Claude Code reads it as context on session start. Cowork reads the same folder to produce the build guide. The tools are connected not by software, but by files.

07 — What's next

The build is three steps away

The project is at a clean handoff point. Everything that can be done in a conversation has been done. What remains is physical and executable.

08 — The bigger point

What this project actually demonstrates

The smart fan is a useful object. But it's not the point. The point is what the process reveals about how AI tools are becoming genuinely useful for real-world projects — not because they're magic, but because they're good at specific things when used deliberately.

AI as a thinking partner, not an answer machine

The most valuable moments in this conversation weren't when Claude produced outputs — they were when it asked questions. Clarifying experience level, use case, heart rate source, and priorities before making a single recommendation. The quality of the output is entirely dependent on the quality of the framing. This is as true for AI as it is for any expert you'd consult.

The honest acknowledgement of limits

The conversation explicitly flagged what it couldn't do well: compile code, test PWM frequencies against real hardware, verify BLE pairing behaviour. Rather than papering over this, it produced a handoff brief — structured context designed to be read by a different tool better suited to those tasks. That kind of honest scope awareness is what makes an AI tool trustworthy.

The file as the universal handoff

None of these tools share live memory. Claude.ai, Claude Code, and Cowork each start fresh. But they all read files. The workflow that emerged — conversation produces files, files carry context to the next tool — is a pattern that generalises far beyond this project. Any complex undertaking benefits from the same discipline: document decisions as you make them, and those documents become the connective tissue between tools, sessions, and people.