How I AI: Felix Rieseberg's Claude Workflows for 3D House Design and a $20 Hardware Buddy

Felix Rieseberg used Claude to turn an unlabeled realtor floor plan into a navigable 3D house model, pull furniture dimensions out of old Gmail receipts, generate a live dashboard from connected apps, and build a $20 hardware button that approves Claude actions from his desk. The interesting part is not the novelty demos. It is the pattern underneath them. See How to Build a Live, Auto-Updating Personal Dashboard with Claude.

In this episode of How I AI, Felix explains that he keeps pushing toward the highest useful level of abstraction. Instead of asking Claude to help with one tedious step, he asks whether it can own the whole process and return something interactive, inspectable, or reusable. I describe this as the "anti-to-do list": the moment work turns into repetitive cleanup, data entry, or scavenger hunting, stop and ask whether the AI should be building the tool instead.

The demos move from personal life logistics to software tooling and then into hardware. Across all three, Felix keeps making the same move: stop thinking in terms of prompts and start thinking in terms of systems, artifacts, and interfaces that continue to work after the first answer.

Turn a realtor floor plan into a usable 3D house planner

Felix was preparing for a move and wanted to know whether his furniture would actually fit in the new house. The problem was that the realtor floor plan had no measurements attached to it. Instead of manually reconstructing dimensions himself, he dropped the floor plan plus every related document he had into a Claude Cowork folder: disclosures, permits, mortgage paperwork, and property records.

I point out that this is where most people still stop too early. They use AI to assist with a task they are already doing manually instead of asking whether the task itself should disappear. Felix repeatedly catches himself doing this during the demo. He starts entering furniture sizes by hand, then realizes Claude can search his email receipts. He starts by asking for layout suggestions, then realizes he actually wants an interactive planner.

Use related documents to reconstruct missing dimensions

Claude searched across the entire folder looking for any reliable reference point it could anchor against. The floor plan itself had no units, but other documents in the packet did.

Felix used Sonnet 4.6 for this because the task was clearly scoped. His rule of thumb is not about raw technical difficulty. He reaches for Opus when the model also needs to help define or reinterpret the problem itself. If he already knows exactly what success looks like, Sonnet is usually enough.

In this folder, you can find a floor plan. Figure out its units from the other documents, then make a new floor plan with measurements.

Claude found garage dimensions buried inside a permit document and used that as a scaling reference for the rest of the house. From there it generated a new version of the floor plan with measurements attached. Felix noted that this kind of document synthesis is exactly the sort of annoying background work he no longer wants to do himself.

Ask for the tool, not the answer

Once the floor plan had dimensions, Felix initially asked Claude for furniture placement ideas. Midway through the interaction he realized that a static recommendation was the wrong abstraction. He did not want a single answer. He wanted a reusable environment where he and his wife could experiment with layouts themselves.

Claude responded by building a small interactive planning app instead of returning another annotated image. Cowork runs with its own virtual machine, so Claude could generate software directly rather than simulating it in chat. Felix emphasized that he never explicitly requested a 3D environment or specified an implementation approach.

Generate a walkable 3D model from the 2D plan

Claude analyzed the floor plan, identified walls, extruded them into 3D space, and generated a walkthrough model where furniture could still be dragged around interactively. Felix peeked at the transcript afterward and saw that Claude had performed contrast analysis on the image to infer wall boundaries. Even as an experienced engineer, he said he would not personally know how to build that pipeline from scratch. You can follow the full implementation in How to Create an Interactive 3D House Model from a Floor Plan Using AI. See How to Create an Interactive 3D House Model from a Floor Plan Using AI.

The most practical part of the workflow came next. Felix connected Gmail and asked Claude to search his receipts for furniture purchases, extract dimensions, and populate the planner with the items he already owned. I immediately zeroed in on the broader idea: email is effectively a personal inventory database. Furniture, clothing, moving records, receipts, and purchases already exist there. Instead of manually cataloging possessions, Claude could reconstruct them from transaction history.

Build dashboards that refresh themselves from live data

The second demo focused on Live Artifacts inside Claude Cowork. Felix describes artifacts as generated outputs that live beyond the chat itself: reports, dashboards, webpages, presentations, planners, or lightweight apps. A live artifact goes further by reconnecting to current data sources whenever it refreshes.

Connect Claude to your existing services

Claude connectors can access services like Spotify, Gmail, Google Calendar, and Notion once the user signs in and grants permission. Felix stressed that this removes a major point of friction for nontechnical users because they do not need to manage API keys or manually wire together integrations.

Leave room for Claude to shape the dashboard

Instead of rigidly specifying every widget, Felix deliberately left the prompt somewhat open-ended. He asked for a personal daily dashboard using information from his connected services and told Claude to decide what might actually be useful. For the public demo, he also instructed it to fabricate the underlying data rather than exposing his real accounts.

hi. Please make me a personal daily dashboard, including reports and information from my various data services, say Spotify. Gmail calendar notion, whatever else you find that's relevant to my life.

this is for a product demo. Please do not use any real data. Just make all the data up. Thanks.

...make this a modern editorial design, something calming.

also make this a live artifact.

The phrase "whatever else you find that’s relevant" gives Claude room to choose the content and structure instead of rigidly filling predefined slots. "Make this a live artifact" turns the result into something persistent that can pull updated information every time it refreshes.

Restyle the same artifact without rebuilding it

One useful detail in the demo is that the dashboard remained editable after generation. Felix did not rebuild the integrations or regenerate the data layer when he changed the design direction. He simply asked Claude to restyle the interface.

I want this to look like a software made in the early two thousands.

Claude transformed the dashboard into something that looked like early-2000s desktop software, complete with pixel-heavy UI choices and references to Winamp-era design. I noted that the surprising part was not just the visual styling. The copy and tone also shifted to match the requested era. Felix sees this as a broader change in who gets to make software. Designers, writers, and non-engineers can increasingly shape working tools directly instead of handing specifications to developers.

Build a physical approval button for Claude See How to Build a $20 Physical AI 'Buddy' with Claude Code.

The final demo started with a small annoyance. Claude frequently asks permission before taking actions like writing files, and Felix wanted those approvals to happen through a physical device instead of another desktop dialog.

Felix does not consider himself a hardware developer. He has little interest in soldering or embedded systems work. What changed is that he no longer needed to understand the implementation details ahead of time. He could describe the interaction he wanted and let Claude work through the Bluetooth protocol, device communication, and software integration.

Start with an inexpensive off-the-shelf device

Felix bought a small self-contained device for around $19 with an LCD screen, Wi-Fi, Bluetooth, storage, and a large physical button. The appeal was not that it was powerful hardware. It was that commodity components are now cheap enough that software experimentation can spill into the physical world.

Describe behavior instead of implementation

After plugging the device into his computer, Felix described the experience he wanted in Claude Code rather than specifying protocols or low-level instructions. He wanted a tiny Claude companion that could cheer him on and light up whenever approval was required.

I want my little Claude to live on this thing, and I wanted to cheer me on every single time I do a good job, and also every single time I need to approve something that Claude is doing, I want it to be on this big button that is out here.

Claude handled the Bluetooth communication layer and generated the device code in one pass. Felix said he barely had to correct anything. He later open-sourced the project so other people could build variations using different hardware.

Pair the device with the Claude desktop app

The Claude desktop app now includes a Hardware Buddy option inside developer mode, making it possible to pair Bluetooth devices directly with Claude workflows.

1. Open Help, Troubleshooting, then select Enable Developer Mode. The app restarts.

1. Open the new Developer menu and select Open Hardware Buddy.
2. Scan for the Bluetooth device and connect it.

Once connected, the device lights up whenever Claude requests approval for an action. Pressing the physical button allows the task to continue. I connected this to a larger trend she is seeing with kids and AI-native interfaces: increasingly personalized software paired with tiny purpose-built devices instead of giant general-purpose computers.

What is actually worth copying here

The strongest idea across all three demos is not any individual prompt. It is the habit of moving one layer higher every time work starts becoming mechanical. Felix does not stop at generating dimensions. He asks for a planner. He does not stop at a report. He asks for a live dashboard that refreshes itself. He does not accept another approval modal. He builds a physical interface for it.

This approach works best on tasks where the result is easy to verify but tedious to assemble: inventory tracking, planning tools, dashboards, personal operating systems, lightweight internal apps, and one-off utilities that would never justify a traditional engineering project. The human role still matters most in defining the outcome, deciding when the abstraction is wrong, and judging whether the generated system is actually useful. Felix repeatedly changes direction midstream because he notices he is optimizing the wrong thing. That judgment layer still belongs to the user.