# How I built a Homey app without an IDE — with Claude Code, Superpowers Skill, and an agentic development loop **URL:** \ **Category:** Developers\ **Created:** [July 10, 2026, 10:19pm UTC](https://community.homey.app/t/how-i-built-a-homey-app-without-an-ide-with-claude-code-superpowers-skill-and-an-agentic-development-loop/157110 "2026-07-10T22:19:17Z")\ **Posts on this page:** 15\ **Page:** 1
**Author:** ![Torsten\_Sturm](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/torsten_sturm/32/77900_2.png) [@Torsten\_Sturm](https://community.homey.app/u/Torsten_Sturm)\ **Post date:** [July 10, 2026, 10:19pm UTC](https://community.homey.app/t/how-i-built-a-homey-app-without-an-ide-with-claude-code-superpowers-skill-and-an-agentic-development-loop/157110/1 "2026-07-10T22:19:17Z")
I recently published a Homey app — **Violet + BADU Blue Pool Control** ([app thread](https://community.homey.app/t/violet-badu-blue-pool-control-for-homey/157109)) — for a pool controller. That thread is about the app. This one is about _how_ it was built, because the process was interesting in itself: the app was written **without using a traditional IDE** at all. Everything happened in **Claude Code** in the terminal, with GitHub for version control. Over time, the setup also grew into an automated, self‑checking development loop. Here is how it went. ## How it began — a few talks that changed my mind I have worked in software development for a few decades, and I had clear opinions about how it should be done. A few talks changed that, and they are the reason I tried this at all. The one that stayed with me was **Boris Cherny** (Creator and Head of Claude Code) saying that, once Claude Code existed, he basically **stopped opening an IDE** and did not go back to it. For someone who spent his whole career working inside an editor, that was surprising. If you want to see what changed my mind, these are the talks: - _Why Coding Is Solved, and What Comes Next_ — Boris Cherny (the “the bottleneck moves” idea I come back to at the end): [https://www.youtube.com/watch?v=SlGRN8jh2RI&t=802s](https://www.youtube.com/watch?v=SlGRN8jh2RI&t=802s) - _Reflecting on a year of Claude Code_: [https://www.youtube.com/watch?v=Hth\_tLaC2j8](https://www.youtube.com/watch?v=Hth_tLaC2j8) - _A live agentic‑coding session_ (Boris Cherny & Jarred Sumner): [https://www.youtube.com/watch?v=DlTCu\_pNDHE](https://www.youtube.com/watch?v=DlTCu_pNDHE) So I decided to test the idea on a real and unfamiliar project. I am a solid **C#/.NET** developer, and JavaScript is close enough to read, but I had **never written a Homey app** , never used this controller’s local API, and the pool‑chemistry maths I wanted (a live **Langelier Saturation Index** safety net to protect my heat exchanger from corrosion) was new to me. That made it a good test: if IDE‑free, agent‑driven development only works on small toy problems, a project like this would show it. The traditional path would have been several weeks of learning the SDK, working out the controller’s API, and then writing and debugging everything by hand. Instead, I stayed in the role of engineer and domain expert, and let the agent do the typing. ## Superpowers: the basis for working without an IDE What made this real engineering, and not just “chatting with an AI until something works”, was a set of workflow skills called **Superpowers** (by Jesse Vincent / `obra`). It gives the agent a fixed process and does not let it skip steps: - **brainstorming** a design before writing any code, - **writing plans** from that design, - **test‑driven development** — tests first, then the code, - **systematic debugging** instead of trial and error, - a **code review** and a **verification** step at the end. Two community skills handle the Homey‑specific parts: a **homey‑app** skill (everything Claude Code needs to now abount Homey SDK, conventions etc in one place) and a **homey‑cli** skill (using the Homey CLI, inspecting the live device, building flows from the terminal, way more functionality than the Homey MCP Server). This let the agent check its work against my real Homey while it worked. The project was built milestone by milestone. Each milestone was turned into a spec, then a plan, then implemented test‑first, then validated and released, with: - a committed **progress dashboard** for every milestone, - **git hooks** that block broken manifest/changelog JSON and prevent secrets from being committed, - **automated security reviews** (a dedicated review subagent and a written threat model) for anything that writes to the controller, - everything in **two languages (EN/DE)**, including the tests. **The result:** an app with about 40 device capabilities, the LSI engine, optional write control, and a full unit‑test suite — from the first milestone to a Store test release in roughly **two weeks of part‑time evenings** (around 30–40 hours of my own time). If I had built it the traditional way, alone, while learning the SDK, working out the controller’s API, checking the chemistry, and doing the write path safely in two languages, I would estimate **several months of spare‑time work (150–250 hours)**. The AI did not replace the engineering decisions; it mainly saved time on the parts that would have cost the most: learning the platform and the domain. ## The next step: making the loop run on its own Once the app was ready for the Store, I became more interested in the development loop than in the app itself. A short self‑assessment put my setup at **level 3 of 4** : the inner loop was verified (hooks, TDD, subagent checks), but there was no automated outer loop, no CI, and the test results did not actually block anything. This produced a list of **12 concrete improvements**. So I pointed the agent at its own toolchain. Using the **`/claude‑automation‑recommender`** skill (which analyses a repository and suggests hooks, subagents, CI and skills) together with the **Fable 5** model, I worked through all 12. The main ones: - **Blocking gates** — failing tests or a failing type‑check now block the commit; a missing changelog or version bump blocks a publish. - **CI and a heartbeat** — GitHub Actions runs the tests and `homey app validate` on every push, plus a nightly run. - **A mock harness** — the glue code in the device driver (where the one real crash had happened) is now tested every time. - **A read‑only live‑smoke test** against the real controller. - **A stop‑verify hook** — a work session cannot end with failing tests or a failing validate. - **A nightly triage routine** that runs the suite and writes the findings into an inbox file that every new session reads first. - **Hook telemetry** feeding a workflow “retro” — a small meta‑loop that learns from repeated friction. - **Condition‑driven milestone loops** (`/goal`) with a separate, cheaper model as the checker. - **Model tiering** — mechanical work runs on a small, fast model, and only the checking and judging steps use the strongest model, so the checker is never the weak point. This moved the setup to **level 4: an automated outer loop** — nightly CI and triage, test feedback that really blocks, and telemetry as a basis for improvement. ## Making it reusable The last step was to move the whole setup out of the pool project and into a **portable skill/plugin** — `skill‑agentic‑loop‑framework` — so the same setup can be used on the next project from day one, instead of being rebuilt each time. [GitHub - tnsturm/skill-agentic-loop-framework · GitHub](https://github.com/tnsturm/skill-agentic-loop-framework) ## How well it works today - The **inner loop** is verified by the hooks, TDD, subagent checks and the retro meta‑loop. The **outer loop** runs on its own: nightly CI stays green, and the triage inbox gets filled. - **The human still makes the decisions.** Push and publish stay manual steps — the agent never ships on its own. My real work is the domain knowledge, testing on the real hardware, and the decisions. - A good example: I evaluated moving the trickiest file to TypeScript and, after a proper test, decided **not** to do it — it would have added risk and kept two diverging build artefacts for no real type‑safety gain (the strict JavaScript check already covered that). The loop is good at doing the work; deciding _whether_ to do it is still my job. - Known bugs are not ignored — they are **frozen as `todo` tests** that describe the correct behaviour, so every run lists them without turning green until they are properly fixed. - **Model tiering keeps the cost reasonable** — you do not pay for the strongest model on mechanical work, and you never save money on the checker. In short: I shipped an app well outside my previous experience, and I got a reusable, self‑checking development loop as a side effect. ## Tools, if you want to try this - **Superpowers** (the workflow skills — brainstorming, plans, TDD, debugging, review) — [GitHub - obra/superpowers: An agentic skills framework & software development methodology that works. · GitHub](https://github.com/obra/Superpowers) - **homey‑cli skill for Claude Code** — [Homey-cli skill for Claude Code - drive Homey /build flows from terminal and AI agents](https://community.homey.app/t/homey-cli-skill-for-claude-code-drive-homey-build-flows-from-terminal-and-ai-agents/155229) - **homey‑app skill** — [GitHub - dvflw/homey-app-skill · GitHub](https://github.com/dvflw/homey-app-skill) - **`/claude‑automation‑recommender`** — the Claude Code skill that suggests hooks/subagents/CI/skills for a repository. - **`skill‑agentic‑loop‑framework`** — the extracted, portable loop setup. [GitHub - tnsturm/skill-agentic-loop-framework · GitHub](https://github.com/tnsturm/skill-agentic-loop-framework) - The example that got me started — Andi Wirz building a published Homey app with Claude without hand‑writing code: [How I built a Homey app with Claude AI — without writing a single line of code myself | wirzfamily.ch](https://www.wirzfamily.ch/how-i-built-a-homey-app-with-claude-ai-without-writing-a-single-line-of-code-myself/) ## The bottleneck moves Boris Cherny describes the whole change with one idea: **the bottleneck moves.** First the hard part is writing the code. Once that is automated, the hard part becomes verification. Once that is automated, it becomes the decision to merge and ship. After that, he expects it to be planning. His rule: _“Every time there’s a new bottleneck, you have to automate that bottleneck.”_ ## Back to the start This brings me back to where I began: Boris Cherny not opening an IDE anymore. A few weeks ago that surprised me. After building and shipping a real app this way, and watching the bottleneck move step by step, it no longer looks like a bold claim to me. It looks like the direction things are going. Happy to answer questions about any part of the workflow. The app itself is here: [[Violet + BADU Blue — Pool control for Homey - Apps - Homey Community Forum](https://community.homey.app/t/violet-badu-blue-pool-control-for-homey/157109)] (and a German write‑up on [poolsteuerung.de](http://poolsteuerung.de): [[Violet + BADU Blue in Homey Pro – neue App mit LSI Berechnung - PoolDigital Forum](https://www.poolsteuerung.de/viewtopic.php?t=2493)]). The source is on GitHub: [GitHub - tnsturm/violet-homey-app · GitHub](https://github.com/tnsturm/violet-homey-app) ---
**Author:** ![smarthomesven](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/smarthomesven/32/79712_2.png) [@smarthomesven](https://community.homey.app/u/smarthomesven)\ **Post date:** [July 11, 2026, 8:29am UTC](https://community.homey.app/t/how-i-built-a-homey-app-without-an-ide-with-claude-code-superpowers-skill-and-an-agentic-development-loop/157110/2 "2026-07-11T08:29:47Z")
So you never even check the code? So if Claude somehow recommends a malware/non existent package on npm (happens more than you think) you just install it without even checking? That is very dangerous, you should **always** check the code or command before running it. ---
**Author:** ![robertklep](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/robertklep/32/160628_2.png) [@robertklep](https://community.homey.app/u/robertklep)\ **Post date:** [July 11, 2026, 8:32am UTC](https://community.homey.app/t/how-i-built-a-homey-app-without-an-ide-with-claude-code-superpowers-skill-and-an-agentic-development-loop/157110/3 "2026-07-11T08:32:14Z")
_Many_ Homey apps nowadays are being generated by LLM’s without any scrutiny, from what I’m seeing. Also because the people using LLM’s tend to not be developers so don’t know where to look. ---
**Author:** ![DaneedeKruyff](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/daneedekruyff/32/964_2.png) [@DaneedeKruyff](https://community.homey.app/u/DaneedeKruyff)\ **Post date:** [July 11, 2026, 8:39am UTC](https://community.homey.app/t/how-i-built-a-homey-app-without-an-ide-with-claude-code-superpowers-skill-and-an-agentic-development-loop/157110/4 "2026-07-11T08:39:19Z")
Hi @Torsten_Sturm, Great to read this learning path from an experienced developer! Very inspiring! I’m no developer myself but I do work a lot with AI both professionally and for personal (help in developing my apps) use. The most important part in your post for me is this: > [@Torsten\_Sturm](#): > > The AI did not replace the engineering decisions; it mainly saved time on the parts that would have cost the most: learning the platform and the domain. That’s crucial for people to realize, AI is just another tool, not the solution. ---
**Author:** ![smarthomesven](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/smarthomesven/32/79712_2.png) [@smarthomesven](https://community.homey.app/u/smarthomesven)\ **Post date:** [July 11, 2026, 9:09am UTC](https://community.homey.app/t/how-i-built-a-homey-app-without-an-ide-with-claude-code-superpowers-skill-and-an-agentic-development-loop/157110/5 "2026-07-11T09:09:55Z")
Well, I know that not everybody who uses Claude is a developer, but you can at least check through the code to see if there are any strange URLs or obfuscated code. I build a few Android (React Native) apps with Claude for personal use, but I often see that it just hallucinates a package that doesn’t exist (for example for Bluetooth advertising). There are many hackers finding these nonexistent packages from Claude and publishing their malware using that package name on npm. Then, when someone installs it (or Claude installs it for them), they’ll be infected with malware. The first thing to do when Claude recommends a package is to go to [npmjs.com](http://npmjs.com) and looking it up there. Go to the Versions tab, when was the first version published? If it was published recently, you should be more skeptical. Go to the Dependencies tab, does it have any dependencies that it doesn’t need? Go to the Code tab, are there any pre-install scripts (very often abused by malware)? Are there any strange binaries or obfuscated code? And when the package is fully safe, you should always install the latest version. Claude often recommends older package versions with many security vulnerabilities, so just running `npm install [package]@latest` instead of the version that Claude recommends is best practice. ---
**Author:** ![Torsten\_Sturm](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/torsten_sturm/32/77900_2.png) [@Torsten\_Sturm](https://community.homey.app/u/Torsten_Sturm)\ **Post date:** [July 11, 2026, 10:37am UTC](https://community.homey.app/t/how-i-built-a-homey-app-without-an-ide-with-claude-code-superpowers-skill-and-an-agentic-development-loop/157110/6 "2026-07-11T10:37:50Z")
Hi Sven, in the beginning, I did check everything by myself. But then again you or your team become a new bottelneck. But exactly this is the point… Claude Code or Codex etc are Development Automation Tools. Think of Claude Code as a team of extremly fast and efficient human developers. It is not possible then that you as a teamleader check every single developers decision about package usage. You will create (pre-)guidelines and checks and verifications within CI. Same is with Claude Code. You have to tell it what to do. But because it is much faster than humans developers, you can tell him: do 100% TDD, write a test for 100% of functionality, do full end to end testing every time, and if you find something solve it until all verification gates are green. And yes, there is still halluzination, but with proper guidelines and the latest Models (Fable 5), this got way better. But think of the humnan development team… not all of them will be the worlds leading employees in this domain… you will have to take precautions to automatically recognize and fix common mistakes. Same with Claude Code… As an example, most Clauders now you use the context7 plugin… it always ensures, that Claude Code works with the latest SDK docs of the project… automatic and within seconds. ---
**Author:** ![smarthomesven](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/smarthomesven/32/79712_2.png) [@smarthomesven](https://community.homey.app/u/smarthomesven)\ **Post date:** [July 11, 2026, 10:48am UTC](https://community.homey.app/t/how-i-built-a-homey-app-without-an-ide-with-claude-code-superpowers-skill-and-an-agentic-development-loop/157110/7 "2026-07-11T10:48:55Z")
It’s not about untested code, but more about the risk of getting infected with malware. It often happens that Claude comes up with an npm package that doesn’t exist. But sometimes, hackers will publish an npm package with that name, so that whenever Claude installs the previously non-existent package, it will then infect you with malware. I would recommend reading this article for more information about the hallucinated packages: > **[AI hallucinations lead to a new cyber threat: Slopsquatting](https://www.csoonline.com/article/3961304/ai-hallucinations-lead-to-new-cyber-threat-slopsquatting.html)** > > Attackers can weaponize and distribute a large number of packages recommended by AI models that don’t really exist. > [@Torsten\_Sturm](#): > > check every single developers decision about package usage Yes, but human developers don’t simply come up with packages that don’t exist​😉 ---
**Author:** ![robertklep](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/robertklep/32/160628_2.png) [@robertklep](https://community.homey.app/u/robertklep)\ **Post date:** [July 11, 2026, 11:10am UTC](https://community.homey.app/t/how-i-built-a-homey-app-without-an-ide-with-claude-code-superpowers-skill-and-an-agentic-development-loop/157110/8 "2026-07-11T11:10:10Z")
Claude seems to be missing some fundamental Homey specifics though. For instance, [using a random UUID as device ID](https://github.com/tnsturm/violet-homey-app/blob/7585be388fc0a937b826ec7eaab4ed0ec51bb1de/drivers/pool/driver.js#L76) is not a good idea, and [Homey stores aren’t encrypted](https://github.com/tnsturm/violet-homey-app/blob/7585be388fc0a937b826ec7eaab4ed0ec51bb1de/drivers/pool/driver.js#L100). ---
**Author:** ![Torsten\_Sturm](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/torsten_sturm/32/77900_2.png) [@Torsten\_Sturm](https://community.homey.app/u/Torsten_Sturm)\ **Post date:** [July 11, 2026, 11:28am UTC](https://community.homey.app/t/how-i-built-a-homey-app-without-an-ide-with-claude-code-superpowers-skill-and-an-agentic-development-loop/157110/9 "2026-07-11T11:28:11Z")
very good point… I will check what Claude suggests how to handle it. Thanks for that special feedback. ---
**Author:** ![smarthomesven](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/smarthomesven/32/79712_2.png) [@smarthomesven](https://community.homey.app/u/smarthomesven)\ **Post date:** [July 11, 2026, 12:50pm UTC](https://community.homey.app/t/how-i-built-a-homey-app-without-an-ide-with-claude-code-superpowers-skill-and-an-agentic-development-loop/157110/10 "2026-07-11T12:50:25Z")
> [@robertklep](#): > > [using a random UUID as device ID](https://github.com/tnsturm/violet-homey-app/blob/7585be388fc0a937b826ec7eaab4ed0ec51bb1de/drivers/pool/driver.js#L76) is not a good idea Yes indeed, the whole point of that ID is to make sure that the same device can only be added once. Should be a unique identifier (e.g. ID from the cloud server of the manufacturer or the MAC address). > [@robertklep](#): > > and [Homey stores aren’t encrypted](https://github.com/tnsturm/violet-homey-app/blob/7585be388fc0a937b826ec7eaab4ed0ec51bb1de/drivers/pool/driver.js#L100). Yes. However, stores can’t be fetched from the API. Settings can be fetched from the API though. AFAIK there is no way to encrypt anything on Homey. ---
**Author:** ![Torsten\_Sturm](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/torsten_sturm/32/77900_2.png) [@Torsten\_Sturm](https://community.homey.app/u/Torsten_Sturm)\ **Post date:** [July 11, 2026, 10:11pm UTC](https://community.homey.app/t/how-i-built-a-homey-app-without-an-ide-with-claude-code-superpowers-skill-and-an-agentic-development-loop/157110/11 "2026-07-11T22:11:20Z")
I see… Some other Homey Apps are using the IP address ([com.luxtronik.heatpump/drivers/luxtronik-heatpump/driver.js](https://github.com/andiwirz/com.luxtronik.heatpump/blob/main/drivers/luxtronik-heatpump/driver.js)), but this is also not recommended by [Pairing | Homey Apps SDK](https://apps.developer.homey.app/the-basics/devices/pairing#device-pairing-data). But how do I get the MAC address at this point? ---
**Author:** ![smarthomesven](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/smarthomesven/32/79712_2.png) [@smarthomesven](https://community.homey.app/u/smarthomesven)\ **Post date:** [July 11, 2026, 10:38pm UTC](https://community.homey.app/t/how-i-built-a-homey-app-without-an-ide-with-claude-code-superpowers-skill-and-an-agentic-development-loop/157110/12 "2026-07-11T22:38:46Z")
> [@Torsten\_Sturm](#): > > ([com.luxtronik.heatpump/drivers/luxtronik-heatpump/driver.js](https://github.com/andiwirz/com.luxtronik.heatpump/blob/main/drivers/luxtronik-heatpump/driver.js)), And that’s another vibe coded (fully AI-generated) app, so the same applies here with the AI not being able to understand Homey’s architecture. > [@Torsten\_Sturm](#): > > But how do I get the MAC address at this point? How does your device connect? Most devices connect using a cloud service, usually those store an ID for the device that you can use. If it connects via a LAN connection it can be trickier. ---
**Author:** ![robertklep](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/robertklep/32/160628_2.png) [@robertklep](https://community.homey.app/u/robertklep)\ **Post date:** [July 12, 2026, 4:56am UTC](https://community.homey.app/t/how-i-built-a-homey-app-without-an-ide-with-claude-code-superpowers-skill-and-an-agentic-development-loop/157110/13 "2026-07-12T04:56:15Z")
> [@Torsten\_Sturm](#): > > But how do I get the MAC address at this point? Ask Claude 😉 ---
**Author:** ![Torsten\_Sturm](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/torsten_sturm/32/77900_2.png) [@Torsten\_Sturm](https://community.homey.app/u/Torsten_Sturm)\ **Post date:** [July 13, 2026, 9:59am UTC](https://community.homey.app/t/how-i-built-a-homey-app-without-an-ide-with-claude-code-superpowers-skill-and-an-agentic-development-loop/157110/14 "2026-07-13T09:59:21Z")
I did ask Claude, and it came up with: “Torsten, I reviewed the Violet API again, and I stumbled upon the undocumented field HW\_SERIAL\_CARRIER in the logged replies. It looks like it could help. It might be a good idea to ask the manufacturer to verify this information.” I did that and got confirmation… 😊 @robertklep thanks for your code review!!! ---
**Author:** ![robertklep](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/robertklep/32/160628_2.png) [@robertklep](https://community.homey.app/u/robertklep)\ **Post date:** [July 13, 2026, 11:05am UTC](https://community.homey.app/t/how-i-built-a-homey-app-without-an-ide-with-claude-code-superpowers-skill-and-an-agentic-development-loop/157110/15 "2026-07-13T11:05:07Z")
It looks like there are multiple fields that could contain a serial number, [according to the Home Assistant integration source](https://github.com/Xerolux/violet-hass/blob/cc3664416c6fbaf97a18a93f08ecd4e824dd4b2f/custom_components/violet_pool_controller/device.py#L715).